Use Case Diagrams

A use case diagram summarizes a system's main functions and its external operating environment.

The Operating Environment

The operating environment is described by a class diagram. All classes in the diagram have the actor stereotype, signifying that instances interact with the system but are external to the system.

Types of actors include:

users
database systems
clients and servers
platforms
devices

For example, the operating environment of an airplane might include:

Even though not all actors are human, the standard icon for an actor is a stick figure:

Use Cases

A use case represents a function that the system performs. Alternatively, a use case can be thought of as a goal that some actor can achieve with the system.

An actor association is an arrow connecting an actor to a use case. This arrow represents a conversation between the actor and the system component responsible for executing the use case.

 

A conversation can be viewed as an exchange of messages. For example, the system might send a message to the user by displaying a dialog box. The user might reply to this message by clicking a button on the dialog box. Conversations can be long or short. The initiator of the conversation is indicated by the direction of the arrow, which points from the initiator to the responder.

Primary actors, such as users, always initiate conversations. Secondary actors, such as servers, always respond to an initiating use case.

The optional system boundary helps to remind us that use cases are internal to the system and actors are external.

Example: An E-Store

Notice that we do not attempt to show structures (like items or the cart) nor the flow of control (e.g., search items, add items, checkout, then check status) in a use case diagram.

Example: An ATM Machine

Notice that we do not include a use case for validating the account holder's identity (read card, read PIN, validate PIN, etc.) While these are functions that an ATM performs, they are not actor goals. In other words, no one uses an ATM machine simply to see if their PIN is valid.

Notice that the system boundary is optional. Just remember: use cases are inside the system. We are responsible for implementing them. Actors are outside the system. We are only responsible for talking to them.

Example: A Word Processor

Notice that related use cases, like related classes, can be grouped into packages. These packages might correspond to the menus on a menu bar while the use cases correspond to the menu items.

Notice that we try to use domain-specific names for actors. In the above example "Author" is domain-specific name for the user of a word processor.

Notice that the names of use cases and use case packages tend to be verbs rather than nouns.

We can describe each package using a separate use case diagram. For example, here are the persistence use cases: