Formal Methods for Software Engineering

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

Contents • FSP language features • Sequential processes • Indexing & parameterization & guards • Parallel composition & synchronization • Process labelling & sharing • Relabelling & hiding • Structured error detection • example FMSE, Lecture 5

Sequential operators STOP • Inaction: defining absence of behaviour • Action-prefix: after action a process behaves like B • Choice: after b process behaves like B, after c like C (a -> B) (b -> B|c ->C) FMSE, Lecture 5

nondeterminism one one two three 0 1 2 3 two Example STOP state: incoming actions only process definition EX = (one -> STOP |one -> two -> STOP |two -> three -> STOP). Actions always in lowercase; processes start with uppercase FMSE, Lecture 5

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

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

Indexed Processes 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). • Only local process definitions can be indexed. • Multiple indexing is possible. FMSE, 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. FMSE, 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)). • Parameters can be defined for non-local process definitions only; • They can be seen as constants local to the definition and must always be instantiated; • In parallel applications of the process the parameters can be set to new values FMSE, Lecture 5

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). Guards FMSE, Lecture 5

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

Synchronization • Parallel components synchronize on identical actions; • Synchronization reduces the reachable states and transitions of the product transition system FMSE, Lecture 5

t pay c 0 1 2 3 c coffee tea 1 t pay c coffee pay t 1,0 2,1 0,1 1,1 3,0 0,0 0 tea Synchronization: Example MACHINE=(pay->SELECT), SELECT=(c->coffee->MACHINE |t->tea->MACHINE). CONTROL = (c->t->CONTROL). ||ALTMACH= (CONTROL||MACHINE). FMSE, Lecture 5

Formal Definition Let T=(ST,LT,->T,t) and U=(SU,LU,->U,u) be labelled transitions systems.Then T||U = (STxSU,LTLU,->,(t,u)) with -> defined by - If s1-a->Ts1’ and aLU then (s1,s2)-a->(s1’,s2) - If s2-a->Us2’ and aLT then (s1,s2)-a->(s1,s2’) - If s1-a->Ts1’ and s2-a->Us2’ then (s1,s2)-a->(s1’,s2’) - -> contains no other transitions than implied by rules 1-3 The state space STxSU of T||U is usually restricted to (s1,s2) that can be reached from (t,u) via transitions in ->, i.e. the reachable state space. FMSE, Lecture 5

Alphabets • The alphabet P of a process P is the set of actions L of the corresponding transition system; • In principle, the P is identical to the set of actions in which the process P can engage. FMSE, Lecture 5

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 = {pay,c,t,coffee,tea} ||ALTMACH =(CONTROL||MACHINE). CONTROL2 = (c->CONTROL2). CONTROL2 = {c}. BecauseCONTROL2MACHINE={c)the action t of MACHINEis not constrained in (CONTROL2||MACHINE). However, (CONTROL2||MACHINE) has a transition system identical to that of MACHINE. Why? FMSE, Lecture 5

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

Process Labelling • Often copies of a process must be put in independent parallel composition; • In such cases the alphabets of the different copies must be disjoint; • This 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. FMSE, Lecture 5

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). Labelling: Examples FMSE, Lecture 5

a.acquire a.use acquire b.acquire b.use 0 1 2 0 1 2 0 1 release RESOURCE a:USER b:USER a.release b.release 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). How can we make RESOURCE communicate with both users? FMSE, Lecture 5

a.acquire b.acquire b.use a.use RESOURCE_SHARE 0 1 2 3 4 b.release {a, b}.acquire a.release 0 1 {a,b}::RESOURCE {a, b}.release Process Sharing {a1,…,an}::P replaces every transition s-b->t in P by s-a1.b->t, … , s-an.b->t ||RESOURCE_SHARE = (USERS||{a,b}::RESOURCE). FMSE, Lecture 5

call service reply CLIENT_SERVER 0 1 2 3 continue Relabelling Relabelling changes the names of the actions of a process The general format is: P/{newlabel1/oldlabel1,…, newlabeln/oldlabeln} CLIENT = (call->wait->continue->CLIENT). SERVER = (request->service->reply->SERVER). ||CLIENT_SERVER = (CLIENT || SERVER) /{call/request,reply/wait}. FMSE, Lecture 5

acquire tau USER 0 1 2 release Hiding Hiding relabels observable actions to the internal action tau. Its general format is: P\{a1,…,an}. The complementary operator P@{a1,…,an} hides all actions not in the set {a1,…,an}. USER = (acquire->use->release->USER)\{use}. or USER = (acquire->use->release->USER@{acquire,release). FMSE, Lecture 5

S1 0 tau b tau S2 0 1 2 3 a a 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). FMSE, Lecture 5

Modelling & Analysis Example • A museum has two entrances where visitors enter and leave. • The number of visitors in the museum is counted by increasing (decreasing) a central counter when a visitor enters (leaves). • There should never be more than MAX visitors inside the museum at a time. FMSE, 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). FMSE, 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?? FMSE, Lecture 5

Only visitors that have queued at the same gate can enter or wait. 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<MAX) v[i].enter -> 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). FMSE, 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<MAX) inc -> COUNTER[n+1] ). FMSE, Lecture 5

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 Museum & Visitors // Museum consists of two gates and a shared counter process. ||MUSEUM = (east:GATE || west:GATE || {east,west}::COUNTER). ||OPENMUSEUM = (MVISITORS || MUSEUM). Is this system correct? FMSE, Lecture 5

enter enter TEST -1 0 1 2 leave leave leave enter Analysis We introduce a TEST process: LTSA safety option checks whether ERROR is reachable in TEST in this composition TEST = TEST[0], TEST[i:R] = (leave -> TEST[i-1] |enter -> TEST[i+1]). -1 indicates an ERROR state ||CORRECT = (OPENMUSEUM ||{{east,west}.v[i:V]}::TEST). FMSE, 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.inc 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! FMSE, 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<MAX) v[i].enter -> inc -> release -> ENTER2 |when(n==MAX) release -> v[i].wait -> WAIT2[i])). ||GATE2 = (ENTER2 || LEAVE). FMSE, Lecture 5

Solution 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. LOCK = (lock -> release -> LOCK). ||MUSEUM2 = (east:GATE2 || west:GATE2 || {east,west}::COUNTER || {east,west}::LOCK). FMSE, Lecture 5

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

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

Formal Methods for Software Engineering