1. Unified Software Development Process
1. The Unified Process: Use-Case Driven, Architecture-Centric, Iterative, and Incremental.
2. The Four Ps: People, Project, Product, and Process in Software Development.
3. A Use-Case-Driven Process.
4. An Architecture-Centric Process
5. An Iterative and Incremental Process

2. Unified Process: Use-Case Driven, Architecture-Centric, Iterative, and Incremental
·    The trend in software is toward bigger, more complex system.
·    A process defined who is doing what when and how to reach a certain goal. (Technologies, Tools, People, Organization Patterns)
·    Unified Software Development Process: the outcome of more than 30 years of experience.

3. Software Development Process
· A Software development process is the set of activities needed to transform a user’s requirements into a software system.
Software Development Process
Software
System
User’s
Requirements

4. Unified Process
·    Unified Process is component-based, which means that the software system being built is made up of software components interconnected via well-defined interfaces in UML. The three key words – use-case driven, architecture-centric, and iterative and incremental
·    Abstract – Concrete: helicopter perspective.
E.g. Drawing Static Fruits on Table in Fine Art

5. Unified Process is Use-Case Driven
User (Actors & Stakeholders) represents someone or something that interacts with the system being developed.
An interaction is a use case (action), a piece of functionality in the system. (use-case view)
Use cases are not just a tool for specifying the requirements of system. They also drive its design, implement, and test: that is, they drive the development process – use cases are specified, use cases are designed, testing cases.

6. Unified Process is Architecture-Centric
Software architecture captures the most significant static and dynamic aspects of the system. (subsystem)

7. Unified Process is Iterative and Incremental
Each mini-project is an iteration that results in an increment. (rolling snow ball). In the following figure, iterative and increment development proceeds as a series of iterations that evolve into the final system.
Initial risks
Initial project scope
Revise Project plan
Define iterative to address
the highest risks
Revise risk assessment
Risks eliminated
Assess the iteration
Plan and develop the iteration

8. Unified Process is Iterative and Incremental
Each iteration consists of one or more of the following process components: requirements capture, analysis and design, implementation, and test.
Developers do not assume that all requirements are known at the beginning of the life cycle; indeed change is anticipated throughout all phases.
This type of life cycle is a risk-mitigating process. Technical risks are assessed and prioritized early in the life cycle and are revised during the development of each iteration. Risks are attached to each iteration so that successful completion of the iteration alleviates the risks attached to it. The releases are scheduled to ensure that the highest risks are tackled first.

9. Two Dimensions Time and Process Component
Time—division of the life cycle into phases and iterations.
 Inception—specifying the project vision
 Elaboration—planning the necessary activities and
required resources; specifying the features and
designing the architecture.
 Construction—building the product as a series of
incremental iterations.
 Transition—supplying the product to the user
community(manufacturing, delivering, and training).

10. Two Dimensions Time and Process Component
Process Components—production of a specific set of artifacts with well-defined activities.
Requirements capture — a description of what the system should do.
Analysis and design — a description of how the system will be realized in the implementation phase.
Implementation—the production of the code that will result in an executable system.
Test—verification and validation of the entire system.

11. The Five workflows-Req. Ana. Des. Imp. Test
Phases
Inception Elaboration Construction Transition
Process Components
Requirement Capture
Analysis and Design
Implementation
Test
Supporting Components
Management
Environment
Deployment
The Five workflows-Req. Ana. Des. Imp. Test

12. Models of the Unified Process
Use–Case Model
Analysis Model
Design Model
Deployment Model
Implementation Model X OK
Test Model
Specified by
Realized by
Distributed by
Implemented by
Verified by

13. Use-Case-Driven Process
Requirements capture has two objectives: -- to find the true requirements.
-- to represent them in a suitable way for the users, customers, and developers.
All the actors and use cases of a system make up a use-case model.
·  Analysis model is different from the design model in that it is a conceptual model rather than a blueprint of the implementation.

