Métamodèle d assemblage de composants par contrats

Métamodèle d assemblage de composants par contrats Auteur : Projet ACCORD (Assemblage de Composants par Contrats en environnement Ouvert et Réparti)* Référence : Lot 1 Livrable 5 Date : Septembre 2003 * : Les partenaires du projet ACCORD sont CNAM, EDF R&D, ENST, ENST- Bretagne, France Telecom R&D, INRIA, LIFL et Softeam. Le projet est conjointement financé par les partenaires et par le RNTL (Réseau National des Techniques Logicielles).

Résumé Dans ce livrable, qui reprend les notions présentées dans le modèle abstrait d assemblage de composants par contrats (livrable 1.4 [ACCORD 2003]), nous présentons un métamodèle basé sur UML permettant la modélisation d applications à base de composants logiciels, en suivant une démarche «MDA» [OMG s MDA]. Les aspects les plus importants de ce métamodèle, en ce sens qu ils sont peu mis en avant et développés dans la première version d UML 2.0 publiée par l OMG [OMG s UML2], concernent d une part la possibilité de réutiliser non seulement des composants, mais également des principes d interaction entre composants, d autre part la modélisation et l usage de contrats pour décrire et assembler des composants. La présentation du métamodèle s appuie sur un exemple de modélisation de «Distributeur» (qui pourrait être un distributeur de boissons, de billets, ) dans le but de montrer comment l usage du métamodèle proposé permet de mieux modéliser les applications à base de composants. Projet RNTL ACCORD Page 2 sur 56

Sommaire Introduction... 4 1 L application «Distributeur»... 5 2 Spécification de composants réutilisables... 6 2.1 Portion du métamodèle dédiée à la spécification de composants... 6 2.2 Exemples de spécification de composants du distributeur... 11 3 Spécification des interactions réutilisables... 12 3.1 Portion du métamodèle dédiée à la spécification des interactions... 12 3.2 Exemples de spécification d interactions réutilisables dans le distributeur... 15 4 Assemblage et délégation pour former des composants «composites»... 17 4.1 Portion du métamodèle concerné par l assemblage et la délégation... 17 4.2 Modifications apportées aux éléments de métamodèle déjà décrits... 19 4.3 Exemples de délégation et d assemblage au sein du distributeur... 19 Délégation... 19 Assemblage... 21 4.4 Mise en œuvre des contrats contrat d interaction... 21 5 Assemblage et délégation incluant l usage de connecteurs-complexes... 22 5.1 Apports des connecteurs-complexes aux modèles d assemblage de composants... 22 5.2 Exemples d assemblages avec connecteurs-complexes dans le distributeur... 23 6 Conclusion... 25 Annexe A : Métamodèle d assemblage de composants par contrats... 27 Annexe B : Format XML d un contrat dans Objecteering... 28 Annexe C : Description détaillée du modèle de composants «Distributeur générique»... 41 Bibliographie... 56 Projet RNTL ACCORD Page 3 sur 56

Introduction Afin de présenter le métamodèle d assemblage de composants par contrats de façon progressive et dans l optique de descriptions indépendantes des composants eux-mêmes et de leurs assemblages, nous avons choisi de prendre seulement les portions du métamodèle concernées par une modélisation particulière. L ensemble complet du métamodèle ACCORD figure en annexe A, et chaque diagramme présenté au cours des divers chapitres y fait référence, et n en montre qu une portion utile pour le cas précis relatif à ce chapitre. Notez que les éléments grisés dans ces diagrammes représentent des concepts très voisins de ceux présents dans UML 2.0. Cette présentation ne prône pas une démarche de modélisation, elle permet seulement de montrer les différents aspects présents dans le métamodèle proposé. Le premier chapitre présente le cahier des charges de l application «Distributeur». Le second chapitre traite de la spécification des composants. L idée principale est d avoir des modèles des «composants sur étagère» que l on peut consulter afin de déterminer leur réutilisation potentielle dans l application que l on souhaite réaliser. Le troisième chapitre s intéresse aux interactions réutilisables et à leur description. Ces «principes d interactions», au même titre que les «composants sur étagère», pourraient être choisis dans une bibliothèque d interactions afin d être appliqués à un ensemble de composants de l application déjà réutilisés ou modélisés. Le quatrième chapitre traite de l assemblage et de la délégation entre deux ports appartenant à des composants distincts. Il expose la mise en œuvre des contrats qui résultent de la confrontation des spécifications des éléments requis ou offerts de part et d autre. Le cinquième chapitre propose l assemblage de composants dans un cadre plus vaste avec l utilisation de connecteurs qui réifient les principes d interaction réutilisables. Projet RNTL ACCORD Page 4 sur 56

1 L application «Distributeur» Le «Distributeur» est utilisable par trois catégories de personnes : Les «clients» qui choisissent le produit désiré, s authentifient (pour paiement), et retirent les produits distribués ; Les «fournisseurs» qui alimentent le ou les stocks du distributeur en produits ; Les «employés de maintenance» qui peuvent vérifier le bon état de fonctionnement du distributeur. Un «Distributeur [figure 1] est formé de composants logiciels de base qui sont : Une interface homme-machine («IHM») permettant aux diverses catégories de personnes de préciser les opérations désirées ; Un composant «Authentification» chargé d identifier chacune des catégories de personnes et de plus, pour le client, de proposer un moyen de paiement adapté à l utilisation du distributeur ; Un composant «Stock» pour le ou les produits à délivrer ; Un composant «Distribution» chargé de prélever un ou des produits du stock et de fournir au client ce qu il souhaite ; Enfin, un composant «coordinateur» qui a un rôle de chef d orchestre relativement aux autres composants du distributeur. Figure 1 : Le composite «Distributeir» et ses composants constituants Une spécification précise et beaucoup plus détaillée figure en annexe C de ce document. A partir de ce cahier des charges, la contrainte est de garder de la généralité dans le modèle plutôt que de s intéresser à un distributeur particulier tel qu un distributeur de boissons, ou un distributeur de billets de banque. Projet RNTL ACCORD Page 5 sur 56

