La présentation est en train de télécharger. S'il vous plaît, attendez

La présentation est en train de télécharger. S'il vous plaît, attendez

1 Quoi ? Un tampon. 2 Une boite noire in out On ne modélise pas les données qui passent par le tampon.

Présentations similaires


Présentation au sujet: "1 Quoi ? Un tampon. 2 Une boite noire in out On ne modélise pas les données qui passent par le tampon."— Transcription de la présentation:

1 1 Quoi ? Un tampon

2 2 Une boite noire in out On ne modélise pas les données qui passent par le tampon

3 3 Le tampon à deux places Deux suites acceptées : [in, out, in, out] [in, in, out, in, out, out, in, out] Les suites suivantes ne sont jamais observées : [in, in, in] [out, in, out] [in, in, out, out, out] En utilisant la notation des expressions régulières, on peut en conséquence modéliser le comportement du tampon ainsi : M = (in. (in. out)* out)*

4 4 Une boîte blanche inout move

5 5 Qui sommes-nous, doù venons- nous?

6 6 Bonjour ! Henri Habrias Cédric Stoquer IUT de Nantes, département informatique LINA (Université de Nantes, EMN)

7 7 Nantes, en Bretagne La Cour des Comptes de Bretagne Le Château des ducs de Bretagne sont situés à Nantes Spectacle de Royal de Luxe

8 8 Ce que nous allons traiter En utilisant un exemple, comment on peut utiliser deux démarches : - la preuve avec B - le model-checking (vérification de modèle) avec FSP pour vérifier une spécification (celle du tampon à deux places) avec deux outils logiciels : l'Atelier B et LTSA

9 9 Doù ce titre … B, B événementiel et LTSA

10 10 Commençons par B - B classique - B événementiel

11 11 B classique vs B événementiel B classique traite de la spécification d'opérations respectant un invariant. Le système d'exécution de ces opérations n'est pas explicitement pris en compte par la méthode. Un des concepts fondamentaux : précondition. On prouve que si une opération est appelée sous sa précondition elle respecte l'invariant de la machine.

12 12 B classique vs B événementiel B événementiel, conserve les concepts du B classique mais a comme concept fondamental celui d'événement. Un événement est spécifié comme une opération gardée.

13 13 Une machine B classique MACHINE PorteClassique SETS ETAT = {ouverte, fermee} VARIABLES aPourEtat INVARIANT aPourEtat : ETAT INITIALISATION etatPorte :: ETAT /* L'initialisation est là pour vérifier que nous avons au moins un modèle de la spécification. On a écrit une substitution indéterministe. */ OPERATIONS ouvrir = etatPorte := ouverte END; fermer = etatPorte := fermee END; et <-- quelEtats =et := etatPorte END Si etatPorte = ouverte, etatPorte := ouverte respecte linvariant

14 14 Une machine B événementiel MACHINE PorteEvenementiel SETS ETAT = {ouverte, fermee} VARIABLES aPourEtat INVARIANT aPourEtat : ETAT INITIALISATION etatPorte :: ETAT OPERATIONS ouverture = SELECT etatPorte = fermee THEN etatPorte := ouverte END; fermeture = SELECT etatPorte = ouverte THEN etatPorte := fermee END; et <-- quelEtats = et := etatPorte END Opérations gardée

15 15 Opération classique vs Evénement - une opération classique est APPELEE - une opération gardée (un événement) nest pas appelée. Elle est déclenchée quand la garde est évaluée à vrai.

16 16 Raffinage : garde vs précondition - en B classique, on affaiblit les préconditions, - en B événementiel, on renforce les gardes. La démarche du B événementiel est celle du parachute. Plus on s'approche du sol, plus l'échelle est fine, plus on voit d'événements.

