semantics precision on final nodes in orthogonal regions

[jdeantoni]

I found a potential semantic hole in yakindu for final nodes in orthogonal states.

here is the example:

According to the documentation here: https://www.itemis.com/en/yakindu/state-machine/documentation/user-guide/quick_ref_final_state:

A final state denotes the end of the execution flow of a state machine or region. It can have multiple incoming transitions but no outgoing ones. Each region may contain at most one final state. In case of orthogonal regions, the execution flow stops when all regions' final states have been reached.

However, it is not clear when the transition from the orthogonal state should be taken ? For now it is taken as soon as the first final node is reached in one of the internal region. It seems strange to me since this behavior is encodable with exit nodes.

Not that in QT, they use the done.state.id stipulated in the scxml norm

(When all of the children reach final states, the element itself is considered to be in a final state, and a completion event done.state.id is generated, where id is the id of the element.)

Then my question is: how can I wait for all regions to be in a final state like in Qt ? Shouldn't it be the default behavior of the yakindu diagram above ?

[jdeantoni]

any idea ? interest ?

[terfloth]

@jdeantoni Thank you for the problem description. You unveiled a bug and a functional hole.

First the transition StateA --always--> StateB is taken before s1 or s2 have the chance to react. This is due to the fact that parent-first-execution is active which should not be the case unless you specify it explicitly. So this is a bug which we will fix with the next bugfix release.

Second you can check for active states in guards. But the final states are not provided as options. These are simply missing in the list of state identifiers. This is the missing functional aspect, We will add those identifiers so that you can specify:

`[ active( StateA.r1._final_) && active (StateA.r2._final_)]`

For our SCXML-statecharts (SCXML domain assigned) we consider to add the done.state.XXX pattern.

[terfloth]

The issue related to the default execution precedence is fixed with release 4.0.4. Thus this issue will be closed.

The remaining topics relating to checking for final states are captutered by the tickets #3217 and #3218. These are scheduled for 4.1 release