14. Use Case
    Why Use Cases?
1.   to capture the value adding requirements. (actors, use cases, intuitive, agreement)
2.   to drive the process (requirement – analysis – design – implementation – test).
3.   to devise the architecture and more …( help to carry out iterative development, which a working realization of a set of use cases.)

15. Capturing the Use Cases
1.   The use-case model represents the functional requirements. Other requirements are either “attached” to the use cases that they concern or kept in a separate list or described in some other way.
2.   Actors are the environment of the system. (messages)
3.   Use cases specify the system. A use case specifies a sequence of actions, including variants, that the system can perform and that yields an observable result of value to a particular actor.

16. A use-case model of ATM system
Withdraw Money
Deposit Money
Bank
Customer
Transfer between Accounts

17. Withdraw Money Use Case
The sequence of actions for a path through this use case is
1.  The bank customer identifies himself or herself.
2.  The bank customer chooses from which
account to withdraw money and specifies
how much to withdraw.
3.  The system deducts the amount from the
account and dispenses the money.

18. Realization of a Use Case in Analysis Model
Use-Case Model
Analysis Model
Withdraw Money
Withdraw Money
participant
Dispenser
Cashier
interface
Withdraw
Account
<<boundary>>
<<control>>
<<entity>>

19. A Class Participating in Several Use-Case Realizations in the Analysis Model
Use-Case Model
Analysis Model
Withdraw Money
Dispenser
Withdraw
Deposit Money
Cashier
Interface
Transfer
Bank
Customer
Bank
Customer
Account
Transfer between
Accounts
Money Receptor
Deposit

20. Using a Collaboration Diagram to Describe a Use-Case Realization
1: identify
2: request withdrawal
3: validate and withdraw
:Cashier
Interface
:Bank
Customer
:Withdraw
:Account
4: authorize dispense
5: dispense money
:Dispenser
A Collaboration Diagram for the Withdraw Money use-case realization in the analysis model

21. Use-Case Realizations in Analysis and Design Models
Use-Case Model
Analysis Model
Design Model
Withdraw Money
Withdraw Money
Withdraw Money

22. Use-Case Realizations in Analysis and Design Models
Analysis
Model
Cashier Interface
Dispenser
Withdraw
Account
Design
Model
Dispenser
Sensor
Withdraw
Account
Display
Dispenser
Feeder
Client
Manager
Persistent
Class
Key Pad
Transaction
Manager
Cash
Counter
Account
Manager
Card Reader
Design Classes in the Design Model tracing to Analysis classes

23. Use-Case-Driven Process
Card Reader
Transaction
Manager
Display
Client
Manager
persistent
class
Key Pad
Withdrawal
Dispenser
Feeder
Cash
Counter
Account
Manager
Dispenser
Sensor
Account
A class diagram realization of Withdraw Money use case

24. A sequence diagram of Withdraw Money

25. Three subsystem and a service subsystem
Card Reader
Display
Key Pad
Dispenser
Sensor
Feeder
Client
Manager
Cash
Counter
Account
Transaction
persistent
class
Withdrawal
<<subsystem>>
ATM Interface
<<service
subsystem>>
withdrawal
Management
Dispensing
Transfers
<<subsystem>>
Account
Management
Bank
Customer
Three subsystem and a service subsystem

26. <<executable>> <<file>>
Dispenser
Sensor
Feeder
Client
Manager
Cash
Counter
Design Model
Implementation Model
<<trace>>
<<compilation>>
<<executable>>
client.exe
<<file>>
client.c
dispenser.c
Components implementing design classes

27. Identifying a Test Case from a Use Case
Test Model
Use-Case Model
<<trace>>
Withdraw Money-Basic Flow
Withdraw Money
Input:
The Bank customer’s account has a balance of $350.
The Bank Customer identifies himself correctly.
The Customer request to withdraw $200 from the account
There is enough money (at lest $200) in the ATM.
Result:
The balance of the Customer’s account decreases to $150.
The Bank Customer receives $200 from the ATM.
Conditions: No other use cases (instances) are allowed to access the account during this test case.

