HOUR 10

Working with Communication

Diagrams

What You’ll Learn in This Hour:

. What a communication diagram is
. How to apply a communication diagram
. How to model active objects, concurrency, and synchronization
. Where communication diagrams fit into the UML

In this hour you’ll learn about a diagram that’s similar to the one you covered in
the last hour. This one also shows the interaction among objects, but it does so in a
way that’s slightly different from the sequence diagram.

Like the sequence diagram, the communication diagram shows how objects interact.
It shows the objects along with the messages that travel from one object to another.
So now you may be asking yourself, “If the sequence diagram does that, why does
the UML need another diagram? Don’t they do the same thing? Is this just overkill?”

The two types of diagrams are similar. In fact, they’re semantically equivalent.
That is, they present the same information, and you can turn a sequence diagram
into an equivalent communication diagram and vice versa.

As it turns out, it’s helpful to have both forms. The sequence diagram emphasizes
the time ordering of interactions. The communication diagram emphasizes the con-
text and overall organization of the objects that interact. Here’s another way to look
at the distinction: The sequence diagram is arranged according to time, the commu-
nication diagram according to space. Both deal with interactions among objects,
and for that reason, each one is a type of interaction diagram.
158 Hour 10

What Is a Communication Diagram?

An object diagram shows objects and their relationships with one another. A
communication diagram is an extension of the object diagram. In addition to the
links among objects, the communication diagram shows the messages the objects
send each other. You usually omit the names of the links because they would add
clutter.

One way to think of the relationship between the object diagram and the com-
munication diagram is to imagine the difference between a snapshot and a
movie. The object diagram is the snapshot: It shows how instances of classes are
linked together in an instant of time (“Instants and instances”. . . Remember?).
The communication diagram is the movie: It shows interactions among those
instances over time.

To represent a message, you draw an arrow near the link between two objects.
The arrow points to the receiving object. A label near the arrow shows what the
message is. The message typically tells the receiving object to execute one of its
(the receiver’s) operations. Arrowheads have the same meaning as in sequence
diagrams.

I mentioned that you can turn any sequence diagram into a communication dia-
gram, and vice versa. Thus, you have to be able to represent sequential informa-
tion in a communication diagram. To do this, you add a number to the label of a
message, with the number corresponding to the message’s order in the sequence.
A colon separates the number from the message.

Figure 10.1 shows the symbol set for the communication diagram.

FIGURE 10.1 :Class1

The symbol set for 1:add()
the communication
diagram.
:Class2
3:update()
2:modify()
:Class3

By the A Change from UML 1.x to UML 2.0

Way If you’ve had some exposure to earlier versions of UML or earlier editions of this
book, you’ll recall the term collaboration diagram. UML 2.0 uses communication dia-
gram instead, and that’s the terminology I’ll use from now on. If you use documenta-
tion or modeling tools based on UML 1.x, of course, you’ll still see the older term.
 Working with Communication Diagrams 159

Let’s take advantage of the equivalence of the two types of diagrams. In order to
develop the communication diagram’s concepts, you’ll revisit examples you
worked with in the previous hour. As you do this, additional concepts will emerge.

Cars and Car Keys

We start again with the domain of cars and car keys. The class diagram in
Figure 10.2 is just a refresher for you (Note it’s the same as Figure 9.5 in Hour 9,
“Working with Sequence Diagrams”). The idea is to remind you about the opera-
tions and signals, so you know the messages each object can receive.

CarOwner Car FIGURE 10.2

CarKey
name make
The domain of cars
dateOfBirth keyIDNumber model and car keys.
address year
licenseNumber getButtonPress(b:ButtonName) tagNumber

drive() processKeyMessage(b:ButtonName)
park() lock()
«signal» BlinkLights unlock()
«signal» Beep openTrunk()
ButtonPad WirelessConnection
«send» «send»

«signal» «signal»
BlinkLights Beep

Next, we create an object diagram that models instances of the classes in Figure 10.2.
This diagram appears in Figure 10.3 and is the foundation for a communication
diagram.

FIGURE 10.3
:CarKey An object diagram
that models
instances of the
classes in
Figure 10.2.

:CarOwner :Car

Now you can add the messages. The messages that appeared in Figure 9.7 appear
here in Figure 10.4. This figure shows one way of dealing with multiple messages
that pass between two objects. As you can see, messages 4 and 5 are signals that go
from the Car to the CarOwner. They have separate labels but not separate arrows.
160 Hour 10

The intent is to keep the diagram from becoming too busy. Some modeling tools,
however, provide a separate arrow for each message. Bear in mind that if different
kinds of messages pass between the same two objects, you have to show both arrows.

