Transcript STOCHASTI PROCESS ALGEBRA: linking process descriptions

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
process
definition
Example
STOP state:
incoming
actions only
nondeterminism
one
EX =
(one -> STOP
|one -> two -> STOP
|two -> three -> STOP).
one
two
0
three
1
2
3
two
Actions always
in lowercase;
processes start
with uppercase
Ed Brinksma
FMSE, Lecture 5
Process Definitions
RECEIVER
OUT
WAIT
=
=
=
(rec
(out
(rec
|ack
->
->
->
->
OUT),
ack -> WAIT),
OUT
WAIT).
Local process
definitions
Ed Brinksma
FMSE, Lecture 5
Indexed Actions
range B=0..1
BUFFER = (in[d:D] -> out[d] -> BUFFER).
We can
define
finite
ranges
as data
domains
Definition of BUFFER is equivalent with
BUFFER = (in[0] -> out[0] -> BUFFER
|in[1] -> out[1] -> BUFFER).
in.1
in.0
0
1
2
out.0
out.1
Ed Brinksma
FMSE, Lecture 5
Indices are
postfixed to
action names
with a dot
notation
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]
(a[1]
|a[2]
|a[3]
Ed Brinksma
->
->
->
->
b
c
c
c
->
->
->
->
STOP
P
P
P).
FMSE, Lecture 5
Parallel Composition
in
BUFFER1 = (in ->
out->BUFFER1).
0
1
out
get
BUFFER2 = (get ->
put->BUFFER2).
0
1
put
||SYSTEM = ( BUFFER1
||BUFFER2).
in
0,1
1,1
Ed Brinksma
FMSE, Lecture 5
put
get
put
Parallel composition of processes
with disjoint actions produces the
product transition system of the
component systems.
get
out
in
0,0
1,0
out
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
MACHINE=(pay->SELECT),
SELECT=(c->coffee->MACHINE
|t->tea->MACHINE).
c
0
1
2
3
coffee
tea
c
CONTROL = (c->t->CONTROL).
1
0
t
pay
||ALTMACH= (CONTROL||MACHINE).
0,0
c
1,0
coffee
2,1
0,1
tea
Ed Brinksma
FMSE, Lecture 5
pay
t
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,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 (s1,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),
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}.
However,
Because(CONTROL2||MACHINE)
CONTROL2MACHINE={c)
has athe
transition
action tsystem
of
identical
MACHINE to
is that
not constrained
of (CONTROL||MACHINE).
in (CONTROL2||MACHINE).
Why?
Ed Brinksma
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)+{t}.
(c->CONTROL2).
(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:
Or, even shorter:
Or, parameterized:
Ed Brinksma
||SWITCHES=(forall[i:1..3] s[i]:SWITCH).
||SWITCHES=(s[i:1..3]:SWITCH).
||SWITCHES(N=3)=(s[i:1..N]:SWITCH).
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
0
a:USER
a.use
1
a.release
b.acquire b.use
2
0
b:USER
1
b.release
acquire
2
0
1
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 =
(USERS||{a,b}::RESOURCE).
0
{a,b}::RESOURCE {a, b}.release
a.acquire
b.acquire
RESOURCE_SHARE
0
b.use
1
a.use
2
b.release
a.release
Ed Brinksma
FMSE, Lecture 5
3
4
1
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
CLIENT_SERVER
0
service
1
2
continue
Ed Brinksma
reply
FMSE, Lecture 5
3
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
USER
0
tau
1
release
Ed Brinksma
FMSE, Lecture 5
2
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).
BA = (b->a->BA).
AorB = ({a,b}->AorB).
||S1 = (AorB||AB||BA).
||T = (AorB||AB)\{a}.
||S2 = (T||BA).
Ed Brinksma
S1
0
tau
S2
FMSE, Lecture 5
0
b
tau
1
2
a
a
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.
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
||VISITORS = (v[i:V]:VISITOR).
One more than MAX to
test the admission
protocol
// Allow visitors to use both museum entrances (east,west).
||MVISITORS = {east,west}::VISITORS.
Ed Brinksma
FMSE, Lecture 5
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).
Ed Brinksma
FMSE, Lecture 5
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]
).
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 ||
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?
Ed Brinksma
FMSE, Lecture 5
Analysis
We introduce a TEST process:
TEST = TEST[0],
TEST[i:R] = (leave -> TEST[i-1]
|enter -> TEST[i+1]).
-1 indicates
an ERROR
state
enter
TEST
-1
0
leave
enter
1
leave
2
leave
LTSA safety
option checks
whether
ERROR is
reachable in
TEST inthis
composition
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
visitor 2 enters before
east.v.3.queue
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 = (
||
||
||
Ed Brinksma
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!
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