We established in Part I that it is important to keep concerns separate. This is the only way to make complex systems comprehensible. Keeping concerns separate should begin right from the start during requirements. In addition, they should be modeled in a way that facilitates early validation and incremental development of the system. The use-case technique does precisely that.

Use cases are a means to specify required usages of a system. They are used to capture the requirements of a system—that is, what a system is supposed to do. When modeling the use cases of a system, you represent the users and any other external systems that may interact with the system as actors. Actors always represent entities that are outside the boundaries of the system.

The required behavior of the system is specified by one or more use cases, which are defined according to the needs of actors. Each use case specifies a unit of useful functionality that the system provides to its actors.

A use-case model contains all the use cases of a system. It is the sum of all the possible uses of a system. You depict the different use cases for a system on a use-case diagram, where a stick figure represents an actor and an ellipse represents a use case. Lines between actor use-case pairs indicate that the actor can interact with the associated use case. For our Hotel Management System, the use-case diagram is depicted in Figure 5-1. A use-case diagram specifies who can do what with the system. For example, a customer can reserve a room. Hotel counter staff can check in or check out the customer.

Figure 5-1. Use-case diagram.

For larger systems, you may partition the use-case model into various use-case packages. Each package can contain a set of use cases for a group of actors, such as for a department in a company. Alternately, you might wish to package use cases according to entities that the use cases manipulate. For example, you may have use cases to manipulate inventory entities, sales entities, and so on. A third way is according to functional areas. For example, sales can be one functional area of a system, customer relationship can be another functional area, and so on. Each use-case package should have a use-case diagram to provide an overview of the use cases contained within it.

Just as drawing classes in a class diagram does not give you code, drawing a use-case ellipse is only a small part of the use-case technique. When applying the use-case technique, you find that a significant portion of time is spent on specifying the behavior for each use case, or more specifically, the behavior of each use-case instance.

Both actors and use cases are classifiers or class-like elements in UML. Both have attributes and operations. Both are instantiable and generalizable. When you describe the behavior of the system through use cases, you follow through the execution of a use-case instance. A use-case instance is created when an actor instance initiates a use case. For example, for the Reserve Room use case, the use-case instance is created when a customer indicates that she wants to reserve a room (see Figure 5-2).

Figure 5-2. Execution of a use-case instance.

Once a use case is instantiated, a dialog between the use-case instance and its actor instances can occur as specified by the use-case specification. This continues until it is terminated as specified by the use-case specification. Just as a class instance follows through a particular path defined by its class source code, a use-case instance follows one path through the use case.

Tracing through the different execution paths of a use case is an important part of understanding what the user wants, what she wants to do with the system, and how she wants the system to respond as she interacts with it. This provides early validation of what the system needs to do.

This execution of a use case results in a use-case scenario. A use-case scenario is made up of one or more use-case flow of events. A use-case flow can be either a complete path or a segment of a path through the use case. The smaller segments allow us to focus attention on specific areas of the system behaviors and are especially useful when considering how variations are handled.

When describing a use case, you start with the simplest or the most typical scenario and trace through the sequence of events in it. We call this the basic flow. A use case has one or more basic flows depending on the number of ways the use case can be instantiated.

After describing the basic flow, you gradually describe how different variations are handled on top of the basic flows; that is, you describe them in separate use-case flows, which we call alternate flows. By keeping the descriptions separate, you prevent the basic flow from being entangled by all the variations that the use case needs to handle.

As you describe the use-case flows in a use case, you may find that some of the interaction sequences are repetitive, and you might want to factor and describe them separately. We call such use-case flows subflows.

The behavior of a use case can be specified in a number of ways depending on who the intended reader is. Today, the textual form is the most frequently used approach to specify the behavior of a use case. This form is most easily understandable by end-user representatives. Listing 5-1 provides an example of a use-case specification for the Reserve Room use case.

Listing 5-1 follows a typical use-case specification template. It has a brief description and a number of flows, which we discuss shortly. The use case also has preconditions and postconditions. They respectively indicate the circumstances in which the use case can be instantiated and the system state when the use-case instance terminates. There is also a section that describes special requirements for the use case. In this case, there are some performance requirements.

