State Machine Evaluation of Transitions

Evaluation of Transitions

When Event is sent to State Machine, Stateflows finds all Transitions triggered with this Event's type in current State's tree. Guards of these Transitions are then evaluated, one by one, and first Transition which Guard returns true is fired. That causes Source State to exit, Transition Effect is run, then Target State is entered.

An Internal Transition neither exits its source State nor enters a target State.

stateDiagram-v2
Source : exit / onExit
Source --> Target1 : Event1 [Guard1] / Effect1
Source --> Target2 : Event1 [Guard2] / Effect2
Target1 : entry / onEntry
Target2 : entry / onEntry

Loading

Let's consider above example:

1. Current State of a State Machine is Source,
2. Event Event1 is sent to a State Machine,
3. Guard1 is evaluated, returns false,
4. Guard2 is evaluated, returns true,
5. Source's onExit is called,
6. Effect2 is called,
7. Target2's onEntry is called,
8. Execution is complete with Target2 as new current State of a State Machine.

Else Transitions

When State contains multiple Transitions with various Guards, sometimes it is handy to use Else Transition - a Guard-less Transition which is fired when all other Transitions with the same Trigger fail to fire. Such Transition can be considered a fallback from all of these Transitions.

stateDiagram-v2
Source : exit / onExit
Source --> Target1 : Event1 [Guard1] / Effect1
Source --> Target2 : Event1 [Guard2] / Effect2
Source --> Target3 : Event1 [else] / Effect3
Target1 : entry / onEntry
Target2 : entry / onEntry
Target3 : entry / onEntry

Loading

Let's consider above example:

1. Current State of a State Machine is Source,
2. Event Event1 is sent to a State Machine,
3. Guard1 is evaluated, returns false,
4. Guard2 is evaluated, returns false,
5. Source's onExit is called,
6. Effect3 is called,
7. Target3's onEntry is called,
8. Execution is complete with Target3 as new current State of a State Machine.

Else-ness of Transition is based on a Trigger type, not Transition type!

Nested States

Transitions on deeper active states are evaluated before transitions on their active ancestors.

stateDiagram-v2
state State1 {
	Substate1 : exit / onExit
	Substate2 : entry / onEntry
	Substate1 --> Substate2 : Event1 / Effect1
}
State1 --> State2 : Event1

Loading

Let's consider above example:

1. Current States of a State Machine are State1 / Substate1,
2. Event Event1 is sent to a State Machine,
3. Both available Transitions are Triggered by Event1, but inner Transition has precedence over outer Transition,
4. Substate1's onExit is called,
5. Effect1 is called,
6. Substate2's onEntry is called,
7. Execution is complete with State1 / Substate2 as new current States of a State Machine.

Local Transitions

For the purposes of fine-tuning specific Transition like "from parent state to substate (direct or not)" or "from substate (direct or not) to state" UML specifies that Transitions might be local or external. The difference is this:

• when local Transitions happens:
  • Transition Source will not be exited and reentered if Transition Target is a substate (direct or not) of a Source,
  • Transition Target will not be exited and reentered if Transition Source is a substate (direct or not) of a Target,
• when external (non-local) Transition happens, Transition Source is always exited and Transition Target is always entered.

Stateflows provides a way to change Transition localness by calling SetIsLocal() method on the level of Transition definition:

Definition fragment (inside the builder callback):

    /* fragment of State Machine definition */
    .AddCompositeState("SomeState", b => b
        .AddTransition<TriggerEvent>("Substate", b => b
            .SetIsLocal(false)
        )
        .AddState("Substate")
    )

By default, all Transitions in Stateflows State Machines are local.