Probl´ematique et contributions

A l’inverse du B classique, une sp´ecification B ´ev´enementiel n’est pas directement

implan-table, car elle est d´ecrite par des ´ev´enements qui se d´eclenchent spontan´ement et que le choix du

d´eclenchement peut ˆetre non-d´eterministe. Par contre, le raffinement d’une sp´ecification B

´ev´e-nementiel permet de raffiner non seulement la repr´esentation de ses donn´ees et ses algorithmes,

comme en B classique, mais aussi son contrˆole. Raffiner le contrˆole consiste `a modifier l’ensemble

des comportements (des traces d’ex´ecution) possibles du syst`eme. Pour ce faire, il est possible de

renforcer les gardes des ´ev´enements ou d’introduire de nouveaux ´ev´enements. Cependant, pour

que cette modification pr´eserve la notion de raffinement, il est n´ecessaire que l’ensemble des traces

d’ex´ecution du raffinement soit inclus, modulo les nouveaux ´ev´enements, dans l’ensemble des traces

d’ex´ecution de l’abstraction. L. Lamport [Lam94b] propose l’exemple d’une horloge donnant l’heure

et les minutes qui peut ˆetre affin´ee pour donner aussi les secondes.

1.4 Probl´ematique et contributions

1.4.1 Probl´ematique

Comme nous l’avons vu, l’un des principaux verrous technologiques des d´eveloppements logiciels

en g´en´eral, mais que l’on retrouve dans l’utilisation des m´ethodes formelles, est la v´erification de

la conformit´e d’un mod`ele par rapport `a un cahier des charges. C’est pourquoi, nous proposons de

1.4. Probl´ematique et contributions

faciliter cette v´erification, en mettant en ´evidence un autre aspect du mod`ele, compl´ementaire `a sa

description en langage B: ses comportements.

Terminologie. Dans cette th`ese, nous avons choisi d’appeler lescomportementsd’un mod`ele, l’ensemble

de ses traces d’ex´ecution ; c’est-`a-dire l’ensemble des s´equences d’´ev´enements ou d’op´erations qu’il autorise.











Seq

1

=

^{oc1 oc2 oc3 oc4 oc5 ocn}

Seq

2

=

^{oc’1 oc’2 oc’3 oc’4 oc’5 oc’m}

. . .

L’id´ee est d’aider le sp´ecifieur en lui fournissant un autre point de vue sur son mod`ele. De plus,

en utilisant un formalisme plus accessible aux non informaticiens, nous voulons donner la possibilit´e

au client de v´erifier lui mˆeme les principales propri´et´es du syst`eme. Enfin, nous proposons de prendre

en compte le processus de raffinement B´ev´enementiel, qui permet de raffiner les comportements.

L’approche propos´ee (figure1.4) consiste `a calculer une repr´esentation de l’ensemble des

compor-tements d’un mod`eleBconstruit par raffinement. Cette approche a pour but l’aide `a la compr´ehension

du pas entre le formel et l’informel. Les descriptions ainsi produites peuvent donc ˆetre utilis´ees pour

documenter ou pr´esenter le mod`ele.

Intégration par raffinement du cahier des charges des différents aspects

Cahier des charges

Exigences fonctionnelles Propriétés Spécification formelle Système raffiné automatique Génération Documentation Représentations graphiques Confrontation pour validation présentation Support de ère 1 modélisation

Fig. 1.4 – Int´egration de notre approche dans le processus de d´eveloppement

Un d´eveloppement B ´ev´enementiel commence g´en´eralement par la r´ealisation d’un diagramme

informel d´ecrivant les comportements attendus du syst`eme. Cela permet de structurer la r´eflexion

pour formaliser les besoins et choisir les donn´ees `a int´egrer dans chaque niveau de description. Ce

diagramme informel peut ensuite ˆetre ajout´e au cahier des charges s’il est valid´e par le client. Il est

alors int´eressant de pouvoir comparer cette ´ebauche des comportements pr´evus du syst`eme avec

une repr´esentation de ceux r´eellement d´ecrits. Nous nous int´eressons donc aussi `a la v´erification de

propri´et´es de s´ecurit´e.

– construire et repr´esenter graphiquement les comportements d’une sp´ecification B;

– mettre en ´evidence le processus de raffinement dans les repr´esentations d’un mod`ele ;

– exploiter la repr´esentation comportementale d’un mod`ele pour le v´erifier par rapport `a une

propri´et´e.

Nous d´etaillons successivement chacun de ces points dans les trois sections suivantes.

1.4.2 Compl´ementarit´e des vues : orient´ees donn´ees / comportements

Un mod`eleB´ev´enementiel est d´ecrit en termes de ses donn´ees, dans le sens o`u chaque ´ev´enement

est d´efini par une condition de d´eclenchement portant sur les valeurs des donn´ees et par une action

