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)