4.1 Basics of Use Cases

Systems respond to external signals by carrying out some desired activity, often with varying outcomes depending upon the system's state. Each desired activity is a functional requirement, such as:

• A customer can order a book by selecting a book number and quantity.

• A customer checks out an open order by entering the credit card number and shipping information.

• The credit card company approves or declines a charge.

• If the customer's credit card charge is approved, the requested items are packed and shipped to the customer.

Use cases are a tool for organizing system requirements by understanding the interactions between the actors that make a request and the responses, or activities, made by the system. (These terms were first defined in [1].)

4.1.1 Actors

Definition: An actor is a role played by an external entity that requires something from the system in one or more interactions with the system.

Roles played by people are the most obvious actors. In an online bookstore we have obvious roles such as:

Organizations can also be actors:

The use case diagram's value is like a table of contents it provides a graphical overview of the actors and use cases. To quote Alistair Cockburn, "If you spend much time studying and worrying about the graphics and the relations, you are expending energy in the wrong place."[2]

Similarly, because "time" is not a person or organization, it is possible to argue that time is not an actor, or that it's ridiculous to model time as a stick figure. Practically speaking, this is about as useful as arguing about how many angels can dance on the head of a pin. It really makes no difference. Invent a clock symbol; use a stick figure; don't show the timer.

Sometimes there may be situations where different actors may all request the same activity. For example, a delivery person delivers the order to the customer, but the dispatcher notifies the system. Who is the actor? The delivery person? The dispatcher? In this case, an effective strategy is to abstract away the mechanism and focus on the eventual source of the request, in terms of the role, in this case the customer.

People and organizations are not the only actors. Use cases may be initiated by the expiration of a delay, or the arrival of an external signal that signals some absolute time. For example, the store requires that an order more than five days old that hasn't been checked out be automatically canceled and deleted from the system. In this example, no active user of the system is initiating the use case. Instead, a timer is set when the order is first made and canceled when the order is checked out. The timer is the actor and the expiration of the timer initiates the use case.

4.1.2 Use Cases

Definition: A use case specifies an interaction between the system and one or more actors together with the activities performed by the system.

For example, in the online bookstore, customers start orders, add and remove items, change the quantity of items, and cancel orders. We may represent this graphically, using a stick figure for an actor and an oval for a use case, as shown in Figure 4.1.

Figure 4.1. Use Case Diagram for the Online Bookstore

We name an activity so it does not include the name of the actor. Hence, we prefer Order Merchandise over Customer Orders New Merchandise.

This naming scheme has the advantages of reducing redundancy (why state the actor twice?) and flexibility (other actors can start a new order).

Consequently, any time a single use case is referred to by more than one actor, the activity's behavior is the same regardless of the actor. If that is not the case, we have distinct activities that must also be named differently. So one oval pointed to by two actors is different from two ovals, as in Figure 4.2.

Figure 4.2. Different Use Cases for Different Actors

We have also found it useful to represent the use case diagram as a table, as shown in Figure 4.3

Figure 4.3. Use Cases Listed as a Table

4.1.3 External Signals

A line to a use case shows the initiating actor. The actor does something or requests something from the system and so is seen as a source of an external signal that initiates the activity. The system itself receives the external signal to inform it of the request to carry out the activity.

External signals often carry data, say, the book number and quantity to restock the product. These data values act as parameters, as shown in Figure 4.4.

Figure 4.4. External Signals with Their Parameters

Real-Time Systems

In many embedded and real-time systems, we don't have "users" in the same way that business systems do. In an elevator control system for example, a passenger may well know that he wants to go a particular floor, but when it comes to organizing requirements into use cases, an ordinary elevator passenger is not likely to be much help. Instead, we will find our users in the various experts in the problem space: mechanical engineers, hardware engineers, and so on.

Similarly, we will find that use cases are not always initiated by people but also by devices. An actor is anything that interfaces ot interacts with the system. People, machines, external systems, and sensors are all candidate actors.

For example, the use cases for an elevator might include:

Note that the Passenger actor is acting as a surrogate for external devices (e.g., buttons and sensors) that actually initiate the use case. This is similar to the technique for managing the user interface in IT systems.

In real-time systems, the external signal may be a signal (a control value), the arrival of data values, a data item reaching a value (position of the elevator reaching a floor), or the expiration of a timer (either absolute or relative).

There may be computation involved in recognizing the external signal. For example, the external signal may be the result of a comparison of values, such as the position and speed of the elevator. This comparison is carried out by an event recognizer. For system engineering purposes, however, it is worthwhile to note the requirement for an event recognizer and any additional communication required with actors.

Similarly, if the only way to know whether a condition is true is to examine the actor, then the system may need to track the state of an actor, or even interrogate the actor periodically. Again, these interfacing solutions are properly system-engineering issues, not requirements. They should be noted, and not allowed to obscure the essentials of the use case.

The way in which the system becomes aware of the external signal is not relevant to the essential requirements of the application, so it should not appear as part of the use case. This formulation effectively separates the interfacing technology, the user interface, from the problem at hand.

Whatever you do, do not model every field on some screen as a separate use case. Exactly how those data values were accumulated is not relevant. Likewise, if a particular UI design requires stepping through multiple windows and menus, do not treat each of these elements as its own use case.

Instead, at some point, a group of related data items are ready and confirmed by the actor. Treat the entire unit as a single external signal that starts the activity.

It is helpful to note any proposed interfacing solutions as part of a description of the external signal, but these possible solutions should not be allowed to obscure the essentials of the use case.