1. The B Method by Péter Györök

2. Contents Metadata The B language The Prover Demo

3. People behind it Developed by Jean-Raymond Abrial – Other people: G. Laffite, F. Mejia, I. McNeal Currently big companies and various universities maintain it ClearSy, Oxford University (Programming Research Group) Subsidised projects

4. History, origin, versions Predecessor: Z-notation (also by Abrial) Newest incarnation: Event-B Tools: Atelier B, B4free, B-toolkit

5. Primary application domain Software engineering – Specification – Design – Proof – Code generation Safety-critical systems Big companies that use it: Siemens, Alstom, Systerel…

6. Success stories METEOR project – Paris Metro Line 14 – (Hungarian relevance?) Ariane 5 (rocket)

7. System overview B notation based on group theory and first order logic The method is heavily focused on system development – Multiple versions of the system: abstract machine -> refiniements -> implementation – The proofs are for the consistency between versions Syntax is expressed using mathematical symbols or their ASCII equivalents (e.g. ! for ∀ ) Lots of syntactic sugar for easily writing down expressions

8. Language features Types: based on set theory Types are either basic (integer, bool, string, enum) or built using Cartesian product, power set or record – Types inferred by typing predicates ( ∈, ⊂, ⊆, =) – The type of something is „the biggest set that contains it” – The type of integer literals and expressions is ℤ – The type of a set literal or expression is p(set), e.g. ℤ ∈ p( ℤ ) – The type of a function from X to Y is ℘ (X × Y) – Distinction of „concrete” types that can be used in implementation – Many advanced types such as array, sequence, relation, tree – each with their own set of operators

9. Language features Expressions and predicates – Predicates use the syntax of first order logic – Expressions of various types use the types’ specific operators – Lambda expressions are allowed Substitutions – Allow a predicate to be transformed ( [x := E] P ) – Resemble features of an imperative language – Also some „alien” features (precondition etc.) – Proof obligations are derived from substitutions – Can be nondeterministic (but the implementation must be deterministic, cf. concrete types)

10. Language features Some types of substitution – BEGIN…END – skip – := :() : ∈ – PRE – ASSERT – IF – CASE – LET – VAR – ; – || – WHILE

11. Language features Machine – The „thing” that we are reasoning about – Resembles classes from OOP – Can be abstract, refinement or implementation – Special constraints apply to implementations – Elements of a machine: Parameters and their constraints Imports, sees, includes etc. Sets (enum or „deferred”) Abstract and concrete constants, variables

12. Language features – Elements of a machine Properties, invariants Values (!) Initialisation and operations – expressed as a substitution Operations can have multiple return values Assertions – this makes it possible to use B as a mathematical proof assistant

13. Language features Example: adding assertions to help with a proof. MACHINE MA CONCRETE_VARIABLES var INVARIANT var ∈ INT ⋀ var 2 = 1 ASSERTIONS var = 1 ⋁ var = - 1... END This must be proven from the invariant. Then it can be used as a lemma in other proofs. Typing predicate

14. Language fetaures The B0 language – Restricted version of the B language – Used for implementation only – Substitutions are equivalent to instructions – Translated to C(++), Ada etc.

15. The Prover Atelier B uses both an automatic and interactive prover The basic concept is the proof obligation (PO): Goal + hypotheses The prover doesn’t type check – that’s part of the proof! e.g. b = e 1 + e 2 where b ∈ BOOL and e 1 ∈ ℤ, e 2 ∈ ℤ is a legal goal which is unprovable Well-definedness must be proved too e.g. 8/c is well-defined if c ≠ 0

16. The Prover Proof obligations – The types of things match up – The refinements are consistent – The initialisation sets the invariants and the operations keep them – The operations meet their pre/postconditions – Assertions are true

17. The Prover Rules: inductive, deductive and rewriting Theory: a list of rules (higher index has priority) Tactic: a list of theories to search for an applicable rule – Backward tactic divides the goal into subgoals – Forward tactic generates new hypotheses – A full tactic is the combination of the two

