1. Structured Event Refinement Michael Butler University of Southampton users.ecs.soton.ac.uk/mjb

2. Motivation In a refinement based approach it is beneficial to model systems abstractly with little architectural structure and large atomic steps – e.g., file transfer, replicated database transaction Refinement and decomposition are used to add structure and then separate elements of the structure Atomicity decomposition – Decomposing large atomic steps to more fine-grained steps Model decomposition – Decomposing refined models to for (semi-)independent refinement of sub-models

3. Theory is not new Standard action system / Event-B refinement is sufficient for atomicity decomposition BUT:Methodological support is weak This talk is about providing stronger methodological support – with the aid of graphical notation

4. Event-B State-transition model (like ASM, B, VDM, Z) – set theory as mathematical language A model consists of variables and events (guarded actions) Refinement – superposition + data refinement – one-to-many event refinement – new events (stuttering steps) Proof method – Refinement proof obligations (POs) generated from models – Automated and interactive provers for POs – Proof feeds back into modelling

5. Rodin Tool for Event-B www.event-b.org Extension of Eclipse IDE (Java based) Open source – managed on sourceforge Repository of modelling elements Rodin Eclipse Builder coordinates: – Well-formedness + type checker – PO generator – Proof manager – Propagation of changes Collection of additional plug-ins – ProB, UML-B, AnimB, ReqMan

6. Refinement proof rule M1 refined by M2 Proof rule using gluing invariant J: Each event M2.E2 (data) refines some M1.E1 under J or (data) refines skip under J Event-B refinement rules are comprehensive but – rules don’t capture common refinement patterns explicitly – sequencing of events is not explicit

7. Simple file store example sets FILE, PAGE, DATA CONT = PAGE ↛ DATA machine filestore variables file, dsk invariant file  FILE ∧ dsk  file  CONT initialisation file := { } || dsk := { } events CreateFile ≙ … WriteFile ≙ // set contents of f to be c anyf, c where f ∈ file c ∈ CONT then dsk(f) := c end ReadFile ≙ // return data in page p of f anyf, p, d! where f ∈ file p ∈ dom(dsk(f)) d! = dsk(f)(p) end

8. Sample event traces of file store  CreateFile.f1, WriteFile.f1.c1, ReadFile.f1.p3.c1(p3), …   CreateFile.f1, CreateFile.f2, WriteFile.f2.c4, WriteFile.f1.c6, …  An (infinitely) many more traces.

9. Refinement of file store Instead of writing entire contents of a file in one atomic step, each page is written separately machinefilestore2 refinesfilestore variablesfile, dsk, writing, wbuf, sdsk invariant writing  file wbuf  writing  CONT sdsk  writing  CONT// shadow disk

10. Refining the WriteFile event Abstract:WriteFile Refinement: StartWriteFile WritePage EndWriteFile(refines WriteFile) AbortWriteFile

11. Events of refinement StartWriteFile ≙ anyf, c where f ∈ (file \ writing) c ∈ CONT then writing := writing  {f} wbuf(f) := c end WritePage ≙ anyf, p, d where f ∈ writing p ↦ d ∈ wbuf(f) p ↦ d ∉ sdsk(f) then sdsk(f) := sdsk(f)  { p ↦ d } end

12. Events of refinement EndWriteFile refines WriteFile ≙ anyf, c where f ∈ writing c = sdsk (f) dom(sdsk(f)) = dom(wbuf(f)) then writing := writing \ { f } wbuf := wbuf \ { f ↦ c } dsk(f) := sdsk(f) sdsk := sdsk\ { f ↦ c } end AbortWriteFile ≙ anyf, c where f ∈ writing c = sdsk (f) then writing := writing \ { f } wbuf := wbuf \ { f ↦ c } sdsk := sdsk \ { f ↦ c } end

13. Comparing abstract and refined traces  CreateFile.f1, CreateFile.f2, WriteFile.f2.c2, WriteFile.f1.c1 …   CreateFile.f1, StartWriteFile.f1.c1, CreateFile.f2, WritePage.f1.p1.c1(p1), StartWriteFile.f2.c2, WritePage.f1.p2.c1(p2), WritePage.f2.p1.c2(p1), WritePage.f2.p2.c2(p2), EndWriteFile.f2.c2, WritePage.f1.p3.c1(p2), EndWriteFile.f1.c1 … 

