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
2 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 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.

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.

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.

Share with friends:

Let Us Help

We actively work with clients around the world to improve their information technology (IT) practices,
typically in the role of mentor/coach, team lead, or trainer. A full description of what we do, and how to contact us, can be found at Scott Ambler + Associates.

Recommended Reading

This book, Disciplined Agile Delivery: A Practitioner's Guide to Agile Software Delivery in the Enterprisedescribes the Disciplined Agile Delivery (DAD) process decision framework.
The DAD framework is a people-first, learning-oriented hybrid agile approach to IT solution delivery. It has a risk-value delivery lifecycle, is goal-driven, is enterprise aware, and provides the foundation forscaling agile.
This book is particularly important for anyone who wants to understand how agile works from end-to-end within an enterprise setting.
Data professionals will find it interesting because it shows how agile modeling and agile database techniques fit into the overall solution delivery process.
Enterprise professionals will find it interesting beause it explicitly promotes the idea that disciplined agile teams should be enterprise aware and therefore work closely with enterprise teams.
Existing agile developers will find it interesting because it shows how to extend Scrum-based and Kanban-based strategies to provide a coherent, end-to-end streamlined delivery process.