Discharching Event-B Proof Obligations

Transcription

1 Discharching Event-B Proof Obligations Studienarbeit am Institut für Theoretische Informatik Prof. Dr. rer. nat. Peter H. Schmitt Fakultät für Informatik Universität Karlsruhe (TH) von cand. inform. Christopher Köker Betreuer: Prof. Dr. rer. nat. Peter H. Schmitt Dipl.-Inform. Mattias Ulbrich 17. September 2008 Institut für Theoretische Informatik

2

3 Hiermit erkläre ich, die vorliegende Arbeit selbstständig und ohne fremde Hilfe verfasst und keine weiteren als die angegebenen Quellen und Hilfsmittel verwendet zu haben. Karlsruhe, den 17. September 2008

4

5 Abstract. In this thesis, a concept for the discharging of Event-B proof obligations using the KeY tool is presented. While Event-B makes use of a set-theoretic notation, KeY uses first-order logic to formulate proof obligations. This thesis shows, how the set-theoretic proof obligations from Event-B can be expressed in first-order logic and be translated to the KeY input language. In the next step, an approach for the discharging of these proof obligations in the KeY tool is formulated and extended to achieve a high level of automation. The overall approach is shown to be promising with help of a case study. It was even possible to discharge more proof obligations automatically with help of the KeY prover than within the Rodin toolset for Event-B modeling.

6

7 Contents 1 Introduction Goal Related Work Outline of the Thesis Event-B/Rodin vs. KeY Event-B The Event-B Language Machines Contexts Refinements Proof Obligations The Rodin Tool Modeling Proving The Rodin Prover KeY The KeY Tool JavaDL and the Sequent Calculus The KeY Prover Taclets Automated Proving with KeY Problem Summary

8 viii Contents 3 Formalizing Event-B Proof Obligations in First-Order Logic Translating Event-B Language Constructs to First-Order Logic Necessary Predicates and Functions Translation of Event-B Language Constructs Expressing Event-B Language Constructs in JavaDL Challenges and Constraints Quantification over Functions, Relations and Sets Function Applications Function which Are Supposed to Have Different Numbers of Arguments Finiteness and Cardinality Set Comprehensions Set Extensions Challenges with Typing Typing in Event-B/Rodin Typing in KeY Options for Proving Event-B Proof Obligations with KeY Resulting Predicates and Functions Necessary Predicates Necessary Functions Step-By-Step: How to Translate Event-B Proof Obligations to the KeY Input Language Towards Automated Translation Summary Proving Event-B Proof Obligations with KeY Creating Taclets Definitions of Set-theoretic Operators Definitions of Finiteness and Cardinality Rewriting and Simplification of Set-theoretic Expressions Further Taclets for Common Problems in Event-B Modeling Summary

9 Contents ix 5 Towards Automated Discharching of Event-B Proof Obligations Automated Proving in Event-B/Rodin Proof Strategies for KeY Including Taclets in Existing KeY-Strategies Remaining Challenges for Automated Proving Summary Case Study: A Tree-structured File System Modeling a Tree-Structured File System in Event-B and Rodin Abstract Model The First Refinement Second and Third Refinement Resulting Proof Obligations Initialization Make Directory Create File Move Delete Copy Discharging the Resulting Proof Obligations Discharging the Proof Obligations in Event-B and Rodin Discharging the Corresponding Proof Obligations with KeY Results Observations Overall performance A Closer Look at the Results Summary Remaining Challenges and Future Work Translating Proof Obligations from Event-B to Key Discharging the Proof Obligations with Key Possible Future Work Automated Translation of Proof Obligations Improving and Introducing New Automated Proof Strategies Generalization to B and Z Languages

10 x Contents 8 Summary and Conclusions 71 Bibliography 73

11 List of Figures 2.1 A machine A context Relationship between machines and contexts (from [DaBA08a]) An Event-B proof obligation Modeling perspective Proving perspective The KeY tool A proof obligation in KeY The abstract model (from [DaBA08a]) The first refinement (from [DaBA08a]) Moving a subtree (from [DaBA08a]) A specification of delete event (from [DaBA08a]) Copying a subtree (from [DaBA08a])

12

13 List of Tables 3.1 Basic operators Elementary set operators Relation and function operators Relation operators and compositions of relations Finiteness and cardinality Rewriting the basic predicates Taclets for rewriting the basic predicates Rewriting common set operators Taclets for rewriting common set operators Rewriting relations Taclets for rewriting relations Rewriting functions Taclets for rewriting functions Rewriting functional operators Taclets for rewriting functional operators Definitions of finiteness Definitions of cardinality Simplification of equalities Simplification of set expressions Simplification of domain-, range- and map-expressions Simplification of functional expressions Rewriting of inclusion predicates Rewriting of converse-expressions Rewriting of domain- and range-expressions Rewriting of union-expressions

14 xiv List of Tables 4.21 Rewriting of composition-expressions Rewriting of set expressions Further taclets I Further taclets II Further taclets III Further taclets IV Further taclets V Further taclets VI Further taclets VII Further taclets VIII Further taclets IX Further taclets X Further taclets XI Proof obligations from initialization Make Directory proof obligations Create File proof obligations Move proof obligations Delete proof obligations Copy proof obligations Results of the case study

15 1. Introduction Event-B [MAL05] [Abri06] is a notation and modeling method developed from the B-method [Abri96]. It uses set theory as a modeling notation. The use of refinement to represent systems at different abstraction levels and the use of mathematical proof to verify consistency between refinement levels are key features of Event-B [even08]. The Rodin tool [RODI07] [ABHV06] has been developed to allow Event-B modeling within an integrated development environment that carries out many tasks automatically. Specification, refinement and the discharging of proof obligations are done within this single toolset [BuHa07]. The KeY System [BeHS07] is a formal software development tool that aims to integrate design, implementation, formal specification, and formal verification of object-oriented software as seamlessly as possible [BeHS08]. While KeY was originally mainly aimed at verification of Java/JavaCard programs, recent research has produced a number of KeY variants to handle related problems [BeHS08]. And as set-theoretic approaches like the B/Event-B [Abri96] [Abri06] and Z/Object-Z [WoDa96] [Smit00] methods also are inherent parts of the world of formal modeling, there is a certain interest to know how well the KeY prover can deal with the proof obligations these set-theoretic approaches produce. In contrast, the Rodin tool does not have a powerful theorem prover integrated [RODI07]. It makes use of external tools like the B4free prover [Syst] in order to discharge the Event-B proof obligations. However, there still seems to be room for improvements, as in the roadmap for the further development of the Rodin toolset [ABHV08], it is explicitly mentioned: The existing automated provers will be extended with more powerful decision procedures. The use of existing first order and higher order automated provers will be investigated. So, it seems to be a obvious task to investigate the capability of the KeY tool when it comes to discharging Event-B or other set-theoretic proof obligations.

16 2 1. Introduction 1.1 Goal The Event-B method clearly specifies all proof obligations which have to be discharged in order to prove the model and all its refinements to be correct. In this thesis it will be investigated, how well the KeY tool can deal with these Event-B proof obligations and then, approaches will be described which lead to a high amount of automatically dischargeable proof obligations. This makes it necessary to come up with a concept how one can translate the proof obligations from the set-theoretic Event-B language to the first-order logic of the KeY input language. And, after that, rules and strategies for an optimal discharging of these proof obligations with the KeY tool have to be established. The whole approach has to be assessed with help of a case study that produces comparable results which allows to check the performance of the two tools KeY and Rodin against each other. 1.2 Related Work The KeY tool has not only been used for the verification of Java-style programs and the proving of first-order logic formulas, but was also extended to be used as a verification tool for the C programming language and the Hoare calculus, for example [BeHS08]. Thus, there is a certain history of applying the KeY tool to new and different-styled languages. However, an approach for discharging set-theoretic proof obligations with KeY is not known. The Rodin tool for integrated modeling and verification with Event-B only comes with a rudimentary prover integrated [RODI07]. External provers like the B4free prover [Syst] or the ProB model checker [LeBu08] can be integrated as plug-ins in the Rodin platform and enhance the capabilities of the innate Rodin prover. However, for the developers of the Rodin tool, advanced tool support for the discharging of Event-B proof obligations remains an open issue [ABHV08]. 1.3 Outline of the Thesis In this thesis, a concept for the discharging of Event-B proof obligations using the KeY tool is presented and verified with help of a case study. Chapter 2 shortly introduces the necessary foundations and briefly summarizes the differences between the Event-B language and the Rodin platform, and the KeY tool. Chapter 3 shows, how Event-B language constructs can be formulated in first-order logic, an important prerequisite for discharging them with the KeY tool. In chapter 4 it is set out, how the proof obligations can be actually proved with help of the KeY tool, while chapter 5 discusses how this discharging can be automated. The whole approach is verified with help of a case study in chapter 6, before remaining challenges and possible future work are discussed in chapter 7. The conclusion is then drawn in chapter 8.

17 2. Event-B/Rodin vs. KeY In order to discharge Event-B proof obligations with the KeY system, one should understand what proof obligations in Event-B are and how they arise, as well as how proofs can be performed with help of the KeY tool. 2.1 Event-B Event-B is a formal specification language for the modeling of complex software systems. A complete description of Event-B can be found in [MAL05] or [Abri06]. In what follows, the important aspects for the further understanding of this thesis are briefly mentioned The Event-B Language An Event-B model consists of contexts and machines. Contexts contain the static parts of a model, while machines contain the dynamic parts of a model [ABHV06]. We now take a closer look at what machines and contexts are Machines In Event-B, the dynamic parts of a model are formalized as so-called machines. These machines are made of four elements [MAL05, chapter II]: 1. A name 2. A list of distinct state variables, collectively denoted by v 3. A list of named predicates, the invariants, collectively denoted by I (v) 4. A collection of transitions, called events Figure 2.1 shows a machine as represented in the Rodin formal modeling tool. Every machine has a state, which is defined by the current values of its variables. These variables are explained as follows [ABHV06]:

18 4 2. Event-B/Rodin vs. KeY Figure 2.1: A machine Variables, like constants, correspond to simple mathematical objects: sets, binary relations, functions, numbers, etc. They are constraint by invariants I (v) where v are the variables of the machine. Invariants are supposed to hold whenever variable values change. But this must be proved first. Thus, invariants are a source of lot of proof obligations which have to be discharged in order to prove a model correct. Beside its state description, a machine contains so-called events, which determine how the state can evolve. Events are defined as follows [ABHV06]: Each event is composed of a guard (G(v)) and an action (S(v)). The guard is the necessary condition under which the event might occur. The action, as its name indicates, determines the way in which the state variables are going to evolve when an event occurs. An event may be executed only when its guard holds. Events are atomic and when the guards of several events hold simultaneously, then at most one of them may be executed at any one moment. The choice of the event to be executed is non-deterministic. The syntactic form of an event is thus given by: E when G(v) then v := S(v) end. The actions consist of a collection of assignments that modify the state simultaneously, that means the predicates describing the state before and after an action (so-called before-after predicates) are conjoined.

19 2.1. Event-B 5 Figure 2.2: A context Contexts The machines introduced were made of a number of variables, invariants and events. However, in Event-B, there are secondary components besides the machines, which are called contexts. These are described in [MAL05, chapter II] as follows: A context is made of the following elements: (1) a name, (2) a list of distinct carrier sets, collectively denoted s, (3) a list of distinct constants, collectively denoted c, and (4) a list of named properties, collectively denoted by P(s, c). Figure 2.2 shows a context as it appears in the Rodin formal modeling tool. Carrier sets are described in [MAL05, chapter II]: The carrier sets are just represented by their name. The different carrier sets of a context are completely independent. The only requirement concerning such sets is that they are supposed to be non-empty. The constants are defined, usually non-deterministically, by means of the properties P(s, c), which are predicates. Later, carrier sets are translated to the KeY input language as constant functions (see section 3.1). The relation between machines and contexts is shown in figure 2.3. As one can see, each machine M can refer to a context C. In this case, the machine sees the context, which means, that all constants and carrier sets from C can be used by M Refinements As it could already be seen in figure 2.3, machines and contexts can be refined and extended respectively. Refining a machine consists of refining its states and its events. Refining is detailed in [ABHV06]:

20 6 2. Event-B/Rodin vs. KeY Figure 2.3: Relationship between machines and contexts (from [DaBA08a]) A concrete machine (with regard to the more abstract one) has a state that should be related to that of the abstraction by a so-called glueing invariant, which is expressed in terms of a predicate J (v, w) connecting the abstract state represented by the variables v and the concrete state represented by the variables w. Each event of the abstract machine is refined to one or more corresponding events of the concrete one. Informally speaking, a concrete event is said to refine its abstraction (1) when the guard of the former is stronger than of the latter (guard strengthening), (2) and when the glueing invariant is preserved by the conjoined action of both events. In the case of an abstract event abs and a corresponding concrete event con of the form abs when P(v) then v := E(v) end con when Q(w) then w := F (w) end the refinement statement to prove is thus the following one: I (v) J (v, w) Q(w) P(v) J (E(v), F (w)) [Refinement] Here, I (v) is the abstract invariant and J (v, w) is the glueing one [ABHV06].

21 2.1. Event-B 7 Figure 2.4: An Event-B proof obligation Proof Obligations For the initial abstract model and all refinements, necessary proof obligations are created automatically. They aim to prove a machine to be consistent. This is done as described in [ABHV06]: This is done by proving that each event of the machine preserves the invariant. More precisely, it must be proved that the action associated with each event modifies the state variables in such a way that the modified variables satisfy the invariant, under the hypothesis that the invariant holds presently and the guard of the event is true. For a machine with variables v, invariant I (v) and an event with guard G(v) and action v := S(v), the proof obligation to be discharged is the following: I (v) G(v) I (S(v)) [INV ] An example proof obligation from the Rodin tool is given in figure 2.4. Other proof obligations to discharge are the refinement proof obligations discussed above or proof obligations originating in the abidance of all invariants at time of initialization as well as proof obligations showing the well-definedness of some expressions The Rodin Tool The Rodin platform is an open and extensible tool environment for Event-B specification and verification [DaBA08a]. It is implemented on top of the Eclipse platform [BuHa07]. It aims to adopt features from integrated development environments for

22 8 2. Event-B/Rodin vs. KeY Figure 2.5: Modeling perspective programming to a similar environment for formal modeling, refinement of models and verification. The key aspects of the Rodin platform are its support for abstract modeling in Event-B, for refinement prove, its extensibility and being open source [ABHV08]. Using the Rodin tool is mainly done with the help of two different views, the modeling perspective and the proving perspective Modeling The modeling perspective is shown in figure 2.5. With help of this perspective, the modeling is done. The perspective is made of a project explorer, which allows to switch between different projects and the different parts of a project, an editor to create and edit machines and contexts, a model overview window and a problem view. An introduction to using the Rodin tool for formal modeling and a detailed description of the elements in the modeling perspective can be found in the Rodin user manual [RODI07] Proving Figure 2.6 shows the proving perspective. This perspective is made of a number of windows: the proof tree, the goal, the selected hypotheses, the proof control, the proof information and the searched hypotheses, which allow the user to perform the different proofs in order to discharge the given proof obligations. A detailed

23 2.2. KeY 9 Figure 2.6: Proving perspective description of all elements in this perspective is given in the user manual of the Rodin platform [RODI07], as well The Rodin Prover The Rodin tool in its rudimentary version is only equipped with a very basis theorem prover. However, an additional advanced prover, called B4free [Syst], is available as a plug-in [BuHa07] [RODI07]. When it will be talked about the Rodin prover later in this thesis, this will always mean the combination of the built-in prover and the plugged-in one. 2.2 KeY As it was mentioned, the KeY System is a formal software development tool that aims to integrate design, implementation, formal specification, and formal verification of object-oriented software as seamlessly as possible [BeHS08]. The intention is to provide a platform that allows close collaboration of conventional and formal software development methods [BeHS07] The KeY Tool Thus, the KeY tool is not merely a theorem prover. However, especially the capabilities of the prover for first-order logic integrated in the KeY system is of special interest for this thesis. This means, that this brief overview will focus on the relevant foundations necessary for understanding the discharging of first-order proof

24 10 2. Event-B/Rodin vs. KeY Figure 2.7: The KeY tool obligations with KeY. A comprehensive source for all other aspects of the KeY tool is the KeY book [BeHS07]. Performing a proof with help of the KeY tool, the view one always deals with is shown in figure 2.7. This view shows the current goal sequent, the proof tree and options for the automated prove component JavaDL and the Sequent Calculus KeY uses a typed dynamic first-order logic, JavaDL, as input language. JavaDL is extensively discussed by Beckert [Beck00]. In this thesis, it will not be made use of the dynamic components of this language. It will be concentrated on the capabilities of the KeY tool dealing with proof obligations formulated in first-order logic. Proving in KeY is done with help of the sequent calculus. This means that proofs are constructed by applying rules to a goal sequent which contains the proof obligation, consisting of an assumption on the left-hand-side and a proposition on the righthand-side. Applying rules to such a proof obligation leads to the construction of a proof tree, that means a sequence of intermediate steps, which are reached by the application of rules. This is done until the proof obligation can be discharged by tracing back the proposition to the known assumptions. For example, the modus ponens rule written in the sequent calculus looks as follows (from [BGHK + 07]): φ, ψ, Γ φ, φ ψ, Γ

25 2.2. KeY 11 Figure 2.8: A proof obligation in KeY Informally speaking, if an implication φ ψ is found on the left-hand-side of a proof obligation, and the formula φ holds on the left-hand-side of this proof obligation as well, the implication φ ψ can be replaced by ψ by applying the modus ponens rule. Here, Γ and stand for the other formulas in the sequent, which remain unchanged under the application of this rule. If one had to prove the validity of the formula (a (a b)) b, this rule would be, together with some syntactic rewriting rules, sufficient to discharge this proof obligation The KeY Prover The Key prover discharges proof obligations by the repeated application of various of such rules. Thereby, the user can interleave automated rule applications and interactive steps, in which the user decides by itself which rule should be applied where. This interactive rule application is further explained in [BGHK + 07]: For interactive rule application, the KeY prover has an easy to use graphical user interface that is built around the idea of direct manipulation. To apply a rule, the user first selects a focus of application by highlighting a (sub-)formula or a (sub-)term in the goal sequent. The prover then offers a choice of rules applicable at this focus. This choice remains manageable even for very large rule bases. The KeY prover with an example proof obligation loaded can be seen in figure Taclets All proof rules in KeY are defined in the so-called taclet language. This taclet language is explained comprehensively in [BeHS07, chapter 4]. An example taclet for the modus ponens rule

26 12 2. Event-B/Rodin vs. KeY φ, ψ, Γ φ, φ ψ, Γ could look as follows (from [BGHK + 07]): \find(p -> q ==>) \assumes(p ==>) \replacewith(q ==>) \heuristics(simplify) Here, p and q are so-called schema variables, that means variables that are matched to (sub-)terms or (sub-)formulas in the goal sequent respectively. They can be declared representing variables, terms or formulas. The following clauses are important to know in the further course of this thesis and are explained in [BeHS07, chapter 4]: \find: The find clause specifies the potential application focus. \assumes: The assumes clause results in a taclet only being applicable if the given sequent in the assumes clause is part of the sequent that is supposed to be modified. \replacewith: If the taclet contains a find clause, then the focus of the taclet application can be replaced with new formulas or terms contained in the replacewith clause. \heuristics: As explained below, taclets can be declared to be part of rule sets or so called heuristics. This can be done with help of the heuristics clause. \varcond: A list of conditions can be attached to each taclet with help of the varcond clause to control how the schema variables in the taclet are allowed to be instantiated. \add: The add clause can add new formulas to a goal. This means that a specific taclet is offered to the user for application if and only if the formula mentioned in the assume clause is present in the sequent and on selecting a matching focus [BGHK + 07]. The advantages of taclets are summarized in [BGHK + 07]: The taclet language is quickly mastered and makes the rule base easy to maintain and extend. Taclets can be proven correct against a set of base taclets. It will be made use of the possibility to create user-specific taclets extensively in chapter 4 to allow the handling of set-theoretic language constructs.

27 2.3. Problem Automated Proving with KeY Automated proving in KeY is done with the help of so-called heuristics. Taclets, the build-in taclets as well as the additional taclets defined by the user, are or can be defined to be a part of such a heuristic. This is explained in [BeHS07, chapter 4]: Each taclet can be declared to be element of a number of rule sets, which in turn are used by the strategies in KeY that are responsible for applying rules automatically. Rule sets are intended as an abstraction from the actual taclets and identify taclets that should be treated in the same way. Existing rule sets in KeY are, among others, alpha (for nonsplitting elimination of propositional connectivities), beta (splitting elimination of connectivities), and simplify (simplification of expressions). Moreover, there exist three sets of user defined taclets (usertaclets1, usertaclets2, usertaclets3 ), which can be included in the automated proof conduction by changing the corresponding properties in the proof control. Hence, in chapter 5, when it comes to the automated discharging of Event-B proof obligations, the necessary rules have to be included in suitable heuristics to allow automatically conducted proofs. 2.3 Problem When discharging Event-B proof obligations with KeY, it is clear that one wants the proof obligations which are dischargeable with the Rodin tool and the proof obligations which are dischargeable with the KeY tool being exactly the same. Hence, a proof obligations has to be dischargeable with the KeY tool if and only if it is dischargeable with the Rodin tool. That means, that it is wanted to achieve the completeness and the soundness of the approach to present. Or formally, if the proof obligation is formulated with help of a formula φ, there exists a model M Event B for the Event-B formula φ Event B in Rodin if and only if there exists a model M KeY for the translated formula φ KeY in KeY: M Event B φ Event B M KeY φ KeY Completeness means that every Event-B proof obligation, which can be discharged by the Rodin tool, should also be dischargeable with help of the KeY tool. In other words, all proof obligations which hold in the Event-B model, have to be dischargeable within KeY, or formally: M Event B φ Event B = M KeY φ KeY Soundness means, that every proof obligation successfully discharged by the KeY tool, should also be dischargeable within the Rodin proving environment. In other words, all proof obligations dischargable with the KeY tool have to really hold in the Event-B model, or formally:

28 14 2. Event-B/Rodin vs. KeY M Event B φ Event B = M KeY φ KeY As it will be discussed later, achieving completeness means some serious challenges, while soundness is achieved comparable easily. Obviously, the main challenge faced on the way to the goal of this thesis, is the difference in the formulation of proof obligations between the Rodin tool and the KeY tool. While Event-B follows a set-theoretic approach, the input language for the KeY prover is restricted to a typed first-order logic. It should not be the case that the Event-B language has more expressive power than the input language used by KeY. However, the translation of the set-theoretic constructs is certainly the first problem one faces. Secondly, the KeY prover has to deal with the Event-B proof obligations. As it has not been developed for dealing with set-theoretic constructs, even if formulated in first-oder logic, it is not even clear how well these proof obligations can be handled manually not to mention if it is possible to discharge them automatically. 2.4 Summary The aims of Event-B/Rodin and KeY are similar on the one hand providing an integrated environment for specification and prove and different on the other hand modeling and verifying on a high level of abstraction vs. verification of executable code. The formalization languages used by the two toolsets differ. Event-B consequently follows a set-theoretic approach, while set-theoretic modeling has not been in the focus of the KeY developers yet. On the other hand, the KeY prover is a powerful tool, while the missing of an advanced theorem prover for Event-B is even admitted by the Rodin developers. The resulting topic of this thesis is obvious: How and how well can the KeY prover deal with Event-B proof obligations?

