# The B Method by Péter Györök. Contents Metadata The B language The Prover Demo.

## Presentation on theme: "The B Method by Péter Györök. Contents Metadata The B language The Prover Demo."— Presentation transcript:

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

Contents Metadata The B language The Prover Demo

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

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

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

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

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

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

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)

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

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

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

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

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.

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

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

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

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

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)

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, …]

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

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 )

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

Demo The task: decide if a given number is prime

Creating a project

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

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

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

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

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

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

Interactive Prover Double-click one

Interactive Prover Now we can enter commands.

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

Completing the proof Green means success!

THE END