Use Case Tutorial (2 of 4)

In the previous blog we explained how the core of a use case is a textual description of the dialogue between an actor and the system.

In this blog entry, we will cover:

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

 What is an actor?

An actor in a use case represents a role in the system and not a specific user.  In the case of an ATM, let us look at the following users:

• Bob who does not work at a bank
•  Jill who works as a branch manager in the bank
•  Ted who is a bank employee that puts cash in the ATM and collects the envelopes

All three of these individuals can be users of the ATM; however, they all have the same role as each other of a Customer when they are interacting with the ATM to withdraw money.

Users are concrete, actors are abstract; when any of the individuals above access the ATM they all have the same privileges and characteristics as far as the withdraw money use case goes.

Actors are roles.  A role is a set of actions that you can access to accomplish your goals, when people are using the ATM they all have the same role.

Now Ted may have additional use cases that he can interact with when he is in the role of someone who is provisioning the ATM with cash and collecting the envelopes.  However, that role is distinct from the role of a Customer.

What is a use case diagram?

The simplest use case diagram shows a relationship between each role in the system and the use cases that they can access.  In the previous blog, we established that a Customer can interact with two use cases: 1) Authenticate customer, and 2) Withdraw money.

Some use cases for the customer could be:

• Deposit money
• Transfer money from one account to another
• Get statement
• Change PIN
• Buy stamps

Some use cases for the ATM Maintainer could be:

• Deactivate ATM
• Activate ATM

With these additional use cases the ATM diagram would look as follows:

Note: Not all ATMs in North America provide the following use cases (but there are some that do J):

• Change PIN
• Get statement
• Buy stamps

Why a collection of use cases provides scope

By definition the core of a use case is a dialogue between an actor and the system and as such is functional and specifies the behavior of the system.  A collection of use cases is essentially the core of a functional specification.

If we were designing a new ATM, we might partition the system as follows:

We may decide that in our first project we will design the system to have only the use cases above in blue, and that the use cases in yellow will be done in a later phase of the system.  If we are executing our project and it looks as if the scope is too large, we can take an entire use case, say Transfer money from one account to another and move it into a later phase.

From a project management standpoint a project's scope is completely defined by the use cases that are to be developed.

Summary

• An actor is a role, and all users with that role will have the same interaction with a use case. 
• A use case diagram shows us which roles can access which use cases
• A project is a set of use cases which provides a complete scope definition 

Next part (3 of 4)

• What additional information should be included in the use case body?
• What additional meta-information should be included in a use case?