modifiant ces donn´ees. Cependant, la s´emantique d’un syst`eme B ´ev´enementiel est d´efinie par

l’ensemble de ses comportements.

Bien que cette information des enchaˆınements possibles des ´ev´enements soit sous-jacente dans

tout syst`eme B´ev´enementiel, elle n’y est pas explicitement d´ecrite. On n’´ecrit pas, par exemple,

qu’₍₍apr`es l’´ev´enement oc

₁

, l’´ev´enement oc

₂

se d´eclenche₎₎. Classiquement, on oppose les

descrip-tions bas´ees sur les donn´ees aux descripdescrip-tions comportementales (bas´ees sur les ´ev´enements). Les

premi`eres d´ecrivent finement l’action effectu´ee par chaque ´ev´enement sur les donn´ees, tandis que

les secondes permettent de mettre en ´evidence des comportements. Les deux styles de description

sont compl´ementaires, car ils donnent deux points de vue diff´erents d’une mˆeme sp´ecification.

Par exemple, les deux descriptions suivantes sont ´equivalentes et sp´ecifient toutes deux que

l’action S

₁

est suivie de l’action S

₂

. Dans une description orient´ee comportement (Cas B.) on se

contente de dire queS

₁

est suivi deS

₂

, tandis que, dans une description orient´ee donn´ees (Cas A.),

on codele comportement `a travers une variable de contrˆoleC, qui permet de forcer l’ex´ecution de

l’action S

₂

apr`es l’ex´ecution deS

₁

.

Initialisation :C:= 1

ev

₁

=ˆ C= 1=⇒(S

₁

||C:= 2) S

₁

; S

₂

; S

₁

; S

₂

; . . .

ev

₂

=ˆ C= 2=⇒(S

₂

||C:= 1)

A. Description orient´ee donn´ees B.Description comportementale

(Le contrˆole est cod´e dansC) (Le contrˆole est explicite)

Intuitivement, la description orient´ee donn´ees est plus expressive. Elle est ´egalement int´eressante

pour la preuve de propri´et´es de sˆuret´e, puisque l’on est amen´e `a d´ecrire, par des assertions, l’´etat du

syst`eme entre deux occurrences d’´ev´enements. Cette information permet alors de d´ecomposer les

obligations de preuve, puisque l’on ne s’int´eresse plus `a la correction d’un enchaˆınement mais `a celle

de chacune des actions qui le composent. `A l’inverse, la description comportementale permet de

s’abstraire du codage (compliqu´e) du contrˆole dans les ´ev´enements. Ce second type de formalisme

est donc mieux adapt´e `a la v´erification de propri´et´es dynamiques.

Le langageBest un formalisme de description orient´e donn´ees. Dans notre approche, nous

pro-posons donc une m´ethode permettant de construire une description comportementale d’un syst`eme

d´ecrit enB. Pour ce faire, nous proposons ´egalement un formalisme graphique de repr´esentation. Il

1.4. Probl´ematique et contributions

existe de nombreux langages permettant de d´ecrire les comportements d’un syst`eme (CSP[Hoa78],

µ-calcul [Par74], etc.) ; il semble toutefois que les automates symboliques soient l’une des

alterna-tives les mieux adapt´ees `a notre objectif d’aide `a la compr´ehension [Liv78]. En effet, ce formalisme

graphique est universel et exhibe de mani`ere intuitive les enchaˆınements d’´ev´enements qui peuvent

survenir.

1.4.3 Visualiser le lien entre deux niveaux de description

Quelques travaux [BL07,LT05,IL06] (pour ne citer qu’eux) portent d´ej`a sur l’aide `a la compr´ehension

de mod`eles Bet `a la validation de sp´ecifications abstraites par rapport au cahier des charges.

Ce-pendant, aucun d’entre eux ne prend vraiment en compte le processus de raffinement.

En effet, un raffinement est une description `a part enti`ere d’un syst`eme `a laquelle ont ´et´e

rajout´ees des informations permettant de faire le lien avec les donn´ees et les ´ev´enements de son

abstraction. Ce lien permet de tracer les donn´ees et leurs propri´et´es `a travers le processus de

raffinement et donc de casser la complexit´e des v´erifications. C’est pourquoi, nous proposons de

faire apparaˆıtre ce lien sur nos repr´esentations. En utilisant des ´etats hi´erarchiques (figure1.5), nous

associons chaque niveau de hi´erarchie aux donn´ees d’un niveau de raffinement. De plus, comme nous

le verrons, cette approche hi´erarchique conserve la structure g´en´erale du syst`eme de transitions

abstrait. Il s’ensuit qu’il est possible de comparer les syst`emes de transitions et donc de r´eutiliser

les efforts de compr´ehension faits pour les niveaux les plus abstraits.

