Section 8.2. States

8.2. States

States model a specific moment in the behavior of a classifier. This moment in time is defined by some condition being true in the classifier.

States model a situation in the behavior of a classifier when an invariant condition holds true. Put more simply, a state is a "condition of being" for the state machine and, by association, the classifier that's being modeled. For example, a coffee machine could be "Grinding Beans," "Brewing," "Warming Coffee," "Dispensing," etc. A state can represent a static situation, such as "Waiting for Username" or a dynamic situation where the state is actively processing data, such as "Encrypting Message."

A state is shown as a rectangle with rounded corners. The name of the state is written inside the rectangle. Figure 8-3 shows a simple state.

Figure 8-3. A simple state

A state name may be placed outside of the rectangle in a tab notation when showing composite or submachine states (see "Composite States" and "Submachine States"). You should either use the tab notation or place the name inside the state; don't do both. Figure 8-4 shows a state using a tab for the state name.

Figure 8-4. A state with its name in a tab

Within the rectangle a state can be divided into compartments as needed. UML defines the following compartments:

Name

Shows the name of the state. This should not be used if the name is placed in a tab.

Internal activities

Shows a list of internal activities that are performed while in the state. See "Activities" for the syntax.

Internal transitions

Shows a list of internal transitions (see "Transitions") and the events that trigger them. Write an internal transition as:

     event ( attributeList ) [ guard condition]/ transition

The attribute list, which is optional, maps the event's parameters to the given attributes of the classifier. The guard condition is also optional, but, if present, must be enclosed by square brackets.

The same event may be listed multiple times as long as each entry has a unique guard condition for the transition.

Figure 8-5 shows a state with compartments.

Figure 8-5. A state with compartments

A state can be either active or inactive. A state is considered active as soon as it is entered because of some transition. Similarly, a state is considered inactive immediately after leaving the state.

UML defines three types of states:

Simple states

Simplest of all states, they have no substates. All the example states used so far in this section are simple states.

Composite states

Have one or more regions for substates. A composite state with two or more regions is called orthogonal.

Submachine states

Semantically equivalent to composite states, submachine states have substates that are contained within a substate machine. Unlike composite states, submachine states are intended to group states, so you can reuse them. Composite states are typically specific to the current state machine.

Composite and submachine states are explained in more detail in the following subsections.

8.2.1. Composite States

A composite state is a state with one or more regions. A region is simply a container for substates. A composite state with two or more regions is called orthogonal.

A composite state may have an additional compartment called the decomposition compartment. A decomposition compartment is a detailed view of the composite state where you can show a composite state's regions, substates, and transitions. Figure 8-6 shows a composite state with a single region.

Figure 8-6. A composite state with one region

You may hide the decomposition compartment to increase the clarity of a diagram. If you hide the compartment, you can use the composite icon to indicate that the state's decomposition isn't shown on this diagram. Figure 8-7 shows a composite state with the decomposition compartment hidden.

Figure 8-7. Composite state with composite icon

You may place states within a region of a composite state to represent internal substates. A substate that isn't contained in another state is called a direct substate, and a substate contained within other substates (resulting in recursive, composite states) is called an indirect substate.

A composite state is considered active when the state machine is in any of the composite's substates. When a composite state is active, the tree of active states, starting with the composite state itself and working down to the current substate, is called the state configuration. For example, a state configuration for Figure 8-6 could be Dispensing->Releasing drink.

8.2.1.1. Regions

A region is shown using a dashed line dividing the decomposition compartment. You may name each region by writing its name within the region's area. Figure 8-8 shows a composite state with two regions.

Figure 8-8. A composite state with two regions

Each region has its own initial pseudostate (see "Pseudostates") and a final state. A transition to a composite state is a transition to the initial pseudostate in each region. Each region within a composite state executes in parallel, and it is perfectly acceptable for one region to finish before another. A transition to the final state of a region indicates completing the activity for that region. Once all regions have completed, the composite state triggers a completion event and a completion transition (if one exists) triggers.

8.2.2. Submachine States

Submachine states are semantically equivalent to composite states in that they are made up of internal substates and transitions. UML defines a submachine state as a way to encapsulate states and transitions so that they can be reused. A submachine state simply means that another state machine, a submachine state machine, is contained by the state. For example, the process of establishing a TCP/IP connection can be encapsulated into its own state machine, and that state machine can then be embedded as the first submachine state of a state machine modeling a web page request.

A submachine state is shown in the same rounded rectangle as any other state, except you show the name of the state, followed by a colon (:), followed by the name of the referenced submachine. Figure 8-9 shows a submachine state.

Figure 8-9. A submachine state referencing the credit card validation state machine

Typically when showing a submachine state you show the entry and exit points of the referenced submachine. You show these points as pseudostates on the border of the submachine state (see "Pseudostates"). Figure 8-10 shows a submachine state with an explicit exit point.

Figure 8-10. Credit card validation submachine state with explicit exit point

If the submachine state is entered through the default initial pseudostate or exited because of the completion of the submachine, you don't need to show explicit entry/exit points. The state machine shown in Figure 8-10 uses the default initial pseudostate and two different exit points. A submachine state machine may be used multiple times within a containing state machine, and different references to the submachine may show different entry/exit points based on what is relevant to the current submachine state.

For clarity you may use the same composite icon to show that the referenced submachine is defined elsewhere in the model. Figure 8-11 shows a submachine state with the composite icon.

Figure 8-11. A submachine state showing the composite icon

8.2.3. Transitions

