UML Page 23 Thursday, September 2, 1999 12:25 PM

2
Modeling with UML

"Every mechanic is familiar with the problem of the part

you can't buy because you can't find it because the
manufacturer considers it a part
of something else. "

—Robert Pirsig, in Zen and the Art of Motorcycle

Maintenance.

Notations enable usto articulate complex ideas

succinctly andprecisely. In projects
involving manyparticipants, often of different
technical and culturalbackgrounds, accuracy and
clarity are critical as the cost of
miscommunication increases rapidly.
For a notation to enable accurate communication, it must come with a well-defined
semantics, it must be well suited for representing a given aspect of a system, and it must be well
understood among project participants. In the latter lies the strength of standards and
conventions: When a notation is used by a large number of participants, there is little room for
misinterpretation and ambiguity. Conversely, when many dialects of a notation exists, or when a
very specialized notation is used, the notation users are prone to misunderstandings as each user
imposes its own interpretation. We selected UML (Unified Modeling Language, [OMG, 1998])
as a primary notation for this book, given that it has a well-defined semantics, provides a
spectrum of notations for representing different aspects of a system, and has been accepted as a
standard notation in the industry.
In this chapter, we first describe the concepts of modeling in general and object-oriented
modeling in particular. We then describe five fundamental notations of UML that we use
throughout the book: use case diagrams, class diagrams, sequence diagrams, statechart
diagrams, and activity diagrams. For each of these notations, we describe its basic semantics and
provide examples. We revisit these notations in detail in later chapters as we describe the
activities that use them. Specialized notations that we use in only one chapter are introduced
later, such as PERT charts in Chapter 11, Project Management, and UML component and
deployment diagrams in Chapter 6, System Design.

23
UML Page 24 Thursday, September 2, 1999 12:25 PM

24 Chapter 2 • Modeling with UML

2.1 Introduction
UML is a notation that resulted from the unification of OMT (Object Modeling Technique,
[Rumbaugh et al., 1991]), Booch [Booch, 1994], and OOSE (Object-Oriented Software
Engineering, [Jacobson et al., 1992]). UML has also been in uenced by other object-oriented
notations, such as those introduced by Shlaer/Mellor [Mellor & Shlaer, 1998], Coad/Yourdon
[Coad et al., 1995], Wirfs-Brock [Wirfs-Brock et al., 1990], and Martin/Odell [Martin & Odell,
1992]. UML has been designed for a broad range of applications. Hence, it provides constructs
for a broad range of systems and activities (e.g., real-time systems, distributed systems, analysis,
system design, deployment). System development focuses on three different models of the
system:

• The functional model, represented in UML with use case diagrams, describes the
functionality of the system from the user’s point of view.
• The object model, represented in UML with class diagrams, describes the structure of a
system in terms of objects, attributes, associations, and operations.
• The dynamic model , represented in UML with sequence diagrams, statechart diagrams,
and activity diagrams, describes the internal behavior of the system. Sequence diagrams
describe behavior as a sequence of messages exchanged among a set of objects, whereas
statechart diagrams describe behavior in terms of states of an individual object and the
possible transitions between states.

In this chapter, we describe UML diagrams for representing these models. Introducing
these notations represents an interesting challenge. On the one hand, understanding the purpose
of a notation requires some familiarity with the activities that use it. On the other hand, it is
necessary to understand the notation before describing the activities. To address this issue, we
introduce UML iteratively. In the next section, we first provide an overview of the five basic
notations of UML. In Section 2.3, we introduce the fundamental ideas of modeling. In
Section 2.4, we revisit the five basic notations of UML in light of modeling concepts. In
subsequent chapters, we examine these notations in detail when we introduce the activities that
use them.

2.2 An overview of UML

In this section, we brie y introduce five UML notations:

• use case diagrams (Section 2.2.1)

• class diagrams (Section 2.2.2)
• sequence diagrams (Section 2.2.3)
• statechart diagrams (Section 2.2.4)
• activity diagrams (Section 2.2.5)
UML Page 25 Thursday, September 2, 1999 12:25 PM

An overview of UML 25

2.2.1 Use case diagrams

