atm use case samples
TRANSCRIPT
Use Cases:The Good, The Bad, and The Ugly
(and what you can do about it)
Hadar [email protected]
In cooperation with:Debra RichardsonThomas AlspaughThomas Standish
And the ROSATEA group at UCI
Hadar Ziv / [email protected]
Hadar Ziv / [email protected]
Presentation Outline Use cases are good
â Quantum leap in software requirements specification (in principle)
Use cases are badâ Difficult, time-consuming, and error-prone (in practice)
Use cases can get uglyâ Use case mistakes, misuse, and even âabuse casesâ
What you can do about itâ Review âTop Tenâ lists (practical advice)
â Consider Goals, Scenarios, Episodes, Concerns, and Aspects(research work in progress)
Hadar Ziv / [email protected]
Use Cases: The GoodUse cases are a simple and powerful way todefine requirements for software behavior
Order tickets Kiosk User
Actor Use Case
Withdraw money Bank customer
Actor Use Case
Hadar Ziv / [email protected]
The Use-Case Model
â A use-case model illustrates» The systemâs intended functions (use cases)
» Its surroundings (actors)
» Relationships between use cases and actors (use case diagram)
â The same use-case model used in requirements» Is used in analysis, design, and test
» Serves as a unifying thread throughout system development
The most important role of a use-case model is to communicate the systemâs functionality and behavior to the customer or end user
The most important role of a use-case model is to communicate the systemâs functionality and behavior to the customer or end user
Hadar Ziv / [email protected]
A Simple ATM Use Case Model
BankSystem
BankCustomer
Deposit Money
Withdraw Money
Transfer Money(Between Accounts)
ATMATMATM
Hadar Ziv / [email protected]
Use Case Details
A use case is a textual or graphical description ofâ Major functions the system will perform for its actorsâ Goals the system achieves for its actors along the way
A use case description should containâ Use case nameâ Basic course or path of actionâ Alternative paths and error/exception conditions
Scenariosâ Describe typical uses of the system as narrativeâ Correspond to a single path or flow through a use caseâ A use case is an abstraction or container of a set of related
scenarios
Hadar Ziv / [email protected]
Use Cases: The Bad and The Ugly
If you donât fully understand the ins and outs of use casesâ It is easy to misuse them or turn them into âabuse casesâ
Ellen Gottesdienerâ âTop Ten Ways Project Teams Misuse Use Cases â and How to Correct
Them.â The Rational Edge, June 2002 (Part I), July 2002 (Part II). Martin Fowler
â âUse and Abuse Cases.â Distributed Computing, April 1998. Doug Rosenberg
â âTop Ten Use Case Mistakes.â Software Development, February 2001. Susan Lilly
â âHow to Avoid Use Case Pitfalls.â Software Development, January 2000. Kulak and Guiney
â âUse Cases: Requirements in Context.â Second Edition, Addison-Wesley2003.
Hadar Ziv / [email protected]
Ten Misguided Guidelines (Gottesdiener)
Donât bother with any other requirements representationsâ Use cases are the only requirements model youâll need!
Stump readers about the goal of your use caseâ Name use cases obtusely using vague verbs such as do or process
Be ambiguous about the scope of your use casesâ There will be scope creep anyway, so you can refactor your use
cases later Include nonfunctional requirements and UI details in your use-
case text Use lots of extends and includes in your initial use-case
diagramsâ This allows you to decompose use cases into itty bitty units of
work
Hadar Ziv / [email protected]
Ten Misguided Guidelines (Contâd)
Donât be concerned with defining business rulesâ youâll probably remember some of them when you design and
code Donât involve subject matter experts in creating, reviewing, or
verifying use casesâ Theyâll only raise questions!
If you involve users at all in use case definition, just âdo itââ Why bother to prepare for meetings with the users?
Write your first and only use case draft in excruciating detailâ Why bother iterating with end users when they donât even know
what they want Donât validate or verify your use cases
â That will only cause you to make revisions and do more rework!
Hadar Ziv / [email protected]
Top Use Case Mistakes (Rosenberg)
Donât write functional requirements instead of usage scenario textâ Requirements are generally stated in terms of what the system shall doâ Usage scenarios are user actions and corresponding system responses
Donât describe attributes and methods rather than usageâ Donât include too many presentation detailsâ Donât detail data-entry fields on user screen
Donât write the use cases too terselyâ Must describe user actions and system responses in detailâ Err on the side of too much detail in user documentation
Donât completely ignore the user interfaceâ Discuss features that allow the user to tell the system to âdo somethingâ
Donât avoid explicit names for boundary objectsâ Name boundary objects explicitly in the use case text
Hadar Ziv / [email protected]
Top Use Case Mistakes (Contâd)
Donât write in a passive or not the userâs voiceâ Should be written from the userâs perspectiveâ Present-tense verb phrases in active voice
Donât ignore system behaviorâ Include what the system does in response to user actions
» Creates new objects» Validates user input» Generates error messages
Donât omit text for alternative courses of actionâ Basic course of action easier to identify and writeâ But alternate courses are critical for correctness and completeness;
robustness Donât focus on things outside the use case
â Such as how you get there or what happens afterwardsâ Watch out for âlong formâ use case templates!
Donât spend a month deciding whether to use includes or extends
Hadar Ziv / [email protected]
What Can Be Done About It?
Question everything, even the basic definitions ofrelationships between Use cases to Goals (1:1?)
Use cases to Scenarios (1:m?)
Goals to Scenarios?
All of the above to design and implementation???
Hadar Ziv / [email protected]
Use Cases and Goals
Use cases correspond to goalsâ A goal is a âdesired state of affairsâ (Schank/Wilensky)
Goals have nontrivial structure and relationshipsâ At least hierarchical but could be more complexâ We need better understanding and analysis of goals
ATM exampleâ High-level stakeholder goals
» Increase the bankâs business success» Increase market share» Provide greater access to banking services
â Low-level goals» Terminate a userâs session» Authenticate a userâs ATM card and PIN» Withdraw $200 cash from userâs account
Hadar Ziv / [email protected]
(Partial) Requirements Goal Graph
increase Bankâsbusiness success
increase profitability
increase productivity increase market share
invest in automation
automate human tellerbanking servicesusing AutomatedTeller Machines
(or ATMs)
increase customer satisfaction
provide greater accessto banking services
moreavailable
hours
moreavailablelocations
safeand
secure
convenientand
easy to useminimize total
system developmentand deployment costs
Hadar Ziv / [email protected]
Use Cases and Scenarios
Use cases contain a family of related scenariosâ Within a single use case, scenarios may have nontrivial structureâ Across use cases, scenarios are often referred to, reused, or linked
in nontrivial waysâ Often, containment becomes confinement!
Scenariosâ A sequence of events that corresponds to a purposeful use of a
systemâ âPurposeful usesâ are characterized by associated goals
Episodesâ Subsequences of events contained within a surrounding scenarioâ Correspond to the pursuit of subgoalsâ Example episodes: Login, Logout, Authenticate
Hadar Ziv / [email protected]
Goals and Scenarios
Software requirementsâ Involve many goals at many different levels of
abstraction/detail» âprovideâ goals» âpreventâ goals
Goals and Scenariosâ A high-level âprovideâ goal typically corresponds to a
single usage scenarioâ A low-level âprovideâ or âpreventâ goal typically
corresponds to a single plan of action or âepisodeââ Therefore, a usage scenario consists of multiple
episodes addressing multiple goals!
Hadar Ziv / [email protected]
A Family of ATM Scenarios
Insert ATM Card
Give PIN to AccessYour Account
WithdrawCash
MakeDeposit
FindBalance
LogOff
ATM MachineReturns Your ATM Card
Choose aTransaction
Hadar Ziv / [email protected]
A Family of ATM Scenarios (Contâd)1. "Login Episode"2. The ATM presents, in English, a choice of transactions the customer may perform. 3. Iteration *:
1. Alternatives: 1. Alternative:
1. The customer selects "Withdraw cash". 2. "Withdraw Cash Episodeâ 2. Alternative: 1. The customer selects "Make deposit". 2. "Deposit Funds Episodeâ 3. Alternative: Guard: Customer has more than one account.
1. The customer selects "Transfer funds". 2. "Transfer Funds Episode" 4. Alternative: 1. The customer selects "Balance". 2. "Balance Episode" 2. ATM presents, in French, a choice of transactions the customer mayperform. 4. The customer selects "Done". 5. The ATM ejects the ATM card and beeps until the customer withdraw it. 6. The customer withdraws the card.
Hadar Ziv / [email protected]
A Sample Login Episode
1. The customer inserts an ATM card into an ATM.
2. The ATM presents a choice of languages.
3. The customer selects English.
4. The ATM prompts for a PIN.
5. The customer enters the PIN for his/her ATM card.
Hadar Ziv / [email protected]
A Sample Withdraw Cash Episode
1. The customer selects "Withdraw cash".
2. The ATM presents the accounts from which the customer can withdraw.
3. The customer selects "Checking".
4. The ATM prompts for an amount to withdraw.
5. The customer enters $200.
6. The ATM dispenses the requested amount of cash.
7. The ATM prints a receipt.
8. The ATM presents a choice of transactions the customer may perform.
Hadar Ziv / [email protected]
Example of Scenario Goal Analysis:g2: Use ATM to
withdraw $200 cashfrom your checking
account
g2a: Get access toATM banking
services in yourlanguage
g2b: Use ATMâsCash Withdrawal
service to withdraw$200 in cash
g2c: Finish ATMsession properly
g2b1:choose
transactionâWithdraw
Cashâ
g2b2:designateâCheckingAccountâ to
use forwithdrawal
g2b3:specify$200 as
amount towithdraw
g2b4:collect cash
& receiptdispensedby ATM
{6,7} {8,9} {10,11} {12,13}
g2a1:insert
ATM card
g2a2: selectFrench as
UI language
g2a3: enterPIN for
ATM card
{1} {2,3} {4,5}
g2c1:choose
transactionâDoneâ
g2c2:collect ATMcard frommachine
{14,15} {16,17}
Hadar Ziv / [email protected]
ATM AND/OR Goal Analysis
Access andAuthorization
Goals
AND
grant access toqualified users
deny access tounqualified users
Allow users whohave been grantedaccess to perform
authorizedtransactions
OR
make depositD
find currentaccount balance
B
withdraw cashamount W
credit deposit Dto balance BB â B + D,
tell customerwhen B is
available forwithdrawal
debit withdrawalfrom balance B
B â B - W
withdrawalpermitted if
AND
W †Balance B W †Bankâs dailywithdrawal limit L
W †ATMâscash C available
to dispense
GOAL G1
GOAL G4 GOAL G2GOAL G3
Hadar Ziv / [email protected]
Concerns and Aspects
Goals correspond to concernsâ âprovideâ concerns
» Withdraw money, Deposit money, Transfer moneyâ âpreventâ concerns
Aspects correspond to cross-cutting concernsâ Typically âpreventâ concerns
» User access/authentication, data integrity, transaction integrity
A requirements-level usage-scenarioâ Will be written as a collection of episodesâ Will be designed to address multiple concernsâ Will be implemented using âregularâ code + aspects for
the cross cutting concerns
Hadar Ziv / [email protected]
Use Cases and Aspects
According to Jacobson,â All use cases are extensions to the ânull systemâ
He sees a relationship between use cases and aspects, suchthatâ aspects â extensionsâ join points â extension points
AOP allows us toâ Separate use case extensions all the way down to codeâ Compose back extensions before execution
Thus, AOP supports extensionsâ Ivar Jacobson, âUse cases and aspects â Working together.â
Hadar Ziv / [email protected]
Summary and Recommendations
Be aware of âtop tenâ lists of use case mistakes,misuse, and âabuse casesââ Beware each article has a different list!â Beware articles provide different, sometimes
conflicting advice! Consider goals and scenarios
â When writing use cases or instead of writing themâ Perform goal analysis and goal decompositionâ Perform scenario analysis and scenario composition
(from episodes)â Design and implement using concerns and aspects (for
cross-cutting concerns)