Use Case Diagrams and

Specifications

Examples
 About Use Case Diagram
• “Invented” by Ivar Jacobson in the late 1960’s
• Alistair Cockburn has extended Jacobson’s
model
• Is a way to specify functional requirements
• Is notated using a use case specification
 About Use Case Diagram
• A use case captures a contract between the
stakeholders of a system about its behavior

• Describes the system’s behavior under various

conditions
• The primary actor initiates some interaction
with
• System responds, protecting the interests of all
of the stakeholders the system
• Different sequences of behaviors, or scenarios,
can unfold, depending on the requests and the
conditions surrounding the request
 Use Case Specification Template*
Number
Name
Summary
Priority
Preconditions
Post conditions
Primary Actor(s)
Secondary Actor(s)
Trigger
Main Scenario Step Action

Extensions Step Branching Action

Open Issues
 Use Case Specification Template*
Number Unique use case number
Name Brief verb-noun phrase
Summary Brief summary of use case major actions
Priority 1-5 (1 = lowest priority, 5 = highest priority)
Preconditions
Post conditions
Primary Actor(s)
Secondary Actor(s)
Trigger
Main Scenario Step Action

Extensions Step Branching Action

Open Issues
 Use Case Specification Template*
Number
Name
Summary
Priority
Preconditions What needs to be true before the use case “executes”
Postconditions What will be true after the use case successfully “executes”
Primary Actor(s)
Secondary Actor(s)
Precondition: y != 0 Precondition: None
Trigger
Post condition: x / y Post condition: if y==0 “Illegal”, else x / y
Main Scenario Step Action
double divide(double x, double y) { double divide(double x, double y) {
return (x / y); if (y == 0) cout << “Illegal\n”;
} else return (x / y);
Extensions Step } Action
Branching

Open Issues
 Actor
Use Case Specification Template*
• Anyone or anything with behavior
Number • May be a person or system
Name • Primary: The stakeholder who or which
Summary initiates an interaction with the system to
Priority achieve a goal. Is generally a category of
Preconditions individuals (a role).
Postconditions • Secondary: Provides a service to the
Primary Actor(s) Primary actor name(s) system. Is almost never a person.
Secondary Actor(s) Secondary actor name(s)
Trigger
Main Scenario Step Action

Extensions Step Branching Action

Open Issues
 Use Case Specification Template*
Number
Name
Summary
Priority
Preconditions
Postconditions
Primary Actor(s)
Secondary Actor(s)
Trigger The action that caused the use case to be invoked
Main Scenario Step Action
Step # This is the “main success scenario” or “happy path”
Step # Description of steps in successful use case “execution”
Step # This should be in a “system-user-system, etc.” format
Extensions Step Branching Action

Open Issues
 Use Case Specification Template*
Number
Name
Summary
Priority
Preconditions
Postconditions
Primary Actor(s)
Secondary Actor(s) Extension
Trigger • Could be an optional path(s)
Main Scenario Step Action • Could be an error path(s)
• Denoted in use case diagrams (UML) by
<<extend>>

Extensions Step Branching Action

Step # Alternative paths that the use case may take
Open Issues
 Use Case Specification Template*
Number
Name
Summary
Priority
Preconditions
Postconditions
Primary Actor(s)
Secondary Actor(s)
Trigger
Main Scenario Step Action

Extensions Step Branching Action

Open Issues Issue # Issues regarding the use case that need resolution
 Use Case Specification Template*
Number Unique use case number
Name Brief noun-verb phrase
Summary Brief summary of use case major actions
Priority 1-5 (1 = lowest priority, 5 = highest priority)
Preconditions What needs to be true before use case “executes”
Postconditions What will be true after the use case successfully “executes”
Primary Actor(s) Primary actor name(s)
Secondary Actor(s) Secondary actor name(s)
Trigger The action that causes this use case to begin
Main Scenario Step Action
Step # This is the “main success scenario” or “happy path.”
… Description of steps in successful use case “execution”
… This should be in a “system-user-system, etc.” format.
Extensions Step Branching Action
Step # Alternative paths that the use case may take
Open Issues Issue # Issues regarding the use case that need resolution
 Use Case 1. Withdraw Money
The system displays the account types available to be
withdrawn from and the user indicates the desired
type. The system asks for the amount to be withdrawn
and the user specifies it. Next, the system debits the
user’s account and dispenses the money. The user
removes the money, the system prints a receipt, and
the user removes the receipt. Then the system displays
a closing message and dispenses the user’s ATM card.
After the user removes his card, the system displays
the welcome message.
 Use Case 1. Withdraw Money
Number 1
Name Withdraw Money
Summary User withdraws money from one of his/her accounts
Priority 5
Preconditions User has logged into ATM
Post conditions User has withdrawn money and received a receipt
Primary Actor(s) Bank Customer
Secondary Customer Accounts Database
Actor(s)
Trigger User has chosen to withdraw money
Main Step Action
Scenario
1 System displays account types
2 User chooses account type
3 System asks for amount to withdraw
4 User enters amount
5 System debits user’s account and dispenses money
6 User removes money
7 System prints and dispenses receipt
8 User removes receipt
9 System displays closing message and dispenses user’s ATM
card
11 User removes card
10 System displays welcome message
Extensions Step Branching Action
5a System notifies user that account funds are insufficient
5b System gives current account balance
5c System exits option
Open Issues 1 Should the system ask if the user wants to see the balance?
 system name
system boundary
ATM System

primary actor 1
Withdraw secondary actor
Money

2
Bank Deposit
Customer Money
Customer
Accounts
role 3 Database
Transfer
Money
association

<<Customer
4
Accounts
Check
Database>>
use case Balance
alternative
actor notation
stereotype
Sub-use Case Diagram

1a
Withdraw
from
<<extend>>
Checking
1
Withdraw
Money
Bank
Customer
<<extend>> 1b
Withdraw
from Customer
Savings Accounts
This is an extend dependency. Database

It indicates that use case 1b is part of use

case 1, but it may or may not be invoked.
The same is true of use case 1a.
Sub-use Case Diagram
1a
Withdraw
from
Checking
1
Withdraw
Money
Bank
Customer
1b
Withdraw
from Customer
Savings Accounts
Database
generalization
 Sub-use Case Diagram

3a
Select
<<include>> Accounts

3
Transfer
Money
Bank
Customer
<<include>> 3b
Update
Account Customer
Balances Accounts
This is an include dependency. Database

It indicates that use case 3b is “included”

in use case 3 and will be invoked.
The same is true of use case 3a.