14.7 Chapter Summary 197 14.7 Chapter Summary This chapter presents a model of generic diagrams. A generic diagram appears as a picture but has semantic content that lies behind the graphics. The model is too large to fit on a single page, so the chapter divides the model into four subject areas. The generic diagram model provides a starting point for various kinds of diagrams such as data structure diagrams, data flow diagrams, state diagrams, and equipment flow diagrams. I have used the technology in this chapter on several consulting projects. Bibliographic Notes This chapter is motivated by my personal experiences with consulting projects. The follow- ing notions have been especially useful in practice. • The uniform mapping of diagram constructs to model constructs. • The ability to hierarchically nest diagrams and models. • The ability to display graphical constructs based on the type of diagram. • The ability to include or omit ports and tabs. 198 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 pro- cessed. 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 no- tation for state diagrams is more complex than presented here, but this simple notation suf- fices for many database applications. Figure 15.2 and Figure 15.3 show a model for state diagrams that can store the data of Fig- ure 15.1. As with earlier chapters, a gray shading denotes entity types that concern metadata. 15.1 State Diagrams 199 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 State- Diagram 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. Figure 15.1 State diagram for processing orders. State diagrams are helpful for enforcing business policies and constraining data. Customer places order OrderAcknowledged OrderConfirmed Verify order ProductMissing ProductAvailable Product in stockProduct out of stock OrderCancelled ProductBackordered OrderComplete Customer cannot wait Customer will wait Payment approved Product in stock ProductShipped Ship product ProductReceived Customer signs for delivery Figure 15.2 State diagram: UML model. State diagrams can enforce a life- cycle or a meaningful sequence of steps for an EntityType. StateDiagram name {unique} StimulusType name {unique} TransitionType 1 * source target 1 * EntityType 1 0 1 1 StateType name 1 * * 200 Chapter 15 / State Diagrams A StimulusType is a category for similar occurrences that can cause changes in State- Diagrams. In Figure 15.1 Customer places order, Verify order, and Product in stock are ex- amples 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 S tateType is a category for similar states in which an entity awaits further stimulus. In Figure 15.1 OrderAcknowledged, OrderCancelled, and ProductBackordered are exam- ples 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 OrderCon- firmed to ProductAvailable. The choice of next StateType depends on both the original State- Type 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 lifecycle 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 Figure 15.3 State diagram: IDEF1X model. stateDiagramID StateDiagram stateDiagramName (AK1.1) entityTypeID (FK) (AK2.1) entityTypeID EntityType . . . transitionTypeID TransitionType stateDiagramID (FK) stimulusTypeID (FK) sourceStateTypeID (FK) targetStateTypeID (FK) stateTypeID StateType stateTypeName stimulusTypeID StimulusType stimulusTypeName (AK1.1) 15.2 Scenarios 201 can have a StateDiagram; thus a Scenario corresponds to a StateDiagram. It is an architec- tural 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 Figure 15.4 Scenario: UML model. A Scenario executes a StateDiagram for an Entity of the StateDiagram’s EntityType. Scenario name Stimulus datetime Transition 1 * source target 1 * Entity 1 1 State startDatetime 1 endDatetime 0 1 0 1 * StimulusType 1 * TransitionType * 1 StateType * 1 EntityType 1 * Figure 15.5 Scenario: IDEF1X model. scenarioID Scenario scenarioName entityID (FK) entityID Entity . . . transitionID Transition scenarioID (FK) stimulusID (FK) sourceStateID (FK) (AK1.1) targetStateID (FK) (AK2.1) stateID State startDatetime stimulusID Stimulus datetime transitionTypeID (FK) stimulusTypeID (FK) endDatetime stateTypeID (FK) stimulusTypeID StimulusType . . . transitionTypeID TransitionType . . . stateTypeID StateType . . . entityTypeID EntityType . . . . areas. The generic diagram model provides a starting point for various kinds of diagrams such as data structure diagrams, data flow diagrams, state diagrams, and equipment flow diagrams. I have used. 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. model for state diagrams that can store the data of Fig- ure 15.1. As with earlier chapters, a gray shading denotes entity types that concern metadata. 15.1 State Diagrams 199 In Figure 15.2