Chapter 2

UNIFIED INTRODUCING THE UML

MODELING
LANGUAGE

In this chapter
Overview of the UML
Three steps to understanding the UML
Software architecture
The software development process

The Unified Modeling Language (UML) is astandard language for writing

software blueprints. The UML may be used to visualize, specify, construct,
and document the artifacts of a software-intensive system.

The UML is appropriate for modeling systems ranging from enterprise infor
mation systems to distributed Web-based applications and even to hard real
time embedded systems. It is avery expressive language, addressing allthe
views needed to develop and then deploy such systems. Even though it is
expressive, the UML is not difficult tO understand and to use. Learning to
apply the UML effectively starts with forming aconceptual model of the lan
guage, which requires learning three major elements:the UML's basic building
blocks, the rules that dictate how these building blocks may be put together,
and some common mechanisms that apply throughout the language.

The UML is only a language, so it is just one part of a software development

method. The UML is process independent, although optimally it should be
used in a process that is use case driven, architecture-centric, iterative, and
incremental,

13
14 PART 1 GETTING STARTED

An Overview of the UML

The UML is a language for

Visualizing
Specifying
Constructing
Documenting
the artifacts of a software-intensive system.

The UML Is a Language

A language provides a vocabulary and the rules for combining words in that
vocabulary for the purpose of communication. Amodeling language is a lan
guage whose vocabulary and rules focus on the conceptual and
sentation of a system. Amodeling language such as the UML isphysical
thus a repre
standard language for Software blueprints.
The basic
Modeling yields an understanding of a system. No one model is ever
principles of
Rather, you often need multiple models that are sufficient.
modeling are
discussed in
connected
understand anything but the most trivial system. For to one another to
Chapter 1. tems, this requires a language that addresses software-intensive sys
the different views of a system's
architecture as it evolves throughout the software
development life cycle.
The vocabulary and rules of a
and read well-formed models,language such as the UML tell you
but they don't tell you what modelshow to create
create and when you should create them. you should
That's the role of the software devel
opment process. Awell-defined prbcess will guide you in
facts to produce, what activities and what deciding what arti
manage them, and how to use those workers to use to create them and
as a whole. artifacts to measure and control the project

The UML Isa Language for

For many
Visualizing
programmers,
and then pounding the distance between
thinking of an
it out in code is close
fact, some things are best cast to zero. You think it,implementation
and direct way to write directly in code. Text is a you code it. In
expressions and algorithms. wonderfully minimal
 CHAPTER 2 INTRODUCING THE UML 15

In such cases, the programmer is still doing some nodeling, albeit entirely
mentally. He or she may even sketch out a few ideas on a white board or on a
napkin. However, there are several problems with this. First, communicating
those conceptual models to others is error-prone unless everyone involved
speaks the same language. Typically, projects and organizations develop their
own language, and it is difficult to understand what's going on if you are an
outsider or new to the group. Second, there are some things about a software
system you can't understand unless you build models that transcend the textual
programming language. For example, the meaning of aclass hierarchy can be
inferred, but not directly grasped, by staring at the code for all the classes in
the hierarchy. Similarly, the physical distribution and possible migration of the
objects in a Web-based system can be inferred, but not directly grasped, by
studying the system's code. Third, if the developer who cut the code never
Wrote down the models that are in his or her head, that information would be
lost forever or, at best, only partially recreatable from the implementation once
that developer movedon.
Writing models in the UML addresses the third issue: An explicit model facili
tates communication.

Some things are best modeled textually; others are best modeled graphically.
Indeed, in all interesting systems, there are structures that transcend what can
be represented in a programming language. The UML is such a graphical lan
guage. This addresses the second problem described earlier.
The complete The UML is more than just a bunch of graphical symbols. Rather, behind each
semantics of symbol in the UML notation is a well-defined semantics. In this manner, one
the UML are developer can write a model in the UML, and another developer, or even
discussed in
The Unified another tool, can interpret that model unambiguously. This addresses the first
Modeling Lan issue described earlier.
guage Refer
ence Manual,
The UML Is aLanguage for Specifying
precise, unambigu
In this context, specifying means building models thatthearespecification of all the
Ous, and complete. In particular, the UML addresses that must be made in
Important analysis, design, and implementation decisions
developing and deploying a software-intensive system.

