There was intent to allow BA to define richer mode (transition) behavior than the core language (AS5506C 12).
The external_condition construct provides a boolean expression over port_component_reference which allows indication of subcomponent in event (data) ports, reaching arbitrarily down a subcomponent hierarchy. This would seem to be strengthening of the mode_transition_trigger of AS5506C 12. But Annex D.3 (19) says
In other categories of components than threads and subprograms, external conditions specify transition conditions out of execution states, triggered on reception of events, or event data, on event or event data ports. For instance, this type of condition can be used to represent mode transitions in process components.
And Annex D3. (C6)
In behavior transitions, external conditions can be used to describe mode transitions in any component classifier, except those belonging to the category of threads and subprograms. In components of these categories, execute conditions and/or dispatch conditions should be used to describe behavior transitions.
Which contradicts Annex D.3 (33)
Transitions leaving execution states may have transition condition with Boolean expressions, timeout, or otherwise.
Things get further muddled by Annex D.3 (C4)
The behavior annex defines transitions from a complete state that represents a mode in the containing component, then the behavior_condition associated with these transitions must be consistent with the corresponding mode transition triggers.
Because only transitions leaving complete states may use only dispatch conditions by Annex D.3 (L5)
Only transitions out of complete states may have dispatch conditions.
Finally, Annex D.3 (L14)
In the case of a Behavior_Specification annex subclause without an in modes statement, if a complete state identifier is a mode identifier, then all complete state identifiers in that annex subclause must also be mode identifiers.
So, should modes be complete states or execution states?
To resolve the confusion, I propose adding another kind of state, a mode state, from which only transitions with execute_condition may leave, and that execute_condition may not be used in any other transition. Furthermore, a behavior may have complete states or mode states, but not both.
There was intent to allow BA to define richer mode (transition) behavior than the core language (AS5506C 12).
The
external_conditionconstruct provides a boolean expression overport_component_referencewhich allows indication of subcomponent in event (data) ports, reaching arbitrarily down a subcomponent hierarchy. This would seem to be strengthening of themode_transition_triggerof AS5506C 12. But Annex D.3 (19) saysAnd Annex D3. (C6)
Which contradicts Annex D.3 (33)
Things get further muddled by Annex D.3 (C4)
Because only transitions leaving complete states may use only dispatch conditions by Annex D.3 (L5)
Finally, Annex D.3 (L14)
So, should modes be complete states or execution states?
To resolve the confusion, I propose adding another kind of state, a mode state, from which only transitions with
execute_conditionmay leave, and thatexecute_conditionmay not be used in any other transition. Furthermore, a behavior may have complete states or mode states, but not both.