Learning UML

Use Cases

As discussed in Chapter 2, a use case is a functional requirement that is described from the perspective of the users of a system. For example, functional requirements for the project management system include: security functionality (such as allowing users to log in and out of the system), inputting of data, processing of data, generation of reports, and so forth.

Use cases follow the type-instance dichotomy first discussed in Chapter 2 and applied to classes and object in Chapter 3. You can use the UML to talk about classes of use cases, and you can use the UML to talk about specific use cases of a class. When speaking of a class of use cases, it’s customary to use the term use case or use-case class. Thus, while you might think of a use case as a specific thing, in the UML, a use case really represents a class of things. When speaking of a specific use case of a class, use the term use-case instance.

A use case defines a functional requirement that is described as a sequence of steps, which include actions performed by a system and interactions between the system and actors. Use cases address the question of how actors interact with a system, and describe the actions the system performs.

In the UML, a use case is shown as an ellipse and labeled with the name of the use-case class. Use cases may be enclosed by a rectangle that represents the boundary of the system that provides the functionality. Figure 4-3 shows various use cases associated with the project management system, including functionality to manage projects, manage resources, and administer the system.

Figure 4-3. Use cases

A use-case instance, often called a scenario, is the performance of a specific sequence of actions and interactions. For example, a specific actor instance that uses security functionality to log in or out of the project management system represents a scenario. Other possible scenarios might include a user who enters data, a user who requests processing to be done on the data, or a user who requests that the system generate a report.

A use-case instance is shown similarly to a use case but labeled with the use-case instance name followed by a colon followed by the use-case name, all fully underlined. Both names are optional, and the colon is present only if the use-case class name is specified. Use-case instances address the questions of how actor instances specifically interact with a system and what specific actions the system performs in return. Use-case instances are not commonly shown on use-case diagrams but rather are simply discussed with users to better understand their requirements.

Because use cases are performed by a system, they define the functional requirements of the system. For example, given the use cases shown in Figure 4-3, we know generally what type of functionality must be provided by the project management system. Other use-case diagrams may refine and decompose these use cases. If we don’t define our use cases, we may fall into the trap of endlessly debating whether we have identified all the functionality of the system.

Each use case is composed of one or more behavior sequences. A behavior sequence is a sequence of steps in which each step specifies an action or interaction. Each action specifies processing performed by the system. Each interaction specifies some communication between the system and one of the actors who participate in the use case. For example, a login use case may have the following behavior sequence:

1. The system provides a user interface to capture login information.

2. The user enters her username.

3. The user enters her password.

4. The system validates the username and password.

5. The system responds appropriately by allowing the user to continue, or by rejecting the user, depending on whether her username and password are valid.

Steps 1, 4, and 5 are actions that the system performs, and steps 2 and 3 are interactions between the system and user. It is fairly simple to see that step 4 is an action, but you may be wondering why steps 1 and 5 are actions rather than interactions, when the system is interacting with the user by presenting a user interface to the user or by responding appropriately with a message window or something similar. Steps 1 and 5 are actions rather than interactions because the system is simply taking action to show a user interface or a response message window that the user can easily choose to ignore. However, if this were not a human user but another system that would receive some communication to which it must reply, these would be interactions rather than actions. Quite often, trying to classify each step as either an action or interaction is not necessary; rather, it is more important to consider a use case as a dialog between actors and the system, to understand how actors interact with the system, and to understand what actions are the responsibility of the system.

Actions and interactions may also be repeated, conditional, or optional. For example, the Manage Project use case may have a behavior sequence for finding a project on which to work, and the following three succeeding behavior sequences:

• One for managing projects involving employees only

• One for managing projects involving consultants only

• One for managing projects involving both employees and consultants

An instance of the Manage Project use case involves actor instances and finding a project and managing it using one of the three available behavior sequences based upon the type of project selected. Behavior sequences, such as the one shown earlier for the login use case, are commonly captured in textual form, but may also be captured using behavioral modeling techniques, as discussed in Part III. However, the UML does not provide any explicit guidance on how to capture behavior sequences.

Because use cases result in some observable value to one or more actors, they must allow actors to achieve their goals. After all, each actor has goals in interacting with a system. Use cases don’t represent actor goals, but instead represent functionality that enable actors to achieve their goals. For example, the use cases shown in Figure 4-3 enable the actors shown in Figure 4-1 to achieve their goals in the following ways:

• To ensure that a project delivers a quality product within the specified time, cost, and resource constraints, a project manager may use the Manage Project use case.

• To ensure that trained and skilled human resources are available for projects, a resource manager may use the Manage Resource use case.

• To ensure that a project management system is available for a project, a system administrator may use the Administer System use case, which may involve a backup system.

The project management system does not offer any functionality to enable human resources to achieve their goals. Note that such functionality is outside the scope of the system.