18. The Prover Procedure of applying the tactic: – Search the backward tactic for an applicable rule – If one is found, apply it and continue with the next theory – Tilde (~) can be used as the „repeat” operator – The whole tactic is implicitly tilded – For every new hypothesis generated, run the forward tactic with the same procedure

19. The Prover The theory is fully customizable, even with inconsistent rules! The prover might loop infinitely Proof obligations are normalized – Examples: n > m becomes m+1 <= n, a ⇔ b becomes (a ⇒ b) ∧ (b ⇒ a), a ⊆ b becomes a ∈ ℘ (b)

20. The Prover Commands can be given to the interactive prover The prover will try to prove what is needed to execute the command. If it fails, a new goal is created ae : Abstract expression – P[…, expr, …] after ae(expr, y) becomes well-defined(expr) ∧ expr=y ⇒ P[…, y, …]

21. Commands ah: Add Hypothesis – If the goal was h 1, …, h n ⇒ G, ah(P) replaces it with h 1, …, h n ⇒ P h 1, …, h n, P ⇒ G ct: proof by contradiction – Replaces a goal h 1, …, h n ⇒ G with h 1, …, h n, ¬ G ⇒ bfalse

22. Commands dc: Do Cases – If the goal is G, use dc(P) to split it into ¬ P ⇒ G P ⇒ G se: Suggest for Exist – If the goal is ∃ (w 1, …, w n ).P(w 1, …, w n ) se(v 1, …, v n ) turns it into P(v 1, …, v n )

23. Commands ap: Arithmetic Proof – An automated mechanism for proving things about systems of linear equations and inequations pp: Predicate Prover – Another automated system pr: Prover Call – Yet another (these all solve different kinds of goals) ar: Apply Rule – Just applies a rule dd: Deduction – For a goal P ⇒ Q, raise P in the hypothesis stack then prove Q ba: Back cg: display Current Goal qu: Quit

24. Demo The task: decide if a given number is prime

25. Creating a project

26. Adding a component Let’s add something to the empty project…

27. Adding a component Since this is our first component, the only choice is „Machine”.

28. Editing Now that we have a machine, double click it on the „Components” list to edit

29. Insert Theorem Here What we want to enter there: MACHINE prim OPERATIONS p ← is_prim ( n ) = PRE n ∈ [3.. MAXINT] THEN p := bool (∀ i. ( i ∈ [ 2.. n-1 ] ⇒ ( n mod i ) ≠ 0 ) ) END

30. Insert Theorem Here What it will look like in B: Atelier B hates single- letter identifiers so we reduplicate everything

31. Adding an implementation IMPLEMENTATION prim_i REFINES prim OPERATIONS pp <-- is_prim ( nn ) = BEGIN VAR ll, kk IN ll := TRUE ; kk := nn ; WHILE ( 2 /= kk & ll = TRUE) DO IF nn mod (kk-1) = 0 THEN kk := kk-1; ll := FALSE ELSE kk := kk-1 END INVARIANT ll : BOOL & nn : NAT & nn >= 3 & kk : 2..nn & (ll=TRUE => (! jj.(jj:kk..nn-1 => nn mod jj /=0))) & (ll=FALSE=> ( kk: 2..nn-1 & nn mod kk = 0)) VARIANT kk END ; pp :=ll END

32. Generate PO’s Click „Po”, then „F0” to try to prove… Interactive Proof time!

33. Interactive Prover Double-click one

34. Interactive Prover Now we can enter commands.

35. Completing the proof Here are the commands to complete the proof: dc(jj = kk-1) pr ah(jj: kk..nn-1) pp(100) pr dc(ll$7777 = TRUE) dd ah(kk$7777 = 2) pr pp pr dd ah(ll$7777 = FALSE) pp dd pr se(kk$7777) pr

36. Completing the proof Green means success!

37. THE END