Formal Methods for Software Engineering

Formal Methods for

Software Engineering

Lecture 5, Part II: FSP

Ed Brinksma FMSE, Lecture 5

Contents

FSP language features Sequential processes Indexing & parameterization & guards

Parallel composition & synchronization

Process labelling & sharing Relabelling & hiding

Structured error detection example


Sequential operators

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

STOP

(a -> B)

(b -> B|c ->C)


Example

EX =

(one -> STOP

|one -> two -> STOP

|two -> three -> STOP).

one

one

two three

two

0 1 2 3

nondeterminism

Actions always in lowercase; processes start with uppercase

STOP state: incoming

actions only

process definiti

on


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


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

0 1 2

We can define finite ranges

as data

domains

Indices are postfixed to action names with a dot notation


Indexed Processes

Only local process definitions can be indexed. 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).


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 differentvalues of the constants.


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


Guards

Guards are used to make control flow dependupon 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).


Parallel Composition

BUFFER1 = (in ->

out->BUFFER1).

BUFFER2 = (get ->

put->BUFFER2).

in

0 1

out

get

put

0 1

||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.


Synchronization

Parallel components synchronize on identical actions;

Synchronization reduces the reachable states and transitions of the product transition system


Synchronization: Example

MACHINE=(pay->SELECT),

SELECT=(c->coffee->MACHINE

|t->tea->MACHINE).

CONTROL = (c->t->CONTROL).

||ALTMACH= (CONTROL||MACHINE).

pay ct

coffeetea

0 1 2 3

c

t

10

pay c coffee pay t

tea

0,0 1,0 2,1 0,1 1,1 3,0


Formal Definition

Let T=(ST,LT,->T,t) and U=(SU,LU,->U,u) be labelled transitions systems.Then

T||U = (STxSU,LTLU,->,(t,u))

with -> defined by - If s1-a->Ts1’ and aLU then (s1,s2)-a->(s1’,s2)

- If s2-a->Us2’ and aLT 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.


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.


However, (CONTROL2||MACHINE) has a transition systemidentical to that of MACHINE. Why?

Because CONTROL2MACHINE={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}.


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 withSYS = (pay -> c -> coffee -> SYS).

Must be a non-local process

definition

Extension can be

any finite set of actions


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.


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).


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

0 1 2b:USER

b.acquireb.use

b.release

0 1 2RESOURCE

acquire

release0 1

How can we make RESOURCE communicate with both users?


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).{a,b}::RESOURCE

{a, b}.acquire

{a, b}.release

0 1

RESOURCE_SHARE

a.acquire

b.acquire b.use

b.release

a.use

a.release

0 1 2 3 4


RelabellingRelabelling changes the names of the actions of a processThe 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}.

CLIENT_SERVERcall service reply

continue

0 1 2 3


Hiding

Hiding relabels observable actions to the internalaction 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}. orUSER = (acquire->use->release->USER@{acquire,release).

USERacquire tau

release

0 1 2


Hiding & Synchronization

As tau does not belong to any process' alphabetit cannot be synchronized upon. Hiding an actionremoves it from the alphabet, and no longerconstrains 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 tau b tau

a a

0 1 2 3


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.


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).


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


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).

Only visitors that have queued at the same

gate can enter or wait.


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]

).


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?


AnalysisWe 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

-1 0 1 2

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


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!


Solution

We make sure that between reading the COUNTER andincrementing 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).


Solution

LOCK = (lock -> release -> LOCK).

||MUSEUM2 = ( east:GATE2

|| west:GATE2

|| {east,west}::COUNTER

|| {east,west}::LOCK).

The process LOCK is shared by the GATE processesand thus makes sure that at most one of them has access to the COUNTER at a time.


Correctness

Analysing...

Depth 28 -- States: 4564 Transitions: 15864 Memory used: 2683K

No deadlocks/errors

Analysed in: 70ms

Fewer states & transitions!


Question

Why don’t we need locks on leavingvisitors and COUNTER decrements?

Or do we?

Formal Methods for Software Engineering

Documents

Transcript of Formal Methods for Software Engineering