A Graphical Tool for Proving Progress - CiteSeerX

A Graphical Tool for Proving Progress Flemming Andersen Kim Dam Petersen Jimmi S. Pettersson Tele Danmark Research, Lyngs Alle 2, DK-2970 Hrsholm

Abstract. We describe a graphical tool for proving leadsto progress

properties of UNITY programs. The tool allows a user to draw Directed Acyclic Graphs (DAGs), to check that DAGs are proof lattices, similar to the idea of Owicki and Lamport. From each proof lattice the desired progress property is deduced. Edges in proof lattices are annotated with information describing how to prove the property that they represent. The tool transforms a DAG to a natural deduction-like proof, similar to the style used by Chandy and Misra. This proof is then, by a compiler, translated into a proof script which is checked by a theorem prover. With this graphical tool it is possible, modulo the strength of the theorem prover, to automatically prove that a program satis es a leadsto property on the basis of a proof lattice that outlines the proof structure.

1 Introduction The work presented here is part of a project on building a software veri cation tool for telecommunication industry; a tool which can be used by software engineers without detailed knowledge on logic or veri cation. The activities in the project are currently based on the UNITY theory [4], which consists of a parallel programming language and a logic for reasoning about these programs. For UNITY we have previously produced a theory in the HOL theorem prover [7] called HOL-UNITY [1] which allows for mechanised reasoning about UNITY program properties and a compiler [9] which translates UNITY programs and properties to the internal form required by HOL-UNITY. The UNITY theory has been chosen because it is simple and provides a wide collection of deduction rules. However, we consider it powerful enough to serve as a foundation for other programming languages, such as SDL [6], C [8] and C++ [13], which are more widely used in the telecommunication industry. That this is possible has been suggested by the fact that Ulla Binau in her PhD thesis [3] shows how a non-trivial subset of C++ extended with constructs for parallelism can be translated into UNITY, and from a subset of UNITY to C++. As a rst step towards hiding veri cation details from a user of the HOLUNITY theorem prover we have produced a compiler [9], which translates UNITY programs and properties written in the UNITY notation into the less legible notation, which is required by the HOL-UNITY theorem prover. The proof of a progress property in UNITY, and other temporal logics, consists of decomposition of the property into simpler properties, which can be

proved directly, by applying a set of inference rules, and can be composed to yield the desired property. The decomposition process involves a book-keeping of which properties have actually been veri ed, and which inference rules to apply to the veri ed properties in order to obtain the desired property. A step towards hiding veri cation details from the software engineer is to produce a graph editor that allows a user to draw the structure of a progress property. Owicki and Lamport show in [10] how specialised Directed Acyclic Graphs (DAGs) can be used to structure the decomposition of a progress property in Temporal Logic, they call such DAGs for proof lattices. In this paper we show that the decomposition of the UNITY progress property leadsto can be described by the same structure. Because our goal is to use the proof lattice for mechanised proving, we require the edges that represents a decomposed progress property to be annotated with information that allows the theorem prover to prove the decomposed property. For this reason we use the name annotated proof lattices for our proof lattices to distinguish between those of Owicki and Lamport. The graphical editor of our tool allows a user to construct a Directed Acyclic Graph, by drawing the annotated edges and nodes, that it consists of. From this graph the tool deduces what basic progress properties have to be proved for the graph to be a proof lattice and how to combine these basic properties to achieve the desired progress property represented by the lattice. The tool then generates these proof obligations as output in a natural deduction style. Each edge annotation is added to its associated basic proof obligation. The compiler part of the tool [9] translates the natural deduction style proof into a proof script readable by the theorem prover part of the tool [1, 7]. The complete tool is a system, in which a progress property can be proved by rst drawing a proof lattice, that, suciently detailed, motivates its correctness and then press a button which, without further intervention, ships o the proof lattice to the compiler and the theorem prover to check the proof. The paper is organised as follows. In Section 2 we give a general description of our annotated proof lattices. The section includes a discussion, based on the box concept described by Owicki and Lamport, on how to represent state space restrictions in a proof lattice. In Section 3 we describe how the UNITY progress relation leadsto can be used as the basic progress relation of the annotated proof lattices. Section 4 describes some of the inference rules in UNITY for deducing leadsto and shows the structure of the chosen annotations. Section 5 sketches the implementation of the tool. The section also shows the form of the proof scripts produced by the tool and describes how the theorem prover is able to verify properties from their scripts.

