מערכות ועיצוב ניתוחתוכנה

2012אביב האחוד הפיתוח תהליך

(The Unified Process)

1

Motivation: Analysis and Design Should Be Done Iteratively!

Presented 1981, this is one of the most famous graphs in Software Engineering.

The cost of removing a software defect grows exponentially for each downstream phase of the development lifecycle in which it remains undiscovered.

…And if you work in waterfall, you always get more distant from the early levels!

The UP: An OverviewWhat are the stages of the Unified Process

(UP)Which artifacts are created in each stage

InceptionUse Case ModelingIdentifying Requirements

ElaborationSystem Sequence DiagramDomain ModelContractsDesign Class Diagram

Topics Discussed in this Session

The Unified Process:An Overview

5

RUP Phases and Iterations

• At the end of each phase we reach a project milestone!• Inception: Is the project feasible?• Elaboration: Is the architecture stable? Are all the primary risks mitigated?• Construction: Is the system ready for installation at the customer’s

environment?• Common misconception: each phase matches a waterfall phase.

Write Use Cases• Stories or scenarios of how people use the

application.• Brief: a paragraph of textual explanation.• Fully Dressed: like we’ve seen in the

previous Practical Session.• Use Case Diagrams: can visualize the use

cases and their connections.• They are secondary in use case work: to

create use cases is to write text.

Create A Domain ModelThe noteworthy domain concepts or objects.Visualization of the concepts or mental

models of a real-world domain.Also called: a conceptual object model.

Assign Object Responsibilities and Draw Interaction DiagramsUsually sequence diagram.Software object designs and programs do

take inspiration from real-world domains…But they are not direct models or simulations

of the real world.(Who rolls a dice? Player or Dice object?)Designated Patterns exist and should be used

(GRASP – more on this later).

Define Class DiagramsIllustrates the attributes and methods of the

classes.Includes visibility and all operations.In contrast to the domain model showing real-

world classes, this diagram shows software classes.

Mind The (Representational) Gap.

Sample Unified Process Artifacts and Timing

s

How Does It All Connect?Partial

Artifacts refined at

each Iteration

You don’t understand UP when…You think that inception = requirements, elaboration = design,

and construction = implementation (that is, superimposing a waterfall lifecycle on to the UP).

You try to define most of the requirements before starting design or implementation.

You try to define most of the design before starting implementation; you try to fully define and commit to an architecture before iterative programming and testing.

A "long time" is spent doing requirements or design work before programming starts.

You think UML diagramming and design activities are a time to fully and accurately define designs and models in great detail, and of programming as a simple mechanical translation of these into code.

You try to plan a project in detail from start to finish; you try to speculatively predict all the iterations, and what should happen in each one.

You want believable plans and estimates for projects before the elaboration phase is finished.

Inception

InceptionInception in one sentence:

Envision the product scope, vision,

and business case.The main problem to solve in one sentence:

Do the stakeholders have basic agreement on the vision of the project, and is it worth investing in

serious investigation?

Inception: An Analogy toOil Business

In the oil business, when a new field is being considered, some of the steps include:1. Decide if there is enough evidence or a business case to even justify exploratory drilling.2. If so, do measurements and exploratory drilling.3. Provide scope and estimate information.4. Further steps...

The inception phase is like step one in this analogy. In step one people do not predict how much oil there is, or the cost or effort to extract it. It is premature— there is insufficient information. Although it would be nice to be able to answer "how much" and "when" questions without the cost and effort of the exploration, in the oil business it is understood to not be realistic.

In UP terms, the realistic exploration step is the elaboration phase. The preceding inception phase is akin to a feasibility study to decide if it is even worth investing in exploratory drilling. Only after exploration (elaboration) do we have the data and insight to make somewhat believable estimates and plans. Therefore, in iterative development and the UP, plans and estimates are not to be considered reliable in the inception phase. They merely provide an order-of-magnitude sense of the level of effort, to aid the decision to continue or not.

