The state of an object is the current values of its attributes together with the current instances of its associations with other objects. As events occur, the state of the object can change. The pattern of events, states, and state transitions for a given class can be abstracted and modeled as a state diagram or a state table.

Model Type (Top)

Graphical.

Purpose (Top)

A state transition diagram shows the states of a system or an object and the possible transitions from one state to another. A state diagram models state sequences caused by event sequences. A specific sequence of events corresponds to a path through the state model.

Components and Structure (Top)

The main components of the diagram are illustrated in the following figure:

• State
  A state is an abstraction of the values and associations of an object. A state corresponds to the interval between two events. The events represent points in time. The state represents an interval in time in which the state remains constant because no events are occuring.

• Event
  An event is a change in the environment of the object that has the potential to change the state of the object. An event occurs at an instant of time.

• Transition
  A state diagram relates events and states. When an event is received, the next state depends on the current state as well as the event. A transition is a change in state caused by an event. The transition is a directed line between the old state and the new state. The line is labeled with the name of the event. The transition may contain a guard. A guard is a logical condition that can only return true or false. All of the lines leaving a state must correspond to different events or different guards on the same event.

Related Models (Top)

• A state transition table can be used in place of a state transition diagram.

• Each event that causes a transition must be in the event dictionary.

Example (Top)

The following is an example of a state diagram for the job object in Sid's radio:

Comments (Top)

1. An STD only works to show you how a single object changes its internal state. It does not show any interactions between one object and another.

2. A state change can only be caused by an event.

3. Every state must have at least one event that takes the object to another state or to the end.

4. If there is no event that takes an object from a state to an end, the object will exist forever. Although this may be the situation in some systems, it most situations it means that a custodial event that destroys the object is missing.

5. If an object does not have interesting attribute changes, then its state transition diagram will not be very informative. Recall that there are several types of messages:

   1. A query message causes a method to execute but it does not cause any attribute values to change and therefore does not cause any change in the way that an object behaves with respect to future events. For this reason, query events are not usually included in a STD because they are trivial. Including them would add nothing to our understanding of the problem or the solution.

   2. An update message causes a method to execute and it also causes an attribute value or the set of associations to change. Some attribute changes are trivial. For example, an update that simply changes the value of a name attribute is probably not interesting because changing the name probably will not change the behavior of the object. But an event that changes a marital status from single to married may change the way the object responds to future events.

   3. An imperative message causes a method to execute to perform some useful service for the requestor. An imperative may cause attribute values or associations to change, but it does not have to. The method that services the imperative will usually call upon the services of other objects. Thus, an imperative may cause a state transition, and will often also cause one or more object interactions as the method delegates its work to other objects.

      Note that a query or update can also cause an object interaction, but that is much less likely.

   What do we conclude from this. We want to look only at interesting (non-trivial) changes to the attributes or associations of an object. These are transitions that cause the object to behave differently than before the transition. Thus, for the most part, we want to look at events which are triggered by update and imperative messages.