Par exemple, consid´erons deux descriptions d’une carte de paiement (figure 1.5) o`u l’on se

focalise sur l’authentification par saisie du code PIN. Nous proposons d’observer 3 ´ev´enements :

EssaiPIN qui mod´elise la saisie d’un code PIN (qui peut ˆetre correct ou incorrect), Bloquer qui

correspond `a la saisie d’un code PIN faux entraˆınant un blocage de la carte (plus d’essai autoris´e)

etD´ebloquer qui permet de r´eactiver la carte en laissant `a nouveau la possibilit´e de saisir un code

PIN. Dans la premi`ere description (figure 1.5.A), nous ne mod´elisons qu’une unique variable´etat

´etat∈ {Bloqu´ee, Active} NbPIN∈0..M ax

Débloquer EssaiPIN état=Active état=Bloquée Bloquer NbPIN=1 EssaiPIN EssaiPIN EssaiPIN EssaiPIN NbPIN=0 Débloquer EssaiPIN état=Bloquée état=Active Bloquer NbPIN=Max EssaiPIN ∈ NbPIN 2..Max−1

A. Abstraction B.Raffinement

Fig. 1.5 – Automate hi´erarchique repr´esentant les comportements d’une carte de paiement

qui peut avoir deux ´etats (Bloqu´ee ouActive). Seuls les ´ev´enements Bloqu´ee etD´ebloquer peuvent

alors changer le syst`eme d’´etat. Dans la seconde description (figure1.5.B), on ne s’int´eresse plus `a la

variable´etat, mais `aNbPIN, qui caract´erise le nombre restant d’erreurs de saisie du code PIN avant

blocage de la carte. L’´ev´enement EssaiPIN permet alors de remettre le compteur au maximum, si

le code est correct, ou sinon de d´ecr´ementer le compteur. Si le compteur ´etait `a 1 et que le code

est incorrect, alors c’est l’´ev´enement Bloquer qui est d´eclench´e. Cette seconde description est un

raffinement de la premi`ere, car elle contient plus d’informations. La formule suivante permet de

relier les variables´etat etNbPIN :

(NbPIN= 0⇔´etat=Bloqu´ee) ∧ (NbPIN>0⇔´etat=Active)

C’est ce lien, appel´e invariant de liaison, que l’on veut expliciter sur nos automates en exploitant la

hi´erarchie des ´etats. Cet invariant entre les donn´ees abstraites et raffin´ees peut ensuite ˆetre retrouv´e

dans le graphe. Il est ainsi possible de retrouver sur le syst`eme de transitions les associations

suivantes, qui sont ´equivalentes `a l’invariant de liaison donn´e plus haut :

(´etat=Active) ⇔ (NbPIN= 1 ∨ NbPIN∈2..Max−1 ∨ NbPIN=Max)

(´etat=Bloqu´ee) ⇔ (NbPIN=0)

Enfin, certaines propri´et´es peuvent ˆetre pr´eserv´ees par raffinement. Par exemple, sur la

des-cription propos´ee en figure 1.5.A il n’est pas possible de saisir un code PIN si la carte est bloqu´ee.

Cette propri´et´e est pr´eserv´ee dans le raffinement, comme on peut le voir sur la figure1.5.B. Cette

pr´eservation est visible, car, grˆace aux contraintes de la repr´esentation hi´erarchique propos´ee, la

structure globale de la figure1.5.A et conserv´ee dans la figure1.5.B.

1.4.4 Appliquer la m´ethode `a la v´erification de propri´et´es

Nous proposons trois techniques de v´erification de propri´et´es qui se basent sur la repr´esentation

des comportements d’un mod`eleB. La premi`ere possibilit´e est une aide `a la preuve d’invariant et

consiste `a v´erifier que l’ensemble des ´etats atteignables v´erifient l’invariant.

Une seconde proposition se base sur le fait qu’une propri´et´e de sˆuret´e est pr´eserv´ee par

raffine-ment. On s’int´eresse alors `a montrer que le mod`ele est un raffinement de la propri´et´e. Pour ce faire,

nous proposons de d´ecrire la propri´et´e et le mod`ele par des syst`emes de transitions et d’´etablir que

celui du mod`ele est une simulation de celui de la propri´et´e (figure 1.6).

Automate de la propriété Description B de la propriété Automate du modèle ^{Modèle B} Propriété informelle Raffinement Simulation

Fig. 1.6 – Deux approches de v´erification bas´ees sur le raffinement

Enfin, notre troisi`eme proposition consiste `a exprimer la propri´et´e dans un langage logique

suf-fisamment simple pour ˆetre d´ecidable et sufsuf-fisamment expressif pour pouvoir d´ecrire des propri´et´es

comportementales. Pour cela, nous introduisons des pr´edicats logiques permettant de d´ecrire des

1.5. Organisation de ce document

Dans le document Systèmes de transitions symboliques et hiérarchiques pour la conception et la validation de modèles B raffinés (Page 29-34)