UML: activity diagram control flow

Question

I have found in internet the following activity diagram:

I can't understand why from Recieve order action there are two control flows (to Ship order and Bill customer). Are they parallel? Then why there is NOT fork. How to understand this diagram? Please, explain.

score 1 · Answer 1 · answered Dec 12 '15 at 08:48

1

This is simply a bad example.

Judging from the context there should be a fork to indicate that both Ship order and Bill customer should happen in parallel.

Then there should be a Join before Send confirmation to indicate that both flows should have finished before the Send confirmation is executed.

answered Dec 12 '15 at 08:48

Geert Bellekens

12,788
2
23
50

1

Thank you for your answer. I also thought this way but one thing what confuses me is that this is from book UML reference by Rumbaugh - one of the creator of UML. – Pavel_K Dec 12 '15 at 08:56
Even the Pope may be in error. But he'll never admit. As Geert said: a really bad example. – qwerty_so Dec 12 '15 at 12:02
It's not so much an error as it is valid UML, just a badly chosen example – Geert Bellekens Dec 12 '15 at 14:36
I see it as erroneous. See my comment in Jim's answer. – qwerty_so Dec 12 '15 at 21:09
@Thomas: it's not erroneous. Please see my response to your comment under my answer. – Jim L. Dec 13 '15 at 01:04
So the Pope was not in error (see comment in the other answer). However, for clarity sake, I prefer the use of a fork. – qwerty_so Dec 13 '15 at 10:56

Jim L. · Accepted Answer · 2015-12-13T22:16:32.310

0

It's perfectly valid UML 2. The first action requires no tokens, so it can start immediately. When the first action finishes, it offers tokens to two other actions and they can start. The last action cannot start until all required tokens are offered. When the last action is done, the containing activity is also done.

Forks just copy tokens. Joins just merge tokens. Thus, forks and joins are often unnecessary.

Please see Conrad Bock's excellent series of articles on activity diagrams in the Journal of Object Technology.

edited Dec 13 '15 at 22:16

answered Dec 12 '15 at 19:02

Jim L.

6,177
3
21
47

Thank you for your answer. If I understand token is some data that is passed between objects. How did you understand that there are tokens? – Pavel_K Dec 12 '15 at 19:07
Data tokens are distinct from control tokens. The UML spec describes how activities work using tokens. That's how I know. Conrad Bock's write up explains all this even more clearly. – Jim L. Dec 12 '15 at 19:09
That's not possible. When an activity ends, it offers all control tokens. – Jim L. Dec 12 '15 at 21:09
In addition, ship order does indeed require a control token to start. – Jim L. Dec 13 '15 at 01:01
Now that I'm on my laptop, I found the first link to Conrad's series and added it to my answer. I strongly urge anyone who uses UML 2 activity diagrams to read these articles. – Jim L. Dec 13 '15 at 22:18
@qwerty_so at least in the current version of UML a token offered on multiple outgoing edges may only be consumed by one follow-up action (see my answer for reference). I think, at least now, your first comment is correct. – Johnson Mar 13 '20 at 08:38
@johnson: In the OP diagram, two tokens are offered, not one. – Jim L. Mar 13 '20 at 11:20
I didn’t notice that he posted a new answer. I’ll take a look. – Jim L. Mar 13 '20 at 22:53
@qwerty_so: I commented on his answer with a quote from the spec. – Jim L. Mar 14 '20 at 02:10

score 0 · Answer 3 · edited Mar 13 '20 at 22:33

0

I did not check if this is a recent amendment to the UML specification but the current version 2.5 (chapter 15.2.3.2) states (emphasis set on my own):

As an ActivityNode may be the source for multiple ActivityEdges, the same token can be offered to multiple targets. However, the same token can only be accepted at one target at a time (unless it is copied, whereupon it is not the same token, see ForkNodes in sub clause 15.3 and ExecutableNodes in sub clause 15.5). If a token is offered to multiple ActivityNodes at the same time, it shall be accepted by at most one of them, but exactly which one is not completely determined by the Activity flow semantics. This means that an Activity model in which non-determinacy occurs may be subject to timing issues and race conditions. It is the responsibility of the modeler to avoid such conditions in the construction of the Activity model, if they are not desired.

From that point of view, I would argue that @Jim L.'s answer might be deprecated. I assume that, at least in the current version of UML, the diagram in question does not reflect the modeler's intention. A fork seems to be not only the clean way but the only right way to go, now.

edited Mar 13 '20 at 22:33

qwerty_so

35,448
8
62
86

answered Mar 12 '20 at 10:09

Johnson

306
1
15

You are right. I put an eemphasis on the important sentence. I guess that this was already present when this question was asked first. – qwerty_so Mar 13 '20 at 22:35
From the same section: “While executing, an ExecutableNode is considered to hold a single control token indicating it is executing. When it completes execution, **it offers control tokens on _all_ outgoing ControlFlows**. All incoming and outgoing ActivityEdges of an ExecutableNode must be ControlFlows.” (Emphasis mine) – Jim L. Mar 14 '20 at 02:07
@JimL. But exactly that is constrained with **my** emphasis. Only one token will be accepted and so the machine blocks... – qwerty_so Mar 14 '20 at 08:50
@qwerty_so: each of the multiple tokens can only be accepted by one Activity Node. – Jim L. Mar 14 '20 at 13:01
@JimL. Well, I'm no native English speaker. But **at most one of them** means to me: once one is accepted, the others will not be accepted. And further in the text **but exactly which one is not completely determined** settles that. – qwerty_so Mar 14 '20 at 22:48
@qwerty_so: Rather than arguing over how to interpret the spec, might I suggest you download a free trial version of the Cameo Simulation Toolkit, which accurately executes and steps through activity models? A spec is not meant for users, it's meant for implementors, and they've already done the hard work of interpreting it accurately. https://www.nomagic.com/product-addons/magicdraw-addons/cameo-simulation-toolkit – Jim L. Mar 14 '20 at 22:56
@JimL. Well, it's not the tool that makes the specification. It's OMG. I also got caught by thinking that EA perfectly matches UML. It's good in that, but not 100%. – qwerty_so Mar 14 '20 at 22:59
No Magic prides itself on following the spec accurately. Their customers insist on it. – Jim L. Mar 14 '20 at 23:03
@JimL. This might be an example for the discrepancy between a formal specification and its interpretation in practice. Maybe the tool just relaxes the specification as allowing non-deterministic behavior here might not be desirable in practice. Talking about determinism, the point here is that, while the given diagram is valid with respect to the syntax of UML, I would strongly suggest not to model non-determinism and rely on a tool to interpret it the way I need. – Johnson Mar 17 '20 at 11:00
The spec, as written, seems clear to many others and to me, but you have an excellent point about the superiority of modeling behavior deterministically. – Jim L. Mar 17 '20 at 13:09

UML: activity diagram control flow

3 Answers3