You Know You Didn't Understand Inception When... It is more than "a few" weeks long for most projects.There is an attempt to define most of the requirements.Estimates or plans are expected to be reliable.You define the architecture; rather, this should be done iteratively in

elaboration.You believe that the proper sequence of work should be:

1) define the requirements; 2) design the architecture; 3) implement.The names of most of the use cases and actors were not identified.All the use cases were written in detail.None of the use cases were written in detail.

Best Practice: 10-20% should be written in detail to obtain some realistic insight into the scope of the problem.

Understanding Requirements:Types of Requirements (FURPS+)

In the UP, requirements are categorized according to the FURPS+ model [Grady92], a useful mnemonic with the following meaning:Functional—features, capabilities, security.Usability—human factors, help, documentation.Reliability—frequency of failure, recoverability, predictability.Performance—response times, throughput, accuracy, availability,

resource usage.Supportability—adaptability, maintainability, internationalization,

configurability.

The "+" in FURPS+ indicates ancillary and sub-factors, such as:Implementation—resource limitations, languages and tools,

hardware, ...Interface—constraints imposed by interfacing with external systems.Operations—system management in its operational setting.PackagingLegal—licensing and so forth.

Use Case Model:Writing Requirements in Context

Objectives:Identify and write use cases.Relate use cases to user goals and elementary

business processes.Use the brief, casual, and fully dressed

formats, in an essential style.Relate use case work to iterative development.

Formality TypesUse cases are written in different formats, depending on need. Use cases are written in varying degrees of formality:

brief—terse one-paragraph summary, usually of the main success scenario.

casual—informal paragraph format. Multiple paragraphs that cover various scenarios.

fully dressed—the most elaborate. All steps and variations are written in detail, and there are supporting sections, such as preconditions and success guarantees.

20

Brief Format Use Case:an ExampleProcess Sale: A customer arrives at a checkout with items to purchase. The cashier uses the POS system to record each purchased item. The system presents a running total and line-item details. The customer enters payment information, which the system validates and records. The system updates inventory. The customer receives a receipt from the system and then leaves with the items.

Guideline: The EBP Use CaseFor requirements analysis for a computer

application, focus on use cases at the level of elementary business processes (EBPs).

EBP is a term from the business process engineering field, defined as:“A task performed by one person in one place at one time, in response to a business event, which adds measurable business value and leaves the

data in a consistent state. e.g., Approve Credit or Price Order.”

Finding Primary Actors, Goals,and Use Cases

Use cases are defined to satisfy the user goals of the primary actors. Hence, the basic procedure is:

1. Choose the system boundary. Is it just a software application, the hardware and application as a unit, that plus a person using it, or an entire organization?2. Identify the primary actors: those that have user goals fulfilled through using services of the system.3. For each, identify their user goals. Raise them to the highest user goal level that satisfies the EBP guideline.4. Define use cases that satisfy user goals; name them according to their goal

Use Cases and Requirements Specification Across Iterations

Identifying Other RequirementsWrite a Supplementary Specification,

Glossary, and Vision.Compare and contrast system features with

use cases. Relate theVision to other artifacts, and to iterative

development. Define quality attributes.

Elaboration

From Inception to ElaborationElaboration is the initial series of iterations during which:The majority of requirements are discovered

and stabilized.The major risks are mitigated or retired.The core architectural elements are

implemented and proven.

Elaboration in one sentence:Build the core architecture, resolve the

high-risk elements, define most requirements, and estimate the overall

schedule and resources.

Some key ideas and best practices that will manifest in elaboration include: Do short, timeboxed risk-driven iterations Start programming early Adaptively design, implement, and test the core and risky parts of the Architecture Test early, often, realistically Adapt based on feedback from tests, users, developers. Write most of the use cases and other requirements in detail, through a series of workshops, once per elaboration iteration.

You Know You Didn't Understand Elaboration When...

