Composants

Les contrats occupent une place explicite dans certaines définitions de composants, ainsi Szyperski considère qu’un composant est "a unit of composition with contractu-ally specified interfaces and explicit context dependencies only". On constatera dans cette partie que les contrats sur les composants ne se limitent pas à la définition des interfaces mais contribuent à la garantie des assemblages.

QCCS. Un métamodèle de contrat (figure 2.12) est défini au sein des travaux relatifs à QCCS [95] dans le cadre de la modélisation UML version 1.4 des composants. Ce modèle aborde la garantie de propriété fonctionnelles et non fonctionnelles des inter-faces de composants. En effet celles-ci sont complètement décrites par des contrats, tant pour leur signature que vis à vis de la qualité de service qui repose sur QML [36]. Pour ce faire ces contrats peuvent être composés. Leur mise en oeuvre est envisagée via un tissage dans le code à la manière des aspects. Ce modèle est intéressant par son in-tégration à UML, toutefois seuls les contrats en tant que satisfaction des composants à des spécifications sont envisagés. Par ailleurs, le contrat en lui même n’est pas détaillé, on ne voit ainsi par exemple ni ses clauses, ni son cycle de vie, etc...

FIGURE 2.12 – métamodèle QCCS de contrat

QoSCL. Un autre modèle de contrat, QoSCL [51], est décrit dans le cadre de UML 2.0 (figure 2.13). Ce modèle intervient aussi bien au niveau de la garantie des spécifica-tions des interfaces d’un composant, qu’à celui de la compatibilité de ces spécificaspécifica-tions au sein d’un assemblage de composants. La notion de contrat reprend celle de QML, ainsi un type de contrat associe à une interface un ensemble de dimensions, c’est à dire de grandeurs non fonctionnelles contraintes. Ce contrat est vérifié à l’exécution via son tissage dans le code de l’application. Par ailleurs, les contrats sont des constituants d’un QoSComponent, dérivant de la classe UML Component, dont ils sont requis et fournis. Le formalisme permet d’exprimer qu’au sein d’un composant, il existe des re-lations entre les dimensions des contrats requis et fournis. Les auteurs présentent une méthode de traduction en langage logique de ces relations et dimensions pour chacun des composants. Ils appliquent ensuite à cette description de l’ensemble du système de composants, un solveur de contraintes qui fournit les domaines de valeur accept-ables pour les dimensions des contrats. Ce modèle présente l’intérêt d’expliciter des relations entre clauses du contrat. Par ailleurs même si le contrat ne garantit que l’ad-hérence d’un composant à ses spécifications, l’assemblage de composants est garanti par la vérification de la composition de leurs contrats. Toutefois le problème des re-sponsabilités n’est pas abordé et la garantie de l’assemblage n’est pas l’objet d’un con-trat unique.

GCCL. Dans le cadre des travaux [68] les auteurs définissent un langage de contrat destiné à vérifier la satisfaction des composants à leurs spécifications ainsi que la cor-rection de leurs assemblages, tant du point de vue fonctionnel que non fonctionnel.

FIGURE 2.13 – métamodèle QoSCL de contrat

Ce langage GCCL (Generalized Common Contract Language, figure 2.14) décrit les contrats comme des ensembles de contraintes exprimées à l’aide de pré, post condi-tions et d’invariants appliqués à divers éléments. Il faut noter que ce langage fournit un modèle de l’architecture à laquelle s’applique les contrats, un modèle des carac-téristiques de QoS qu’ils contraignent, un modèle des événements ainsi que des cy-cles de vie des éléments de l’architecture contrainte. L’intégration des contrats dans l’architecture contrainte est ainsi complète. Le modèle événementiel permet de posi-tionner le déclenchement de la vérification des contraintes par rapport aux cycle de vie des entités sur les caractéristiques desquelles elles portent. Comme les contrats prennent en paramètres les composants ou interfaces présentant les grandeurs de QoS qu’ils contraignent, l’adhérence des composants à leur spécification peut être vérifiée à l’exécution. Ces contraintes peuvent par ailleurs dépendre des variables que les con-trats prennent en paramètre, et se retrouver corrélées quand elles en ont en commun. D’autre part, le modèle de caractéristiques de QoS est défini de sorte qu’il soit possible d’appréhender les possibilités de traitement de leurs contraintes par des solveurs. La satisfaction des composants aux contrats peut ainsi être vérifiée statiquement. Finale-ment, des dépendances entre contrats peuvent être définies de diverses manières, par exemple via des paramètres qu’ils partagent. La compatibilité des éléments contractu-alisés et donc la validité des assemblages peut ainsi être vérifiée. Toutefois la notion de responsabilité n’est pas explicitée, ni les rôles des participants au contrat qui n’intervi-ennent qu’en tant que "fournisseurs" de grandeurs contraintes.

