Software Design & Architecture

Lecture # 3
Use Case Modeling
 What is a Use Case?
Narrative descriptions of domain processes in a

structured prose format

They are stories or scenarios of how people use the

system

2
  To describe functional System Specifications

 To provide starting point for System Design (including

GUI)
 To provide basis for System Verification tests
 To provide a quick checkout for the customer

3
The Scope of Use Cases
Analysis Design Test
and
Implementation
Use cases make up the glue
Capture Implement Verify that
use cases use cases use cases
are satisfied

User Understands Analyst

Expresses

Use Case

Implements
Designs Verifies

Programmer Tester

Architect
 Case Study – The NextGen POS System
Computerized application used to record sales and
handle payments
Used in retail store
It includes hardware and software components
It also interfaces to other applications, such as a third-
party tax calculator and inventory control
Multiple and varied clients-side terminals and
interfaces
Commercial POS (a product)

5
 Use Case, Actor, and Scenario
 Actors
 Something with behavior such as person, computer system, or
organization
 Scenario
 It is a specific sequence of actions and interactions between actors
and the system
 It is also called use case instance
 It is one particular story of using a system
 Example: scenario of successfully purchasing items with cash or
scenario of failing to purchase items because of credit payment
denial
 Use case then is a collection of success and failure scenarios
 Use cases are requirements, primarily functional

6
 Use Case, Actor, and Scenario
 A UC is a dialogue between an actor and a system that
accomplishes a task
 The dialogue is presented as a sequence of steps
 A complete sequence of steps is a use case scenario
 A scenario (UC instance) forms a complete path through
the UC
 A UC can contain multiple scenarios/paths
 UCs are not object-oriented artifacts! They feed into
other OO models

7
 Kinds of Actors
• Primary actor
– has user goals fulfilled through using services of the system
– why identify? To find user goals, which drive use cases

• Supporting actor
– provides a service (for example, information) to the system
– why identify? To clarify external interfaces and protocols

• Offstage actor
– has an interest in the behavior of the use case
– why identify? To ensure that all necessary interests are identified
and satisfied

8
 Guidelines: How to Find Use Cases?
 Four Steps
1. Choose the system boundary
2. Find primary actors
3. Identify goals for each primary actor
4. Define use cases that satisfy user goals
i. Draw Use Case Diagram

ii. Write Use Case Text

9
 1. Choose the System Boundary

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

10
 2 and 3. Primary Actors and their Goals
Brainstorm (pooling of spontaneous ideas about a
problem) the primary actors first
Questions to help identify actors and goals
Who starts and stops the system?
Who does user and security management?
Who does system administration?
Is “Time” an actor because the system does something in
response to a time event?
Are there any external software system that call upon the
services of the system?
Organize the actors and goals in an Actor Goal List

11
 Actor Goal List

12
 4. Define Use Cases that Satisfy User Goals
(i. Use Case Diagram)
system boundary NextGen POS communication

Process Sale alternate

notation for
Customer a computer
Payment system actor
Authorization
Service
Handle Returns
«actor»
actor Tax Calculator
Cashier

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

Manage Security

System Manage Users

Administrator use case
...
13
 4. Define Use Cases that Satisfy User Goals
(i. Use Case Diagram)

For a use case context Show computer system actors

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

NextGen

«actor»
Process Sale Payment
Authorization
Service
Cashier
...

primary actors on supporting actors

14 the left on the right
 4. Define Use Cases that Satisfy User Goals
(ii. Writing Use Case Text)
Use cases are text documents, not (just) diagrams

Use case modeling is primarily an act of writing text,

not drawing diagrams

15
 4. Define Use Cases that Satisfy User Goals
(ii. Writing Use Case Text)
 Guideline: Black Box Use Cases
 Black-Box Style:
 Focus on what, not how
 Defer implementation details
 Avoid reference to specific technologies

16
 4. Define Use Cases that Satisfy User Goals
(ii. Writing Use Case Text)
Use Case Formats
Brief, Casual, and Fully Dressed

Brief Format

17
 4. Define Use Cases that Satisfy User Goals
(ii. Writing Use Case Text)
Causal Format

18
4. Define Use Cases that Satisfy User Goals
(ii. Writing Use Case Text) Fully Dressed Format
Use Case Sections Comments
Use case name Start with a verb
Scope The system under design
Level “User goal” or “Sub function”
Primary Actor Calls on system to deliver its services
Stakeholders and interests Who cares about the system and what do
they want
Preconditions What must be true on start
Success Guarantee What must be true on successful completion
Main Success Scenario Unconditional happy path scenario of
success
Extensions Alternate scenario of success or failure
Special Requirements Related NFRs
Technology and Data variation list Varying I/O methods
Frequency of occurrence Influences investigation, testing
19
Miscellaneous Open issues
 Fully dressed Use Case
(e.g., Process Sale)
 Use case UC1: Process Sale
 Scope: Point of Sale
 Level: User Goal
 Primary Actor: Cashier
 Stakeholders and Interests:
 -Cashier: Wants accurate and fast entry, no payment errors, …
 -Salesperson: Wants sales commissions updated.
 Preconditions: Cashier is identified and authenticated.
 Success Guarantee (Postconditions):
 -Sale is saved. Tax correctly calculated.
 Main success scenario (or basic flow): [on next slide]
 Extensions (or alternative flows): [on next slide]
 Special requirements: Touch screen UI, …
 Technology and Data Variations List:
 -Identifier entered by bar code scanner,…
 Open issues: What are the tax law variations? …
 UC1: Process Sale
 Main success scenario (or basic flow):
 The Customer arrives at a POS checkout with items to purchase.
 The cashier records the identifier for each item. If there is more than one
