Métamodèle des contrats

La gure 4.5 présente le métamodèle Kmelia enrichi par les contrats [AAM11]. Nous rappelons que les composants Kmelia sont caractérisés par un état et des ser- vices. Ils sont assemblés sur leurs points d'accès (EndPoint) qui sont des interfaces

composées d'une liste de services. Un assemblage relie les composants, éventuelle- ment via d'autres assemblages, sur une relation de clientèle (contrat client/serveur classique). Un composite les encapsule dans une relation d'inclusion (contrat pa- rent/enfant). Nous remarquons que toute les liaisons entre composant se font au niveau des services.

Chaque élément de modélisation dénit un contrat. Un contrat peut être, lui- même, composite. Par exemple le contrat de clientèle déni au niveau d'un as- semblage est composé d'un contrat structurel (signatures), d'un contrat fonctionnel (pré/post-conditions) et d'un contrat comportemental (eLTS). Un contrat peut éga- lement contenir plusieurs éléments (ContractElement). Par exemple un contrat d'un service requis, contient un invariant, une pré-condition et une post-condition.

Component Assembly Composite

Link CompositionLink AssemblyLink Contract EndPoint Service RequiredService ContractElement Verification StructuralContract FonctionnalContract BihaviouralContract Signature Dependencies PreCondition PostCondition Guard RequiredPromotion 1..* 1..* 0..* 0..* 0..* 0..* 0..* 1..* 1..* 0..* 1..* Port Interface Invariant 2 uses contains defines defines defines defines ContractEvaluation State Result Diagnostic Technique 1 0..* 0..* Automatisation Complexity Completude ProvidedPromotion ProvidedService

Figure 4.5  Métamodèle simplié du modèle Kmelia enrichi par les contrats La partie grisée montre que plusieurs techniques peuvent être utilisées pour vé- rier un même contrat élémentaire. Les techniques de vérication de contrats sont caractérisées par leur degré d'automatisation, leur complexité (qui peut être calculée en fonction du modèle) et la force du résultat (une preuve de propriété est plus forte que l'absence d'échecs lors d'un test, par exemple). Une vérication eectuée pro- duit un résultat, partiel ou complet, assorti d'un diagnostic exploitable par d'autres vérications.

4.5 Conclusion

Dans ce chapitre, nous avons présenté notre contribution à l'enrichissement du modèle Kmelia, à savoir un langage de données pour les expressions et les prédi- cats, une notion d'observabilité et des contrats de service. Ce langage de données servira tout d'abord dans l'étape de spécication du système puis dans l'étape de vérication. L'analyse statique est opérationnelle dans l'outil COSTO associé au

modèle Kmelia. Nous avons illustré cette démarche sur un exemple simplié d'une application de gestion de stock.

L'intégration du langage de données fait de Kmelia un langage large-spectre qui :  couvre à la fois les aspects structurels, fonctionnels et comportementaux ;  renforce la notion de requis (par la notion du contexte virtuel) facilitant une

réutilisation individuelle (composants o-the-shelf ) ;

 renforce la notion d'observabilité en favorisant ainsi la construction composi- tionnelle.

La prise en compte de données dans Kmelia permet d'exprimer des propriétés de cohérence plus avancées au niveau des services (conformité du eLTS par rapport aux assertions pré/post-conditions), au niveau des composants (préservation de l'inva- riant), des assemblages (le contrat de clientèle entre un service oert et requis) et de composition (encapsulation et correction de la promotion). La vérication de telles propriétés doit s'intégrer aux vérications de propriétés sur les aspects structurels et dynamiques. Dans les deux chapitres suivants, nous détaillons chacune de ces propriétés et dénissons pour chacune d'elles les obligations à vérier, ainsi que la technique de vérication associée.

Chapitre 5

Un cadre pour la spécication et la

vérication de contrats

Dans ce chapitre, nous montrons comment tirer parti des contrats dans la déve- loppement des systèmes à composants. Nous présentons d'abord la notion de contrats multi-niveaux (section 5.1). Ensuite, nous proposons un processus de développement de composants basé sur l'utilisation de contrats (section 5.2). Enn, nous nous in- téressons à deux niveaux de vérication basés sur des obligations de preuve : d'une part, les obligations de preuve intra-composant associées aux composants et à leurs services (sections 5.3) et, d'autre part, les obligations de preuve inter-composants essentiellement liées aux assemblages et aux composites (sections 5.4).