14. Breaking atomicity Abstract WriteFile is replaced by – new events:StartWriteFile, WritePage, – refining event:EndWriteFile Refined events for different files may interleave Non-interference is dealt with by treating new events as refinements of skip – new events must maintain gluing invariants But: refinement rule does not reflect the connection between then new events and the abstract event

15. Jackson Structure Diagrams Part of Jackson System Development Graphical representation of behaviour We can exploit the hierarchical nature of JSD diagrams to represent event refinement Adapt JSD notation for our needs

16. WriteFile sequencing in JSD WriteFile StartWriteFile WritePage * EndWriteFile Sequencing is from left to right * signifies iteration

17. Adapting the diagrams Attach the iterator to an arc rather than a node to clarify atomicity Events are represented by leaves of the tree Solid line indicates EndWrite refines Write Dashed line indicates new events refining skip Write StartWrite PageWrite EndWrite * *

18. Interleaving of multiple instances Pages may be written after StartWrite has occurred The writing is complete (EndWrite) once all pages have been written Multiple write “processes” for different files may interleave Write(f) StartWrite(f) PageWrite(f,p) EndWrite(f) all(p)

19. Event refinement diagram Diagram represents atomicity refinement explicitly and Diagram specifies sequencing constraints on events Write(f) StartWrite(f) PageWrite(f,p) EndWrite(f) all(p)

20. Hierarchical refinement Write(f) StartWrite(f) PageWrite(f,p) EndWrite(f) all(p) ByteWrite(f,p,b) all(b) StartPage(f,p) EndPage(f,p)

21. Event ordering as guarded actions Events: B ≙ ¬B  B := true C ≙ B ∧ ¬C  C := true variable B is true when B event has occurred A A C C B B

22. Interleaving of multiple instances A( x:T ) B(x) C(x) variable B is a subset of T variable C is a subset of B Events: B ≙ x ∉ B  B := B ⋃ {x} C ≙ x ∈ B ∧ x ∉ C  C := C ⋃ {x}

23. Additional multiplicity A( x:T ) B(x,y) C(x) all(y:S) variable B is a set of pairs T × S variable C is a set of T Events: B ≙ x ↦ y ∉ B  B := B ⋃ {x ↦ y} C ≙ ( ∀ y ∙ x ↦ y ∈ B) ∧ x ∉ C  C := C ⋃ {x}

24. Some occurrences A(x:T) B(x,y) C(x) some(y:S) Events: B ≙ x ↦ y ∉ B  B := B ⋃ {x ↦ y} C ≙ ( ∃ y ∙ x ↦ y ∈ B) ∧ x ∉ C  C := C ⋃ {x} C(x) can occur provided B(x,y) occurs for at least one y B(x,y’) may occur after C(x) for other y’

25. Partial Order Interpretation Ordering of events is partial – no ordering between each B(x) – B(x) do not depend on C – the only constraint is on C A A B(x) C C all(x) A A B(x) C C some(x)

26. Replicated data base Abstract model db  object  DATA Commit = /* update a set of objects os */ anyos, upd where os  object ∧ update  ( os  DATA )  ( os  DATA ) then db := db <+ update( os ⊲ db ) end

27. Refinement by replicated database sdb  site  (object  DATA) Update is by two phase commit: PreCommit followed by Commit Global commit if all sites pre-commit Global abort if at least one site aborts

28. Mutual Exclusion Update(t) Commit(t) Abort(t) Update transaction will commit or abort but not both At abstract level, update transaction is a choice of 2 atomic events:

29. Event refinement diagram for Commit Commit(t) Start(t) PreCommit(t,s) Global Commit(t) Local Commit(t,s) all s in SITE Which event refines the abstract Commit?

30. Event refinement diagram for Commit Commit(t) Start(t) PreCommit(t,s) Global Commit(t) Local Commit(t,s) all s in SITE Decision to proceed is made by GlobalCommit?

31. Abort(t) Start(t) Refuse(t,s) Global Abort(t) Local Abort(t,s) all s in PreCommit[{t}] some s in SITE Event refinement diagram for Abort Protocol aborts transaction if some site aborts