29 3. Formalizing Event-B Proof Obligations in First-Order Logic As it was already mentioned in Section 2.1, the Rodin tool provides a comfortable interface for discharging Event-B proof obligations. An important feature is that all the set-theoretic expressions first appear on the highest possible level of abstraction. The automated prover or the user can then decide which of the set-theoretic operators should be broken up into more basic components. This leads to a high degree of proof automation and, on the other hand, to a clearly arranged proof obligation with a low number of quantifiers. When formalizing Event-B proof obligations in first-order logic, it is desirable to make a similar style of conducting a proof possible. Thus, the approach in this chapter and in chapter 4, follows this basic idea. This means, that all the set-theoretic functions and predicates will be defined in firstorder logic, which are necessary to translate Event-B proof obligations as unchanged as possible. And this means introducing a lot of derived (or high-level ) functions, which can then step-by-step be reduced to the basic operators. 3.1 Translating Event-B Language Constructs to First-Order Logic The translation of Event-B language constructs is done on the same level of abstraction. In most cases, all what has to be done is replacing the Event-B construct (for example the function symbol ) by a corresponding first-order function (here: Union) and using a prefix-notation (this means that s t is replaced by Union(s, t)) Necessary Predicates and Functions Following this approach, every Event-B language construct is mapped to exactly one corresponding predicate or function. This means, that translating Event-B proof obligations to first-order logic is a relatively straightforward job. Some exceptions

30 16 3. Formalizing Event-B Proof Obligations in First-Order Logic are mentioned in section 3.2. But these exceptions can be dealt with without the necessity of introducing extra predicates or functions. So, all in all, one needs exactly as many language constructs in first-order logic as there are language constructs in the Event-B specification Translation of Event-B Language Constructs The set-theoretic Event-B language is based on a predicate, called the membership predicate symbol. Given an expression E and a set s, the construct E s is a membership predicate [MAL05, chapter V]. It is important to note that a set is an expression, too. Nearly all other predicates and function introduced for expressing Event-B language constructs in first-order logic can be reduced to this single basic predicate. How this reduction works is explained in detail in chapter 4. An exception is the function Map, which stands for the maplet operator, denoting an ordered pair. This function will not be reduced to the in predicate (even if theoretically possible) and is therefore treated as a basic operator, as well. The only two additional predicates used are inclusion and properinclusion, but as mentioned, it is possible to replace them by formulas only containing the basic predicate in. As it makes it easier to translate Event-B constructs, and because a lot of proofs can be conducted on a higher level without a complete reduction to the in predicate, the Event-B constructs and should be translated to the predicates inclusion and properinclusion respectively and only reduced if necessary during a proof. The translation rules for the set-theoretic predicates, and as well as the operator are given in table 3.1. Token name Token Event-B First-Order Logic ELEMENT OF x S in(x, s) NOT AN ELEMENT OF x S in(x, s) PROPER INCLU- S T properinclusion(s, t) SION INCLUSION S T inclusion(s, t) NOT PROPER IN- S T properinclusion(s, t) CLUSION NOT INCLUSION S T inclusion(s, t) MAPLET x y Map(x, y) Table 3.1: Basic operators The common set constructs cartesian product and powerset are translated to the corresponding functions. The empty set is expressed by the expression Emptyset. Basic set-theoretic operators are expressed by the corresponding binary functions. This is shown in table 3.2. Relation operators and function operators are translated to a corresponding binary function, as well (see table 3.3). A special case is the application of a function to an

31 3.2. Expressing Event-B Language Constructs in JavaDL 17 Token name Token Event-B First-Order Logic SET EQUALITY = S = T s = t POWER SET P P(S) Powerset(s) CARTESIAN PROD- S T Cartesian(s, t) UCT EMPTYSET Emptyset INTERSECTION S T Intersection(s, t) UNION S T Union(s, t) DIFFERENCE \ S \ T Difference(s, t) UPTO.. y.. z Upto(y, z) Table 3.2: Elementary set operators expression, for example the common construct f (x). This is expressed by a binary function FuncAppl, and will be explained in more detail in section 3.2. Operations on relations like the converse of a relation, various relation restrictions and the image of a set under a relation as well as operators for composing two binary relations are translated to their corresponding functions as it can be seen in table 3.4. The finiteness and cardinality functions can be translated 1:1 from Event-B to JavaDL. These functions are shown in table Expressing Event-B Language Constructs in JavaDL Once Event-B language constructs have been expressed in first-order logic, it is a small step to express Event-B proof obligations in JavaDL, the KeY input-language. However, especially the typing of functions and some advanced set-theoretic constructs still provide some challenges Challenges and Constraints Even if most of the translation to first-order logic seems to work very intuitively and straightforward, there are still some challenges which were not yet discussed. The discussion of the solved problems and remaining challenges also provides an explanation why this kind of translation approach had been chosen Quantification over Functions, Relations and Sets One of the first challenge faced when trying to translate Event-B to the KeY inputlanguage might be quantification over functions, relations or sets. For example, one could face formulas like S(x S x T ) or f (f S T f S T ). If S and T would have been declared as sorts in the.key file and f had been declared as a function in functions with a return type of T and one required parameter of type S, these formulas could not have been translated to JavaDL, which being first-order does not allow these kinds of quantifications. Even simpler formulas like x S could not be translated if S was declared as a sort.

32 18 3. Formalizing Event-B Proof Obligations in First-Order Logic Token name Token Event-B First-Order Logic RELATION S T Rel(s, t) TOTAL RELATION S T TRel(s, t) SURJECTIVE RE- S T SurjRel(s, t) LATION TOTAL SURJEC- S T TSurjRel(s, t) TIVE RELATION FUNCTION APPLI- ( ) f (x) FuncAppl(f, x) CATION PARTIAL FUNC- S T Func(s, t) TION TOTAL FUNCTION S T TFunc(s, t) PARTIAL INJEC- S T PInj (s, t) TION TOTAL INJECTION S T TInj (s, t) PARTIAL SURJEC- S T PSurj (s, t) TION TOTAL SURJEC- S T TSurj (s, t) TION BIJECTION S T Bij (s, t) FIRST PROJEC- prj 1 prj 1 (r) FirstProjection(r) TION SECOND PROJEC- prj 2 prj 2 (r) SecondProjection(r) TION IDENTITY id Id(S) Id(s) Table 3.3: Relation and function operators The solution means that everything, a variable, a function, a relation and a powerset, has to be treated as a symbol of type set. The predicates in, inclusion, properinclusion and finite are all defined over sets, as well as all the functions take sets as arguments and return an expression of type set. Unary and binary operators like P,, or produce new sets out of the sets they get as arguments. Of course, this solution (treating everything as a set) seems to lead to the loss of all type information. Fortunately, a lot of type information can be saved otherwise, as discussed below. An other problem in the same context is, that functions in Event-B are often used as elements contained in some set as well as function symbols which stand for the application of the function to an expression. An example is the formula f S T f (x) = y. This means, that the problem is not completely solved by saying that f is an ordinary set. One also needs a possibility to express the application of a function to an expression Function Applications This problem can be solved by introducing the function FuncAppl, which takes as parameters two expressions of type any. The first parameter stands for the function

33 3.2. Expressing Event-B Language Constructs in JavaDL 19 Token name Token Event-B First-Order Logic MAP x y Map(x, y) OVERRIDING r q Overriding(r, q) BACKWARD COM- r q BComp(r, q) POSITION o FORWARD COMPO- 9 r o 9 q FComp(r, q) SITION DIRECT PRODUCT r q DirectProduct(r, q) PARALLEL PROD- r q ParallelProduct (r, q) UCT CONVERSE 1 r 1 Converse(r) DOMAIN dom dom(r) Dom(r) RANGE ran eran(r) Ran(r) IMAGE [ ] r[w] Image(r, w) DOMAIN RESTRIC- TION S r DRes(s, r) DOMAIN SUB- S r DSub(s, r) TRACTION RANGE RESTRIC- r S RRes(r, s) TION RANGE SUBTRAC- TION r S RSub(r, s) Table 3.4: Relation operators and compositions of relations Token name Token Event-B First-Order Logic FINITENESS finite() finite(s) finite(s) CARDINALITY card() card(s) Card(s) Table 3.5: Finiteness and cardinality

34 20 3. Formalizing Event-B Proof Obligations in First-Order Logic to be applied and the second parameter stands for the expression the function is applied to. The example f (x) = y can thus be translated to the formula FuncAppl(f, x) = y. Here, it is important to now that f (x) only makes sense if x is included in the domain of f. This is taken care of by a so-called well-formedness condition: x dom(f ) If one uses an expression like f (x) in an Event-B model, one has to prove this wellformedness condition. Either, f has been declared as a total function. Then, no new proof obligation appears here. Or, f has only been declared as a partial function. Then, an additional proof obligation is set up by the Rodin tool. In this paper, all Event-B proof obligations are translated to the KeY input language as they are. This means, that one does not need to think about introducing additional proof obligations, as the well-formedness of function application constructs has already been taken into account by the Rodin tool. For every such well-formedness requirement, the Rodin tool will create a new proof obligation to show exactly this well-formedness. But if want would like to use the KeY tool to discharge set-theoretic proof obligations not originating in the Rodin tool, the well-formedness of all function applications had to be proven explicitly, of course Function which Are Supposed to Have Different Numbers of Arguments Another challenge is given by set-theoretic symbols like and. Translated to first-order logic, these language constructs could be seen as functions which can take two or more, but not a fixed number of arguments. For example, the formula s t u would be translated to the formula Union(s, t, u), while the formula s t would be translated to the formula Union(s, t). That kind of flexible numbers of arguments are not possible in JavaDL, nor can it be dealt with by the KeY taclet language. Hence, in the approach presented in this thesis, this problem is dealt with by a nesting of the respective function. This results in the following translations: s t u Union(s, Union(t, u)) s t u Intersection(s, Intersection(t, u)) This concept can be extended to four or more arguments, of course. Obviously, this only works because the respective functions are associative. In chapter 4, taclets are created to deal with these kind of nested functions. However, they tend to make automated proving more complicated, as rules for rewriting such nested constructs can not be applied automatically. In practice, given the case study in chapter 6 and a lot of examples in [MAL05] and [RODI07], there does not seem to be a huge number of Union or Intersection function with more than two arguments, so that the performance of the automated proof search strategies in KeY should not be affected strongly.

35 3.2. Expressing Event-B Language Constructs in JavaDL Finiteness and Cardinality The functions finite and card can be used in Event-B to express if a set is finite or non-finite or to represent the number of elements in a set respectively. It is an easy job to translate these functions to JavaDL. However, to deal with these functions requires additional taclets using the definitions of finiteness and cardinality. Fortunately, these taclets could be adopted from rewriting rules already in use by the inherent Rodin prover [RODI07]. They are shown in section Set Comprehensions One major challenge when translating formulas in Event-B to formulas in JavaDL are so called sets defined in comprehension. In Event-B, they are written {x P E}, where P denotes a predicate and E denotes an expression. These set comprehensions can be read as the set of objects with shape E when P holds [MAL05]. The basic set comprehension {x P E} can be rewritten when used as argument of a set membership. This means that e {x P E} can be rewritten as x (P e = E), if x does not occur free in e. Thus, to use set comprehensions in KeY, they have to be formulated as in the right-hand-side of the rewriting rule introduced. In case the set comprehension construct is not used as argument of an in predicate denoting set membership, but as part of an inclusion or properinclusion predicate or in a set equality relation, these predicates have to be rewritten and reduced to the most basic in predicate. This can be done using the rewriting rules introduced for inclusions, proper inclusion and set equality in section 4.1. Finally, if the set comprehension construct is used as argument of a set-theoretic function, it can only be dealt with by a pull-out. In the example a b {x P E} r, this means that the set comprehension construct is replaced by a new variable, for example z, and the equality of z and the set comprehension construct is added as an assumption. The result look as follows: {x P E} = z a b z r This proof obligation can now be translated as described before. Dealing with set comprehensions makes it obvious, that one has to trust the Rodin tool in a way that all the Event-B proof obligations generated make sense. Given that the Rodin tool has performed a type check, all the Event-B proof obligations generated are meaningful in the sense, that they do not produce strange set comprehensions due to a lack of typing. An example is Russell s paradox: Given a set comprehension s = {x x x x} the formulas s s and s s are both true and false, which is impossible.

