Use Case Tutorial (1 of 4)

In this next series of blog entries we focus on defining use cases by starting with simple examples and working our way through more sophisticated use cases.  In this blog, we identify the core part of a use case, which identifies the interaction of the user and system in a series of ordered steps.  The next blog will focus on use case diagrams and their relationship to use cases.

Use cases are concerned with the interaction between each actor and the system.  At the core of every use case is a conversation or dialog that occurs between an actor and the system.  All interactions with the system involve us providing the system with inputs and the system providing us with outputs; or we could simply say that when we input information into the system that we are ‘telling’ it something and that when the system outputs something it is ‘telling’ use something.

Let's focus on the core of the interaction between the actor and system before we investigate more complex issues in use cases.  In future blogs we will get to alternate execution paths, screen shots, or data validation.  For now assume that no mistakes will be made.

A complete dialog (not a use case) for the withdrawal from an ATM might look as follows:

Simplified Dialog

This dialog can be simplified when we recognize that when the ATM is asking for something the user needs to provide it for the withdrawal process to be successful.  Clearly there are times where users do not provide input on time (if at all), however, let’s deal with these exceptional cases later.  If we assume that every simple request by the ATM will be provided by the user, we now get the following dialog:

Steps 4, 8, and 10 are requests for simple information that can be selected from a list or entered as a single text.  This will not change the next action in the dialog and therefore these can be collapsed into a single step with the user response.

What is interesting to note is that we could not collapse steps 6/7 and steps 9/10 of the original use case into a single step.   In step 6, the ATM presents the list of transactions and asks the user to select one.  Clearly step 5. would be different if the user had selected ‘display balance’.  Just as in step 9, when the user is asked if they want to do another transaction the answer will determine if the next step is 3 or step 11.

In reality, we have two use cases here: the first one is the main loop of the ATM that authenticates the user (Authenticate User) and determines the transaction that he wants to do, and the second one is the withdraw money (Withdraw Money) use case.

Use Case: Authenticate User

The key thing to see in the Authenticate User use case is that we only diagram inputs from the user (i.e. arrow left to right) when the user is providing an input that will alter the flow of the use cases or invoke another use case.

Use Case: Withdraw Money

With most of the dialog now in the Authenticate User use case, we see that the withdraw money use case is very small.

Summary

• At its core a use case is a dialog that occurs between an actor and a system. 
• We can break a dialog into one or more use cases by identifying the places in the dialog where  user input alters the flow of a use case or invokes another one

Next part (2 of 4)

• What is an actor?
• What is a use case diagram?
• Why a collection of use cases provides project scope.