Visual Constraint Notation

Figure 3.4: Simple Exit Restriction between the Paid and Unpaid States

Our diagrammatic convention for specifying database level CLTL constraints resembles traditional workflow and process modelling techniques in that the notion of a ‘state’ re- sembles that of a stage in a business process. One such state is represented by a labelled box or rectangle on a constraint diagram. As described earlier, an artifact (representing an individual instance of a business process) is in a given state if it satisfies the func- tion defined on the attributes of the artifact type to be in that state. We use lines with varying arrows (connectors at different ends) as connections between the states to imply some path restrictions associated with two states. For all such connections there is formal interpretation as a CLTL constraint on the artifact history.

Consider the diagram in Figure 3.4 involving two states on SalesOrders that we had defined earlier. For brevity we have omitted the actual function definitions associated with

the states and instead referred to them via their state name/label. There is a connector with a three pronged arrow at the Unpaid side and a direct connection to the Paid state. The logical interpretation derived by this arrow in the diagram can be read from Table 3.1: If a SalesOrder artifact is in the Unpaid state at time t, and does not satisfy the condition to be in the Unpaid state at time t + 1, then it must satisfy the condition to be in the Paid state at time t + 1. The LTL equivalent can also be specified by simply reading Table 3.1 as follows:

(•U npaid(SalesOrder) ∧ ¬U npaid(SalesOrder)) ⇒ P aid(SalesOrder)

If we unwrap the states using their definitions, we can write the temporal constraint as the following implication on the boolean attributes of the view:

(•(¬paid ∧ ¬reviewed ∧ ¬shipped) ∧ ¬(¬paid ∧ ¬reviewed ∧ ¬shipped)) ⇒ (paid ∧ reviewed)

The notation presented below represents the basic constructs of our proposed graphical database constraint modeling language (DCML):

Visual Notation and LTL Interpretation

Multi-Way Exit Restriction •A(x) ∧ ¬A(x)

⇒ B(x) ∨ C(x)

If an artifact was in state A at time t and does not satisfy the condition to be in state A at time t + 1, then it must satisfy the condition to be in state B or state C at time t + 1. Note that the graphical notation only depicts a 2-way exit restriction leading to states B or C, but the notation can be extended and used to specify exit restrictions in which the OR conditional arrows end towards n different states where n ≥ 1. In such cases the artifact must satisfy the condition to be in at least one state on the right hand side at time t + 1.

Visual Notation and LTL Interpretation

Entry Restriction (B(x) ∧ ¬ • B(x)) ⇒ •A(x)

If an artifact is in state B at time t, and does not satisfy the condition to be in state B at time t − 1, then it must satisfy the condition to be in state A at time t − 1. Note that this constraint can be considered the dual of the exit restriction. A multi-way entry restriction can be created by specifying several entry restrictions originating from one state and ending in many others.

Never Eventually Reach A(x) ⇒ ¬B(x)

If an artifact was ever in state A, it should never satisfy the condition to be in state B.

Disallow Exit A(x) ⇒ A(x)

If an artifact was ever in state A, it should still be in state A

Guard Attribute: A(x)

⇒

•attribute = attribute

While the artifact is in state A, the value of the specified attribute(s) should remain unchanged. In other words, whenever the artifact satisfies A(x), it should also satisfy •ai = ai for the specified attribute i

Visual Notation and LTL Interpretation

Invariant Attribute: •attribute = attribute

since A(x)

Once the artifact is in state A, the value of the specified attribute(s) should forever remain unchanged. In other words, if the artifact ever satisfies A(x), it should from that point onwards, make the specified attribute invari- ant, i.e., the attribute does not change its then assigned value in subsequent history entries.

Table 3.1: Basic path restrictions and their equivalent temporal assertions. Note that each state has an associated boolean function specified over the attributes of the artifact type. In our notation we use shorthand notation S(x) to denote the application of the function of the state S to the attributes of the artifact x.

The notation presented above gives a formal meaning in CLTL to each of the diagrammatic conventions used in specifying a DCML diagram. For example, the following augmented version of the two state DCML diagram presented in Figure 3.4 embeds two additional constraints using the notation presented in Table 3.1:

In addition to the constraint present in the original DCML diagram (Figure 3.4), three other constraints are embedded in Figure 3.5. First, let us examine the double headed arrow ending in the Paid state, which imposes an entry restriction that can be interpreted from Table 3.1 as follows:

(P aid(SalesOrder) ∧ ¬ • P aid(SalesOrder)) ⇒ •U npaid(SalesOrder)

The above implication can be expanded using the definitions of Paid and Unpaid functions and is very similar to the one presented earlier for Figure 3.4. The net result is that now there is both an entry and an exit restriction between the Unpaid and Paid states, and these constraints must now independently hold true for all SalesOrder artifacts. Informally (in the business sense), we can describe the interplay of both these constraints simultaneously as follows: An artifact can only move from the Unpaid state to the Paid state and if an artifact arrives in the Paid state it must have come there from the Unpaid state. Having both an entry and an exit restriction between the two states makes the transition system much more rigid in its flow/direction.

In addition to the above discussed two constraints, there are two invariant constraints in Figure 3.5 that make the reviewed and paid attributes immutable when the artifact reaches the Paid state. The invariant constraint for the reviewed attribute can be interpreted using Table 3.1 as follows:

(•reviewed = reviewed) since P aid(SalesOrder) or equivalently by expanding the definition of the Paid function as:

(•reviewed = reviewed) since (paid ∧ reviewed)

Similarly, the diagram also requires that the paid attribute also is invariant (unchange- able) when an artifact reaches the Paid state. Note that because embedded in the state definition is the requirement that paid = true (i.e., if an artifact is in the Paid state its attribute paid will be true), a natural consequence of the above constraint diagram is that if an artifact ever reaches the Paid state its paid attribute will remain true from that point

onwards in all history entries.

We summarize this section by emphasizing that our proposed database constraint mod- eling language tries to mimic the notion of states and path constraints as they exist in classical workflow and process modelling languages. However, because the language is formally related to CLTL, it can produce complex visual models that may be difficult to understand for the reader not familiar with temporal logic. Furthermore, we do not make the claim that the visual-CLTL notation that we have presented covers all possible LTL style flow constructs. However, it will serve as the basis on which generic visual-CLTL mappings can be established by policy makers specializing in various domains. We shall discuss improvements and extensions to this notation in subsequent chapters and propose various fragments of DCML for specific situations. However, the above proposed DCML notation should suffice for now in explaining and highlighting the benefits of database level visual constraint modeling in general.