FIGURE 10.4
A communication :CarKey
diagram that
models the
messages that
pass between the
objects in 1: getButtonPress(b) 2: processKeyMessage(b)
Figure 10.3

[b = “lock”] 4: BlinkLights [b = “lock”]

[b = “lock”] 5: Beep 3: lock()
:CarOwner :Car

To show you the equivalence of the communication diagram and the sequence
diagram, Figure 10.5 shows Figure 10.4 side by side with Figure 9.7.

FIGURE 10.5 :CarOwner :CarKey :Car

The communication :CarKey

getButtonPress(b)
diagram and the
equivalent processKeyMessage(b)

sequence diagram 1: getButtonPress(b) 2: processKeyMessage(b)

[b = “lock”]
[b = “lock”] BlinkLights lock()
for the car and car
key example. [b = “lock”] Beep
[b = “lock”] 4: BlinkLights [b = “lock”]
[b = “lock”] 5: Beep 3: lock()
:CarOwner :Car

Changing States and Nesting Messages

Suppose Car has an attribute, locked, whose values are either True or False.
Thinking back to Hour 8, “Working with State Diagrams,” you can imagine two
states, Locked and Unlocked for Car, as shown in Figure 10.6.

You can show a change of state in a communication diagram. To do that in this

example, you show the value of locked in the Car object. Then, you duplicate the
Car object with the new value of locked. Connect the two, and then show a mes-
sage going from the first to the second. Label the message with the keyword
«become».

This example gives you the chance to examine an additional concept related to
communication diagrams—using the numbering system to show something
 Working with Communication Diagrams 161

about the relationships among messages. So far, you’ve only seen messages in
sequence. It’s also possible to show one message nested in another. You number
the nested message by starting it with the number of the message it’s nested in,
then a decimal point, and then a number for the nested message. Figure 10.7
shows the state change and the nesting.

FIGURE 10.6
Modeling the
Unlocked and
Locked states of a
car.

Unlocked

Unlock Message Lock Message

Locked

FIGURE 10.7
:CarKey Modeling state
changes in a
communication
diagram. Note the
nested message
1: getButtonPress(b) 2: processKeyMessage(b) (3.1: «become»)

[b = “lock”]
3: lock()
:Car
:CarOwner
locked = False

3.1: «become»
[b = “lock”] 4: BlinkLights
[b = “lock”] 5: Beep
:Car

locked = True
162 Hour 10

Figure 10.8 shows an alternative technique for modeling state changes. I prefer
the first way as the dotted-line arrow in the second brings to mind a dependency.
People who are new to UML often find dependencies difficult to follow.

FIGURE 10.8
Another way to :CarKey
model state
changes in a
communication
diagram.
1: getButtonPress(b) 2: processKeyMessage(b)

[b = “lock”]
3: lock()
:CarOwner :Car[unlocked]

3.1: «become»
[b = “lock”] 4: BlinkLights
[b = “lock”] 5: Beep

:Car[locked]

The nested message in this example might lead you to believe that messages are
nested only in connection with state changes. This is not the case, as the next sec-
tion shows.

The Soda Machine

Now you will move on to the soda machine example and see the communication
diagrams that match up with the sequence diagrams from Hour 9.

You begin with the best-case scenario of the “Buy soda” use case. The communi-
cation diagram is straightforward, as Figure 10.9 shows.

The diagram provides another example of a nested message. The return message
Available is nested in the call checkAvailability(). Thus, its number is 3.1.

I’ll leave it as an exercise for you to create the communication diagrams that cor-
respond to the remaining instance sequence diagrams for scenarios in the soda
machine (Figures 9.10, 9.11, and 9.12). Instead, I’ll turn my attention to the
generic sequence diagram (Figure 9.13) and show you the corresponding commu-
nication diagram (Figure 10.10)
 Working with Communication Diagrams 163

:Customer
1: accept(cash, selection)
FIGURE 10.9
The communication
diagram for the
:Front best-case scenario
of the “Buy soda”
use case.

6: receiveSoda(selection) 2: getCustomerInput(cash, selection)

:Dispenser
ilable
3.1 : Ava

:Register
3: checkAvailability(selection)
5: releaseSoda(selection)

4: update(cash, price)

:Customer
1: accept(cash,selection)
FIGURE 10.10
The communication
:Front diagram for the
generic sequence
diagram of the
[no change] 3.1:returnCash(cash)
«transaction over» [no change] soda machine.
3.2: displayPrompt(“Use Correct Change”)
[cash > price]
6: receiveChange(cash, price)
[sold out] 4.1: displayPrompt(“Sold Out”) 2: getCustomerInput(cash, selection)
«transaction over» [sold out]
4.2: returnCash(cash)
:Dispenser

«transaction over» [selection avaliable]

7: receiveSoda(selection)

