Earlier this year I had an interesting talk about sequence diagrams. The topic was asynchronous messages and how UML models them. As I find the topic interesting, I thought I will write a bit about that.

So how does UML models asynchronous messages, and how can you tell from a sequence diagram if a message is asynchronous? During the talk there were four signs mention that shows that a call is asynchronous:

1. There are dashed arrows showing the return calls.
2. The activity boxes are not continuous on the main lifeline
3. The arrowhead is not filled for the asynchronous message
4. The asynchronous message is not horizontal but diagonal.

My favourite one is the diagonal message, and I first I intended to write only about that, but then I thought better and decided to write bout all four statements above.

I will show you which ones are false statements, and why the last one – which was called simply nonsense – is actually true.

1) There are dashed arrows showing the return calls.

Well, asynchronous messages definitely have return calls. But so does synchronous messages. The UML specification does not restrict the use of return call to either of them. So having return calls on your diagram is not an indicator of whether the call is asynchronous or synchronous .

UML Superstructure Specification, v2.1.2 page 472 Figure 14.11

2) The activity is not continuous on the lifeline of the called or the calling object

That can be true. Or not. It actually does not show with 100% certainity if it’s a synchronous or asynchronous flow.
The activity can go on and off for a couple of reasons.

a) On the called object’s lifeline it goes off after a return call (whether shown or not)

b) When you do a callback from an asynchronous call

c) When you do a callback from a synchronous call with an explicit End Source Activation on the original synchronous call

NOTE: Ok, this is a red herring. It only seems to be a synchronous message, and the only reason you can do this is because the CASE tool allows you to do stupid things. This is an asynchronous call despite the misleading arrowhead. Now, can you tell me if the guy who drew this diagram was doing it deliberately to mess with the reader, or wanted to create an asynchronous message and did not bother with the correct arrow heads, or tried to be clever, and this is a synchronous message and wants to get a point through in an awkward way, or simply does not understand the whole synchronous/asynchronous business? No? Thought so.

So this one you can discard, bad use of the modeling tool / notation is simply that.

d) On the calling object’s lifeline the activity rectangle gets disrupted when you start a new message group

You have to take into consideration that although it is not a good practice – at least in my opinion – nothing on Earth prevents or forbids you from displaying more than one flow on one diagram, and that can mess up the activity rectangles even more.

On the activity rectangle

This activity rectangle thing, where we state that the object is “active” or “inactive” based on the presence of the rectangle, is not well handled. For one thing in the UML specification they are called: ExecutionOccurences (that name is telling a bit more about the meaning of it). The other thing is, if you think about the rectangle as an indicator of whether an object is active or not, then why does a callback from an asynchronous call disrupts the activeness of the object? The object does not become less active when he receives a call back.

Notation

ExecutionOccurences are represented as thin rectangles (grey or white) on the lifeline (see “Lifeline (from BasicInteractions, Fragments)” on page 490).
We may also represent an ExecutionSpecification by a wider labeled rectangle, where the label usually identifies the action that was executed. An example of this can be seen in Figure 14.13 on page 475.
For ExecutionSpecifications that refer to atomic actions such as reading attributes of a Signal (conveyed by the Message), the Action symbol may be associated with the reception OccurrenceSpecification with a line in order to emphasize that the whole Action is associated with only one OccurrenceSpecification (and start and finish associations refer to the very same OccurrenceSpecification).

Overlapping execution occurrences on the same lifeline are represented by overlapping rectangles as shown in Figure 14.15

UML Superstructure Specification, v2.1.2 page 479

If you think about it as an Execution Occurence, and not whether the Object is active or not, it will make more sense.

3) The arrowhead is not filled

Actually that’s the only way to show an asynchronous message according to the UML Superstructure specification.

Notation
A message is shown as a line from the sender message end to the receiver message end. The line must be such that every line fragment is either horizontal or downwards when traversed from send event to receive event. The send and receive events may both be on the same lifeline. The form of the line or arrowhead reflects properties of the message:

• Asynchronous Messages have an open arrow head.
• Synchronous Messages typically represent operation calls and are shown with a filled arrow head.
• The reply message from a method has a dashed line.

UML Superstructure Specification, v2.1.2 page 493

A quick note: some books and CASE tools use the half-stick arrowhead to differentiate the asynchronous messages – an open arrowhead with the bottom half missing -, because for a time that was the UML specification. But even then, the asynchronous message is shown by a different arrowhead than the synchronous message.

Sadly, on big diagrams printed on small papers that’s not too easy to read – Martin Fowler proposes the us of the half-stick arrowhead, stating that the filled/open distinction is too subtle. I am not sure that the half-stick arrowhead will solve this, but definitely was a bigger difference than the current one.

4) The message is not horizontal but diagonal.

It seems weird, doesn’t it? An asynchronous message “does not cause the invoking operation to halt execution while it awaits the return of control.” That means it can take it’s own sweet time to execute and that means it is not neccessarily an instantaneous call. So, we can define how long it can take to execute and return a result for example – i.e. timeout.

As the lifeline of an object in a sequence diagram represents time, the simple fact that an asynchronous message have 5 seconds to start, or 5 seconds to execute, can be shown by a diagonal message line – plus we write the Duration and Timing constraints – as it happens that’s the way you show it in UML.

Of course most of the time we don’t apply timing constraints on a message. But it is good to know that there is a possibility to do that. So you can say, that for simplicity’s sake an asynchronous message is diagonal except when the set of timing constraints is empty. Then it’s a diagonal with an angle of 0 degrees.

{ Don’t do that. It’s pointless and just shows you always wanted to be a theoretical mathematician, and failed for a good reason ;) }

And if we are talking about time, there are a few other possibilities according to the UML specifications.

Figure 14.26 – Sequence Diagram with time and timing concepts

The Sequence Diagram in Figure 14.26 shows how time and timing notation may be applied to describe time observation and timing constraints. The :User sends a message Code and its duration is measured. The :ACSystem will send two messages back to the :User. CardOut is constrained to last between 0 and 13 time units. Furthermore the interval between the sending of Code and the reception of OK is constrained to last between d and 3*d where d is the measured duration of the Code signal. We also notice the observation of the time point t at the sending of OK and how this is used to constrain the time point of the reception of CardOut.

UML Superstructure Specification, v2.1.2 page 513

We can define the timing interval for the message, and we can define Observation timing and duration for the message – useful in the case of time sensitive systems, and contrary to what some people maintaint, that there is no possibility to define time related behaviour in the UML, there is a few ways to show that.

That was it. All my first thoughts on the sequence diagramme and the asynchronous message notations. I had an inclination to cut it into two separate posts, but in the end, I think it’s complete this way.

As always, any criticism, comment, question or idea on what I have left out, or what should I delve into a bit more, or mistakes I made are welcome.

Related articles by Zemanta

• PHX Session #5 : Architecture Without Big Design Up Front (Garibay) (slideshare.net)
• UML & SCRUM Workshop (slideshare.net)
• Usability of UML tools should beat the “pencil and paper” alternative (modeling-languages.com)
• OMG is trying to improve the interoperability of UML/MOF/XMI-based tools (modeling-languages.com)