The UML Is a Language for Constructing

its models can be directly
The UML is not a visual programming language, butThis means that it is
connected to a variety of programming languages.
 16 PART 1 GETTING STARTED

possible to map from a model in the UML to a programming language such as

Java, C++, or Visual Basic, or even to tables in a relational database or the per
sistent store of an object-oriented database. Things that are best expressed
graphically are done so graphically in the UML, whereas things that are best
expressed textually are done so in the programming language.
Modeling the This mapping permits forward engineering-the generation of code from a
structure of a
system is
UML model into aprogramming language. The reverse is also possible: You
discussed in can reconstruct a model from an implementation back into the UML Reverse
Parts 2 engineering is not magic. Unless you encode that information in the imple
and 3. mentation, information is lost when moving forward. from models to code.
Reverse engineering thus requires tool support with human intervention. Com
bining these two paths of forward code generation and reverse engineering
yields round-trip engineering, meaning the ability to work in either a graphical
or a textual view, while tools keep the two views consistent.
Modeling the In addition to this direct mapping, the UML is sufficiently expressive and
behavior of a
system is
unambiguous topermit the direct execution of models, the simulation of sys
discussed in tems, and the instrumentation of running systems.
Parts 4
e
and 5.

he UML Is a Language for Documenting

Ahealthy software organization produces all sorts of
artifacts in addition to
raw executable code. These artifacts include (but are not
limited to)
Requirements
Architecture
Design
Source code
Project plans
Tests
Prototypes
Releases
Depending on the development culture, some of these
more or less formally than others. Such artifacts are treated
of a project, they are also artifacts are not only the deliverables
ing about a system during critical in controlling, measuring, and
its development communicat
and after its deployment.
The UML addresses the
documentation
details. The UML also provides a
of a system's
architecture and all of its
for tests. Finally, the UML language for expressing
project planning and releaseprovides a language for modelingrequirements and
the activities of
management.
 CHAPTER 2 INTRODUCING THE UML 17

Where Can the UML Be Used?

The UML is intended primarily for software-intensive systens. It has been

used effectively for such domains as
Enterprise information systems
Banking and financial services
Telecommunications
Transportation
Defense/aerospace
Retail
Medical electronics
I Scientific
Distributed Web-based services
The UML is not limited to modeling software. In fact, it is expressive enough
to model nonsoftware systems, such as workflow in the legal system, the struc
ture and behavior of apatient healthcare system, software engineering in air
craft combat systems, and the design of hardware.

A Conceptual Model of the UML

To understand the UML, you need to form a conceptual model of the language.
and this requires learning three major elements: the UML's basic building
blocks, the rules that dictate how those building blocks may be put together,
and some common mechanisms that apply throughout the UML. Once you
have grasped these ideas, youwill be able to read UML models and create
some basic ones. As you gain more experience in applying the UML,you can
build on this conceptual model, using more advanced features of the language.

Building Blocks of the UML

The vocabulary of the UML encompasses three kinds of building blocks:
1. Things
2. Relationships
3. Diagrams

Things are the abstractions that are first-class citizens in a model; relationships
tie these things together; diagrams group interesting collections of things.
 GETTING STARTED
PART 1
18

of things in the UML:

in the UML There are four kinds
Things
1. Structural things
2. Behavioral things
3. Grouping things
4. Annotationalthings
building blocks of the UML Yo
These things are the basic object-oriented
well-formed models.
use them to write
Structural things are the nouns of UML models, These
Structural Things
of a model, representing elements that are either
are the mostly static parts things are called classifers.
the structural
conceptual or physical. Collectively,
of a set of objects that share the same attributes,opera
Classes are A class is a description semantics. A class implements one or more interfaces.
discussed in tions, relationships, and rectangle, usually including its name,
Chapters 4 Graphically, a class is rendered as a
and 9. attributes, and operations, as in Figure 2-1.

