11 improving use cases

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