Junction
A junction is an element of a state machine. It is processed when it is reached by one of the incoming transitions. The junction is used to merge multiple incoming transitions or to split a incoming transition into multiple outgoing transitions.
A junction belongs to a region.
Symbol
A junction is shown as a small black filled circle.
Symbol in context
Example
Even though the junction is outside of the 'Composite state 1', taking the compound transition from 'Simple State 1' to the junction and then to 'Simple State 2' does not cause exiting and re-entering of the composite state. For the calculation of what states are exited and entered only the main source and the main target are considered. The parents of intermediate vertices are ignored!
Characteristics
-
A junction has at least one incoming transition and one outgoing transition.
-
Transitions exiting a junction cannot have a trigger.
-
Just the outgoing transitions with a guard that evaluates to true are enabled. If more than one transition is enabled, a sole transition is chosen arbitrary from the enabled outgoing transitions.
-
At least one outgoing transition must have a guard that evaluates to true when the junction is reached, else the state machine is ill-formed.
-
It is recommended to define one outgoing transition with no guard (an “else”).
-
A junction has at most one outgoing transition with an "else" guard.
-
A junction is a static conditional branch (in contrast choice is a dynamic conditional branch).
-
If a junction is placed after a choice, it must have at least one enabled outgoing transition, else it is an ill-formed state machine and will throw an exception.
Interpretation of and deviation from the UML specification
yasmine deviation
A junction outside of a state, but with the incoming transitions emanating from the state and the outgoing transitions targeting children of the state, will not cause exiting and re-entering of that state in a compound transition.
Rationale
According to the UML specification (if no entry and/or exit points are involved) first the source state(s) are exited, then the transitions are taken, and then the target state(s) are entered (see 15.3.14 Transition, Semantics, Transition execution sequence). If entry and/or exit points are involved, entrering or exiting of states may be interrupted and some transitions may be executed before entry points or after exit points. Still all source states are exited before any target state is entered.
If a junction contains an exiting transition that enters a state that was previously left by a transition leaving that very state this logic would be changed. It would be possible to have composite transitions that exit a state, enter the same state, leave it again and then enter another. This would significantly complicate the transition execution logic. As this is only a corner case (which - in our opionion - is not very relevant in practice and that is not mentioned/defined in the documentation) we decided to handle it as described above. This keeps the transition logic sane and simple without degrading performance in state machines where this scenario does not appear (which should be almost always be the case).
The logic stays simpler because in order to figure out which states need exited and entered, only the main source state and the main target state have to be taken into consideration. This would not be true, if every intermediate transition target (the junction in our case) would have to be taken into consideration.