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
 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.
 Software Development Process
 A Software development process is the set
of activities needed to transform a user’s
requirements into a software system.
 
 
 
 
User’s Software Development Software
Requirements
Process System
 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
 Unified Process is Use-Case Driven
1. User (Actors & Stakeholders) represents someone
or something that interacts with the system being
developed.
2. An interaction is a use case (action), a piece of
functionality in the system. (use-case view)
3. 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.
Unified Process is Architecture-Centric

• Software architecture captures the most

significant static and dynamic aspects of the
system. (subsystem)
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.

Define iterative to address

the highest risks
Plan and develop the iteration
Initial risks
Initial project scope
Assess the iteration

Risks eliminated
Revise Project plan
Revise risk assessment
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.
 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).
 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.
 The Five workflows
 
Phases
Process Components Inception Elaboration Construction Transition

Requirement Capture
Analysis and Design
Implementation
Test  
 
Supporting Components

Management
Environment
Deployment

The Five workflows-Req. Ana. Des. Imp. Test

Models of the Unified Process
Specified by

Use–Case Model
Analysis Model

Realized by

Design Model
Implemented by Distributed by
Verified by

X
OK
Deployment Model
X
OK
Implementation Model
Test Model
 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.
  Analysismodel is different from the design
model in that it is a conceptual model rather
than a blueprint of the implementation.
 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.)
 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.
 A use-case model of ATM system

  Withdraw Money
 
 
 
 
  Deposit Money
 
 

Bank Transfer between

Customer Accounts
 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.
 Realization of a Use Case in
Analysis Model
 
 
  Use-Case Model Analysis Model
 
 
  Withdraw Money Withdraw Money
  participant
 
 
 

Dispenser Cashier Withdraw Account

interface
<<boundary>> <<control>> <<entity>>
 A Class Participating in Several Use-Case
 
Realizations in the Analysis Model
 
 
  Use-Case Model Analysis Model
 
 
 
  Withdraw Money Dispenser Withdraw
 
 
 
 
  Deposit Money Cashier Transfer
Bank Bank Interface Account
 
Customer Customer

Transfer between
Money Receptor Deposit
Accounts
 Using a Collaboration Diagram to Describe
 
a Use-Case Realization
 
 
 
  1: identify 2: request withdrawal
 
  :Cashier 3: validate and withdraw
  Interface
 
 
:Bank :Withdraw :Account
  Customer
  4: authorize dispense
5: dispense money :Dispenser

A Collaboration Diagram for the Withdraw Money use-

case realization in the analysis model
 Use-Case Realizations in Analysis
and Design Models
Use-Case Model Analysis Model Design Model

Withdraw Money Withdraw Money Withdraw Money

 Use-Case Realizations in Analysis
 
and Design Models
Analysis
Model
Cashier Interface Dispenser Withdraw Account

Design
Model
Dispenser Withdraw Account
Display
Sensor

Dispenser Client Persistent

Key Pad
Feeder Manager Class

Cash Transaction Account

Card Reader
Counter Manager Manager

Design Classes in the Design Model tracing to Analysis classes

 Use-Case-Driven Process

Card Reader

Display Transaction
Client Manager
Manager
persistent
Key Pad class

Withdrawal
Dispenser
Feeder
Cash
Counter Account
Dispenser Account
Sensor Manager

A class diagram realization of Withdraw Money use case

A sequence diagram of Withdraw Money
 <<subsystem>> <<subsystem>> <<subsystem>>
Transaction Account
ATM Interface
Management Management

Card Reader Withdrawal

Transaction
Display Manager

Key Pad Client persistent

<<service class
Bank Manager
subsystem>>
Customer Dispenser Dispensing withdrawal Account
Feeder Manager
Cash Management Transfers
Counter
Dispenser Account
Sensor
Withdrawal

Three subsystem and a service subsystem

Design Model Implementation Model

Client
Manager <<trace>> <<executable>>
client.exe
Dispenser <<compilation>>
Feeder
<<file>>
client.c
Dispenser <<trace>>
Sensor
<<file>>
Cash dispenser.c
Counter

Components implementing design classes

 Identifying a Test Case from a Use Case
Use-Case Model Test Model

<<trace>>