36 22 3. Formalizing Event-B Proof Obligations in First-Order Logic Because the Rodin type checker would demand that x is declared a member of one of the carrier sets of the current model, the construct s = {x x x x} could not be formulated in Event-B. This means that it will fortunately not be translated to JavaDL either, as the KeY tool would not be able to prevent the construction of set comprehensions which such strange behavior Set Extensions Another set construct which can not be translated straightforward are so called set extensions, that means sets formulated like for example s = {a, e, f, k}. While sets like s = {1,..., 5} can be formulated with help of the Upto function (this would result in the formulation s = Upto(1, 5)), this is not possible if the set contains an arbitrary collection of elements. One could, of course, use the set comprehension construct together with a disjunction of all elements included. But instead, to reduce the translation effort, the set extension construct is translated to a number of SetExtension functions. Then, s = {a, e, f, k} can be formulated as s = SetExtension(a,SetExtension(e, SetExtension(f, k))), while {e} is translated to SetExtension(e,Emptyset). As shown in section 4.1, it is then possible to define all the taclets needed to use set extensions during the performance of a proof, for example taclets that make use of a commutativity property or which deal with set extensions used as arguments for an in predicate Challenges with Typing At first glance, typing of the new functions and predicates in KeY does not necessarily seem to be a problem. One could for example think, that a predicate in which indicates set membership, takes as arguments an expression of type Element and another expression of type Set. This results in a predicate in(element, Set), corresponding to the Event-B formula element set. But of course, set membership is also defined for a formula like subset P(set). This means that one would need another predicate insetset, which takes expressions of type Set and SetSet as arguments. This can go on forever. It results in a lot of predicates even if one would restrict the language to a certain level of Sets. So, the first problem is: How to deal with the Element, Set, SetSet, SetSetSet,...- chain without introducing predicates with the same intuitive meaning more than once. Thinking further, the next challenge are the different types of elements which can appear. One would not want to declare multiple predicates like in(integer, Set), in(boolean, Set), in(string, Set), and so on for all thinkable types that could appear. Again, even with some kind of restriction, this becomes infeasible. Moreover, as the predicates would need to have different names, rewriting rules dealing with these predicates had to be written multiple times, as well. One can clearly imagine that this ends up in a rule-blow-up. One possible solution would be the use of so-called typing constructors. A predicate in could then be declared as

37 3.2. Expressing Event-B Language Constructs in JavaDL 23 : α αset, and α could be instantiated with any arbitrary element. Unfortunately, typing constructors are not an element of JavaDL, so one has to find another solution Typing in Event-B/Rodin Event-B handles typing in a different way. On the one hand, functions and predicates are typeless in a way that they can be applied to all types of arguments. On the other hand, an Event-B model contains a set of so-called carrier sets (see section 2.1), and assures that every variable and expression is an element of one of these carrier sets. Moreover, it is assured that functions and predicates are used in consistence with the membership of elements in these carrier sets. This means, that carrier sets in Event-B have certain properties. For example, they are disjoint and non-empty. Moreover, if for example e is a member of the carrier set A, e f, e f or e f can not be elements of A as these expressions are typed differently. The resulting types for all binary and unary expressions are defined in [MAL05, chapter VI, pages 31,32]. All these carrier sets properties are taken care of by the type checker of the Rodin tool. Type checking in Event-B is explained in detail in Syntax of the Mathematical Language in [MAL05, chapter VI] Typing in KeY The implementation of an Event-B like approach seems to be possible in KeY without serious challenges. All arguments and return values could be declared being of type any, which would mean that they could be used no matter what type of arguments they get. The only thing to do would be to define one constant function for every carrier set that is used in the Event-B model to translate. Thus, it would be possible to preserve that kind of semantic type information, which would be necessary to perform sound proofs in KeY, even if the types introduced by this constant functions do not correspond to the original types used in JavaDL. Type information in a syntactical sense is lost, but given that the Rodin tool only creates proof obligations which are syntactically correct, this can probably be accepted as only such proof obligations should be discharged. Let us think of an Event-B model with a carrier set CS and a proof obligation e(e CS e CS). Then, in the translation to the KeY input language, this would yield a function declared as any CS; and a proof obligation any e; (in(e, CS) -> in(e, CS)).

38 24 3. Formalizing Event-B Proof Obligations in First-Order Logic Options for Proving Event-B Proof Obligations with KeY Hence, to deal with the typing problem, two options can be taken into account when one aims to prove Event-B proof obligations with KeY: Perform a Type Check to Determine the Right Predicates Of course, one could try to reconstruct the type of expressions out of the context they are used in. Then, a type check would be performed by checking the consistency of the reconstructed implicit type information. For example, let us have a look at the following Event-B code, where ELEMENT is a carrier set in the Event-B model and e, s and t are variables: e ELEMENT e s s t Then, one could conclude that s had to be a set of elements of type ELEMENT, while t had to be a set of sets of elements of type ELEMENT and so on. Thus, s would for example be typed as SET OF ELEMENTS and t as SET OF SETS OF ELEMENTS and so on. Technically, that should not be a problem. But, as mentioned above, the resulting problem is obvious: All the predicates and functions had to be defined multiple times, as well as the rules dealing with these predicates and functions. Hence, without typing constructors mentioned above allowing for polymorphic predicates, this option has to be ruled out. Trust the Event-B Type Checker and Use a Typeless Version for Proving For the moment, all the proof obligations which are to be discharged by the KeY tool originate in proof obligations created by the Rodin tool out of the Event-B models. This means, that the proof obligations which are translated to the KeY input language are already type checked by the Rodin tool. Thus, it seems reasonable to trust the Rodin type checker and to simply adopt the proof obligations without further type checks. The obvious advantage is, that the set of required predicates is minimized and the translation of proof obligations can be performed with the least possible effort. In this case, we can declare a constant function of type any in KeY for each carrier set in the Event-B proof obligation. Then, the Event-B code e ELEMENT e S S SUP would be translated as: in(e, ELEMENT ) in(e, S) in(s, SUP). Given that the Rodin type checker has performed a correct type check, we thus get a type checked proof obligation for KeY with all type information needed to perform a proof. Unfortunately, this option compromises the completeness of the translation approach presented. Given a Event-B model with two carrier sets A and B and a proof obligation x (x A x B), this can be easily shown in Event-B as the carrier sets are disjoint per definition.

39 3.2. Expressing Event-B Language Constructs in JavaDL 25 In KeY, we can not use these properties of the carrier sets. So, if one aims for completeness, the properties of the carrier sets (disjointness, non-emptiness etc. as mentioned before) had to be formalized for the corresponding constant functions in KeY, as well. This seems to be a huge, but given an automated translation probably manageable, effort. However, neither during the performance of the case study (see chapter 6), nor for discharging other proof obligations which came up during writing this thesis, the non-completeness of the translation approach was a handicap. Choosing the second option, KeY simulates the Rodin tool in a way that the semantic type information is present in form of carrier sets or constant functions respectively, while all predicates and functions are of an universal character. For application in practice, this seems to be an easy to handle, even so successful approach, as all upcoming proof obligations could be discharged despite the lack of theoretical completeness Resulting Predicates and Functions As already mentioned in section 3.1, the translation of Event-B language constructs to the KeY input language requires as many predicates and functions as there are in the Event-B language specification Necessary Predicates The required predicates are in, inclusion, properinclusion and finite, which correspond to the Event-B symbols,, and finite respectively. As discussed, the type of the arguments has to be any : in(any,any) inclusion(any,any) properinclusion(any,any) finite(any) Necessary Functions All the necessary functions return an expression of type any, as discussed above. They require one or two arguments of the same type. The only exceptions are the constant function symbol Emptyset, which does not require an argument, and the function Upto, which require its arguments to be of type integer: any Powerset(any) any Cartesian(any,any) any Union(any,any) any Intersection(any,any)

40 26 3. Formalizing Event-B Proof Obligations in First-Order Logic any Difference(any,any) any SetExtension(any,any) any Upto(int,int) any Emptyset any Map(any,any) any Rel(any,any) any TRel(any,any) any SurjRel(any,any) any TSurjRel(any,any) any FuncAppl(any,any) any Func(any,any) any TFunc(any,any) any PInj(any,any) any TInj(any,any) any PSurj(any,any) any TSurj(any,any) any Bij(any,any) any FirstProjection(any) any SecondProjection(any) any Id(any) any Dom(any) any Ran(any) any Converse(any) any DRes(any,any) any RRes(any,any) any DSub(any,any) any RSub(any,any) any Image(any,any) any FComp(any,any)

41 3.3. Step-By-Step: How to Translate Event-B Proof Obligations to the KeY Input Language 27 any BComp(any,any) any Overriding(any,any) any DirectProduct(any,any) any ParallelProduct(any,any) any Card(any) In order to discharge an Event-B proof obligation with Key, of course, one has to include all these predicates and functions in the \predicates and \functions sections of the.key file respectively. 3.3 Step-By-Step: How to Translate Event-B Proof Obligations to the KeY Input Language As shown in the previous sections, the translation of Event-B proof obligations to the KeY input language can be done in a straightforward manner. The following steps have to be performed: 1. All the necessary functions and predicates from section 3.2 have to be declared in the.key file. 2. All taclets presented in section 4.1 must be included in the.key file. 3. For all carrier sets in the Event-B model, one corresponding constant function has to be declared. Aiming for completeness, the properties related to carrier sets have to be formulated and added to the left-hand-side of the sequent to prove. 4. For all constants and variables in the Event-B model, corresponding constants and variables have to be declared in the.key file. 5. All set comprehension constructs have to be dealt with as described in section All formulas from the Event-B proof obligation must be formulated in firstorder logic using the predicates and functions corresponding to the Event-B language constructs. Now, the proof obligation can be discharged using the KeY prover.

42 28 3. Formalizing Event-B Proof Obligations in First-Order Logic 3.4 Towards Automated Translation Following this step-by-step routine, it should be possible to perform all tasks except the reformulation of set comprehensions automatically without problems. And even the rewriting of set comprehension constructs does not seem to be a major challenge using the approach presented above. One, only technical remaining challenge, would be the format of the proof obligations. Event-B proof obligations are stored in a XML document, while the input files for the KeY prover are simple text documents. But there does not seem to be a major challenge preventing the automated translation of Event-B proof obligations to the KeY input language. So, an automation of this job seems to be a desirable and realistic to implement feature for future work on this topic. 3.5 Summary This chapter presented a step-by-step approach with which Event-B proof obligations can be translated to the KeY input language. All necessary predicates and function corresponding to the set-theoretic constructs of Event-B have been defined, as well as rules for the translation of these constructs. Dealing with the typing problem showed to be the biggest challenge, and with the solution presented one has to accept loosing the theoretical completeness of the translation. Finally, the resulting translation rules lead to a straightforward translation. It should be possible to implement this step-by-step routine without further problems, so that an automated translation from Event-B to JavaDL would be possible.

