Transcript Define use cases:

‫תהליך הפיתוח האחוד‬
(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!
Topics Discussed in this Session
 The UP: An Overview
 What are the stages of the Unified Process (UP)
 Which artifacts are created in each stage
 Inception
 Use Case Modeling
 Identifying Requirements
 Elaboration
 System Sequence Diagram
 Domain Model
 Contracts
 Design Class Diagram
The Unified Process:
An Overview
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.
5
•
•
•
•
•
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 Model
 The 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 Diagrams
 Usually 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 Diagrams
 Illustrates 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
Inception
 Inception 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 to
Oil 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.
 Packaging
 Legal—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 Types
Use 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.
Brief Format Use Case:
an Example
Process 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.
20
Guideline: The EBP Use Case
 For 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 Requirements
 Write a Supplementary Specification, Glossary, and
Vision.
 Compare and contrast system features with use cases.
Relate the
 Vision to other artifacts, and to iterative development.
Define quality attributes.
Elaboration
From Inception to Elaboration
Elaboration 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 highrisk 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 particular
scenario of a use case, the events that external actors
generate, their order, and
inter-system events. All systems are treated as a black box;
the emphasis of the
diagram 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.
System Sequence Diagrams (example)
30
Domain Model:
Visualizing Concepts
Objectives:
 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
Contracts – An Example
Contract CO2: enterItem
Operation: enterItem(itemID:ItemID,quantity:integer)
Cross References: Use Cases: Process Sale
Preconditions:
There is a sale underway
Postconditions:
• 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).
34
GRASP: Designing Objects
with 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
39
by iteration.
Now Go and Build Your Software!