Pour donner quelques exemples, ce choix permet d imaginer : - Le remplacement d un composant d authentification acceptant d un client des pièces de monnaie, par un composant de substitution qui interroge une banque et effectue un prélèvement électronique. - Le regroupement des composants «Stock» et «Distribution» dans un composant «GestionnaireProduit» qui permettrait de réaliser des distributeurs variés en conservant toujours les mêmes composants «IHM», «Authentification» et «Coordinateur». Seuls les paramètres des interfaces des composants tels que les menus d affichage de l IHM, ou le montant à prélever lors de l authentification nécessitant des modifications. - La constitution d un stock de distributeur de boissons à partir d un groupe de stocks de café moulu, de chocolat en poudre, de lait, Ces exemples montrent la possibilité de concevoir au niveau métier des composants très généraux à très spécifiques (CIM : Computation Independent Models), avec dans chacun de ces cas la possibilité d effectuer des raffinements successifs pour passer de modèles indépendants de toute plate-forme (PIM : Platform Independent Model) à des modèles liés à une plate-forme d implantation (PSM : Platform Specific Models). La proposition d une démarche précise à effectuer dans le développement de ces modèles n est pas l objectif du projet ACCORD, et nous essaierons simplement de montrer au travers des divers exemples que la richesse du métamodèle proposé peut couvrir l ensemble de la modélisation CIM-PIM-PSM propre à la démarche MDA (Model Driven Architecture) de l OMG.[OMG s MDA]. 2 Spécification de composants réutilisables 2.1 Portion du métamodèle dédiée à la spécification de composants Le diagramme de classes [figure 2] présente ce qui est utile à la spécification de composants. C est la notion de «type» de composant du modèle abstrait (livrable 1.4 [ACCORD 2003]) qui est ici présentée, c'est-à-dire la description des services rendus par le composant, sans préciser son implémentation (notion de classe de composant) ni la façon dont il sera déployé (notion d instance). Il faut noter que la spécification d un type de composant consiste à décrire le service (ensemble d interfaces) qu il peut fournir. Dans la [figure 2], on voit les éléments port et opération qui font déjà référence à un choix d implémentation en regroupant des interfaces et en précisant sur quelle(s) opération(s) va s appuyer le service offert. En toute logique, ces deux éléments ne devraient apparaître qu avec la notion de classe de composant. La justification de leur présence réside dans le fait que la spécification stricto sensu d un composant par ses services manque d informations pour un concepteur qui s appuie sur la réutilisabilité des composants. Celui-ci aura très rapidement besoin de savoir comment il peut utiliser le composant dans son architecture, et si un composant sur étagère peut correspondre à ses besoins. Toutefois, le métamodèle présenté n interdit pas de regrouper toutes les interfaces du composant dans un seul port vu comme le «service» global offert par le composant tel qu il est défini dans le glossaire du livrable 1.4. Projet RNTL ACCORD Page 6 sur 56

Figure 2 : Portion du métamodèle pour la spécification de composants. Opération (Operation) La classe opération contient le nom et la signature de l opération considérée. La signature d une opération décrit les types et noms des paramètres, le type de retour et les types d exception qui peuvent être levées par l opération. Association : o une opération est rattachée à une et une seule interface. C est un élément auquel on peut attacher un contrat. Un contrat est généralement décrit par un ensemble de pré-conditions, de post-conditions et d invariants. Les pré-conditions et invariants doivent être satisfaits lors de l appel de l opération, sinon l appelant est fautif et est à l origine de disfonctionnements éventuels. Les post-conditions et invariants doivent être satisfaits lors de la fin de l exécution de l opération, sinon l implémentation de cette opération est défectueuse. Interface Une interface regroupe un ensemble d opérations définies autour de données communes, ou utilisées conjointement. L interface garantit que toute implémentation réalisera l ensemble des opérations qu elle regroupe, assurant ainsi une indépendance entre l implémentation et le service proposé ou requis. Associations : o une interface possède un ensemble non vide d opérations ; o une interface n est pas nécessairement attachée à un port, et la même interface peut apparaître dans plusieurs ports distincts. Projet RNTL ACCORD Page 7 sur 56

C est un élément auquel on peut attacher un contrat. Par exemple, on peut préciser globalement que les opérations d une interface sont toutes synchrones (l appelant reste en attente de la fin d opération) ou asynchrones (l appelant invoque l opération et effectue aussitôt autre chose pendant que l opération invoquée se déroule). On peut aussi préciser que des opérations doivent être en exclusion mutuelle : Contrat de pile de données informatiques : Facette synchronisation avec exclusion mutuelle ; Clause : Empiler (élément) et Dépiler( ) ne peuvent être effectuées simultanément.. Port Un port permet d isoler un composant logiciel de son environnement en fournissant un point d interaction adressable. Le port permet ainsi de circonscrire en un point précis les échanges entre le composant et son environnement extérieur ; il rassemble une ou plusieurs interfaces pour offrir ou requérir un élément de service. Un exemple simple de port peut être donné avec un composant «Banque» disposant des interfaces «Consultation de compte bancaire», «Opérations boursières et de virements», «Retrait d espèces». Un accès par Internet à cette banque ne proposerait que les deux premières interfaces ; un GAB (Guichet Automatique de Banque) offrirait les trois. On peut les voir comme deux ports pour accéder au composant «Banque». Associations : o un port possède un ensemble non vide d interfaces ; o un port fait partie d un composant (agrégation), et d un seul. Un contrat peut porter sur un port. L exemple précédent du composant «Banque» peut définir un contrat «Sécurité des transactions» différent pour les deux ports. Composant (Component) Le composant logiciel permet de structurer les applications en pièces interchangeables et facilement réutilisables. Son objectif est d offrir les mêmes possibilités de composition qui existent pour les composants matériels, avec la souplesse d adaptation du logiciel en plus. Association : o un composant est composé d au moins un port. Un exemple de contrat concernant un composant peut être donné avec la persistance ou non de ses données entre deux utilisations successives. Le composant peut ainsi recouvrer son état antérieur ou être initialisé de la même façon à chaque utilisation. Note concernant les éléments grisés : Dans un souci de simplification de la présentation, on n a pas détaillé les possibilités d héritages, ou la possibilité de disposer d attributs ou de propriétés pour les méta-classes composant, port, interface et opérations. Il va de soi que l héritage pour les interfaces et la redéfinition d opérations est toujours possible. Projet RNTL ACCORD Page 8 sur 56

