1. Use Cases 2 ENGR 110 2015 ♯10 Peter Andreae
Engineering and Computer Science
Victoria University of Wellington
Copyright Rebecca Ford, Peter Andreae

2. Step 2: Identifying Actors: Static context diagrams
Shows how actors are connected to the system.
<< actor>>
Bank IS
<< actor>>
Visa AS
Cardholder
ATM
Only got to here in first lecture (pondy, 2015)
Maintenance operator
Bank customer

3. Step 3: Identifying interactions
How does each actor use/interact with the ATM system
Primary actor:
Uses system to achieve goal
Actors
System interactions
Type
Cardholder
Withdraw money
Primary
Bank customer
Withdraw money, check balance, deposit cash/cheque
Authorization systems
None (secures transactions)
Secondary
Maintenance operator
Refill cash dispenser, recover lost cards, retrieve deposits
Contrary to what we might believe, all actors do not necessarily use the system!
We call the one for whom the use case produces an observable result the primary actor.
In contrast, secondary actors constitute the other participants of the use case.
Secondary actors are requested for additional information; they can only consult or inform the system when the use case is being executed.
This is exactly the case of the two “non-human” actors in our example: the Visa AS and the Bank IS are only requested by the ATM within the context of realising certain use cases. However, they themselves do not have their own way of using the ATM.
Secondary actor:
Actors that system uses in order to achieve goals

4. Use Case Diagrams
Use Case Diagrams are a way of formally expressing system interactions
Shows the interactions between the actors and the system
Represents the specific sequence of actions
Models a service offered by the system
Expresses actor/system interactions
Steps:
Add primary actors
Add functional requirements as “use cases”
Map actors to use cases
Add system boundary

5. ATM: Use Case Diagram: 2 Use case Steps: Primary actors Use cases
Map actors to use cases
System boundary
Secondary actors
Retrieve cheques
Withdraw money
Check balance
Deposit cheque
Deposit cash
Refill dispenser
Retrieve lost cards
Cardholder
Use case
Bank customer
Maintenance operator

6. ATM: Use Case Diagram: 2 << actor>> Visa AS
Add the secondary actors (For simplicity, leave out the maintenance operator)
Visa system to authorise visa card transactions
Bank information system to withdraw from, deposit to, check balance of account
<< actor>>
Visa AS
<< actor>>
Bank IS

7. << actor>>
ATM: Use Case Diagram: 1
Primary actors
Use cases
Map actors to use cases
System boundary
Secondary actors
Withdraw money
Check balance
Deposit cheque
Deposit cash
Cardholder
secondary
<< actor>>
Bank IS
Visa AS
Role
secondary
Bank customer
What’s the problem with this diagram?

8. Need to Distinguish Use Cases
If a single use case could have two different sets of actors,
 Need to break it down.
<< actor>>
Visa AS
secondary
Withdraw money using a visa card
Cardholder
<< actor>>
Bank IS
secondary
Withdraw money using a bank card
Bank customer

9. An Exercise: a Library system.
You have been contracted to develop a computer system for a university library. The system needs to be able to conduct simple bookkeeping tasks, such as keeping track of the books and journals that users have borrowed. Staff members are allowed to borrow both books and journals, but students can only borrow books. The system should also allow users to browse books, reserve books (if there is a copy available) and enable librarians to keep the catalogue up to date.
Step 1: clarify your functional requirements
Step 2: identify the actors in the system
Step 3: Identify actor/system interactions

10. ATM: Use Case Diagram Is this enough to tell you what’s
<< actor>>
Visa AS
What additional
details do we
need?
secondary
Withdraw money (visa)
<< actor>>
Bank IS
secondary
Cardholder
Is this enough to
tell you what’s
going on in the
system?
Withdraw money (bank)
Check balance
Refill dispenser
Deposit cash
Retrieve lost cards
Bank customer
Maintenance operator
Deposit cheque
Retrieve cheques

