Communication Diagrams

Massimo Felici
Room 1402, JCMB, KB
0131 650 5899
mfelici@inf.ed.ac.uk
Communication Diagrams
ƒ Communication Diagrams, formerly called
Collaboration Diagrams
ƒ UML Interaction Diagrams refine the kind of
activity undertaken in checking with CRC cards
ƒ The communication is implicit in a Sequence
Diagram, rather than explicitly represented as in a
Communication Diagram
ƒ There is some redundancy between Communication
and Sequence Diagrams
• They differently show how elements interact over time
• They document in detail how classes realize user cases
• Communication Diagrams show relationship between objects
• Sequence Diagrams focus on the time in which events occur

© 2004-2006 SEOC - Lecture Note 13 2

Communication Diagrams’ Rationale
ƒ Model collaborations between objects or roles that
deliver the functionalities of use cases and
operations
ƒ Model mechanisms within the architectural design
of the system
ƒ Capture interactions that show the passed
messages between objects and roles within the
collaboration
ƒ Model alternative scenarios within use cases or
operations that involve the collaboration of
different objects and interactions
ƒ Support the identification of objects (hence
classes) that participate in use cases
© 2004-2006 SEOC - Lecture Note 13 3
Realizing Use cases in the Design Model
ƒ Use-case driven design is a
key theme in a variety of
software processes based on
the UML
ƒ UML supports specific
modeling constructs that
realize use cases in the
implementation
ƒ Collaborations
(Communications) enhance
the systematic and
aggregate behavioral aspects
of the system
ƒ Collaborations support
traceability from
requirements expressed in
use cases into the design
© 2004-2006 SEOC - Lecture Note 13 4
Example: Communication Diagrams
ƒ Each message in a collaboration diagram has a
sequence number.
ƒ The top- level message is numbered 1. Messages sent
during the same call have the same decimal prefix but
suffixes of 1, 2, etc. according to when they occur.

© 2004-2006 SEOC - Lecture Note 13 5

Communication Diagrams
ƒ Specification level shows ƒ Participants on a
generic cases of collaboration diagram are
collaborations represented by a rectangle
(communications) <name>:<class>
• Generic form captures a ƒ A communication link is
collaboration among class shown with a single line that
roles and association roles connects two participants
and their interactions ƒ A message on a
ƒ Instance level shows a communication diagram is
specific instance of an shown using a filled arrow
interaction taking place and from the message sender to
involving specific object the message receiver
instances
• Instance form captures a
scenario among objects
conforming to class roles and
links conforming to
association roles
© 2004-2006 SEOC - Lecture Note 13 6
What is a Collaboration?
ƒ A Collaboration is a collection of named objects and
actors with links connecting them. They collaborate
in performing some task.
ƒ A Collaboration defines a set of participants and
relationships that are meaningful for a given set of
purposes
ƒ A Collaboration between objects working together
provides emergent desirable functionalities in
Object-Oriented systems
• Each object (responsibility) partially supports emergent
functionalities
• Objects are able to produce (usable) high-level
functionalities by working together
ƒ Objects collaborate by communicating (passing
messages) with one another in order to work
together
© 2004-2006 SEOC - Lecture Note 13 7
Collaborations
ƒ Actors
• Each Actor is named and has a role
• One actor will be the initiator of the use case
ƒ Objects
• Each object in the collaboration is named and has
its class specified
• Not all classes need to appear
• There may be more than one object of a class
ƒ Links
• Links connect objects and actors and are instances
of associations
• Each link corresponds to an association in the class
diagram
© 2004-2006 SEOC - Lecture Note 13 8
Interactions
ƒ Use cases and Class Diagrams constrain
interactions
ƒ Associations and Links in a Collaboration
Diagram show the paths along which
messages can be sent from one instance to
another
ƒ A message is the specification of a stimulus
ƒ A stimulus represents a specific instance of
sending the message, with particular
arguments
© 2004-2006 SEOC - Lecture Note 13 9
Messages
ƒ Message Signature ƒ Messages occurring at the same
• return-value, message-name, time
argument-list • Adding a number-and-letter
ƒ Message Flows notation to indicate that a
• Procedural or Synchronous: A message happens at the same
message is sent by one object time as another message
to another and the first object ƒ Invoking a message multiple
waits until the resulting action
times
has completed.
• Looping constraint, e.g., *[i=0..9]
• Asynchronous: A message is
sent by one object to another,
ƒ Sending a message based on a
but the first object does not condition
wait until the resulting action • A guardian condition is made up
has completed. of a logical boolean statement,
• Flat: Each arrow shows a e.g., [condition=true]
progression from one step to ƒ When a participant sends a
the next in a sequence. Normally message to itself
the message is asynchronous.
• Return: the explicit return of
control from the object to
which the message was sent.