2 Proof Lattices Owicki and Lamport describe in [10] how a proof lattice for a program can be used to outline the proof structure of a progress formula in temporal logic of form p ; q. A proof lattice is a Directed Acyclic Graph with nodes labeled by temporal formulae, that has a single entry node and a single exit node and,

where for each node, labeled r, with outgoing edges to nodes s1 ; : : :; sn; n  1 the formula r ; s1 _ : : : _ sn hold. Owicki and Lamport prove that if there exists a proof lattice for a program with an entry node labeled p and an exit node labeled q then the formula p ; q is satis ed. We will use the name proof lattice theorem for this theorem. In this paper we de ne a variant of proof lattices, called annotated proof lattices, which is adapted to progress relations of state transition systems. In our variant of proof lattices, nodes are labeled with state dependent predicates, i.e. functions from states to truth values. Our aim is to use a proof lattice as a proof sketch that can be checked by a theorem prover. To achieve this, we introduce two extra requirements: (1) nodes with multiple (> 1) outgoing edges must satisfy implication, and (2) nodes with a single outgoing edge must be annotated with information by which the theorem prover can check the associated ; property. In general annotations are without any structure. However, when we consider UNITY leadsto progress properties, the annotations will represent inference rules that justi es deduction of these properties. Annotated proof lattices are formally de ned as follows: De nition 1 (Annotated Proof Lattice) An annotated proof lattice for a program over a relation ;, a set A of annotations, and a set of annotated relations ;a ; a 2 A, which are subsets of ; is a nite directed acyclic graph with nodes labelled by state dependent predicates and edges optionally labelled by annotations such that: 1. There is a single entry node that has no incoming edges. 2. There is a single exit node that has no outgoing edges. 3. If a node labelled r has a single outgoing edge to a node labelled s, then the edge is annotated, with say a, and r ;a s holds. 4. If a node labelled r has multiple outgoing edges to nodes labelled s1 ; : : :; sn ; n > 1, then [r ) (s1 _ : : : _ sn )]. The notation p _ q denotes state abstracted disjunction, i.e. given a state it yields the disjunction of p and q in that state, and the notation [p] denotes satisfaction of p in every state. The proof of Owicki and Lamport's proof lattice theorem has a structure which can easily be adapted to hold for annotated proof lattices. To prove this it requires a few theorems about the lattice relation ;, that expresses re exivity, transitivity and disjunctivity.

p;p p ; q; q ; r p;r [p ) (q1 _ : : : _ qn )]; q1 ; r ; : : :; qn ; r p;r

(1) (2) (3)

The proof lattice theorem can be stated formally as follows in our setting:

Theorem 2 If there exists an annotated proof lattice over a relation ; that satis es (1){(3), with an entry node labeled p and an exit node labeled q, then p;q

Proof First we prove a simple lemma: if a node r has outgoing edges to s1 ; : : :; sn ; n  1 then r ; (s1 _ : : : _ sn ).

If n = 1 then the node has a single outgoing edge. By de nition this edge is annotated, say with a, and r ;a s1 . By de nition the annotated relations are subsets of ;, hence r ; s1 . Otherwise we have n > 1. In this case the node has multiple outgoing edges. By de nition [r ) (s1 _ : : : _ sn )]. From theorem 3 about the ; relation we get r ; (s1 _ : : : _ sn ). This completes the proof of the lemma. From this lemma we realise that an annotated proof lattice has the same structure as a proof lattice in the Owicki and Lamport setting. We refer to their paper [10] for the completion of the proof. 2

