Page 65 -

32 Part 1 • SyStemS analySiS FundamentalS

customer at the company store. Even though it is the same person in the real world, it is rep-
resented as two different symbols on a use case diagram because the person interacts with the
system in different roles. The actor exists outside the system and interacts with the system in a
specific way. An actor can be a human, another system, or a device such as a keyboard or Web
connection. Actors can initiate an instance of a use case. An actor may interact with one or more
use cases, and a use case may involve one or more actors.
Actors may be divided into two groups. Primary actors supply data or receive information
from the system. Some users directly interact with the system (system actors), but primary
actors may also be businesspeople who do not directly interact with the system but have a stake
in it. Primary actors are important because they are the people who use the system and can pro-
vide details on what the use case should do. They can also provide a list of goals and priorities.
Supporting actors (also called secondary actors) help to keep the system running or provide
other services. These are the analysts, programmers, people who run the help desk, and so on.
Sometimes it is useful to create an actor profile that lists the actors, their background, and
their skills in a simple table format. This may be useful to understand how the actor interacts
with the system. An example is an Order Processing Specialist. The profile would be, “A routine
user of the software, familiar with minor features, order exceptions, and order customization.” It
is also useful to list the actors and their goals and priorities. Each goal may become a use case.
A use case provides developers with a view of what the users want. It is free of technical or
implementation details. We can think of a use case as a sequence of transactions in a system. The
use case model is based on the interactions and relationships of individual use cases.
A use case always describes three things: an actor that initiates an event, the event that trig-
gers a use case, and the use case that performs the actions triggered by the event. In a use case, an
actor using the system initiates an event that begins a related series of interactions in the system.
A use case is used to document a single transaction or event. An event is an input to the system
that happens at a specific time and place and causes the system to do something.
It is better to create fewer use cases rather than more. Often queries and reports are not
included; 20 use cases (and no more than 40 or 50) are sufficient for a large system. Use cases
may also be nested, if needed. Some use cases use the verb manage to group use cases for add-
ing, deleting, and changing into another, lower-level, use case diagram. You can include a use
case on several diagrams, but the actual use case is defined only once in the repository. A use
case is named with a verb and a noun.
Use Case Relationships
Active relationships are referred to as behavioral relationships and are used primarily in use
case diagrams. There are four basic types of behavioral relationships: communicates, includes,
extends, and generalizes. Notice that all these terms are action verbs. Figure 2.13 shows the
arrows and lines used to diagram each of the four types of behavioral relationships. The four
relationships are described next.

Relationship Symbol Meaning
An actor is connected to a use case using a line with
Communicates
no arrowheads.

Includes << include >> A use case contains a behavior that is common to more than one
other use case. The arrow points to the common use case.

Extends << extend >> A different use case handles exceptions from the basic use case.
The arrow points from the extended to the basic use case.
One UML “thing” is more general than another “thing.”
Generalizes
The arrow points to the general “thing.”
Figure 2.13
Four types of behavioral relationships and the lines used to diagram each.