43 4. Proving Event-B Proof Obligations with KeY After the Event-B proof obligations have been translated to JavaDL (see section 3.2), one would of course like to discharge these proof obligations with KeY, too. The KeY prover was introduced in section 2.2 and can deal well with proof obligations formulated in first-order logic. But the challenge is as follows: Proofs would not be possible, if the prover was not able to work with the set-theoretic predicates and functions which were introduced in the previous chapter. So, one has to provide the KeY prover with rules (or taclets as explained in section 2.2), which allow the prover to handle these set-theoretic constructs. An easy to understand example is the following. Given the proof obligation in(e, s) in(e, Union(s, t)) (or e s e s t in Event-B), this can not be discharged using common taclets for first-order proofs. Here, the prover has to know a rule like Union \find(in(e, Union(s, t))) \replacewith(in(e, s) in(e, t)), which then leads to a modified proof obligation in(e, s) in(e, s) in(e, t) (or e s e s e t in Event-B). This proof obligation can be discharged automatically without problems by the KeY prover. 4.1 Creating Taclets The example shows, that the main task is to provide the KeY prover with all the taclets necessary for dealing with the introduced set-theoretic constructs.

44 30 4. Proving Event-B Proof Obligations with KeY Token name Predicate Rewritten ELEMENT OF x S n.a. NOT AN ELEMENT OF x S x S PROPER INCLU- S T S T S T SION INCLUSION S T S P(T ) NOT PROPER IN- S T S T CLUSION NOT INCLUSION S T S T Table 4.1: Rewriting the basic predicates Inclusion Inclusion2 ProperInclusion \find(inclusion(s, t)) \replacewith(in(s, Powerset(t))) \find(inclusion(s, t)) \varcond(\notfreein(x, s), \notfreein(x, t)) \replacewith(\forall x; (in(x, s) in(x, t))) \find (properinclusion(s, t)) \replacewith (in(s, Powerset(t))!(s = t)) Table 4.2: Taclets for rewriting the basic predicates Definitions of Set-theoretic Operators The basic approach for doing this consists of reducing all the set theoretic operators defined in section 3.1 by definitions to the basic predicates in (corresponding to ), inclusion (corresponding to ) and set equality, denoted =, as well as to the basic function Map (corresponding to ). Then, even the inclusion and the set equality predicates can be further reduced to the in predicate. This is done by the rewriting rules shown in table 4.1. The corresponding taclets are presented in table 4.2. The common set theoretic operators are rewritten using the rules in table 4.3. Token name Predicate Rewritten SET EQUALITY s = t s P(t) t P(s) EMPTYSET E INTERSECTION x S T x S x T UNION x S T x S x T DIFFERENCE x S\T x S x T POWER SET T P s x(x T x s) CARTESIAN PROD- (x, y) S T x s y t UCT UPTO x y.. z x y x y SET EXTENSION x {a,..., b} x = a... x = b Table 4.3: Rewriting common set operators

45 4.1. Creating Taclets 31 SetEquality \find (s = t) \replacewith (in(s, Powerset(t)) in(t, Powerset(s))) Emptyset \find(in(e, Emptyset)) \replacewith(false) Intersection \find(in(e, Intersection(s, t))) \replacewith(in(e, s) in(e, t)) Union \find(in(e, Union(s, t))) \replacewith(in(e, s) in(e, t)) Difference \find(in(e, Difference(s, t))) \replacewith(in(e, s)!in(e, t)) Powerset \find(in(t, Powerset(s))) \varcond (\notfreein(x, t), \notfreein(x, s)) \replacewith(\forall x; (in(x, t) in(x, s))) Powerset2 \find(in(t, Powerset(s))) \replacewith(inclusion(t, s)) CartesianProduct \find(in(map(e, f ), Cartesian(s, t))) \replacewith(in(e, s) in(f, t)) Upto \find(in(i, Upto(j, k))) \replacewith((i >= j ) (i <= k)) SetExtension \find(in(e, SetExtension(f, s))) \replacewith(e = f in(e, s)) SetExtensionEmptyset \find(in(e, SetExtension(f, Emptyset))) \replacewith(e = f ) Table 4.4: Taclets for rewriting common set operators Taclets defined in table 4.4 allow the rewriting of this common set operators for the KeY prover. Relations, function and functional operators can also be reduced to the basic predicates applying the rules in tables 4.5, 4.7 and 4.9 using the taclets from tables 4.6, 4.8 and 4.10 respectively. The rewriting rules are all taken from the chapter Event-B: Mathematical Language in [MAL05, chapter V] and were then adopted to KeY taclets by the author. As they are the definitions of the set-theoretic operators, these rules are treated as axioms, which means that their correctness was not proven. Token name Predicate Rewritten RELATION r S T r S T TOTAL RELATION r S T r S T dom(r) = S SURJECTIVE RE- r S T r S T ran(r) = T LATION TOTAL SURJEC- r S T r S T r S T TIVE RELATION Table 4.5: Rewriting relations

46 32 4. Proving Event-B Proof Obligations with KeY BinaryRelation TotalRelation SurjectiveRelation \find(in(r, Rel(s, t))) \varcond (\notfreein(x, r), \notfreein(y, r), \notfreein(x, s), \notfreein(y, s), \notfreein(x, t), \notfreein(y, t)) \replacewith(\forall x; (\forall y; (in(map(x, y), r) in(map(x, y), Cartesian(s, t))))) \find(in(r, TRel(s, t))) \replacewith(in(r, Rel(s, t)) Dom(r) = s) \find(in(r, SurhRel(s, t))) \replacewith(in(r, Rel(s, t)) Ran(r) = t) TotalSurjectiveRelation \find(in(r, TSurjRel(s, t))) \replacewith(in(r, TRel(s, t)) in(r, SurjRel(s, t))) Table 4.6: Taclets for rewriting relations Token name Predicate Rewritten FUNCTION INVO- F = f (E) E F f CATION PARTIAL FUNC- f S T f S T (f 1 o 9 f ) = TION id(ran(f )) TOTAL FUNCTION f S T f S T S = dom(f ) PARTIAL INJEC- f S T f S T f 1 T S TION TOTAL INJECTION f S T f S T f 1 T S PARTIAL SURJEC- f S T f S T T = ran(f ) TION TOTAL SURJEC- f S T f S T T = ran(f ) TION BIJECTION f S T f S T f S T FIRST PROJEC- (E F ) G E F r G = E TION prj 1 (r) SECOND PROJEC- (E F ) G E F r G = F TION prj s (r) IDENTITY E F Id(s) E S E = F Table 4.7: Rewriting functions

47 4.1. Creating Taclets 33 FunctionInvocation1 \find(funcappl(f, a) = b) \replacewith(in(map(a, b), f )) FunctionInvocation2 \find(in(funcappl(f, a), s)) \varcond(\notfreein(y, f ), \notfreein(y, a), \notfreein(y, s)) \replacewith(\forall y; (in(map(a, y), f ) in(y, s))) PartialFunction \find(in(f, Func(s, t))) \replacewith(in(f, rel(s, t)) FComp(Converse(f ), f ) = Id(Ran(f ))) TotalFunction \find(in(f, TFunc(s, t))) \replacewith(in(f, Func(s, t)) s = Dom(f )) PartialInjection \find(in(f, PInj (s, t))) \replacewith(in(f, Func(s, t)) in(converse(f ), Func(s, t))) TotalInjection \find(in(f, TInj (s, t))) \replacewith(in(f, TFunc(s, t)) in(converse(f ), Func(s, t))) PartialSurjection \find(in(f, PSurj (s, t))) \replacewith(in(f, Func(s, t)) t = Ran(f )) TotalSurjection \find(in(f, TSurj (s, t))) \replacewith(in(f, Func(s, t)) t = Ran(f )) Bijection \find(in(f, Bij (s, t))) \replacewith(in(f, TInj (s, t)) in(f, TSurj (s, t))) FirstProjection \find(in(map(map(e, f ), g), FirstProjection(r))) \replacewith(in(map(e, f ), r) g = e) SecondProjection \find(in(map(map(e, f ), g), SecondProjection(r))) \replacewith(in(map(e, f ), r) g = f ) Identity \find(in(map(e, f ), Id(s))) \replacewith(in(e, s) f = e) Table 4.8: Taclets for rewriting functions

48 34 4. Proving Event-B Proof Obligations with KeY Token name Predicate Rewritten MAP x y f n.a. OVERRIDING E F r q E F (dom(q) p) q BACKWARD COM- E f r q F E r o 9 q POSITION FORWARD COMPO- E F r o 9 q x(e x p x F q) SITION DIRECT PRODUCT E (F G) r q E F p E G q PARALLEL PROD- (E F ) (G E G p F H q UCT H ) r q CONVERSE x y r 1 y x r DOAMIN E dom(r) y (E y r) RANGE E ran(r) x (x E r) IMAGE F r[w] x (x w x F r) DOMAIN RESTRIC- TION E F S r E F r E S DOMAIN SUB- E F S r E F r F T TRACTION RANGE RESTRIC- E F r S E F r E S TION RANGE SUBTRAC- TION E F r S E F r F T Table 4.9: Rewriting functional operators Definitions of Finiteness and Cardinality The Event-B functions finite and card can be translated 1:1 to JavaDL. To allow the KeY prover to deal with these functions, the taclets from tables 4.11 and 4.12 are needed respectively. These rules are all taken from [RODI07, chapter 6] and have been adopted to KeY taclets, too Rewriting and Simplification of Set-theoretic Expressions Of course, a lot of proof obligations can be discharged without reducing all settheoretic constructs to the basic predicates. A lot of simplifications can be done on a higher level of abstraction. This is especially useful when the complexity of an expression can directly be reduced drastically. On the other side, some proof obligation do not directly simplify an expression, but allow to rewrite the expression they are applied to in a way that further simplification of the proof goal becomes possible. In the user manual of the Rodin platform [RODI07, chapter 6], all the rules used by the basic prover included in the Rodin toolset are presented. Out of them, the taclets not already included in KeY as taclets for applying the definitions of set-theoretic operators or rules already included in KeY as basic rules dealing with first-order logic, have been adopted to KeY taclets, too.

49 4.1. Creating Taclets 35 Overriding BackwardComposition ForwardComposition DirectProduct ParallelProduct Converse Domain Range Image DomainRestriction DomainSubtraction RangeRestriction RangeSubtraction \find(overriding(p, q)) \replacewith(union(dsub(p, Dom(q)), q)) \find(in(map(e, f ), BComp(p, q))) \varcond(\notfreein(x, e), \notfreein(x, f ), \notfreein(x, p), \notfreein(x, q)) \replacewith(\exists x; (in(map(e, x), q) in(map(x, f ), p))) \find(in(map(e, f ), FComp(p, q))) \varcond(\notfreein(x, e), \notfreein(x, f ), \notfreein(x, p), \notfreein(x, q)) \replacewith(\exists x; (in(map(e, x), p) in(map(x, f ), q))) \find(in(map(e, Map(f, g)), DirectProduct(p, q))) \replacewith(in(map(e, f ), p) in(map(e, g), q)) \find(in(map(map(e, f ), Map(g, h)), ParallelProduct(p, q))) \replacewith(in(map(e, g), p) in(map(f, h), q)) \find(in(map(e, f ), Converse(r))) \replacewith(in(map(f, e), r)) \find(in(e, Dom(r))) \varcond(\notfreein(y, e), \notfreein(y, r)) \replacewith(\exists y; (in(map(e, y), r))) \find(in(f, Ran(r))) \varcond(\notfreein(x, f ), \notfreein(x, r)) \replacewith(\exists x; (in(map(x, f ), r))) \find(in(e, Image(r, w))) \varcond(\notfreein(x, e), \notfreein(x, r), \notfreein(x, w)) \replacewith(\exists x; (in(x, w) in(map(x, e), r))) \find(in(map(e, f ), DRes(s, r))) \replacewith(in(e, s) in(map(e, f ), r)) \find(in(map(e, f ), DSub(s, r))) \replacewith(!in(e, s) in(map(e, f ), r)) \find(in(map(e, f ), RRes(r, t))) \replacewith(in(map(e, f ), r) in(f, t)) \find(in(map(e, f ), RSub(r, t))) \replacewith(in(map(e, f ), r) in(f, t)) Table 4.10: Taclets for rewriting functional operators

