Object-Oriented Analysis

& Design
面向对象的分析与设计
Part 2: Inception

• Chapter 4. Inception is Not the Requirements Phase

• Chapter 5. Evolutionary Requirements
• Chapter 6. Use Cases
• Chapter 7. Other Requirements

2
Chapter 6 Use Cases

• Objectives:

• Identify and write use cases.

• Use the brief, casual, and fully dressed formats, in an essential
style.
• Apply tests to identify suitable use cases.
• Relate use case analysis to iterative development.

3
 Sample UP Artifact Relationships

Domain Model

Sale Sales
Business 1 1 .. * ...
LineItem
Modeling date ...
quantity
...

objects , attributes ,
associations
scope , goals , Vision
Use - Case Model
actors , features

Process Sale
Process
use
Sale 1 . Customer
case
Cashier
arrives ... 2 .
names
Cashier
makes new
sale .
terms , attributes ,
3 . ... Glossary
validation
Requirements
Use Case Diagram Use Case Text

system
events

: System

Operation : : Cashier
make Supplementary
enterItem (… )
system NewSale () Specification
operations
Post - conditions :
enterItem
- . .. non - functional reqs ,
( id , quantity )
quality attributes
Operation Contracts System Sequence Diagrams

requirements

Design Model
: Register : ProductCatalog : Sale

enterItem
Design (itemID , quantity )

spec = getProductSpec ( itemID )

addLineItem ( spec , quantity )

 Motivation: Why Use Cases

• Use case are text stories, they are simple and familiar.
• Makes it easier for customers to contribute to requirement definition and
review, that lowers the risk of missing the mark.
• More user centric (compared with traditional feature list)
– Who is using the system?
– What are their goals?
– What are their typical scenarios of use?
• Use case is a good way for domain experts or requirement donors to
write use cases by themselves, is the central to discover and define the
functional requirements.
• Able to scale both up and down in terms of sophistication and formality.

5
Use-Case Model

• Use cases are requirements, primarily functional or behavioral

requirements that indicate what the system will do.
• Use-Case Model is the set of all written use cases; is defined
within UP Requirements Discipline.
• Use-Case Model may optionally include a UML use case
diagram to show the names of use cases, actors, their
relationships and use case text.
• There is nothing objected-oriented about use cases; we're not
doing OO analysis when writing use cases.
• Use cases are a key requirements input to classic OOA/D.

6
Applying UML: Use Case Diagrams
system NextGen POS communication
boundary

Process Sale

Customer Payment alternate notation for a

Authorization computer system actor
Service

Use Case
Handle Returns «actor »
Tax
actor Cashier Calculator

«actor »
Diagram
Cash In Accounting
System
Manager
«actor »
«a ctor » Analyze Activity
HR System
Sales Activity
System

Manage Security use case text

System
Administrator Manage
ManageUser
Users
use case
. .Role
Manage .

7
Notation Guidelines

For a use case context Show computer system

diagram, limit the use cases actors with an alternate
to user-goal level use cases. notation to human actors.

NextGen

Process Sale <<actor>>

Payment
Authorization
Cashier Service
...

supporting actors
on the right
primary actors
on the left
13
8
Some Use Cases Examples

9
Some Use Cases Examples

10
Some Use Cases Examples

11
Some Use Cases Examples

12
Some Use Cases Examples

13
What are Actors, Scenarios, and Use Cases

• Actor
– something with a behavior; such as a person, computer system,
machines or organization, System under Discussion (SuD)
itself when it calls upon the services of other systems.
• Scenario——Use Case Instance
– A specific sequence of actions and interactions between actor
(s) and the system (one story; success or failure)

• Use Case
– A collection of related success and failure scenarios
describing the actors attempts to support a goal

14
Three Kinds of Actors

• Three kinds of actors in the SuD:

• Primary actor: fulfill the user goals by using services of SuD, for
example cashier.——To find user goals.
• Supporting actor: provide a service to the SuD, often a computer
system, but could be an organization or person, for example the
automated payment authorization service.——To clarify external
interfaces and protocols.
• Offstage actor: has an interest in the behavior of the use case, but is
not primary or supporting, for example a government tax agency.—— To
ensure that all necessary interests are identified and satisfied.

15
 Three Kinds of Actors
system NextGen POS communication
boundary

Process Sale

Customer Payment
Authorization
Service
Handle Returns «actor »
Tax
Cashier Calculator
Supporting actor
Primary actor «actor »
Cash In Accounting
System
Manager
«actor »
«a ctor » Analyze Activity
HR System
Sales Activity
System

Manage Security

System
Administrator Manage
ManageUser
Users
use case
. .Role
Manage .

16
How to Find Use Cases

• Guideline: Take an Actor and Actor-Goal Perspective

• In UP: Use case is a set of use-case instances, where
each instance is a sequence of actions a system
performs that yields an observable result of value to a
particular actor .
• Two attitudes during requirements analysis:
• Write requirements focusing on the users or actors of a system ,
asking about their goals and typical situations.
• Focus on understanding what the actor considers a valuable
result.

17
How to Find Use Cases

1. Choose the system boundary

– Software, hardware, person, organization

2. Identify the primary actors

– Goals fulfilled by using the system

3. Identify goals for each actor

– Use highest level that satisfies EBP(Elementary Business
Processes )
– Exception: CRUD(增、删、改、查)

4. Define use cases that satisfy user goals

– Name the use case similar to the user goal
– Goal:process a sale | Use Case:Process Sale 18
Actors, Goals & Boundaries

Enterprise Selling Things

Checkout Service
Sales Tax
Agency
POS System
Goal: Collect
taxes on sales Sales Activity
System Cashier

Customer

Goal: Buy items Goal: Analyze sales Goal: Process sales

and performance data

19
 At Which Level to Write a Use Case

project goal

Strategic Goals
“white”
advertise order invoice

User Goals “yellow”

set up reference monitor place create send
promotion promotion promotion order invoice invoice

Subfunctions “indigo”
identify register user identify identify
promotion product customer

A subfunction-level use Case describes substeps required to support a user

goal, and is usually created to factor out duplicate substeps shared by
several regular use cases ( to avoid duplicating common text ) . 20
 Actor-Goal List

Actor Goal
Cashier Process sales
Process rentals
Handle returns
…

Manager Start up
Shut down

System Admin Add user

Modify user
…

21
Other Ways to Find Actors and Goals

• Another approach to aid in finding actors, goals, and use

cases is to identify external events.
• What are they?
• Where from?
• Why?

22
Questions to Help Find Actors and Goals

• In addition to obvious primary actors and goals, the

following questions help identify others that may be
missed:
• Who starts and stops the system?
• Who does system administration?
• Who does user and security management？
• Is “time” an actor because the system does something in
response to a time event?

23
Questions to Help Find Actors and Goals

• Is there a monitoring process that restarts the system if it fails?

• Who evaluates system activity or performance？
• How are software updates handled？Push or pull update?
• Who evaluates logs? Are they remotely retrieved?
• In addition to human primary actors, are there any external
software or robotic systems that call upon sevices of the system?
• Who gets notified when there are errors or failures?
• ……

24
What Tests Can Help Find Useful Use Cases?

• Three Tests to Find a Useful Use Case

– The Boss Test: evaluate the use cases from the
perspective of the boss.
– The EBP Test: focus on use cases at the level of
elementary business processes (EBPs).
– The Size Test: evaluate the complexity of the use cases,
choose the proper size.

25
Example: Applying the Tests

• Negotiate a Supplier Contract

– Much broader and longer than an EBP. Could be modeled as a
business use case, rather than a system use case.

• Handle Returns
– OK with the boss. Seems like an EBP. Size is good

• Log In
– Boss not happy if this is all you do all day