28. Summary of A Use-Case-Driven Process
Use Cases drive the process.
During the requirements workflow, developers can represent requirements as use cases. Project managers can then plan the project in terms of the use cases that developers work with.
During analysis and design, developers create use-case realizations in terms of classes or subsystems. Developers then implement components. Components are integrated into increments that each realize a set of use cases.
Finally, testers verify that the system implements the right use cases for the users. In other words, use cases bind together all development activities and drive the development process--this is perhaps the most important benefit of the use-case-driven approach.
But this is not all. Other aspect of unified process is architecture-centric.

29. An Architecture-Centric Process
1. Use Cases Driven Workflow: Requirement  Analysis  Design  Implementation  Test
2. Use Cases alone are not enough to achieve a working system. It should be supplied with architecture
3. Architectural model elements: subsystems, dependencies, interfaces, collaborations, nodes, active classes.
4. Blind men and elephant: a big snake (the trunk), a piece of cord (tail), a big fan (ear), or a small tree (the leg).
5. Software architecture encompasses the significant decisions about
The organization of a software system.
The structural elements and their interfaces that will comprise the system, together with their behavior as specified in the collaborations among those elements.

30. An Architecture-Centric Process
The composition of the structural and behavioral elements into progressively larger subsystems.
The architectural style that guides this organization: the elements and their interfaces, their collaborations, and their composition.
6. Architecture Description(Views of Models): 4+1 views, use-case model, analysis model, view of design model, …
7. Why we need architecture?
Understand the system
Organize development
Foster reuse
Evolve the system

31. The Layered Architecture Organizes Systems in Layer of Subsystem
Application-specific layer
Application-general layer
Middleware layer
System-software layer

32. Architecture of ATM System
Architecture View of the Use-Case Model of the ATM System
Architecture View of the Design Model of the ATM System
<<subsystem>>
ATM
Interface
Withdrawal
<<subsystem>>
Transaction
Management
<<subsystem>>
Account
Management
Transfers
Dispensing
History
Transferal
Deposits
Architecture View of the Deployment Model of the ATM System
ATM Client
ATM App.
Server
ATM Data
Sever
internet
internet
Bank
Customer

