Upload
dale-holt
View
219
Download
0
Embed Size (px)
Citation preview
Structured Event Refinement
Michael ButlerUniversity of Southamptonusers.ecs.soton.ac.uk/mjb
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
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
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
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
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
Simple file store examplesets FILE, PAGE, DATA
CONT = PAGE ↛ DATA
machine filestorevariables file, dskinvariant file FILE ∧ dsk file CONT
initialisation file := { } || dsk := { }
events
CreateFile ≙ …
WriteFile ≙ // set contents of f to be cany f, c where
f ∈ file c ∈ CONT
then dsk(f) := c
end
ReadFile ≙ // return data in page p of fany f, p, d! where
f ∈ file p ∈ dom(dsk(f)) d! = dsk(f)(p)
end
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.
Refinement of file store
• Instead of writing entire contents of a file in one atomic step, each page is written separately
machine filestore2refines filestorevariables file, dsk, writing, wbuf, sdsk
invariant
writing filewbuf writing CONTsdsk writing CONT // shadow disk
Refining the WriteFile event
• Abstract: WriteFile
• Refinement:StartWriteFileWritePageEndWriteFile (refines WriteFile)AbortWriteFile
Events of refinementStartWriteFile ≙
any f, c wheref ∈ (file \
writing)c ∈ CONT
thenwriting :=
writing {f} wbuf(f) := c
end
WritePage ≙any f, p, d where
f ∈ writing p ↦ d ∈ wbuf(f) p ↦ d ∉ sdsk(f)
then sdsk(f) := sdsk(f) { p ↦ d }
end
Events of refinementEndWriteFile refines WriteFile ≙
any f, 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 ≙ any f, c where
f ∈ writing c = sdsk(f)
then writing := writing \ { f }
wbuf := wbuf \ { f ↦ c } sdsk := sdsk \ { f ↦ c }end
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
…
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
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
WriteFile sequencing in JSD
WriteFile
StartWriteFile WritePage * EndWriteFile
Sequencing is from left to right
* signifies iteration
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
*
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)
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)
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)
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
CB
Interleaving of multiple instances
A( x:T )
B(x) C(x)
variable B is a subset of Tvariable C is a subset of B
Events:
B ≙ x B ∉ → B := B {x}⋃
C ≙ x B x C ∈ ∧ ∉→ C := C {x}⋃
Additional multiplicity
A( x:T )
B(x,y) C(x)
all(y:S)
variable B is a set of pairs T × Svariable 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}⋃
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’
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
B(x) C
all(x)
A
B(x) C
some(x)
Replicated data base• Abstract model
db object DATA
Commit = /* update a set of objects os */any os, updwhere
os object ∧update ( os DATA ) ( os DATA )
then db := db <+ update( os ⊲ db ) end
Refinement by replicated database
sdb site (object DATA)
Update is by two phase commit:PreCommit followed by Commit
Global commit if all sites pre-commitGlobal abort if at least one site aborts
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:
Event refinement diagram for Commit
Commit(t)
Start(t) PreCommit(t,s) Global Commit(t)
Local Commit(t,s)
all s in SITE all s in SITE
Which event refines the abstract Commit?
Event refinement diagram for Commit
Commit(t)
Start(t) PreCommit(t,s) Global Commit(t)
Local Commit(t,s)
all s in SITE all s in SITE
Decision to proceed is made by GlobalCommit?
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
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
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
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)
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
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
all s
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
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
all s
What is the enabling condition for SendPreCommit(t,s) ?
Ping Pong
Request
ResponseTransaction
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)
Ping Ping
Req1
Req2
Ping Ping
Transaction
Request1 Request2
SndReq1 RcvReq1 SndReq2 RcvReq2
SndReq2 can occur before RcvReq1SndReq1 is the enabling condition for SndReq2
Transaction
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
Ping Pong
Transaction(t)
Request(t) Response(t)
SndReq(t) RcvReq(t) SndRsp(t) RcvRsp(t)
Transaction(t)
Ping Ping
Transaction
Request1 Request2
SndReq1 RcvReq1 SndReq2 RcvReq2
SndReq2 can occur before RcvReq1SndReq1 is the enabling condition for SndReq2
Transaction
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)
Recv Pre Commit(t,s)
all s
all s
Architectural/role decomposition
• Explicit message/receive allows to separate requester/responder roles
• We do this by slicing the diagrams
Ping Pong
Request
ResponseTransaction
Requester behaviour for Ping Pong
Transaction(t)
Request(t) Response(t)
SndReq(t) RcvRsp(t)
Responder behaviour for Ping Pong
Transaction(t)
Request(t) Response(t)
RcvReq(t) SndRsp(t)
Transaction(t)
Coordinator behaviour for database
Commit(t)
Start(t) PreCommit(t,s)
Broadcast Start(t)
Recv Pre Commit(t,s)
all s
Non-coordinator behaviour for database
Commit(t,s)
Start(t) PreCommit(t,s)
RcvStart(s,t) [RcvStart(s,t)]Send Pre
Commit(t,s)
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