Window

origin
size

open)
close()
move()
display()

Figure 2-1:Classes
Interfaces are An interface is a collection of operations that specify a service of a class or
discussed in component. An interface therefore describes the externally visible behavior of
Chapter 11.
that element. An interface might represent the complete behavior of a class or
component or only apart of that behavior. An interface defines a set of opera
tion specifications (that is,their signatures) but never a set of operation imple
mentations. The declaration of an interface looks like a class with the keyword
<interface» above the name; attributes are not relevant, except sometimes to
show constants. An interface rarely stands alone, however. An interface pro
vided by a class to the outside world is shown as a small circle attached to the
class box by a line. An interface required by a class from some other class is
shown as a small semicircle attached to the class box by a line, as in
Figure 2-2.
 CHAPTER2 INTRODUCING THE UML 19

einterface»
IWindow
open()
close()
move()
display()

Window
IWindow IPaint

Figure 2-2: Interfaces

Collaborations Acollaboration defines an interaction and is asociety of roles and other ele
are discUssed
ments that work together to provide some cooperative behavior that's bigger
in Chapter 28. than the sum of all the elements. Collaborations have structural, as well as
behavioral, dimensions. A given class or object might participate in several
collaborations. These collaborations therefore represent the implementation of
patterns that make up a system. Graphically, a collaboration is rendered as an
ellipse with dashed lines, sometimes including only its name, as in Figure 2-3.

Chain of
responsibility

Figure 2-3: Collaborations

Use cases are A use case is a description of sequences of actions that a system performs that
discussed in yield observable results of value to a particular actor. Ause case is used to
Chapter 17. structure the behavioral things in a model. A use case is realized by a collabo
ration. Graphically, a use case is rendered as an ellipse with solid lines, usually
including only its name, as in Figure 2-4.

Place order

Figure 2-4: Use Cases

The remaining three things-active classes, components, and nodes-are all

class-like, meaning they also describe sets of entities that share the same
attributes, operations, relationships, and semantics. However, these three are
 PART 1 GETTING STARTED
20

different enough and are necessary for modeling certain aspects of an object-
treatment.
oriented system, so they warrant special
An gctiveclass is a class whose objects oWn one OT more processes or threads
Active classes
are discussed and therefore can initiate control activity. An active class is just like a class
with
in Chapter 23. except that its objects represent elements whose behavior is concurrent
other elements. Graphically, an active class is rendered as a class with double
lines on the left and right; it usually includes its name, attributes, and opera
tions, as in Figure 2-5.
EventManager

suspend)
flush()

Figure 2-5: Active Classes

Components Acomponentis a modular part of the system design that hides its implementa
and internal
structure are
tion behind aset of external interfaces. Within a system, components shar1ing
discussed in the same interfaces can be substituted while preserving the same logical
Chapter 15. behavior. The implementation of a component can be exxpressed by wifing
together parts and connectors; the parts can include smaller components.
Graphically, acomponent is rendered like a class with a special icon in he
upper right corner, as in Figure 2-6.

Orderform

Figure 2-6: Components

The remaining two elements-artifacts and nodes-are also different. They
represent physical things, whereas the previous five things represent concep-
tual or logical things.
Artifacts are An artifact is a physical and replaceable part of asystem that contains physical
discussed in
Chapter 26. information ("bits"), In a system, you'l encounter different kinds of deploy-
ment artifacts, such as source code files, executables, and scripts. Anartifact
typically information.
represents
Graphically,
the renderedpackaging
an artifact isphysical ofsource
as a rectangle Or run-time
with the keyword«artifact»
above the name, as in Figure 2-7.
 CHAPTER 2 INTRODUCING THE UML 21

«artifact»

window.dll

Figure 2-7: Artifacts

Nodes are
discussed in
A node is aphysical element that exists at run time and represents a computa
Chapter 27. tional resource, generally having at least some memory and,often, processing
capability. Aset of components may reside on a node and may also migrate
from node to node. Graphically, anode is rendered as acube, usually including
only its name, as in Figure 2-8.

Server