• Move Piece on Game Board

– Single step – fails the size test

26
Use Cases vs. Feature Lists

• Feature Lists: “the system shall…”

– Traditional approach
– Less preferable for user-oriented software
• Only mention function, not flow
• If flows are written elsewhere, then redundant and hard to maintain in
parallel

• High-level feature lists are okay

– Include in Vision document
– “executive summary of use cases”

27
Use Case Text

• Use case are text stories of some actor using a

system to meet goals, can be written in three
formats：
– Brief: one-paragraph summary, main success scenario
– Casual: multiple, informal paragraphs covering many
scenarios

– Fully-Dressed: all steps and variations written in detail with

supporting sections

Usually, writing the stories is more important than

diagramming a use case model in UML

28
A Use Case Example (Brief format)

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.

29
Example (Casual format)

Handle Returns

Main Success Scenario: A customer arrives at a checkout with

items to return. The cashier uses the POS system to record each
returned item…

Alternate Scenarios:

If they paid by credit, and the reimbursement transaction to

their credit account is rejected, inform the customer and pay
them with cash.

If the item identifier is not found in the system, notify the

cashier and suggest manual entry of the identifier code

If the system detects failure to communicate with the external

accounting system… (etc.) 30
 Template for a Fully Dressed Use Case
Use Case Section Comment

Use Case Name Start with a verb

Scope The system under design

Level “User goal” or “subfunction”

Primary Actor Calls on the system to deliver its services

Stakeholders and Interests Who cares about this use case, and what do they want?

Preconditions What must be true on start, and worth telling the reader

Success Guarantee What must be true on successful completion, and worth telling
the reader?

Main Success Scenario A typical, unconditional happy path scenario of success

Extensions Alternate scenarios of success or failure

Special Requirements Related non-functional requirements

Technology and Data Variations Varying I/O methods and data formats.
List
Frequency of Occurrence Influences investigation,testing,and timing of implementaton.

Miscellaneous Such as open issues. 31

A fully-dressed use case example
• Use Case UC1: Process Sale
Scope: NextGen POS application
Level: user goal
Primary Actor: Cashier
Stakeholders and interests:
• Cashier: Wants accurate, fast entry, and no payment errors, …
• Salesperson: Wants sales commissions updated
• Customers: Wants purchase and fast service with minimum effort,…
• Company: Wants to accurately record transactions and …
• Manager: Wants to be able to quickly perform override operations, …
• Government Tax Agencies: Want to collect tax from every sale. ….
• Payment Authorization Service: Wants to receive digital authorization request in
the correct format and protocol, …
Preconditions: Cashier is identified and authenticated
Success Guarantee (or Postconditions): Sale is saved. Tax is correctly calculated.
Accounting and inventory are updated. Commissions recorded. Receipt is generated.
Payment authorization approvals are recorded. 32
A fully-dressed use case example

Main Success Scenario (or Basic Flow):

1. Customer arrives at POS checkout with goods and/or services to purchase
2. Cashier starts a new sale
3. Cashier enters item identifier
4. System records sale line item and presents item description, price, and running
total. Price calculated from a set of price rule
Cashier repeats steps 3-4 until indicates done
5. System presents total with taxes calculated.
6. Cashier tells Customer the total, and asks for payment
7. Customer pays and System handles payment
8. System logs completed sale and send sale and payment information to the
external Accounting system (for accounting and commissions) and Inventory
system (to update inventory)
9. System presents receipt.
10. Customer leaves with receipt and goods (if any).
3
3
A fully-dressed use case example
Extensions (or Alternative Flow):
*a. At any time, Manager requests and override operations:
1. System enters Manager-authorized modes
2. Manager or Cashier performs one Manager-mode operation, e.g.
cash balance change, resume a suspended sale on …
3. System reverts to Cashier-authorized mode.
*b. …
1a. Customer or Manager indicate to resume a suspended sale.
1. Cashier performs resume operations, and enters the ID to retrieve
the sale
2. System displays the state of the resumed sale, with subtotal.
…
4 a. Customer tells Cashier they have a tax-exempt status (e.g., seniors)
1. Cashier verifies, and then enters tax-exempt status code.
2. System records status (which it will used during tax calculation)
3a. Invalid item ID (not found in system);
3
1. … 4
Details

