Quoi ? Un tampon

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

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)*

Une boîte blanche move in out

Qui sommes-nous, d’où venons-nous?

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

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

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

D’où ce titre … B, B événementiel et LTSA

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

B classique vs B événementiel 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.

B classique vs 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.

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 l’invariant

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

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

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.

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

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.

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 si’il existe des gardes abstraites qui sont vraies alors il existe des gardes du raffinage qui sont vraies.

Le tampon à deux places en B M1_I REFINES IMPORTS M2 INCLUDES CONS PROD

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

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 move = skip END Nécessaire car on raffine à signatures constantes

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

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

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

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

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

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

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

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

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

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

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

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.

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.

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}.

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.

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.

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.

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.

IN MEMORIAM Claude Piéplu (1923-2006)