Withdraw Money Withdraw Money-Basic Flow

Input:
•The Bank customer’s account 12-121-1211 has a balance of $350.
•The Bank Customer identifies himself correctly.
•The Customer request to withdraw $200 from the account 12-121-1211.
•There is enough money (at lest $200) in the ATM.
Result:
•The balance of the Customer’s account 12-121-1211 decreases to $150.
•The Bank Customer receives $200 from the ATM.
Conditions: No other use cases (instances) are allowed to access the
account 12-121-1211 during this test case.
 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.
 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.
 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
The Layered Architecture Organizes Systems in
Layer of Subsystem

Application-specific layer

Application-general layer

Middleware layer

System-software layer
 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

Withdrawal
<<subsystem>> <<subsystem>> <<subsystem>>
ATM Transaction Account
Interface Management Transfers Management
Dispensing

Transferal Deposits History

• Architecture View of the Deployment Model of the ATM System

ATM Client ATM App. ATM Data

internet Server internet
Bank Sever
Customer
 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.
 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.
 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.
 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
• Develop in Small Steps (min-waterfall)--The third key for
developing a software product in small manageable steps.
1. You plan a little.
2. You specify, design, and implement a little.
3. 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.
2. To set forth an architecture to guide software development.
3. To provide a framework that better handles inevitable
requirements and other changes.
4. To build up the system over time incrementally
rather than all at once near the end when change becomes expensive.
5. To provide a development process
through which the staff can work more effectively.
 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.
2. Understand system context.
3. Capture functional requirements.
4. Capture nonfunctional requirements.
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.

Buyer Seller
Buyer Payment
Handler
Seller

Account Invoice
 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
Find Actors and Structure the
System Analyst Use Cases Use Case Model

Prioritize
Architect
Use Cases

Use-Case Detail a Use Case

Specifier

User-Interface
Prototype
Designer
User-Interface
 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.
 Analysis
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 Analysis Model
Described using the language of the customer Described using the language of the developer
External view of the system Internal view of the system
Structured by use cases: gives structure to the external Structured by stereotypical classes and packages;
view gives structure to the internal view
Used primarily as a contract on what the system Used primarily by developers to understand how the
should and should not do system should be shaped, i.e., designed and
implemented
May contain redundancies inconsistencies, etc. among Should not contain redundancies, inconsistencies,
requirements ect., among requirements
Captures the functionality of the system, including Outlines how to realize the functionality with the
architecturally significant functionality. system, including architecturally significant
functionality; works as a first cut at design.
Defines use cases that are further analyzed in the Defines use-case realizations, each one representing
analysis model the analysis of a use case from the use-case model
• 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.
Figure 8.3: The analysis model is a hierarchy of analysis packages containing

*
1
*

Analysis Model Analysis System Analysis Package

* * * *

Analysis Class Use-case

Realization-Analysis
• 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
Control Class

Analysis class special

requirements
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.
• 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)
 Order Confirmation

Order Handler

Invoice

Payment Request UI
Buyer

Payment Scheduler Payment Request

A class diagram for a realization of the Pay Invoice use cases

 5: Get

:Order
Confirmation

4: Get
:Order Handler

3: Check Invoice
2: Browse
1: Browse Invoices
:Invoice
6: Schedule invoice for payment
9: setStatus (scheduled)

7: Schedule payment
:Payment Request UI
:Buyer 8: New

:Payment Scheduler :Payment Request

A collaboration diagram for a realization of the Pay Invoice use cases

• 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 Analyze a Use Case Analyze a Class Analyze a Package

by architect by Use-Case Engineer by Component Engineer by Component Engineer
 Finding analysis package
The Input and result of architectural analysis from use cases

Pay Invoice Invoice Buyer Send Reminder

Use-Case Model Architect

Analysis Package <<trace>> <<trace>> <<trace>>

[outlined]

Supplementary
Requirement Buyer’s Invoice Seller’s Invoice
Analysis Class Management Management
Architectural [outlined]
Analysis
Business Model
[or domain model]

Account Bank Customer

Architecture <<trace>>
Description <<trace>>

Architecture [view of the analysis model]

Description Account Bank Customer
[view of use-case model] Management Management

Finding general analysis

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