Date post: | 27-Dec-2015 |
Category: |
Documents |
Upload: | hannah-terry |
View: | 214 times |
Download: | 0 times |
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)