© Gudmund Grov & Andrew Ireland Dependable Systems Group Planning for System Development Gudmund Grov & Andrew Ireland Dependable Systems Group School of Mathematical & Computer Sciences Heriot-Watt University Edinburgh

© Gudmund Grov & Andrew Ireland Dependable Systems Group Outline Proof planning and software development Event-B and rigorous system development Research opportunities A proposal

© Gudmund Grov & Andrew Ireland Dependable Systems Group Conjecture Theorem Proving Automatic Theorem Prover: Proof Rules + Guidance Theory Proofs

© Gudmund Grov & Andrew Ireland Dependable Systems Group Conjecture Proof Planning Proof Plans: methods and critics Proof Checker Theory TacticsProofs Proof Planner External tools Program Analysis (SPARK) User Interaction

© Gudmund Grov & Andrew Ireland Dependable Systems Group 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

© Gudmund Grov & Andrew Ireland Dependable Systems Group 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

© Gudmund Grov & Andrew Ireland Dependable Systems Group 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

© Gudmund Grov & Andrew Ireland Dependable Systems Group 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

© Gudmund Grov & Andrew Ireland Dependable Systems Group 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

© Gudmund Grov & Andrew Ireland Dependable Systems Group 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

© Gudmund Grov & Andrew Ireland Dependable Systems Group 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

© Gudmund Grov & Andrew Ireland Dependable Systems Group Models and contexts Model Context Variables Invariants Events Constants Carrier sets Properties Sees

© Gudmund Grov & Andrew Ireland Dependable Systems Group Development: refinement & (de-)composition

© Gudmund Grov & Andrew Ireland Dependable Systems Group instantiates Development: generic instantiation

© Gudmund Grov & Andrew Ireland Dependable Systems Group Abrial’s “Cars on a Bridge” Model n

© Gudmund Grov & Andrew Ireland Dependable Systems Group First Refinement b a c c a=0 c=0 a

© Gudmund Grov & Andrew Ireland Dependable Systems Group b a c First Refinement

© Gudmund Grov & Andrew Ireland Dependable Systems Group Second Refinement 0 1 b c=0 ac a=0 a c

© Gudmund Grov & Andrew Ireland Dependable Systems Group Second Refinement 0 1 b a c

© Gudmund Grov & Andrew Ireland Dependable Systems Group Proof Obligation 1 ML_out preserves inv2_3 Failure analysis: proof obligation unprovable Proof patch: assume negated premise of goal implication, i.e. simplified to Model patch 1 (local): strengthen guard: Model patch 2 (global): strengthen invariant:

© Gudmund Grov & Andrew Ireland Dependable Systems Group 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:

© Gudmund Grov & Andrew Ireland Dependable Systems Group 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

© Gudmund Grov & Andrew Ireland Dependable Systems Group Proof Obligation 3 ML_out preserves inv2_4 Failure analysis: unprovable case Model patch: event splitting First event: (trivial to prove)Second event:

© Gudmund Grov & Andrew Ireland Dependable Systems Group Example proof 4 ML_out_2 preserves inv2_4 Note: guard cannot be updated by since it already contains Model patch: update action, i.e.

© Gudmund Grov & Andrew Ireland Dependable Systems Group 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

© Gudmund Grov & Andrew Ireland Dependable Systems Group 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

© Gudmund Grov & Andrew Ireland Dependable Systems Group 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

© Gudmund Grov & Andrew Ireland Dependable Systems Group Planning for Event-B Proof plans represent common patterns of reasoning Model plans represent common patterns of development?

© Gudmund Grov & Andrew Ireland Dependable Systems Group Planning for Event-B Event-B MUI Event-B PUI Event-B POG Event-B POM Event-B SEQP Event-B SC ProB

© Gudmund Grov & Andrew Ireland Dependable Systems Group Planning for Event-B Proof Planner Event-B MUI Event-B PUI Event-B POG ProB Event-B POM Event-B SEQP Event-B SC

© Gudmund Grov & Andrew Ireland Dependable Systems Group Planning for Event-B Proof Planner Event-B MUI Event-B POG ProB Event-B POM Event-B SEQP Event-B SC Model Planner

© Gudmund Grov & Andrew Ireland Dependable Systems Group Planning for Event-B Proof Planner UML-B MUI Event-B POG ProB Event-B POM Event-B SEQP Event-B SC Model Planner Event-B MUI

© Gudmund Grov & Andrew Ireland Dependable Systems Group 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

© Gudmund Grov & Andrew Ireland Dependable Systems Group 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!