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.

Software Development Process

User’sRequirements

SoftwareSystem

    

 

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.

Initial risks Initial project scope

Revise Project plan

Define iterative to addressthe highest risks

Revise risk assessment

Risks eliminated

Assess the iteration

Plan and develop the iteration

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 DimensionsTime 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 DimensionsTime 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

 

Process Components

Supporting Components

 

Requirement CaptureAnalysis and DesignImplementationTest 

ManagementEnvironmentDeployment

Phases

Inception Elaboration Construction Transition

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

Models of the Unified Process

Use–Case Model Analysis Model

Design Model

Deployment Model

Implementation Model

XOK

XOK

Test Model

Specified by

Realized by

Distributed byImplemented byVerified by

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.

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

Transfer between Accounts

BankCustomer

        

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

Dispenser Cashierinterface

Withdraw Account

participant

<<boundary>> <<control>> <<entity>>

          

A Class Participating in Several Use-Case

Realizations in the Analysis Model

Transfer between Accounts

Deposit Money

Withdraw Money

BankCustomer

BankCustomer

Analysis ModelUse-Case Model

Money Receptor Deposit

CashierInterface

Transfer

Withdraw 

Dispenser

Account

             

 

Using a Collaboration Diagram to Describe a Use-Case Realization

:BankCustomer

:Dispenser

:CashierInterface

:Withdraw :Account

2: request withdrawal1: identify

3: validate and withdraw

4: authorize dispense5: dispense money

A Collaboration Diagram for the Withdraw Money use-case realization in the analysis model

            

 

Use-Case Realizations in Analysis and Design Models

Withdraw Money

Use-Case Model

Withdraw Money

Analysis Model Design Model

Withdraw Money

Use-Case Realizations in Analysis and Design Models

Analysis Model

Cashier Interface Dispenser Withdraw Account

Display

Design Model

Key Pad

Card Reader

DispenserSensor

DispenserFeeder

CashCounter

ClientManager

Withdraw Account

PersistentClass

AccountManager

TransactionManager

Design Classes in the Design Model tracing to Analysis classes

 

Use-Case-Driven Process

A class diagram realization of Withdraw Money use case

Card Reader

Display

Key Pad

DispenserSensor

DispenserFeeder

ClientManager

CashCounter

AccountManager

TransactionManager

persistentclass

Withdrawal

Account

A sequence diagram of Withdraw Money

Three subsystem and a service subsystem

<<subsystem>>AccountManagement

Card Reader

Display

Key Pad

DispenserSensor

DispenserFeeder

ClientManager

CashCounter

AccountManager

TransactionManager

persistentclass

WithdrawalAccount

<<subsystem>>

ATM Interface

<<service

subsystem>>withdrawal Management

<<subsystem>>TransactionManagement

Dispensing

Withdrawal

Transfers

Bank

Customer

Components implementing design classes

DispenserSensor

DispenserFeeder

ClientManager

CashCounter

Design Model Implementation Model

<<trace>>

<<compilation>>

<<trace>>

<<executable>>

client.exe

<<file>>

client.c

<<file>>

dispenser.c

Identifying a Test Case from a Use Case

Use-Case Model Test Model

Withdraw Money Withdraw Money-Basic Flow

<<trace>>

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

<<subsystem>>

ATM Interface

<<subsystem>>

TransactionManagement

<<subsystem>>

AccountManagement

BankCustomer

HistoryDepositsTransferal

Withdrawal

Dispensing

Transfers

• Architecture View of the Deployment Model of the ATM System

ATM Client ATM App.Server

ATM Data

Severinternet internet

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 SellerPaymentHandler

Account Invoice

Buyer

Seller

Capturing the Requirements as Use Cases

• Use Case Model (actors + use cases with constraints)• Use-cases (functional requirements)• Supplementary requirements (non-functional)

User-Interface

Designer

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

Workflow for Capturing Requirements as Use Cases

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.

AnalysisThe 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 ModelUse 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

• 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.

Analysis Model Analysis PackageAnalysis System

Analysis Class Use-case Realization-Analysis

Figure 8.3: The analysis model is a hierarchy of analysis packages containing

*1

*** *

*

• 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.

Analysis class

responsibilities

attributes

relationships

special requirements

Boundary Class

Control 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.

• 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)

Payment Request

Buyer

Order Handler

Payment Scheduler

Order Confirmation

Invoice

Payment Request UI

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

:Payment Request

:Buyer

:Order Handler

:Payment Scheduler

:Order Confirmation

:Invoice

:Payment Request UI

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

1: Browse Invoices

6: Schedule invoice for payment

2: Browse

4: Get

9: setStatus (scheduled)

7: Schedule payment

5: Get

8: New

3: Check Invoice

• 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 Package

by Component Engineer

Analyze a Class

by Component Engineer

Analysis Package[outlined]

Business Model[or domain model]

SupplementaryRequirement

Use-Case Model

ArchitectureDescription

[view of the analysis model]

ArchitecturalAnalysis

ArchitectureDescription

[view of use-case model]

The Input and result of architectural analysis

Pay Invoice

Buyer’s Invoice

Management

Invoice Buyer

Seller’s Invoice

Management

Send Reminder

Finding analysis package from use cases

Account Management

Bank CustomerAccount

Bank Customer Management

Finding general analysis packages from domain classes

Architect

Analysis Class

[outlined]

<<trace>> <<trace>> <<trace>>

<<trace>><<trace>>

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• 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.

the purposes of design:

Brief Comparison of the Analysis Model and the Design Model Analysis ModelConceptual 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 ModelPhysical 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.

• 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.

ImplementationIn 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.