Presentation is loading. Please wait.

Presentation is loading. Please wait.

Formal Methods for Software Engineering Lecture 5, Part II: FSP.

Similar presentations

Presentation on theme: "Formal Methods for Software Engineering Lecture 5, Part II: FSP."— Presentation transcript:

1 Formal Methods for Software Engineering Lecture 5, Part II: FSP

2 Ed BrinksmaFMSE, Lecture 5 Contents lFSP language features nSequential processes nIndexing & parameterization & guards nParallel composition & synchronization nProcess labelling & sharing nRelabelling & hiding lStructured error detection nexample

3 Ed BrinksmaFMSE, Lecture 5 Sequential operators lInaction: defining absence of behaviour lAction-prefix: after action a process behaves like B lChoice: after b process behaves like B, after c like C STOP (a -> B) (b -> B|c ->C)

4 Ed BrinksmaFMSE, Lecture 5 Example EX = (one -> STOP |one -> two -> STOP |two -> three -> STOP). one twothree two 0123 nondeterminism Actions always in lowercase; processes start with uppercase STOP state: incoming actions only process definition

5 Ed BrinksmaFMSE, Lecture 5 Process Definitions RECEIVER = (rec -> OUT), OUT = (out -> ack -> WAIT), WAIT = (rec -> OUT |ack -> WAIT). OUT = (out -> ack -> WAIT), WAIT = (rec -> OUT |ack -> WAIT). Local process definitions

6 Ed BrinksmaFMSE, Lecture 5 Indexed Actions range B=0..1 BUFFER = (in[b:B] -> out[b] -> BUFFER). BUFFER = (in[0] -> out[0] -> BUFFER |in[1] -> out[1] -> BUFFER). Definition of BUFFER is equivalent with in.0 in.1 out.0 out.1 012 We can define finite ranges as data domains Indices are postfixed to action names with a dot notation

7 Ed BrinksmaFMSE, Lecture 5 Indexed Processes u Only local process definitions can be indexed. u Multiple indexing is possible. range D=1..2 range B=0..1 BUFFER = (in[b:B][d:D] -> FULL[b][d]), FULL[b:B][d:D] = (out[b][d] -> BUFFER).

8 Ed BrinksmaFMSE, Lecture 5 Constants & Parameters const N=3 range D=1..N range B=0..1 BUFFER = (in[b:B][d:D] -> FULL[b][d]), FULL[b:B][d:D] = (out[b][d] -> BUFFER). Constants can be seen as global specification parameters; they make it easier to produce specifications for different values of the constants.

9 Ed BrinksmaFMSE, Lecture 5 Constants & Parameters range B=0..1 BUFFER(N=3) = (in[d:1..N] -> FULL[d]), FULL[d:1..N] = (out[d] -> BUFFER). ||MEDIUM = (BUFFER(2)||BUFFER(2)). lParameters can be defined for non-local process definitions only; lThey can be seen as constants local to the definition and must always be instantiated; lIn parallel applications of the process the parameters can be set to new values

