Working with state diagrams

What Is a State Diagram?

One way to characterize change in a system is to say that its objects change their state in response to events and to time. Here are some quick examples:

When you throw a switch, a light changes its state from Off to On.

When you click a remote control, a television changes its state from showing you one channel to showing you another.

After an appropriate amount of time, a washing machine changes its state from Washing to Rinsing.

The Fundamental Symbol Set

Figure 8.1 shows the rounded rectangle that represents a state, along with the solid line and arrowhead that represent a transition. The arrowhead points to the state being transitioned into. The figure also shows the solid circle that symbolizes a starting point and the bull's-eye that symbolizes an endpoint.

Figure 8.1. The fundamental UML symbols in a state diagram. The icon for a state is a rounded rectangle, and the symbol for a transition is a solid line with an arrowhead. A solid circle stands for the starting point of a sequence of states, and a bull's-eye represents the endpoint.

 

Adding Details to the State Icon

The UML gives you the option of adding detail to these symbols. You can divide the state icon into two areas. The top area holds the name of the state (which you have to supply whether you subdivide the icon or not) and the bottom area holds activities that take take place in that state. Figure 8.2 shows these details.

 

Adding Details to the Transitions: Events and Actions

You can also add some details to the transition lines. You can indicate an event that causes a transition to occur (a trigger event) and the computation (the action) that executes and makes the state change happen. To add events and actions you write them near the transition line, using a slash to separate a triggering event from an action. Sometimes an event causes a transition without an associated action, and sometimes a transition occurs because a state completes an activity (rather than because of an event). This type of transition is called a triggerless transition.

The graphical user interface (GUI) you interact with gives examples of transition details. For the moment, assume the GUI can be in one of three states:

 

Adding Details to the Transitions: Guard Conditions

The preceding account of GUIs leaves a lot to be desired. First of all, if you leave your computer unattended or if you just sit idly by and don't type or use the mouse, a screensaver appears and rescues your pixels from potential burnout. To say this in state-change terms, if enough time passes without any user input, the GUI transitions from the Working state into a state I didn't show in Figure 8.4—the Screensaving state.

The time interval is specified in your Windows Control Panel. It's usually 15 minutes. Any keystroke or mouse movement transitions the monitor from the Screensaving state back to the Working state.

Substates

This model of the GUI is still somewhat empty. The Working state, in particular, is a lot richer than Figures 8.4 and 8.5 indicate.

When the GUI is in the Working state, a lot is happening behind the scenes, although it might not be particularly evident onscreen. The GUI is constantly waiting for you to do something—type a keystroke, move the mouse, or press a mouse button. It then must register those inputs and change the display to visualize those actions for you onscreen—for example, by moving the cursor when you move the mouse, or by displaying an a when you press the a key.

Sequential Substates

As the name implies, sequential substates occur one after the other. Recapping the aforementioned substates within the GUI's Working state, you have this sequence:

Awaiting User Input

Registering User Input

Visualizing User Input

Concurrent Substates

Within the Working state, the GUI isn't just waiting for you. It's also watching the system clock and (possibly) updating an application's display after a specific interval. For example, an application might include an onscreen clock that the GUI has to update.

All this is going on at the same time as the sequence I just discussed. Although each sequence is, of course, a set of sequential substates, the two sequences are concurrent with one another. You represent concurrency with a dotted line between the concurrent states

 

History States

When your screensaver is on and you move your mouse to get back to the Working state, what happens? Does your display go back to looking as it did right after the GUI was initialized? Or does it look exactly the way you left it before the screensaver came on?

Obviously, if the screensaver caused the display to revert back to the beginning of the Working state, the whole screensaver idea would be counterproductive. Users would lose work and have to restart a session from square one.

New in UML 2.0

UML 2.0 has added some new state-relevant symbols called connection points. They represent points of entry into a state or exits out of a state.

Here's an example: Imagine a couple of the states of a book in a library. At first, it's residing on a shelf. If a borrower has called in to reserve the book, a librarian retrieves the book and brings it into the state of “Being checked out.” If a borrower comes to the library, browses through the shelves, selects the book, and then decides to borrow it, it enters the Being-checked-out state, but in a different way. You can think of each way of getting to the Being-checked-out state as going through a separate entry point.

 
Why Are State Diagrams Important?

The UML state diagram provides a variety of symbols and encompasses a number of ideas, all to model the changes that just one object goes through. This type of diagram has the potential to get very complex very quickly. Is it really necessary?

In fact, it is. It's important to have state diagrams because they help analysts, designers, and developers understand the behavior of the objects in a system. A class diagram and the corresponding object diagram show only the static aspects of a system. They show hierarchies and associations, and they tell you what the behaviors are. They don't show you the dynamic details of the behaviors.

Building the Big Picture

Now you can add behavioral elements to your big picture of the UML. Figure 8.10 presents the picture with the state diagram included.

 

Figure 8.10. The big picture of the UML now includes a behavioral element, the state diagram.

Summary 

Objects in a system change their states in response to events and to time. The UML state diagram captures these state changes. A state diagram focuses on the state changes in just one object. A rounded rectangle represents a state, and a line with an arrowhead represents a transition from one state to another.

The state icon shows the name of the state and can hold activities as well. A transition can occur in response to a trigger event and can entail an action. A transition can also occur because of an activity in a state: A transition that takes place in this fashion is termed a triggerless transition. Finally, a transition can occur because a particular condition—a guard condition—holds true.

State Diagrams

State diagrams (also called State Chart diagrams) are used to help the developer better understand any complex/unusual functionalities or business flows of specialized areas of the system. In short, State diagrams depict the dynamic behavior of the entire system, or a sub-system, or even a single object in a system. This is done with the help of Behavioral elements.