Figure 2-8: Nodes

These elements- classes, interfaces,collaborations, use cases, active classes,
components, artifacts, and nodes--are the basic structural things that you may
include in a UML model. There are also variations on these, such as actors,
signals,and utilities (kinds of classes); processes and threads (kinds of active
classes); and applications, documents, files, libraries, pages, and tables (kinds
of artifacts).
Use cases,
which are used
Behavioral Things Behavioral things are the dynamic parts of UML mod
els. These are the verbs of a model, representing behavior over time
to structure the
In all, there are three primary kinds of behavioral things. and space.
behavioral
things ina
model, are First, an interaction is a behavior that comprises a set of
discussed in among a set of objects or roles within a particular contextmessages
to
exchanged
Chapter 17; cific purpose, The behavior of a society of objects or of an accomplish a spe
interactions
are discussed may be specified with an interaction, An interaction individual operation
in Chapter 16. involves
elements, including messages, actions, and connectors (the a number of other
between objects). Graphically, a message is rendered as a connection
always including the name of its operation, as in directed line, almost
Figure 2-9,
display

Figure 2-9: Messages

 22 PART 1 GETTING STARTED

State Second, a state machine is a behavior that specifies the sequences of states an
machines are object or an ineraction goes through during its lifetime in response to events,
discussed in together with its responses to those events. The behavior of an individual class
Chapter 22. or acollaboration of classes may be specified with a state machine. A state
machine involves a number of other elements, including states, transitions (the
flow from state to state), events (things that trigger a transition), and activities
(the response to atransition), Graphically, a state is renderedas a rounded rect
angle, usually including its name and its substates, if any, as in Figure 2-10.

Waiting

Figure 2-10: States

Third, an activity is a behavior that specifies the sequence of steps a computa

tional process performs. In an interaction, the focus is on the set of objects that
interact. In a state machine, the focus is on the life cycle of one object at a
time. In an activity, the focus is on the flows among steps without regard to
which object performs each step. Astep of an activity is called an action.
Graphically, an action is rendered as a rounded rectangle with a name indicat
ing its purpose. States and actions are distinguished by their different contexts.

process order

Figure 2-11: Actions

These three elements-interactions, state machines, and activities-are the
basic behavioral things that youmay include in a UML model. Semantically,
these elements are usually connected to various structural elements, primar1ly
classes, collaborations, and objects.
Grouping Things Grouping things are the organizational parts of UML
models, These are the boxes into which a model can be decomposed. There is
one primary kind of grouping thing, namely, packages.
Packages are A package is a general-purpose mechanism for organizing the design itself, as
discussed in opposed to classes, which organize implementation constructs. Structural
Chapter 12. things, behavioralthings, and even other grouping thingsmay be placed in a
package. Unlike components (which exist at run time), a package is purely
 CHAPTER 2 INTRODUCING THE UML 23

conceptual (meaning that it exists only at development time). Graphically, a

package is rendered as a tabbed folder, usually including only its name and,
sometimes, its contents, as in Figure 2-12.

Business rules

Figure 2-12: Packages

Packages are the basic grouping things with which you may organize a UML
model. There are also variations, such as frameworks, models,and subsystems
(kinds of packages).
Notes are
discussed in
Annotational Things Annotational things are the explanatory parts of
UML models. These are the comments you may apply to describe, illuminate,
Chapter 6.
and remark about any element in a model. There is one primary kind of annota
tional thing, called a note. A note is simply a symbol for rendering constraints
and comments attached to an element or a collection of elements. Graphically,
a note is rendered as a rectangle with a dog-eared corner, together with a tex
tual or graphical comment, as in Figure 2-13.

return copy
of self

Figure 2-13: Notes

This element is the one basic annotational thing you may include ina UML
model. You'll typically use notes to adorn your diagrams with constraints or
comments that are best expressed in informalor formal text. There are also
variations on this element, such as requirements (which specify some desired
behavior from the perspective of outside the model).
Relationships in the UML There are four kindsof relationships in the
UML:

1. Dependency
2. Association
3. Generalization
4. Realization
 GETTING STARTED
