What is a Use Case?

Use Case

A use-case instance is a sequence of actions a system performs that yields an observable result of value to a particular actor.

A use-case defines a set of use-case instances.

Topics

Explanation

There are several key words in this definition:

Use-case instance. The sequence referred to in the definition is really a specific flow of events through the system, or an instance. Many flow of events are possible, and many may be very similar. To make a use-case model understandable, you should group similar flows of events into one use-case. Identifying and describing a use case really means identifying and describing a group of related flows of events.
System performs. This means that the system provides the use case. An actor communicates with a use-case instance of the system.
An observable result of value. You can put a value on a successfully performed use case. A use case should make sure that an actor can perform a task that has an identifiable value. This is very important in determining the correct level or granularity for a use case. Correct level refers to achieving use cases that are not too small. In certain circumstances, you can use a use case as a planning unit in the organization that includes the actor.
Actions. An action is a computational or algorithmic procedure; it is invoked either when the actor provides a signal to the system or when the system gets a time event. An action may imply signal transmissions to either the invoking actor or other actors. An action is atomic, which means it is performed either entirely or not at all.
A particular actor. The actor is key to finding the correct use case, especially because the actor helps you avoid use cases that are too large. As an example, consider a visual modeling tool. There are really two actors to this application: a developer - someone who develops systems using the tool as support, and a system administrator - someone who manages the tool. Each of these actors has his own demands on the system, and will therefore require his own set of use cases.

The functionality of a system is defined by different use cases, each of which represents a specific flow of events. The description of a use case defines what happens in the system when the use case is performed.

In an automated teller machine the client can, for instance, withdraw money from an account, transfer money to an account, or check the balance of an account. These functions correspond to flows that you can represent by use cases.

Each use case has a task of its own to perform. The collected use cases constitute all the possible ways of using the system. You can get an idea of a use-case task simply by observing its name.

How to Find Use Cases

Following is a set of questions that are useful when identifying use cases:

For each actor you have identified, what are the tasks in which the system would be involved?
Does the actor need to be informed about certain occurrences in the system?
Will the actor need to inform the system about sudden, external changes?
Does the system supply the business with the correct behavior?
Can all features be performed by the use cases you have identified?
What use cases will support and maintain the system?
What information must be modified or created in the system?

Use cases that are often overlooked, since they do not represent what typically are the primary functions of the system, can be of the following kind:

System start and stop.
Maintenance of the system. For example, adding new users and setting up user profiles.
Maintenance of data stored in the system. For example, the system is constructed to work in parallel with a legacy system, and data needs to be synchronized between the two.
Functionality needed to modify behavior in the system. Example would be functionality for creating new reports, not only hard code a set of specific reports on data stored in the system.

If you have developed a business use-case model and a business object model, see also Concepts: Going from Business Models to Systems.

How a Use Case Evolves

In early iterations in elaboration, only a few use cases (those that are considered architecturally significant) are described in any detail beyond the brief description. You should always first develop an outline of the use case (in step-by-step format) before delving into the details. This step-by-step outline should be your first attempt at defining the structure of the flow of events of the use case (see Flow of Events - Structure below). Always start with the basic flow of the use case. Once there is some agreement on the outline of the basic flow, you can add what the alternative flows should be in relation to the basic flow.

Towards the end of elaboration, all use cases you plan to describe in detail should be completed.

Are All Use Cases Described in Detail?

There will often be use cases in your model that are so simple that they do not need a detailed description of the flow of events, a step-by-step outline is quite enough. The criteria for making this decision is that you don't see disagreement among user kind of readers on what the use case means, and that designers and testers are comfortable with the level of detail provided by the step-by-step format. Examples are use cases that describe simple entry or retrieval of some data from the system.

The Scope of a Use Case

It is often hard to decide if a set of user-system interactions, or dialog, is one or several use cases. Consider the use of a recycling machine. The customer inserts deposit items, such as cans, bottles, and crates, into the recycling machine. When she has inserted all her deposit items, she presses a button, and a receipt is printed. She can then exchange this receipt for money.

Is it one use case to insert a deposit item, and another use case to require the receipt? Or is it all one use case? There are two actions, but one without the other is of little value to the customer. Rather, it is the complete dialog with all the insertions, and getting the receipt, that is of value for the customer (and makes sense to her). Thus, the complete dialog, from inserting the first deposit item, to pressing the button and getting the receipt, is a complete case of use, a use case.

Additionally, you want to keep the two actions together, to be able to review them at the same time, modify them together, test them together, write manuals for them and in general manage them as a unit. This becomes very obvious in larger systems.

How Use Cases Are Realized

A use case describes what happens in the system when an actor interacts with the system to execute the use case. The use case does not define how the system internally performs its tasks in terms of collaborating objects. This is left for the use-case realizations to show.

Example:

In the telephone example, the use case would indicate - among other things - that the system issues a signal when the receiver is lifted and that the system then receives digits, finds the receiving party, rings his telephone, connects the call, transmits speech, and so on.

In an executing system, an instance of a use case does not correspond to any particular object in the implementation model (for example, an instance of a class in the code). Instead, it corresponds to a specific flow of events that is invoked by an actor and executed as a sequence of events among a set of objects. In other words, instances of use cases correspond to communicating instances of implemented objects. We call this the realization of the use case. Often, the same objects participate in realizations of more than one use case. For example, both the use cases Deposit and Withdrawal in a banking system may use a certain account object in their realization. This does not mean that the two use cases communicate, only that they use the same object in their realization.

You can view a flow of events as consisting of several subflows, which taken together yield the total flow of events. You can reuse the description of a subflow in other use cases' flow of events. Subflows in the description of one use case's flow of events may be common to those of other use cases. In the design you should have the same objects perform this common behavior for all the relevant use cases; that is, only one set of objects should perform this behavior, no matter which use case is executing.

Example:

In an automated teller machine system the initial subflow is the same in the flow of events of the use cases Withdraw Money and Check Balance. The flow of events of both use cases start by checking the identity of the card and the client's personal access code.

A Use-Case has Many Possible Instances

A use-case instance can follow an almost unlimited, but enumerable, number of paths. These paths represent the choices open to the use-case instance in the description of its flow of events. The path chosen depends on events. Types of events include:

Input from an actor. For example, an actor can decide, from several options, what to do next.

Example:

In the use case Recycle Items in the Recycling-Machine System the Customer always has two options: hand in still another deposit item or get the receipt of returned items.

A check of values or types of an internal object or attribute. For example, the flow of events may differ if a value is greater or less than a certain value.

Example:

In the use case Withdraw Money in an automated teller machine system, the flow of events will differ if the Client asks for more money than he has in his account. Thus, the use-case instance will follow different paths.

Concurrency of Use-Case Instances

Instances of several use cases and several instances of the same use case work concurrently if the system permits it. In use-case modeling, you can assume that instances of use cases can be active concurrently without conflict. The design model is expected to solve this problem, because use-case modeling does not describe how things work. One way to view this is to assume that only one use-case instance is active at a time and that executing this instance is an atomic action. In use-case modeling, the "interpreting machine" is considered infinitely fast, so that serialization of use case instances is not a problem.

� Rational Software Corporation 1998

Rational Unified Process 5.1 (build 43)