e WAIT−3 WAIT−4 after(1) WAIT−5 WAIT−6 after(2)
Figure 10.4 Example to illustrate discretisation of clocks
result of Asarin et al. [14], based on results of Henzinger et al. [96], that dense time models in which all timing intervals are closed, can be discretised using clock ticks of 1. The dense time model that is used in our semantics falls in this class.
The discretisation preserves the untimed (reachability) properties of the orig- inal dense time model, but it may introduce some different timing behaviour [14, 96]. So it is not possible to use a real-time logic as property language. But since there is no real-time model checker supporting strong fairness constraints, we are subject to this limitation anyway.
10.3
Strong fairness
The need for strong fairness. Workflow specifications can contain loops. Con- sider for example the activity diagram in Figure 1.1 on page 3. There is a loop Send bill,WAIT-3,Handle payment,Notify customer,Send Bill,. . .. It is possible that this loop is never exited, that is, the payment may never be ok. This is not what is intended. Ideally, a workflow will eventually exit a loop, because the workflow will eventually terminate. So in Figure 1.1, ideally the payment will eventually be ok.
At first sight, it may seem as if loops are only introduced directly in the control flow, as in Figure 1.1. But even a workflow specification that has no loops in the control flow may have loops in its underlying transition system. This is due to event occurrences that can occur in a certain state but that are irrelevant and therefore ignored. For example, in Figure 10.5 event e can occur while node A is active, but then it is simply ignored. Nothing in our semantics prevents e from happening over and over again while A is active. The run in Figure 10.5 would therefore be a valid run. But we want to exclude such a run, because in it, activity A never terminates while e occurs infinitely often. (This behaviour resembles Zeno behaviour in timed systems.)
To exclude these infinite loops, we have to find a way to specify that the loops will be exited eventually. A useful way to specify this is to use strong fairness (also known as compassion) constraints. A strong fairness constraint (p, q), where
164 Chapter 10· Verification of functional requirements A WAIT e initial state {A} e occurse occurs e occurse occurs
{A} {A} {A}
...
Figure 10.5 Example of hidden loops
s1 s2 s3
p,!q !p, q !p, !q
Figure 10.6 Kripke structure to illustrate strong fairness. ‘!’ denotes¬
p and q are properties, states that if p is true infinitely often in a run, then q must be true infinitely often in the run as well [122]. Intuitively, a property p can only be true infinitely often if there is a loop in the transition system in which p is made true. So the strong fairness constraint (p, q) says that if there is some loop which makes p true infinitely often, then q must be made true infinitely often by the loop as well. If this is not the case, the loop is not strongly fair and the loop must be exited after a finite number of iterations. For example, specifying strong fairness constraint (p, q) for the Kripke structure in Figure 10.6, implies that run s1, s1, . . is not strongly fair, since q never becomes true. Strong fairness constraint (p, q) only becomes true when we exit the loop around s1. Using a strong fairness constraint, therefore, we can specify that some loop must be exited eventually. Note that run s1, s1, . ., s1, s2, s3, s3, . . does satisfy strong fairness constraint (p, q). Even though q is false infinitely often in this run, the strong fairness constraint is satisfied, since p is false infinitely often as well.
Encoding strong fairness. We now address the question how strong fairness constraints can be encoded in workflow specifications. We have chosen to specify for every hyperedge h that is triggered by an external event a strong fairness constraint that states that if h is relevant infinitely often, it must be taken infinitely often. The strong fairness condition for the complete activity hypergraph is the conjunction of all individual strong fairness constraints1:
sf =df
h∈HyperEdges|¬ internal(h)
( stable ∧ source(h) C , stable ∧ target(h) C )
1Strictly speaking, the formalisation does not express this since it does not state thath should
be taken. But for models in which no source and target of a hyperedge is contained in the source and target of another one, the formalisation is correct.
10.3· Strong fairness 165 Predicate internal has been defined in Chapter 6 on page 83. This strong fairness constraint states that the environment must behave in a fair way: if a hyperedge is infinitely often relevant in a stable state, the environment must generate the trigger event of this hyperedge some time and must make the guard true some time. We assume that the guard is satisfiable. For the example activity diagram in Figure 10.5, strong fairness constraint ([A] C , [WAIT] C ) states that activity node A must terminate some time. So the run in Figure 10.5 is not strongly fair, because node A is infinitely often contained in the configuration, but node WAIT is not. In this run, the environment does not behave in a fair way; consequently, we cannot give any guarantee about the correct functioning of the workflow system, for example termination of the workflow.
We do not put a strong fairness constraint for hyperedges that are triggered by the system itself, so by some internal event. The enabling of these hyperedges does not depend upon the environment, but solely upon the system itself. Since we are specifying the system, it does not make sense to put any assumptions upon it. Therefore, hyperedges triggered by an internal event do not have to be strongly fair.
An alternative way to encode strong fairness constraints is to specify a strong fairness constraint for each cycle in the generated Kripke structure. But this results in a far greater number of strong fairness constraints, since a workflow specification with external events will have cycles in almost every state (cf. Figure 10.5). In addition, we would have to take into account that for some cycles, namely those caused by internal hyperedges, no strong fairness constraints must be specified. Detection of such cycles is hard and cumbersome.
Verifying strong fairness. Each strong fairness constraint (p, q) is equivalent to LTL constraint G F p⇒ G F q, where (as explained before) G ϕ means that ϕ is globally true in every state of the run and Fϕ means that ϕ is true in some future state of the run. At first, we tried to encode the strong fairness constraints as antecedent of the LTL property that has to be verified and then use an ordinary LTL model checker likeNuSMV or Spin. Since we have a lot of strong fairness constraints, however, verification of these models was undoable in practice. To illustrate this, our example has 21 hyperedges, so 21 strong fairness constraints. This already is too much for bothNuSMV and Spin: we were not able to verify the simple property sf ⇒ false (true iff the model has no run), where sf is the conjunction of the strong fairness constraints for every hyperedge, as explained and defined above.
We therefore decided to use an existing special algorithm for model check- ing LTL formulas with strong fairness constraints. The algorithm was defined by Kesten, Pnueli and Raviv [110]. With this algorithm, the strong fairness con- straints are not encoded in the LTL formula that has to be verified, but the strong fairness constraints are added to the Kripke structure. The resulting Kripke struc- ture with the strong fairness constraints is called a Fair Kripke Structure [110].
166 Chapter 10· Verification of functional requirements The algorithm restricts the evaluation of an LTL formula to strongly fair runs only. The algorithm has been implemented in a tool called Temporal Logic Veri- fier (TLV) [139]. TLV performed significantly better thanNuSMV and Spin: TLV only took 20 seconds to verify false under the strong fairness constraints. But un- fortunately, TLV does not support batch processing, so we could not integrate it into TCM. We therefore implemented the algorithm of Kesten et al. [110] in the open source model checker NuSMV, which does support batch processing. The resulting strong fairness model checker is calledNuSMVfair. It is now part of the
NuSMV 2.1 model checker, which can be downloaded from the NuSMV homepage at http://nusmv.irst.itc.it.