The textual specification of a use case may not adequately describe what the user representative wants. Thus, it is not uncommon that the use-case specification is supplemented with additional tables and diagrams, such as user interface descriptions and flow charts.

Let’s look at the flows in Listing 5-1 more closely. It shows one basic flow and one alternate flow for the Reserve Room use case. The basic flow describes the steps leading to a successful reservation of a room for a specified time period. Step 3 refers to the subflow Check Room Cost. We use an underline in Listing 5-1 to denote a reference. This subflow is defined later in S1 to describe the steps to choose rooms for reservation. By using subflows, you keep the basic flow less cluttered. In addition, multiple flows can reference or “use” the subflow. Thus, instead of specifying the interaction multiple times, you need to specify it only once.

Listing 5-1 shows an alternate flow, A1, that handles the case of duplicate submission of reservations. Note that the basic flow has no checks for duplicate submission or any reference to the alternate flow. All such details are in the alternate flow. Using this approach, you can keep concerns about duplicate submissions totally separate from the basic flow and localize them to the alternate flow A1. But you must somehow indicate where the behavior for handling duplicate submissions is inserted into the basic flow. This is achieved with the phrase that says, “If in step 5 of the basic flow. . . .”. Note that in general a use case specification will contain a number of alternate flows. We indicate this in Listing 5-1 through A2, ... It is important that you explore these alternatives and describe how the system should use them appropriately.

Aspect orientation applies a similar mechanism and thus provides a seamless transition when we attempt to realize a use case. We discuss more of that in Chapter 6, “Structuring Use Cases.”

The complexity of a use case is very much dependent on how many variations or scenarios it must handle. The use cases identified in Figure 5-1 may apply to a simple hotel or even to small a bed and breakfast accommodation. A sophisticated hotel chain might have the same set of use cases, but each use case will have to handle a much larger number of variations.

The ellipse notation on its own does not give any indication of the complexity of a use case. For example, Figure 5-3 illustrates the Reserve Room use case. It has no indication of how complex the Reserve Room use case is or the multitude of variations or scenarios the use case needs to handle.

Figure 5-3. Reserve Room use case using ellipse notation.

Although the ellipse is the most well-known notation for use cases, there are also other ways to display it. A use case is actually just a special case of classifiers or a stereotype of classifiers. A classifier in UML is a class-like thing—it can be instantiated, and it is generalizable. You can denote a use case using the standard rectangle notation for classifiers with an ellipse icon in the upper right-hand corner of the rectangle with optional separate list compartments for its contents, as exemplified in Figure 5-4. Figure 5-4 illustrates the Reserve Room with its flows in a compartment. This notation gives us an overall perspective of the responsibilities of a use case.

Figure 5-4. Flows as compartments.

As illustrated by the earlier Reserve Room example, each use-case flow can be a basic flow, an alternate flow, or a subflow. In Figure 5-4, we distinguish between different kinds of flows using tags denoted as strings within brackets: {}. While UML allows us to define tag values to give more information about particular elements in our model, the tags {basic}, {alt}, and {sub} are not defined in UML. However, we believe that they should be added, since they reflect the standard practice in writing use cases.

Use cases, like classes, are generalizable elements, and their flows can be either concrete or abstract. A flow is concrete when the steps that constitute the flow are defined—that is, you have all the text that describes flow. A flow is abstract when you have given the flow a name, but the flow itself is unspecified. The actual specification is defined as a child use case.

Each use case is a unit of useful functionality that the system provides to its actors. A use-case specification contains a number of flows that describe how variations are handled. You can easily verify that you have captured stakeholder concerns by walking through the flows with the stakeholders.

The use-case technique is a widely adopted technique to model the requirements of a system. Use cases are a huge topic, and while we do not explore them in depth, many books have been written to demonstrate how to apply the technique effectively. If you want to learn more about use cases, we recommend the following books as references:

There have not been many changes to the use-case technique or the representation of use cases since their introduction. In this chapter, we introduced a small enhancement—to represent use-case flows as a compartment within the use-case classifier. This helps us visualize the responsibilities of the use case and prevents practitioners from falling into the functional decomposition trap. More importantly, it is the starting point for us to model pointcuts in use cases, which we discuss in Chapter 6.