32. Locking objects PreCommit(t,s) : locks all objects for transaction t at site s LocalCommit(t,s) LocalAbort(t,s) : release all objects for transaction t at site s

33. Read transactions Abstract read: values read are from single abstract database db Concrete read: (provided objects are not locked) values read are from copy of database at a site sdb(s) Key gluing invariant: ∀ s, o · o ∉ dom(lock(s)) ⇒ (sdb(s))(o) = db(o) This invariant doesn’t always hold

34. Global and local commit not synchronised Commit(t) Global Commit(t) Local Commit(t,s) all s in SITE How are db(o) and sdb(s)(o) related in between GlobalCommit and LocalCommit? Commit updates db, but GlobalCommit does not update sdb LocalCommit updates sdb(s)

35. Another gluing invariant ∀ t,s,o · t ∈ GlobalCommit ∧ t ↦ s ∉ LocalCommit ∧ t ↦ o ∈ tos ⇒ db(o) = ( (tupd(t)) (tos[{t}] ◁ sdb(s)) ) (o) The value of the object at a site is found by applying the update associated with the transaction to the database at the local site

36. Introducing messaging Commit(t) Start(t) PreCommit(t,s) Broadcast Start(t) RcvStart(s,t) Send Pre Commit(t,s) Recv Pre Commit(t,s) all s

37. Where are we going? Start with system-level model of transaction, independent of architecture/roles Introduced stages of a transaction Next we will introduce explicit message send/receive – this will allow us to separate later the requester/responder roles

38. Introducing messaging Commit(t) Start(t) PreCommit(t,s) Broadcast Start(t) RcvStart(s,t) Send Pre Commit(t,s) Recv Pre Commit(t,s) all s What is the enabling condition for SendPreCommit(t,s) ?

39. Ping Pong Request Response Transaction

40. Ping Pong Transaction(t) Request(t) Response(t) SndReq(t) RcvReq(t) SndRsp(t) RcvRsp(t) Clearly Transaction(t) is enabled by RcvReq(t) Transaction(t)

41. Ping Req1 Req2

42. Ping Transaction Request1 Request2 SndReq1 RcvReq1 SndReq2 RcvReq2 SndReq2 can occur before RcvReq1 SndReq1 is the enabling condition for SndReq2 Transaction

43. Possible solution Ordering constraints between cousins is only preserved by solid lines, not by dashed lines Additional ordering can be inserted explicitly as guards if required

44. Ping Pong Transaction(t) Request(t) Response(t) SndReq(t) RcvReq(t) SndRsp(t) RcvRsp(t) Transaction(t)

45. Ping Transaction Request1 Request2 SndReq1 RcvReq1 SndReq2 RcvReq2 SndReq2 can occur before RcvReq1 SndReq1 is the enabling condition for SndReq2 Transaction

46. Replicated database with explicit guard Commit(t) Start(t) PreCommit(t,s) Broadcast Start(t) RcvStart(s,t) [ RcvStart(s,t) ] Send Pre Commit(t,s) [ RcvStart(s,t) ] Send Pre Commit(t,s) Recv Pre Commit(t,s) all s

47. Architectural/role decomposition Explicit message/receive allows to separate requester/responder roles We do this by slicing the diagrams

48. Ping Pong Request Response Transaction

49. Requester behaviour for Ping Pong Transaction(t) Request(t) Response(t) SndReq(t) RcvRsp(t)

50. Responder behaviour for Ping Pong Transaction(t) Request(t) Response(t) RcvReq(t) SndRsp(t) Transaction(t)

51. Coordinator behaviour for database Commit(t) Start(t) PreCommit(t,s) Broadcast Start(t) Recv Pre Commit(t,s) all s

52. Non-coordinator behaviour for database Commit(t,s) Start(t) PreCommit(t,s) RcvStart(s,t) [RcvStart(s,t)] Send Pre Commit(t,s) [RcvStart(s,t)] Send Pre Commit(t,s)

53. Event refinement diagrams Explicit representation of atomicity decomposition Diagrams may be refined to arbitrary depth in successive steps Ordering of events made explicit Partial event ordering means different behavioural views may be separated Leaves represent both event and state explicitly Built-in operators: sequencing and replication Support architectural/role decomposition