1 quoi ? un tampon. 2 une boite noire in out on ne modélise pas les données qui passent par le...
TRANSCRIPT
1
Quoi ?
Un tampon
2
Une boite noire
in out
On ne modélise pas les données qui passent par le tampon
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
Une boîte blanche
in out
move
5
Qui sommes-nous, d’où venons-nous?
6
Bonjour !
Henri HabriasCédric StoquerIUT de Nantes, département informatiqueLINA (Université de Nantes, EMN)
7
Nantes, en Bretagne
La Cour des Comptes de BretagneLe Château des ducs de Bretagnesont situés à Nantes
Spectacle deRoyal de Luxe
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
D’où ce titre … B, B événementiel et LTSA
10
Commençons par B
- B classique
- B événementiel
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
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
Une machine B classique
MACHINE PorteClassiqueSETS ETAT = {ouverte, fermee}VARIABLES aPourEtatINVARIANT aPourEtat : ETATINITIALISATION 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. */
OPERATIONSouvrir = etatPorte := ouverte END;fermer = etatPorte := fermee END;et <-- quelEtats =et := etatPorte END
Si etatPorte = ouverte,etatPorte := ouverterespecte l’invariant
14
Une machine B événementiel
MACHINE PorteEvenementielSETS ETAT = {ouverte, fermee}VARIABLES aPourEtatINVARIANT aPourEtat : ETATINITIALISATION etatPorte :: ETAT
OPERATIONSouverture = SELECT etatPorte = fermeeTHEN etatPorte := ouverte END;fermeture = SELECT etatPorte = ouverteTHEN etatPorte := fermee END;et <-- quelEtats = et := etatPorte
END
Opérations gardée
15
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. Elleest déclenchée quand la garde est évaluée à vrai.
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
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
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
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.
20
Le tampon à deux places en B
M1
M2
INCLUDES
CONS PROD
M1_IREFINES
IMPORTS
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
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écessairecar on raffineà signaturesconstantes
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 inclut PROD et CONS
MACHINE M2
INCLUDES
PROD, CONS
PROMOTES
in, out
OPERATIONS
move = pmove || cmove
END
PROD CONS
27
M2 simule M1
IMPLEMENTATION M1_I
/* machine pour prouver que M2 simule M1 */
REFINES
M1
IMPORTS
M2
PROMOTES
in, out, move
END
28
Passons maintenant à FSP
On spécifie un comportement en FSP.
LTSA génère l’automateetPermet 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
29
FSP et LTSA
Magee J., Kramer J., Concurrency, State Models & Java Programs, Wiley, 1999
Second edition, 2006
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
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
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<N) in -> ETAT[i+1] | when (i>0) out -> ETAT[i-1]).
ou
When exprime la garde en FSP
in
out in
out
33
La spec de bas niveau en FSP
PROD = (in -> move -> PROD).CONS = (move -> out -> CONS).||BUFF_2 = (PROD || CONS).
in outmove move
in
out in
outtau
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
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
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
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
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
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
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
IN MEMORIAM Claude Piéplu (1923-2006)