Structured Event Refinement

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-Bwww.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 underJ 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, cwhere 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 variables file,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, cwhere f∈ (file \ writing) c∈ CONT then writing := writing{f} wbuf(f) := c end WritePage ≙ anyf, p, dwhere 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, cwhere 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, cwhere 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 Write • Attach the iterator to an arc rather than a node to clarify atomicity • Events are represented by leaves of the tree • Solid line indicates EndWriterefines Write • Dashed line indicates new events refining skip * StartWrite PageWrite EndWrite

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

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

20. Hierarchical refinement Write(f) all(p) StartWrite(f) PageWrite(f,p) EndWrite(f) all(b) StartPage(f,p) ByteWrite(f,p,b) 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 B C

22. Interleaving of multiple instances • 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} A( x:T ) B(x) C(x)

23. Additional multiplicity • 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} A( x:T ) all(y:S) B(x,y) C(x)

24. Some occurrences Events: • B ≙ x↦y ∉ B → B := B ⋃ {x↦y} • C ≙ (∃y ∙ x↦y ∈ B) ∧x∉C • →C := C ⋃ {x} A(x:T) some(y:S) B(x,y) 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 some(x) all(x) B(x) C B(x) C

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 sitespre-commit Global abort if at least one site aborts

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

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

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

31. Event refinement diagram for Abort Abort(t) all sin PreCommit[{t}] some sin SITE Local Abort(t,s) Start(t) Refuse(t,s) Global Abort(t) 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) Commit updates db, but GlobalCommitdoes not update sdb LocalCommitupdates sdb(s) all sin SITE Local Commit(t,s) Global Commit(t) How are db(o) and sdb(s)(o)related in between GlobalCommitand LocalCommit?

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) all s Start(t) PreCommit(t,s) all s Broadcast Start(t) RcvStart(s,t) Send Pre Commit(t,s) Recv Pre Commit(t,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) all s Start(t) PreCommit(t,s) all s Broadcast Start(t) RcvStart(s,t) Send Pre Commit(t,s) Recv Pre Commit(t,s) What is the enabling condition for SendPreCommit(t,s) ?

39. Ping Pong Request Transaction Response

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

41. Ping Ping Req1 Req2

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

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) Response(t) Request(t) Transaction(t) SndReq(t) RcvReq(t) SndRsp(t) RcvRsp(t)

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

46. Replicated database with explicit guard Commit(t) all s Start(t) PreCommit(t,s) all s [ RcvStart(s,t) ] Send Pre Commit(t,s) Broadcast Start(t) RcvStart(s,t) Recv Pre Commit(t,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 Transaction Response

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

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