 |
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 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 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.
This artifact description is excerpted from Chapter 11 of
The Object Primer 3rd Edition: Agile Model Driven
Development with UML 2.
 |
|
The Object Primer 3rd Edition: Agile Model Driven
Development with UML 2 is an
important reference book for agile modelers,
describing how to develop 35
types of agile
models including all 13
UML 2 diagrams.
Furthermore, this book describes the techniques
of the
Full Lifecycle Object Oriented Testing
(FLOOT) methodology to give you the fundamental
testing skills which you require to succeed at
agile software development. The book also
shows how to move from your agile models to
source code (Java examples are provided) as well
as how to succeed at implementation techniques
such as
refactoring and
test-driven development
(TDD). The Object Primer also includes a
chapter overviewing the critical database
development techniques (database refactoring,
object/relational mapping,
legacy analysis, and
database access coding) from my award-winning
Agile Database Techniques
book. |
 |
|
Agile Modeling: Effective Practices for Extreme
Programming and the Unified Process is the seminal
book describing how agile software developers approach
modeling and
documentation. It describes principles and
practices which you can tailor into your existing
software process, such as
XP, the
Rational Unified Process (RUP), or the
Agile Unified Process (AUP), to streamline your
modeling and documentation efforts. Modeling and
documentation are important aspects of any software
project, including agile projects, and this book
describes in detail how to
elicit requirements,
architect, and then
design your system in an agile manner. |
 |
|
The Elements of UML 2.0 Style describes a collection
of standards, conventions, and
guidelines
for creating effective
UML diagrams. They are based on sound, proven
software engineering principles that lead to diagrams
that are easier to understand and work with. These
conventions exist as a collection of simple, concise
guidelines that if applied consistently, represent an
important first step in increasing your productivity as
a modeler. This book is oriented towards
intermediate to advanced UML modelers, although there
are numerous examples throughout the book it would not
be a good way to learn the UML (instead, consider
The Object Primer). The book is a brief 188
pages long and is conveniently pocket-sized so it's easy
to carry around. |
I actively work with clients around the world to
improve their information technology (IT) practices as
both a mentor/coach and trainer. A full
description of what I do, and how to contact me, can be
found here.
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.
|
