Formal Methods for Software Engineering
-
Upload
sybill-miranda -
Category
Documents
-
view
35 -
download
0
description
Transcript of Formal Methods for Software Engineering
![Page 1: Formal Methods for Software Engineering](https://reader035.fdocuments.net/reader035/viewer/2022062721/56813815550346895d9fc9ad/html5/thumbnails/1.jpg)
Formal Methods for
Software Engineering
Lecture 5, Part II: FSP
![Page 2: Formal Methods for Software Engineering](https://reader035.fdocuments.net/reader035/viewer/2022062721/56813815550346895d9fc9ad/html5/thumbnails/2.jpg)
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
![Page 3: Formal Methods for Software Engineering](https://reader035.fdocuments.net/reader035/viewer/2022062721/56813815550346895d9fc9ad/html5/thumbnails/3.jpg)
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)
![Page 4: Formal Methods for Software Engineering](https://reader035.fdocuments.net/reader035/viewer/2022062721/56813815550346895d9fc9ad/html5/thumbnails/4.jpg)
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
![Page 5: Formal Methods for Software Engineering](https://reader035.fdocuments.net/reader035/viewer/2022062721/56813815550346895d9fc9ad/html5/thumbnails/5.jpg)
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
![Page 6: Formal Methods for Software Engineering](https://reader035.fdocuments.net/reader035/viewer/2022062721/56813815550346895d9fc9ad/html5/thumbnails/6.jpg)
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
![Page 7: Formal Methods for Software Engineering](https://reader035.fdocuments.net/reader035/viewer/2022062721/56813815550346895d9fc9ad/html5/thumbnails/7.jpg)
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).
![Page 8: Formal Methods for Software Engineering](https://reader035.fdocuments.net/reader035/viewer/2022062721/56813815550346895d9fc9ad/html5/thumbnails/8.jpg)
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.
![Page 9: Formal Methods for Software Engineering](https://reader035.fdocuments.net/reader035/viewer/2022062721/56813815550346895d9fc9ad/html5/thumbnails/9.jpg)
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
![Page 10: Formal Methods for Software Engineering](https://reader035.fdocuments.net/reader035/viewer/2022062721/56813815550346895d9fc9ad/html5/thumbnails/10.jpg)
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).
![Page 11: Formal Methods for Software Engineering](https://reader035.fdocuments.net/reader035/viewer/2022062721/56813815550346895d9fc9ad/html5/thumbnails/11.jpg)
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.
![Page 12: Formal Methods for Software Engineering](https://reader035.fdocuments.net/reader035/viewer/2022062721/56813815550346895d9fc9ad/html5/thumbnails/12.jpg)
Ed Brinksma FMSE, Lecture 5
Synchronization
Parallel components synchronize on identical actions;
Synchronization reduces the reachable states and transitions of the product transition system
![Page 13: Formal Methods for Software Engineering](https://reader035.fdocuments.net/reader035/viewer/2022062721/56813815550346895d9fc9ad/html5/thumbnails/13.jpg)
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
![Page 14: Formal Methods for Software Engineering](https://reader035.fdocuments.net/reader035/viewer/2022062721/56813815550346895d9fc9ad/html5/thumbnails/14.jpg)
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.
![Page 15: Formal Methods for Software Engineering](https://reader035.fdocuments.net/reader035/viewer/2022062721/56813815550346895d9fc9ad/html5/thumbnails/15.jpg)
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.
![Page 16: Formal Methods for Software Engineering](https://reader035.fdocuments.net/reader035/viewer/2022062721/56813815550346895d9fc9ad/html5/thumbnails/16.jpg)
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}.
![Page 17: Formal Methods for Software Engineering](https://reader035.fdocuments.net/reader035/viewer/2022062721/56813815550346895d9fc9ad/html5/thumbnails/17.jpg)
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
![Page 18: Formal Methods for Software Engineering](https://reader035.fdocuments.net/reader035/viewer/2022062721/56813815550346895d9fc9ad/html5/thumbnails/18.jpg)
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.
![Page 19: Formal Methods for Software Engineering](https://reader035.fdocuments.net/reader035/viewer/2022062721/56813815550346895d9fc9ad/html5/thumbnails/19.jpg)
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).
![Page 20: Formal Methods for Software Engineering](https://reader035.fdocuments.net/reader035/viewer/2022062721/56813815550346895d9fc9ad/html5/thumbnails/20.jpg)
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?
![Page 21: Formal Methods for Software Engineering](https://reader035.fdocuments.net/reader035/viewer/2022062721/56813815550346895d9fc9ad/html5/thumbnails/21.jpg)
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
![Page 22: Formal Methods for Software Engineering](https://reader035.fdocuments.net/reader035/viewer/2022062721/56813815550346895d9fc9ad/html5/thumbnails/22.jpg)
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
![Page 23: Formal Methods for Software Engineering](https://reader035.fdocuments.net/reader035/viewer/2022062721/56813815550346895d9fc9ad/html5/thumbnails/23.jpg)
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
![Page 24: Formal Methods for Software Engineering](https://reader035.fdocuments.net/reader035/viewer/2022062721/56813815550346895d9fc9ad/html5/thumbnails/24.jpg)
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
![Page 25: Formal Methods for Software Engineering](https://reader035.fdocuments.net/reader035/viewer/2022062721/56813815550346895d9fc9ad/html5/thumbnails/25.jpg)
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.
![Page 26: Formal Methods for Software Engineering](https://reader035.fdocuments.net/reader035/viewer/2022062721/56813815550346895d9fc9ad/html5/thumbnails/26.jpg)
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).
![Page 27: Formal Methods for Software Engineering](https://reader035.fdocuments.net/reader035/viewer/2022062721/56813815550346895d9fc9ad/html5/thumbnails/27.jpg)
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??
![Page 28: Formal Methods for Software Engineering](https://reader035.fdocuments.net/reader035/viewer/2022062721/56813815550346895d9fc9ad/html5/thumbnails/28.jpg)
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.
![Page 29: Formal Methods for Software Engineering](https://reader035.fdocuments.net/reader035/viewer/2022062721/56813815550346895d9fc9ad/html5/thumbnails/29.jpg)
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]
).
![Page 30: Formal Methods for Software Engineering](https://reader035.fdocuments.net/reader035/viewer/2022062721/56813815550346895d9fc9ad/html5/thumbnails/30.jpg)
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?
![Page 31: Formal Methods for Software Engineering](https://reader035.fdocuments.net/reader035/viewer/2022062721/56813815550346895d9fc9ad/html5/thumbnails/31.jpg)
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
![Page 32: Formal Methods for Software Engineering](https://reader035.fdocuments.net/reader035/viewer/2022062721/56813815550346895d9fc9ad/html5/thumbnails/32.jpg)
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!
![Page 33: Formal Methods for Software Engineering](https://reader035.fdocuments.net/reader035/viewer/2022062721/56813815550346895d9fc9ad/html5/thumbnails/33.jpg)
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).
![Page 34: Formal Methods for Software Engineering](https://reader035.fdocuments.net/reader035/viewer/2022062721/56813815550346895d9fc9ad/html5/thumbnails/34.jpg)
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.
![Page 35: Formal Methods for Software Engineering](https://reader035.fdocuments.net/reader035/viewer/2022062721/56813815550346895d9fc9ad/html5/thumbnails/35.jpg)
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!
![Page 36: Formal Methods for Software Engineering](https://reader035.fdocuments.net/reader035/viewer/2022062721/56813815550346895d9fc9ad/html5/thumbnails/36.jpg)
Ed Brinksma FMSE, Lecture 5
Question
Why don’t we need locks on leavingvisitors and COUNTER decrements?
Or do we?