Cependant, l héritage concernant les ports ou les composants nécessiterait une étude détaillée comme mentionné dans le livrable 1.4. Pour les attributs ou propriétés que l on pourrait attacher à ces éléments, il nous semble préférable de les ignorer car elles n influent pas sur la spécification et l assemblage des composants. Stéréotype d élément «contractualisé» (ContractableElement) Précise les éléments auxquels on peut attacher un contrat. Contrat (Contract) Le contrat de type est une spécification permettant d évaluer les différents aspects d un composant réutilisable, disponible sur étagère. Il est organisé en facettes qui décrivent des critères que l on peut mettre en confrontation lors d un assemblage. Association : o un contrat est constitué d un ensemble non vide de facettes Facette (Facet) Une facette présente un aspect particulier du contrat, on a indiqué ici les facettes sémantique et pragmatique qui décrivent respectivement la fonction précise réalisée, et des critères non fonctionnels relatifs à l implémentation future des éléments. Dans la facette sémantique, on pourra trouver l expression de contraintes sur le séquencement ou le parallélisme de certaines tâches, les invariants, les pré-conditions et post-conditions à respecter. Dans la facette pragmatique, on pourra faire figurer des critères de performance mesurables tels que le temps de réponse, une mesure de complexité des algorithmes utilisés, etc. La décomposition en facettes syntaxiques, sémantiques et pragmatiques est proche de la classification des contrats décrite dans [A. Beugnard 1999]. La facette syntaxique concerne la mise en correspondance des signatures d opérations, et intervient lors d un assemblage. Elle n apparaît donc pas dans la [figure 2], mais sera présentée au chapitre 4. Association(s) : o une facette est rattachée à un contrat et à un seul ; o une facette est composée d un ensemble non vide de clauses. Clause La clause contient l information relative à la description du critère considéré dans la facette. Elle peut s exprimer de différentes manières, le cas le plus simple étant un texte descriptif de la contrainte à respecter, ou bien par une expression plus formelle utilisable avec un outil (un interprète OCL par exemple). En cela, la clause est très proche de la notion de «constraint» présente dans UML 2. Projet RNTL ACCORD Page 9 sur 56

Cependant, il est parfois nécessaire d exprimer la contrainte par un diagramme où l on doit pouvoir référencer les éléments concernés par cette contrainte. Cette notion de référence à des diagrammes n existe pas en UML. Un exemple de telle clause est présenté [figure 3], il est issu du cas d étude d EDF où p1 et p2 sont des ports respectivement de configuration et d échange (livrable 3.6 [ACCORD 2003]). el_1 : Coordination [contrat pragmatique du composant/service] attendre(p1.init) init(fichier_couplage, nb_connexion) increment(nb_connexion) attendre(p2.req ) decrement(nb_connexion) connecter() choix(req) deconnecter() nb_connexion nb_connexion>1 lire_intervalle( ) lire_sequentiel( ) lire( ) lire_iter( ) lire_instant( ) ecrire_iter( ) ecrire_temp( ) ecrire( ) nb_connexion=1 gérer_exception() Figure 3 : un exemple de clause décrivant une contrainte de coordination d interfaces Association : o une clause est rattachée à une et une seule facette. Dans le métamodèle, la clause est le plus souvent une simple «Expression», au sens d UML 2, avec le formalisme pour lequel elle a une signification et son expression textuelle. La référence à un diagramme permet de mettre en évidence qu une clause peut nécessiter une forme plus complexe d expression [figure 4]. Toutefois, UML n interdit pas de nommer des diagrammes et d utiliser ces noms dans des expressions. Figure 4 : Portion du métamodèle pour la spécification d une clause Projet RNTL ACCORD Page 10 sur 56

Il semble naturel de pouvoir hériter d un contrat pour définir un nouveau contrat, de pouvoir redéfinir certaines clauses, ou de pouvoir réutiliser une facette ou une clause dans deux contrats différents. C est une des raisons pour laquelle une mise en oeuvre possible des contrats consisterait à leur faire correspondre la notion d interface, et aux clauses la notion d opération de vérification. Une vérification du contrat peut alors être réalisée par une implémentation de l interface qui lui correspond avec les opérations concrètes de vérification de chacune de ses clauses. Les possibilités d héritage et de re définition découlent alors de celles des classes et des opérations. Ces possibilités d implémentations des contrats sont toutefois hors du cadre du projet ACCORD. 2.2 Exemples de spécification de composants du distributeur Pour illustrer la spécification de composants, on va considérer les composants «Stock» et «Distribution» qui peuvent être associés pour former un assemblage, et ainsi conjointement un nouveau composant. C est cet exemple qui nous servira pour la présentation des contrats au cours des chapitres suivants. Du point de vue métier, on veut pouvoir distinguer des composants «Distribution» qui incluent un procédé de fabrication nécessitant la préhension d un certain nombre d ingrédients dans un ordre prédéterminé, de ceux qui ne font que délivrer des objets manufacturés pris dans un stock, sans les transformer. Pour les composants «Stock», on veut pouvoir distinguer ceux qui ne permettent de consommer qu un seul produit à la fois (même si le stock est lui-même composé de stocks de produits divers), de ceux qui permettent de délivrer un mélange de produits en une seule étape, et de ceux enfin qui permettent de délivrer une séquence de produits incluant éventuellement des mélanges. On définit ainsi des contrats que l on peut attacher aux composants, mais également aux ports de «consommation» coté composant «Distribution» et aux ports de «fourniture» coté composant «Stock» en définissant une facette «produits» avec le critère mono/multi et une facette «procédé» avec un critère simultanéité/configurable. Pour illustrer ces concepts, on peut concevoir divers distributeurs de boissons dont on a illustré quelques conceptions de la zone «Stock-Distribution» dans la [figure 5]. Les ports sont représentés par des rectangles en bordure des composants, les contrats par une feuille à l aspect déroulé. Les contrats de spécification des composants et des ports sont normalement rattachés aux éléments sur lesquels ils portent: Pour clarifier la figure, on a mis un numéro au niveau des ports pour référencer le contrat qui lui est rattaché. Les assemblages licites que l on pourrait effectuer sont présentés par des traits reliant un port de «Stock» à un port de «Distribution». On peut y noter que le contrat 3 peut se substituer là où les contrats 1 ou 2 sont utilisés : on peut utiliser un stock multi-produits configurable pour en fait ne proposer qu un seul produit ou un mélange de produits en une seule étape. Projet RNTL ACCORD Page 11 sur 56

