Does the state machine define the behavior for reactive classes and use cases?
Every class or use case that responds to incoming events should have an explicit state machine created. |
Does every level of nesting have a default state?
Does every composite state contain more than one nested state?
An exception to this rule is when the state machine is for a base class which is expected to be extended in subclasses by
adding additional nested states. |
Does every and-state have a default state?
Does every and-states represent independence of execution and not OS threads?
Active classes are the primary means in the UML to represent OS threads not and-states. |
Are all events for a state machine synchronous or all asynchronous?
Use of both synchronous and asynchronous events in the same state machine can lead to race conditions, so mixing them in
the same state machine should be done with great care. |
Are all state and event names drawn from the problem domain?
The state machine should usually map closely to the problem concepts being represented. |
Are composite and and-states used when they simplify the overall state machine?
The use of nesting and orthogonality should be restricted to circumstances in which they simplify the state machine.
And-states can always be separated out into separate classes (with relations to the original) but that may or may not
simplify the behavioral representation. In general, separate classes are preferred unless the and-states are inherently
tightly-coupled. Also, it is usually preferable to use and-states for use case state machines. |
Are race conditions addressed when the same event occurs in different and-states?
A Race Condition can arise when the same event is used in orthogonal and-states. Such circumstances should be examined to
ensure that they do not lead to race conditions. |
Is the guard on the same conditional pseudostate orthogonal?
Guard conditions should be non-overlapping, so that it is clear which path is taken; for example [x>0] and <x <=)]
are orthogonal, but [x>0] and [x>10] are not. |
Do guards have side effects?
A guard should not change anything - whether it is a state, value of other condition - due to its execution. |
Are actions assumed to execute after guards?
In UML state machines, guards are always executed prior to actions. |
Is transition flow primarily top-bottom and left-right?
This isn't always possible but when it is, it makes the diagram easier to read. |
Are most states conditions in which the context waits for an event of interest?
This isn't universally true since occasionally states are added to force a run-to-completion step, but the vast majority of
states wait for events of interest. |
Is every state reachable?
Are black-hole states avoided?
Avoid states that have no exiting transitions. If a state machine terminates, it should transition to a terminal
pseudostate. |
|