Perspectives

Les r´esultats de cette th`ese ont ´et´e outill´es et sont utilisables, puisqu’ils ont ´et´e exploit´es dans

diff´erentes ´etudes de cas pour aider notamment `a leur v´erification et `a leur documentation

(Sec-tion 6.3.2). Toutefois, certains points de ces r´esultats pourraient ˆetre am´elior´es ou adapt´es pour

ˆetre appliqu´es dans d’autres domaines. Nous d´eveloppons ici ces deux types de perspectives.

Am´eliorations

– L’utilisation de deux conditions de franchissement permet d’am´eliorer la compr´ehension du

lien entre le mod`ele et ses comportements, car cela permet de distinguer les valuations ne

permettant pas de d´eclencher l’´ev´enement et celles ne permettant pas d’atteindre un ´etat

donn´e. Cependant, ces deux conditions portent sur l’´etat des variables avant le d´eclenchement

de l’´ev´enement. Il serait int´eressant de caract´eriser ´egalement les valuations de l’´etat

d’ar-riv´ee qui sont atteignables. Cette information serait particuli`erement int´eressante pour

ai-der `a traiter des probl`emes d’atteignabilit´e d’une valuation `a travers une s´equence

d’occur-rences d’´ev´enements. Pour caract´eriser ce pr´edicat, il est alors possible soit d’utiliser le calcul

de plus forte post-condition, d´ecrit initialement dans [Dij76, Hes92], puis adapt´e `a B par

S. Dunne [Dun03], soit leWP. Dans ce dernier cas, il serait possible d’exprimer la condition

T caract´erisant que ₍₍toutes les valuations de l’´etat F sont atteignables par l’´ev´enement ev

depuis l’´etat E ₎₎par l’obligation de preuve suivante :

T =ˆ ∀x

^′

· ∃x·(E ∧ D ∧ A ∧ hAction(ev)i[x:=x

^′

]F)

– L’une des heuristiques introduites tout au long de ce manuscrit est de r´eduire le nombre de

d´efauts de preuve sans restreindre le langageB´ev´enementiel consid´er´e. Pour am´eliorer encore

les r´esultats obtenus, nous avons alors exp´eriment´e une utilisation de tactiques utilisateur

dans la version actuelle deG´en´eSyst. Pour chaque condition de franchissement, si le prouveur

automatique ´echoue `a prouver une formule, alors nous proposons d’utiliser successivement

les tactiques suivantes dans le prouveur interactif de l’AtelierB ou de B4free, jusqu’`a ce que

8.2. Perspectives

toutes les cinq soient tent´ees ou que le but soit prouv´e :

1. dd && pp(rp.0)

2. re && pp(rp.0)

3. re && dd && pp(rp.1)

4. re && dd && pp(rp.2)

5. re && pp(rp.1)

La commande dd permet de ne consid´erer que le but de la preuve et de r´eunir toutes les

hypoth`eses dans un ensemble d’hypoth`eses globales, tandis que la commandeppest un appel

au prouveur de pr´edicats. Le param`etre rp.xpermet alors de pr´eciser le sous-ensemble des

hypoth`eses globales qu’il peut utiliser

³

. Enfin, la commande re permet de recommencer la

preuve `a z´ero. L’utilisation de ces tactiques a permis de r´esoudre la quasi-totalit´e des cas

de d´efaut de preuve de la batterie de tests (section 6.3.1). Dans cette version prototype de

