State Machines

Introduction

 

A state machine is a behavior that represents the sequences of states that an object undergoes during its lifetime in response to events, together with its responses to those events.

 

The state of an object is a condition or situation during the life of an object during which it satisfies some condition, performs some activity or waits for some event.

 

We can visualize a state machine in two ways: 1) by focusing on the control flow from one activity to another (using activity diagrams) or 2) by focusing on the states of objects and the transitions among those states (using state chart diagrams).

 

 

States

 

A state is a condition or situation during the life of an object during which it satisfies some condition, performs some activity, or waits for some event. An object remains in a state for a finite amount of time. A state has several parts:

 

 

A state is represented as a rectangle with rounded corners as shown below:

 

 

Initial and Final States

 

As we can see from the above figure, there are two special states that may be defined for an object’s state machine. First, the initial state, which indicates the default starting place of control for the state machine or sub state.

 

Initial state is represented as a filled black circle. Second, the final state, which indicates that the execution of the state machine or the enclosing state has been completed. Final state is represented as filled black circle enclosed in a hollow circle.

 

Transitions

 

A transition is a relationship between two states indicating that an object in one state will perform certain actions and enter another state when a specified event occurs and specified conditions are satisfied. A transition has five parts:

 

 

A transition is visually represented as a solid directed line from the source state to the target state. A self-transition is a transition whose source and target states are the same.

 

 

Event Trigger

 

An event is a specification of a significant occurrence that has location in time and space. In state machines, an event is an occurrence of stimulus that can trigger a state transition. For example, the “play button” makes the music player to change from “idle” state to “playing”.

 

There can be triggerless transitions which are represented by a transition with no event trigger. A triggerless transition also called a completion transition is triggered implicitly when its source state has completed its activity.

 

Guard Condition

 

A guard condition is rendered as a Boolean expression enclosed in square brackets and placed after the trigger event. A guard condition is evaluated only after the trigger event for its transition occurs. Therefore, it’s possible to have multiple transitions from the same source state and with the same event trigger, as long as those conditions don’t overlap.

 

Action

 

An action is an executable atomic computation. Actions may be method calls, signals or creation of objects or destruction of objects.

 

Advanced States and Transitions

 

UML’s state machines provide a number of advanced features that help us to manage complex behavioral models. Some of these advanced features include entry and exit actions, internal transitions, activities and deferred events.

 

 

Entry and Exit Actions

 

When the control enters a certain state, it might carry out a particular action. Such action is known as an entry action. Similarly, a state might carry out a particular action when the control leaves that state. Such action is known as exit action. Entry and exit actions are represented using the keywords “entry” and “exit” respectively.

 

Internal Transitions

 

In state machines, a state might process certain events without leaving the current state. Such transitions which represent events that are handled without leaving the current state are known as internal transitions. Internal transitions are different from self transitions in the sense that events on self transitions are handled outside the current state.

 

Activities

 

After entering the state, that state might do a set of actions. These actions are collectively known as the activity performed by a state. In UML, activities are represented using the keyword “do”.

 

Deferred Events

 

In some situations, a state might handle certain events in another state of the object. Such events which are postponed to be handled later in another state are known as deferred events. In UML, deferred events are represented with the “do” action.

 

Substates

 

A substate is a state included in another state. For example, a Heater might be in the Heating and at the same time it might be in the Activating state which is a nested state in the Heating state. In UML, we render a composite state just like a normal state, but with an optional graphic compartment that shows a nested state machine. Substates may be nested to any level.

 

Sequential Substates

 

Consider the state machine for ATM system:

 

 

Substates such as Validating and Processing are called sequential or disjoint substates. Given a set of disjoint states in an enclosing composite state, the object is said to be in the composite state and in only one of the disjoint substates at a time.

 

Therefore, sequential substates divide the state space of the composite state into disjoint states. A nested sequential state machine may have at most one initial state and one final state.

 

History States

 

Unless otherwise specified, when a transition enters a composite state, the action of the nested state machine starts over again at its initial state. However, there are situations in which we might want the state machine to remember the last substate that was active prior to leaving the composite state.

 

For example, in modeling the behavior of an agent which performs unattended backup of computers across the network, we like it to remember where it was in the process if it ever gets interrupted by, for example, a query from the operator.

 

A history state allows a composite state that contains sequential substates to remember the last substate that was active in it prior to the transition from the composite state. In UML, a history is represented as a hollow circle with the symbol ‘H’ as shown in the below figure:

 

 

Concurrent Substates

 

Concurrent substates allow us to specify two or more state machines that execute in parallel in the context of the enclosing object.

 

For example, in the below figure, the Maintenance mode is decomposed into two concurrent substates, Testing and Commanding, shown by nesting them in the Maintenance state but separating them from one another with a dashed line. Each of these concurrent substates is further divided into sequential substates.

 

Execution of these two concurrent substates continues in parallel. Eventually, each nested state machine reaches its final state. If one concurrent substate reaches its final state before the other, control in that substate waits at its final state. When both the nested state machines reach their final state, control from the two concurrent substates joins back into one flow.

 

 

Common Modeling Techniques

 

Modeling the Lifetime of an Object

 

To model the lifetime of an object:

• Set the context for the state machine, whether it is a class, whether it is a class, a use case, or the system as a whole.
• Establish the initial and final states for the object.
• Consider the events to which this object may respond.
• Starting from the initial state to the final state, lay out the top level states the object may be in. Connect these states with transitions triggered by the appropriate events.
• Identify any entry or exit actions.
• Expand these states as necessary by using substates.
• Check for the consistency of events in the object interface with the events in the state machine.
• Check that all actions mentioned in the state machine are sustained by the relationships, methods and operations of the enclosing object.
• Trace through the state machine, either manually or by using tools, to check it against expected sequences of events and their responses.
• After rearranging, again check it against the expected sequences to ensure that you have not changed the object’s semantics.