State machine handling in model inheritance¶

State machine handling between parent and child can take 3 forms:

Parent has a statemachine, and the child modifies functionality and/or appends states
Parent has a statemachine but not the child. All states are inherited by the child, which calls parent functions for state transitions
Child has a statemachine but not the parent. Only the child has state transition logic and state machine

In all cases, state transitions should always be initiated from the child.

In the first 2 cases both the parent and child tables will have a rowstate column. If the child and parent has the same state, the values will be the same. If the child has a child state added, which is entered, the child will have the child state value, but the parent will still have the parent state value, since it does not know about any child states. If child states are hooked into the parent states from the child, proper care needs to be taken to make sure the child state hooks back into the parent states properly, otherwise there might be a mismatch in the parent/child states. It is possible to define this in a way that is not consistent, the framework does not detect all possible definition inconsistencies.

Here is some more detailed information about the 3 scenarios listed above.

Parent has a statemachine, and the child modifies functionality and/or appends states¶

The child can modify transition conditions and add actions, and/or append states to the parent statemachine. The child only need to add the statemachine definitions that differs from the parent state machine, the whole parent state machine definition does not have to be copied.
Example where the child has added an additional check and an additional action to the transition.

state ParentStart {
   on ToParentPrepare [AdditionalChildCheck] do AddtionalChildAction;
}

When redeclaring a state on the child that already exists in the parent, in order to modify functionality, the statename will not be bold. This way it is easy to identify which states are added to the child state, and which states that already exists in the parent.

New states can also be added to the child:

state ParentStart {
   on ToChildBeforePrepare transitionTo ChildBeforePrepare;
}
state ChildBeforePrepare {
   ...
}

In this example, to hook back into the parent state machine, we must reuse the same event and state that exists in the parent, for example

state ChildBeforePrepare {
   on ToPrepare transitionTo ParentPrepare;
}

If the event does not exist in the parent, the parent state will not change, so it is important to make sure the transition is correct also from the parent statemachine. It is possible to transition to a state in the child, without the parent state being transitioned correctly. There should not be transitions being done in the child statemachine to parentstates without using the parent state events. If a child has many states in between 2 parent states the states can be changed freely, as it preserves the correct parent state.

Parent has a statemachine but not the child. All states are inherited by the child, which calls parent functions for state transitions¶

The child get the transition events generated by the code generator, and there is an internal child state machine that forwards the calls to the parent.

Child has a statemachine but not the parent. Only the child has state transition logic and state machine¶

Works like a regular state machine, but the parent is not aware of the child having any states

Important note¶

All statechanges must be initiated from the child. There is no mechanism in the parent to signal state changes to the child, but the child communicates state changes with the parent.