Chapter 4: Use Cases

This chapter describes the primary means by which you can use the UML to capture functional requirements. You express these requirements in terms of the specific actions that external entities and the system perform in executing required and optional behavior.

Actors and Use Cases

An actor represents one of the following things:

• A role that a user can play with regard to a system

• An entity, such as another system or a database, that resides outside the system

The UML notation for an actor is a stick figure with a short descriptive name , as shown in Figure 4-1.

Figure 4-1: Actors (primary notation)

You can also show an actor using a stereotyped class or a user-defined icon (see Figure 4-2 for examples of both).

Figure 4-2: Actors (secondary notation)

Note ‚  

The name of an actor should not be that of a particular person; instead, it should identify a role or set of roles that a human being, an external system, or a part of the system being built will play relative to one or more use cases. Note also that a single physical entity may be modeled by several different actors and, conversely, a given actor may be played by multiple physical entities.

A use case is a sequence of actions performed by an actor and the system that yields an observable result, or set of results, of value for one or more actors.

The standard notation for a use case is an ellipse combined with a short name that contains an active verb and (usually) a noun phrase (see Figure 4-3).

Figure 4-3: Use cases (primary notation)

The name of a use case can appear either within the ellipse or below it.

The text of a use case describes possible paths through the use case. Two kinds of flows of events are associated with use cases. These are as follows :

• The main flow of events (sometimes referred to as the basic course of action ) is the sunny-day scenario, the main start-to-finish path that the actor and the system follow under normal circumstances. The assumption is that the primary actor doesn't make any mistakes, and the system generates no errors. A use case always has a main flow of events.

• An exceptional flow of events (or alternate course of action ) is a path through a use case that represents an error condition or a path that the actor and the system take less frequently. A use case often has at least one exceptional flow of events.

Each unique execution of a use case represents a use case instance.

A use case can be associated with one or more subjects. For example, the subject may be a collaboration (see the section "Collaborations" in Chapter 1), and the use case would express the conditions that something interacting with that collaboration would need to meet in order to gain full access to the services that the collaboration offers. (Note that a subject can also be associated with more than one use case.) A subject may also "own" a use case, which is represented using the notation shown in Figure 4-4.

Figure 4-4: Subject owning use case

Actors and use cases appear on use case diagrams, which are described later in this chapter.