A knowledge-based interactive verifier for logic programs

Transcription

1 International Journal of Knowledge-based and Intelligent Engineering Systems 18 (2014) DOI /KES IOS Press A knowledge-based interactive verifier for logic programs Emmanouil Marakakis, Haridimos Kondylakis and Nikos Papadakis Department of Informatics Engineering, Technological Educational Institute of Crete, Heraklion, Greece Abstract. This paper presents an interactive verifier for logic programs. These logic programs are constructed by a schema-based method. Each program is associated with proof schemes due to the program development method. The correctness proof of a program is guided by its associated proof schemes. The main components of the verifier are the prover which carries out the proof steps, the knowledge base (KB) which includes representations of all theories and transformation rules, the KB update which supports the update of KB and the graphical user interface (GUI). The emphasis in the design of this proof checker is on effective guidance of the proof based on the activated proof schemes and on performance by the verifier of tedious, trivial and time consuming tasks. The difficult proof decisions are taken by the user, then, the proof checker applies them. The design of the interface is based on providing the user the required support for the proof of a theorem and for the update of KB. This system is an effective and useful tool for the interactive verification of non-trivial logic programs. Keywords: Interactive verifier, proof checker, logic programs, correctness, proof schemes, knowledge representation 1. Introduction Lately the need for systems that ensure the correctness of software is increasing rapidly. Software failures can cause significant economic loss, endanger human life or environmental damage. Therefore, the development of systems that verify the correctness of software under all circumstances is crucial. Formal methods are techniques based on mathematics which aim to make software production an engineering subject as well as to increase the quality of software. Formal verification, in the context of software systems, is the act of proving or disproving the correctness of a system with respect to a certain formal specification or property, using formal methods of mathematics. Formal program verification is the process of formally proving that a computer program does exactly what is stated in the program specification it was written to realize. Corresponding author: Emmanouil Marakakis, Department of Informatics Engineering, Technological Educational Institute of Crete, Heraklion, GR-71410, Greece. Tel.: ; Fax: ; mmarak@cs.teicrete.gr. Automated techniques for producing proofs of correctness of software systems fall into two general categories: 1) Automated theorem proving [10], in which a system attempts to produce a formal proof given a description of the system, a set of logical axioms, and a set of inference rules. 2) Model checking, inwhich a system verifies certain properties by means of an exhaustive search of all possible states that a system could enter during its execution. Interactive verifiers or proof checkers are programs which are used to help a user in building a proof and/or find parts of proofs. These systems provide information to the user regarding the proof in hand, and then the user can make decisions on the next proof step that he will follow. Interactive theorem provers are generally considered to support the user, acting as clerical assistants in the task of proof construction. The interactive systems have been more suitable for the systematic formal development of mathematics and in mechanizing formal methods [4]. Proof editors are interactive language editing systems which ensure that some degree of semantic correctness is maintained as the user develops the proof. The proof checkers are placed between the two extremes, which are the automatic theorem provers and the proof editors [8]. ISSN /14/$ IOS Press and the authors. All rights reserved

2 144 E. Marakakis et al. / A knowledge-based interactive verifier for logic programs In this paper we will present a proof checker or an interactive verifier for logic programs which are constructed by a schema-based method [11,13]. A metaprogram is any program which uses another program, the object program, as data. This proof checker is a meta-program which reasons about object programs. The logic programs and the other elements of the theory represented in the KB of this system are the object programs. The KB is the data of the proof checker. The proof checker accesses and changes the KB. The representation of the underlying theory (object program) in the proof checker (meta-program) is a key issue in the development of the proof checker. The size of programs which can be verified by this proof checker is non-trivial. This system has been implemented in Sicstus Prolog and its interface has been implemented in Visual Basic. An early version, a prototype, of this system has been presented in [15]. The knowledge representation which is crucial for the design and implementation of the system has been presented in [14]. In this paper we present the overall design, implementation and use of this interactive verifier. The rest of the paper is organized as follows. In Section 2, we present basic definitions, background and related work. Then, in Section 3 the architecture of the proof-checker and an overview of its main components are presented. System interface and basic tasks are presented in Section 4. Then, knowledge representation is discussed in Section 5. Section 6 describes in detail the prover and illustrates a set of successive proof steps. Section 7 presents the evaluation of the prover. Finally, Section 8 concludes the research results of this paper and discusses future research. 2. Basic definitions, background and related work 2.1. Basic definitions and background Definition 1. Formal proof is a structure of valid applications of inference rules? A formal proof might take one of the following forms: a) a sequence of lines in which each line is either an axiom or follows from a number of preceding lines by an inference rule. The last line of the proof is called the conclusion of the proof. b) A tree in which each leaf is an axiom and each non-leaf node follows from its immediate sub-nodes by an inference rule. The root of the tree is called the conclusion of the proof. This paper studies the interactive verification of logic programs which have been constructed by a schema-based method [11] with respect to their formal specification. In the following, we define formally the form of logic programs and the one of specifications, as well as the form of theorems that can be proved by this prover. The following notation is used in this paper: <> stands for the empty sequence. :: stands for the term constructor for sequences, i.e. x :: q is a sequence with head x and tail q. #q stands for the length of sequence q. Σ is the summation operator for all numeric data types. x a y stands for the less-than or equal comparison of an unspecified type elements x and y. τ stands for a type variable. Z and seq stand for the data types of integers and sequences respectively. The other notation is the standard one which is used in Logic Programming. We assume that the reader is familiar with it. Definition 2. Let Pr be a logic program constructed by the method in [11,13], excluding the definitions of the Data Type (DT) operations. Let p(x 1,...,x n ) L 1,...,L m be a clause where x 1,...,x n are distinct variables and L 1,...,L m are literals whose arguments are variables or constants. Let y 1,...,y d be the variables in the body of clause which do not appear in its head. The clause p(x 1,...,x n ) y 1,..., y d (L 1... L m ) is equivalent to the previous one. Suppose that there are r such clauses for predicate p/n p(x 1,...,x n ) E 1...p(x 1,...,x n ) E r where each E i (1 i r) stands for a corresponding formula of the form y 1,..., y d (L 1... L m ). Then the completed definition of the predicate p/n is the formula: x 1... x n (p(x 1,...,x n ) E 1... E r ) Let p 1,...,p k be all the predicate symbols which appear in the head atoms of program clauses in Pr. The completion of program Pr denoted by comp(pr) is the set of completions of p 1,...,p k. The predicate sum(x1, x2) where Type(sum) = seq(z) Z is true iff x2 is the sum of a sequence of integers x1. The following program, Pr, for predicate sum/2 has been constructed by the method in [11,13] excluding the definitions of DT operations. Modes and types are omitted for simplicity of presentation. Types are shown in the completion of clauses. The predicates empty_seq/1, head/2 and tail/2 are DT operations for sequences. neutral_add_subtr_int/1 and plus_int/3 are DT operations for integers. The definitions of DT op-

