Use cases
Applying UML and Patterns
Applying UML and Patterns :Craig Larman
Object-Oriented Analysis and Design
Overview
• Use cases describe domain processes in
a structured prose format.
• We explore basic skills.
– Definitions.
– Notation.
– Guidelines.
– Practice.
Object-Oriented Analysis and Design
Objectives
• Read and create high-level and expanded
format use cases.
• Distinguish between essential and real use
cases.
Object-Oriented Analysis and Design
Use cases
• They are used to discover and record
requirements.
• Use cases are not diagrams they are text
documents.
• Use cases are one way of capturing the functional
requirements.
• Use cases are text stories
of some actors using a
system to meet goals.
Object-Oriented Analysis and Design
MOTIVATION: Comprehensible &
Familiar
• Use cases are stories.
• A simple and familiar
model that many
people, especially nontechnical, can easily
relate to.
Object-Oriented Analysis and Design
Use Cases
• They are a collection of related success and
failure scenarios that describe an actor using
a system to satisfy a goal.
• They must return an observable value to a
particular actor.
Borrow
Resources
Object-Oriented Analysis and Design
scenarios
• A scenario is also called a use case instance.
• It is a specific sequence of actions and
interactions between actors and the system.
or
It is one path through the system.
Object-Oriented Analysis and Design
Actor
• An actor is someone with behavior.
• Think of actors in terms of Roles rather than
job titles.
• Actors carry out use cases.
• A single actor carries out many use cases and
many roles.
• There is one Primary actor and possibly
several secondary actors.
Object-Oriented Analysis and Design
Actors can be:
Actors
• Roles of humans.
Example: A Patron.
• Other computer systems.
Example: The Visa network.
Object-Oriented Analysis and Design
The three Common formats for Use
cases.
• Brief: One paragraph summary of the main
success scenario.
• Casual: multiple paragraphs that covers
various scenarios.
• Fully dressed: All steps and sections are
written in detail, and there are supporting
sections such as preconditions and success
guarantees. Also known as the expanded
format.
Object-Oriented Analysis and Design
Brief Use Case
Name: Borrow Resources
Actors: Patron (initiator), Librarian
Description: The use case begins when the
Patron arrives at the check-out with books and
videos to borrow and submits them to the
Librarian, who records the resources borrowed.
The Patron then leaves with the resources.
Object-Oriented Analysis and Design
Use Case Diagrams
Library Information System
Borrow
Resources
Add
Resources
Librarian
Patron
Return
Resources
Object-Oriented Analysis and Design
Sample High-Level Primary Use Cases
 Name: Add Resources.
 Actors: Librarian.
 Description: The use case begins when the
Librarian receives new resources (books and
videos) to add to the catalog. The title,
call number, and other information are recorded.
Then the resources are placed on a shelf
organized by resource type and
call numbers.
Object-Oriented Analysis and Design
Sample High-Level Primary Use Cases
Other possible use cases.
• Return a Resource.
• Delete a Resource.
• Notify Overdue Patrons.
• Collect Fines.
Object-Oriented Analysis and Design
GUIDELINES: Use Case Modeling
•
It is common to group CRUD (Create, Read,
Update, Delete) operations into one use case.
–
•
Manage Users
Name starts with a verb.
Manage Users
•
All systems have a Start Up and Shut Down use case
(perhaps trivial and low level).
Object-Oriented Analysis and Design
Abstraction Levels of Use Cases
ESSENTIAL
REAL
The essence of the process.
Analysis-oriented.
Concrete, design-oriented.
Expresses process (relatively)
independent of
a hardware/software solution.
Expressed in terms of the
solution—screen shots of
windows, entry into input
fields, and so forth.
 Essential use cases defer
the details of the UI, and Clerk takes Customer ID
focus on the intentions of card and reads the bar code
the actors.
with laser scanner.
 Clerk enters Customer ID.
Object-Oriented Analysis and Design
Essential versus Real Use Cases
Essential
Real
The Librarian records the call
number.
The Librarian uses the laser
wand to scan the bar code for
the call number, which is
transmitted to the computer.
The AccountHolder identifies
himself to the ATM.
The AccountHolder inserts
the card into the ATM card
reader. He is prompted to
enter his PIN (see screen
shot 4), which he inputs with a
numeric keypad.
Object-Oriented Analysis and Design
Expanded Format Use Cases
 Describe the use case in greater detail.
 Can be written essential or real.
 Have the following components:
◦ Name.
 Starts with a verb.
◦ Description.
 From the high-level use case.
◦ Actors.
 Initiator and participants from high-level use case.
◦ Type.
 If decomposed, then super / sub (abstract).
 Also, primary / secondary, and essential / real.
Object-Oriented Analysis and Design
Expanded Format Use Cases
(continued)
 Have the following components (continued):
◦ Cross-references.
 Related use cases and system functions.
◦ Preconditions.
 Assumptions that must hold true.
o Stakeholders and their interests.
◦ Typical Course of Events.
 Most important section describes regular flow of events.