L assemblage «Distribution ::Cannettes» avec «Stock ::Stock_gobelets» peut paraître licite du fait que les ports portent le même contrat, l incompatibilité devrait apparaître lors de la confrontation des interfaces, de types incompatibles. Figure 5 : Exemples de spécifications des composants «Stock» et «Distribution» 3 Spécification des interactions réutilisables 3.1 Portion du métamodèle dédiée à la spécification des interactions Le groupe de travail ACCORD a introduit une notion de connecteur multi-points permettant d assembler des composants autour d une interaction commune, décrite par ce connecteur. Il est appelé connecteur-complexe pour éviter une confusion avec le connecteur bi-points d UML 2. Des exemples d interactions entre composants sont donnés dans la thèse d E. Cariou [E.Cariou 2003]. Pour reprendre un de ces exemples qui illustre bien la notion de connecteurcomplexe, on peut considérer un système de banque vidéo où les clients votent pour choisir un film à diffuser, puis reçoivent la diffusion du film ayant obtenu le plus de suffrages. Une architecture sans connecteur-complexe pourrait être celle présentée [figure 6]. Elle oblige à dupliquer dans chaque client des composants (vote et diffusion-réception) qui réalisent une interaction avec la banque vidéo. Cette conception non seulement complique la conception des clients, mais également la conception du système de vote ou de diffusion car au lieu Projet RNTL ACCORD Page 12 sur 56

d avoir une modélisation claire de l interaction, il faut aller consulter les composants serveur et client pour s en faire une idée précise. La seconde architecture [figure 7] met en œuvre deux connecteurs-complexes qui permmetent de concevoir des interactions de vote et de diffusion réutilisables dans de multiples applications. Figure 6 : Système de banque vidéo sans connecteur-complexe On constate également que la conception des clients et du serveur est nettement simplifiée par l utilisation uniquement d un port avec ses interfaces de service nécessaires pour jouer un rôle dans l interaction vote ou diffusion. Figure 7 : Système de banque vidéo avec connecteurs-complexes Projet RNTL ACCORD Page 13 sur 56

Les éléments du métamodèle nécessaires à la spécification d interactions sont présentés dans la [figure 8]. Ils ne font que compléter les possibilités de spécification de composants réutilisables vues au chapitre 2. Une spécification d interaction repose sur les deux nouveaux éléments connecteur-complexe et prise que nous allons maintenant préciser. Figure 8 : Portion du méta_modèle pour la spécification d interactions Connecteur-complexe (ComplexConnector) Le connecteur-complexe est un composant spécifique, chargé de réaliser une interaction entre composants. Il dispose de prises qui précisent le rôle joué par le composant relié au connecteur-complexe dans l interaction. Dans notre exemple précédent, pour l interaction de diffusion, il existe des prises distinctes pour les récepteurs et pour l émetteur du flux vidéo. En tant que composant, le connecteur-complexe possède au moins un port. Le ou les ports qu il possède permettent de gérer l interaction que le connecteur-complexe représente, c'est-àdire soit de configurer l interaction avant sa mise en œuvre, soit d agir sur elle au cours de son fonctionnement. Dans notre exemple la banque vidéo, en plus de sa connexion à l interaction de vote par une prise afin de collecter les résultats, peut aussi utiliser un port de cette interaction pour initier et paramétrer la procédure de vote. Associations : o Un connecteur-complexe est composé d un ensemble non vide de prises ; o Il dispose également d au moins un port, de part son héritage de composant. Le connecteur-complexe, au même titre qu un composant, peut avoir un contrat de type pour spécifier l ensemble des services qu il offre. Prise (Plug) La prise est une forme spécifique de port, elle dispose d interfaces comme lui, mais celles-ci ne sont pas nécessairement explicitées. Projet RNTL ACCORD Page 14 sur 56

Un bus Corba, par exemple, possède des prises «skeleton» et «stub» permettant de décrire une interaction entre deux composants en distinguant la réalisation d une opération ou l appel d opération distante au niveau de chaque entité connectée. La compatibilité des interfaces IDL correspondantes est dérivée de la compatibilité des interfaces des composants connectés. Il n est donc pas nécessaire de montrer explicitement ces interfaces. Les prises jouent ainsi un rôle d acheminement au travers du connecteur-complexe des flux de contrôle et/ou de données entre les composants connectés. Associations : o une prise possède un ensemble éventuellement vide d interfaces (elle hérite de port avec une contrainte); o une prise fait partie d un connecteur-complexe, et d un seul; o plusieurs prises peuvent être associées à un même port (port d un composant intervenant dans plusieurs interactions), mais une prise ne peut être attachée à plus d un port (elle ne peut pas concerner plusieurs ports simultanément). Cette association complète les possibilités d assemblage de ports que nous détaillerons au chapitre 4. Un contrat peut porter sur une prise. Il sera confronté au contrat de port d un composant relié par cette prise au connecteur-complexe, et permettra de déterminer ainsi la possibilité ou non d assemblage port-prise. 3.2 Exemples de spécification d interactions réutilisables dans le distributeur Notre propos, ici, est de montrer la faible dépendance entre les conceptions de chacun des composants «IHM»,»Authentification», «Stock» et «Distribution» et celle du connecteur-complexe chargé de la coordination de ces composants. La première interaction consisterait pour le client à choisir le produit à délivrer et à l obtenir aussitôt. Le paiement pouvant s effectuer à l avance ( le composant «Authentification» accepte par exemple des pièces de monnaie jusqu à ce que la somme versée permette de choisir quelque chose), ou bien après obtention du produit ( cas d un composant «Authentification» effectuant un prélèvement sur carte bancaire lorsque la distribution a correctement fonctionné). La seconde interaction consisterait pour le client à sélectionner un produit à délivrer, à obtenir un code d accès pour récupérer son produit lorsqu il sera prêt, enfin à utiliser le code d accès pour obtenir son produit. Le choix d un paiement à l avance ou à la livraison doit être conservé. Dans la première interaction, on peut prendre des exemples de distributeurs de boissons à jetons ou à pièces, de distributeurs de billets de banque. Pour la seconde interaction, il serait possible d imaginer un distributeur de pizzas qui fabrique la pizza demandée et la livre prête à manger, ou d un distributeur de T-shirts imprimés ou le motif d impression est choisi par le client lors de sa commande. Une modélisation possible de ces interactions est présentée [figure 9]. Projet RNTL ACCORD Page 15 sur 56

