The What and Why of Verification

The question of why verification really matters was comprehensively addressed in Chapter 1, where we pointed out that one of the major reasons why policy management in database systems is very expensive is that the unintended consequences of various interacting con- straints are hard to isolate. Not only can constraints interfere with each other, but they can also interfere with established business objectives and practices pertaining to various artifacts. For example, an incorrectly implemented constraint may cause legal (required) paths in an artifact lifecycle to be un-traversable. More importantly, proving (to savvy auditors or to internal managers responsible for specific processes) that unintended con- sequences of a set of constraints can never occur is extremely difficult when constraints

are programmed in an ad-hoc fashion. To this end, the ability to verify and prove that “something bad” cannot happen is vitally important.

Therefore we need to be able to define what this “something bad” is before we can verify that it never happens. We have already demonstrated that CLTL restricted to past operators is an expressive logic for specifying enforceable constraints over artifact histories. However, we now claim that CLTL is sufficiently expressive to describe invariants about artifacts that may warrant verification. Consider our running example of the InvoicePro- cessing artifact and a situation where a policy maker wants to verify if there can ever (in the future) exist a “shipped invoice that is subsequently marked as unpaid”, s/he could write that check condition as an LTL assertion F(•S ∧ ¬U ). Similarly the concerned individual can check formulas that specify complex paths in the workflow. For example, if s/he wanted to determine whether it is possible for an artifact to comply with (traverse) the transition from state S1 to S3 after being in state S2, then the formula F(S3∧ •(S1∧ S2)) could be used to represent that particular sequence of state changes.. Thus, it should be apparent that linear temporal logic can also be used to describe invariants, check-conditions, or some prescribed behaviour of artifacts that may warrant verification.

Construction of a CLTL SAT problem

Having written formulas that specify properties (or invariants) about artifacts, then the next natural step is to ascertain whether these formulas can (ever) be true or not. We can phrase this problem as follows: Given a set of constraints applicable on an artifact type (i.e., an artifact constraint system) and a property that warrants verification, can there ever exist an artifact history, that (a) complies with the artifact constraint system and (b) in which the property is true? In other words can the ACS and the property both be satisfied at the same time?

Although this phrasing of the problem reduces the notion of verification of a user- specified property about an artifact to CLTL satisfiability, there are a few more steps left in completing the construction of the LTL satisfiability problem before it can be fed into a CLTL solver for meaningful results. Foremost, note that the ACS does not capture the implicit constraints introduced to manage artifact lifecycle instantiation and termination.

Recall Section 3.4.4 starting on page 60 in which two implicit constraints regarding termi- nation of lifecycles were introduced for every artifact. To simplify our construction we will denote these lifecycle termination constraints as Cφ:

Cφ := (•φ ⇒ φ) ∧ (φ ⇒ ^

ai∈A

•ai = ai) _(5.2)

We remind the reader that the restrictions embedded in Cφ were placed to ensure that (i) once the implicitly introduced lifecycle termination marker (φ) is set to true, it forever remains true and (ii) the attribute values of the artifact never change from that point onwards. These restrictions were placed to ensure that an object cannot change once it is in the “dead state.”

Finally, recall the instantiation constraint φS(A) introduced in Section 3.5.2 starting on page 67, and note that it was used to represent an instantiation function that is to be interpreted only for t=0. With this last component in hand we can completely specify our CLTL SAT problem as follows:

φS(A) ∧ G[ACS ∧ Cφ] ∧ F(CheckCondition) (5.3)

Note that this CLTL formals is intuitive to understand and requires the solver to find a history/run in which three conditions are satisfied:

• φS(A): The history must satisfy the artifact instantiation constraint.

• G[ACS ∧ Cφ]: Forever (or Globally), the history must comply with the constraints in the ACS and the termination constraints.

• F(CheckCondition): Subsequent to satisfying the instantiation constraint, sometime in the Future (or eventually), the CheckCondition must become true.

In other words we are requiring a SAT solver to traverse all possible legal artifact lifecycles and determine if (eventually) the specified condition/property can hold true for an artifact subject to a given ACS. If the above formula is satisfiable, then the CheckCondition can be met and the “something bad” that the designer of the CheckCondition wanted to avoid can happen.

Example

Consider our running example of the InvoiceProcessing Artifact and the check condition introduced earlier: “can a previously shipped invoice be marked as unpaid.” This condition was formulated as F(•S ∧ ¬U ). The ACS for our example was given in Formula 5.1 and Cφ was described in Formula 5.2. Since the constraint diagram did not restrict how InvoiceProcessing artifacts can be created/instantiated φS(A) is considered to be true. The resulting SAT problem is as follows:

true ∧ G[(P ∧ ¬ • P ⇒ •U ] ∧ [(S ∧ ¬S) ⇒ •P ] ∧ [S ⇒ ¬φE] ∧ [•φ ⇒ φ] ∧ [φ ⇒ ^ ai∈A •ai = ai]] ∧ F[•S ∧ ¬U ] (5.4) Note that the above formula is a simple substitution of the various parts in formula 5.3. For visual clarity we have broken the formula into three different lines. Line one is the initialization, which is unrestricted (i.e., an artifact can take any values to start). Line two is the set of global constraints that the artifact must satisfy. These constraints include not only the operational business rules (contained in the ACS) but also the termination con- straints (last two conjuncts in line two). Finally, line three introduces an aspect about the future that the solver must include for while abiding by the rules embedded in the previous

two lines. That is, in the legal (compliant) future subsequent to artifact instantiation, can the specified CheckCondition be true?