50 36 4. Proving Event-B Proof Obligations with KeY FiniteEmptyset FiniteSetExtension FiniteUnion FiniteIntersection FiniteDifference FinitePowerset FiniteCartesian FiniteConverse FiniteUpto \find(finite(emptyset)) \replacewith(true) \find(setextension(a, b)) \replacewith(true) \find(finite(union(s, t))) \replacewith(finite(s) finite(t)) \find(finite(intersection(s, t))) \replacewith(finite(s) finite(t)) \find(finite(difference(s, t))) \replacewith(finite(s)) \find(finite(powerset(s))) \replacewith(finite(s)) \find(finite(cartesian(s, t))) \replacewith(finite(s) finite(t)) \find(converse(r)) \replacewith(finite(r)) \find(finite(upto(a, b))) \replacewith(true) Table 4.11: Definitions of finiteness CardEmptyset \find(card(emptyset)) \replacewith(0) CardSetExtension \find(card(setextension(e, s))) \replacewith(1 + Card(s)) CardPowerset \find(card(powerset(s))) \replacewith(2 Card(s) ) CardCartesian \find(card(cartesian(s, t))) \replacewith(card(s) Card(t)) CardDifference \find(card(difference(s, t))) \replacewith(card(s) Card(Intersection(s, t))) CardUnion \find(card(union(s, t))) \replacewith(card(s)+card(t) Card(Intersection(s, t))) CardEqualsZero \find(card(s) = 0) \replacewith(s = Emptyset) CardGreaterThanZero \find(card(s) > 0) \replacewith( s = Emptyset) CardEqualsOne \find(card(s) = 1) \replacewith(\exists x(s = SetExtension(x, Emptyset))) Table 4.12: Definitions of cardinality

51 4.1. Creating Taclets 37 ElementEqual \find(e = e) \replacewith(true) ElementNotEqual \find(!e = e) \replacewith(false) MapEqual \find(map(e, f ) = Map(g, h)) EmptysetNotEqual \replacewith(e = g f = h) \find(!s = Emptyset) \varcond(\notfreein(x, s)) \replacewith(\existsx; (in(x, s))) SetExtensionEqual \find(setextension(e, Emptyset) = SetExtension(f, Emptyset)) \replacewith(e = f ) Table 4.13: Simplification of equalities The correctness of these rules has been shown by the KeY-inherent feature for proving the correctness of new taclets. For this task, the taclets dealing with the definitions of the set-theoretic operators had been used as axioms. Table 4.13 shows taclets for the simplification of set equalities. A lot of common set expression can be simplified with the taclets in table Table 4.15 contains rules for the simplification of expressions including the functions Domain, Range and Map. Some functional expressions can be simplified with the taclets from table Sometimes, the rewriting of the inclusion predicate can be necessary. This can be performed using the rules from table Expression using the Converse functions are dealt with by the taclets in table Table 4.19 contains taclets rewriting various forms of domain- and range restrictions. Expressions containing the Union function are rewritten using the predicates in table Forward compositions can be rewritten with the taclets from table Last but not least, the rewriting of some miscellaneous set expressions is done by the taclets presented in table Further Taclets for Common Problems in Event-B Modeling During the discharging of various proof obligations and out of the intention to make common Event-B proof obligations easy to discharge, further taclets had been defined. They aim to make proofs of Event-B proof obligations with the KeY tool easier and to allow a higher degree of automation. Again, the correctness of these rules had been shown by the KeY-inherent feature for proving the correctness of new taclets. This time, all the taclets which were proven correct until now, served as basis for these proofs.

52 38 4. Proving Event-B Proof Obligations with KeY EmptysetIntersection \find(intersection(s, Emptyset)) \replacewith(emptyset) DoubleIntersection \find(intersection(s, s)) \replacewith(s) EmptysetUnion \find(union(s, Emptyset)) \replacewith(s) DoubleUnion \find(union(s, s)) \replacewith(s) EmptysetInclusion \find(inclusion(emptyset, s)) \replacewith(true) DoubleInclusion \find(inclusion(s, s)) \replacewith(true) EmptysetProper \find(properinclusion(emptyset, s)) Inclusion \replacewith(true) DoubleProperInclusion \find(properinclusion(s, s)) \replacewith(false) SetExtensionToTrue \find(in(a, SetExtension(a, b))) \replacewith(true) DoubleSetExtension \find(setextension(a, a)) \replacewith(setextension(a, Emptyset)) DoubleSetExtension2 \find(setextension(a, SetExtension(a, b))) \replacewith(setextension(a, b)) DoubleDifference \find(difference(s, s)) \replacewith(emptyset) DifferenceEmptyset \find(difference(s, Emptyset)) \replacewith(s) EmptysetDifference \find(difference(emptyset, s)) \replacewith(emptyset) InSetExtension \find(in(e, SetExtension(f, Emptyset))) \replacewith(e = f ) CartesianSetExtension \find(in(map(a, b), Cartesian(s, SetExtension(e, Emptyset)))) \replacewith(in(a, s) b = e) Table 4.14: Simplification of set expressions

53 4.1. Creating Taclets 39 EmptysetImage EmptysetDomain EmptysetRange DomainSetExtension RangeSetExtension DomainMap RangeMap MapOverriding1 MapOverriding2 MapOverriding3 \find(image(r, Emptyset)) \replacewith(emptyset) \find(dom(emptyset)) \replacewith(emptyset) \find(ran(emptyset)) \replacewith(emptyset) \find(dom(setextension(f, g))) \replacewith(union(dom(f ), Dom(g))) \find(ran(setextension(f, g))) \replacewith(union(ran(f ), Ran(g))) \find(dom(setextension(map(a, b), Emptyset))) \replacewith(setextension(a, Emptyset)) \find(ran(setextension(map(a, b), Emptyset))) \replacewith(setextension(b, Emptyset)) \find(in(map(e, f ), Overriding(r, SetExtension(Map(a, b), Emptyset)))) \replacewith(true) \find(in(map(e, f ), Overriding(r, Overriding(p, SetExtension(Map(a, b), Emptyset))))) \replacewith(true) \find(in(map(e, f ), Overriding(r,Overriding(p, Overriding(q, SetExtension(Map(a, b), Emptyset)))))) \replacewith(true) Table 4.15: Simplification of domain-, range- and map-expressions ConverseMap FCompEmptyset EmptysetFComp \find(converse(map(a, b))) \replacewith(map(b, a)) \find(fcomp(r, Emptyset)) \replacewith(emptyset) \find(fcomp(emptyset, r)) \replacewith(emptyset) Table 4.16: Simplification of functional expressions InclusionUnion IntersectionInclusion UnionInclusion InclusionIntersection DifferenceInclusion \find(inclusion(s, Union(s, a))) \replacewith(true) \find(inclusion(intersection(s, a), s)) \replacewith(true) \find(inclusion(union(a, b), s)) \replacewith(inclusion(a, s) inclusion(b, s)) \find(inclusion(s, Intersection(a, b))) \replacewith(inclusion(s, a) inclusion(s, b)) \find(inclusion(difference(a, b), s)) \replacewith(inclusion(a, Union(b, s))) Table 4.17: Rewriting of inclusion predicates

54 40 4. Proving Event-B Proof Obligations with KeY ConverseUnion ConverseIntersection ConverseDRes ConverseDSub ConverseRRes ConverseRSub \find(converse(union(p, q))) \replacewith(union(converse(p), Converse(q))) \find(converse(intersection(p, q))) \replacewith(intersection(converse(p), Converse(q))) \find(converse(dres(s, r))) \replacewith(rres(converse(r), s)) \find(converse(dsub(s, r))) \replacewith(rsub(converse(r), s)) \find(converse(rres(r, s))) \replacewith(dres(s, Converse(r))) \find(converse(rsub(r, s))) \replacewith(dsub(s, Converse(r))) Table 4.18: Rewriting of converse-expressions UnionDRes IntersectionDRes UnionDSub IntersectionDSub DResUnion DResIntersection DSubUnion DSubIntersection RResUnion RResIntersection RSubUnion RSubIntersection UnionRRes IntersectionRRes UnionRSub IntersectionRSub \find(dres(union(s, t), r)) \replacewith(union(dres(s, r),dres(t, r))) \find(dres(intersection(s, t), r)) \replacewith(intersection(dres(s, r), DRes(t, r))) \find(dsub(union(s, t), r)) \replacewith(intersection(dsub(s, r),dsub(t, r))) \find(dsub(intersection(s, t), r)) \replacewith(union(dsub(s, r), DSub(t, r))) \find(dres(s, Union(p, q))) \replacewith(union(dres(s, p), DRes(s, q))) \find(dres(s, Intersection(p, q))) \replacewith(intersection(dres(s, p), DRes(s, q))) \find(dsub(s, Union(p, q))) \replacewith(union(dsub(s, p), DSub(s, q))) \find(dsub(s, Intersection(p, q))) \replacewith(intersection(dsub(s, p), DSub(s, q))) \find(rres(r, Union(s, t))) \replacewith(union(rres(r, s),rres(r, t))) \find(rres(r, Intersection(s, t))) \replacewith(intersection(rres(r, s), RRes(r, t))) \find(rsub(r, Union(s, t))) \replacewith(intersection(rsub(r, s),rsub(r, t))) \find(rsub(r, Intersection(s, t))) \replacewith(union(rsub(r, s), RSub(r, t))) \find(rres(union(p, q), s)) \replacewith(union(rres(p, s), RRes(q, s))) \find(rres(intersection(p, q), s)) \replacewith(intersection(rres(p, s), RRes(q, s))) \find(rsub(union(p, q), s)) \replacewith(union(rsub(p, s), RSub(q, s))) \find(rsub(intersection(p, q), s)) \replacewith(intersection(rsub(p, s), RSub(q, s))) Table 4.19: Rewriting of domain- and range-expressions

55 4.1. Creating Taclets 41 ImageUnion UnionImage DomUnion RanUnion \find(image(r, Union(s, t))) \replacewith(union(image(r, s), Image(r, t))) \find(image(union(p, q), s)) \replacewith(union(image(p, s), Image(q, s))) \find(dom(union(p, q))) \replacewith(union(dom(p), Dom(q))) \find(ran(union(p, q))) \replacewith(union(ran(p), Ran(q))) Table 4.20: Rewriting of union-expressions FCompUnion UnionFComp FCompImage DResFComp DSubFComp RResFComp RSubFComp \find(fcomp(p, Union(q, r))) \replacewith(union(fcomp(p, q), FComp(p, r))) \find(fcomp(union(q, r), p)) \replacewith(union(fcomp(q, p), FComp(r, p))) \find(image(fcomp(p, q), s)) \replacewith(image(q, Image(p, s))) \find(fcomp(dres(s, p), q)) \replacewith(dres(s, FComp(p, q))) \find(fcomp(dsub(s, p), q)) \replacewith(dsub(s, FComp(p, q))) \find(fcomp(p, RRes(q, s))) \replacewith(rres(fcomp(p, q), s)) \find(fcomp(p, RSub(q, s))) \replacewith(rsub(fcomp(p, q), s)) Table 4.21: Rewriting of composition-expressions SetEqualityToInclusion \find(s = t) \replacewith(inclusion(s, t) inclusion(t, s)) InclusionDifference \find(inclusion(s, Difference(a, b))) \replacewith(inclusion(s, a) (Intersection(s, b) = Emptyset)) DifferenceIntersection \find(difference(u, Intersection(s, t))) \replacewith(union(difference(u, s), Difference(u, t))) DifferenceUnion \find(difference(u, Union(s, t))) \replacewith(intersection(difference(u, s), Difference(u, t))) Table 4.22: Rewriting of set expressions