Les ellipses figurent les connecteurs-complexes, les ronds sur ces ellipses les différentes prises, pour reprendre la notation définie dans le modèle abstrait. Dans cet exemple, les connecteurs-complexes de paiement disposent d un port permettant de connaître le choix effectué par le client et un port pour le paiement du produit correspondant. Ceci permet de connecter les connecteurs-complexes de distribution à l un au choix des deux services de paiement. Figure 9 : Spécification d interactions pour la réalisation de familles de distributeurs Le connecteur-complexe «distribution différée» utilise un composant supplémentaire pour gérer les commandes en cours et mémoriser les correspondances entre clients et produits demandés (avec leur date de disponibilité). En ce qui concerne la distribution du produit demandé par le client, on peut se relier à un quelconque des composants «Distribution» présents dans la [figure 5]. Donnons quelques exemples de contraintes induites sur les composants par la spécification de facettes de contrats propres aux connecteurs-complexes : Annulation du paiement dans le cas d un disfonctionnement de la distribution Facette «Procédé de prélèvement conditionnel» Projet RNTL ACCORD Page 16 sur 56

Clause : Pré-conditions (Solvabilité du client ET Distribution opérationnelle) Post-conditions (Distribution effectuée ET Validation du prélèvement) OU ((NON Distribution effectuée) ET Annulation du prélèvement) Un tel contrat va nécessiter : - pour l interface de Distribution un compte-rendu d opération ; - pour le composant d Authentification une interface de paiement du produit comprenant des opérations de contrôle de solvabilité, de validation ou d annulation de paiement. Report des disponibilités de produits dans la distribution au niveau de l IHM Facette «Sélection de produits» Clause : Produits disponibles «inclus» Choix du client. Cette clause est instanciée lors d une interrogation du composant «Distribution» dans le contrat du même nom, puis utilisée au travers du contrat «Choix du produit» dans l IHM. Ceci implique un retour d information sur l état des stocks, ou des procédés de fabrication, dans les interfaces des composants «Distribution» utilisés. 4 Assemblage et délégation pour former des composants «composites» Dans ce chapitre, nous allons présenter les notions d assemblage sans faire usage de connecteurs-complexes ( c'est-à-dire de composants d interaction réutilisables). On utilise donc les mêmes éléments d assemblage que ceux figurant dans UML 2, mais avec des notions complémentaires de contrats d assemblage. Dans le glossaire du modèle abstrait, la notion de «composite» est celle d un assemblage de composants pour constituer un nouveau composant. L association «contains» présente dans le métamodèle de la [figure 10] est dérivée des délégations et assemblages qui rendent un composant membre d un composite. Elle est donc redondante, mais explicite clairement la composition de composants et permet une navigation simple d un composite vers ses constituants internes. Nous ne présentons dans ce chapitre que l utilisation de connecteurs UML pour assembler les composants, en réservant le chapitre 5 à des assemblages comportant des connecteurscomplexes. 4.1 Portion du métamodèle concerné par l assemblage et la délégation La distinction entre assemblage et délégation relève de la nature des interfaces mises en connexion. La nature d une interface précise si le service rendu disponible par l interface est offert ou requis. Lorsque les interfaces reliées sont de même nature (requis/requis ou offert/offert), on parle de délégation. C est le cas d un composant qui offre un service réalisé en fait par un de ses constituants interne, ou dont un composant interne requiert un service qu il est obligé de faire figurer dans ses services requis. Lorsque les interfaces sont de natures différentes (requis/offert), on parle d assemblage. La nature des interfaces est révélée par les contrats qu elles portent. Cette nature peut également n apparaître que pour les besoins d assemblage des composants. Une communication «pier to pier», par exemple, est symétrique du point de vue requis/offert Projet RNTL ACCORD Page 17 sur 56

lorsqu elle est opérationnelle. Il faut préciser par des contrats lequel des deux interlocuteurs doit initier cette transaction, ou préciser le procédé de gestion des connexions éventuellement initiées parallèlement. Ces spécifications vont permettre ou non l assemblage des deux composants interlocuteurs. C est pourquoi dans la [figure 10] n apparaît pas la distinction entre assemblage et délégation qui sont confondues dans le connecteur. Connecteur (Connector) Le connecteur permet de représenter l assemblage ou la délégation entre 2 ports (en général de deux composants distincts, mais non nécessairement). Les contraintes imposées dans UML 2 sur le connecteur telles que la correspondance d une interface requise avec son implémentation du coté opposé, ou la conformance des types sont reportées dans les contrats d assemblage et de délégation.. Association o Le connecteur est composé d exactement deux «extrémités de connecteur» Figure 10 : Portion du métamodèle concernant la réalisation de «composites» Extrémité de connecteur (ConnectorEnd) Associations o Une extrémité fait partie d un et un seul connecteur ; o Une extrémité n est reliée qu à un et un seul port. Projet RNTL ACCORD Page 18 sur 56

4.2 Modifications apportées aux éléments de métamodèle déjà décrits Un port peut être utilisé dans le cadre de plusieurs assemblages ou délégations, il est associé à un ensemble éventuellement vide d extrémités de connecteurs. L établissement d un connecteur entre deux ports fait apparaître la notion de contrat proprement dit entre deux, ou plus de deux, éléments «contractualisés». Il s agit d un moyen terme entre chacune des spécifications de ces éléments, moyen terme qui comme un contrat dans la vie réelle satisfait les deux parties. Dans le cas trivial, le contrat est simplement une union des deux spécifications mises en confrontation avec conservation des clauses de facettes les plus restrictives. Dans le cadre de la délégation, le contrat permet de savoir ce qui est délégué au composant interne. L ensemble des services offerts par le composite ne provient en général pas d un seul composant interne, et le contrat sert à montrer la répartition de ces services externes à l intérieur même du composite. En terme de méta-classe contrat, on trouve maintenant des contrats de classe et d instance qui précisent comment va être conçu le composite, de quelles instances de composants sur étagères il va faire usage. Les contrats d instances sont relatifs au déploiement et à la configuration des instances, mais peuvent être utiles pour un composant connecteur-complexe où l on peut préciser quelle partie du composite sera destinée à un déploiement auprès de chaque client de l interaction modélisée. La facette syntaxique apparaît pour mettre en confrontation les signatures d opérations dans les interfaces des deux ports mis en connexion. Elle permet de gérer l adaptation éventuelle des interfaces pour réaliser un assemblage syntaxiquement cohérent. 4.3 Exemples de délégation et d assemblage au sein du distributeur Délégation Pour la délégation, nous allons prendre l exemple de la confidentialité des informations dans le cadre d un distributeur utilisant un système de paiement par carte bancaire. La [figure 11] présente l architecture de ce distributeur. On pourrait trouver au niveau de la facette de confidentialité du distributeur : - Cryptage des informations de la bande magnétique de la carte au moyen de la puce, en utilisant comme amorce le code confidentiel saisi; - Transaction avec un protocole sécurisé (IPSec, ATM, ) entre la banque et le distributeur ; - Destruction des données cryptées provenant de l IHM dès que la transaction bancaire est accomplie. Projet RNTL ACCORD Page 19 sur 56

Figure 11 : Spécifications de sécurité au niveau des ports de chaque composant Les contrats vont permettre dans ce cas de transférer la responsabilité de chacun des items présents dans la spécification générale vers les composants respectifs IHM, Authentification et coordinateur comme cela est présenté [figure 12]. Figure 12 : Contrats relayant les termes du contrat global du composant au niveau de chacun de ses constituants spécifiques. Projet RNTL ACCORD Page 20 sur 56

Assemblage Pour l assemblage de composants, nous allons reprendre l exemple de la [figure 5] où l on assemble les composants «Stock» et «Distribution». Nous avions une facette «produits» (un seul produit / multi-produits) et une facette «procédé» (simultanéité dans la distribution / configurable, autorisant une combinaison d actions séquentielles ou simultanées). Les contrats vont préciser l usage réel du composant, avec les services strictement nécessaires pour l assemblage considéré. Même si un composant peut offrir plus, seuls les termes du contrat d assemblage sont considérés, et doivent être satisfaits. La [figure 13] illustre des contrats qui émanent des spécifications les plus contraintes des deux ports assemblés. Pour ne pas alourdir la figure, seuls ont été présentés les contrats dans l assemblage de droite, car les spécifications sur chacun des deux ports mis en relation sont identiques à ce contrat. Figure 13 : contrats d assemblage entre «Stock» et «Distribution» 4.4 Mise en œuvre des contrats contrat d interaction Dans les exemples que nous avons donnés, on voit surtout des contrats associés à des ports, alors que dans le métamodèle les composants, ports, interfaces et opérations peuvent tous disposer de contrats. De même, on s est généralement concentré sur une facette particulière d un contrat, alors qu en général un contrat est «compatible» pour deux spécifications confrontées lorsque toutes les facettes de ce contrat permettent de mettre en accord les diverses facettes des deux spécifications considérées. Ces deux problèmes sont liés à la façon dont on va utiliser et confronter l ensemble des éléments constituant une spécification requise avec ceux d une spécification offerte. Le but étant de déterminer, à l issu de cette confrontation, si les deux spécifications sont compatibles Projet RNTL ACCORD Page 21 sur 56

et donc si les entités qu elles représentent (composant, port, interface ou opération) peuvent être associées dans le cadre d un assemblage ou d une délégation. Nous donnons le nom de «contrat d interaction» à ce procédé d examen des contrats, de leurs facettes et clauses respectives. Il ne figure pas dans le métamodèle car il sera très lié à l outil de modélisation et aux formalismes choisis pour exprimer des clauses. Il est sousjacent au connecteur UML 2. Dans le livrable 1.3 [ACCORD 2003], on a montré comment la propagation de contraintes le long des assemblages permet d obtenir une information de qualité de service globale d un composant à partir des qualités de chacun de ses constituants. La propagation peut également être utilisée en sens contraire, en déterminant a priori les qualités souhaitées pour un assemblage et en sélectionnant des constituants sous contraintes. Un schéma XML est proposé en annexe pour l expression et l usage des contrats. 5 Assemblage et délégation incluant l usage de connecteurscomplexes 5.1 Apports des connecteurs-complexes aux modèles d assemblage de composants La [figure 14] présente les éléments du métamodèle relatifs à l association de composants et de connecteurs-complexes en vue de réaliser des composites ou des applications. Il n y a pas d éléments nouveaux introduits, tous ont déjà été décrits précédemment. Figure 14 : Portion du métamodèle concernée par l assemblage avec connecteurs-complexes Projet RNTL ACCORD Page 22 sur 56

L association entre prise(plug) et port est dérivée de celle qui existe entre deux ports via un connecteur et deux extrémités de connecteur (associations Connector-ConnectorEnd-Port). C est pour rendre plus explicite les assemblages entre port et prise que l on a introduit ce lien. Cette association entre prise et port précise par une contrainte qu il n est pas nécessaire d expliciter d interfaces dans le cas d une prise. Dans le cas général, on n envisage pas de connecter deux prises ensemble, bien que le métamodèle n impose pas de contrainte sur les types des éléments aux extrémités d un connecteur. La délégation et l assemblage se font de la même façon que pour les composites tel que cela a été décrit au chapitre 4. Le connecteur-complexe agit dans ce cas comme un connecteur simple, mais en autorisant une délégation à plusieurs constituants internes ou un assemblage avec plus de deux parties. La notion de rôle porté par les prises d un connecteur-complexe permet d ajouter des contraintes supplémentaires sur les composants qui peuvent y être raccordés. 5.2 Exemples d assemblages avec connecteurs-complexes dans le distributeur Le premier exemple [figure 15] considère un composant «Stock» constitué lui-même de plusieurs stocks. Le connecteur-complexe mis en œuvre ici est une délégation «1 parmi N» qui assure qu une commande «consommer» au plus haut niveau est reportée sur l un des stocks internes. Figure 15 : connecteur-complexe jouant un rôle de délégation Nous illustrons un assemblage au moyen d un connecteur-complexe dans la [figure 16]. Son rôle est de pouvoir constituer un stock qui fournisse de façon simultanée plusieurs produits, en combinant à volonté des stocks internes mono-produit et multi-produits. La contrainte qui porte sur ce connecteur, et les stocks connectés, est l obtention préalable du délai séparant l ordre «consommer» de la fourniture du ou des produits d un stock particulier. Le connecteur-complexe doit, connaissant les délais propres à chaque stock connecté, agencer les divers ordres «consommer» afin que la fourniture soit simultanée pour l ensemble des stocks connectés. Projet RNTL ACCORD Page 23 sur 56

Dans cet exemple, les prises doivent être distinguées en trois catégories : les prises_s (comme singulier) pour connecter des stocks à un seul produit en nombre quelconque(multiplicité *) ; les prises_p (comme pluriel) pour connecter des stocks délivrant un ensemble de produits de façon simultanée (multiplicité * également) ; enfin une seule prise_a (pour assemblage) qui permet de voir cet ensemble de stocks comme un seul stock avec un délai fonction du plus lent de ses constituants internes. Un exemple de connecteur-complexe pouvant ajouter une contrainte sur les composants qui lui sont connectés est le caractère synchrone ou asynchrone des interactions entre composants. Dans ce cas, le connecteur choisi peut influer sur le comportement de chacun des composants qui lui sont rattachés. Figure 16 : connecteur-complexe jouant un rôle d assemblage Projet RNTL ACCORD Page 24 sur 56

6 Conclusion Ce document a présenté l ensemble des notions relatives au profil d assemblage de composants qui est basé sur les concepts de composant, de connecteurs et de ports introduits dans la dernière version d UML proposée à l OMG. Les éléments du métamodèle ACCORD peuvent être dérivés vers des plateformes à base de composants, telles que EJB ou CCM dans le cadre du projet, ceci permettant de modéliser des composants ou des applications indépendamment des plateformes. La vérification des contrats pour déterminer la réelle compatibilité des composants assemblés reste actuellement délicate à automatiser. Cependant, l architecture proposée clarifie le rôle des spécifications et des contrats qui permettent de les confronter en examinant les divers aspects qui les concernent : descriptions du rôle du composant et de sa décomposition (type/classe et instance) ; raffinement du contrat du composant en contrats pour ses ports,ses interfaces,ses opérations ; cloisonnement des contrats en clauses comparables par utilisation de facettes destinées à mettre en œuvre des outils compatibles de vérification de contraintes. Projet RNTL ACCORD Page 25 sur 56

ANNEXES Projet RNTL ACCORD Page 26 sur 56

Annexe A : Métamodèle d assemblage de composants par contrats Projet RNTL ACCORD Page 27 sur 56

Annexe B : Format XML d un contrat dans Objecteering Un contrat est une spécialisation de commentaires (note) dans l outil. Son contenu est un texte XML qui est structuré comme suit : <CONTRACT KIND = Type/Class/Instance> <FACET KIND = Semantic/Pragmatic/Syntactic> <CLAUSE LANGUAGE = Textual/OCL/...> DATA / DIAGRAM_REFERENCE </CLAUSE> (1..*) </FACET> (1..*) </CONTRACT> Une description plus détaillée, sous forme de schéma XML est également présentée ci-après. Projet RNTL ACCORD Page 28 sur 56

Schema ContratAccord2.xsd schema location: C:\accord\ContratAccord.xsd Elements contracts Complex types ContractType element contracts diagram children specification contract source <xs:element name="contracts"> <xs:complextype> <xs:all> <xs:element name="specification" minoccurs="0"> <xs:complextype> <xs:complexcontent> <xs:extension base="contracttype"/> </xs:complexcontent> </xs:complextype> <xs:element name="contract" minoccurs="0"> <xs:complextype> <xs:complexcontent> <xs:extension base="contracttype"> <xs:sequence> <xs:element name="status"> <xs:complextype> <xs:attribute name="state" type="xs:string"/> </xs:complextype> </xs:sequence> </xs:extension> </xs:complexcontent> </xs:complextype> </xs:all> </xs:complextype> Projet RNTL ACCORD Page 29 sur 56

element contracts/specification diagram type extension of ContractType children propertiesconformityref propertiesexclusionref variablesuseref variable clause facet contractconformityref attributes Name Type Use Default Fixed Annotation id xs:id required type xs:string required name xs:string optional source <xs:element name="specification" minoccurs="0"> <xs:complextype> <xs:complexcontent> <xs:extension base="contracttype"/> </xs:complexcontent> </xs:complextype> Projet RNTL ACCORD Page 30 sur 56

element contracts/contract diagram type extension of ContractType children propertiesconformityref propertiesexclusionref variablesuseref variable clause facet contractconformityref status attributes Name Type Use Default Fixed Annotation id xs:id required type xs:string required name xs:string optional source <xs:element name="contract" minoccurs="0"> <xs:complextype> <xs:complexcontent> <xs:extension base="contracttype"> <xs:sequence> <xs:element name="status"> <xs:complextype> Projet RNTL ACCORD Page 31 sur 56

<xs:attribute name="state" type="xs:string"/> </xs:complextype> </xs:sequence> </xs:extension> </xs:complexcontent> </xs:complextype> element contracts/contract/status diagram attributes Name Type Use Default Fixed Annotation state xs:string source <xs:element name="status"> <xs:complextype> <xs:attribute name="state" type="xs:string"/> </xs:complextype> Projet RNTL ACCORD Page 32 sur 56

complextype ContractType diagram children propertiesconformityref propertiesexclusionref variablesuseref variable clause facet contractconformityref used by attributes annotation elements contracts/contract contracts/specification Name Type Use Default Fixed Annotation id xs:id required type xs:string required name xs:string optional documentation Basic contract structure. Attributes: ID/name are identifiants; type can be source <xs:complextype name="contracttype"> <xs:annotation> <xs:documentation>basic contract structure. Attributes: ID/name are identifiants; type can be </xs:documentation> </xs:annotation> <xs:choice> <xs:sequence> <xs:element name="propertiesconformityref" minoccurs="0"> <xs:annotation> <xs:documentation>reference to properties (from another facette or a single property) that must be respected</xs:documentation> </xs:annotation> <xs:complextype> Projet RNTL ACCORD Page 33 sur 56

<xs:sequence> <xs:element name="aliases" minoccurs="0" maxoccurs="unbounded"> <xs:annotation> <xs:documentation>add this section to locally rename imported variables</xs:documentation> </xs:annotation> <xs:complextype> <xs:attribute name="originalname" type="xs:string" use="required"/> <xs:attribute name="newname" type="xs:string" use="required"/> </xs:complextype> </xs:sequence> <xs:attribute name="reference" type="xs:idref" use="required"/> </xs:complextype> <xs:element name="propertiesexclusionref" minoccurs="0"> <xs:annotation> <xs:documentation>reference to properties (from another facette or a single property) that should not be respected</xs:documentation> </xs:annotation> <xs:complextype> <xs:sequence> <xs:element name="aliases" minoccurs="0" maxoccurs="unbounded"> <xs:annotation> <xs:documentation>add this section to locally rename imported variables</xs:documentation> </xs:annotation> </xs:sequence> <xs:attribute name="reference" type="xs:idref" use="required"/> </xs:complextype> <xs:element name="variablesuseref" minoccurs="0"> <xs:annotation> <xs:documentation>reference to import the used variables (of a dimension or a property) without the properties. Is this usefull?</xs:documentation> </xs:annotation> <xs:complextype> <xs:sequence> <xs:element name="aliases" minoccurs="0" maxoccurs="unbounded"> <xs:annotation> <xs:documentation>add this section to locally rename imported variables</xs:documentation> </xs:annotation> <xs:complextype> <xs:attribute name="originalname" type="xs:string" use="required"/> <xs:attribute name="newname" type="xs:string" use="required"/> </xs:complextype> </xs:sequence> <xs:attribute name="reference" type="xs:idref" use="required"/> </xs:complextype> <xs:element name="variable" minoccurs="0" maxoccurs="unbounded"> <xs:annotation> <xs:documentation>define variables that will be used. Attributes: id/name are identifiants;</xs:documentation> </xs:annotation> <xs:complextype> <xs:simplecontent> <xs:extension base="xs:string"> <xs:attribute name="id" type="xs:id" use="required"/> <xs:attribute name="name" type="xs:string" use="optional"/> </xs:extension> </xs:simplecontent> </xs:complextype> <xs:element name="clause" maxoccurs="unbounded"> <xs:annotation> <xs:documentation>a single property from the specification. Attributes: id/name are identifiants; language could be OCL, TOCL,...</xs:documentation> </xs:annotation> <xs:complextype> <xs:simplecontent> <xs:extension base="xs:string"> <xs:attribute name="id" type="xs:id" use="required"/> <xs:attribute name="name" type="xs:string" use="optional"/> <xs:attribute name="language" type="xs:string" use="required"/> </xs:extension> </xs:simplecontent> Projet RNTL ACCORD Page 34 sur 56

</xs:complextype> <xs:element name="facet" minoccurs="0" maxoccurs="unbounded"> <xs:annotation> <xs:documentation>a set of properties gathered according their type. Attributes: id/name are identifiants; type can be syntactic, semantic, pragmatic, system, other</xs:documentation> </xs:annotation> <xs:complextype> <xs:sequence> <xs:element name="propertyref" type="xs:idref"/> </xs:sequence> <xs:attribute name="id" type="xs:id" use="required"/> <xs:attribute name="name" type="xs:string" use="optional"/> <xs:attribute name="type" type="xs:string"/> </xs:complextype> </xs:sequence> <xs:element name="contractconformityref"> <xs:annotation> <xs:documentation>complet acceptance of another contract. Get it by its ID or name</xs:documentation> </xs:annotation> <xs:complextype> <xs:choice> <xs:element name="nameref" type="xs:string"/> <xs:element name="idref" type="xs:idref"/> </xs:choice> </xs:complextype> </xs:choice> <xs:attribute name="id" type="xs:id" use="required"/> <xs:attribute name="type" type="xs:string" use="required"/> <xs:attribute name="name" type="xs:string" use="optional"/> </xs:complextype> element ContractType/propertiesConformityRef diagram children aliases attributes annotation Name Type Use Default Fixed Annotation reference xs:idref required documentation Reference to properties (from another facette or a single property) that must be respected source <xs:element name="propertiesconformityref" minoccurs="0"> <xs:annotation> <xs:documentation>reference to properties (from another facette or a single property) that must be respected</xs:documentation> </xs:annotation> <xs:complextype> <xs:sequence> <xs:element name="aliases" minoccurs="0" maxoccurs="unbounded"> <xs:annotation> <xs:documentation>add this section to locally rename imported variables</xs:documentation> </xs:annotation> <xs:complextype> <xs:attribute name="originalname" type="xs:string" use="required"/> <xs:attribute name="newname" type="xs:string" use="required"/> </xs:complextype> </xs:sequence> <xs:attribute name="reference" type="xs:idref" use="required"/> </xs:complextype> Projet RNTL ACCORD Page 35 sur 56