PART 1
24

These relationships are the basicrelationalIbuilding blocks,of the UML. You

well-formed models.
Ise them to write
relationship between two model
First, adependency is asemantic
Denendenoies
which achange to one element (the independent one) may affect theelements in
ol the other element (the dependent one). Graphicaly, a dependency semant
is renics
are discussed
n Chanters 5

dered as a dashedline, possibly directed, andl occasionally includingaalabel, as

in Figure 2-14.

Figure 2-14: Dependencies

Associations Second, an association is a structural relationship
are discuSSed
a set of links, a link being a among classes that describes
in Chanters 5
and 10.
connection
classes. Aggregation is a special kind of among objects that are instances of the
relationship between awhole and its parts.association, representing a structural
rendered as asolid line, possibly directed, Graphically, an association is
often containing other
Figure 2-15. adornments, such asoccasionally including a label, and
multiplicity and end names, as in
0..1

employer employee
Generalareiza Figure 2-15: Associations
tions Third, ageneralization isa
discussed in the
Chapters 5
and 10. izedspeci
el
parent.
ement specializsharesation/generstructure
alized(theelement (the child) builds on
parent). The child the aspecilizatiofincatrelationship
ion general
of the
in
which
holGrloawphiarrowhead
cally, generalization
with a a the and the behavior of the
pointing to therelaparent,
tionshipas inrendered as a solid line
is
Figure 2-10.
Realizations
are discussed
Fourt h, a Figure 2-16:Generalizations
in Chapter 10.
one realization is a
cll assifier specifies a semantic
You'
and encounter
the classes contract thatrelationship between
rthatcomponent
ealization rselthatationshianotps inhertwoclassiplaces:
wherein classifiers,
dered
Or
cFigureol abasor2-17.aatiocrossns realizeathem. realize them, and between interfaces fier guarantees
to carry out.

between
generalGrizataphiioncalandly, arealization relationship is ren-
betw een
a use cases and the

dependency relatosy
 CHAPTER 2 INTRODUCING THE UML 25

Figure 2-17: Realizations

These four elements are the basic relational things you may include in a UML
model. There are also variations on these four, such as refinement, trace,
include, and extend.

The five views Diagrams in the UML Adiagram is the graphical presentation of a set of
of an architec elements, most often rendered as a connected graph of vertices (things) and
ture are
discussed later paths (relationships). You draw diagrams to visualize asystem from different
in this chapter. perspectives, so a diagram is aprojection into a system. For all but the most
trivial systems, a diagram represents an elided view of the elements that make
up a system. The same element may appear in all diagrams, only a few dia
grams (the most common case), or in no diagrams at all (a very rare case). In
theory, a diagram may contain any combination of things and relationships. In
practice, however, a small number of common combinations arise, which are
consistent with the five most useful views that comprise the architecture of
a software-intensive system. For this reason, the UML includes thirteen kinds
of diagrams:

1.Class diagram
2. Object diagram
3. Component diagram
4. Composite structure diagram
5. Use case diagram
6. Sequence diagram
7.Communication diagram
8. State diagram
9. Activity diagram
10. Deployment diagram -
11. Package diagram
12. Timing diagram
13. Interaction overview diagram
Class Aclass diagram shows aset of classes, interfaces, and collaborations and their
diagrams are
discussed in
relationships. These diagrams are the most common diagram found in model
Chapter 8.
ing object-oriented systems, Class diagrams address the static design view of a
system. Class diagrams that include active classes address the static process
view of a system.Component diagrams are variants of class diagrams.
Object An object diagram shows aset of objects and their relationships. Object dia
diagrams are grams represent static snapshots of instances of the things found in class dia
discussed in
Chapter 14.
grams. These diagrams address the static design view or static process view of
26 PART 1 GETTING STARTED

prototypical
a system as do class diagrams, but from the perspective of real or
cases.

Acomponent diagram is shows an encapsulated class and its interfaces, ports,

