Date post: | 18-Jan-2016 |
Category: |
Documents |
Upload: | joseph-walton |
View: | 217 times |
Download: | 1 times |
1
Nantes, en BretagneNantes in Brittany
La Cour des Comptes de BretagneLe Château des ducs de Bretagneare situated in Nantes
Spectacle deRoyal de Luxe
A bad solution, why?
Composition: to maintain properties
4
Proof and Model-checking, two Complementary Approaches
Henri HabriasI.U.T. de Nantes
LINA, Laboratoire de Nantes Atlantique
5
A black box
in out
We do not take into account the data going through this buffer
6
Two-places buffer
Two accepted traces : [in, out, in, out]
[in, in, out, in, out, out, in, out]
The following traces are never accepted :
[in, in, in]
[out, in, out]
[in, in, out, out, out]
Using the notation for regular expressions :
M = (in . (in . out)* out)*
7
Jackson trees
M
outin
outin
PROD
in move
*
*
CONS
move out
*
8
A white box
in out
move
9
Our presentation
Through an example :
- proof and refinement with B
- model-checking with FSP
To specify a two-places buffer
With two tools : Atelier B and LTSA
10
B
- Classical B
- Event B
11
Classical B vs Event B
Classical B
An abstract machine with an Invariant and Operations respecting the invariant.
The execution system of these operations is not explicitely taken into account compte par la méthode.
We prove that an operation called under its precondition respects the invariant..
12
Classical B vs Event B
Event B,
Keeps the concepts of classical B but use as fundamental concept, the concept of event..
An event is specified as a guarded operation.
An operation is called.An event is not called.
13
A classical B Machine
MACHINE classicalDoorSETS STATE = {open, closed}VARIABLES doorStateINVARIANT doorState : STATEINITIALISATION doorState :: ETAT
OPERATIONSopen = doorState := open END;close = doorState := closed END;st <-- whatState =st := doorState END If doorState = open,
doorState := openrespects the invariant
14
A Event B Machine
MACHINE EventBDoorSETS STATE = {open, closed}VARIABLES doorStateINVARIANT doorState : STATEINITIALISATION doorState :: STATE
OPERATIONSopening = SELECT doorState = closedTHEN doorState := open END;closing = SELECT doorState = openTHEN doorState := closed END;st <-- whatStates = st := doorState
END
15
The door, classical B
close open
openclosed
close
open
open close
16
The door, Event B
openclosed
close
open
initialisation initialisation
17
Classical operation vs Event
- a classical operation is called
- an event is NOT called. An event is trigged when its guard istrue
18
Refinement : guard vs precondition
- in classical B,
preconditions are weaked,
- in Event B ,
Guards are strenghten .
Parachute: more we are closed the ground more events we see.
19
Refinement in Event B
- new variables
- new constraints linking these new variables to the old variables
- new events
And we refine the higher level events
20
The two places buffer in B (Architecture)M1
M2
INCLUDES
CONS PROD
M1_IREFINES
IMPORTS
21
M1 (1)
MACHINE
M1
VARIABLES
state
INVARIANT
state : 0..2
INITIALISATION
state := 0
22
M1Machine (2)OPERATIONS
in = SELECT state = 0 THEN state := 1
WHEN state = 1 THEN state := 2
END;
out = SELECT state = 1 THEN state := 0
WHEN state = 2 THEN state := 1
END;
move = skip
END
Necessary because we refine withconstant signatures.
23
MACHINE PROD (1)
MACHINE
PROD
VARIABLES
pstate
INVARIANT
pstate : 0..1
INITIALISATION
pstate := 0
PROD CONS
24
MACHINE PROD (1)
OPERATIONS
in =
SELECT pstate = 0 THEN
pstate := 1 END;
pmove =
SELECT pstate = 1 THEN
pstate := 0 END
END
PROD CONS
25
La machine CONS
MACHINE CONS
VARIABLES cstate
INVARIANT
cstat : 0..1
INITIALISATION cstate := 0
OPERATIONS
out = SELECT cstate = 1 THEN cstate := 0 END;
cmove = SELECT cstate = 0 THEN cstate := 1 END
END
PROD CONS
26
M2 includes PROD and CONS
MACHINE M2
INCLUDES
PROD, CONS
PROMOTES
in, out
OPERATIONS
move = pmove || cmove
END
PROD CONS
27
M2 simulates M1
IMPLEMENTATION M1_I
/* to prove that M2 simulates M1 */
REFINES
M1
IMPORTS
M2
PROMOTES
in, out, move
END
28
FSP
We specify a behaviour in FSP.
LTSA generate the automatonandPermits executions.
We can minimise the automaton.
We can verify properties :
- no deadlock- progress property
29
FSP and LTSA
Magee J., Kramer J., Concurrency, State Models & Java Programs, Wiley, 1999
Second edition, 2006
30
P = (a (cd)*, b (cd)*)*
P= (a -> STATE1 | b -> STATE1),
STATE1 = (a -> STATE1 | b -> STATE1 | c -> STATE2),
STATE2 = (d -> STATE1).
P= ab*P= (a -> STATE),STATE =(b ->STOP | a -> STATE).
P=aa*
P= (a -> STOP | a -> STATE),
STATE = (a -> STATE).P= (a, b, c)*
P= (a -> P |b -> P | c -> P).
FSP and Regular Expressions
A limitation of FSP
P = a*
It impossible to translate into FSP
In FSP, no empty sequence
32
From CCS to FSP
C1 = in.m. C1
C2 = m'.out.C2
System = C1 | C2
C1 =(in -> m -> C1).
C2 =(m -> out -> C1).
||SYSTEM = (C1 || C2).
Is written in LTSA :
33
|| in B and the diamond in Process algebra
P1
P2
P2
P1
Diamond
x=3 & y = 1
x:= x+2 || y:= y+2
x=5 & y = 5
x=3 & y = 1
x:=x+2; y:=x+2
x=5 & y=7
x=3 & y = 1
x:=x+2;x:=x+2
x=5 & y=5
34
High level spec in FSP
BUFFER = STATE0,STATE0 = (in -> STATE1),STATE1 = (in -> STATE2 | out -> STATE0),STATE2 = (out -> STATE1).
BUFFER(N=2) = STATE [0],STATE[i:0..N] = (when (i<N) in -> STATE [i+1] | when (i>0) out -> STATE [i-1]).
ou
When : guard in FSP
in
out in
out
35
Low level spec in FSP
PROD = (in -> move -> PROD).CONS = (move -> out -> CONS).||BUFF_2 = (PROD || CONS).
in outmove move
in
out in
outtau
36
Equivalent Specs ?
If now we hide the silent action le move, it is replaced by a tau.
If we ask the minimisation of the automation, we obtain the same automaton as the one of the high level spec
Equivalence between the two behaviours
37
Two equivalences for the minimisation
In FSP, for minimisation, two équivalences are considered.
-The strong equivalence considers that two systems are equal if they
Have the same behaviour when the occurrence of all their actions can
Be observed included the silent action.
Minimisation uses this equivalence when ther is no silent action.
38
Weak equivalence
-The weak equivalence considers that two systems are equal if they
exhibit the same behaviour for an external observer who cannot detect
the occurrence of the tau actions.
PROD = (in -> move -> PROD).
CONS = (move -> out -> CONS).
||BUFF_2 = (PROD || CONS)\{move}.
39
Verification of properties with LTSA
- Safety property) , as the absence of deadlock.
Defines a deterministic process asserting that this same processaccepts every trace including the actions of the alphabet of this process.
-Liveness property
Asserts that something good will arrive eventually.
40
Progress property
In FSP, the temporal logic is not used..
We are limited to a class of liveness property called progress, which is the opposite to the property of starvation.
Such a property asserts that, whatever will be the state of the system,It is always the case where a specified action will eventually be executed.
41
A behaviour in FSP
MEN(N=3) = BACHELOR[0]BACHELOR[spouses_nb : 0..N] = (marriage -> MARRIED[1])MARRIED[spouses_nb :0..N]=(when (spouses_nb ==1) divorce -> MEN |when (spouses_nb >1) divorce -> MARRIED[spouses_nb –1] |when (spouses_nb == 3] it_is_enough_for_a_man ->divorce -> MARRIED[spouses_nb –1 ] |when (spouses_nb <3) marriage -> MARRIED[spouses_nb + 1]).
Not considered: the death of a a man who was never married
42
4 Relational schemas (without null values)
Schema 1Marriages_in_course (id_married_men , id_married_women)
Schema 2Marriages_in_course (id_married_men , id_married_women)
Schema 3Marriages_in_course (id_married_men , id_married_women)
Schema 4Marriages_in_course (id_married_men , id_married_women)
43
B notation
isToDayMarriedWith : id_married_women -->> id_married_men
isToDayMarriedWith : id_married_men ->> id_married_women
isToDayMarriedWith : id_married_women >->> id_married_men
isToDayMarriedWith : id_married_women <--> id_married_men & dom (isToDayMarriedWith) = man
44
Polygamy without polyandry
Bachelor Married
Marriage/ N:= N+1
Divorce or death/SELECT N=1 THEN N:=N-1
Divorce or death/SELECT N>1 THEN N:=N-1
Marriage/N:=N+1
Harel Automata with guards
45
Conclusion
To specify, refine and verify :
-the B approach permits to manipulate variables as it is done classicallyin programming.
-The approach by Process Algebras does not use variables. A stateis modelised by a behaviour.-With LTSA, we are obliged to modelise a variable by a behaviour and It complicates the specification comparatively to what is done with B.
46
Conclusion
But otherwise with B the automaton is not explicit whereas LTSAProducts the automaton.
- in B, we are guided by the proof,
- in FSP we are guided by the execution and by the generated automaton and his minimisation. Considering the automaton it is possibleto restructurate the specification
47
IN MEMORIAM Claude Piéplu (1923-2006)