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 communication 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 diagram, and vice versa. Thus, you have to be able to represent sequential information 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. The symbol set for the communication diagram.

A Change from UML 1.x to UML 2.0

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 diagram instead, and that's the terminology I'll use from now on. If you use documentation or modeling tools based on UML 1.x, of course, you'll still see the older term.

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.

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 operations and signals, so you know the messages each object can receive.

Figure 10.2. The domain of cars and car keys.

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. An object diagram that models instances of the classes in Figure 10.2.

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.

Figure 10.4. A communication diagram that models the messages that pass between the objects in Figure 10.3

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.

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. The communication diagram and the equivalent sequence diagram for the car and car key example.

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.

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

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 message 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 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.7. Modeling state changes in a communication diagram. Note the nested message (3.1: «become»)

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 model state changes in a communication diagram.

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 section shows.

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 communication diagram is straightforward, as Figure 10.9 shows.

Figure 10.9. The communication diagram for the best-case scenario of the “Buy soda” use case.

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 correspond 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 communication diagram (Figure 10.10)

Figure 10.10. The communication diagram for the generic sequence diagram of the soda machine.

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 stereotypes and guard conditions appear.

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.

Figure 10.11. Modeling object creation in the best-case scenario in the cell-phone–enabled soda machine.

Sometimes, two messages come out of a decision process, and their guard conditions 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 necessitates 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. Numbering the messages for mutually exclusive guard conditions.

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.

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 communication 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. An object sending a message to multiple objects in a class.

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 represent 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. An object sending a message in a specified order to multiple objects in a class.

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 expression that has the name of the returned value on the left, followed by :=, followed 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. A communication diagram that includes the syntax for a returned result.

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. An active object controls the flow in a sequence. It's represented as a rectangle with a thick, bold border.

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.

An example will clarify this for you. Suppose your objects are people in a corporation, 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.

Figure 10.17. Message synchronization in a communication diagram.

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. The big picture of the UML, including the communication diagram.

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.

Some messages are subsidiaries of others. The label-numbering scheme represents this in much the same way that some technical manuals show headings and subheadings—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.

Now that you've learned about sequence diagrams and their siblings, communication diagrams, test and strengthen your knowledge with the quiz and the exercises. As always, you'll find the answers in Appendix A, “Quiz Answers.”