A transition shows the relationship, or path, between two states or pseudostates. It represents the actual change in the configuration of a state machine as it heads from one state to the next. Each transition can have a guard condition that indicates if the transition can even be considered (enabled), a trigger that causes the transition to execute if it is enabled, and any effect the transition may have when it occurs.

Transitions are shown as a line between two states, with an arrowhead pointing to the destination state. You specify the details of the transition using the following syntax:

          trigger [guard] / effect

where:

trigger

Indicates what condition may cause this transition to occur. The trigger is typically the name of an event, though it may be more complex.

guard

Is a constraint that is evaluated when an event is fired by the state machine to determine if the transition should be enabled. Guards should not have any side effects and must evaluate to a boolean. Guards will always be evaluated before a transition is fired. The order in which multiple guards are evaluated isn't defined. A guard can involve tests of states in the current state machinefor example, not in Dialing or in WaitingForCall. The state names can be fully qualified if necessary.

effect

Specifies an activity that is executed when a transition happens. This activity can be written using operations, attributes, and links of the owning classifier as well as any parameters of the triggering event. An effect activity may explicitly generate events such as sending signals or invoking operations.

Figure 8-12 shows several transitions between states.

8.2.3.1. Transition types

UML defines several specific types of transitions. These are described in the following list. There are no special symbols associated with transition types. They are defined only for clarity and common vocabulary.

Compound transition

A representation of the change from one complete state machine configuration to another. Compound transitions are a set of transitions, choices, forks, and joins leading to a set of target states.

High-level transition

A transition from a composite state. If the destination of the transition is outside the composite state, all the substates are exited, and their exit activities are run, followed by the exit activity of the composite state. If the transition ends with a target inside the composite state, the exit activity of the composite state isn't run.

Figure 8-12. A state machine with several transitions

Internal transition

A transition between states within the same composite state. The containing state isn't exited or reentered during the transition. A transition directly from one region of a composite state to another region in the same composite state isn't allowed.

Completion transition

A transition from a state that has no explicit trigger. When a state finishes its do activities, a completion event is generated. This event is placed in the event pool and dispatched before any other event (see "Event Processing"). If the completion transition's guard conditions (if there are any) are met, the transition is triggered. You can have multiple completion transitions, however they must have mutually exclusive guard conditions. A completion transition from an orthogonal composite state will be taken when all the regions have reached their final state and have completed their do activities.

8.2.3.2. Signal symbols

Transitions may be shown in more detail using explicit icons to show signal sending, signal receipt, and effect activities. These icons are not necessary and are simply used to provide a more transition-oriented view of a state machine.

You can show a transition that receives a signal by showing an unlabeled transition from the source state to a rectangle with a triangular notch on one side. The signal's signature is shown inside the rectangle. Complete the diagram by showing an unlabeled transition pointing from the rectangle to the target state. Figure 8-13 shows a detailed view of a transition receiving a signal.

You can show a transition that sends a signal as part of the transition effect by drawing an unlabeled transition pointing from the source state to a rectangle with a triangular point on one side. The signature of the signal (including parameters) is shown inside the rectangle. Another unlabeled transition links the rectangle to the target state. Figure 8-14 shows a detailed view of a transition sending a signal.

Figure 8-13. A transition-oriented view showing a signal being received

Figure 8-14. Transition-oriented view of a signal being dispatched

You can show effects that occur as a result of a transition using a simple rectangle. The description of the activity is written inside the rectangle. As with signal icons, you link everything together with an unlabeled transition from the source state to the rectangle, and then from the rectangle to the target state. Figure 8-15 shows details of the effects of a transition.

8.2.3.3. Transitions and composite states

A transition from an external state to the border of a composite state is called default entry. The entry activity of the composite state is executed, and then the default transition to a substate occurs.

A transition from an external state to a specific substate of a composite state is called explicit entry. The entry activity for the composite state is executed before the substate becomes active.

Whenever a state machine transitions to an orthogonal composite state (a composite state with two or more regions), each region is entered either explicitly or by default. If the composite state is entered through an explicit entry, any other region is entered using its default transition.

Figure 8-15. Transition-oriented view with an activity

When leaving a composite state the exit activities for the active substates are executed from the inside out. In other words, the deepest of the active substate's exit activities executes first, and then its containing substate, and so on.

When exiting an orthogonal composite state, the active substate in each region is exited first; the exit activity for the composite state is then executed.

8.2.4. Activities

An activity represents some functionality that is executed by a system. A state can have activities that are triggered by transitions to and from the state or by events raised while in the state. A state's activities execute only if the state is active.

Each activity has a label showing when the activity executes, and an optional activity expression. An activity is written as:

          label / activity expression

You can write an activity expression using pseudocode:

     list.append(keystroke) ; print("*")

or natural language:

     record keystroke and show password character

You may omit the slash when you don't show the activity expression. Activity expressions can use attributes and operations available to the classifier owning the state machine.

UML reserves three activity labels:

Entry

Triggers when a state is entered. The entry activity executes before anything else happens in the state.

Exit

Triggers when leaving a state. The exit activity executes as the last thing in the state before a transition occurs.

Do

Executes as long as a state is active. The do activity executes after the entry activity and can run until it completes, or as long as the state machine is in this state.

Each state may have additional activities associated with it, and specific labels for each. See Figure 8-5 for an example of a state with several activities.

If the do activity completes, it causes a completion event, which can trigger a transition (see "Dispatch"). If there is a completion transition (a transition with no other event condition), the exit activity executes, and the transition occurs. If some other event causes the state to transition before the do activity completes, the activity is aborted, the exit activity executes, and the transition occurs.