10 Ed BrinksmaFMSE, Lecture 5 Guards Guards are used to make control flow depend upon value expressions: P = (a[i:0..3] -> (when (i==0) b -> STOP |when (i!=0) c -> P)). This is equivalent to: P = (a[0] -> b -> STOP (a[1] -> c -> P |a[2] -> c -> P |a[3] -> c -> P).

11 Ed BrinksmaFMSE, Lecture 5 Parallel Composition BUFFER1 = (in -> out->BUFFER1). BUFFER2 = (get -> put->BUFFER2). in 01 out get put 01 ||SYSTEM = ( BUFFER1 ||BUFFER2). in out in out get put get put 1,1 1,0 0,1 0,0 Parallel composition of processes with disjoint actions produces the product transition system of the component systems.

12 Ed BrinksmaFMSE, Lecture 5 Synchronization lParallel components synchronize on identical actions; lSynchronization reduces the reachable states and transitions of the product transition system

13 Ed BrinksmaFMSE, Lecture 5 Synchronization: Example MACHINE=(pay->SELECT), SELECT=(c->coffee->MACHINE |t->tea->MACHINE). CONTROL = (c->t->CONTROL). ||ALTMACH= (CONTROL||MACHINE). payc t coffee tea 0123 c t 1 0 payccoffeepayt tea 0,0 1,02,10,11,13,0

14 Ed BrinksmaFMSE, Lecture 5 Formal Definition Let T=(S T,L T,-> T,t) and U=(S U,L U,-> U,u) be labelled transitions systems.Then T||U = (S T xS U,L T  L U,->,(t,u)) with -> defined by - If s 1 -a-> T s 1 ’ and a  L U then (s 1,s 2 )-a->(s 1 ’,s 2 ) - If s 2 -a-> U s 2 ’ and a  L T then (s 1,s 2 )-a->(s 1,s 2 ’) - If s 1 -a-> T s 1 ’ and s 2 -a-> U s 2 ’ then (s 1,s 2 )-a->(s 1 ’,s 2 ’) - -> contains no other transitions than implied by rules 1-3 The state space S T xS U of T||U is usually restricted to (s 1,s 2 ) that can be reached from (t,u) via transitions in ->, i.e. the reachable state space.

15 Ed BrinksmaFMSE, Lecture 5 Alphabets lThe alphabet  P of a process P is the set of actions L of the corresponding transition system; lIn principle, the  P is identical to the set of actions in which the process P can engage.

16 Ed BrinksmaFMSE, Lecture 5 However, (CONTROL2||MACHINE) has a transition system identical to that of MACHINE. Why? Because  CONTROL2  MACHINE={c) the action t of MACHINE is not constrained in (CONTROL2||MACHINE). Alphabet: Example MACHINE = (pay->SELECT), SELECT = (c->coffee->MACHINE |t->tea->MACHINE).  MACHINE = {pay,c,t,coffee,tea} CONTROL = (c->t->CONTROL).  CONTROL = {c,t}. ||ALTMACH =(CONTROL||MACHINE).  ALTMACH = {pay,c,t,coffee,tea} CONTROL2 = (c->CONTROL2).  CONTROL2 = {c}.

17 Ed BrinksmaFMSE, Lecture 5 Alphabet Extension We can extend the alphabet of CONTROL2 so that it constrains both c and t actions. CONTROL2 = (c->CONTROL2).CONTROL2 = (c->CONTROL2)+{t}. (CONTROL2||MACHINE) is now equivalent with SYS = (pay -> c -> coffee -> SYS). Must be a non-local process definition Extension can be any finite set of actions

18 Ed BrinksmaFMSE, Lecture 5 Process Labelling lOften copies of a process must be put in independent parallel composition; lIn such cases the alphabets of the different copies must be disjoint; lThis can be done by prefixing the actions of each copy with a new label a:P prefixes each action name in  P with label a.

19 Ed BrinksmaFMSE, Lecture 5 Labelling: Examples Consider the process: SWITCH=(on->off->SWITCH). We can define a system of three switches by: ||SWITCHES=( s[1]:SWITCH || s[2]:SWITCH || s[3]:SWITCH). Or, equivalently: ||SWITCHES=(forall[i:1..3] s[i]:SWITCH). Or, even shorter: ||SWITCHES=(s[i:1..3]:SWITCH). Or, parameterized: ||SWITCHES(N=3)=(s[i:1..N]:SWITCH).

20 Ed BrinksmaFMSE, Lecture 5 Process Sharing Suppose we have two user processes that share a resource: USER = (acquire -> use -> release -> USER). ||USERS = (a:USER || b:USER). RESOURCE = (acquire -> release -> RESOURCE). a:USER a.acquirea.use a.release 012 b:USER b.acquireb.use b.release 012 RESOURCE acquire release 01 How can we make RESOURCE communicate with both users?

21 Ed BrinksmaFMSE, Lecture 5 Process Sharing {a 1,…,a n }::P replaces every transition s-b->t in P by s-a 1.b->t, …, s-a n.b->t ||RESOURCE_SHARE = (USERS||{a,b}::RESOURCE). {a,b}::RESOURCE {a, b}.acquire {a, b}.release 01 RESOURCE_SHARE a.acquire b.acquireb.use b.release a.use a.release 01234

22 Ed BrinksmaFMSE, Lecture 5 Relabelling Relabelling changes the names of the actions of a process The general format is: P/{newlabel 1 /oldlabel 1,…, newlabel n /oldlabel n } CLIENT = (call->wait->continue->CLIENT). SERVER = (request->service->reply->SERVER). ||CLIENT_SERVER = (CLIENT || SERVER) /{call/request,reply/wait}. CLIENT_SERVER callservicereply continue 0123

23 Ed BrinksmaFMSE, Lecture 5 Hiding Hiding relabels observable actions to the internal action tau. Its general format is: P\{a 1,…,a n }. The complementary operator P@{a 1,…,a n } hides all actions not in the set {a 1,…,a n }. USER = (acquire->use->release->USER)\{use}. or USER = (acquire->use->release->USER@{acquire,release). USER acquiretau release 012

24 Ed BrinksmaFMSE, Lecture 5 Hiding & Synchronization As tau does not belong to any process' alphabet it cannot be synchronized upon. Hiding an action removes it from the alphabet, and no longer constrains its occurrence in the environment. AB = (a->b->AB). BA = (b->a->BA). AorB = ({a,b}->AorB). ||S1 = (AorB||AB||BA). ||T = (AorB||AB)\{a}. ||S2 = (T||BA). S1 0 S2 taub aa 0123

25 Ed BrinksmaFMSE, Lecture 5 Modelling & Analysis Example lA museum has two entrances where visitors enter and leave. lThe number of visitors in the museum is counted by increasing (decreasing) a central counter when a visitor enters (leaves). lThere should never be more than MAX visitors inside the museum at a time.

26 Ed BrinksmaFMSE, Lecture 5 Modelling: a Visitor // Visitors queue at the museum and then enter // or wait their turn; after entering they leave // at some future time. VISITOR = (queue -> WAIT), WAIT = (enter -> leave -> VISITOR |wait -> WAIT).

27 Ed BrinksmaFMSE, Lecture 5 Modelling: Concurrent Visitors // We create a set of concurrent visitors by prefixing // the generic actions with an identifying prefix v[i]. range V=1..MAX+1 ||VISITORS = (v[i:V]:VISITOR). // Allow visitors to use both museum entrances (east,west). ||MVISITORS = {east,west}::VISITORS. One more than MAX to test the admission protocol Wait at one entrance and enter another??

28 Ed BrinksmaFMSE, Lecture 5 Modelling: a Museum Gate ENTER = (v[i:V].queue -> WAIT[i]), // when visitor v[i] has queued get counter number; when less // than MAX admit visitor and inc counter, else let him wait. WAIT[i:V] = (get[n:R] -> (when (n inc -> ENTER |when (n==MAX) v[i].wait -> WAIT[i])). // a visitor can always leave. LEAVE = (v[i:V].leave -> decr -> LEAVE). ||GATE = (ENTER || LEAVE). Only visitors that have queued at the same gate can enter or wait.

29 Ed BrinksmaFMSE, Lecture 5 Modelling: a Counter range R=0..MAX COUNTER = COUNTER[0], COUNTER[n:R] = (get[n] -> COUNTER[n] |when (n>0) decr -> COUNTER[n-1] |when (n COUNTER[n+1] ).

30 Ed BrinksmaFMSE, Lecture 5 Museum & Visitors // Museum consists of two gates and a shared counter process. ||MUSEUM = (east:GATE || west:GATE || {east,west}::COUNTER). ||OPENMUSEUM = (MVISITORS || MUSEUM). Composition: (for MAX=2) OPENMUSEUM = MVISITORS.{east,west}::VISITORS.v.1:VISITOR || MVISITORS.{east,west}::VISITORS.v.2:VISITOR || MVISITORS.{east,west}::VISITORS.v.3:VISITOR || MUSEUM.east:GATE.ENTER || MUSEUM.east:GATE.LEAVE || MUSEUM.west:GATE.ENTER || MUSEUM.west:GATE.LEAVE || MUSEUM.{east,west}::COUNTER State Space: 3 * 3 * 3 * 19 * 4 * 19 * 4 * 3 = 2 ** 22 Composing... Depth 794 -- States: 10000 Transitions: 36917 Memory used: 4495K -- States: 10975 Transitions: 40758 Memory used: 5790K Composed in 441ms Is this system correct?

31 Ed BrinksmaFMSE, Lecture 5 Analysis We introduce a TEST process: TEST = TEST[0], TEST[i:R] = (leave -> TEST[i-1] |enter -> TEST[i+1]). TEST leave enter leave enter leave enter 012 ||CORRECT = (OPENMUSEUM ||{{east,west}.v[i:V]}::TEST). -1 indicates an ERROR state LTSA safety option checks whether ERROR is reachable in TEST in this composition

32 Ed BrinksmaFMSE, Lecture 5 Analysis Trace to property violation in {east.v.1,east.v.2,east.v.3,west.v.1,west.v.2,west.v.3}::TEST: east.v.1.queue west.v.2.queue east.get.0 east.v.1.enter east.v.3.queue east.get.1 east.v.3.enter west.get.1 west.v.2.enter Analysed in: 40ms visitor 2 enters before the inc for visitor 3 has occurred!

33 Ed BrinksmaFMSE, Lecture 5 Solution We make sure that between reading the COUNTER and incrementing by a GATE, the other GATE cannot access it. ENTER2 = (v[i:V].queue -> WAIT2[i]), WAIT2[i:V] = (lock -> get[n:R] -> (when(n inc -> release -> ENTER2 |when(n==MAX) release -> v[i].wait -> WAIT2[i])). ||GATE2 = (ENTER2 || LEAVE).

34 Ed BrinksmaFMSE, Lecture 5 Solution LOCK = (lock -> release -> LOCK). ||MUSEUM2 = ( east:GATE2 || west:GATE2 || {east,west}::COUNTER || {east,west}::LOCK). The process LOCK is shared by the GATE processes and thus makes sure that at most one of them has access to the COUNTER at a time.

35 Ed BrinksmaFMSE, Lecture 5 Correctness Analysing... Depth 28 -- States: 4564 Transitions: 15864 Memory used: 2683K No deadlocks/errors Analysed in: 70ms Fewer states & transitions!

36 Ed BrinksmaFMSE, Lecture 5 Question Why don’t we need locks on leaving visitors and COUNTER decrements? Or do we?

Download ppt "Formal Methods for Software Engineering Lecture 5, Part II: FSP."

Similar presentations

Ads by Google