© gudmund grov & andrew ireland dependable systems group planning for system development...

© Gudmund Grov & Andrew IrelandDependable Systems Group

Planning for System Development

Gudmund Grov & Andrew IrelandDependable Systems Group

School of Mathematical & Computer Sciences Heriot-Watt University

Edinburgh


Outline

• Proof planning and software development

• Event-B and rigorous system development

• Research opportunities• A proposal


Conjecture

Theorem Proving

Automatic Theorem Prover:Proof Rules + Guidance

Theory

Proofs


Conjecture

Proof Planning

Proof Plans:methods and critics

ProofChecker

Theory

Tactics ProofsProofPlanner

External tools

• Program Analysis (SPARK)

• User Interaction


Proof Plans:A Science of Reasoning

concrete proofs

proofs patterns

Patterns provide guidance in the search for concrete proofs, in particular where proof patching is required


Proof Planning • Reuse: strategies can be easily ported between

proof checkers • Robustness: critics and middle-out reasoning provide

flexibility in how proof search is organized

• Cooperation: provides a natural level for combining multiple reasoning processes, i.e. complementary techniques compensating for each other’s weaknesses


• Clam-Oyster, lambdaClam: Functional program verification, synthesis & transformation; hardware verification

• Periwinkle, lambdaClam, Whelk: Logic program synthesis

• Bertha: Imperative program verification & synthesis• SPADEase: Verification automation for SPARK• CORE: Cooperative Reasoning for Automatic Software

Verification • SEAR: System Evolution via Animation and Reasoning

Software Development Applications


Automatic Proof Patching • Inductive lemmas discovery• Conjecture generalization• Case splitting• Induction rule revision & synthesis• Existential witnesses • Correcting false conjectures• Loop invariant discovery• Frame axiom discovery • Tactic formation via data-mining


Event-B• An approach to systems development which

seamlessly combines modelling and reasoning• Developed from the classical B-method for

software development• Tackles problem of volatile requirements by

promoting model evolution and reformulation • Event-B tool: Eclipse based plug-in architecture

providing “design-time feedback”• EU Projects: RODIN (04-07) DEPLOY (08-12)• Industrial partners: Bosch, Siemens, Space

Systems Finland, SAP, Nokia


Event-B• Systems represented as discrete transition

systems, using classical logic and set-theory• System = Model + Context

– Models contain variables, invariants and events (guards + actions)

– Contexts contain constants, carrier sets and properties

• Development of complex systems managed via:– refinement– (de-)composition– generic instantiation


User Interaction & Event-B• Proving:

– autoprover failures– proof-failure analysis– existential witnesses

• Modelling:– defining models, refinements, (de-)compositions

and generic instantiations– defining gluing invariants – links variables

between model refinements– patching models using proof-failure analysis– selecting refinement patterns


Models and contexts

Model Context

Variables

Invariants

Events

Constants

Carrier sets

Properties

Sees


Development:refinement & (de-)composition


instantiates

Development:generic instantiation


Abrial’s “Cars on a Bridge” Model

n


First Refinement

b

a

c

c

a=0c=0

a


b

a

c

First Refinement


Second Refinement01

b

c=0

a c

a=0a

c


Second Refinement01

b

a

c


Proof Obligation 1

• ML_out preserves inv2_3

Failure analysis: proof obligation unprovableProof patch: assume negated premise of goal implication, i.e.

simplified to

QuickTime™ and a decompressor

are needed to see this picture.

Model patch 1 (local):strengthen guard:

Model patch 2 (global):strengthen invariant:


Proof Obligation 2

• IL_out preserves inv2_4

Failure analysis: proof obligation unprovable.Proof patch: assume negated premise of goal implication:

simplified to



Model patch 1 (local):strengthen guard:



Model patch 2 (global):strengthen invariant:


Observations on Model Patching• Both proof-failures suggest the same global patch, i.e. at

least one traffic light must always be set to red!• Model patch: inv2_5 is added to the invariant:

• Note that proof-analysis gives rise to alternative model patches


Proof Obligation 3

• ML_out preserves inv2_4 Failure analysis: unprovable case

Model patch: event splitting

First event: (trivial to prove)Second event:


Example proof 4

• ML_out_2 preserves inv2_4 Note: guard cannot be updated by

since it already containsModel patch: update action, i.e.


Observations• Proof-failure analysis plays a central role in

developing systems within Event-B• Over coming proof-failures typically involves

patching models, e.g. invariant strengthening, modifying events (guards & actions)

• Strong interplay between modelling and proving: “A program [model] and its proof should be developed [planned] hand-in-hand, with the proof [plan] usually

leading the way” “The Science of Programming” Gries, `81

• No automation for proof-failure analysis and patching, i.e. currently hand-crafted by users


Observations• Proof-failure analysis plays a central role in

developing systems within Event-B• Over coming proof-failures typically involves

patching models, e.g. invariant strengthening, modifying events (guards & actions)

• Event-B promotes strong interplay between modelling and proving

• No automation for proof-failure analysis and patching, i.e. currently hand-crafted by users


Opportunities • Proving:

– Increasing proof automation with the Event-B tool:• proving invariants, refinements, generic instantiations• Reuse, reformulation & learning strategies (tactic formation) • proof by mathematical induction (Rodin toolset roadmap includes

inductive data types)• existential witnessing

– Proof patching:• invariants, generalizations and lemmas

• Modelling & Proving:– Exploiting the interplay between proving and modelling,

i.e. use proof-failure analysis to inform model patching– Discovering gluing invariants– Build upon existing refinement patterns


Planning for Event-B

Proof plans represent common patterns of reasoning

Model plans represent common patterns of development?



Event-BMUI

Event-BPUI

Event-BPOG

Event-BPOM

Event-BSEQP

Event-BSC

ProB



ProofPlanner

Event-BMUI

Event-BPUI

Event-BPOG

ProB

Event-BPOM

Event-BSEQP

Event-BSC



ProofPlanner

Event-BMUI

Event-BPOG

ProB

Event-BPOM

Event-BSEQP

Event-BSC

ModelPlanner



ProofPlanner

UML-BMUI

Event-BPOG

ProB

Event-BPOM

Event-BSEQP

Event-BSC

ModelPlanner

Event-BMUI


Planning for Event-B Proposal • Develop a proof planning plug-in• Reuse and develop new proof plans which

increase proof automation• Investigate the idea of model planning via the

development of a plug-in • Through the development of proof and model

plans, investigate the interplay between proving and modelling, e.g. how proof-failure analysis informs model reformulation and evolution


Conclusion • Event-B: a mature technology for developing

complex systems• Open architecture where the interplay between

modelling and proving is taken seriously• Opportunities for model and proof planning:

– Engineering: raise the level at which a developer works – focus on high-level modelling decisions

– Science: deepen our understanding of the relation between modelling and proof – a science of rigorous modelling!

© gudmund grov & andrew ireland dependable systems group planning for system development...

Documents