It is important to note that having a State diagram for your system is not a compulsion, but must be defined only on a need basis.

Defining a State diagram

Just as we define classes for a Class diagram, it is necessary to define the elements of a State diagram. Let us first see what the elements of a State diagram are.

Elements of a State diagram

A State diagram consists of the following behavioral elements:

Element and its Description	Symbol
Initial State: This shows the starting point or first activity of the flow. Denoted by a solid circle. This is also called as a "pseudo state," where the state has no variables describing it further and no activities.
State: Represents the state of object at an instant of time. In a state diagram, there will be multiple of such symbols, one for each state of the Object we are discussing. Denoted by a rectangle with rounded corners and compartments (such as a class with rounded corners to denote an Object). We will describe this symbol in detail a little later.
Transition: An arrow indicating the Object to transition from one state to the other. The actual trigger event and action causing the transition are written beside the arrow, separated by a slash. Transitions that occur because the state completed an activity are called "triggerless" transitions. If an event has to occur after the completion of some event or action, the event or action is called the guard condition. The transition takes place after the guard condition occurs. This guard condition/event/action is depicted by square brackets around the description of the event/action (in other words, in the form of a Boolean expression).
History States: A flow may require that the object go into a trance, or wait state, and on the occurrence of a certain event, go back to the state it was in when it went into a wait state—its last active state. This is shown in a State diagram with the help of a letter H enclosed within a circle.
Event and Action: A trigger that causes a transition to occur is called as an event or action. Every transition need not occur due to the occurrence of an event or action directly related to the state that transitioned from one state to another. As described above, an event/action is written above a transition that it causes.
Signal: When an event causes a message/trigger to be sent to a state, that causes the transition; then, that message sent by the event is called a signal. Represented as a class with the <<Signal>> icon above the action/event.
Final State: The end of the state diagram is shown by a bull's eye symbol, also called a final state. A final state is another example of a pseudo state because it does not have any variable or action described.

Note: Changes in the system that occur, such as a background thread while the main process is running, are called "sub states." Even though it affects the main state, a sub state is not shown as a part of the main state. Hence, it is depicted as contained within the main state flow.

As you saw above, a state is represented by a rectangle with rounded edges. Within a state, its Name, variables, and Activities can be listed as shown in Figure 6.1.

Figure 6.1: the structure of the state element

States

A state is denoted by a round-cornered rectangle with the name of the state written inside it.

Initial and Final States
The initial state is denoted by a filled black circle and may be labeled with a name. The final state is denoted by a circle with a dot inside and may also be labeled with a name.

Transitions
Transitions from one state to the next are denoted by lines with arrowheads. A transition may have a trigger, a guard and an effect, as below.

"Trigger" is the cause of the transition, which could be a signal, an event, a change in some condition, or the passage of time. "Guard" is a condition which must be true in order for the trigger to cause the transition. "Effect" is an action which will be invoked directly on the object that owns the state machine as a result of the transition.

State Actions
In the transition example above, an effect was associated with the transition. If the target state had many transitions arriving at it, and each transition had the same effect associated with it, it would be better to associate the effect with the target state rather than the transitions. This can be done by defining an entry action for the state. The diagram below shows a state with an entry action and an exit action.

It is also possible to define actions that occur on events, or actions that always occur. It is possible to define any number of actions of each type.

Self-Transitions
A state can have a transition that returns to itself, as in the following diagram. This is most useful when an effect is associated with the transition.

Compound States
A state machine diagram may include sub-machine diagrams, as in the example below.

The alternative way to show the same information is as follows.

The notation in the above version indicates that the details of the Check PIN sub-machine are shown in a separate diagram.

Entry Point
Sometimes you won’t want to enter a sub-machine at the normal initial state. For example, in the following sub-machine it would be normal to begin in the "Initializing" state, but if for some reason it wasn’t necessary to perform the initialization, it would be possible to begin in the "Ready" state by transitioning to the named entry point.

The following diagram shows the state machine one level up.

Exit Point
In a similar manner to entry points, it is possible to have named alternative exit points. The following diagram gives an example where the state executed after the main processing state depends on which route is used to transition out of the state.

Choice Pseudo-State
A choice pseudo-state is shown as a diamond with one transition arriving and two or more transitions leaving. The following diagram shows that whichever state is arrived at, after the choice pseudo-state, is dependent on the message format selected during execution of the previous state.

Junction Pseudo-State
Junction pseudo-states are used to chain together multiple transitions. A single junction can have one or more incoming, and one or more outgoing, transitions; a guard can be applied to each transition. Junctions are semantic-free. A junction which splits an incoming transition into multiple outgoing transitions realizes a static conditional branch, as opposed to a choice pseudo-state which realizes a dynamic conditional branch.

Terminate Pseudo-State
Entering a terminate pseudo-state indicates that the lifeline of the state machine has ended. A terminate pseudo-state is notated as a cross.

History States
A history state is used to remember the previous state of a state machine when it was interrupted. The following diagram illustrates the use of history states. The example is a state machine belonging to a washing machine.

In this state machine, when a washing machine is running, it will progress from "Washing" through "Rinsing" to "Spinning". If there is a power cut, the washing machine will stop running and will go to the "Power Off" state. Then when the power is restored, the Running state is entered at the "History State" symbol meaning that it should resume where it last left-off.

Concurrent Regions
A state may be divided into regions containing sub-states that exist and execute concurrently. The example below shows that within the state "Applying Brakes", the front and rear brakes will be operating simultaneously and independently. Notice the use of fork and join pseudo-states, rather than choice and merge pseudo-states. These symbols are used to synchronize the concurrent threads.