Drawing States
Check carefully that the identified “states” are really states. An error, which is often observed, is that artificial states are introduced to get a simulation-step within the Rational Statemate execution semantics (see Incrementing in theTrue States figure).
True states are characterized by the fact you spend time in them; either you are waiting for a signal change or there is a function active while in the state.
●
Statecharts describing the hierarchy of the control activity for System Levels 1 and 2 (refer to Methodology) should be structured in a specific way:
Start with only the major stable states and, if there are any, the transition-states between these states.
Refine the transition states only when readability is maintained, otherwise declutter them.
●
All states within a Statechart should have the same size in height and width (Refer to Graphical Settings/Drawing Preferences). If a bigger size is needed, then the relevant size should be a multiple of the pre-defined “basic” height or width.
●
Avoid dummy names like Idle or Wait.
Use more meaningful names like Wait_for_xxx.
●
If a state is connected to a function
entering / st!(Function_xx)
, the name of the state should reflect this:Function_xx_active
(see the True States figure).
●
●
Use static reactions only for Rational Statemate-specific actions during a transition (refer to Labeling Transitions) or for Rational Statemate-Simulation-specific features as shown in the True Statesfigure.
●
Use explicit
entering / st!(Function_xx), exiting / sp!(Function_xx)
rather thanWithin / Throughout
syntax for flexibility (see the True States figure).