collaboration/communication diagrams like
UML sequence diagrams, are used to explore the dynamic
nature of your software. Collaboration diagrams
show the message flow between objects in an OO application,
and also imply the basic associations (relationships)
between classes. Collaboration diagrams are often
- Provide a birds-eye view of a
collection of collaborating objects, particularly
within a real-time environment.
- Allocate functionality to classes
by exploring the behavioral aspects of a system.
- Model the logic of the implementation
of a complex operation, particularly one that interacts
with a large number of other objects.
- Explore the roles that objects
take within a system, as well as the different relationships
they are involved with when in those roles.
There are guidelines for:
- General issues
An Instance-Level UML Collaboration diagram.
- Use Instance-Level Diagrams To Explore Object Design
Issues. Instance-level UML Collaboration diagrams,
such as the one shown in Figure
1 , depict interactions between objects (instances).
Instance-level diagrams are typically created to explore
the internal design of object-oriented software.
- Use Specification-Level Diagrams to Explore Roles.
Specification-level UML Collaboration diagrams, such
as the one shown in Figure 4
, are used to analyze and explore the roles taken
by domain classes within a system.
- Collaboration Diagrams Do Not Model Process Flow.
- When Sequence Is Important Use a Sequence Diagram.
- Apply Sequence Diagram Guidelines To Instance-Level
Collaboration Diagrams. Because UML Collaboration
diagrams depict an alternate view of the same information
as UML Sequence diagrams much of the same style advice
applies. The following lists of guidelines,
originally presented for UML Sequence diagrams, are
applicable to collaboration diagrams:
- Name Objects When Your Reference
Them In Messages
- Name Objects When Several of
the Same Type Exist
- Apply Textual Stereotypes Consistently
- Apply Visual Stereotypes Sparingly
- Focus on Critical Interactions
- Prefer Names Over Types for
- Indicate Types as Parameter
- Do Not Model a Return Value
When it is Obvious What is Being Returned
- Model a Return Value Only When
You Need to Refer to it Elsewhere
- Model Return Values as Part
of a Method Invocation
- Indicate Types as Return Value
2 presents the notation for invoking messages on
UML Collaboration diagrams. For example in Figure
1 the message 1.2:
orderTotal := calculateTotal()
indicates a sequence number of 1.2, there is
no loop occuring, a return value of orderTotal
and an invoked method named calculateTotal().
The basic notation for invoking a message on a collaboration
|sequenceNumber loopIndicator: returnValue
Figure 3 .
A UML Collaboration diagram depicting concurrent message
- Indicate a Return Value Only When It Isn抰 Clear
- Indicate Parameters Only When They Aren抰 Clear
- Depict an Arrow
For Each Message
- Consolidate Getter Invocations. When you have
several getters invoked in a row a good short cut
is to model a single message such as getInfo()
in Figure 1
to act as a placeholder.
- Indicate Concurrent
Threads With Letters
. In Figure
3 you see that some messages are preceded by the
indicating that those messages are being processed
The lines between the classifiers
depicted on a UML Collaboration diagram represent instances
of the relationships ?including associations, aggregations,
compositions, and dependencies ?between classifiers.
A Specification-Level UML Collaboration diagram.
- Model 揃are?Links On Instance-Level Collaboration
- Show Role-Pertinent Information on Specification-Level
Diagrams. In Figure 4 you see that the roles taken
by classes as well as the high-level multiplicities
(either blank or an asterisk to represent many) are
- Prefer Roles on Links Instead of Within Classes
- Indicate Navigability Sparingly
- Links Should Be Consistent Static Relationships
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.
The Object Primer 3rd Edition: Agile Model Driven
Development with UML 2 is an important reference
book for agile modelers, describing how to develop
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
test-driven development (TDD). The Object
Primer also includes a chapter overviewing the critical
database development techniques (database
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
documentation. It describes principles
and practices which you can tailor into your existing
software process, such as
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
architect, and then
design your system in an agile manner.