Machine-Checked Refinement Proof Obligationsfor Rodin in the Boogie2 language v2.0

- Technical Report -

Zheng Cheng?, Rosemary Monahan, and James F. Power

Computer Science DepartmentNational University of Ireland Maynooth

Co. Kildare, Ireland

Abstract. Rodin is an open tool set for the Event-B modelling lan-guage. It provides both modelling and interactive theorem proving fa-cilities. In this work, we translate Rodin’s refinement proof obligationsinto the Boogie language. The goal is to provide a Design by ContractTM

view of an Event-B program. The new view allows the user to performautomated/interactive verification independently from Rodin and it isexpected to be user-friendly to both professional and non-professionalRodin users.

Keywords: Software Verification, Intermediate Verification Language,Formal Modelling, Refinement, Rodin, Event-B, Boogie

1 Introduction

To get a better understanding of the system under development, modelling canbe applied to define the system’s requirements, properties, to estimate cost etc.Successful modelling can ensure the high quality of the final product.

Event-B [17] is a state-based modelling language, based on the idea of re-finement calculus [19]. It provides a systematic approach to gradually model thesystem with a systematic reasoning method in the form of proofs. The Event-Blanguage has been applied to the design of non-trivial algorithms [28, 44], fault-tolerant systems and safety critical systems [23, 27].

The Rodin platform (Rodin) is an open tool set for the Event-B language,which integrates modelling and interactive theorem proving [18]. It supports therefinement calculus on models, and strives to minimise the impact of refinementon existing proofs. Generally, while modelling the system, development in Rodinneeds to ensure that changes in the system are feasible and well-justified. Italso needs to guarantee that the final refined system is never in a invalid state.For these purposes, Rodin generates Proof Obligations (PO) that need to bedischarged (i.e. proved valid).

? Funded by John & Pat Hume Scholarship and Doctoral Teaching Scholarship fromthe Computer Science Department of NUI Maynooth.

However, the POs generated from Rodin are rendered in a triptych style,where the domain of the problem and various properties of the system are in-tertwined. It is difficult for non-professional Rodin users to comprehend the POquickly. Moreover, Rodin display the POs differently to their definition, i.e. thesimplified (rewritten) POs are displayed. The simplification make the POs easierto be discharged. However, it can cause some problems when the Rodin usersreview the proof or prove interactively. Therefore, one of the goals of our workis to reconstruct the POs from Rodin in a more user-friendly way.

The Boogie2 language1 is an intermediate verification language [20, 40]. It isbased on Hoare logic [38] and follows the Design by Contract (DbC) style [46].The Boogie language allows the source program encoded in it to be discharged todifferent theorem provers (Z3 [47] by default). It also shows good performance invarious verification benchmarks [14, 54] and thus lots of verification tools involvethe Boogie language in their back-end [22, 33, 41, 53].

In this work, we focus on a class of POs from Rodin, i.e. refinement POsthat ensure the refinement in Event-B is correctly performed. We propose toreconstruct them as in the DbC style of the Boogie language. The translationis implemented in a generic translation framework for the Boogie language [31].The goal is to provide an alternative view of refinement PO, which allows theuser to perform automated/interactive verification independently from Rodin.

The alternative view is expected to be user-friendly to both professional andnon-professional Rodin users. Several facilities are designed in the frameworkto achieve our goal. In particular, a plug-in that allows a formula in Rodinserialised to XML format is designed. Also, a prelude for the Boogie language isimplemented to support the set-theoretic constructs of Event-B. The experimentperformed shows the feasibility of translating refinement POs to the Boogielanguage by applying our generic translation framework. Moreover, the generatedBoogie program preserves the automatic discharging rate of the refinement POsin Rodin. In addition, the translation can be applied to the POs other than therefinement POs.

Outline The rest of the paper is organised as follows. The background of thiswork is presented in Section 2. Section 3 illustrates the technical details of ourtranslation framework. The overall result is shown in Section 4. Then, we givea review of related work in Section 5. Finally, the future work and conclusion ispresented in Section 6.

2 Background

In this section we first summarise the refinement calculus as integrated intothe Event-B language. Then, we introduce Rodin, which is the tool support

1 Boogie is the name of a program verifier, and also the name of an intermediate verifi-cation language. To distinguish, from now on, we refer to the Boogie program verifieras the Boogie verifier ; we refer to the Boogie2 intermediate verification language asthe Boogie language, and we refer to the code written in Boogie2 language as theBoogie code or the Boogie program.

2

for Event-B. Next, the Boogie language is briefly illustrated, along with thediscussion of a generic translation framework for the Boogie language.

2.1 Refinement Calculus in the Event-B Language

The refinement calculus is a logic of framework that is used to reason aboutthe system being modelled. It concerns the correctness of a system, and pre-serving the correctness when making changes to the system [19]. There are twotechniques that can be used in refinement calculus: data refinement [49] andalgorithm refinement [36].

Data refinement techniques are concerned with changing the data represen-tation of the developed system (e.g. refining from sets to arrays). They canarise when the user wants to reduce the internal computational cost or changeto a more efficient data structure, whereas algorithm refinement techniques areconcerned with turning an abstract algorithm into an more easily implementedversion (e.g. stepwise refinement for computing cubes by addition [36]).

Event-B is a state-based modelling language, which is considered to be anevolution of the B language [51]. It takes refinement as its central concept, whereboth data refinement and algorithm refinement are supported. Initially, the usercan use the mathematical tools of Event-B (e.g. set theory, transition systemsand predicate calculus) to describe the system on an abstract level. Then, re-finement can be applied to gradually introduce the details and complexities intothe system. The last refinement is used to generate the executable code.

Figure 1 shows a snippet of the celebrity algorithm [5] in the Event-B lan-guage. The context and the machine are the basic constructs of an Event-Bprogram. A context introduces constants, carrier sets (i.e. user defined types),axioms and theorems. The axioms state the rules in terms of predicates andare un-condtionally accepted as true when developing the system. In addition,Event-B gives a type to a constant through an axiom (it has to be in the samecontext of the constant). Axioms can be marked as theorems. In this case, thetheorems are conditionally accepted as true if they can be proved by using theaxioms that have been declared beforehand (i.e. the order of declaring the axiomsand theorems matters). A context can be extended by an arbitrary number ofsub-contexts, such that all constants, carrier sets, axioms and theorems declaredin the base context are inherited.

A machine encapsulates variables, invariants (i.e. the predicates that shouldalways hold during the execution of the current machine) and events (i.e. meth-ods) for the modelling system. The variables’ types are given by an invariant. Thevariables’ values are initialised in a special event, namely INITIALZATION,and can be changed by events. Each distinct combination of the variables’ valuesconstitutes a unique state for the machine. A correct machine would ensure thatits states never violate any invariant at any time. An event can contain parame-ters, guards, actions and witnesses. The parameters are the inputs of an event.The guards of an event specify the conditions under which it can be executed.The actions of an event assign values to variables. The assigned value can be

3

CONTEXTCelebrity c0CONSTANTSkcPAXIOMSaxm1 : P ⊆ Naxm2 : c ∈ Paxm3 : k ∈ (P\c) ↔Paxm4 : k [c] = P ↔ caxm5 : k ∩ id = ∅END

MACHINECelebrity 1SEESCelebrity c0VARIABLESrQINVARIANTSinv1 : Q ⊆ Pinv2 : c ∈ QEVENTS...remove 1 : not extendedANYxyWHEREgrd1 : x ∈ Qgrd2 : y ∈ Qgrd3 : x 7→ y ∈ kTHENact1 : Q := Q\xEND...END

MACHINECelebrity 2REFINESCelebrity 1SEESCelebrity c0VARIABLESrRbINVARIANTSinv1 : R ⊆ Pinv2 : b ∈ Pinv3 : b /∈ Rinv4 : Q = R ∪ bEVENTS...remove 1 : not extendedREFINESremove 1ANYxWHEREgrd1 : x ∈ Rgrd2 : x 7→ b ∈ kWITHy : b = yTHENact1 : R := R\xEND...END

Fig. 1: Part of the Celebrity Algorithm in Event-B language. It introduces a context(a), two machine (b) and (c) for modelling the celebrity algorithm

.

deterministic (i.e. a concrete value can be found for this assignment), or non-deterministic (i.e. a predicate that describes the properties of a expected value,and it would be replaced by a concrete value during the refinement). In addition,a machine can refer to the constructs in any contexts by declaring those con-texts’ names in the sees section of the machine. If a machine is declared in therefines section of another machine, we say the first machine is being refined bythe latter one. In this case, the two machines establish a refinement relationship,

4

where we refer the first machine as the abstract machine and the latter machineas the concrete machine.

The last two constructs we discuss are called the gluing invariant and thewitness. They are related to refinement in Event-B. During a program derivation,we are often in a situation where we have an abstract (inefficient or unimple-mentable) variable in the machine, and we want to replace it with a concrete(efficient, implementable) variable. Event-B handles such circumstances by mak-ing the abstract variable into a ghost variable in the concrete machine, and usinga gluing invariant in the concrete machine to state the relationship between theghost variable and concrete variable. In this way, the feasibility of this replace-ment is shown by the gluing invariant and thus the ghost variable can disappearin the concrete machine. The witness can be declared in each event. A witnessis a mapping between the abstract parameter and the concrete parameter andallows the abstract parameter to be omitted in the concrete event.

2.2 Boogie Language

