Use Cases - Alternate Courses (1 of 2)

In our previous series we explain the basics of a use case and how they can be extended with more information inside and outside the use case:

Tutorial Part	Description
1 of 4	Shows that a use case is a dialog between a role and the system
2 of 4	Define actors and show what a use case diagram is
3 of 4	Add detail inside the use case such as screens, data entry criteria, and reports
4 of 4	Add detail outside the use case showing its context with the rest of the system

This information is a good first step to being able to write use cases.  However, without the notion of alternate courses the use case it is not possible to write effective use cases.

In every dialog that an actor has with the system there are choices that must be made.  These choices occur at three distinct levels:

• Low level choices represented by a step inside the use case
• Medium level choices represented by alternate courses of activity inside the use case
• High level choices represented by other use cases

Let's take the ATM dialog extend it to show the different choices that the actor and ATM has and discuss how to address each choice from a documentation standpoint. Below we show the various possible interactions between the actor and the ATM as a UML state machine.

State A

The actor approaches the ATM and sees the welcome message.  The only choice is to either insert your card or walk away. 

The choice of walking away is NOT detectable by the ATM; therefore there is only one choice available at this time.  Therefore there is only one way to proceed from state A.

State B

The first few steps from our use case for Authenticate User from the Use Case Tutorial (1 of 4) was as follows:

1. ATM displays greeting to user and asks him to insert his card

2. ATM reads card and gets PIN from user

3. ATM presents a list of transactions and asks user to select one

4. User selects transaction

Clearly we assumed in use case step 1 above that we assumed that the card would be inserted, read and valid.  This choice represents a medium level choice because it changes the flow of the actor/system interaction for the rest of the use case.

We can call the interaction above the Basic Course of the use case.  The basic course is the sequence events which occur most frequently in the use case.  Exceptions to this sequence of events will be documented in an alternate course inside of the same use case. 

When the actor inserts their card into the ATM, now there are choices possible:

• The ATM might be unable to read the card (state E)
• The ATM is able to read the card
• The format is not the ISO/IEC 7813 format expected by an ATM (state D)
• The format is the ISO/IEC 7813 format expected by an ATM (state C)

The result of reading the card will lead to these 3 distinct states, each of which requires a different message to be shown to the actor.  Only the state where the card is recognized as an ATM card has any meaningful continuation. We can extend the dialog of the use case in the following way:

Basic course

1. ATM displays greeting to user and asks him to insert his card

2. ATM reads card and gets PIN from user

3. ATM presents a list of transactions and asks user to select one

4. User selects transaction

Alternate course: Card can not be read

1. ATM displays greeting to user and asks him to insert his card

2. ATM is unable to read the card

3. ATM displays that it can not read the card
4. ATM ejects card

Alternate course: Card not in ISO/IEC 7813 format

1. ATM displays greeting to user and asks him to insert his card

2. ATM is unable to read the card

3. ATM displays that the card is not an ATM card
4. ATM ejects card

Next Steps

While we have identified two alternate courses to cover state D and E, we have not identified what the next step is.  We need to extend the alternate courses with information on the next step for the developer.

Basic course

1. ATM displays greeting to user and asks him to insert his card

2. ATM reads card and gets PIN from user

3. ATM presents a list of transactions and asks user to select one

4. User selects transaction

Alternate course: Card can not be read

1. ATM displays greeting to user and asks him to insert his card

2. ATM is unable to read the card

3. ATM displays that it can not read the card

4. ATM ejects card

Next step: Return to step 1 of the basic course 

Alternate course: Card not in ISO/IEC 7813 format

1. ATM displays greeting to user and asks him to insert his card

2. ATM is unable to read the card

3. ATM displays that the card is not an ATM card

4. ATM ejects card

Next step: Return to step 1 of the basic course

In this case the developer simply restarts the main event loop of the ATM and goes back to showing the greeting.

This covers State C, D, and E

Next part (2 of 2)

• How to handle user input choices, state F
• How to handle the cancel button, state G
• How to handle user interaction choices, state H