Style Guidelines for Statecharts : Drawing States

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

 

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).

Break long names into two or more lines.

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 than Within / Throughout syntax for flexibility (see the True States figure).