17 17 Raffinage en B événementiel On fait apparaître : - de nouvelles variables et - de nouvelles contraintes reliant ces nouvelles variables aux anciennes variables (on complète l'invariant) - de nouveaux événements Et on raffine les événements de plus haut niveau

18 18 Obligations de preuve en B événementiel - Preuve que les événements maintiennent l'invariant - Preuve de la terminaison de l'événement. Les nouveaux événements introduits lors du raffinage ne doivent pas prendre le contrôle pour toujours. Ils doivent tous faire décroître un variant.

19 19 Obligations de preuve en B événementiel - Etant donné qu'un système s'arrête quand toutes les gardes de ses événements sont fausses, quand un raffinage s'arrête, son abstraction doit s'être arrêtée elle aussi, c'est-à-dire qu'il ne doit pas y avoir arrêt prématuré du raffinage. On doit prouver que : - si toutes les gardes raffinées sont fausses alors toutes les gardes abstraites sont fausses - et que siil existe des gardes abstraites qui sont vraies alors il existe des gardes du raffinage qui sont vraies.

20 20 Le tampon à deux places en B M1 M2 INCLUDES CONSPROD M1_I REFINES IMPORTS

21 21 La machine M1 (1) MACHINE M1 VARIABLES state INVARIANT state : 0..2 /* l'état est le nombre de données dans le tampon */ INITIALISATION state := 0

22 22 La machine M1 (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 Nécessaire car on raffine à signatures constantes

23 23 MACHINE PROD (1) MACHINE PROD VARIABLES pstate INVARIANT pstate : 0..1 INITIALISATION pstate := 0 PRODCONS

24 24 MACHINE PROD (1) OPERATIONS in = SELECT pstate = 0 THEN pstate := 1 END; pmove = SELECT pstate = 1 THEN pstate := 0 END END PRODCONS

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

26 26 M2 inclut PROD et CONS MACHINE M2 INCLUDES PROD, CONS PROMOTES in, out OPERATIONS move = pmove || cmove END PRODCONS

27 27 M2 simule M1 IMPLEMENTATION M1_I /* machine pour prouver que M2 simule M1 */ REFINES M1 IMPORTS M2 PROMOTES in, out, move END

28 28 Passons maintenant à FSP On spécifie un comportement en FSP. LTSA génère lautomate et Permet de faire des exécutions. On peut minimiser lautomate. On peut aussi vérifier des propriétés : - absence de verrou fatal - propriété de progrès

29 29 FSP et LTSA Magee J., Kramer J., Concurrency, State Models & Java Programs, Wiley, 1999 Second edition, 2006

30 30 P = (a (cd)*, b (cd)*)* P= (a -> ETAT1 | b -> ETAT1), ETAT1 = (a -> ETAT1 | b -> ETAT1 | c -> ETAT2), ETAT2 = (d -> ETAT1). P= ab* P= (a -> ETAT1), ETAT =(b ->STOP | a -> ETAT1). P=aa* P= (a -> STOP | a -> ETAT), ETAT = (a -> ETAT). P= (a, b, c)* P= (a -> P |b -> P | c -> P). FSP et Expressions régulières

31 31 De CCS à FSP C1 = in.m. C1 C2 = m'.out.C2 System = C1 | C2 C1 =(in -> m -> C1). C2 =(m -> out -> C1). ||SYSTEM = (C1 || C2). s'écrit en LTSA :

32 32 La spéc de haut niveau en FSP BUFFER = ETAT0, ETAT0 = (in -> ETAT1), ETAT1 = (in -> ETAT2 | out -> ETAT0), ETAT2 = (out -> ETAT1). BUFFER(N=2) = ETAT[0], ETAT[i:0..N] = (when (i ETAT[i+1] | when (i>0) out -> ETAT[i-1]). ou When exprime la garde en FSP in out in out

33 33 La spec de bas niveau en FSP PROD = (in -> move -> PROD). CONS = (move -> out -> CONS). ||BUFF_2 = (PROD || CONS). in outmove in out in out tau

34 34 Specs équivalentes ? Si maintenant nous cachons l'action silencieuse, le move, celle-ci est remplacée par tau. Si nous demandons la minimisation de l'automate, nous obtenons alors le même automate que celui de la spécification de haut niveau. Nous avons ainsi une équivalence entre les deux comportements.

35 35 Deux équivalences pour la minimisation En FSP, pour la minimisation, deux équivalences sont considérées. - L'équivalence forte considère que deux systèmes sont égaux s'ils ont même comportement quand l'occurrence de toutes leurs actions peuvent être observées y compris celle de l'action silencieuse (tau). La minimisation utilise cette équivalence lorsqu'il n'y a pas d'action silencieuse.

36 36 Léquivalence faible - L'équivalence faible considère que deux systèmes sont égaux s'ils exhibent le même comportement pour un observateur extérieur qui ne peut détecter l'occurrence des actions tau. PROD = (in -> move -> PROD). CONS = (move -> out -> CONS). ||BUFF_2 = (PROD || CONS)\{move}.

37 37 Vérification de propriétés en LTSA - propriétés de sûreté (safety), comme l'absence de verrou fatal. définit un processus déterministe qui asserte que toute trace incluant les actions de l'alphabet de ce processus, est acceptée par ce même processus. - propriétés de vivacité (liveness). asserte que quelque chose de bon se produira fatalement.

38 38 Propriété de progrès En FSP, on n'utilise pas la logique temporelle. On se limite à une classe de propriété de vivacité appelée progrès, qui est l'opposée de la propriété de famine. Une telle propriété asserte que quelque soit l'état dans lequel est le système, c'est toujours le cas où une action spécifiée sera fatalement exécutée.

39 39 Conclusion Pour spécifier, raffiner et vérifier un logiciel : - L'approche de B permet de manipuler des variables comme on le fait classiquement en programmation. - L'approche par les algèbres de processus comme CCS n'utilise pas de variables (on parle de CCS pur). Un état y est modélisé par un comportement. C'est le comportement possible quand on est dans cet état. - Avec LTSA, on est obligé de modéliser une variable par un comportement, ce qui complique la spécification comparativement à ce que l'on ferait avec B.

40 40 Conclusion Mais d'un autre côté, avec B, l'automate n'est pas explicite, alors que LTSA produit l'automate. - en B, on est guidé par la preuve, - en FSP on est guidé par l'exécution que génère l'outil ainsi que par l'automate généré et sa minimisation. On peut, à la vue de l'automate, restructurer la spécification en FSP.

41 41 IN MEMORIAM Claude Piéplu ( )


Télécharger ppt "1 Quoi ? Un tampon. 2 Une boite noire in out On ne modélise pas les données qui passent par le tampon."

Présentations similaires


Annonces Google