single super state - Printable Version +- MISRA Discussion Forums (https://forum.misra.org.uk) +-- Forum: MISRA Autocode (https://forum.misra.org.uk/forumdisplay.php?fid=8) +--- Forum: MISRA AC SLSF discussions (https://forum.misra.org.uk/forumdisplay.php?fid=152) +--- Thread: single super state (/showthread.php?tid=781)

single super state - ggentile - 05-10-2010 Following MAAB 2.1 rule db_0137 a chart with single superstate is forbidden. INstead MISRA SLSF rule #39 require 0 to N superstate. We are close to the MISRA rule 39 in fovour of MAAB db_0137, I'd like to have some comment on the decision (we agree to MISRA) not include db_0137. Giacomo Re: single super state - MISRA Reply - 15-10-2010 Just to clarify, MISRA AC SLSF 039A specifies that "a state must have either zero or more than one sub-state." This is effectively equivalent to the MAAB db_0137 rule "A state cannot have only one substate." A single superstate is disallowed in both cases. Re: single super state - ggentile - 16-10-2010 May you clarify the rationale of this rule? Is common to have one super state and more than one state inside. The only matter is in haveing state that contain one state that contain one state and so on.... Giacomo Re: single super state - MISRA Reply - 19-10-2010 The rationale of this rule is to maximize the efficiency of a chart. Any actions within a single state (without any siblings at the same chart level) could be executed by the parent state without recourse to a state scheduler to manage the single state, i.e. the single state is generally unnecessary. A single state at any level of a chart, particularly the root level of a statechart, is often seen to be indicative of an incomplete or erroneous design or implementation. The single instance where we have seen a single state legitimately used is at the root level of a chart to enable the implementation of reset functionality in the chart, which strictly would then require a deviation from MISRA AC SLSF 039A. In this case the single super-state contains all logic for normal operation. A default transition into the state will handle normal entry into the superstate at first execution. A loop-back "reset" transition is placed on the super-state boundary to cause execution flow to exit the super-state and re-enter the super-state upon a reset event occuring. This re-entry causes reset/initialisation logic present via default transitions internal to the super-state to execute. As they say a picture is worth a thousand words, so hopefully the following example will illustrate the thinking behind the above exception.