Component
diagramns and and internal structure consisting of nested components and connectors, Com
internal struc ponent diagrams address the static design implementation view of a system
ture are dis
They are important for building large systems from smaller parts. (UML dis
tinguishes acomposite structure diagram, applicable to any class, from a com
cUsseo in
Chapter 15.
ponent diagram, but we combine the discussion because the distinction
between a component and a structured class is unnecessarily subtle.)
Use case
Ause case diagram shows a set of use cases and actors (a special kind of class)
diagrams are and their relationships. Use case diagrams address the static use case view of a
discussed in system. These diagrams are especially important in organizing and modeling
Chapter 18.
the behaviors of a system.

Interaction Both sequence diagrams and communication diagrams are kinds of interaction
diagrams are
discussed in
diagrams. An interaction diagram shows an interaction, consisting of a set of
Chapter 19.
objects or roles,including the messagesthat may be dispatched among them.
Interaction diagrams address the dynanmic view of a system. A sequence dia
gram isan interaction diagram thatemphasizes the time-ordering of messages;
a communication diagram is an interaction diagram that emphasizes the struc
tural organization of the objects or roles that send and receive messages.
Sequence diagrams and communication diagrams represent similar basic con
cepts, but each diagram emphasizes a different view of the concepts. Sequence
diagrams emphasize emporal ordering, and communication diagrams empha
size the data structure through which messages flow. A timing diagram (not
covered in this book) shows the actual timnes at which messages are exchanged.
State A state diagram shows a state machine, consisting of states, transitions, eventS,
diagrams are
discussed in and activities. Astate diagrams shows the dynamic view of an object. They are
Chapter 25. especially important in modeling the behavior of an interface, class, or collab
oration and emphasize the event-ordered behavior of an object, which is espe
cially useful in mnodeling reactive systems.
Activity An activity diagram shows the structure of a process or other computation as
diagrams are the flow of control and data from step to step within the computation. Activiy
discussed in
Chapter 20 diagrams address the dynamic view of a system. They are especially importa
in modeling the function of a system and emphasize the flow of control among
objects.
Deployment A deployment diagram shows the configuration of run-time processing node
diagrams are and the components that live on them. Deployment diagrams address the static
discussed in
Chapter 31. deployment view of an architecture. A node typically hosts one or more aru
facts.
 CHAPTER 2 INTRODUCING THE UML 27

Artifact
diagrams are
An artifact diagram shows the physical constituents of asystem on the com
discussed in
puter. Artifacts include files, databases, and similar physical collections of bits.
Chapter 30.
Artifacts are often used in conjunction with deployment diagrams. Artifacts
also show the classes and components that they implement. (UML treats arti
fact diagrams as a variety of deployment diagram, but we discuss them sepa
rately.)
Package dia Apackage diagram shows the decomposition of the model itself into organiza
grams are dis tion units and their dependencies.
CUSsed in
Chapter 12.
Atiming diagram is an interaction diagram that shows actual times across dif
ferent objects or roles, as opposed to just relative sequences of messages. An
interaction overview diagram is a hybrid of an activity diagram and a sequernce
diagram. These diagranms have specialized uses and so are not discussed in this
book. See the UML Reference Manual for more details.

This is not a closed list of diagrams. Tools may use the UML to provide other
kinds of diagrams, although these are the most common ones that you will
encounter in practice.

Rules of the UML

The UML's building blocks can't simply be thrown together in a random

fashion. Like any language, the UML has anumber of rules that specify what
a well-formed model should look like. A well-formed model is one that is
semantically self-consistent and in harmony with all its related models.

The UML has syntactic and semantic rules for

Names What you can call things, relationships, and diagrams

Scope The context that gives specific meaning to a name
Visibility How those names can be seen and used by others
Integrity How things properly and consistently relate to one another
Execution What it means to run or simulate a dynamic model

Models built during the development of a software-intensive system tend to

evolve and may be viewed by many stakeholders in different ways and at dif
ferent times. For this reason, it is common for the development team to not
only build models that are well-formed, but alsoto build models that are

Elided Certain elements are hidden to simplify the view

Incomplete Certain elements may be missing
Inconsistent The integrity of the model is not guaranteed