© 2004-2006 SEOC - Lecture Note 13 10

Where should messages go?

ƒ The message is directed from sender to receiver

ƒ The receiver must understand the message
ƒ The association must be navigable in that direction
Law of Demeter
ƒ Dealing with a message m an Object O can send
messages to:
• Itself
• Objects sent as argument in the message m
• Objects O creates in responding to m
• Objects that are directly accessible from O, using attribute
values

© 2004-2006 SEOC - Lecture Note 13 11

Activations: Flow of Control
ƒ Procedural interactions
• At most one object is computing at any time
ƒ Activation
• An object has a live activation from when it
receives a message until it responds to the
message
ƒ Waiting for response
• Synchronous messages on sending a message to
another object, an object will wait until it receives
a response
ƒ Activation task
• Activations are stacked and the top activation has
control. When the top action responds the next to
top regains control and so on…
© 2004-2006 SEOC - Lecture Note 13 12
Creation and Deletion
In Communication In Sequence Diagrams, It
Diagrams the objects are is possible to use the
labeled: lifelines
•New for objects created in •New objects have their icon
the collaboration inserted when they are
•Destroyed for objects created
destroyed during the •Destroyed objects have their
collaboration lifeline terminated with X

© 2004-2006 SEOC - Lecture Note 13 13

Communication vs. Sequence Diagrams
ƒ Shows participants ƒ Support parallel message
effectively • Both Communication and
• Both Communication and Sequence diagrams show
Sequence diagrams show parallel messages effectively
participants effectively ƒ Support asynchronous
ƒ Showing the links between messages
participants • Sequence diagrams explicitly
• Communication diagrams and clearly show the links
explicitly and clearly show between participants
the links between ƒ Easy to read message
participants
ordering
ƒ Showing message signatures
• Sequence diagrams explicitly
• Both Communication and and clearly show message
Sequence diagrams show ordering
messages effectively
ƒ Easy to create and maintain
• Communication diagrams do
have the edge on the ease-
of-maintenance

© 2004-2006 SEOC - Lecture Note 13 14

Constructing Collaboration Diagrams
1. Identify behavior whose realization and
implementation is specified
2. Identify the structural elements (class roles,
objects, subsystems) necessary to carry out the
functionality of the collaboration
• Decide on the context of interaction: system, subsystem,
use case and operation
3. Model structural relationships between those
elements to produce a diagram showing the
context of the interaction
4. Consider the alternative scenarios that may be
required
• Draw instance level collaboration diagrams, if required.
• Optionally draw a specification level collaboration diagram
to summarize the alternative scenarios in the instance level
sequence diagrams
© 2004-2006 SEOC - Lecture Note 13 15
Constructing Collaboration Diagrams
1. Identify behavior
2. Identify the
structural elements
3. Model structural
relationships
4. Consider the
alternative scenarios

© 2004-2006 SEOC - Lecture Note 13 16

Summary

ƒ Interaction Diagrams
• Collaboration Diagrams
• Sequence Diagrams
ƒ Collaboration Diagrams’ Rationale
ƒ Collaboration Diagrams
• Collaborations
• Interactions
• Messages
ƒ Constructing Collaboration Diagrams

© 2004-2006 SEOC - Lecture Note 13 17