• Scope
– System use case vs. business use case
• Level
– User-goal level, Elementary business process (EBP)
– Subfunctions-level, Ex. Pay by Credit
• Stakeholders and Interests
– Important: defines what the use case covers, “that which satisfies the
stakeholders’ interests”
• Preconditions
– What must always be true before beginning a scenario in the use case
(e.g., “user is already logged in”)

35
 Details

• Success Guarantees (Postconditions)

– What must be true on successful completion of the use case; should
meet needs of all stakeholders
• Main Success Scenario and Steps (Basic Flow)
– Records steps: interactions between actors; a validation (by system); a
state change (by system)
• Extensions (Alternative Flows)
– Scenario branches (success/failure)
– Longer/more complex than basic flow
– Branches indicated by letter following basic flow step number, e.g. “3a”
– Two parts: condition, handling steps
• Special Requirements
– Non-functional considerations (e.g., performance expectations
36
Details

• Technology and Data Variations List

– How something must be done
– 3a. Item identifier entered by laser scanner or keyboard
– 3b. Item identifier may be any UPC , EAN , JAN , or SKU coding
scheme
– 7a. Credit account information entered by card reader or keyboard.
– 7b. Credit payment signature captured on paper receipt . But within two
years, we predict many customers will want digital signature capture.

37
Other Formats of Use Case

the two-column format

There isn't one best format. Sections may be added and removed.
The key thing is to write the details of the main success scenario and its extensions.
38
Guideline: Write in an Essential UI-Free Style

• Essential Style Writing

Keep the user interface out and focus on actor intent

• Contrasting Examples
Essential Style:
1. Administrator identifies self.
2. System authenticates identity.
3. …
Concrete Style:
1. Administrator enters ID and password in dialog box (see Picture 3).
2. System authenticate Administrator.
3. System displays the “edit users” window (see Picture 4).
4. …

39
Guideline: Write terse Use Cases

• Write terse use cases, delete “noise” words;

• “System authenticates” rather than “The System
authenticates”.

40
Guideline: Write Black-Box Use Cases

• Focus on “what”, not “how”

• Good: The system records the sale

• Bad: The system writes the sale to a database

Premature design decisions!
• Worse: The system generates a SQL INSERT
statement…

Analysis vs. Design = “What” vs. “How”

41
Example：Monopoly Game

14
42
Evolve Use Cases and Other Specification
Across the Iterations

16
43
UP Artifacts and Timing

s: start; r: refine
44
44
Relationships of Use Case

• Use cases can be related to each other.

• For example, a subfunction use case such as
HandleCredit Payment may be part of several regular
use cases, such as Process sale and Process Rental.
• Organizing use cases into relationships has no impact
on the behavior or requirements of the system.
• Rather, it is simply an organization mechanism to
improve communication and comprehension of the use
cases, reduce duplication of text and improve
management of the use case documents.

45
Guideline : Avoid Agonizing Over Use Case
Relationships

• Discusses relating Use Cases has some value, but the

important work is writing use case text.
• Organizing use cases is an optional step to possibly
improve their comprehension or reduce duplication.
• A deeper problem in analysis-oriented work on software
projects: Too much time wasted on low-value analysis
and modeling.
•Don't spend too much time on use case
relationships, focus on writing the key use case text.

46
 The Include Relationship

• Include Relationship is the most common and important

relationship between use cases.
• It is common to have some partial behavior that is common
across several use cases .
• For example, the description of paying by credit occurs in several
use cases, including Process SaleProcess, Rental , Contribute to
Lay-away Plan, and so forth .
• Rather than duplicate this text, it is desirable to separate it into its
own subfunction use case, and indicate its inclusion.
• This is simply refactoring and linking text to avoid duplication.
• Another motivation is simply to decompose an overwhelmingly long
use case into subunits to improve comprehension.

47
The include Relationship Example

UC1: Process Sale

…
Main Success Scenario:
1. Customer arrives at a POS checkout with goods and/or services
purchase
…
7. Customer pays and System handles payment
…
Extensions:
a. Paying by credit: include Handle Credit Payment
b. Paying by check: include Handle Check Payment
…

UC7: Process Rental

…
Extensions:
6.b Paying by credit: include Handle Credit Payment
48
…
The include Relationship Example

UC12: Handle Credit Payment

…
Level: Subfunction
Main Success Scenario:
1. Customer enters their credit account information
2. System sends payment authorization request to an external Payment
Authorization Service System, and requests payment approval
3.System receives payment approval and signals approval to Casher 4.
…
Extensions:
a. System detects failure to collaborate with external system:
1. System signals error to Cashier
2. Cashier asks Customer for alternate payment
…
 Use Case Diagrams

NextGen POS

Process Sale

Cashier
«include» «include» «actor»
Accounting
«include» System

Handle Check Handle Cash Handle Credit

Payment Payment Payment
Customer «actor» Credit
«include» Authorization
«include» «include» Service
UML notation:
the base use
Process Rental
case points to
the included use
case
Handle Returns

Manage Users

...

50
 Terminology : Concrete , Abstract , Base ,
and Addition Use Cases

• A concrete use case is the elementary business process use

case, initiated by an actor and performs the entire behavior
desired by the actor,e.g. Process Sale.
• An abstract use case is a subfunction use case that is part of
another use case, that is never instantiated by itself, e.g.Handle
Credit Payment. It is always part of another story, such as
Process sale.
• A base use case is that includes another use case or that is
extended or specialized by another use case, e.g. Process Sale.
Base use cases are usually concrete.
• An addition use case is an inclusion,extension or specialization
use case, e.g. Handle credit Payment. Addition use cases are
usually abstract.

51
The Extend Relationship

• Suppose a use case's text should not be modified (at least not
significantly) for some reason, or the use case has been
baselined as a stable artifact and can't be touched.
• Continually modifying the use case with myriad new
extensions and conditional steps is a maintenance headache.
How to append to the use case without modifying its original
text?
• The extend relationship provides an answer. The idea is to
create an extending or addition use case and within it
describe where and under what condition it extends the
behavior of some base use case.

