The Use of Rippling to Automate Event-B
Invariant Preservation Proofs
YuHui Lin
NI VER
S
E
R
G
O F
H
Y
TH
IT
E
U
D I
U
N B
Doctor of Philosophy
Centre for Intelligent Systems and their Applications
School of Informatics
University of Edinburgh
2015
Abstract
The use of formal method techniques can contribute to the production of more reliable
and dependable systems. However, a common bottleneck for the industrial adoption
of formal methods techniques is proof automation. To address the challenge of proof
automation, we aim to improve it by using automated theorem proving techniques. We
set one popular formal method technique as our working domain in this thesis, that
is, Event-B. More specifically, we target a family of proofs, i.e. invariant preservation
(INV) proofs, which can account for a significant part of the proofs that needs human
interactions.
We apply one of the most successful automated theorem proving techniques, which
is rippling, to improve the proof automation of Event-B INV POs. Rippling uses metalevel guidance to automate proofs, and it is in particular useful to develop proof patches
to recover proofs based on the meta-level guidance when proof attempts fail.
We are especially interested in the case when lemmas are required to recover failed
proofs. We combine a scheme-based theory-exploration system, i.e. IsaScheme, with
rippling to develop a proof patch for lemma discovery, i.e. ahLemma. In addition to
ahLemma, we also develop two proof patches to suggest case-splits and to simplify
the goal and hypotheses by rewriting. The combining use of rippling and these proof
patches can improve the proof automation of INV POs.
iii
Acknowledgements
First and foremost I offer my sincerest gratitude to my supervisors Alan Bundy, Gudmund Grov and Ewen Maclean. I feel myself extremely lucky to have all of you as my
supervisors, for your patience, mobilised support and exceptional supervision.
I am very grateful to Omar Montano-Rivas for his willingness to answer my many
questions about IsaScheme. I also want to thank Andrew Ireland and Paul Jackson for
their great suggestions and feedback in my PhD annual reviews. A special thank also
goes to Leo Freitas and Jim Woodcock for introducing me to the academic world in
my MSc thesis. I am also grateful to all the members of the DReaM group and the
AI4FM project for providing a stimulating and creative research environment.
I also want to thank the Centre for Intelligent Systems and their Applications
(CISA) group, School of Informatics and EPSRC for funding my PhD and making
the research presented in this thesis possible.
I would like to express my deepest and gratitude love to my family. I want to thank
my mother, XiuZhen Yao, and my father, XiaoSheng Lin, for their boundless love and
unconditional support. Without their support I would not have been able to start my
postgraduate study in the UK and then have this PhD opportunity. Finally I would
like to thank my beloved wife Lu Li for her endless love and giving me a beautiful
daughter.
iv
Publications
Parts of the chapter 4 and chapter 5 have appeared in Automated Reasoning Workshop
2011 [31], NASA Formal Methods 2012 [127] and IJCAR Workshop on Automated
Theory eXploration 2012 [128].
v
Declaration
I declare that this thesis was composed by myself, that the work contained herein is
my own except where explicitly stated otherwise in the text, and that this work has not
been submitted for any other degree or professional qualification except as specified.
(YuHui Lin)
vi
Table of Contents
1
2
Introduction
1
1.1
Background & Motivation . . . . . . . . . . . . . . . . . . . . . . .
1
1.2
Research Contribution . . . . . . . . . . . . . . . . . . . . . . . . .
2
1.3
Outline of Thesis . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
Literature Survey
5
2.1
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
2.2
Formal Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
2.2.1
Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
2.2.2
Formal Analysis and Verification . . . . . . . . . . . . . . . .
6
2.2.3
Formal Modelling and Reasoning . . . . . . . . . . . . . . .
8
Event-B . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10
2.3.1
Tools and Applications . . . . . . . . . . . . . . . . . . . . .
10
2.3.2
Modelling and Refinement . . . . . . . . . . . . . . . . . . .
10
2.3.3
A Challenge of Discharging Proof Obligations . . . . . . . .
11
2.4
Automated Theorem Proving . . . . . . . . . . . . . . . . . . . . . .
12
2.5
Rippling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
14
2.6
Patching Proofs . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16
2.7
Theory Formation and Theorem Discovery . . . . . . . . . . . . . . .
17
2.7.1
IsaScheme . . . . . . . . . . . . . . . . . . . . . . . . . . .
18
2.7.2
IsaCoSy . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19
2.7.3
Hipster . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19
2.7.4
HR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
20
2.7.5
MATHsAiD . . . . . . . . . . . . . . . . . . . . . . . . . . .
20
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
21
2.3
2.8
vii
3
Background
23
3.1
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
23
3.2
Event-B . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
23
3.2.1
Mathematical Modelling Language . . . . . . . . . . . . . .
23
3.2.2
Modelling Structure . . . . . . . . . . . . . . . . . . . . . .
24
3.2.3
An Example of an Event-B Model . . . . . . . . . . . . . . .
27
3.2.4
Proof Obligations . . . . . . . . . . . . . . . . . . . . . . . .
31
3.2.5
The Rodin Platform
. . . . . . . . . . . . . . . . . . . . . .
32
3.3
Curried and Uncurried Functions in Poly/ML . . . . . . . . . . . . .
33
3.4
Rippling and Proof Critics . . . . . . . . . . . . . . . . . . . . . . .
34
3.4.1
Strong and Weak Fertilisation . . . . . . . . . . . . . . . . .
35
3.4.2
Case Analyses Critic . . . . . . . . . . . . . . . . . . . . . .
40
3.4.3
Lemma Calculation and Lemma Speculation . . . . . . . . .
41
Isabelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
44
3.5.1
Frameworks and Structures . . . . . . . . . . . . . . . . . . .
44
3.5.2
Tactical Reasoning . . . . . . . . . . . . . . . . . . . . . . .
46
3.5.3
Event-B Proof Obligations in Isabelle . . . . . . . . . . . . .
47
3.6
IsaPlanner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
48
3.7
IsaScheme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
50
3.8
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
51
3.5
4
Applying Rippling and proof-patching Techniques
53
4.1
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
53
4.2
INV POs and Rippling . . . . . . . . . . . . . . . . . . . . . . . . .
55
4.2.1
INV POs as Inductive Proofs . . . . . . . . . . . . . . . . . .
55
4.2.2
Applying Rippling . . . . . . . . . . . . . . . . . . . . . . .
57
4.2.3
Heuristics for the INV POs Domain . . . . . . . . . . . . . .
59
Proof-patching Techniques . . . . . . . . . . . . . . . . . . . . . . .
60
4.3.1
A Profile of Types of Failures . . . . . . . . . . . . . . . . .
60
4.3.2
Skeleton Rewrite Patch . . . . . . . . . . . . . . . . . . . . .
63
4.3.3
Case Split Patch . . . . . . . . . . . . . . . . . . . . . . . .
69
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
77
4.3
4.4
5
Scheme-based Lemma Conjecturing
79
5.1
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
79
5.2
Overall Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
81
viii
6
7
8
5.3
Heuristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
83
5.4
LHS Construction . . . . . . . . . . . . . . . . . . . . . . . . . . . .
85
5.5
RHS Construction . . . . . . . . . . . . . . . . . . . . . . . . . . . .
89
5.6
Instantiation using the Dynamic Seeding Pool . . . . . . . . . . . . .
96
5.7
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
Implementation
103
6.1
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
6.2
Design and Architecture . . . . . . . . . . . . . . . . . . . . . . . . 104
6.3
Implementing the proof-patching Techniques . . . . . . . . . . . . . 106
6.3.1
Invoking IsaScheme . . . . . . . . . . . . . . . . . . . . . . 106
6.3.2
Proof-patching Techniques as Reasoning Technique . . . . . . 109
6.3.3
Combining Proof Patches with Rippling . . . . . . . . . . . . 110
6.4
Pre-processing Event-B INV POs . . . . . . . . . . . . . . . . . . . 111
6.5
Running POPPA in IsaPlanner . . . . . . . . . . . . . . . . . . . . . 116
6.6
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
Evaluation
119
7.1
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
7.2
Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
7.3
Effectiveness Analysis . . . . . . . . . . . . . . . . . . . . . . . . . 123
7.3.1
The Effectiveness of the Rippling Guidance . . . . . . . . . . 125
7.3.2
The Effectiveness of the Proof-patching Techniques . . . . . . 126
7.4
Comparing with the Lemmas in Manual Proofs . . . . . . . . . . . . 129
7.5
Comparing with the Lemmas from the List Theory . . . . . . . . . . 132
7.6
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
Related Work & Future Work
137
8.1
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
8.2
Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
8.2.1
Theory Formation for Lemma Discovery . . . . . . . . . . . 137
8.2.2
Automatic Provers in Rodin . . . . . . . . . . . . . . . . . . 139
8.3
Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
8.4
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
ix
9
Conclusions
153
9.1
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
9.2
Revisiting Our Hypothesis . . . . . . . . . . . . . . . . . . . . . . . 153
9.3
Concluding Contributions . . . . . . . . . . . . . . . . . . . . . . . . 154
9.4
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
A Mathematical Notations
157
A.1 Event-B Notations . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
A.2 Isabelle Notations: . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
B A Lattice for the Relations-based Datatype Constructors
159
C Default Wave-rules in RippleINV
161
D Glossary
167
Bibliography
171
x
Chapter 1
Introduction
1.1
Background & Motivation
With significantly increasing computational power, hardware and software systems
grow in scale and functionality, as well as complexity. This growth brings about a
greater possibility of catastrophic system failures, which may lead to loss of money
or even human lives. Formal methods are rigorous, mathematics-based techniques
to verify hardware and software systems. Applying formal methods techniques can
contribute to the production of more reliable and dependable systems. According to
Woodcock et al’s recent survey of the industrial use of formal methods [168], 92% of
the industrial responders reported that the use of formal methods improved the quality
of their products.
One approach to use formal methods is to integrate formal methods techniques
into the development process so that the developer can formally model target systems,
and reason about the systems by means of mathematical proofs. In such formal development processes, developers use the mathematical modelling language provided
by a formal methods technique to capture requirements in an abstract formal model,
and then stepwise refine the model in a final product. At each step of development,
designers verify that the specification can still holds by discharging proof obligations
(POs) which are mathematical formulas to be proven. Most of these POs can be discharged automatically by the related supporting tool of the formal methods technique.
The remaining small proportion of the POs have to be discharged interactively. The
activity of interactively discharging these POs needs expert experience, and is still
time-consuming even with such expertise. Moreover, in industrial applications, even
1
2
Chapter 1. Introduction
this small proportion can be thousands due to the huge numbers of the POs. For example, in the Line 14 of Paris Subway project there are 27,800 POs, 8.1% (around 2250)
of which requires interactions [3], and in the Shuttle at Roissy Airport project there are
43,610 POs, 3.3% (around 1424) of which requires interactions [3]. To interactively
prove the POs in the first case takes 7.1 Man-Month, and 4.6 Man-Month in the second
case [3]. Therefore, proof automation becomes a challenge for all the formal methods
techniques that are applied in the approach.
To address the challenge of proof automation, we aim to improve it by using an
automated theorem proving technique. We set one popular formal methods technique
that can be applied in the approached discussed above as our working domain in this
thesis, that is, Event-B [6]. More specifically, we target a family of Event-B POs called
invariant preservation (INV) POs which can account for a significant part of all of the
POs that need interactive proofs. For example, in one Event-B case study 1 , 80% of
POs with interactive proofs are INV POs.
We apply one of the most successful automated theorem proving techniques, which
is Rippling [30], to improve the proof automation of Event-B INV POs. Rippling uses
meta-level guidance to automate proofs, and it is in particular useful to develop proof
patches to recover proofs based on the meta-level guidance when proof attempts fail.
We are especially interested in the case when missing lemmas are required to recover
rippling. Our proof patch for discovering the missing lemmas is developed on the top
of the theory-exploration system, IsaScheme [142]. Theory-exploration systems are
tools to automate mathematical discovery processes including the invention of definitions, conjectures, theorems, examples, counter-examples, problems and algorithms
for solving these problems. Our hypothesis in this thesis is:
Combining rippling with its proof-patching mechanism, in particular the
scheme-based lemma conjecturing proof patch, can contribute to a significant improvement of proof automation for the INV POs in the Event-B
domain.
1.2
Research Contribution
In summary, the main contributions of this thesis are
1 Available
in http://deploy-eprints.ecs.soton.ac.uk/128/
1.3. Outline of Thesis
3
• We illustrate that rippling is applicable to Event-B INV POs. We show that
the meta-level guidance of rippling is effectiveness for Event-B INV POs, by
evaluating the interactively proved INV POs from 12 existing, third-party case
studies. The result shows that when rippling successfully terminates, a majority
of the INV POs (around 77%) can be proved automatically.
• We combine rippling and the theory exploration system, i.e. IsaScheme, to develop a proof patch for the purpose of lemma discovery. This proof patch can be
used to produce lemmas to recover failed proofs, and can conjecture a reasonable number of lemmas which are similar to the ones inserted interactively by
humans.
• We develop two proof patches to suggest case-splits and to simplify the INV
PO for rippling by rewriting. These two proof patches and the lemma discovery
proof patch are effective and essential to recover rippling for INV POs in EventB.
1.3
Outline of Thesis
The organisation of this thesis is as follows:
Chapter 2 - Literature Survey: We give an overview of formal methods techniques,
and introduce Event-B. We also summarise automated theorem proving techniques. In particular, we discuss the work regarding rippling, proof-patching
techniques and the theory exploration systems.
Chapter 3 - Background: We present the background materials to give more technical details of Event-B and rippling. Also we present the systems on which our
work is based, i.e. Isabelle [149], IsaPlanner [64, 65] and IsaScheme [142].
Chapter 4 - Applying Rippling and Proof-patching Techniques: We show that rippling is applicable to INV POs with examples. We illustrate the framework of
applying rippling together with proof-patching mechanisms for the INV POs.
Also we present our proof patches to suggest case splits and to suggest a new
embedding by rewriting both the goal and the hypothesis which is embedded in
the goals.
4
Chapter 1. Introduction
Chapter 5 - Scheme-based Lemma Conjecturing: We present a lemma discovery
proof patch, which is called ahLemma. ahLemma is developed based on the
scheme-based theory exploration system, i.e. IsaScheme, which is used to synthesise missing lemmas using the meta-level guidance of rippling and several
heuristics.
Chapter 6 - Implementation: We present how to export the INV POs from Rodin
to IsaPlanner based on the work by Schmalz [158], as our proof patches and
rippling are implemented in IsaPlanner. We also give the implementation details
for using rippling together with our three proof-patching techniques as a proof
technique, which is POPPA (Proof Obligation Proofs Patched Automatically)2 ,
to automate INV POs. We then show how to apply POPPA to the INV POs in
IsaPlanner.
Chapter 7 - Evaluation: We describe the experiments that we ran to verify the hypothesis of this thesis by evaluating the implementation of POPPA. The evaluation set we adopt is a set of INV POs from various Event-B case studies which
is disjoint from our development set.
Chapter 8 - Related Work & Further Work: We present the related work regarding the use of theory exploration systems in lemma discovery. Also we discuss
some directions for future work.
Chapter 9 - Conclusions: We summarise the work in this thesis, and the contribution
we have achieved.
Appendix: There are four appendixes. Appendix A provides the definitions for the
operators in the Event-B mathematical modelling language. Appendix B shows
a lattice for a family of Event-B operators. The default rewrite rules of rippling
in our systems are given in Appendix C. A glossary is available in Appendix D.
Our work involves two proof notations for proofs, i.e. the Isabelle notations and the
Event-B notations. To avoid confusion, we mainly use the Event-B one in this thesis,
and we will make a note of the use of the Isabelle notions when appropriate.
2 Thanks
Alan Bundy for suggesting this acronym.
Chapter 2
Literature Survey
2.1
Introduction
We first discuss the motivation of the use of formal methods in the development of software and hardware systems. The descriptions of available formal methods techniques
are given in §2.2. In §2.3, we discuss a more specific formal methods technique, i.e.
Event-B [6], with which we are working. In particular, we highlight the main challenge
for the industrial use of Event-B, i.e. proof automation. In §2.4 we introduce automatic
theorem proving which can be used to address this challenge, followed by an introduction of a theorem proving technique called rippling [30] on which our work is based in
§2.5. In §2.6 we survey the proof-patching techniques used to recover failed rippling
proof attempts. In §2.7 we discuss the techniques for theorem discovery which can
contribute to proof automation. A summary is given in §2.8.
2.2
2.2.1
Formal Methods
Motivation
Software and hardware systems can fail in dreadful ways leading to catastrophic loss
of money and even human lives. There are also less serious, but still significant failures
which we’d like to cure. The errors introduced during system development are becoming the most serious culprit of such failures [40]. For instance: in the Smart Response
Technology (SRT) algorithm, the Pentium FDIV bug [146] in P5 Pentium processors
was introduced by a programming error. Intel Corporation spent 475 million dollars
to recall these processors in 1995. The interlock software of the radiation therapy ma5
6
Chapter 2. Literature Survey
chine, called Therac-25, failed due to a race condition [126]. The failures resulted
in overdosing at least six patients 100 times the intended dose, killing two between
1985 and 1987. More recently, the software bugs in Toyota’s electronic throttle control
system were proved to be the cause of the infamous unintended acceleration problem
[13], which resulted in recalls of at least 9.9 million cars world-wide and even loss of
37 lives from 2001 to 2010 [87].
In [95], Holloway argued that the approach of using mathematical analysis during system development can contribute to more reliable systems. Formal methods
follow this mathematical approach. They are rigorous mathematical techniques for
specifications, designs and verifications of software and hardware system development
[2, 39, 114]. The combination of formal methods and traditional testing techniques
can deliver higher quality systems with dependability and reliability [75]. According
to Woodcock et al’s recent survey [168], formal methods have been applied to various
domains, e.g. transportation, defence, financial and consumer electronics, and 92% of
all cases reported improvements in product quality.
We will survey some recent techniques in the formal methods area. For the early
work in this area, we refer to Jones’s survey [115], which includes some notable work,
such as Turing’s proof of a factorial routine [162], Floyd’s assertion annotation on a
flow-chart diagram [74] and Hoare’s axiomatic system [93].
2.2.2
Formal Analysis and Verification
Program analysers and Verifiers
Static analysis is an analysis of runtime properties of the programs without executing
them. One important use of static analysis is to eliminate unexpected runtime errors,
e.g. uncaught exceptions and race conditions. Such errors usually lead to system
crashes. Some early influential tools are LINT [119] and FINDBUGS [98]. However, these tools are unsound, therefore they cannot provide rigorous guarantees. Subsequently, a family of static analysis techniques with soundness has been developed
based on the abstract interpretation frameworks [55, 56]. Abstract interpretation abstracts a superset of all the possible traces of the target program as an abstract domain.
The behavioural properties of the target program are preserved in the abstract domain.
Abstract interpretation verifies the desired properties of a target program in the abstract
2.2. Formal Methods
7
domain to get approximate conclusions. Some examples of industrial applications of
abstract interpretation based static analysers are: the use of Astrée [21] in verifying the
Airbus electric flight control [60]; and the use of the C Global Surveyor in verifying
the Mars Path-Finder [144]. More related tools and applications are available in the
survey [66].
Apart from the static analysis, another trend of program verification is annotation
based program verifiers. Basically, properties are specified with annotations in the
code and theorems (or verification conditions) are generated to prove that the program
satisfies the specification. The annotations can be assertions, pre/post conditions, invariants, etc.
A notable early work is Hoare logic [93, 74], which is also known as Floyd-Hoare
logic or Hoare rules. Some recent work of the annotation based program verification
techniques are Spec# [12] for C# program, ESC/JAVA2 [43] for Java program, VCC
[50] for concurrent program in C program, Dafny [123] for .Net programming platform and SPARK [11] for Ada. Assertions can also be used to assist testing. The
related techniques are called assertion-based testing. An example of such techniques
is Quickcheck [45] that can generate test cases to attempt to falsify the assertions which
are written by programmers to specify the logical properties of programs.
Model Checking
Model checking is another branch of formal verification. It relies on building or generating finite state machines for target systems, and then exhaustively searching the finite
state space to check the desired properties [47]. The advantages of model checking are:
it is a fully automated technique to check properties; and counter-example execution
traces can be raised for diagnosis, when desired properties are not satisfied.
A major problem of model checking is the explosive number of states generated
in complex systems, which is known as the state explosion problem. Some main approaches to address the problem are: to represent states symbolically using ordered
binary decision diagrams [35, 137]; and to reduce the size of state space by abstraction.
Another approach to avoid the state explosion problem is called bounded model
8
Chapter 2. Literature Survey
checking [20]. Instead of searching the complete state space, it attempts to refute the
desired properties only within a bounded state space. The bounded state space is constrained by limiting the steps of the execution traces to a given depth. This technique is
not conclusive because it may fail to refute properties in the bounded state space. That
is, systems might or might not hold the desired properties, because a counter-example
might exist outside of the bounded states.
Model checking techniques have been mainly applied in hardware and protocol
verification [48]. Some notable projects are: verifying the cache coherence protocol of
the IEEE Futurebus+ Standard 896.1-1991 [129]; formally checking the entire control
protocol of Philips stereo components [17]; and the use of model checking in verifying
the International Telecommunications Union ISDN User Part Protocol in the NewCoRe Project [44].
Models can also be used to assist testing. Model-based testing [163] is such an
example of the use of formal methods in testing. This technique starts with a formal
model, which describes the desired behaviours or properties of the implementation under test, and then generates test cases to test if the implementation is compliant with
this model. Some examples are Labelled Transition Systems [161] for concurrent systems, Spec Explorer [164] for C# programs and UPPAAL [121] for real time systems.
A survey of formal methods assisted testing is in [90].
2.2.3
Formal Modelling and Reasoning
A branch of formal methods techniques provides a comprehensive approach to model
and reason about target systems from the beginning stage of development process,
i.e., requirement and design. These techniques provide mathematical specification languages to describe the target systems, and provide mathematical analysis to reason
about systems’ validity and desired properties. Note that in the context of these formal
methods techniques, the word ‘modelling’ is interpreted as building a specification
with the mathematical specification languages, rather than as a formalisation of the
target system as a finite state machine in the model checking area. In this context,
the ‘model’ is the outcome specifications, i.e. formal specification. Note that word
‘model’ here is also different from the one used in model theory which is a general
theory of interpretations of axiomatic set theory. A ‘model’ in model theory is a math-
2.2. Formal Methods
9
ematical structures obeying axioms.
These techniques can be categorised by specifying systems from different aspects.
Process calculi are tools used to provide descriptions to specify systems from the interaction aspect, as well as algebras laws for mathematical analysis. They are particularly
useful to specify and reason about behaviours of communication and synchronisation
between agents and processes in concurrent systems. Some popular techniques are
Communicating Sequential Processes(CSP) [94], Calculus of Communicating Systems
(CCS) [139] and the π-calculus [141].
There are also formal methods techniques to specify systems from the state aspect.
These languages use invariants to constrain all the states of the target system, and adopt
pre-conditions and post-conditions to define the states before and after a system operation is executed. Some examples of such formal methods techniques are the B method
[2], Event-B [6], VDM [114] and the Z notation [167]. Code generation techniques
are available to automatically generate code from the models of these formal methods
techniques, e.g. generating JML [122] annotations from Event-B specifications [69];
generating Ada [16] programs from formal specifications of the B method [4, 42].
Some examples of industrial applications of the state-based formal methods languages are: the use of VDM in the development of the Central Control Function Display Information System which is a part of the new air traffic management system for
London’s airspace [83]; applying Z notation to formalise parts of IBM’s Customer Information Control System which is an online transaction processing system [97]; the
use of Z notation in the project of an Air Traffic Control system, i.e. iFACTS [102];
the use of the B method in the railway project of Line 14 of the Paris Métro [15]; and
the use of Event-B in formalising the Instruction Set Architecture of the XCore microprocessor [169].
In the survey [168] of the current industrial use of formal methods, the specification
and modelling techniques used at the design stage were rated as the most-used formal
methods techniques among all. We will continue to review work for the Event-B in the
next section, as Event-B is at the heart of this thesis.
10
Chapter 2. Literature Survey
2.3
Event-B
Event-B [69] is a state-based formal method used to model and reason about systems.
Systems are described in an event-based approach, where the states of the systems
transit from one to another when an event occurs. Examples of events to trigger state
transitions are system operations and user inputs.
2.3.1
Tools and Applications
To provide supports for modelling and mathematical analysis, an integrated development environment (IDE), called Rodin [5, 7, 36, 51], has been developed. Rodin is an
extensible open source tool, and many plug-ins have been developed to facilitate the
use of Event-B in different stages of system development process. For instance, UMLB [159] provides a ‘UML-like’ graphical front end; Tasking Event-B [68] supports the
code generation of multi-tasking Java, Ada, and OpenMP C code from Event-B specifications; and AnimB features the animation support for testing. The complete list of
available plug-ins is available in [73].
Case studies have been developed to demonstrate the industrial use of Event-B, e.g.
developing the Mondex smart card electronic cash system [38]. Also, several industrial
partners of the DEPLOY Project [61] used Event-B and Rodin on deployment projects,
e.g. developing a cruise control system and a start-stop system in Bosch, and analysing
the business choreography mode in SAP [62]. In the rest of this section, we will show
the approach to develop Event-B models.
2.3.2
Modelling and Refinement
To develop an Event-B model, developers start with an abstract model capturing requirements, and then step-wise refine it towards a concrete model until final products
have been achieved. At each step of development, designers verify the specification
by discharging proof obligations (POs) which are mathematical formulas to be proven.
We will come back to discuss the challenge of discharging POs in the coming section.
This step-wise modelling strategy is called refinement. Refinement allows developers
to add new requirement features and design details to a model steps by steps.
There are two types of refinement steps which are categorised by their purposes:
2.3. Event-B
11
horizontal (or feature augmentation) and vertical refinements (or structural refinement) [132]. In horizontal refinement, new requirement features and functionalities
are introduced to the refined model; whereas in vertical refinement the abstract parts
are refined into a concrete one with more design details, e.g. replacing a set datatype
with an array.
Two extreme directions of achieving refinement are the rule-based style and the
posit-and-prove style. The rule-based style provides transformation rules for which the
validity has been verified, and developers can only used these pre-defined rules to refine
models. A notable example using this style is [143], where a set of basic refinement
transformation rules were introduced. The posit-and-prove style offers more flexibility
for developers to post their refined model, but developers now need to prove the refined
model is a valid refinement step by discharging POs. Event-B adopts the posit-andprove style refinement. Although refinement is a very important aspect of Event-B,
our work focuses on the challenge of automatically discharging POs which is covered
in the coming section.
2.3.3
A Challenge of Discharging Proof Obligations
POs are generated during modelling for developers to reason about their choices of design. A majority of these POs can be discharged automatically with the support tools,
i.e., the Rodin built-in and plug-in theorem provers. For those POs which the support
tools fail to automate, it can either be the case that the Event-B model is incorrect, or
the case that the provers is not powerful enough to discharge the POs. For the former case, a technique called reasoned modelling critics [105], has been developed to
address this problem. By analysing and abstracting failed proofs, this technique turns
the failures into high level modelling suggestions, leading to successful proofs. In this
project, we focus on the latter case, where the models are correct and more powerful
proving techniques are needed.
Human interaction is then required to discharge these remaining POs, which can
be very expensive due to the need for expert experience and is also time-consuming
even with such a expertise. This problem is not limited to Event-B, but for any formal methods techniques which uses the posit-and-prove refinement style, e.g. VDM.
Moreover, the interactively proved POs can be thousands due to the huge numbers of
12
Chapter 2. Literature Survey
the POs in industrial cases. Therefore, proof automation has become a challenge for
the use of formal techniques in industry.
Techniques have been developed to address this challenge from two aspects, i.e.,
the modelling aspect and the proof aspect. From the modelling aspect, proof automation can be improved by revising the current model of which POs can be simplified
and then discharged automatically.From the proof aspect, on the other hand, those
techniques accept non-trivial POs and try to discharge them directly. One example of
such techniques from the proof aspect is Isabelle for Rodin [158]. It translates Event-B
models and POs to an external theorem prover, i.e. Isabelle [149]. and takes advantage of the proving power of Isabelle to discharge more POs. Although the techniques
from different aspects are addressing the challenge with different approaches, they are
complementary to each other. In this project, we develop our techniques from the
proof aspect. In the next section, we will discuss the background and techniques in the
theorem proving domain.
2.4
Automated Theorem Proving
Automated theorem proving is a research area: describing how conjectures, which are
unproven propositions, entail the given axioms with inference rules in mathematical
logical systems, e.g. propositional calculus and predicate calculus. Automated theorem proving techniques can be applied to discharge POs raised in the formal methods techniques. In this section, we discuss the work of automated theorem proving
techniques, followed by a discussion of some real applications of automated theorem
proving techniques.
During the 1920’s and 1930’s, the fundamental concepts and techniques in the automated theorem proving domain were established, e.g. Gödel’s Completeness Theorem
[78], Gödel’s Incompleteness Theorems [79], Decidability, Skolem Normal Form, Herbrand’s Theorem [89], Sequent Calculus [76] and the Cut-Elimination Theorem [76].
Based on those foundations, automated theorem proving techniques were developed. In 1957, Newell et al. reported experiments with a heuristic-based problem
solving system, called the Logic Theory Machine [145], to produce proofs in propositional calculus. Two years later, Dunham, Fridshal and Sward published their work of
2.4. Automated Theorem Proving
13
a proof method that first uses a systematic approach instead of a heuristic one [67].
Apart from the work in propositional calculus, progress was also made in predicate
calculus. In 1960, Gilmore made an early attempt to automate proofs for simple theorem of first-order logic [77]. Around the same time, a similar system was reported
in [152]. In 1965, an influential technique, called resolution [154], was invented by
Robinson. Its central idea is to transform a formula into an equivalent sentence in conjunctive normal form, and then use proof by contradiction with unification.
Theorem proving techniques were then developed towards two directions, i.e.,
machine-oriented and human-oriented (interactive). The machine-orientated approach
relies on generic proof strategies, whereas the human-oriented approach involves human interaction to guide proofs. The theorem proving systems which work in the
human-oriented approach are also called proof assistants. A family of modern machineoriented theorem proving techniques is SMT solvers. A SMT solver provides background theories, such as arithmetic and arrays, to transform predicates in these theories into boolean satisfiability problems, so that boolean satisfiability procedures can
be applied to try to automate the proofs.
For the interactive approach, in 1970s, Milner invented the Logic for Computable
Functions (LCF) approach for interactive automated theorem proving [138]. In this
approach, theorems are represented as an abstract datatype; and can only be derived
from earlier theorems and axioms using the given inference rules. A general-purpose
functional programming language, called Meta Language (ML), was also introduced
to allow users to write theorem-proving tactics. The LCF approach was widely adopted
by many theorem provers, such as HOL [80], HOL Light [85], Isabelle [149], ProofPower [124], Nuprl [53], Coq [54].
In [29], Bundy pointed out that human mathematicians intuitively construct highlevel plans for proofs, instead of constructing them with low-level inference directly.
It was argued that, to achieve a better understanding of reasoning, both logic and a
high-level understanding should be put into consideration. In 1981, a technique called
meta-level inference was described in Bundy and Welham’s work [34]. Their metalevel driven system worked at both the meta-level (or high-level) and the object-level
(or low-level) to achieve algebraic manipulation. The object-level inference contains
14
Chapter 2. Literature Survey
domain knowledge for algebraic manipulation, e.g. rewrite rules, while the meta-level
one comprises methods used to control manipulation and guide proof search. Subsequently, proof planning [28, 32] was first introduced to the theorem proving domain.
Proof planning is motivated by the fact that there exists families of proofs with a similar pattern. The pattern is a proof plan which can be encoded as a meta-level guidance
to guide search in automated theorem proving. One of the most successful instances
of proof planning is rippling [30]. More details of rippling are given in §2.5. A proof
planner is a system which can construct proof plans and use proof plans to guide
proof searches. There are several proof planners have been implemented, e.g. Clam
[33], λClam [153], HOL/Clam [24], Ωmega [18], INKA [101] and IsaPlanner [64, 65].
Also the proof planning technique has been implemented in the Prototype Verification
System (PVS) [148].
Automated theorem proving techniques can be used to improve the automation of
generating proofs in formal methods. Some successful applications are: The Secure
Micro-kernel project used Isabelle to verify the secure embedded L4 (seL4), which is
the first general-purpose operating system kernel that has been verified [117]; KIV [10],
which is a formal system development tool adopting the LCF tactic approach for proof
supports, was used to verify both the medical guideline for the management of diabetes
of mellitus types 2 [96] and the Mondex smart card electronic cash system [84]; HOLlight was used to formalise an algorithm of the exponential function operation in IEEE754 [86]; ProofPower is used as part of the CLawZ toolset [147] to automate proofs for
verifying the correctness of codes that was automatically generated from the Simulink
[134] modelling language.
2.5
Rippling
Rippling [30] is a proof plan that was originally developed to guide the rewriting of the
induction conclusion in the step cases towards the inductive hypothesis. It is applicable in any scenarios when the goal is syntactically similar to one of the hypotheses and
every part of the hypothesis appears as a sub-expression in the goal. The hypothesis is
called the given, and the pattern is also referred to as ‘one of the givens is embedded
in the goal’.
Rippling guides rewriting to preserve the similar parts and reduces the differences
2.5. Rippling
15
between the given and the goal, and eventually the given is applied to simplify the goal.
The step of applying the given to the goal is called fertilisation. There are two types of
fertilisation, strong fertilisation and weak fertilisation. Strong fertilisation is the case
that when the goal matches the given exactly, the given can be applied directly to the
goal; Weak fertilisation is the case that, if the given is a equation based formula and
either left-hand side (LHS) or right-hand side (RHS) of the given is matched, the given
can be applied as a rewrite rule to rewrite the goal.
Each step of applying a rewrite rule to the goal is called a wave step. The rewrite
rule is called a wave-rule. The part to be preserved is called the skeleton. The differences to be removed are called wave-fronts. The parts of the skeleton which are
surrounded by wave-fronts are wave-holes. An example is given in Figure 2.1 for
illustration. For each wave step, a measure needs to be decreased, which is called
the ripple measure. Therefore, rippling always terminates, because it eventually ends
either by succeeding to fertilise or is blocked at which point there is no applicable
wave-rule and the goal cannot be fertilised.
Given:
8B C.(a + B) + C = a + (B + C)
Wave-fronts: Suc(...)
Goal:
(Suc(a) + b) + c = Suc(a) + (b + c)
Wave-holes: a
Skeleton: (a + b) + c = a + (b + c)
Figure 2.1: An the given being embedded in the goal
We will give more details of rippling with examples in §3.4. A formal account of
rippling can also be found in [14]. Rippling has been implemented in various systems,
such as Clam, λClam, HOL/Clam, INKA, IsaPlanner and Nuprl [151]. Many variations of rippling have been developed [100, 150, 1, 109].
Rippling has also been applied to summing series [166], equation solving [99] and
non-standard analysis [133]. Moreover, there are also successful applications of rippling in the formal methods domain, e.g. in the synthesis of higher-order programs
[120]; the automation of the verification of hardware circuits including a parametrised
multiplier and a simple computer microprocessor [41]; the automatic generation of
16
Chapter 2. Literature Survey
loop invariants for program verification in SPARK [104] and HUME [81].
As a proof method used within a proof plan, rippling contains knowledge of how
proofs should proceed, i.e., rippling towards the given. This expectation is, in particular, useful to develop proof patches for repairing proofs when rippling is blocked. We
will discuss related proof-patching techniques in the following section.
2.6
Patching Proofs
When a proof plan fails to prove a goal, the meta-level information of the proof plan is
helpful to build patches to recover the failed proof and eventually finish the proof. A
proof patch is typically developed for a proof plan and triggered when the proof plan
fails in a particular way. In this section, we survey proof patches developed for the
rippling proof plan.
The first proof-patching techniques, known as proof critics [30, 103], were developed for rippling. There are five patches in the proof critics, i.e., revising induction,
generalisation, case analyses, lemma speculation and lemma calculation.
• The revising induction critic suggests an alternative induction rule to replace the
original one when there exists a partial match between the goal and wave-rules,
i.e. only the skeletons matches.
• The case analyses critic is triggered when there exists an applicable conditional
wave-rule, but the planner fails to prove the condition. This critic applies a case
split to provide additional hypotheses to assume the condition and its negation.
• The generalisation critic is used to patch failed proof attempts when generalisation is required to replace a constant or any ground term with a universal variable,
so that the universal quantifier can be instantiated to a proper term to finish the
proof.
• Lemma calculation is triggered in a failed proof attempt after weak fertilisation
is applied. A lemma is constructed by generalising the goal which is produced
after the application of weak fertilisation.
• Lemma speculation is used to dynamically conjecture missing lemmas with the
2.7. Theory Formation and Theorem Discovery
17
hints of desired shape of lemma from the rippling expectation, e.g. parts of the
skeleton are moving together.
We illustrate how these proof critics work with examples in §3.4.
All these proof critics have been implemented in Clam [103]. There are also implementations of some of them in other proof planners. The lemma speculation and
case-split critics have been implemented in Ωmega; and the lemma speculation and
lemma calculation critics have been implemented in IsaPlanner [64, 111].
Apart from proof critics, more proof patches have been developed for rippling. The
interactive critic [106] is a patch built on top of proof critics. It gives users opportunities to choose a proof critic to apply when more than one proof critic is applicable.
This critic has been implemented in the XBarnacle system [131], which is a graphical
front-end for Clam.
The divergence critic [165] is developed to patch failed proof attempts caused by
divergence in PROLOG [49] and the SPIKE [23]. It detects patterns of divergence, e.g.
accumulating term structure, and then suggests lemma and generalisation to eliminate
the term structure leading to divergence.
Case-analysis [110] is a rippling proof patch implemented in IsaPlanner. It is triggered when rippling is blocked due to the existence of the case-statements and
if-statements in the wave-front. These two terms are used to define functions in
higher-order systems. This critic adopts heuristics to apply a case split to eliminate
these problematic terms.
The applications of proof patches are not limited to inductive proofs. One example
is Andrew Ireland’s work on loop invariant discovery[107]. It applies a proof plan, i.e.
rippling, and proof patching techniques to automate the discovery of loop invariants
for imperative programs through analysing failed verification proofs.
2.7
Theory Formation and Theorem Discovery
Theory Formation is a technique to perform concept invention and conjecture discovery. The first theory-formation system was the Automated Mathematician (AM)
18
Chapter 2. Literature Survey
system [125]. It generates and modifies short Lisp programs which are then interpreted as defining various mathematical concepts. Theory-formation techniques can
also be used to discover interesting conjectures or theorems. Currently several theoryformation systems, such as HR [52], IsaCoSy [112], IsaScheme [142], MATHsAiD
[136] and Hipster [113] are able to automatically discover and prove conjectures as
theorems. Potentially useful theorems can be conjectured before starting proofs; or
conjecturing the missing lemmas (theorems) when proof attempts fail. We will survey
these systems in this section.
2.7.1
IsaScheme
IsaScheme is a scheme-based theory exploration system. The central idea of the
scheme-based approach is that of a scheme, which is a formula containing higherorder variables, called scheme-variables. Schemes are intended to capture the shapes
of mathematical concepts and theorems, e.g. the associativity and distributivity laws,
to discover new concepts and theorems. The discovery process is carried out through
instantiating the scheme-variables using provided terms. Schemes can be used to not
only invent mathematical concepts, but they can also contribute to theorem discovery.
In this thesis, we are only concerned with the latter functionality.
Although the concept of scheme-based theory exploration was first introduced in
Theorema [27], it does not provide automation for theory discovery. Theorema requires the user to provide the appropriate substitutions, as it cannot instantiate the
scheme-variables automatically [57]. IsaScheme, on the other hand, is the first system
to provide automation of scheme-based theory exploration, including the instantiations
of scheme-variables.
IsaScheme was developed on top of Isabelle. It takes schemes, terms as a seeding
pool and a proof method as inputs. It produces type-correct conjectures by instantiating
the schemes to the given terms from the seeding pool. The conjectures are then filtered
with counter-example checkers, and hopefully proved by the given proof method. An
example is given in §3.7.
2.7. Theory Formation and Theorem Discovery
2.7.2
19
IsaCoSy
IsaCoSy (Isabelle Conjecture Synthesis) is a theory-formation tool for inductive theories. It was developed on top of IsaPlanner and Isabelle. With a given inductive theory
which is formed by the definitions of recursive datatypes and functions, IsaCoSy can
synthesis a set of interesting theorems for the given theory.
IsaCoSy introduce a constraint mechanism to synthesis conjectures. The constraint
mechanism prunes the search space, disallowing some conjectures. The constraint language in the constraint mechanism is capable of describing undesired patterns of combinations of operators and constants, and filtering out the conjectures matching the
patterns. For example, disallowing the pattern of the combination where the constant
0 appears as the left arguments of the operator +, i.e. (0 + ), as any such term is
rewritten by the rewrite rules. The constraints for the irreducible terms are generated
automatically by analysing the existing rewrite rules to capture all the reducible patterns of terms to be rewritten. The constraint mechanism can exponentially reduce the
synthesis exploration space [112]. After the conjectures are synthesised, IsaCoSy then
uses counter-example checkers to filter out the non-theorems, and then tries to prove
the remaining conjectures with IsaPlanner.
2.7.3
Hipster
Hipster is a system integrating the theory exploration system of the Haskell [160] programs, i.e. HipSpec [46], with the theorem prover system, i.e. Isabelle. Hipster works
by translating the current theory in Isabelle to a Haskell program, and using HipSpec
to synthesise conjectures. These conjectures are then translated back to Isabelle so that
Isabelle’s proof methods can be used to prove them.
Hipster takes operators as inputs, and then generates theorems for these operators.
The synthesis conjecturing first constructs all type-correct terms up to a given depth
limit using the given operators. It then attempts to divide the terms into equivalence
classes where every term semantically equals to each other. For every equivalence
class, a representative term is picked to build conjectures by equating it into the rest of
terms in the same equivalence class.
20
Chapter 2. Literature Survey
2.7.4
HR
HR is an example-driven theory-formation system naming after the mathematicians
Hardy and Ramanujan. This system is inspired by the approach whereby humans
induce conjectures by generalising patterns from given examples. Note that the conjectures produced using this approach might be non-theorems. Therefore, disproof is
required to filter non-theorems out so that the produced definitions are the correct ones.
An example of incorrect conjecture is: if the prime numbers of the given example are
3, 5, 7, a possible conjecture is that all prime numbers are odd.
To invent new theorems, HR starts with initial domain concepts as examples which
are represented with data-tables. New concepts are produced and added as examples
by applying a set of production rules to vary the current existing concepts. Heuristics
measuring interestingness are used to guide the application of conception production,
i.e., more interesting concepts are used more than the less interesting ones. An example
measure of interestingness is complexity. HR induces conjectures from the examples,
and then applies a theorem prover and a model checker to prove or disprove the conjectures.
2.7.5
MATHsAiD
MATHsAiD [136] is an abbreviation for Mechanically Ascertaining Theorems from
Hypotheses, Axioms and Definitions. It is intended to be used by research mathematicians, and aims to discover only interesting and useful theorems from the mathematicians point of view. In a given theory, MATHsAiD allows users to select a set of
axioms to be used during the discovery process, and a set of terms of interest which
users wish to appear in the generated theorems.
There are three main components in the discovery process, i.e. the hypothesis
generator, the theorem generator, and the theorem filter. The hypothesis generator
produces a sequence of sets of axioms. Each set of axioms is used as separated input
hypotheses for the theorem generation process. The idea behind this is to build up layers of axioms, and generate layers of theorems with increasing complexity from local
set of axioms. The theorem generator then derives theorems from the input hypotheses.
The derived theorems are filtered with the simplicity test and the irredundancy test by
the theorem filter. The simplicity test only keeps the simplest theorems in equivalent
2.8. Summary
21
theorems. The irredundancy test discharges the theorems which don’t use all the input
hypotheses, as those theorem are expected to be discovered in a layer lower than the
current one.
2.8
Summary
We have surveyed the literature which we consider to be related to our work. We
firstly surveyed the techniques in the formal methods area, in particular, the Event-B
formal method technique. Then we discussed the main challenge of the industrial use
of Event-B, and also describe theorem proving techniques which are one of possible
solution to the challenge. Lastly, we have surveyed rippling, proof-patching techniques
and theorem discovery techniques which we used to address the challenge in our work.
Chapter 3
Background
3.1
Introduction
Our work aims at improving proof automation for Event-B proof obligations by using
rippling and developing new proof patches for rippling. In this chapter we present the
related background with technical details. In §3.2 we introduce Event-B, in particular,
the mathematical modelling language, the modelling structures, the proof obligations
and the main development platform. We then give the technical details with examples of rippling and the lemma discovery proof critics in §3.4. Both our work and the
dependent systems of our work, i.e., Isabelle, IsaPlanner and IsaScheme, are implemented with the ML functional programming language. We present the curried and
uncurried functions of ML for ease of presentation in §3.3, and give relevant details
of the dependent systems in §3.5, §3.6 and §3.7, respectively. A summary is given in
§3.8.
3.2
3.2.1
Event-B
Mathematical Modelling Language
The Event-B mathematical modelling language [6] comprises first-order logic, set theory and arithmetic. There are three basic datatypes, i.e., Z, BOOL and carrier sets. Each
of them is defined in terms of sets. The descriptions of each basic datatype are given
as follows:
• Z is a set of all integers.
23
24
Chapter 3. Background
• BOOL is a set of boolean values composed of TRUE and FALSE, i.e., {TRUE, FALSE}
• Carrier sets are sets defined by users. They are initially unspecified non-empty
datatypes of sets. Further constraints or properties can be posted explicitly in
Event-B modelling structures.
With the three basic datatypes, more datatypes can be defined recursively with the
two datatype constructors, i.e., P and ×. The following definition summarises the
datatypes in Event-B, where T stands for datatypes.
T=
b Z | BOOL | carrier sets
| P(T)
| T×T
P(T) is the power set of T, and T × T is the Cartesian production of two datatypes.
Operators related to predicates, quantifiers, sets, relations, functions and arithmetic
are defined based on these datatypes. A concise reference can be found in Appendix
A. A full description of these modelling languages is available in [156].
The mathematical language can be extended to allow for new basic predicate definitions, new operator definitions and new inductive data type definitions, with the
theory component of the Event-B platform [37]. Our work does not cover the possible
extended operators and inductive theories, although they are also very interesting as
rippling is applicable to these inductive theories. We focus on the prefixed mathematical language in this thesis, and only show the possible use of our techniques in the
extended theories in §7.5.
3.2.2
Modelling Structure
An Event-B model is structured with two components: contexts and machines. Contexts hold the static information whereas machines contain the dynamic information.
Figure 3.1 shows the subcomponents of machines and contexts together with the relations between machines and contexts.
A context may contain carrier sets, constants and axioms, as shown in Figure 3.1.
Carrier sets are user-defined datatypes which have been discussed in §3.2.1; Constants
are static values; Axioms define properties of carrier sets and constants. We will give
3.2. Event-B
25
sees
CONTEXT
MACHINE
CONTEXT
extends
sees
sees
CONTEXT
- Carrier Sets
- Constants
- Axioms
refines
MACHINE
sees
DIrect Relations:
- Variables
- Invariants
- Events
annotations
IndIrect Relations:
Components:
A Collations of Components:
(from 0 unto many)
Figure 3.1: The contents of the Event-B components and their relations
an example of contexts in §3.2.3. A context always refer to the contents of any contexts that it extends. The extension relation is called ‘extends’. Note that a context can
extend from one to many contexts.
Machines are used to specify behavioural properties of models from the state point
of view. A machine can also always refer to the contents of a number of contexts that
it extends. The extension relation is called ‘sees’. Note that both the relation ‘see’ and
‘extends’ are transitive. For example, if a context A extends a context B and a machine
C extends A, the contents of B are referable for C.
Refinement is the process of transforming an model into a more concrete (less abstract) model. An example of refinement is to refine from a list to an array. Each
refinement step creates a more concrete model which is a refinement of the previous
one and must be verified through the use of proof. The keyword ‘refines’ is used to
26
Chapter 3. Background
describe the refinement relation between machines. The concrete machine indirectly
sees the referable contexts of the abstract machine. Although refinement is an important topic in Event-B, this thesis focuses only invariant proofs which is for a single
machine. Therefore refinement will not be treated further here.
A machine may contain variables, invariants and events, as shown in Figure 3.1.
Variables are used to describe the state of the machine; invariants specify the properties
of the state which must be preserved in every reachable state of the machine; and
events are structures to describe how the state changes by modifying the values of the
variables. An example of a machine is given in §3.2.3 to illustrate each subcomponent.
An event takes one of the following forms:
< name > =
b begin < actions > end
(3.1)
< name > =
b when < guards > then < actions > end
(3.2)
< name > =
b any < parameters > where < guards > then < actions > end
(3.3)
where name is a name for an event; Parameters are local variables which are represent
arbitrary inputs and are used for local definitions for events; Guards are preconditions
for events. These are predicates defined over the variables of the machine and the local variables of the events. Actions define changes over the variables. (3.3) can be
considered as the most general form among the three forms; (3.2) is a form without
parameters, that is used when no input is needed; and (3.1) is a form without either parameters or guards, that is used when no input is needed and no precondition required
to trigger the events. The INITIALISATION event has form (3.1). INITIALISATION
is a special event which is required in every machine to specify the initial state of a
machine by providing the initial values for each variable. Note that there is no such
a form of event which either contains parameters and actions, because the parameters
only provide declarations for local variables and the related definitions have to be given
in guards.
There are three kinds of actions, i.e., empty, deterministic and non-deterministic.
The empty actions have no effect in terms of state-changing. Event-B uses the keyword
skip to represent such a null operation; Deterministic actions change states of machines
3.2. Event-B
27
by explicitly and directly assigning new values to variables, i.e.,
variable := new value
Non-deterministic actions achieve state-changing by providing a set of possible new
values for a variable and specifying that the new value of the variable can be any
element in that set. This set can be defined either with predicates or set expressions,
i.e.,
variable :∈ predicate
variable :| set expression
where symbol (:∈) in the first definition means the variable is assigned to an arbitrary
value which satisfies the predicate, whereas symbol (:|) in the second definition means
the variable is assigned to an arbitrary value from the set which is described by the
set expression.
3.2.3
An Example of an Event-B Model
To illustrate the subcomponents of contexts and machines, we employ an Event-B
model of a telephone exchange system as an example 1 . There are Event-B mathematical modelling language annotations in this example, e.g. →
7 and 7→. Their definitions
are provided in Appendix A. We also explain the relevant annotations when discussing
this example. This example is also a running example throughout the whole thesis.
Note that not all events of the model are presented; we only give four representative
ones. We first explain the context of the model, followed by an explanation of the
machine.
Context
Figure 3.2 shows the context of the Event-B model. The name of the context is given
at the top of the context, i.e. C0. Carriers sets are defined below the keywords SETS,
constants are given under CONSTANTS and axioms are below AXIOMS. Each axiom
is assigned with a name, e.g. StatusDef.
1 This
example was originally developed in Z from [130]. We translated it to Event-B, and make
some changes for ease of presentation.
28
Chapter 3. Background
CONTEXT C0
SETS
DIGIT SEQ
CONSTANTS
connecting
seize
STATUS
ringing
speech
engaged
Connected
st
num
InitSubs
NULL
AXIOMS
StatusDef : partition(STATUS, {seize}, {connecting}, {ringing}, {speech}, {engaged})
stTyp : st ∈ (STATUS × DIGIT SEQ) → STATUS
ConnectedTyp : Connected ⊂ STATUS
ConnectedDef : Connected = {ringing, speech}
numTyp : num ∈ (STATUS × DIGIT SEQ) → DIGIT SEQ
stnumDef : ∀x·x ∈ (STATUS × DIGIT SEQ) ⇒ (st(x) 7→ num(x)) = x
InitSubs : InitSubs ⊆ DIGIT SEQ
NULLTyp : NULL ∈ InitSubs
END
Figure 3.2: The CONTEXT of an Event-B model of an telephone exchange system
Two carrier sets are defined, DIGITSEQ and STATUS. DIGITSEQ is a datatype to represent a set of valid telephone numbers. STATUS is a datatype to represent the line status
of telephones. In the axiom of StatusDef, STATUS is further constrained to be an enumerated type containing the constants, such as connecting, seize, ringing, speech
and engaged. This is defined by using operator partition (operation), where STATUS
is the union of {connecting}, {seize}, {ringing}, {speech} and {engaged}, and the
intersection of any pair of them is the empty set (∅). In the axioms of ConnectedTyp
and ConnectedDef, constant Connected is defined to be a subset of STATUS which
represents the connected line status of telephones. The axioms of stTyp and numTyp
define constant st and num as two total functions (→). The axiom stnumDef con-
3.2. Event-B
29
strains st and num to project the first or the second element of the datatype (STATUS
× DIGITSEQ). This is achieved by stating that for all elements x with the datatype
(STATUS × DIGITSEQ), an ordered pair (7→) of st(x) and num(x) equals x itself.
Constant InitSubs is a subset of type DIGITSEQ that is used to initialise the current
registered telephone numbers in the telephone exchange system. Constant NULL is a
special value to represent a null number in the system.
Machine
Figure 3.3 shows the machine of the Event-B model. Similar to the context, the name
of the machine is given at the top of the context, i.e. M0. Keyword SEES shows the
referable contexts. The subcomponents such as variables, invariants and events are
defined under keywords VARIABLES, INVARIANTS and EVENTS, respectively.
Variable Subs records all the registered telephone numbers in the system. It is defined as a set with the type DIGITSEQ in SubsTyp. Variable call is used to keep track
of the status of the call, and to include the caller, the callee and the current status (e.g.
ringing). The type of the variable call is given in invariant callTyp, representing a
partial function (→)
7 from a caller to the line status and the callee. Variable incoming
is used to keep track of the relation between a telephone number and the telephone
numbers of current incoming calls. It is a total function (→) from a telephone number
to a set of telephone numbers, as defined in incomingTyp. Invariant incomingDef
states that one cannot call himself (herself). The variable Callers is a set of telephone
numbers, as defined in CallersTyp. It is used to record the telephone numbers of
the callers whose calling attempts have been connected. This is stated in the invariant
CallersDef. In CallersDef, the mapping from callers to the line status is first projected from call by compositing call with the projection function st. The mapping
is filtered (B) by the set Connected which only contains the connected status. Then
the domain of the filtered mapping is the desired callers’ numbers.
There are 12 events in total in this machine. However, only four of them are presented, as this is sufficient for illustration. Event INITIALISATION is to specify the
initial state of the machine by providing the initial values for each variable. Event
RegisterSubs is to register a new telephone number subs. subs is added to the set of
all the registered numbers in the system, i.e. subs, and the function incoming recording the relation of incoming calls is updated (C
−) with an ordered pair of the new num-
30
Chapter 3. Background
MACHINE M0
SEES C0
VARIABLES
Subs
call
incoming
Callers
EVENTS
INVARIANTS
SubsTyp : Subs ⊆ DIGIT SEQ
callTyp : call ∈ Subs →
7 (STATUS × Subs)
incomingTyp : incoming ∈ Subs → P(Subs)
CallersTyp : Callers ∈ P(Subs)
CallersDef : Callers = dom(call; st BConnected)
incomingDef : ∀x·x ∈ dom(incoming) ⇒ x ∈
/ incoming(x)
NullExisits : NULL ∈ Subs
Initialisation
begin
act1 : call := ∅
act3 : Callers := ∅
act4 : Subs := InitSubs
act2 : incoming := InitSubs × {∅}
end
Event RegisterSubs =
b
any
subs
where
grd1 : subs ∈ DIGIT SEQ
grd2 : subs ∈
/ Subs
then
Event LiftFree =
b
any
s
where
grd1 : s ∈
/ dom(call)
grd2 : s ∈ Subs
then
act1 : call := call ∪ {s 7→ (seize 7→ NULL)}
end
Event DialNum =
b
any
s, ds
where
grd1
grd2
grd3
grd4
: s ∈ dom(call)
: (call; st)(s) = seize
: ds ∈ dom(call)
: s 6= ds
act1 : Subs := Subs ∪ {subs}
then
act2 : incoming := incoming C− {subs 7→ ∅} act1 : call := call C− {s 7→ (connecting 7→ ds)}
end
act2 : incoming(ds) := incoming(ds) ∪ {s}
end
END
Figure 3.3: The MACHINE of an Event-B model of an telephone exchange system
3.2. Event-B
31
ber subs and an empty-set. Event LiftFree describes an action that a caller, with telephone number s, picks up the phone and gets ready to dial the callee’s number. The relevant line status, i.e. {s 7→ (seize 7→ NULL)} is then added (∪) to call. An subsequent
action is defined in event DialNum, where s is the caller’s number and ds is the callee’s
number. Note that the mapping of the line status, i.e. {s 7→ (connecting 7→ ds)}, is up-
dated (C
−) to call accordingly, and the incoming calling numbers of the ds is extended
with s.
3.2.4
Proof Obligations
Different kinds of proof obligations arise to verify models from different aspects. For
instance, invariant preservation (INV) proof obligations ensure each invariant still
holds after the state is changed by an event; well-definedness (WD) proof obligations
guarantee that the formulas of axioms, invariants, guards and actions are well-defined.
For example, no division by zero. Feasibility proof obligations (FIS) proof obligations
make sure that non-deterministic actions are satisfiable by asking for a witness. INV
POs can account for a significant part of all of the POs that need interactive proofs. For
example, in one case study of buyer / seller B2B communication 2 , 80% of POs with
interactive proofs are INV POs. In this thesis we only focus on INV POs. An example
of the INV PO of invariant callTyp for event RegisterSubs is shown as below.
sub ∈ DIGIT SEQ
sub ∈
/ Subs
···
(3.4)
call ∈ Subs →
7 (Status × Subs)
`
call ∈ (Subs ∪ {sub}) →
7 (Status × Subs ∪ {sub})
where (→)
7 is a symbol of partial function and sub is the new registered telephone
number. This INV PO is used to ensure that the type of call remains after Subs is
extended with sub.
2 Available
in http://deploy-eprints.ecs.soton.ac.uk/128/
32
Chapter 3. Background
3.2.5
The Rodin Platform
Rodin [5, 7, 36, 51] is an extensible integrated development tool for both modelling
and proving. A screenshot of Rodin is given in Figure 3.4. There are three main components in Rodin, i.e., the static checker, the proof obligation generator and the proof
obligation manager [7].
Figure 3.4: A screenshot of Rodin
The static checker performs checking of well-formedness of Event-B models and
gives users related feedback. Well-formedness is defined in terms of syntax correctness and type correctness. The proof obligation generator automatically generates all
kinds of proof obligations. The proof obligation manager maintains the status of each
proof obligation and the associated proofs.
Rodin provides interfaces for both automatic proving and interactive proving. Automatic proving in the Rodin interface is in a ‘button-click’ manner. For interactive
proving, the available operations are:
• removing unrelated hypotheses or adding related hypotheses to the automated
proof methods.
• applying a case split with an user provided predicate. This operation is called
‘dc’.
3.3. Curried and Uncurried Functions in Poly/ML
33
• instantiating quantifiers in either goals or hypotheses.
• performing generalisation by replacing a sub-term with a fresh variable. This
operation is called ‘ae’.
• providing a lemma via the cut rule. It is called ‘ah’. This operation generates a
new goal to prove the lemma, and inserts the lemma into the hypotheses of the
original goal.
As an extensible tool, Rodin supports external provers via plugins. An example of
such a plugin is the Atelier B prover 3 . More recently, Schmalz formalised the logic
of Event-B in Isabelle [158]. A plugin called Isabelle for Rodin was also developed
to export proof obligations to the formalised logic of Isabelle. We will give more
explanations of the exported Event-B POs in Isabelle in §3.5.3.
3.3
Curried and Uncurried Functions in Poly/ML
Meta Language (ML) [140] is a type-safe functional programming language with static
typing, eager evaluation and some imperative features. Poly/ML [135] is a full implementation of ML. It has been used to implement systems such as Isabelle, IsaPlanner
and IsaScheme. We also use Poly/ML to implement our work in this thesis. In this
section, we give the syntax for function declaration in Poly/ML, which is used in the
explanation of our implementation in chapter 6.
In ML, functions with multiple arguments can be declared in either curried or uncurried form. To illustrate, consider a function sum which takes two integers and returns the sum of them. A curried version of its declaration is
val sum :
int -> int -> int
where the first two int are arguments and the last one is a returned value; a curried
version of its definition is
fun sum (a :
int) (b :
int) = a + b
An uncurried version of its declaration is
val sum :
3 http://www.atelierb.eu/en/
(int * int) -> int
34
Chapter 3. Background
where the two arguments are concatenated with *. An uncurried version of the declaration of sum is:
fun sum ((a :
int), (b :
int)) = a + b
In this thesis, both forms are used. The uncurried forms are more likely to be adopted
for the functions which are used as operations and combinators. Infix notation is often
allowed for the uncurried forms; For remaining functions, the curried forms are used.
In the case of the sum example, we prefer to represent it in the uncurried form.
3.4
Rippling and Proof Critics
Rippling [30] was originally developed to guide the rewriting of the induction conclusion in the step cases towards the inductive hypothesis. However, we argue that
the proofs of INV POs can be considered as inductive. We will give more discussion
regarding this argument in §4.2. In this section, we give technical details for rippling
and the patching mechanism. Note that we use the Isabelle notations in this section. In
particular, Isabelle uses (→) to represent the object-logic implication whereas Event-B
uses (⇒).
Figure 3.5 shows a proof plan using rippling for inductive proofs. The examples
given in this section are mainly from [30]. For ease of understanding, we revisit some
definitions of rippling’s terminologies from §2.5 and show a schematic example: the
step of applying the embedded hypothesis, called the given, to the goal is called fertilisation; a wave step is the step of applying a rewrite rule to the goal; a wave-rule is the
applied rewrite rule; a skeleton is the part to be preserved during rippling in the goal;
Wave-fronts are the differences to be removed or moved out of the way; wave-holes are
the parts of the skeleton which are surrounded by wave-fronts. A schematic example
of a rippling goal is shown as below
↑
P (x) ` P ( F (x) )
↑
↑
where P (x) is the given, P ( · · · (x) · · · ) is the skeleton, F (· · · ) ) is the wave-front
and x is the wave-hole. A possible wave-rule is
↑
P ( F (x) ) = Q (P (x))
↑
3.4. Rippling and Proof Critics
35
A possible wave-step is to rewrite the goal using this wave-rule from the left-hand side
to the right-hand side, which results in
P (x) ` Q (P (x))
↑
Now the fertilisation step can be done by applying the given. Some real examples of
rippling will be discussed in the following of this section.
Induction
Base Case(s)
Step Case(s)
Rippling
Simplification
Wave Steps
Fertilisation
Figure 3.5: A proof plan using rippling for inductive proofs
3.4.1
Strong and Weak Fertilisation
To illustrate how rippling works, consider the following step case of an inductive proof.
The examples are for lists. The notation is from Isabelle, where (rev) is a function to
reverse a given list; (#) is a fundamental list construction operator, called cons; (@) is
an infix operator to concatenate two lists; and ([]) represents an empty list.
Given : rev (t @ l) = (rev l) @ (rev t)
Goal : rev ( (h # t)
↑
↑
(3.5)
@ l) = (rev l) @ (rev (h # t) )
This goal is annotated with rippling annotations. Recall that a rippling goal consists
of a skeleton, wave-holes and wave-fronts. Wave-fronts are the difference between the
goal and the embedded hypothesis; Skeleton is the part expected to be preserved which
is the range of the embedding mapping from the hypothesis; and wave-holes are the
parts of skeleton which are located inside of wave-fronts. Wave-fronts are framed with
boxes, e.g. (h # ...) ; wave-holes are annotated with underlines, e.g. t; the skeleton
36
Chapter 3. Background
comprises wave-holes and those non-annotated parts; and the arrows on the top-righthand corner of the wave-fronts, e.g. ↑, indicate the direction of rippling. We will
explain this concept later. Now we show how to apply rippling to prove this goal.
Assume that we have the following wave-rules:
(X # Y ) @ Z
rev (H # T )
↑
↑
= (X # (Y @ Z)
↑
(3.6)
= rev (T ) @ (H # [])
X @ (Y @ Z)
( (X1 @ H)
↑
↑
= (X @ Y ) @ Z
↑
(3.7)
↑
(3.8)
↑
= Y1 @ H ) = (X1 = Y2 )
(3.9)
Note that all the above wave-rules are skeleton preserving. Each wave-rule can be applied when the annotations and the term in the LHS of a wave-rule matches. We now
show proving (3.5) using rippling as follows:
Given: rev (t @ l) = (rev l) @ (rev t)
Goal: rev ( (h # t)
↑
↑
@ l) = (rev l) @ (rev (h # t) )
rev ((h # (t @ l))
↑
⇓ by (3.6)
↑
= (rev l) @ (rev (h # t) )
⇓ by (3.7)
rev (t @ l) @ (h @ [])
↑
= (rev l) @ (rev t @ (h @ []))
↑
⇓ by (3.8)
rev (t @ l) @ (h @ [])
↑
= ((rev l) @ (rev t)) @ (h @ [])
↑
⇓ by (3.9)
(rev (t @ l) = (rev l) @ (rev t))
⇓ by strong fertilisation
Proved
Note that each step is skeleton preserving, and matching is constrained to match
wave-front to wave-front and skeleton to skeleton.
Recall that strong fertilisation is to apply the embedded hypothesis, e.g.,
rev (t @ l) = (rev l) @ (rev t)
3.4. Rippling and Proof Critics
37
to simplify the current goal. The goal is now fully rippled so that strong fertilisation
can be applied. There is another way to fertilise equation-based goals, when just the
LHS or RHS of the goal is rippled. This type of fertilisation is called weak fertilisation. To illustrate, consider proving the same goal but without (3.8). Although the goal
cannot be fully rippling, the LHS of the goal, however, is rippled. Weak fertilisation
can be applied to use the inductive hypothesis to rewrite the goal. The proof is shown
as below.
Given: rev (t @ l) = (rev l) @ (rev t)
Goal: rev ( (h # t)
↑
↑
@ l) = (rev l) @ (rev (h # t) )
rev ((h # (t @ l))
↑
⇓ by (3.6)
↑
= (rev l) @ (rev (h # t) )
⇓ by (3.7)
rev (t @ l) @ (h @ [])
↑
= (rev l) @ (rev t @ (h @ []))
↑
⇓ by weak fertilisation
(rev l) @ (rev t) @ (h @ [])
↑
= (rev l) @ (rev t @ (h @ []))
↑
⇓ Reflexive Property of Equality
True
Note that the last step is not part of rippling. The resulting subgoal after weak fertilisation requires some additional proof steps or an automatic proof method to finish the
proof.
3.4.1.1
Rippling-in and Rippling-out
There are two rippling directions, rippling-out and rippling-in. rippling-out is annotated with (↑), and rippling-in is annotated with (↓). To explain the rippling directions,
a rippling applicable goal can be represented as a decorated term tree where the skeleton is the tree and wave-fronts decorate the nodes [30]. To illustrate, consider the
conjecture:
∀t, k, l.qrev (t, k @ l) = qrev (t, k)@l
where qrev(X, Y) is a function to append the reversed list of X in front of Y. By applying
induction on t, the step case of the goal is
38
Chapter 3. Background
Given : ∀k, l. qrev (t, k @ l) = qrev( t, k)@ l
(3.10)
Goal : ∀k, l. qrev ((h # t), k @ l) = qrev ((h # t), k) @ l
Note that, both in the hypothesis and the conclusion, variables k and l are bound by universal quantifiers. For the variables bound by universal quantifiers in the hypothesis,
we can instantiate them to any type-correct term to assist the proof; while in the conclusion we need to show that the goal satisfies any value of these variables. Therefore,
after the processes of skolemization for quantifier elimination, these bound variables
in the hypothesis become free variables, but those in the conclusion becomes skolem
constants. To distinguish the different status of these variables, we use upper case for
the free variables, e.g. K and L, and lower case for the skolem constants, e.g. k and l.
The goal now becomes
Given : qrev (t, K @ L) = qrev( t, K)@ L
↑
(3.11)
↑
Goal : qrev ( (h # t) , k @ l) = qrev ( (h # t) , k) @ l
The decorated term tree of (3.11) is shown in Figure 3.6. Note that the tree is the parse
tree of the skeleton decorated with wave-fronts.
=`
```
H
H
H
H
HH
h#t
``
@
qrev
↑
@
qrev
,l
,
l
Q
Q
bkc
blc
h#t
↑
blc
bkc
Figure 3.6: A decorated term tree representation of a rippling goal
Rippling-out moves the wave-fronts upwards in the term tree. Rippling-in moves
wave-fronts downwards until each wave-front reaches a leaf node and the leaf node is
a position of a sink (b...c), which corresponds to free variables in the given. In Figure 3.6, the possible sinks are bkc and blc. When the wave-fronts are in sinks, the free
variables in the given can be instantiated to the formula in the sink to conclude the goal.
The rippling directions of the strong and weak fertilisation examples in the last section are rippling-out. Here, we give another example to illustrate rippling-in. Consider
3.4. Rippling and Proof Critics
39
the following wave-rules to prove (3.11):
↑
↓
qrev ( H # T , L) = qrev (T, H # L )
H # (X @ Y )
↓
= (H # X)
↓
@Y
(3.12)
(3.13)
The proof is shown as follows.
Given: qrev (t, K @ L) = qrev( t, K)@ L
↑
↑
Goal: qrev ( (h # t) , k @ l) = qrev ( (h # t) , k) @ l
⇓ by (3.12)
↓
↑
qrev (t, h # (bkc @ blc) ) = qrev ( (h # t) , k) @ l
⇓ by (3.12)
↓
↓
qrev (t, h # (bkc @ blc) ) = qrev (t, h # bkc ) @ l
qrev (t, (h # bkc)
↓
⇓ by (3.13)
@ l) = qrev (t, h # bkc
(3.4.1.1)
↓
@l
⇓ use sink to absorb wave-fronts
qrev (t, b(h # k)c @ l) = qrev (t, bh # kc) @ l
⇓ by strong fertilisation,
instantiating K to h # k
Proved
Note that rippling only allows turning rippling-out to rippling-in but not the other way
around, so that termination can be guaranteed. In general, rippling-in can happen when
• there is a wave-rule allowing turning the direction of a wave-front from outwards
to inwards, and
• there is at least one sink inside the wave-front.
Rippling-in is useful when the proofs are achieved by instantiating free variables (universal quantifiers) in the given. Rippling-in pushes the differences inwards and leads
to the instantiation of the free variable in the given during fertilisation, e.g. the step
of instantiating K to h # k in the example (3.4.1.1), while ripping-out pushes the differences outwards the top, followed by the step of fertilisation of applying the original
given directly without any instantiation.
40
Chapter 3. Background
3.4.2
Case Analyses Critic
In this subsection we give an example to illustrate the case analyses critic [30, 103].
Before we introduce this critic, we show the concepts of conditional wave-rule and
complementary pair of rewrite rules.
When rewrite rules can have conditions e.g.,
Cond =⇒ LHS
where Cond is a condition and
RHS
mean to rewrite from the LHS to the RHS. Note
that we use the meta-logic implication =⇒ from Isabelle to represent the conditional
rewrite rule. More details regarding the meta-logic implication will be given later in
§3.5. This rewrite rule is interpreted as: when Cond is satisfied, rewrite the sub-term
of the goal matching LHS to RHS.
Conditional rewrite rules sometimes are available in a complementary pair. These
rewrite rules share the same LHS, and their conditions are complementary. For example,

(1) X = Y =⇒ X ∈ (Y # T ) True
↑
(2) X =
6 Y =⇒ X ∈ ( Y # T ) X ∈ T
(3.14)
where symbol (∈) is list membership. Both rewrite rules have the same LHS, i.e.
X ∈ (Y # T ), and their conditions are complementary. Note that the rewrite rules of a
complementary pair do not have to be wave-rules.
When a rewrite rule is conditional, the corresponding wave-rule is conditional. A
conditional wave-rule can be only applied when LHS is matched and the condition is
provable.
If the condition of a conditional wave-rule is not provable, but the wave-rule belongs to a complementary pair, e.g. the second rewrite rule of (3.14). A case split on
the complementary condition will be suggested by the case split critic, and the conditional wave-rule will then be applicable. To illustrate, consider the following goal with
the wave rule (3.6) and the complementary pair of (3.14).
3.4. Rippling and Proof Critics
41
Given : a ∈ t → a ∈ (t @ l)
Goal : a ∈ h # t
↑
→a∈( h#t
↑
@ l)
With (3.6), the goal becomes
a∈ h#t
↑
↑
→a∈( h#t @l )
Now rippling is blocked, because the condition of the conditional wave-rule of (3.14)
is not provable. Fortunately, the conditional wave-rule belongs to a complementary
pair. Therefore, the case split critic can suggest a case split on the complementary
condition, i.e., a = h ∨ a 6= h, so that the proof is recovered.
For the case a = h, after application of the first rewrite rule of (3.14), the goal
becomes
True → True
Although this subgoal ceases to be a rippling problem due to no embeddings, it can be
trivially proved.
For the case a 6= h, the conditional wave-rule of (3.14) is now applicable to rewrite
the goal as
a ∈ t → a ∈ (t @ l)
where strong fertilisation is now triggered to finish the proof.
3.4.3
Lemma Calculation and Lemma Speculation
Lemma calculation [30, 103] and lemma speculation [30, 103] are two proof patches
to recover blocked proof attempts by discovering missing lemmas.
Lemma Calculation
Lemma calculation works by generalising the goal as a lemma after weak fertilisation
is applied. To illustrate, consider proving the following goal with the wave-rule (3.7)
only.
Given : rev (rev (t)) = t
Goal : rev (rev (h # t) ) = (h # t)
42
Chapter 3. Background
Proof becomes blocked after the rippling step with (3.7), i.e.,
rev ( rev t@(h # []) ) = (h # t)
After applying weak fertilisation, the goal becomes
rev ( rev t@(h # []) ) = (h # rev(rev t)
Then common sub-terms are generalised, i.e. rev t. We now have the lemma
rev ( X@(H # []) ) = (H # rev X)
which is a missing lemma to unblock the goal.
Lemma Speculation
Lemma speculation is a more advanced proof critic for lemma discovery. It is triggered
in the case when rippling is blocked and lemma calculation is not applicable. Lemma
speculation initially constructs a schematic wave-rule which is a wave-rule containing
higher-order variables, which can be used to unblock part of the goal. This schematic
wave-rule is constructed based on the known possible term structures of the next proof
state from the rippling expectation, together with the higher-order variables to represent the unknown term structure. These higher-order variables are then incrementally
instantiated at the subsequent rippling steps, until fertilisation becomes applicable and
all the higher-order variables are fully instantiated. This approach of stepwise instantiating the higher-order variables during proofs is called middle-out reasoning [118]. To
illustrate lemma speculation, consider proving the following blocked proof with (3.7)
only.
Given : rev (rev (t) @ l) = rev (l) @ t
Goal : rev (rev (h # t)
↑
@ l) = rev (l) @ h # t
↑
Note that an alternative rippling annotation for the rewrite rule (3.7) is
rev (T ) @ (H # [])
↓
= rev (H # T )
↓
(3.15)
Both LHS and RHS become blocked after applying the RHS of (3.7) to the LHS, i.e.,
rev ( rev (t) @ (h # [])
↑
@ l) = rev (l) @ h # t
↑
3.4. Rippling and Proof Critics
43
Neither fertilisation nor lemma calculations is applicable. Lemma speculation is then
triggered. It constructs the LHS of a schematic wave-rule using a subterm of the
blocked goal, i.e.,
rev (l) @ h # t
↑
With the skeleton preservation rule and the rippling measure, the RHS of the schematic
wave-rule is constructed using higher-order variables, i.e.,
↓
F1 (rev (l), h, t, l) @ t
where F1 is a higher-order variable to represent the unknown term structures in the
wave-front. Note that more than one possible RHS can be constructed, e.g. rippling
outwards. We only show the successful branch of searching space. After generalisation
of LHS and RHS, argument l is removed, i.e.,
↓
F1 (rev (l), h, t) @ t
Followed by the application of this schematic wave-rule from LHS to RHS, the
goal becomes
rev ( rev (t) @ (h # [])
↑
@ l) = F1 (rev (l), h, t)
↓
@t
Now the RHS of the goal and the LHS of (3.15), i.e. rev (T ) @ (H # [])
↓
are unifi-
able. The RHS of the goal after unification becomes:
↓
↓
F2 ( rev (l) @ (F3 (rev (l), h, t)#[]) , h, t) @ t
where F1 = λw, x, y. F2 (w @ (F3 (w, x, y)#[]), x, y). With the rippling step with (3.15),
the goal evolves to
↓
· · · = F2 (rev (F3 (rev(l), t, h) # l) , h, t)
↓
@t
After each instantiation of the higher-order variables by unification, attempts also are
made to instantiate the remaining meta-variables with projection functions in order to
make fertilisation applicable, e.g. F2 and F3 are instantiated as F2 = λw, x, y. w and
F3 = λw, x, y. y, and the goal becomes
rev ( rev (t) @ (h # [])
↑
@ l) = rev (h # l)
↓
@t
44
Chapter 3. Background
Note that weak fertilisation is now applicable, and all the higher-order variables in the
schematic wave-rule have been fully instantiated. The generalised version of the fully
instantiated schematic wave-rule is
rev (W ) @ X # Y
3.5
3.5.1
↑
= rev (X # W )
↓
@Y
Isabelle
Frameworks and Structures
Isabelle [149] is a general purpose LCF-style proof assistant implemented in ML. The
main application of Isabelle is writing specifications and theorem proving. Isabelle
provides a meta-logic as a logical framework to formalise logic systems. A formalised
deductive logic system is called object logic. Some examples of object logic are higherorder logic (HOL), first-order logic (FOL) and Zermelo-Fraenkel set theory (ZF). The
name ‘Isabelle/HOL’ means the Isabelle system with the HOL object logic.
The meta-logic uses the implication notation, i.e.
=⇒ , to represent inference
rules. Note that this implication annotation is right-associative infix. To illustrate:
H0 =⇒ H1 =⇒ · · · =⇒ Hn =⇒ Concl
which is can also be represented as
[H0 ; H1 ; · · · ; Hn ] =⇒ Concl,
This formula is equivalent to the inference rule:
H0 , H1 , · · · Hn
Concl
as well as a proof sequent:
H0 ; H1 ; · · · ; Hn ` Concl
Users can construct declarations, definitions and proofs with object logics. These
contents are organised as theories in Isabelle, which are similar to the concept of modules in programming languages. A general form of a theory is shown in Figure 3.7.
THY is the name of the theory; P1 · · · Pn are the names of existing theories. These
theories are the parent theories of THY whose contexts are visible and referable to THY.
3.5. Isabelle
45
theory THY
imports P1 · · · Pn
begin
declaration, definitions and proofs
end
Figure 3.7: A general form of a theory in Isabelle/HOL
Isabelle provides commands to facilitate theory development. For instance, typedecl
declares a new type without defining it; consts declares a constant; and axioms introduces a predicate as an axioms which can be used to state the properties of types
and constant. For example, for a constant a with type int, the following predicate, i.e.
a > 1, can be provided as an axiom to specify that the constant a is greater than 1 :
Note that axioms are highly discouraged as one has to be very careful to not introduce
inconsistencies in a theory.
The syntaxes of typedecl, consts and axioms are shown in Figure 3.8. Note that
the axiom’s name is optional.
typedecl T
consts “const name” :: TYPE
axioms [axiom name” :] “axiom predicate”
Figure 3.8: Syntax Isabelle commands
Isabelle also supports a locale mechanism [116, 82] to organise formal theory development in a modular fashion. A locale is a concept of ‘local theory’ in Isabelle. It
is a context of fixed parameters and assumptions, in which theorems could be proved.
An example of a partial order specification as a locale from [9] is shown in Figure
3.9. Parameters are declared with fixes, and axioms of a local theory are defined with
assumes.
46
Chapter 3. Background
locale partial order =
fixes le :: “ 0 α ⇒ 0 α ⇒ bool ”
assumes refl : “ le x x ”
and anti sym: “ [le x y; le y x] =⇒ x = y ”
and trans “ [ le x y; le y z ] =⇒ le x z ”
Figure 3.9: A partial order specification as a locale
Note that we only cover the Isabelle commands which are used in this thesis. More
introduction and tutorials for writing specifications and proving theorems in Isabelle
can be found in [108].
3.5.2
Tactical Reasoning
As a LCF-style theorem prover, Isabelle uses the abstract datatype thm to represent
theorems. Soundness is guaranteed by the fact that the object of thm can only be derived from earlier thm objects using the primitive inference rules through the Isabelle
logic kernel.
The tactical mechanism is used to manipulate theorems. A tactic is a function from
a theorem to a sequence of possible consequent theorems, i.e.,
val tactic :
thm -> thm Seq.seq
Note that sequences are evaluated in a lazy fashion which means they can be potentially
infinite. The application of a tactic to a theorem fails when an empty sequence is
returned. To facilitate tactic development, Isabelle also provides tactic constructors
called tacticals. Tacticals take tactics as arguments to construct new tactics. Examples
of tactical are
val THEN : tactic -> tactic -> tactic
val ORELSE : tactic -> tactic -> tactic
where THEN constructs a new tactic by composing the given two tactics, and ORELSE
returns a tactic which tries the first tactic and then the second tactic in order and only
applies the first successful one. The tactical approach is an elegant and trustworthy
method for formal reasoning.
3.5. Isabelle
3.5.3
47
Event-B Proof Obligations in Isabelle
The Event-B Logic in Isabelle
The Event-B logic is formalised as a three-value logic on top of HOL [158]. The threevalue type is made by constructing the existing types with the type constructor option
(annotated with ↑). The option constructor extends type ‘α to SOME ‘α and NONE,
where NONE is used to represent ill-formed formulas. This process is called lifting.
Examples of lifted type bool and int are:
datatype bool↑ = SOME true | SOME false | NONE
datatype int↑ = SOME int | NONE
where bool↑ is defined as SOME true, SOME false or NONE. SOME true means that
a three-value predicate is true; SOME false represents that a three-value predicate is
false; and NONE is ill-formed, e.g, division by zero. All the Event-B formulas in Rodin
are represented as corresponding formulas in the three-value logic. In particular, predicates in Event-B are represented using the type bool↑. Additionally, some functions
are defined to evaluate the formulas in the type bool↑ to bool, so that users can do
proofs with these formula in HOL. The functions are shown as below:
T(ϕ) ≡ (ϕ = SOME true)
F(ϕ) ≡ (ϕ = SOME false)
WD(ϕ) ≡ (ϕ 6= NONE)
WT(ϕ) ≡ (ϕ 6= SOME false)
However, Isabelle’s automated proof techniques perform poorly for terms in the threevalue logic [158]. Consequently, a tactic called ebsimp’ [158] was developed to rewrite
all terms of three-value formula to HOL terms. This process is called unlifting. All
these terms in the three-value logic become terms in HOL with well-definedness predicates. To illustrate, consider the following lemma:
T((a ↑ . ÷ .b ↑). = .c ↑)
where a, b and c are integers, and operator ↑ lifts these integers to a three-value integer
type; . ÷ . and . = . are the corresponding division and equation operations in the three-
value logic. After unlifting, it turns into
b 6= 0 ∧ a ÷ b = c
48
Chapter 3. Background
where the inserted b 6= 0 is the well-definedness condition.
To get further advantage from the existing automatic proof techniques, a tactic tailored for Event-B proof obligations was developed [158], i.e. axe’. axe’ involves the
proof techniques in Isabelle such as simplifiers, classical reasoners and SMT solvers.
The improvement of proof automation was reported in [158, 157]. In this thesis, we
only target those POs which cannot be automatically proved by axe’. All the formalisation of the Event-B logic and the proof supports are organised in a theory called
EventB.
The Structures of the Exported Event-B POs
A PO is exported with required information, i.e,., type definitions and axioms for hypothesises. The structure of such a theory is shown in 3.10.
Carrier sets are declared as a global type in the theory with the keyword typedecl.
There are three locales to structure each PO. Two locales are used to maintain the
required information from the contexts and the machine: The locale, which is named
with the PO names and the postfix ‘ decls’, is to keep the information regarding to
constants, variables and local variables of the event which the PO belongs to. The
locale, which is named with the PO names and the postfix ‘ hyps’, is defined based
on the first locale, and to hold the required information regarding to axioms, invariant
and guards. The third locale is for the goal information. This locale is named with the
PO names and the postfix ‘ goal’. By using the parameters and assumptions from the
first two locales as proof context and using the goal information from the last local as
a goal, users can now prove POs with Isabelle.
3.6
IsaPlanner
IsaPlanner [64, 65] is a proof planner developed on top of Isabelle/HOL. The proof
states in IsaPlanner are represented by a data structure called reasoning state (RState).
Each RState contains contextual information, a proof plan and a reasoning technique
(RTechn).
The context information includes a proof context and the information for wave-
3.6. IsaPlanner
theory MACHINE NAME
imports “EventB”
begin
typedecl <CARRIER SET>
···
locale <PO 1 NAME> decls =
fixes <CONSTAN > :: <CONSTANT TYPE >
···
fixes <VARIABLE > :: <VARIABLE TYPE >
···
fixes <LOCAL VAR > :: <LOCAL VAR TYPE >
···
locale <PO 1 NAME > hyps = <PO 1 NAME > decls +
assumes: <AXIOM >
···
assumes: <INVARIANT >
···
assumes: <GUARD >
···
locale <PO 1 NAME> goal = <PO 1 NAME > decls +
assumes: <GOAL>
locale <PO 2 NAME > decls =
···
locale <PO 2 NAME > hyps = <PO 2 NAME decls > +
···
locale <PO 2 NAME> goal = <PO 2 NAME > decls +
end
Figure 3.10: The structure of an exported Event-B machine
49
50
Chapter 3. Background
rules and rippling measurements. A proof plan is also a data structure containing
information such as meta-variable instantiations for proofs, open and proved subgoals
for tracking proof progress, names for each subgoal and their assumptions. A RTechn
is a function from a RState to a sequence of RStates, i.e.,
val RTechn :
RState -> RState Seq.seq
A sequence of RStates is all the possible consequent RStates which are generated by
the application of the RTechn to the RState. If an empty sequence is produced, the
application of RTechn has failed. This mechanism is similar to tactics in Isabelle. IsaPlanner also provides an interface to conveniently encapsulate the tactics of Isabelle
to RTechns. Additionally, IsaPlanner provides a similar tactical mechanism to construct new RTechns from existing ones. The functions serves as RTechn constructor
are called RTechn combinators. An example of an RTechn combinator is as follows.
val thenr:
(RTechn * RTechn) -> RTechn
where thenr produces a new RTechn which applies the first RTechn and then applies
the second RTechn to the RStates produced by the first RTechn. When evaluating a
RState, IsaPlanner applies the RTechn in the RState to the RState to produce a sequent
of new RStates. These new RStates can be further evaluated in the same way until
there is no open subgoal or the RTechn produces a empty sequence.
3.7
IsaScheme
IsaScheme [142] can be used to invent new mathematical concepts and theorems. In
this section, we focus on the use of IsaScheme in theorem discovery. An example will
be given to illustrate the discovery process where IsaScheme uses the given arguments,
including schemes, a seeding pool and a proof method, to find theorems.
Schemes capture the shape of the desired theorems. In this example, we provide the
following three schemes.
∀a b c.F1 (F1 a b) c = F1 a (F1 b c)
(3.16)
∀a b.F1 a b = F1 b a
(3.17)
∀x.F1 a a = a
(3.18)
3.8. Summary
51
where a, b and c are local variables bound by the ∀ quantifiers; F1 is a scheme variable
(second-order variable); and the function arguments employ the curried style. Each
scheme captures different shapes, e.g. (3.16) is for associativity, (3.17) is for commutativity and (3.18) is for absorption. IsaScheme will then attempt to instantiate each
scheme-variable to one of the exact term in the provided seeding pool. In this example,
we give the following terms as a seed pool.
seeding pool = {∪, ∩, λ x, y. x, λ x, y. y}
Note that the operators in the seeding pool are, in fact, lambda terms. For instance, the
operators ∪ and ∩ are considered as λx, y.x ∪ y and λx, y.x ∩ y. Conjectures are pro-
duced by instantiating these schemes with the seeding pool. IsaScheme then disproves
or proves the conjectures to find theorems. For disproof, IsaScheme uses the integrated
two counter-example checkers, i.e., Quickcheck [19] and Nitpick [22]. Quickcheck randomly generates test cases to falsify conjectures, whereas Nitpick is a model checking
based counter-example finder. For proofs, IsaScheme applies the given proof methods
to prove conjectures. With the given automatic proof method, IsaScheme will return
the following 6 theorems.
a ∪ (b ∪ c) = (a ∪ b) ∪ c
a ∩ (b ∩ c) = (a ∩ b) ∩ c
b∪a=a∪b
b∩a=a∩b
a=a∪a
a=a∩a
3.8
Summary
In this chapter, we have presented the background materials for our work. We first
illustrated with examples for Event-B and rippling, followed by the conventions of
the use of curried and uncurried functions in ML. Furthermore, we have presented the
systems which our work is built on, such as Isabelle, IsaPlanner and IsaScheme.
Chapter 4
Applying Rippling and proof-patching
Techniques
4.1
Introduction
Event-B is a state-based and refinement-based formal methods technique to model and
reason about systems. This technique captures requirements into an abstract formal
specification and then stepwise refines them to the final product. At each step of development, proof obligations (POs) are generated to reason about the development
choices, e.g. to ensure internal coherence of the current abstraction and valid refinement. A majority of POs can be automated with Rodin’s proof automation support.
The proofs of the remaining small proportion of POs need human interactions. However, the proof automation is still a challenge for the industrial application of Event-B,
because even this small proportion of POs in a real industrial-size project can number
thousands. In this section we show that a part of the problem is a lack of meta-level reasoning since Rodin provers only work at the object-logic level. In [29], it was argued
that, to achieve a better understanding of reasoning, both object-level and meta-level
understanding are needed.
In Event-B a significant proportion of POs, which require human interaction, fall
into a family called INVariant preservation (INV). INV POs are generated to ensure
each invariant still holds after the changes made by an event in an Event-model. In the
case study of information flow policies for dynamic virtual organisations (IFP) [26],
30 out of 227 POs have to be proved interactively in Rodin, and 24 of these POs belong
to type INV.
53
54
Chapter 4. Applying Rippling and proof-patching Techniques
We observe that most INV POs that require human interaction, follow a pattern
that one of the invariants is embedded in the goal. For ease of presentation, we call this
invariant the embedding invariant, and call the corresponding hypothesis at the proof
level the embedding hypothesis. In IFP, all the 24 INV POs follow this pattern. We
will discuss why those INV POs which do not follow this pattern tend to be proved
automatically in §4.2.1. This pattern makes a meta-level reasoning technique applicable, i.e. rippling. Rippling contains the knowledge of how proofs should proceed,
i.e., rewriting towards the hypothesis which is embedded in the goal. This knowledge
is useful to develop proof-patching techniques for repairing proofs when rippling is
blocked.
In this thesis, we develop three proof-patching techniques to recover blocked rippling for Event-B INV POs. Namely, these three proof patches are ahLemma, Skeleton
Rewrite and Case Split. We use a similar proof-patching framework as in [30, 103]
and [111], which is shown in Figure 4.1. In this chapter we only introduce the Skeleton Rewrite and Case Split proof-patching techniques. The ahLemma proof-patching
technique will be presented separately in chapter 5, as ahLemma is the most important
proof patches among these three.
Rippling
rippling
applicable
blocked
Proof
Patches
Wave Steps
rippled
recovered
failed
Fertilisation
fertilised
Automatic
Proof Methods
Figure 4.1: Rippling with proof-patching techniques
The main contributions of this chapter are:
• to show that INV POs can be seen to be inductive proofs so that rippling is
blocked
Rippling
rippling
applicable
Wave Steps
recovered
Proof Patches
successful
successful
not applicable
Case Split
rippled
Fertilisation
Skeleton
Rewriting
not applicable
successful
4.2. INV POs and Rippling
55
applicable to those INV POs which are step cases.
• to develop two heuristics for the use of rippling in INV POs.
• to give an account of causes of failures in rippling for INV POs.
• to develop Skeleton Rewrite and Case Split proof patches.
In §4.2, we motivate and illustrate the use of rippling in Event-B INV POs with
examples, as well as the heuristics we employed for INV POs. In §4.3 we introduce the
Skeleton Rewrite and Case Split proof-patching techniques in details. For convenience
of presentation, we use
to represent the direction of rewrite rules, and use =
b for
a definition. To distinguish the use of the term ‘variable’ at the proof level and at
the Event-B modelling level, we call the use of ‘variable’ in Event-B modelling the
Event-B model variable in this chapter. The use of term ‘variable’ refers to variables
at the proof level. Note that we use the Event-B notations at the proof level. Also note
that the notation of object-logic level implication (⇒) in Event-B is shorter than the
notation of meta-level implication ( =⇒ ) in Isabelle, although they are very similar.
4.2
4.2.1
INV POs and Rippling
INV POs as Inductive Proofs
In Event-B, states are represented by Event-B model variables in machines. Events can
change states of Event-B models by assigning new values to Event-B model variables.
INV POs are then generated to verify that each invariant still holds after the state is
changed by an event. The shape of the goal of the Event-B INV POs can be described
as
inv(var10 , · · · , varn0 )
where var10 , · · · , varn0 are Event-B model variables of a Event-B model after being
changed by an event, and inv is a predicate for an invariant which takes Event-B model
variables as parameters. Note that, (0 ) is used to indicate the post state of a variable.
Generally speaking, an event can change Event-B model variables in the following two
cases:
1. assigning a constant value, e.g. vari0 = 1; or
56
Chapter 4. Applying Rippling and proof-patching Techniques
2. updating a new value based on the current value, e.g. vari0 = vari + 1.
Note that the discussion here focuses on the cases of deterministic events. For the nondeterministic events, some additional processes are required to transform them to the
shape discussed above. We will discuss them in future work in §8.3. In case (1), the
shape of the goal of the INV PO becomes
inv(const1 , · · · , constn )
(4.1)
A typical example of case (1) is the INV POs generated by the INITIALISATION event.
In case (2), assume that the Event-B model variables before being changed by an event
are var1 , · · · , varn , the shape of the goal of the INV PO then can be described as:
inv(F1 (var1 ), · · · , Fn (varn ))
(4.2)
where F1 , · · · , Fn are functions returning a new value based on a given value. Note
that this INV PO follows the pattern of step cases of inductive proofs, i.e. one of the
hypotheses is embedded in the goal, i.e.,
↑
↑
inv(var1 , · · · , varn ) ` inv( F1 (var1 ) , · · · , Fn (varn ) )
(4.3)
These two shapes fit the pattern of inductive proofs, where the INV POs generated in
shape (4.1) can be considered as base cases, and the INV POs in shape (4.3) can be
considered as steps cases. Moreover, we argue that INV POs do not only syntactically
follow the pattern of inductive proofs, they are in fact inductive proofs, because they
can be considered as an induction of the length of traces of Event-B models. For this
reason, the meta-level reasoning technique, i.e. rippling, which was originally developed for step cases of the inductive proofs, is applicable to those INV POs in shape
(4.3). Moreover, we also observe that the INV POs which need human interaction are
mainly in shape (4.3). For instance, in IFP, all 24 of interactively proved INV POs are
of shape (4.3). This observation conforms to the intuition that step cases are usually
more complex than base cases in inductive proofs.
Shape 4.3 contains general patterns of the rippling annotations. The annotation
↑
consists of two parts: the wave-front ( Fi (...) ) and the wave-hole (vari ). For each
Event-B action which updates a variable (vari ) in an event, it can be considered as a
Fi (...). Therefore, a wave-front will be inserted for each Fi (...), and the updated variable vari will be annotated with a wave-hole.
4.2. INV POs and Rippling
4.2.2
57
Applying Rippling
The key strategy to prove step cases of inductive proofs is to rewrite the goal towards
the embedding hypothesis, until the hypothesis becomes applicable to simplify the inductive conclusion. Rippling uses this strategy as a meta-level guidance to improve
automation for inductive proofs. To illustrate how rippling works for INV POs, consider invariant CallersDef in Figure 3.3, i.e.,
Callers = dom((call ; st) BConnected)
(4.4)
In event LiftFree from the same Event-B model, Event-B model variable call is updated based on its previous state, i.e.,
call := call ∪ {(s 7→ (seize 7→ NULL))}
The generated INV PO for invariant (4.4) and event LiftFree is in shape (4.3), i.e.,
inv4.4 (Callers, call)
`
(4.5)
↑
inv4.4 (Callers, F (call) )
where inv4.4 is
λx, y. x = dom((y ; st) BConnected)
and F is
λx.x ∪ {(s 7→ (seize 7→ NULL))}
Therefore, this INV PO with the rippling annotations is
Callers = dom((call ; st) BConnected)
`
(4.6)
↑
Callers = dom(( call ∪ {(s 7→ (seize 7→ NULL))} ; st) BConnected)
Recall that, for each wave-step, the skeleton (i.e., the non-boxed and the underlined
parts) in a goal should be preserved, and a ripple measure must decrease, e.g. the
skeleton parts which are separated by wave-fronts (i.e. the boxed parts) are moved together. To illustrate the use of rippling in INV PO 4.6, we assume having the following
wave-rules:
58
Chapter 4. Applying Rippling and proof-patching Techniques
↑
( f ∪ g) ; S
( f ; S) ∪ (g ; S)
↑
( f ∪ g) B S
dom ( f ∪ g)
↑
↑
( f B S) ∪ (g B S)
(4.7)
↑
dom( f ) ∪ dom(g)
(4.8)
↑
(4.9)
The following proofs show how rippling guides parts of the skeleton moving together
and wave-fronts moving outwards, until the invariant becomes applicable for fertilisation.
INV:
Callers = dom((call ; st) BConnected)
↑
GOAL: Callers = dom(( call ∪ {(s 7→ (seize 7→ NULL))} ; st) BConnected)
⇓ by (4.7)
↑
Callers = dom( ((call ; st) ∪ ({(s 7→ (seize 7→ NULL))} ; st)) BConnected)
Callers =
⇓ by (4.8)
↑
dom( (call ; st BConnected) ∪ ({(s 7→ (seize 7→ NULL))} ; st) BConnected )
Callers =
⇓ by (4.9)
dom((call ; st) BConnected) ∪ dom(({(s 7→ (seize 7→ NULL))} ; st) BConnected)
↑
by weak fertilisation
⇓ to substitute dom((call ; st) BConnected)
with Callers
Callers = Callers ∪ dom(({(s 7→ (seize 7→ NULL))} ; st) BConnected)
The goal has now been rippled. For the remaining proofs, as st projects (s 7→ (seize 7→
NULL)) to (s 7→ seize) and seize is not in Connected, the following subterm in the goal
(({(s 7→ (seize 7→ NULL))} ; st) BConnected)
can be simplified to ∅ by strong fertilisation, which completes this proof. Note that
weak fertilisation is applicable in the very beginning of the proofs before applications
of any wave-rules. However, we delay the applying of weak fertilisation until both
LHS and RHS have been fully rippled. We will explain the choice of this heuristic in
§4.2.3.
4.2. INV POs and Rippling
4.2.3
59
Heuristics for the INV POs Domain
In this subsection we present two heuristics which we use to tailor rippling for INV
POs. The motivation of these heuristics are that there are still some differences for
INV POs compared to the goals in traditional inductive theories, i.e. the theory of list.
We show both these differences together with the related heuristics as follows. For
ease of presentation, we show the definition of each heuristic first, followed by the
motivations and explanations.
Heuristic 4.2.1 (Rippling-out only). Only the direction of rippling out-wards is considered for INV POs.
Recall that there are two directions in rippling, i.e. outwards and inwards. From
the decorated term tree representation, rippling-out moves the wave-fronts upwards to
the root node of the term tree; rippling-in moves wave-fronts downwards to a position
of a sink, which corresponds to universally quantified variables in the given. Although
rippling supports both directions, from our empirical experiments, rippling-in happens
rarely for INV POs. In fact, we didn’t manage to find any evidence for rippling-in in
our experiments. Hence, we constrain the direction of rippling to outwards only for
INV POs. The point of this constraint is to limit the search space for the lemma conjecturing for ahLemma, which will be discussed later in chapter 5. This constraint also
helps us to filter out irrelevant causes of failures when we analyse types of failures, for
INV POs in §4.3.
Heuristic 4.2.2 (Eager Rippling). For equation-based goals, weak fertilisation is allowed to apply only if both LHS and RHS have been fully rippled.
Definition 4.2.1 (Fully Rippled). A term t is called full rippled if all the wave-fronts
of t have moved to the root node of the decorated term tree of t 1 .
For equation-based goals, weak fertilisation intends to apply when either one side
is fully rippled. It uses the embedding hypothesis as a rewrite rule to simplify the subterms that are fully rippled. It makes fertilisation applicable when either LHS or RHS
has been fully rippled and the other one cannot be fully rippled, where strong fertilisation cannot be applicable.
1 Note
that because of the rippling heuristic I, we only consider the cases of rippling-out.
60
Chapter 4. Applying Rippling and proof-patching Techniques
However, weak fertilisation turns out to be a potential problem for the best use of
rippling in INV POs. This is because equation-based invariants can be defined in a way
that one-hand-side is simple but the-other-hand-side is non-trivial.The one-hand-side
can easily become fully rippled so that weak fertilisation is applicable. In an extreme
case, the one-hand-side is fully rippled even when rippling starts, e.g. INV PO (4.6).
Applying weak fertilisation in too early stages of proofs might not contribute much
to simplification of INV POs. Take the INV PO (4.6) for example, if we apply weak
fertilisation in the first proof step, the goal of the INV PO becomes
dom((call ; st) BConnected) =
↑
dom(( call ∪ {(s 7→ (seize 7→ NULL))} ; st) BConnected)
which is still non-trivial to discharge. Therefore, we restrict the applicability of weak
fertilisation to the situation only when both LHS and RHS are fully rippled to prevent
a goal from being fertilised when one is fully rippled and the other one is stuck. Although, with this restriction, an equation-based INV PO would become blocked rather
than fertilised, if there is no applicable wave-rule. Instead of a fertilised but non-trivial
goal, a blocked INV PO is more preferable, because we can try to recover the blocked
rippling using proof patches, which are the techniques developed based on the metalevel guidance provided by rippling. We will discuss the proof-patching techniques for
INV POs in the coming section.
4.3
4.3.1
Proof-patching Techniques
A Profile of Types of Failures
At each wave step, the skeleton is preserved and a ripple measure must decrease.
Hence, rippling always terminates either in a fertilised state or a blocked one. To
recover blocked rippling, [30, 103] systematically investigated failures of rippling in
inductive theories, and also categorised those failures into 4 types. For each type of
failure, proof critic was developed to recover failures in the same type. These 4 types
of failures and the corresponding proof critics are summarised in Table 4.1. More details about these critics have been reviewed in §2.6.
We develop a profile of types of failures for INV POs based on the types of the
4.3. Proof-patching Techniques
61
Types of failures
Proof critics
Effect
(a) An incorrect induction
The revising in-
To suggest an alternative in-
rule is applied
duction critic
duction rule
(b) A sink is missed to absorb
The
To insert a sink by generalisa-
wave-fronts
tion critic
tion
(c) No unconditional wave-
The case analyses
To suggest a case-split from
rule can be applied, however,
critic
the unproven condition
(d) There is no applicable
Lemma calcula-
To
wave-rule
tion, lemma spec-
wave-rules
generalisa-
there is an applicable conditional wave-rule, but failing
to prove the condition of the
wave-rule
conjecture
applicable
ulation
Table 4.1: Proof critics and the corresponding types of failures
failures of the proof critics. Not all types of failures are relevant in the INV POs
domain in this project, i.e. types (a) and (b), because:
• for type (a): Recall that in §4.2.1 we discussed two cases in which events change
the variable. The values of variables in an Event-B model, can be defined as
vari =
b consti 1 | · · · | consti n
| Fi 1 (vari ) | · · ·
| Fi n (vari )
This recursive definition can be used to define an inductive rule. The failures in
type (a) suggest that an incorrect induction rule might be applied. Typically, this
type of failures results in the failures in proving step cases. Also typically, the
patch suggests an alternative induction rule which leading to a different step case
to prove In the INV POs domain, these failures can be interpreted as one of Fi i
is not appropriate. Therefore, the generated INV POs which can be considered
as step cases are difficulty to discharge. The corresponding patch is to revise
Fi i which requires changes to Event-B models. This belongs to the approach
of turning failed proofs into modelling guidance [105]. As changing Event-B
62
Chapter 4. Applying Rippling and proof-patching Techniques
models is not our focus in this thesis, and in this thesis we assume that EventB models are correct and well-developed, type (a) is not an appropriate type of
failure in this project, although failures in this type are likely.
• for type (b): As rippling will not move inwards, there is no situation for which
a sink is required, i.e., type (b) is not needed for INV POs. Moreover, this type
of failures can be interpreted as that an Event-B model is incorrect due to an
inappropriate invariant. Here, the inappropriate invariant means the invariant
is over-restrictive but the rest of the model is still correct. The generalisation
critic then can be seen as a generalisation of the over-restrictive invariant. In
this project, we only focus on the proof aspect, and we assume that Event-B
models are complete and correct. This type of failure belongs to the domain of
the modelling critic, and is beyond the scope of this project.
Therefore, we only adopt types (c) and (d) into our profile of types of failures for
INV POs. The proof patch for the failures in type (d) is to attempt to discover a lemma.
However, it is generally difficult to identify the existence of such a lemma. Therefore,
we would like to apply some other solutions, which are more light-weight, before starting exploring the missing lemmas. We notice that, in some blocked proofs, rippling
can be recovered by unfolding the definitions of the non-recursively defined operators
in both the hypotheses and the goal. This unfolding offers an additional type of patch
for type (d) failures. We separate those failures to which this unfolding is applicable
as a third type of failure of type (d). We will discuss this type of failure later in §4.3.2.
We combine this new identified type together with types (c) and (d) as a profile of
types of failures in the INV POs domain. This profile is shown in Table 4.2. Note that
types (ii) is type (c), type (iii) is type (d). To address each type of failure, we develop a
proof patch to recover proofs for each type. For type (i) and (ii), We used an empirical
approach by analysing existing failed proofs to identify patterns which cause failures
in type (i) and type (ii) for their patches. We then used these patterns to develop the
related patches and the preconditions for these two types. For type (iii), as we cannot
know the existence of such a wave-rule upfront, all the failed proofs, which are not
captured by the preconditions of the patches of types (i) and (ii), are considered as
failures of type (iii). Therefore, when a failure occurs, we try to recover failures with
the proof patches for (i) and (ii) first, followed by the patch (iii).
4.3. Proof-patching Techniques
Types of failures in INV POs
63
Proof
Effect
patches
(i) No applicable wave-rule is available
Skeleton
To rewrite the embed-
to proceed, but rippling can be recovered
Rewrite
ding hypothesis and the
by unfolding the definitions of operators
skeleton.
in both the embedding hypothesis and the
skeleton.
(ii) No applicable unconditional wave-
Case Split
To suggest a case-split
rule is available to proceed, however,
from the unproven con-
there is an conditional wave-rule where
dition
the lhs of the wave-fronts and the wavehole match the goal, but the condition of
this wave-rule is not provable.
(iii) No applicable wave-rule is available
to proceed, but there might exist such a
ahLemma
To conjecture applicable wave-rules.
wave-rule which is yet to be discovered.
Table 4.2: A profile of types of failures and our proof patches for INV POs
Figure 4.2 is a refined framework from the one in Figure 4.1, where the proof patch
for type (i) is Skeleton Rewrite, the patch for type (ii) is Case Split and the patch for
type (iii) is ahLemma. Note that the order of Skeleton Rewrite and Case Split is not
important.
Briefly, Skeleton Rewrite can be used to identify the operators over which no waverules are available to ripple wave-fronts. This patch rewrites the problematic operator
in the hypothesis and the goal so that an alternative embedding is suggested. Case Split
can be used to identify patterns when case split is needed, and to suggest a case split
automatically. ahLemma is a more general proof patch to recover rippling by trying
to conjecture missing wave-rules. Skeleton Rewrite is presented in 4.3.2, Case Split is
discussed in 4.3.3. ahLemma is not covered in this chapter but in chapter 5.
4.3.2
Skeleton Rewrite Patch
In each wave step, rippling requires an application of a wave rule to ripple wave-fronts
past an outer skeleton, while the whole skeleton must be preserved and a rippling
64
Chapter 4. Applying Rippling and proof-patching Techniques
blocked
Rippling
rippling
applicable
Wave Steps
Proof Patches
successful
recovered
Skeleton
Rewriting
not applicable
successful
Case Split
rippled
not applicable
Fertilisation
successful
AhLemma
fertilised
failed
Automatic
Proof Methods
Figure 4.2: Rippling with detailed proof-patching techniques
measure must decrease. However, for some operators in Event-B, the rewrite rule,
which can both simplify goals and satisfy the skeleton preservation rule, is not always
available.
For example, for the following rippling goal:
↑
P (x) ` P ( H (x) )
rippling will be blocked, if no rewrite rule is available to ripple the wave-front over P .
↑
P ( H (x) )
Q (P (x))
↑
Intuitively, we need to discover the missing rewrite rule to ripple the wave-front over
P . However, the existence of such a rewrite rule is unknown. In some cases, a more
light-weight solution is to relax the skeleton preservation rippling constraint, and allow
to rewrite the occurrences of the problematic operators, e.g. P , in the hypothesis as
well as in the goal, so that these problematic operators are replaced by other operators
for which there might be wave-rules. Type (i) describes the failures where rippling is
blocked caused these problematic operators2 , e.g. P .
We used an empirical approach to survey all the Event-B operators to identify those
operators in this type of failures. We first made experiments with INV POs to collect
failures of type (i). With these failures, we provided rewrite rules for Skeleton Rewrite
2 The
needs for allowing rewriting the embedding hypothesis to suggest an alternative embedding for
rippling is also suggested by Alan Bundy in BBN 778.
4.3. Proof-patching Techniques
65
as a proof patch to recover rippling. Also we generalised preconditions to trigger the
proof patch. Note that the termination property is still preserved with these rewrite
rules, we will show the proofs of termination later in this section.
A pattern for the relations-based datatype constructors
!
7
$
$
$
Partial Functions(
) : Relations(
) + Functional
$
Total Relations(
): Relations(
)+ Total
!): Relations( ) + Surjective
Surjective Relations($
$): Relations( ) + Total + Surjective
Total Surjective Relations($
Total Functions(!): Relations(
) + Functional + Total
7 ): Relations( ) + Functional + Injective
Partial Injections(⇢
7 ): Relations( ) + Functional + Surjective
Partial Surjections(⇣
Total Injections(⇢): Relations(
) + Functional + Total + Injective
Total Surjections(⇣): Relations(
) + Functional + Total + Surjective
Bijections(
): Relations(
) + Functional + Total + Injective + Surjective
⇢
⇣
$
$
$
$
$
$
$
Figure 4.3: A list of relations-based datatype constructors in Event-B
From our experiments, we identified a family of operators which blocked rippling with causes of type (i). For ease of presentation, we call this family of operators relations-based datatype constructors, as these operators are datatype constrictors
which are defined based on the relations (↔) operator. Figure 4.3 shows a list of these
operators. A lattice order for the operators in this family is also available in Appendix
B.
The basic operator of all relations-based datatype constructors is relations (↔).
Note that, except for relations, all the remaining operators are defined on top of relations with the properties such as total, functional, injective and surjective. The relations
operator takes two sets as parameters to construct a set of relation between the given
two sets, i.e.,
param set1 ↔ param set2
where param set1 and param set2 are two sets for parameters. Recall that in Event-B,
each set can be a datatype. Hence, the relations operator constructs a datatype for a
relation between two objects with the given datatypes. Similarly, the remaining operators of relations-based datatype constructors can construct the related datatypes in
66
Chapter 4. Applying Rippling and proof-patching Techniques
the same way. For convenience of presentation, we call these datatypes, which are
constructed by relations-based datatype constructor, as relations-based datatypes.
Relations-based datatypes are commonly used to model relationship in Event-B.
For each variable with a relations-based datatype, an invariant of the following shape
is required to constrain the datatype for the variable.
var name∈ param set1 relations-based-datatype-constructors
param set2
where var name is a variable with a relation-base datatype, and param set1 and param set2
are parameters to construct a relation-base datatype. An example of such an invariant
is the invariant callTyp from the Event-B model in Figure 3.3, i.e.,
call ∈ Subs →
7 (Status × Subs)
(4.10)
where call is defined as a partial function from set Subs to set (Status × Subs).
The problem is that when param set1 or param set2 is changed by Event-B events,
there is not always an applicable wave rule to ripple the wave-front param set1 or
param set2 over the relations-based datatype constructors. This is a shared problem
for all the members of the relation-based family. The core of the problem is that the
fundamental operator relations(↔) is defined by operator powerset , i.e.,
M↔N =
b P(M × N)
and it is non-trivial to have applicable unconditional lemmas as wave-rules to ripple
the wave-front over the powerset operator. That is, in most case, the required rewrite
rule is conditional and its applicability depends on the current proof context. To address this problem for all the relations-based family members, we relax the skeleton
preservation constraint and suggest new embeddings for the goal. This is achieved by
allowing to rewrite the embedding hypothesis and the skeleton part of the goal, so that
the problematic operators can be replaced by other operators for rippling. Figure 4.4
shows a list of rewrite rules for this purpose, and Figure 4.5 shows the details of the
skeleton rewrite patch. Note that none of these rewrite rules are defined recursively,
as a recursive rewrite rule would be a wave-rule. These rewrite rules are essentially
an unfolding of the non-recursive definition. They are generally applicable to rewrite
those relations-based datatype constructors, as long as the preconditions described in
Figure 4.5 are satisfied.
4.3. Proof-patching Techniques
↔ simp : r ∈ M ↔ N
67
(dom(r) ⊆ M ∧ ran(r) ⊆ N)
↔
→ simp : r ∈ M ↔
→N
(dom(r) ⊆ M ∧ ran(r) = N)
←
↔ simp : r ∈ M ←
↔N
(dom(r) = M ∧ ran(r) ⊆ N)
↔
↔ simp : r ∈ M ↔
↔M
(dom(r) = A ∧ ran(r) = B)
→
7 simp : f ∈ M →
7 N
7 simp : f ∈ M 7 N
( f unctional f ∧ dom( f ) ⊆ M ∧ ran( f ) ⊆ N)
( f unctional f ∧ in jective f ∧ dom( f ) ⊆ M ∧ ran( f ) ⊆ N)
7 simp : f ∈ M 7 N
( f unctional f ∧ dom( f ) ⊆ M ∧ ran( f ) = N)
→ simp : f ∈ M → N
( f unctional f ∧ dom( f ) = M ∧ ran( f ) ⊆ N)
simp : f ∈ M N
simp : f ∈ M N
simp : f ∈ M N
( f unctional f ∧ in jective f ∧ dom( f ) = M ∧ ran( f ) ⊆ N)
( f unctional f ∧ dom( f ) = M ∧ ran( f ) = N)
( f unctional f ∧ in jective f ∧ dom( f ) = M ∧ ran( f ) = N)
Figure 4.4: Rewrite rules for relations based data types
Preconditions:
1. Rippling is blocked;
2. The skeleton matches the pattern
R ∈ M relation based datatype constructors N
3. There is at least one wave-front in M or N
4. Any wave-fronts in M and N have been fully rippled in M and N, i.e., there is no skeleton
outside the wave-fronts in M and N.
Applying the Patch:
1. Apply the related relation based datatype constructors rewrite rule to the embedding hypothesis.
2. Apply the same rewrite rule to the goal.
3. Eliminate the conjunctions generated by the rewrite rule for both the hypothesis and goal.
4. Re-compute the embedding for every subgoal.
Figure 4.5: Pseudo code of the Skeleton Rewrite patch
Example
To illustrate the use of this patch, consider the event RegisterSubs in Figure 3.3. The
following INV PO is generated for the invariant (4.10).
call ∈ Subs →
7 (Status × Subs)
`
↑
↑
7 (Status × (Subs ∪ {s}) )
call ∈ (Subs ∪ {s}) →
68
Chapter 4. Applying Rippling and proof-patching Techniques
Rippling is eventually blocked at the following state,
call ∈ Subs →
7 (Status × Subs)
`
(4.11)
↑
call ∈ (Subs ∪ {s}) →
7 (Status × Subs ∪ (Status × {s})
↑
because there can be no such a wave-rule to ripple either wave-front over the →
7 op-
erator. The Skeleton Rewrite patch is triggered, as the preconditions in Figure 4.5 are
satisfied:
• rippling is blocked
• the skeleton, which is call ∈ Subs →
7 (Status × Subs) satisfies the pattern described in precondition (2).
• both (Subs ∪ {s})
↑
and (Status × Subs ∪ (Status × {s})
↑
contain a wave-front,
and both have been fully rippled.
By applying the related skeleton rewrite rule (→
7 simp) to both the goal and the em-
bedding hypothesis, it becomes
f unctional call ∧
dom(call) ⊆ Subs ∧
ran(call) ⊆ Status × Subs
`
f unctional call∧
dom(call) ⊆ (Subs ∪ {s})∧
ran(call) ⊆ (Status × Subs) ∪ (Status × {s})
We then continue to eliminate the ∧ in the embedding hypothesis and the goal,
follows by computing embedding for each subgoal. This step of ∧-elimination and
re-computing embedding is from the rewrite rule in piecewise fertilisation [8], i.e.,
A0 ` A B0 ` B
A0 ∧ B0 ` A ∧ B
where A0 is embedded in A and B0 is embedded in B. Each application of this rewrite
rule can produce two simpler subgoals, because each subgoal has a smaller embedding
4.3. Proof-patching Techniques
69
compared to the original one. After this step, the PO then becomes three rippling
subgoals:
f unctional call ` f unctional call
dom(call) ⊆ Subs ` dom(call) ⊆ (Subs ∪ {s})
↑
ran(call) ⊆ Status × Subs ` ran(call) ⊆ (Status × Subs ∪ (Status × {s})
↑
Note that the problematic relation-based operator has been removed, so that rippling
can now continue and eventually finish the proof. For the first subgoal, strong fertilisation will be applied to prove it; For the second and third ones, they will still be
blocked, but the lemma conjecturing proof patch, i.e. ahLemma, will then be triggered
to conjecture the following two lemmas so that rippling can be completed and strong
fertilisation can also be applicable for them.
dom(call) ⊆ (Subs ∪ {s})
↑
dom(call) ⊆ Subs
ran(call) ⊆ (Status × Subs ∪ (Status × {s})
↑
ran(call) ⊆ Status × Subs;
Note that, the proof-patching technique of ahLemma will be presented in chapter 5, so
we are not giving more details of how there are conjectured in this chapter.
It is worth mentioning that the termination property still holds for this proof patch
although we allow rewriting skeletons. This is because Skeleton Rewrite is essentially
an unfolding of non-recursive definitions, and Skeleton Rewrite only applies to unfold
the definitions of operators of the relations-based datatype constructors. Each rewrite
removes one occurrence of these operators and they are only applicable when such
operator exists, so process terminates.
4.3.3
Case Split Patch
To discharge Event-B POs, there are cases when a case split is required so that proofs
can be continued. The interactive proof interface of Rodin also provides an operation,
called ‘dc’ for users to apply case splits. In [30, 103], a proof patch, i.e. the case
analyses critic, was developed to suggest a case split on the unproven conditions when
rippling is blocked but a conditional wave-rule is applicable. The feature of this critic
can be used to automatically suggest the necessary case splits for INV POs, if we can
provide proper conditional wave-rules where:
70
Chapter 4. Applying Rippling and proof-patching Techniques
• the conditional wave-rules capture the patterns when case split is required. In
another words, the conditional wave-rules become applicable when case split is
needed.
• the condition relates to the required case split.
We use an empirical approach to collect the conditional wave-rules for the patterns
where case split is needed. With the collected patterns, we develop a Case Split proof
patch which combines the case analyses critics with some additional processes for INV
POs. These additional processes are to optimise the use of the case analyses critic for
INV POs. We first introduce the patterns which we captured for case split, followed
by the motivation and descriptions for the additional processes.
Conditional rewrite rules for the case split patterns
The patterns correspond to a subset of the relations-based datatypes, which contain the
functional properties or the injective property. The functional property constrains any
two distinct elements in the range of a relation to be always mapped to distinct elements in the domain of the relation. The injective property constrains any two distinct
elements in the domain of a relation to be always mapped to distinct elements in the
range of the relation.
A typical use of the functional property and the injective property in an invariant
is with the function application operator. In the case of the functional property, this
typical use is f (x) = ..., and r ∼ (x) = ... for the injective property, where ∼ is an
inverse operator relation that relates an element y to x if the original relation r relates x
to y.
When updating an Event-B model variable f for an element a in the domain of f ,
e.g. f C
− {(a 7→ b)}, an INV PO of the following shape will be generated.
(f C
− {(a 7→ b)})(x) = ...
For variable r, which is in a relations-based datatype containing the injective property,
the update is e.g. r C
− {(b 7→ a)}, and the corresponding INV PO is
(r C
− {(b 7→ a)}) ∼ (x) = ...
4.3. Proof-patching Techniques
71
In order to proceed with the proof, a current strategy to simplify this pattern of POs
in Rodin is to interactively apply a case split, e.g. a case split on x = a, then further
simplify the two subgoals respectively. This strategy was documented as a proof tactic
in Rodin [155], but only for the case of relation f with the functional property.
funcapp C
− functional:
Complementary
condition: x = a ∨ x 6= a

↑

(1) [x 6= a; f unctional f ; x ∈ dom( f )] =⇒ f C
− {(a 7→ b)} (x)

(2)
↑
[x = a; f unctional f ] =⇒ f C
− {(a 7→ b)} (x)
f (x)
↑
b
funcapp C
− injective:
Complementary
condition: x = a ∨ x 6= a



(1) [x 6= a; in jective r; f unctional (((r C
− {(b 7→ a)}) ∼));






x ∈ dom((r C
− {(b 7→ a)}) ∼); x ∈ dom(r ∼)]



↑
↑
⇒ ( (r C
− {(b 7→ a)}) ∼)(x)
r ∼ (x)






(2) [x = a; in jective r; f unctional ((r C
− {(b 7→ a)}) ∼)]



↑


− {(b 7→ a)}) ∼)(x) b
⇒( (r C
Figure 4.6: Wave-rules and rewrites for the Case Split proof patch
A proof patch based on the case split critic
Conditional rewrite rules are used to capture the patterns we discussed above. A conditional rewrite rule is represented in the following format
[Cond1 ; · · · ; Condn ] =⇒ LHS
RHS
where [Cond1 · · ·Condn ] are a list of conditions which are required to be satisfied in
order to apply rewrite, LHS is the term to be rewritten, and RHS is the term after
rewriting.
We provide a complementary pair of conditional rewrite rules for each pattern, as
shown in Figure 4.6. As described in §3.4.2, a complementary pair is two conditional
rewrite rules with same LHS, different RHS and and complementary conditions. If a
72
Chapter 4. Applying Rippling and proof-patching Techniques
case split is introduced on these complementary conditions, then each rewrite rule of
a complementary pair enables continued rippling in one of the resulting cases. Note
that only the first condition is related to the case split. We call this condition the case
split condition. The remaining conditions are generated for the well-definedness of the
function application operator. That is, for a given term with function application operator f (x), f has to be functional and x has to be in the domain of f , i.e. f unctional f
and x ∈ dom( f ). These well-definedness conditions can always be easily proved as
long as the LHS of the rewrite rule is matched. Therefore the presence of these conditions does not affect the property of complementary conditions.
With the provided complementary pair, the case analyses critic can suggest a case
split on the complementary condition, and then apply the corresponding rewrite rule
with a matched case split condition. However, in the INV POs domain, the case analyses critic can fail for two reasons. We will show the causes of these two issues first
and then show how we address them.
(i) case split cannot be applied, when the variable x in case split condition is bound by
a quantifier, e.g.,
↑
∀x. ( f C
− {(a 7→ b)}) (x) = ...
Note that the possible quantifier bound variables can only be the variables in
skeletons. This is because at the proof level, the variable for the Event-B model
variables, constants and parameters are global. The only possible local variables
are the ones defined as part of invariants, e.g. x.
(ii) The second rewrite rule of a complementary pair is not a wave-rule, as skeleton is
not preserved. However, the resulting subgoal after applying the second rewrite
rule can be rippling applicable when the variable b of the second rewrite rule of
the pair is unified as a term in the shape of F ( f (a)), where F is a higher-order
variable. For example,
(f C
− {(a 7→ f (a) + 1)})(x) = ...
With the fact that a = x, the unified term can also be rewritten to F ( f (x)) where
the rippling skeleton is preserved. Rippling can then be applied to this subgoal.
To address these two problems, we introduce two additional processes. For problem (i), we check if the case split condition contains bound variable before applying a
4.3. Proof-patching Techniques
73
case split. If there is any bound variable, we then instantiate both the bound variables
in the goal and the embedding hypothesis to a same fresh variable in the right order. In
the case of quantifier ∀, we introduce a fresh variable to instantiate the bound variable
in the goal, then instantiate the corresponding variable to the same fresh variable in the
embedding hypothesis. The reason that we can instantiate both bound variables in the
goal and the hypothesis to the same fresh variable is because, with heuristic (4.2.3), i.e.
rippling-out only, the bound variable will not be instantiated to some existing terms by
rippling-inward. The instantiated fresh variable have to be the same, because we wish
to maintain the embedding between the goal and the embedding hypothesis. For problem (ii), the basic idea of our solution is to substitute the corresponding term a with x
in the corresponding term b, e.g. b[a/x], before applying the second rewrite rule of a
complementary pair. We then can check if the rewrite rule after substitution preserves
the skeleton so that rippling can proceed.
We developed a case split patch based on the case analyses critic with the two
additional processes discussed above. Figure 4.7 shows the pseudo code for this patch.
Example
To illustrate the use of this patch, consider the invariant incomingDef from the telephone exchange example in Figure 3.3.
∀x.x ∈ dom(incoming) ⇒ x ∈
/ incoming(x)
(4.12)
With the changes made by the event DialNum, the following INV PO is generated for
the invariant (4.12),
∀x.x ∈ dom(incoming) ⇒ x ∈
/ incoming(x)
`
∀x.x ∈ dom (incoming C
− {ds 7→ (incoming(ds) ∪ {s})})
↑
(4.13)
↑
− {ds 7→ (incoming(ds) ∪ {s})}) (x)
⇒x ∈
/ (incoming C
Rippling is now blocked as no wave-rule is applicable. The case split patch is then
triggered, because
↑
• the subterm (incoming C
− {ds 7→ (incoming(ds) ∪ {s})}) (x) in the goal matches
the LHS of the complementary pair funcapp C
− functional, i.e.,
↑
fC
− {(a 7→ b)} (x).
74
Chapter 4. Applying Rippling and proof-patching Techniques
Preconditions
1. Rippling is blocked;
2. There is a complementary pair whose LHS matches the blocked goal
3. The case split conditions of both rewrite rules of the matched complementary pair are not
provable
Applying the Patch:
unify LHS with the goal term to produce a unified complementary
condition which all the variables are unified to the terms of the goal
check whether the unified complementary
condition contains a quantifier bound variable.
N
Y
instantiate the quantifier bound variable
both in the goal and the embedding
hypothesis to the same fresh variable.
For the case of a universal quantifier,
instantiate the variable in the goal
followed by the one in the invariant; And
instantiate an existential quantifier in the
opposite order.
apply a case split on the unified
complementary condition to
produce two subgoals
match the rewrite rules of the
complementary pair with the subgoals
by checking the case split condition of
each rewrite rules
for each rewrite rule, check whether the rewrite rule is a wave-rule
Y
N
unify LHS with the goal term to get
a unified RHS
use the rewrite rule as a waverule to continue rippling for the
matched subgoal.
check whether the unified RHS preserves the skeleton
N
Y
apply the rewrite rule
directly to continue
rippling.
check whether the case split condition is in the shape
of X = Y or Y = X, where X is a subterm of the skeleton
of LHS and Y is a subterm of wave-front of LHS.
Y
N
substitute all the occurrences of Y with X in the unified RHS, i.e., unified RHS[Y/X]
check whether the unified RHS[Y/X] preserves the skeleton
Y
conjecture and prove a new rewrite rule with RHS[Y/X],
i.e., unified LHS = unified RHS[Y /X ]
N
apply the rewrite rule to
the matched subgoal.
Rippling is ended for the
resulting subgoal.
apply the conjectured rewrite rule to the subgoal to continue rippling
Figure 4.7: Pseudo code of the Case Split patching technique
4.3. Proof-patching Techniques
75
• neither x = ds nor x 6= ds is provable.
By unifying the LHS of funcapp C
− functional with the matched subterm, f be-
comes incoming, a becomes ds, b becomes (incoming(ds) ∪ {s})and x becomes x.
The related complementary condition is unified as x = ds ∨ x 6= ds. As x is a quantifier
bound variable, we then instantiate this variable for the goal and the hypothesis. The
INV PO (4.13) now becomes
x0 ∈ dom(incoming) ⇒ x0 ∈
/ incoming(x0 )
`
x0 ∈ dom (incoming C
− {ds 7→ (incoming(ds) ∪ {s})})
(4.14)
↑
↑
⇒ x0 ∈
/ (incoming C
− {ds 7→ (incoming(ds) ∪ {s})}) (x0 )
and the corresponding complementary condition becomes x0 = ds ∨ x0 6= ds, and no
quantifier bound variable is in the complementary condition.
A case split on x0 = ds∨x0 6= ds is then suggested by the case split patch to produce
two subgoal. That is,
x0 = ds
x0 ∈ dom(incoming) ⇒ x0 ∈
/ incoming(x0 )
`
(4.15)
x0 ∈ dom (incoming C
− {ds 7→ (incoming(ds) ∪ {s})})
↑
↑
− {ds 7→ (incoming(ds) ∪ {s})}) (x0 )
⇒ x0 ∈
/ (incoming C
and
x0 6= ds
x0 ∈ dom(incoming) ⇒ x0 ∈
/ incoming(x0 )
`
(4.16)
− {z 7→ (incoming(ds) ∪ {s})})
x0 ∈ dom (incoming C
↑
↑
⇒ x0 ∈
/ (incoming C
− {z 7→ (incoming(ds) ∪ {s})}) (x0 )
Subgoal (4.16) is then matched with the first rewrite rule of funcapp C
− functional,
whereas the subgoal with the case x0 = ds is matched with the second rewrite rule.
76
Chapter 4. Applying Rippling and proof-patching Techniques
Because the first rewrite rule is in fact a wave-rule, the subgoal with the case x0 6= ds
can be use the first rewrite rule as a wave-rule to ripple to
x0 6= ds∧
x0 ∈ dom(incoming) ⇒ x0 ∈
/ incoming(x0 )
`
(4.17)
x0 ∈ dom (incoming C
− {z 7→ (incoming(ds) ∪ {s})})
↑
⇒ x0 ∈
/ incoming(x0 )
For subgoal (4.15), the matched rewrite rule is not a wave-rule, as the skeleton is
not preserved. By unifying the LHS of the rewrite rule with the subgoal, we can have
the unified RHS, i.e. (incoming(ds) ∪ {s}. Still the skeleton is still not preserved.
The case split patch then continues to check whether the case split condition is
met, which is x0 = ds, matches the pattern of X = Y or Y = X where X is a subterm
of the skeleton of LHS and Y is a subterm of wave-front of LHS. The purpose of this
operator is, to try to substitute a subterm in the wave-front of LHS with a subterm in
the skeleton of LHS in the unified RHS, to recover the skeleton in the unified RHS. For
the example, the unified RHS after substitution becomes (incoming(x0 ) ∪ {s}. Note
that the skeleton is now preserved in the new RHS. We then conjecture and prove the
new rewrite rule, i.e.,
↑
− {ds 7→ (incoming(ds) ∪ {s})}) (x0 )
(incoming C
incoming(x0 ) ∪ {s}
↑
The subgoal is now unblocked with this rewrite rule, i.e.,
x0 6= ds∧
x0 ∈ dom(incoming) ⇒ x0 ∈
/ incoming(x0 )
`
(4.18)
x0 ∈ dom (incoming C
− {ds 7→ (incoming(ds) ∪ {s})})
⇒ x0 ∈
/ incoming(x0 ) ∪ {s}
↑
↑
Note that the case split patch can be easily extended if new case split patterns are
identified. We only need to provide a new a complementary pair of conditional rewrite
rules for each pattern, then the case split patch can work on the new case split pattern.
4.4. Summary
77
An example of a possible case split pattern can be:



(1) [x 6= a0 ; f unctional ( f C
− {(a0 7→ b0 ) C
− {(a1 7→ b1 )});







x ∈ dom(( f C
− {(a0 7→ b0 ) C
− {(a1 7→ b1 )}))]



↑
↑
=⇒ f C
− {(a0 7→ b0 ) C
− {(a1 7→ b1 )} (x)
f (x) C
− {(a1 7→ b1 )}





(2) [x = a0 ; f unctional ( f C
− {(a0 7→ b0 ) C
− {(a1 7→ b1 )})]




↑



=⇒ f C
− {(a 7→ b ) C
− {(a 7→ b )} (x) b
0
0
1
1
1
where the complementary condition is x 6= a0 ∨ x = a0
4.4
Summary
In this chapter we showed that rippling is applicable to INV POs. We also presented
an account of types of failures for rippling in the INV POs domain. For each type, we
developed a proof patch to recover failures. The Skeleton Rewrite proof patch works
by rewriting the relation-based operators and ∈ operator to the operators for which it
is possible to ripple over, and the Case Split proof patch automatically suggests a case
split and rewrite rules to simplify goals when case split is needed.
Chapter 5
Scheme-based Lemma Conjecturing
5.1
Introduction
In chapter 4, we have shown the use of rippling for INV POs, and we also presented
two proof patches to recover blocked rippling by rewriting the skeleton or suggesting a
case split for the failures of type (i) and (ii). In this chapter, we present the proof patch
aimed at conjecturing intermediate lemmas to recover type (iii) of failures for rippling
in the Event-B INV POs domain. We name this proof patch as ahLemma.
Proofs can be blocked due to the needs for intermediate lemmas. This happens
when rippling is blocked due to missing wave-rules. The meta-level guidance of rippling, i.e., the parts of the skeleton that are moving together, can provide useful information to conjecture these missing wave-rules. To illustrate how the meta-level
guidance of rippling is helpful, consider invariant CallersDef from the telephone exchange example in Figure 3.3, i.e.,
Callers = dom((call ; st) BConnected)
with the changes made in event DialNum, the following INV PO is generated for invariant CallersDef, i.e.,
Callers = dom(call ; st BConnected)
`
(5.1)
↑
− {(s 7→ (connecting 7→ ds))}) ; st BConnected)
Callers = dom( (call C
However, rippling is blocked at the first step, because no wave-rule is available to ripple
79
80
Chapter 5. Scheme-based Lemma Conjecturing
the wave-front
(call C
− {(s 7→ (connecting 7→ ds))})
↑
over relational forward composition (;). Nevertheless, rippling can expect that, after
the next ripple step, wave-fronts are moving upwards in the term tree and the parts of
skeleton are moving together. That is, the goal of the after ripple step should have the
following shape:
↑
Callers = dom( (call; st · · · ) BConnected)
Note that the exact details of the terms within the wave-front are unknown to rippling.
We use symbol · · · in the wave-front to represent these unknown terms. With the
rippling expectation, we can speculate a possible shape for the missing wave-rule,
which could recover the blocked INV PO (5.1)
↑
(call C
− {(s 7→ (connecting 7→ ds))}) ; st
(call; st · · · )
↑
(5.2)
This requires us to speculate the unknown terms in the wave-front, i.e., · · · ↑ , in order
to conjecture the missing ware-rule.
To speculate the unknown terms in the wave-fronts, we employ a scheme-based
approach. The central idea of this approach is to construct a lemma by using a formula
containing meta-variables to constrain and represent the unknown terms. For example,
a possible formula to represent the unknown terms in the above example is
F1 (call; st, F2 (st, {(s 7→ (connecting 7→ ds))}))
↑
(5.3)
where F1 and F2 are meta-variables, and the related rewrite rule with meta-variables is
↑
(call C
− {(s 7→ (connecting 7→ ds))}) ; st
F1 (call; st, F2 (st, {(s 7→ (connecting 7→ ds))}))
↑
Those constructed rewrite rules which contain meta-variables are called schemes. A
scheme constrains the shape of the possible wave-rule in particular for the unknown
term structures in the wave-fronts. We construct various schemes to represent different
possible shapes for the unknown term structures in the wave-fronts, e.g., associativity and distributivity. Then we use a state of the art theory exploration tool, IsaScheme[142], to instantiate those meta-variables in the constructed schemes with the
5.2. Overall Process
81
terms in a seeding pool. We then filter the false conjectures by disproving, and generate potential useful lemmas by proving.
The main contribution of this chapter is to develop a scheme-based approach to
conjecture missing wave-rules to recover proofs when rippling is blocked.
§5.2 gives an overview of the process of ahLemma. §5.3 discusses the heuristics
and constraints used in our approach. §5.4 and §5.5 present the construction of the
schemes to constrain the shapes of the missing wave-rule. §5.6 introduces the process
of building a seeding pool to instantiate the meta-variables in the schemes. Note that
we only present the process in this chapter, the justification of the effectiveness will be
covered in chapter 7.
5.2
Overall Process
Generally, the key of ahLemma is to use schemes to capture and constrain the possible shapes of the missing wave-rules, then to use IsaScheme to instantiate the metavariables in the scheme to conjecture the missing wave-rules which we need. We use
an equation-based format for each scheme, i.e.,
LHS = RHS
where the LHS is a subterm from the blocked goal which we wish to rewrite at the next
wave-step, while the RHS is what this subterm is expected to be rewritten to. When
lemmas are generated with these schemes, they will be used to rewrite the blocked goal
from the LHS to the RHS, i.e.,
LHS
RHS
(5.4)
When LHS is a predicate and is from the top level of the goal, another possible format
for scheme construction is
RHS ⇒ LHS
(5.5)
where ⇒ is object-level implication. The generated rewrite rule from this scheme can
be used to rewrite the goal from the LHS to the RHS, as shown in (5.4). This is be-
cause we prove goals by reasoning backwards, and the generated rewrite rules from
this scheme are applied to goals. The equation-based format is more restrictive than
format (5.5), because the equation-based format can constrain the generated rewrite
82
Chapter 5. Scheme-based Lemma Conjecturing
rules to be reversible but format (5.5) cannot. The use of the equation-based format
can avoid generating lemmas which are correct but lead the rewritten goal to be unprovable. An extreme case which we want to avoid is when RHS is evaluated to be
false.
We use the equation-based format to construct schemes. The main challenges of
conjecturing lemmas with schemes are:
Challenge (i) To construct schemes which are general enough to capture the shapes
of the missing wave-rule, but restricted enough to filter out those useless ones.
Challenge (ii) To reduce the search space of the possible instantiations of meta-variables
in a scheme so that the scheme can be instantiated in a reasonable time.
To address challenge (i), we choose an empirical approach to run experiments to
summarise the possible shapes of missing lemmas, and then construct schemes using
the rippling expectation and these possible shapes of lemmas. To construct a scheme,
we first choose a subterm from the blocked goal as LHS. The details of the choice of
LHS will be given in §5.4. With the rippling expectation, we know the parts of skeleton
in LHS will move together in RHS, i.e., the parts of skeleton becomes a subterm in
RHS. For example, with a chosen LHS for the blocked goal (5.1),
↑
(call C
− {(s 7→ (connecting 7→ ds))}) ; st
(5.6)
the RHS should contain the subterm
call ; st
However, rippling provides no guidance for the shape of terms in the wave-front. To
get the possible shapes of wave-fonts, we adopt an empirical approach to collect these
possible shapes. These shapes can be represented using meta-variables. For the example in (5.6), an associativity shape can be
F1 (call; st, {(s 7→ (connecting 7→ ds))})
↑
and a distributivity shape can be
F1 (call; st, F2 (st, {(s 7→ (connecting 7→ ds))}))
↑
where F1 and F2 are meta-variables which can be later instantiated in IsaScheme.
More details of the shapes of the RHS are discussed in §5.5. We construct RHS with
5.3. Heuristics
83
the collected possible shapes, and then combine the LHS and RHS to produce schemes
to constrain the shapes of the lemmas. The generated lemmas from those scheme are
applicable wave-rules for the blocked goal.
Recall that IsaScheme uses the lambda terms in the seeding pool to instantiate the
meta-variables in the scheme. Therefore, for the second challenge, we note that the size
of the search space is directly proportional to the number of schemes and the number
of lambda terms of the seeding pool. The optimisation of schemes is also a part of the
work for challenge (i). To optimise the number of lambda terms in the seeding pool,
we introduce heuristics to generate a dynamic seeding pool based in the LHS, instead
of using a static seeding pool. We’ll discuss how to generate the dynamic seeding pool
of Event-B operators for the given schemes in §5.6.
In the rest of this chapter, we will first introduce the heuristics in the whole process
of ahLemma, followed by more details of the patching process of ahLemma where the
use of these two heuristics will be discussed. Figure 5.1 gives an overall account of the
patching process of ahLemma. Note that we only present the process in this chapter.
The justification of the effectiveness will be covered in chapter 7. To elucidate the process of ahLemma, we employ INV PO (5.1) as a running example, where appropriate,
throughout the discussion of the patching process.
5.3
Heuristics
We use two heuristics to facilitate our scheme-based lemma conjecturing. These two
heuristics are introduced in this section. The first heuristic is regarding function arity.
We observe that nearly all the operators in Event-B are either binary or unary, or can be
rewritten to an equivalent binary or unary version [71]. The only exception is operator
partition. This operator can be rewritten to a conjunction of a set of terms containing
binary operators, i.e.,
partition S [X, Y, Z]
(S = X ∪ Y ∪ Z)
∧ (X ∩ Y = ∅)
∧ (Y ∩ Z = ∅)
∧ (X ∩ Z = ∅)
84
Chapter 5. Scheme-based Lemma Conjecturing
Preconditions:
1. Rippling is blocked.
Applying the Patch:
Process
construct LHS
construct a list of possible RHSs
construct a list of schemes by
combining the LHS with each RHS
construct a seeding pool by
analysing LHS
instantiate schemes with the
seeding pool using IsaScheme
Output
LHS
[ RHS1 ... RHSn ]
[ Scheme1: LHS = RHS1
...
Schemen: LHS = RHSn ]
Seeding
Pool
[ wave-rule1
...
wave-rulen ]
apply one of these wave-rule
and continue rippling if the list of
the wave-rules is not empty;
otherwise fail
Figure 5.1: Scheme-based lemma conjecture
Therefore, we only consider to match a variable or to instantiate a meta-variables to a
binary or unary operator, i.e., F (x, y) or F (x). The heuristics is shown as follows:
Heuristic 5.3.1 (Function arity). During the scheme construction, only consider that
the function arity of the operators to be matched are either binary or unary, and to
instantiate the meta-variables to be inserted in the RHS are binary or unary.
We will give more details of the use of this heuristic in §5.4 and §5.5.
The second heuristic is to avoid generating conditions for lemmas if they are conditional. From our empirical experiment, we note that most of the missing lemmas
are conditional. If we wish to conjecture a general version of those rewrite rules, we
need to extract the condition from the proof context. However, speculating conditional
5.4. LHS Construction
85
lemmas is not a trivial problem. Therefore, we are only interested in conjecturing a
contextual correct lemma. We assume the required conditions are presented or can
be trivially inferred in the proof state. To achieve this, we do not generalise the variables in schemes when we construct schemes, and we use the current proof state when
proving the instantiated schemes.
Heuristic 5.3.2 (Conjecturing lemmas within the current proof context). Only conjecture a contextual correct lemma, by assuming the required conditions are present or
can be trivially inferred in the proof state.
In the following sections, we will present the process of the scheme-based lemma
conjecturing in details.
5.4
LHS Construction
The first step of the patching process is to construct the LHS. The LHS of schemes
states the subterm which we want to rewrite to recover the blocked goal. The main
tasks in getting such a subterm from a blocked goal are:
• to choose a wave-front from the goal.
• to choose the operators which we wish to ripple the chosen wave-front over.
We will discuss each of them respectively.
Choice of wave-front
When there is only one wave-front in the blocked goal, the choice of wave-front is
straightforward, i.e., the only blocked one. However, when there are more than one
wave-fronts in the blocked goal, we need to check the relationship among these wavefronts before we make the choice. The relations of these wave-fronts can either be
nested, e.g.,
↑
↑
f (g1 ( g0 (a, b) , c), d) , with a decorated tree representation
f (g1 (...), d)
"
"b
b
g0 (a, b)
↑
c
↑
86
Chapter 5. Scheme-based Lemma Conjecturing
1. Given a goal G, with skeleton S.
2. Get the left-most and most-nested wave-front node from the decorated tree representation of G. e.g., the left-most, most-nested, wave-front node in the following
↑
example is f5 (y) .
f0
XXXX
X
x
f1
f
2
XXX
f7 ( f3 (...), k)
↑
f4
"b
b
"
Z
Z
f5 (y)
↑
XX
f6 (m, i)
z
↑
n
3. Get the parent node of the left-most and most-nested wave-front node. If the operator is either max or min, pick the parent node of max and min, otherwise pick the
parent node of the left-most and most-nested wave-front node, e.g., f3 (...).
4. Get the term of the sub-tree of the picked node to form LHS. e.g.,
f3 (...)
Z
Z
f5 (y)
↑
z
Figure 5.2: Constructing the LHS of the scheme
or independent, e.g.,
↑
↑
f ( g0 (a, b) , g1 ( g2 (c, d) ), with a decorated tree representation
f
!aa
!!
a
!
a
g0 (a, b)
↑
g1
g2 (c, d)
↑
Nested wave-fronts might arise when there are two wave-fronts under one operator
and one of the wave-front is rippled over this operator. For example, to ripple the
wave-front g0 (a, b)
↑
in
↑
↑
f ( g0 (a, b) , g1 ( g2 (c, d) )
5.4. LHS Construction
87
using the rewrite rule, i.e.
↑
f ( g0 (X,Y ) , Z)
g3 ( f (X, Z),Y )
↑
we create a nested wave-front, i.e.
↑
g3 ( f (a, g1 ( g2 (c, d) )), b)
↑
For nested wave-fronts, we choose the most-nested one, i.e. the lowest one in the tree.
The point of this choice is that unblocking the most-nested one may lead to the unblocking of the less nested one [103].
For the independent wave-fronts, because all of the wave-fronts are yet to be unblocked, the choice of decision is not important. Here we choose the left-most one. In
our running example, we only have one wave-front.
(call C
− {(s 7→ (connecting 7→ ds))})
↑
Choice of operators to be rippled over
Given that we have chosen a wave-front from the blocked goal, the operators to be
rippled over are those operators which are currently located above the chosen wavefront in the term tree, and will move to the wave-hole of the wave-front after the next
ripple step. Note that we only consider the direction of rippling outward. Possible
candidates of these operators are the parent nodes of the chosen wave-fronts in the
term tree. To illustrate, consider the decorated tree of the running example shown in
Figure 5.3. The possible candidates of the wave-front
− {(s 7→ (connecting 7→ ds))})
(call C
↑
are the operators (;B dom =).
Note that the more operators to be rippled over are included, the more the relevant
variables and operators will be involved with the conjectured rewrite rule. The more
involved relevant variables and operators, the more complicated the conjectured rewrite
rule will be. An extreme example is to include all the possible candidates operators.
In the running example, they are ;B dom =. With such a LHS, we can then have
conjectured a rewrite rule by simply removing all the wave-fonts for the RHS, i.e.,
88
Chapter 5. Scheme-based Lemma Conjecturing
=
((hhhhh
(
(
(
(
hhh
hh
((((
(
h
dom
Callers
B
XXX
XX
;
Connected
XXX
XX
call C
− {s 7→ connecting 7→ ds}
↑
st
Figure 5.3: A decorated tree representation of the goal of the running example
↑
− {(s 7→ (connecting 7→ ds))}) ; st BConnected)) =
(Callers = dom( (call C
(Callers = dom(call ; st BConnected))
If this rewrite rule is provable in the current proof context, it can be an applicable
wave-rule to recover the proof. However, it is unlikely that the rewrite rule can be
proved by an automatic proof method, if the automatic proof method cannot prove the
blocked goal.
Therefore, we want to include the operators to be rippled over as few as possible
to minimise the relevant variables and operators involved with the conjectured rewrite
rule. From our experiments, we notice that getting only one operator from and above
the parent node is usually sufficient to successfully conjecture rewrite rules. One exception is when the operator to be rippled over is either max or min, which are unary
operators returning a greatest or least integer from a given integer set. For these two
operators, we need to get both the parent node and the parent node of the parent node
so that a rewrite rule can be conjectured.
Our choice of the operator to be rippled over is either
• the operator of the parent node, or
• max or min, and the operator of the parent node of max or min
Note that the type of max and min is from intset to int. There is not the case when
the parent node of max or min is still max or min. Hence, the number of the operators
to be rippled over is always either one or two.
5.5. RHS Construction
89
For the running example, we use our heuristic introduced in this section ot pick the
operator of the parent node of the wave-front, i.e. (;), as the operator to be rippled over.
Therefore we have constructed the LHS of schemes, i.e.,
↑
(call C
− {(s 7→ (connecting 7→ ds))}) ; st
(5.7)
An algorithm for computing the LHS of schemes from the decorated tree view of a
goal is shown in Figure 5.2. In the next section, we will show how to construct the
RHS of schemes.
5.5
RHS Construction
We construct a list of RHS based on the constructed LHS. Briefly, we summarise the
possible shapes of the LHS, and for each shape, we provide the related shapes RHS for
the RHS construction.
The possible of shapes of the LHS are limited. This can be concluded from the
following reasons:
(i) the function arity of the operators in Event-B is either binary or unary, i.e., f (x, y)
or f (x)
(ii) we only choose one wave-front in the LHS.
(iii) the operators to be rippled over in the LHS is either one operator of the parent
node, or operators max or min and the operator of the parent node of max or min,
i.e., f ( ... ↑ ...), f (max( ... ↑ )...) or f (min( ... ↑ )...)
(iv) we observe that the depth of a wave-hole in a wave-front is, in practice, rarely
↑
more than two, i.e., f (... ...) , f1 ( f2 (...)...)
↑
With (i), (ii) and (iii), the shapes of the non-wave-front parts of the LHS are:
One operator : g( ... ↑ ), g( ... ↑ , A), g(A, ... ↑ )
Two operators : g(max( ... ↑ ), g(max( ... ↑ ), A), g(A, max( ... ↑ ))
g(min( ... ↑ )), g((min( ... ↑ ), A), g(A, (min( ... ↑ ))
90
Chapter 5. Scheme-based Lemma Conjecturing
Note that, as max and min are unary operators, the shapes of two operators can be
unified with the related shapes of one operator by considering max, min and their parent node operator g as one operator, i.e., λx.g(max(x)), λx, y.g(max(x), y) or λx, y.g(y, max(x)).
Now the revised the possible shapes of the non-wave-front parts of the LHS are:
g( ... ↑ ), g( ... ↑ , A), g(A, ... ↑ )
With (i) and (iv), the shapes of the wave-front of the LHS are
↑
↑
Depth 1 : f (H) , f (H, X) , f (X, H)
↑
↑
↑
↑
Depth 2 : f1 ( f2 (H)) , f1 ( f2 (H, X)) , f1 ( f2 (X, H)) ,
↑
↑
f1 ( f2 (H), X) , f1 (X, f2 (H)) ,
↑
↑
↑
f1 ( f2 (H, X),Y ) , f1 ( f2 (X, H),Y ) , f1 (Y, f2 (H, X)) , f1 (Y, f2 (X, H))
↑
where the three shapes are for the case when the wave-hole is at depth 1 of the wavefront, while the remaining shapes are for the case when the wave-hole is at the depth
2 of the wave-front. Similar to how we treat max and min in wave-fronts, we also
consider f1 and f2 as one operator in the cases of depth 2, when the total number of
arguments in the wave-fronts are less than or equal to 2. For instance, the shapes of
↑
f1 ( f2 (H)) , f1 ( f2 (H, X))
↑
and f1 ( f2 (H), X)
↑
are then unified with
↑
f (H) , f (H, X)
↑
and f (H, X)
↑
where in the first shape f = λx. f1 ( f2 (x)), in the second shape f = λx, y. f1 ( f2 (x, y)),
and in the third shape f = λx, y. f1 ( f2 (x), y). Hence, the possible shapes of wave-fronts
are then concluded as:
↑
↑
Depth 1 : f (H) , f (H, X) , f (X, H)
↑
↑
↑
↑
Depth 2 : f1 ( f2 (H, X),Y ) , f1 ( f2 (X, H),Y ) , f1 (Y, f2 (H, X)) , f1 (Y, f2 (X, H))
↑
By permuting the shapes of wave-fronts and the shapes of the non-wave-front parts,
we can have the possibles shapes of the LHS shown in Figure 5.4.
To simplify matching LHS with the shapes of the LHS, we consider the wave-hole
and all the arguments of the parents of the wave-hole as one atom node in LHS. That
5.5. RHS Construction
91
Depth 1:
↑
↑
↑
g( f (H) ), g( f (H) , A), g(A, f (H) )
↑
↑
↑
↑
↑
↑
g( f (H, X) ), g( f (H, X) , A), g(A, f (H, X) )
g( f (X, H) ), g( f (X, H) , A), g(A, f (X, H) )
Depth 2:
↑
↑
↑
↑
↑
↑
↑
↑
↑
↑
↑
↑
g( f1 ( f2 (H, X),Y ) ), g( f1 ( f2 (H, X),Y ) , A), g(A, f1 ( f2 (H, X),Y ) ),
g( f1 ( f2 (X, H),Y ) ), g( f1 ( f2 (X, H),Y ) , A), g(A, f1 ( f2 (X, H),Y ) ),
g( f1 (Y, f2 (H, X)) ), g( f1 (Y, f2 (H, X)) , A), g(A, f1 (Y, f2 (H, X)) ),
g( f1 (Y, f2 (X, H)) ), g( f1 (Y, f2 (X, H)) , A), g(A, f1 (Y, f2 (X, H)) )
Figure 5.4: An account of possible shapes of the LHS of the constructed schemes
is, we do not further investigate the structure of the term in such atoms. For example,
with a given LHS
↑
f ( g((a ∪ b), (b ∪ c)) , (c ∪ d))
a ∪ b, b ∪ c and c ∪ d are considered as one single node. Therefore, this LHS matches
↑
with shape g( f (H) , A).
With the shapes of the LHS, we have run empirical experiments to summarise possible shapes of the RHS for each shape of LHS. The summarised shapes of RHS are
shown in Table 5.1 and Table 5.2. Note that these shapes include some common shapes
of lemmas, e.g., absorption, associativity and distributivity.
92
Chapter 5. Scheme-based Lemma Conjecturing
LHS
RHS
↑
g(H), F1 (g(H))
↑
g(H, A), F1 (g(H, A))
↑
↑
g(A, H), F1 (g(A, H))
↑
↑
g(H), F1 (g(H), X) , F1 (g(H), F2 (X)) ,
g( f (H) )
g( f (H) , A)
g(A, f (H) )
↑
↑
g( f (H, X) )
↑
F1 (g(H), F2 (F3 (H, X)))
↑
g( f (H, X) , A)
↑
↑
↑
g(H, A), F1 (g(H, A), X) , F1 (g(H, A), F2 (X, A)) ,
↑
↑
F1 (g(H, A), F2 (H)) , F1 (g(H, A), F2 (X, H)) ,
F1 (g(H, A), F2 (F3 (H, X)))
↑
g(A, f (H, X) )
↑
↑
g(A, H), F1 (g(A, H), X) , F1 (g(A, H), F2 (A, X))
↑
↑
↑
F1 (g(A, H), F2 (H)) , F1 (g(A, H), F2 (X, H)) ,
F1 (g(A, H), F2 (F3 (H, X)))
↑
↑
↑
↑
g(H), F1 (X, g(H) , F1 (F2 (X), g(H)) ,
g( f (X, H) )
F1 (F2 (F3 (X, H)), g(H))
↑
g( f (X, H) , A)
↑
↑
↑
g(H, A), F1 (X, g(H, A)) , F1 (F2 (X, A)), g(H, A) ,
↑
↑
F1 (F2 (H), g(H, A)) , F1 (F2 (H, X)), g(H, A) ,
F1 ((F2 (F3 (X, H)), g(H, A))
↑
g(A, f (X, H) )
↑
↑
↑
g(A, H), F1 (X, g(A, H)) , F1 (F2 (A, X), g(A, H)) ,
↑
↑
F1 (g(A, H), F2 (H)) , F1 (F2 (H, X), g(A, H)) ,
F2 (F3 (H, X)), F1 (g(A, H))
↑
Table 5.1: Possible shapes of the RHS for each LHS shape of depth one
5.5. RHS Construction
93
LHS
RHS
↑
g(H), F1 (F2 (g(H), X),Y )
↑
g(H, A), F1 (F2 (g(H, A), X),Y ) ,
g( f1 ( f2 (H, X),Y ) )
g( f1 ( f2 (H, X),Y ) , A)
↑
↑
↑
F1 (F2 (g(H, A), F3 (X, A)), F4 (Y, A)) ,
↑
F1 (F2 (g(H, A), X), F3 (Y, A)) ,
F1 (F2 (g(H, A), F3 (X, A)),Y )
↑
g(A, {1 ({2 (H, X),Y ) )
↑
↑
g(A, H), F1 (F2 (g(A, H), X),Y ) ,
↑
F1 (F2 (g(A, H), F3 (A, X)), F4 (A,Y )) ,
↑
F1 (F2 (g(A, H), X), F3 (A,Y )) ,
F1 (F2 (g(A, H), F3 (A, X)),Y )
↑
↑
g(H), F1 (F2 (X, g(H)),Y )
↑
g(H, A), F1 (F2 (X, g(H, A)),Y ) ,
g( f1 ( f2 (X, H),Y ) )
g( f1 ( f2 (X, H),Y ) , A)
↑
↑
↑
F1 (F2 (F3 (X, A), g(H, A)), F4 (Y, A)) ,
↑
F1 (F2 (F3 (X, A), g(H, A)),Y ) ,
F1 (F2 (X, g(H, A)), F3 (Y, A))
↑
g(A, f1 ( f2 (X, H),Y ) )
↑
↑
g(A, H), F1 (F2 (X, g(A, H)),Y ) ,
↑
F1 (F2 (F3 (A, X), g(A, H)), F4 (A,Y )) ,
↑
F1 (F2 (A, X), g(A, H)), F3 (A,Y )) ,
F1 (F2 (A, X), g(A, H)), F3 (A,Y ))
↑
↑
g(H), F1 (Y, F2 (g(H), X))
↑
g(H, A), F1 (Y, F2 (g(H, A), X)) ,
g( f1 (Y, f2 (H, X)) )
g( f1 (Y, f2 (H, X)) , A)
↑
↑
↑
F1 (F3 (Y, A), F2 (g(H, A), F4 (X, A)) ,
↑
F1 ((Y, A), F2 (g(H, A), F3 (X, A)) ,
F1 ((Y, A), F2 (g(H, A), F3 (X, A))
↑
g(A, f1 (Y, f2 (H, X)) )
↑
↑
g(A, H), F1 (Y, F2 (g(A, H), X))) ,
↑
F1 (F3 (A,Y ), F2 (g(A, H), F4 (A, X))) ,
↑
F1 (F3 (A,Y ), F2 (g(A, H), (A, X))) ,
F1 ((A,Y ), F2 (g(A, H), F3 (A, X)))
↑
g(H), F1 (Y, F2 (X, g(H)))
↑
g(H, A), F1 (Y, F2 (X, g(H, A))) ,
g( f1 (Y, f2 (X, H)) )
g( f1 (Y, f2 (X, H)) , A)
↑
↑
↑
↑
F1 (F3 (Y, A), F2 (F4 (X, A), g(H, A))) ,
↑
F1 (F3 (Y, A), F2 (X, g(H, A))) ,
F1 (Y, F2 (F3 (X, A), g(H, A)))
↑
g(A, f1 (Y, f2 (X, H)) )
↑
↑
g(A, H), F1 (Y, F2 (X, g(A, H))) ,
↑
F1 (F3 (A,Y ), F2 (F4 (A, X), g(A, H))) ,
↑
F1 (Y, F2 (F3 (A, X), g(A, H))) ,
F1 (F3 (A,Y ), F2 (X, g(A, H)))
↑
Table 5.2: Possible shapes of the RHS for each LHS shape of depth 2
94
Chapter 5. Scheme-based Lemma Conjecturing
↑
1. With a chosen LHS, e.g., f ( g(a, b) , c), match this LHS with the shapes in Figure
5.4.
2. Get the corresponding possible shapes of the RHS from Table 5.1 and Table 5.2 for
the matched shaped of the LHS, e.g., the matched LHS shape is:
↑
g( f (H, X) , A)
then the corresponding RHS shapes are:
↑
↑
g(H, A), F1 (g(H, A), X) , F1 (g(H, A), F2 (X, A)) ,
↑
↑
F1 (g(H, A), F2 (H)) , F1 (g(H, A), F2 (X, H)) ,
F1 (g(H, A), F2 (F3 (H, X)))
↑
3. Construct the RHS with those RHS shapes by instantiating the variables from the
LHS, e.g.,
↑
↑
f (a, c), F1 ( f (a, c), b) , F1 ( f (a, c), F2 (b, c)) ,
↑
↑
F1 ( f (a, c), F2 (a)) , F1 ( f (a, c), F2 (c, a)) ,
F1 ( f (a, c), F2 (F3 (a, b))
↑
Figure 5.5: Constructing the RHS of the scheme
Now we can construct schemes from the information of possible shapes. Figure
5.5 describes an algorithm for conjecturing the RHS of the scheme. To illustrate, let’s
consider our running example (5.1). Following step 1, we start the RHS construction
with the LHS of the scheme, e.g.
↑
(call C
− {(s 7→ (connecting 7→ ds))}) ; st
This LHS matched the shape of the LHS
↑
g( f (H, X) , A)
which give us a list of possible shapes of the RHS:
5.5. RHS Construction
95
g(H, A),
↑
↑
F1 (g(H, A), X) , F1 (g(H, A), F2 (X, A)) ,
↑
F1 (g(H, A), F2 (H)) ,
↑
F1 (g(H, A), F2 (X, H)) ,
F1 (g(H, A), F2 (F3 (H, X)))
↑
With these shapes of RHS, we can now construct the RHS for the LHS, which are:
call ; st,
↑
F1 (call ; st, {(s 7→ (connecting 7→ ds))}) ,
↑
F1 (call ; st, F2 ({(s 7→ (connecting 7→ ds))}, st)) ,
F1 (call ; st, F2 (call))
↑
↑
F1 (call ; st, F2 ({(s 7→ (connecting 7→ ds))}, call)) ,
F1 (call ; st, F2 (F3 (call, {(s 7→ (connecting 7→ ds))})))
↑
Now by combining the LHS and the RHS, we have the schemes,
↑
(call C
− {(s 7→ (connecting 7→ ds))}) ; st = call ; st,
↑
(call C
− {(s 7→ (connecting 7→ ds))}) ; st =
↑
F1 (call ; st, {(s 7→ (connecting 7→ ds))}) ,
↑
(call C
− {(s 7→ (connecting 7→ ds))}) ; st =
↑
F1 (call ; st, F2 ({(s 7→ (connecting 7→ ds))}, st)) ,
↑
(call C
− {(s 7→ (connecting 7→ ds))}) ; st =
F1 (call ; st, F2 (call))
↑
↑
(call C
− {(s 7→ (connecting 7→ ds))}) ; st =
↑
F1 (call ; st, F2 ({(s 7→ (connecting 7→ ds))}, call)) ,
↑
(call C
− {(s 7→ (connecting 7→ ds))}) ; st =
F1 (call ; st, F2 (F3 (call, {(s 7→ (connecting 7→ ds))})))
↑
96
Chapter 5. Scheme-based Lemma Conjecturing
5.6
Instantiation using the Dynamic Seeding Pool
Therefore the efficiency of the instantiation depends on the size of the candidate seeding pool. We want to heuristically select a set of operators to instantiate meta-variables
in the constructed schemes. The main idea of our dynamic seeding pool construction
is to empirically observe how operators change from LHS to those on the RHS, and
then create heuristics to add those operators which are considered to be relevant based
on the operators on the LHS. In this section we show some heuristics for dynamically
choosing related Event-B operators for instantiation by analysing the operators on the
LHS. Note that, as each schemes has the same LHS, we only need to construct one
seeding pool for them all. Also, because we only investigate how operators change
from the possible shapes of the LHS to the possible shapes of the RHS, we do not investigate the operators in the term structures which are considered as atoms. For ease of
presentation, we introduce some definitions of correspondences of operators together
with some observed patterns before discussing the heuristics for the construction of
the seeding pool. For convenience of presentation, we introduce y, where {A, B} y C
means if A or B is in the LHS then add C to the seeding pool, and C y {A, B} means
if C appears in the LHS then to add both A and B to the seeding pool.
Observation I : Operators which appear on one side of rewrite rules also appear on
the other side.
Many of distributive and associative rules follow this pattern. One common example rewrite rule is
A ∪ (B ∩ C)
↑
= (A ∪ B) ∩ (A ∪ C)
↑
.
This observation suggests to include the operators which appear in the LHS of the
scheme in the seeding pool.
Observation II : Operator C
− is defined hierarchically in Event-B. That is, this op-
erator is defined by other operators in Event-B, e.g., C
− is defined using dom, ∪ and
−. We include these definitional operators on the RHS when C
C
− is on the LHS. Table
5.3 shows the hierarchically defined operators, with those operators by which they are
defined.
5.6. Instantiation using the Dynamic Seeding Pool
97
C
− y {dom , C
−, ∪}
Table 5.3: Hierarchically defined operators
Observation III : operators for relations correspond to related operators over sets.
Take C and ∩ for example, they have the same functionality, but ∩ applies to the
whole pairs and C only applies to the first element of pairs. Therefore, when a relation
projection operator dom ranges over a relation operator in the LHS, the corresponding
set operator might appear in the RHS, e.g.,
dom (B C A)
↑
= dom(A) ∩ B
↑
Table 5.4 shows the correspondence between operators over relations and sets in EventB. Therefore, when a relation projection operator dom or ran ranges over a relation
operators on the LHS, we add the corresponding set operators to the seeding pool.
{C, B} y ∩
{C
−, B
−} y \
Table 5.4: Correspondences for relation and set Operators
Observation IV : predicate operators of ∧ and ∨ can be introduced in the wave-front
of the RHS, when evolving a predicate from outside to inside of a wave-front, e.g.,
x ∈ (A ∪ B)
↑
= x ∈ A∨x ∈ B
↑
It suggests that if there is a predicate outside the wave-front in the LHS of the
scheme, we include ∧ and ∨ in the seeding pool.
Observation V: There are pairs of duality operators and complementary operators in
Event-B. The pair of duality operators is
∩ and ∪
A pair of complementary operators are defined as complementary to each other. They
follow either one of the properties:
F1 (F2 (A, B), B) = ∅
98
Chapter 5. Scheme-based Lemma Conjecturing
or
F1 (A, B) ∨ F2 (A, B)
In Event-B these pairs of complementary operators are:
∈ and ∈,
/ ⊂ and 6⊂, ⊆ and 6⊆ C and C
−, B and B
−
We observe that, if a complementary or duality operator appears in a wave-front of
LHS, and the direct parent operator of the wave-front is a negation related operators,
it is likely that the other complementary or duality operator appears on the RHS. For
instance:
A \ (B ∪ C)
↑
= (A \ B) ∩ (A \C)
↑
Table 5.5 summarises the negation related operators, and Table 5.6 summarises the
correspondences for duality and complementary operators.
C
−, \, ∈,
/ 6⊂, 6⊆, C
−, B
−
Table 5.5: Negation related operators
∩ y ∪, ∈y∈,
/ CyC
−, B y B
−, ⊂y6⊂, ⊆y6⊆
∪ y ∩, ∈y∈,
/
− y C, B
C
− y B, 6⊂y⊂, 6⊆y⊆
Table 5.6: Correspondences for duality and complementary operators
Observation VI: Additional operators appear in the RHS, when rippling a wave-front
over the interval operator (..)1 or the cardinality operator (card) in the LHS. The similarity of interval and cardinality is that they both are operators which convert between
sets and integers. The corresponding operations for this observation are shown in Table
5.7. An example of a wave-rule for this observation is:
i .. ( j + 1)
↑
= (i .. j) ∪ { j + 1}
↑
.. y {∪ , \, λx.{x}}
card y {+, −}
Table 5.7: Correspondences for interval and cardinality
1 m .. n
=
b {i|m ≤ i ∧ i ≤ n}
5.6. Instantiation using the Dynamic Seeding Pool
99
From the all the observations and heuristics discussed, we build the heuristics
shown in Figure 5.6 to dynamically select operators for the seeding pool.
1. Add the operators from the LHS to the seeding pool, except for those operators in
subterms of atoms (Observation I).
2. Add the corresponding definitional operators to the seeding pool if the current seeding pool contain the operators which are defined hierarchically (Observation II).
3. If the direct parent operator of the wave-front is either dom or ran, then we need
to add corresponding operators between relations and sets by checking the current
seeding pool with Table 5.4 (Observation III).
4. If LHS is a predicate, add ∧ and ∨ to the seeding pool (Observation IV).
5. If the direct parent operator of the wave-front is a negation related operator, as
shown in 5.5, add the related complementary or duality operators by checking the
operators in the current seeding pools with Table 5.6 (Observation V).
6. Add the corresponding operators to the seeding pool if the current seeding pool
contains the interval operator or the cardinality operator (Observation VI).
Figure 5.6: Heuristics for dynamic seeding pool
To illustrate the process, consider the LHS (5.7), i.e.,
↑
(call C
− {(s 7→ (connecting 7→ ds))}) ; st
constructed in the previous section. We now show how to dynamic construct a seeding
pool with this LHS. The first step is to include all the non-atom operators to setup an
initial seeding pool, i.e.,
C
− ;
Note that the operator 7→ in the atom {(s 7→ (connecting 7→ ds))} is not included in
the seeding pool. For the remaining steps, we check the operators in the seeding pool,
instead of the operators from LHS. This is because, we wish to put into consideration
with the operators, which have already been added to the pool, at the following steps
of pool constructions.
100
Chapter 5. Scheme-based Lemma Conjecturing
The second step is to check if there exists definition, and to include the corresponding
definitional operators if so. In the example, C
− is included, so we add the definitional
operators to the pool. Now the initial pool is further expanded to:
C
− ; dom C
− ∪
For steps 3 and 4, as the operator outside the wave-front on LHS is neither ran nor
dom, and the type of LHS is not a predicate, no extra operators are added. In step 5,
we add operators for complementary or duality pairs. The pool becomes, i.e.,
C
− ; dom C
− ∪ C ∩
No extra operator would be added in step 6, as there is no interval nor cardinality
in the pool. Therefore, the pool has now been constructed. With this pool, we now
can send the constructed schemes and the seeding pool to IsaScheme so that the metavariables of the schemes can be instantiated. A useful intermediate lemma is then
returned within 387 second, i.e.,
↑
(call C
− {(s 7→ (connecting 7→ ds))}) ; st
call; st C
− ({(s 7→ (connecting 7→ ds))} ; st)
↑
Note that this lemma is a conditional lemma, i.e.,
dom({(s 7→ (connecting 7→ ds))}) = dom({(s 7→ (connecting 7→ ds))} ; st)
Its correctness relies on the current proof context. Also, because the lemmas generated
by ahLemma are proof context related, ahLemma can generate the conditional lemmas
without stating the explicit conditions. From this point of view, the applicability of
ahLemma is more general than just generating unconditional wave-rules manually for
all pairs of Event-B operators. This lemma is instantiated from the scheme:
↑
− {(s 7→ (connecting 7→ ds))}) ; st =
(call C
F1 (call; st, F2 (st, {(s 7→ (connecting 7→ ds))}))
where F1 = C
− and F2 = ;.
↑
5.7. Summary
5.7
101
Summary
We have shown a scheme-based lemma conjecturing technique called ahLemma to
suggest intermediate lemmas, when rippling is blocked due to a missing lemma. ahLemma
can synthesise missing lemmas based on the rippling expectation and several heuristics
discussed in this chapter. In this approach, we construct schemes with meta-variables
to constrain the shape of the lemma which we want to generate. Then we introduce several heuristics to reduce the search space for the instantiation of those meta-variables.
Chapter 6
Implementation
6.1
Introduction
In Chapter 4 and Chapter 5, we have presented the use of rippling together with three
proof-patching techniques as a proof technique to automate Event-B INV POs. In this
chapter we will describe the implementation of this proof technique, which we call
Proof Obligation Proofs Patched Automatically (POPPA).
We decided to choose Isabelle/HOL as the main platform, and to implement POPPA
in an Isabelle/HOL based proof planner, called IsaPlanner. The reasons are:
• Rippling was implemented in IsaPlanner [64, 65];
• IsaScheme [142], which ahLemma is dependent on, was also based on Isabelle/HOL;
• All the tools above are implemented in the Poly/ML programming language.
They can be communicated using their relevant interfaces written in ML;
• Event-B INV POs can be exported from Rodin to Isabelle using Matthias Schmalz’s
Isabelle for Rodin plugin [158].
Our main work was to implement POPPA and apply it to Event-B INV POs. This
includes:
• to implement each proof-patching technique as a reasoning technique (RTechns)
in IsaPlanner ;
• to combine rippling with the implemented proof-patching techniques to generate
an integrated RTechn;
103
104
Chapter 6. Implementation
• to initialise the IsaPlanner proof representation, i.e. reasoning state (RState) for
Event-B INV POs, so that we can apply the integrated RTechn to Event-B INV
POs.
§6.2 introduces the fundamental framework to implement POPPA. The implementation details of POPPA are given in §6.3. We describe how to initialise a RState from
an Event-B INV PO so that POPPA can be applied in IsaPlanner in §6.4. The screenshots of initialisation of an Event-B INV PO and running POPPA in IsaPlanner are
available in §6.5. A summary is given in §6.6.
6.2
Design and Architecture
Several third-party tools and components are involved in the implementation of POPPA,
i.e. Rodin, the Isabelle for Rodin plugin, Isabelle/HOL, HOL-EventB, IsaPlanner and
IsaScheme. Rodin and the Isabelle for Rodin plugin exports Event-B specifications
and Event-B INV POs to the format which Isabelle can process; HOL-EventB is developed based on Isabelle/HOL to format the logic of Event-B and provide the support
for the Event-B mathematical operations, e.g. → and C; IsaPlanner and IsaScheme
provide support for rippling and scheme-based theory exploration.
RippleINV
IsaScheme
IsaPlanner
HOL- EventB
IsaPlanner
IsaScheme
HOL- EventB
HOL
HOL
Figure 6.1: Dependencies of related tools & Isabelle theory stack
The left diagram of Figure 6.1 shows the dependency of POPPA and the related
tools, in which HOL is a fundamental theory in Isabelle to provide support for higherorder logic. All these tools are compiled as a heap in the Isabelle framework for the
implementation of POPPA, as shown in the right part of the Figure 6.1. Note that the
6.2. Design and Architecture
105
orders of HOL-EventB, IsaPlanner and IsaScheme are not crucial, because there is no
dependency between them.
RTechn
+ rippling
+ case split patch
+ skeleton rewrite patch
+ lemma conjecturing
patch
schemes
seeding pool &
context
IsaScheme
conjectures
Figure 6.2: Details of RTechn of POPPA
With the fundamental Isabelle framework, we are able to implement POPPA as a
RTechn. Recall that a RTechn is a function which is applied a RState to produce a
set of new RStates, and RState is a data structure to represent a proof state in IsaPlanner. This proof state contains current proof plans, contextual information and the next
RTechn to be applied. Figure 6.2 shows key components of the POPPA RTechn we
implemented. POPPA includes all our three proof-patching techniques and rippling.
The approach in which we implemented POPPA is: first to implement each proofpatching technique as a RTechn; then to combine rippling and our three proof-patching
RTechns with RTechn combinators which produce a new RTechn with given subRTechns. We will explain more in §6.3. When the scheme-based lemma conjecturing
part is applied, IsaScheme is invoked with the schemes, the seeding pool and context,
and IsaScheme returns instantiated lemmas back. We will give implementation details
of invoking IsaScheme in §6.3.1.
To apply the RTechn shown above to Event-B INV POs, we need to initialise a
RState for IsaPlanner. This process is shown in Figure 6.3, where init is the key part
to execute the initialisation. The main tasks of initialisation are:
• setup a goal from the Isabelle/HOL compatible source Event-B specifications
and the INV PO which was exported from Rodin and the Isabelle for Rodin
plugin;
106
Chapter 6. Implementation
Isabelle
for Rodin
wave
-rules
Rodin
RState
+ INV PO goal
+ RTechn
+ wave-rules
init
Eval
RTechn
Event-B
Spec &
INV POs
IsaPlanner
HOL-EventB
Isabelle/HOL
Figure 6.3: The process and the architecture
• insert a set of rewrite rules as a default wave-rules for rippling to the RState
• set the RTechn of POPPA into the RState;
More details of the implementation of init will be given in §6.4.
6.3
6.3.1
Implementing the proof-patching Techniques
Invoking IsaScheme
Before we present the implementation of rippling together with the proof-patching
techniques as one RTechn, we give implementation details for the procedure of invoking IsaScheme to get conjectures. This step is described as ‘instantiate the schemes to
get conjectures’ in the algorithm of ahLemma in Figure 5.1 from Chapter 5.
Recall that we want to invoke IsaScheme to instantiate our constructed schemes
and seeding terms together with the current proof context to conjecture lemmas. We
only pass IsaScheme a dummy proof method, i.e. sorry, which consider every lemma is
true. The reason for the use of sorry is because we want to prove conjectures outside of
IsaScheme. It give us more flexibility to choose between ‘proving all the conjectures’
6.3. Implementing the proof-patching Techniques
107
Encapsulate the current theory as a
local theory, then translate the local
theory to an e_state
Invoke IsaScheme with
- a list of schemes
- a list of seeding terms
- a dummy proof method,i .e. sorry
- an e_state containing all the type
information of variables.
Transform the returning e_state back
to a local theory then to a theory
Get a list of conjectures synthesised
by IsaScheme
Disprove or prove each conjecture
Figure 6.4: Process of invoking IsaScheme to produce lemmas.
or ‘stop proving the conjectures until the first lemma is proved’, where the first option
gives all potential lemmas while the second option is more efficient time-wisely. In
the current implementation, we choose the second option, as we want POPPA to have
a reasonable time response.
The details of the process invoking IsaScheme from the implementation point of
view are shown in Figure 6.4. We will walk through this process in the rest of this
subsection. In this figure, e state is a data structure capturing theory exploration
states in IsaScheme, and local theory is just an intermediate data type to bridge between
data type theory and data type e state. It has no substantial effect on the whole process.
Note that when an Event-B INV PO is exported to Isabelle, all related variables of
the Event-B specification are exported in a theory. Therefore, when we transfer the
108
Chapter 6. Implementation
theory to an e state, all the type information is available in the e state for IsaScheme
to synthesize conjectures. The step of transferring a local theory to e state is achieved
by using the following ML function.
val lookup state local :
local theory -> e state
Then the corresponding ML function to invoke IsaScheme is shown as below.
val Conjectures.explore conjectures :
Attrib.binding -> Attrib.binding -> Attrib.binding
-> term list -> term list -> Method.text -> e state -> e state
Some of the important arguments are: the two arguments with the type term list are
a list of schemes and a list of seeding terms; the first argument of e state is the one we
transferred from the current theory. The last e state is the returned theory exploration
states containing conjectured lemmas when IsaScheme completes conjecture synthesis.
The argument with the type Method.text is a proof method which IsaScheme uses to
prove the conjectures.
By transferring the returning e state back to a local theory using
val update state local :
e state -> local theory
We then can further export the local theory to a theory. Because all the conjectures
are stored in the theory using a prefixed THM as a name convention, we can search the
theory using ‘THM ’ as a keyword to get all the lemmas.
Now we need to disprove or prove each conjecture. For the same reason of proving lemmas outside of IsaScheme, i.e., being efficient time-wise, we decided to disable the counter example checking in IsaScheme and disprove conjectures outside of
it. Another constraint for us to disprove conjectures outside of IsaScheme is that the
IsaScheme supported counter example checkers, i.e. Quickcheck and Nitpick, are not
capable of disproving the conjectures, because Quickcheck can’t handle the datatype
defined by typedecl which is used heavily in the exported Event-B specification; and
nitpick reaches its searching limit and aborts due to overwhelming numbers of types
in Event-B specifications. As a result, in our implementation, we choose to disprove
conjectures by proving the negation of conjectures instead.
6.3. Implementing the proof-patching Techniques
6.3.2
109
Proof-patching Techniques as Reasoning Technique
Following the algorithms for the case split, skeleton rewrite and ahLemma in chapter 4 and chapter 5, each proof-patching technique can be implemented as a tactic
for the actions to be taken and a predicate returning a boolean with given proof information. For ease of presentation, we name these tactics as apply case split,
apply skel rewrite and apply ahLemma, and name the predicates as cond case split0
and cond skel rewrite0. Note that the scheme-based lemma conjecturing proofpatching technique is applicable as long as rippling is blocked, there is no need to
provide a predicate for it.
IsaPlanner provides the following two functions to encapsulate a tactic in Isabelle
to a RTechn.
val mk from isa tac s :
val apply dtac :
(string * tactic) -> DTac.T
DTac.T -> RTechn.T
This first function encapsulates a tactic with a name to a DTac which is a similar
tactic data structure in IsaPlanner. Then the second function encapsulates a DTac to
a RTechn.
With these functions, we can produce the corresponding RTechns for
apply case split, apply skel rewrite and apply ahLemma, namely,
apply case split rt0, apply skel rewrite rt0 and apply ahLemma rt.
We now have completed the implementation of the RTechn for apply ahLemma,
but for apply case split rt0 and apply skel rewrite rt0, we still need to combine them with the corresponding preconditions.
We first revise the predicate cond case split0 and cond skel rewrite0 by fetching the required proof information from RState, i.e.
val cond case split:
RState -> bool
val cond skel rewrite :
RState -> bool
then we combine the predicates with the corresponding RTechn by using the following
RTechn combinator.
110
Chapter 6. Implementation
val rstif:
(RState -> bool) -> RTechn -> RTechn -> RTechn
rstif produces a new RTechn which returns the first RTechn when the predicate is
true, otherwise the second RTechn. The completed definitions are shown in Figure 6.5.
apply case split rt =
b
rstif cond case split
apply case split rt fail
apply skel rewrite rt =
b
rstif cond skel rewrite
apply skel rewrite rt fail
Figure 6.5: The top level RTechn implementation for the skeleton rewrite and case split
proof-patching techniques
6.3.3
Combining Proof Patches with Rippling
To combine the proof-patching RTechn with rippling, the following two RTechn combinators are used to define a new RTechn
val thenr:
val orr:
(RTechn * RTechn) -> RTechn
(RTechn * RTechn) -> RTechn
where thenr produces a new RTechn which applies the first RTechn and then applies
the second RTechn to the RStates produced by the first RTechn; orr produces a new
RTechn which tries the first RTechn and the second RTechn in orders and only applies
the first successful one.
The definition of the combined RTechn is shown in Figure 6.6, i.e. rippling EventB.
To ease reading, we also show the definition of rippling in the figure.
ripple step defines one step of rippling which applies a wave-rule. rippling
first checks if the goal is rippled. If not, it takes a rippling step and then recur-
6.4. Pre-processing Event-B INV POs
111
ripple step =
b apply ripple step thenr
ensure measure decrease
rippling =
b rippled orr
(ripple step thenr rippling) orr
blocked
rippling proof patches =
b
rippled orr
(ripple step thenr rippling proof patches) orr
(apply case split rt orr
apply skel rewrite rt orr
apply ahLemma rt)
b rippling proof patches thenr
rippling EventB =
fertilisation thenr
auto rt
Figure 6.6: The top-level implementation of rippling and its extension with our proofpatching techniques
sively applies rippling. If rippling fails to take the rippling step, rippling becomes
blocked. The ‘blocked’ one is where we insert our proof-patching RTechn, as defined
as ripple proof patches. To handle non-rippling sub-goals, ripple proof patches
is combined with fertilisation, and further combined with auto rt, which encapsulates
the Isabelle automatic proof method, i.e. axe’ [158], as a RTechn.
6.4
Pre-processing Event-B INV POs
Using the Isabelle for Rodin plugin, INV POs can be exported to Isabelle. To illustrate,
consider the INV PO (4.6), i.e.,
112
Chapter 6. Implementation
···
Callers = dom((call ; st) BConnected)
`
Callers = dom(( call ∪ {(s 7→ (seize 7→ NULL))} ; st) BConnected)
recall that this INV PO is generated for invariant CallersDef with Event LiftFree and
from the Event-B model in Figure 3.3. Figure 6.7 shows the Rodin exported version of
this INV PO. Recall that locale LiftFree CallersDef INV hyps stores the axioms
information and locale LiftFree CallersDef INV goal keeps the goal information.
We use this example to illustrate the pre-processing in this section. Note that all terms
of the exported PO are in a three-value logic which is not very readable. These terms
will later be unlifted to HOL-terms in the pre-processing.
With an exported INV PO, we can get the unlifted goal and axioms of the exported
Event-B INV POs using the Poly/ML functions provided by HOL-EventB. Note that
in HOL-terms → is the symbol for the object logic implication and =⇒ for the meta
level implication. In this example, the unlifted goal term is
Callers = dom((call ∪ {(s, seize, NULL)}) ; st BConnected)
and the list of unlifted axioms (i.e. the assumptions) are:
[Connected ⊂ UNIV , Connected = {ringing, speech},
UNIV = {seize} ∪ {connecting} ∪ {ringing} ∪ {speech} ∪ {engaged}∧
({seize} ∩ {connecting} = ∅ ∧ {seize} ∩ {ringing} = ∅∧
{seize} ∩ {speech} = ∅ ∧ {seize} ∩ {engaged} = ∅)∧
({connecting} ∩ {ringing} = ∅ ∧ {connecting} ∩ {speech} = ∅∧
{connecting} ∩ {engaged} = ∅)∧
({ringing} ∩ {speech} = ∅ ∧ {ringing} ∩ {engaged} = ∅)∧
{speech} ∩ {engaged} = ∅,
st ∈ t f un (UNIV ×UNIV ) UNIV , num ∈ t f un (UNIV ×UNIV ) UNIV ,
∀x.x ∈ UNIV ×UNIV →
(( f unctional st ∧ x ∈ dom st) ∧ f unctional num ∧ x ∈ dom num) ∧ (st 0 x, num0 x) = x,
InitSubs ⊆ UNIV ,Subs ⊆ UNIV , call ∈ p f un Subs (UNIV × Subs),
incoming ∈ t f un Subs (P Subs), Callers ∈ P Subs,
6.4. Pre-processing Event-B INV POs
113
typedecl DIGITSEQ
typedecl STATUS
locale LiftFree CallersDef INV decls =
fixes s :: DIGITSEQ
fixes seize :: STATUS
fixes Callers :: DIGITSEQ set
fixes incoming :: (DIGITSEQ × DIGITSEQ set) set
fixes connecting :: STATUS
fixes Subs :: DIGITSEQ set
fixes ringing :: STATUS
fixes call :: (DIGITSEQ × (STATUS × DIGITSEQ)) set
fixes speech :: STATUS
fixes engaged :: STATUS
fixes num :: ((STATUS × DIGITSEQ) × DIGITSEQ) set
fixes Connected :: STATUS set
fixes st :: ((STATUS × DIGITSEQ) × STATUS) set
fixes InitSubs :: DIGITSEQ set
fixes NULL :: DIGITSEQ
locale LiftFree CallersDef INV hyps = LiftFree CallersDef INV decls +
assumes ConnectedTyp: T (bsubset Connected↑ (UNIV::STATUS set)↑ )
assumes ConnectedDef: T (beq Connected↑ .ringing↑ , speech↑ .)
assumes CallersDef:
T (beq Callers↑ (bdom (branres (call↑ .;. st↑ ) Connected↑)))”
assumes SubsTyp: T (bsubseteq Subs↑ (UNIV::DIGITSEQ set)↑ )
···
locale LiftFree CallersDef INV goal = LiftFree CallersDef INV decls +
assumes: ¬F (beq Callers↑
(bdom (branres ((call↑ .∪. .(bmapsto s↑ (bmapsto seize↑ NULL↑)).) .;. st↑) Connected↑)))
Figure 6.7: The exported INV PO for the invariant CallersDef with the Event LiftFree
114
Chapter 6. Implementation
Callers = dom(call ; st BConnected),
∀x.x ∈ dom incoming → ¬( f unctional incoming ∧ x ∈ dom incoming → x ∈ incoming0 x),
NULL ∈ Subs, NULL ∈ InitSubs,s ∈
/ dom call, s ∈ Sub]
We need the following pre-processing steps to instantiate a RState with the goal
and the axioms:
• to construct an Isabelle goal term with all the axioms and the INV PO goal.
• to initialise a RState in which the goal term becomes a goal to be proved.
• to import default wave-rules for rippling to the RState.
• to set the implemented RTechn described in the last section as the reasoning
technique.
The first step is to construct a goal term with all the axioms and the goal to represent
the inference rule as follows.
axiom1 , axiom2 · · · axiomn
goal
where the part above the line is a list of assumptions while the below one is a conclusion. In Isabelle, this can be done by using the meta-level implication =⇒ to construct
an Isabelle goal term with the INV goal and all the axioms , i.e.
axiom1 =⇒ axiom2 =⇒ · · · =⇒ axiomn =⇒ goal
where the right-most term is the conclusion, and the rest of the terms are assumptions.
In the example, the constructed goal term is:
Connected ⊂ UNIV =⇒ Connected = {ringing, speech} =⇒
UNIV = {seize} ∪ {connecting} ∪ {ringing} ∪ {speech} ∪ {engaged}∧
({seize} ∩ {connecting} = ∅ ∧ {seize} ∩ {ringing} = ∅∧
{seize} ∩ {speech} = ∅ ∧ {seize} ∩ {engaged} = ∅)∧
({connecting} ∩ {ringing} = ∅ ∧ {connecting} ∩ {speech} = ∅∧
{connecting} ∩ {engaged} = ∅)∧
({ringing} ∩ {speech} = ∅ ∧ {ringing} ∩ {engaged} = ∅)∧
{speech} ∩ {engaged} = ∅ =⇒
st ∈ t f un (UNIV ×UNIV ) UNIV =⇒ num ∈ t f un (UNIV ×UNIV ) UNIV =⇒
6.4. Pre-processing Event-B INV POs
115
∀x.x ∈ UNIV ×UNIV →
(( f unctional st ∧ x ∈ dom st) ∧ f unctional num ∧ x ∈ dom num) ∧ (st 0 x, num0 x) = x =⇒
InitSubs ⊆ UNIV =⇒ Subs ⊆ UNIV =⇒ call ∈ p f un Subs (UNIV × Subs) =⇒
incoming ∈ t f un Subs (P Subs) =⇒ Callers ∈ P Subs =⇒
Callers = dom(call ; st BConnected) =⇒
∀x.x ∈ dom incoming →
¬( f unctional incoming ∧ x ∈ dom incoming → x ∈ incoming0 x) =⇒
NULL ∈ Subs =⇒ NULL ∈ InitSubs =⇒ s ∈
/ dom call =⇒ s ∈ Sub =⇒
Callers = dom((call ∪ {(s, seize, NULL)}) ; st BConnected)
With the goal term, we then use the Poly/ML function from IsaPlanner
PPInterface.init rst of terms
to initialise a RState which has the following goal to be proved.
axiom1 , axiom2 , · · · , axiomn
`
goal
The next step is to insert a set of rewrite rules to the RState as a default set of waverules for rippling. We choose the set of rewrite rules from all the rewrite rules of Rodin
[70] by filtering out those which are invalid as wave-rules. The invalid wave rules are
those that have no common embeddings between left-hand-side and right-hand-side,
e.g.
i ∈ N = True
These rewrite rules are Event-B specific but specification independent, and they are
unconditional and generic across proofs. Therefore, once we have imported them as
lemmas to Isabelle, they can be used to prove Event-B POs from any Event-B specifications. We manually provide each rewrite rule in Isabelle, and prove each as a lemma
using the existing proof methods, e.g. auto and axe’. All these lemmas are proved
directly using these proof methods in Isabelle. Therefore, the work of proving these
lemmas is minor, compared to the work saved by automating PO proofs using POPPA.
All the lemmas are available in Appendix C. Then we use the following function from
IsaPlanner
val RState.get ctxt:
RState.T -> context
116
Chapter 6. Implementation
to get the proof context ctxt from the RState, followed by inserting the list of theorems
into the proof context ctxt using
val WRulesGCtxt.add wrule thm:
thm -> context -> context
to get a new proof context ctxt’. Then we set the ctxt’ back to the RState using the
below function
val RState.set ctxt:
context -> RState.T
to produce a RState with a set of default wave-rules for rippling. The set of the default
wave-rules are the set of rewrite rules from Event-B. This set is general for all POs.
Therefore, this step is automated. The last step is to set the implemented RTechn to the
RState with the following function.
val set rtechn :
RTechn.T option -> RState.T -> RState.T
In general, we can now run the proof for the RState produced above in IsaPlanner.
However, some Event-B INV POs require an additional pre-processing step to remove
the Well Definedness (WD) terms in both the goal and the embedded hypothesis. These
WD terms are inserted for some operations to guarantee the valid use of the operations.
The inserted WDs in both the goal and hypothesis break the embeddings. Currently
this pre-processing has to be done manually. We leave automation as further work and
discuss it in §8.3.
6.5
Running POPPA in IsaPlanner
We implement a top level ML function for users to initialise an RState. The interface
is shown as follows:
val init :
string -> context -> RState.T
It takes a string of the name of the target Event-B INV PO and the current proof context
to initialise a RState. Figure 6.8 shows a screenshot of initialising a RState with this
interface. The bottom of the screen prints the goal of the RState.
To prove the goal using POPPA, the following interface is available for user evaluate the RState in IsaPlanner.
6.6. Summary
117
Figure 6.8: A screenshot of initialising an Event-B INV PO to RState
Figure 6.9: A screenshot of the running proof in IsaPlanner
val PPInterface.ipp rst:
RState.T -> unit
Figure 6.9 shows a screenshot of the use of the interface proving activity in IsaPlanner.
6.6
Summary
The implementation of POPPA is based on Isabelle/HOL, HOL-EventB, IsaPlanner
and IsaScheme. We implement each proof-patching technique as a RTechn, then combine them with rippling using reasoning technique combinators to implement POPPA.
118
Chapter 6. Implementation
We then initialise a RState from the source Event-B specifications and the INV PO
exported from Rodin with the Isabelle for Rodin plugin. IsaPlanner can now apply the
RTchn to the RState to run proof using POPPA for the Event-B INV PO.
Chapter 7
Evaluation
7.1
Introduction
In previous chapters, we presented the design and the implementation of our proof
technique, i.e. POPPA, to automate the Event-B INV POs. POPPA combines rippling
together with three proof patches, i.e. the scheme-based lemma conjecturing patch
(ahLemma), the case split patch and the skeleton rewriting patch. In this chapter, we
report on the experiments with POPPA using an evaluation set consisting of 50 INV
POs from various Event-B case studies, which cover various domains and were developed by different developers. The reason for the choice of INV POs is because the
complexities of INV PO proofs are highly related to what the areas of Event-B specifications are, and how the developers design the specification. This evaluation set is
disjoint from the development set used to develop our proof-patching techniques. The
hypotheses we wish to verify in this chapter are:
1. The guidance of rippling is an effective proof plan for the Event-B INV POs,
and the use of the guidance of rippling in the Event-B INV PO domain can
significantly improve proof automation of INV POs;
2. The scheme-based lemma conjecturing patch, case split patch and skeleton rewriting patch often recovers blocked proof attempts and lead to the success of rippling;
3. The scheme-based lemma conjecturing proof-patching technique often discovers similar lemmas to the lemmas which are inserted interactively in the Rodin
proofs.
119
120
Chapter 7. Evaluation
Moreover, we examine the generality of the schemes of the ahLemma proof patch by
checking the shapes of the lemmas from a new theory, which is the List theory from
the Isabelle online document1 .
In §7.2, we give more details about the evaluation set and outline the experiments
which we conducted to verify our hypotheses. §7.3 gives the analysis for the effective
use of rippling and the proof-patching techniques for the Event-B INV POs to support
the hypothesis (1) and (2). §7.4 analyses the similarities between the conjectured lemmas and those which are interactively inserted in the Rodin’s proofs for the hypothesis
(3). We compare the lemmas from the List theory with the schemes in anLemma in
§7.5. A summary is given in §7.6.
For convenience of presentation, we will call the ahLemma patching technique LC,
the case split patching technique CS and the skeleton rewrite patching technique SR.
7.2
Methodology
To develop POPPA, we use a development set comprising 80 INV POs. This development set is drawn from a diverse set of case studies. POPPA manages to ripple and
fertilise 60 out of these 80 INV POs, and goes on to prove 48 of these fertilised INV
POs. To evaluate POPPA, we prepared an evaluation set which is disjoint from the development set and which is also from diverse case studies. This evaluation set consists
of 50 INV POs. All these INV POs require interactive proofs in Rodin, and none of
them can be proved with any automatic proof method in Isabelle. These INV POs are
chosen from the case studies developed by various developers and were from several
areas including academic algorithms, aeronautics and space, networks, transportation
and business. Note that the development of these case studies is existing work, and not
the result of the work undertaken in this thesis. Also all the case studies are correct
and complete, therefore, all the POs of these case studies are provable and have been
proved interactively in Rodin. Table 7.1 shows the details of the INV POs sources
for the evaluation set. To make the evaluation set generic, we picked these INV POs
evenly from the case studies. Also, for the INV POs from the same case study, we se1 This
theory is available at http://isabelle.in.tum.de/website-Isabelle2013/dist/
library/HOL/List.html
Only LC applied
15
7.2. Methodology
Only CS applied
Fertilised
9
Not
Fertilised
35
Both LC & CS applied
9
15
Only LC applied
7
Only CS applied
1
Only SR applied
1
Both LC & CS applied
2
Both LC & SR applied
2
121
LC & SR
2
lected those Both
which
areapplied
generated
from differentNone
events,
appliedinvariant
2 and machines (levels
of Event-B models). Hence, the INV POs in the evaluation set are not specific to one
case study, one event or one invariant.
We carried out our experiments on the evaluation set, using POPPA
65%
70%
30%
100%
74%
26%
CPU: Intel(R) Core(TM) 35%
i5 @ 2.4GHz
Memory:
8GB OS: OSX 10.9.2
LC not Required
Fertilised
Not Fertilised
Similar Lemmas
LC Required
Software:
Isabelle2012, IsaPlanner
2012
Others
Proved
and Rodin V2.6 (with the Atelier B Provers plugin
Similar Lemmas
Fertilised
35
17
Proved
17
LC Required
and the26Isabelle
Others for Rodin9plugin)
LC not Required
9
Overall, the totals of fertilised and proved INV POs for each case study by using
Not Fertilised
15
POPPA is shown in Table 7.2. As proof complexities of INV POS depends on how the
Event-B model are built, the percentages of the proved INV POs for each case study
varies.
6%
within 3 mins
4
3 - 5 minutes
19
5- 10 minutes
36
more than 10
minutes
8
67
28%
54%
12%
within 3 mins
more than 10 minutes
3 - 5 minutes
5- 10 minutes
Figure 7.1: Performance of LC
The performance of the most important proof patch in POPPA, i.e. LC, are summarised in Figure 7.1. This chart shows the time used for the successful applications of
LC, i.e. a lemma is suggested by LC. A significant part of the applications, i.e. 54%,
were returned between 5 minutes and 10 minutes, and most of the applications, i.e.
88%, were made within 10 minutes.
122
Chapter 7. Evaluation
Case study name
Train system [6]
Concurrent program development [6]
Routing algorithm for mobile agent [6]
The leader election protocol (IEEE1394) [6]
The Buyer / Seller B2B
communication protocol [91]
Developer
Jean-Raymond
Abrial
Jean-Raymond
Abrial
Jean-Raymond
Abrial
Jean-Raymond
Abrial
Thai Son Hoang
Num of
INV POs
Num of all
a
INV POsb
7
17
3
6
3
5
3
5
3
15
3
8
1
1
Thai Son Hoang,
Link state routing development [92]
David Basin and,
Hironobu Kuruma and
Jean-Raymond Abrial
Space Systems Finland Mini Pilot [63]
Dubravka Ilic and
Kimmo Varpaaniemi
Development of flash file systemc [58]
Kriangsak Damchoom
10
45
Response coalition perturbed [26]
Jeremy Bryans
4
12
Jeremy Bryans
8
37
Development of the floodset algorithm [25]
Jeremy Bryans
2
4
Rabins choice coordination algorithm [170]
Ali Gondal
3
7
Totals :
N/A
50
162 d
Disk Paxos: a reliable distributed system
with a network of processors and disks
Table 7.1: Details of the sources of the INV POs for Evaluation. Note that as the total
number of the INV POs which need interactive proof varies significantly among different
case studies, the numbers of the INV POs in the evaluation set are not distributed evenly
among these case studies.
a The
column entitled Num of INV POs shows the number of the INV POs which has been selected
as part of the evaluation set from those INV POs described by the column entitled Num of all INV POs
for each case study.
b The column entitled Num of all INV POs shows the total number of the INV POs, which can not
be proved by any automatic proof methods in Isabelle and Rodin, for each case study;
c Only parts of this case study are used.
d We did not try POPPA on all the INV POs for those case studies for evaluation. This is because
many of them had already been used in the development set. Also, we deliberately avoid selecting those
INV POs if we have included some INV POs generated for the same invariant or the same event. This
is because over-representation of one kind of problem might skew the evaluation results.
7.3. Effectiveness Analysis
Case study name
123
Nums of
Proved POs
Nums of POs
Train system
3
7
Concurrent program development
3
3
Routing algorithm for mobile agent
1
3
The leader election protocol (IEEE1394)
1
3
The Buyer / Seller B2B communication protocol
1
3
Link state routing development
2
3
Space Systems Finland Mini Pilot
1
1
Development of flash file system
6
10
Response coalition perturbed
1
4
4
8
Development of the floodset algorithm
1
2
Rabins choice coordination algorithm
3
3
Disk Paxos: a reliable distributed system
with a network of processors and disks
Table 7.2: Details of fertilised and proved INV POs by using POPPA
The discussion for hypotheses (1) and (2) are based on the following data collected
from our experiments:
• The results of the final proof, i.e. whether the INV PO is proved.
• The results of rippling, i.e. whether fertilisation is applied to the goal.
• The successful application of the proof-patching techniques for each INV PO,
e.g., whether a proof technique was triggered and successful applied.
All data mentioned above are available online in https://www.sites.google.com/
site/evalpoppa/ and in http://homepages.inf.ed.ac.uk/s1064212/evalpage/
index.html.
7.3
Effectiveness Analysis
To evaluate the effective use of rippling to automate INV POs, we ran several experiments using rippling with POPPA which contains all three proof-patching techniques.
124
Chapter 7. Evaluation
For ease of presentation, we name it V1. To analyse the effectiveness of each patching technique, we also experimented with three different versions which are made by
switching off one proof patch from V1. They are named V2, V3 and V4. For comparison, we also experimented using a version with all patches switched off, i.e. V0.
Table 7.3 shows the details of the combinations of rippling and the proof-patching
techniques.
Version
Rippling LC
V0
Y
V1
CS
SR
N
N
N
Y
Y
Y
Y
V2
Y
N
Y
Y
V3
Y
Y
N
Y
V4
Y
Y
Y
N
Table 7.3: Various combinations of rippling and proof patches for evaluation
The overall experimental results of these versions are shown in Table 7.4. We will
continue to analyse these results to discuss our hypotheses in the rest of this section.
Version
Proved
Fertilised
LC
CS
SR
V0
0
0
0
0
0
V1
27
35
37
21
5
V2
5
9
0
21
2
V3
13
17
27
0
5
V4
25
32
37
21
0
Table 7.4: The overall experimental results for all versions. Total numbers of INV POs
in the evaluation set is 50. The column entitled Proved shows the number of INV POs
which was proved; the column entitled Fertilised shows the number of the INV POs to
which fertilisation was successfully applied; the columns entitled LC, CS and SR show
the number of INV POs which triggered and successfully applied the scheme-based
lemma conjecturing patch, the case split proof patch and the skeleton rewrite proof
patch, respectively.
7.3. Effectiveness Analysis
7.3.1
125
The Effectiveness of the Rippling Guidance
In this project, we have argued that the majority of interactively proved Event-B INV
POs can be seen to be the step cases in inductive proofs, as shown in §4.2. One key
strategy to prove the step cases of inductive proofs is to rewrite the goal towards the
embedded hypothesis, until the embedded hypothesis becomes applicable to simplify
the goal. Rippling uses this strategy as meta-level guidance to improve the automation of inductive proofs. In this section, we want to show that the use of this rippling
guidance in the Event-B INV PO domain is effective. Our analysis only focus on the
results of V1, as V1 contains all three proof-patching techniques and makes the best
use of the rippling guidance compared to the other versions.
SR
23%
37
30%
70%
77%
21
Fertilised
0
V3
5
0
Not Fertilised
Fertilised
35
Not
Fertilised
15
V4
Fertilised but Not Proved
Proved
Proved
27
Fertilised but Not Proved
8
Figure 7.2: The experimental results pie chart categorised by ‘if fertilised’ and ‘if proved’.
The 50 INV POs have been first categorised by ‘whether the PO is fertilised’, then
further categorised the fertilised INV POs with ’whether the PO is proved’.
In Figure 7.2, the overall results show that 70% of INV POs are fertilised using
POPPA. Note that being fertilised means rippling has completed, and it is a sign of
successful application of rippling guidance which is leading rewrite towards using the
embedded hypothesis to simplify the goal. When fertilised, a majority of INV POs,
27 out of 35 (77%), can be proved automatically using V1. This suggests that, for the
27 INV POs, the major proof complexities have been effectively simplified with the
rippling guidance. The automatic proof methods in Isabelle, which were not able to
13%
%
13%
126
Chapter 7. Evaluation
prove the original goal, now can prove the simplified subgoals.
However, there are still 8 out of 35 (23%) INV POs for which rippling guidance
is effective, but the automated proof fails at a later point. Most of the remaining subgoals of these INV POs require case splits or instantiations of quantifiers in some
non-embedded hypotheses. These types of proof complexities are out of rippling guidance’s scope.
For those INV POs which cannot be automated, the proof information from POPPA,
e.g. the proof status and the proof history containing rewrite steps, can also be useful
for users to analyse the failures. Each rewrite steps in POPPA, i.e. each wave step,
follows meta-level guidance, and therefore has a clear purpose, i.e. moving certain
wave-fronts up to the root. By analysing the proof status and proof history, users can
have a high-level understanding of the progress of the failed proofs which can help
them figure out what might be missing in the failed proofs. We will discuss this later
in §8.3.
7.3.2
The Effectiveness of the Proof-patching Techniques
Proof-patching techniques were developed to unblock rippling. Therefore, when we
assess the effectiveness of the proof-patching techniques, we are only concerned whether
the proof-patching techniques are able to recover rippling proofs and lead to the success of rippling.
As shown in Table 7.4, none of the INV POs can be fertilised in V0. That is,
rippling is blocked for all the INV POs in the evaluation set, and proof-patching techniques are required to recover rippling. When three proof-patching techniques are
enabled in V1, 35 out of 50 (70%) INV POs have been fertilised. This result suggests
that the rippling failures of 70% of the INV POs have been recovered by the proof
patch in V1. Figure 7.3 shows further details of the different configurations of the
proof-patching techniques.
LC is shown to be the most important proof-patching techniques in our work. As
shown in Figure 7.3, LC has been successfully used to unblock proofs to be fertilised
for 26 out of the 35 (around 75%) fertilised INV POs. This number includes 15 INV
7.3. Effectiveness Analysis
127
6%
26%
13%
70%
13%
43%
30%
13%
7%
26%
7%
Fertilised
Not Fertilised
Only LC applied
Only CS applied
Only SR applied
Both LC & CS applied
Both LC & SR applied
None applied
Only LC applied
Only CS applied
Both LC & CS applied
Both LC & SR applied
Fertilised
47%
Only LC applied
15
Only CS applied
9
35
Both LC & CS applied
Both LC & SR applied
9
Not
Fertilised
2
15
Only LC applied
7
Only CS applied
1
Only SR applied
1
Both LC & CS applied
2
Both LC & SR applied
2
None applied
2
Figure 7.3: Details of the usage of proof-patching techniques in V1. The 50 Event-B INV
POs of the evaluation set are categorised by ‘whether fertilised’, then they are further
categorised by ‘which proof-patching technique(s) have been successfully applied’.
POs applying only LC, 9 INV POs applying both LC and CS and 2 INV POs applying both LC and SR. For the 15 INV POs where rippling did not succeed, 11 out of
them (around 73%) applied LC to recover rippling at some point but yet failed to be
fertilised. Therefore, LC has been applied to recover rippling for 37 out of 50 (74%)
of all the Event-B INV POs in the evaluation set 2 .
Similarly, CS has been successfully used to unblock proofs to be fertilised for 18
out of the 35 (around 52%) fertilised INV POs. This number includes 9 INV POs applying only CS and 9 INV POs applying both CS and LC . For the 15 INV POs where
rippling did not succeed, 3 of them applied CS to recover rippling at some point but
yet failed to be fertilised. Therefore, CS has been applied to recover rippling for 21 out
of 50 (42%) of all the Event-B INV POs in the evaluation set.
2 The
use of rounding results in the sum of all the percentages in the fertilised pie chart exceeds
100%, i.e. 101%
128
Chapter 7. Evaluation
SR is shown to be the least important proof patch. It has been used to unblock
proofs to be fertilised for only 2 out of the 35 (around 6%) fertilised INV POs, where
both of these INV POs applying both SR and LC. For the 15 INV POs where rippling
did not succeed, 3 of them applied SR to recover rippling at some point but yet failed to
be fertilised. Therefore, SR has been applied to recover rippling for 5 out of 50 (10%)
of all the Event-B INV POs in the evaluation set.
LC none of the
CS
Note that there are 2 INV POs to which
proof patchesSR
are successfully
Num of INV POs
40INV POs which are not fertilised, the proof-patching techapplied. Also, for the 15
niques fail to recover rippling37at some point. The main causes are the37
need of case
30
30%
splits and the instantiation of quantifiers in the non-embedded hypotheses. We will
27
discuss the limitations of20the proof-patching techniques in chapter 8.
21
21
21
Fertilised
10
The analysis above discussed
the effectivenesses of the proof-patching techniques
from the perspective of the usage during
We
6 rippling.
0
2 will continue
0 5 to assess the
0 ef0
fectiveness of the proof-patching techniques
by V2
comparing theV3results whenV4
different
V1
F
proof-patching techniques are disabled.
N
F
Fertilised
Num of INV POs
40
35
30
32
20
17
10
0
9
0
V0
V1
V2
V3
V4
Figure 7.4: Numbers of fertilised INV POs
As can be seen from Figure 7.4, when LC is disabled, the number of the fertilised
INV POs significantly drops to 9 out of 50 (18%). The drop indicates that LC recovers
failed rippling for 26 of the 35
6%(74%) fertilised INV POs. Similarly, when CS or SR
3%
13%
70%
is disabled, i.e. V2 and V3, these numbers decrease to 17 of 50 (34%) and 32 of 50
13%
(64%), respectively. Therefore,
CS recovers
26%
43% failed rippling for 18 out of 35 (51%) of
30%
13%
7%
23%
Fertilised
Not Fertilised
Only LC applied
Only CS applied
Both LC & CS applied
Both LC & SR applied
47%
7%
Only LC applied
Only CS applied
Only SR applied
Both LC & CS applied
Both LC & SR applied
7.4. Comparing with the Lemmas in Manual Proofs
129
fertilised INV POs, while SR only contributes to 3 out of 35 (9%) INV POs. Thus, LC
is shown to be the most important proof-patching technique, followed by CS, and SR
is the least.
LC
CS
SR
Num of INV POs
40
37
37
30
30%
27
20
21
21
21
Fertilised
10
5
0
0
V1
2
V2
0
V3
5
0
F
V4
N
F
Figure 7.5: Numbers of the Event-B INV POs which needs each patch
Fertilised
Moreover, from Figure 7.5, we observe that the usage of each proof-patching tech40
Num of INV POs
nique varies in different degrees when different proof-patching techniques are disabled.
The first thing to30notice is 35
that the usage of CS remains the same as 21, no matter
32
whether LC and SR are disabled or not. In contrast to the steady applicability of CS,
20only affected when CS is disable, i.e. falling to 27; the usage of SR
the usage of LC is
17a drop from 5 to 2.
is only affected when LC is disabled, i.e.
10
0
7.4
9
0
Comparing
in Manual Proofs
V0 with
V1 the
V2 Lemmas
V3 V4
Recall that Rodin allows users to prove a lemma and then insert the lemma into the
assumptions of the goal using the command ‘ah’. This feature serves as a cut rule for
a proof, i.e.
assm1 , · · · assmn ` lemma assm1 , · · · assmn , lemma ` goal
6%
assm1 , · · · assmn `70%
goal
13%
13%
26%
43%
For ease of presentation, we use
(ah) to refer to the lemma which is interactively47%
in30%
13% by the LC with
serted with ‘ah’ in this section. We compare the lemmas
conjectured
7%(3). For the
26% ah, and use this result to support hypothesis
the interactively inserted
Fertilised
Not Fertilised
Only LC applied
Only CS applied
Only SR applied
Both LC & CS applied
Both LC & SR applied
None applied
Only LC applied
Only CS applied
Both LC & CS applied
Both LC & SR applied
Only LC applied
7%
15
Only LC applied
7
Only CS applied
1
130
Chapter 7. Evaluation
reason that an ah could be a combination of several steps of applying wave-rules or
conjectured lemmas, we consider L , which is a lemma produced by LC, is similar to
an ah, if L satisfies the following condition:
• there exists an equation-based ah which is inserted for the same goal as L , and
the applications of ah are the same as the application of L together with the subsequent applications of wave-rules and other conjectured lemmas in the rippling
proofs.
A special case of this condition is when both the LHS and RHS of the ah can
already be unified with the LHS and RHS of the L . In this case, there is no need to
further consider the subsequent applications of wave-rules and conjectured lemmas.
To give a general explanation of this condition, consider the ah added in Rodin for a
goal is
dom((( f ∪ f 0 ) ; g) B S) = dom(( f ; g) B S) ∪ dom(( f 0 ; g) B S)
and the following wave-rule is available.
(a ∪ b) B c = (a B c) ∪ (b B c)
(7.1)
LC has been applied two times and generated two lemmas for the goal.
( f ∪ f 0 ) ; g = ( f ; g) ∪ ( f 0 ; g)
(7.2)
dom( ( f ; g) ∪ ( f 0 ; g) ) = dom(( f ; g) B S) ∪ dom(( f 0 ; g) B S)
(7.3)
We would consider that LC can produce similar lemmas to ah, because ah is the equivalent to the applications of (7.2) followed by (7.1) and (7.3).
The generated lemmas from the our proofs of the 35 fertilised INV POs have been
examined, as all the lemmas have been conjectured by LC when necessary in the scope
of rippling guidance. Figure 7.6 shows the results of the comparison. For the 26 INV
POs out of the 35 fertilised INV POs, which LC has been successfully applied, there
are 17 (around 65%) of them which have produced all the similar lemmas as the ah
from the interactive Rodin proofs. All the 17 INV POs have been proved. More importantly, it shows that LC often speculates the same lemmas as humans. When LC is
successfully applied and produces the similar lemmas as the ah from the Rodin proofs,
the proofs of the INV POs are simplified by the conjectured lemmas.
7.4. Comparing with the Lemmas in Manual Proofs
70%
131
65%
26%
100%
74%
30%
35%
Rippled
Not Rippled
Rippled
Not Rippled
35
LC not Required
LC Required
LC Required
26
LC not Required
9
Proved
Similar Lemmas
Others
Similar Lemmas
17
Others
9
Proved
17
15
Figure 7.6: The results of comparing the ah with the lemmas conjectured by LC
We do not expect LC to generate the lemmas covering all the ahs. Also we notice
that not all the generated lemmas are related to ahs. We analysed ah with which LC
did not produce similar lemmas, and we summarise the following explanations:
• Rippling could be blocked due to the need of case splits. Therefore, rippling has
not reached the point where LC can be triggered to generate the similar lemmas,
even if LC is capable of producing them;
• LC manages to conjecture the similar lemmas but the automatic proof methods
in Isabelle are not powerful enough to prove them;
• LC generates an ah, but chooses to apply a different one in the proof;
• LC is only capable of generating equation based lemmas, but the ahs are not
subject to this constraint. These non-equational ahs are usually inserted to assist
the automatic proof methods to handle predicate operations, e.g. ⊂;
• The automatic proof methods in Rodin and Isabelle have different strengths and
weaknesses in proving INV POs. So different lemmas are required to address
the problematic parts of the proofs;
• The interactive proofs in Rodin might adopt a different proof plan from the one
of rippling guidance. Hence, the entire proofs in Rodin are completely different
from the corresponding ones with rippling.
132
7.5
Chapter 7. Evaluation
Comparing with the Lemmas from the List Theory
Our work is developed for the domain of the pre-defined datatypes and operators of the
pre-defined mathematical language in Event-B. The mathematical language of Event-B
can be extended to allow for new datatypes and new operators with the theory component of Rodin [37]. Therefore, we wanted to examine how our work would operate
with the new datatypes and operations from a fresh theory. In particular, we wanted to
investigate whether the schemes from our most effective proof patch, i.e., LC, can still
capture patterns of the rewrite rules in the new theory.
We wish to simulate the scenario where a new theory is encoded to Event-B to
allow for new operators and datatypes. We choose a theory from the Isabelle library,
i.e. the List theory. This theory is not part of the mathematical language in Event-B,
and it contains new datatypes and operations. As this theory is well-developed, there
are many rewrite rules available. None of rewrite rules is not encoded into Rodin, and
we want to check if our scheme can capture the rewrite rules which can be used as
wave-rules.
From this theory, we then collected a set of the rewrite rules which can be used as
wave-rules. For each equation-based lemma, two rewrite rules are considered, i.e.,
LHS
RHS
RHS
LHS
and
We then compare these rewrite rules with the schemes of LC.
Our criteria to decide if a rewrite rule is captured by a scheme are that: presumably
with the same substitution,
• one side of the rewrite rule matches the LHS of the scheme; and
• the other side of the rewrite rule matches the RHS of the scheme.
Note that the LHS of the rewrite rule is not necessarily the same as the LHS of the
source lemma, e.g. it can be the RHS of the source lemma. The criteria above only
concern the shape of the scheme, but not the construction of the dynamic seeding pool
for instantiation. This is because the heuristics to construct the seeding pool are closely
Not Rippled
15
7.5. Comparing with the Lemmas from the List Theory
133
related to the operators of the Event-B mathematical language. These heuristics would
not work for the operations of a new theory.
35%
15%
49%
Unary
Operators
25
Binary
Operators
35
Ternary
Operators
11
Unary Operators
Binary Operators
Ternary Operators
Figure 7.7: Operators in theory List
The first thing to notice is that there are 71 new operators in the List theory. Figure
7.73 shows the arity of these operators. Recall that there is only one operator which has
more than two arguments in the mathematical language of Event-B, which is partition,
74%
26% using biand the operation with partition can be rewritten to a term which is defined
nary operations only. Unlike the operators in the pre-defined mathematical language,
3
32%
there are 11 ternary operators in the List theory. However, these ternary operators are
only a small proportion of all the operators, i.e. 15%. Captured
Unary and
binaryRules
operators are
Rewrite
Uncaptured Rewrite Rule
still the majority of the operators, i.e. 25% and 49%, respectively. Therefore, although
the use of heuristic (5.3.1) for scheme, which limits the operators of the LHS of the
Two WF in th
Rewrite Rule
Ripple Over
LHS is Match
schemes to either binary or unary, would miss some
shapes of the rewrite rules from
Captured
190
Rewrite
the List theory, the impact is minor. Moreover, this
minorRules
impact argument are also
agreed by our results. We will come back to this later, when analysing the uncapturedTwo WF in the L
shapes of the rewrite rules.
Uncaptured
Rewrite Rule
Rewrite Rule wit
Operators
66
From the List theory, we identify 256 rewrite rules which can be potential wave-Ripple Over Mor
Operators
rules for rippling. By using our two criteria introduced in this section, the overall
LHS is Matched
results are:
• the shape of 190 of 256 (74%) of the shapes of the rewrite rules are captured by
our schemes.
3 The
99%
use of rounding results in the sum of all the percentages in the pie chart is less than 100%, i.e.
Captured
Rewrite Rules
190
134
Uncaptured
Rewrite Rule
Two Wave-fronts in the LHS
Chapter
26
Rewrite Rule with Ternary
Operators
12
7. Evaluation
• 66 out of 256 (26%) of the shapes
of Over
the More
rewrite
rules are not captured.
Ripple
than One
66
7
Operators
LHS can
is Matched
RHS is not
21
These results suggest that our schemes
alsobut
capture
the shapes
of a significant
numbers of wave-rules, even in a new theory with new operators.
55%
63%
7%
93%
80%
20%
45%
37%
LHS is Matched
LHS is not Matched
Rewrite Rule with
Ternary Operators
Ripple Over More than
One Operators
LHS is
Matched
Rewrite Rule with
Ternary Operators
12
Ripple Over More than
One Operators
7
LHS is not
Matched
Both LHS and RHS
are Matched
LHS is Matched
but RHS is not
Both LHS and RHS
are Matched
190
LHS is Matched
but RHS is not
47
237
New Shapes
Two Wave-fronts
New Shapes
21
Two Wave-fronts
26
19
Figure 7.8: Results of captured and uncaptured rewrite rules from the LHS and RHS
matching perspective
We now continue to analyse the results for each criterion. The analysis outcome
is shown in Figure 7.8. For the reason that, in our scheme construction process, we
first match the LHS and then generated the corresponding possible shapes of the RHS
for the matched LHS. Our analysis starts with the matching results of the LHS of the
scheme, followed by the matching results of the RHS.
As shown in Figure 7.8, we summarise that
• 237 of 256 (93%) of the LHS of the rewrite rules can be matched with one of the
LHS of the schemes.
• 190 of 237 (80%) of the RHS of the rewrite rule are captured by our scheme,
when their LHS are matched.
Only 19 of 256 (7%) rewrite rules fail to match the LHS with our schemes. 12 of
↑
them (63%) are caused by the ternary operators on the LHS e.g., g( f (H, a) , x, y), and
7.6. Summary
135
↑
7 of 19 (37%) are caused by rippling over two operators, e.g., g1 (g2 (( f (H, a) , x), y).
Note that the 12 unmatched rewrite rules are the only ones which are affected by the
ternary operators in all 256 rewrite rules. That is, only around 5% of all the possible
wave-rules are introduced by the ternary operators in the new theory. Therefore, the
use of the constraint of considering only binary and unary operators in our schemes
only miss a very small proportion of the shapes of the wave-rules in the List theory
which includes 11 ternary operators.
There are 47 of 237 (20%) rewrite rules for which our scheme cannot capture the
RHS. A significant part of them, i.e., 55% (26 of 47), are caused by the case when there
are two wave-fronts in LHS and both of them have to be unblocked at the same time,
but we only try to unblock one wave-front on the RHS. A typical example of such a
rewrite rule is a symmetric version of a distributive rule, e.g.,
↑
(a ∗ c) + (b ∗ c)
↑
(a + b) ∗ c
↑
Although this type of uncaptured shape exists in the pre-defined mathematical operators, e.g.,
(p C
− r)
↑
∪ (q C
− r)
↑
(p ∪ q) C
−r
↑
they are rarely applicable in our experiments. Therefore, this type of uncaptured shape
might not have a significant impact on the use of our scheme for a new theory. The
remaining 21 rewrite rules of the uncaptured shapes are the case where new shapes are
needed when the LHS is matched. However, they are a small proportion of the set of
all rewrite rules.
7.6
Summary
We chose a set of Event-B INV POs as an evaluation set from various case studies
developed by different developers. The evaluation set is disjoint from the development
set. The implementation of POPPA has been evaluated using the Event-B INV POs
from this evaluation set.
We supported the hypothesis that guidance of rippling is an effective meta-level
proof plan for the Event-B INV POs, by showing that 70% of the INV POs are successfully rippled and fertilised, and 77% of the 70% (around 54% overall), have been
136
Chapter 7. Evaluation
fully discharged afterwards automatically with POPPA.
To show the hypothesis that our proof-patching techniques are effective and essential to unblock rippling, we compared the results of the completed version of our implementation with different configurations of proof-patching techniques. Initially, all
the 50 INV POs are blocked in rippling. 35 out of 50 (70%) INV POs were unblocked
and succeed to be fertilised using all three proof-patching techniques in rippling. This
number varies when different proof patching techniques are switched off.
We also verified the hypothesis that the LC is often capable of generating the lemmas which are similar to the ones inserted interactively by humans during the proofs
of the evaluation set. We compared the lemmas produced by the 35 fertilised INV POs
with the ones inserted interactively from the proofs in Rodin. For 26 of them where
LC is required, 17 out of the 26 INV POs (around 65%) LC is able to generate similar
lemmas.
Furthermore, we compared the shapes of 256 lemmas from the List theory with the
schemes in ahLemma proof patch. These lemmas are possible wave-rules for rippling.
The results show that the shapes of 74% of these lemmas are captured by the schemes
in ahLemma.
Chapter 8
Related Work & Future Work
8.1
Introduction
In §8.2 we discuss the related work regarding the use of theory formation systems in
lemma discovery, as well as the automatic provers in Rodin. In §8.3, we conclude some
possible future work to improve our work in various aspects. A summary is given in
§8.4.
8.2
8.2.1
Related Work
Theory Formation for Lemma Discovery
ahLemma is inspired by the lemma calculation and lemma speculation proof critics
[103]. Both lemma calculation and lemma speculation were originally developed as
proof patches for rippling in the inductive theorem proving domain.
• The lemma calculation critic was developed for equation-based goals to which
weak fertilisation can be applicable. This critic is eager to apply weak fertilisation so that a lemma can be generated by generalising the subsequent goal of the
application of weak fertilisation. This critic is successful in inductive theories,
as the cut rule is inevitable and these generalised lemmas can often be proved
by induction in inductive theories. However, in the case when the cut rule is not
necessary, e.g. the set theory in Event-B, the proof complexities of the produced
lemmas are almost the same as the original goals. Compared to the heuristic of
eager fertilisation of this critic, heuristic eager rippling (4.2.3) in POPPA works
in the opposite way. It postpones application of weak fertilisation until both LHS
137
138
Chapter 8. Related Work & Future Work
and RHS are fully rippled, for the reason that applying weak fertilisation at an
early stage would not simplify goals significantly. Therefore, although lemma
calculation does always produce the conjectures which can recover proofs, these
conjectures are not likely to be proved with the same proof methods which failed
to prove the original goals.
• Lemma speculation constructs schemes by using the known possible shapes of
the skeleton after the application of a further ripple step, and placing a metavariable to represent the unknown term structures in the wave-front. Lemma
speculation then relies on intermediate middle-out rewriting steps and higherorder unification to instantiate the meta-variable in schemes. Both ahLemma
and lemma speculation are based on the schemes to produce lemmas, i.e., the
use of meta-variables in lemma conjecturing. The scheme produced in lemma
speculation is more general than the ones produced in ahLemma. This is because
lemma speculation applies higher-order unification to the subsequent applications of wave-rule to gradually instantiate the meta-variable, but ahLemma tries
to instantiate the meta-variables using IsaScheme in the current proof steps. The
instantiation of the meta-variables in lemma speculation requires the existence
of subsequent wave-steps before fertilisation is applied. For example, lemma
speculation would fail to construct a lemma to unblock the LHS of the following
goal,
↑
↑
f0 ( h(a, b) , c) = f1 ( f2 ( g(x, y) , z))
This is because no subsequent wave-step is available for lemma speculation to instantiate the meta-variable to some subterms in the wave-front. However, lemma
speculation can still instantiate the inserted meta-variable as projection when
unifying with the application of weak fertilisation. Similarly, lemma speculation
would also fail to conjecture a lemma for the RHS, if the wave-rule to ripple the
wave-front over f1 is also missing. ahLemma does not have such a restriction.
In general, the applicability of ahLemma is better than lemma speculation.
Apart from the lemma speculation and lemma calculation proof critics, there are
lemma discovery techniques which have been implemented in some systems to suggest lemmas in the middle of proofs. Example of these systems are Hipster [113] and
ACL2(ml) [88].
8.2. Related Work
139
Hipster also features lemma discovery by theory exploration in Isabelle/HOL. The
traditional uses of theory exploration systems for lemma discovery are in a bottomup approach which tries theory exploration to produce potentially interesting lemmas
before starting proving. ahLemma works in a top-down approach which generates lemmas from the point when proof attempts fail. Hipster can work in either the top-down
approach (or proof mode) or the bottom-up approach (or exploratory mode). Hipster takes operations as inputs and translates Isabelle/HOL theories into Haskell and
then generates equation-based conjectures containing the given operations, by testing
and evaluating the Haskell program. These conjectures are then exported back to Isabelle/HOL for proofs and filtering. The filtering is with respect to complexity of
proofs. Two configurable proof methods with different proving capabilities, which are
called routine reasoning and difficult reasoning, are used for this purpose of filtering.
Hipster only returns those conjectures that are proved by the difficult reasoning but not
the routine reasoning.
Another theory discovery system is ACL2(ml), which takes an analogical approach
to construct equation-based lemmas. ACL2(ml) can synthesize analogous lemmas for
the current goal from a given pair of an example lemma and an example theorem where
the theorem has been proved using the lemma. ACL2(ml) uses statistical machinelearning techniques to generate the information of similarity of term structures between
the current goal and the example theorem. The desired lemmas are then constructed
by analogically mutating the example lemma using the information of similarity.
Hipster, ACL2(ml) and ahLemma can only produce equation-based lemmas. Hipster constrains lemmas by proof complexity. It filters out lemmas which can be proved
by the less powerful proof method. The constraints in ACL2(ml) mainly come from
the example theorem and the example. Both Hipster and ACL2(ml) are independent
of rippling, but the scheme approach used in ahLemma is more suitable as a proof
patch, because schemes are used to represent the shapes of the lemmas which satisfy
the rippling expectation.
8.2.2
Automatic Provers in Rodin
Rodin [5, 7, 36, 51] has a built-in automatic prover for proof automation support, i.e.
New PP [72]. There is also an Atelier B proof plugin to extend the support using the
140
Chapter 8. Related Work & Future Work
provers from Atelier B, i.e. PP and ML [72]. Some strengths and weakness of these
provers are: New PP is unsound [72] but it can output a set of used hypotheses; while
PP and ML are sound but they do not output a set of used hypotheses.
More recently, two more Rodin proof plugins, i.e. SMT-solver plugin [59] and Isabelle for Rodin [158], were developed. The SMT solver plugin provides an interface
to use external SMT-solvers. The Isabelle for Rodin plugin exports POs to Isabelle,
and then proves the POs using an automatic proof method in Isabelle, which was developed for the Isabelle for Rodin plugin, i.e. axe’. axe’ involves the proof techniques
such as simplifiers, classical reasoners and SMT solvers.
All these automatic provers only work at the object-logic level, an example of this
approach is unfolding definitions to primitive operations for proofs. POPPA works
both at the meta-level and the object-logic level. Using the meta-level guidance from
rippling, POPPA can automate those INV POs which previously could only be proved
interactively. Note that we only look at those interactively proved INV POs in this
project. Also POPPA uses automatic proof methods that work at the object-logic level
internally, e.g. axe’, and these automatic proof methods can be easily changed in
POPPA. Therefore, we do not consider POPPA as a substitute for the automatic provers
which work at the object-logic level, but as a complementary tool to work with them.
That is, combining POPPA with the automatic provers working at the object-logic
level, more POs can be automated.
When proofs fail in POPPA, the failed proof information can also be helpful for
users to analyse failures. This is because, using the meta-level guidance from rippling,
each rewrite step and patching step in POPPA has a clear purpose, e.g. moving wavefront outwards. Users can more easily understand what the current proof progress is.
8.3
Future Work
We summarise possible work in which research efforts can be put in the future from the
aspects including the efficiency and effectiveness of our proof methods, applicability
and usability.
8.3. Future Work
141
Lemma Discovery
One main constraint on POPPA, from the efficiency point of view, is the applicability
of the currently available counter-example checkers. The currently available counterexample checkers, i.e., Quickcheck [19] and Nitpick [22], do not work for the conjectures generated by ahLemma. Quickcheck cannot handle the type defined by typedecl
which is used to formalise the carrier sets of Event-B models. Nitpick fails to check
conjectures due to reaching its search limits to explore the search space of proof context
which includes the full Event-B theory. Currently disproofs are achieved by proving
the negation of the conjectures using the same proof method used in proving the conjectures. One of the limitations of this approach is that, if the proof method could not
prove a conjecture in a given proof context, it is unlikely that the proof method can
disprove the negation of the conjecture in the same proof context.
The improvement of applicable counter-example checkers can directly shorten the
time which ahLemma uses to conjecture lemmas.
Another drawback of POPPA, from the effectiveness point of view, is the limitations of the proving capabilities of the proof method which are used to prove the conjectures from ahLemma. The proof method is not powerful enough at proving the case
when either case splits or instantiating the quantifiers of the non-embedded hypothesis
is required. For example, consider the following INV PO:
a≤b
∀i.k(i, d)
···
f (a, b, c, d)
`
f (a, b, g(c), d)
where a, b, c and d are variables of a machine; f (a, b, c, d) is an invariant; and f (a, b, g(c), d)
is an INV PO. If the proofs of an ahLemma conjecture require a case split on a < b or
a = b, which is suggested by a ≤ b, or the proofs need a non-trivial instantiation of i in
∀i.k(i, d), the current proof method will fail to prove the conjecture. Therefore, if the
proof method could handle these two cases, more lemmas can be proved to unblock
rippling which can contribute to a further improvement of the proof automation.
142
Chapter 8. Related Work & Future Work
One more possible improvement is to conjecture lemmas by only checking the
properties of the related operators, e.g. associativity, but not through IsaScheme. For
example, if we have the following LHS,
↑
f (A, f (B, C) )
where f is a associative operator, then we can have the following RHS without running
IsaScheme.
f ( f (A, B), C)
↑
Rodin internally preserves the commutativity and associativity properties of operators. One future work can be to get the associativity property from Rodin, and construct lemmas in a more lightweight way when possible, before running IsaScheme.
This will be more useful, especially, when more new operators are provided by users
in the theory component of Rodin [37].
Rippling for Non-Deterministic Events
The meta-level guidance of rippling is essential for POPPA, in particular, for the proof
patches, because the proof patches rely on the prediction for the next proof step from
the guidance. The key property required by rippling is the embedding of a hypothesis
in a goal. Therefore, POPPA can only be applied to those POs where the embedding
exists. In this project, we only apply POPPA to INV POs, as INV POs satisfy the
embedding property. POPPA could be applied to other types of POs if this embedding
property is satisfied.
In §4.2 we have shown that INV POs can be seen to be inductive proofs. POPPA
can be applied to those INV POs which are step cases. For the INV POs from deterministic events, they are always in the typical shape of step cases in inductive theories,
where one of the hypotheses is embedded in the conclusion. However, when events
are defined in a non-deterministic way, e.g.,
variable :∈ set expression
the INV POs from these events are not in the typical shape of step cases. For example,
consider an invariant inv(x) where x is a variable in an Event-B machine. A non-
8.3. Future Work
143
deterministic event changes x by the following operation
x :∈ f(x)
where f is a set expression taking x as a parameter, and x is assigned to an arbitrary
value from the set specified by f. The related INV PO is
· · · , x0 ∈ f(x), inv(x) ` inv(x0 )
where no embedding is available. Currently POPPA cannot handle the INV POs generated from non-deterministic events. There is a need for further work to process these
INV POs before POPPA becomes applicable. We will show the process as follows.
If we consider x0 as a skolem constant after eliminating an universal quantifier,
we can generalise the goal by putting the universal quantifier back and pushing the
hypothesis containing x0 , which is x0 ∈ f(x), in the conclusion, i.e.,
· · · , inv(x) ` ∀x0 . x0 ∈ f(x) ⇒ inv(x0 )
Then we can further eliminate the universal quantifier in the conclusion using the
Hilbert choice operation with the following rewrite rule
∀x.P(x)
P(ε λx.¬P(x)
which replaces the quantified variable x0 as
ε λx0 . ¬(x0 ∈ f(x) ⇒ inv(x0 ))
Therefore, the goal becomes
· · · , inv(x)
`
(ε λx0 . ¬(x0
∈ f(x) ⇒ inv(x0 ))) ∈ f(x) ⇒ inv(
ε λx0 . ¬(x0
∈ f(x) ⇒ inv(x0 )))
↑
↑
And then rippling becomes applicable. Thereafter, POPPA can be applied to this goal.
144
Chapter 8. Related Work & Future Work
[DIGITSEQ]
STATUS ::= seize | ringing | speech | engaged | connecting
Connected == {ringing, speech}
InitSubs : P DIGITSEQ
NULL : DIGITSEQ
st : (STATUS ⇥ DIGITSEQ) ! STATUS
num : (STATUS ⇥ DIGITSEQ) ! DIGITSEQ
InitSubs ✓ DIGITSEQ
NULL 2 InitSubs
8 x : (STATUS ⇥ DIGITSEQ) • (st(x ) 7! num(x )) = x
Figure 8.1: The Z specification of the telephone exchange system corresponding to the
context part in Event-B
State
Subs : P DIGITSEQ
call : DIGITSEQ !
7 (STATUS ⇥ DIGITSEQ)
incoming : DIGITSEQ !
7 P DIGITSEQ
Callers : P DIGITSEQ
NULL 2 Subs
call 2 Subs !
7 (STATUS ⇥ Subs)
dom call ✓ Subs
Callers 2 P Subs
incoming 2 Subs ! P Subs
Callers = dom(call o9 st B Connected )
8 x : DIGITSEQ • x 2 dom incoming ) x 2
/ incoming(x )
Init
State 0
LiftFree
State
s? : DIGITSEQ
call 0 = ;
Callers 0 = ;
Subs 0 = InitSubs
incoming 0 = InitSubs ⇥ {;}
s? 2
/ dom call
s? 2 Subs
Subs 0 = Subs
incoming 0 = incoming
Callers 0 = Callers
call 0 = call [ {s? 7! (seize 7! NULL)}
Figure 8.2: The Z specification of
the telephone exchange system corresponding to the
1
machine part in Event-B
Extended Applications to Other Formal Methods
Invariant proofs are not specific to Event-B. They exist in all the formal methods which
adopt a state-based paradigm for modelling. Examples of these formal methods are the
1
8.3. Future Work
145
9x : a • p ^ x = t
t 2 a ^ p[t/x ]
Subs 2 P DIGITSEQ ^ call 2 DIGITSEQ !
7 STATUS ⇥ DIGITSEQ ^
incoming 2 DIGITSEQ !
7 P DIGITSEQ ^ Callers 2 P DIGITSEQ ^
NULL 2 Subs ^ call 2 Subs !
7 STATUS ⇥ Subs ^
dom call ✓ Subs ^ Callers 2 P Subs ^ incoming 2 Subs ! P Subs ^
Callers = dom(call o9 st B Connected ) ^
(8 x : DIGITSEQ | x 2 dom incoming • x 2
/ incomingx ) ^
s? 2 DIGITSEQ ^ s? 2
/ dom call ^ s? 2 Subs
`
(9 Callers 0 : P DIGITSEQ; Subs 0 : P DIGITSEQ;
call 0 : P(DIGITSEQ ⇥ (STATUS ⇥ DIGITSEQ));
incoming 0 : P(DIGITSEQ ⇥ P DIGITSEQ) •
Subs 2 P DIGITSEQ ^ call 2 DIGITSEQ !
7 STATUS ⇥ DIGITSEQ ^
incoming 2 DIGITSEQ !
7 P DIGITSEQ ^
Callers 2 P DIGITSEQ ^ NULL 2 Subs ^ call 2 Subs !
7 STATUS ⇥ Subs ^
dom call ✓ Subs ^ Callers 2 P Subs ^
incoming 2 Subs ! P Subs ^ Callers = dom(call o9 st B Connected ) ^
(8 x
0 : DIGITSEQ | x
Subs 0 2 P DIGITSEQ ^
0 2 dom incoming • x
02
/ incomingx
0) ^
call 0 2 DIGITSEQ !
7 STATUS ⇥ DIGITSEQ ^
incoming 0 2 DIGITSEQ !
7 P DIGITSEQ ^ Callers 0 2 P DIGITSEQ ^ NULL 2 Subs 0 ^
call 0 2 Subs 0 !
7 STATUS ⇥ Subs 0 ^
dom call 0 ✓ Subs 0 ^
Callers 0 2 P Subs 0 ^ incoming 0 2 Subs 0 ! P Subs 0 ^
Callers 0 = dom(call 0 o9 st B Connected ) ^
(8 x 1 : DIGITSEQ | x 1 2 dom incoming 0 • x
s? 2 DIGITSEQ ^ s? 2
/ dom call ^ s? 2 Subs ^
12
/ incoming 0 x
1) ^
Subs 0 = Subs ^ incoming 0 = incoming ^ Callers 0 = Callers ^
call 0 = call [ {(s? 7! (seize 7! NULL))}
Figure 8.3: A PO from the Z specification of telephone exchange system
1
B method [2], Event-B [6], VDM [114]
and the Z notation [167]. Therefore, POPPA
is also applicable to the invariant proofs for these formal methods, if the logic of these
formal methods are formalised in Isabelle.
To illustrate, we translate parts of the case study in Figure 3.3 and 3.2 to an equivalent model in the Z notation. We show the proof obligations arising in Z are invariant
proofs. This translated model is shown in Figure 8.1 and 8.2. Figure 8.1 contains the
context part of the model in Event-B, whereas Figure 8.2 contains the machine part of
the model in Event-B. Each open box in Figure 8.2, e.g.,
146
Chapter 8. Related Work & Future Work
Subs 2 P DIGITSEQ ^ call 2 DIGITSEQ !
7 STATUS ⇥ DIGITSEQ ^
incoming 2 DIGITSEQ !
7 P DIGITSEQ ^ Callers 2 P DIGITSEQ ^
NULL 2 Subs ^ call 2 Subs !
7 STATUS ⇥ Subs ^
dom call ✓ Subs ^ Callers 2 P Subs ^ incoming 2 Subs ! P Subs ^
Callers = dom(call o9 st B Connected ) ^
(8 x : DIGITSEQ | x 2 dom incoming • x 2
/ incomingx ) ^
s? 2 DIGITSEQ ^ s? 2
/ dom call ^ s? 2 Subs
`
Subs 2 P DIGITSEQ ^ call 2 DIGITSEQ !
7 STATUS ⇥ DIGITSEQ ^
incoming 2 DIGITSEQ !
7 P DIGITSEQ ^
Callers 2 P DIGITSEQ ^ NULL 2 Subs ^ call 2 Subs !
7 STATUS ⇥ Subs ^
dom call ✓ Subs ^ Callers 2 P Subs ^ incoming 2 Subs ! P Subs ^
Callers = dom(call o9 st B Connected ) ^
(8 x
0 : DIGITSEQ | x
Subs 2 P DIGITSEQ ^
0 2 dom incoming • x
call [ {(s? 7! (seize 7! NULL))}
"
02
/ incomingx
0) ^
2 DIGITSEQ !
7 STATUS ⇥ DIGITSEQ ^
State2 DIGITSEQ !
incoming
7 P DIGITSEQ ^ Callers 2 P DIGITSEQ ^ NULL 2 Subs ^
Subs : P DIGITSEQ
"
call
: DIGITSEQ
7 NULL))}
(STATUS 2
⇥ Subs
DIGITSEQ)
call [
{(s?
7! (seize 7!!
!
7 STATUS ⇥ Subs ^
incoming : DIGITSEQ !
7 P DIGITSEQ
"
: P DIGITSEQ
dom Callers
call [ {(s?
7! (seize 7! NULL))} ✓ Subs ^
NULL
2 Subs
Callers
2 P Subs
^ incoming 2 Subs ! P Subs ^
call 2 Subs !
7 (STATUS ⇥ Subs)
"
Callers
= call
dom(
dom
✓ call
Subs[ {(s? 7! (seize 7! NULL))} o9 st B Connected ) ^
2 P Subs | x 1 2 dom incoming 0 • x 1 2
(8 x Callers
1 : DIGITSEQ
/ incoming 0 x 1) ^
incoming 2 Subs ! P Subs
s? 2 DIGITSEQ
^ s? 2
/ dom
call ^ s? 2 Subs ^
o
Callers = dom(call
9 st B Connected )
Callers
DIGITSEQ• ^
Subs
DIGITSEQ
8 x2: P
DIGITSEQ
x2
dom22
incoming
)x^
2
/ incoming(x )
call Init
[ {(s? 7! (seize 7! NULL))}
"
2 P(DIGITSEQ ⇥ (STATUS ⇥ DIGITSEQ)) ^
LiftFree
State 02 P(DIGITSEQ ⇥ P DIGITSEQ)State
incoming
s? : DIGITSEQ
call 0 = ;
0
Callers = ;
s? 2
/ dom call
Subs 0 = InitSubs
s? 2 Subs
incoming 0 = InitSubs ⇥ {;}
Subs 0 = Subs
Figure 8.4: An annotated PO from the
Z specification
0
incoming
= incomingof telephone exchange
0
Callers = Callers
call 0 = call [ {s? 7! (seize 7! NULL)}
NAME
···
system
2
···
is called a schema which contains definitions for an operation(event). In each schema,
the variable with symbol (’) represents the post state of the variable after the operations
in a schema, and the variable with symbol (?) means it is a local input variable which
is the same as parameters in Event-B.
1
8.3. Future Work
147
In Figure 8.2, the schema with name State includes the variables and invariants in
Event-B. The schema with name Init is event Initialisation of the Event-B model, and
the one with name LiftFree is event LiftFree.
A proof obligation, i.e. precondition verification, can be calculated for LiftFree. This proof obligation is shown in Figure 8.3. Note that this proof obligation
contains the invariant proofs for all invariants, although it is not in the same shape as
the ones in Event-B, such as (3.4). This proof obligation can be simplified to the shape
of invariant proofs in Event-B using the one-point-rule, i.e.,
∃x.(x ∈ a) ∧ p ∧ (x = t)
t ∈ a ∧ p[t/x]
where (p[t/x]) means substituting the occurrence of x in p with t. The one-point-rule
needs to be applied four times to the following part of this proof obligation, i.e.,
···
`
(∃Callers0 : P DIGIT SEQ; Subs0 : P DIGIT SEQ;
call 0 : P(DIGIT SEQ × (STATUS × DIGIT SEQ));
incoming0 : P(DIGIT SEQ × P DIGIT SEQ)•
···
Subs0 = Subs ∧ incoming0 = incoming ∧Callers0 = Callers∧
call 0 = call ∪ {(s? 7→ (seize 7→ NULL))}
so that the ∃ quantifier is eliminated and each variable with symbol (’) is substi-
tuted. That is, Subs0 is substituted with Subs, incoming0 is substituted with incoming,
Callers0 is substituted with Callers and call 0 is substituted with call ∪ {(s? 7→ (seize 7→
NULL))}. The subsequent proof obligation is shown in Figure 8.4. This proof obligation is now a rippling applicable problem.
Automation for Well-definedness Terms
Some preliminary processes are required for INV POs before POPPA can be applicable, when the exported Event-B INV POs contain Well-Definedness (WD) terms after
148
Chapter 8. Related Work & Future Work
they are unlifted (see §3.5.3). These WD terms in INV POs only appear in the Event-B
logic in Isabelle but not Rodin. The point of preliminary process is to eliminate these
WD terms from the goal, as the existence of WD terms may break the embedded relation between the goal and the embedded invariant. Currently the preliminary process
is made manually. Possible future work is to automate this process. To illustrate the
problem of the WD terms, consider the following INV PO
a÷b = c
`
↑
(a + e) ÷ b = (c + d)
↑
where the embedding is a ÷ b = c, and the WD term would be inserted for the welldefinedness of the ÷ operation. The unlifted version is shown as below:
b 6= 0 ∧ a ÷ b = c
`
b 6= 0 ⇒ (a + e) ÷ b = (c + d)
where b 6= 0 is a WD term. Note that the invariant does not embed in the goal now.
In this case, the embedded relation can be recovered by applying the conjunctionelimination and implication-introduction, which leads to
b 6= 0
b 6= 0 ∧ a ÷ b = c
`
(a + e) ÷ b = (c + d)
However, this process becomes less obvious when these operations, for which WD
terms need to be insert, are located inside of nested predicates. An example of such an
invariant is:
(a ÷ b = c) ⇒ (d ÷ e = f )
Improved Integration with Rodin
The current deployment of POPPA is not integrated with Rodin. Rodin users have to
first export Event-B INV POs with the Isabelle for Rodin plugin [158], followed by
some preliminary process for the WD terms, if there are any. Then users can invoke
8.3. Future Work
149
POPPA to try to prove the INV POs. This deployment is not very user-friendly. A more
user-friendly deployment will be to integrate POPPA as a plugin for Rodin, so that the
whole process could be in a ‘push-button’ style. To package POPPA available for
Rodin users, the preliminary process of WD terms has to be automated first. POPPA
could then be packaged as a plugin on top of the Isabelle for Rodin plugin.
Sending Feedback to Users
One possible future work, if a Rodin plugin has been developed for POPPA, is to provide feedback when POPPA is terminated. In addition to proof automation results,
POPPA can provide more feedback, i.e. a proof plan / proof history through IsaPlanner [64, 65]. This proof plan / proof history contains wave-steps and patching steps
that have been applied. An example of such a proof plan / proof history is given in Figure 8.5. However, the current interface of the proof plan / proof history is presented in
pure text and is not very readable, as it was designed for experienced theorem proving
users. A better interface might be also needed in the future to make it more accessible
for novice users. Some potential useful features for the new interface could be to allow
users to walk through each proof step, and to hide and show irrelevant proof information. Rodin users can then understand what the current progress is, e.g. fertilised and
fully automated, and what have been done to achieve the progress. When proof automation is not successful, getting understanding of the progress can be, in particular,
helpful to identify why automation fails and prove the PO manually.
Another potential useful feedback is the lemmas generated by ahLemma. These
lemmas sometimes reveal some interesting properties of the Event-B model, where the
properties are the conditions of the generated lemma. Rodin users can generalise the
properties from the lemmas as theorems in the model, and then insert the theorems into
the model to benefit the proofs for other POs in the same model. Also, this process can
be developed as a reasoned modelling (see §2.3.3) to suggest additional theorems.
Invariant Generation as a Proof Patch
Part of our work focuses on recovering failed INV POs. However, failed INV POs are
not always provable due to an incomplete or incorrect model. This, in particular, happens in an early modelling stage of system development. For these unprovable INV
POs, we do not want to recover the proofs. Instead, we should try to revise the model
150
Chapter 8. Related Work & Future Work
Figure 8.5: An example of proof plan / proof history from POPPA
with the assistance of these failed proofs. A technique, called reasoned modelling critics [105], works in this approach to provide modelling suggestions for revising.
We notice that an unprovable INV PO can be caused by an incomplete but still
correct model. A possible patch is to insert a new invariant to the model by analysing
the unprovable INV PO1 . To illustrate this scenario, consider the following model:
Machine m1
Variables S,P,Q
Invariants typeinv: {S, P, Q} ⊆ B
inv1: Q ⇒ P
Events
INITIALISATION , begin S,P,Q := false,false,false end
1 This
idea and example were proposed by Gudmund Grov in BlueBook note 1755.
8.4. Summary
151
Event e1 , begin S,P = true,true end
Event e2 , when S then Q := true end
Event e3 , begin S,P,Q := false,false,false end
End
where the INV PO for invariant inv1 and event e2 is not provable, i.e.,
Q ⇒ P, S ` true ⇒ P
Note that notation (⇒) used here is the implication at object-logic level in Event-B. It
is shorter than the meta-level implication ( =⇒ ) used in Isabelle. The problem of this
unprovable conjecture is a lack of the specifications / statement between S and P. That
is,
S⇒P
(8.1)
Although this statement is missing in the definitions of invariants, the model does not
violate this statement. This is because the missing statement is implicitly defined by
the events of the model: it is never the case that S is true and P is f alse, as S and P
are always changed to true or f alse at the same time according to events e1 and e3.
Therefore, the model is still correct but incomplete, although the invariant proof fails.
A patch for this scenario is to insert statement (8.1) as an invariant to this model so
that the model is completed and the INV PO for invariant inv1 and event e2 is then
provable, i.e.,
Q ⇒ P, S ⇒ P, S ` true ⇒ P
This INV PO now can be easily discharged automatically. For the lemma conjecturing
patch of POPPA, which is ahLemma, it is also possible that ahLemma fails to prove
and disprove a conjecture and this failure is caused by the correct but still incomplete
model. Therefore, we can also suggest to developers to insert the conjecture which
ahLemma fails to prove and disprove.
8.4
Summary
In this chapter, we have discussed the related work in the field of theory exploration
systems for lemma discovery. Also we have summarised the limitations and possible
152
Chapter 8. Related Work & Future Work
future work from various aspects. We first discussed the future work in improving
the efficiency and effectiveness of ahLemma by improving the applicabilities of the
counter-example checkers and the proving capabilities of the proof method for the
ahLemma conjectures. We showed possible future work in the use of POPPA in the
INV POs generated from non-deterministic events, as well as the general applicability
and extensibility of POPPA to the INV POs in other formal specification languages. We
then discussed the future work from the usability point of view, which includes work
of the automation on the preliminary process of the WD terms and the integration of
POPPA as a Rodin plugin.
Chapter 9
Conclusions
9.1
Introduction
In §9.2, we revisit the hypothesis introduced in the chapter 1. We then conclude the
contributions of this thesis in §9.3. A summary is given in §9.4.
9.2
Revisiting Our Hypothesis
The hypothesis of this thesis is
Combining rippling with proof-patching mechanism, in particular, using
the scheme-based lemma conjecturing proof patch, can contribute to a
significant improvement of proof automation for the INV POs in the EventB domain.
This hypothesis can be analysed by the following two statements from two different
aspects:
1. The applicability aspect: both rippling and and its proof-patching mechanism
are applicable to the majority of the Event-B INV POs which need human interaction.
2. The effectiveness aspect: both rippling and its proof-patching mechanism are
effective in improving the proof automation of Event-B INV POs.
Applicability Analysis
For the reason that the proof-patching mechanism is always applicable as long as rippling is applicable and then becomes blocked, the central claim of statement (1) is
whether we can apply the majority of the INV PO that currently require interactive
153
154
Chapter 9. Conclusions
proofs. In §4.2 we argued that INV POs can be considered as inductive proofs over
all traces of Event-B models. Also rippling was originally developed for the step cases
of inductive proofs. Hence, rippling is applicable to parts of the INV POs which are
step cases. Moreover, step cases are usually more complex than base cases in inductive
proofs. Therefore, statement (1) is supported. Furthermore we have shown the applicability of rippling to those INV POs in §4.2.
Effectiveness Analysis
To analyse from the effectiveness aspect, we first give supports from the overall improvement which the combining rippling and its proof-patching mechanism bring. We
then give further assessment measured in term of the purpose of the use of rippling and
the patching mechanism, respectively.
In chapter 4 and 5, we presented our proof technique, i.e. POPPA, which comprises
rippling and the three proof patches that we developed. The evaluation presented in
chapter 7 showed that POPPA simplified 70% the INV POs which previously needed
human interaction, and fully proved 77% of these. This result provides evidences to
support statement (2).
Arguably, effectiveness can also be analysed in terms of the purpose of use. The
purpose of rippling in the INV POs is to provide guidance as a proof plan; the purpose
of the use of the proof patches is to recover blocked rippling and lead to the success
of rippling. In §7.3.1, we analysed the evaluation results to show that the major proportion of INV POs, i.e. 77%, had been proved when the rippling guidance succeeded
so that fertilisation can be applied to simplify the goals. In §7.3.2 we analysed the
evaluation results to show that 70% of INV POs were unblocked and succeeded to be
fertilised using all three proof patches. Moreover, we showed that disabling any of
these proof patches would result in a drop of the numbers of fertilised INV POs. These
two results validate the statement (2).
9.3
Concluding Contributions
In chapter 1, we gave a summary of the contributions of this thesis. Here we restate
those contributions with more explanation.
Applying Rippling to INV POs
9.4. Summary
155
In §4.2 we argued that INV POs can be considered as inductive proofs over all traces of
Event-B models and rippling is applicable to parts of the INV POs which are step cases.
The key strategy of such proofs is to rewrite the goal towards the hypothesis which is
embedded in the goal, until the embedded hypothesis becomes applicable to simplify
the goal. Rippling abstracts this strategy as meta-level guidance. We presented the
application of rippling to INV POs in §4.2. We also showed the effectiveness of such
guidance of rippling in §7.3.1.
Developing a Proof Patch using Theory Exploration tools
We presented a scheme-based, lemma conjecturing proof patch, i.e. ahLemma, to
recover failed proof attempts in chapter 5. ahLemma adopts a scheme-based theory
exploration system, i.e. IsaScheme, to discover missing lemmas. To our knowledge,
this is the first time to adopt a theory exploration system to discover lemmas in a proofpatching approach for rippling. Moreover, in §7.4, the evaluation results showed that
around 65% of the fertilised INV POs have produced similar lemmas to the ones inserted interactively in the Rodin proofs.
Effective Proof Patches in the Event-B domain
We developed three proof patches to recover rippling to for INV POs in Event-B. In
§7.3.2, we analysed the evaluation results to show that each proof patch is effective
and necessary to lead to the success of rippling.
9.4
Summary
We applied a proof planning technique, called rippling, as meta-level guidance, to
guide the proofs of Event-B INV POs. Also, by exploring the properties of rippling to
analyse failures, we developed three proof patches to discover missing lemmas, suggest case splits and simplify INV POs by suggesting new embeddings. For the lemma
discovery proof patch, we combined a scheme-based, theory exploration system with
heuristics to conjecture lemmas to unblock proof attempts. This is the first time where
a theory exploration system is used to discover lemmas in a proof-patching approach
for rippling. We have developed a proof technique, called POPPA, by combining rippling with these three proof patches. POPPA was built on top of Isabelle, IsaPlanner
and IsaScheme.
156
Chapter 9. Conclusions
We evaluated POPPA using a set of Event-B INV POs as an evaluation set from
various case studies developed by different developers. All of these INV POs require
human interaction in Rodin, and none of them can be proved, so far, by any Isabelle
automatic proof methods. POPPA managed to ripple 70% of these Event-B INV POs,
and 77% of those fertilised POs have been automatically proved. Initially, all the
INV POs in the evaluation set were blocked if only rippling is used. With the use
of the three proof-patching techniques in POPPA, 70% of INV POs were unblocked
and succeeded to be fertilised. We also compared the lemmas, which are produced
by the lemma discovery proof patch for the fertilised INV POs, with the ones inserted
interactively in the proofs using Rodin. Results showed that around 65% of them are
similar to the interactively provided lemmas.
Appendix A
Mathematical Notations
A.1
Event-B Notations
Notation
Definition
Notation in Isabelle
P∧Q
object-logic conjunction
P⇒Q
object-logic implication
P∨Q
¬P
∅
{x}
{x.P|F}
object-logic disjunction
P∧Q
P∨Q
P→Q
¬P
negation
{}
empty set
a singleton set
the set of all values of F for all values of x that satisfy the predicate P.
{x}
{x.P ∧ F}
P must constrain the variables in x.
S∪T
union operation
S\T
union operation
S∩T
intersection operation
x 7→ y
ordered pair
P(S)
power set
S∪T
S∩T
S−T
(x, y)
M×N
Cartesian product
card(S)
cardinality of the set S
M×N
Pow S
partition(S, x1 · · · xn ) x1 · · · xn partition the set S, and the
card S
n/a
intersection of any two of x1 · · · xn
are empty set
x∈S
set membership
157
x∈S
158
Appendix A. Mathematical Notations
x∈
/S
non-set membership
S 6⊆ T
not a subset
S 6⊂ T
noe a proper subset
S↔T
P(S × T )
ran(r)
{y|∃x.x 7→ y ∈ r}
S⊆T
subset
S⊆T
proper subset
m .. n
{i|m ≤ i ∧ i ≤ n}
dom(r)
rCs
rC
−s
rBs
rB
−s
r;s
rC
−s
r∼
r[s]
M→
7 N
f (x)
A.2
x∈
/S
S⊆T
S 6⊆ T
S⊂T
S 6⊂ T
{m .. n}
rel S T
{x|∃y.x 7→ y ∈ r}
Dommain r
Range r
{x 7→ y|x 7→ y ∈ r ∧ x ∈ s}
rCs
{x 7→ y|x 7→ y ∈ r ∧ x ∈
/ s}
rC ∼s
{x 7→ y|x 7→ y ∈ r ∧ y ∈
/ s}
r∼ Bs
{x 7→ y|x 7→ y ∈ r ∧ y ∈ s}
{x 7→ y|∃z.x 7→ z ∈ r ∧ z 7→ y ∈ s}
s ∪ (dom(s) C
− r)
{x 7→ y|y 7→ x ∈ r}
rBs
r O s
r <+ s
converse r
{y|∃x.x ∈ s ∧ x 7→ y ∈ r}
{ f | f ∈ M ↔ Nland(∀x, y, z.(x 7→
y ∈ f ∧ x 7→ z ∈ f ) ⇒ (y = z))}
x 7→ f (s) ∈ f
f ‘‘ s
pfun M N
f ’x
Isabelle Notations:
Description
Notation
meta-logic implication ⇒
datatype list
datatype 0 α list
Singleton list
[x]
Append two lists
@
Definition
n/a
[] | 0 α # 0 α list
x # []
[] @ ys = ys |
(x # xs) @ ys = x # (xs @ ys)
Reverse a list
rev
rev[] = [] |
rev(x # xs) = rev(xs) @ [x]
Quick list reversion
qrev
qrev([], ys) = ys |
qrev(x # xs, ys) = qrev(xs, x # ys)
Appendix B
A Lattice for the Relations-based
Datatype Constructors
$
Relations
$
!
7
Total Relations
Partial Functions
⇢
7
!
Partial Injections
Total Functions
$
!
Surjective Relations
⇣
7
Partial Surjections
⇢
$
$
Total Surjective Relations
⇣
Total Surjections
Total Injections
⇢
⇣
Bijections
!
7
$
$
$
Partial Functions(
) : Relations(
) + Functional
Total Relations( $): Relations(
)+ Total
!): Relations( ) + Surjective
Surjective Relations($
$): Relations( ) + Total + Surjective
Total Surjective Relations($
Total Functions(!): Relations(
) + Functional + Total
7 ): Relations( ) + Functional + Injective
Partial Injections(⇢
7 ): Relations( ) + Functional + Surjective
Partial Surjections(⇣
Total Injections(⇢): Relations(
) + Functional + Total + Injective
Total Surjections(⇣): Relations(
) + Functional + Total + Surjective
Bijections(
): Relations(
) + Functional + Total + Injective + Surjective
⇢
⇣
$
$
$
$
$
$
159
$
Appendix C
Default Wave-rules in RippleINV
SIMP FORALL AND (∀x.P ∧ Q) = ((∀x.P) ∧ (∀x.Q))
SIMP EXISTS OR (∃x.P ∨ Q) = (∃x.P) ∨ (∃x.Q)
SIMP EXISTS IMP (∃x.P → Q) = ((∀x.P) → (∃x.Q))
SIMP finite BUNION finite(S ∪ R) = (finite S ∧ finite R)
SIMP finite UNION finite( S) = (finite S ∧ (∀x.(x ∈ S → finite x)))
S
SIMP finite POW finite(Pow S) = finite S
DERIV finite CPROD finite(S × R) = ((S = {}) ∨ (R = {}) ∨ (finite(S) ∧ finite R))
SIMP finite CONVERSE finite(converse S) = finite S
DISTRI AND OR (P ∧ (Q ∨ R)) = ((P ∧ Q) ∨ (P ∧ R))
DISTRI OR AND (P ∨ (Q ∧ R)) = ((P ∨ Q) ∧ (P ∨ R))
DERIV IMP IMP (P → (Q → R)) = ((P ∧ Q) → R)
DISTRI IMP AND (P → (Q ∧ R)) = ((P → Q) ∧ (P → R))
DISTRI IMP OR ((P ∨ Q) → R) = ((P → R) ∧ (Q → R))
DISTRI NOT AND (¬(P ∧ Q)) = (¬P ∨ ¬Q)
DISTRI NOT OR (¬(P ∨ Q)) = (¬P ∧ ¬Q)
DERIV NOT IMP (¬(P → Q)) = (P ∧ ¬Q)
161
162
Appendix C. Default Wave-rules in RippleINV
DEF IN BUNION x ∈ S ∪ R = (x ∈ S ∨ x ∈ R)
DEF IN BINTER x ∈ S ∩ R = (x ∈ S ∧ x ∈ R)
DEF IN SETMINUS x ∈ S − R = (x ∈ S ∧ x ∈
/ R)
DISTRI BUNION BINTER (S ∪ (Q ∩ R)) = ((S ∪ Q) ∩ (S ∪ R))
DISTRI BINTER BUNION (S ∩ (Q ∪ R)) = ((S ∩ Q) ∪ (S ∩ R))
DISTRI BINTER SETMINUS (S ∩ (Q − R)) = ((S ∩ Q) − (S ∩ R))
DISTRI SETMINUS BUNION (S − (Q ∪ R)) = ((S − Q) − R)
DERIV TYPE SETMINUS BINTER (S − (Q ∩ R)) = ((S − Q) ∪ (S − R))
DERIV TYPE SETMINUS BUNION (S − (Q ∪ R)) = ((S − Q) ∩ (S − R))
DERIV TYPE SETMINUS SETMINUS (UNIV − (Q − R)) = ((UNIV − Q) ∪ R)
DISTRI CPROD BINTER (S × (Q ∪ U)) = ((S × Q) ∪ (S ×U))
DISTRI CPROD BUNION (S × (Q ∩ U)) = ((S × Q) ∩ (S ×U))
DISTRI CPROD SETMINUS (S × (Q −U)) = ((S × Q) − (S ×U))
DERIV SUBSETEQ SETMINUS R (S ⊆ A − B) = (S ⊆ A ∧ (S ∩ B = {}))
SIMP MULTI DOMRES DOM Domain (r) C r = r
DERIV RELIMAGE RANSUB ((r ∼ BS) ‘‘ R) = (r ‘‘ R − S)
DERIV RELIMAGE RANRES ((r B S) ‘‘ R) = ((r ‘‘ R) ∩ S)
DERIV FCOMP DOMRES ((S C p) O q) = (S C (p O q))
DERIV FCOMP DOMSUB ((SC ∼ p) O q) = (SC ∼ (p O q))
DERIV FCOMP RANRES (p O (q B S)) = ((p O q) B S)
DERIV FCOMP RANSUB (p O (q ∼ BS)) = ((p O q) ∼ BS)
DERIV FCOMP SING ((x, y) O (y, z)) = (x, z)
SIMP MULTI DOM DOMRES (Domain (A C f )) = ((Domain f ) ∩ A)
163
SIMP MULTI DOM DOMSUB Domain (AC ∼ f ) = (Domain f − A)
SIMP MULTI RAN RANRES Range( f B A) = (Range f ∩ A)
SIMP MULTI RAN RANSUB (Range( f ∼ BA)) = (Range f − A)
DISTRI FCOMP BUNION R (p O (q ∪ r)) = ((p O q) ∪ (p O r))
DISTRI FCOMP BUNION L (q ∪ r) O p = (q O p) ∪ (r O p)
DISTRI DPROD BUNION r >< (s ∪ t) = (r >< s) ∪ (r >< t)
DISTRI DPROD BINTER r >< (s ∩ t) = (r >< s) ∩ (r >< t)
DISTRI DPROD SETMINUS r >< (s − t) = (r >< s) − (r >< t)
DISTRI DPROD OVERL (r >< (s <+ t)) = ((r >< s) <+ (r >< t))
DISTRI PPROD BUNION (pprod r(s ∪ t)) = ((pprod rs) ∪ (pprod rt))
DISTRI PPROD BINTER pprod r(s ∩ t) = (pprod rs) ∩ (pprod rt)
DISTRI PPROD SETMINUS pprod r(s − t) = (pprod rs) − (pprod rt)
DISTRI PPROD OVERL pprod r(s <+ t) = (pprod rs) <+ (pprod rt)
DISTRI OVERL BUNION L (p ∪ q) <+ r = (p <+ r) ∪ (q <+ r)
DISTRI OVERL BINTER L (p ∩ q) <+ r = (p <+ r) ∩ (q <+ r)
DISTRI DOMRES BUNION R s C (p ∪ q) = (s C p) ∪ (s C q)
DISTRI DOMRES BUNION L (s ∪ t) C r = (s C r) ∪ (t C r)
DISTRI DOMRES BINTER R s C (p ∩ q) = (s C p) ∩ (s C q)
DISTRI DOMRES BINTER L (s ∩ t) C r = (s C r) ∩ (t C r)
DISTRI DOMRES SETMINUS R s C (p − q) = (s C p) − (s C q)
DISTRI DOMRES SETMINUS L (s − t) C r = (s C r) − (t C r)
DISTRI DOMRES DPROD s C (p >< q) = (s C p) >< (s C q)
DISTRI DOMRES OVERL s C (r <+ q) = (s C r) <+ (s C q)
164
Appendix C. Default Wave-rules in RippleINV
DISTRI DOMSUB BUNION R sC ∼ (p ∪ q) = (sC ∼ p) ∪ (sC ∼ q)
DISTRI DOMSUB BUNION L (s ∪ t)C ∼ r = (sC ∼ r) ∩ (tC ∼ r)
DISTRI DOMSUB BINTER R sC ∼ (p ∩ q) = (sC ∼ p) ∩ (sC ∼ q)
DISTRI DOMSUB BINTER L (s ∩ t)C ∼ r = (sC ∼ r) ∪ (tC ∼ r)
DISTRI DOMSUB DPROD AC ∼ (r >< s) = (AC ∼ r) >< (AC ∼ s)
DISTRI DOMSUB OVERL AC ∼ (r <+ s) = (AC ∼ r) <+ (AC ∼ s)
DISTRI RANRES BUNION R r B (s ∪ t) = (r B s) ∪ (r B t)
DISTRI RANRES BUNION L (p ∪ q) B s = (p B s) ∪ (q B s)
DISTRI RANRES BINTER R r B (s ∩ t) = (r B s) ∩ (r B t)
DISTRI RANRES BINTER L (p ∩ q) B s = (p B s) ∩ (q B s)
DISTRI RANRES SETMINUS R r B (s − t) = (r B s) − (r B t)
DISTRI RANRES SETMINUS L (p − q) B s = (p B s) − (q B s)
DISTRI RANSUB BUNION R r ∼ B(s ∪ t) = (r ∼ Bs) ∩ (r ∼ Bt)
DISTRI RANSUB BUNION L (p ∪ q) ∼ Bs = (p ∼ Bs) ∪ (q ∼ Bs)
DISTRI RANSUB BINTER R r ∼ B(s ∩ t) = (r ∼ Bs) ∪ (r ∼ Bt)
DISTRI RANSUB BINTER L (p ∩ q) ∼ Bs = (p ∼ Bs) ∩ (q ∼ Bs)
DISTRI CONVERSE BUNION converse (p ∪ q) = converse p ∪ converse q
DISTRI CONVERSE BINTER converse (p ∩ q) = converse p ∩ converse q
DISTRI CONVERSE SETMINUS converse (r − s) = converse r − converse s
DISTRI CONVERSE FCOMP converse (p O q) = (converse q O converse p)
DISTRI CONVERSE PPROD converse (pprod r s) = pprod (converse r) (converse s)
DISTRI CONVERSE DOMRES converse (s C r) = (converse r) B s
DISTRI CONVERSE DOMSUB converse (sC ∼ r) = (converse r) ∼ Bs
165
DISTRI CONVERSE RANRES converse (r B s) = s C (converse r)
DISTRI CONVERSE RANSUB converse (r ∼ Bs) = sC ∼ (converse r)
DISTRI DOM BUNION Domain (r ∪ s) = Domain (r) ∪ Domain (s)
DISTRI RAN BUNION Range(r ∪ s) = Range(r) ∪ Range(s)
DISTRI RELIMAGE BUNION R r ‘‘ (S ∪ R) = r ‘‘ S ∪ r ‘‘ R
DISTRI RELIMAGE BUNION L (p ∪ q) ‘‘ S = (p ‘‘ S) ∪ (q ‘‘ S)
Appendix D
Glossary
ae An interactive proving command in Rodin to replace a sub-term with a fresh variable.
ah An interactive proving command in Rodin to insert a new lemma.
ahLemma Proof Patch A scheme-based lemma conjecturing proof patch for Event-B
INV POs.
AM Automated Mathematician.
axe/axe´ An automatic proof method in Isabelle provided by the Isabelle for Rodin
plugin.
Case Split Proof Patch A proof patch to suggest case split for Event-B INV POs.
Complementary Pair A pair of conditional rewrite rule whose conditions are complementary.
Context A component of an Event-B model containing the static information.
CS The case split proof patch.
CSP Communicating Sequential Processes.
dc An interactive proving command in Rodin to apply a case split.
DEPLOY Project A project to make major advances in engineering methods for dependable systems through the deployment of formal engineering methods.
Embedding Hypothesis The hypothesis which is embedded in the goal.
167
168
Appendix D. Glossary
Fertilisation The step of applying the induction hypothesis to simplify the induction
conclusion.
Formal Methods Rigorous mathematical techniques for specifications, designs and
verifications of software and hardware system development.
IDE An integrated development environment.
IFP An Event-B case study: information flow policies for dynamic virtual organisations.
INV PO Invariant preservation proof obligations: a type of proof obligations generated to ensure the invariant holds when the states of the systems are changed.
Isabelle for Rodin A plugin for Rodin to export proof obligations to Isabelle.
Isabelle A LCF style theorem prover.
IsaPlanner A prove planner built on top of Isabelle.
IsaScheme A scheme-based theory exploration system built on top of Isabelle.
LC The ahLemma proof patch.
LCF Logic for Computable Functions.
LHS Left-hand side of an equation based formula.
Machine A component of Event-B model containing the dynamic information.
ML Meta Language: a type-safe functional programming language.
Nitpick A counter-example checker.
PO Proof Obligations: mathematical formulas to be proven for the purpose of reasoning about the target systems.
Poly/ML A full implementation of ML.
POPPA Proof Obligation Proofs Patched Automatically: the proof technique which
we develop in this thesis.
Proof-patching Recover failed proofs based on the meta-level guidance from rippling.
169
Quickcheck A counter-example checker.
Relations-based Datatype Constructors A family of datatype constructors in EventB which are defined based on the relations datatype constructor (↔).
RHS Right-hand side of an equation based formula.
Rippling-inwards A rippling direction which moves wave-fronts down towards the
leaf nodes of the term tree.
Rippling-outwards A rippling direction which moves wave-fronts up towards the
root node of the term tree.
Rippling an automatic reasoning technique which contain meta-level guidance to automate proofs.
Rodin an extensible integrated development tool for both modelling and proving in
Event-B.
RState Reasoning states: the proof state representation in IsaPlanner.
RTechn Reasoning techniques: a function from a reasoning state to another reasoning
state.
Scheme A formula containing higher-order variables
Seeding Pool A set of terms which IsaScheme uses to instantiate the meta-variables
of schemes.
Skeleton Rewrite Proof Patch A proof patch to suggest a new embedding for EventB INV POs.
Skeleton The part in the induction conclusion where the induction hypothesis is embedded. The skeleton is required to be persevered during rippling.
SR The Skeleton Rewrite proof patch.
SRT The Smart Response Technology (SRT) algorithm in Pentium FDIV
Strong Fertilisation The step of applying the induction hypothesis directly to the induction conclusion when the conclusion matches the hypothesis exactly.
170
Appendix D. Glossary
Theory Formation a technique to perform concept invention and conjecture discovery.
Wave Step A step of applying a rewrite rule to the goal in rippling.
Wave-front The differences to be removed between the induction hypothesis and the
induction conclusion.
Wave-hole The parts of the skeleton in a wave-front.
Wave-rule The rewrite rules in Rippling.
WD Well Definedness.
Weak Fertilisation The step of using the equational induction hypothesis to simplify
the equational induction conclusion when one side of the conclusion is rippled.
Bibliography
[1] A. Smaill and I. Green. Higher order annotated terms for proof search. In
J. Von Wright, J. Grundy, and J. Harrison, editors, Ninth international Conference on Theorem Proving in Higher Order Logics TPHOL, volume 1125 of
Lecture Notes in Computer Science, pages 399–414, Turku, Finland, Aug. 1996.
Springer Verlag.
[2] J.-R. Abrial. The B Book: Assigning Programs to Meanings. Cambridge University Press, Aug. 1996.
[3] J.-R. Abrial. Formal methods in industry: achievements, problems, future.
In Proceedings of the 28th international conference on Software engineering,
pages 761–768. ACM, 2006.
[4] J.-R. Abrial. Formal methods: Theory becoming practice. J. UCS, 13(5):619–
628, 2007.
[5] J.-R. Abrial. A system development process with Event-B and the Rodin platform. In Formal Methods and Software Engineering, pages 1–3. Springer, 2007.
[6] J.-R. Abrial. Modeling in Event-B - System and Software Engineering. Cambridge University Press, 2010.
[7] J.-R. Abrial, M. J. Butler, S. Hallerstede, T. S. Hoang, F. Mehta, and L. Voisin.
Rodin: an open toolset for modelling and reasoning in Event-B.
STTT,
12(6):447–466, 2010.
[8] A. Armando, A. Smaill, and I. Green.
Automatic synthesis of recursive
programs: The proof-planning paradigm. Automated Software Engineering,
6(4):329–356, 1999.
171
172
Bibliography
[9] C. Ballarin. Tutorial to locales and locale interpretation. In Contribuciones
cientı́ficas en honor de Mirian Andrés Gómez, pages 123–140. Universidad de
La Rioja, 2010.
[10] M. Balser, W. Reif, G. Schellhorn, K. Stenzel, and A. Thums. Formal system
development with KIV. In T. Maibaum, editor, Fundamental Approaches to
Software Engineering, volume 1783 of LNCS. Springer-Verlag, 2000.
[11] J. Barnes. High Integrity Software: The SPARK Approach to Safety and Security.
Addison Wesley, New York, NY, 2003.
[12] M. Barnett, M. Fähndrich, K. R. M. Leino, P. Müller, W. Schulte, and H. Venter.
Specification and verification: the spec# experience. Commun. ACM, 54(6):81–
91, 2011.
[13] M. Barr. Transcript of morning trial proceedings. http://www.sddt.com/
files/Bookout_v_Toyota_Barr_REDACTED_002.pdf. Accessed: 2014-0722.
[14] D. A. Basin and T. Walsh. A calculus for and termination of rippling. Journal
of Automated Reasoning, 16(1–2):147–180, Mar. 1996.
[15] P. Behm, P. Benoit, A. Faivre, and J.-M. Meynadier. Meteor: A successful
application of B in a large project. In FM99Formal Methods, pages 369–387.
Springer, 1999.
[16] M. Ben-Ari. Ada for Software Engineers - Second Edition with Ada 2005.
Springer, 2009.
[17] J. Bengtsson, W. D. Griffioen, K. J. Kristoffersen, K. G. Larsen, F. Larsson,
P. Pettersson, and W. Yi. Verification of an audio protocol with bus collision
using UppAal. In Computer Aided Verification, pages 244–256. Springer, 1996.
[18] C. Benzmüller, L. Cheikhrouhou, D. Fehrer, A. Fiedler, X. Huang, M. Kerber,
M. Kohlhase, K. Konrad, A. Meier, E. Melis, W. Schaarschmidt, J. H. Siekmann,
and V. Sorge. Omega: Towards a mathematical assistant. In W. McCune, editor,
CADE, volume 1249 of Lecture Notes in Computer Science, pages 252–255.
Springer, 1997.
Bibliography
173
[19] S. Berghofer and T. Nipkow. Random testing in Isabelle/HOL. In SEFM, volume 4, pages 230–239, 2004.
[20] A. Biere, A. Cimatti, E. Clarke, and Y. Zhu. Symbolic model checking without
BDDs. Springer, 1999.
[21] B. Blanchet, P. Cousot, R. Cousot, J. Feret, L. Mauborgne, A. Miné, D. Monniaux, and X. Rival. Design and implementation of a special-purpose static
program analyzer for safety-critical real-time embedded software, invited chapter. In T. Mogensen, D. Schmidt, and I. Sudborough, editors, The Essence of
Computation: Complexity, Analysis, Transformation. Essays Dedicated to Neil
D. Jones, LNCS 2566, pages 85–108. Springer-Verlag, Oct. 2002.
[22] J. C. Blanchette and T. Nipkow. Nitpick: A counterexample generator for
higher-order logic based on a relational model finder. In Interactive Theorem
Proving, pages 131–146. Springer, 2010.
[23] A. Bouhoula and M. Rusinowitch. Spike-user manual. INRIA, Dec, 1995.
[24] R. Boulton, K. Slind, A. Bundy, and M. Gordon. An interface between CLAM
and HOL. In Theorem Proving in Higher Order Logics, pages 87–104. Springer,
1998.
[25] J. Bryans. Developing a consensus algorithm using stepwise refinement. In
S. Qin and Z. Qiu, editors, Formal Methods and Software Engineering, volume
6991 of Lecture Notes in Computer Science, pages 553–568. Springer Berlin
Heidelberg, 2011.
[26] J. W. Bryans, J. S. Fitzgerald, and T. McCutcheon. Refinement-based techniques in the analysis of information flow policies for dynamic virtual organisations. In Adaptation and Value Creating Collaborative Networks, pages 314–
321. Springer, 2011.
[27] B. Buchberger and A. Craciun. Algorithm synthesis by lazy thinking: Using
problem schemes. In Proceedings of SYNASC, pages 90–106, 2004.
[28] A. Bundy. The use of explicit plans to guide inductive proofs. In Conf. on
Automated Deduction (CADE 9), 1987.
174
Bibliography
[29] A. Bundy. A science of reasoning. In Computational Logic - Essays in Honor
of Alan Robinson, pages 178–198, 1991.
[30] A. Bundy, D. Basin, D. Hutter, and A. Ireland. Rippling: Meta-Level Guidance
for Mathematical Reasoning, volume 56 of Cambridge Tracts in Theoretical
Computer Science. Cambridge University Press, June 2005.
[31] A. Bundy, G. Grov, and Y. Lin. Productive use of failure in top-down formal
methods. In Automated Reasoning Workshop 2011, page 13, 2011.
[32] A. Bundy, F. V. Harmelen, J. Hesketh, and A. Smaill. Experiments with proof
plans for induction. Journal of Automated Reasoning, 7(3):303–324, Sept. 1991.
[33] A. Bundy, F. van Harmelen, C. Horn, and A. Smaill. The Oyster-Clam system.
In M. E. Stickel, editor, 10th International Conference on Automated Deduction,
LNAI 449, pages 647–648, Kaiserslautern, FRG, July 24–27, 1990. SpringerVerlag.
[34] A. Bundy and B. Welham. Using meta-level inference for selective application
of multiple rewrite rule sets in algebraic manipulation. Artificial Intelligence,
16:189–211, 1981.
[35] J. R. Burch, E. M. Clark, K. L. McMillan, D. L. Dill, and L. J. Hwang. Symbolic
model checking: 1020 states and beyond. In J. C. Mitchell, editor, Proceedings
of the 5th Annual IEEE Symposium on Logic in Computer Science, pages 428–
439, Philadelphia, PA, June 1990. IEEE Computer Society Press.
[36] M. Butler and S. Hallerstede. The Rodin formal modelling tool. In BCS-FACS
Christmas 2007 Meeting-Formal Methods In Industry, London., 2007.
[37] M. Butler and I. Maamria. Mathematical extension in Event-B through the
Rodin theory component. 2010.
[38] M. Butler and D. Yadav. An incremental development of the Mondex system in
Event-B. Formal Aspects of Computing, 20(1):61–77, 2008.
[39] R. W. Butler. What is formal methods ? http://shemesh.larc.nasa.gov/
fm/fm-what.html. Accessed: 2014-07-02.
[40] R. W. Butler. Why is formal methods necessary ? http://shemesh.larc.
nasa.gov/fm/fm-why-new.html. Accessed: 2014-07-02.
Bibliography
175
[41] F. J. Cantu, A. Bundy, A. Smaill, and D. Basin. Experiments in automating
hardware verification using inductive proof planning. In Formal Methods in
Computer-Aided Design, pages 94–108. Springer, 1996.
[42] N. Cataño, T. Wahls, C. Rueda, V. Rivera, and D. Yu. Translating B machines
to JML specifications. In S. Ossowski and P. Lecca, editors, SAC, pages 1271–
1277. ACM, 2012.
[43] P. Chalin, J. R. Kiniry, G. T. Leavens, and E. Poll. Beyond assertions: Advanced
specification and verification with JML and ESC/Java2. In Formal Methods
for Components and Objects (FMCO) 2005, Revised Lectures, volume 4111
of Lecture Notes in Computer Science, pages 342–363, Berlin, 2006. SpringerVerlag.
[44] J. A. Chaves. Formal methods at AT&T - an industrial usage report. In Proceedings of the IFIP TC6/WG6. 1 Fourth International Conference on Formal
Description Techniques for Distributed Systems and Communication Protocols:
Formal Description Techniques, IV, pages 83–90. North-Holland Publishing
Co., 1991.
[45] K. Claessen and J. Hughes. Quickcheck: a lightweight tool for random testing
of Haskell programs. Acm sigplan notices, 46(4):53–64, 2011.
[46] K. Claessen, M. Johansson, D. Rosén, and N. Smallbone. Hipspec: Automating
inductive proofs of program properties. In ATx/WInG@ IJCAR, pages 16–25.
Citeseer, 2012.
[47] E. M. Clarke and E. A. Emerson. Design and synthesis of synchronization skeletons using branching-time temporal logic. In D. Kozen, editor, Proceedings of
the Workshop on Logic of Programs, Yorktown Heights, volume 131 of Lecture
Notes in Computer Science, pages 52–71. Springer-Verlag, 1981.
[48] E. M. Clarke and R. Kurshan. Computer-aided verification. Spectrum, IEEE,
33(6):61–67, 1996.
[49] W. F. Clocksin and C. S. Mellish. Programming in Prolog (2Nd Ed.). SpringerVerlag New York, Inc., New York, NY, USA, 1984.
[50] E. Cohen, M. Dahlweid, M. Hillebrand, D. Leinenbach, M. Moskal, T. Santen,
W. Schulte, and S. Tobies. VCC: A practical system for verifying concurrent C.
176
Bibliography
In S. Berghofer, T. Nipkow, C. Urban, and M. Wenzel, editors, Theorem Proving
in Higher Order Logics, 22nd International Conference, TPHOLs 2009, volume
5674 of Lecture Notes in Computer Science, pages 23–42, Berlin, Aug. 2009.
Springer-Verlag.
[51] J. Coleman, C. Jones, I. Oliver, A. Romanovsky, and E. Troubitsyna. RODIN
(rigorous open development environment for complex systems). University of
Newcastle upon Tyne, Computing Science, 2005.
[52] S. Colton. Automated Theory Formation in Pure Mathematics. Springer Verlag,
2002.
[53] R. L. Constable, S. F. Allen, W. R. Cleveland, J. F. Cremer, R. W. Harper, D. J.
Howe, T. B. Knoblock, N. P. Mendler, P. Panangaden, J. T. Sasaki, and S. F.
Smith. Implementing Mathematics with The Nuprl Proof Development System.
Prentice-Hall, 1986.
[54] T. Coq. The Coq proof assistant : Reference manual : Version 7.2, Feb. 2002.
[55] P. Cousot and R. Cousot. Abstract interpretation: a unified lattice model for
static analysis of programs by construction or approximation of fixpoints. In
Proceedings 4th Annual ACM Symposium on Principles of Programming Languages, pages 238–252, 1977.
[56] P. Cousot and R. Cousot. Abstract interpretation frameworks. Journal of Logic
and Computation, 2(4):511–547, 1992.
[57] A. Craciun and M. Hodorog. Decompositions of natural numbers: From a case
study in mathematical theory exploration. In Symbolic and Numeric Algorithms
for Scientific Computing, 2007. SYNASC. International Symposium on, pages
41–47. IEEE, 2007.
[58] K. Damchoom. An incremental refinement approach to a development of a flashbased file system in Event-B. PhD thesis, University of Southampton, 2010.
[59] D. Déharbe, P. Fontaine, Y. Guyot, and L. Voisin. SMT solvers for rodin.
In Proceedings of the Third International Conference on Abstract State Machines, Alloy, B, VDM, and Z, ABZ’12, pages 194–207, Berlin, Heidelberg,
2012. Springer-Verlag.
Bibliography
177
[60] D. Delmas and J. Souyris. Astrée: From research to industry. In Static Analysis,
pages 437–451. Springer, 2007.
[61] DEPLOY project. Industrial deployment of system engineering methods providing high dependability and productivity. http://www.deploy-project.eu.
Accessed: 2014-07-31.
[62] DEPLOY project. Industrial projects. http://wiki.event-b.org/index.
php/Industrial_Projects. Accessed: 2014-07-31.
[63] DEPLOY project.
Rodin platform archive of ssf pilot (by ssf).
http://
deploy-eprints.ecs.soton.ac.uk/73/. Accessed: 2014-07-02.
[64] L. Dixon. A generic approach to proof planning. PhD thesis, PhD thesis, School
of Informatics, University of Edinburgh, 2005.
[65] L. Dixon and J. D. Fleuriot. IsaPlanner: A prototype proof planner in Isabelle.
In Proceedings of CADE’03, volume 2741 of LNCS, pages 279–283, 2003.
[66] V. D’silva, D. Kroening, and G. Weissenbacher. A survey of automated techniques for formal software verification. Computer-Aided Design of Integrated
Circuits and Systems, IEEE Transactions on, 27(7):1165–1178, 2008.
[67] B. Dunham, R. Fridshal, and G. L. Sward. A non-heuristic program for proving
elementary logical theorems. In IFIP Congress, pages 282–284, 1959.
[68] A. Edmunds and M. Butler. Tasking Event-B: An extension to Event-B for generating concurrent code. Programming Language Approaches to Concurrency
and Communication-cEntric Software, page 1, 2011.
[69] A. Edmunds, A. Rezazadeh, and M. Butler. Formal modelling for Ada implementations: tasking event-B. June 2012.
[70] Event-B and Rodin Documentation Wiki. All rewrite rules. http://wiki.
event-b.org/index.php/All_Rewrite_Rules. Accessed: 2014-07-02.
[71] Event-B and Rodin Documentation Wiki.
atiors.
Event-B mathematical oper-
http://handbook.event-b.org/current/html/mathematical_
notation.html. Accessed: 2014-07-31.
178
Bibliography
[72] Event-B and Rodin Documentation Wiki.
Provers for rodin.
handbook.event-b.org/current/html/atelier_b_provers.
http://
Accessed:
2015-02-28.
[73] Event-B and Rodin Documentation Wiki. Rodin plug-ins. http://wiki.
event-b.org/index.php/Rodin_Plug-ins. Accessed: 2014-07-31.
[74] R. W. Floyd. Assigning meanings to programs. In Proceedings of the American
Mathematical Society Symposia in Applied Mathematics 19, volume 1967.
[75] M.-C. Gaudel. Formal methods and testing: Hypotheses, and correctness approximations. In J. A. Fitzgerald, I. J. Hayes, and A. Tarlecki, editors, FM,
volume 3582 of Lecture Notes in Computer Science, pages 2–8. Springer, 2005.
[76] G. Gentzen. Investigations into logical deduction. In M. E. Szabo, editor, The
Collected Papers of Gerhard Gentzen, pages 68–213. North-Holland, Amsterdam, 1969.
[77] P. C. Gilmore. A proof method for quantification theory: Its justification and
realization. IBM J. Research and Development, 4:28–35, January, 1960.
[78] K. Gödel. On the completeness of the calculus of logic. Gödel, 2003:61–101,
1986.
[79] K. Gödel. Über formal unentscheidbare Sätze der Principia Mathematica und
verwandter systeme I (On formally undecidable propositions of Principia Mathematica and related systems I). In S. Feferman et al., editors, Kurt Gödel. Collected Works, volume I, pages 144–195. Oxford University Press, 1986.
[80] M. J. C. Gordon and T. F. Melham, editors. Introduction to HOL: A theorem
proving environment for higher order logic. Cambridge University Press, 1993.
[81] G. Grov and A. Ireland. Towards automated property discovery within Hume. In
2nd International Workshop on Invariant Generation (WING09), pages 45–59,
2009.
[82] F. Haftmann and M. Wenzel. Local theory specifications in Isabelle/Isar. In
S. Berardi, F. Damiani, and U. de’Liguoro, editors, TYPES, volume 5497 of
Lecture Notes in Computer Science, pages 153–168. Springer, 2008.
Bibliography
[83] A. Hall.
179
Using formal methods to develop an ATC information system.
In Industrial-Strength Formal Methods in Practice, pages 207–229. Springer,
1999.
[84] D. Haneberg, G. Schellhorn, H. Grandy, and W. Reif. Verification of Mondex
electronic purses with KIV: from transactions to a security protocol. Formal
Asp. Comput, 20(1):41–59, 2008.
[85] J. Harrison. HOL Light: A tutorial introduction. In M. K. Srivas and A. J.
Camilleri, editors, FMCAD, volume 1166 of Lecture Notes in Computer Science, pages 265–269. Springer, 1996.
[86] J. Harrison. Floating point verification in HOL Light: The exponential function.
Formal Methods in System Design, 16(3):271–305, 2000.
[87] J. R. Healey.
USA TODAY - Toyota deaths reported to safety
database rise to 37.
http://usatoday30.usatoday.com/money/autos/
2010-02-17-toyota17_ST_N.htm. Accessed: 2014-07-22.
[88] J. Heras, E. Komendantskaya, M. Johansson, and E. Maclean. Proof-pattern
recognition and lemma discovery in ACL2. In Logic for Programming, Artificial
Intelligence, and Reasoning, pages 389–406. Springer, 2013.
[89] J. Herbrand. Recherches sur la théorie de la démonstration. 1930.
[90] R. M. Hierons, J. P. Bowen, and M. Harman, editors. Formal Methods and Testing, An Outcome of the FORTEST Network, Revised Selected Papers, volume
4949 of Lecture Notes in Computer Science. Springer, 2008.
[91] T. S. Hoang. Event-B model of the buyer / seller B2B communication. http:
//deploy-eprints.ecs.soton.ac.uk/128/. Accessed: 2014-07-31.
[92] T. S. Hoang, H. Kuruma, D. Basin, and J.-R. Abrial. Developing topology
discovery in Event-B. In Integrated Formal Methods, pages 1–19. Springer,
2009.
[93] C. A. R. Hoare. An axiomatic basis for computer programming. CACM: Communications of the ACM, 12, 1969.
[94] C. A. R. Hoare. Communicating sequential processes. Comm.ACM, 21(8):666–
677, 1978.
180
Bibliography
[95] C. M. Holloway.
Why engineers should consider formal methods.
16th
AIAA/IEEE digital avionics systems conference, Irvine, California , October,
1997, 1997.
[96] A. Hommersom, P. Groot, P. J. F. Lucas, M. Balser, and J. Schmitt. Verification
of medical guidelines using background knowledge in task networks. IEEE
Trans. Knowl. Data Eng, 19(6):832–846, 2007.
[97] I. Houston and S. King. CICS project report experiences and results from the
use of Z in IBM. In VDM’91 Formal Software Development Methods, pages
588–596. Springer, 1991.
[98] D. Hovemeyer and W. Pugh. Finding bugs is easy. ACM Sigplan Notices,
39(12):92–106, 2004.
[99] D. Hutter. Coloring terms to control equational reasoning. Journal of Automated
Reasoning, 18(3):399–442, June 1997.
[100] D. Hutter and M. Kohlhase. A colored version of the lambda-calculus. Lecture
Notes in Computer Science, 1249:291–305, 1997.
[101] D. Hutter and C. Sengler. INKA: the next generation. In M. A. McRobbie and
J. K. Slaney, editors, Proceedings of the Thirteenth International Conference
on Automated Deduction (CADE-96), volume 1104 of LNAI, pages 288–292,
Berlin, July 30–Aug. 3 1996. Springer.
[102] iFACTS.
ATC
The
use
project.
of
formal
methods
on
the
iFACTS
http://www.open-do.org/2010/04/20/
the-use-of-formal-methods-on-the-ifacts-air-traffic-control-project/.
Accessed: 2014-07-02.
[103] A. Ireland and A. Bundy. Productive use of failure in inductive proof. Journal
of automated reasoning, 16(1-2):79–111, 1996.
[104] A. Ireland, B. J. Ellis, and T. Ingulfsen. Invariant patterns for program reasoning.
In MICAI 2004: Advances in Artificial Intelligence, pages 190–201. Springer,
2004.
[105] A. Ireland, G. Grov, and M. Butler. Reasoned modelling critics: turning failed
proofs into modelling guidance. In Abstract State Machines, Alloy, B and Z,
pages 189–202. Springer, 2010.
Bibliography
181
[106] A. Ireland, M. Jackson, and G. Reid. Interactive proof critics. Formal Asp.
Comput, 11(3):302–325, 1999.
[107] A. Ireland and J. Stark. On the automatic discovery of loop invariants, 1997.
[108] Isabelle.
Isabelle
documents.
https://isabelle.in.tum.de/
documentation.html. Accessed: 2014-08-13.
[109] M. Johansson, A. Bundy, and L. Dixon. Best-first rippling. In O. Stock and
M. Schaerf, editors, Reasoning, Action and Interaction in AI Theories and
Systems, volume 4155 of Lecture Notes in Computer Science, pages 83–100.
Springer, 2006.
[110] M. Johansson, L. Dixon, and A. Bundy. Case-analysis for rippling and inductive
proof. In Interactive Theorem Proving, pages 291–306. Springer, 2010.
[111] M. Johansson, L. Dixon, and A. Bundy. Dynamic rippling, middle-out reasoning and lemma discovery. In S. Siegler and N. Wasser, editors, Verification,
Induction, Termination Analysis, volume 6463 of Lecture Notes in Computer
Science, pages 102–116. Springer, 2010.
[112] M. Johansson, L. Dixon, and A. Bundy. Conjecture synthesis for inductive
theories. Journal of Automated Reasoning, 47(3):251–289, 2011.
[113] M. Johansson, D. Rosn, N. Smallbone, and K. Claessen. Hipster: Integrating
theory exploration in a proof assistant. In S. Watt, J. Davenport, A. Sexton,
P. Sojka, and J. Urban, editors, Intelligent Computer Mathematics, volume 8543
of Lecture Notes in Computer Science, pages 108–122. Springer International
Publishing, 2014.
[114] C. B. Jones. Systematic Software Development Using VDM. Prentice Hall,
second edition, 1990.
[115] C. B. Jones. The early search for tractable ways of reasoning about programs.
IEEE Annals of the History of Computing, 25(2):26–49, 2003.
[116] F. Kammüller and M. Wenzel. Locales : A sectioning concept for Isabelle. Technical Report UCAM-CL-TR-449, University of Cambridge, Computer Laboratory, 15 JJ Thomson Avenue, Cambridge CB3 0FD, United Kingdom, phone
+44 1223 763500, Oct. 1998.
182
Bibliography
[117] G. Klein, K. Elphinstone, G. Heiser, J. Andronick, D. Cock, P. Derrin, D. Elkaduwe, K. Engelhardt, R. Kolanski, M. Norrish, T. Sewell, H. Tuch, and S. Winwood. seL4: Formal verification of an OS kernel. In Proceedings of the 22nd
Symposium on Operating Systems Principles (22nd SOSP’09), Operating Systems Review (OSR), pages 207–220, Big Sky, MT, Oct. 2009. ACM SIGOPS.
[118] I. Kraan, D. A. Basin, and A. Bundy. Middle-out reasoning for synthesis and
induction. Journal of Automated Reasoning, 16(1–2):113–145, Mar. 1996.
[119] F. Kunst. Lint, a C program checker. Vrije Universiteit, Amsterdam, 1988.
[120] D. Lacey, J. Richardson, and A. Smaill. Logic program synthesis in a higherorder setting. In Computational LogicCL 2000, pages 87–100. Springer, 2000.
[121] K. G. Larsen, M. Mikucionis, and B. Nielsen. Online testing of real-time systems using UppAal. In J. Grabowski and B. Nielsen, editors, FATES, volume
3395 of Lecture Notes in Computer Science, pages 79–94. Springer, 2004.
[122] G. T. Leavens, A. L. Baker, and C. Ruby. JML: A notation for detailed design.
In H. Kilov, B. Rumpe, and I. Simmonds, editors, Behavioral Specifications of
Businesses and Systems, pages 175–188. Kluwer Academic Publishers, Boston,
1999.
[123] K. R. M. Leino. Dafny: An automatic program verifier for functional correctness. In Logic for Programming, Artificial Intelligence, and Reasoning, 16th International Conference, LPAR-16, volume 6355 of Lecture Notes in Computer
Science, pages 348–370. Springer-Verlag, 2010.
[124] Lemma 1 Ltd.
Proofpower.
http://www.lemma-one.com/ProofPower/
index/. Accessed: 2014-07-02.
[125] D. B. Lenat. Automated theory formation in mathematics. Contemporary Mathematics, 29:287–314, 1984.
[126] N. Leveson and C. S. Turner.
accidents.
An investigation of the Therac-25
http://courses.cs.vt.edu/professionalism/Therac_25/
Therac_1.html. Accessed: 2014-07-02.
[127] Y. Lin, A. Bundy, and G. Grov. The use of rippling to automate Event-B invariant preservation proofs. In A. Goodloe and S. Person, editors, NASA Formal
Bibliography
183
Methods, volume 7226 of Lecture Notes in Computer Science, pages 231–236.
Springer, 2012.
[128] Y. Lin, A. Bundy, and G. Grov. The use of rippling to automate Event-B invariant preservation proofs. In IJCAR Workshop on Automated Theory eXploration
(ATX 2012), Manchester, 2012.
[129] D. E. Long. Model checking, abstraction, and compositional verification. PhD
thesis, Citeseer, 1993.
[130] M. Loomes and J. Woodcock. Software engineering mathematics: Formal methods demystified, 1988.
[131] H. Lowe and D. Duncan. Xbarnacle: Making theorem provers more accessible.
In Automated DeductionCADE-14, pages 404–407. Springer, 1997.
[132] K. D. M. Butler, J.-R. Abrial and A. Edmunds. Applying Event-B and Rodin to
the filestore. In ABZ, VSRNet Workshop, 2008.
[133] E. Maclean, J. D. Fleuriot, and A. Smaill. Proof planning non-standard analysis.
In ISAIM, 2002.
[134] MathWorksd. Simulink - simulation and model-based design. http://www.
mathworks.co.uk/products/simulink/. Accessed: 2014-07-16.
[135] D. Matthews. Poly/ML home page. http://www.polyml.org/index.html.
Accessed: 2014-07-31.
[136] R. L. McCasland and A. Bundy. Mathsaid: a mathematical theorem discovery tool. In Symbolic and Numeric Algorithms for Scientific Computing, 2006.
SYNASC’06. Eighth International Symposium on, pages 17–22. IEEE, 2006.
[137] K. L. McMillan. Symbolic Model Checking: An Approach to the State Explosion
Problem. Kluwer Academic Publishers, 1993.
[138] R. Milner. Logic for computable functions: descriptions of a machine implementation. ACM SIGPLAN Notices, 7:1–6, 1972.
[139] R. Milner. Communication and Concurrency. Prentice-Hall, 1989.
[140] R. Milner. The definition of standard ML: revised. MIT press, 1997.
184
Bibliography
[141] R. Milner. Communicating and Mobile Systems: the Pi-Calculus. Cambridge
University Press, 1999.
[142] O. Montano-Rivas, R. L. McCasland, L. Dixon, and A. Bundy. Scheme-based
synthesis of inductive theories. In G. Sidorov, A. H. Aguirre, and C. A. R.
Garcı́a, editors, MICAI (1), volume 6437 of Lecture Notes in Computer Science,
pages 348–361. Springer, 2010.
[143] C. Morgan. Programming from specifications. Prentice-Hall, Inc., 1990.
[144] NASA. C global surveyor. http://ti.arc.nasa.gov/tech/rse/vandv/
cgs/. Accessed: 2014-07-31.
[145] A. Newell, J. C. Shaw, and H. A. Simon. Empirical explorations with the logic
theory machine. In Western Joint Computer Conference, volume 15, pages 218–
239, 1957. Also in Feigenbaum and Feldman, 1963.
[146] T. R. Nicely. Pentium FDIV flaw. http://www.trnicely.net/pentbug/
pentbug.html. Accessed: 2014-07-02.
[147] C. O’Halloran. Automated verification of code automatically generated from
R Autom. Softw. Eng, 20(2):237–264, 2013.
simulink.
[148] S. Owre, J. M. Rushby, and N. Shankar. PVS: A prototype verification system.
In D. Kapur, editor, Proceedings of the 11th International Conference on Automated Deduction (CADE-11), volume 607 of LNAI, pages 748–752. Springer,
Saratoga Springs, NY, June 1992.
[149] L. C. Paulson. Isabelle: a generic theorem prover, volume 828 of LNCS.
Springer-Verlag, 1994.
[150] Pientka and Kreitz. Automating inductive specification proofs. FUNDINF:
Fundamenta Informatica, 39, 1999.
[151] B. Pientka and C. Kreitz. Instantiation of existentially quantified variables in
inductive specification proofs. In Artificial Intelligence and Symbolic Computation, pages 247–258. Springer, 1998.
[152] D. Prawitz, H. Prawitz, and N. Voghera. A mechanical proof procedure and its
realization in an electronic computer. J. ACM, 7(2):102–128, 1960.
Bibliography
185
[153] J. Richardson, A. Smaill, and I. Green. Proof planning in higher-order logic
with λClam. In C. Kirchner and H. Kirchner, editors, Proceedings of the 15th
International Conference on Automated Deduction (CADE-98), volume 1421 of
LNAI, pages 129–133, Berlin, July 5–10 1998. Springer.
[154] J. A. Robinson. A machine-oriented logic based on the resolution principle.
Journal of the ACM, 12(1):23–41, Jan. 1965.
[155] Rodin Proof Tactics. Functional overriding in goal. http://wiki.event-b.
org/index.php/Rodin_Proof_Tactics. Accessed: 2014-09-25.
[156] Rodin User’s Handbook.
Mathematical notation.
http://handbook.
event-b.org/current/html/mathematical_notation.html.
Accessed:
2014-08-13.
[157] A. Romanovsky and M. Thomas, editors. Industrial Deployment of System Engineering Methods. Springer, Berlin, 2013.
[158] M. Schmalz. Formalizing the Logic of Event-B. Partial Functions, Definitional
Extensions, and Automated Theorem Proving. PhD thesis, ETH Zurich, 2012.
[159] C. Snook and M. Butler.
UML-B: Formal modeling and design aided by
UML. ACM Transactions on Software Engineering and Methodology (TOSEM),
15(1):92–122, 2006.
[160] S. Thompson.
Haskell: the craft of functional programming, volume 2.
Addison-Wesley, 1999.
[161] Tretmans. Testing concurrent systems: A formal approach. In CONCUR:
10th International Conference on Concurrency Theory. LNCS, Springer-Verlag,
1999.
[162] A. Turing. Checking a large routine. In The early British computer conferences,
pages 70–72. MIT Press, 1989.
[163] M. Utting and B. Legeard. Practical Model-Based Testing: A Tools Approach.
Morgan-Kaufmann, 2006.
[164] M. Veanes, C. Campbell, W. Grieskamp, W. Schulte, N. Tillmann, and L. Nachmanson. Model-based testing of object-oriented reactive systems with Spec Explorer. In R. M. Hierons, J. P. Bowen, and M. Harman, editors, Formal Methods
186
Bibliography
and Testing, volume 4949 of Lecture Notes in Computer Science, pages 39–76.
Springer, 2008.
[165] T. Walsh. A divergence critic for inductive proof. Journal of Artificial Intelligence Research, 4:209–235, 1996.
[166] T. Walsh, A. Nunes, and A. Bundy. The use of proof plans to sum series. Lecture
Notes in Computer Science, 607:325–339, 1992.
[167] J. Woodcock and J. Davies. Using Z - Specification, Refinement, and Proof.
Prentice Hall, London, 1996.
[168] J. Woodcock, P. G. Larsen, J. Bicarregui, and J. S. Fitzgerald. Formal methods:
Practice and experience. ACM Comput. Surv, 41(4), 2009.
[169] S. Wright and K. Eder. Experience of deploying Event-B in industrial microprocessor development. In Industrial Deployment of System Engineering Methods,
pages 107–122. Springer, 2013.
[170] E. Yilmaz and T. S. Hoang. Development of Rabin’s choice coordination algorithm in Event-B. 2010.