:Register 4: checkAvailability(selection)
7: releaseSoda(selection)

[cash > price] 3: checkForChange(cash, price)

5: update(cash,price)

As you can see, the diagram is somewhat cluttered, particularly where messages
pass between the Register and the Front. Several message labels are close to
each other, two different kinds of messages transmit down that link, and stereo-
types and guard conditions appear.

Creating an Object
To understand object creation, recall the cell-phone–enabled soda machine. The
created object is the transaction record that enables the machine to charge the
customer’s account. Again, to model object creation, put «create» on the message
label. Figure 10.11 shows the communication diagram.
164 Hour 10

FIGURE 10.11 1: getButtonPress(creditCardNumber)

3: getButtonPress(selection)
Modeling object
creation in the :Customer :CellPhone
best-case
scenario in the
cell-phone–enabled
2: processCustomerInfo(creditCardNumber)
soda machine. 4: processCustomerInfo(selection)

2.1: displayPrompt(“Approved”)

:Front

6: <<create>> 5: checkAvailability(selection)
7: releaseSoda(selection)
5.1 Available

8: receiveSoda(selection)
:TransactionRecord :Dispenser

One More Point About Numbering

Sometimes, two messages come out of a decision process, and their guard condi-
tions are mutually exclusive. How do you number them? Go back to the cell-
phone–enabled soda machine. Figure 10.11 models just the best-case scenario.
Suppose you add the possibility that the customer is not approved. This necessi-
tates the guard condition [approved] on message 2.1 in Figure 10.11, and an
additional message with a guard condition [not approved]. In the latter case, the
transaction is over, and the Front displays a prompt to that effect.

What’s the number for the additional message? It’s also 2.1. Because the guard
conditions are mutually exclusive, only one path is possible. Figure 10.12 focuses
in on the relevant part of Figure 10.11 and shows the two messages.

FIGURE 10.12 [approved] 2.1: displayPrompt(“Approved”)

Numbering the
messages for «transaction over» [not approved]
mutually exclusive :Front 2.1: displayPrompt(“Card Not Approved”)
guard conditions.

A Few More Concepts

Although you’ve covered a lot of ground, you haven’t exhausted all the concepts
related to communication diagrams. The concepts that follow are a little esoteric,
but they might come in handy in your modeling efforts.
 Working with Communication Diagrams 165

Multiple Receiving Objects in a Class

Sometimes an object sends a message to multiple objects in the same class. A professor,
for example, asks a group of students to hand in an assignment. In the communica-
tion diagram, the representation of the multiple objects is a stack of rectangles
extending backward. You add a bracketed condition preceded by an asterisk to
indicate that the message goes to all objects. Figure 10.13 shows the details.

FIGURE 10.13
:Professor
An object sending a
message to multi-
ple objects in a
class.
*[all] 1: handIn(assignment)

:Student

In some cases, the order of message-sending is important. For example, a bank

clerk serves each customer in the order that he or she appears in line. You repre-
sent this with a while whose condition implies order (such as line position =
1. . .n) along with the message and the stacked rectangles (see Figure 10.14).

FIGURE 10.14
:BankClerk
An object sending a
message in a spec-
ified order to multi-
ple objects in a
*[line position = 1…n] 1: doBankingBusiness() class.

:Customer

Representing Returned Results

A message can be a request for an object to perform a calculation and return a
value. A customer object might request a calculator object to compute a total
price that’s the sum of an item’s price and sales tax.

The UML provides a syntax for representing this situation. You write an expres-
sion that has the name of the returned value on the left, followed by :=, followed
166 Hour 10

by the name of the operation and the quantities it operates on to produce the
result. For this example, that expression would be totalPrice:= compute
(itemPrice,salesTax). Figure 10.15 shows the syntax on a communication
diagram.

FIGURE 10.15 :Customer

A communication
diagram that 1: totalPrice: = compute(itemPrice, salesTax)
includes the syntax
for a returned
result.

:Calculator

Incidentally, the right side of the expression is called a message-signature.

Active Objects
In some interactions, a specific object controls the flow of messages. This active
object can send messages to passive objects and interact with other active objects.
In a library, for instance, a librarian takes reference requests from patrons, looks
up reference information in a database, gives information back to the patrons,
assigns workers to restock books, and more. A librarian also interacts with other
librarians who are carrying out the same operations. When two or more active
objects do their work at the same time, it’s called concurrency.

The communication diagram represents an active object the same as any other,
except that it’s border is thick and bold. (See Figure 10.16.)

FIGURE 10.16 4: get(title)

An active object
controls the flow in :Librarian :Worker
a sequence. It’s 3: returnInfo(title)
represented as a
rectangle with a
thick, bold border. :Worker
2: lookUp(title)
1: processReferenceRequest(title)
:Patron