Use cases are used during requirements elicitation and analysis to represent the
functionality of the system.
Use cases focus on the behavior of the system from an external point
of view. A use case describes a function provided by the system that yields a visible result for an
actor. An actor describes any entity that interacts with the system (e.g., a user, another system,
the system’s physical environment). The identification of actors and use cases results in the
definition of the boundary of the system, that is, in differentiating the tasks accomplished by the
system and the tasks accomplished by its environment. The actors are outside the boundary of
the system, whereas the use cases are inside the boundary of the system.
For example, Figure 2-1 depicts a use case diagram for a simple watch. The WatchUser
actor may either consult the time on their watch (with the ReadTime use case) or set the time
actor may change the
(with the SetTime use case). However, only the WatchRepairPerson
battery of the watch (with the ChangeBattery use case).

SimpleWatch

ReadTime

SetTime
WatchUser WatchRepairPerson

ChangeBattery

Figure 2-1 A UML use case diagram describing the functionality of a simple watch. The
WatchUser
actor may either consult the time onher watch (with theReadTime use case) or set the time (with the
SetTime use case). However, only the WatchRepairPerson actor may change the battery of the watch
(with the ChangeBattery use case).
Actors are represented with stick figures, use cases with ovals, and the
boundary of the system with a box enclosing the use cases.

2.2.2 Class diagrams

We use class diagrams to describe the structure of the system. Classes are abstractions that
specify the common structure and behavior of a set of objects. Objects are instances of classes
that are created, modified, and destroyed during the execution of the system. Objects have state
that includes the values of its attributes and its relationships with other objects.
Class diagrams describe the system in terms of objects, classes, attributes, operations, and
their associations. For example, Figure 2-2 is a class diagram describing the elements of all the
watches of the SimpleWatch class. These watch objects all have an association to an object of
the PushButton class, an object of the Display class, an object of the Time class, and an object
UML Page 26 Thursday, September 2, 1999 12:25 PM

26 Chapter 2 • Modeling with UML

SimpleWatch
1 1 11
1 2
21

Display Battery Time PushButton

Figure 2-2 A UML class diagram describing the

elements of a simple watch.

of the Battery class. The numbers on the ends of associations denote the number of links each
SimpleWatch object can have with
an object of a given class. For example, a SimpleWatch has
exactly two PushButtons, one Display, two Batteries, and one Time. Similarly, all
PushButton, Display, Time, and Battery objects are associated to exactly one SimpleWatch
object.

2.2.3 Sequence diagrams

Sequence diagrams are used to formalize the behavior of the system and to visualize the
communication among objects. They are useful for identifying additional objects that participate
in the use cases. We call objects involved in a use case participating objects. A sequence
diagram represents the interactions that take place among these objects. For example, Figure 2-3
is a sequence diagram for the SetTime use case of our simple watch. The leftmost column
represents the WatchUser actor who initiates the use case. Labeled arrows represent stimuli that
an actor or an object sends to other objects. In this case, the WatchUser presses button 1 twice
and button 2 once to set her watch a minute ahead. The SetTime use case terminates when the
WatchUser presses both buttons simultaneously.

2.2.4 Statechart diagrams

Statechart diagrams describe the behavior of an individual object as a number of states and
transitions between these states. A state represents a particular set of values for an object. Given
a state, a transition represents a future state the object can move to and the conditions associated
with the change of state. For example, Figure 2-4 is a statechart diagram for the SimpleWatch.
Note that this diagram represents different information than the sequence diagram of Figure 2-3
does. The sequence diagram focuses on the messages exchanged between objects as a result of
external events created by actors. The statechart diagram focuses on the transitions between
states as a result of external events for an individual object.
UML Page 27 Thursday, September 2, 1999 12:25 PM

An overview of UML 27

:SimpleWatch :Time :Display

:WatchUser

pressButton1() blinkHours()
pressButton1()
blinkMinutes()

pressButton2()
incrementMinutes()
refresh()
pressButtons1And2()
commitNewTime()
stopBlinking()

Figure 2-3 A UML sequence diagram for the SimpleWatch.

The leftmost column represents the timeline
of the WatchUser actor who initiates the use case. The other columns represent the timeline of the
objects
that participate in this use case.
Object names are underlined to denote that they are instances (as opposed
to classes). Labeled arrows are stimuli that an actor or an object sends to other objects.

button2Pressed
button1&2Pressed
Increment
BlinkHours
Hours

button1Pressed

button2Pressed
button1&2Pressed
Increment
BlinkMinutes
Minutes

button1Pressed
button1&2Pressed
button2Pressed
Increment
BlinkSeconds StopBlinking
Seconds

Figure 2-4 A UML statechart diagram for SetTime use case of the SimpleWatch.