A communication diagram is made up of three things: participants, the communication links between those participants, and the messages that can be passed along those communication links, as shown in Figure 8-1.

Figure 8-1. Much simpler than sequence diagrams, communication diagrams are made up of participants and links

Participants on a communication diagram are represented by a rectangle. The participant’s name and class are then placed in the middle of the rectangle. A participant’s name is formatted as <name> : <class>, similar to participants on a sequence diagram.

You need to specify either the participant’s name or class (or both). If, for some reason, you do not have both the name and class information—sometimes a participant is anonymous and does not have a name—then either the class or the name can be left out.

A communication link is shown with a single line that connects two participants. A link’s purpose is to allow messages to be passed between the different participants; without a link, the two participants cannot interact with each other. A communication link is shown in Figure 8-2.

Figure 8-2. Two messages are passed along the link between participant1 and participant2

A message on a communication diagram is shown using a filled arrow from the message sender to the message receiver. Similar to messages on a sequence diagram, a message’s signature is made up of the message name and a list of parameters. However, unlike sequence diagrams, the message signature alone is not enough for a communication diagram—you also need to show the order in which the messages are invoked during the interaction.

Communication diagrams do not necessarily flow down the page like sequence diagrams; therefore, message order on a communication diagram is shown using a number before each message. Each message number indicates the order in which that message is invoked, starting at 1 and increasing until all of the messages on the diagram are accounted for. Following this rule, in Figure 8-2, 1. messageA( ) is invoked first and then 2. messageB( ).

Things get more complicated when a message sent to a participant directly causes that participant to invoke another message. When a message causes another message to be invoked, the second message is said to be nested inside the original message, as shown on Figure 8-3.

Figure 8-3. Nested messages on sequence diagrams are easy to see; when the initial message, message1(..), is invoked on participant2, participant2 then invokes the nestedmessage2(..) on participant3

Communication diagrams use their message numbering scheme to show the order of nested messages. If we say that the initial message is numbered 1., then any messages nested within the initial message begin with 1., adding a number after the decimal point for the ordering of the nested messages. If an initial message’s number was 1., then the first nested message’s number would be 1.1. An example of this nested message ordering is shown in Figure 8-4.

Messages Occurring at the Same Time

Communication diagrams have a simple answer to the problem of messages being invoked at the same time. Although sequence diagrams need complicated constructs, such as par fragments, communication diagrams take advantage of their number-based message ordering by adding a number-and-letter notation to indicate that a message happens at the same time as another message, shown in Figure 8-5.

Figure 8-4. messageA( ) directly leads to nested 1.1 messageC( ), followed by nested messageD( ), before message 2 is invoked

Figure 8-5. Messages 2a. messageB( ), 2b. messageB( ), and 2c. messageC() are all invoked at the same time after 1. messageA( ) has been invoked

Sending a Message Based on a Condition

Sometimes a message should be invoked only if a particular condition is evaluated to be true. For example, your system might have a message that should be invoked only if the previous message has executed correctly. Just as with sequence diagram fragments, communication diagram messages can have guards set to describe the conditions that need to be evaluated before a message is invoked.

Figure 8-6. The addition of a new looping constraint to 1. messageA( ) means that the message will be invoked 10 times before the next set of messages—2a, 2b, and 2c—can be invoked

A guard condition is made up of a logical Boolean statement. When the guard condition evaluates to true, the associated message will be invoked—otherwise, the message is skipped.

Figure 8-7 shows how a guard condition can be applied to one of three concurrently executing messages.

Figure 8-7. a. messageB( ) will be invoked only at the same time as 2b. messageB( ) and messageC( ) if the expression condition == true is evaluated as true; if condition == true returns false, then 2a. messageB( ) is not invoked, but message 2b. messageB( ) and 2c. messageC( ) are

When a Participant Sends a Message to Itself

A participant talking to itself may sound strange at first, but if you think in terms of a software object making a call to one of its own methods, you might start to see why this form of communication is needed (and even common). Just as on sequence diagrams, a participant on a communication diagram can send a message to itself. All that is needed is a link from the participant to itself to enable the message to be invoked, as shown in Figure 8-8.

Figure 8-8. The participant can invoke 1. messageA( ) on itself because it has a communication line to itself

With the new communication diagram notation out of the way, it’s now time to look at a practical example. We’re going to take one of the sequence diagrams from Chapter 7 and show how its interactions can also be modeled on a communication diagram (see Figure 8-9).

Figure 8-9. This sequence diagram describes the interactions that take place in a CMS when a new regular blog account is created

Don’t be afraid to refer back to Chapter 7 to help you out with the notation shown on the sequence diagram. Sequence diagrams contain a lot of unique notation, and mastering it all can take some time! It isn’t necessary to have a sequence diagram before you create a communication diagram. You can create communication diagrams or sequence diagrams for your interactions in whatever order you see fit.

The first step is to add the participants from Figure 8-9 to the communication diagram shown in Figure 8-10.

Figure 8-10. The participants involved in an interaction are often the first pieces added to a communication diagram

Next, the links between each of the participants are added so they can communicate with each other, as shown in Figure 8-11.

It’s now time to add the messages that are sent between participants during the lifetime of the interaction, as shown on Figure 8-12. When adding messages to a communication diagram, it’s usually best to start with the participant or event that kicks off the interaction.

Figure 8-11. By looking at the sequence diagram in Figure 8-9, the links required to support the message passing can be added to the communication diagram

Figure 8-12. The Administrator actor starts things off by passing three separate messages to the ui:AccountCreationUserInterface participant

Once the initial message or messages are added to the communication diagram, things start to get more complicated. The 3. enterAuthorDetails( ) message triggers a nested creation message that is sent from the ui : AccountCreationUserInterface participant to create a new authorDetails : CustomerDetails participant. Nested messages get an additional decimal point based on the triggering message’s number, as shown in Figure 8-13.

Figure 8-13. When the <<create>> message is added to the communication diagram, its message order number is set to 3.1. to show that it is nested inside the 3. enterAuthorDetails( ) message

With that small hurdle out of the way, the rest of the messages can be added to the communication diagram (see Figure 8-14).

Figure 8-14. The finished communication diagram shows the complete set of messages within the Create a new Regular Blog Account interaction according to those shown on the original sequence diagram shown in Figure 8-9

Communication and sequence diagrams present such similar information that a comparison is almost inevitable. Setting personal preferences aside, what are the best reasons for picking a sequence diagram, a communication diagram, or even a combination of both to model a particular interaction?

How the Fight Shapes Up

Figure 8-15 shows the two different representations of the same Create a new Regular Blog Account interaction.

Figure 8-15. The Create a new Regular Blog Account interaction can be modeled using a sequence diagram and a communication diagram

You’ve seen sequence and communication diagrams, which are the two most commonly used types of interaction diagrams. Timing diagrams are a more specialized interaction diagram focusing on time constraints on interactions, which is particularly useful for expressing time constraints in real-time systems. Timing diagrams are covered in Chapter 9.