UML25 — UML 2.3: Transitions outgoing junction vertexes should be allowed to have triggers

The Superstructure 2.3 mentions (15.3.14, page 573) a constraint for transitions:

“Transitions outgoing pseudo states may not have a trigger (except for those coming out of the initial pseudo state).”

I think this constraint is too limiting.

First of all, it is not observed even in the specification:

On page 546 it says about state lists (15.3.9, page 546):

“Multiple trigger-free and effect-free transitions originating on a set of states and targeting a junction vertex with a single

outgoing transition may be presented as a state symbol with a list of the state names and an outgoing transition symbol

corresponding to the outgoing transition from the junction.”

Conclusion:

1) the transition from each of the states in the list cannot have a trigger

2) the constraint says, that the transition from a junction vertex also cannot have a trigger

==> the transitions out of state lists cannot have triggers

However In figure 15.27 and 15.28 such triggers are shown (e, f, logCard, logVerify).

Second and more importantly, the described situation of “multiple transitions originating on a set of states and targeting a junction vertex” is quite common and therefore should be allowed, whether or not the modeler wants to use state lists.

Suggestion

Transitions from junction vertexes should be an exception to the constraint above. So the constraint on transitions needs to be reformulated:

Page 573: “Transitions outgoing pseudo states may not have a trigger (except for those coming out of the initial or of junction pseudo states).”

Then another constraint needs to be added

Page 573: “The outgoing transitions of a junction pseudo state may have triggers only, when the incoming transitions originate from states and don’t have triggers.”

Adding triggers to transitions emanating from junction points would contradict the fundamental run-to-completion
semantics of UML. This would require the execution of a compound transition chain, which is executed in a single
run-to-completion step by definition, to stop in “mid-stream” at the junction pseudostate to await the arrival of new
events.
There is nothing in UML preventing transitions emanating from different source states to converge on a common join
point (that is what junction points are for), which I think is the capability that the submitter is really asking for. It
is indeed a very common situation. These transitions may have different triggers or, quite often the same trigger.
In the latter case, AND ONLY IN THAT CASE, it is possible to use the state-list notation. However, in that case,
the common trigger is used for the originating “transition” that goes to the common junction point (“transition” is in
quotes here, because it is really just a notational shortcut for the multiple transitions that share the same trigger but
originate from different states). From there onwards, it is possible to have different outgoing transitions with different
guards (but not different triggers) and different effect behaviors.
Note that neither figure 15.27 nor figure 15.28 are examples of the case where a common junction point is the target
of the “transition” originating from a state list (instead, they terminate on a State).
Disposition: Closed - No Change