◦ Alternatives.

o
o
o
o
Exceptional alternatives that might arise.
Special requirements. : related non-functional requirements.
Technology and data variation
Frequency.
Open Issues.
Object-Oriented Analysis and Design
EBP for Use Case Levels
•
Focus on use cases at the level of EBPs.
– “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.”
• Naively, can you apply the “boss test” for an
EBP?
Object-Oriented Analysis and Design
Here’s one in a brief format:
– Rent Videos. A Customer arrives with videos to
rent. The Clerk enters their ID, and each video ID.
The System outputs information on each. The
Clerk requests the rental report. The System
outputs it, which is given to the Customer with
their videos.
Object-Oriented Analysis and Design
EBP for Use Case Levels
•
For example, how do we know which of these is at a useful level?
– Negotiate a Supplier Contract
– Rent Videos
– Log In
– Start Up
•
Boss: “What do you do all day?”
•
Me: “I logged in!”
•
Is Boss happy?
Object-Oriented Analysis and Design
Size for Use Case Levels
• An EBP-level use case usually is composed of several
steps, not just one or two.
• It isn’t a single step.
•
Applying the EBP and size guidelines:
–
–
–
–
•
Negotiate a Supplier Contract
Rent Videos
Log In
Start Up
The others can also be modeled as use cases.
– But, prefer a focus on the EBP level.
Object-Oriented Analysis and Design
Use Case Diagrams
Video Store
Information System
Clerk
Pay Fines
Rent Items
Manage
Memberships
Customer
Log In
Manage
Inventory
Administrator
Manage Users
«actor»
Credit
Authorization
Service
Object-Oriented Analysis and Design
GUIDELINES: Use Case Diagrams
Show computer system actors
with an alternate notation to
human actors.
Prefer use cases at the EBP level.
Video Store Information System
«actor»
Credit
Authorization
Service
Rent Videos
Clerk
...
primary actors on
the left
supporting actors
on the right
Object-Oriented Analysis and Design
EXAMPLE: Fully Dressed
Use Case UC1: Rent Video
Level: User-level goal (EBP level)
Primary Actor: Clerk
Preconditions:
• Clerk is identified and authenticated.
Stakeholders and their Interests:
Clerk: Wants accurate, fast entry.
Customer: Wants videos, and fast service with minimal
effort.
Accountant: Wants to accurately record transactions.
Marketing: Wants to track customer habits.
Object-Oriented Analysis and Design
EXAMPLE: Fully Dressed
Main Success Scenario (or Basic Flow or “Happy Path”):
1.
2.
3.
4.
Customer arrives at a checkout with videos or games to rent.
Clerk enters Customer ID.
Clerk enters rental identifier.
System records rental line item and presents item description.(Clerk
repeats steps 3-4 until indicates done.)
5.
System displays total.
6.
Customer pays. System handles payment.
7.
Clerk requests rental report.
8.
System outputs it. Clerk gives it to Customer.
9.
Customer leaves with rentals and report.
Object-Oriented Analysis and Design
EXAMPLE: Fully Dressed
Extensions (or Alternatives):
a*. At any time, System fails:
1. Clerk restarts System
2. logs in
3. requests recovery from prior state
1a. New Customer.
1. Perform use case Manage Membership.
2a. Customer ID not found.
1. Cashier verifies ID. If entry error, reenter, else Manage Membership.
2b. Customer has unpaid fines (usually for late returns).
1. Pay Fines.
Object-Oriented Analysis and Design
EXAMPLE: Fully Dressed
Special Requirements:
 Language internationalization on the display messages and rental
report.
 Large text on display. Visible from 1 m.
Technology and Data Variations:
 ID entries by bar code scanner or keyboard.
Frequency:
 Near continuous
Open Issues:
 Should we support a magnetic stripe cards for customer ID, and
allow customer to directly use card reader?
Object-Oriented Analysis and Design
Use-Case Miscellany
Borrow
Resources
Librarian
 The first line of a use case course of events should
describe the event that starts the use case.
◦ Example: This use case begins when the <actor>
<generates an input event>
 Start the use-case name with a verb.
◦ Purchase …
◦ Borrow …
Object-Oriented Analysis and Design
generalization
– A use case generalization shows that one use case
is simply a special kind of another.
– A child can be substituted for its parent whenever
necessary.
– Generalization appears as a line with a triangular
arrow head toward the parent use case.
Object-Oriented Analysis and Design
Include relationships
• Includes are especially helpful when the same
use case can be factored out of two different
use cases.
• In the diagram, include notation is a dotted
line beginning at base use case ending with an
arrows pointing to the include use case. The
dotted line is labeled <<include>>.
Object-Oriented Analysis and Design
extend relationship
• An extend relationship indicates that one use
case is a variation of another.
• Extend notation is a dotted line, labeled
<<extend>>, and with an arrow toward the
base case.
• The extension point, which determines when
the extended case is appropriate, is written
inside the base case.