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)

2. Use Cases

Use cases are an interesting part of the UML. They predate the UML by years and for me they are a bit “sticking out”. The actual UML notation while can give a nice diagram does not really provide much information, most of that info is in the textual description of the Use Case – which is the actual hard part of the Use Case business.

People like the “potatos” nonetheless, they look easy, a stick-man here, a potato there, connect them with arrows, and we have a new requirement, lets go code. Yes, I did it too when I started to use them. Unfortunately, while the resulting diagrams would have made nice posters if I only put them in a frame, the practical value was zero. So here is a few common mistakes I met in the last few years.

1. the potatoes and stick men are the focus of the Use Case model, and the textual part is almost completely ignored – a really useful and thorough book is Alistair Cockburn‘s Writing Effective Use Cases.

2. the Use Case model is used as a process flow, with one potato for every step in the process, and <<precedes>> and <<invokes>> associations, or simple associate arrows guiding you through the whole flow. This is evident, how much info does a bubble with a one line description of a 25 step long process give?

Real life example. Sorry.

3. the Use Case model is used for the wrong requirements.
4. the Use Case model is used in the wrong phase of the project.

The 1) and 2) are evident, I would talk about the last two points, 3) and 4).

3. The Use Case model is used for the wrong requirements

So here we can tie the different requirement types with the Use Case model. If we look at either Wiegers’or the BABOK requirement types, we can see that there are only a few kinds of requirements that can be modeled with Use Cases.
The first thing that is evident that Business Requirements cannot be modeled with Use Cases. Neither can Quality of Service Requirements, Assumptions and constraints and Implementation requirements be modeled with Use Cases – or, if you go with Wiegers’grouping, no Business Rule, Quality Attribute, External Interface or Constraint can be modeled.
With a quick note that the existence of External Interfaces can be implied by Actors representing external systems.
The only requirements that can be modeled with Use Cases are the User requirements, and part of the Functional Requirements. A Use Case called “Recovering User Data within 2 seconds” is not exactly a Use Case.

4. the Use Case model is used in the wrong phase of the project.

As Business Requirements cannot be modeled with Use Cases, and Business Requirements are on the top of the chain – they are the very first requirements to discover – it is evident that the “start requirement gathering by drawing a Use Case model” approach is wrong.
And still, I have met it a few times – what is more worrying though is that it does not mean that Use Cases are used to model the Business Requirements. It simply means that Business Requirements are skipped.
As a result we don’t really know why we started the project apart from a hazy “we need a new system”, what is the exact goal to achieve, and how to measure if we are there.
What we will know is that there are a lot of functional requirements, an ever growing list, and we will finish the project if every single one of them is implemented.

It is not the fault of the Use Case, or the UML or such, but if the first requirement we see is a Use Case and it is called “Reserve Hotelroom” then we should suspect that maybe a few steps and requirements are already missing.

The first topic I want to get a go with is the use of Use Cases. But, before I start on the use cases I would like to clear up some basics about the requirements.
I’ve met a lot of people for who there is only one kind of requirement: business requirements, every single one conforms to the same theoretical and well defined structure and can be documented in the same template.
I personally think that it is an oversimplification of the whole thing, and I think it usually means that:

1. half of the requirements are missing
2. a lot of different things are not recognized as requirements

I think that there are different kinds of requirements, with different goals and as it happens with different documentation needs -
I usually go with the Business Requirement, Functional Requirement, Functional Requirement distinctions and for me it works pretty well -, and in the literature about requirements there are different groupings and types listed. I will just look at two sources now, but I think those two are enough to prove this statement.

In Karl E. Wiegers: Software Requirements, Second Edition the requirements are grouped as follow:

• Business Requirements: Business requirements describe why the organization is implementing the system – the objectives the organization hopes to achieve.
• User Requirements: describe the user goals or tasks that the users must be able to perform with the product.
• System Requirements: describes the top-level requirements for a product that contains multiple subsystems.
• Functional Requirements: specify the software functionality that the developer must build into the product to enable users to accomplish their tasks.
• Business Rules: include corporate policies, government regulations, industry standards, accounting practices and computational algorithms.
• Quality Attributes: desired characteristics like usability, portability, integrity,efficiency, and robustness.
• External Interfaces: describe external interfaces between the system and the outside world.
• Constraints: restrictions concerning the development, restricting the choices available to the developer for design and construction of the product.

The Business Analysis Body of Knowledge (BABOK) lists the following types of requirements:

• Business Requirements: are higher-level statements of the goals, objectives, or needs of the enterprise. They describe such things as the reasons why a project is initiated, the things that the project will achieve, and the metrics which will be used to measure its success.
• User Requirements: are statements of the needs of a particular stakeholder or class of stakeholders. They describe the needs that a given stakeholder has and how that stakeholder will interact with a solution. User Requirements serve as a bridge between Business Requirements and the various classes of solution requirements.
• Functional Requirements: describe the behavior and information that the solution will manage. They describe capabilities the system will be able to perform in terms of behaviors or operations-a specific system action or response.
• Quality of Service Requirements: capture conditions that do not directly relate to the behavior or functionality of the solution, but rather describe environmental conditions under which the solution must remain effective or qualities that the systems must have. They are also known as non-functional or supplementary requirements.
• Assumptions and constraints: identify aspects of the problem domain that are not functional requirements of a solution, and will limit or impact the design of the solution.
• Implementation requirements: describe capabilities that the solution must have in order to facilitate transition from the current state of the enterprise to the desired future state, but that will not be needed once that transition is complete.

The groupings overlap in several places, and are the results of long years of experience – in the case of BABOK long years of many people’s experience – so I think that it can be accepted that there is a real need for separating the different kind of requirements. Especially if you ever want to take the CBAP Exam, because that uses the BABOK as the course material.

But if we accept that there are different kind of requirements, with different goals, levels and content, then we have to admit that they need different documentation, different way to model and present them, and that they can not really be put in the same template.

That’s enough about laying down the basic assumptions about requirements, that I will use in the rest of the post, and we can move to the use cases.

Since then I tried to educate myself, keeping up with the new stuff – which means buying a lot of books from amazon, and reading the interweb s. Hungarian publishers are not – or at least were not – too mad about this technology stuff, except when it comes to programming languages. The Gang of Four Design Pattern book took 9 years to publish here in Hungarian. But I digress.

I try to stay up to date, and try to make people improve where ever I go – especially with the “before coding” phases of the project, requirement gathering, design, etc. And then I like tools too. That’s why when Yanic asked if I would do a review of his Trace Modeler application I instantly said yes. And will publish the review the next week. But in the meantime I had a sudden idea – if I have this blog, why not write about UML an it’s use as I see it? I am reviewing a modeling tool that uses UML notations, so I could go a bit into the notation parts too. At the least, there will be some content on the blog. At the most some people get ideas.

It’s my blog, I work with UML, so noone can prevent me doing that. In the next couple of weeks – or, considering my writing speed, months – I will run a series of posts about UML and related stuff.