structured event refinement l.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Structured Event Refinement PowerPoint Presentation
Download Presentation
Structured Event Refinement

Loading in 2 Seconds...

play fullscreen
1 / 53

Structured Event Refinement - PowerPoint PPT Presentation


  • 163 Views
  • Uploaded on

Structured Event Refinement. Michael Butler University of Southampton users.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

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Structured Event Refinement' - aveline


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
structured event refinement

Structured Event Refinement

Michael Butler

University of Southampton

users.ecs.soton.ac.uk/mjb

motivation
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
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
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 b www event b org
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
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
simple file store example
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

sample event traces of file store
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
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

refining the writefile event
Refining the WriteFile event
  • Abstract: WriteFile
  • Refinement:

StartWriteFile

WritePage

EndWriteFile (refines WriteFile)

AbortWriteFile

events of refinement
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

events of refinement12
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

comparing abstract and refined traces
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
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
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 sequencing in JSD

WriteFile

StartWriteFile

WritePage*

EndWriteFile

Sequencing is from left to right

* signifies iteration

adapting the diagrams
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

interleaving of multiple instances
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)

event refinement diagram
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)

hierarchical refinement
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)

event ordering as guarded actions
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

interleaving of multiple instances22
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)

additional multiplicity
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)

some occurrences
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’

partial order interpretation
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

replicated data base
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

refinement by replicated database
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

mutual exclusion
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

event refinement diagram for commit
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?

event refinement diagram for commit30
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?

event refinement diagram for abort
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

locking objects
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
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
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?

another gluing invariant
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
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)

where are we going
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 messaging38
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) ?

ping pong
Ping Pong

Request

Transaction

Response

ping pong40
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)

ping ping
Ping Ping

Req1

Req2

ping ping42
Ping Ping

Transaction

Request1

Request2

Transaction

SndReq1

RcvReq1

SndReq2

RcvReq2

SndReq2 can occur before RcvReq1

SndReq1 is the enabling condition for SndReq2

possible solution
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 pong44
Ping Pong

Transaction(t)

Response(t)

Request(t)

Transaction(t)

SndReq(t)

RcvReq(t)

SndRsp(t)

RcvRsp(t)

ping ping45
Ping Ping

Transaction

Request1

Request2

Transaction

SndReq1

RcvReq1

SndReq2

RcvReq2

SndReq2 can occur before RcvReq1

SndReq1 is the enabling condition for SndReq2

replicated database with explicit guard
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)

architectural role decomposition
Architectural/role decomposition
  • Explicit message/receive allows to separate requester/responder roles
  • We do this by slicing the diagrams
ping pong48
Ping Pong

Request

Transaction

Response

requester behaviour for ping pong
Requester behaviour for Ping Pong

Transaction(t)

Response(t)

Request(t)

SndReq(t)

RcvRsp(t)

responder behaviour for ping pong
Responder behaviour for Ping Pong

Transaction(t)

Response(t)

Request(t)

Transaction(t)

RcvReq(t)

SndRsp(t)

coordinator behaviour for database
Coordinator behaviour for database

Commit(t)

all s

Start(t)

PreCommit(t,s)

Broadcast Start(t)

Recv Pre Commit(t,s)

non coordinator behaviour for database
Non-coordinator behaviour for database

Commit(t,s)

Start(t)

PreCommit(t,s)

[RcvStart(s,t)]

Send Pre Commit(t,s)

RcvStart(s,t)

event refinement diagrams
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