56 42 4. Proving Event-B Proof Obligations with KeY CommuteUnion CommuteUnion2 MergeUnion CommuteIntersection CommuteIntersection2 MergeIntersection CommuteSetExtension CommuteSetExtension2 \find(union(s, t)) \replacewith(union(t, s)) \find(union(s, Union(t, w))) \replacewith(union(t, Union(s, w))) \find(union(union(s, t), Union(u, w))) \replacewith(union(s, Union(t, Union(u, w)))) \find(intersection(s, t)) \replacewith(intersection(t, s)) \find(intersection(s, Intersection(t, w))) \replacewith(intersection(t, Intersection(s, w))) \find(intersection(intersection(s, t),intersection(u, w))) \replacewith(intersection(s,intersection(t, Intersection(u, w)))) \find(setextension(s, t)) \replacewith(setextension(t, s)) \find(setextension(s, SetExtension(t, w))) \replacewith(setextension(t, SetExtension(s, w))) Table 4.23: Further taclets I IntersectionUnion1 IntersectionUnion2 UnionDifference \find(intersection(union(s, t), u)) \replacewith(union(intersection(s, u), Intersection(t, u))) \find(intersection(u, Union(s, t))) \replacewith(union(intersection(s, u), Intersection(t, u))) \find(union(difference(s, u), Difference(t, u))) \replacewith(difference(union(s, t), u)) Table 4.24: Further taclets II The taclets in table 4.23 fill a gap by allowing to use the commutativity properties of the Union and Intersection functions and to deal with nested operators induced by the characteristic of the translation from Event-B to JavaDL. The taclets in table 4.24 can be used to rewrite combinations of the Union with the Intersection or Difference function respectively. And the taclets in table 4.25 can be used to rewrite combinations of the Difference with the Intersection or Union function respectively. DifferenceUnion1 DifferenceUnion2 DifferenceIntersection1 DifferenceIntersection2 \find(difference(s, Union(s, t))) \replacewith(emptyset) \find(difference(s, Union(t, s))) \replacewith(emptyset) \find(difference(s, Intersection(s, t))) \replacewith(difference(s, t)) \find(difference(s, Intersection(t, s))) \replacewith(difference(s, t)) Table 4.25: Further taclets III

57 4.1. Creating Taclets 43 RightIntersection- Intersections RightInclusionUnion \find(==> Intersection(Intersection(s, t), Intersection(s, u)) = Emptyset) \add(==> Intersection(t, u) = Emptyset) \find(==> inclusion(e, Union(s, t))) \add(==> (inclusion(e, s) inclusion(e, t))) \find(==> inclusion(union(s, u), Union(t, u))) \add(==> inclusion(s, t)) \find(==> inclusion(union(s, t), Union(u, w))) \add(==> inclusion(s, u) inclusion(t, w)) Table 4.26: Further taclets IV InclusionToIn RightInclusionUnion- Union RightSplitInclusion Intersection- SetExtension- Emptyset UnionInInclusionTo- Inclusion \find(inclusion(setextension(e, Emptyset), s)) \replacewith(in(e, s)) \find(intersection(setextension(e, Emptyset), s) = Emptyset) \replacewith( in(e, s)) \assumes(inclusion(u, s) ==>) \find(e = Union(u, SetExtension(a, Emptyset)) ==>) \add(inclusion(e, s) ==>); \add(==> in(a, s)) Table 4.27: Further taclets V The taclets in table 4.26 simplify a proof obligation containing certain constructs with the inclusion predicate or the Intersection function by adding extra options on the right-hand-side of the sequent. Table 4.27 shows more taclets for simplifying inclusion- and Intersection-constructs. The taclets in table 4.28 have shown to be very useful while conducting the case study. As explained in section 6.2 they are responsible for the automated discharging of a series of proof obligations which could not be discharged automatically by the Rodin provers. More taclets presented in table 4.29 deal with the combination of compositions and the Converse function. Combinations of Domain and Range functions with Domain Subtraction and Range Subtraction constructs respectively should be treated automatically as well as certain inclusion constructs on the right side of the sequent, which can often be discharged by proving even stronger propositions. This is done by the taclets in table LeftUnionRightIn \assumes(union(t, u) = s ==>) \find(==> in(e, s)) \add(==> (in(e, t) in(e, u))) LeftIntersectionRight- In \assumes(intersection(t, u) = s ==>) \find(==> in(e, s)) \add(==> (in(e, t) in(e, u))) Table 4.28: Further taclets VI

58 44 4. Proving Event-B Proof Obligations with KeY IdentityIdentity ConverseConverse IntroduceConverse FCompToBComp BCompToFComp ConverseFComp ConverseBComp FCompConverse BCompConverse ConverseEmptyset ConverseId \find(id(id(s))) \replacewith(id(s)) \find(converse(converse(r))) \replacewith(r) \find(r) \replacewith(converse(converse(r))) \find(fcomp(f, g)) \replacewith(bcomp(g, f )) \find(bcomp(f, g)) \replacewith(fcomp(g, f )) \find(converse(fcomp(f, g))) \replacewith(bcomp(converse(f ), Converse(g))) \find(converse(bcomp(f, g))) \replacewith(fcomp(converse(f ), Converse(g))) \find(bcomp(converse(f ), Converse(g))) \replacewith(converse(fcomp(f, g))) \find(fcomp(converse(f ), Converse(g))) \replacewith(converse(bcomp(f, g))) \find(converse(emptyset)) \replacewith(emptyset) \find(converse(id(r))) \replacewith(id(r)) Table 4.29: Further taclets VII DomainDomainSub \find(dom(dsub(f, a))) \replacewith(difference(dom(f ), a)) RangeRangeSub \find(ran(rsub(a, f ))) \replacewith(difference(ran(f ), a)) InclusionRanDRes \find(==> inclusion(ran(dres(s, r)), t)) \add(==> inclusion(ran(r), t)) InclusionRanDSub \find(==> inclusion(ran(dsub(s, r)), t)) \add(==> inclusion(ran(r), t)) InclusionDomDRes \find(==> inclusion(dom(rres(r, s)), t)) \add(==> inclusion(dom(r), t)) InclusionDomDSub \find(==> inclusion(dom(rsub(r, s)), t)) \add(==> inclusion(dom(r), t)) Table 4.30: Further taclets VIII

59 4.2. Summary 45 PowersetCartesian BinaryRelation2 UnionInRelation IntersectionInRelation DifferenceInRelation \find(powerset(cartesian(s, t))) \replacewith(rel(s, t)) \find(in(map(a, b), Rel(s, t))) \replacewith(in(map(a, b),cartesian(s, t))) \find(in(union(f, g), Rel(s, t))) \replacewith(in(f, Rel(s, t)) in(g, Rel(s, t))) \find(==> in(intersection(f, g), Rel(s, t))) \add(==> in(f, Rel(s, t)) in(g, Rel(s, t))) \find(==> in(difference(f, g), Rel(s, t))) \add(==> in(f, Rel(s, t)) in(g, Rel(s, t))) Table 4.31: Further taclets IX FunctionProperty \find(fcomp(converse(f ), f ) = Id(Ran(f ))) \varcond(\notfreein(x, f ), \notfreein(y, f ), \notfreein(z, f )) \replacewith(\forall x; (\forall y; (\forall z; ((in(map(x, y), f ) in(map(x, z), f )) y = z)))) PartialFunction2 \find(in(f, Func(s, t))) \varcond(\notfreein(x, f ), \notfreein(y, f ), \notfreein(z, f )) \replacewith(in(f, Rel(s, t)) (\forall x; (\forall y; (\forall z; ((in(map(x, y), f ) in(map(x, z), f )) y = z))))) FuncToPowersetFunc1 \assumes(in(a, Powerset(s)) ==>) \find(in(f, Func(a, b)) ==>) \add(in(f, Func(s, b)) ==>) FuncToPowersetFunc2 \assumes(in(b, Powerset(s)) ==>) \find(in(f, Func(a, b)) ==>) \add(in(f, Func(a, s)) ==>) Table 4.32: Further taclets X Simplification of relations in combination with other functions are achieved by applying the taclets from table Properties related to functions are used for simplifications by the taclets contained in table The taclets in table 4.33 have been created to discharge certain proof obligations which came up during the conduction of the case study (see chapter 6). They are explained in section 6.2. All in all, an extra number of 54 taclets was created to allow more proof obligations to be discharged automatically. All together, a number of 191 taclets is now available in KeY for the discharging of set-theoretic proof obligations. 4.2 Summary With all taclets presented in this chapter, the discharging of Event-B proof obligations in KeY is possible. This is verified by the case study in chapter 6. Where

60 46 4. Proving Event-B Proof Obligations with KeY RangeToInclusion \assumes(ran(f ) = s ==>) \varcond(\notfreein(x, f ), \notfreein(x, s)) \add( x; (inclusion(image(f, x), s)) ==>) BijectionImage- Intersection UnionImage- Intersection InImageConverse \assumes(in(f, Bij (s, t)) ==>) \find(==> Intersection(Image(f, a), Image(f, b)) = Emptyset) \add(==> Intersection(a, b) = Emptyset) \assumes(inclusion(s, Union(a, b)) ==>) \find(union(image(f, Intersection(s, a)), Image(f, Intersection(s, b)))) \replacewith(t); \add(==> in(f, Func(s, t))) \assumes(in(f, Rel(Difference(s, SetExtension(a, Emptyset)), w)) ==>) \find(u = Image(Converse(f ), t) ==>) \add( in(a, u) ==>) Table 4.33: Further taclets XI necessary, the correctness of the created taclets was proven. With additional taclets created for common problems in Event-B modeling and out of the experiences gained in the case study, the proving becomes more straightforward to perform and automated proof support can be easier supplied by the KeY tool.

61 5. Towards Automated Discharching of Event-B Proof Obligations In order to use the Event-B modeling language efficiently, one would of course aim for a high amount of proof obligations which can be discharged automatically or with a very low level of required user interaction. This means, that after an Event-B proof obligation has been translated to JavaDL, the desired behavior of the KeY tool would be the user pressing the button and the KeY tool applying all necessary rules automatically until all proof goals are closed. As the necessary proof rules have already been defined in chapter 4, now, a form of strategies is needed to determine when to apply which rule to which term or formula in the proof obligation. 5.1 Automated Proving in Event-B/Rodin As introduced in section 2.1, the Rodin tool for Event-B already comes with an integrated prover and a more comprehensive prover can be freely downloaded and integrated in the Rodin tool, as well. As it will be discussed later in section 6.2, this advanced prover is already able to perform fully automatic proofs in a lot of cases. 5.2 Proof Strategies for KeY The KeY tool is already equipped with a prover which can discharge a lot of firstorder logic proof goals automatically or with a minimum amount of user interaction. That is what we want to achieve for discharging Event-B proof obligations as well. Automated proofs in KeY are done with help of so called heuristics, that mean rule sets, which identify taclets that are treated in the same way by the prover [BeHS07,

62 48 5. Towards Automated Discharching of Event-B Proof Obligations chapter 4]. As mentioned in section 2.2, the heuristic simplify is meant to include taclets which are used to simplify expressions. Moreover, there are the sets of user defined taclets (usertaclets1, usertaclets2, user- Taclets3 ), in which further Event-B specific taclets could be included. 5.3 Including Taclets in Existing KeY-Strategies When we take a look at taclets defined for dealing with Event-B proof obligations, we see that a lot of the taclets defined in section 4.1 do indeed aim to simplify set-theoretic expressions. These taclets should be included in the simplify heuristic without doubt. A lot of the taclets do not only deal with expressions in a syntactic sense, but also include predicates or combinations of certain predicates and pre-defined functions. In case these taclets could undoubtly be seen as being of simplifying character, they were included in the simplify heuristic, too. The same applies to taclets, which make use of the \add construct to give alternative options to close a proof by adding additional conclusion to the right-hand-side of the sequent that can be used in special cases. So, all in all, the following taclets have been included in the simplify heuristic (in alphabetical order): Bijection, BijectionImageIntersection, BinaryRelation2 CartesianProduct, CartesianSetExtension, Converse, ConverseConverse, Converse- Emptyset, ConverseId, ConverseMap Difference, DifferenceEmptyset, DifferenceInRelation, DifferenceIntersection1, DifferenceIntersection2, DifferenceUnion1, DifferenceUnion2, DirectProduct, Domain- DomainSub, DomainMap, DomainRestriction, DomainSetExtension, DomainSubtraction, DoubleDifference, DoubleInclusion, DoubleIntersection, DoubleProperInclusion, DoubleSetExtension, DoubleSetExtension2, DoubleUnion ElementEqual, ElementNotEqual, Emptyset, EmptysetDifference, EmptysetDomain, EmptysetFComp, EmptysetImage, EmptysetInclusion, EmptysetIntersection, EmptysetProperInclusion, EmptysetRange, EmptysetUnion FCompEmptyset, FirstProjection, FuncToPowersetFunc1, FuncToPowersetFunc2 Identity, IdentityIdentity, InclusionDomDRes, InclusionDomDSub, InclusionIntersection, InclusionRanDRes, InclusionRanDSub, InclusionToIn, InclusionUnion, InclusionUnionUnion, InImageConverse, InSetExtension, Intersection, Intersection- Inclusion, IntersectionInRelation, IntersectionIntersectionsRight, IntersectionSetExtensionEmptyset, IntersectionUnion1, IntersectionUnion2, IntersectionUnionsRight LeftIntersectionRightIn, LeftUnionRightIn MapEqual, MapOverriding1, MapOverriding2, MapOverriding3, MergeIntersection, MergeUnion ParallelProduct, PartialInjection, PartialSurjection, PowersetCartesian RangeMap, RangeRangeSub, RangeRestriction, RangeSetExtension, RangeSubtraction, RightInclusionUnion