It is more than "a few" months long for most projects. It only has one iteration (with rare exceptions for well-understood

problems). Most requirements were defined before elaboration. The risky elements and core architecture are not being tackled. It does not result in an executable architecture; there is no production-

code programming. It is considered primarily a requirements phase, preceding an

implementation phase in construction. There is an attempt to do a full and careful design before

programming. There is minimal feedback and adaptation; users are not continually

engaged in evaluation and feedback. There is no early and realistic testing. The architecture is speculatively finalized before programming. It is considered a step to do the proof-of-concept programming, rather

than programming the production core executable architecture. There are not multiple short requirements workshops that adapt and

refine the requirements based on feedback from the prior and current iterations. If a project exhibits these symptoms, the elaboration phase was not understood.

Use Case System Sequence Diagram

Identify system events.Create system sequence diagrams for use cases.A system sequence diagram (SSD) is a picture that

shows, for a particularscenario of a use case, the events that external actors

generate, their order, andinter-system events. All systems are treated as a black

box; the emphasis of thediagram is events that cross the system boundary from

actors to systems.An SSD should be done for the main success scenario of

the use case, and frequent or complex alternative scenarios.

30

System Sequence Diagrams (example)

Domain Model:Visualizing ConceptsObjectives:Identify conceptual classes related to the

current iteration requirements.Create an initial domain model.Distinguish between correct and incorrect

attributes.Add specification conceptual classes, when

appropriate.Compare and contrast conceptual and

implementation views.

Domain Model (cont.) Using UML notation, a domain model is illustrated with a set of class

diagrams in which no operations are defined. It may show: • domain objects or conceptual classes • associations between conceptual classes • attributes of conceptual classes Some software systems are for domains that find very little analogy in

natural or business domains; software for telecommunications is an example. It

is still possible to create a domain model in these domains, but it requires a

high degree of abstraction and stepping back from familiar designs. For example, here are some candidate conceptual classes related to a

telecommunication switch: Message, Connection, Port, Dialog, Route, Protocol.

System Sequence Diagrams Contracts

34

Contracts – An ExampleContract CO2: enterItemOperation:enterItem(itemID:ItemID,quantity:integer)Cross References: Use Cases: Process SalePreconditions: There is a sale underwayPostconditions:• A SalesLineItem instance sli was created (instance

creation).• sli was associated with the current Sale (association

formed).• sli.quantity became quantity (attribute modification).• sli was associated with a ProductSpecification, based

on itemID match (association formed).

GRASP: Designing Objectswith Responsibilities

The following sections present the first five GRASP patterns:Information Expert - Assign a responsibility to the

information expert: the class that has the information necessary to fulfill the responsibility.

Creator - Assign class B the responsibility to create an instance of class A.

High Cohesion - Assign a responsibility so that cohesion remains high.

Low Coupling - Assign a responsibility so that coupling remains low.

Controller - Assign the responsibility for receiving or handling a system event message to a class.

Design Model:Creating Design Class Diagrams

Create design class diagrams (DCDs).Determine Visibility Identify the classes, methods, and associations to show in a

DCD.A (short) Example from Larman – The Dice Game.

Design Model:Creating Design Class Diagrams

Summary In the next iteration we start by updating our UP

artifacts (use case model, domain model) according to the last iteration insights.

Choose a different use case (or more than one) to express in a fully dressed mode.

Continue to realize it via the discussed techniques from above according to the last iteration insights.

We continue to do this until the product is finished.

38

Benefits of Iterative Development (vs. waterfall)• Early rather than late mitigation of high risks.

technical, requirements, objectives, usability, and so forth.

• Early visible progress.• Programmers program early, testers test early

etc’.• Early feedback, user engagement, and

adaptation, leading to a refined system that more closely meets the real needs of the stakeholders.

• Managed complexity;The team is not overwhelmed by "analysis

paralysis" or very long and complex steps• The learning within an iteration can be

methodically used to improve the development process itself, iteration by iteration.

39

Now Go and Build Your Software!