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

Ed Brinksma FMSE, Lecture 5

 Sequential operators

 Inaction: STOP

defining absence of behaviour

 Action-prefix: (a -> B)

after action a process behaves like B

 Choice: (b -> B|c ->C)

after a process behaves like B, after c like C

Ed Brinksma FMSE, Lecture 5

 Example
process STOP state:
definition incoming
actions only
nondeterminism

one

EX = one

(one -> STOP two three

|one -> two -> STOP

|two -> three -> STOP). 0 1 2 3

two
Actions always in
lowercase; processes
start with uppercase

Ed Brinksma FMSE, Lecture 5

 Process Definitions

RECEIVER = (rec -> OUT),

OUT = (out -> ack -> WAIT),
WAIT = (rec -> OUT
|ack -> WAIT).

Local process
definitions

Ed Brinksma FMSE, Lecture 5

 Indexed Actions
range B=0..1
BUFFER = (in[d:D] -> out[d] -> BUFFER).

We can Definition of BUFFER is equivalent with

define
finite BUFFER = (in[0] -> out[0] -> BUFFER
ranges
|in[1] -> out[1] -> BUFFER).
as data
domains Indices are
in.1 postfixed to
in.0 action names
0 1 2 with a dot
out.0 notation
out.1

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

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

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

Ed Brinksma FMSE, 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).

Ed Brinksma FMSE, Lecture 5

 Parallel Composition
in
BUFFER1 = (in -> 0 1
out->BUFFER1). out

get
BUFFER2 = (get ->
0 1
put->BUFFER2).
put

in
||SYSTEM = ( BUFFER1
||BUFFER2). 0,1 1,1

out

get
get

put

put
Parallel composition of processes in
with disjoint actions produces the
product transition system of the 0,0 1,0

component systems. out

Ed Brinksma FMSE, Lecture 5

 Synchronization

 Parallel components synchronize on

identical actions;
 Synchronization reduces the reachable
states and transitions of the product
transition system

Ed Brinksma FMSE, Lecture 5

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

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

pay c coffee pay t

||ALTMACH= (CONTROL||MACHINE).
0,0 1,0 2,1 0,1 1,1 3,0

tea

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

1. If s1-a->Ts1’ and a LTLU then (s1,s2)-a->(s1’,s2)
2. If s2-a->Us2’ and a LTLU then (s1,s2)-a->(s1,s2’)
3. If s1-a->Ts1’ and s2-a->Us2’ then (s1,s2)-a->(s1’,s2’)
4. -> contains no other transitions than implied by rules 1-3

The state space STxSU of T||U is usually restricted to (s 1,s2) that can
be reached from (t,u) via transitions in ->, i.e. the reachable state
space.

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

Ed Brinksma FMSE, Lecture 5

 Alphabet: Example
MACHINE = (pay->SELECT),
MACHINE =
SELECT = (c->coffee->MACHINE
{pay,c,t,coffee,tea}
|t->tea->MACHINE).

CONTROL = (c->t->CONTROL). CONTROL = {c,t}.

ALTMACH =
||ALTMACH =(CONTROL||MACHINE).
{pay,c,t,coffee,tea}

CONTROL2 = (c->CONTROL2). CONTROL2 = {c}.

However,
Because(CONTROL2||MACHINE) has athe
CONTROL2MACHINE={c) transition
action tsystem
of
identical is that
MACHINE to not constrained in (CONTROL2||MACHINE).
of (CONTROL||MACHINE). Why?

Ed Brinksma FMSE, Lecture 5

 Extension
Alphabet 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
CONTROL2 = (c->CONTROL2)+{t}.
(c->CONTROL2).
definition

(CONTROL2||MACHINE) is now equivalent with

SYS = (pay -> c -> coffee -> SYS).

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

Ed Brinksma FMSE, 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).

Ed Brinksma FMSE, 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.acquire a.use b.acquire b.use acquire
0 1 2 0 1 2 0 1
a:USER a.release b:USER b.release RESOURCE release

How can we make RESOURCE communicate with both users?

Ed Brinksma FMSE, Lecture 5

 Process Sharing
{a1,…,an}::P replaces every transition
s-b->t in P by s-a1.b->t, … , s-an.b->t

{a, b}.acquire
||RESOURCE_SHARE =
0 1
(USERS||{a,b}::RESOURCE).
{a,b}::RESOURCE {a, b}.release

a.acquire

b.acquire b.use a.use

RESOURCE_SHARE
0 1 2 3 4

b.release

a.release

Ed Brinksma FMSE, Lecture 5

 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}.
call service reply
CLIENT_SERVER
0 1 2 3

continue

Ed Brinksma FMSE, Lecture 5

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

acquire tau
USER
0 1 2

release

Ed Brinksma FMSE, Lecture 5

 Hiding & Synchronization
As tau does not belong to any process alphabet
it cannot be synchronized upon. Hiding an action
makes removes it from the alphabet, and no longer
constrains its occurrence in the environment.

AB = (a->b->AB). S1

BA = (b->a->BA). 0
AorB = ({a,b}->AorB).
tau b tau
||S1 = (AorB||AB||BA). S2

||T = (AorB||AB)\{a}. 0 1 2 3
||S2 = (T||BA). a a

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

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

Ed Brinksma 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 One more than MAX to

test the admission
||VISITORS = (v[i:V]:VISITOR). protocol

// Allow visitors to use both museum entrances (east,west).

||MVISITORS = {east,west}::VISITORS. Wait at one

entrance and
enter another??

Ed Brinksma FMSE, 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<MAX) v[i].enter -> inc -> ENTER
|when (n==MAX) v[i].wait -> WAIT[i])).

// a visitor can always leave.

Only visitors that have
LEAVE = (v[i:V].leave -> decr -> LEAVE). queued at the same
gate can enter or wait.
||GATE = (ENTER || LEAVE).

Ed Brinksma 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]
).

Ed Brinksma FMSE, 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 ||

Is this system correct?

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

Ed Brinksma FMSE, Lecture 5

 Analysis
We introduce a TEST process:
LTSA safety
TEST = TEST[0],
option checks
TEST[i:R] = (leave -> TEST[i-1]
|enter -> TEST[i+1]).
whether
ERROR is
-1 indicates
reachable in
an ERROR TEST enter enter
TEST inthis
state -1 0 1 2 composition
leave leave leave

enter

||CORRECT = (OPENMUSEUM
||{{east,west}.v[i:V]}::TEST).

Ed Brinksma 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 visitor 2 enters before
east.get.1 the inc for visitor 3 has
east.v.3.enter occurred!
west.get.1
west.v.2.enter
Analysed in: 40ms

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

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

Ed Brinksma FMSE, Lecture 5

 Correctness

Analysing...
Depth 28 -- States: 4564 Transitions: 15864 Memory used: 2683K
No deadlocks/errors
Analysed in: 70ms

Fewer states &

transitions!

Ed Brinksma FMSE, Lecture 5

 Question

Why don’t we need locks on leaving

visitors and COUNTER decrements?
Or do we?

Ed Brinksma FMSE, Lecture 5