63 5.3. Including Taclets in Existing KeY-Strategies 49 SecondProjection, SetExtension, SetExtensionEmptyset, SetExtensionEqual, SetExtensionToTrue, SplitInclusionRight, SurjectiveRelation TotalFunction, TotalInjection, TotalRelation, TotalSurjection, TotalSurjectiveRelation Union, UnionDifference, UnionImageIntersection, UnionInclusion, UnionInInclusionToInclusion, UnionInRelation, Upto Now, three groups of taclets remain, which were not included in heuristics and therefore can not be applied automatically yet. First, there are taclets which neither make an expression simpler nor more complicated, but make use of certain properties that allow to rewrite an expression in a way another rule could be made applicable. Good examples are rules that make use of commutativity properties (for example, as s t equals to t s, Union(s, t) can be rewritten as Union(t, s)). These taclets could be grouped in one of the usertaclet heuristics and applied only if simplification of the proof obligations did not reach the goal alone. However, during the performance of the case study presented in chapter 6, proofs were found to be better to perform if the rule was chosen manually in such cases, so that a lot of not helpful and sometimes even distracting automatic rule applications could be avoided. The second group of taclets, which were not included in heuristics, consists of all the rewriting taclets that introduce quantifiers when being applied. Examples are the taclets for reducing set equality or inclusion predicates to the basic set membership predicate in. Set equality is reduced to set membership by the two taclets SetEquality and Powerset: SetEquality \find(s = t) \replacewith(in(s, Powerset(t)) in(t, Powerset(s))) Powerset \find(in(t, Powerset(s))) \varcond(\notfreein(x, t), \notfreein(x, s)) \replacewith(\forall x; (in(x, t) -> in(x, s))) Inclusion can be reduced to set membership by the Inclusion2 taclet: Inclusion2 \find(inclusion(s, t)) \varcond(\notfreein(x, s), \notfreein(x, t)) \replacewith(\forall x; (in(x, s) -> in(x, t))) For discharging certain proof obligations, these rewriting taclets have to be applied necessarily. On the other hand, a huge amount of proof obligations can be discharged without rewriting set equalities and inclusions. For discharging these proof

64 50 5. Towards Automated Discharching of Event-B Proof Obligations obligations, the automated application of the taclets mentioned could be even counterproductive. As these taclets introduce new quantifiers and bound variables, the prover could try to find a good instantiation for these variables instead of applying more goal-directed rules. With the experience from the case study in chapter 6, it seems reasonable for the moment not to include rules introducing new variables in any heuristic, but to apply such rules only manually close to the very end of a proof. Finally, the third group of taclets to be applied manually are all taclets dealing with finiteness and cardinality. This is because they only appear very infrequently and have to be applied in accordance with the specific situation they are a part of. Thus, as a result, all simplifying rules have been included in the simplify heuristic, and all the other rules are not included in a heuristic. This means that 105 (or 55%) out of the 191 taclets defined in section 4.1 can be applied automatically and 86 rules (thereof 18 dealing with finiteness and cardinality) have to be applied manually. But as one will see in the case study, a high degree of proofs is closed automatically nevertheless. 5.4 Remaining Challenges for Automated Proving Even if the one comparably simple step of integrating all simplifying taclets in the corresponding heuristic already leads to very encouraging results (see chapter 6), there are obviously three challenges that prevent the KeY prover from discharging even more proof obligations automatically. These challenges are: 1. Implementation of new specialized heuristics and integration of all taclets in heuristics to allow automated application 2. Using non-simplifying rules towards the end of a proof 3. Improving the handling of bound variables Of course, the allocation of set-theoretic specific taclets to heuristics, especially to the usertaclet groups, could be deeper investigated and further improvements seem to be possible. But, on the other hand, the challenges mentioned have nothing to do with specific set-theoretic problems but are common challenges automated first-order provers face. So, the most potential for improving the result with the KeY tool, seems to lie in the definition of more and more specific taclets. These taclets could deal with a lot of possible corner cases without introducing new bound variables, but would be applicable on a higher level of abstraction. Then, these taclets could be added to the simplify heuristic and would be applied automatically without problems.

65 5.5. Summary Summary For discharging Event-B proof obligations automatically with help of the KeY tool, the only think that was done was to include all taclets with simplifying character in the corresponding KeY heuristic simplify. As it turned out (see the case study in chapter 6), this was already a very effective step towards a high degree of automatically performed proofs. However, further improvements seem possible. They could be achieved through even more and more specialized taclets or through the creation of specialized strategies dealing with common structures and problems faced when discharging proof obligations resulting from Event-B modeling.

66 52 5. Towards Automated Discharching of Event-B Proof Obligations

67 6. Case Study: A Tree-structured File System After showing how Event-B proof obligations can be expressed in first-oder logic and translated to the input language of the KeY prover, the feasibility of this approach is tested using a case study. Moreover, it is compared how well the provers of the Rodin tool and the Key tool can deal with the proof obligations induced by a model. For this purpose, a model of a tree-structured file system is used. It will be made use of a model proposed by Damchoom et al. [DaBA08a]. Damchoom et al. use the Event-B modeling language and the Rodin tool for specification and proof of their model. As the model and all corresponding proofs are published, it can be used to compare the discharging of proof obligations with the Rodin tool and the KeY tool respectively. 6.1 Modeling a Tree-Structured File System in Event-B and Rodin The model of the tree-structured file system focuses on a tree structure and functionalities affecting the tree structure: create, delete, copy and move objects, that can be files or directories. A more detailed description of the model can be found in [DaBA08a]. The complete model including all proof obligations and corresponding proofs is available online [DaBA08b]. Here, the model properties necessary for a basic understanding of the proof obligations are shortly mentioned. The system specification is divided into four levels (an abstraction and three levels of refinement). It thus consists of four machines additional to two contexts Abstract Model The abstract model focuses on tree properties and basic tree operations. Both files and directories are treated as objects which are nodes of the tree structure. The important requirements at this level of abstraction are the following:

68 54 6. Case Study: A Tree-structured File System Figure 6.1: The abstract model (from [DaBA08a]) The file system has a root node All objects except the root node must have a parent node There are no loops in the file system Every node in the file system is reachable from the root node. In figure 6.1, the machine variables, invariants corresponding to the formulated requirements and initialization values of all variables are given The First Refinement The first refinement partitions objects into files and directories, which are initialized to the empty set and a set only containing the root node respectively. This means that also the Create event has to be refined into two different events Create File and Make Directory. Out of this, this level introduces additional requirement, which are: The set of objects is partitioned into the set of files and the set of directories The root node is a directory The parent of each node must be a directory After the first refinement, the machine including variables, invariants and initialization values looks as shown in figure 6.2. In addition, the events Copy and Delete are further refined to take into account the additional requirements (see [DaBA08a] for details). As this level already includes interesting details which lead to non-trivial proof obligations and, on the other hand, still is feasible as an example for this paper, the proof obligations of the first refinement are used to investigate the possibility of discharging them with the KeY-tool.

69 6.1. Modeling a Tree-Structured File System in Event-B and Rodin 55 Figure 6.2: The first refinement (from [DaBA08a]) Second and Third Refinement The second refinement introduces file content and corresponding events like Open, Close, Write and Read. The third refinement further adds ownerships and access permissions to the model. Together, the second and third refinement stand for a total of 56 new proof obligations. 41 (or 73%) of them are discharged automatically by the Rodin tool. More details are again given in [DaBA08a]. For the case study in this paper, this levels of refinement are not taken into account. Proof obligations from this levels could, however, be discharged by the KeY tool, as well, without any known caveat Resulting Proof Obligations Out of the four levels of the system specification, the proof obligations are automatically created by the Rodin tool. It comes up with a total of 158 proof obligations, which are attached to one of the four levels (machines) or the two contexts respectively. At the level of the first refinement, the model includes five events, which are Make Directory, Create File, Move, Delete and Copy Initialization Proof obligations are created to show that invariants hold initially. A total of seven proof obligations is needed Make Directory With event Make Directory, a new directory object is created in an existing directory. The correct execution can be shown by discharging nine proof obligations.

70 56 6. Case Study: A Tree-structured File System Figure 6.3: Moving a subtree (from [DaBA08a]) Create File With event Create File, a new file object is created in an existing directory. This leads to eight proof obligations Move Here, an existing object is moved in the tree structure from one place to another place (see figure 6.3). Guards are needed to rule out the cases that the destination does not exist or that the destination is a descendant of the object being moved or the object itself. The Move event adds four proof obligations to discharge Delete The Delete event removes an existing object including all its descendants from the file system. As an example, figure 6.4 shows the corresponding specification of the delete event. Here, obj is the object to be deleted, des is the set of all its descendants, and tcl(parent) the transitive closure of the parent relation. Ten proof obligations are to discharge in order to prove this event to be modeled correctly. One of them is for example move/inv1/inv : ran(parent) directories, obj (files directories) \ root, to directories, des = (tcl(parent)) 1 [{obj }], to des {obj } ==> ran(parent {obj to}) directories This proof obligation ensures that the invariant inv2.6 of the first refinement model (see figure 6.2) still holds after the execution of the Delete event Copy With event Copy, (see figure 6.5) an existing object can be moved from one place to another place. As with the Move event, Guards are needed to rule out the

71 6.2. Discharging the Resulting Proof Obligations 57 Figure 6.4: A specification of delete event (from [DaBA08a]) Figure 6.5: Copying a subtree (from [DaBA08a]) cases that the destination does not exist or that the destination is a descendant of the object being moved or the object itself. In case that the object being copied is a directory, all descendants of that directory also have to be copied to the new location. Additionally, the copy must have the same structure as the original. All together, this is taken care of by twelve additional proof obligations. 6.2 Discharging the Resulting Proof Obligations Out of the first refinement of the modeled tree-structured file system, a total of 50 proof obligations is given by the Rodin tool. These proof obligations have been discharged by Damchoom et al. [DaBA08a] directly in the Rodin tool. But using the translation from the Event-B language to JavaDL as proposed in 3.1 and 3.2, they can also be dealt with by the KeY prover.