Synchronization
Another circumstance you might run into is an object sending a message only
after several other (possibly nonconsecutive) messages have been sent. That is,
the object must synchronize its message with a set of other messages.
 Working with Communication Diagrams 167

An example will clarify this for you. Suppose your objects are people in a corpo-
ration, and they’re concerned with a new product campaign. Here is a sequence
of possible interactions:

1. The Senior VP of Marketing asks the VP of Sales to create a campaign for a

particular product.

2. The VP of Sales creates the campaign and tells the Sales Manager to assign
the campaign to a Salesperson.

3. The Sales Manager directs a Salesperson to sell the product according to the
campaign.

4. The Salesperson makes sales calls to potential customers in order of their

priority.

5. After the Sales Manager has issued the directive (that is, when steps 3 is
complete), a corporate Public Relations Specialist has the local newspaper
place an ad about the campaign.

How do you represent step 5’s position in the sequence? Again, the UML provides
a syntax. Instead of preceding this message with a numerical label, you precede it
with the number of the message that has to be completed prior to step 5 taking
place and then add a slash. If more than one message is required, use a comma
to separate one list-item from another, and end the list with a slash. Figure 10.17
shows the communication diagram for this example.

:SeniorVPOfMktg
FIGURE 10.17
1: create(campaign, product) Message
synchronization in
a communication
:VPOfSales diagram.

2: assign(campaign, product)

:PRSpecialist
:SalesMgr

3 / placeAd(campaign, product) 3: sell(campaign, product)

Newspaper

:SalesPerson

*[priority = 1…n] 4: takeSalesCall(campaign)

:Customer
168 Hour 10

Building the Big Picture

Now you can add the communication diagram to your picture of the UML. It’s
another behavioral element, as Figure 10.18 shows.

FIGURE 10.18 Structural Elements Behavioral Elements

The big picture of
the UML, including
the communication Class State
Interface
diagram.

Use case

:Name1 :Name2
Actor

Relationships

Association

Generalization

Dependency

Realization Sequence

Grouping Extension
:Name1 1: Message()
«Stereotype»
Package {Constraint}
:Name2

Communication
Annotation

Note

Summary
A communication diagram is another way of presenting the information in a
sequence diagram. The two types of diagrams are semantically equivalent, but it’s
a good idea to use both when you construct a model of a system. The sequence
diagram is organized according to time, and the communication diagram is
organized according to the links among objects.

The communication diagram shows the associations among objects as well as the
messages that pass from one object to another. An arrow near an association line
represents a message, and a numbered label shows the content of the message.
The number represents the message’s place in the sequence of messages.

Conditionals are represented as before—by putting the conditional statement in

square brackets.
 Working with Communication Diagrams 169

Some messages are subsidiaries of others. The label-numbering scheme represents

this in much the same way that some technical manuals show headings and sub-
headings—with a numbering system that uses decimal points to show levels of
nesting.

Communication diagrams allow you to model multiple receiving objects in a

class whether the objects receive the message in a specified order or not. You can
also represent active objects that control the flow of messages, as well as messages
that synchronize with other messages.
170 Hour 10

Q&A
Q. Will I really have to include both a communication diagram and a
sequence diagram in most UML models I build?
A. It’s a good idea to include both. The two types of diagrams are likely to
stimulate different thought processes during the analysis segment of the
development effort. The communication diagram clarifies the relationships
among the objects because it includes interobject links. The sequence dia-
gram focuses attention on the sequence of interactions. Also, your client
organization might include people whose thought processes differ from one
another. When you have to present your model, one type of diagram might
be better suited than the other for a particular individual.

Q. In Hour 9, you showed how UML 2.0 puts frames around parts of the
sequence diagram. Does UML 2.0 do anything similar for the communica-
tion diagram?
A. You can draw a frame around a communication diagram in the same way
that you draw a frame around a sequence diagram. UML 2.0 doesn’t set up
frames around parts of a communication diagram, however.

Q. In this hour you showed how to model an object changing its state. Can I
model this in a sequence diagram?
A. Yes you can. You indicate an object’s state by putting a state icon on its
lifeline. The state icon’s location on the lifeline indicates the time during
which the object is in that state. To show the object changing its state, add
a new state icon farther down the lifeline. Although UML allows you to
take symbols from one kind of diagram and add them to another, some
modeling tools do not.

Workshop
Now that you’ve learned about sequence diagrams and their siblings, communi-
cation diagrams, test and strengthen your knowledge with the quiz and the exer-
cises. As always, you’ll find the answers in Appendix A, “Quiz Answers.”

Quiz
1. How do you represent a message in a communication diagram?

2. How do you show sequential information in a communication diagram?