Unified Software Development Process 1. The Unified Process: Use-Case Driven, Architecture-Centric,...
-
Upload
miranda-hardy -
Category
Documents
-
view
290 -
download
3
Transcript of Unified Software Development Process 1. The Unified Process: Use-Case Driven, Architecture-Centric,...
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.