Expressing both concurrency and time in activity diagrams

Question

I am not sure how to express my scenario using activity diagrams:

What I am trying to visualise is the fact that:

• A message is received
• Two independent and concurrent actions take place: logging of the message and processing the message
• Logging always takes less time than processing

The first activity in the diagram is correct in the sense that the actions are independent but it does not relay the fact that logging is guaranteed to take less time than processing.

The second activity in the diagram is not correct because, even if logging completes before processing, it looks as though processing depended on the logging's finishing first and that does not represent the reality.

Here is a non-computer related example:

• You are a novice in birdwatching, trying to make your first notes in your notebook about birds passing by

• A flock of birds approaches, you try to recognise as many details as possible

• You want to write down the details in your notebook, but wait, you begin to realise that your theoretical background does not work in practice, what should be a quick scribble actually amounts to nothing in the end because you did not recognise anything

• In the meantime, the birds majestically flew away without waiting for you, the activity is gone

• Or maybe you did actually write it down, it took you only a moment and the birds are still nearby, slowly flying away, ending the activity again after some time

• Or maybe you were under such awe that you just kept watching at them, without taking any notes - they fly away, disappearing in the horizon, ending the activity

• After a few hours, you have enough notes and you come home very happy - maybe you did not capture everything but this was enough to make you smile anyway

I can always add a comment to a diagram to express it all somehow but I wonder, is there a more structured way to express what I described in an activity diagram? If not an activity diagram then what kind of a diagram would be better suited in your opinion? Thank you.

Answer 1

Your first diagram assumes that the duration of logging is always shorter than processing:

• If this assumption is correct, the upper flow reaches the flow-final node, and the remaining flows continue until the first reaches the activity-final node. Here, the processing continues and the activity ends when the processing ends. This is exactly what you want.
• But if once, the execution would deviate from this assumption and logging would get delayed for any reason, then the end of the processing would reach the activity-final node, resulting in the immediate interruption of all other ongoing activities. So logging would not complete. Maybe it’s not a problem for you, but in most cases audit expects logs to be complete.

You may be interested in a safer way that would be to add a join node:

The advantage is that the activity does not depend on any assumptions. It will always work:

• whenever the logging is faster, the token on that flow will wait at the join node, and as soon as process is finished the activity (safely) the join can happen and the outgoing token reaches the end. This is exactly what you currently expect.
• if the logging is exceptionally slower, no problem: the processing will be over, but the activity will wait for the logging to be completed.

This robust notation makes logging like Schroedinger's cat in its box: we don't have to know what activity is longer or shorter. At the end of the activity, both actions are completed.

Time in activity diagrams?

Activity diagrams are not really meant to express timing and duration. It's about the flow of control and the synchronization.

However, if time is important to you, you could:

• visually make one activity shorter than the other. This is super-ambiguous and absolute meaningless from a formal UML point of view. But it's intuitive when readers see the parallel flow (a kind of sublminal communication ;-) ) .
• add a comment note to express your assumption in plain English. This has the advantage of being very clear an unambiguous.
• using UML duration constraints. This is often used in timing diagram, sometimes in sequence diagrams, but in general not in activity diagrams (personally I have never seen it, but UML specs doesn't exclude it either).

Time is something very general in the UML specs, and defined independently of the diagram. For example:

8.4.4.2: A Duration is a value of relative time given in an implementation specific textual format. Often a Duration is a non- negative integer expression representing the number of “time ticks” which may elapse during this duration.

8.5.1: An Interval is a range between two values, primarily for use in Constraints that assert that some other Element has a value in the given range. Intervals can be defined for any type of value, but they are especially useful for time and duration values as part of corresponding TimeConstraints and DurationConstraints.

In your case you have a duration observation for the processing (e.g. d), and a duration constraint for the logging (e.g. 0..d).

8.5.4.2: An IntervalConstraint is shown as an annotation of its constrainedElement. The general notation for Constraints may be used for an IntervalConstraint, with the specification Interval denoted textually (...).

Unfortunately little more is said. The only graphical examples are for messages in sequence diagrams (Fig 8.5 and 17.5) and for timing diagrams (Fig 17.28 to 17.30). Nevertheless, the notation could be extrapolated for activity diagrams, but it would be so unusal that I'd rather recommend the comment note.