[SOLVED] Where does a State machine go when both guard conditions on leaving transitions are false?

Edited - the ultimate (but long) answer

The question at stake in this edge case

Normally, an exit action cleans the situation before leaving a state. It's therefore uncommon in real life to have a cleanup action that might affect a transition.

Assuming that x is a property not accessed by any other concurrent state machine, we can follow the diagram and see that the machine enters the first states with x being successively 0, 2, 4, 6, until it enters with x=8 the state with two outgoing transitions.

The edge case is that the exit action could have an impact on the condition of the guard. The key question is then whether the guard is evaluated before or after the exit behavior:

if the guard is evaluated before exiting the state, x is 8 and the [x<9] would be true and the transition fire.
if the guard is evaluated after exiting the state, x is 9 and both guards are false, which means that the state would not be exited, and hence x would stay at 8, end of the game forever.

Unauthoritative answer

Unfortunately the UML specs are not super-clear in this regard. I'd expected a clear statement about when the guard is evaluated, but the information is diluted over several paragraphs and subject to different interpretations (see comments exchanged with qwerty_so).

So I ended up looking at The UML user guide, a book that is not authoritative and no longer aligned with the latest UML specs, but which has the advantage of being written very clearly by the inventors of UML before OMG made it very abstract.

Their message is clear: the transition guard is evaluated when an trigerring event matching the transition is received. This means that it is evaluated before the exit behavior, in line with the logic exposed by qwerty_so.

The question then remains when no triggering event is specified, although we can understand that it has to do with the state being ready to exit.

What do the specs say

Pager 315 of the UML 2.5.1 specs we read that:

A Transition may have an associated guard Constraint. Transitions that have a guard which evaluates to false are disabled.

But what are the enabled transitions? The UML specs require in the section about run-to-completion several conditions and in particular that:

(...) there exists at least one full path from the source state configuration to either the target state configuration or (...) in which all guard conditions are true

The full path from source to target requires to leave the state. P 311/312 of the UML 2.5.1 specification, explain in this regard that:

Regardless of how a State is exited, the StateMachine is deemed to have “left” that State only after the exit Behavior (if defined) of that State has completed execution.

So, this would mean that there is no path that is enabled, because exiting would mean x to be 9, and both guards would evaluate to false. This was the conclusion of my initial answer. But the contradiction with the user's guide left me no sleep.

Reading and reading again, I finally found two other relevant paragraphs. The first one explains the case of unguarded simple transitions when no triggering event is specified (P.314):

A special kind of Transition is a completion Transition, which has an implicit trigger. The event that enables this trigger is called a completion event and it signifies that all Behaviors associated with the source State of the completion Transition have completed execution. In case of simple States, a completion event is generated when the associated entry and doActivity Behaviors have completed executing.

The key in this paragraphe above, is that the exit is not mentioned in the completion of the state. This allowed me to make the link with The UML user's guide: The event triggering the transition is when the entry and do are completed, independently of exit.

Another paragraph about the guard mentions compound transition. I initially thought that the "compound transition" referred to a special case with sub-state machines or composite states that would not be relevant in our case:

Guards are evaluated before the compound transition that contains them is enabled, unless they are on Transitions that originate from a choice Pseudostate. In the latter case, the guards are evaluated when the choice point is reached.

It appears however that the "compound transition" corresponds to the traversal of machine between two stable configurations. It is also explained that one of the case of a compound transition is the completion transition:

If we put the two together, this means that the guard is evaluated before the exit behavior. This is complex but unambiguous and overrides my former interoperation based on the "complete path".

Conclusion

Your machine would fire the transition with the guard x<9 and would then do another loop and then fire the one with >=10 and finally reach the end.

The specs are very tricky to read in that matter. It's true that they cover a broad number of cases, but there is already a note (showing that it was not sufficiently clear). This note deservers to be amended:

Transition guards

A Transition may have an associated guard Constraint. Transitions that have a guard which evaluates to false are disabled. Guards are evaluated before the compound transition that contains them is enabled, unless they are on Transitions that originate from a choice Pseudostate. In the latter case, the guards are evaluated when the choice point is reached. A Transition that does not have an associated guard is treated as if it has a guard that is always true.

NOTE. A completion Transition may also have a guard, in which case the guard is evaluated independently of the exit behavior.