3 E. Marakakis et al. / A knowledge-based interactive verifier for logic programs 145 erations are omitted from the definition of Pr because they are assumed to be basic construction elements of the underlying program development method. sum(x1, x2) p1(x1) p2(x1, x2) sum(x1, x2) p1(x1) p3(x1, x3, x4) sum(x4, x5) p4(x1, x3, x5, x2) p1(x1) empty_seq(x1) p2(x1, x2) neutral_add_subtr_int(x2) p3(x1, x2, x3) p5(x1, x2, x3) p6(x1, x2, x3) p5(x1, x2, x3) head(x1, x2) p6(x1, x2, x3) tail(x1, x3) p4(x1, x2, x3, x4) plus_int(x3, x2, x4) Note that this definition of completion is slightly different from the standard one in [3,9]. We do not add in the comp(pr) negative unit clauses for undefined predicates in Pr because these predicates are assumed to be implemented by DT operations. We also omit the equality theory, which is assumed to be part of the theory of DTs. The logic program completion comp(pr) of Pr is as follows. x1/seq(z), x2/z, [sum(x1, x2) (p1(x1) p2(x1, x2) [ x3/z, x4/seq(z), x5/z, [ p1(x1) p3(x1, x3, x4) sum(x4, x5) p4(x1, x3, x5, x2) ]])] x1/seq(z), [p1(x1) empty_seq(x1)] x1/seq(z), x2/z, [p2(x1, x2) neutral_add _subtr_int(x2)] x1/seq(z), x2/z, x3/seq(z), [p3(x1, x2, x3) p5(x1, x2, x3) p6(x1, x2, x3)] x1/seq(z), x2/z, x3/seq(z), [p5(x1, x2, x3) head(x1, x2)] x1/seq(z), x2/z, x3/seq(z), [p6(x1, x2, x3) tail(x1, x3)] x1/seq(z), x2/z, x3/z, x4/z, [p4(x1, x2, x3, x4) plus_int(x3, x2, x4)] Definition 3. Let Pr be a program, excluding the DT definitions. Let A be the theory of underlying DTs including the specifications of the DT operations. Then the meaning Prog of a program is defined as follows. Prog = comp(pr) A For example, the theory A of DTs for predicate sum/2 consists of axioms, lemmas and specifications of DT operations. Axioms Domain closure axiom for sequences x1/seq(a2), [x1 =<> ( x3/a2, x4/seq(a2), [x1= x3::x4])] Uniqueness axioms for sequences i) x1/a2, x3/seq(a2), [ [x1::x3=<>]] ii) x1/a2, x3/a2, x4/seq(a2), x5/seq(a2), [x1 ::x4= x3::x5 x1= x3 x4= x5] Definition of summation operation over 0 entities [ ] #x1 x1/seq(z), x1 =<> x2 = x1 i =0 i=1 Lemmas x1/seq(a2), [x1 <> [ x3/a2, x4/seq(a2), [x1= x3::x4]]] x1/a2, x3/seq(a2), x4/seq(a2), [x3= x1::x4 ( k/n, [2 k #x3 x3 k = x4 k 1 ])] x1/seq(a2), x3/seq(a2), x4/a2, [x1= x4::x3 #x1= #x3+1] x1/a2, x3/seq(a2), x4/seq(a2), [x3= x1::x4 x1= x3 1 ] Informally, the first lemma states if a sequence x1/seq(a2) is non-empty, this is equivalent to say that x1 consists from head x3/a2 and tail x4/seq(a2). Logic specifications of DT operations x1/seq(a2), [empty_seq(x1) x1=<>] x1/z, [neutral_add_subtr_int(x1) x1= 0] x1/seq(a2), x3/a2, [head(x1, x3) [x1 <> [ x4/seq(a2), [x1= x3::x4]]]] x1/seq(a2), x3/seq(a2), [tail(x1, x3) [ x4/a2, [x1 <> x1= x4::x3]]] x1/z, x2/z, x3/z, [plus_int(x1, x2, x3) x3= x2+ x1] For each predicate (relation) p there are two versions its specification denoted by p S and its implementation denoted by p. Definition 4. Let p S be a predicate. The logic specification (Spec p ) for p S is defined to be a formula in polymorphic many-sorted FOL of the form Spec p = x/ τ(p s ( x) Def p ) where x is a tuple of distinct variables and τ is a tuple of sorts corresponding to the variables in x.def p is a formula in polymorphic many-sorted FOL which defines the relation p s ( x). For example, the initial logic specification (Spec sum ) for the relation sum S is defined to be the following formula in polymorphic many-sorted FOL. ( ) #x1 x1/seq(z), x2/z sum S (x1, x2) x2 = x1 i i=1