Liaison entre comportements et architecture. Un modèle de contrat beaucoup plus orienté vers la garantie de l’assemblage des composants est décrit dans [102] (figure

2.15). Dans celui-ci sont réifiées les spécifications des ports des composants (AssemblyContract), mais aussi celles des liens entre ports (Dependence,Synchronization,LinkBehavior).

Ainsi une connexion entre deux ports est validée par la vérification statique de la com-patibilité de leursAssemblyContractrespectifs, constitués de pré et post conditions écrites dans un langage logique. Le contratDependence, exprime la dépendance com-portementale entre ports d’un même composant, le LinkBehavior entre ports de composants distincts. Ces contrats sont en fait des spécifications des comportements dont la composition fournit celui de l’assemblage de composants, tout en garantissant leur compatibilité. Ce modèle de contrat présente l’avantage d’être très proche de l’ar-chitecture, puisque à chaque relation architecturale correspond un type de contrat. Par ailleurs les contrats comportementaux locaux sont composables afin d’obtenir le

trat de la composition prise globalement. Toutefois, la notion de responsabilité n’est pas abordée dans ces différents contrats. Par ailleurs, comme dans QoSCL, la validité de l’assemblage, c’est à dire la compatibilité de ses constituants est garantie par la com-position des contrats mais pas par un contrat unique réifiant des rôles, responsabilités ..., sur lequel raisonner.

FIGURE 2.15 – métamodèle pour l’analyse de la composition

CQML. CQML [3] est un formalisme de description de qualité de service dédié aux composants (figure 2.16). Il ne réifie pas de contrat mais décrit comment en définir et vérifier un sur la base des termes qu’il fournit. CQML permet de décrire des qualités

(quality) qui sont des contraintes sur des grandeurs de QoS (quality_characteristic).

Un profil (profile) associe un ensemble de qualités à un composant, en distinguant les qualités qu’il requiert (uses) de celles qu’il fournit en échange (provides). Un contrat garantit dans ce cadre la validité d’une composition de composants : "Un con-trat de QoS est un accord au moment du run-time entre des composants collaborants sur la QoS que chaque composant a la responsabilité de fournir". En résumé un trat entre composants est l’association de l’ensemble de leurs profils. Pour que le con-trat soit validé, il faut que ce que les uns fournissent corresponde à ce que les autres requièrent. Il est intéressant de voir apparaître la notion de responsabilité des com-posants et celle de garantie, inhérente aux contrats de la vie courante. Par ailleurs la compatibilité des spécifications fournies et requises est explicitement mise en oeuvre. Toutefois, les correspondances entre profils se font sans tenir compte du détail de l’ar-chitecture, l’ensemble des spécifications fournies doivent satisfaire à chacune de celles qui sont requises.

Requirements and Assurances Contracts. Les Requirements/Assurances Contracts [90] réalisent plus formellement les contrats décrits dans le cadre de CQML. En effet dans cette approche, la spécification des composants comprend des propriétés qu’ils requièrent et d’autres qu’ils fournissent. Il s’agit en particulier des interfaces des com-posants dont le comportement des méthodes est formellement spécifié. Les contrats formellement réifiés (figure 2.17) sur ces bases sont constitués de participants, les com-posants en interaction, et de correspondances entre propriétés requises et fournies par ces derniers. Le contrat est valide dans la mesure ou les correspondances entre pro-priétés requises et fournies sont satisfaites. Ces contrats présentent l’intérêt d’expliciter la notion de compatibilité entre les composants participants au contrat. Il faut noter que les correspondances sont établies sur le rapport entre spécifications de méthode requise

FIGURE 2.16 – Modèle de description de la QoS dans CQML

et fournie, ces clauses de contrats ne sont donc à chaque fois que binaires, même si le contrat peut faire intervenir plus de deux participants. La portée des spécifications des méthodes n’est pas clairement définie, il semble qu’elle recouvre le composant dans son ensemble.

FIGURE 2.17 – Requirements/Assurances Contracts

Conclusion :

Les responsabilités et rôles des composants ne sont pas réifiés dans les contrats rencon-trés. Par contre l’architecture est prise en compte à divers niveaux. L’approche la plus

simple consiste à constater que des composants collaborent et à vérifier que l’associ-ation de leurs spécificl’associ-ations n’est pas contradictoire, comme dans QoSCL et CQML. L’architecture est prise en compte plus finement dans les Requirements/Assurances Contract qui mettent en relation explicitement les parties fournies et requises. Enfin le modèle [102] prend en compte chaque relation entre les composants, mais ne dispose pas d’un contrat global à l’assemblage.