UML Communication Diagrams: An Agile Introduction

A fundamental concept of the Unified Modeling Language (UML) is that you use different diagrams for different purposes. Class diagrams are used to model the static nature of your system, sequence diagrams are used to model sequential logic, and state machine diagrams are used to model the behavior of complex classes. But what happens when you need to show the behavior of several objects collaborating together to fulfill a common purpose? This is what UML 2 communication diagrams, formerly known as collaboration diagrams in UML 1.x, can be used for because they provide a birds-eye view of a collection of collaborating objects. UML communication diagrams show the message flow between objects in an OO application and also imply the basic associations (relationships) between classes. Figure 1 presents a simplified collaboration diagram for displaying a seminar details screen or page. The rectangles represent the various objects involved that make up the application. The lines between the classes represent the relationships (associations, composition, dependencies, or inheritance) between them. The same notation for classes and objects used on UML sequence diagrams are used on UML communication diagrams, another example of the consistency of the UML. The details of your associations, such as their multiplicities, are not modeled because this information is contained on your UML class diagrams: remember, each UML diagram has its own specific purpose and no single diagram is sufficient on its own. Messages are depicted as a labeled arrow that indicates the direction of the message, using a notation similar to that used on sequence diagrams.

Figure 1. Example communication diagram.

Figure 2 summarizes the basic notation for modeling messages on communication diagrams. Optionally, you may indicate the sequence number in which the message is sent, indicate an optional return value, and indicate the method name and the parameters (if any) passed to it. Sequence numbers should be in the format A.B.C.D to indicate the order in which the messages where sent. In Figure 1 message 1 is sent to the Seminar object which in turn sends messages 1.1 and then 1.2 to the Course object. Message 5 is sent to the Seminar object, which sends message 5.1 to enrollment, which in turn sends message 5.1.1 to student, and it finally sends message 5.1.1.1 to itself. Notice how a recursive connection, or a self connection, is required so that student can do this.

Although Figure 1 applies sequence numbers to the messages, my experience is if you feel the need to use sequence numbers on communication diagrams this is a good indication you should be using sequence diagrams instead. The main difference between communication diagrams and sequence diagrams is that sequence diagrams are good at showing sequential logic but not that good at giving you a “big picture view”� whereas communication diagrams are the exact opposite.

Figure 2. Message notation.

[sequenceNumber:] methodName(parameters) [: returnValue]

In Figure 1 you see the Seminar Details user interface object collaborates with the seminar object to obtain the information needed to display its information. It first invokes the getter method to obtain the name of the seminar. To fulfill this responsibility, the seminar object then collaborates with the course object that describes it to obtain the name of the course. In this example I showed return values for some messages but not others to provide examples of how to do it. I’ll either indicate the type of the return value, for example string, or the result, such as seminarName. Normally I wouldn’t show return values on this diagram because the messages are named well – my heuristic is to only model return values when it isn’t clear what the message returns. Better yet I try to find a new name for the message (remember, messages map to operations implemented by your classes).

Another trick I often use is to consolidate trivial messages such as getter invocations. In I modeled the series of getter method invocations to obtain the information needed to display the list of students enrolled in a seminar as the single message getInfo. I also added a note to the diagram to make it clear what I was doing, but I typically don’t do that. Why is this important? Because agile developers will only do things that add value, and defining an exact list of getter invocations wouldn’t have added value.

You draw communication diagrams in the same way as you draw sequence diagrams, the only real difference is that you lay out the notation in a different manner. To tell you the truth I rarely find the need to create communication diagrams although I have found them useful in situations where we didn’t have use cases as the primary requirements artifact. Sequence diagrams and use cases seem to go hand in hand because of how easy it is to model the sequential logic of a use case using a sequence diagram. Communication diagrams seem to be preferred by people with a “structure bent”�, people that focus on UML class diagrams or class responsibility collaborator (CRC) cards, because of the similarity of communication diagrams with those types of artifacts. As always, follow the AM practice Apply the Right Artifact(s) and use the most appropriate technique for your situation.

Source

This artifact description is excerpted from Chapter 11 of The Object Primer 3rd Edition: Agile Model Driven Development with UML 2.

Translations

Japanese

Disclaimer

The notation used in these diagrams, particularly the hand drawn ones, may not conform perfectly to the current version of the UML for one or more of reasons:

The notation may have evolved from when I originally developed the diagrams. The UML evolves over time, and I may not have kept the diagrams up to date.
I may have gotten it wrong in the first place. Although these diagrams were thoroughly reviewed for the book, and have been reviewed by thousands of people online since then, an error may have gotten past of us. We’re only human.
I may have chosen to apply the notation in “non-standard” ways. An agile modeler is more interested in created models which communicate effectively than in conforming to notation rules set by a committee.
It likely doesn’t matter anyway, because the modeling tool(s) that you’re using likely won’t fully support the current version of the UML notation perfectly anyway. Bottom line is that you’re going to be constrained by your tools anyway.

If you’re really concerned about the nuances of “official” UML notation then read the current version of the UML specification.