4 146 E. Marakakis et al. / A knowledge-based interactive verifier for logic programs Definition 5. Let Pr be a program with top-level predicate p excluding DT definitions, and Spec its specification. p does not occur in Spec and p S does not occur in comp(pr). Pr is par t ially correct with respect to Spec if Spec A comp(pr) = x/ τ(p( x) p s ( x)) Pr is complete with respect to Spec if Spec A comp(pr) = x/ τ(p( x) p s ( x)) Pr is totally correct with respect to Spec if it is both partially correct and complete. That is, Spec A comp(pr) = x/ τ(p( x) p s ( x)) In the running example, the theory and the correctness theorem are as follows. spec sum A comp(pr) = x1/seq(z), x2/z (sum(x1, x2) sum s (x1, x2)) where spec sum stands for the specification of the relation sum S (x1, x2). Suppose that we have formulated a logic specification for a logic program. We proceed to prove the correctness of program with respect to its specification by manipulating the specification into a suitable form. The form of a logic specification which often facilitates the correctness proof of a program constructed by the method in [11,13] is a structural decomposition which we call structured form of specification or structured specification (StrSp). Definition 6. The structured form of a specification is built around the structural cases of a parameter as follows. Let τ be a type and let x/τ. Suppose that there exists a finite set of constructors f 1 /n1,...,f k /nk such that for all x/τ, x = f 1 (y 1,...,y n1 )... x = f k (z 1,...,z nk ). The specification of a predicate p consists of a disjunction of sub-formulas F 1 (x)... F d (x). Each sub-formula F i (x)(1 i d) has the form S i G i where S i is of the form x = f j (y 1,...,y nj )(1 j k) and G i is either a conjunction of literals or a disjunction of conjunctions of literals. In addition, x canbeused in the correctness proofs as the induction parameter. For example, the StrSp of the relation sum S (x1, x2) is as follows. x1/seq(z), x2/z (sum s (x1, x2) [x1=<> x2= 0 [ x4/z, x5/z, x6/seq(z), [x1 = x5::x6 x2 = x5 + x4 sum s (x6, x4)]]]) StrSp is used in the theory as spec sum for the proof of the theorem. Definition 7. A proof scheme is a systematic plan of proof actions Related work LPTP [18] is closely related to this system. LPTP is an interactive theorem prover in which a user can prove correctness properties of pure Prolog programs. The formal theory underlying LPTP is the inductive extension of pure Prolog programs. Theorema on the other hand, presented in [19], is a theorem prover which supports automatic and interactive reasoning. It has been implemented in the programming language of Mathematica System. The language of Theorema is an untyped higher order language extended with sequence variables. Both systems however, do not provide a GUI neither allow runtime update of the KB. Finally it is not possible to provide the intermediate steps of the proof in readable form as in this proof checker. Systems with similar limitations are the Karlsruhe Interactive Verifier (KIV) [6], the PVS [17] and Isabelle [20,21]. KIV provides an interactive theorem prover integrated into a sophisticated tool environment supporting aspects like the automatic generation of proof obligations, generation of counter examples, proof management, proof reuse etc. PVS supports several quite powerful decision procedures and a symbolic model checker. Isabelle on the other hand is a generic proof assistant while this proof assistant is connected with a specific correctness proof method. All three systems, do not support GUI, they are executed in command line and the KB is updated using Emacs before starting the programs. In addition, the user cannot update at runtime the KB and the user has to remember previous steps in order to understand the current step and to decide for the next one. Boogie [1] is a program verification condition generator for an imperative core language. It has frontends for the programming languages C# and C enriched by annotations in First-Order Logic (FOL). Its verification conditions are constructed via a weakest preconditions calculus from FOL annotations. Verification conditions are transformed and proved. HOL- BoogieP is an extension which combines Boogie with the interactive theorem prover Isabelle/HOL. In particular, it combines automated and interactive proof methods for code-verification. The proofs in Boogie are based on the weakest precondition calculus while the proof methods in this system are FOL equivalence preserving transformations and induction. Boogie is a verifier for imperative programs while this system is for logic programs. Moreover, Boggie does not support a GUI which will help the user to understand the results of the verification process.

