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

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

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

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

Ed Brinksma FMSE, Lecture 5

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)

Ed Brinksma FMSE, Lecture 5

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

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

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

0 1 2

We can define finite ranges

as data

domains

Indices are postfixed to action names with a dot notation

Ed Brinksma FMSE, Lecture 5

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

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

Ed Brinksma FMSE, Lecture 5

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.

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

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

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

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

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

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

Must be a non-local process

definition

Extension can be

any finite set of actions

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

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

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

Ed Brinksma FMSE, Lecture 5

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

Ed Brinksma FMSE, Lecture 5

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

Ed Brinksma FMSE, Lecture 5

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

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

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

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.

LEAVE = (v[i:V].leave -> decr -> LEAVE).

||GATE = (ENTER || LEAVE).

Only visitors that have queued at the same

gate can enter or wait.

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

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

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

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

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!

Ed Brinksma FMSE, Lecture 5

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

Ed Brinksma FMSE, 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 processesand thus makes sure that at most one of them has access to the COUNTER at a time.

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 leavingvisitors and COUNTER decrements?

Or do we?