Interaction Diagrams - Chapter 15
Describe/illustrate sequence of message exchanges
among objects that are working together to achieve some
functionality required in the system
•used to illustrate the design required to achieve the
purpose
Types
•Collaboration diagram
•Sequence diagram
Sample Collaboration Diagram
• Suppose an event such as a light turning red occurs, and the
traffic light must send a message to the camera letting it
know that a red light occurred.
changeToRed()
PortageMain: trafficLight
1:changeToRed()
pm: camera
1.1:takePhoto()
Sample Sequence Diagram
• Suppose an event such as a light turning red occurs, and the
traffic light must send a message to the camera letting it
know that a red light occurred.
PortageMain: trafficLight
pm: camera
changeToRed()
changeToRed()
takePhoto()
Interaction Diagrams
Messages
•asynchronous or synchronous
•components
•numbered (collaboration diagram)
•guard
•name
•parameter list
•name is mandatory ... others as required
Messaging
• Synchronous messages
•asynchronous messages
•return messages
• We will assume (at first) that all messages are synchronous:
• if object A sends a message to object B then A is
suspended
• object B gains control, and B begins to compute
• object A waits until B responds (i.e. B sends a message
back to A)
•When an asynchronous message is sent from A to B, A does
not pause and wait for B to finish … results in multiple
threads of control.
Messaging
Synchronous messages:
• We say that control, or the ability to compute, is gained
by holding a token that is passed with a message. The
object with the token is executing, or ...
• You can consider there is an activation stack:
when object A sends a message to object B, object B
goes on to the top of the stack and it can compute. If B
responds to A then B is popped from the stack and A,
being at the top, begins to compute
Collaboration Diagram
•Objects are represented similarly to classes in a class
model … relationships are indicated clearly
•Objects may be named or unnamed
123543:Student
:Student
•Timing is understood by the numbering scheme. We
use a nested decimal numbering to indicate the order in
which messages are sent
•Many messages may be sent across one link
Figure 15.3 Collaboration diagram for makePayment
Messages numbered 1.1, 1.2, … are sent in response to receipt
of message numbered 1. Return messages are often left out
Figure 15.7 Messages
Many messages may be sent across one link
Messages numbered 1, 2, 3 are sent in response to receipt of
message msg1; message 3.1 is sent in response to message 3
Figure 15.8 Message to ‘this’
A message sent from an object to itself (i.e. invoking one of its
own methods) is indicated by a reflexive link, but this does not
imply a reflexive association
Figure 15.9 Instance creation
We will use a create message to indicate that an object is being
instantiated
Figure 15.10 Sequence Numbering
The initial message triggering the collaboration is
unnumbered. All messages sent as the result of an object
receiving a message numbered X, are prefixed with “X.”
We need a
numbering
scheme to
know the
order of
messages
Figure 15.11 Complex numbering
Figure 15.12 Conditional Message
A guard (enclosed in square braces []) indicates a condition
that must be true for the message to be sent
Figure 15.13 Mutually exclusive messages
a, b, etc are used as suffixes to indicate mutually exclusive
messages. A guard would accompany these
Figure 15.14 Iteration
Figure 15.15 Iteration over a multiobject
A multi-object represents a collection of objects.
E.g. the SalesLineItems for a Sale;
E.g. the ProductSpecifications for a ProductCatalog
Figure 15.16 Messages to a class itself, not an object
A message may be sent to the class, and not to a specific object.
Collaboration Diagram - example
Suppose we have classes for POrder, Customer, LineItem, Product
with the following class model
1
0..*
POrder
Customer
1
0..*
LineItem
0..*
1
Product
We want to exhibit how objects of these classes communicate in order
for the POrder to learn its value
Collaboration Diagram - example
Suppose
•POrder does not know its value.
•To determine its value it must ask each of its line items
“what are you worth?”, and then ask the customer “what
discount do you get”.
•Each line doesn’t remember the corresponding products
price and so it must interrogate the product to determine the
price
1
0..*
POrder
Customer
1
0..*
LineItem
0..*
1
Product
Collaboration Diagram
Given that the objects below are involved, we show them
along with the basic associations
Since these are objects, not classes, there are no multiplicities
Some message starts things off
reportTotal()
3:discount:=reportDiscount()
128937:POrder
JonesSupply:Customer
1:cost:=reportTotal()
2:reportTotal()
1.1:price:=reportPrice()
line1:LineItem
TYZMonitor:Product
2.1:price:=reportPrice()
line2:LineItem
OptMouseX :Product