5 E. Marakakis et al. / A knowledge-based interactive verifier for logic programs 147 Fig. 1. The main window of the proof-checker. (Colours are visible in the online version of the article; ) JAPE (Just Another Proof Editor) [2] is a generic interactive proof editor while this proof checker has been designed for a specific correctness method. JAPE supports step-by-step interactive development of proofs in formal logic. It also provides a simple windows interface which is not friendly. JAPE generates the lines of a proof with a straightforward recursive transformation of the tree. The tree structure invisibly constrains proof moves. That is, when a rule with multiple antecedents is used, multiple proof sub-trees are generated. It isn t possible to use part of one sub-tree in proving another. JAPE has a static KB in which the user cannot perform updates. 3. Architecture of the proof checker In this section, we present the architecture of this proof checker. This verifier guides the correctness proof of a logic program by applying proof schemes associated with the logic program. The proof scheme associated with the top-level predicate is either selected automatically by the system or the user can select it from a list of five proof schemes. The proof schemes are hardwired in the design of this proof checker. The design of the proof checker aims to offer to the user effective guidance in his proof based on the proof schemes. It also aims to alleviate the user from simple, repeated and tedious proof steps by performing them automatically. In addition, it aims to allow the upgrade of prover in order to support the automation of more complex proof Fig. 2. Architecture of the proof-checker. tasks. The design of the interface aims to facilitate the proof task of the user since intense interaction is required to prove a theorem. A screenshot of the main window of this system is shown in Fig. 1. A high-level design of this system is depicted in Fig. 2. This interactive verifier of logic programs consists of three distinct parts the interface,theprover and the KB. The interface offers an environment where the user can think and decide about the proof steps that have to be applied. The user specifies each proof step and the prover performs it. The Prover of the system consists of the following two components. 1) The Spec Transformer which transforms a specification expressed in typed FOL into structured form. 2) The Theorem Proof Checker which supports the proof task of the selected correctness theorem. The KB Update subsystem allows the user to update the KB of the system through a user-friendly interface. The KB contains the representation of specifications, theorems, axioms, lemmas, andprograms complements. It also has the representation of FOL laws in order to facilitate their selection for application. These entities are represented in ground representation. The main benefit of this representation is the distinct semantics of object program variables from metavariables [7]. It should be noted that the user would like to see KB in a comprehensible form which is independent of their representation. However, the ground representation cannot be easily understood by users. Moreover, the editing of elements in ground representation is error-prone. Part of the interface of the system is the Ground-Nonground Representation Transformer component which transforms an expression in ground representation into a corresponding one in the standard formalism of FOL and vice-versa. The standard form of expressions helps users in the proof task and for the update of the KB.

