Post on 06-May-2015
Improving Use Cases How to evaluate and upgrade use cases
Use cases should always be reviewed with an eye toward improvement
Guidelines fall into three main categories
¡ General ¡ Scenario style ¡ Scenario content
We'll use the nomenclature proposed by Camille Salinesi of the University of Paris
Let's start with the five general guidelines ¡ These deal with the use
case as a whole
GG1: Identify every use case by a goal statement ¡ Structured as a predicate composed of a verb
and complements
GG2: Use a template ¡ "Use cases are not just composed of scenarios;
employ the Use Case template that is given to you to characterize your Use Cases with all the Use case attributes"
GG3: Describe each scenario separately
A use case is always composed of several scenarios that describe alternate ways to try to achieve the goal
GG4: Be consistent when writing scenarios ¡ Write all scenarios in a consistent way in their ¡ Terminology ¡ Style ¡ Contents
GG5: Validate use cases and try to discover other scenarios
¡ Use a checklist with these and other guidelines
¡ Then analyze them to discover other use cases and scenarios
The ten scenario style guidelines
They deal with ¡ Flows of actions (SG1 – SG6) ¡ Initial and final states (SG7) ¡ Terminology (SG8 – SG10)
SG1: Use present tense and active voice ¡ Scenarios are action clauses ¡ They should be written in an explicit and
complete way
Wrong Better
The personal identification number is checked
The ATM engine checks the personal identification number
Check the personal identification number
The ATM engine checks the personal identification number
SG2: Avoid time, duration, location, manner and so on ¡ Scenarios never include circumstances ¡ These details tend to shape the solution
prematurely
Wrong Better
The ATM engine checks the personal identification number in less than thirty seconds
The ATM engine checks the personal identification number
SG3: Only describe actions that should happen
Wrong Better
The ATM should not eject the cash to the user
Move the sentence to an alternate scenario
SG4: Describe in chronological order
¡ sadf
Wrong Better
The user's account is updated after it has been properly checked
The ATM checks the user's account. The bank consortium updates the user's account.
SG5: Duplicate sequences only if they involve different objects
Wrong Better
The ATM engine checks the validity date and serial number
The ATM engine checks the validity date The ATM engine checks the serial number … or … For each card attribute, the ATM engine checks the card attribute
SG6: Avoid 'else'
Wrong Better
If the personal identification number is correct, then the ATM displays a prompt for amount to the user, otherwise the ATM ejects the card to the use
The ATM engine displays a prompt for amount to the user … and then move the card ejection to an alternate scenario
SG7: Don't describe state within a scenario ¡ Start and finish states should have their own
sections
Wrong Better
The user inserts a card into the ATM but the ATM is not ready to serve, so it ejects the card to the user
Create a use case called "Withdraw cash from a non-ready ATM"
SG8: Be consistent; don't use synonyms or homonyms ¡ Synonym – Two words that have the same
meaning ¡ eg. client and customer ¡ Pick one and stick to it
¡ Homonym – One word with two meanings ¡ eg. user – Is this the employee or the customer? ¡ Use the different words
Wrong Better
The user enters his PIN The user approves the transaction The client removes the cash
The customer enters his PIN The employee approves the transaction The customer removes the cash
SG9: Avoid ambiguity ¡ Avoid anaphoric references like 'he', 'she', or 'it' ¡ Anaphora – a word whose reference depends
on context ¡ Use nouns rather than pronouns
Wrong Better
The customer enters his PIN The ATM engine checks to make sure it is valid
The customer enters his PIN The ATM engine validates the PIN
SG10: Avoid making specific references to the scenario model ¡ Don't refer to other scenarios unless you do so by
name
Wrong Better
The customer enters his PIN The ATM engine validates the PIN Cash is withdrawn in a normal way
What is a 'normal way'? Go ahead and describe in detail what that means … or … Cash is withdrawn according to UC117 Withdraw Cash
The nine content guidelines are what should be in the
scenarios themselves
CG1: A scenario describes only one flow ¡ Each scenario is one possible way to reach the
goal of the use case ¡ If there are others, they are different scenarios in
the same use case
Wrong Better
If the card is valid do ABC. If not, do XYZ.
Split into two scenarios
CG2: Interactions have a name, two agents and one object
Try to use one of these templates: ¡ <Agent> <’take’ Interaction > <Object> from <Agent> ¡ <Agent> <’give’ Interaction > <Object> to <Agent> ¡ <Agent> <’move’ Interaction > <Object> from <Agent> to <Agent> ¡ <Agent> <’internal’ Interaction> <Object> ¡ <Agent> <Interaction> <Agent>
Wrong Better
The user inserts his card The PIN is checked
The user inserts his card into the ATM The ATM checks the PIN
CG3: A scenario describes sequentially ordered interactions ¡ In other words, it tells a story ¡ Don't know why this isn't #1 – the most basic
description
Wrong Better
The user types a PIN into the ATM which checks it
The user types a PIN into the ATM The ATM checks the card validity
CG4: Repetitions are okay ¡ Use this formula: ¡ Repeat <interactions> until <some condition>
Wrong Better
The user types a PIN in the ATM, the ATM checks that the personal identification number is correct. If the personal identification number is incorrect, the user types again the personal identification number and so on.
The user types a PIN in the ATM, and the ATM checks that the personal identification number is correct until the personal identification number is correct, or the user has typed three incorrect personal identification numbers
CG5: Constraints are okay ¡ As long as they're expressed like this ¡ If <some condition> then <interactions>
Wrong Better
The ATM checks the card validity If the card is not valid, then the ATM ejects the card to the user, else the ATM displays a prompt for a personal identification number to the user
The ATM checks the card validity If the card is valid, then the ATM displays a prompt for a personal identification number to the user … and put the 'else' case in another scenario
CG6: Interactions can be concurrent ¡ Word it like this: ¡ <Interactions> meanwhile <another interaction>
Wrong Better
The ATM engine presents choices to the customer The ATM engine calculates the customer's available balance (Implies asynchronous activity)
The ATM engine presents choices to the customer Meanwhile the ATM engine calculates the customer's available balance
CG7: Each scenario should have start and final states ¡ If a use case has multiple start or final states, it
should be split into two use cases ¡ … or reword the states
Wrong Better
ATM has paper
(A machine can dispense cash even when it is out of paper) Customer has a card Customer has cash
CG8: All scenarios must achieve a goal. All exceptions must fail to achieve it
Wrong Better
The ATM checks the card validity. If the card is not valid, the ATM swallows the card and the user calls the ATM maintenance service
The ATM checks the card validity. If the card is not valid, the ATM swallows the card
CG9: A scenario is at only one contextual level ¡ Tougher to grasp ¡ A scenario should address only one of: ¡ contextual – flow of services among agents ¡ functional – interactions with the system ¡ physical – interactions between systems
¡ So you must know which level and make sure you stick to just one level
Wrong Better
1. Bank issues a card to a customer 2. Customer inserts card into ATM 3. ATM contacts bank to validate card
Split into two or three use cases
Conclusion ¡ All scenarios should be reviewed in order to
improve them ¡ The rules discussed give guidelines on exactly
how that can be done