This chapter is from the book
This chapter is from the book
This chapter is from the book
15.5 Basic Communication Diagram Notation
Links
A link is a connection path between two objects; it indicates some form of navigation and visibility between the objects is possible (see Figure 15.23). More formally, a link is an instance of an association. For example, there is a link—or path of navigation—from a Register to a Sale, along which messages may flow, such as the makePayment message.
)
Figure 15.23 Link lines.
Note
Note that multiple messages, and messages both ways, flow along the same single link. There isn't one link line per message; all messages flow on the same line, which is like a road allowing two-way message traffic.
Messages
Each message between objects is represented with a message expression and small arrow indicating the direction of the message. Many messages may flow along this link (Figure 15.24). A sequence number is added to show the sequential order of messages in the current thread of control.
)
Figure 15.24 Messages.
Guideline
Don't number the starting message. It's legal to do so, but simplifies the overall numbering if you don't.
Messages to "self" or "this"
A message can be sent from an object to itself (Figure 15.25). This is illustrated by a link to itself, with messages flowing along the link.
)
Figure 15.25 Messages to "this."
Creation of Instances
Any message can be used to create an instance, but the convention in the UML is to use a message named create for this purpose (some use new). See Figure 15.26. If another (less obvious) message name is used, the message may be annotated with a UML stereotype, like so: «create». The create message may include parameters, indicating the passing of initial values. This indicates, for example, a constructor call with parameters in Java. Furthermore, the UML tagged value {new} may optionally be added to the lifeline box to highlight the creation. Tagged values are a flexible extension mechanism in the UML to add semantically meaningful information to a UML element.
)
Figure 15.26 Instance creation.
Message Number Sequencing
The order of messages is illustrated with sequence numbers, as shown in Figure 15.27. The numbering scheme is:
-
The first message is not numbered. Thus, msg1 is unnumbered. [10]
-
The order and nesting of subsequent messages is shown with a legal numbering scheme in which nested messages have a number appended to them. You denote nesting by prepending the incoming message number to the outgoing message number.
)
Figure 15.27 Sequence numbering.
Figure 15.28 shows a more complex case.
)
Figure 15.28 Complex sequence numbering.
Conditional Messages
You show a conditional message (Figure 15.29) by following a sequence number with a conditional clause in square brackets, similar to an iteration clause. The message is only sent if the clause evaluates to true.
)
Figure 15.29 Conditional message.
Mutually Exclusive Conditional Paths
The example in Figure 15.30 illustrates the sequence numbers with mutually exclusive conditional paths.
)
Figure 15.30 Mutually exclusive messages.
In this case we must modify the sequence expressions with a conditional path letter. The first letter used is a by convention. Figure 15.30 states that either 1a or 1b could execute after msg1. Both are sequence number 1 since either could be the first internal message.
Note that subsequent nested messages are still consistently prepended with their outer message sequence. Thus 1b.1 is nested message within 1b.
Iteration or Looping
Iteration notation is shown in Figure 15.31. If the details of the iteration clause are not important to the modeler, a simple * can be used.
)
Figure 15.31 Iteration.
Iteration Over a Collection
A common algorithm is to iterate over all members of a collection (such as a list or map), sending the same message to each. In communication diagrams, this could be summarized as shown in Figure 15.32, although there is no official UML convention.
)
Figure 15.32 Iteration over a collection.
Messages to a Classes to Invoke Static (Class) Methods
See the discussion of metaclasses in the sequence diagram case on p. 236, to understand the purpose of the example in Figure 15.33.
)
Figure 15.33 Messages to a class object (static method invocation).
Polymorphic Messages and Cases
Refer to Figure 15.21 for the related context, class hierarchy, and example for sequence diagrams. As in the sequence diagram case, multiple communication diagrams can be used to show each concrete polymorphic case (Figure 15.34).
){kind=link}
)
Figure 15.34 An approach to modeling polymorphic cases in communication diagrams.
Asynchronous and Synchronous Calls
As in sequence diagrams, asynchronous calls are shown with a stick arrow; synchronous calls with a filled arrow (see Figure 15.35).
)
Figure 15.35 Asynchronous call in a communication diagram.