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.

Answer 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.

Answer 2

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.

Answer 3

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.