As Thomas Kilian described here, normal behavior of nodes of Activity diagrams with tokens is:
A node becomes active when at all of its incoming
Inf
Merge
- and DecisionNode
s look the same, but are different elements: .
In a diagram you can only distinguish both by looking at the incoming and outgoing InformationFlow
s. The first has multiple incoming and one outgoing while the second has the opposite relation. A MergeNode
accepts any incoming token and forwards it directly to its single outgoing InformationFlow
. So unlike Action
s it will not wait for all tokens. The DecisionNode
in contrast accepts only a single token and lets it pass to only one of its outgoing InformationFlow
s. It is the modeler's responsibility to set guards in a way that only one evaluates to true. If there are more (or even unguarded) InformationFlow
s the token will take any arbitrary free route.
Fork
and Join
are also two different elements which look the same: (or vertically).
You can also distinguish them by the number of in-/outgoing InformationFlow
s. Fork
has one in and multiple out and Join
vice versa. A Fork
will send as many tokens as it has outgoing InformationFlow
s once a token arrives at its single incoming InformationFlow
. The Join
will (like Action
s) wait for tokens arrive at all of its incoming InformationFlow
s. Only then it will emerge a single token at its single outgoing InformationFlow
.
So while Merge
- and DecisionNode
s control the flow of a single token (execution path) Fork
and Join
are used to start and synchronize parallel execution paths.