52
The extend Relationship
UC1: Process Sale (the base use case)
…
Extension Points: VIP Customer, step 1. Payment, step 7
Main Success Scenario:
1. Customer arrives at a POS checkout with goods and/or services to
purchase
…
7. Customer pays and System handles payment
…
UC15: Handle Gift Certificate Payment (the extending use case)
…
Trigger: Customer wants to pay with gift certificate
Extension Points: Payment in Process Sale
Level: Subfuction
Main Success Scenario:
1. Customer gives gift certificate to Cashier
2. Cashier enters gift certificate ID
… 53
The extend relationship

Process Sale

Extension Points:
Payment UML notation:
VIP Customer 1.The extending use case
points to the base use case.
«extend»
Payment, if Customer 2.The condition and
presents a gift certificate extension point can be
shown on the line.
Handle Gift Certificate
Payment

54
Homework

• 从你们组的用例模型中选择一个你认为最重要的用例，以
Fully Dressed形式编写该用例的用例说明：

55
Experiment 1

• 分析你们小组目标系统的需求分析：
• 1、完善系统用例图；
• 2、针对每个用例撰写用例说明，形成完整的Use-Case Model；
• 4、完善其他需求分析制品（ Vision 、Supplementary
Specification 、 Glossary 、 Business Rules ）

56