Restricted State Space Owicki and Lamport allow a sub-lattice of a proof lattice to be surrounded by a box annotated with an invariant 2r to indicate that the invariants holds in conjunction with temporal formulae in the nodes of the sub-lattice. They describe how it is sucient to prove the invariant at entrance to the sub-lattice and that it can be left out at the exit. This is stated by the following invariant progress theorem: (p ^ 2r ) ; q (4) (p ^ 2r ) ; (q ^ 2r ) The purpose of boxing is to restrict the state space by some predicate r. In our setting, however, nodes are labelled by state dependent predicates rather than temporal logic formulae. This means, we can not use 2r. As a solution we introduce the notation 2; r, which expresses that r holds forever, once it is satis ed. The invariant progress theorem can now be formalised in our setting as: (p ^ r ) ; q ; 2; r (5) (p ^ r ) ; (q ^ r ) Based on this theorem it is possible to formalise the concept of boxed annotated proof lattices. We can prove that the proof lattice theorem also holds for such lattices. We will refrain from doing so, due to the limited space at our disposal in this paper. Unless otherwise speci ed proof lattices in the rest of the paper will be used in the meaning of annotated proof lattices.

3 UNITY proof lattices The UNITY progress relation leadsto satis es theorems (1){(3). Hence, it can be used as a basis relation for annotated proof lattices. Such lattices have actually been used in proving leadsto properties of two smaller program examples: a lift control program [2], and a version of the Sliding Window Protocol [12]. In these examples the annotations for the simple implication implies, the basic UNITY progress property ensures, and an induction relation are used. These UNITY annotations and others are discussed in the next section. To show what a proof lattice looks like, we present one of the proof lattices from the Sliding Window Protocol in Figure 1. The lattice demonstrates the nr > k

nr > k ^ ack[1]  k

)PPPq

ensures

? nr > k ^ ack[1] = nr ? 1 PPq implies P

ack[1]  k

nr > k ^ ack[1] > k

  / implies

? ensures freceive ack[1]g

restrict valid ^ hs  k

lu > k

Fig. 1. Example of a proof lattice steps involved in proving the property nr > k leadsto lu > k. This leadsto property reads: if a message k has been delivered to the receiver, then sooner or later, the transmitter will receive an acknowledgement for message k. The split at the top node nr > k into two branches, indicates that the proof has two cases: ack[1]  k and ack[1] > k each of which has to be considered separately. In the rst case an ensures followed by an implies proof step leads to ack[1]  k, a situation, which, in the second case, is reached by a single implies proof step. From this situation a nal ensures proof step leads to the goal lu > k. In the last ensures proof step additional information is supplied in the annotation. To make the predicates more readable, we use traditional predicate notation, without subscripts, in the proof lattices. Our graphical tool, described in the next section, translates these predicates into proper state dependent predicates before handling them over to the theorem prover. The property presented in Figure 1 only holds in a state space restricted by a predicate (valid ^ hs  k). This restriction is denoted by the restrict annotation in the lattice.

4 UNITY Annotations The UNITY logic provides a wide collection of inference rules for deducing

leadsto properties. We want the annotation on edges to inform a theorem prover

on which inference rule to apply. Optionally the annotation can be given extra information that indicates how to apply the rule, or speed up the deduction process.

Implication The annotation implies indicates that the leadsto property follows from an implication. The UNITY theorem [p ) q ] p leadsto q justi es this annotation. The HOL-UNITY theorem prover reduces the state abstracted implication to a rst order logic implication and then applies the tactics described in [11].

Ensures The annotation ensures indicates that the basic UNITY progress relation should be used to prove the property. The UNITY theorem p ensures q p leadsto q

(6)

justi es this annotation. An ensures property expresses that the program has an ensuring action which, when executed in a state satisfying p, will ensure satisfaction of q, and p holds until q holds. The HOL-UNITY theorem prover is able to validate this ensures property directly. But, because this implies that the theorem prover will have to test each action to nd the ensuring action, an ensures annotation allows the ensuring action to be optionally given as parameter, for optimising the process of proving. Figure 1 contains two examples of ensures annotated edges. One with and one without an ensuring action parameter.

Lattice To avoid large complex lattices, we introduce the annotation lattice(l) to denote insertion of another proof lattice. This plays the role of lemma in traditional proving. To avoid mutual dependencies we will require that the inserted proof lattice has been veri ed. The annotation in this case is justi ed by the leadsto property following from the inserted proof lattice.