The Boogie language (a.k.a BoogiePL) is an intermediate verification language[20, 40]. The source program and its specification can be translated into theBoogie language (as in Spec# [22]), and then rely on Boogie to compute the POand to interact with theorem provers/SMT solvers (Z3 by default). Translationsinto Boogie language exist or are under way for several languages: Spec# [22],C [33], Dafny [41] and Eiffel [53].

A Boogie program follows the DbC style [46]. In contract-based formal ver-ification, a contract is given by the preconditions and postconditons, e.g. usingthe Hoare logic expressed in a specification language [37]. It states the respon-sibility between the caller and callee of the program. The precondition denotesa predicate that the caller must obey before calling the program, whereas thepostconditon denotes a predicate that the callee guarantees to return to thecaller. One approach to check if a program matches its contract is by checkingwhen the postconditon in the contract are established, whether the program’spreconditions can be satisfied by executing the program. The approach is usuallycalled the weakest precondition calculus and it is applied in the Boogie verifier[21].

The Boogie language is procedure-oriented and it is intended to be concise.The constructs in Boogie are fewer than in other high level languages. However,the existing constructs are expressive enough to model new behaviour outsidethe Boogie language, e.g. ownership [22] and concurrent behaviour [42, 8]. As abyproduct of the asymmetric translation (i.e. the translation is not one-to-onemapping) from a programming language to the Boogie language, there could bea certain degree of abstraction made during the translation process. In [39], it issuggested the translation should be with a soundness proof to ensure the validityof the abstraction (i.e. the verification result should determine the correctnessof the source program).

5

2.3 The Rodin Platform

Rodin is an Eclipse-based development environment for Event-B [18]. It is opensource and provides support for checking specification correctness and for refine-ment proofs. While constructing an Event-B program, Rodin will automaticallygenerate a set of POs for the program under consideration. Each PO is a logicalformula, whose validity implies that certain correctness properties are satisfiedby the program under consideration. In Rodin, the correctness properties in-clude:

1. The Event-B program is not in an invalid state (i.e. a state where someinvariant might not hold).

2. The behaviour of a concrete Event-B program will correspond to the be-haviour of its abstract program.

The first property is ensured by proving that the invariant is preserved and byproving the well-definedness of predicates [16]. The second one, i.e. the corre-spondence between abstract and concrete Event-B programs, is usually calledthe refinement PO, which will be the focus of our work.

There are three kinds of POs which can be generated from Rodin to ensurethat the refinement is correct [16]:

– Guard strengthening (GRD)

– Action simulation (SIM)

– Equality of a preserved variable (EQL)

For example, an action simulation PO ensures that each action in the concreteevent simulates the corresponding abstract action. This ensures that when aconcrete event is “executed”, it does is not contradict what the correspondingabstract event does.

Fig. 2: Proof Obligation Displayed in Rodin

6

Figure 2 shows a typical action simulation PO in Rodin. In the Rule Detailspanel, a PO is rendered in a triptych style, i.e. it takes the format of:

D ∧ S → R

where D stands for the domain of the problem, S stands for the model of thesystem and R stands for the requirements that should be satisfied by the system.But there is no intuitive way to further distinguish the domain of the problemfrom the model of the system in the POs displayed by Rodin. This is becauseeach PO is managed separately from the context and machine information. Inaddition, the predicates in Rodin might have been simplified in order to make aPO easier to solve by the program verifiers. Unfortunately, the original predicateis no longer presented in the proving perspective of Rodin. As a result, we thinkit is less user-friendly for both professional and non-professional Rodin users toperform interactive proof or review POs in Rodin.

2.4 A Generic Translation Framework for the Boogie Language

When developing the system in a model-driven environment, one may work withdifferent models to represent the same system, where each model is an abstrac-tion of the system from a certain perspective. A metamodel is an abstraction ofdifferent models, whose responsibility is to capture the meaning and commonal-ities in the models [25]. A model conforms to a metamodel if and only if it is aninstance of the metamodel, i.e. the essence of different models captured by themetamodel are presented in the given model.

In a previous paper, we propose a generic translation framework for the Boo-gie language [31] based on metamodelling. It is designed for systematically trans-lating any source languages to the Boogie language and ensuring the translationcorrectness. Currently, the tool support for the generic translation framework in-cludes the ATL [3] and Acceleo [1]. Both of them are open source project. ATL isa translation metamodel and is responsible for translation between metamodels.Acceleo is a code template engine, and is used for pretty printing the Boogiemodel to the Boogie code (i.e. giving a concrete syntax for the Boogie model.).

3 Technical Details

This section will describe the technical details of translating refinement POs ofRodin to the Boogie language. We will first describe our translation mechanism.A introduction to the Event-B language metamodel, along with a Rodin plug-in to generate the instance of this metamodel will then be illustrated. Next, wemove on to the encoding of the mathematical foundation of the Event-B languageinto the Boogie language, which will be used in the later translation. Then, theBoogie language metamodel is presented, accompanied by the description of apretty printer for the model instance of the Boogie language metamodel. Finally,we describe the translation from the refinement POs in Rodin to the Boogie

7

language in ATL. The concrete translation result can be found in Section 4.1.An overview of the translation is visualized in Figure 3. This work is a concreteimplementation of our proposed generic translation framework for the Boogielanguage (as described in Section 2.4): When an Event-B model is extractedfrom an Event-B program using a developed plug-in (Section 3.3), we use theATL to translate it into the Boogie model. The translation is performed againsta set of pre-defined translation rules. Each rule describes how the construct(s) inEvent-B language metamodel (Section 3.2) being mapped to the construct(s) inthe Boogie language metamodel (Section 3.5). The framework also provides anintermediate representation, called the Boogie extension metamodel, to assist thetranslation. It allows the user target this intermediate representation for reusinga set of predefined constructs that outside the Boogie language metamodel (e.g.the set theory as explained in Section 3.4). Eventually, the Boogie model ispretty-printed to the Boogie program(s) using Acceleo.

Fig. 3: An Overview of the Generic Translation Framework for the Boogie language

3.1 Translation Mechanism

Figure 4 outlines our translation mechanism. The basic need of our translationis to tie the refinement POs syntactically to the program specification so thatthere could be no doubt as to which program they are applied. Therefore, inour translation mechanism, for each refinement PO in the triptych style, thedomain of the problem (e.g. constants, sets, axioms and etc.) can be treatedas the preconditions in a program’s contract. The model of system is dividedin two parts: actions and non-action constructs. The actions are translated tothe statements in the program’s body. Each non-action construct is modeledas either a precondition (if the non-action construct is an invariant, an event’sguard or a witness) or an auxiliary construct (if the non-action construct is aevent’s parameter). Meanwhile, the goals (requirements), as in the triptych style,are mapped to the postconditons, which need to be discharged by the Boogieverifier. Moreover, we want to group all the refinement POs of the same event

8

into a single Boogie program, so that duplicate information does not need to berepeatedly displayed.

Refinement POs for an event APO1 : D1 ∧ S1→ R1PO2 : D1 ∧S1→ R2

Result Boogie programprocedure A(Tr[[S1]]) returns()requires Tr[[D1]];requires Tr[[S1]];ensures Tr[[R1]];ensures Tr[[R2]];{Tr[[S1]];}

Fig. 4: Translation Mechanism for Rodin’s Refinement PO. The function Tr[[X]] yieldsthe corresponding construct(s) in the Boogie language for a given Event-B constructX.

.

3.2 Event-B Language Metamodel

The source language metamodel is one of the essentials for the generic translationframework. In this section, we will describe how we obtain the source languagemetamodel, i.e. the Event-B language metamodel.

Rodin provides two metamodels designed for Event-B. One metamodel de-fines the structure of Event-B projects (structural metamodel). The other one de-fines Event-B’s formula (formula metamodel). Although the two metamodels arehighly dependent on each other, they are organised separately by Rodin. More-over, we found some inconsistencies between the Event-B’s formula AbstractSyntax Tree (AST) and Rodin’s formula metamodel. These inconsistencies willbecome an obstacle if people choose to generate the source language modelthrough the AST. Therefore, we decided to:

1. Reconstruct the formula metamodel from the Event-B’s formula AST.2. Make modifications on top of the pre-existing structural metamodel.3. Merge the metamodel (1) and (2) together.

It is simple to extract the formula metamodel from Event-B’s formula AST.We use the binding compiler (a.k.a XJC [12]) from the Java Architecture forXML Binding Library (a.k.a JAXB [13]) for this task. The modified structuralmetamodel is similar to the pre-existing one, except that the refinement POsinformation is also stored for each event. Merging two metamodels is relativelyeasy. We link the root of the formula metamodel with the elements in the struc-tural metamodel that can store the formula (e.g. the invariant, or the witness).The full metamodel can be accessed in [32].

9

3.3 Plug-in for Serializing Event-B Program

In order to systematically translate Rodin’s refinement POs to the Boogie lan-guage, we develop a plug-in for Rodin that can serialise the Event-B programinto a source language model (a XML-like file). The model will conform to theEvent-B language metamodel that is described in Section 3.2.

3.3.1 Event-B Program to Source Language Model Rodin organisesall the project’s information using a database [10]. This database is a set ofXML files that can be read/updated/created by using Rodin’s API. Therefore,we draw on Rodin’s API for instantiating an instance of the customised AST.The customised AST is a set of Java classes. It can be seen as a programmaticversion of our merged metamodel.

The task of instantiation can be done through Rodin’s API, except for thePOs generation. As described in Section 3.1, instead of the whole PO, we proposeto store only the goal part, where the first two pieces information are storedelsewhere. Therefore, we do not intend to read the POs directly from Rodin.

POs Generation When generating a refinement PO, we are concerned withboth the concrete and abstract machine. So, the first step of POs generation isusing Rodin’s API to synthesise them both. Then, depending on the type of PO,we generate a predicate that represents its meaning. To avoid meaningless PO,we apply the following filter strategy to reduce the size of the PO:

– A PO is filtered out if it is contained in its hypotheses list.– A PO is filtered out if it is a membership test on the Boolean set, i.e. whether

a element of type Boolean is in the Boolean set.

The hypotheses list of a PO is calculated according to the Rodin user’s handbookv2.7 [15]. For example, the GRD PO ensures that the guards of a concrete eventis stronger than the guards of the abstract event. It suggests a concrete eventmust only be enabled if the abstract event is enabled. According to Rodin user’shandbook, the hypotheses list for each GRD PO involves axioms of a concretemachine, invariants from both abstract and concrete machines, guards of theconcrete event and witnesses of the concrete event. Thus, it is trivial to prove aGRD PO if itself is already in its hypotheses list.

Notice the filter strategy in Rodin is different to ours: their predicate mightbe simplified (as illustrated in Section 2.3). A PO might not be filtered out byRodin even if it is trivial, since the simplified form is not in the hypotheses list.Our encoding does not simplify the goal, thus the filter is more aggressive thanthe one applied by Rodin. As a result, the POs generated from Rodin and fromour plug-in might not be the same. But the differences are justified. Furtherdetails on the issues caused by the different filter strategies can be found inSection 4.2.

The naming mechanism for all refinement POs is similar to the namingschema of Rodin. For example, for a concrete event evt and an action act inboth concrete and abstract events, the name of each Action simulation PO takethe format of: evt act SIM.

10

The generation of the refinement POs is located in the class ProofObliga-tionHelper under the package ie.nuim.cs.menu.popup.actions. We suggestthat other kinds of POs generation should be registered within the same classfor modularity.

Once we obtain an instance of customised AST, we use JAXB to serialiseit into source language model. To work with JAXB, we require the classes incustomised AST comply to the following rules:

– The serialised fields of the class must be annotated with JAXB’s XML seri-alisation annotation.

– The serialised class must have a private parameter-less constructor.

The product at this stage is the source language model corresponding to theinput Event-B programs2.

3.4 The Mathematical Foundation of Event-B

Set theory is part of the mathematical foundation of Event-B, which allows theuser to abstract the system in a rigorous and precise manner. However, a similartheory does not exist in the Boogie language by default. In this section, wedescribe how we encode set theory as a prelude of the Boogie language.

The prelude is an idiom for extending the expressiveness of the base language.It draws on the primitive constructs of the base language to formulate newfunctionalities that can be used systematically outside the base language. OurBoogie prelude encodes the definitions and operations of set theory according tothe mathematical toolkit manual of Event-B [48] to ensure their consistency.

We divide set theory into 3 encodings for clarity:

– Sets.– Relations.– Functions.

Our Sets encoding is built on top of a pre-existing Boogie prelude for theDafny language (see [4]), written by Leino and Summers. The pre-existing pre-lude introduces the definition for set and 10 operations on set(s). We extended itwith Event-B’s primitive set types, i.e. natural numbers, Boolean set and Integerset. We also add the proper-subset operation on sets, to express that a set issubset, but not equal to, another set.

Our Relations encoding introduces 4 types of relation and 17 operations onthe relations, along with 1 definition for pair and 4 operations on pairs. The twoencoding strategies we tried suggest that the relation should be encoded as aset of pairs, rather than a mapping between two set of elements (see Line 4 inListing 1.1). This preserves the genericity between relation and set. For example,encoding the relation as a set of pairs allows us to pass in a relation whenever an

2 Our plug-in is developed as a button in the project pop-up menu. Thus, all thecontexts and machines within the selected Event-B project will be serialised andmerged into a single source language model

11

operation expects a set, whereas the other encoding strategy would require us toencode a separate operation that specifically working on the relation. Listing 1.1shows a snippet of Relations encoding in the Boogie prelude. This encoding firstintroduces the definition for pairs and relations. Then it defines two operations onrelations (i.e. the domain and range function). The semantic of each operationis interpreted by the appropriate axioms. For example: the semantics of thedomain function is that if r is a relation between the sets D and R, then thedomain of r is the set of the elements of D that are related to at least oneelement of R by r.

Listing 1.1: Part of The Boogie Prelude for Relations

1 type Pair D R = [D, R] bool;

2 ...

34 type Rel D R = Set (Pair D R);

5 ...

67 function Rel#Domain <D, R>(Rel D R): Set D;

8 axiom (forall <D, R> r: Rel D R, _dom#obj: D ::

9 Rel#Domain(r)[_dom#obj] <==>

10 (exists _ran#obj: R, p: Pair D R ::

11 r[p] && p[_dom#obj , _ran#obj ]));

1213 function Rel#Range <D, R>(Rel D R): Set R;

14 axiom (forall <D, R> r: Rel D R, _ran#obj: R ::

15 Rel#Range(r)[_ran#obj] <==>

16 (exists _dom#obj: D, p: Pair D R ::

17 r[p] && p[_dom#obj , _ran#obj ]));

18 ...

Our encoding of Functions introduces 7 types of function and 1 operationon functions. Function is a restricted relation, where an element in the func-tion’s domain can map to at most one element of the function’s range. All theoperations on relations can be applied to functions.

Consequently, we extend the Boogie language with this prelude. This allowsthe translation to target both the default constructs of Boogie and auxiliaryconstructs defined in the prelude. The full prelude can be accessed in [32].

The Boogie prelude is part of our Boogie extension metamodel that any highlevel languages can directly translate to.

3.5 The Boogie Language Metamodel

The target of the generic translation framework is the Boogie language meta-model. In this section we will describe how we construct the Boogie languagemetamodel and how we use Acceleo to facilitate pretty printing an instance ofit.

12

We manually extract the Boogie metamodel from the parser of the Boogieverifier (see [4]). More specifically, each AST class creates a node in the meta-model, where its inheritance relationship is preserved. Each primitive field ofthe AST class creates a primitive field in the metamodel, whereas each non-primitive field of the AST class creates a containment relationship between thecorresponding nodes in the metamodel. The final Boogie metamodel is availableat [32].

As described at the beginning of this chapter, after the translation, a cor-responding Boogie model for the source Event-B model will be generated. Itwill conform to the Boogie metamodel. However, the Boogie verifier only takesa Boogie program as its input, which requires that we pretty-print the Boogiemodel to a Boogie program. We use Acceleo [1] for this task. Acceleo prints theinput model according to the given template. We organise all the templates inthe following way:

– The main template.

– The type template.

– The expression template.

– The statement template.

– The top-declaration template.

The classification is straightforward and the responsibility of each template issuggested by their names. The main template is the entry point of the Acceleoexecution. It will dispatch the pretty-printing task to the top-declaration tem-plate. The top-declaration template introduces how to print top-declarations likeaxiom, procedure, implementation etc. It will interact with the expression, state-ment and type template, which handles different Boogie expressions, statementsand types respectively. Running Acceleo with the main template will yield aBoogie program that corresponds to the input model.

To ensure that the designed Boogie metamodel will capture the essence of aBoogie program, we annotated the parser of the Boogie verifier with the XMLserialization library [7]. Then, we use the annotated parser to parse a Boogie pro-gram A3 into a model. Next, pretty printing the model yields a Boogie programB. We check that the two Boogie programs A and B yield the same verifica-tion result. In addition, two separate Boogie program are manually generated toensure A and B verify the same thing:

– the conjunction of A’s preconditions ⇐⇒ the conjunction of B’s precondi-tions.

– the conjunction of A’s postconditions ⇐⇒ the conjunction of B’s postcon-ditions.

As a result, we have confidence that the Boogie metamodel is correctly designed.

3 The candidate Boogie programs come from the test suites for the parser of Boogieverifier [4]

13

3.6 ATL Translation

Once we have the source and target language metamodel, we can use ATL toapply our translation mechanism that is described in Section 3.1.

In general, the ATL translation should be as complex as necessary, but assimple as possible. Therefore, the heavy computation should be done on theRodin platform, rather than leave it for the translation. For example, it is simpleto generate POs using the Rodin’s API (see Section 3.3.1), but the same task isrelatively hard to encode in ATL.

We organise the translation rules by their relativity in the source language,for example, all kinds of atomic expressions in Event-B are grouped together. Wealso give each translation rule a meaningful name for clarity. There are 109 rulesand 5 helper functions needed in the ATL template, to translate most of theEvent-B constructs into the constructs in the Boogie language metamodel (seeSection 3.5). Some of the rules directly target the Boogie prelude we illustratedin Section 3.4. The full mappings between the source and target language is listedin Appendix A. Next, we highlight some of the important translation decisions.

Predicate as Function We do not directly encode each predicate (e.g.invariant, guard or PO) as a precondition/postcondition in the Boogie language.Instead, we encapsulate each predicate within a Boogie function, and place it atthe call site of the predicate. Since a predicate might mention both the beforestate and after state of a variable, we need to distinguish the function’s argumentlist at the call site from the function’s parameter list at the function’s signature:a primed variable in Event-B means the after state of a variable. It is encodedas a primed variable in the function’s parameter list, but stays the same in theargument list. The variable that has the same name as a primed variable, butomits the prime symbol is in the before state of a variable. It stays the samein the parameter list, but is passed in as an old expression in the function’sargument list. For example, the invariant inv2:

inv2 : b ∈ P

of concrete machine Celebrity 2 in Figure 1 will be translated to a Boogiefunction:

function Celebrity 2 inv2 (P : Set int, b : int) returns (bool) {P [b]}

And at the call site, the above function will be replaced by the following functioncall:

Celebrity 2 inv2(P, b)

All the other variables are treated the same in both lists, unless the variableis an abstract parameter in the Event-B program. In this case the variable needsto be translated as a witness function at the call site. Recall that the witness isa special predicate that shows how an abstract parameter can be obtained fromthe concrete event. Since the abstract parameter is not defined in the concrete

14

event (but still be used), we decide to represent each abstract parameter inthe concrete event by a Boogie function. For example, the witness predicate forabstract parameter y:

y : b = y

in the event remove 1 of concrete machine Celebrity 2 in Figure 1c will betranslated to a Boogie function:

function Celebrity 2 remove 1 WitOf y (expr : int) returns (int) {expr}

And each occurrence of y in the concrete event will be replaced by the followingcall to the above function:

Celebrity 2 remove 1 WitOf y(b)

The implication of encapsulating the predicate as a function is threefold.First, we can preserve the format of a predicate (which is hard to achieve byplacing the predicate directly at the call site). Second, the encapsulated functioncan be repeatedly referenced at every occurrence of the same predicate. Third,the encoding can also enhance the readability of the resulting Boogie program.

Parallel Actions When executed, Event-B’s actions are running concur-rently [15]. This behaviour would implicitly suggest the right hand side of eachaction could only refer to the old state of variables. For example, in Event-B, wemight have a parallel actions like:

b :=a

a :=a+1

which would result in b having the old value of a, and a being incremented by 1from its old state. We model this concurrent behaviour as the parallel assignmentof the Boogie language, in which the right hand side of the assignment alwaysrefers to the old state of the variable. For instance, the statement:

x, y := y, x;

swaps the value of variables x and y in the Boogie language.Non-deterministic actions in Event-B are handled in a similar way. Only that

the intermediate variables are introduced first to hold the right hand side (i.e. thecondition) of the non-deterministic action, before they are added to the parallelassignment discussed above. For example, a non-deterministic action in Event-Bsuch as:

m : int | m′ = m + 1

will yield the following statements in the Boogie language:

var m′ : int;

assume (m′ == m + 1);

15

Then, a pair is added along with other parallel assignment pairs:

m := m′

Eventually, the result at this stage would be a translated Boogie model inXML format. It is ready to be pretty printed using the Acceleo template de-scribed in Section 3.5.

The final step is to run the generated Boogie programs, which we refer to asverification tasks. A refinement verification task is a combination of the Boogiecode for the machine of interest and its corresponding context(s). Manuallyconstructing the tasks can be time consuming. Therefore we design an extraAcceleo template to render the source language model into a batch file thatcontains the verification tasks [32].

4 Result

In this section, we first show the translation result. Then, we compare the per-formance between the Rodin’s default program verifier and the Boogie verifierfor refinement PO.

4.1 Translation Result

In this section, we illustrate how the Rodin’s refinement POs are translatedinto the Boogie language. The corresponding verification task for the Event-Bprogram in Figure 1 is shown in Listing 1.2. It contains the translated context(Figure 1a) and concrete machine (Figure 1c). The translation is in consistentwith the mechanism illustrated in Section 3.1, and the full translation can beaccessed on [32].

Listing 1.2: The Refinement Verification Task for Machine Celebrity 2 of Figure 1

1 const k : Rel int int;

2 const c : int;

3 const P : Set int;

45 axiom Set#Subset(P, NAT);

6 axiom P[c];

7 axiom Rel#isRel(k,

8 Set#Difference(P, Set#Singleton(c)),

9 P);

10 axiom Set#Equal(Rel#Image(Rel#Inverse(k),

11 Set#Singleton(c)),

12 Set#Difference(P, Set#Singleton(c)));

13 axiom Rel#Equal(Rel#Intersection(k, Rel#Identity ()),

14 Rel#Empty ());

1516 var r : int;

16

17 var R : Set int;

18 var b : int;

19 var Q : Set int;

2021 function Celebrity_2_inv1(P : Set int , R : Set int)

22 returns (bool)

23 {Set#Subset(R, P)}

2425 function Celebrity_2_inv2(P : Set int , b : int)

26 returns (bool)

27 {P[b]}

2829 function Celebrity_2_inv3(R : Set int , b : int)

30 returns (bool)

31 {!R[b]}

3233 function Celebrity_2_inv4(Q : Set int , R : Set int , b : int)

34 returns (bool)

35 {Set#Equal(Q, Set#Union(R, Set#Singleton(b)))}

3637 function Celebrity_2_remove_1_grd1(R : Set int , x : int)

38 returns (bool)

39 {R[x]}

4041 function Celebrity_2_remove_1_grd2

42 (b : int , k : Rel int int , x : int) returns (bool)

43 {k[x , b]}

4445 function Celebrity_2_remove_1_grd1_PO_GRD

46 (Q : Set int , x : int) returns (bool)

47 {Q[x]}

4849 function Celebrity_2_remove_1_grd2_PO_GRD

50 (Q : Set int , y : int) returns (bool)

51 {Q[y]}

5253 function Celebrity_2_remove_1_grd3_PO_GRD

54 (k : Rel int int , x : int , y : int) returns (bool)

55 {k[x , y]}

5657 function Celebrity_2_remove_1_WitOf_y(expr : int)

58 returns (int)

59 {expr}

6061 ...

62636465 procedure Celebrity_2_remove_1(x : int) returns ();

66 requires Celebrity_2_remove_1_grd1(R, x);

17

67 requires Celebrity_2_remove_1_grd2(b, k, x);

68 requires Celebrity_2_inv1(P, R);

69 requires Celebrity_2_inv2(P, b);

70 requires Celebrity_2_inv3(R, b);

71 requires Celebrity_2_inv4(Q, R, b);

72 modifies R;

73 ensures old(Celebrity_2_remove_1_grd1_PO_GRD(Q, x));

74 ensures old(Celebrity_2_remove_1_grd2_PO_GRD(

75 Q, Celebrity_2_remove_1_WitOf_y(b)));

76 ensures old(Celebrity_2_remove_1_grd3_PO_GRD(

77 k, x, Celebrity_2_remove_1_WitOf_y(b)));

7879 implementation Celebrity_2_remove_1(x : int) returns ()

80 {

81 R := Set#Difference(R, Set#Singleton(x));

82 }

8384 ...

As the result shows, line 1 to 14 translates the given context of Figure 1. Line16 to 82 shows the translation of the remove 1 event in Celebrity 2 machineof Figure 1. Each predicate in the specification is encapsulated in a separatefunction to enhance readability. We can see 2 guards, 4 invariants and 3 POsbeing generated in this way. The modifies clause is generated by the syntacticanalysis of the event’s body (i.e. the left hand side of each assignment clause).We separate the specification from the implementation in the Boogie languageto distinguish their responsibility.

Implication of Our Encoding The implication is that Rodin can nowdischarge the refinement POs through the Boogie verifier, which enhances theinteroperability between different platforms. Also, all the related informationis now split into verification tasks in the Boogie language, which captures theessence of the source Event-B programs. Each verification task is shown in aDbC style and provides the user with a different interactive proving experienceto Rodin. For example, in the Boogie language, it is easy to create a user-specifiedsub-goal by putting a predicate in an appropriate context (e.g. an assertion inthe method body). And if any predicate fails to prove, the user can draw on thetrace information from the Boogie verifier or examine the information from theverification task to prove the predicates validity interactively. By doing so, theuser can perform automated/interactive verification independently from Rodin,without going back and forth between the two different environments.

Therefore, we expect that encoding Rodin’s refinement POs in Boogie lan-guage would be user-friendly to both professional and non-professional Rodinusers when they are reviewing POs or performing interactive proofs.

18

4.2 Comparison Study

We perform the refinement POs translation on four Event-B programs. Theyare: the celebrity problem (Celebrity) [5], the celebrity problem seeded withfault (Celebrity2)4, the tree-structured file system (TSFS) [34] and the vehicleon-board controller for trains (VOBC) [52]. The generated programs are sent tothe Boogie verifier (version 2.2.30705.1126, with Z3 version 4.3.0). The setting forthe control group is based on the POs generated from the Rodin platform(version2.7). The verifiers for Rodin include the default newPP verifier, and two verifiersfrom the Atelier B (version 2.0.1) [2]: the ML and PP verifier. The verificationresult is summarised in Table 1.

Total GRD SIM EQLRodin Boogie Rodin Boogie Rodin Boogie Rodin Boogie

Celebrity 18/18 18/18 14/14 14/14 4/4 4/4 0/0 0/0

Celebrity2 19/23 19/23 12/14 12/14 6/6 6/6 1/3 1/3

TSFS 18/18 14/14 12/12 12/12 6/6 2/2 0/0 0/0

VOBC 14/14 8/8 0/0 0/0 14/14 8/8 0/0 0/0

Table 1: Verification Result from Rodin and Translated Boogie program. (The numbersindicated in each cell are the Verified PO/Total POs of this kind)

The table shows three interesting facts: First, Rodin generates 10 more SIMPOs than ours encoding (4 from TSFS, 6 from VOBC). By examining thesePO, we find they have one characteristic in common, i.e. these POs have takentheir simplified form, and the Rodin’s filter cannot filter them out because theyare not in their hypotheses list (see Section 3.3.1, also see bug report [9]). Ourencoding does not simplify the predicate, and thus can filter out such trivialcases from the PO list.

Second, all the generated refinement POs in the Boogie language preserve thedischarging rate from the Rodin platform. Moreover, there are some POs thatcannot be discharged by the newPP verifier of Rodin, and must be separatelydischarged by the ML verifier from Atelier B. But, the generated Boogie programhas no problem in verifying these POs at all (a detailed POs discharging resultcan be found in Appendix B). We suspect this is caused by the weakness ofRodin’s newPP verifiers [50, 6]. For example, the newPP verifier is sensitive tounnecessary hypotheses (because of the Davis Putnam algorithm [35] it uses),which may prevent newPP from finding a proof even when the PO obviouslyholds. On the other hand, Z3 which is used at the back-end of the Boogie verifier,can determine the minimal set of hypotheses that are required to prove a givengoal [47]. Therefore, it would be more resilient to the unnecessary hypotheses.

Third, we find that if not intentionally seeded, the EQL POs are rarelypresented. Each EQL PO is generated when a variable is contained in both the

4 The source code for the celebrity algorithm with seeded fault can be found in [11]

19

abstract and concrete machines, and needs to prove that the value of this co-existed variable stays the same after executing the concrete event if the concreteevent changes the variable’s value but the abstract event does not. In otherwords, the co-existed variable’s value cannot be changed in the concrete event ifit is not changed in the abstract event. In the future, we want to check the EQLPOs in the Boogie language by omitting the co-existing variable’s name fromthe modifies clause of the concrete event if we find the abstract event does notchange its value. Thus, any modification to the co-existed variable in the concreteevent will immediately yield an error of changing the value of an unmodifiablevariable, and can imply an unsuccessful refinement.

5 Related work

Many program verifiers choose to translate to the Boogie language for managingthe complex task of generating verification conditions and sharing its back end[22, 33, 41, 53]. These translations are usually designed for a specific source lan-guage, and are not intended to be reused by others. Also, they usually target theBoogie language directly, which involves a large amount of low-level details. Thegeneric translation framework we propose generalises the translation procedureto provide a reusable translation system. Users might find the Boogie extensionmetamodel helpful since it extends the expressiveness of the Boogie language byencoding a set of low-level details such as mathematical functions and auxiliaryaxioms.

In [43], Mentre et al. design the bpo2why tool that translates the POs fromthe B language to the Why3 intermediate verification language [26]. To ensurethe mathematical background of the B language is faithfully encoded in Why3,they translate each Why3 theorem into the Coq interactive proof system [24]and allow the axiomatic system’s consistency to be checked. Such a feature isnice but expensive to have, and we expect our encoding of the mathematicalbackground for the Event-B language will be checked for axiom consistency in asimilar way in the near future.

Event-B2Dafny [29] is the first tool we are aware of that translates Rodin’sPOs into the Boogie family. The target language Dafny [41] is a program ver-ification language. It translates to the Boogie language and discharges throughthe Boogie verifier. Part of set theory (the basic operations on set) is defined inDafny through a Boogie prelude. Since Dafny does not allow user-defined axioms(so as to prevent axiom inconsistency in the proof system), the rest of set theoryis introduced through data-types, methods, functions under classes in Dafny.

The experiments by Chalin [30] have shown that within a DbC static analysissystem, the majority (97%) of PO assertions are written in contracts ratherthan any other format (e.g. inline assertions). Thus, we think PO assertions incontracts tend to be easier to understand for programmers. Both [43] and [29] aremore focused on discharging the POs automatically. The structure of their POsis preserved as in the triptych style and are directly translated into the inlineassertions of the target language. In contrast, we observe the shortcomings of

20

reviewing Rodin’s POs in the triptych style, and decide to translate the Event-Bprograms along with the refinement POs into the Boogie programs of a DbCstyle. As a result of our translation mechanism, while we can discharge the POsautomatically, the user can also have an alternative view (which is independentfrom the source environment) of an interactive proof (when the POs cannotbe discharged) or review of the PO. Moreover, by design, DbC restricts theexpressiveness of assertions by requiring that they be executable. This restrictionin expressiveness has the effect on the generating run-time assertion checking inexecutable code, and thus allows it to be more easily adopted by industry atlarge [30].

6 Conclusion and Future Work

In this work, we used a generic translation framework [31] to translate the re-finement POs in Rodin to the Boogie language. The goal is to provide an DbCview of Rodin’s refinement PO. This alternative view allows the user to performautomated/interactive verification independent of Rodin and is expected to beuser-friendly to both professional and non-professional Rodin users. Several fa-cilities had been designed in the framework to achieve the goal. In particular,a plug-in that allows the formula in Rodin being serialised to XML format wasdesigned for translation to the Boogie language. Also, a prelude for the Boogielanguage was implemented to support mathematical theory of Event-B. The ex-periment result had shown the feasibility of translating the refinement POs to theBoogie language by using the generic translation framework. It also showed thatthe generated Boogie program can preserve the discharging rate of refinementPOs in Rodin.

To convince people that our encoding can be applied to other kinds of POsfrom Rodin, we apply the same translation mechanism to encode the invariantpreservation (INV) PO. The preliminary work already shows its feasibility oninvariant preservation PO. However, since the ghost variables and their gluinginvariants are implicitly indicated by Rodin, some of the INV POs must beproved interactively. One simple solution is to mimic the way we encoded thewitness. To do this, we will need to accurately calculate the ghost variables andtheir corresponding gluing invariants in the concrete machine.

The ML verifier for the Atelier B has a set of known weaknesses [6], forexample, not all set theoretical axioms are part of ML. More case studies areneeded to see how the generated Boogie program behave under these weaknessesof the ML verifier. And we are confident that our effort to date will be furtherconfirmed by the expansion of the case studies.

Mery and Singh designed the EB2C tool to convert Event-B program into Cexecutables [45]. A substantial amount of deterministic behaviour of the Event-Blanguage are considered. Because of the procedure-oriented nature of the Boogielanguage, we are planning to use the generated Boogie program to produceexecutable code for Event-B programs. Our focus will be complementary to theEB2C tool, to:

21

– Cover more behaviours of the Event-B language in the executable code.– Insert run-time checking for some of the POs (e.g. INV PO) in the executable

code.

By doing so, the robustness of the generated executable code will be enhanced,which is important in industrial application domains, such as medical, avionicsand automotive control.

Acknowledgements

We would like to thank K. Rustan M. Leino for discussing and providing valuableinsight for this work. Also, we appreciate informative answers given at Rodinuser mailing list by Thai Son Hoang and Laurent Voisin.

References

1. Acceleo, http://www.eclipse.org/acceleo/2. Atelier B, http://methode-b.com/update site/atelierb provers3. The ATL transformation language, http://www.eclipse.org/atl/4. Boogie source code, http://boogie.codeplex.com/5. The celebrity problem, http://handbook.event-

b.org/current/html/tut celebrity problem.html6. A description of program verifiers in Rodin, http://handbook.event-

b.org/current/html/atelier b provers.html7. The Microsoft XML serialization library, http://msdn.microsoft.com/en-

us/library/system.xml.serialization.xmlserializer.aspx8. Poirot, http://research.microsoft.com/projects/poirot/9. Rodin bug report 646: Inconsistent generation of SIM POs,

http://sourceforge.net/p/rodin-b-sharp/bugs/646/10. The Rodin database, http://wiki.event-b.org/index.php/Plug-in Tutorial11. The source code for the celebrity problem with seeded fault12. The Java Architecture for XML Binding Binding Compiler (XJC),

http://jaxb.java.net/2.2.4/docs/xjc.html13. The Java Architecture for XML Binding (JAXB), http://jaxb.java.net/14. VerifyThis: A collection of verification benchmarks, http://www.verifythis.org/15. Rodin user’s handbook v.2.7 (2012), http://handbook.event-b.org/current/html/16. Abrial, J.R.: Summary of Event-B proof obligations (2008),

http://www.docstoc.com/docs/7055755/17. Abrial, J.R.: Modeling in Event-B: System and software engineering. Cambridge

University Press (2010)18. Abrial, J.R., Butler, M., Hallerstede, S., Hoang, T.S., Mehta, F., Voisin, L.: Rodin:

an open toolset for modelling and reasoning in Event-B. International Journal onSoftware Tools for Technology Transfer Volume 12, Issue 6, Pages 447–466 (2010)

19. Back, R.J., von Wright, J.: Refinement calculus: A systematic introduction.Springer (1998)

20. Barnett, M., yuh Evan Chang, B., Deline, R., Jacobs, B., Leino, K.R.M.: Boogie: Amodular reusable verifier for object-oriented programs. Lecture Notes in ComputerScience Volume 4111, 364–387 (2006)

22

21. Barnett, M., Leino, K.R.M.: Weakest-precondition of unstructured programs. ACMSIGSOFT Software Engineering Notes Volume 31 Issue 1, 82 – 87 (2006)

22. Barnett, M., Leino, K.R.M., Schulte, W.: The Spec# programming system: Anoverview. Lecture Notes in Computer Science Volume 3362, 49–69 (2005)

23. Benaıssa, N., Cansell, D., Mery, D.: Integration of security policy into systemmodeling. Lecture Notes in Computer Science Volume 4355, 232–247 (2006)

24. Bertot, Y., Casteran, P.: Interactive Theorem Proving and Program Development.Coq’Art: The Calculus of Inductive Constructions. Springer (2004)

25. Bezivin, J.: In search of a basic principle for Model-Driven Engineering. UPGRADEVolume 5, Issue 2 (2004)

26. Bobot, F., Filliatre, J.C., Marche, C., Paskevich, A.: Why3: Shepherd Your Herdof Provers. In: Boogie 2011: First International Workshop on Intermediate Verifi-cation Languages (2011)

27. Cansell, D., Gibson, J.P., Mery, D.: Refinement: A constructive approach to for-mal software design for a secure e-voting interface. Journal of Electronic Notes inTheoretical Computer Science Volume 183, Pages 39–55 (2007)

28. Cansell, D., Mery, D.: Formal and incremental construction of distributed algo-rithms: On the distributed reference counting algorithm. Theoretical ComputerScience Volume 364, Issue 3, Pages 318–337 (2006)

29. Catano, N., Leino, K., Rivera, V.: The EventB2Dafny Rodin plug-in. In: 2nd Work-shop on Developing Tools as Plug-ins (TOPI) (2012)

30. Chalin, P.: Are practitioners writing contracts? Lecture Notes in Computer ScienceVolume. 4157, 100–113 (2006)

31. Cheng, Z.: A proposal for a generic translation framework for Boogie language.In: 26th European Conference on Object-Oriented Programming, PhD studentworkshop, PhD student workshop (2012)

32. Cheng, Z.: The source code repository for machine-checked refinement proof obli-gations of Rodin in Boogie2 language (2013), http://code.google.com/p/compiler-boogie/

33. Cohen, E., Dahlweid, M., Hillebrand, M., Leinenbach, D., Moskal, M., Santen,T., Schulte, W., Tobies, S.: VCC: A practical system for verifying concurrent C.Lecture Notes in Computer Science Volume 5674, 23–42 (2009)

34. Damchoom, K., Butler, M., Abrial, J.R.: Modelling and proof of a tree-structuredfile system. In: 10th International Conference on Formal Engineering Methods.Kitakyushu-City, Japan (2008)

35. Davis, M., Putnam, H.: A computing procedure for quantification theory. Journalof the ACM Volume. 7, Issue. 3, 201–215 (1960)

36. Dromey, G.: Program derivation: The development of programs from specification.Addison Wesley (1989)

37. Hatcliff, J., Leavens, G.T., Leino, K.R.M., Muller, P., Parkinson, M.: Behavioralinterface specification languages. ACM Computing Surveys Volume 44, Issue 3(2012)

38. Hoare, C.A.R.: An axiomatic basis for computer programming. Communicationsof the ACM Volume 12, Issue 10, 576 – 580 (1969)

39. Lehner, H., Muller, P.: Formal translation of bytecode into BoogiePL. ElectronicNotes in Theoretical Computer Science Volume 190, Issue 1, Pages 35–50 (2007)

40. Leino, K.R.M.: This is Boogie 2 (2008)41. Leino, K.R.M.: Dafny: An automatic program verifier for functional correctness.

Lecture Notes in Computer Science Volume 6355 (2010)42. Leino, K.R.M., Muller, P., Smans, J.: Verification of concurrent programs with

Chalice. Lecture Notes in Computer Science Volume. 5705, 195–222 (2009)

23

43. Mentre, D., Marche, C., Filliatre, J.C., Asuka, M.: Discharging proof obligationsfrom Atelier B using multiple automated provers. Lecture Notes in Computer Sci-ence Volume. 7316, 238–251 (2012)

44. Mery, D.: A simple refinement-based method for constructing algorithms. ACMSIGCSE Bulletin Volume 41, Issue 2, Pages 51–59 (2009)

45. Mery, D., Sing, N.K.: Automatic code generation from Event-B models. In: Pro-ceedings of the Second Symposium on Information and Communication Technol-ogy. pp. 179–188 (2011)

46. Meyer, B.: Applying ’design by contract’. IEEE Computer Volume 25, Issue 10, 40– 51 (1992)

47. de Moura, L., Bjørner, N.: Z3: An efficient SMT solver. Lecture Notes in ComputerScience Volume 4963, 337–340 (2008)

48. Robinson, K.: A concise summary of the Event B mathematical toolkit (2008)49. de Roever, W.P., Engelhardt, K.: Data refinement: model-oriented proof methods

and their comparison. Cambridge University Press (1998)50. Schmalz, M.: Rodin’s soundness bugs (2012)51. Schneider, S.: The B-method, an introduction. Palgrave (2001)52. Su, W., Abrial, J.R., Huang, R., Zhu, H.: From requirements to development:

methodology and example. In: 13th International Conference on Formal Engineer-ing Methods. Durham, United Kingdom (2011)

53. Tschannen, J., Furia, C.A., Nordio, M., Meyer, B.: Verifying Eiffel programs withBoogie. In: BOOGIE workshop (2011)

54. Vladimir, K., Muller, P., Shankar, N., Leavens, G.T., Wstholz, V., Alkassar, E.,Arthan, R., Bronish, D., Chapman, R., Cohen, E., Hillebrand, M., Jacobs, B.,Leino, K.R.M., Monahan, R., Piessens, F., Polikarpova, N., Ridge, T., Smans, J.,Tobies, S., Tuerk, T., Ulbrich, M., Weiss, B.: The 1st verified software competition,extended experience report. In: Formal Methods (2011)

24

APPENDIX

A ATL Translation

Table 2: Structural Constructs

Source(Event-B) Target(Boogie)

RefinementProofUnit N/AContext Program*Constant ConstantCarrierSet TypeConstructor + ConstantAxiom AxiomMachine ProgramVariable Global VariableInvariant Procedure’s PreconditionEvent Procedure + ImplementationParameter Formal DeclarationGuard Procedure’s PreconditionAction Assignment*: a constant is translated to unique constant in the Boogie lan-guage if it is within a partition expression of Event-B langauge.

25

Table 3: Formula Constructs - Predicate

Source(Event-B) Target(Boogie)

Tag

RELATIONAL PREDICATE

*EQUAL 101 ==Set#Equal(Set, Set): boolRel#Equal(Rel, Rel): bool

*NOTEQUAL 102 !=!Set#Equal(Set, Set): bool!Rel#Equal(Rel, Rel): bool

LT 103 <LE 104 ≤GT 105 >GE 106 ≥*IN 107 MapSelect

Functioncall*NOTIN 108 ! MapSelect

!FunctioncallSUBSET 109 Set#ProperSubset(Set, Set): boolNOTSUBSET 110 !Set#ProperSubset(Set, Set): boolSUBSETEQ 111 Set#Subset(Set, Set): boolNOTSUBSETEQ 112 !Set#Subset(Set, Set): bool

LITERAL PREDICATE

BTRUE 610 trueBFALSE 611 false

SIMPLE PREDICATE

KFINITE 620 N/A

UNARY PREDICATE

NOT 701 !

QUANTIFIED PREDICATE

FORALL 851 forallEXISTS 852 exist

MULTIPLE PREDICATE

KPARTITION 901 axiom

ASSOCIATIVE PREDICATE

LAND 351 &&LOR 352 ‖BINARY PREDICATE

LIMP 251 =⇒LEQV 252 ⇐⇒

26

Table 4: Formula Constructs - Expression

Source(Event-B) Target(Boogie)

Tag

NO TAG

FREE IDENT 1 typedIdentifierBOUND IDENT DECL 2 typedIdentifierBOUND IDENT 3 typedIdentifierINTLIT 4 LiteralSETEXT 5 Set#Singleton(Element): SetBECOMES EQUAL TO 6 AssignmentBECOMES MEMBER OF 7 Havoc+assumeStatmentBECOMES SUCH THAT 8 Havoc+assumeStatmentPREDICATE VARIABLE 9 N/A

BINARY EXPRESSION

MAPSTO 201 identifiersREL 202 Rel#isRel(Rel, Set, Set): boolTREL 203 Rel#isTotalRel(Rel, Set, Set): boolSREL 204 Rel#isSujectiveRel(Rel, Set, Set): boolSTREL 205 Rel#isTotalSujectiveRel(Rel, Set, Set): boolPFUN 206 Rel#isPartialFunction(Rel, Set, Set): boolTFUN 207 Rel#isTotalFunction(Rel, Set, Set): boolPINJ 208 Rel#isPartialInjection(Rel, Set, Set): boolTINJ 209 Rel#isTotalInjection(Rel, Set, Set): boolPSUR 210 Rel#isPartialSurjection(Rel, Set, Set): boolTSUR 211 Rel#isTotalSurjection(Rel, Set, Set): boolTBIJ 212 Rel#isBijection(Rel, Set, Set): boolSETMINUS 213 Set#Difference(Set, Set): SetCPROD 214 Rel#CartesianProductDPROD 215 N/APPROD 216 N/ADOMRES 217 Rel#DomainRestriction(Rel, Set): RelDOMSUB 218 Rel#DomainSubtraction(Rel, Set): RelRANRES 219 Rel#RangeRestriction(Rel, Set): RelRANSUB 220 Rel#RangeSubtraction(Rel, Set): RelUPTO 221 Set#GenBoundedSet(int, int): SetMINUS 222 -DIV 223 /MOD 224 %EXPN 225 N/AFUNIMAGE 226 Fun#Application(Rel, elem): elemRELIMAGE 227 Rel#Image(Rel, Set): Set

27

Table 5: Formula Constructs - Expression

Source(Event-B) Target(Boogie)

Tag

ASSOCIATIVE EXPRESSION

*BUNION 301 Set#Union(Set, Set): SetRel#Union(Rel, Rel): Rel

*BINTER 302 Set#Intersection(Set, Set): SetRel#Intersection(Rel, Rel): Rel

BCOMP 303 Rel#BackwardComposition(Rel, Rel): RelFCOMP 304 Rel#ForwardwardComposition(Rel, Rel): RelOVR 305 Rel#Override(Rel, Rel): RelPLUS 306 +MUL 307 *

ATOMIC EXPRESSION

INTEGER 401 intNATURAL 402 NATNATURAL1 403 NAT1BOOL 404 BOOLTRUE 405 trueFALSE 406 false*EMPTYSET 407 Set#Empty(): Set

Rel#Empty(): RelKPRED 408 N/AKSUCC 409 N/AKPRJ1 GEN 410 N/AKPRJ2 GEN 411 N/AKID GEN 412 Rel#Identity(): RelKBOOL 601 expr

QUANTIFIED EXPRESSION

QUNION 801 N/AQINTER 802 N/ACSET 803 N/A

UNARY EXPRESSION

KCARD 751 N/APOW 752 Set#PowerSetPOW1 753 Set#PowerSet1KUNION 754 N/AKINTER 755 N/AKDOM 756 Rel#Domain(Rel): SetKRAN 757 Rel#Range(Rel): SetKPRJ1 758 N/AKPRJ2 759 N/AKID 760 Rel#Identity(): RelKMIN 761 Set#Min(Set): intKMAX 762 Set#Max(Set): intCONVERSE 763 N/AUNMINUS 764 N/A

28

B Detailed POs result from Rodin and Generated BoogieProgram

Table 6: Tree-Structured File System

Rodin Boogie

FMCH01

mkdir/grd1/GRD AP APmkdir/grd2/GRD AP/ML APmkdir/act3/SIM AP FILTEREDcrt file/grd1/GRD AP APcrt file/grd2/GRD AP/ML APcrt file/act3/SIM AP FILTEREDmove/grd1/GRD AP/ML APmove/grd3/GRD AP APdelete/grd1/GRD AP APdelete/grd4/GRD AP APdelete/act4/SIM AP FILTEREDcopy/grd1/GRD AP/ML APcopy/grd9/GRD AP/ML APcopy/grd3/GRD AP/ML APcopy/grd5/GRD AP APINITIALISATION/act4/SIM AP FILTEREDFMCH03

copy/act4/SIM AP APcopy/act3/SIM AP APNote: AP is a shorthand for Automatically Proved by thenewPP verifier, and AP/ML for Automatically Proved by theML verifier.

29

Table 7: Vehicle On-Board Controller for Trains

Rodin Boogie

mode m4

INITIALISATION/act5/SIM AP FILTEREDVOBC transit acceptance passive/act4/SIM AP FILTEREDVOBC special transit availability/act3/SIM AP FILTEREDVOBC special transit one cab active/act3/SIM AP FILTEREDVOBC special do nothing availability/act3/SIM AP FILTEREDVOBC special states/act3/SIM AP FILTERED

mode m5

TRAIN mss change/act1/SIM AP APTRAIN mss change 1/act1/SIM AP APTRAIN mss change 2/act1/SIM AP APTRAIN mss change 3/act1/SIM AP APTRAIN mss change 4/act1/SIM AP APTRAIN mss change 5/act1/SIM AP APTRAIN atpm button depressed released 1/act1/SIM AP APTRAIN atpm button depressed released 2/act1/SIM AP AP

Table 8: The Celebrity Problem

Rodin Boogie

Celebrity 1

celebrity/act1/SIM AP AP

Celebrity 2

celebrity/grd1/GRD AP APcelebrity/grd2/GRD AP APcelebrity/act1/SIM AP APremove 1/grd1/GRD AP APremove 1/grd2/GRD AP APremove 1/grd3/GRD AP APremove 2/grd1/GRD AP APremove 2/grd2/GRD AP APremove 2/grd3/GRD AP APremove 2/grd4/GRD AP AP

Celebrity 3

INITIALISATION/act1/SIM AP APINITIALISATION/act2/SIM AP APremove 1/grd1/GRD AP APremove 1/grd2/GRD AP APremove 2/grd1/GRD AP APremove 2/grd2/GRD AP APremove 2/act2/SIM AP APcelebrity/grd1/GRD AP AP

30

Table 9: The Celebrity Problem with Seeded Fault

Rodin Boogie

Celebrity 1

celebrity/act1/SIM AP AP

Celebrity 2

celebrity/grd1/GRD* AP APcelebrity/grd2/GRD* Fail Failcelebrity/act1/SIM AP APremove 1/r/EQL* AP APremove 1/grd1/GRD AP APremove 1/grd2/GRD AP APremove 1/grd3/GRD AP APremove 2/grd1/GRD AP APremove 2/grd2/GRD AP APremove 2/grd3/GRD AP APremove 2/grd4/GRD AP AP

Celebrity 3

INITIALISATION/act1/SIM AP APINITIALISATION/act2/SIM AP APremove 1/grd1/GRD AP APremove 1/grd2/GRD AP APremove 1 act2/SIM* AP APremove 2/grd1/GRD AP APremove 2/grd2/GRD AP APremove 2/r/EQL* Fail Failremove 2/act2/SIM* AP APcelebrity/grd1/GRD* Fail Failcelebrity/b/EQL* Fail FailNote: * indicates the PO is effected by a seeded fault.

31