INCORRECT InitialNode no implicit fork

In the Activity Diagram and model shown above, because (unlike an ExecutableNode) there is no implicit fork (no copy of the token is made), the InitialNode is offering THE SAME control token on both outgoing edges:

UML-2.5.1: 'The outgoing ActivityEdges of an InitialNode must all be ControlFlows. The control token placed on an InitialNode is offered concurrently on all outgoing ControlFlows.'

So it is not determined whether x or y executes! The JoinNode attempt must then "fail", because it can't be reached via both, as shown in the attached simulation mini-video.

We see in the next slides some options for handling this correctly.

Up next

CORRECT InitialNode explicit fork

Notes

Snippets (quotes/extracts)

[UML-2.5.1] An InitialNode shall not have any incoming ActivityEdges, which means the InitialNodes owned by an Activity will always be enabled when the Activity begins execution and a single control token is placed on each such InitialNode when Activity execution sta

[UML-2.5.1] The outgoing ActivityEdges of an InitialNode must all be ControlFlows. The control token placed on an InitialNode is offered concurrently on all outgoing ControlFlows.

[UML-2.5.1] As an ActivityNode may be the source for multiple ActivityEdges, the same token can be offered to multiple targets.

[UML-2.5.1] 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 ... and ExecutableNodes ...).

[UML-2.5.1] 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.

[UML-2.5.1] 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.

Visit also