Planning for System Development

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

2. Outline • Proof planning and software development • Event-B and rigorous system development • Research opportunities • A proposal

3. Theorem Proving Conjecture Automatic Theorem Prover: Proof Rules + Guidance Proofs Theory

4. Proof Planning Conjecture Proof Plans: methods and critics Proof Planner Tactics Proof Checker Proofs Theory • Program Analysis (SPARK) • User Interaction External tools

5. Proof Plans:A Science of Reasoning proofs patterns concrete proofs Patterns provide guidance in the search for concrete proofs, in particular where proof patching is required

6. 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

7. Software Development Applications • 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

8. 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

9. 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

10. 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

11. 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

12. Models and contexts Context Model Variables Constants Sees Carrier sets Invariants Properties Events

13. Development:refinement & (de-)composition

14. instantiates Development:generic instantiation

15. n Abrial’s “Cars on a Bridge” Model

16. c c a a a=0 c=0 First Refinement b

17. c a First Refinement b

18. c c a a a=0 c=0 Second Refinement 0 1 b

19. c a Second Refinement 0 1 b

20. Model patch 1 (local): strengthen guard: Failure analysis: proof obligation unprovable Proof patch: assume negated premise of goal implication, i.e. simplified to Model patch 2 (global): strengthen invariant: Proof Obligation 1 • ML_out preserves inv2_3

21. 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: Proof Obligation 2 • IL_out preserves inv2_4

22. 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_5is added to the invariant: • Note that proof-analysis gives rise to alternative model patches

23. Failure analysis: unprovable case Model patch: event splitting Second event: First event: (trivial to prove) Proof Obligation 3 • ML_out preserves inv2_4

24. Note: guard cannot be updated by since it already contains Model patch: update action, i.e. Example proof 4 • ML_out_2 preserves inv2_4

25. 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

26. 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

27. 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

28. Planning for Event-B Proof plans represent common patterns of reasoning Model plans represent common patterns of development?

29. Planning for Event-B Event-B SC Event-B POG Event-B MUI Event-B SEQP Event-B POM Event-B PUI ProB

30. Planning for Event-B Event-B SC Event-B POG Event-B MUI Event-B SEQP Event-B POM Event-B PUI ProB Proof Planner

31. Planning for Event-B Event-B SC Event-B POG Event-B MUI Event-B SEQP Event-B POM ProB Proof Planner Model Planner

32. Planning for Event-B Event-B SC Event-B POG Event-B MUI Event-B SEQP Event-B POM UML-B MUI ProB Proof Planner Model Planner

33. 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

34. 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!