PATTERNS OF DATA MODELING- P43 docx

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.. 15 St

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

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 nono-tation 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 StateState-Diagrams 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 stock Product 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

target

1

*

EntityType 1 0 1

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 StateType 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

target

1

*

Entity 1

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)

stateTypeID (FK)

stimulusTypeID

StimulusType

.

transitionTypeID

TransitionType

.

stateTypeID

StateType

.

entityTypeID

EntityType

.