33. Summary of An Architecture-Centric Process Chapter
Three Interesting Concepts
What is architecture?
Software architecture focuses both on the significant structural elements of the system, such as subsystem, classes, components, and nodes, as well as collaborations that occur among these elements via interfaces.
How is it Obtained?
The architecture is developed iteratively during the elaboration phase through requirements, analysis, design, implementation and test.
How is it Described?
The architecture description is a view of the models of the system. (use-case, analysis, design, implementation and deployment models.

34. An Iterative and Incremental Process
Software Process needs to have a sequence of clearly articulated milestones. (Referring to Part III)
Inception Phase: the essential criterion is viability, approached by
Identifying and reducing the risks critical to the systems’ viability.
Moving from a key subset of the requirements through use-case modeling into a candidate architecture.
Making an initial estimate within broad limits, of cost, effort, schedule, and product quality.
Initiating the business case that the project appears to be economically worth doing, again with broad limits.

35. An Iterative and Incremental Process
Elaboration Phase: the essential criterion is the ability to build the system in an economic framework.
Identifying and reducing the risks significantly affecting system construction.
Specifying most the use cases that represent the functionality.
Extending the candidate architecture to executable baseline proportions.
Preparing a project play in sufficient detail to guide the construction phase.
Making an estimate within limits narrow enough to justify a business bid.
Finalizing the business case -- project is worth doing.

36. An Iterative and Incremental Process
Construction Phase: the essential criterion is a system capable of initial operation in the users’ environment, approach by
A series of iteration, leading to periodic builds and increments, so that throughout this phase, viability of the system is always evident in executable form.
Transition Phase: the essential criterion is a system that achieves final operational capability, approached by
Modifying the product to alleviate problems not identified in the earlier phases.
Correcting defects.
The phases and the iterations within them receive more detailed treatment in Part III

37. Why Iterative and Incremental Development?
Develop in Small Steps (min-waterfall)--The third key for developing a software product in small manageable steps.
1. You plan a little You specify, design, and implement a little You integrate, test, and run each iteration a little.
Why Iterative and Incremental Development?
1. To get a handle on the critical and significant risks early To set forth an architecture to guide software development To provide a framework that better handles inevitable requirements and other changes To build up the system over time incrementally rather than all at once near the end when change becomes expensive To provide a development process through which the staff can work more effectively.

38. Requirements Capture: From Vision to Requirements
Why Requirements Capture is Difficult.
Professional software developers usually build software for someone other than themselves.
Overview of Requirements Capture
Every software project is unique. This singularity comes from the variations in the kind of system, the customer, the development organization, the technology, and so on.
Requirement capture workflow includes the following steps.
1. List candidate requirements Understand system context Capture functional requirements Capture nonfunctional requirements.

39. Example: The Sales: From Order to Delivery Business Use Case
Workers take the following steps in the business use case Sales: From Order to Delivery:
1. A buyer orders goods or services by contacting the seller.
2. The Seller sends an invoice to the buyer through the payment handler.
3. The seller delivers the goods or services to the buyer.
4. The buyer pays via the payment handler. This involves transferring money from the account of the buyer to the account of the seller.
Seller
Buyer
Payment
Handler
Buyer
Seller
Account
Invoice

40. Capturing the Requirements as Use Cases
Use Case Model (actors + use cases with constraints)
Use-cases (functional requirements)
Supplementary requirements (non-functional)
Workflow for Capturing Requirements as Use Cases
System Analyst
Architect
Use-Case
Specifier
Find Actors and Use Cases
Prototype
User-Interface
Detail a Use Case
Prioritize
Use Cases
Structure the
Use Case Model
User-Interface
Designer

41. Summary of the Requirement Workflow
How to Capture the Requirements on a System?
A business model or a domain model to set the context of the system
A use-case model that captures the functional and the nonfunctional requirements that are specific to individual use cases. The use-case model is described by a survey description, a set of diagrams, and a detailed description of each use case.
A set of user interface sketches and prototypes for each actor representing the design of the user interfaces.
A supplementary requirements specification for the requirements that are generic and not specific for a particular use case.

42. Analysis Brief Comparison of the Use-Case Model and Analysis Model
The purpose of analysis is to achieve a more precise understanding of the requirements and to achieve a description of the requirements by refining and structuring them.
Brief Comparison of the Use-Case Model and Analysis Model
Use Case Model
Described using the language of the customer
External view of the system
Structured by use cases: gives structure to the external view
Used primarily as a contract on what the system should and should not do
May contain redundancies inconsistencies, etc. among requirements
Captures the functionality of the system, including architecturally significant functionality.
Defines use cases that are further analyzed in the analysis model
Analysis Model
Described using the language of the developer
Internal view of the system
Structured by stereotypical classes and packages; gives structure to the internal view
Used primarily by developers to understand how the system should be shaped, i.e., designed and implemented
Should not contain redundancies, inconsistencies, ect., among requirements
Outlines how to realize the functionality with the system, including architecturally significant functionality; works as a first cut at design.
Defines use-case realizations, each one representing the analysis of a use case from the use-case model

43. Design and implementation are so much more than analysis (refining and structuring the requirements), so a separation of concern is needed.
The purpose of analysis
1. An analysis model yields a more precise specification of the requirements than we have in the results from requirements capture, including the use-case model.
2. An analysis model is described using the language of the developers, and can thereby more formalism and be used to reason about the internal workings of the system.
3. An analysis model structures the requirements in a way that facilitates understanding them, preparing them, changing them, and, in general, maintaining them.
4. An analysis model can be viewed as a first cut at a design model (although it is a model of its own), and is thus an essential input when the system is shaped in design and implementation.

44. Realization-Analysis
Figure 8.3: The analysis model is a hierarchy of analysis packages containing * 1 *
Analysis System
Analysis Package
Analysis Model * * * *
Use-case
Realization-Analysis
Analysis Class

45. Analysis Class -- represents an abstraction of one or several classes and /or subsystems in the systems’ design. Analysis classes always fit one of three basic stereotypes: boundary, control, and entity classes.
Boundary Class
responsibilities
attributes
relationships
special requirements
Control Class
Analysis class
Entity Class
Boundary Classes
A boundary class is used to model interaction between the system and its actors ( users and external systems). Boundary classes often represent abstractions of windows, forms, panes, communication interfaces, printer interfaces, sensors, and terminals.

46. Entity Classes
An entity class is used to model information that is long-lived and often persistent. Entity classes often show a logical data structure and contribute to the understanding of what information that the system is dependent upon.
Control Classes
Control classes represent coordination, sequencing, transaction, and control objects and are often used to encapsulate control related to a specific use case.
The dynamics of the system are modeled by control classes, since they handle and coordinate the main actions and control flows, and delegate work to other objects (boundary and entity objects).
Use Case Realization--Analysis (Class and Interaction Diagrams)

47. A class diagram for a realization of the Pay Invoice use cases
Order Handler
Payment Scheduler
Order Confirmation
Invoice
Payment Request UI
Buyer
Payment Request
A class diagram for a realization of the Pay Invoice use cases

48. 6: Schedule invoice for payment 9: setStatus (scheduled)
:Order Handler
:Payment Scheduler
:Order Confirmation
:Invoice
:Payment Request UI
5: Get
4: Get
3: Check Invoice
2: Browse
1: Browse Invoices
6: Schedule invoice for payment
9: setStatus (scheduled)
7: Schedule payment
:Buyer
8: New
:Payment Request
A collaboration diagram for a realization of the Pay Invoice use cases

49. Architectural Analysis
Analysis Package
Analysis packages provides a means of organizing the artifacts of the analysis model in manageable piece. An analysis package can consist of analysis classes, use-case realizations, and other analysis packages (recursively).
Analysis packages should be cohesive (i.e., their contents should be strongly related), and they should be loosely coupled (i.e., their dependencies on each other should be minimized).
Service Packages
Workers (Architect, Use-Case Engineer, Component Engineer)
Workflow (Architectural Analysis)
Architectural Analysis
by architect
Analyze a Use Case
by Use-Case Engineer
Analyze a Class
by Component Engineer
Analyze a Package
by Component Engineer

50. The Input and result of architectural analysis
Finding analysis package from use cases
The Input and result of architectural analysis
Pay Invoice
Invoice Buyer
Send Reminder
Use-Case Model
Architect
Analysis Package
[outlined]
<<trace>>
<<trace>>
<<trace>>
Supplementary
Requirement
Buyer’s Invoice
Management
Seller’s Invoice
Management
Analysis Class
[outlined]
Architectural
Analysis
Business Model
[or domain model]
Account
Bank Customer
Architecture
Description
[view of the analysis model]
<<trace>>
<<trace>>
Architecture
Description
[view of use-case model]
Bank Customer Management
Account Management
Finding general analysis packages from domain classes

51. Summary of Analysis
Analysis packages and service packages, and their dependencies and contents.
Analysis classes, their responsibilities, attributes, relationships, and special requirements.
Use-case realizations -- analysis, which describes how use cases are refined in terms of collaborations within the analysis model and their special requirements.
The architectural view of the analysis model, including its architecturally significant elements.

52. Chapter 9 Design
the purposes of design:
Acquire an in-depth understanding of issues regarding nonfunctional requirements and constraints related to programming languages, component reuse, operating systems, distribution and concurrency technologies,database technologies, use-interface technologies, transaction management technologies, and so on.
Create an appropriate input to and point of departure for subsequent implementation activities by capturing requirements on individual subsystems, interfaces, and classes.
Be able to decompose implementation work into more manageable pieces handled by different development teams, possible concurrently. This is useful in cases where such decomposition cannot be done based on the results from requirements capture.
Capture major interfaces between subsystems early in the software life cycle. This is helpful when we reason about architecture and when we use interfaces as synchronization instruments between different development teams.
Be able to visualize and reason about the design by using a common notation.
Create a seamless abstraction of the systems’ implementation, in the sense that the implementation is a straightforward refinement of the design by filling in the “meat” but not changing the structure.

53. Brief Comparison of the Analysis Model and the Design Model
Conceptual model, because it is an abstraction of system and avoids implementation issues
Design-generic (applicable to several designs)
Three conceptual stereotypes on classes:<<control>., <<entity>>, and <<boundary>>
Less formal
Less expensive to develop (1:5 ratio to design)
Few layers
Dynamic (but not much focus on sequence)
Outlines the design of the system, including its architecture
Primarily created by “leg work: , in workshops and the like
May not be maintained throughout the complete software life cycle
Defines a structure that is an essential input to shaping the system--including creating the design model
Design Model
Physical model, because it is a blueprint of implementation
Not generic, but specific for an implementation
Any number of (physical) stereotypes on classes, depending on implementation language
More formal
More expensive to develop (5:1 ratio to analysis)
Many layers
Dynamic (much focus on sequence)
Manifests the design the system, including its architecture (one of its views).
Primarily created by “visual programming: in round-trip engineering environments; the design model is “round-trip engineered” with the implementation model
Should be maintained throughout the complete software life cycle
Shapes the system while trying to preserve the structure defined by the analysis model as much as possible.

54. Design Model -- Use-Case Realization Design
Since the design model is very close to implementation, it is natural to keep and maintain the design model through the complete software life cycle.
Design Model -- Use-Case Realization Design
class design, class diagrams, interaction diagrams, state diagrams, activity diagrams, component diagrams and deployment diagrams.
Design Subsystem (service subsystems) And Interface
Architecture Description (View of the Design Model)
Works (Architect, Use-Case Engineer, and Component Engineer) and Workflow
Architectural Design
(1) Identifying Nodes and Network Configurations
(2) Identifying Subsystems and Their Interfaces
Identifying Application Subsystems
Identifying Middleware and System-Software Subsystems

55. Summary of Design
Design model is the blueprint of the implementation , which including the following elements:
design subsystem and service subsystems and their dependencies, interface, and contents.
Design classes from analysis classes
Use-case realizations -- design, describe how use cases are designed in terms of collaborations within the design model.
Architectural view of design model.
Design model and deployment model are considered as the primary input to subsequent implementation and test activities.

56. Implementation
In implementation, we start with the result from design and implement the system in terms of components, that is, source code, scripts, binaries, executables, and the like.
Implementation subsystems and their dependencies, interfaces, and contents.
Components, including file and executable components, and their dependencies on each other. The components are unit tested.
The architectural view of the implementation model, including its architecturally significant elements.
Implementation also results in a refinement of the architectural view of the deployment model, when executable components are mapped onto nodes.

57. Test The purposes of testing are to
Plan the tests required in each iteration, including integration tests and system tests.
Design and implement the tests by creating test cases that specify what to test, creating test procedures that specify how to perform the tests, and creating executable test components to automate the tests if possible.
Perform the various tests and systematically handle the results of each test. Builds found to have defects are retested and possibly sent back to other core workflows, such as design and implementation, so that the significant defects can be fixed.
Test Model is a collection of test cases, test procedures, and test components.