Page 292 -

chaPter 10 • object-oriented systems analysis and design Using Uml 259

Relationships are the glue that holds the things together. It is useful to think of relation-
ships in two ways. Structural relationships are used to tie things together in structural diagrams.
Structural relationships include dependencies, aggregations, associations, and generalizations.
Structural relationships show inheritance, for example. Behavioral relationships are used in
the behavioral diagrams. The four basic types of behavioral relationships are communicates,
includes, extends, and generalizes.
There are two main types of diagrams in UML: structural diagrams and behavioral dia-
grams. Structural diagrams are used, for example, to describe the relationships between classes.
They include class diagrams, object diagrams, component diagrams, and deployment diagrams.
Behavioral diagrams, on the other hand, can be used to describe the interaction between people
(called actors in UML) and the thing we refer to as a use case, or how the actors use the system.
Behavioral diagrams include use case diagrams, sequence diagrams, communication diagrams,
statechart diagrams, and activity diagrams.
In the remainder of this chapter, we first discuss use case modeling, the basis for all UML
techniques. Next, we look at how a use case is used to derive activities, sequences, and classes—
the most commonly used UML diagrams. Because entire books are dedicated to the syntax and
usage of UML (the actual UML specification document is over 800 pages long), we provide only
a brief summary of the most valuable and commonly used aspects of UML.
The six most commonly used UML diagrams are:
1. A use case diagram, describing how a system is used. Analysts start with a use case
diagram.
2. A use case scenario (although technically it is not a diagram). This scenario is a verbal
articulation of exceptions to the main behavior described by the primary use case.
3. An activity diagram, illustrating the overall flow of activities. Each use case may create
one activity diagram.
4. Sequence diagrams, showing the sequence of activities and class relationships. Each use
case may create one or more sequence diagrams. An alternative to a sequence diagram is a
communication diagram, which contains the same information but emphasizes communi-
cation instead of timing.
5. Class diagrams, showing the classes and relationships. Sequence diagrams are used (along
with CRC cards) to determine classes. An offshoot of a class diagram is a gen/spec dia-
gram (which stands for generalization/specialization).
6. Statechart diagrams, showing the state transitions. Each class may create a statechart dia-
gram, which is useful for determining class methods.

How these diagrams relate to one another is illustrated in Figure 10.5. We will discuss each
of these diagrams in the following sections.

Use Case Modeling
UML is fundamentally based on an object-oriented analysis technique known as use case model-
ing, which was introduced in Chapter 2. A use case model shows a view of the system from the
user perspective, thus describing what a system does without describing how the system does
it. UML can be used to analyze the use case model and to derive system objects and their inter-
actions with each other and with the users of the system. Using UML techniques, you further
analyze the objects and their interactions to derive object behavior, attributes, and relationships.
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.
Use cases are 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. For more infor-
mation about use case symbols and how to draw use case diagrams, see Chapter 2.
Figure 10.6 is a use case example of student enrollment at a university. Notice that only the most
important functions are represented. The Add Student use case does not indicate how to add students,