of the same item, the Cashier can enter the quantity as well.
 The system determines the item price and adds the item information to
the running sales transaction. The description and the price of the current
item are presented.
 On completion of item entry, the Cashier indicates to the POS system
that item entry is complete.
 The System calculates and presents the sale total.
 The Cashier tells the customer the total.
 The Customer gives a cash payment (“cash tendered”) possibly greater
than the sale total.
 Extensions (or alternative flows):
 If invalid identifier entered. Indicate error.
 If customer didn’t have enough cash, cancel sales transaction.
 Terminology: Concrete, Abstract, Base, and
Addition Use Cases
 Concrete use case
 is initiated by an actor
 is an EBP use case
 e.g., Process Sale
 Abstract use case
 is never instantiated by an actor
 is a sub-function use case (part of another use case)
 e.g., Handle Credit Payment
 Base use case
 that includes another use case, or that is extended or specialized by another use
case
 e.g., Process Sale with respect to the included Handle Credit Payment
 Addition use case
 that is an inclusion, extension, or specialization
 Handle Credit Payment in the include relationship to Process Sale
 Addition use cases are usually abstract
 Base use cases are usually concrete
Use Case Associations
Use case association = relationship between use cases
Important types:
Include
 A use case uses another use case (functional decomposition and
reuse of existing functionality)
Extends
 A use case extends another use case
Generalization
 A use case has different specializations
 ≪include≫: Functional Decomposition
 Problem:
 A function in the original problem statement is too complex to be
solvable immediately
 Solution:
 Describe the function as the aggregation of a set of simpler functions.
The associated use case is decomposed into smaller use cases

CreateDocument

≪include≫
≪include≫
≪include≫

Scan OCR Check

 ≪ include : Reuse of Existing Functionality
 Problem: ≫
 There are already existing functions. How can we reuse them?
 Solution:
 The include association from Use Case A to Use Case B indicates that an
instance of A performs all the behavior described in B (“A delegates to
B”)
 Example:
 The use case “ViewMap” describes behavior that can be used by the use
case “OpenIncident” (“ViewMap” is factored out)
 Note: The base use case cannot exist alone. It is always called with the
supplier use case

≪include≫

OpenIncident
ViewMap
Base Use ≪include≫
Case Supplier
AllocateResources Use Case
Example: Include Relationship
UC1: Process Sale
 …
 Main Success Scenario:
1. Customer arrives at a POS checkout with goods and/or services
to purchase
.…
7. Customer pays and System handles payment.
…
 Extensions:
7b. Paying by credit: Include Handle Credit Payment.
7c. Paying by check: Include Handle Check Payment.
…
 Example: Include Relationship cont…
UC12: Handle Credit Payment
 …
 Level: Sub-function
 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 Cashier.
4. …
 Extensions:
2a. System detects failure to collaborate with external system:
1. System signals error to Cashier.
2. Cashier asks Customer for alternate payment.
 …
When to Use Include Relationship?
Use include when you are repeating yourself in

two or more separate use cases and you want to

avoid repetition.

A use case is very complex and long, and

separating it into subunits aids comprehension.

 ≪ extend Association for Use Cases
 Problem: ≫
 The functionality in the original problem statement needs to be extended.
 Solution:
 An extend association from Use Case B to Use Case A indicates that B is
an extension of A.
 Example:
 The use case “ReportEmergency” is complete by itself , but can be
extended by the use case “Help” for a specific scenario in which the user
requires help
 Note: In an extend association, the base use case can be executed without
the use case extension

Base Use
Case B
Help
FieldOfficer
A ≪extend≫

ReportEmergency
≪extend≫ Association for Use Cases
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.
Example: Extend Relationship
____Process Sale___
Extension Points:
Payment
VIP Customer UML Notation:
1. The extending use
≪extend≫ case points to the
base use case.
Payment, if
customer presents a2. The condition and the
gift certificate extension point can be
shown on the line.
Handle gift certificate
payment
Example: 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
.…
Example: Extend Relationship cont…
UC15: Handle Gift Certificate Payment (the extending use case)
 …
 Trigger: Customer wants to pay with gift certificate.
 Extension Points: Payment in Process Sale.
 Level: Sub-function
 Main Success Scenario:
1. Customer gives gift certificate to Cashier.
2. Cashier enters gift certificate ID.
 …
 Generalization Association in Use Cases
 Problem
 You have common behavior among use cases and want to factor this out.
 Solution
 The generalization association among use cases factors out common
behavior. The child use cases inherit the behavior and meaning of the
parent use case and add or override some behavior.
 Example
 Consider the use case “ValidateUser”, responsible for verifying the
identity of the user. The customer might require two realizations:
“CheckPassword” and “CheckFingerprint”

CheckPassword

Parent ValidateUser
Child
Case
CheckFingerprint Use Case
 Use-Case Experts advise to Keep Things Simple
and Prefer the include Relationship
NextGen POS

Process Sale

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

Handle Check Handle Cash Handle Credit

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

Handle Returns

Manage Users

...
35
 Recommended Readings
 Section 3.3, Chapter # 3: Case Studies from Applying UML and
Patterns: An Introduction to Object-Oriented Analysis and Design and
Iterative Development by Craig Larman, 3rd Edition
 Chapter # 6: Use Cases from Applying UML and Patterns: An
Introduction to Object-Oriented Analysis and Design and Iterative
Development by Craig Larman, 3rd Edition
 Chapter # 7: Other Requirements from Applying UML and Patterns: An
Introduction to Object-Oriented Analysis and Design and Iterative
Development by Craig Larman, 3rd Edition
 Chapter # 30: Relating Use Cases from Applying UML and Patterns:
An Introduction to Object-Oriented Analysis and Design and Iterative
Development by Craig Larman, 3rd Edition

36