UML State Machine Diagrams: Diagramming Guidelines

• Explore the complex behavior of a class, actor, subsystem, or component.
• Model real-time systems.

There are guidelines for:

1. General issues
2. State
3. Substates
4. Transitions and Actions
5. Guards

1. General

Figure 1. A UML state machine Diagram for a seminar during enrollment.

1. Create A state machine When Behavior Differs Based on State. A Seminar object is fairly complex, reacting to events such a enrolling a student differently depending on its current state, as you see depicted in Figure 1.
2. Place The Initial State In The Top-Left Corner
3. Place The Final State In The Bottom-Right Corner

2. State Guidelines

A state is a stage in the behaviour pattern of an entity. States are represented by the values of the attributes of an entity. For example, in Figure 1 a seminar is in the Open For Enrollment state when it has been flagged as open and there are seats available to be filled.

1. State Names Should be Simple but Descriptive
2. Question “Black Hole” States. A black hole state is one that has transitions into it but none out.
3. Question “Miracle” States. A miracle state is one that has transitions out of it but none into it.

3. Substate Modeling Guidelines

Figure 2. The complete lifecycle of a Seminar.

Figure 3. A top-level state machine for Seminar.

1. Model Substates For Targeted Complexity. Figure 2models the entire lifecycle of a Seminar, depicting Figure 1as a collection of substates of a new Enrollment composite state, also called a superstate.
2. Aggregate Common Substate Transitions
3. Create a Hierarchy of State Machines for Very Complex Entities. Figure 3represents the top-level view andFigure 1depicts a more detailed view.
4. Top-Level State Machines Always Have Initial and Final States

4. Transitions and Actions

A transition is a progression from one state to another and will be triggered by an event that is either internal or external to the entity being modeled. For a class, transitions are typically the result of the invocation of an operation that causes an important change in state, although it is important to understand that not all method invocations will result in transitions. An action is something, in the case of a class it is an operation, that is invoked by/on the entity being modeled.

1. Name Software Actions Using Implementation Language Naming Conventions
2. Name Actor Actions Using Prose
3. Indicate Entry Actions Only When Applicable For All Entry Transitions
4. Indicate Exit Actions Only When Applicable For All Exit Transitions
5. Model Recursive Transitions Only When You Want to Exit and Re-Enter the State
6. Name Transition Events in Past Tense
7. Place Transition Labels Near The Source State
8. Place Transitions Labels Based on Transition Direction. To make it easier to identify which label goes with a transition, place transition labels according to the following heuristics:

• Above transition lines going left-to-right
• Below transition lines going right-to-left
• Right of transition lines going down
• Left of transition lines going up

5. Guards

A guard is a condition that must be true in order to traverse a transition.

1. Guards Should Not Overlap. The guards on similar transitions leaving a state must be consistent with one another. For example guards such as x <0, x=0, and x>0 are consistent whereas guard such as x <= 0 and x>= 0 are not consistent because they overlap.
2. Introduce Junctions to Visually Localize Guards .In Figure 2you see that there are two transitions from Being Taught as the result of the student dropped event, whereas there is only one in Figure 3– the transitions are combined into a single one that leads to a junction point (the filled in circle).
3. Guards Need Not Form a Complete Set
4. Name Guards Consistently