1 / 47

Nantes, en Bretagne Nantes in Brittany

Nantes, en Bretagne Nantes in Brittany. Spectacle de Royal de Luxe. La Cour des Comptes de Bretagne Le Château des ducs de Bretagne are situated in Nantes. 1. A bad solution, why?. Composition: to maintain properties. Proof and Model-checking, two Complementary Approaches. Henri Habrias

selma
Download Presentation

Nantes, en Bretagne Nantes in Brittany

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Nantes, en BretagneNantes in Brittany Spectacle de Royal de Luxe La Cour des Comptes de Bretagne Le Château des ducs de Bretagne are situated in Nantes 1

  2. A bad solution, why?

  3. Composition: to maintain properties

  4. Proof and Model-checking, two Complementary Approaches Henri Habrias I.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 CONS M PROD * * move out in out in move * in out

  8. A white box move in out

  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 classicalDoor SETS STATE = {open, closed} VARIABLES doorState INVARIANT doorState : STATE INITIALISATION doorState :: ETAT OPERATIONS open = doorState := open END; close = doorState := closed END; st <-- whatState =st := doorState END If doorState = open, doorState := open respects the invariant

  14. A Event B Machine MACHINE EventBDoor SETS STATE = {open, closed} VARIABLES doorState INVARIANT doorState : STATE INITIALISATION doorState :: STATE OPERATIONS opening = SELECT doorState = closed THEN doorState := open END; closing = SELECT doorState = open THEN doorState := closed END; st <-- whatStates = st := doorState END

  15. The door, classical B open close open close open closed open close

  16. The door, Event B initialisation initialisation open closed open close

  17. Classical operation vs Event - a classical operation is called • an event is NOT called. An event is trigged when its guard is • true

  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 M1_I REFINES IMPORTS M2 INCLUDES CONS PROD

  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 with constant 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 automaton • and • Permits 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. FSP and Regular Expressions 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). P = (a (cd)*, b (cd)*)* P= (a -> STATE1 | b -> STATE1), STATE1 = (a -> STATE1 | b -> STATE1 | c -> STATE2), STATE2 = (d -> STATE1).

  31. 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 Is written in LTSA : C1 =(in -> m -> C1). C2 =(m -> out -> C1). ||SYSTEM = (C1 || C2).

  33. || in B and the diamond in Process algebra P2 x=3 & y = 1 x=3 & y = 1 P1 x=3 & y = 1 P2 P1 x:= x+2 || y:= y+2 x:=x+2;x:=x+2 x:=x+2; y:=x+2 x=5 & y=5 x=5 & y = 5 x=5 & y=7 Diamond

  34. High level spec in FSP BUFFER = STATE0, STATE0 = (in -> STATE1), STATE1 = (in -> STATE2 | out -> STATE0), STATE2 = (out -> STATE1). in out in out ou BUFFER(N=2) = STATE [0], STATE[i:0..N] = (when (i<N) in -> STATE [i+1] | when (i>0) out -> STATE [i-1]). When : guard in FSP

  35. Low level spec in FSP PROD = (in -> move -> PROD). CONS = (move -> out -> CONS). ||BUFF_2 = (PROD || CONS). in out tau move move out in in out

  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 process • accepts 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 1 Marriages_in_course (id_married_men , id_married_women) Schema 2 Marriages_in_course (id_married_men , id_married_women) Schema 3 Marriages_in_course (id_married_men , id_married_women) Schema 4 Marriages_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 Marriage/N:=N+1 Marriage/ N:= N+1 Bachelor Married Divorce or death/ SELECT N=1 THEN N:=N-1 Divorce or death/ SELECT N>1 THEN 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 classically • in programming. • The approach by Process Algebras does not use variables. A state • is 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 LTSA • Products 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 possible • to restructurate the specification

  47. IN MEMORIAM Claude Piéplu (1923-2006)

More Related