5.1 Notion de contrats multi-niveaux

Comme nous l'avons évoqué dans les chapitres 2 et 3, la plupart des travaux proposent une vérication de type correction structurelle et comportementale d'une architecture. Notre objectif est d'enrichir la description des composants ainsi que leur composition an de vérier leur validité vis-à-vis des aspects fonctionnels. Se- lon [Mey03] : " a Trusted Component is a reusable software element possessing speci- ed and guaranteed property qualities ". La notion de contrat est utile pour modéliser diérents types de propriétés (comme nous l'avons déjà vu dans la section 2.3.7). Par exemple :

 les propriétés structurelles : la compatibilité des signatures d'interface (noms et types) ; est-ce qu'un composant donne assez d'informations sur son (ses) interface(s) an d'être (ré)utilisable par d'autres composants ? La dispo- nibilité des composants requis, la disponibilité des services requis et la correc- tion des interfaces des composants liés ;

 les propriétés fonctionnelles : est-ce que les composants font ce qu'ils sont censés faire ? Ces propriétés peuvent être vériées sur les composants, les assemblages et les compositions ;

 les propriétés comportementales : l'interaction entre deux ou plusieurs composants assemblés est-elle correcte ? Les propriétés dépendent des carac- téristiques du modèle d'interaction : séquentiel ou concurrent, synchrone ou

asynchrone, binaire ou n-aire avec partage de données, synchronisation, etc. Services Composants Assemblages Composites Propriétés structurelles Prop riété s co mpo rtem ental es Propriétés fonctionnelles correction fonctionnelle préservation de l'invariant

compatibilité des assertions conformité des assertions

cohér ence prot ocol e com patib ilité dyn amiqu e confo rmité dyn amiqu e correction du typage cohérence de l’interface compatibilité de signatures et de structure, disponibilité de services iEncapsulation + observabilité Exemple d'un contrat multi-niveaux :

contrat de clientèle

Figure 5.1  Diérents aspects de la modélisation des systèmes à base de compo- sants.

Le contrat de service regroupe, en plus de la signature, la cohérence com- portementale assurant que son exécution ne conduit pas à des états incohérents (tel que l'interblocage) d'une part, et d'autre part la correction fonctionnelle expri- mant le fait qu'un service réalise ce qu'il est censé faire en utilisant l'axiomatique de Hoare. Le contrat de composant prévoit essentiellement l'accessibilité des services (chaîne de dépendance), la cohérence du composant (préservation de son invariant) ainsi que la correction du protocole (enchaînement licite des appels de services). Le contrat d'assemblage est un contrat de clientèle classique mais qui se décline sur trois niveaux de compatibilité. Enn, le contrat de composite est une variante du précédent pour la relation parent/enfant (visibilité, promotion).

An de faire face aux diérentes propriétés susmentionnées, nous introduisons la notion de contrat multi-niveaux (multi-level contract). La gure 5.1 illustre le fait que la correction est vériée à partir des éléments structurels, fonctionnels et comportementaux. Ces derniers peuvent se manifester sous forme de contrats dénis au niveau des services comme des assertions (pré/post-conditions), au niveau des composants comme des invariants à préserver par les services, au niveau des assem- blages pour garantir des propriétés de compatibilité de composants ou au niveau des composites pour s'assurer de la correction des services promus.

Dénition 5.1 Un contrat multi-niveaux est un contrat déni à diérents niveaux de modélisation (service, composants, assemblage, composite) portant sur plusieurs aspects de la modélisation.

Par exemple, le contrat de clientèle exprimé au niveau d'un assemblage se décline sur trois niveaux ; la compatibilité des signatures, la conformité des assertions ainsi

que la compatibilité des comportements. La vision hiérarchique des contrats fournit un cadre pratique pour maîtriser la construction progressive des systèmes à base de composants et le processus de leur vérication en séparant les préoccupations structurelles, fonctionnelles et dynamiques.

Dans la suite, nous présentons les apports des contrats (multi-niveaux) en terme de spécication et de vérication. Notons que les contrats peuvent également être utilisés à des ns de simulation et de test1 _{mais, dans cette thèse, nous nous intéres-}

sons plus à l'utilisation des contrats dans la vérication des systèmes à composants.

5.2 Processus de développement des systèmes à base