1. Structuring for Reuse: from B to Event-B Mike Poppleton, DSSE

2. Outline 1.Classical B – recap 2.Structuring in classical B 3.Event-B – recap 4.Towards structuring in Event-B 5.Fusion of events and models 6.Conclusion 2

3. Classical B: quick recap Model-based formal method, obvious LTS semantics: Unit of modularity = MACHINE Static information = SETS, CONSTANTS, PROPERTIES Dynamic state = VARIABLES, INVARIANT Behaviour = INITIALIZATION, OPERATIONS A partial Module Interconnection Language (MIL): o INCLUDES, EXTENDS, PROMOTES o IMPORTS, SEES … 3

4. Classical B: quick recap II The atom of behaviour: the substitution: x := Exp(x,s,c) x :| Pred(x 0,x,s,c) x : ∈ SetExp(…) is elaborated in the GSL (generalised substitution language): PRE Pred THEN Sub END CHOICE Sub1 OR Sub2 … END SELECT Pred1 THEN Sub1 WHEN Pred2 THEN Sub2 … ELSE... END ANY z WHERE Pred(z,x) THEN Sub(z,x) END typically x := Exp(z,x) IF Pred THEN Sub1 ELSE Sub2 END etc … 4

5. Structuring in Classical B: Operation-level Remember : B acts via call-/invocation-based preconditioned operations Event-B acts via occurrence of enabled guarded events Conditional substitutions: o IF-THEN(-ELSE), SELECT(-ELSE), CASE(-ELSE) … o Nesting of substitutions within such … o (shades of von Neumann SSIR …) Operation call (of included by including machine operation) 5

6. Structuring in B: Machine-level M INCLUDES N: internal reuse M, N variables, operations distinct: Concatenate defns, conjoin predicates operation call: o  op M (i) = SubsExp (ao  op N (ai)) is realised by a “substituted substitution”: [fo, fi := ao, ai] 6

7. Structuring in B: Machine-level II M INCLUDES N … But: Included N ops not externally visible from M In including op, “at most one op of a given including machine can be called” Encapsulation: included vars writable only by included ops ? Machine inclusion restriction on op call is presumably to guarantee variable distinctness ? 7

8. Structuring in B: Machine-level II M PROMOTES N.op1, N.op2 … (M INCLUDES N) M EXTENDS N : externally visible reuse named/ all included ops become full ops of including machine (ie externally visible) ? but these ops are NOT internally callable ? 8

9. Structuring in B: Machine-level III M USES N: elaborated inclusion: 2-step multiple reuse: M1, M2, M3 variables distinct M1 -USES  M2  USES- M3 INCLUDES M M1, M3 reuse static part of M2 without re-copying M2’s text M1, M3 can read M2 vars, cannot use M2 ops M INCLUDES M1,M2,M3 9

10. Structuring in B: Implementation-level M SEES N: implementation-level, for flexible visibility across the development tree M, N variables distinct Seen machine independence  Seeing INVARIANT cannot see seen VARIABLES Contrast with INCLUDES/USES: specification-level including/using INVARIANT can see included/used VARIABLES 10

11. Questions Why were these structuring mechanisms removed in the evolution to Event-B ? o Elaborate and awkward visibility rulesets and POs o Elaborate and awkward stucturing mechanism (haven’t discussed REFINEMENTs, IMPLEMENTATIONs, IMPORT, SEES) o And said structuring can be inconsistent ( Rouzaud, Potet, 1999 ) o ?? Should/can any of these mechanisms be introduced into Event-B (and if so, how) ? 11

12. Answers ? 1.Atomic conditional transition: o No: use separate event for each conditional branch o Rely on event scheduling o ! But lose control over invocation … 2.INCLUDES for internal operation call: o No, as for (1.) 3.PROMOTES/EXTENDS: o Yes, would like the reuse … 4.USES o Would like the reuse without awkward MIL mechanisms to avoid multiple machine text copies (ie need more sophisticated textual composition) 12

13. Event-B What’s the evolution from Classical B ?  Abrial doc 13

14. Event-B events & consistency MACHINE M, axioms P, invariant I, event e, variable v: e = ANY t WHERE Q(t,v) THEN v := F(t,v) END guard G = ∃ t.Q(t,v) before-after predicate E = ∃ t.(Q(t,v) ⋀ v’ = F(t,v)) consistency: P ⋀ I(v) ⋀ G(v) ⋀ E(v,v’) ⇒ I(v’) 14

15. Event-B events & consistency MACHINE M, axioms P, invariant I, event e, variable v: e = ANY t WHERE Q(t,v) THEN v := F(t,v) END guard G = ∃ t.Q(t,v) before-after predicate E = ∃ t.(Q(t,v) ⋀ v’ = F(t,v)) consistency: P ⋀ I(v) ⋀ G(v) ⋀ E(v,v’) ⇒ I(v’) 15

16. Simple composition in Event-B (1) Variables, events disjoint: ie “PROMOTES/EXTENDS/USES” M(v, {e i }) + N(w, {f j }) = concatenate definitions, conjoin predicates No conflict: independent product of two models Enabledness “increases” Consistency is preserved trivially: I M+N (v,w) = I M (v) ⋀ I N (w) e M+N = e M || skip N 16

17. Simple composition in Event-B (2) (2) variables disjoint, events intersect ie new (to Event-B) e M = ANY t WHERE Q M (t,v) THEN v := F M (t,v) END guard: ∃ t. Q M (t,v) b-a pred: ∃ t.(Q M (t,v) ⋀ v’ = F M (t,v)) e N = ANY u WHERE Q N (u,w) THEN w := F N (u,w) END guard: ∃ u. Q N (u,w) b-a pred: ∃ u.(Q N (u,w) ⋀ w’ = F N (u,w))  e M+N =ANY t,u WHERE Q M (t,v) ⋀ Q N (u,w) THEN v := F M (t,v) || w := F N (u,w) END guard: ∃ t,u. (Q M (t,v) ⋀ Q N (u,w)) b-a pred: ∃ t,u.(Q M (t,v) ⋀ Q N (u,w) ⋀ v’ = F M (t,v) ⋀ w’ = F N (u,w)) 17

18. Consistency for composition (2) ? Enabledness OK: ∃ t. Q M (t,v), ∃ u. Q N (u,w) ⊢ ∃ t,u. (Q M (t,v) ⋀ Q N (u,w)) …(but we lose independent enabledness …) Consistency OK: distribution of ⋀ through ∃ in combined guard, b-a predicate NB: No communication between events 18

19. Fusion composition in Event-B (3) Variables intersect, events intersect ie new NB (1, 2) are special cases of (3) … 19

20. Fusion: “compositional composition” 20

21. 21