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