6 E. Marakakis et al. / A knowledge-based interactive verifier for logic programs Fig. 3. The interface for transforming a logic specification into structured form. (Colours are visible in the online version of the article; 4. System interface and basic tasks Fig. 4. The interface for selecting theory, theorem and optionally a proof scheme. (Colours are visible in the online version of the article; played. The aim of this window is to allow the user to select the appropriate theory and optionally a proof scheme for his proof. In addition, the user can either select a theorem or define a new one. After the appropriate selections, the user can proceed to the actual proof of the theorem by selecting Prove Correctness Theorem. TH OR This proof checker has to have a well-designed user interface (UI) in order to provide guidance to its users. The design of the interface of an interactive verifier depends on users intentions. The users of this prover are interested in proving a theorem or updating the KB in order to be able to work with additional theorem proofs. So, they are expected to know very well the correctness method which is supported by this system [12, 16]. All information in the interface is presented in standard mathematical form understandable by a user. On the other hand, its representation in KB and in the proof process is in ground form which is not easily comprehensible by users. CO PY Task Transform logic specification into structured form AU If a user selects Transform Logic Specification into Structured Form from main window, then the window shown in Fig. 3 will be displayed. The aim of this window is to support the transformation of a specification into structured form according to the correctness method. This window allows the user to select a specification that will be transformed, the theory elements that will be used in a transformation step and the transformation rules that will be applied. It also allows the user to cancel transformation steps. Moreover, the user is able to produce a report for the transformations applied up to the current point of his task Task Prove program correctness If a user selects Prove Program Correctness from main window, the window shown in Fig. 4 will be dis Task Update knowledge base If a user selects Update Knowledge Base from main window, then the window shown in Fig. 5 will be displayed. This window supports the update of KB. The update of KB involves either the update of existing predicate specifications, specifications of DT operations, lemmas, theorems, logic programs and FOL laws or the insertion of new ones. When theories and theorems are updated syntactic and semantic integrity checks are performed such as detection of contradictory statements. 5. Knowledge representation A language which is used to reason about another language (or possibly itself) is called meta-language and the language reasoned about is called the object language. A meta-program is a program whose data is another program, i.e. the object program. This proofchecker is a meta-program which manipulates other logic programs. It has been implemented in Prolog and the underlying theory, i.e. the logic programs being verified and the other elements of KB, is the object program. An important decision is how to repre-

7 E. Marakakis et al. / A knowledge-based interactive verifier for logic programs 149 Fig. 5. The main window for updating KB. (Colours are visible in the online version of the article; ) sent programs of the object language (i.e. the KB elements) in the programs of the meta-language, i.e. in the prover. The knowledge representation issues of this proof checker have been presented in [14]. This section aims to support the understanding of the paper. Ground representation and non-ground representation are the two main approaches to the representation of object programs in meta-programs. In logic programming there is not clear distinction between programs and data because data can be represented as program clauses. The semantics of a meta-program depend on the way the object program is represented in the meta-program. Normally, a distinct representation is given to each symbol of the object language in the meta-language. This is called naming relation [7]. The naming relation for constants, functions, propositions, predicates and connectives is straightforward. The main problem is the representation of variables of the object language in the language of metaprogram. There are two approaches. One approach is to represent the variables of object program as ground terms in meta-program. This representation is called ground representation. The other approach is to represent the variables of object program as variables (or non-ground terms) in meta-program. This representation is called non-ground representation. We have followed the ground representation approach for the representation of elements in KB. The ground representation is more clear and expressive than the non-ground one and it can be used for many meta-programming tasks. Ground representation is suitable for meta-programs which have to reason about the computational behavior of the object program. The ground representation is required in order to perform any complex meta-programming task in a sound way. Its inherent complexity can be reduced by specialization [5]. Another issue is how the theory of the object program is represented in the meta-program. There are again two approaches. One approach is the object program to be represented in meta-program as program statements (i.e. clauses). In this case, the components of the object program are fixed. The other approach is the object program to be represented as a term in a goal that is executed in meta-program. In this case the object program can be either fixed or it can be constructed dynamically and the meta-program can reason about arbitrary object programs. This is called dynamic meta-programming. The object program in this proof checker is represented as clauses. The underlying theory is fixed for each proof task so it does not require any dynamic reformulation. In addition, the dynamic meta-programming approach requires additional CPU time and memory space to support the dynamic structures. The KB shown in Fig. 2 contains the representation of specifications, theorems, axioms, lemmas and programs complements. It also has the representation of FOL laws in order to facilitate their selection for application. These KB elements are represented in ground representation [7]. Their representation is presented in this section Representation of main symbols of object language The representation of the main symbols of the object language which are used in this paper is shown below. Object language symbol Representation constant constant object program variable term v(i), i N function term g(i), i N proposition, formulas of FOL term f(i), i N predicate term p(i), i N connectives (,,,, ),,,->, <-> exists ( ) ex for all ( ) all length of sequence x1 (#x1) len(v(1):type):nat plus (+) plus minus ( ) minus type variable term tv(i), i N type sequence seq empty sequence (<>) nil_seq sequence constructor:: seq_cons x1 i /Type (e.g. x 1 /α1) v(1, i:nat):type (e.g. v(1, 1:nat)

8 150 E. Marakakis et al. / A knowledge-based interactive verifier for logic programs :tv(1)) equality (=) eq inequality ( ) eq less-equal ( ) le greater-equal ( ) ge type natural (N) nat type integer (Z) int non-zero natural (N 1 ) posint Predicates are represented by their names assuming that each predicate has a unique name. The sum of n elements n x i is represented as the following ground i=1 term: sum(1:nat, v(2):nat, v(3, v(4):nat):type):type where Type is the type of x i. Throughout this paper we use the correctness theorem and theory for predicate sum/2. That is, Comp(Pr) Spec A = x1/seq(z), x2/z (sum(x1, x2) sum S (x1, x2)) 5.2. Representation of variables Type variables The type variables are specified by the lower case letter a followed by a positive integer which is the unique identifier of the variables e.g. a1, a2, etc. Each type variable is represented in ground form by a term of the form tv(n) where N stands for the unique identifier of the variable. For example, the ground representation of the type variables a1, a2 could be tv(1), tv(2) respectively Object program variables Object program variables and variables in specifications are expressed by using the lower case English letter x followed by a positive integer which is the unique identifier of the variables e.g. x1, x2, etc. Each object variable is represented in ground form by a term of the form v(n) where N stands for the unique identifier of the variable. For example, the ground representation of the object variables x1, x2 is v(1) and v(2) respectively. Subscripted variables of the form x1 i represent elements from constructed objects. They are represented by a term of the form v(id, i:nat):elementtype where the first argument Id represents its unique identifier and the second one represents its subscript. Id isa natural number. This type of variables occurs mainly in specifications. A term like v(id, i:nat):elementtype can be assumed as representing either a regular compound term or an element of a structured object like a sequence. The distinction is performed by checking the types of the elements x and x(i). For example, for i = 1 by checking x1:seq(α1) and x1(1:nat): α1, it can be inferred that x1(1:nat): α1 is an element of x1:seq(α1) Representation of theory The theory elements whose representation is discussed in this section are presented in Section Representation of programs and specifications Programs, structured predicate specifications and specifications of DT operations are represented by predicates progr_compl_id/2, sp_struct_id/2 and dtop_sp_id/2 respectively. These predicates have same structure. Their first argument is a list of unique identifiers either of program complements or StrSp or specifications of DT operations respectively. The second argument is a list of lists of unique identifiers either of program clauses or StrSp formulas or DT operation formulas respectively. For example, progr_compl_id([progr1, progr2], [[1,2,3,4,5,6, 7], [8,9,10,11,12,13,14,15,16,17,18,19,20,21, 22]]). progr1 is the identifier of program complement of predicate sum/2 and the identifiers of its clauses are in list [1 7]. Each program clause is represented by the predicate progr_clause(progr_id, Clause_Id, Program_ clause).. The arguments Progr_Id and Clause_Id are the unique identifiers of program and a clause respectively. Program_clause is a list which has the representation of the clause in ground form. The representation of clause with identifier 5 of program progr1 is the following. progr_clause(progr1, 5, [all v(12):seq(int), all v(13):int, all v(14):seq(int), [p5(v(12):seq(int), v(13):int, v(14):seq(int)) <-> head(v(12): seq(int), v(13):int)]]). The specification of each formula is represented by a predicate of the form sp_struct(struct_spec_id, Struct_spec_formula_ Id, Unique_name, Struct_spec_formula).. The arguments Struct_spec_Id and Struct_spec _formula_id are the unique identifiers of StrSp and a formula respectively. Unique_name has the unique name of a StrSp. Struct_spec_formula is a list which has a StrSp in ground representation. The specification of each formula of a DT operation is represented by a predicate of the form

9 E. Marakakis et al. / A knowledge-based interactive verifier for logic programs 151 dtop_sp(dtop_spec_id, DtOp_spec_formula_Id, Unique_dtOp_name, Spec_formula).. The arguments DtOp_spec_Id and DtOp_spec _formula_id are the unique identifiers of DT operation specification and a formula respectively. Unique _dtop_name is the unique name of a DT operation specification. Spec_formula is a list which has the ground representation of specification of a DT operation. For example, the representation of DT operation empty_seq/1 is as follows. dtop_sp(empty_seq, 1, sequence empty, [all v(1):seq(tv(1)), [empty_seq(v(1):seq(tv(1))) <-> eq(v(1):seq(tv(1)), nil_seq:seq(tv(1)))]]) Representation of axioms and lemmas A set of axioms is applied to each DT including the domain closure andthe uniqueness axioms. The specification of each axiom is represented by a predicate of the following form axiom_def(axiom_id, DT_name, Axiom_name, Axiom_specification). The argument Axiom_Id is the unique identifier of axiom, i.e. a positive integer. DT_name is the name of a DT which the axiom is applied to. Axiom_name is the name of axiom. Axiom_specification is a list which has the representation of specification of axiom. Lemmas are represented by predicate lemma_sp/4 which has same structure as the one of axioms, i.e. axiom_def/4. For example, the representation of domain closure axiom is as follows. axiom_def (1, sequences, domain closure, [all v(1):seq(tv(1)), (eq(v(1):seq(tv(1)), nil_seq) \/ [ex v(2):tv(1), ex v(3):seq(tv(1)), eq(v(1):seq(tv(1)), seq_cons(v(2):tv(1), v(3):seq(tv(1))):seq(tv(1)))])]) Representation of first-order logic laws FOL laws are equivalence preserving transformation rules. Each FOL law is specified by a FOL formula. Theyare representedbypredicatefol_law/3 as follows. fol_law(fol_law_id, FOL_law_description, FOL _law_specification).. The argument FOL_law_Id is the unique identifier of the FOL law, i.e. a positive integer. FOL_law _description is the name of a FOL law. FOL_law _specification is a list which has the ground representation of specification of the FOL law. For example, the FOL: P (Q R) (P Q) (P R) is represented by the clause: fol_law(2, distribution, [f1/ \ (f2 \ /f3) <-> (f1/ \ f2) \ /(f1/ \ f3)]). Note, that this representation activates a predicate which constructs special code for applying this FOL law Representation of theorems Theorems must also be represented in the KB. The specification of a theorem may need to be transformed into structured form in order to proceed to its proof. A theorem is represented by predicate theorem/4. That is, theorem(theorem_id, Program_Id, Spec_struct_ Id, Theorem_specification). The arguments Theorem_Id, Program_Id and Spec_struct_Id are the unique identifiers of atheorem, a program and a StrSp respectively. Theorem_specification is a list which has the representation of specification of theorem. For example, the theorem: x1/seq(z), x2/z (sum (x1, x2) sum s (x1, x2)) is represented by the next clause: theorem(1, progr1, spec_struct1, [all v(1):seq(int), all v(2):int, (sum(v(1):seq(int), v(2):int):int <-> sum_ s(v(1):seq(int), v(2):int))]). 6. The prover A schematic view of the Prover, i.e. the Theorem Proof Checker andthe Specification Transformer is presented in this section. In addition, the functions and the interactions of their subcomponents are discussed. Examples will illustrate the KB representation and the reasoning in the proof task Schemata-based proof schemes The logic program construction method in [11,13] is based on schemata. Each design schema is associated with a correctness proof scheme which can be followed for the correctness of the constructed program. These proof schemes and the correctness method are presented in [12,16]. In this paper, a simple introductionismadetothem.theincremental proof scheme is used in the running example of this paper so its presentation will help in understanding the paper.

10 152 E. Marakakis et al. / A knowledge-based interactive verifier for logic programs Suppose that we have constructed a logic program by the method in [11,13] and we have formulated a logic specification for this program. In order to prove the correctness of the program with respect to its specification, the following steps have to be performed. 1. The specification is transformed into a structured form. 2. The proof scheme which corresponds to the design schema applied to the top-level predicate is applied. The proof scheme of the schema which has been applied for the instantiation, i.e. construction, of the top-level predicate is initially followed. The proof proceeds in a top-down fashion. If a program has nested instances of schemata the correctness proof may require the proof of some correctness theorems for predicates in lower levels. For such correctness theorems the proof scheme of the schema which has been applied for the instantiation of the predicate of the correctness theorem is followed. In this way, the structure of logic programs can be exploited when finding a proof. The Proof schemes corresponding to the design schemas used in the program construction method [11, 13] and the correctness method are presented in [12, 16]. The structure of Theorem Proof Checker component of this prover, Fig. 2, depicts the implementation of the five proof schemes of the logic program correctness method. The proof schemes are hardwired into the structure of the Theorem Proof Checker. The correctness proof of a theorem may require the use of more than one proof scheme. In this case we have nested use of proof schemes. Let s assume that we have a theorem t 1 that its correctness proof requires the correctness proof of another theorem t 2. The proof of t 2 will be used in the proof of t 1 as lemma. In this case, the proof of the theorem t 1 is temporarily interrupted in order to make the proof of theorem t 2. The second or inner theorem, i.e. t 2, will be proved by the same correctness method. After the completion of theorem t 2, the first or outer theorem, i.e. t 1,usesitaslemmaand proceeds to the completion of its proof. A proof scheme can be activated either automatically by the system or by selection from the user. After the activation of a proof scheme the proof checker guides the user on the proof of his theorem based on the activated proof scheme. In the following, variables are not accompanied by types for simplicity of presentation Proof scheme for incremental schema If the Incremental schema has been applied to construct p( x) then structural induction on a well-founded set is applied. Definition 8. Let be a binary relation. A partiallyordered set (S, ) in which every nonempty subset has a least element is called a well-founded set. Let (S, ) be a well-founded set and P be a proposition over S. If the following two conditions hold, 1. Base case: P (x) is true for each minimal element of S. 2. Induction step: x S( y S(y x P (y)) P (x)) then infer that z SP(z). This is the principle of structural induction. Let τ be a type, and let μ be a mapping from τ to some well-founded set (S, ). M induces a wellfounded ordering on τ, i.e.forallu 1,u 2 of type τ, u 1 τ u 2 iff μ(u 1 ) μ(u 2 ). Let ῡ(p(u, ῡ) Def p ) be the correctness theorem to be proved, abbreviated by Φ(u). P (x) in the structural induction schema can now be instantiated by Φ(u) where u is of type τ, and a well-founded ordering has been defined on τ by mapping τ to some well-founded set. The above induction scheme is used as the correctness proof method for the Incremental schema. The following proof schemes for the base case and induction step of the above induction schema show how the proof can proceed. In order to prove u, ῡ(p(u, ῡ) Def p ) where p(u, ῡ) has been defined by an Incremental schema, perform the following steps. In the following, represents the bottom element of the well-founded set (S, ), i.e. there is no S such that. Base case: u, ῡ(u = (p(u, ῡ) Def p )) Induction hypothesis: u Ind(u) u, u,υ (u u (p(u, ῡ ) Def p )) Induction step: u, ῡ(u Ind(u) (p(u, ῡ) Def p )) Theorem prover The process of proving a theorem, shown in Fig. 6, proceeds in three steps. Step 1: Initially, the user has to specify the theorem that is going to be proved and to select the corresponding theory. The selection of the proof scheme is optional. The theory is retrieved from

11 E. Marakakis et al. / A knowledge-based interactive verifier for logic programs 153 Fig. 6. Sequence diagram of Theorem Proof Checker. (Colours are visible in the online version of the article; /KES ) the KB and presented to the user for selection. The theory consists of a program complement,alogic specification, axioms and lemmas. The interface which allows the user to make these selections is shown in Fig. 4. Step 2: Next, the user proceeds to the actual proof of the theorem. In order to do that he has to select specific parts from theorem, theory and transformation rules that will be applied. The transformation rules that can be applied are FOL laws, folding and unfolding. Step 3: Finally, the selected transformation is applied and the equivalent form of the theorem is presented to the user. The user can validate the result. He is allowed to approve or cancel the specific proof step. The last two steps are performed iteratively until the theorem is proved Specification transformer Figure 7 depicts the procedure for transforming a specification in the required structured form, which is similar to the previous case. In this case however, the underlying theory consists of Spec Axioms Lemmas. Initially, the user selects a specification, then the rest theory is automatically selected by the system. Next, in step 2, the user has to select specific theory elements and transformation rules. In step 3, the selected transformation rule is performed. Step 2 and step 3 are performed iteratively until the selected specification is transformed in the required structured form. Fig. 7. Sequence diagram of Specification Transformer. (Colours are visible in the online version of the article; /KES ) Fig. 8. Sequence diagram of the performproofstep procedure. (Colours are visible in the online version of the article; org/ /kes ) 6.4. The main proof procedure The schematic view of the main algorithm for the procedure which performs a proof step, i.e. perform- ProofStep, is showninfig.8. The Transformation- Step procedure is actually a sub-procedure of the performproofstep procedure, so it will not be presented. It is assumed that the user has selected some theory elements, and a transformation rule that should be applied to the current proof step. The function block diagram of the algorithm performproofstep shown in Fig. 8 will be discussed through an example. Consider that the running theorem has been transformed and its current form is the following: x1/seq(z), x2/z (sum(x1, x2)

12 154 E. Marakakis et al. / A knowledge-based interactive verifier for logic programs (x1=<> x2= 0 [ x3/z, [ x4/seq(z), false x2= x4+ x3 sum s (x4, x3)]])) The user has selected the following FOL law to be applied to the above theorem: P false false Initially, the current theorem is converted to the corresponding ground representation by the procedure ConvertGr and we get: [all v(1):seq(int), [all v(2):int, sum(v(1):seq(int), v(2):int) <-> (eq(v(1):seq(int), nil_seq:seq(int))/ \ eq(v(2):int, 0: int) \/ [ex v(3):int, [ex v(4):int, [ex v(5):seq(int), false/ \ eq(v(2):int, plus(v(4):int, v(3): int):int)/ \ sum_s(v(5):seq(int), v(3):int)]]])]] Next, the procedure applyproofstep, a subprocedure of peformproofstep, applies the FOL law to the current theorem and derives the new theorem. In order to do that, this procedure constructs and asserts a set of clauses which implement the selected FOL law. This set of clauses is omitted due to lack of space. Then, it applies this set of clauses and derives the new theorem in ground representation. That is, [all v(1):seq(int), [all v(2):int, sum(v(1):seq(int), v(2):int) <-> (eq(v(1):seq(int), nil_seq:seq(int))/ \ eq(v(2):int, 0:int) \/ [ex v(3):int, [ex v(4):int, [ex v(5):seq(int), false/ \ sum_s(v(5):seq(int), v(3):int)]]] )]] Finally, the new theorem is then converted to the corresponding non-ground form in order to be presented to the user. That is, x1/seq(z), x2/z (sum(x1, x2) (x1=<> x2= 0 [ x3/z, [ x4/seq(z), false sum s (x4, x3)]])) 6.5. Illustration of successive proof steps In this subsection, we illustrate a set of successive proof steps in order to show the main functions of the system. Let s assume that the user has specified a theorem to be proved, and he has selected a theory and a proof scheme. That is, he has proceeded to the verification task shown in Fig. 9. For example, let s assume that the user likes to prove the correctness theorem for predicate sum/2. In addition, he has selected the corresponding theory and the Incremental proof scheme has been activated. This proof scheme requires proof by induction on an inductive DT. The following steps exemplify the actions of the user. First, the user selects induction and a new menu opens. Then, he selects Base in the new menu. The induction base is set to be Fig. 9. Induction base for the correctness of sum/2. (Colours are visible in the online version of the article; KES ) x1/seq(z) =<>/seq(z) By setting the induction base and selecting OK the sub-window labeled Induction Base opens and the first step of the induction base appears on the corresponding frame. x1/seq(z), x2/z, [sum(x1, x2) [x1=<> x2= 0 [ x4/z, x5/z, x6/seq(z), [x1= x5::x6 x2= x5+ x4 sum s (x6, x4)]]]] Next, the user would like to apply an equivalence preserving transformation using an axiom. Axioms is pressed in order to select an axiom from the list of axioms. That is, x1/a2, x3/seq(a2), [x1::x3=<>] By selecting Apply Proof Step, possible axioms applications are identified. If there is only one axiom application the proof step is applied and the new theorem is derived. On the other hand, if there are more than one possible applications, a message is shown to the user to make the necessary selections. In this case the proof step is applied and the new theorem is derived. That is, x1/seq(z), x2/z, [sum(x1, x2) [x1=<> x2= 0 [ x4/z, x5/z, x6/seq(z), false x2= x5+ x4 sum s (x6, x4)]]] After that, the user would like to apply a FOL. FOL Laws is selected in order to show the list of FOL laws. The following FOL law is selected. P false false By selecting the button Apply Proof Step the specified proof step is applied. The new theorem is derived. That is, x1/seq(z), x2/z, [sum(x1, x2) [x1=<> x2= 0 [ x4/z, x5/z, x6/seq(z), false sum s (x6, x4)]]]

13 E. Marakakis et al. / A knowledge-based interactive verifier for logic programs 155 Fig. 10. Proving the induction step of correctness theorem for sum/2. (Colours are visible in the online version of the article; org/ /kes ) The transformation process continues with selections of theory elements and applications of transformation rules. The proof of the induction base is completed when it has been proved for induction base that the specified relation x1/seq(z), x2/z sum s (x1, x2) is equivalent to the implemented predicate x1/seq(z), x2/z sum(x1, x2). Then the induction step has to be proved. Initially the button Induction is selected followed by selection of Step. The induction step has to be specified in sub-window Induction Step. That is, x1/seq(z) <>/seq(z) The form of the theorem to be proved is derived. That is, x1/seq(z), x2/z(sum(x1, x2) (false x2= 0 [ x3/z, [ x4/z, [ x5/seq(z), x1= x4::x5 x2= x4+ x3 sum s (x5, x3)]]])) Then, the user would like to apply a FOL. FOL Laws is selected in order to show the list of FOL laws. The following FOL law is selected. P false false By selecting Apply Proof Step the proof step is applied. The derived theorem is as follows: x1/seq(z), x2/z (sum(x1, x2) (false [ x3/z, [ x4/z, [ x5/seq(z), x1= x4::x5 x2= x4+ x3 sum s (x5, x3)]]])) Similarly, the correctness proof process continues with selections of theory elements and applications of transformation rules until it has been proved that the specified relation x1/seq(z), x2/z, sum s (x1, x2) is equivalent to the implemented predicate x1/seq(z), x2/z, sum(x1, x2). Figure 10 shows the last three Fig. 11. Required execution time as clauses elements increase. steps of the induction base and the first three steps of the induction step. 7. Evaluation The response time of this proof checker is very good as shown in Fig. 11. The computational complexity of one proof/transformation step is linear in the size of the input elements of each clause and the applied clauses. Moreover, since the user each time selects the theorem, the theory and the transformation rules that will be applied, it is quite fast. In the tests, the execution time of a proof step in this system ranges from 4mSection 8msec. Moreover, we identified that the maximum memory usage in a proof step was 139 Kbytes. 8. Conclusions This research work involves the development of a proof checker that can be used efficiently by its users for the proof of correctness theorems for logic programs constructed by the schema-based method in [11]. The overall interface of this system is user friendly and facilitates the proof task. Despite the obvious necessity of a nice GUI, systems such as LPTP, Theorema, KIV, PVS, Isabelle and Boogie do not offer such a functionality. The main features of this system which make it to be an effective and useful tool for the interactive verification of non-trivial logic programs constructed by the method in [11] are the following. The proof of the correctness theorem is guided by the logic-program construction method. Initially, the proof scheme connected with the program schema applied for the construction of the top-level predicate of the logic program is activated. The activation of a proof scheme is performed either automatically by the system or by