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)

It did not take Yanic Inghelbrecht too much time to point out that his tool is better for sketching sequence diagrams, and asked if I would review his tool, Trace Modeler. Of course I said sure, and it was not because he offered me a personal licence – I just have to tell you that yes, he offered one, also as he wrote in his mail:

Please understand that I do not wish to influence you in any way by this. I’m pretty confident you’ll like it and of course I’m hoping for a favorable evaluation, but above all I hope you’ll give your honest opinion.

So there we go, all transparent and you all know the complete background.

So I just downloaded Trace Modeler, and started to poke around. I have to admit that at first sight I did not like it. The fact that there is no class diagram, so I just have to draw the sequence diagram “in the air” so to speak made me balk. I tried it anyway and after a while it dawned on me that this is a sketch tool, not a design tool, and for that there is no real need for a class diagram. Keeping that in mind I concentrated on how well it supports the sequence diagram sketching.

So after playing with it and poking at it I have a well formed opinion, and it boils down to a list of “Things I like” and a list of “Things I don’t like”. The latter is more like a wish-list and some suggestions. One more thing. I will not show you how to use it, what are the menus and will not tell you what a sequence diagram is – for that there are resources like the Trace Modeler User Manual and the UML Superstructure Specification.

So lets see the likes and dislikes.

Things I like

1. The handling.

   I like it. It is self evident and easy to understand most of the time – the exception see under Things I don’t like – and honestly one of the easiest I have met so far.

2. Diagram Style

   First place to go.Beside the possibility to set up the layout rules – distance between objects, message spacing, layout direction, etc. – you can set whether empty returns are shown or not – I usually hide them, make it less cluttered, but sometimes it’s good to see them – and you can display the Control Flow – with configurable colour, so you can make it bright red and see the control flow from a mile.

3. It’s small and no install

   Really, the whole thing takes up 4.2MB, no installation required, so you can carry it around on a USB stick.

Things I don’t like (suggestions + wishlist)

1. The message dragging

   It is handy and convenient, but there are a few problems:
   - Sometimes the drawing is oversensitive and you have to re-drag the line
   UPDATE: Ok, it was pointed out that you don’t have to drag the arrow, you simply place it over the target line and it will put it there.
   - there are “dead spaces”, which means that between two lifelines the red trace disappears (signaling that it won’t be a ‘self message’) and you have to drag the mouse further right for it to reappear (signaling it will be a message to the next lifeline). This dead zone is about half a centimeter on my screen.

   Solution: you don’t start from the originating object but place the arrow on the target object.
   However, if you do this, it will take a while to discover that you actually can send messages both direction.
   Update: Ok, see above, it is not the solution, it is how it was intended to work.

   I would like it better if there were no dead zone, and the source-target objects would be highlighted, but this deadzone is the result of testing and user feedback, so apparently works for the majority of users.
   

2. Can’t move the end of the arrows.

   One of the more interesting examples in the UML Superstructure specification under the Sequence diagram section is overtaking messages – actually an asynchronous message with a duration constraint, but calling it “overtaking message” sounds more car-race like.

   

   The message CardOut overtakes the message OK in the way that the receiving event occurrences are in the
   opposite order of the sending OccurrenceSpecifications. Such communication may occur when the messages are
   asynchronous.

   But as this is a sketch oriented tool it is not a big loss – just make a note somewhere. And there is a promise that multiple-flow of control, and more will be implemented this year.

So after all the above, and taking into consideration that we are talking about a sketching application, not a full blown CASE tool, I think Trace Modeler is up to that task. It won’t replace any big, integrated CASE tools, but it is perfect when you have to do a quick sketch and paper is not an option.

For a sequence diagram sketchpad it is good. What would be even better if there was an export option to some of the usual CASE formats – Rational Rose, EA, etc. – so after I made the sketch I could import it into my usual case tool and use it – Yanic’s response to this wish was

Unfortunately there is no easy way to do this. XMI was supposed to be a standard way of exchanging UML diagrams and models, but every CASE tool has its own little quirks and inconsistencies so interchanging data is not straightforward.

The sad truth is that he is totally right and I am well aware that the standard is not a standard at all. But I still wish. Wouldn’t it be nice if standards were treated like standards?

So Tracemodeler is definitly on my list of “on-site tools”. And in the end, a 30sec demo from the