Induction UNITY supports inductive proving of progress by the theorem 8m : p ^ (M = m ) leadsto (p ^ (M k

Fig. 2. Proof lattice with an induction edge parameter k ? nr is the metric function M and l is the name of an already proved lattice.

PSP

Another rule, which is often used in practice is PSP (Progress-Safety-Progress): p leadsto q ; r unless b (8) p ^ r leadsto (q ^ r ) _ b The relation unless represents a basic safety relation, that can be proved directly by the theorem prover. We will use ve parameters in a PSP annotation. One parameter for each of the four predicates p, q, r and b, and a parameter l for the lattice proving the leadsto property in the assumption. An example on how to use the PSP rule is sketched in Figure 3.

Cancellation

Another rule, which is used to simplify predicates, is the cancellation rule: p leadsto q _ b ; b leadsto r p leadsto q _ r

(9)

p^r

? PSP(p; q; r; b; l) ? ?@@R q^r b @ ? a @ R? a (q ^ r) _ b

1

2

s

Fig. 3. Proof lattice with a PSP edge In this inference rule the predicate p can be determined from the context, as the beginning node. The annotation requires ve parameters: three parameters to specify the remaining predicates: q, r, and b and two parameters l1 and l2 to specify the already proved proof lattices in the assumptions. An example of how to use this rule is sketched in Figure 4. p

? cancellation(q; b; r; l ; l ) ? ?@@R q r ? a @ a R? @ 1

q_r

1

s

2

2

Fig. 4. Proof lattice with a cancellation edge

In nite branching The only inference rule we have seen until now which introduces in nite branching is the induction rule; but only in a restricted form. The UNITY progress relation leadsto, however, allows for a more general in nite branching, as indicated by the inductive de nition: p ensures q p leadsto q p leadsto q ^ q leadsto r p leadsto r

(10) (11)

8Wi : pi leadsto q (12) ( i pi ) leadsto q where i ranges over some index set. The proof lattices can be extended to describe a wider class of proofs if a notation is introduced for denoting an indexed family of branches. This extension may be achieved, if index parameters are allowed as annotations to the lattice edges. Using this approach, edges can represent in nite collections of branches indexed by some binding variable i. Such a variable i is then considered a constant of unknown value in the succeeding part of the lattice, i.e. both when i is used in predicates as well as annotations. In Figure 5 we have outlined an example of a proof lattice having an in nite branching with the edge annotated by i. P

? i ? ?@@R S 1(i) S 2(i) a (i)@ @R? ?a (i) R(i)

1

Q

2

Fig. 5. Parametric branching proof lattice This proof lattice is then expected to be proved by the inference rule expressing in nite disjunction of leadsto properties.

5 Mechanised proof lattice veri cation Our tool consists of three parts: (1) the graph editor, which allows the user to draw a DAG; from this it produces a proof in natural deduction style that checks the basic and composite lattice properties, (2) the HOL-UNITY compiler which compiles the proof into a form readable by the HOL-UNITY theorem prover, and nally (3) the HOL-UNITY theorem prover, which checks the proof. The graph editor itself is divided into three parts: (1) a pure graphical editor, which allows the user to draw a DAG; from the DAG it generates a list of text and poly-line objects with their graphical attributes, (2) an analyser that constructs an internal DAG data structure from the graphical objects, and checks that it has the structure of a proof lattice, and (3) a proof generator that produces a proof in natural deduction style from the DAG data structure. As pure graphical editor we currently use a general purpose public domain image drawing program TGIF [5]. This is expected to be replaced by a more

specialised editor, in which the fancy editing modes of TGIF are replaced by fancy boxing and annotation modes. The analyser and proof generator is integrated in the same program. The analyser scans the output of TGIF for retrieving text and poly-line objects. The analyser then uses a simple coordinate analysis to classify the text objects as being nodes, annotations, etc. Following this, it checks that the graph has the structure of a proof lattice, i.e. that it has a single entry and exit node, that all single outgoing edges are annotated and all single outgoing edges are annotated, and that it is acyclic, i.e. has no cycles. Presently the analyser is not able to detect and handle state space restriction boxes. The internal DAG data structure provides a possibility for backward and forward traversing from arbitrary nodes or edges in the lattice. This makes it possible to experiment with other representations of the lattice proof. The present version of the proof generator produces a proof in natural deduction style as listed in Figure 6. This Figure is the result of analysing the proof lattice showed in Figure 1. Our compiler is presently being extended to understand the presented natural deduction style proofs and produces proper output to the theorem prover from it. PROPERTY nr > k LEADSTO lu > k PROOF (1) { ensures } nr > k /\ ack[1] k /\ ack[1] = nr - 1 (2) { implies } nr > k /\ ack[1] = nr - 1 LEADSTO ack[1] >= k (3) { ensures {receive_act[1]} } ack[1] >= k LEADSTO lu > k (4) { TRANS (2) (3) } nr > k /\ ack[1] = nr - 1 LEADSTO lu > k (5) { TRANS (1) (4) } nr > k /\ ack[1] k (6) { implies } nr > k /\ ack[1] > k LEADSTO ack[1] >= k (7) { TRANS (6) (3) } nr > k /\ ack[1] > k LEADSTO lu > k (8) { DISJ [(5), (7)] } nr > k LEADSTO lu > k END

Fig. 6. Proof script produced by the graph analyser The proof script in Figure 6 starts with the property to be proved. This is followed by a list of proof steps. Each proof step is described by three compo-

nents: the number of the proof step, a UNITY rule, optionally supplied some arguments, and the property proved by the proof step. The resulting property of the last proof step should be identical to the one, which the script states is to be proved. The names TRANS and DISJ denotes the transitivity rule and nite disjunction rule respectively. The names ensures and implies represents the annotation rules discussed in the previous section. The rst versions of the proof generator produced code directly for the HOLUNITY theorem prover, as showed in Figure 7. The equivalent to this code will be generated by the HOL-UNITY compiler given the more legible predicate notation. val lat_thm = let val tm_1 = --`nr >* (K k)`-val tm_2 = --`nr >* (K k) /\* ack at (K 1) * (K k) /\* ack at (K 1) >* (K k)`-val tm_4 = --`nr >* (K k) /\* (ack at (K 1) =* (nr -* (K 1)))`-val tm_5 = --`ack at (K 1) >=* (K k)`-val tm_6 = --`lu >* (K k)`-val lma_2 = TAC_PROOF(([], --`(^tm_2 LEADSTO ^tm_4) ^Pr`--), ensures_LAT_TAC {act= NONE}) val lma_4 = TAC_PROOF(([], --`(^tm_4 LEADSTO ^tm_5) ^Pr`--), implies_LAT_TAC) val lma_5 = TAC_PROOF(([], --`(^tm_5 LEADSTO ^tm_6) ^Pr`--), ensures_LAT_TAC {act= SOME(--`act_3_fn 1`--)}) val thm_5 = lma_5 val thm_4 = TAC_PROOF(([], --`(^tm_4 LEADSTO ^tm_6) ^Pr`--), TRANS_LAT_TAC {thm1= lma_4, thm2= lma_5}) val thm_2 = TAC_PROOF(([], --`(^tm_2 LEADSTO ^tm_6) ^Pr`--), TRANS_LAT_TAC {thm1= lma_2, thm2= thm_4}) val lma_3 = TAC_PROOF(([], --`^tm_3 LEADSTO ^tm_5) ^Pr`--), implies_LAT_TAC) val thm_3 = TAC_PROOF(([], --`(^tm_3 LEADSTO ^tm_6) ^Pr`--), TRANS_LAT_TAC {thm1= lma_3, thm2= thm_5}) val thm_8 = TAC_PROOF(([], --`(^tm_1 LEADSTO ^tm_6) ^Pr`--), DISJ_LAT_TAC {thml= [thm_2,thm_3]}) in thm_8 end

Fig. 7. HOL-UNITY theorem prover code In the theorem prover code identi ers of temporary values has been pre xed with: tm, lma, thm to indicate that the value is a term, proved basic progress

property, or proved composite progress property. The tactics *_LAT_TAC are composed from the proof lattice annotations or denotes the composition rules. A more detailed description of the tactics for proving ensures and implies annotated properties may be found in [11]. The code for the transitivity lattice tactic is sketched in Figure 8. The tactic rst retrieves the transitivity theorem, val TRANS_LAT_TAC = let val LEADSTO_TRANS_THM = theorem "leadsto" "LEADSTO_TRANS_THM" in fn {thm1= thm1, thm2= thm2} => ACCEPT_TAC (MATCH_MP LEADSTO_TRANS_THM (CONJ thm1 thm2)) end

Fig. 8. HOL-UNITY code for the transitivity tactic the two leadsto theorem given as assumptions are then matched against the transitivity theorem to yield a consequential theorem; this theorem is nally accepted, provided it has the expected form.

6 Conclusions We have presented a graphical tool for drawing proof lattices, which produces a proof script for a theorem prover. The tool is yet only a prototype. This makes experimentation with various formats of proof scripts and annotations easier; but requires insight of the user. The tool has been developed with mechanised proving of UNITY progress properties in mind, but, as the core system consists of a simple graph search, it is easily adapted to other theorem provers or graph representable relations. The present tool can generate proof scripts in two formats: a natural deduction style proof script suitable for compilation or a direct proof which the theorem prover is able to check. An existing compiler for UNITY that generates proof scripts for the HOLUNITY theorem is presently being extended to support the presented natural deduction style proofs. The impact of this is a system, in which progress properties can be proved by drawing a suciently detailed proof lattice, and then let the compiler and HOL-UNITY theorem prover do the rest, provided, of course, the HOL-UNITY theorem prover is able to prove the basic properties generated from the proof lattice. It is even be possible, during the construction process of the proof lattice, to check the validity of the individual edges by shipping them o to the compiler and theorem prover. Hence, errors during the proof construction can be captured at an early stage.

We have successfully used the presented proof lattices for developing progress proofs for two smaller examples. The developed proof lattices provide a compact and readable view of the proof. The actual proof of these lattices was originally done by a manual translation to a proof script, a tedious job, which inspired us to make the presented tool for automating the process. The tool is expected to be used as part of our next exmaple, proving properties of an ATM protocol.

References 1. F. Andersen. A Theorem Prover for UNITY in Higher Order Logic. PhD thesis, Technical University of Denmark, 1992. Also published as TFL RT 1992-3, Tele Danmark Research, 1992. 2. F. Andersen, K.D. Petersen, and J.S. Pettersson. Program Veri cation using HOL-UNITY. In HUG'93: HOL User's Group Workshop, pages 1{17, 1993. 3. Ulla Binau. Correct Concurrent Programs: A UNITY design method for Compositional C++ Programs. PhD thesis, Technical University of Denmark, 1994. 4. K. M. Chandy and J. Misra. Parallel Program Design: A Foundation. Addison{ Wesley, 1988. 5. W. C.-W. Cheng. TGIF(n) Unix Manual. Version 2.14, patchlevel 9. 6. Editors: O. Frgemand and A. Sarma. SDL '93 Using Objects: Proceedings of the Sixth SDL Forum, Darmstadt, Germany 1993. North Holland, 1993. 7. M.J.C. Gordon. HOL { A Proof Generating System for Higher Order Logic. Cambridge University, Computer Laboratory, 1987. 8. B.W. Kernighan and D.M. Ritchie. The C Programming Language. Prentice Hall. 1978, Second Edition 1988. 9. K.E. Nielsen. The HOL-UNITY compiler. Technical report in preparation, Tele Danmark Research, 1994. 10. S. Owicki and L. Lamport. Proving Liveness Properties of Concurrent Programs. ACM TOPLAS, Vol. 4, No. 3, July 1992. Pages 456{495. 11. K.D. Petersen. HOL-UNITY Tactics { HOL Tactics for Automatic Proof of UNITY Properties. TFL LD-1994-2, Tele Danmark Research, December 1993. 12. K.D. Petersen and J.S. Pettersson. Proving Protocols Correct { Proving Safety and Progress Properties of the Sliding Window Protocol using HOL-UNITY. Research Report TFL RR 1993-3, Tele Danmark Research, December 1993. 13. B. Stroustrup. The C++ Programming Language. Addison Wesley. 1991. Second Edition, 1993.

This article was processed using the LaTEX macro package with LLNCS style