G´en´eSyst, les temps de calcul sont d´emesur´es (la construction des comportements du canal

de communication passe de 4 secondes `a 77 secondes), mais ils pourraient ˆetre diminu´es en

n’utilisant les tactiques que dans les cas de d´efaut de preuve av´er´e. Nous n’avons pas encore

pu tester cette approche sur les plus gros mod`eles, mais le taux de r´eduction des cas de d´efaut

de preuve semble tr`es prometteur.

– Une autre approche pour minimiser le nombre de d´efauts de preuve consisterait `a utiliser

d’autres prouveurs, ayant chacun leur propres tactiques. Pour ce faire, nous pourrions nous

int´eresser aux d´emarches outill´ees telles queWhy [Fil03], qui est un g´en´erateur d’obligations

de preuve pour de multiples prouveurs (Simplify [DNS05], Ergo [CCK07], haRVey [RD03],

etc). Cet outil prend en entr´ee une sp´ecification Why d´ecrite en termes de pr´e et

post-conditions et g´en`ere des obligations de preuve dans le langage de chacun des prouveurs pris en

compte. Il suffit alors d’axiomatiser les symboles non interpr´et´es de la logiqueBet d’exprimer

les assertions `a l’aide du langage des pr´edicats deWhy. En ce sens, ce travail pourrait s’inspirer

de ce qui a ´et´e fait avec succ`es dans l’outil Barvey [CDD

⁺

04, CDGR04] et plus r´ecemment

dans [CD07].

Utilisations

– En section 2.3.1, nous avons vu que diff´erentes approches ont ´et´e propos´ees pour d´eriver

un mod`ele B `a partir d’une description comportementale [MS99, GFL07, But00]. Il serait

int´eressant de coupler ces approches avec celle deG´en´eSyst pour proposer une m´ethode de

d´eveloppement multi-vues. La principale difficult´e de ce type d’approche est de maintenir

une certaine coh´erence entre les diff´erentes vues. Pour ce faire, l’id´ee serait de d´eriver le

squeletteB`a partir d’une sp´ecification comportementale, puis de v´erifier le mod`ele d´evelopp´e

en comparant ses comportements effectifs avec ceux attendus. Cette validation peut alors

ˆetre effectu´ee avec G´en´eSyst apr`es le d´eveloppement de chaque raffinement. Typiquement,

3rp.0: aucune hypoth`ese ;rp.1hypoth`eses qui ont une variable libre en commun avec le but ;rp.2: hypoth`eses qui ont une variable libre en commun soit avec le but, soit avec une hypoth`ese ayant une variable libre en commun avec le but.

l’int´egration deG´en´eSystdans la plateforme Rodin [JCI

+

05,BLS05] sous la forme d’un plugin

permettrait d’atteindre facilement ce r´esultat.

D’autres approches de d´eveloppement multi-vues ont d´ej`a ´et´e propos´ees. Nous pouvons citer

par exemple les approches CSP——B [ST05] et CSP+B [BL05] qui consistent `a s´eparer les

aspects contrˆole, d´ecrit en CSP, et donn´ees, d´ecrit en B. Il est alors possible de d´evelopper

s´epar´ement les deux aspects, modulo des preuves de coh´erence. L’approcheUML-B [OJS05]

permet ´egalement de consid´erer en mˆeme temps une vue UML et une vue B du mod`ele.

Ces deux vues sont ici consid´er´ees comme toujours coh´erentes. D´evelopper un tel mod`ele

consiste alors `a appliquer des r`egles de r´e´ecriture modifiant conjointement les deux vues, en

pr´eservant leur coh´erence. Contrairement `a ces approches, la m´ethode que nous proposons

aurait l’avantage de conserver la s´eparation des trois phases du cycle de d´eveloppement en

V : conception, d´eveloppement et validation. Il serait alors possible de concevoir le syst`eme

en UMLavant de d´evelopper le mod`ele formel et de valider ensuite la conformit´e de chaque

raffinement avec le cahier des charges.

– Diff´erents aspects de la m´ethode de v´erification de propri´et´es de s´ecurit´e bas´ee sur le langage

SEPL (pr´esent´e en section 7.4.3) pourraient ˆetre d´evelopp´es. Il serait notamment int´eressant

d’exploiter la hi´erarchie des syst`emes de transitions pour v´erifier des propri´et´es par partie et

ainsi simplifier leur v´erification. Par extension, cela reviendrait `a v´erifier des propri´et´es sur

le mod`ele abstrait et de les pr´eserver par raffinement. Par exemple dans [MMJ00,Lan05], les

auteurs caract´erisent une classe de propri´et´es logiques pouvant ˆetre v´erifi´ees par partie sur un

mod`ele modulaire. Intuitivement, cette approche devrait pouvoir ˆetre adapt´ee aux syst`emes

de transitions hi´erarchiques.

– Enfin, nous avons commenc´e, `a travers le stage d’ing´enieur de deuxi`eme ann´ee d’´Evelyne

Altariba, `a ´etudier l’impact de la modularit´e sur la construction des comportements d’un

mod`ele B classique. Cependant, les premiers r´esultats n’ont pas encore pu ˆetre exploit´es.

Intuitivement, dans un mod`ele d´efini par un ensemble de composants communicants, c’est

le composant appelant qui va contraindre les comportements du composant appel´e. De la

mˆeme mani`ere les r´esultats des appels d’op´erations peuvent influencer les comportements

de l’appelant. Il serait donc int´eressant de permettre un calcul des comportements d’un

composantBen prenant en compte son environnement d’ex´ecution. De plus, nous avons utilis´e

la hi´erarchie pour d´ecrire les comportements d’un mod`ele raffin´e. Ce type de repr´esentation

pourrait ´egalement ˆetre utilis´e pour repr´esenter les comportements d’un mod`ele compos´e de

plusieurs modules. En effet, si une transition repr´esente l’ex´ecution d’une op´eration, alors

une vue plus fine du syst`eme permettrait de visualiser les op´erations appel´ees lors de cette

ex´ecution.

Cinqui`eme partie

Compl´ement sur les

substitutions g´en´eralis´ees

A

A.1 Calcul de la terminaison

Le tableau A.1 r´esume le r´esultat du calcul de la terminaison des principales substitutions

primitives.

Substitution Condition de terminaison

trm(x:=E) btrue

trm(x, y:=E, F) btrue

trm(skip) btrue

trm(P |S) P ∧ trm(S)

trm(P =⇒S) P ⇒trm(S)

trm(S

1

[]S

2

) trm(S

1

) ∧ trm(S

2

)

trm(@z·S) ∀z·trm(S)

trm(S ;S

2

) [S]trm(S

2

)

Tab. A.1 – Terminaison des principales substitutions

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