UML state machine diagrams,
formerly called state chart diagrams in UML 1, depict the dynamic behavior of an
entity based on its response to events, showing how the entity reacts to various
events depending on the current state that it is in. Create a
UML state machine
diagram to explore the nature of a:
Explore the complex behavior of a class, actor, subsystem, or component.
Model real-time systems.
There are guidelines for:
- General issues
Figure 1. A UML state machine
Diagram for a seminar during enrollment.
- 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
- Place The Initial State In The Top-Left Corner
- Place The Final State In The Bottom-Right Corner
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.
- State Names Should be Simple but Descriptive
- Question "Black Hole" States. A black hole state is one that has transitions into it but
- Question "Miracle" States. A miracle state is one that has transitions out of it but
none into it.
Figure 2. The complete lifecycle
of a Seminar.
Figure 3. A top-level state
- Model Substates For Targeted Complexity. Figure 2models the entire lifecycle of a
Figure 1as a collection of substates of a new
composite state, also called a superstate.
- Aggregate Common Substate Transitions
- Create a Hierarchy of State Machines for Very Complex Entities.
Figure 3represents the top-level view andFigure 1depicts a more detailed view.
- Top-Level State Machines Always Have Initial and Final States
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.
- Name Software Actions Using Implementation Language Naming Conventions
- Name Actor Actions Using Prose
- Indicate Entry Actions Only When Applicable For All Entry Transitions
- Indicate Exit Actions Only When Applicable For All Exit Transitions
- Model Recursive Transitions Only When You Want to Exit and Re-Enter the
- Name Transition Events in Past Tense
- Place Transition Labels Near The Source State
- 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:
transition lines going left-to-right
transition lines going right-to-left
of transition lines going down
of transition lines going up
A guard is a condition that must be true in order to
traverse a transition.
- 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.
- Introduce Junctions to Visually Localize Guards.In Figure 2you see that there are two transitions from
Taught as the result of the
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).
- Guards Need Not Form a Complete Set
- Name Guards Consistently