11. Use Case descriptions/bodies
Need to explain the dynamics of the use cases
For each Use Case:
Construct a list of all interactions with the system.
Describe an interaction in a Use Case Body:
table of sequence of actions
Describes an interaction.
Each interaction needs to have:
a clearly identifiable beginning
a clearly identifiable end
clearly specified possible sequences of events
System
Actions
Use Case Name
(Actors’ Names)
Actor Actions

12. Use Case Bodies: Actor Actions
What is the goal of the actor?
Use case name should reflect that goal
Typical user actions:
Request information
Edit/Enter information
Verify information
Choose some options
Confirm
Choose right level of detail:
too abstract  leaves important information out
too detailed  hides important information in the verbiage.

13. System Actions
What the system must do to support the goal of the interaction
Typical system responsibility steps:
Present, Show, Print,… information
Record, Update, Insert, Delete… information
Request information
Offer choices
Confirm
Accept payment,
Verify PIN, Verify payment, Verify password
Choose the right level of detail!

14. ATM: Use Case Body: Withdraw Money (Visa)
Cardholder
Withdraw Money Using Visa Card
(Actors: Cardholder, Visa AS)
Withdraw
money
using a
visa card
secondary
<< actor>>
Visa AS
User Intention
System responsibility

15. ATM: Use Case Body: Withdraw Money (Visa)
Cardholder
Withdraw Money Using Visa Card
(Actors: Cardholder, Visa AS)
1. User inserts card
2. Request PIN
3. User enters PIN
4. Request authorisation
5. Visa AS confirms
6. Show options
7. User selects Withdraw
8. Ask for desired amount
9. User enters amount
10. ATM requests limit
11. Visa AS reports limit
Hide on print!
12. ATM checks if under limit
13. ATM returns card
secondary
14. User takes card
15. ATM issues banknotes
<< actor>>
Visa AS
16. User takes money
User Intention
System responsibility

16. Use Case Bodies: multiple paths
The interaction doesn’t always go the same way!
User might enter the wrong PIN the first time.
The card might be invalid
The account may be over its limit …
Description of the interaction must have multiple paths
“Standard” successful path
Alternatives, where something unexpected happens
Errors, where something goes wrong and the interaction fails.

17. Use Case Bodies: multiple paths
Each sequence from beginning to an end state is a “scenario” of what can happen.
Main success sequence leads to the normal end where the interaction succeeds
Alternatives have unexpected events, but also lead to success
Error sequences lead to failure
sequences
error end
normal end
beginning
error end

18. ATM: Alternative/Error sequences
What are some of the alternative/error sequences?
Pin entry error (temporarily – 1 or 2 times)
Pin entry error (conclusively – 3 times)
Money requested > daily withdrawal amount
Card not taken
Money not taken
<< actor>>
Visa AS
secondary
Withdraw money using a visa card
Cardholder

19. ATM: Alternative Sequences: Pin Entry Error
A1: Pin entry error (temporarily – 1 or 2 times)
Withdraw Money Using Visa Card (sequence A1)
(Actors: Cardholder, Visa AS)
Same as main
success
scenario
1. User inserts card
2. Request PIN
3. User enters PIN
4. Request authorisation
5. Visa AS rejects
6. Verify 1st/2nd attempt
7. Go to M.2
M.2 = step 2 of the main success scenario

20. ATM: Alternative Sequences: Pin Entry Error
A1: Pin entry error (temporarily – 1 or 2 times)
A1 starts at step 4 of the main success scenario
Withdraw Money Using Visa Card (sequence A1)
(Actors: Cardholder, Visa AS)
1. User inserts card
2. Request PIN
3. User enters PIN
4. Request authorisation
5. Visa AS rejects
6. Verify 1st/2nd attempt
7. Go to M.2

21. Exercise
Make alternative scenarios for the other cases in the “Withdraw Money (Visa)” use case:
Pin entry error (conclusively: after 3 attempts)
Money requested > daily withdrawal amount
Card not taken
Money not taken
Withdraw Money Using Visa Card (sequence A2)
(Actor: Cardholder, Visa AS)

22. Use Case Role-Play How can you check use cases?
Three people read out the card
One person for each actor
Third for the system
Other team members listen
Does the use case make sense?
Does each participant have all the information they need, when they need it?