Chapter 15

State Diagrams

A state diagram specifies states and stimuli that cause changes of state. State diagrams are often used for control and managing user interaction. They are also helpful for enforcing business policies and constraining data — the reason for coverage in this chapter.

Figure 15.1 shows a simple state diagram for processing orders. A customer places an order and it is quickly acknowledged. Some further processing assigns a customer number and order number and the order is then confirmed. The desired product may or may not be available. If inventory is lacking, the order can be back ordered or if the customer cannot wait, the order is cancelled. Once inventory is available, the customer’s payment is processed. Upon payment approval, the order is considered complete. The product is then shipped and the customer signs for delivery. This completes order processing and the order is considered fulfilled.

One way to realize state diagrams is by writing the equivalent procedural code. Another option is to have a generalized interpreter based on declarations in database tables as this chapter explains. An interpreter is especially useful for simple state diagrams.

15.1 State Diagrams

The UML not only has a notation for data structure (the class diagram) but also has one for state diagrams (as well as other kinds of diagrams). In Figure 15.1 the rounded boxes denote StateTypes. The solid circle is an initial StateType and the bull’s-eye is a final StateType. The directed lines connecting a source StateType to a target StateType are TransitionTypes. A Stimulus causes a change of state and is shown as a label on a transition. The full UML notation for state diagrams is more complex than presented here, but this simple notation suffices for many database applications.

Figure 15.2 and Figure 15.3 show a model for state diagrams that can store the data of Figure 15.1. As with earlier chapters, a gray shading denotes entity types that concern metadata.

In Figure 15.2 and Figure 15.3 a StateDiagram specifies the permissible StateTypes and the StimulusTypes that cause changes of state. State diagrams are helpful for situations where there is a lifecycle or a meaningful sequence of steps to enforce. An EntityType has a StateDiagram if there is a process to enforce. An application can involve multiple StateDiagrams via multiple EntityTypes. The individual StateDiagrams interact through common stimuli.

A StateDiagram has no memory of the past and responds to stimuli solely on the basis of an entity’s current state. StimulusType names must be unique for an application. StateType names must be unique within the scope of a StateDiagram.

A StimulusType is a category for similar occurrences that can cause changes in StateDiagrams. In Figure 15.1 Customer places order, Verify order, and Product in stock are examples of StimulusTypes. Each entity proceeds at its own pace and a StimulusType provides a means for grouping together occurrences with similar behavior. (In the UML a stimulus can be an event — see Chapter 10 — and/or a boolean guard condition that must be true for a transition to occur.)

A StateType is a category for similar states in which an entity awaits further stimulus. In Figure 15.1 Order Acknowledged, OrderCancelled, and ProductBackordered are examples of StateTypes. Each entity has its individual state but is governed by the StateDiagram for its EntityType. A StateType defines the context for processing stimuli. The same stimulus can have different effects (or no effect) for different StateTypes.

A TransitionType is a change from a source StateType to a target StateType. The source and target usually differ but can be the same StateType. In Figure 15.1 one TransitionType is from OrderAcknowledged to OrderConfirmed. Another TransitionType is from OrderConfirmed to ProductAvailable. The choice of next StateType depends on both the original StateType and the Stimulus.

The StateDiagram in Figure 15.1 has the following constructs:

• 11 StateTypes (the initial StateType, the final StateType, and 9 intermediate StateTypes).
• 9 StimulusTypes (Product in stock affects behavior in two different places).
• 12 TransitionTypes.

15.2 Scenarios

A StateDiagram defines the 1ifecyc1e for an EntityType. In contrast a Scenario executes a StateDiagram for an Entity of the StateDiagram’s EntityType. Figure 15.4 and Figure 15.5 show a Scenario model that can store the history of execution as well as the current State. Via model traversal, a Scenario has an Entity; an Entity has an EntityType; and an EntityType can have a StateDiagram; thus a Scenario corresponds to a StateDiagram. It is an architectural decision for what data should be stored, how long it is stored, when it is archived, and when it is discarded.

A Stimulus is something that happens at a point in time. An example of a Stimulus is Joe Smith the customer placing an order for a laptop computer on May 29, 2010 at 10:15 AM. Thus a Stimulus is a specific occurrence that conforms to the general description of its StimulusType.

A State is the period in which an Entity waits for the next Stimulus. For example, Joe Smith has placed his order and the order is in the StateType of Order Acknowledged awaiting completion of verification. Similar States are described by a common StateType. All Stimuli are ignored in a State, except those for which a StateDiagram prescribes behavior. Each Entity can have many States over time, but has exactly one State at a time. A StateDiagram has no memory of the past and responds to Stimuli solely on the basis of an Entity’s current State.

Note the contrast between Stimulus and State. A Stimulus represents a point in time. A State represents an interval of time.

A Transition is an instantaneous change from a source State to a target State. A Transition happens when a Stimulus occurs and the Entity’s current State and the Stimulus matches the types specified for the TransitionType. The Transition causes the Entity to shift to the target State. Multiple Entities may be caused to Transition by the same Stimulus.

The StateDiagram and Scenario models use the ItemDescription and Homomorphism templates (see Chapter 5).

15.3 Chapter Summary

A state diagram specifies the permissible states and stimuli that cause changes of state. A scenario executes a state diagram and can store the current state as well as the past history. State diagrams are helpful for situations where there is a lifecycle or a meaningful sequence of steps to enforce. Developers typically realize state diagrams by writing the equivalent procedural code. But another option is to have a generalized interpreter based on the models in this chapter.

Bibliographic Notes

I have used declarative state diagrams on several industrial consulting projects. This chapter was motivated by Chapter 6 of [Silverston-2009]. Silverston and Agnew discuss the notion of data status which can be much more richly modeled with state diagrams.

[Blaha-2005] has a further explanation of UML state diagrams.

References

[Blaha-2005] Michael Blaha and James Rumbaugh. Object-Oriented Modeling and Design with UML, 2nd Edition. Upper Saddle River, NJ: Prentice Hall, 2005.

[Silverston-2009] Len Silverston and Paul Agnew. The Data Model Resource Book, Volume 3. New York, New York: Wiley, 2009.