ENGR 110 10:1

Use Cases 2ENGR 110 2015 ♯10

Peter AndreaeEngineering and Computer Science

Victoria University of Wellington

Copyright Rebecca Ford, Peter Andreae

ENGR 110 10:2Step 2: Identifying Actors: Static context diagrams• Shows how actors are connected to the system.

Cardholder

<< actor>>Bank IS << actor>>

Visa AS

ATM

Bank customer Maintenance operator

ENGR 110 10:3Step 3: Identifying interactions

• How does each actor use/interact with the ATM system

Actors System interactions

Type

Cardholder Withdraw money Primary

Bank customer

Withdraw money, check balance, deposit cash/cheque

Primary

Authorization systems

None (secures transactions) Secondary

Maintenance operator

Refill cash dispenser, recover lost cards, retrieve deposits

Primary

Primary actor: Uses system to achieve goal

Secondary actor: Actors that system uses in order to achieve goals

ENGR 110 10:4Use 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:1. Add primary actors

2. Add functional requirements as “use cases”

3. Map actors to use cases

4. Add system boundary

ENGR 110 10:5ATM: Use Case Diagram: 2

Cardholder

Bank customer

Maintenance operator Retrieve cheques

Withdraw money

Check balance

Deposit cheque

Deposit cash

Refill dispenser

Retrieve lost cards

Use case

Steps:

1. Primary actors

2. Use cases

3. Map actors touse cases

4. System boundary

5. Secondary actors

ENGR 110 10:6ATM: Use Case Diagram: 2

• Add the secondary actors (For simplicity, leave out the maintenance operator)

– Visa system to authorisevisa card transactions

– Bank information system towithdraw from, deposit to, check balance of account

<< actor>>Bank IS

<< actor>>Visa AS

ENGR 110 10:7ATM: Use Case Diagram: 1

Cardholder

Bank customer

Withdraw money

Check balance

Deposit cheque

Deposit cash

1. Primary actors2. Use cases3. Map actors

to use cases4. System boundary5. Secondary actors

<< actor>>Bank IS

<< actor>>Visa AS

secondary

secondary

secondary

secondary

secondary

Role

What’s the problem with this diagram?

ENGR 110 10:8Need to Distinguish Use Cases

• If a single use case could have two different sets of actors, Need to break it down.

Cardholder

Bank customer

Withdraw money using a visa card

<< actor>>Bank IS

<< actor>>Visa AS

Withdraw money using a bank card

secondary

secondary

ENGR 110 10:9An Exercise: a Library system.

You have been contracted to develop a computer system fora 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

ENGR 110 10:10ATM: Use Case Diagram

Cardholder

Bank customer

Maintenance operator

Withdraw money (visa)

Check balance

Deposit cheque

Deposit cash

Refill dispenser

Retrieve cheques

Retrieve lost cards

Withdraw money (bank)

<< actor>>Bank IS

<< actor>>Visa ASsecondary

secondary

Is this enough to tell you what’s going on in the system?

What additionaldetails do we need?

ENGR 110 10:11Use 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 aUse 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

Actor Actions

System Actions

Use Case Name(Actors’ Names)

ENGR 110 10:12Use 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.

ENGR 110 10:13System 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!

ENGR 110 10:14ATM: Use Case Body: Withdraw Money (Visa)

Withdraw Money Using Visa Card(Actors: Cardholder, Visa AS)

User Intention System responsibility

Cardholder

Withdrawmoney using a

visa card

<< actor>>Visa AS

secondary

ENGR 110 10:15ATM: Use Case Body: Withdraw Money (Visa)

Withdraw Money Using Visa Card(Actors: Cardholder, Visa AS)

User Intention System responsibility

Cardholder

<< actor>>Visa AS

secondary

1. User inserts card 2. Request PIN3. User enters PIN 4. Request authorisation

6. Show options7. User selects

Withdraw8. Ask for desired amount

9. User enters amount

5. Visa AS confirms

13. ATM returns card14. User takes card 15. ATM issues banknotes16. User takes money

12. ATM checks if under limit11. Visa AS reports limit10. ATM requests limit

ENGR 110 10:16Use 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.

ENGR 110 10:17Use 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

beginning

sequences error end

normal end

error end

ENGR 110 10:18ATM: 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

CardholderWithdraw money using a visa card

<< actor>>Visa AS

secondary

ENGR 110 10:19ATM: Alternative Sequences: Pin Entry Error

Withdraw Money Using Visa Card (sequence A1)(Actors: Cardholder, Visa AS)

A1: Pin entry error (temporarily – 1 or 2 times)

2. Request PIN

3. User enters PIN

1. User inserts card

4. Request authorisation

5. Visa AS rejects 6. Verify 1st/2nd attempt

M.2 = step 2 of the main success scenario

7. Go to M.2

Same as mainsuccessscenario

ENGR 110 10:20ATM: Alternative Sequences: Pin Entry Error

Withdraw Money Using Visa Card (sequence A1)(Actors: Cardholder, Visa AS)

A1: Pin entry error (temporarily – 1 or 2 times)

5. Visa AS rejects 6. Verify 1st/2nd attempt

7. Go to M.2

2. Request PIN

3. User enters PIN

1. User inserts card

4. Request authorisation

A1 starts at step 4 of the main success scenario

ENGR 110 10:21Exercise

• 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)

ENGR 110 10:22Use 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?