Composition conceptuelle basée sur la relation Tout-Partie

Transcription

1 École doctorale des sciences exactes et de leurs applications UFR sciences et techniques Composition conceptuelle basée sur la relation Tout-Partie THÈSE présentée et soutenue publiquement le 9 décembre 2004 pour l obtention du Doctorat de l Université de Pau et des Pays de l Adour (spécialité informatique) par Nicolas Belloir Composition du jury Rapporteurs : Pr Jean-Marc Jézéquel IRISA, Université de Rennes I Pr Yves Ledru LSR-IMAG, Université de Grenoble I Examinateurs : Pr Jeanine Souquières LORIA, Université de Nancy II Pr Gilles Motet LESIA, INSA de Toulouse Directeur : Pr Franck Barbier LIUPPA, Université de Pau et des Pays de l Adour Co-directeur : Dr Jean-Michel Bruel LIUPPA, Université de Pau et des Pays de l Adour Laboratoire d Informatique de l Université de Pau et des Pays de l Adour

2 Mis en page avec la classe thloria.

3 Remerciements Les remerciements. Président Rapporteurs Jury Directeur co-directeur équipe projet laboratoire autres i

4 ii

5 Je dédie cette thèse à la mémoire de ma mère, à Nadége et à Titouan. iii

6 iv

7 Table des matières Introduction 1 Partie I État de l art 7 Chapitre 1 Terminologie Concepts et définitions Du Cbd à la Cbse Composant logiciel Service de composant Interface Contrat Patrons de conception Canevas d applications Relation entre ces concepts Processus de développement d applications basées composants La réutilisation : un principe fondateur Acteurs du processus Étude du processus de développement Résumé du chapitre v

8 Table des matières Chapitre 2 Composition logicielle et composition niveau modèle Composition Illustration de la problématique par une étude de cas Éléments de définition Mise en œuvre de la composition logicielle Langages de script Langages de glu Modèles de composants Langages de description d architecture Langages de composition Bilan de la composition bas niveau Composition au niveau conceptuel Le patron de conception Composite Contrats Approche formelle pour la composition Bilan sur la composition au niveau conceptuel Chapitre 3 Uml et les composants Modélisation, métamodélisation et métamétamodélisation : une question d à propos Uml 1.x Uml Aperçu des améliorations Nouveaux concepts Diagrammes de composants Support pour la composition Nouveau métamodèle La composition conceptuelle en Uml Limites de la composition conceptuelle en Uml Nos solutions Apport d Uml 2.0 par rapport à Uml 1.x Problématique de notre thèse vi

9 Partie II Modèle de composition, une proposition basée sur la théorie de la relation Tout-Partie 67 Chapitre 4 Une approche pour la composition logicielle basée sur la relation Tout- Partie Étude de l application de la relation Tout-Partie à la composition logicielle Démarche, fondations et hypothèses de notre proposition Études des propriétés de la relation Tout-Partie pour la composition logicielle Classification des propriétés retenus selon les dimensions architecturale et dynamique Relations entre les propriétés de composition retenues Identification de différents types de relations Tout-Partie Résumé de l étude Définition d un métamodèle Uml pour la Cbse basé sur la relation Tout-Partie Discussion sur les choix de métamodélisation Proposition de métamodèle Contraintes Ocl Résumé de l application à Uml du modèle de composition Conclusion Partie III Outillage appliqué à la composition 101 Chapitre 5 WpcP : un profil Uml dédié à la composition logicielle Définition et démarches Définition Éléments d un profil Uml Démarche d élaboration d un profil et éléments de description Notre proposition : le profil WpcP Domaine du profil Définition technique Définition opérationnelle Réalisation et exemple d utilisation Limites dues à l outil et choix techniques Exemple d utilisation Bilan du profil vii

10 Table des matières Chapitre 6 Environnement de composition Java pour un déploiement de composants rigoureux Vers un assemblage contraint des composants logiciels : l environnement WpcE Un environnement de composition spécifique Pilotage de composants L environnement Jmx Présentation de Jmx Le service de relation Jmx Environnement de composition Java pour un développement rigoureux Construction de relations Tout-Partie Implémentation de la relation Tout-Partie Exemple d utilisation Bilan du chapitre Chapitre 7 Application de la technologie Bit pour la vérification des contrats de exprimés sur les états Contrats basés sur les états et vérification a posteriori Test de composant Spécificité du test de composant Le test intégré de composant La technologie Bit Le Contract testing Le State-based contract testing Outillage de la technologie Bit La librairie Bit/J Exemple d utilisation de la librairie Bit/J Bilan du chapitre Conclusions générale et perspectives 143 Bibliographie 151 viii

11 Annexes 163 Annexe A Les contraintes Ocl 165 Annexe B Présentation de Jmx 171 Annexe C Le profil WpcP 181 Glossaire des termes techniques 191 Index 195 Index des personnalités, projets, laboratoires et entreprises Index des méthodes, techniques et outils Index ix

12 Table des matières x

13 Introduction 1

14

15 Cadre général de la thèse La réutilisation de parties de logiciel déjà développées pour construire de nouvelles applications présente de nombreux intérêts. Notamment, elle permet une baisse des coûts de production des nouvelles applications, et également une meilleure qualité du code réutilisé : plus un code est réutilisé plus il y a de chances de voir son nombre de bogues diminuer. La technologie objet a été une approche prometteuse pour la réutilisation [MN98]. Cependant, force est de constater qu elle n a pas atteint ses objectifs. En effet, les objets sont des entités de granularité trop faible pour une réutilisation efficace. Il a donc été envisagé de réutiliser des entités de granularité plus importante, en tenant compte de nouvelles préoccupations telles que la prise en compte du comportement, de l hétérogénéité, de l importance du concept d interface et surtout de l impact du client/serveur et des systèmes distribués. Cela a abouti au concept de composant logiciel. En plus d être réutilisables, les composants facilitent le développement de systèmes logiciels plus flexibles et plus modulaires, risquant moins de devenir prématurément obsolètes [BBB + 00]. Cela améliore notamment les possibilités de développement rapide et de maintenance. La construction d une application est donc vue, non plus comme un développement intégral et complet, mais comme un assemblage de briques de bases réutilisables. On parle alors de composition logicielle. Cette évolution a conduit à une différenciation des métiers des acteurs du processus logiciel : on distingue maintenant le développeur de composants, qui a la charge de concevoir, créer et fournir des composants, du développeur d applications qui construit une application par assemblage de composants. Dans ce domaine, les technologies supportant la construction et l assemblage de composants ont atteint un premier niveau de maturité, notamment avec l avènement des standards de composants technologiques tels que Ejb (Entreprise JavaBeans ) [Mic99], Ccm (Corba Component Model) [OMG99a] ou (D)Com ((Distributed) Component Object Model) [Rog96, Gri97]. Le monde industriel, qui voit dans le développement basé composant (Cbd 1 ) un moyen de réduire le coût de développement et de maintenance des logiciels, a notamment dynamisé leur essor. Malgré cela, les techniques d ingénierie logicielle spécifiques à ce domaine (l ingénierie logicielle basée composant, appelée également la Cbse 1 ), dans des phases telles que la modélisation, la vérification ou la validation des applications à composants sont encore insuffisantes et demandent de plus amples efforts de recherche [Hig01]. Dans ce cadre, un point est particulièrement critique : il s agit de la combinaison des composants entre eux, et surtout de sa formalisation. L état actuel des standards permet de faire interagir des composants ensemble lorsqu ils ont été plus ou moins conçus pour cela. Dans le cas contraire, les composants sont adaptés, ou insérés au sein d adaptateurs (i.e., container, ou enveloppeur 2 ou code glu) les rendant compatibles entre eux. Ces actions ne sont pas triviales et représentent un frein à l essor du Cbd. Une des raisons à cela est que les efforts de recherche ont plus porté sur le concept de composant que sur celui de composition. Lorsqu on traite de la Cbse, il convient de considérer deux niveaux différents. Le premier est le niveau conception dans lequel les composants sont des entités abstraites de conception. Le second est le niveau déploiement, dans lequel les composants sont des entités exécutables. Actuellement, les besoins au niveau déploiement s avèrent satisfaits par des technologies matures telles que.net [SGM01], Ejb ou Corba [OMG02a]. À l inverse, les techniques de modélisation pêchent par manque de constructions de modélisation dédiées, bien formalisées et peut-être mieux inspirées de travaux de recherche précédents. Notre travail entre dans ce cadre et se propose d apporter des améliorations à cette limite. 1 Nous utiliserons dans ce document les acronymes anglais Cbd (Component-Based Development) et Cbse (Component- Based Software Engineering) à la place des équivalents français Dbc et Ilbc peu connus et rarement employés. 2 Wrapper en anglais 3

16 En particulier, le langage de modélisation Uml, qui est un standard de facto tant au niveau industriel qu au niveau de la recherche, n offrait jusqu à ce jour que peu de moyens permettant de modéliser les applications basées composants. La dernière évolution du langage, la version 2.0, a apporté des améliorations relativement significatives, palliant en partie à cette lacune. Cependant, de nombreuses incohérences sont encore présentes dans la définition du langage : la sémantique des concepts propres à la Cbse est parfois absente, peu précise ou même incohérente. Au niveau assemblage, les technologies actuelles permettent à des composants d interagir, mais sans évaluer leur compatibilité [SW02]. La meilleure prise en compte de la composition au niveau conception devra améliorer ce point. Objectif de la thèse Dans cette thèse, nous nous sommes intéressés à une approche nouvelle autour de la composition conceptuelle. Nous nous sommes pour cela fixés les objectifs suivants : Nous cherchons à modéliser la composition logicielle en y incluant le plus de sémantique possible (au sens Uml, c est-à-dire définie par un métamodèle et des contraintes). Pour cela, nous caractérisons la composition au travers d un certain nombre de propriétés spécifiques. Nous appliquons nos propositions à Uml. Nous cherchons à définir un cadre applicatif cohérent, tout au long du cycle de développement. Pour cela, nous voulons offrir les moyens de vérifier que les propriétés de composition sont correctement implémentées par l application réalisée. Nous explorons deux approches complémentaires. La première consiste à proposer un environnement contraint de déploiement dans lequel les propriétés de composition peuvent être implémentées telles quelles. La seconde fournit des moyens de test sur le comportement externe des compositions. L approche retenue, pour le modèle de composition, est basée sur la théorie de la relation Tout-Partie. À l origine, cette théorie a une base mathématique. Elle a été développée pour les ontologies. Notre but est de l adapter pour le génie logiciel et plus particulièrement la Cbse. Notre équipe a déjà exploré cette approche en l appliquant à la modélisation objet [BHSPLB03]. Elle a identifié un certain nombre de propriétés caractéristiques et les a formalisées. Nous nous proposons de partir de ces travaux, d étudier leur éventuelle application à la composition de composants et de proposer, dans le cadre d Uml, un modèle de composition à partir de cette étude. D un point de vue applicatif, nous proposons une plate-forme visant à garantir une cohérence tout au long du processus de réalisation. Il s agit de : un profil 3 Uml permettant d utiliser notre modèle de manière pragmatique, développé à l aide du module Profile Builder de l atelier de génie logiciel Objecteering ; un environnement de déploiement centré sur la composition logicielle, permettant la manipulation et le pilotage dynamique des assemblages de composants. L idée est de pouvoir directement implémenter les propriétés de composition spécifiées au niveau du modèle ; l utilisation d une technique de test de composants permettant la vérification du comportement externe des compositions logicielles. En particulier, notre proposition permet la description et la vérification de contrats basés sur les états. 3 Dans ce document, nous utilisons la traduction francisée du terme anglais «profile» : profil 4

17 Le contexte applicatif dans lequel s est déroulé cette thèse (projet européen Component+ 4 ) a eu des impacts sur l orientation que nous avons donnée à notre étude. En particulier, le projet a été mené en partenariat avec des industriels (notamment Philips Electronics (Angleterre) et Engineering Ingegneria Informatica (Italie)). Pour cette raison, le travail s est fortement attaché à produire des résultats concrets et des outils les soutenant. Organisation du mémoire Ce document est décomposé en trois parties (cf. Figure 1). La partie I présente l état de l art de notre problématique. Le chapitre 1 donne, dans un premier temps, une définition des concepts de base de la Cbse. Puis, le chapitre 2 présente un état de l art de la composition logicielle. Le chapitre 3 présente Uml et en particulier la manière dont Uml traite la composition de composants. Il se termine en dressant un bilan et en posant précisément notre problématique. La partie II définit et explique notre modèle de composition conceptuelle. le chapitre 4 présente notre approche basée sur la relation Tout-Partie et l applique au langage de modélisation Uml. Enfin, la partie III détaille l outillage que nous fournissons pour réaliser notre modèle : un profil Uml, détaillé au chapitre 5 ; un environnement d assemblage, présenté au chapitre 6, permettant le déploiement de composants respectant la modélisation de la composition établie grâce au profil ; une librairie permettant la vérification du comportement externe des compositions présentée au chapitre 7. I État de l art II Modèle de composition III Outillage Partie 1 Terminologie 2 3 État de l art UML sur la et la composition CBSE logicielle 4 Étude de la relation Tout-Partie et Métamodèle Uml basétout-partie 5 Profil Uml 6 Environnement de composition 7 Test intégré orienté contrat Chapitre Fig. 1 Représentation schématique de l organisation du mémoire 4 projet Européen Component+, http :// 5

18 6

19 Première partie État de l art 7

20

21 Chapitre 1 Terminologie Sommaire 1.1 Concepts et définitions Du Cbd à la Cbse Composant logiciel Service de composant Interface Contrat Patrons de conception Canevas d applications Relation entre ces concepts Processus de développement d applications basées composants La réutilisation : un principe fondateur Acteurs du processus Étude du processus de développement Résumé du chapitre Ce chapitre présente les concepts élémentaires du développement à base de composants. Tout d abord, la section 1.1 donne les définitions des principaux concepts que nous retenons. Nous présentons la Cbse, puis nous nous intéressons aux abstractions particulières que sont un composant, ses services, ses interfaces et les contrats exprimables à son égard. Nous introduisons également les notions de patrons et de canevas d applications qui sont des notions importantes du développement à base de composants. La section 1.2 présente le processus de développement d une application basée composants. Nous commençons par parler de réutilisation, puis nous présentons les acteurs de ce type de processus logiciel. Enfin, nous regardons plus en détail les particularités du développement orienté composants. 1.1 Concepts et définitions Cette section a pour objectif de définir les termes clés que nous employons dans la suite de ce mémoire. Nous présentons les concepts de base du développement à base de composants, discutons de leurs définitions dans le domaine et, le cas échéant, nous positionnons sur les éléments de définitions que nous retenons. En effet, tous les concepts abordés n ont pas une définition unique. Aussi, loin de prétendre détenir la définition absolue, il nous a paru important de donner au lecteur notre définition. Pour commencer, nous expliquons la signification des concepts Cbd et Cbse. 9

22 Chapitre 1. Terminologie Du Cbd à la Cbse Les concepts de Cbd et de Cbse sont parfois utilisés comme des synonymes. Pourtant leur signification n est pas la même. Le Cbd traduit l idée de création d une application par utilisation/réutilisation de composants. La Cbse désigne les méthodes, techniques et outils permettant la conception et la mise en œuvre d applications basées composants. Elle a ainsi permis au Cbd de passer d une approche artisanale à une approche industrielle. Les définitions des concepts inhérents à la Cbse sont encore mal formalisées et portent parfois à confusion. Le flou qui entoure certaines définitions vient de la manière dont la Cbse a été créée et a évolué, aux confins de plusieurs domaines. Nous citons les deux principaux : l approche orientée objet et les travaux portant sur les architectures logicielles. L expérience tirée de l approche objet a été fondatrice pour la prise en considération de l aspect réutilisation dans la Cbse. Les travaux sur les architectures logicielles ont montré l importance d une architecture clairement spécifiée pour la construction d applications. Les avantages d une telle paternité sont : la modularité de l application ; la possibilité de mieux organiser le développement de l application ; une identification claire des interactions entre les modules ; l amélioration très significative de la maintenabilité, car il est alors aisé de faire évoluer un module indépendamment des autres. Le Cbd intéresse de nombreux domaines aussi différents que le temps réel ou l informatique de gestion. Or ces domaines ont culturellement des méthodes pour le développement et des contraintes très différentes les unes des autres. Par exemple, le développement temps réel requiert un niveau de certification élevé et long à réaliser. À l inverse, le développement d applications Web nécessite une grande réactivité et des temps de développement très courts. Le Cbd a suscité un intérêt et un investissement très important dans le monde industriel. Plusieurs raisons peuvent l expliquer. D une part, les promesses de rentabilité et de qualité accrue des logiciels finalisés, avancées par cette technologie, ont poussé les industriels à investir dans ce domaine. D autre part, des moyens pour soutenir le Cbd ont rapidement été créés. Johnson prétend que le marché des composants est né avec Visual Basic [Mic] et les composants graphiques. Les modèles de composants industriels tels que Com [Rog96] et DCom [Gri97], implémentés dans le système Windows ont également conduit à créer une dynamique et une évolution rapide. Cette dynamique ne repose cependant ni sur des bases stables et admises, ni sur des standards. Comme nous le verrons dans le chapitre 2, il existe à l heure actuelle des moyens pour construire des applications à base de composants sur des environnements de déploiement fiables. Cependant, l expérience a montré que le Cbd nécessitait une approche systématique [CL00]. Les principales missions de la Cbse sont les suivantes [CH01] : 10 fournir un support pour le développement des composants ; supporter le développement des composants en tant qu entités réutilisables, c est-à-dire anticiper la réutilisation et concevoir la réutilisabilité ; faciliter la maintenance et l évolution des systèmes en permettant la modification et le remplacement de leurs composants.

23 1.1. Concepts et définitions Composant logiciel La notion de composant logiciel, bien qu étant le cœur de la Cbse n a pas de définition universellement acceptée. Parmi celles proposées, la plus couramment admise a été énoncée lors du Workshop on Component Oriented Programming en 1996 et reprise dans le livre de Szyperski et al. [SGM02]. Elle sert également de base à d autres définitions plus ou moins connexes [CHJK02b, ART03, CHJK02a, BBB + 00, ABB + 01]. Nous ne les reprenons pas intégralement mais discutons des points de désaccord entre ces définitions et celle de Szyperski. Celle-ci définit un composant en énumérant ses propriétés caractéristiques : «A software component is a unit of composition with contractually specified interfaces and context dependencies only. A software component can be deployed independently and is subject to composition by third parties». Trois propriétés caractéristiques sont mises en relief par cette définition. La première traite le côté architectural d un composant : un composant encapsule totalement son implémentation et communique avec son environnement au travers de ses interfaces [CHJK02a]. Atkinson et al. dans [ABB + 01] confortent ce point en parlant de «self-contained piece of software, with well-defined interaction points and nodes». La deuxième caractéristique porte sur la notion de composition. Un composant est une unité de composition et est sujet à composition ; il doit donc être conçu pour la composition, c est-à-dire pour être combiné avec d autres composants afin de construire des entités logicielles de taille plus conséquente. Enfin, la troisième caractéristique concerne la capacité de déploiement d un composant. Le déploiement est l action de mise en service d un composant au sein d une architecture spécifique. Nous en reparlons dans la section Elle doit être indépendante, c est-à-dire que l on peut déployer un composant indépendamment de toute autre partie d une application. Cela signifie également qu il doit pouvoir être déployé par une tierce personne, c est-à-dire une personne qui ne l a pas créé et qui ne le connaît pas. Cette notion est nouvelle dans le développement d applications. En effet, la modularité des applications basées composants permet de maintenir une partie du logiciel à la manière des systèmes d exploitation ou des systèmes de gestion de bases de données. On peut parler d administration d application. Cette propriété est particulièrement importante pour la réutilisabilité d un composant Différence entre objet et composant Chessman et Daniels dans [CD01] définissent les composants comme une extension de la technologie orientée objet (OO). À ce titre, un composant est vu comme une unité logicielle structurée selon les principes objets suivants : unification des données et des fonctions, encapsulation et identité unique. Un composant étend ces principes et se différencie d un objet par les points suivants : il fournit une représentation de sa spécification distincte de son implémentation à travers son interface ; il possède généralement des moyens de communication plus étendus que les objets (ces derniers se limitent généralement aux mécanismes de message) ; il a souvent des capacités de persistance là où un objet est limité à son état local ; il est généralement de granularité plus importante qu un objet et propose des actions complexes via ses interfaces. Le tableau 1.1 résume les différences entre objets et composants. La question de savoir si une classe seule peut être un composant est souvent posée. Nous soutenons que, si une classe est livrée avec ses interfaces de services requis et fournis, alors elle peut être considérée comme un composant de granularité faible. La définition précédente présente un point de vue intéressant : il s agit du fait qu un composant possède souvent des capacités de persistance. Ce point est en contradiction avec Szyperski qui dit qu un composant «has no (externally) observable state». Ces deux approches sont 11

24 Chapitre 1. Terminologie Propriété Objet Component Interface bien définie Possible Obligatoire Capacité à être déployé Non Oui Communication Invocation de méthode Invocation de méthode, de service, envoie de signal... Capacité de persistance État interne Possible Granularité Simple Variée Tab. 1.1 Résumé des différences entre un objet et un composant souvent débattues dans la communauté composant. L approche de Szyperski est une vue dans laquelle un composant ne peut être distingué des autres copies de ce composant. L approche dans laquelle un composant a des capacités de persistance implique le contraire. En effet, à partir du moment où un composant peut stocker des informations, il peut être distingué des autres copies de ce composant. Cette approche nous semble plus ouverte et plus intéressante car elle permet d utiliser la technologie composant pour un plus grand nombre de cas. Nous adhérons donc à la vue de Chessman et Daniels sur ce point Forme et cycle de vie d un composant Les définitions précédentes identifient les propriétés d un composant mais ne précisent pas exactement ce qu est, structurellement, un composant, notamment lors des différentes phases de son cycle de vie. Il est pourtant intéressant d en étudier les caractéristiques et d en différencier la sémantique : le terme composant ne qualifiant pas le même type d élément lorsqu on parle au niveau modèle ou au niveau déploiement. Dans [BBB + 00], un composant logiciel est définit comme suit : «A software component merges two distinct perspectives [...] : Viewed as implementations, components can be deployed, and assembled into larger (sub)systems. Viewed as architectural abstractions, components express design rules that impose a standard coordination model on all components. These design rules take the form of a component model, or a set of standards and conventions to which components must conform». Cette définition fait apparaître deux aspects physiques différents : le composant d implémentation qui est un programme ou une partie de programme, et le composant de conception qui est un modèle. [CD01] vas plus loin et identifie six notions caractérisant un composant (la Figure 1.1 représente cette proposition) : Standard de composants : un composant, pour pouvoir être assemblé afin de construire une application, doit se conformer à des règles précises définies par un standard. Par exemple, les standards tels que Ejb, Ccm, ou Com, sont des normes de composants. On trouve cette notion également sous l appellation de modèles de composants. Nous reviendrons plus loin sur cette notion (cf. p. 40). 2. Spécification de composant : afin de pouvoir utiliser un composant, il faut savoir précisément ce qu il peut faire. Cette règle est particulièrement vraie lorsque l utilisateur d un composant n est pas son créateur. Il faut donc fournir une spécification claire des composants. 3. Interface de composant : l interface d un composant est une partie importante de sa spécification. Elle permet de séparer sa spécification de son implémentation. Cela autorise, a priori facilement, le remplacement d un composant par un autre (implémentant la même interface). 4. Implémentation de composant : l implémentation d un composant est une mise en œuvre possible de la spécification d un composant. Il peut y avoir de nombreuses mises en œuvre d une même spécification, dans des langages différents par exemple.

25 1.1. Concepts et définitions 5. Composant installé (ou déployé) : il s agit de la forme que prend une implémentation de composant lorsqu elle est déployée sur un système. À chaque fois qu un composant est déployé, il crée un composant installé. 6. Composant objet : il s agit de la forme du composant lorsque l application est en exécution. Seuls les composants objets font réellement quelque chose. Cette définition est limitée à des composants OO. Elle peut toutefois être étendue à d autres formes de composants. On parlera alors plutôt d instances de composant. Interface de composant Interface supportées 1..* * Spécification de composant 1 réalisation * Implémentation de composant 1 Installation * Installation de composant 1 * Instance Composant objet Fig. 1.1 Spécialisation de la notion de composant en fonction de son cycle de vie [CD01] Dans un même esprit, Marvie [Mar02] étend la définition de Szyperski par quatre notions caractérisant celle de composant : le type d un composant, l implantation d un composant, le paquetage d un composant et l instance d un composant. En résumé, il est nécessaire de tenir compte de la forme structurelle d un composant au cours de son cycle de vie. Un composant, d un point de vue spécification, est une représentation conceptuelle d une entité informatique réutilisable. On parle de composant conceptuel. D un point de vue implémentation, il s agit de la représentation codée de cette entité conceptuelle. Il peut y avoir plusieurs représentations codées en fonction de la technologie dans laquelle le composant devra s intégrer. Il peut également y avoir plusieurs instances d une implémentation de composant. On peut même imaginer plusieurs instances de différentes implémentations d un même composant conceptuel. Ces instances et ces types auront cependant en commun les interfaces du composant Une forme particulière de composant : le composant sur étagère Nous introduisons ici un type de composant particulier : le composant Cots, pour Commercial Off- The-Shelf, appelé encore Cots tout simplement, et dont la traduction française est «composant sur étagère» 5. Ce type de composant répond à une demande forte du marché industriel. Il s agit de composants vendus, généralement sous forme binaire, par des fournisseurs de composants, à des utilisateurs 5 On utilisera plutôt l acronyme Cots pour sa concision. 13

26 Chapitre 1. Terminologie de composants : l idée est de proposer un large choix de composants directement exploitables (sans modification) et intégrables dans une application basée composants. Wallnau et Stafford, du laboratoire Sei (Software Engineering Institute) de Carnegie Mellon, définissent un composant Cots de la manière suivante [WS01] : une implémentation d une fonctionnalité livrée sous forme binaire, sujet à composition part une tierce personne, vendu ou fourni sous licence par un vendeur, souhaitant en tirer profit, sous une forme identique (c est-à-dire non modifiable). Oberndorf et al. [OBS00] ajoutent que le vendeur a la charge de fournir le support et les évolutions de ces composants. Les composants Cots sont à eux seuls une thématique complète comme le montre les nombreux travaux ou ouvrages et les nombreuses conférences 6 et ateliers qui leur sont dédiés. Ils posent des problèmes particuliers tant au niveau technique qu au niveau commercial et légal. D un point de vue technique, les Cots sont souvent de taille importante. Ils sont paramétrables pour pouvoir être intégrés à un grand nombre d applications. Cela implique des capacités de paramétrage importantes, mais également une complexité accrue, ce qui peut avoir des conséquences sur les performances. En outre, il est souhaitable qu ils soient certifiés et éprouvés pour des usages variés. Ils posent cependant des problèmes de validation et de certification au sein de leur nouvel environnement. Enfin, les applications à base de Cots nécessitent des nouvelles méthodes de développement, traitant notamment les aspects spécifiques comme la sélection des composants, la réutilisation, l évaluation [Kur01, Cra01]. Les questions d ordre commercial et légal sont également à prendre en compte. Il ne s agit plus de développements internes ou sous contrats mais d achats de produits finis, maintenus. Le choix des composants Cots peut être influencé par une politique commerciale (accords entre entreprises utilisatrices et fournisseurs) ou des restrictions légales : par exemple, se pose pour les entreprises des secteurs stratégiques la question de l opportunité d utiliser des Cots produits par des entreprises étrangères. Pour finir, citons une forme particulière de Cots que sont les Cots produits sous forme de logiciels libres. Ils permettent l accès au code source, et notamment la modification du code pour être adapté à un besoin particulier Taille des composants La taille des composants est très variable. Un composant, dans sa plus petite taille, peut être un simple objet ou une collection d objets. On parle alors de brique de base. Notons qu un composant a pour finalité d être déployé indépendamment d autres composants ; il doit contenir les moyens lui permettant de le faire [ACC02a] (caractéristiques de gestion de ressources ou de sécurité par exemple). Par composition, on peut construire, à partir de ces briques de base, des composants de taille plus importante. Dans certaines approches, un composant peut être considéré comme une application. C est le cas par exemple de certains composants Microsoft, comme Word ou Excel. Ces composants sont des Cots, puisqu ils sont utilisés uniquement sous forme exécutable. Les applications construites à partir des Cots sont appelées des produits basés-cots 7. Office est un produit basé-cots construit à partir des composants comme Word et Excel par exemple. Remarquons que ce point est discutable. En effet, il n est pas possible de remplacer dans Office un composant (Word par exemple) par un composant différent (un autre traitement de texte par exemple). Le débat sur la taille des composants peut également être présenté comme une différence de compréhension entre le monde académique et le monde industriel [Bos00]. Le monde académique a tendance à définir les composants comme des entités bien définies (souvent petites, avec des propriétés fonctionnelles et non fonctionnelles facilement compréhensibles) alors que pour le monde industriel, les composants sont 6 Par exemple International Conference on COTS-Based Software Systems http :// 7 Cots-based product en anglais 14

27 1.1. Concepts et définitions généralement des parties complètes de systèmes pouvant être réutilisées mais avec des interfaces n étant pas spécialement bien définies et avec peu d adéquation vis-à-vis des modèles de composants [Crn02]. Les Erp (Entreprise Resource Planning) comme Sap 8 en sont un exemple. Les systèmes de gestion de stock ou les systèmes de paie y sont vus comme des composants. Comme on peut le constater, cette vision est à la limite de la définition d un composant Déploiement des composants L aspect réutilisable des composants logiciels sous-entend leur utilisation dans des environnement différents. On parle alors de déploiement sur un environnement cible. Même dans le cas de composants à usage unique, le premier environnement de déploiement que connaît un composant est son environnement de développement. Il est généralement considéré comme différent de celui dans lequel il sera mis en exploitation. Ce concept n est pas propre à la Cbse ; on le retrouve par exemple en informatique embarquée, où les programmes sont souvent déployés sur des machines cibles dont l architecture machine est différente de celles de développement. Le Cbd a connu un engouement important notamment avec l avènement des architectures distribuées, où une application est souvent composée de plusieurs nœuds de déploiement. Cependant, les applications distribuées ne sont pas les seules candidates possibles au Cbd. En effet, il est tout à fait possible de développer des applications fonctionnant sur un seul nœud de déploiement avec l approche composant. Le déploiement est étroitement lié avec l aspect configuration des composants. En effet, la réutilisation amène à déployer un composant dans des environnements hétérogènes. Pour pouvoir s adapter à cette hétérogénéité, le composant doit être fourni avec des moyens de configuration. Ces moyens peuvent être accessibles via des interfaces de configuration comme discutés à la section Considérons un composant permettant l interrogation de bases de données : il devra être configuré en fonction du type de base de données avec lequel il devra interagir Notre position Nous sommes en accord avec la définition de Szyperski. Cependant, nous la spécialisons avec les éléments complémentaires que nous avons présenté. Nous considérons qu un composant a un état interne. Il peut être de granularité importante mais dans sa plus simple expression, un objet avec des interfaces clairement spécifiées peut être considéré comme un composant. Nous considérons le composant à travers les niveaux d abstraction suivants : le composant conceptuel, le type de composant, l implémentation de composant et l instance de composant. Les composants Cots sont considérés de la même manière. Nous les différencions uniquement par leur aspect boîte noire et leur côté commercial Service de composant Nous avons présenté une définition du concept de composant. Nous n avons pas encore parlé de son rôle, au sein d une application : un composant propose (respectivement requiert) des services à d autres composants. Il s agit d un échange de services de type client-serveur. Le composant, respectivement, est vu des autres composants, comme serveur pour les services qu il propose et comme client pour les services qu il requiert. Un service est défini comme suit par [BSW03] : «A service is a running instance (all the way down to supporting hardware and infrastructure) that has specific quality attributes, such 8 Pour plus d information voir http :// 15

28 Chapitre 1. Terminologie as availability, while a component needs to be deployed, installed, loaded, instantiated, composed, and initialized before it can be put to actual use». Cette définition est résumable en disant qu un service est une action possible fournie par le composant lorsque celui-ci est en exécution. Il s engage à fournir ce service sous réserve que certaines conditions soient remplies, notamment en terme de qualité de service (QoS) Interface Un composant doit être clairement différencié des autres composants et de leur contexte d exécution [CHJK02a]. Le mécanisme permettant cela est l interface. Les interfaces sont un mécanisme de contrôle des dépendances existantes entre les différents modules d un programme ou d un système [BBB + 00]. Par extension, elles ont le même rôle pour les composants. Une interface d un composant peut être définie comme une spécification de ses points d accès [SGM02], c est-à-dire qu elle offre la liste des services fournis ou requis par le composant. La différenciation de ces deux types d interfaces, communément appelées interface de services requis et interface de services fournis, est désormais acquise comme le montre leur prise en compte dans la version 2.0 d UML [OMG03b, OMG03d]. L existence d un troisième type d interface est sujet à discussion. Il s agit de la notion d interface de configuration [Bos00], appelée également «diversity interface» dans [Omm02]. Cette interface décrit notamment les capacités de configuration d un composant. Interface ProvInterPAM setcap settarget... Interface ReqInterPAM getforcevent getcapvent... component Pilote Automatique Marine légende interface interface Interface de configuration Interface ConfInterPAM settypebateau setinterfacerequise component composant interface de service fournis interface de service requis dependance Fig. 1.2 Un composant et ses interfaces La Figure 1.2 illustre la notion d interface en utilisant les notations définies dans Uml Elle représente un composant simple (un pilote automatique de bateau). Il propose trois interfaces : l interface de services fournis ProvInterPAM, l interface de services requis ReqInterPAM et l interface de configuration 9 Dans la suite de ce document, les notations utilisées pour les figures seront en Uml 2.0, sauf mention contraire précisée. Lorsqu une nouvelle notation est employée, elle est précisée en légende. 16

29 1.1. Concepts et définitions ConfInterPAM. Ce composant est conçu pour pouvoir être adapté à plusieurs types de bateaux. Lors de son déploiement sur un bateau, il faut le configurer en lui donnant le type du bateau pour qu il puisse paramétrer ses calculs. Cela se fait par le biais de l interface de configuration ConfInterPAM et l opération settypebateau. Il s agit d un service de configuration fonctionnel puisqu il est lié au métier du composant. L interface de configuration pose le problème des services de configuration fonctionnels et non fonctionnels. En effet, dans cet exemple l interface propose un service de configuration non fonctionnel, l opération setinterfacerequise, qui permet de spécifier le composant qui implémente l interface de services requis. Ce type d opération sera identique à tous les composants et a été ajouté durant le développement par ré-ingénierie. Ce type d interface est fortement lié à l implémentation choisie, et ne doit donc pas être inclue au modèle à ce stade de conception. Les interfaces de configurations sont proches des interfaces de services fournis. Elles s en différencient par leur côté préparation au fonctionnement du composant (paramétrage) que ce soit d un point de vue fonctionnel ou non fonctionnel. Les utilisateurs de ces interfaces ne sont pas les mêmes personnes. Les interfaces de configuration sont manipulées par les administrateurs d applications alors que les interfaces de services fournis sont manipulées par les utilisateurs de composants. Une interface se présente sous la forme d une collection de noms d opérations. Elle fournit, pour chaque opération, sa description et son protocole [Crn02]. L implémentation de ses opérations est encapsulée dans le composant. Comme indiqué dans [CHJK02a], cela permet de : remplacer l implémentation d un service sans modifier l interface, ce qui optimise localement un système sans impliquer sa reconstruction (à la manière d un driver dans un système d exploitation que l on peut mettre à jour sans avoir à recharger le système) ; ajouter de nouvelles interfaces et donc de nouvelles implémentations sans changer les implémentations existantes, ce qui permet d améliorer l adaptabilité des composants. La mise en œuvre de la notion d interface est maintenant aisée car de nombreux langages de programmation récents la supportent, comme par exemple Java. Dans le cas contraire, des langages de spécification d interfaces ont été également développés, indépendamment de tout type de langage, comme le langage Idl (Interface Definition Language) définit par le Dce 10 (Distributed Computing Environment). Un exemple de code est donné en Figure interface ProvInterPAM { 2 void setcap ( out int icap ) ; 3 void s e t T a r g e t ( i n f l o a t i L a t t i t u d e, i n f l o a t ilongitude ) ; 4 } ; Fig. 1.3 Exemple de définition d interface en IDL Contrat La plupart des techniques de description d interfaces se limitent à une seule description syntaxique. Meyer [Mey00] soutient que les langages de description d interface ne sont pas suffisamment expressifs pour décrire autre chose que la dimension architecturale. Ils ne décrivent pas le comportement du composant mais juste la liste de ses services. La notion de contrat [Mey97] permet notamment de pallier à cette lacune. Il est admis [SGM02, CHJK02a] que les contrats permettent de spécifier de manière plus rigoureuse le 10 Voir http :// 17

30 Chapitre 1. Terminologie comportement des composants. Un contrat liste les contraintes globales que le composant doit maintenir (invariants). Pour chaque opération d un composant, un contrat liste également les contraintes qui doivent être assurées par le client (pré-conditions) et celles que le composant promet d établir en retour (postconditions). Les pré-, postconditions et invariants constituent une spécification du comportement d un composant. Un contrat peut se décomposer en quatre niveaux différents. Cette classification a été proposée par Jézéquel et son équipe dans [BJPW99]. Ces niveaux se différencient en terme de difficulté d automatisation des assemblages [ACC02a]. Ces niveaux sont, par ordre de difficulté de réalisation croisante : Niveau 1 : contrat syntaxique. Il s agit là de la plupart des contrats actuels. Le contrat n est assuré que par les signatures des opérations ; Niveau 2 : contrat par contraintes. Ce niveau décrit pour chaque service offert les conditions d utilisation et le résultat attendu ; Niveau 3 : contrat par synchronisation. Ce niveau garantit la bonne marche du système en cas d utilisation concurrente de l interface ; Niveau 4 : contrat de qualité de service. Ce type de contrat décrit les conditions d utilisation de l interface permettant de garantir la QoS de l interface. La plupart des modèles de composants actuels n imposent que le niveau 1. Ils n assurent que le typage correct des interfaces offertes et requises. Certains langages, comme Eiffel [Mey92] permettent une description des interfaces par contrats de niveaux 2, en introduisant dans leur syntaxe des pré, et post-conditions. Notons que sous réserve d atomicité d exécution des services, c est-à-dire que le service ne s appuie pas sur une cascade d autres services, le contrat de niveau 2 suffit à garantir le bon fonctionnement du composant [ACC02a]. Cependant, cette réserve est limitative dans les applications modernes où, bien souvent, des contraintes de parallélisme ou d exécution multiples sont nécessaires (applications clientserveur ou architectures trois tiers par exemple). Le rôle des contrats de niveau 3 est de décrire les contraintes de concurrence fixées par le composant. Ils permettent de considérer les interactions entre un composant et son environnement de manière non atomique. c est-à-dire que la description des transactions n est plus seulement envisagée au cas par cas mais dans sa globalité. Les opérateurs de composition permettent la définition d obligations telles que de fournir une description des entrées/sorties prenant en compte tous les cas potentiels possibles. Des contrats peuvent être également posés sur des assemblages de composants. On appelle cela des contrats de composition [Col03]. Enfin, le niveau 4 de contrat dérive d une demande forte de la communauté, notamment industrielle, pour garantir la QoS fournie par un composant. C est particulièrement vrai dans le domaine des applications temps-réel ou embarquées, dans lesquelles les conséquences d un composant n assurant pas une bonne QoS peuvent être dramatique. Par exemple, un composant assurant le transfert des données en 10ms, alors que le temps de transfert pour assurer la sécurité de l application est de 1ms, ne peut être candidat à un déploiement dans cette application. Un projet travaillant sur ce point est en cours de développement : il s agit du projet Artist Patrons de conception Les définitions des abstractions précédentes décrivent ce qu est un composant, ce qu il fait et comment il le fait. Nous nous intéressons maintenant à deux moyens aidant à réaliser une application basée composants. Les patrons de conception [GHJV95] forment une méthode de réutilisation des informations de conception. Ils ont été introduits dans le monde OO. Un patron est défini par Johnson comme suit [Joh97] : «A 11 Projet Européen ARTIST IST , http :// 18

31 1.1. Concepts et définitions pattern describes a problem to be solved, a solution, and the context in wich that solution works». Il s agit d une solution récurrente à un problème. Un patron peut également être adapté selon les circonstances spécifiques [SGM02]. On peut établir quatre catégories de patrons. Chaque catégorie est basée sur le niveau d abstraction à partir duquel ils sont utilisés [CHJK02b] : les patrons d analyse de Fowler [Fow96] aident à analyser les besoins et le système ; les patrons d architecture [AIS + 78] travaillent sur les propriétés globales et architecturales du système. Ils décrivent la structure globale du système, et fournissent des moyens de décrire l ensemble des sous-systèmes, de spécifier leur rôle et de décrire les relations existant entre eux ; les patrons de conception raffinent la structure et les comportements des sous-systèmes et des composants. Par leur aspect générique, les patrons sont considérés comme des micro-architectures visant à réduire la complexité, à promouvoir la réutilisation et à fournir un vocabulaire commun aux concepteurs [BM04]. Ils décrivent la structure et le comportement du système et des composants et les communications entre eux : les patrons de programmation sont dépendants des paradigmes et des langages de programmation utilisés. Client uses interface Cible operationrequise() Adaptée operationspecifique() Légende implements extends Association implémentation Héritage Adapter operationrequise() operationspecifique() Fig. 1.4 Patron de conception Adapter [GHJV95] La Figure 1.4 montre le patron de conception Adapter. Ce patron est utile lorsque l on désire utiliser une classe existante mais que l interface proposée n est pas satisfaisante ; il propose alors de définir une classe effectuant les actions d adaptation nécessaires. L interface Cible définit l interface désirée par le client, la classe Adaptée définit l interface existante des objets à manipuler, la classe Adapter effectue les actions nécessaires pour la réalisation des opérations suivant l interface désirée en se basant sur les opérations existantes. La classe Client manipule l objet suivant l interface désirée. Les patrons ont été appliqués avec succès dans la conception de nombreuses applications OO. Ils sont considérés comme des micro-architectures réutilisables qui contribuent à la bonne cohésion de l architecture complète. Cependant, la connaissance (terme consacré) contenue dans les patrons de conception est une connaissance non structurée qui est porteuse de nombreuses ambiguïtés à cause notamment de la description informelle des solutions. [CHJK02a] explique la relation existante entre patrons de conception et composants. Elle peut être vue comme suit : les patrons de conception, dans le processus de conception des applications basées composants, aident à déterminer les unités réutilisables et, le cas échéant, à les identifier sous la forme de composants existants, ou à les développer sous la forme d unités réutilisables. Enfin, les patrons de conception peuvent être utilisés pour décrire les compositions de composants. Il est envisageable de décrire dans des patrons, différents cas de composition type que l on pourrait utiliser. Nous reviendrons sur cette idée dans la section page 46 traitant du patron Composite. 19

32 Chapitre 1. Terminologie Les patrons sont souvent considérés comme des simples artefacts non logiciels, c est-à-dire de la documentation détaillée dans laquelle la solution est décrite dans un format particulier [KS98]. Un rapport de l Uqam (Université de Québec À Montreal) [BM04] identifie un certain nombre de problèmes liés à l utilisation des patrons : vérification de la bonne application du patron au résultat final ou complexité de certains patrons, par exemple. Par ailleurs, les patrons ne sont pas exprimables par un langage ou un environnement de modélisation utilisable directement. C est un des reproches récurrents adressés à cette approche. De nombreux travaux ont travaillé à corriger ce dernier point en proposant : l intégration des patrons dans un outil Uml [SGJ00] ; la définition d une représentation explicite des patrons basée sur les mécanismes d extensions d Uml [FL01] ; le développement d un profil Uml pour l utilisation des patrons [SA02] ; une approche de métamodélisation pour l intégration des patrons à l approche MDA [AAG01] ; l utilisation d Ocl [OMG03c], conjointement à celle de patrons, pour permettre la génération d un outil à partir d un métamodèle [AP03]. Notons les travaux de Keller et Schauer [KS98], qui ont proposé un environnement, basé sur les patrons de conception, maintenant une cohérence entre la conception, le développement et l exécution des composants. Cette approche présente deux limitations : d une part, la composition se limite à de l intégration de composants (nous revenons sur ce concept à la section ) ; d autre part, leur environnement est un environnement intégré dans lequel il est difficile d utiliser des composants développés extérieurement, et notamment des Cots. Un autre axe de travail particulièrement intéressant consiste à utiliser le coté extensible des patrons. L idée est de proposer un ensemble de patrons de conception, chacun capitalisant les règles de bonne forme pour un type particulier de composition. Dans ce cadre, [DAC99] propose de prouver les conceptions formellement. Ces conceptions forment alors un patron de conception pour la composition Canevas d applications Tout comme la définition de composant, la notion de framework, que nous traduisons par canevas d applications, est un second moyen aidant à réaliser une application basée composants. [Joh97] en donne deux définitions complémentaires. La première définition décrit la structure d un canevas : «A framework is a reusable design of all or part of a system that is represented by a set of abstract classes and the way their instances interact». La seconde définition concerne son but : «A framework is a skeleton of an application that can be customized by an application developer». Un canevas d applications peut être vu comme une conception réutilisable d une partie d un système, fournissant un ensemble de classes abstraites ainsi que les moyens de les faire interagir. Il peut être utilisé pour décrire quelque chose qui est utilisable, non seulement tel quel dans une situation particulière, mais également, après modification, dans une situation similaire à la situation conçue initialement. Cette modification peut avoir lieu durant la phase de conception ou d exécution, et est appelée instantiation du canevas [CHJK02a]. La contribution majeure des canevas est qu ils forcent les composants à effectuer leurs tâches à l aide de mécanismes contrôlés par le canevas lui-même, ce qui renforce le respect des principes architecturaux. Nous citons comme exemple de canevas d applications le Jaf 12 (pour JavaBeansTM Activation Framework). Un canevas sert non seulement à réaliser des applications très rapidement, mais permet aussi d obtenir des applications à structures semblables [GHJV95]. C est un gain en terme de maintenance (connaissance de la structure des applications). Cependant, cette contrainte est parfois trop forte. Le risque est alors de trop limiter la structure des applications et de devoir adapter les composants existants au canevas. 12 Voir http ://java.sun.com/products/javabeans/glasgow/jaf.html pour plus de détail. 20

33 1.1. Concepts et définitions Cela entre alors en contradiction avec l esprit de la Cbse, qui promeut la réutilisation telle quelle de composants Relation entre ces concepts Fig. 1.5 Relation entre les concepts pour une application basée composants [BBB + 00] Dans cette section, nous établissons les relations entre les concepts vus précédemment. Nous nous appuyons pour cela sur la Figure 1.5, tirée de [BBB + 00], qui schématise ces relations. Un composant (1) est une implémentation logicielle mettant en œuvre un ensemble de services décrits par une ou plusieurs interfaces (2). Les composants respectent certaines obligations qui sont décrites par des contrats (3). Ceux-ci assurent que des composants développés indépendamment obéissent à des règles d interaction, et peuvent être déployés dans un environnement de compilation et d exécution standard (4). Une application basée composants est construite à partir d instances de composants. Chaque composant est basé sur un type de composants (5). Un modèle de composants (6) est un ensemble de types de composants, de leurs interfaces, et éventuellement de patrons de conception décrivant les interactions entre les différents types de composants. Un canevas d applications (7) fournit un ensemble de critères de déploiement et d exécution (8) comme support au modèle de composants. La notion de canevas est souvent liée à celle de patron. Ils décrivent tous deux un groupe de participants et les relations entre eux, ce qui permet de les réutiliser dans toute situation semblable. Szyperski dans [SGM02] les différencie en ce sens que le canevas décrit une unité de conception de taille plus importante et plus spécialisée (orientée architecture) que les patrons. Les concepts de modèle de composants et de canevas sont également relativement liés. Un modèle de composants définit un ensemble de standards et de conventions utilisés par le développeur de composants alors qu un canevas de composants est une infrastructure support pour les modèles de composants [BBB + 00, CHJK02a]. 21

34 Chapitre 1. Terminologie 1.2 Processus de développement d applications basées composants La structure particulière des applications à base de composants et l importance de la réutilisation pour un composant, font que les processus traditionnels de développement ont dû être adaptés pour le développement de ce type d applications. Dans cette section, nous discutons des particularités liées au processus de développement des applications à base de composants La réutilisation : un principe fondateur Un des objectifs du Cbd est de généraliser la réutilisation de modules logiciels. L intérêt majeur de la réutilisation est de réduire l effort de développement en réutilisant des parties de logiciels déjà développées (dans ce cas précis, des composants). Cela a également un impact qualitatif : statistiquement, plus un composant est réutilisé, plus les éventuels bogues qu il pouvait contenir peuvent avoir été détectés et corrigés. En théorie, les composants réutilisés ne nécessitent pas plus d effort d intégration que les composants développés spécifiquement. En pratique, ce n est pas totalement vrai. La réutilisation induit des efforts plus importants sur d autres postes du cycle de développement. Par exemple, la phase d intégration est plus difficile à réaliser puisque les composants réutilisés n ont pas été conçus spécifiquement pour l application dans laquelle ils vont être intégrés, à la différence d un développement classique. En effet, le composant, même certifié, peut présenter des incompatibilités avec l application dans laquelle il va être intégré, par exemple en terme de contraintes de temps ou de ressources Réutilisation versus réutilisabilité Le processus de réutilisation englobe la réutilisation elle-même mais également la réutilisabilité. La réutilisation concerne l action de sélection d un composant et d intégration dans une architecture logicielle. La réutilisabilité concerne le développement de l entité réutilisable. Plus précisément, la réutilisabilité consiste à dégager, pour le composant, un potentiel à être aisément réutilisable. La conception et le développement d une entité réutilisable sont différents d une conception d un développement spécifique. Le composant doit être pensé pour être réutilisé : il doit être robuste, compatible avec un maximum d environnements différents et extensible [Mey97]. Cela implique donc un développement plus coûteux qu un développement classique. Il est admis qu en moyenne, le développement d un composant par rapport à un développement spécifique est rentable s il est réutilisé plus de trois fois [SGM02] Boîte blanche vs boîte noire La réutilisation peut être envisagée suivant deux facettes : la réutilisation boîte blanche et la réutilisation boîte noire. Nierstrasz et Meijler dans [MN98] les décrivent de la manière suivante : «Applications developers develop specific applications by composing both domain-specific functional components and generic, coordination components, in a black box fashion ; components developers build black-box components by identifying useful software abstractions and factoring out both domain-specific an generic components». Deux points importants apparaissent ici. Le premier concerne la forme des composants. Ils sont vus comme des composants boîte noire. Cette approche est à opposer aux définitions précédentes qui sous-entendaient qu on pouvait adapter un composant. Adapter un composant est une approche boîte 22

35 1.2. Processus de développement d applications basées composants blanche. Szyperski [SGM02] définit les mécanismes d abstraction boîte noire et boîte blanche comme la visibilité de l implémentation «derrière» les interfaces. Une réutilisation de type boîte noire consiste à réutiliser le composant tel quel sans aucune vision de la manière dont il est implémenté et sans aucune modification de code de la part du développeur de l application. Le composant peut toutefois être adapté par son interface de configuration. On peut pour cela par exemple, avec les Ejb, utiliser les descripteurs de déploiements. Ces descripteurs permettent de décrire les attributs d exécution des composants côté serveur (sécurité, contexte transactionnel). Ils décrivent, pour les outils de déploiement, comment ajouter des composants au conteneur Ejb. Une fois le composant déployé, les propriétés décrites dans les descripteurs serviront toujours à indiquer au conteneur Ejb comment gérer l exécution du composant. La réutilisation par approche boîte blanche, par opposition à l approche précédente, consiste à réutiliser un composant en ayant accès à son implémentation et en permettant sa modification (adaptation). C est un peu l esprit qui anime les technologies open source : il est possible de réutiliser des technologies pour les adapter à ses propres besoins. La réutilisation boîte blanche induit une multiplication du nombre de composants. Cela peut être une complication pour la réutilisation car cela pose des problèmes : d identification, par exemple dans un entrepôt de composant ; de robustesse, car une modification peut introduire des erreurs dans le code du composant ; et de maintenance, car il peut alors exister plusieurs versions de composants se ressemblant mais ayant chacune des particularités. Cette approche est toutefois une thématique de recherche active, en particulier d un point de vue composition [MSKC04]. Nous préférons défendre une approche plus efficace en terme de cohérence globale, mais aussi plus difficile à réaliser, qui consiste à développer des composants boîte noire paramétrables prenant en compte un maximum de possibilités. [MN98] abonde en ce sens et dit que la forme de réutilisation la plus désirable est la réutilisation boîte noire. Ce choix découle également de notre intérêt particulier pour les Cots qui sont, par nature, le plus souvent boîte noire Acteurs du processus L évolution technologique que connaît l informatique a une implication directe sur le rôle et les compétences des divers acteurs entrant en jeu dans le cycle de vie d une application. La complexité croissante des applications et des technologies entraîne une spécialisation des métiers plus importante que par le passé. Le nombre d acteurs et les compétences nécessaires à la réalisation et à la maintenance d une application peuvent d ailleurs varier en fonction de sa taille, de sa complexité et de son domaine de l application. Dans le cadre des applications basées composants, il est intéressant de voir que les rôles des acteurs sont particulièrement indépendants les uns des autres [SGM02]. Parmi ces rôles, il est courant de distinguer le développeur de composants de l utilisateur de composants. Par utilisateur il faut entendre une personne intégrant ou réutilisant un composant pour une application. [MN98] parle de distinction nette existant entre deux rôles séparés avec des préoccupations séparées : le développeur d application, qui est l utilisateur de composants, et le développeur de composants. Afin d illustrer cette différence, considérons pour chacun les préoccupations concernant la réutilisation. Le développeur d applications est concerné par la réutilisation et le développeur de composants par la réutilisabilité. Marvie dans [Mar02] parle du cas des applications réparties à base de composants et va plus loin en identifiant six acteurs principaux : architecte logiciel, développeur de composants, intégrateur de composants, placeur de composants, déployeur d applications et administrateur d applications. Szyperski donne un point de vue différent dans [SGM02] et décrit le rôle de l architecte du système, de l architecte de canevas, du développeur de composants et de l utilisateur de composants. Plus précisément, ces rôles sont décrits comme suit : 23

36 Chapitre 1. Terminologie Architecte du système. Son rôle consiste à analyser les besoins et à établir, à partir du ou des systèmes existants, l architecture du système à développer. Par ailleurs, il découpe également l architecture du système en divers canevas d applications. Architecte de canevas. Son rôle est de comprendre l architecture du système, ainsi que son domaine, afin de déterminer quel(s) canevas utiliser. Il détermine les besoins du canevas ainsi que ce qu il fournit aux composants. Développeur de composants. A partir des spécifications du canevas et des besoins du composant, il analyse, conçoit et développe les composants. Il doit apporter un soin tout particulier à la réutilisabilité du composant. En effet, c est au développeur de composants (au sens large) d envisager la réutilisabilité du composant. Si le composant est bien conçu, elle sera importante. Dans le cadre des Cots, ce dernier point est encore plus critique puisque la réutilisabilité du composant dans ce cas représente sa valeur marchande : plus un composant est réutilisable, plus le retour sur investissement est important. Utilisateur de composants. On l appelle également assembleur de composants. À partir des besoins de l application, il sélectionne les composants et, éventuellement les canevas appropriés, et les assemble. Il détermine également s il ne trouve pas de composants correspondant à son attente, les besoins pour le développement d un nouveau composant. Enfin, il fournit un jugement sur la qualité des composants et des canevas qu il utilise. Dans [BSW03], l utilisateur de composants est décrit comme une tierce partie, voir un utilisateur final qui n est pas capable de, ou qui n est pas disposé à, modifier les composants. Il décide uniquement ce qui doit être composé et sous quelle condition ; pour cela il a besoin des spécifications des composants et de standards permettant aux composants créés, indépendamment les uns des autres, d interopérer. Dans la suite de ce document, nous allons surtout parler des développeurs de composants et des utilisateurs de composants. Par développeur de composants, nous entendons tout acteur créant des composants, et par utilisateur de composants, tout acteur développant une application à base de composants Étude du processus de développement Le processus de développement des applications basées composants repose globalement sur les même activités (résumées dans la Table 1.2) que le développement d une application classique [Som01]. Cependant, il diffère des développements traditionnels notamment à travers sa focalisation sur l identification d entités réutilisables et les relation entre elles et ce, notamment à partir de l analyse des besoins [ART03]. La réutilisation de composants implique un processus d identification et de sélection du composant à réutiliser, voir un processus de spécification de celui-ci en vue de son développement dans le cas où il n existerait pas. L aspect modularité implique un effort important de la conception de l architecture de l application, ce qui n était pas forcément le cas dans les développements classiques Modèles de développements classique et la Cbse Les modèles de développement classiques se prêtent plus ou moins à supporter le développement à base de composants. Le modèle séquentiel correspond à une étude séquentielle du système, de la phase de recueillement des besoins jusqu à la fin du cycle de vie. Chaque activité est terminée avant de passer à la suivante. Cette approche rigide est mal adaptée au monde composant. En effet, le développement à base de composants est typiquement un développement où des phases peuvent être menées en parallèle. Par exemple, si la phase d analyse détermine le besoin spécifique d un composant particulier, le modèle 24

37 1.2. Processus de développement d applications basées composants Activité Analyse des besoins et spécification du système Conception du système et du logiciel Implémentation et test unitaire Intégration, vérification du système et validation Opération de support et maintenance Suppression du système Description Les services, les contraintes et les objectifs du système sont établis. Ils sont définis en détails et servent de spécification au système. La conception du logiciel implique d identifier et de décrire les abstractions fondamentales du système logiciel et les relations entre elles. Une architecture globale pour le système est définie. Une conception détaillée suit la conception globale Formalisation de la conception dans une forme exécutable. Elle peut être composée de petites unités. Les unités sont vérifiées vis-à-vis de leur spécification. Les unités sont intégrées. Le système complet est vérifié, validé et délivré au client. Le système est opérationnel. Il requiert un support continu et des opérations de maintenance. Cette activité est souvent oubliée dans le cycle de vie d un système. Elle concerne la suppression propre du système et éventuellement son remplacement par un autre système. Tab. 1.2 Activités canoniques durant un cycle de vie [Som01, CJC02] séquentiel implique de terminer la phase d analyse avant de spécifier le composant à développer. Or, il peut être judicieux de commander le développement de ce composant, à un éventuel fournisseur, le plus tôt possible, de manière à tenir compte de son temps de développement. Les temps de développement sont par ailleurs différents en fonction du type de composants. Les composants génériques, c est-à-dire utilisables dans de nombreuses applications sont plus difficiles à réaliser que les composants métiers. Ces derniers sont les composants qui implémentent un ensemble de services liés à un domaine d application particulier. Leur réalisation est donc plus proche d un développement classique. Les modèles évolutionnistes permettent de développer un système graduellement, par itérations successives. À chaque étape, le résultat du système est montré à ses commanditaires et leurs remarques sont prises en compte pour faire évoluer le système [Pfl01]. L intérêt de ce type de modèles est de réduire fortement le risque de découvrir un problème crucial tard dans le cycle de développement. Le problème de ce type de processus est qu il peut engendrer un nombre coûteux d itérations. Il existe plusieurs types de modèles évolutionnistes, discutés notamment dans [CJC02]. L approche itérative, le modèle incrémental, le modèle par prototypage, et enfin, le modèle à spirale défini par Bœhm [Boe86]. Aucun de ces modèles n est conçu autour de la problématique de réutilisation. Ils peuvent cependant être utiles, comme par exemple le modèle par prototypage, pour déterminer rapidement la faisabilité d une application, ou s appliquer à certaines phases du développement des applications à base de composants. Le processus de développement logiciel unifié défini par Jacobson et al. [JBR99] est un processus de développement de système optimisé pour les applications objets et les systèmes à base de composants. Il s agit d un développement incrémental itératif composé de quatre phases. La première décrit formellement le système. La seconde, définit et crée l architecture du système. La troisième concerne le développement, avec des capacités de réutilisation. Enfin, la quatrième concerne la livraison du système au client. Pour chacune de ces étapes, il y a plusieurs itérations des activités classiques. Ce modèle est mieux adapté au monde composant. De plus, il est souvent utilisé avec Uml, dont la version 2.0 prend en compte la 25

38 Chapitre 1. Terminologie conception des applications à base de composants comme discuté dans le chapitre 3. Cependant, il ne traite réellement les aspects réutilisation que lors de la phase d implémentation, ce qui est, de notre point de vue, trop tard la plus part du temps, pour une réutilisation efficace Modèles de développements spécifiques à la Cbse La section précédente a montré que les modèles de l ingénierie logicielle classique pouvaient être utilisés comme base pour le développement d application à base de composants. Il sont toutefois mal adaptés et notamment sur deux aspects [MN98]. Premièrement, la réutilisation de composants est généralement envisagée trop tard dans le cycle de développement du logiciel, notamment après que la conception détaillée ait été finalisée, alors qu une réutilisation optimale des composants requiert également la réutilisation des architectures logicielles. Deuxièmement, aucune méthode existante ne donne de consigne précise sur la manière dont un composant doit être développé pour être réutilisable. Les méthodes classiques devront donc être adaptées pour prendre en compte les particularités de ce type de développement, notamment en insistant sur les aspects développement de composants réutilisables, mais aussi sur les aspects développement de systèmes à partir de composants [SGM02, Crn01]. La Figure 1.6 (tirée de [BBB + 00]) compare le cycle de développement d applications basées composants par rapport au modèle en cascade. Il existe des points remarquables sur cette figure. Le cycle de développement en cascade se décompose en trois grandes phases : analyse-conception, développementvalidation-déploiement et enfin maintenance. Le cycle de Cbd est plus complexe et moins décomposé en phases indépendantes les unes des autres. La partie analyse des besoins est couplée avec l identification et la sélection des composants à réutiliser. En parallèle, dans le cas où un composant satisfaisant ne peut être trouvé, il est nécessaire de le créer. Dans ce cas, le composant rentre dans un cycle de développement parallèle où il passera par les phases d implémentation/validation/mise à disposition du cycle classique. La phase adaptation du cycle composant concerne plusieurs points. Il peut s agir d adaptation au sens strict d un composant (approche boîte blanche). Cette phase concerne également la composition logicielle, c est-à-dire l assemblage de composants en vue de la réalisation d une application. Enfin, il faut noter le parallèle existant entre la phase de maintenance d une application classique et la phase de remplacement d un composant par un autre Spécificités du développement d une application à partir de composants La phase d analyse des besoins diffère d un développement classique car, en plus de spécifier les besoins du système, elle doit aussi conduire à l identification des composants nécessaires à la construction du système. Pour cela, elle doit définir préalablement l architecture du système, qui a pour objectif de définir les composants et leur moyen d interaction [SDK + 95, MT00]. Cependant, il n est pas trivial de déduire les besoins en terme de composants à partir des besoins du système, car cela peut amener à sélectionner des composants mal adaptés. Lorsqu un composant sélectionné répond aux besoins, il faut encore qu il puisse s intégrer dans l architecture logicielle, ce qui n est pas toujours le cas. En réalité, les processus d analyse des besoins et de conception doivent être combinés avec le processus de sélection des composants [CJC02]. La phase de sélection des composants est une phase particulièrement critique [FM03], notamment d un point de vue économique. Afin de réaliser une recherche efficace, le composant recherché doit être spécifié, si possible de manière standardisée. Le processus d évaluation inclut un aspect technique et un aspect non technique, ce dernier étant notamment basé sur des considérations économiques. Par exemple, il doit permettre de déterminer s il vaut mieux acheter un Cots ou développer un composant en interne. 26

39 1.2. Processus de développement d applications basées composants Analyse des besoins Conception Implémentation Test Livraison Maintenance Recherche Sélection Adaptation Test Déploiement Remplacement Création Fig. 1.6 Cycle de développement d applications basées composants comparé avec le cycle en cascade [BBB + 00] Bien qu il existe plusieurs méthodes permettant d évaluer un composant, il est souvent plus rentable de sélectionner un ensemble de composants répondant plus ou moins à la spécification, et notamment un assemblage de composants, que d évaluer un composant tout seul. Une fois le composant sélectionné, il faut alors déterminer si : le composant est adapté à la spécification ; la spécification doit être adaptée au composant ; un composant nouveau doit être développé. Dans un développement traditionnel, la phase de conception du système est le résultat de l analyse des besoins et du raffinement de plusieurs itérations. Dans le développement basé composants, l architecture initiale est le résultat de tous les besoins et du choix du modèle de composants. Ce dernier a un impact direct sur la rapidité d assemblage du système par la suite. Lors de la phase de développement du système, dans l approche basée composant idéale, l implémentation devrait se limiter au développement de code glu 13 (code d adaptation). Le code glu est le code ajouté aux composants afin de les rendre compatibles avec un environnement dans lequel ils n ont pas été conçus pour fonctionner. Ce code assure la liaison entre le canevas et le composant. Nous reviendrons plus en détail sur cette notion dans la section 2.2. En fonction des composants sélectionnés, du modèle de composants choisi, cela est plus ou moins vrai. De plus, il peut être nécessaire de développer, ou de faire développer, un composant spécifique pour pallier à un échec de la phase de sélection. La phase d intégration du système est la phase durant laquelle les composants sélectionnés et développés sont composés (c est-à-dire assemblés entre eux) pour créer le système. Cette phase devrait être triviale mais se montre en pratique très complexe, mis à part si les composants ont été conçus pour être composés ensemble. Ce n est cependant pas le cas général. Outre les adaptations syntaxiques, les composants peuvent être adaptés lorsqu ils ne répondent pas directement à la spécification. La configuration des assemblages de composants peut également poser problème. Enfin, l assemblage dynamique des composants lors de l exécution du système est également à prendre en compte. La difficulté de la 13 glue en anglais 27

40 Chapitre 1. Terminologie phase d intégration nécessite de tenir compte de l aspect intégration/composition durant tout le cycle de développement. La phase de validation et de vérification est similaire à celle d un développement classique. Il ne faut toutefois pas confondre ces deux termes. La vérification détermine si le système est correct vis-à-vis de lui-même. Par exemple la vérification d un modèle Uml consiste à observer si le modèle est correct par rapport à la définition d Uml. La vérification d un code consiste à vérifier si le code ne produit pas d erreurs. La validation détermine si le système répond au cahier des charges. Enfin, la phase de maintenance du système est similaire à celle d un système normal. Cependant, la mise à jour dynamique du système est rendue possible par le fait que les composants existent même lors de l exécution du système Spécificités du développement de composants Un composant doit être bien spécifié, facile à comprendre, suffisamment général, facile à adapter, facile à délivrer et à déployer, et enfin facile à remplacer [Crn01]. Cette phrase illustre bien la difficulté de développer un composant. En fait, le développement d un composant est, à de nombreux niveaux, comparable au développement d un système complet : les besoins doivent être établis, analysés et spécifiés, le composant doit être conçu, implémenté, vérifié, validé et délivré [Som01, Mey97, CJC02]. Cependant, cette vision globale du développement d un composant omet deux particularités qui pourtant sont à prendre en compte lors développement d un composant [CJC02] : d une part sa réutilisabilité et d autre part le fait qu un composant soit construit pour être une partie de quelque chose d autre. La difficulté du développement d un composant commence dès la phase d analyse des besoins. En effet, que l on se place dans le contexte d un composant à développer pour répondre à un besoin spécifique, ou bien dans le cadre d un composant générique Cots, l analyse des besoins est cruciale pour répondre pleinement à l attente des commanditaires du composant. Plus elle sera complète et stable, plus le composant sera réutilisable directement sans nécessité une adaptation. Cela implique également une étude approfondie sur les capacités de configuration du composant. Plus un composant est générique, plus il doit offrir de capacités de configuration de manière à être adapté à son futur environnement. Enfin, un composant doit fournir une spécification précise et complète. C est également là une clé de sa réutilisabilité. C est particulièrement vrai pour un composant fourni sous forme binaire. Une fois le composant développé, le fournisseur doit s assurer qu il répond bien à sa spécification. Cette vérification ne peut se faire qu unitairement et vis-à-vis de son environnement de développement. En effet, il n est pas réaliste de penser qu on puisse tester un composant par rapport à tous les environnements cibles dans lesquels il pourrait être déployé. Malgré cela, cette phase est importante puisqu elle assure la confiance entre les clients et le fournisseur. Ce dernier pourra également certifier le composant via une norme qualité pour améliorer encore son attractivité. 1.3 Résumé du chapitre Un composant est une entité logicielle qui encapsule totalement son implémentation et communique avec son environnement à travers des points d interaction clairement identifiés que sont ses interfaces. Un composant est une entité de composition et de réutilisation qui doit être conçue autour de ces deux objectifs. Il doit être déployable indépendamment par une tierce personne. Il offre souvent des moyens de persistance et peut donc être caractérisé par son état interne. Les interfaces d un composant sont de 28

41 1.3. Résumé du chapitre trois types : elles décrivent les services rendus, les services fournis et les services de configuration du composant. Elles contiennent généralement un ensemble d opérations réalisant ces services. Des contrats doivent être spécifiés et utilisés pour améliorer la sémantique de ces interfaces. Le type de ces contrats est lié aux moyens d implémentation choisis pour le composant et l application cible. Le terme «composant» peut avoir une sémantique différente en ce qui concerne sa forme physique. Nous retenons principalement les composants de modélisation, les composants en tant qu implémentation, et les instances de composants. L aspect conception des composants et des applications à base de composants est particulièrement important. Les patrons de conception offrent une assistance sur ce point. Le développement sera guidé par des canevas de conception et des modèles de composants. Les composants sont avant tout des unités de réutilisation. La réutilisation peut être envisagée sous un aspect boîte blanche ou boîte noire. La réutilisation boîte noire, bien que plus difficile à réaliser à grande échelle, nous paraît présenter plus de garanties pour un développement plus rigoureux. Le processus de développement d une application basée composants est différent de celui d une application classique. Les acteurs de ce processus sont d ailleurs hautement spécialisés et il est important de les différencier clairement. Nous considérons dans ce document deux acteurs particuliers : le fournisseur de composants et le développeur d applications à base de composants. Les modèles de développement classiques sont mal adaptés au développement des applications basées composants. Il peuvent toutefois être utilisés lors d étapes particulières du développement. Cependant, un effort particulier doit être porté sur la prise en compte de la réutilisation au plus tôt dans le cycle de vie de l application. 29

42 Chapitre 1. Terminologie 30

43 Chapitre 2 Composition logicielle et composition niveau modèle Sommaire 2.1 Composition Illustration de la problématique par une étude de cas Éléments de définition Mise en œuvre de la composition logicielle Langages de script Langages de glu Modèles de composants Langages de description d architecture Langages de composition Bilan de la composition bas niveau Composition au niveau conceptuel Le patron de conception Composite Contrats Approche formelle pour la composition Bilan sur la composition au niveau conceptuel La composition de composants permet de créer soit une application basée composants, soit de construire un composant de granularité plus importante. Il existe de nombreuses définitions de la notion de composition. Parmi celles-ci, Nierstrasz et Meijler [NM95] la définissent de la manière suivante : «Software composition is the construction of software applications from components that implement abstractions pertaining to a particular problem domain». La composition logicielle y est décrite comme un mécanisme, sans préciser lequel, permettant la construction d une application à partir de composants. Les auteurs ne donnent aucune indication sur une éventuelle sémantique de la composition ni sur les moyens pour la mettre en œuvre. Néanmoins, le Software Composition Group 14, dont Nierstrasz et Meijler font partie, propose de nombreux travaux théoriques et appliqués sur la composition. Nous y reviendrons plus en détail dans la suite de chapitre. Nous considérons la composition selon deux niveaux. Ces deux niveaux portent sur trois phases différentes du cycle de vie d une application : 14 http :// scg/ 31

44 Chapitre 2. Composition logicielle et composition niveau modèle La composition haut niveau, ou composition conceptuelle, concerne la phase d analyse et la conception globale du système. On traite l activité d identification et de description des abstractions fondamentales du système logiciel (composants) et les relations entre elles (compositions). Il s agit de considérer la composition au niveau modèle et donc de préparer et guider l assemblage au niveau programmation. Les langages de modélisation et de spécification permettent la réalisation de cette phase. La composition bas niveau, ou composition logicielle, concerne : la description de l architecture globale du système et la spécification de la conception détaillée. Cette phase peut être réalisée conjointement avec des Adl (Architecture Description Language) et des langages de modélisation et de spécification. l implémentation et le déploiement des compositions. Cette phase peut être réalisée à l aide des modèles de composants, des langages de script ou de glu, ou encore de simples langages de programmation. Dans ce chapitre, nous décrivons les différentes manières de réaliser la composition. Pour cela, dans la section 2.1, nous commençons par illustrer la difficulté de l assemblage de composants via un exemple. Puis, nous discutons plus en détail la composition logicielle. Dans la section 2.2, nous nous intéressons aux approches de composition bas niveau. Puis, dans la section 2.3, nous nous intéressons à la composition haut niveau. 2.1 Composition Intuitivement, on peut définir la composition logicielle comme l action de mettre en relation deux ou plusieurs composants afin de les faire interagir. A priori, si l on se réfère à la définition d un composant, cela ne pose pas de difficulté. La forme la plus simple de composition est l appel d une opération d un composant (service de l interface) par un autre. C est le cas en Ejb par exemple en permettant tout type d appel distant via la remote interface Illustration de la problématique par une étude de cas Nous nous appuyons sur une étude de cas que nous avons réalisée : la construction d une application basée composants gérant une machine à café ; nous la réutiliserons dans la suite de ce document La machine à café Nous envisageons un système de distribution de boissons. Il devra permettre à des utilisateurs de sélectionner une boisson, de la payer et de la récupérer. Le paiement pourra être fait soit en monnaie, soit au moyen d un compte personnel protégé par mot de passe. Ce compte pourra être crédité par l utilisateur via le même monnayeur que celui servant à payer en espèces. Une étude des besoins de l application a permis d identifier trois composants principaux : ComplexCoffeeMachine, permettant la gestion de l application et la communication avec les utilisateurs via une interface utilisateur (GUIComplexCoffeeMachine), E-Money permettant de gérer le porte-monnaie électronique des utilisateurs ayant un compte, et enfin CoffeeMachine permettant la distribution des breuvages ainsi que l insertion de monnaie (voir Figure 2.1). 32

45 2.1. Composition interface ComplexCoffeeMachine component ComplexCoffeeMachine component E-Monney component CoffeeMachine Fig. 2.1 Relations entre les composants de l application component CoffeeMachine component Coiner component DrinkMaker Fig. 2.2 Décomposition du composant CoffeeMachine 33

46 Chapitre 2. Composition logicielle et composition niveau modèle Présentation des composants identifiés CoffeeMachine gère les services de saisie de monnaie et ceux de préparation et de livraison des boissons. La Figure 2.2 décrit sa structure interne. Sa représentation en Uml 2.0. est réalisée sous la forme d un PackagingComponent 15. Il contient deux sous-composants représentés en Uml 2.0. sous la forme de BasicComponent : Coiner (voir la Figure 2.3) et DrinkMaker (voir la Figure 2.4). interface Coiner_ProvInt settargetprice() setcoin() getsum() cancelcoin() interface Coiner_ReqInt sendcoinok() component Coiner givechange() sendfinish() interface Coiner_ConfInt setreqinterface() Fig. 2.3 Représentation du composant Coiner Coiner gère la saisie et le remboursement de la monnaie. Il offre les services de spécification de la somme d argent à saisir, puis de saisie et de rendu de la monnaie. DrinkMaker gère la préparation et la livraison d une boisson. Il offre en outre un service d identification des boissons disponibles Exemple de composition logicielle Nous avons présenté les différents composants en tant qu entités autonomes. Nous illustrons ici une composition entre DrinkMaker et CoffeeMachine. Les composants détaillés précédemment ont été considérés au niveau modèle. Nous les avons implémentés en Java. Nous n utilisons pas, pour le moment, de modèles de composants. Nous souhaitons illustrer les problèmes de composition d une manière générale. Nous nous intéressons ici à la façon dont les composants interagissent et sont reliés entre eux. DrinkMaker fournit des services à CoffeeMachine et inversement. Un composant qui a besoin d un service d un autre composant doit référencer ce dernier pour pouvoir y accéder. Une première approche intuitive est de réutiliser les principes objets. Le composant est directement référencé dans le composant initial. Les opérations à utiliser sont appelées via cette référence. La Figure 2.5 donne un exemple de code ainsi développé. Il s agit d une implémentation possible de CoffeeMachine. Dans ce cas, CoffeeMachine crée une instance de DrinkMaker, dans son propre code. Cette forme de composition, la plus primaire, est 15 Les concepts PackagingComponent et BasicComponent sont décrits dans la documentation Uml ([OMG03d], p. 133) 34

47 2.1. Composition interface DrinkMaker_ProvInt setdrink() preparedrink() canceldrink() getkindofdrink() interface DrinkMaker_ReqInt getdrink() senddrinkok() component DrinkMaker sendfinish() interface DrinkMaker_ConfInt addtolistofdrink() setreqinterface() Fig. 2.4 Représentation du composant DrinkMaker 1 public c l a s s CoffeeMachine implements coffeemachine_ ProvInt, 2 coffeemachine_ ConfInt, 3 DrinkMaker_ReqInt, 4 Coiner_ReqInt { 5 // D e f i n i t i o n de l a composition : i n s t a n c i a t i o n des composants 6 Coiner _ coiner ; 7 DrinkMaker _drinkmaker ; 8 [... ] 9 // Appel d une des o p e r a t i o n s du composant DrinkMaker 10 _listofdrink = _drinkmaker. getkindofdrink ( ) ; 11 } Fig. 2.5 Composition logicielle primaire en Java 35

48 Chapitre 2. Composition logicielle et composition niveau modèle mal adaptée au domaine de la Cbse. Le couplage des codes est en effet maximal. Le remplacement d un composant par un autre implique la modification du code interne des composants Discussion Cet exemple est révélateur sur plusieurs points. D un point de vue composition bas niveau, la composition logicielle ne doit pas être traitée au niveau du code interne des composants : les codes doivent être indépendants les uns des autres. Les relations entre les composants doivent être décrites et réalisées en dehors du code des composants. Nous en reparlons plus en détail à la section 2.2. D un point de vue composition haut niveau, nous avons spécifié un modèle Uml dans lequel CoffeeMachine est composé de DrinkMaker et de Coiner (voir Figure 2.2). Or, il n y a aucun élément dans ce diagramme traitant de la composition en temps que telle, au niveau modèle. Il n y a pas de moyen, par exemple, de spécifier de sémantique particulière sur la composition. Dans les sections suivantes, nous discutons de différentes techniques de composition, tant haut niveau que bas niveau. Avant cela, nous précisons la notion de composition logicielle Éléments de définition L étude de cas précédente a montré qu il était difficile d assembler des composants avec les techniques traditionnelles de modélisation et de développement. Les définitions qui vont suivre précisent et augmentent celle de Nierstrasz, donnée en introduction du chapitre. Elles identifient deux niveaux sémantiques fondamentaux à partir desquels l assemblage de composants peut être traité Assemblage de composants : intégration versus composition Szyperski définit la composition comme suit : «Composition : Assembly of parts (components) into a whole (a composite) without modifying the parts. Parts have compositional properties if the semantics of the composite can be derived from those of the components» ([SGM02], p. 550). Stafford et Wallnau donnent une définition jouant sur la nuance entre les termes d intégration et de composition [SW02] : «Component integration is the mechanical task of «wiring» components together [...] There must therefore be a means of determining the properties of assemblies in order to check their run-time compatibility. Component composition supports this type of reasonning [...] Component composition is based on the ability to assign properties to the whole based on the properties of the parts and the relationships between the parts». Dans ces définitions, on retrouve deux aspects fondamentaux de la composition : une dimension architecturale, qui consiste à lier deux composants entre eux afin de remplir une ou plusieurs fonctionnalités. Elle s intéresse à faire correspondre des services requis avec des services fournis des composants. Il s agit la plupart du temps d une approche syntaxique. une dimension sémantique dans laquelle les propriétés de la composition sont définies à partir des propriétés des composants. Cette dimension est plus difficile à réaliser. Elle vise à répondre à des problèmes du type : prédiction du comportement des compositions ou contrainte du système par spécification de règles de composition. Tous les assemblages de composants, réalisés par intégration, ne sont pas viables en exécution. Combiner les dimensions architecturales et sémantiques d un assemblage est alors nécessaire, dans le but de déterminer quelles combinaisons de composants sont valides. 36

49 2.1. Composition La Figure 2.6 illustre la différence entre la dimension syntaxique de l intégration et la dimension sémantique de la composition. En (a), un lien entre deux composants A et B est modélisé. Chacun des composants est respectivement réalisé par trois composants respectant les interfaces. Chacune de ces réalisation est caractérisée par des particularités de type comportementale ou de charge mémoire, par exemple. En (b), les différents cas d intégration, de ces composants entre eux, est représenté. Chaque composant réalisant A (A1, A2 ou A3) peut être lié avec un composant réalisant B (B1, B2 ou B3). Enfin, en (c), la figure illustre le résultat de la composition. Seuls quelques réalisations peuvent être liées ensembles de manière à ce que ce lien «fonctionne» lors de la phase d exécution. «component» B3 «component» A3 «component» B3 «component» B «component» B2 «component» A2 «component» B2 «component» B1 «component» A1 «component» B1 (a) composition conceptuelle (b) intégration «component» A3 «component» A «component» A2 «component» A1 «component» A1 «component» A3 (c) composition «component» B2 «component» B1 Fig. 2.6 Différence entre intégration et composition La problématique de la composition logicielle a été étudiée de longue date. Par exemple, [Ode94] a proposé une étude caractérisant la composition logicielle en plusieurs sous-types. Malheureusement, comme le notent Lumpe et al. dans [LSS + 03], moins d efforts ont été faits dans la recherche de techniques de réalisation de la composition logicielle que dans le développement de modèles de composants particuliers. Schneider et Han dans [SH04] abondent en ce sens. Ils concluent que des freins à l usage généralisé et intensif de la Cbse perdureront tant que des réponses satisfaisantes à la question «comment composer correctement des composants logiciels entre eux?» n auront pas été apportées Techniques de composition L assemblage de composants peut être réalisé de plusieurs manières : visuellement, déclarativement, impérativement par langage de programmation ou par langage de script [Cer04] : la composition visuelle consiste à relier des représentations graphiques d instances de composants entre eux par des «traits» dans des environnements visuels de composition (par exemple l environnement BeanBuilder de Sun [Mic02]). 37

50 Chapitre 2. Composition logicielle et composition niveau modèle la composition déclarative consiste à utiliser des langages ([WD01] par exemple) décrivant les relations entre les concepts propres à la composition. Bien que proche des Adl, ces langages s en différencient par le fait que le résultat de la composition est toujours exécutable. la composition impérative par langage de programmation consiste à décrire les compositions en utilisant le même langage de programmation que celui des composants, par exemple Java. Cette approche est limitative à plusieurs niveaux. D une part elle rend difficile la décorrélation entre le développement et l assemblage. D autre part, ces langages sont généralement typés et compilés de manière statique ce qui rend difficile la maintenance et l évolution du système. la composition impérative par langage de script utilise un langage de script (CorbaScript [MGG97] par exemple) contenant ses concepts propres de composition. Ces langages sont généralement non typés et interprétés ce qui autorise une composition plus tardive. Leur utilisation autorise également une différenciation claire entre le développement et la composition de composants Composition horizontale versus composition verticale Plusieurs types de relations de composition se cachent sous l appellation composition logicielle. Elles peuvent être fondamentalement différentes. Nous en distinguons deux : la composition verticale et la composition horizontale. La composition horizontale représente l assemblage classique de composants. Elle peut être vue comme l échange de services entre composants de même granularité : un composant X fournit des services à un composant Y. Il s agit de la relation la plus couramment utilisée et envisagée pour assembler des composants. La composition verticale concerne l assemblage de composants réalisé entre un composant de granularité faible (sous-composant) et un composant de granularité plus forte (composé) 16. On parle alors d un composant composé de sous-composants [Bar02], ou de composition hiérarchique [MDEK95, Cer04]. Légende délégatoin port component Composant Management Interface de configuration du composant Interface de configuration du sous-composant component Sous-composant Client Interface de services fournis du composant Interface de services fournis du sous-composant Fig. 2.7 Organisation canonique d un composé en regard d un de ses sous-composants La Figure 2.7 illustre ce concept : le composé s appuie sur les services fournis par un ou plusieurs sous-composants pour proposer à son tour des services plus complexes. Lors de son déploiement, le composé, i.e. le composant construit par composition verticale, est configuré afin d être adapté à son nouvel environnement. La configuration de ses sous-composants peut être nécessaire mais elle est alors à 16 Villalobos, dans sa thèse [Vil03a] utilise une sémantique différente pour la notion de composition verticale. Il emploie le terme de composition verticale pour parler de la composition entre la ou les réalisations physiques des composants et leur modèle 38

51 2.2. Mise en œuvre de la composition logicielle la charge directe du composé. Le client du composé interagit avec lui au moyen de l interface de services fournis de ce dernier. Les services, décrits dans cette interface, peuvent être implémentés, soit directement par le composé, soit par un des sous-composants. Ils peuvent également être le fruit d une conjugaison entre les fonctionnalités du composé et celles d un ou de plusieurs sous-composants. Nous utilisons pour représenter ces deux derniers cas le mécanisme de delegation connector d Uml 2.0. L imbrication du sous-composant dans le composé est représenté en utilisant une composite structure. Ces mécanismes sont décrits dans la section 3.3. Le risque d augmentation du couplage entre les composants est une des conséquences négatives de la composition verticale. Cela dépend de la manière dont le lien de composition est implémenté (voir section 2.3.2). De plus, les apports de cette approches sont multiples. D une part, elle permet de réduire la complexité des architectures, en organisant l architecture en grands groupes de composants. Cela a pour effet d accroître le niveau d abstraction des architectures. Ce raffinement successif est utile dans les phases de conception pour concevoir l application progressivement [WCD + 01]. D autre part, le remplacement d un sous-composant par un autre n aura d impact direct que sur le composé dont il fait partie. À l extrême, les sous-composants de plus petite granularité peuvent être vus comme des pièces de base rendant un service unique. L encapsulation et l aspect boîte noire, qu impose généralement cette forme de composition, sont problématiques pour les Cots. En effet, il est très difficile de garantir qu une composition, qui réalise une vue externe, implémente, non seulement la structure, mais aussi le comportement défini par la vue externe [Cer04]. Cela pose donc des problèmes de confiance : il manque actuellement des moyens de validation spécifiques à cette approche hiérarchique. 2.2 Mise en œuvre de la composition logicielle Actuellement, la composition logicielle est principalement traitée au niveau implémentation. Sa réalisation se fait à travers des langages dédiés, dans un esprit d intégration plutôt que de composition. Nous distinguons plusieurs technologies mettant en œuvre des moyens de composition : les langages de script (section 2.2.1) forment la plus ancienne alternative à la composition par langage de programmation. Les langages de glu (section 2.2.2) sont plus spécifiques que les langages de script. Ils permettent la composition de composants hétérogènes, par enrobage. Les modèles de composants (section 2.2.3) offrent des moyens de composition directement utilisables au niveau implémentation. Les Adl (section 2.2.4) interviennent plus tôt dans le cycle de vie. Ils décrivent la composition d un point de vue architectural tout comme les langages de composition (section 2.2.5) plus spécifiques mais encore peu répandus Langages de script Les langages de script sont des langages de programmation censés être plus faciles à utiliser. Pour cela, ils sont souvent faiblement typés et la plupart du temps interprétés au lieu d être compilés. Ils sont une des plus anciennes façons de composer des composants [Gsc02]. Le développeur utilise un tel type de langage pour décrire les interactions et les interconnections entre composants. Les plus couramment utilisés sont les scripts Unix, Perl [Lar01], Tcl/Tk [Joh94] ou encore JavaScript [Dav01]. Cependant, ces langages souffrent du même problème que les langages de programmation classiques. Ils manquent de concepts spécifiques à la composition logicielle et sont donc mal adaptés à celle-ci. De plus, ils ne résolvent pas les problèmes d interopérabilité qui se posent lorsque la composition porte sur des composants hétérogènes. 39

52 Chapitre 2. Composition logicielle et composition niveau modèle Modèles JavaBeans Ejb Com et DCom.Net Ccm Fractal Koala Odp JavaPods Darwin Étudié dans [Mar02], [Vil03b], [Cer04] [Mar02], [Cer04] [Mar02], [Vil03b], [Cer04] [ART03] [Mar02], [Vil03b], [Cer04] [Cer04] [ART03] [Mar02] [Mar02] [Mar02] Tab. 2.1 Documentation existante sur les modèles de composants Langages de glu Les langages de glu sont souvent utilisés pour la composition logicielle. Il sont basés sur la technique de l enrobage. Cela consiste à enrober (encapsuler) les composants à l aide d un code spécifique permettant la communication et l assemblage avec d autres composants enrobés de la même façon [SN99, SML99]. L inconvénient principal de cette approche est qu elle surcharge systématiquement l application. De plus, même si elle représente une bonne réponse à l interopérabilité des composants, elle présente toutefois certaines limites, notamment sur les aspects maintenance. Par exemple, considérons une application, développée dans un premier temps avec des composants prévus pour fonctionner ensembles ; la glu n est pas nécessaire. Dans le cas du remplacement d un ou de plusieurs composants, non conçus spécifiquement pour cela, son utilisation peut être alors utile. Elle est alors coûteuse à mettre en place sur la totalité de l application Modèles de composants Les modèles de composants définissent des standards permettant aux composants d interopérer en vue de la réalisation d une application. Actuellement, il existe de nombreux modèles de composants. Citons les modèles : académiques (Darwin [MDEK95] et JavaPods [Bru02] ou Vienna [OGJ03] par exemple). Notons que Darwin est ici considéré comme un modèle de composants. Il est souvent classé en tant qu Adl. On peut expliquer cette confusion par le fait que Darwin est plus centré sur le comportement que sur la structure du système [ISW02] ; industriels (JavaBeans [Mic97], Ejb [Mic99], Com [Rog96] / DCom [Gri97] /.Net [SGM01]) ; intermédiaires, fruits d une coopération industrielle et académique (Odp [ISO98], Ccm [OMG99a], Koala [Omm02] et Fractal [BCS02]). La liste de ces modèles n est pas exhaustive. L objectif de cette thèse n est pas d étudier en détail les divers modèles de composants. De nombreuses études sur ce sujet ont été menées, par exemple dans des livres ([SGM02, EF02]), des rapports ([ART03]) ou dans des thèses ( Marvie [Mar02], Cervantes [Cer04] ou encore Villalobos [Vil03b]) et nous invitons le lecteur à les consulter. Le tableau 2.1 donne, en fonction des modèles de composants, une liste de documents à consulter. Cette liste n est pas non plus exhaustive. 40

53 2.2. Mise en œuvre de la composition logicielle Nous nous intéressons, dans cette section, à la manière dont ces modèles traitent l assemblage de composants, sans rentrer dans les aspects techniques. Nous nous attardons sur plusieurs modèles moins étudiés que sont Fractal (notamment pour son aspect hiérarchique et générique), Koala (pour son aspect spécifique à un domaine) et Vienna (pour son apport à l interopérabilité entre modèles) Les modèles classiques Les études citées précédemment ont établi les conclusions suivantes quand à l aspect composition des modèles de composants étudiés : JavaBeans est bâti autour d une composition principalement visuelle ; Com utilise une composition impérative, à travers un langage de programmation ou un langage de script. Ejb fait de même à travers le langage Java ; Ccm utilise une composition déclarative. La composition hiérarchique n est envisagé que dans Darwin, Odp et JavaPods Fractal Fractal [BCS02] est un modèle de composants, développé par le consortium ObjectWeb 17. Il est considéré comme générique puisqu il n est dédié à aucun domaine d application particulier. La composition peut être déclarative avec FractalADL ou visuelle avec FractalGUI. Fractal réalise la composition horizontale (avec la notion de primitive bindings). Un des aspects intéressants de ce modèle, outre sa généricité, est le support important de composition verticale qu il fournit (par la notion de composite bindings). La composition, est bâtie autour d une sémantique décrite dans [BCS02]. Cette sémantique repose sur deux dimensions : une dimension architecturale et une dimension dynamique. En particulier, ces dimensions sont envisagées autour des concepts d encapsulation, de composition, de partage, de cycle de vie, d activité, de contrôle et de mobilité. Nous considérons cette approche comme particulièrement importante. Notre approche est similaire sur ce point et nous y revenons en détail dans le chapitre 4. Un composant Fractal est composé de deux parties : un controller et un content. Le content est composé d autres composants qui sont sous le contrôle du controller du composant les contenant. Le modèle de composants est récursif et permet l imbrication des composants. Cette forme d encapsulation des composants n est pas stricte : un composant peut être partagé par plusieurs composants de niveau supérieur. Le composant est alors contrôlé par plusieurs controller. Un composant de haut niveau gère la configuration de tous les composants intervenant dans le partage. La Figure 2.8 montre une vue interne d un composant Fractal [BCS03]. On y voit un composant composé de deux sous-composants qui sont représentés par leur vue externe Koala Le modèle de composants Koala [vovdlkm00] permet un assemblage tardif de composants réutilisables sans surcoût de ressource, dans le domaine de l informatique embarqué. Il est utilisé dans le monde électronique (Philips) notamment pour intégrer des logiciels dans les téléviseurs. Il propose la conjonction d un modèle de composants classique (Com) et d un Adl (Darwin), tous deux améliorés, pour expliciter l architecture des applications. Il implémente la notion de composition hiérarchique (par des compound components). Le code suivant, tiré de [vovdlkm00] décrit la définition d un assemblage de composants. 17 http :// 41

54 Chapitre 2. Composition logicielle et composition niveau modèle Fig. 2.8 Vue interne d un composant Fractal [BCS03] Les liens entre composants et interfaces sont décrits comme des affectations. Aucune sémantique n est associée à la composition. 1 component CTvPlatform 2 { 3 provides IProgram pprg ; 4 requires I I 2 c slow, f a s t ; 5 contains 6 component CFrontEnd c f r e ; 7 component CTunerDriver ctun ; 8 connects 9 pprg = c f r e. pprg ; 10 c f r e. rtun = ctun. ptun ; 11 ctun. r i 2 c = f a s t ; 12 } Vienna Le Vcf (Vienna Component Framework) [OGJ03] permet l interopérabilité et la composition de composants développés selon des modèles de composants différents. Il permet actuellement la prise en compte des propriétés suivantes : gestion du cycle de vie des composants, gestion de la persistance, accès aux méthodes fournies par le composants, manipulation des états du composant et transfert des événements aux différents composants. Il est évolutif : la prise en compte des modèles de composants se fait à l aide d une façade générique derrière laquelle se trouve un plugin spécifique à chaque modèle de composants (voir Figure 2.9). Ainsi, pour traiter un nouveau modèle de composants, il suffit de développer un nouveau plugin. 42

55 2.2. Mise en œuvre de la composition logicielle Fig. 2.9 Architecture du Vcf [OGJ03] A notre connaissance, ce modèle permet d assembler des composants mais ne fournit pas de moyen spécifique pour la composition hiérarchique Bilan sur les modèles de composants Les modèles de composants cités précédemment sont la plupart du temps spécifiques à un domaine ou une technologie. JavaBeans et Ejb sont liés au monde Java. Com, DCom et.net au monde Microsoft. JavaBeans est plutôt lié aux applications non distribuées supportant l interaction à travers une interface utilisateur. Koala est dédié aux applications embarquées. Actuellement, il n existe pas de modèle de composants «idéal» [Mar02]. Vienna est une approche intéressante pour la composition de composants développés dans des modèles de composants hétérogènes. Fractal est un modèle de composants récent et prometteur. Il a été conçu notamment pour pallier au manque de généricité des modèles de composants classiques. D un point de vue composition, tous supportent la composition horizontale. Seuls Darwin, Odp, JavaPods, Koala et Fractal supportent la composition hiérarchique. Darwin, comme le montre [Mar02], n offre pas tous les concepts que peuvent fournir les modèles de composants récents. À l inverse, Odp prend en compte la plupart de ces concepts. Il n est cependant pas utilisable directement : il doit être instancié. Koala est particulièrement intéressant à travers l analogie avec les composants électroniques : il est centré sur l assemblage tardif et n ajoute que peu de surcharge lorsqu il est utilisé, par rapport à un développement classique. Enfin, Fractal est réellement centré sur la composition hiérarchique. Il s appuie pour cela sur un ensemble de propriétés de composition, non spécifiées explicitement Langages de description d architecture Les Adl spécifient l architecture d une application. Nierstrasz et Meijler définissent une architecture logicielle comme suit [NM95] : «A (software) architecture is a description of the way in which a specific system is composed from its components». Une architecture logicielle décrit donc l ensemble des composants d une application et leurs interconnexions, à travers généralement les concepts de composants, 43

56 Chapitre 2. Composition logicielle et composition niveau modèle d interfaces et de connecteurs. Les Adl sont à un autre niveau de préoccupation que les modèles de composants. On peut parler de niveau macroscopique pour les Adl et microscopique pour les modèles de composants [Mar02], ce qui les rend complémentaires. Les Adl sont utilisés lors de la phase de conception avancée et les modèles de composants pour la réalisation des applications. Tout comme pour les modèles de composants, nous ne décrivons pas en détails les Adl. De nombreuses études le font. Notons en particulier l article de Medvidovic et Taylor [MT00] qui dresse une classification d un grand nombre d Adl. Cette classification a été établie à travers un canevas de classification défini par les auteurs. Notons également l étude de Marvie dans [Mar02] portant sur un plus petit nombre d Adl (Rapide [Tea97], Wright [All97], Acme [GMW97], xarch et xadl 2.0 [DvdHT02], C2 [TMA + 96] et Olan [BBB + 98]) mais étudiés plus en détail : les Adl sont comparés selon un canevas de comparaison centré autour de quinze concepts (structure, validation, intégration, déploiement ou propriété hiérarchique par exemple). Il est intéressant de noter que ces deux études sont en désaccord sur les capacités des Adl à traiter la composition hiérarchique. Marvie soutient que tous les Adl n offrent pas la prise en compte de la composition hiérarchique : seuls Wright et Olan la supportent explicitement. À l inverse, Medvidovic et Taylor disent que «Most ADLs provide explicit feature to support hierarchical composition of components...». Même si les Adl offrent une vue macroscopique de l application, ils sont avant tout des langages de description et non de conception. Ils s utilisent lorsque le concepteur a une vue complète de l architecture de l application. Ils sont d excellents outils transitoires entre la conception de l application et l assemblage de composants avec les modèles de composants. Le choix d un Adl implique la plupart du temps l utilisation d un modèle de composants spécifique. Or, nous avons vu que certains modèles de composants étaient limités quant aux possibilités offertes pour la réalisation de la composition hiérarchique. Cela implique un choix rigoureux quant à l Adl à utiliser. Cette remarque est d autant plus vraie que les Adl sont souvent, ou trop génériques (lourdeur et difficulté d adaptation de la généricité) ou trop spécifiques à un domaine particulier (inadaptation totale pour une utilisation hors domaine) Langages de composition Les langages objets qui se focalisaient sur le niveau objet n ont pas réussi à fournir une vue compositionnelle des applications [NM95]. Les langages de composition sont des langages opérant à un plus haut niveau d abstraction [Gsc02]. Ils représentent un amalgame entre le scripting, les Adl, et les langages de coordination [Ach02]. Ils sont centrés sur la composition logicielle. Plusieurs approches ont été menées pour la réalisation des langages de composition. La plus significative s appuie sur la base formelle du π-calcul. Elle est menée par le Software Composition Group (SCG) de l Université de Berne. L équipe de Nierstrasz a réalisé séquenciellement Pict [Jea96], un langage de composition expérimental, puis Piccola [Ach02], un langage de composition plus évolué, supportant un grand nombre de modèles de composants à travers la définition de différents styles de composition. Un autre langage de composition basé sur une approche formelle (processus algébrique FSP) a été proposé par le SEI. Il s agit de CL [ISW02]. En plus de ses capacités de traitement des compositions logicielles, il a été conçu pour permettre la prédiction de leur comportement. D un point de vue moins formel, le langage Bean Markup Language [WCD + 01], développé par Ibm, est un autre exemple de langage de composition. Il s agit d un langage déclaratif basé sur Xml et permettant de spécifier la composition de composants JavaBeans. Citons dans le même type le Long- Term Persistance for JavaBeans de Sun [Mic01]. 44

57 2.3. Composition au niveau conceptuel Bilan de la composition bas niveau Nous avons présenté dans cette section plusieurs techniques de composition logicielle bas niveau. Nous utilisons le terme bas niveau pour parler de techniques permettant la réalisation de la composition entre composants, de la phase de conception avancée au déploiement des composants. Un large choix technologique est offert au développeur d applications à base de composants. La dynamique actuelle s oriente d ailleurs vers une utilisation conjointe de plusieurs de ces techniques. Des langages de script par exemple sont souvent intégrés à des modèles de composants ou à des Adl. Les langages de glu sont souvent couplés avec un Adl. Les modèles de composants sont largement orientés implémentations. Un des problèmes identifiés [EF02] de ces modèles de composants est leur mauvaise habitude à focaliser sur des problèmes pratiques et à être décrits suivant une approche technique orientée implémentation. Cela les rend difficiles à comprendre en terme de concepts et de principes. Le nombre de modèles de composants implique d ailleurs aux développeurs d applications de devoir connaître plusieurs technologies complexes. Un autre problème des modèles de composants concerne la réutilisation : réutiliser des composants développés selon un modèle distinct n est possible que dans une application développée selon le même modèle de composants. Des travaux comme le Vcf visent à remédier à cette lacune, autrement qu en utilisant des langages de glu. À ce jour et à notre connaissance, cette plate-forme n est encore qu expérimentale et nécessite le développement de pluggins pour chaque modèle de composants. Les Adl permettent de décrire l architecture de l application. Ils sont souvent orientés vers un modèle de composants spécifique. Ils n offrent généralement qu un support descriptif à la composition. Les langages de composition, par définition, sont plus spécifiques que les Adl. Actuellement, ils sont soit spécifiquement formels, soit spécifiques à une technologie. Leur intérêt principal est d apporter une sémantique à la composition logicielle. Pour conclure sur cette partie, nous reconnaissons l importance d utiliser les modèles de composants pour développer une application, mais nous nous associons à la remarque de Marvie stipulant l importance de ne pas s enfermer dans un modèle technologique [Mar02]. Cette constatation est dans l esprit de l approche MDA [BGMR03], proposée par l OMG. Celle-ci propose de développer des applications uniquement par transformation de modèles. L application est conçue indépendamment de tout modèle technologique et est générée automatiquement par transformation de modèle. Cela signifie que la composition logicielle doit être traitée au plus tôt dans le cycle de vie des applications et sous forme de modèle indépendant de toute mise en œuvre technique sous-jacente. 2.3 Composition au niveau conceptuel Après avoir discuté des techniques de composition bas niveaux, nous discutons ici des méthodes permettant la spécification de la composition lors des phases d analyse et de conception préliminaire. D un point de vue conception des composants, l intégration de la composabilité est un facteur favorisant la réutilisation. D un point de vue conception des applications à base de composants, la prise en compte de la composition permet de bien spécifier les relations entre les composants, notamment sur des points tels que les dépendances entre composants ou les comportements des assemblages de composants, par exemple. Ces points sont particulièrement importants, pour les préoccupations d adaptation des composants [MSKC04] : elles sont difficiles à réaliser lorsque les dépendances entre les composants ne sont pas formellement spécifiées. La spécification des compositions est encore plus vitale dans le cadre des 45

58 Chapitre 2. Composition logicielle et composition niveau modèle assemblages de composants boîte noire, puisque dans ces cas, on ne peut pas par définition les adapter. Il est alors nécessaire de déterminer les propriétés des compositions pour améliorer la compatibilité des composant lors de leur exécution [SW02]. Cette préoccupation n est pas récente. Déjà, Garlan et al. dans [GAO95] considéraient que le manque d information sur la conception des composants était un des problèmes les plus significatifs du développement de logiciels basés composants. Malgré cela, les efforts menés pour améliorer la prise en compte de la composition, lors des phases d analyse et de conception, n ont pas été suffisants [ART03, Hig01, BSW03, LSS + 03]. Considérer la composition au niveau modèle pose plusieurs problèmes significatifs. Par exemple, assurer la propagation des propriétés assurant la qualité logicielle lors de la composition de services en est un. Dans le rapport final de l atelier WCOP03 [BSW03], il est dit que, s il est délicat de le faire pour les propriétés fonctionnelles, il l est encore plus pour les aspects non-fonctionnels. En effet, pour ces derniers, des nouveaux aspects apparaissent lors des compositions et sont difficiles à prévoir et à contrôler. Cela rejoint un autre point souvent envisagé dans les travaux portant sur la Cbse concernant les propriétés fonctionnelles et non fonctionnelles des composants et des assemblages de composants. On parle également de «separation of concerns», qui est un principe de base de l ingénierie logicielle et qui vise à dissocier les propriétés fonctionnelles des propriétés non fonctionnelles [Wal95]. Dans ce cadre, [JPWG01] propose comme solution de générer les contrats portant sur les propriétés non fonctionnelles sous forme d aspects. Plus généralement, l utilisation de la programmation orientée aspect (AOP pour Aspect Oriented Programming), pour résoudre les problèmes liés aux propriétés non fonctionnelles, trouve de plus en plus de défenseurs. Les méthodes utilisées pour l analyse et la conception peuvent être classées en trois catégories : les approches formelles, semi-formelles et informelles [FKV94]. Les approches informelles correspondent à des spécifications en langage naturel. Elles peuvent par exemple définir des règles résultant d une certaine capitalisation des connaissances. Les approches semi-formelles utilisent généralement une sémantique particulière pour la réalisation des modèles de conception, mais n offrent pas de moyen de prouver mathématiquement que ces modèles sont corrects et/ou que les applications réalisées respectent les propriétés spécifiées dans le modèle. Elles s appuient généralement sur des notations graphiques de types diagrammes, ce qui a pour avantage de représenter le système à modéliser synthétiquement. Les approches formelles permettent de décrire, à l aide d un formalisme précis, reposant sur une base mathématique, les spécifications d une application critique. Dans la suite de cette section, nous montrons deux techniques permettant la prise en compte de propriétés compositionnelles lors de la modélisation des assemblages de composants logiciels : les patrons de conception et en particulier le patron Composite, d une part, et les contrats de conception, d autre part. Les approches à patrons et l utilisation de contrats sont largement reconnus comme des techniques utiles pour la conception des systèmes. De nombreux travaux s y intéressent. Enfin, nous faisons un aparté à propos des méthodes formelles pour nous situer plus spécifiquement par rapport à leurs utilisations Le patron de conception Composite Les patrons de conception (Gamma et al. dans [GHJV95]), présentés en section 1.1.6, peuvent être utilisés pour la modélisation des applications à base de composants. En particulier, le patron Composite, décrit par Gamma et al., traite la notion de composition. Il permet d organiser les entités à modéliser sous forme hiérarchique dans laquelle entités et compositions d entités sont traitées uniformément. La Figure 2.10 montre le modèle Uml de ce patron. Un composant peut être soit une feuille (un composant simple) soit un composite (un composant composé de feuilles et de composites). Bien que très utile 46

59 2.3. Composition au niveau conceptuel pour modéliser la composition hiérarchique, ce patron présente quelques faiblesses. Il est notamment parfois trop généraliste (un composite accepte n importe quelle forme de composant) et manque de sémantique. Même si l utilisation de contraintes Ocl par exemple peut pallier à ce manque en restreignant les conditions de son usage. Client Component Operation() Add(Component) Remove(Component) GetChild(int) 0..* Leaf Operation() Composite Operation() Add(Component) Remove(Component) GetChild(int) +children forall g in children g.operation(); Fig Le patron Composite [GHJV95] Contrats Un des challenges de la composition logicielle est de pouvoir déterminer que deux composants sont compatibles entre eux. On peut le traduire par la notion de compatibilité. Nous avons vu dans la section que la notion de contrat permet de décrire plus précisément l interopérabilité entre composants. L importance de la spécification de contrats pour les composants est largement reconnue. La nature des contrats et les techniques de spécification de contrat, peuvent varier en fonction de la nature du composant : c est le cas par exemple des approches où le composant est considéré comme une entité ayant un état [Mey03], ou n ayant pas d état [SGM02]. Parmi les techniques permettant de spécifier des contrats, nous mentionnons les langages de logique du premier ordre, du type Ocl et les langages à automates, comme les Statecharts de Harel [Har87] ou les «protocol state machine» exprimables sur les ports en Uml 2.0. Nous présentons ici succinctement quelques approches appliquant les contrats à la composition des composants. [CdAHS03] définit un formalisme pour la spécification de contrats exposant les besoins du composant en terme de ressources critiques. [WBGP01] présente une approche définissant des contrats sur des propriétés non fonctionnelles dans le métamodèle Uml. [LFA02] utilise la notion de contrats de coordination pour exprimer formellement le lien entre deux composants. Un des points intéressants de cette approche est qu elle fournit un outil pour générer, à partir d une expression textuelle du contrat, le code Java correspondant. Le projet Accord 18 définit les principes de construction d une architecture logicielle fondée sur les concepts de composants logiciels et de contrats. La spécification des composants 18 Le projet ACCORD est un projet RNTL développé par les partenaires suivants : le Cnam, Edf R&D, l Enst- Bretagne, France Telecom R&D, l Inria avec notamment l équipe Triskell, le Lifl, et la société Softeam. Voir http :// 47

60 Chapitre 2. Composition logicielle et composition niveau modèle repose sur un contrat de «Type». Un tel contrat exprime des aspects fonctionnels (ou sémantiques) et pragmatiques [GLAM + 04]. Il est composé de «facettes» permettant d organiser la spécification en entités comparables. Les facettes sont définies soit en utilisant un formalisme particulier (Ocl ou clauses logiques [CFN04], par exemple), soit en utilisant des diagrammes Uml Approche formelle pour la composition L utilisation d approches formelles pour la modélisation est un domaine actif du génie logiciel [Ber01]. Les méthodes formelles sont généralement divisées en deux grandes familles. La première famille comporte les méthodes dites constructives et la seconde les méthodes par vérification de modèles. Les méthodes de la première famille vont «construire» au fur et à mesure le produit final attendu alors que celles de la seconde famille vont vérifier la correction de l expression de ce produit sous forme d automates (par exploration des états atteignables) [Pet03]. En guise d application réussie, on peut citer la ligne de métro 14, Météor, dont le système de pilotage sans chauffeur a été développé en B, et qui est opérationnelle [BBFM99]. La communauté des méthodes formelles s est intéressée à la composition logicielle. [Kin02] propose une approche pour décrire sémantiquement et formellement les composants. L article présente un algorithme déterminant automatiquement si les composants peuvent interopérer sans se soucier de la syntaxe ou du modèle de composants sous-jacent et également les moyens pour générer automatiquement le code glu. [MS03] propose un modèle mathématique pour modéliser la sémantique de la composition de composants logiciels. Cependant, à l heure actuelle ce travail a été principalement théorique. Les auteurs travaillent d ailleurs à appliquer leur modèle à Uml : «our work has been mostly theoretical. If this theory is to be of any pratical use, then it must be presented in a way accessible to the non-theoretician. For this reason we are looking into pragmatic extension of Uml». Le couplage d une méthode formelle avec une notation objet et plus particulièrement Uml est un axe de recherche important actuellement. Citons pour exemple les travaux portant respectivement sur Z [Bru96, Dup00] et B [Led02]. En effet, les notations telles qu Uml proposent un formalisme aisément accessible mais manquant de sémantique. À l inverse, les approches formelles offrent une sémantique précise mais sont encore peu accessibles. Le couplage des deux approches apporte donc une amélioration à l activité de spécification [Led02]. Dans le cadre de la Cbse, une thèse récente [Pet03] propose l utilisation du langage B pour la spécification et la génération automatique du code des composants [PMP03]. Cette approche permet également la génération des contrats associés Bilan sur la composition au niveau conceptuel La prise en considération de la composition au niveau conceptuel est une problématique désormais clairement identifiée. Divers travaux ont présenté des approches visant à répondre à cette problématique. Parmi celles-ci les patrons et de contrats sont des techniques largement utilisées, que ce soit dans des approches informelles, semi-formelles ou formelles. Considérons le cas des approches semi-formelles ou formelles. Les approches formelles présentent l avantage de s appuyer sur une sémantique spécifiée mathématiquement. Cependant, elles manquent encore de reconnaissance de la part du monde industriel. À ce titre, Henri Habrias note dans l avantpropos de [Hab01] :«il semble que les «méthodologistes» du «marché» ignorent ces travaux 19. Il est étonnant par exemple, de voir depuis trente ans, de «nouvelles méthodes» manipulant les concepts d invariant, de relations, d éléments de produits cartésien, de fonction (injective, surjective, etc.) sans le 19 Note : l auteur parle des méthodes formelles. 48

61 2.3. Composition au niveau conceptuel dire explicitement, sans pratiquer la «réutilisation» des enseignements fondamentaux de l informatique, et en introduisant chaque fois de nouvelles notations graphiques, dont à chaque nouvelle livraison, il faut deviner la sémantique». Il faut cependant modérer ce propos : «despite some well-known critiques, diagrammatic languages are proving extremely helpfull in software and systems development» [HR04]. Pour allier ces deux points de vues, des approches proposent le couplage des méthodes formelles avec ces «nouvelles notations graphiques». Nous proposons une démarche différente. Plutôt que de redéfinir la sémantique des approches semi-formelles via une méthode formelle, nous proposons d améliorer la sémantique des approches semi-formelles, en s appuyant sur les outils sémantiques qu elles apportent. Uml est en passe de devenir l approche semi-formelle la plus utilisée pour modéliser les applications à base de composants. Ce langage de modélisation utilise d ailleurs un langage formel basé sur la logique du premier ordre pour décrire sa sémantique. Nous proposons d étudier la manière dont le langage permet de décrire la composition logicielle (voir chapitre suivant) et, le cas échéant, d améliorer le langage sur ce point particulier. 49

62 Chapitre 2. Composition logicielle et composition niveau modèle 50

63 Chapitre 3 Uml et les composants Sommaire 3.1 Modélisation, métamodélisation et métamétamodélisation : une question d à propos Uml 1.x Uml Aperçu des améliorations Nouveaux concepts Diagrammes de composants Support pour la composition Nouveau métamodèle La composition conceptuelle en Uml Limites de la composition conceptuelle en Uml Nos solutions Apport d Uml 2.0 par rapport à Uml 1.x Problématique de notre thèse Nous avons volontairement exclu de la discussion précédente le cas d Uml. Uml est un langage de modélisation, apparu officiellement en 1997 à travers la version 1.1, sous l égide de l OMG, organisme de normalisation international. L objectif d Uml était d unifier les approches de modélisation (à base de formalismes essentiellement graphiques, semi-formels) sur la base du paradigme orienté objet [BLB02]. Ce travail de normalisation a fait suite aux travaux de Rumbaugh, Booch et Jacobson visant à atteindre un consensus sur les concepts fondamentaux de l objet à travers une méthode unifiée. Malgré la présence du terme «langage» dans l acronyme d Uml, et la définition de sa sémantique par métamodélisation (les concepts de construction sont exprimés en Uml), la compréhension et l usage d Uml restent sujets à problèmes [BLB02]. D ailleurs, David Harel dans [HR04], dit que «the metamodel is but a way to describe the language s syntax ; it is a crucial precursor, but it is not the semantic itself». Cependant, ce langage de modélisation est actuellement admis comme le standard de modélisation de facto, tant du point de vue du monde académique qu industriel. Nous allons donc nous attarder plus en détail sur la manière dont Uml traite la composition au niveau conceptuel. Ce standard est par ailleurs en train de connaître une évolution majeure en passant des versions 1.x 20 à la version 2.0. Aussi nous allons nous intéresser séparément à ces deux versions. Nous nous sommes inspirés pour cela d un travail mené dans [BO04]. 20 nous utilisons la notation Uml 1.x pour parler des versions 1.4 et 1.5 d Uml. 51

64 Chapitre 3. Uml et les composants Dans ce chapitre, nous commençons par traiter de métamodélisation (section 3.1). Nous présentons ensuite Uml.1.x (section 3.2) et les évolutions de la version 2.0 (section 3.3). Nous traitons alors la manière dont est mise en œuvre la composition des composants (section 3.4), avant de parler des apports de la version 2.0 par rapport à la version 1.x (section 3.5). Enfin, (section 3.6) nous concluons sur la partie I et nous posons la problématique de notre travail de thèse, qui est de proposer un modèle de composition au niveau conceptuel permettant d apporter une sémantique (au sens Uml) à la relation de composition et de la garantir à chaque stade du développement, et ce jusqu au code. 3.1 Modélisation, métamodélisation et métamétamodélisation : une question d à propos L écriture de modèles requiert des moyens d expression basés sur une syntaxe et une sémantique précise. On peut comparer cela à la nécessité, pour écrire des programmes, de disposer de langages de programmation. Dans le cadre des modèles, on parle de métamodélisation 21. L écriture de modèles est une technique permettant la représentation non exhaustive de systèmes. Ils correspondent au point de vue du concepteur sur le système qui oriente le modèle sur ses besoins. Cela permet une simplification pour des questions notamment de lisibilité et de compréhension. On peut dire qu un modèle est une représentation filtrée d un système [Bre02]. Ce filtre est un métamodèle. Un même système peut donc être modélisé différemment en fonction du métamodèle sur lequel il est basé. Afin de différencier les termes utilisés précédemment, nous considérons les définitions suivantes données par Bézivin et al. dans [BG01] : un modèle est une abstraction d un système qui devrait être plus simple que celui-ci. Cette simplification se traduit, en général, par la disparition de détails d ordre technique. Un modèle représente le système qu il décrit et doit pouvoir être utilisé à sa place pour répondre à un certain nombre de questions sur celui-ci ; un métamodèle est la spécification d une abstraction, i.e. d un ou plusieurs modèles. Cette spécification définit un ensemble de concepts importants pour exprimer des modèles, ainsi que les relations entre ces concepts. Le métamodèle définit la terminologie à utiliser pour définir des modèles. La métamodélisation est donc une technique de définition de concepts permettant de modéliser des systèmes. Cependant, un métamodèle est spécifique à un domaine particulier. Uml par exemple est un métamodèle permettant de définir des modèles en utilisant une approche inspirée de l OO. Il ne peut exister de métamodèle universel permettant de décrire tout type de système informatique [Mar02]. Dans ce cadre, l OMG a définit le métamodèle Meta Object Facility (Mof) [OMG03a], pour définir des métadonnées. Une métadonnée est un terme générique correspondant à une donnée représentant de l information. Le but du Mof est de fournir un cadre de travail supportant tout type de métadonnée, et permettant la définition de nouveaux types en fonction des besoins. Pour atteindre ce besoin, le Mof repose sur une décomposition de son architecture en quatre niveaux. La clé de voûte de cette architecture est la présence d un niveau de métamétamodélisation, dans lequel est décrit le modèle Mof. La Figure 3.1 décrit l architecture du Mof. Le niveau M0 est le niveau contenant les informations à décrire (une instance de composant par exemple). Le niveau M1 contient les métadonnées décrivant l information regroupées sous forme de modèles (le modèle des composants et des liens de composition entre eux par exemple). Le niveau M2 contient les métamétadonnées, c est-à-dire la description de la 21 méta : du grec, signifiant à propos de. 52

65 3.2. Uml 1.x métamétamodèle Entité, Relation, Paquetage (M3) métamodèle Classe, Composant, Méthode (M2) modèle CoffeeMachine, Coiner (M1) information acoffeemachine, acoiner, othercoiner (M0) Fig. 3.1 Les différents niveaux du Mof structure et de la sémantique des métadonnées (la notation utilisée pour le modèle Uml par exemple). Ces définitions sont regroupées au sein d un métamodèle. Il contient par exemple la définition de ce qu est un composant. Enfin, le niveau M3 décrit la structure et la sémantique des métamétadonnées, regroupées au sein d un métamétamodèle. Notons que pour éviter une infinité de niveaux, le niveau M3 est métacirculaire et suffit à se décrire. 3.2 Uml 1.x Dans Uml 1.x, les composants sont représentés par le concept de component 22, vu comme une partie du package Core du métamodèle Uml. Un component est un classifier, qui représente : «a modular, deployable and replaceable part of a system». Il peut être spécifié par un ensemble de classifiers faisant partie de lui. Selon le standard, un composant peut être implémenté par un ensemble d artifacts (exécutable, fichier binaire...) et peut être déployé sur un (ou en ensemble) de nœud(s) (node(s)). Les composants Uml 1.x sont utilisés dans les modèles de conception et d implémentation. Le component est un concept de niveau type, ce qui n est pas surprenant puisque c est une sorte de classifier. Le concept correspondant au niveau instance est une instance de composant (Component instance). Elle réside sur une instance de nœud (Node instance). Notons qu Uml considère qu une instance de composant peut avoir un état («may have a state»). Cependant, rien n est mentionné dans le standard sur : la nature de cet état ; la manière dont cet état peut être utilisé ; le type de concept à utiliser pour manipuler cet état ; par exemple on peut se poser la question de l utilisation d un Uml state machine particulier décrivant la dynamique des états d une instance de composant. D un point de vue diagramme, les composants peuvent apparaître sur les deux types de diagrammes d implémentation : le diagramme de composants et le diagramme de déploiement. Le diagramme de 22 Dans cette section, nous utilisons la police Sans Serif pour mettre en relief les concepts d Uml 53

66 Chapitre 3. Uml et les composants Classifier Class isactive : Boolean Interface Node +deploymentlocation * * +deployedcomponent Component +implementationlocation * * +container ElementResidence visibility : visibilitykind +implementation * Artifact DataType +resident * ModelElement name : Name Primitive Enumeration ProgrammingLanguageDataType expression : TypeExpression 1 +enumeration +literal EnumerationLiteral 1..* {ordered} Fig. 3.2 Partie d Uml 1.x modélisant le concept de composant [OMG03f, p. 2-16] composants décrit la structure du composant, en montrant les classifiers qui spécifient un composant et les éléments qui l implémentent. Il peut montrer les interfaces du composant qui correspondent à la notion d interface Uml. Une interface est un ensemble nommé d opérations. Les interfaces exposées par le composant représentent les services offerts par les éléments résidant dans le composant. Le diagramme de déploiement décrit la structure des nœuds sur lesquels le composant est déployé, et leurs relations. Pour résumer, les concepts Uml (et les métaclasses correspondantes) qui jouent un rôle dans la modélisation des composants sont (voir Figure 3.2 et Figure 3.3) : 54 Component - modélise le composant, c est-à-dire une partie du système ; Node - une ressource d exécution sur laquelle le composant peut être déployé ; Artifact - une pièce physique d information (fichier, etc.) qui peut représenter l implémentation d un composant ; (ensemble de) Classifier - typiquement utilisé pour spécifier un composant ; Component instance - instance d un composant, qui peut avoir un état ; Node instance - instance de nœud ; Instance - instance de classifier ; Interface - ensemble nommé d opérations, modélisant les service offerts par un composant. La notion de composition est définie comme un cas particulier d agrégation (voir l attribut aggregation

67 3.3. Uml 2.0 ModelElement (from Core) Classifier (from Core) 1..* +classifier * Instance +ownedinstance 0..* +resident owner ComponentInstance resident * 0..1 NodeInstance Fig. 3.3 Partie d Uml 1.x modélisant le concept d instance de composant [OMG03f, p. 2-96] dans la Figure 3.4 [OMG03f] dont la valeur détermine si l association est une agrégation, ou une composition, ou aucun des deux). Peu de pages traitent de la définition des composants dans Uml 1.x. Elles s intéressent plus aux composants physiques. Même dans ce contexte particulier, les adeptes de la communauté Corba / J2ee /.Net qui ont tenté d utiliser les composants dans le cadre d Uml 1.x ont eu un mauvais retour sur expérience ([Sin03] par exemple). Une des raisons évoquées est l incapacité d Uml à exprimer correctement la nature des agrégations des composants. L utilisation d Uml 1.x pour la Cbse impose la plupart du temps l utilisation des mécanismes d extension d Uml pour cela, notamment les stéréotypes et le langage Ocl. Enfin, et c est une de ses limitations les plus gênantes, Uml 1.x considère les composants très tard dans le cycle de vie (principalement en terme de diagramme d implémentation). AssociationEnd isnavigable : Boolean ordering : OrderingKind aggregation : AggregationKind targetscope : ScopeKind multiplicity : Multiplicity changeability : ChangeableKind visibility : VisibilityKind Fig. 3.4 La composition en Uml 1.x au niveau métamodèle 3.3 Uml 2.0 La réutilisabilité et la possibilité de décrire une représentation de l architecture ont été les concepts clés qui ont guidé la définition de la nouvelle version d Uml. Le modèle de composant a été amélioré, un concept complet de composition a été introduit, notamment au niveau diagramme de classe. Nous 55

68 Chapitre 3. Uml et les composants allons, d abord, introduire les nouveaux concepts, puis discuter de leurs avantages et inconvénients. Les diagrammes Uml que nous donnons en exemple dans tout le document ont été définis manuellement. En effet, la notation n a été adoptée que très récemment et, au jour d aujourd hui, aucun outil de modélisation graphique ne l intègre. Les diagrammes Uml 2.0 que nous fournissons dans ce document ont été définis manuellement. Nous avons utilisé un support graphique L A TEX compatible avec la notation Uml 2.0 [BO04], basé sur le support graphique existant pour Uml, pst-uml. La plupart des diagrammes de ce document ont été écrits en utilisant ce package Aperçu des améliorations Uml 2.0 fournit un support pour la décomposition à travers la nouvelle version de structured classifier. Un structured classifier est une entité dont l intérieur peut être décomposé (class, collaboration et component). Des nouveaux concepts supportant la décomposition ont été introduits : part, connector et port. Ils supportent la spécification physique des composants comme dans Uml 1.x, mais également la spécification de composants logiques (comme les composants «business» ou les composants «process») et les composants déployés (comme les artefacts et les nœuds). Un composant est vu comme une «self contained unit that encapsulates state + behavior of a set of classifiers». Il peut avoir sa propre spécification de son comportement et spécifier des contrats sur ses services fournis/requis, à travers la définition des ports. Il s agit alors d une unité substituable qui peut être remplacée tant que la définition des ports ne change pas. Notons que la notion de changement n est pas définie sémantiquement et doit être envisagée à un niveau syntaxique. component Car component e: Engine powers component drive: Axle component w: Wheel Fig. 3.5 Exemple de composite structure Nouveaux concepts Trois nouveaux concepts font partie du modèle de composants. Notons que ces concepts peuvent être utilisés avec n importe quel diagramme composite. Ces concepts sont : 56 Part : une entité interne à une structure composite. Notons que, comme illustré par la Figure 3.5, les instance de classes et les parts ont des notations similaires. Les parts doivent être vues comme des rôles, et leurs instances comme des réalisations qui satisfont ces rôles. Connector : ils expriment les relations entre Part. C est un lien (une instance d une association) qui permet la communication entre deux ou plusieurs instances. Cela peut être réalisé par un pointeur ou une connexion réseau par exemple.

69 3.3. Uml 2.0 Port : le point de connexion par lequel les messages sont envoyés/reçus par une classe (ou un composant). Les ports ont un type qui est donné par un ensemble d interfaces (requises ou fournies) et peuvent être décrits par un automate à états. Uml 2.0 a introduit un type spécifique d automate à états (qui décrit les protocoles d usage des parties du système) : protocol state machines, et a renommé le type précédent (servant maintenant à décrire le comportement de certaines entités) : behavioral state machines. EstablishCall component Phone NetworkServices Fig. 3.6 Notation pour un composant avec ses interfaces La notion d interface n a elle pas changé. Elle représente une signature donnée en terme d un ensemble de concepts publiques (opérations, attributs, événements). Cependant, son utilisation a été étendue, un classifier devant implémenter ou nécessiter une interface (provided / required interface). La notation graphique représentant un classifier avec une interface a évolué afin de prendre en compte cette évolution. Dans la Figure 3.6, nous avons un composant avec un service requis (NetworkServices) et service fourni (EstablishCall). Les interfaces peuvent être attachées à des ports. Une required interface, attachée à un port, caractérise les éléments comportementaux dont le classifier, attaché au port, a besoin. L environnement extérieur devra les fournir via le port. À l inverse, une provided interface caractérise les éléments comportementaux offerts par le classifier. Notons la différence entre un port et une interface : une interface spécifie un service offert/requis par un classifier alors qu un port spécifie un service offert/requis par le classifier via un point particulier d interaction (le port). Il est possible d attacher à un port ou à une interface, un protocol state machine. Celui-ci définit une vue externe plus précise via la spécification de contraintes dynamiques explicites sur la séquence d exécution des appels d opérations et des échanges d événements. Un protocol state machine peut être également utilisé pour définir la vue externe d un composant. À ce sujet la documentation ([OMG03d], p. 138) dit que : «Optionally, a behavior such as a protocol state machine may be attached to an interface, port and to the component itself, to define the external view more precisely by making dynamic constraints in the sequence of operation calls explicit». Notons toutefois que le protocol state machine semble plutôt dédié à être attaché à des interfaces et ou à des ports. Le protocol state machine d un port doit être «compatible» avec le protocol state machine de toutes les interfaces qui lui sont attachées. Cependant, la spécification d Uml ne décrit pas précisément ce qu est la «compatibilité» dans ce contexte Diagrammes de composants Dans Uml 1.x, les diagrammes de composants supportaient principalement le concept de composant d un point de vue implémentation. Dans Uml 2.0, les diagrammes intègrent non seulement les composants d un point de vue conceptuel, mais supportent également la Cbse de telle façon qu il est maintenant possible de suivre la conception, depuis les composants conceptuels jusqu à l implémentation des composants. 57

70 Chapitre 3. Uml et les composants Il y a deux vues possibles pour modéliser les composants : une vue externe, correspondant à l approche boîte noire usuelle, dans laquelle l attention est portée sur les contrats liant le composant à ses clients en termes de services fournis et requis ; une vue interne, cachée pour les clients, correspondant à la vue boîte blanche usuelle. Dans ce cas, l attention est portée sur la manière dont le composant est organisé en termes de parts, subcomponents, connectors, etc. component C1 component C2 Fig. 3.7 Notations possibles pour un composant Notons que la notation pour un component a évolué (voir Figure 3.7). L introduction de «component», et l usage optionnel du logo, ont remplacé la component box de Uml 1.x. component CoffeeMachine component Coiner component DrinkMaker Fig. 3.8 Utilisation des delegation connectors 58 Il y a deux types de connecteurs spécifiques pour les composants : un assembly connector est le lien entre une interface requise, et une fournie. C est une façon de lier les composants entre eux. Dans la Figure 3.8, un assembly connector est utilisé entre les souscomposants DrinkMaker et Coiner ; un delegation connector représente une idée similaire mais d un point de vue interne : une flèche indique la direction de la délégation. Dans la Figure 3.8, un delegation connector est modélisé entre le port relié à l interface de services fournis de CoffeeMachine et les interfaces de services fournis des composants DrinkMaker et Coiner.

71 3.3. Uml 2.0 Class (from StructuredClasses) Interface (from Interfaces) +/provided * +/required * Component isindirectlyinstantiated : Boolean {subsets source, subsets owner, subsets client} +abstraction realization {subsets ownedelement, subsets clientdependency} * Realization +realizingclassifier {subsets supplier, subsets target} 1 Classifier (from Kernel) Fig. 3.9 Définition de la métaclasse Component dans le métamodèle Uml 2.0 [OMG03d, p. 151] Support pour la composition Connector kind : ConnectorKind * +contract * Behavior from BasicBehavior enumeration ConnectorKind assembly delegation Fig Lien entre composants [OMG03d, p. 151] De nouveaux concepts ont été introduits dans Uml 2.0 avec un impact sur le support pour la composition. Les BasicComponents sont des sous-types de Class et sont utilisés dans les compositions. Les PackagingComponents sont une extension de BasicComponents pour définir les aspects groupés d un PackagingComponents. Un BasicComponent à l intérieur d un PackagingComponent est appelé un Nested- Component, que nous francisons sous l appellation de «composant imbriqué». Concrètement, l élément pouvant être imbriqué dans un composite peut être n importe quel type de classifier. Dans la pratique, il s agit souvent de classes. Par ailleurs, le mécanisme de délégation sousentend que cette imbrication est en fait une implémentation : «A delegation connector is a declaration that behavior that is available on a component instance is not actually realized by that component itself, but by another instance that has «compatible capabilities» [OMG03d, p.160]. Cela revient à dire que le composant est implémenté par le composite. Nous sommes donc dans un cas d inclusion topologique. Dans le langage Open [FHSG98], il existe la notion de Containment Relationships. Elle traduit des relations d inclusion et non de composition. Dans le cas de composants, le sens associé à cette inclusion n est pas décrit par la documentation d Uml 2.0. La documentation précise bien que la délégation 59

72 Chapitre 3. Uml et les composants Classifier (from Kernel) Class (from Kernel) BehavioredClassifier (from BasicBehaviors) StructuredClassifier (from InternalStructures) Class (from Communications) EncapsuledClassifier (from Ports) Class (from StructuredClasses) Component (from BasicComponents) Fig Réalisation de la métaclasse Component dans le métamodèle Uml 2.0 permet de modéliser la décomposition hiérarchique du comportement, dans laquelle les services fournis par un composant peuvent être réalisés par un autre, encapsulé à plusieurs niveau d imbrication. Mais elle n apporte pas plus d information sur des points tels que le partage entre composants à l intérieur de composites différents. La relation de composition devrait permettre de répondre à ce genre de questions. C est là un manque persistant dans la nouvelle version d Uml. En fait, malgré les ajouts et les modifications des notations pour les composants, le principal changement, ou plutôt celui ayant le plus d impact sur les recherches actuelles (comme la nôtre [BHSPLB03]) est l introduction de l élément CompositeStructures, et, à moindre niveau, la nouvelle distinction de la notion d interface requise. Les composants communiquent par messages, à travers leurs ports. Ils peuvent également communiquer directement en point à point, utilisant alors le même principe que certains modèles de composants Nouveau métamodèle La superstructure Uml 2.0 [OMG03d] propose un paquetage Components qui définit les liens entre les éléments décrits dans les précédentes sous-sections. L idée générale est de spécifier un composant comme un «modular unit with well-defined interfaces that is replaceable within its environment». Le paquetage Components supporte la spécification des composants conceptuels et physiques, à l aide des artefacts qui les implémentent. Elle supporte également la spécification des nœuds sur lesquels les instances de composants sont déployés et exécutés. Le paquetage BasicComponent définit un composant comme une classe spécialisée ayant une spécification externe (provided et required interfaces), et une implémentation interne (classifier qui réalise son comportement). Les liens entre les composants sont basés sur la compatibilité des interfaces. Le paquetage PackagingComponent définit un composant comme un groupe d éléments qui représente une partie du processus de développement. La Figure 3.9 représente la réalisation de la métaclasse Component dans le métamodèle Uml 2.0. dans le paquetage BasicComponent. 60 Nous ne détaillons pas tous les éléments du métamodèle. Nous mentionnons juste comme illustration

73 3.4. La composition conceptuelle en Uml 2.0 des autres éléments de définition, la manière dont le lien entre les composants est modélisé (voir Figure 3.10). Classifier (from Kernel) NamedElement (from Kernel) StructuredClassifier {union, subsets, member} +/role * * 0..1 {subsets classifier} {subsets role, subsets attribute, subsets ownedmember} +ownedattribute +/part * ConnectableElement Property 0..1 * {subsets feature, subsets ownedmember} ownedconnector * {subsets redefinitioncontext} * Connector * +redefinedconnector {subsets redefinedelement} Fig Le métamodèle Structured Classifier [OMG03d, p. 126] La Figure 3.11 représente les dépendances de la métaclasse Component dans l ensemble du métamodèle Uml. La métaclasse Component hérite de la métaclasse Structured Classifier (voir Figure 3.12). Pour le reste des éléments de définitions cités, voir la proposition complète Uml 2.0 [OMG03d]. 3.4 La composition conceptuelle en Uml 2.0 Dans cette section, nous discutons de la manière dont Uml 2.0 traite la notion de composition. Nous nous appuyons pour cela sur l étude de cas de la machine à café, présentée en section Nous nous intéressons en particulier au composant CoffeeMachine. Il est composé des sous-composants Coiner (voir Figure 2.3 page 34) et DrinkMaker (voir Figure 2.4 page 35). Les exemples d utilisation d Uml 2.0 sont assez rares à ce jour. Cela est dû d une part au manque d outils intégrant les nouveaux concepts du langage et, d autre part, au fait que le langage lui-même n est pas encore officiellement finalisé (il est, au moment où nous rédigeons ces lignes, en phase d évaluation). Dans la suite de cette section, nous discutons des limites de la conception conceptuelle en Uml 2.0 (section 3.4.1) puis nous proposons quelques solutions pour y pallier (section 3.4.2) Limites de la composition conceptuelle en Uml 2.0 Certains liens entre les composants de l étude de cas ne sont pas des simples associations, mais des liens de composition. En Uml 1.x, il existait deux types de lien de composition : la composition et l aggregation. Ces relations, comme décrites dans la documentation, sont inconsistantes [HSB99a]. Malheureusement le métamodèle d Uml 2.0 n a pas évolué sur ce point, malgré des propositions rectificatives [BHSPLB03]. Cependant, grâce au concept de CompositeStructure, il est possible de décrire des mécanismes de délégation. Par exemple, l appel d une des méthodes de l interface de services fournis de CoffeeMachine est transféré à l interface de services fournis d un de ses sous-composants (voir Figure 3.13). 61

74 Chapitre 3. Uml et les composants interface CoffeeMachine_ProvInt_2 setdrink() canceldrink() cancelcoin() getkindofdrink() setcoin() getsum() CoffeeMachine component Coiner interface CoffeeMachine_ReqInt setdrink() getdrink() givechange() component DrinkMaker interface CoffeeMachine_ProvInt_1 initnbofprepareddrink() getnbofprepareddrink() inittotalsum() gettotalsum() getdate() interface CoffeeMachine_ConfInt_1 addtolistofdrink() interface CoffeeMachine_ConfInt_2 setdate() Fig Vue boîte blanche de CoffeeMachine Lors de la conception de l étude de cas, nous nous sommes focalisés sur l aspect composabilité des composants. Comme illustré par les Figure 3.15 et 3.14, le comportement du composant est difficile à exprimer sans intégrer les opérations requises (par exemple, senddrinkok() dans l état SayingOk). Par définition, il y a une forte dépendance entre un composant et le composant lui rendant des services. Malheureusement, il n y a pas de formalisme spécifique pour cette dépendance. En Uml, cela pourrait être illustré par un diagramme de collaboration. Cependant, ce diagramme concerne les instances d objet et non les composants ou les interfaces. Comme illustré dans [BRB04], cela a des conséquences importantes sur la vérification de la composition. Les concepts qui servaient à la composition dans les précédentes versions d Uml sont toujours présents. Cela a pour conséquence de laisser au concepteur le choix du concept à utiliser (lien de composition, d agrégation, ou composite structure par exemple). La question de la cohérence de ces doubles mécanismes est alors posée. Les mécanismes de délégation offrent un plus considérable mais manquent encore de précision. En effet, il n est pas précisé, dans la spécification, la sémantique à associer à ces mécanismes. Par exemple, on peut se demander si l ensemble des opérations de l interface est délégué, ou si la délégation ne se limite qu à une opération particulière. Ces imprécisions illustrent encore le manque de sémantique associé à Uml 2.0 et militent pour une précision de celle-ci Nos solutions Nous présentons ici quelques solutions aux limites soulevées précédemment. Nos solutions touchent la composition structurelle et la composition comportementale. 62

75 3.4. La composition conceptuelle en Uml Composition structurelle Nous faisons la distinction entre les services fonctionnels et non fonctionnels, comme discuté dans la section Nous ne considérons ici que le cas des services fonctionnels. Nous avons fait une distinction entre les services qui sont délégués aux sous-composants (nous utilisons alors un port : CoffeeMachine_ProvInt_2 et un delegation connector, matérialisé par une flèche foncé à l intérieur du composite dans la Figure 3.13) et ceux qui sont traités directement par le composant (CoffeeMachine_ProvInt_1). Pour ces derniers, l utilisation d un port n est pas utile. Nous utilisons la même distinction entre les interfaces de configuration (les flèches claires dans le composite). Cette distinction n est pas nécessaire dans une vue boîte blanche d un composant, mais est cohérente avec une structure composite. Pour être plus précis, nous pouvons séparer les différentes propriétés de CoffeeMachine en trois catégories : propriétés complètement indépendantes de la composition (e.g., la couleur de la machine) ; propriétés issues de la composition, mais indépendamment de ses sous-composants.il ne s agit pas d une fonctionnalité fournie par un sous-composant particulier (e.g., Nombre de boissons délivrées) ; propriétés directement issues d un des sous-composant (e.g., le montant total d argent dans la machine). Ces trois catégories sont respectivement appelées propriétés propres, émergentes, and résultantes [BHSPLB03, Kil99]. Nous en parlons plus en détail dans le chapitre 4. Coiner getsum() MoneyChecking cancelcoin/givechange setcoin(coin)/sum=sum+coin settargetprice(p)[p>0]/sum=0 Ready WaitingForMoney when(sum = p) when(sum > p) MoneyIsEnough do / givechange TooMuchMoney do / sendcoinok Fig Behavioral state machine du composant Coiner La Figure 3.14 décrit le comportement externe de Coiner et la Figure 3.15 le comportement de Drink- Maker, à travers un behavioral state machine. Uml 2.0 n offre pas de moyen, ni de méthode, pour représenter le comportement de CoffeeMachine vis-à-vis du comportement de ses sous-composants sans modification des machines à états de ses souscomposants. En fait la représentation du comportement du composé inclut des parties des machines à états de ses composés, mais implicitement Composition comportementale Pazzi [Paz00, Paz02] a défini un langage de composition appelé Part-Whole Statecharts (Pws)). Ce langage, permet une composition explicite hiérarchique des Statecharts. Son intérêt est notamment de 63

76 Chapitre 3. Uml et les composants getkindofdrink(setofdrink) Ready setdrink(d) canceldrink() DrinkSelected SayingOk do / sendfinish() preparedrink(d) GivingDrink do / givingdrink() PreparingDrink do / timer(10s) Fig Behavioral state machine du composant DrinkMaker ne pas modifier les machines à états des sous-composants lorsqu ils forment une nouvelle composition. Cela apporte des avantages en terme de réutilisabilité, de maintenabilité, et de compréhensibilité de l abstraction logicielle. Le principe est le suivant : la modélisation par machine à états induit des dépendances entre composants, notamment au niveau des événements. L idée est de transformer ces dépendances par une relation «verticale». Le problème de cette approche, est qu elle définit un nouveau formalisme et ne s intègre pas facilement dans Uml. Malgré cet inconvénient, elle représente un concept très intéressant pour la composition verticale. Le bénéfice de cette approche est de décrire la communication entre les Statecharts au niveau du Statechart du composé uniquement. Le comportement du composé est alors explicite et les comportements des sous-composants inchangés. La comportement du composé CoffeeMachine est décrit en utilisant l approche de Pazzi, par la Figure Il a été créé en identifiant les événements communs. Les opérations sur les transitions implémentées par les sous-composants sont entre < et > (<CancelCoin> par exemple). Les autres opérations sont des opérations du composé. L opération soulignée est source de la transition. Les opérations non soulignées sur la transition sont les conséquences de la transition. Par exemple, dans la transition de l état ReadyToPrepare à l état Ready, l opération Cancel est la source de la transition. Elle est implémentée par le composé. Les opérations <CancelCoin> et <Canceldrink> sont implémentées par les sous-composants et sont les conséquences de la transition. 3.5 Apport d Uml 2.0 par rapport à Uml 1.x Le support offert par la version 2.0 pour la modélisation des applications à base de composants est meilleur que dans les versions précédentes d Uml. Uml 2.0 fournit des éléments de modélisation qui étaient manquants dans Uml 1.x. Ils permettent de modéliser à la fois la composition au niveau conceptuelle et au niveau logiciel. C est un apport indiscutable vis-à-vis des versions 1.x. Cependant, comme illustré par notre exemple, la spécification du métamodèle manque toujours de définitions claires et précises. De nombreuses ambiguïtés se trouvent toujours dans la spécification officielle, aussi bien à propos des nouveaux concepts que des anciens. Le choix des notations à utiliser pour modéliser certains concepts est parfois flou. 64

77 3.6. Problématique de notre thèse Cancel<CancelDrink CancelCoin> Global State of CoffeeMachine Preparation <SendCoinOK> NoDrinkSelected <SetDrink(drink)> Ready ReadyToPrepare <SetDrink(drink)> NoMoneyGiven <SendCoinOK> startdrinkprep <PrepareDrink(drink)> GetDrink <GinvingDrink> GinvingDrink SendDrinkOk <SendFinish> PreparingDrink Fig Behavioral state machine du composant CoffeeMachine Du point de vue du traitement de la composition, les concepts initiaux, que sont l agrégation et la composition, sont toujours incohérents. Uml 2.0 a apporté un support supplémentaire avec les structures composites. Cependant, la sémantique sur l utilisation de ces structures composites n est pas précise. De plus, nous avons montré que la relation sous-jacente à ce concept est plus une relation de containment que de composition. La différenciation entre les anciens et les nouveaux concepts n est pas claire et est laissée au choix du concepteur, ce qui rend difficiles les choix de modélisation. 3.6 Problématique de notre thèse Aujourd hui, le Cbd est soutenu par des techniques stables et reconnues telles que les modèles de composants. Le chapitre 1 a montré que la communauté avait obtenu un relatif consensus sur les définitions des concepts clés inhérentes au Cbd. Elle s est attachée à fournir des moyens pour réaliser des composants et des applications à base de composants. Le challenge actuel dans le domaine de la Cbse est de fourbir les techniques, méthodes et outils pour faire passer le Cbd d une approche artisanale à une réelle approche industrielle. En effet, malgré le support pour le développement d applications à base de composants, la réutilisation des composants n est encore que peu effective hors d un contexte particulier (environnement spécialisé par exemple). Une des raisons à cela est que la composition des composants n est généralement envisagée qu au niveau des phases d assemblage et de déploiement. Pour résoudre ce problème, la composabilité, et plus généralement la composition, doivent être spécifiquement pris en compte lors des phases d analyse et de conception. C est ce que nous appelons la composition conceptuelle. Dans le chapitre 2, nous avons fourni un aperçu des techniques permettant de mettre en œuvre la composition à deux niveaux distincts : au niveau conception détaillée, assemblage et déploiement (bas niveau) et au niveau analyse et conception préliminaire (haut niveau). Le constat que nous dressons est que les techniques bas niveaux sont relativement matures et répondent assez bien au besoin de la 65

78 Chapitre 3. Uml et les composants composition logicielle. Par contre, les techniques haut niveaux sont encore immatures et manquent de support pour la composition conceptuelle. Parmi les approches conceptuelles étudiées, les méthodes formelles apportent une solution élégante. Leur base mathématique permet une description précise de la composition. Cependant, elles peinent à s imposer en industrie, à cause notamment de leur manque d expressivité graphique. Dans ce cadre, plusieurs approches récentes proposent de coupler une méthode formelle avec une approche semi-formelle offrant un moyen d expression graphique. Nous proposons la démarche différente. Plutôt que de redéfinir la sémantique des approches semi-formelles via une méthode formelle, nous proposons d améliorer la sémantique des approches semi-formelles, en s appuyant sur les outils sémantiques qu elles apportent. Dans ce cadre, nous nous intéressons au cas du langage Uml. D ailleurs, l atelier WCOP03 [BSW03] abonde en ce sens dans ses conclusions : «It is an advantage if component specification could be based on standardized specifications approaches such as [...] Uml 2.0. [...] Uml 2.0 is viewed as a good basis, but further standardization is needed here». Dans le chapitre 3, nous avons étudié la manière dont Uml permettait l expression de la composition. Nous avons vu que l évolution récente du standard avait été bénéfique à la modélisation basée composants. En outre, son côté généraliste (sans lien avec une technologie particulière) va dans le sens de l approche MDApréconisée par l Omg (et donc pour les industriels). Cela permet une structuration des applications basée composants indépendante de tout modèle technologique. Cependant, nous avons montré que malgré cette évolution, la sémantique d Uml restait floue et sans base formelle, en particulier sur le cas de la composition. Dans ce cadre, notre objectif a été d améliorer la définition de la relation de composition. Nous avons montré que la composition conceptuelle devra s appuyer sur des concepts existants et reconnus, tels que l utilisation de contrats, la spécification des propriétés non fonctionnelles et fonctionnelles des applications, ou encore le traitement des compositions des comportements. Toujours en accord avec l approche MDA, nous ne nous attachons pas spécifiquement à une méthode de mise en œuvre particulière des modèles. Cependant, nous défendons l idée que les propriétés spécifiées lors de la conception doivent se retrouver au niveau assemblage et déploiement. Cela peut se faire à l aide d un modèle de composants modifié pour prendre en compte ces propriétés spécifiques de composition. De plus, il est nécessaire de permettre la vérification du respect des propriétés spécifiées par le modèle. Pour cela, des outils de vérification appropriés doivent être fournis. Ces besoins illustrent la nécessité de définir un cadre de composition cohérent pour la spécification, l implémentation et la vérification. 66

79 Deuxième partie Modèle de composition, une proposition basée sur la théorie de la relation Tout-Partie 67

80

81 Chapitre 4 Une approche pour la composition logicielle basée sur la relation Tout-Partie Sommaire 4.1 Étude de l application de la relation Tout-Partie à la composition logicielle Démarche, fondations et hypothèses de notre proposition Études des propriétés de la relation Tout-Partie pour la composition logicielle Classification des propriétés retenus selon les dimensions architecturale et dynamique Relations entre les propriétés de composition retenues Identification de différents types de relations Tout-Partie Résumé de l étude Définition d un métamodèle Uml pour la Cbse basé sur la relation Tout-Partie Discussion sur les choix de métamodélisation Proposition de métamodèle Contraintes Ocl Résumé de l application à Uml du modèle de composition Conclusion Dans la partie I, nous avons défini la terminologie que nous utilisons. Nous avons ensuite présenté un état de l art, d une part sur les compositions logicielles et conceptuelles et, d autre part, sur la manière dont Uml modélisait la composition. Nous avons terminé en posant la problématique de notre travail de thèse : améliorer la formalisation de la composition verticale dans le cadre de la modélisation basée Uml. Nous traitons de la composition verticale (présentée en section ). Il s agit d une approche hiérarchique de la conception. La conception hiérarchique est bien connue et a été largement utilisée dans les approches objets. La méthode de conception Hood [Gro91] a même été spécifiquement définie sur ce concept. Dans le monde composant, cette approche n est pas nouvelle [BO92]. D un point de vue réalisation, nous avons montré que plusieurs modèles de composants la prenaient en compte. Cette partie présente le modèle basé sur Uml et Ocl sur lequel nous nous appuyons pour donner une assise à la relation de composition au niveau conceptuel. Celui-ci s appuie sur une théorie mathématique 69

82 Chapitre 4. Une approche pour la composition logicielle basée sur la relation Tout-Partie connue et largement étudiée : la relation Tout-Partie. L utilisation de cette base théorique a déjà été utilisée avec succès en modélisation orientée objet, pour améliorer la définition des relations d agrégation et de composition en Uml 1.x [BLB02, BHSPLB03]. Nous nous servons de ces résultats comme point de départ de notre travail. Ces travaux ont abouti à l identification des propriétés caractérisant une relation Tout-Partie. Ces propriétés permettent de spécifier formellement la signification de cette relation. Notre approche a consisté à étudier l applicabilité de ces travaux à la modélisation des compositions verticales de composants. Pour ce faire, nous avons étudié les résultats apportés par les deux articles cités précédemment. Nous avons discuté des propriétés dans le cadre de notre approche. Nous avons retenu, et modifié le cas échéant, celles que nous avons jugées opportunes dans notre cadre. Nous avons intégré le résultat de cette étude à Uml. Pour cela, nous avons proposé une modification du métamodèle Uml à travers la définition d une relation de composition spécifique. Nous avons amélioré la syntaxe de cette relation en utilisant le langage Ocl pour renforcer la sémantique des propriétés de composition. Rappelons que nous considérons le terme «sémantique» dans le cadre d Uml : la sémantique y est définie par un métamodèle et des contraintes Ocl. Ce terme est utilisé dans ce document différemment du contexte dans lequel les théoriciens l utilisent, en accord avec la remarque de [HR04] : «Semantics is not merely a term that theoricians use to prove theorems». Ce chapitre s organise de la manière suivante. En premier lieu, nous décrivons l étude menée afin de proposer une assise formelle à la relation de composition au niveau conceptuel (section 4.1). Puis, nous présentons notre proposition pour intégrer les résultats de cette étude au langage Uml (section 4.2). Enfin, nous concluons sur cette proposition (section 4.3). 4.1 Étude de l application de la relation Tout-Partie à la composition logicielle Dans cette section, nous décrivons notre réflexion concernant l adaptation de la relation Tout-Partie à la composition logicielle. Pour cela, cette section est organisée comme suit. En section 4.1.1, nous décrivons les hypothèses de notre proposition. Nous décrivons notre démarche puis présentons la relation Tout-Partie. Puis, nous décrivons la manière dont nous l appliquons à la composition logicielle. Enfin, nous résumons la démarche initiale utilisant la la relation Tout-Partie pour la modélisation objet. À la section 4.1.2, nous présentons notre étude systématique des propriétés de composition. Nous les classons selon leur domaine d application à la section Nous détaillons ensuite, les interactions entre les propriétés (= à la section 4.1.4). Nous identifions enfin différents types de relations Tout-Partie à partir de leurs propriétés de composition à la section Enfin, nous concluons par un bilan de cette étude à la section Démarche, fondations et hypothèses de notre proposition Le dictionnaire Larousse définit le verbe composer de la manière suivante :«Former un tout en assemblant des parties» [Lar99]. On voit intuitivement que les deux éléments réalisant la composition ne sont pas d un même niveau hiérarchique, le «tout» de cette définition est d un niveau supérieur à ses «parties». Ce concept n est pas nouveau. La méréologie est une théorie mathématique, issue des travaux de Lesnievski (1916) dont une partie est présentée dans [Les89]. Il s agit de la théorie des relations Tout-Partie et des relations de Parties à Parties dans un Tout. Ces travaux sont une reformulation de la théorie ensembliste. Ils ont permis de doter la méréologie d une formulation exacte de manière à définir 70

83 4.1. Étude de l application de la relation Tout-Partie à la composition logicielle les principes généraux des relations existant entre une entité et ses composants et ce, quelle que soit la nature de l entité. Nous considérons que ce concept de Tout-Partie présente un certain nombre d aspects utiles à la formalisation de la composition verticale, présentée dans la section page Démarche Notre démarche a été la suivante. Nous sommes partis de travaux, menés par notre équipe et dont les résultats ont été reconnus [BLB02, BHSPLB03], utilisant la relation Tout-Partie comme base théorique pour l amélioration de la définition des relations d agrégation et de composition dans le cadre de la conception orientée objet 23, en Uml 1.x. Leurs auteurs ont effectué une étude importante des travaux portant sur la relation Tout-Partie à partir de laquelle a été identifié un ensemble de propriétés ayant un impact sur cette relation. Ces propriétés caractérisent donc les relations Tout-Partie. Nous avons effectué une revue systématique des propriétés identifiées. Pour chacune d elles, nous avons étudié son applicabilité et sa pertinence dans le monde orienté composant. Après avoir envisagé les propriétés une à une, nous en avons étudié les interactions. Notre étude, que ce soit pour l évaluation systématique des propriétés, ou pour la comparaison de leurs interactions, repose sur une expérimentation par implémentation de notre métamodèle après une série d études expérimentales au moyen de l outillage que nous présentons en partie III. Nous justifions cette approche à la section Exemples de relations Tout-Partie : mise en relief de la variété sémantique La relation Tout-Partie présente des variations sémantiques caractérisées par des propriétés clairement identifiées. Les exemples suivants en sont l illustration. Considérons les relations 24 suivantes, toutes étant des relations de compositions verticales : Calculateur - Centrale de mesure, CoffeeMachine - DrinkMaker, CoffeeMachine - Coiner, E-Money - Coiner, Four - Horloge, Pilote automatique - Barre, et Dictionnaire de mots - Gestionnaire de BD. Prenons la relation Calculateur - Centrale de mesure. Dans un avion moderne, les calculateurs sont souvent doublés voir triplés. La centrale de mesure effectuant les mesures est partagée par tous les calculateurs. Dans le cadre de la relation CoffeeMachine - DrinkMaker, le composant gérant la fabrication de boisson ne peut pas être partagé entre plusieurs machines à café. Dans ces deux relations, le nombre d instances du composant Tout, partageant le composant Partie, n est pas le même : dans un cas, il ne peut y avoir de partage ; dans l autre si. Dans les exemples précédents, le partage était envisagé par des composants de même type. On trouve un partage à la signification différente dans l exemple de la machine à café. En effet, si l on considère les relations CoffeeMachine - Coiner et E-Money - Coiner, le composant Coiner, sur une même machine, peut-être partagé entre le système de porte-monnaie électronique et la machine à café, c est-à-dire entre deux instances de types différents. Considérons le cas de la relation Dictionnaire de mots - Gestionnaire de BD. Le composant Dictionnaire de mots permet l interrogation dynamique de bases de données. Il accède à une base de données et récupère le résultat de requêtes qu il transforme en tableaux textuels. Il utilise pour cela 23 pour mémoire, la différence entre objets et composants est discutée à la section Lorsqu on parle dans ce document d une relation Tout-Partie, elle est nommée en respectant la convention suivante : les deux éléments de la relation sont séparés par un tiret ; le Tout est toujours en premier et le composant Partie en second ; le Tout est toujours en petite majuscule et le composant Partie en minuscule. Cette convention ne s applique pas aux schémas puisqu ils suivent la convention graphique d Uml 71

84 Chapitre 4. Une approche pour la composition logicielle basée sur la relation Tout-Partie un composant Gestionnaire de BD, lui fournissant le schéma de la base de données, et les résultats des requêtes générées. Lorsqu on détruit Dictionnaire de mot, Gestionnaire de BD n est pas détruit (pour ne pas détruire la base de données). Dans le cas de la machine à café, à la destruction du CoffeeMachine, il ne sert à rien de laisser exister le composant DrinkMaker. Dans ces deux relations, la dépendance au niveau du cycle de vie n est pas la même. On le voit, la relation Tout-Partie peut être modulée autour d un ensemble de propriétés apportant une sémantique différente en fonction de leur spécification ou non sur une relation donnée Applicabilité de la relation Tout-Partie à la composition logicielle L utilisation de la relation Tout-Partie, pour donner une assise formelle à la composition, se situe à un niveau spécifique de la théorie de la relation Tout-Partie et plus particulièrement dans la limite imposée par une notion fondamentale du génie logiciel orienté composant : le typage de composant. Nous restreignons, en effet, le cadre applicatif de cette théorie à la seule composition de types de composants et par extension à la composition des instances de ces types de composants. Nous considérons que la notion de type et d instance d objet est comparable à celle de type de composant et d instance de composant discutée dans le chapitre 1. Nous nous situons donc dans le même contexte que celui discuté dans [BHSOG01b]. Dans le cadre de la modélisation d applications basées composants, un type de composant donné, dans un modèle de composants donné, correspond à un ensemble d instances potentielles qui, par définition sont conformes à ce type. Le type de composant joue, soit le rôle d un Tout 25, soit le rôle d une Partie, soit le rôle des deux, en fonction de son implication dans une ou plusieurs relations Tout-Partie. Nous utilisons dans ce document le terme générique de Tout ou de Partie pour parler de «la» relation Tout-Partie en tant que métatype. À partir de ce métatype sont tirées une ou plusieurs relations Tout-Partie qui seront, dans un modèle de conception, ses instances. La Figure représente le concept de Tout-Partie aux différents niveaux architecturaux définis par le Mof (voir section 3.1), en utilisant l étude de cas présentée en section Le niveau 2, ou niveau métadonnées, contient la représentation du concept Tout-Partie en tant que métatype. Au niveau 1 sont représentés des types de composants dans les modèles de conception (CoffeeMachine pour Tout et Coiner pour Partie). Enfin, le niveau 0 représente les instances de composants, ici en Java. Les flèches verticales en pointillés représentent les dépendances entre les différentes entités Tout-Partie et les différents niveaux La relation Tout-Partie dans le cadre de la modélisation OO : une base de travail Les travaux présentés dans [BLB02, BHSPLB03] ont été initiés en 1999 [HSB99b]. Ils proposent l utilisation de la théorie de la relation Tout-Partie pour résoudre l incohérence des notions d agrégation et de composition dans Uml 1.x. Pour cela, les auteurs ont établi une classification des propriétés de la relation Tout-Partie, en terme de propriétés primaires (propriétés que doit respecter obligatoirement une relation pour être qualifiée de Tout-Partie) et secondaires (propriétés qui spécialisent au besoin une relation Tout-Partie), et proposé une modification du métamodèle d Uml 1.x. L intérêt de cette approche est de permettre la définition, notamment grâce à la classification et à la formalisation des 25 D un point de vue vocabulaire, dans la suite de ce document nous utiliserons avec une même signification les expressions «composant Partie», «Partie» ou encore «sous-composant». Il en sera de même pour les expressions «composant Tout», «Tout» ou encore «composé». 26 Nous utilisons comme symbole le losange en pointillé pour représenter une relation Tout-Partie. Ainsi, nous évitons le problème de l incohérence existant entre la notion de composition et celle d agrégation dans Uml, révélée par [HSB99a]. Cette notation est valable pour l ensemble de ce document. 72

85 4.1. Étude de l application de la relation Tout-Partie à la composition logicielle Whole-Part Niveau 2 instance component CoffeeMachine component Coiner Niveau 1 instance instance instance artifact CoffeeMachine.java artifact Coiner.java Niveau 0 Fig. 4.1 Le concept Tout-Partie en fonction des différents niveaux du Mof propriétés, de plusieurs types de relations Tout-Partie : l article se limite aux deux types agrégation et composition présents dans Uml. Le choix est justifié de la manière suivante :«deux sous-types de Tout- Partie semblent assez. L extensibilité s oppose à cette notion de minimalité. Il est néanmoins souhaitable, dans sa version canonique, de limiter Uml dans sa couverture de Tout-Partie». Nous reviendrons sur ce point en section car nous le jugeons améliorable. Le tableau 4.1 représente la liste des propriétés de la relation Tout-Partie, utiles dans le cadre de la modélisation OO, classées en propriétés primaires et secondaires. «La nécessité et la suffisance de cette liste ne peuvent pas être prouvées formellement» [BLB02]. Cependant, la liste a été établie après l étude de nombreux articles, dans des domaines différents, et la prise en compte de nombreuses remarques suites à publications, ce qui autorise à la considérer comme cohérente. Type de propriétés Primaires Secondaires Nom de propriété Nature binaire, propriété émergente, propriété résultante, asymétrie au niveau instance et anti-symétrie au niveau type. Encapsulation, dépendance des cycles de vie (9 cas), transitivité, partageabilité, séparabilité, mutabilité, et configurationalité. Tab. 4.1 Classification des propriétés de la relation Tout-Partie appliquée au monde OO [BHSPLB03, BLB02] Ces propriétés ont été formalisées, lorsque cela était possible, sous la forme de règles Ocl. Nous invitons le lecteur intéressé à consulter l article initial pour avoir le détail de l applicabilité de ces propriétés à la problématique de la modélisation OO. 73

86 Chapitre 4. Une approche pour la composition logicielle basée sur la relation Tout-Partie Études des propriétés de la relation Tout-Partie pour la composition logicielle Nous discutons ici des propriétés identifiées par [BHSPLB03] et de leur utilité et de leur adaptation pour notre approche. Pour cela, nous les étudions une par une. Cette étude nous a amenés à conclure que nous ne retenons pas les propriétés suivantes : la nature binaire de la relation, car elle est évidente dans le cadre de l approche composant ; les propriétés émergente et résultante, car nous les considérons comme des heuristiques de modélisation ; la transitivité, car elle est d une part définie de manière axiomatique dans les travaux de Lesniewski et, d autre part, incompatible au typage ; la configurationalité, car d une part elle induit des relations 3-aires, ce qui est incompatible avec la nature binaire de la relation Tout-Partie, et d autre part elle est mal formalisée dans [BHSPLB03]. Au contraire, l étude a montré l intérêt des propriétés suivantes dans le cadre de la modélisation orientée composant : asymétrie au niveau des instances ; antisymétrie au niveau des types ; encapsulation ; partageabilité ; dépendance de cycles de vie ; séparabilité ; mutabilité Nature binaire de la relation Nous considérons les relations entre sous-composants et composés comme binaires par nature. Nous soutenons qu une relation Tout-Partie n-aire n a pas de sens, dans le cadre de la composition logicielle Propriétés émergentes et résultantes Une propriété émergente est une caractéristique intrinsèque du composé, c est-à-dire que sa valeur est déterminée indépendamment de ses composants. Une propriété résultante est une caractéristique du composé dont la valeur dépend directement de ses composants [Kil99]. component Calculateur component Centrale de mesure Fig. 4.2 Relation de composition entre un calculateur et une centrale de mesure Afin d illustrer les notions de propriétés émergente et résultante, dans un contexte de composant logiciel, envisageons la relation de composition Calculateur - Centrale de mesure, illustrée par la Figure 4.2. Ces deux composants peuvent être utilisés dans de nombreuses applications (automobile, 74

87 4.1. Étude de l application de la relation Tout-Partie à la composition logicielle aviation, informatique embarquée plus généralement). La fréquence de calcul d un calculateur est un exemple de propriété émergente de la relation. Elle est indépendante du sous-composant et n a pas de raison d exister dans le cas où le calculateur n est pas en relation avec son sous-composant (dans ce cas, le calculateur n aurait en effet aucune donnée à calculer). Un calcul, comme par exemple celui de l accélération, est un exemple de propriété résultante de cette relation. Ce dernier est en effet obtenu généralement en effectuant la dérivée de la vitesse mesurée. La donnée vitesse est apportée par le composant centrale de mesure. La dérivée est calculée par le composé calculateur. L expérience a montré qu il était parfois difficile de déterminer une propriété émergente et une propriété résultante pour toute relation de composition. Le tableau 4.2 présente des exemples de relations Tout-Partie et de leurs propriétés émergentes et résultantes. Or, les propriétés émergentes et résultantes ont été classées comme propriétés primaires dans la classification des propriétés dans le monde OO. Cela implique que seules les relations ayant ces propriétés vérifiées, peuvent être traitées par le modèle basé sur la relation Tout-Partie. D un point de vue théorique, cette restriction est logique. D un point de vue pratique, nous sommes réservés sur cette limitation. En effet, l utilisation d une composition verticale est importante d un point de vue conceptuel, notamment à travers l abstraction qu elle apporte. Nous pensons que des relations, qui ne possèdent pas directement une propriété émergente et une propriété résultante, peuvent être modélisées sous la forme d une relation Tout-Partie. Nous considérons que les avantages de cette approche sont suffisants pour considérer ces deux propriétés comme des heuristiques de modélisation. Des relations ne possédant pas de propriété émergente ou résultante peuvent donc être candidates à notre modèle de composition. Relation Tout-Partie Propriété émergente Propriété résulatnte CoffeeMachine - Coiner Somme totale récoltée Calculateur - Centrale de mesure Fréquence de calcul Calcul de l accélération Four - Horloge Démarrage différé Altimètre - Baromètre Plage de mesure Calcul de l altitude Tab. 4.2 Échantillon de propriétés émergentes et résultantes D un point de vue services, les services résultants dépendent à la fois du Tout et des composants Partie. Il n est donc pas aisé de les placer dans une interface particulière. Par exemple, dans l étude de cas de la machine à café, si nous considérons qu ils dépendent d un sous-composant de CoffeeMachine, ils doivent être placés dans l interface CoffeeMachine_ProvInt_2 (celle avec le port et le delegation connector de la Figure 3.13 page 62). Si nous considérons qu ils dépendent du composé, il faut alors les placer dans l interface CoffeeMachine_ProvInt_1. Nous choisissons de placer ces services dans l interface du composé, afin de réserver celles des sous-composants pour les mécanismes de délégation des services complètement dépendants des sous-composants Asymétrie au niveau des instances La relation Tout-Partie, pour les composants, est asymétrique au niveau des instances de composant. L asymétrie signifie irréflexivité (i.e. une instance de composé ne peut pas être composant de lui-même) et l antisymétrie (i.e. une instance de composant ne peut pas être composé du composant qu il compose) [BLB02]. Pour illustrer notre propos, nous discutons d un exemple. Considérons le composant Dictionnaire de mots, présenté à la section Admettons que nous souhaitons modéliser un dictionnaire multi- 75

88 Chapitre 4. Une approche pour la composition logicielle basée sur la relation Tout-Partie * (a) component Dictionnaire de mots component adicomtlg:dictionnaire de mots component adico:dictionnaire de mots component adicounelg:dictionnaire de mots (b) (c) Fig. 4.3 Illustration de la propriété d asymétrie au niveau des instances langues. On peut modéliser le fait que l instance du dictionnaire multi-langues s appuie sur une ou plusieurs instances de dictionnaire. Pour ce faire, nous utilisons la relation Tout-Partie Dictionnaire de mots - Dictionnaire de mots. La Figure 4.3 illustre cet exemple : en (a) est définie une relation de composition au niveau du type de composant Dictionnaire de mots. Un dictionnaire peut être composé de dictionnaires ; en (b), une instance de dictionnaire ne peut être composée d elle même (c est l application de la propriété d asymétrie au niveau des instances) ; en (c), l instance de composant adicomtlg peut être composée d un ou de plusieurs dictionnaires (ici le dictionnaire adicounelg). L asymétrie au niveau des instances a été mise en avant dans le cadre de la modélisation objet. Si nous nous référons à la section , les différences entre un objet et un composant n ont pas d impact direct sur cette propriété. En effet, soient les différences identifiées suivantes : existence d interfaces clairement identifiées, moyens de communication plus importants, persistance, granularité plus importante et capacités à être déployées. Par nature, ces critères n ont pas d impact sur le fait qu une instance de composant puisse être composée d elle-même Antisymétrie au niveau des types Dans [BHSPLB03], l antisymétrie est fixée de la manière suivante. La phase d analyse sert à définir une représentation intelligible des besoins et du fonctionnement de l application, à un niveau abstrait. Cette représentation a pour objectif, notamment d être claire, afin d être comprise par le destinataire du logiciel. Ainsi, ce dernier peut valider l analyse du système. Au niveau de la phase de conception, la relation Tout-Partie est un outil pour construire des modules logiciels ayant une forte cohésion et un faible couplage. Lors de ces deux phases, l objectif de la relation Tout-Partie est de construire des modèles lisibles, donc le plus simplement possible, ce qui doit permettre à terme une implémentation simple. Dans cet objectif, nous avons choisi de promouvoir l anti-symétrie au niveau des types [HSB99b]. Nous sommes en accord avec cette justification et retenons cette propriété. En effet, l importance de la clarté d un modèle au niveau analyse est acquis. D autre part, par nature la Cbse cherche à minimiser le couplage au niveau des éléments d une application. Cet objectif est donc en adéquation avec la justification apportée au niveau modélisation objet. Cela nous permet de retenir cette propriété au niveau composants. 76

89 4.1. Étude de l application de la relation Tout-Partie à la composition logicielle La Figure 4.4 illustre une symétrie au niveau des types. component A component B Fig. 4.4 Exemple de symétrie Encapsulation L encapsulation est une des propriétés clés de notre approche. Comme nous le verrons à la section 4.1.4, elle est fortement liée aux propriétés de partageabilité, de transitivité et de dépendance de cycle de vie. Intuitivement, un composant Partie est encapsulé par un composant Tout si ce dernier est le seul composant du système à accéder au composant Partie. Le composant encapsulé n est alors référencé que par le composant Tout. L encapsulation a un impact sur le composant Partie. Elle implique de : ne pas pouvoir être sous-composant d un autre composant Tout via une autre relation Tout-Partie ; ne pas entretenir de relation, extérieure au Tout, avec un autre composant (nous verrons à la que nous modérons cette interdiction car elle est redondante avec la partageabilité). Cependant, l encapsulation pouvant être récursive, le composant peut avoir une relation de type Tout-Partie avec un autre composant pour lequel il joue lui-même le rôle de composant Tout. La propriété d encapsulation est fondamentale dans le monde composant. En effet, un composant doit être vu le plus souvent suivant une vision boîte noire. Cela permet de ne s intéresser qu à son comportement sans se soucier des éléments qui le composent. Cependant, tout sous-composant ne doit pas forcément être encapsulé strictement au sein de son composé. Cette propriété est d ailleurs liée à la propriété de partageabilité. En effet, dans certain cas, un composant doit être partagé par plusieurs composés. Il est alors encapsulé au niveau type. Dans d autres cas, c est une instance de composant qui doit être partagée. Or si la propriété d encapsulation est sélectionnée, ceci est impossible. Dans ce cas, il est nécessaire d utiliser deux instances de composants, bien que cela puisse avoir comme conséquence de surcharger l application. La Figure 4.5 représente une relation Tout-Partie où un composant Horloge est encapsulé par un composant Four, dans une relation Four - Horloge. Horloge propose l interface de services fournis provhorloge et Four l interface de services fournis provfour. Cette dernière est utilisée par l IHM (Interface Homme Machine) du four. D un point de vue service, l encapsulation implique que les services du composant Partie ne soient accessibles que par le composant Tout. Pour rendre accessible un service du composant Partie à l extérieur du composant Tout, il faut encapsuler ce service à l intérieur d un des services du composé. Dans l exemple de la Figure 4.5, les services de provhorloge ne peuvent être utilisés que par le composant Four. Pour rendre accessible un service de provhorloge par un autre élément du système, il faut encapsuler ce service dans un service de provfour. Ainsi, le principe de l encapsulation est respecté. Cette approche est celle des delegation connector en Uml 2.0 (voir section 3.3, page 55). L implémentation d un service est réalisée par l invocation d une opération (par exemple gettime() est une opération fournie par provhorloge). Si le service fourni par gettime() doit être proposé comme 77

90 Chapitre 4. Une approche pour la composition logicielle basée sur la relation Tout-Partie component Four component Horloge provhorloge provfour IHMFour Fig. 4.5 Encapsulation du composant Horloge par le composant Tout Four service fourni de l interface provfour, alors l appel de cette opération doit être encapsulé lui-même dans le code d une de ses opérations. On peut utiliser pour cela le patron de conception Proxy [GHJV95]. Un exemple de mise en œuvre est donné par la Figure public interface provfour { 2 public void gettime ( ) ( ) ; 3 } 4 public C l a s s Four implements provfour { 5 Horloge _ instofhorloge ; 6 7 void gettime ( ) { 8 _ instofhorloge. gettime ( ) ; 9 }} Fig. 4.6 Exemple Java d encapsulation de service par un composant Tout La définition de l encapsulation telle qu elle est évoquée au début de cette sous-section est satisfaisante dans le cadre d un composé où il n y aurait qu un seul sous-composant. Cependant, dans la pratique, un Tout est souvent composé de plusieurs composants Partie. C est le cas, par exemple, du composé Coffee- Machine (voir Figure 2.2 page 33). Or, si l on s en tient à la définition donnée, si dans un même composé un sous-composant nécessite un service rendu par un autre sous-composant (DrinkMaker nécessitant un service de Coiner par exemple), et que la propriété d encapsulation a été spécifiée pour les deux souscomposants, alors le service ne peut être rendu directement. Cela signifie que le service doit être encapsulé par un service du composé pour être utilisé. D un point de vue pratique, cette encapsulation de service implique une surcharge de l appel du service et une perte de performance. Plusieurs raisons peuvent entraîner la spécification de la propriété d encapsulation ; le composé peut embarquer les éléments dont il a besoin ; d un point de vue sécurité, les services des sous-composants ne doivent pas être accessibles à l extérieur du composé. Ces raisons concernent le composé vis-à-vis de l application complète. Elles ne concernent pas les interactions entre les sous-composants au sein d un même composé. Aussi nous proposons que la contrainte d encapsulation s applique uniquement visà-vis du système extérieur au composé. Par exemple, dans la Figure 4.7, la propriété d encapsulation est spécifiée entre CoffeeMachine Coiner, ainsi qu entre CoffeeMachine et DrinkMaker. Les composants encapsulés peuvent communiquer entre eux (par exemple via la relation C-DM). Par contre, le composant 78

91 4.1. Étude de l application de la relation Tout-Partie à la composition logicielle component CoffeeMachine CM-DM component DrinkMaker C-DM component Coiner C-EM component E-Money Fig. 4.7 Domaine d application de l encapsulation E-Money, extérieur au composé, ne peut pas interagir directement avec Coiner (la relation C-EM n est pas empêchée par la propriété d encapsulation). E-Money peut toutefois interagir avec CoffeeMachine. Nous laissons ainsi au développeur du composé le soin de juger si des sous-composants peuvent interagir au sein d un même composé. L interaction entre sous-composants d un composé est d ailleurs décrite comme possible dans [CHJK02a] :«Objects within a single component have access to each other s implementation» Partageabilité et exclusion locales et globales La notion de partage entre composants peut être vue à plusieurs niveaux : partage d un même processeur, partage de mémoire commune ou de flots de données par exemple. Nous nous intéressons au partage des services dans la suite de cette discussion. Dans ce cadre, le partage peut être défini de la manière suivante : «La notion de partage permet à un même composant Partie de faire partie de plusieurs composants Tout. Le partage peut intervenir au niveau local ou au niveau global [BLB02]». De la même manière que pour l encapsulation, nous traitons du partage entre Tout et Partie hors du sous-système évoqué. Nous ne discutons pas du partage entre sous-composants par exemple. component Altimètre component Nominal:Altimètre component Secours:Altimètre component Baromètre component :Baromètre (1) (2) Fig. 4.8 Partageabilité locale Le partage au niveau local consiste à partager une instance du composant Partie entre plusieurs instances de même type de composant Tout. Dans la Figure 4.8, en (1), le composant de type Altimètre est composé du composant Baromètre, formant une relation Altimètre - Baromètre ; en (2), une instance de Baromètre peut être partagée par plusieurs instances de Altimètre, si la propriété de partageabilité locale a été spécifiée en (1). Le partage au niveau global consiste à partager une même instance du composant Partie entre une ou 79

92 Chapitre 4. Une approche pour la composition logicielle basée sur la relation Tout-Partie plusieurs instances de composants Tout, ces derniers étant de types différents. Considérons les relations Altimètre - Baromètre et GPS - Baromètre. Dans la Figure 4.9 en (1), Baromètre est un sous-composant de Altimètre et de GPS ; une instance de Baromètre peut être partagée par une ou plusieurs instances de Altimètre et/ou de GPS. component Altimètre component GPS component :Altimètre component :GPS component Baromètre (1) (2) component :Baromètre Fig. 4.9 Partageabilité globale Le contraire de la partageabilité locale est l exclusion locale. Elle signifie qu une même instance d un composant Partie ne peut pas faire partie de plusieurs instances de composants Tout de même type. Dans la Figure 4.8 en (2), si l exclusion locale a été spécifiée sur la relation Altimètre - Baromètre en (1), un des deux liens de composition est impossible en (2). Le contraire de la partageabilité globale est l exclusion globale. Elle signifie qu une même instance d un composant Partie ne peut pas faire partie de plusieurs instances de composants Tout de différents types. Dans la Figure 4.9 en (1), si l exclusion globale a été spécifiée sur la relation Altimètre - Baromètre, alors le lien de composition GPS - Baromètre est impossible. La partageabilité a un impact sur la disponibilité des services rendus par un sous-composant. Un composant partagé peut nécessiter d être configuré d une certaine façon lorsqu il interagit avec un premier composé, et être configuré d une autre manière lorsqu il interagit avec un second. La reconfiguration lors du passage de l un à l autre est dynamique. Elle ne pose pas de problème si, par exemple, les deux composés n ont besoin du sous-composant que de manière séquentielle, dans un traitement journalier par exemple. La Figure 4.10 montre le sous-composant Gestionnaire de BD gérant l accès dynamique à une base de données. Il est en relation avec un composant Tout Dictionnaire de mots et avec un composant Tout AdministrationStock assurant la maintenance de la base de données (ajout/suppression de références, par exemple). On peut imaginer que le composé AdministrationStock assure la maintenance de nuit. Le sous-composant Gestionnaire de BD est alors reconfiguré pour offrir des services de maintenance. Le composé AdministrationStock peut alors fonctionner pendant ce temps. Le composé Dictionnaire de mots ne fonctionne pas pendant ce temps. Cette solution est acceptable, par exemple dans une entreprise fermée la nuit. Elle ne l est pas pour un service Web par exemple. Dans ce cas, les interférences dues par exemple à une reconfiguration doivent être minimales Dépendances de cycles de vie La propriété de dépendance des cycle de vie caractérise la relation en terme de création et de destruction des instances de composants Tout et Partie. Il y a neuf cas possibles selon les ordres de création et de destruction. La Figure 4.11 illustre ces neuf cas. Le cycle de vie est représenté par un segment 80

93 4.1. Étude de l application de la relation Tout-Partie à la composition logicielle AdministrationStock Dictionnaire de mots reconfiguration Gestionnaire de BD Fig Partageabilité séquentielle horizontal borné par deux rond : le blanc matérialise la naissance et le noir la mort du composant. Le segment le plus haut représente le cycle de vie du Tout ; les autres représentent les cycles de vie possibles du composant Partie. Les segments verticaux en pointillés matérialisent une projection de la naissance et de la mort du composant Tout. Le premier cas illustre la simultanéité de naissance (et de mort) des deux composants : on parle alors de dépendance existentielle. Par simultanéité, il faut comprendre modulo le temps de création (et de destruction), c est-à-dire le retour des fonctions de création (et de destruction) de chaque composant. En effet, les phases d initialisation et de terminaison sont à considérer indépendamment du processus opérationnel pour lequel le programme a été conçu. C est particulièrement vrai dans des domaines tels que le temps réel où le temps d exécution de ces phases peut conduire à un débordement des cycles de calcul, par exemple. Tout Partie (1) (2) (3) (4) (5) (6) (7) (8) Temps (9) Fig Les neuf cas de cycle de vie La pertinence de certains cas dépend du bien-fondé de la transcription de ces cas dans le réel. Par exemple, est-il possible d envisager l existence du composant Tout sans que le composant Partie ait été créé, et alors que le composant Tout s appuie sur sa partie pour fournir ses services? Prenons deux 81

94 Chapitre 4. Une approche pour la composition logicielle basée sur la relation Tout-Partie exemples : Imaginons que le composant Tout s intègre dans une application temps-réel critique. Il semble dangereux de permettre au composant Tout de proposer un service qu il ne peut rendre que si sa partie est en exécution alors que le cas (4) de la Figure 4.11 par exemple a été spécifié lors de la modélisation. Cela signifie que, avant que le composant Tout puisse fournir son service, il doit attendre l instanciation du composant Partie. Cela peut entraîner une perte de temps inacceptable dans ce type d application. Imaginons la même relation dans une application non critique. Dans cette application, le service du composant Tout nécessitant l exécution du composant Partie n est appelé qu un nombre de fois limité (c est le cas d un composant Partie gérant un service d impression par exemple). Dans ce cas, la présence en exécution du composant Partie peut être envisagée comme une charge inutile du système. Ainsi, la mise en œuvre de la relation comme modélisé en (4) sur la Figure 4.11 se justifie. La caractérisation de la propriété de dépendance existentielle est moins triviale qu il n y paraît. Le choix fait par le concepteur peut avoir un impact considérable dans certains cas. Plus la criticité de l application est liée à la relation, plus le couplage entre cycle de vie du composant et du composé doit être important. Cela permet d éviter les temps de latence dus à la création ou à la destruction du souscomposant Séparabilité et mutabilité Les propriétés de séparabilité et de mutabilité sont fortement couplées. Elles permettent de caractériser la dynamique de la relation de composition. «La séparabilité est la propriété caractérisant le fait qu un composant Partie puisse être séparé de son composant Tout». Malheureusement, cette propriété est source de confusion, à cause de son manque de distinction avec, en particulier, la dépendance de vie [BLB02]. En effet, considérons la relation Tout-Partie CoffeeMachine - DrinkMaker. Posons la propriété 1 de la Figure 4.11 comme dépendance de cycle de vie. La propriété impose une simultanéité de création et de destruction. Mais elle n impose pas que les composants formant la relation ne puissent pas être séparés. De plus, en cas de séparation des deux composants, la relation de composition entre eux n existe plus. La règle sur les dépendances de cycle de vie n est alors pas applicable. Pour préciser ce problème, il convient de s intéresser à la mutabilité [BLB02]. Dans le domaine composant, la mutabilité a la définition suivante : «La mutabilité est la propriété qui permet de faire évoluer en nombre et/ou en identité l ensemble des sous-composants de même type liés à un composé. Par opposition, l immutabilité implique que l ensemble des sous-composants de même type d un composé soit le même tout au long du cycle de vie du composé, en nombre et en identité» [BLB02]. [BHSOG01a] a établi formellement que (i) immutabilité => inséparabilité et que donc (ii) séparabilité => mutabilité. L implication (i) entraîne pour un tel type de relation une dépendance existentielle. La séparabilité et la mutabilité peuvent être comparées avec l aspect dynamique de Fractal [Bru03]. Nous en reparlons dans la section Enfin, de même manière que discuté pour la propriété de dépendance de cycle de vie, ces propriétés sont à considérer pour le cycle opérationnel, i.e. indépendamment des phases d initialisation et de terminaison. Afin d illustrer le rôle de ces deux propriétés, nous donnons deux exemples. Le premier illustre la non séparabilité. Imaginons, dans le cadre de la machine à café, que la non séparabilité ait été spécifiée sur la relation CoffeeMachine - Coiner. L exemple de code suivant montre une violation de cette 82

95 4.1. Étude de l application de la relation Tout-Partie à la composition logicielle propriété : CoffeeMachine, lorsqu il reçoit l information notifiant qu il y a assez d argent pour délivrer une boisson, se sépare de Coiner. 1 public c l a s s CoffeeMachine { 2 Coiner _ instofcoiner ; 3 4 void HandlerEnoughMonney ( ) { 5 _ instofcoiner = NULL; 6 [... ] 7 }} Le second exemple que nous donnons illustre la mutabilité. Dans le cadre d une relation Serveur - Session, un composant Serveur doit créer une instance du sous-composant Session à chaque fois qu il reçoit une demande de nouvelle connexion. C est un cas d ajout dynamique de composants. L exemple de code suivant illustre ce cas. La mutabilité autorise ce fonctionnement. 1 public class Serveur { 2 void AddNewSession ( ) { 3 _setofsession [... ] = new S e s s i o n ( ) ; 4 [... ] 5 }} Transitivité Notre étude n a pas retenu cette propriété. En effet, nous verrons à la section qu elle peut être caractérisée par la conjugaison des propriétés d encapsulation et de partageabilité. Son étude est toutefois intéressante car elle présente des éléments de question non encore abordés. component Calculateur component GPS component Station météo (a) (b) (c) (f) (g) component Altimètre component Générateur de graphique (d) (e) «interface» SetPression GetPression component Baromètre Fig Transitivité sur les services et partage 83

96 Chapitre 4. Une approche pour la composition logicielle basée sur la relation Tout-Partie La transitivité est une propriété atypique. Elle concerne un triplet identifié de types de composants, alors que les autres relations traitent d une seule relation, donc d une paire de types de composants : la partageabilité, par exemple, spécifie qu un sous-composant est partageable mais n identifie pas le composé hors du sous-système de la relation initiale. La Figure 4.12 représente cinq relations Tout-Partie : Gps - Altimètre, Calculateur - Altimètre, Altimètre - Baromètre, Station météo - Générateur de graphique et Générateur de graphique - Baromètre. L application partiellement modélisée dans cet exemple est composée de trois composants de granularité forte : un GPS (Global Position System), qui est un système de positionnement par satellite. Il s appuie sur un composant Altimètre, lui-même usant d un composant Baromètre. L altimètre dispose d un baromètre pour établir l altitude en fonction de la pression. Le composant GPS se sert des services du baromètre pour afficher la pression courante et la modifier le cas échéant grâce à une interface (c). Le composant Baromètre fournit deux services à travers les opérations SetPression et GetPression, respectivement servant à initialiser et à récupérer la pression courante ; une station météo présentant notamment des graphique d évolution des pressions, générés par le composant Générateur de graphique. Celui-ci manipule le composant Baromètre pour obtenir la pression courante à intervalles régulièrs. Le composant Station météo utilise également le composant Baromètre pour afficher la pression courante ; un calculateur. Il s appuie sur le composant Altimètre, et donc indirectement sur le composant Baromètre. Cependant, à la différence de Station météo ou de GPS, il n a pas besoin directement des services de Baromètre. D un point de vue services, la propriété de transitivité permet au composant GPS d utiliser directement un service du composant Baromètre sans que ce service soit fourni par l interface d Altimètre. Au contraire la non transitivité indique que GPS ne peut utiliser un service de Baromètre que s il est fourni par l interface d Altimètre. Les composants GPS et Station météo utilisent le composant Baromètre, mais de manière différente. Le composant GPS utilise la totalité des services de Baromètre puisqu il récupère la pression courante mais peut également l initialiser. Dans ce cas la propriété de transitivité peut être spécifiée sur la relation Altimètre - Baromètre. Au contraire, le composant Station météo n utilise que le service GetPression. Par mesure de sécurité, il ne peut accéder à SetPression. La propriété de transitivité ne doit pas être spécifiée dans ce cas. Enfin, le composant Calculateur n utilise aucun service du composant Baromètre. La propriété de non transitivité doit donc être spécifiée. La relation Altimètre - Baromètre est particulièrement remarquable dans l exemple précédent. Le composant Altimètre est le composant Partie de deux relations Tout-Partie : Calculateur - Altimètre et Gps - Altimètre. Les besoins de transitivité ne sont pas les même pour les deux relations. Cela pose la question concrète de la relation sur laquelle va être déclarée la transitivité. En effet, l exemple illustre bien qu on ne peut, comme on pourrait le penser intuitivement, la déclarer sur la relation Altimètre - Baromètre. On peut également se demander si la transitivité ne peut pas se spécifier au niveau des opérations plutôt qu au niveau des relations. Cela offrirait plus de précision. Cependant, cette solution va à l encontre de l esprit composant puisqu il est admis qu on ne traite que les interfaces. Par contre, il semble avantageux de pouvoir le spécifier, non pas au niveau des relations entre composants directement, mais plutôt au niveau des liens entre les interfaces, c est-à-dire à un niveau de conception plus détaillé. Cela laisserait au concepteur la possibilité de définir des interfaces différentes avec, par exemple, une interface fournissant les services pouvant être toujours transitifs et une autre les services plus critiques. 84

97 4.1. Étude de l application de la relation Tout-Partie à la composition logicielle Configurationalité La propriété de configurationalité permet de spécifier l existence d un lien entre les composants Partie, d un même Tout. Par exemple, dans le cadre d une voiture (le Tout), son fonctionnement n est possible que si les composants Partie (roues, carrosserie, transmission, moteur) ont des relations bien définies entre elles. Dans le cadre d une composition verticale, nous pensons que cette propriété n apporte pas une information nouvelle et intéressante. En effet, le lien qu il peut y avoir entre un sous-composant et un autre se traduit par une relation de composition horizontale entre ces deux sous-composants. Cette affirmation est appuyée par la remarque suivante, issue du commentaire associé à la règle Ocl de [BHSPLB03] spécifiant cette propriété : «for a bundle of Whole-Part relationships having the same Whole type, any Part Type is involved in at least one connection with the other Part types of the bundle». Nous ne retenons donc pas cette propriété pour caractériser la composition verticale Classification des propriétés retenus selon les dimensions architecturale et dynamique Van der Hœk et al. [And98] ont proposé une plate-forme proposant des critères pour la modélisation des systèmes. L étude constate que les recherches menées sur les architectures logicielles, le pilotage des configurations et les systèmes distribués évoluent indépendamment. Leurs contributions ne concernent que leur propre domaine d intérêt. Les auteurs regrettent cet état de fait et précisent que ces trois domaines tournent autour d un but commun qui est la modélisation des systèmes. Ils défendent une approche commune basée sur la modélisation des systèmes et préconisent que cette approche s appuie sur des critères communs. Ils ont pour cela proposé la définition de six critères selon lesquels une plate-forme de modélisation devait être construite : la composition (que nous appellerons dimension architecturale) : modélisation du système comme un ensemble de composants interconnectés ; la cohérence 27 : renforcement de la cohésion d un système lorsque des composants sont combinés ; la construction : support de la construction d un système exécutable ; la traçabilité de version : spécifation de l existence et des relations entre les différentes versions des composants ; la sélection : sélection d un composant à partir d un ensemble de composants ; le dynamisme : support des changements dynamiques d un système déployé. Nous considérons que cette approche est applicable à la modélisation des applications à base de composants. Nous pensons qu elle apporte une démarche globale allant dans le sens de l amélioration de la qualité de ces applications. Nous utilisons ces critères dans notre travail. Nous ne traitons cependant pas les critères de traçabilité des versions et de sélection des composants car nous les considérons moins fondamentaux pour notre approche. Nous nous intéressons donc aux principaux critères ayant un impact sur nos travaux : l aspect architectural et l aspect dynamique. Dans une moindre mesure, nous intégrons les critères de cohérence et de construction dans notre approche. Nous les traitons au niveau de notre outillage (voir page 103). Comme nous le discutons en détail à la section 4.3, nous ne prouvons pas formellement la cohérence de notre approche. Nous la fixons par construction. Nous avons défini un outillage utilisable à divers niveaux du cycle de vie d une application basée composants : un profil Uml permet de modéliser la composition ; un environnement contraint de déploiement autorise le déploiement 27 Nous utilisons cohérence pour traduire l anglais consistance. 85

98 Chapitre 4. Une approche pour la composition logicielle basée sur la relation Tout-Partie de composants en respectant les propriétés de composition spécifiées à l aide du profil ; enfin, une librairie Java supporte la définition de contrats de composition pour tester le comportement final des composés. Nous rentrons effectivement dans le cadre de la définition de la construction. propriété dimension architecturale dimension dynamique asymétrie au niveau instance antisymétrie au niveau type encapsulation partageabilité séparabilité mutabilité dépendance de cycles de vie X X X X X X X Tab. 4.3 Classification des propriétés de composition retenues selon les dimensions architecturale et dynamique Nous nous intéressons aux critères architecturaux et dynamiques. Les propriétés que nous avons identifiées entrent dans ces deux dimensions. Les propriétés d asymétrie au niveau instance, d antisymétrie au niveau des types, d encapsulation et de partageabilité permettent de définir les relations entre les composants d un point de vue architectural. Les propriétés de dépendance des cycles de vie, de séparabilité et de mutabilité sont, elles, liées à la dimension dynamique du système, puisqu elles permettent de définir les relations entre les composants en fonction du temps d exécution. Le tableau 4.3 résume cette classification. Cette approche se retrouve également appliquée dans [BCS02], où Bruneton et al. identifient les propriétés que doit avoir un modèle de composants générique selon ces deux dimensions Relations entre les propriétés de composition retenues Nous discutons dans cette section des relations entre les propriétés secondaires (au sens de [BHSPLB03]) retenues. Nous ne traitons pas des cas d asymétrie au niveau instance ni d antisymétrie au niveau des types. Ces deux propriétés sont caractéristiques de toute de forme de relation Tout-Partie comme a montré [BHSPLB03]. Notre objectif est d identifier, à travers les relations entre les propriétés secondaires, différents sous-types de la relation Tout-Partie. Dans la suite de cette section, nous détaillons pour chaque propriété secondaire l impact de sa sélection ou de sa non sélection sur les autres propriétés de la relation. Le tableau 4.4 résume les relations entre les propriétés secondaires retenues. Les propriétés sélectionnées sont en gris foncé et les propriétés sur lesquelles il y a des conséquences sont en gris clair Aspect architectural : lien entre les propriétés De part la contrainte architecturale qu elle impose, la propriété d encapsulation a un impact sur le cycle de vie du composant Partie. Ainsi, pour qu un composant puisse être encapsulé par un autre, il faut que ce dernier existe : l encapsulation impliquant que le composant Partie ne soit accessible que par le composant Tout, il est incohérent d envisager l existence du composant Partie sans que le Tout ait été instancié. Ainsi, cela garantit, qu aucun autre composant ne pourra accéder au futur composant Partie, et cela permet, de plus, de ne pas surcharger le système inutilement. Nous posons donc que seuls les cas de (1) jusqu à (4), de la Figure 4.11 page 81, sont autorisés lorsque la propriété d encapsulation est spécifiée. 86

99 4.1. Étude de l application de la relation Tout-Partie à la composition logicielle encapsulation partageabilité séparabilité mutabilité encapsulation partageabilité séparabilité mutabilité dépendance de cycles de vie non partageabilité globale cas 1 à 4 exclusion globale et locale => encapsulation mutabilité inséparabilité => cas 1 immutabilité => inséparabilité Tab. 4.4 Relation entre les propriétés secondaires retenues L encapsulation a également un lien fort avec les notions de partage et de transitivité. Pour illustrer ce lien, nous allons nous servir de la Figure 4.12 page 83. Elle représente un système au niveau type. Imaginons que l on spécifie l encapsulation sur la relation Générateur de graphique - Baromètre. Cela implique l existence de deux instances de Baromètre, dont une encapsulée dans Générateur de graphique. L existence de deux instances de Baromètre peut être également spécifiée par l exclusion globale sur la relation. La propriété de partageabilité a un impact sur la transitivité (cette dernière n apparaît pas sur le tableau car nous ne l avons pas retenue). Si la propriété de non partageabilité globale est spécifiée, alors le composant Partie ne peut être accessible que par le composant Tout. Dans ce cas, un tiers composant, ayant une relation de type Tout-Partie avec le composant Tout précédent, ne peut accéder au composant Partie. La transitivité est donc empêchée par la spécification de la non partageabilité globale. Cela est suffisant car, dans le cas de la partageabilité locale, la propriété primaire d asymétrie au niveau des instances interdit que l on puisse se retrouver dans un cas où un composant serait composé de lui-même. L exclusion globale implique qu aucun Tout de type différent, du composé de la relation où la propriété est spécifiée, puisse accéder au sous-composant. L exclusion locale implique la même chose pour tout composé du même type. Les deux combinés impliquent donc l encapsulation sur la relation initiale. La spécification de la propriété de transitivité implique la partageabilité globale, et la non encapsulation. Il serait incohérent d autoriser explicitement la transitivité et de l empêcher en même temps par la spécification du non partage. Considérons la transitivité d un point de vue service. La spécification de la transitivité a un impact sur la partageabilité. La spécification de la non transitivité n a, par contre, pas d impact direct sur la partageabilité. En effet, la transitivité est une propriété portant sur la totalité des services. La non transitivité implique donc que la totalité des services ne puisse être utilisable directement par un autre composé. Par contre, elle n empêche pas d utiliser certains services du composant initial. En fait, on est amené à se poser la question de l opportunité de l utilisation de cette propriété dans notre cadre. En effet, la non encapsulation et le partage global sont suffisants pour spécifier la transitivité dans notre cadre. Nous ne retenons pas cette propriété au final. Le tableau 4.4 n en fait donc pas mention. 87

100 Chapitre 4. Une approche pour la composition logicielle basée sur la relation Tout-Partie Aspect dynamique : lien entre les propriétés Les liens entre les propriétés de séparabilité et de mutabilité ont été discutés dans [BHSPLB03]. Pour mémoire la séparabilité implique la mutabilité et l immutabilité implique l inséparabilité. Nous considérons ces propriétés acquises Identification de différents types de relations Tout-Partie Dans Uml 1.x, la relation de composition était modélisée à travers les relations de composition et d agrégation. Comme discuté en section 3.2 page 53, la sémantique de ces deux relations était mal définie dans la documentation Uml. Dans [BHSPLB03], ces deux relations sont décrites suivants les propriétés de la relation Tout-Partie qui les caractérisaient le mieux. La composition traduit un lien fort de composition dans lequel le composé et le sous-composant sont très fortement couplés. Le couplage au niveau architectural est assuré par une encapsulation totale et, au niveau dynamique par une dépendance existentielle. L agrégation, au contraire, traduit un faible couplage au niveau de la relation Tout-Partie, plus important qu une simple association. Au contraire de ce qui a été énoncé dans [BHSPLB03], nous pensons que ces deux types de relations Tout-Partie ne sont pas suffisants pour permettre la modélisation de tous les cas. En effet, la composition implique au niveau dynamique une dépendance existentielle. Cela a pour conséquence une simultanéité de création et de destruction pour le composé et le sous-composant. Or, dans certains cas, le souscomposant, bien qu encapsulé, ne fournit des services que très ponctuellement au composé. Le temps où il ne fournit pas de service, il occupe des ressources inutilement, ce qui peut être préjudiciable dans le cas d applications embarquées par exemple (Le sous-composant DrinkMaker dans la machine à café n a pas de raison d être en exécution en permanence). Nous préconisons donc un nouveau type de relation Tout- Partie garantissant le respect du fort couplage architectural mais apportant une plus grande souplesse sur le plan dynamique. L agrégation présente une forme de composition à très faible couplage architectural et dynamique. De la même manière que pour la composition, nous préconisons de préserver ce couplage faible au niveau architectural, mais également d offrir au concepteur un couplage plus fort au niveau dynamique Spécialisation selon la dimension architecturale La Figure 4.13 illustre, avec notre étude de cas, la différence entre agrégation et composition. La partie (1) représente le modèle de composants de l application. Le composant E-Money utilise Coiner pour approvisionner le porte-monnaie électronique. CoffeeMachine l utilise également. Deux relations Tout-Partie sont spécifiées : E-Money - Coiner et CoffeeMachine - Coiner. Les parties (2) et (3) représentent le résultat, au niveau implémentation, de la spécification de la composition ou de l agrégation sur la relation CoffeeMachine - Coiner en (1). En (2), l agrégation entraîne la spécification de la non encapsulation et de la partageabilité. Cela implique donc l existence d une seule instance de Coiner. En (3), la composition entraîne l encapsulation et la non partageabilité globale. Cela implique donc l existence de deux instances de Coiner, une encapsulée dans CoffeeMahine et l autre en relation avec E-Money. En fonction de la propriété spécifiée sur E-Money - Coiner, l instance :Coiner pourra être encapsulée ou non dans E-Money. Nous allons maintenant discuter de l intérêt de définir d autres types de relations Tout-Partie sur cet exemple, en mixant les propriétés de partageabilité et d encapsulation. Dans la Figure 4.14, les parties (4) 88

101 4.1. Étude de l application de la relation Tout-Partie à la composition logicielle component E-Money component CoffeeMachine (1) component Coiner component DrinkMaker component :E-Money component :CoffeeMachine component :E-Money component :CoffeeMachine component :DrinkMaker component :Coiner component :DrinkMaker component :Coiner (2) (3) component :Coiner Fig Différence entre agrégation et composition et (5) représentent le résultat, au niveau implémentation, de la spécification des propriétés d encapsulation et/ou de partage sur la relation CoffeeMachine - Coiner en (1) de la Figure En (4), la propriété d encapsulation a été spécifiée sur CoffeeMachine - Coiner ainsi que la propriété de partage global. Cela signifie que l instance de Coiner est encapsulée à l intérieur du composant CoffeeMachine. Mais cela implique que l instance de E-Money puisse accéder également à l instance de Coiner, malgré l encapsulation. D un point de vue implémentation, l encapsulation implique que l instance de Coffee- Machine instancie l instance de Coiner. Il faut donc, pour que E-Money puisse l utiliser, que celui-ci ait une référence vers l instance de Coiner. En Java, cela pourrait se faire de la manière illustré par le code suivant, c est-à-dire par une fonction spécifique de l interface de configuration : 1 public class coffeemachine implements [... ] { 2 // i n s t a n c i a t i o n des composants P a r t i e e n c a p s u l e s 3 Coiner _ coiner ; 4 [... ] 5 // Passage d une r e f e r e n c e v e r s Coiner 6 Coiner g e t R e f e r e n c e ( ) { 7 return ( _coiner ) ; 8 }} Ce cas est très intéressant puisque, alors qu il est réalisable techniquement, il viole les définitions des propriétés données précédemment. En fait, se pose la question de l application stricte de l encapsulation. Par définition, elle implique que le sous-composant ne soit accessible par aucun autre composé. Or, la spécification de la non partageabilité globale et locale est équivalente. Il y a donc une forme de redondance. Nous proposons donc de traiter la propriété d encapsulation comme une spécification architecturale. Elle signifie la contenance physique mais est décorrélée de son lien avec la partageabilité. Le couplage de l encapsulation et du partage global par exemple signifie que, bien qu encapsulé physiquement au sein du composé initial, le sous-composé peut rendre directement des services à un composé d un autre type. Le 89

102 Chapitre 4. Une approche pour la composition logicielle basée sur la relation Tout-Partie component :E-Money component :CoffeeMachine component :Coiner component :DrinkMaker (4) component :E-Money component :CoffeeMachine (5) component :Coiner component :Coiner component :DrinkMaker Fig Autres sous-types de relation Tout-Partie composé initial aura à sa charge de permettre cela, quelque soit la technique utilisée. Enfin, en (5), les propriétés de non encapsulation et d exclusion globale ont été spécifiées. Cela implique donc l existence de deux instances de Coiner distinctes non encapsulées. Cet exemple montre que les simples relations de composition et d agrégation sont insuffisante pour couvrir les différentes possibilités offertes par la combinaison des propriétés de partage global et d encapsulation. Nous proposons donc la définition de quatre relations de type Tout-Partie, couvrant la dimension architecturale de la relation Tout-Partie. La première, dérivée de la composition initiale de Uml, conjugue l encapsulation et le partage global. Nous la nommons Strong Composition. La seconde, implique la non encapsulation et le non partage global, et affine la définition de l agrégation initiale d Uml. Nous la nommons Lightweight Aggregation. La troisième, conjugue l encapsulation et le partage global. Nous la nommons Lightweight Composition. L encapsulation la cantonne dans la famille des composition. Enfin, la quatrième entraîne la non encapsulation et l exclusion mutuelle. Il s agit dans l esprit d une agrégation. Nous la baptisons Strong Aggregation. Dans cette discussion, nous n avons pas étudié l impact de la propriété de partage/exclusion local. Nous laissons en fait le choix au concepteur de renforcer la sémantique des modèles utilisant ces quatre sous-types de la relation Tout-Partie avec cette propriété. Ce choix est guidé par le fait que cette propriété s applique sur un même type de composé. Il s agit donc d une propriété qui aura plus d impact au niveau du concepteur de composants que sur celui d utilisateur de composants. Or celui-ci à une vue plus microscopique de son travail puisqu il est spécialisé sur un seul composant et donc a besoins de plus de liberté d action Spécialisation selon la dimension dynamique Comme discuté en amont de la spécialisation architecturale, la dimension dynamique implique des spécificités au niveau des différents types de relations Tout-Partie. Nous pensons qu il est intéressant 90

103 4.2. Définition d un métamodèle Uml pour la Cbse basé sur la relation Tout-Partie de le faire suivant deux aspects : un aspect dynamique et un aspect statique. L aspect statique traduit une relation stable et immuable de sa création jusqu à sa destruction. Cela implique la spécification des propriétés d inséparabilité et d immutabilité. Et inversement pour l aspect dynamique. Nous choisissons de lier les propriétés de mutabilité et de séparabilité dans les types identifiés de relation Tout-Partie. Nous laissons l opportunité au concepteur de ne pas les lier en spécifiant les propriétés une à une. L encapsulation a également un impact sur le côté dynamique du système puisqu il implique que le composé soit créé avant (respectivement détruit après) ou au moins en même temps que le composant. Cela limite aux cas (1),(2), (3) et (4) des dépendances de cycle de vie, de la Figure 4.11 page 81. Le tableau 4.5 résume ces spécialisations Résumé de l étude Dans cette section, nous avons présenté notre vision de la composition verticale sur la base de la sémantique apportée par la relation Tout-Partie. Nous avons étudié et illustré l applicabilité des propriétés définies dans [BHSPLB03] à la conception de la composition. Seules deux propriétés ne nous ont pas semblé adaptées dans ce cadre, il s agit de la configurationalité et de la transitivité. La propriété d encapsulation a également nécessité un complément de définition. En effet, nous avons montré que sa définition initiale était trop stricte d une part, et redondante d autre part avec celle de la non partageabilité globale. Nous l avons donc restreinte en la décrivant comme une propriété spécifiant la contenance mais pas le non partage. Enfin, dans le cadre des propriétés primaires, nous nous sommes positionnés sur le fait que l existence d au moins une propriété émergente et d une résultante, soit recommandée mais plus obligatoire. Cela permet d utiliser notre modèle de composition hiérarchique pour des compositions qui, a priori, ne pouvaient y être candidates. Par ailleurs, cette étude nous a permis d identifier quatre types de relation de composition jouant sur des critères architecturaux. Elles sont caractérisées par leur dimension dynamique également. Elles offrent la possibilité de spécifier des relations Tout-Partie en couvrant la totalité des combinaisons possibles entre fort couplage et faible couplage. Le tableau 4.5 résume les différents types de la relation Tout-Partie en fonction des propriétés qui les caractérisent. Cependant, nous avons noté qu il était intéressant de proposer au concepteur de combiner lui-même les propriétés d une relation Tout-Partie, dans la mesure où ces combinaisons n interfèrent pas avec les liens qui existent entre les propriétés. Ainsi, cette approche offrent à la fois des relations avec une base de propriétés déjà spécifiées couvrant un large spectre de modélisation, mais également une certaine souplesse en autorisant le concepteur à spécifier lui-même des relations de type Tout-Partie particulières. 4.2 Définition d un métamodèle Uml pour la Cbse basé sur la relation Tout-Partie Dans la section précédente, nous avons présenté notre modèle de composition pour l amélioration de la relation de composition au niveau conception. Notre approche est basée sur la spécification de règles de composition et la définition de relations de composition prédéfinies en fonction de ces propriétés. Notre objectif est d intégrer ce modèle de composition à Uml afin de pallier aux incohérences du langage sur ce thème. Le langage Uml est auto-inclus, c est-à-dire qu il est défini par lui même. Sa définition repose sur un métamodèle d une part et sur des règles Ocl précisant sa syntaxe d autre part. Des commentaires 91

104 Chapitre 4. Une approche pour la composition logicielle basée sur la relation Tout-Partie Strong Composition Lightweight Composition Strong Agrégation Lightweight Agrégation stat. dyn. stat. dyn. stat. dyn. stat. dyn. encapsulation oui oui oui oui non non non non partageabilité non non oui oui non non oui oui séparabilité / non oui non oui non oui non oui mutabilité. dépendance de 1 cas 4 cas 1 cas 4 cas 9 cas 9 cas 9 cas 9 cas cycles de vie Tab. 4.5 Les différents types de la relation Tout-Partie textuels précisent également des notions non exprimables en Ocl. Nous travaillons donc sur ces trois niveaux de définition. Cette section est organisée de la manière suivante : nous discutons de l orientation que nous souhaitons donner à notre métamodèle en section ; nous décrivons ensuite notre proposition de métamodèle en section : nous discutons enfin de la traduction en Ocl des propriétés de composition dans la section Rappelons que ces propriétés ont été initialement discutées et traduites sous la forme de règles Ocl dans [BHSPLB03]. Notre contribution a consisté à adapter le contexte de ces propriétés au nouveau métaschéma et à corriger des erreurs de l article initial. Aussi, le détail des règles Ocl adaptées est donné en annexe A Discussion sur les choix de métamodélisation Notre problématique consiste à améliorer le concept de relation de composition dans Uml. Notre travail se situe donc au niveau M2 du Mof, comme discuté en section 3.1. Nous discutons dans cette section du concept de relation de composition. Nous décrivons les modifications que nous préconisons au niveau du métamodèle Uml Première approche intuitive Nous cherchons à caractériser la notion de composant en fonction de ses assemblages. Un composant peut être un composant Tout s il est composé de sous-composants. Ce même composant lorsqu il est assemblé peut-être considéré comme un composant Partie. La différence dépend de la sémantique de la relation de composition. Notre première approche, intuitivement, a été de proposer une spécialisation de la métaclasse component [BBB03b, BBB03c]. L objectif était de spécialiser chaque composant par son rôle dans la composition, à l aide de stéréotypes. Dans l exemple de la Figure 4.15, le composant Calculateur a été spécialisé comme un composant Tout grâce au stéréotype «Whole» et le composant Centrale de mesure comme un composant Partie, grâce au stéréotype «Part». Or, un composant Tout, dans une première relation, peut être lui-même le composant Partie dans une seconde relation. Deux choix sont alors envisageables. Le premier consiste à considérer une relation de composition à la fois, ce qui implique presque autant de schémas que de relations Tout-Partie. Cette solution n est pas satisfaisante. 92

105 4.2. Définition d un métamodèle Uml pour la Cbse basé sur la relation Tout-Partie component Whole Calculateur component Part Centrale de mesure Fig Première approche intuitive de mise en œuvre de la relation Tout-Partie La deuxième solution, que nous avons choisie, consiste à caractériser son rôle dans la relation concernée. Nous illustrons cette approche par l exemple de la Figure 4.16 : le composant Calculateur est caractérisé comme un composant Tout (et respectivement Centrale de mesure comme un composant Partie) en fonction de son rôle dans la relation. component Calculateur Whole Part component Centrale de mesure Fig Orientation de la mise en œuvre de la relation Tout-Partie Un des avantages d Uml vient de la possibilité qui est faite au concepteur de modéliser l application suivant différents points de vue. Il est donc intéressant de permettre au concepteur de créer des schémas locaux (représentant un seul niveau de composition, par exemple un seul composant Tout avec un ou plusieurs composants Partie) dans lesquels il pourra utiliser une notation proche de celle de l exemple de la Figure Pour des schémas de plus grande granularité, il pourra utiliser les notations proches de celles de la Figure Bases de notre proposition Comme nous l avons vu dans la section 3, notre travail a porté sur la base de Uml 1.x. Nous avons cependant cherché à ce que l effort nécessaire au passage de nos travaux de Uml 1.x à Uml 2.0 soit le moins important possible. Pour ce faire, nous avons fait apparaître certains concepts de la version 2.0 dans notre approche. D autre part, les aspects traitant de la composition entre composants dans Uml 2.0 sont encore limitatifs et sans sémantique particulière [BO03]. Pour ces raisons nous avons choisi de proposer une modification du métamodèle Uml spécifique à notre approche et en même temps facilement intégrable dans les versions ultérieure d Uml. Pour ce faire, nous avons défini un nouveau métatype abstrait modélisant la relation de composition entre les composants. Ce choix présente un inconvénient. Il spécialise une notion de conception propre à un type de classifier particulier, les composants. En ce sens, il complexifie le langage Uml au détriment de sa généricité. Cependant, cette branche de modèle pourra à terme être insérée dans une version stable d Uml 2.0, en tant que généralisation d une forme de relation, par exemple. La prise en compte d une relation de 93

106 Chapitre 4. Une approche pour la composition logicielle basée sur la relation Tout-Partie composition spécifique aux composants est en accord avec l importance croissante du monde composant tant dans l industrie que dans le monde académique. Uml a bien été, à la base, une spécialisation des langages de conception vers le monde objet. Dans le même esprit, nous justifions notre proposition comme une spécialisation du langage de conception Uml vers le monde composant, suivant alors l évolution des techniques de modélisation et des technologies actuelles Proposition de métamodèle La modification du métamodèle pour l intégration de nos travaux porte principalement sur l ajout d une relation spécifique. Le type de diagramme sur lequel nos travaux ont un impact est également à considérer. En effet, dans la version 1.x, les composants étaient principalement traités au niveau des diagrammes de déploiement. Dans la version 2.0, le diagramme de composants permet de concevoir, d un point de vue architectural, les applications par assemblage de composants. Il permet également de modéliser l architecture d un point de vue instances de composants. Notre travail porte sur la modélisation de la composition lors des phases d analyse et de conception préliminaire. Il a un impact sur les aspects architecturaux, dynamiques et comportementaux de l application. Les aspects architecturaux se traitent au niveau du diagramme de composants en Uml 2.0. Les aspects dynamiques que nous traitons sont en fait des contraintes que nous spécifions et non une description de la dynamique du système. Nous préconisons de les traiter au même niveau que les contraintes architecturales. Enfin, les aspects comportementaux seront considérés par des diagrammes d état-transition classiques Ajout de la métaclasse VerticalComponentRelationship Nous avons vu précédemment que Uml 2.0 ne résolvaient pas les incohérences au niveau de la notion d agrégation et de composition des composants. L introduction des composite structures ajoute même un nouveau moyen de modéliser la composition, laissant le choix au concepteur du concept à utiliser. Or, les composite structures sont des classifiers, et non spécifiquement des composants. Cela peut induire en erreur le concepteur. Nous préconisons donc, pour la modélisation des compositions de composants, de restreindre les moyens d expression de cette composition. Dans ce cadre, nous ne retenons pas les composite structures et exprimons nos relations de composition à la manière de l agrégation et de la composition dans Uml 1.x. Le métaschéma. Nous avons défini la métaclasse abstraite ComponentRelationship. Elle matérialise toute forme de relation entre composants et n est pas implémentable. Nous matérialisons respectivement les compositions verticales et les compositions horizontales par les deux métaclasses VerticalComponentRelationship et HorizontalComponentRelationship. Ces deux métaclasses sont disjointes (c est-à-dire qu une relation de composition doit être soit verticale, soit horizontale) et implémentent la métaclasse ComponentRelationship. Rappelons que nous ne traitons pas, dans ce travail, le cas de la composition horizontale. Cependant, nous pensons qu un travail similaire au notre peut être porté sur les compositions horizontales. Une relation de composition verticale est établie entre deux composants, le composant Tout et le composant Partie. Cette caractérisation de la notion de composant se fait sur le rôle que joue un composant dans la relation. Pour matérialiser cette notion, nous avons défini deux liens d association entre la métaclasse component et la métaclasse VerticalComponentRelationship. Nous avons nommés ces associations en fonction du rôle joué par le composant, wholemember et partmember. Enfin, nous avons spécialisé la métaclasse InstanceSpecification en CompInstance afin de traduire le concept d instance de composant. 94

107 4.2. Définition d un métamodèle Uml pour la Cbse basé sur la relation Tout-Partie Relationship InstanceSpecification disjoint classifier 1..* ComponentRelationship Association Classifier disjoint CompInstance 0..* iscompinstof Horizontal ComponentRelationship Vertical ComponentRelationship * * 1 wholemember 1 partmember Component 1..* iscompof Fig Ajout des métaclasses modélisant la relation de composition Nous revenons ainsi à un concept qui existait en Uml 1.x et qui a disparu dans Uml 2.0. Nous justifions ce choix par notre optique de spécialisation orientée composition de composants. La Figure 4.17 présente cette partie de notre métamodèle. Les métaclasses ajoutées sont en gris foncé. Les liens ajoutés sont en double épaisseur. Les propriétés de composition identifiées dans la section 4.1 caractérisent la VerticalComponentRelationship. Nous incluons les propriétés paramétrables en tant qu attributs de celle-ci. Les attributs isencapsuled, isglobalshared, islocalshared, isseparable et ismutable prennent une valeur booléenne. Les autres attributs possèdent un jeu de valeurs prédéfinies. Le tableau 4.6 résume les attributs, leur type et les jeux de valeurs prédéfinies. attribut type du jeu de valeur valeurs possibles commentaires isencapsuled Boolean true/false spécifie l encapsulation isglobalshared Boolean true/false spécifie la partageabilité globale islocalshared Boolean true/false spécifie la partageabilité locale isseparable Boolean true/false spécifie la séparabilité ismutable Boolean true/false spécifie la mutabilité lifedependency LifeDependencyKind de 1 à 9 spécifie les relations entre le cycle de vie du composé et celui du composant : 9 cas sont possibles Tab. 4.6 Détail des valeurs prédéfinies des attributs de la métaclasse VerticalComponentRelationship Associations. Chaque élément de la relation est un composant de type Component. La relation a un sens. L un de ses côtés est un composé (WholeMember) et l autre coté un sous-composant (partmember) : wholemember : Component Extrémité de la relation jouant le rôle du Tout. partmember : Component Extrémité de la relation jouant le rôle de la Partie. Attributs. 95

108 Chapitre 4. Une approche pour la composition logicielle basée sur la relation Tout-Partie Vertical ComponentRelationship isencapsuled : Boolean shareable : ShareabilityKind isseparable : Boolean ismutable : Boolean lifedependency : LifeDependencyKind Fig Détail de la métaclasse VerticalComponentRelationship isencapsuled spécifie que le sous-composant de la relation est encapsulé par le composé. isglobalshared spécifie que le sous-composant de la relation est partageable globalement. islocalshared spécifie que le sous-composant de la relation est partageable localement. isseparable spécifie qu une instance du sous-composant de la relation peut-être séparée de son composé. ismutable spécifie que les instances du sous-composant en relation avec une instance du composé peut varier en nombre, mais aussi en type. Ce dernier point signifie que l on peut changer une instance de composant par une autre instance de composant. lifedependency spécifie le cycle de vie entre le composant et le composé Spécialisation de la métaclasse VerticalComponentRelationship Dans la section 4.1.5, nous avons identifié quatre types spécifiques de relation Tout-Partie. Nous les insérons dans le métamodèle sous la forme de quatre métaclasses, chacune héritant de la métaclasse VerticalComponentRelationship. La Figure 4.19 représente cette portion du métamodèle. Nous avons traduit les propriétés sous forme de stéréotypes. Cela permet de spécialiser aisément les métaclasses en fonction des stéréotypes. Toutes les relations implémentent les propriétés primaires : nature binaire, asymétrie au niveau des instances et antisymétrie au niveau des types. Elles sont définies sur la relation VerticalComponentRelationship. Les sous-types de relations de composition en héritent Contraintes Ocl Dans cette section, nous discutons des contraintes Ocl que nous appliquons au métamodèle afin de renforcer la syntaxe associée aux concepts de la composition verticale. Avant cela, nous donnons une description rapide du langage Ocl Le langage Ocl 96 Le langage Ocl est le langage de contraintes d Uml. À la base [Jos98], Ocl a été proposé pour : spécifier les invariants de classes et les types dans les diagrammes de classes ; spécifier le «type invariant» pour les stéréotypes ;

109 4.2. Définition d un métamodèle Uml pour la Cbse basé sur la relation Tout-Partie Vertical ComponentRelationship binary instance-asymmetry type-antisymmetry {disjoint} Lightweight Composition encapsuled global-sharing Strong Composition encapsuled global-unsharing Lightweight Aggregation global-sharing Strong Aggregation global-unsharing Fig Ajout des métaclasses spécialisant les différents types de relations Tout-Partie décrire les pré et post-conditions des opérations déclarées dans les diagrammes de classes ; décrire les gardes au sein des diagrammes d état-transition ; spécifier les chemins de navigation ; spécifier les contraintes des opérations Ocl décrites par l utilisateur. Sa syntaxe est similaire à celle des langages de programmation objet : le langage fournit des variables et des opérations pour construire les expressions et les contraintes. Le langage est fortement typé et définit des types classiques (Integer, Real, String, Boolean, ObjectType et EnumType) et des types collections (Set, Bag et Sequence). Ces derniers sont très importants et permettent de spécifier des propriétés, notamment sur des collections d objets, de manière déclarative. Ils sont paramétrés par un type T qui définit le type des éléments de la collection. Ces caractéristiques expriment une relation étroite avec la théorie des ensembles [Led02]. Expressions Ocl. Une expression Ocl est une application d une opération Ocl sur une constante, une variable ou une expression Ocl. Les expressions telles que les invariants, écrits dans le contexte d une classe, peuvent faire référence à une instance de cette classe en utilisant le mot clé self. L ensemble de toutes les instances effectives d une classe Class est dénoté Class.allInstances. Les expressions plus complexes peuvent être construites au moyen des appels d opérations et d une construction if then else endif. Le premier argument d un appel d opération dénote la valeur ou l objet cible à laquelle/auquel l opération est appliquée. Ceci s effectue en utilisant la notation où l expression cible suivie par un point «.», le nom de l opération et éventuellement les arguments supplémentaires dans une paire de parenthèses. L emboîtement des appels d opérations est possible. Les attributs de classes peuvent être accédés de la même manière. Si la cible d une opération est une valeur d une collection, une flèche «->» est utilisée au lieu du point. Pour plus de renseignements sur Ocl, cf. [OMG03c]. Contraintes Ocl. Le contexte d une opération Ocl est soit un classifier, soit une de ses opérations. Si le contexte spécifie un classifier, l expression de contrainte correspond à un invariant que toutes les instances du classifier doivent respecter. Si le contexte est une opération, l expression de contrainte justifie la pré/post-condition de l opération. 97

110 Chapitre 4. Une approche pour la composition logicielle basée sur la relation Tout-Partie Les invariants sont des conditions portant sur toutes les instances du classifier. Elles sont des conditions supplémentaires au sein d une classe que l on ne peut pas spécifier en utilisant les notations graphiques. Un invariant est accompagné d un contexte spécifiant le classifier auquel il s applique. Prenons par exemple une classe Person qui a un attribut age de type Integer. La contrainte ci-dessous traduit le fait que la valeur de l âge doit être supérieure à zéro. 1 context Person inv : 2 age > 0 La spécification d une pré ou post-condition a besoin d un contexte de type Classifier : :oper(...) :type- Retour, qui est composé d un classifier et de la signature de l opération Les contraintes Ocl associées au métamodèle Les propriétés de composition définies à la section 4.1 s appliquent au métamodèle présenté à la section [BHSPLB03] a défini des règles Ocl traduisant les propriétés de la relation Tout-Partie, en s appuyant sur le métaschéma proposé. Globalement, la sémantique des propriétés de composition que nous avons retenu est la même que celle des propriétés initiales. Aussi les règles Ocl que nous associons à notre métamodèle ne sont que des adaptations des règles définies initialement. Seul le contexte est différent puisqu elles ne caractérisent plus le monde général de la conception objet mais celui de la modélisation des compositions de composants, et donc ne s appuient pas sur le même métaschéma. L adaptation de ces règles à notre métaschéma n étant pas une contribution importante, dans le sens où nous n avons pas apporté de modifications significatives (hormis le contexte) à ces règles, nous les présentons en annexe A. Notons cependant une erreur dans les règles Ocl traduisant l irréflexivité et l antisymétrie ([BHSPLB03], page 463). Ces règles font référence au type correspondant au composé (respectivement au composant) en utilisant Whole (respectivement Part), qui est non défini. Pour accéder au type, il faut repartir de la relation et utiliser le lien partmember ou le lien wholemember. Les règles deviennent donc dans notre modèle : 1 context VerticalComponentRelationship inv I r r e f l e x i v i t e : 2 wholemember. compinstance >forall (w w. ocliskindof ( partmember ) 3 implies not w. part >i n c l u d e s (w) ) 4 5 partmember. compinstance >forall ( p p. ocliskindof ( wholemember ) 6 implies not p. whole >i n c l u d e s ( p ) ) Nous appliquons le même raisonnement sur la propriété d antisymétrie : 1 context VerticalComponentRelationship inv Antisymetrie : 2 wholemember. compinstance >forall (w w. ocliskindof ( partmember ) implies w. whole 3 >forall ( x w. part >i n c l u d e s ( x ) implies w = x ) ) 4 partmember. compinstance >forall ( p p. ocliskindof ( wholemember ) implies p. part 5 >forall ( x p. whole >i n c l u d e s ( x ) implies p = x ) ) 98

111 4.2.4 Résumé de l application à Uml du modèle de composition 4.3. Conclusion Dans cette section, nous avons présenté notre proposition de modification du métamodèle Uml pour prendre en compte notre modèle de composition. Nous préconisons la définition d une nouvelle relation spécifique à la composition de composants. Cela crée une spécialisation d Uml à ce problème ce qui présente comme avantage de s affranchir de l incohérence des concepts d agrégation-composition d Uml 1.x et de faciliter la future intégration de nos travaux à Uml 2.0. Notre proposition est axée sur la définition d une métaclasse représentant la composition hiérarchique, spécialisée en quatre sous-relations spécialisées en fonction des propriétés d encapsulation et de partageabilité. Elles sont elles-mêmes spécialisables selon un aspect dynamique. Ce dernier est en fait l application, pour la séparabilité et la mutabilité réunies, des implications qui les lient. Par rapport à la relation de composition initiale d Uml 1.x, le fait de pouvoir la spécialiser au niveau dynamique présente l avantage de pouvoir modéliser une relation à très fort couplage tant architectural que dynamique, ce qui n était pas le cas avant. Dans [BLB02], les auteurs disent même que : «le problème principal d Uml est l occultation de l immutabilité car la composition supporte la séparabilité, et par conséquent admet la mutabilité. Une question ouverte est donc de voir s il serait intéressant de proposer un sous-type de relation Tout-Partie possédant la propriété d immutabilité». Nous répondons à cette question par l affirmative. Nous justifions ce choix par la forme particulière de certains composants, en particulier les Cots pour lesquels une certaine QoS est exigée. Par exemple, le composant peut avoir à garantir qu il peut fournir un service à tout moment. Or, pour le cas où ce service est rendu par un de ses sous-composants, le composé doit garantir la présence permanente du sous-composant, ce que garantit notamment l immutabilité. Nous avons également, lorsque cela était possible, défini des règles Ocl formalisant les propriétés identifiées dans la section 4.1. Nous nous sommes cependant heurté à des problèmes liés principalement à la puissance d expression d Ocl. Celle-ci ne nous permet pas de définir des règles pour toutes les propriétés (par exemple, comment traduire la notion de contenance de l encapsulation). Un des moyens de pallier à cette lacune est d utiliser un langage plus expressif, notamment en codant «en dur» dans un outil les contraintes. 4.3 Conclusion Dans ce chapitre, nous avons présenté l approche sur laquelle nous nous appuyons pour donner une assise à la relation de composition au niveau conceptuel. Nous avons pour cela mené une étude sur l adaptation de la relation Tout-Partie à la composition conceptuelle. Puis nous avons décrit une proposition de modification du métamodèle Uml pour prendre en compte notre modèle de composition. Le modèle de composition que nous avons proposé est basé sur la définition d un métaschéma et de règles Ocl. Nous n avons pas cependant prouvé la complétude et la cohérence de ce modèle. Pour ce faire, deux approches sont possibles, par démonstration ou par construction : L approche par démonstration, est l approche classique utilisée dans le monde des méthodes formelles. Elle consiste à définir une spécification formelle du modèle et à démontrer à l aide de preuves sa cohérence et sa complétude. L intérêt de cette approche est qu elle est irréfutable, car le modèle est prouvé mathématiquement. Cependant, sa réalisation présente des difficultés. D une part, la spécification formelle est difficile à réaliser, notamment en Ocl. En effet, à notre connaissance, il manque des outils de spécification et d outils de preuves Ocl reconnus. D autre part, la réalisation de preuve est lourde à mettre en œuvre. 99

112 Chapitre 4. Une approche pour la composition logicielle basée sur la relation Tout-Partie L approche par construction, est l approche utilisée par les éditeurs de logiciels, par exemple. Elle consiste à implémenter le modèle. L implémentation implique notamment de résoudre les incohérences ou les approximations du modèle par des choix de réalisation. L idée est de dire que, si l implémentation fonctionne correctement, le modèle sous-jacent est correct, dans la limite de cette implémentation. Nous avons retenu l approche par construction. Nous justifions ce choix de la manière suivante. D une part, nous avons jugé l investissement pour la réalisation de l approche par par démonstration trop lourd compte tenu de notre base de départ. D autre part, l approche retenue nécessite l implémentation d outils ce qui est une solution en accord avec le cadre industriel de cette étude. Nous sommes toutefois conscients des limites de cette approche. D une part, l implémentation n a pas valeur de preuve formelle. Elle ne permet pas de prouver la complétude ni la cohérence du modèle, mais uniquement des parties du modèle qui sont implémentées. Dans la partie suivante, nous présentons l outillage réalisé dans le cadre de cette étude. Il se compose d un profil Uml, d un environnement contraint de composition et d une librairie permettant la vérification de contrats de composition. 100

113 Troisième partie Outillage appliqué à la composition 101

114

115 Introduction à l outillage La partie précédente a présenté les fondements de notre approche de la composition. Nous avons défini un modèle de composition basé sur la spécification de propriétés de composition. Ces propriétés ont un impact sur trois niveaux du développement d une application basée composants : architectural, dynamique, et comportemental. En fait les propriétés ont un impact direct sur les deux premiers niveaux : le niveau comportemental étant le résultat des spécifications sur ces deux niveaux. Afin d éprouver notre modèle et aussi de démontrer l utilité de notre approche, nous avons voulu fournir une chaîne d outillage implémentant nos propositions. Notre idée est d offrir un environnement de composition couvrant le cycle de développement d une application, et notamment les phases de conception, d assemblage et de vérification. Cet environnement repose sur trois outils, chacun traitant un niveau différent du Cbd. Le premier outil est un environnement graphique de modélisation Uml, étendant un environnement de modélisation existant (Objecteering), sous la forme d un profil Uml. Il implémente les concepts vus précédemment. Il permet notamment de vérifier la cohérence des propriétés de composition spécifiées sur les modèles. Nous le présentons dans le chapitre 5. Le second outil est un environnement contraint d assemblage et de déploiement de composants. Il permet de décrire des relations implémentant les propriétés de composition, entre les composants à déployer. Il offre également la possibilité d administrer dynamiquement les composants et les compositions de composants. Il garantit le respect des propriétés spécifiées d un point de vue architectural et dynamique. Nous le présentons dans le chapitre 6. Ces deux outils offrent ce que nous appelons des moyens de vérification a priori. Les capacités de vérification des modèles, par l environnement de modélisation, ainsi que les contraintes assurées sur les compositions déployés, par l environnement d assemblage, garantissent un premier niveau de vérification. Cela n est pas suffisant. En effet, la vérification comportementale n a pas été réalisée. D autre part, l expérience montre que, quelque soit le niveau de certification annoncé par un composant (i.e. les garanties de bon fonctionnement apportées par son fournisseur), il est fondamental de donner à son utilisateur la possibilité de le tester en situation dans son environnement de déploiement. Il est nécessaire pour un composant d être capable de montrer qu il correspond bien à sa spécification. Le troisième outil que nous proposons répond à ce besoin. Il permet de définir et de vérifier des contrats basés état. L équipe Aoc a pour cela développé une librairie Java permettant la mise en œuvre de tests intégrés au sein des composants, portant sur l évaluation de contrats. Cette librairie permet de définir et d évaluer des contrats sur le comportement externe des compositions. Les contrats testés garantissent le respect des propriétés spécifiées d un point de vue comportemental. Nous décrivons cette réalisation dans le chapitre 7. Ces trois outils sont schématisés à l aide du tableau 4.7. Cette chaîne d outillage offre des facilités pour supporter la construction d un système exécutable. Elle répond donc à la propriété de construction discutée dans la section Pour mémoire, cette propriété décrivait l importance de fournir un support complet pour la réalisation d un système. L autre aspect important, décrit dans cette même section, porte sur la cohésion du développement. Cette propriété caractérise le fait que des moyens sont mis en œuvre à chaque étape pour montrer la cohérence de l étape vis-à-vis de l étape précédente. Le profil que nous avons développé implémente des règles de vérification permettant de tester la validité des compositions conceptuelles. L environnement de déploiement assure la cohérence du déploiement vis-à-vis du modèle de conception de l application. Enfin, le développement de contrats de composition vérifie le respect du comportement de la composition. 103

116 Type de vérification a priori Niveau Outil Domaine de composition Conception profil Uml (WpcP) dynamique, architectural, comportemental Assemblage environnement de dynamique, architectural composition basé sur Jmx (WpcE) Vérification Test intégré de comportemental contrats basés état Approche utilisée Métamodèle et langage J Propriétés de composition codées par l outil Contrats décrits par Statecharts exécutables a priori a posteriori Tab. 4.7 Vue schématique de l outillage proposé 104

117 Chapitre 5 WpcP : un profil Uml dédié à la composition logicielle Sommaire 5.1 Définition et démarches Définition Éléments d un profil Uml Démarche d élaboration d un profil et éléments de description Notre proposition : le profil WpcP Domaine du profil Définition technique Définition opérationnelle Réalisation et exemple d utilisation Limites dues à l outil et choix techniques Exemple d utilisation Bilan du profil Un métamodèle couvre un domaine spécifique ayant un large champ d applications. Chaque domaine peut être décomposé en sous-domaines qui nécessitent un raffinement spécifique du métamodèle standard. Le métamodèle Uml tient compte de ce fait et fournit par défaut des mécanismes d extension (voir [OMG01c], p. 2-74). Ils permettent d adapter la sémantique d Uml sans en changer le métamodèle grâce au concept de profil. Dans ce chapitre, nous définissons un profil Uml dédié à la composition, que nous appelons WpcP (pour Whole-Part Composition Profile). Ce profil met en œuvre le métamodèle présenté à la section??. Ce chapitre est organisé comme suit. Nous présentons dans la section 5.1 les mécanismes d extension d Uml et le concept de profil. Nous définissons notre profil à la section 5.2. Nous donnons un exemple d utilisaiton à la section 5.3. Nous concluons sur cet outil à la section Définition et démarches La notion de profil Uml [OMG99b] est apparue dans le standard Uml 1.3. Il s agit d un ensemble prédéfini de mécanismes d extension pour un domaine, une technologie ou une méthodologie particulière. L infrastructure d Uml est définie par la librairie FoundationPackage. Le paquetage Core spécifie un 105

118 Chapitre 5. WpcP : un profil Uml dédié à la composition logicielle FoundationPackage Core Profiles Fig. 5.1 Lien entre le paquetage Core et les profils en Uml [OMG03b] métalangage qui peut être réutilisé pour définir un certain nombre de métamodèles, tels que Uml. Le paquetage Profiles dépend du paquetage Core, comme le montre la Figure 5.1. Il permet la modification d Uml en vue de la création de nouveaux langages basés sur le métalangage fournit par le paquetage Core. Notons qu un profil est principalement conçu pour étendre Uml mais qu il peut aussi permettre d implémenter un métamodèle basé sur le paquetage Core ([OMG03b], p. 25) Définition La définition d un profil Uml, donné par le lexique d Uml, est la suivante ([OMG03b], page 14) : «a stereotyped package that contains model elements that have been customized for a specific domain or purpose using extension mechanisms, such as stereotypes, tagged definitions and constraints. A profile may also specify model libraries on which it depends and the metamodel subset that it extends». Un ensemble cohérent d extensions est alors appelé profil. Il peut être vu comme une spécification qui spécialise un ou plusieurs métamodèles standards appelés métamodèles de référence. Le profil est alors dédié à un domaine spécifique de ces modèles de référence. La Figure 5.2 illustre le positionnement des profils dans l architecture Mof. Les profils spécialisent des métamodèles standards au niveau M2 (Uml ou Cwm [OMG01a]) et sont utilisés par les modèles du niveau M1. Uml-Rt [OMG03e], Edoc [OMG02b] et Olap ([OMG01a], page 14-1) sont des profils standards, c est-à-dire définis par l Omg. Dans le schéma, MonProfil représente un profil défini par un utilisateur quelconque. Nous nous intéressons, dans la suite de ce chapitre, aux profils Uml. Les différents éléments structurant un profil sont décrits dans la section suivante Éléments d un profil Uml Les mécanismes d extension d Uml sont décrits comme une partie de la spécification Uml ([OMG01c], pp 2-74). Ils incluent les notions de stéréotype, de valeur marquée et de contrainte. Notons que nous les illustrons avec des éléments de notre profil. Ces éléments sont décrits et justifiés à la section 5.2 : 106 un élément de type stéréotype est un moyen permettant de classifier un élément d un modèle. Il permet aux outils Uml d identifier un élément spécifique d un modèle et de lui appliquer un processus particulier. Par exemple, dans le profil Corba, un composant Corba [OMG01b] est décrit par une classe Uml stéréotypée par «CORBAComponent».

119 5.1. Définition et démarches Métamétamodèle (M3) Mof Métamodèle (M2) Uml Cwm autre standards Uml-Rt Edoc Olap Profils standards MonProfil Profils d utilisateurs terminaux Modèles (M1) Objets (M0) Fig. 5.2 Les profils vis-à-vis de l architecture Mof [OMG99b] un élément de type valeur marquée spécifie la valeur étiquetée qui peut être attachée à un type d élément du modèle. Toujours dans le profil Corba, la valeur marquée islocal de type Boolean, est applicable à un élément de type CORBAInterface. Elle indique si une interface Idl est locale ou non. un élément de type contrainte permet à un utilisateur de raffiner et de spécifier de nouvelles significations pour tout élément du modèle. Voici un exemple de contrainte du profil Corba : 1 // A l l non n a v i g a b l e near AssociationEnds o f a s t e r e o t y p e Class 2 // <<CORBAUserDefinedType>> must have a t a r g e t S c o p e " i n s t a n c e ". 3 s e l f. nonnavigablenearends. t a r g e t S c o p e = # i n s t a n c e Éléments sélectionnés du métamodèle de référence Un profil précise les éléments du métamodèle 28 qu il spécialise. Les autres éléments du métamodèle sont toujours accessibles. Par exemple, Edoc spécialise, et donc sélectionne, les éléments de modélisation statiques du métamodèle d Uml, mais pas les éléments des Use Case. 28 dans cette section, lorsqu on parle du métamodèle on entend le métamodèle de référence à partir duquel est bâti le profil. 107

120 Chapitre 5. WpcP : un profil Uml dédié à la composition logicielle Les stéréotypes Un stéréotype est défini pour une métaclasse spécifique du métamodèle 29. Dans un profil Uml, le stéréotype crée une métaclasse Uml virtuelle basée sur la métaclasse Uml existante. Il fournit ainsi le moyen de classer les instances de cette métaclasse de base, et peut également spécifier des contraintes additionnelles ou des valeurs marquées requises. Par exemple, dans notre profil, le stéréotype «WPCPcomponent» étend la métaclasse Uml Class. Lorsque ce stéréotype est appliqué à une instance de Class, il la contraint à ne pas être une simple classe objet, mais un composant conceptuel Les valeurs marquées La sémantique d une valeur marquée est définie pour une métaclasse spécifique du métamodèle 30. La définition d une valeur marquée contient son nom, son type, la description de son rôle et des contraintes s appliquant à chaque valeur correspondante. Comme mécanisme d extension d Uml, la valeur marquée agit comme un attribut d une métaclasse Uml, permettant ainsi l attachement arbitraire d informations à une instance. Un ensemble de valeurs marquées peut être associé à un stéréotype afin d être appliqué aux éléments de modélisation portant sur ce stéréotype. Par exemple, isencapsuled est une valeur marquée associée au stéréotype «VCR» de la métaclasse Relationship. Elle peut prendre deux valeurs (true ou false) pour caractériser le fait que la relation supporte la propriété d encapsulation Les contraintes Les contraintes peuvent être définies sur n importe quel élément Uml, mais plus particulièrement, dans le cadre d un profil, sur une métaclasse ou un stéréotype particulier. Elles permettent de spécialiser davantage la sémantique des éléments du métamodèle utilisés dans ce profil. Cette spécification est écrite soit en langage naturel, soit sous la forme d une expression Ocl. Lorsque les contraintes sont associées à un stéréotype, elles ne s appliquent qu à des éléments de modélisation classés par ce stéréotype Les descriptions Les sémantiques du profil et des éléments contenus dans le profil peuvent être également spécifiées par des descriptions en langage naturel, afin de décrire plus précisément ces éléments. Par exemple, les objectifs d un profil et sa compatibilité avec d autres profils devraient être ainsi décrits en détail La notation La notation d Uml peut être personnalisée par les mécanismes des profils : définition d icônes associées aux stéréotypes (Par exemple, on peut créer l artefact représentant un composant en Uml 2.0 en créant un stéréotype «WPCPcomponent» à partir de la métaclasse Class. On peut alors associer l icône représentant les composants à ce stéréotype) ; 29 Plusieurs métaclasses peuvent avoir un stéréotype de même nom, mais il s agit bien de stéréotypes différents tout de même. 30 Comme pour les stéréotypes, deux définitions de valeurs marquées ayant le même nom peuvent exister dans un même profil à condition de faire référence à des métaclasses différentes. 108

121 5.1. Définition et démarches disposition pour les diagrammes (par exemple, règles de placement de certains éléments sur les diagrammes) ; capacités de filtrage (par exemple, affichage des seuls éléments publics) fournis au travers du mécanisme des règles Les règles Les profils doivent être capables de définir des règles dédiées au domaine spécifique qu ils concernent. Elles peuvent être de différents types dont, par exemple, les suivants : Règles de transformation : elles expriment comment un modèle peut être transformé vers un but spécifique. Par exemple, le profil Corba exprime comment un modèle Uml peut être transformé en une implémentation Corba. Certaines règles de transformation automatisent le développement de certains types d activités (génération de code, patrons de conception par exemple) ; Règles de validation : elles vérifient que le modèle possède bien les propriétés souhaitées. Ces règles vérifient les critères de cohérence du modèle. Elles peuvent être exprimées à l aide de contraintes ou de tout autre mécanisme. On les appelle les Well-formedness rules 31 ; Règles de présentation : elles définissent quels types d éléments de modélisation doivent apparaître dans quels types de diagrammes et indiquer aussi quelles informations doivent être cachées. Élements Extensions Règles de Validation Règles de Présentation Règles de Transformation Package, Classe, Use Case Stereoype : «Business_Object» (Class). Tagged Value : {analysis}. Métrique : 10 classes max par paquetage ; 10 opérations max par classe Tous les acteurs doivent coopérer avec au moins un Use Case. Détection des objets sans classe, des messages sans opération. Diagramme de classes et de Use Case. Seules les opérations publiques sont affichées. Visualisation particulière des classes Business_Object. Plan type de documentation. Complétion automatique des diagrammes. Tab. 5.1 Exemple de contenu d un profil d analyse [Sof99] Le tableau 5.1 donne un exemple de contenu d un profil d analyse [Sof99]. Le profil porte sur les éléments Package, Classe, Use Case. Il définit un stéréotype : «Business_Object» sur la métaclasse Class, et une valeur marquée : {analysis}. Il définit ensuite des règles de validation, de présentation et de transformation. De nombreux autres mécanismes relatifs aux profils sont détaillés dans [OMG01c]. Ils concernent plus les relations entre différents profils que leur caractérisation. On peut citer : généralisation ou héritage entre profils, dépendance d importation, compatibilité entre profils, sélection de profils, échange de profils ou encore regroupement de profils. L objectif de notre profil étant prioritairement d illustrer la faisabilité et l intérêt de notre modèle de composition, nous n abordons pas ces notions particulières. 31 Nous francisons Well-formedness rules par l expression règles de bonne écriture. 109

122 Chapitre 5. WpcP : un profil Uml dédié à la composition logicielle Démarche d élaboration d un profil et éléments de description La définition d un profil Uml suit généralement les processus suivants : 1. identifier les sous-ensembles des classes du métamodèle Uml qui seront incluses dans le profil ; 2. pour chaque classe, identifier une classe de base dans le sous-ensemble du métamodèle Uml qui, une fois stéréotypée de manière appropriée, jouera le rôle de la classe du métamodèle ; 3. pour chaque attribut et association du métamodèle, définir un moyen de les traduire. Les attributs, pour lesquels aucun métaattribut du sous-ensemble du métamodèle Uml ne correspond, peuvent être simulés avec la création d une valeur marquée. La plupart des associations ont une association analogue dans le métamodèle Uml ; 4. pour les éléments du sous-ensemble du métamodèle Uml qui ont un lien possible (mapping) avec des concepts du métamodèle à transformer, mais qui ne sont pas directement utilisés pour l émulation, montrer comment ils sont reliés aux concepts du métamodèle ; 5. donner des contraintes additionnelles aux éléments du métamodèle Uml qui sont impliquées par l utilisation du profil ; 6. définir des notations (icônes) pour les concepts du métamodèle représentés par des stéréotypes. Les quatre éléments de description d un profil sont les suivants [ACC02b] : le domaine du profil : la description du profil passe par la description du domaine auquel le profil est rattaché. Celle-ci peut se faire en définissant le métamodèle du domaine. La description du profil peut se contenter de référencer le domaine ; la définition technique du profil : techniquement, un profil n est qu un ensemble de stéréotypes, valeurs marquées et contraintes. Ces éléments permettent d établir une correspondance entre les concepts Uml et les concepts du domaine représentés par le profil. Il est important de noter qu en principe seule cette partie suffit à définir un profil selon le standard Uml ; la partie opérationnelle du profil : concrètement, un profil ne peut se résumer uniquement à la seule définition technique. C est aussi et surtout un ensemble de règles qui permettent de rendre le profil opérationnel. Par exemple, le profil Ejb contient un ensemble de règles pour générer automatiquement le code Java correspondant et les fichiers de déploiement. Cette partie, qui n est pas clairement identifiée dans la définition classique de profil Uml, est fondamentale car elle enrichit considérablement le profil. Elle le fait passer d une simple extension graphique à une notation ayant une signification plus précise que le métamodèle initial ; un exemple d utilisation du profil : tous les documents de description de profil que nous avons étudiés présentent des exemples. Un exemple, qui a un but pédagogique, est plus que nécessaire dans la description d un profil. 5.2 Notre proposition : le profil WpcP Dans cette section, nous décrivons notre profil Uml, nommé WpcP. Il implémente le métamodèle défini à la section 4.2. Un profil s appuie sur une version stable d un métamodèle. Nous avons défini ce profil à partir de la dernière version stable d Uml à ce jour, c est-à-dire Uml 1.5. Nous décrivons en premier le profil, puis nous donnons un exemple de son application à l aide de l outil Objecteering/Profile Builder. 110

123 5.2. Notre proposition : le profil WpcP Domaine du profil Ce profil permet de modéliser en Uml la composition hiérarchique, sur un même nœud de déploiement. Le métamodèle de référence est consultable à la section Définition technique Nous décrivons ici les stéréotypes et les valeurs marquées du profil. Les contraintes liées aux stéréotypes n y sont pas décrites. Pour les consulter, voir la section A.1. Le profil est écrit en respectant le formalisme défini dans [OMG99b]. Le détail du profil est donné en Annexe C, page Diagramme d application Dans notre approche, nous traitons de composants de spécification, et de leurs instances. Nous utilisons pour les représenter deux types de diagramme de classe spécifiques. Le premier, que nous appelons Dtc (Diagramme de Types de Composants), modélise l architecture d un point de vue types. Le second, que nous appelons Dic (Diagramme d Instances de Composants), instancie le Dtc et donc représente l architecture d un point de vue instances. Dans Uml 1.x, les composants s utilisent dans les diagrammes d implémentation (diagrammes d instance et de déploiement). Ils ne peuvent être utilisés au niveau diagramme de classe. Dans la section 4.2, le composant est décrit comme une métaclasse pouvant établir des relations de composition. Nous ne pouvons réutiliser la métaclasse component au niveau du profil. En effet, les Dtc et les Dic sont une spécialisation du diagramme de classe. En conséquence, nous ne pouvons utiliser dessus des composants. La solution consiste à créer un stéréotype héritant de la métaclasse Class traduisant la notion de composants et d instances de composants. Cette approche n est pas pénalisante vis-à-vis de l adaptation future de notre profil à Uml 2.0. En effet, il suffira alors d utiliser directement le métatype component défini par Uml 2.0 au lieu du stéréotype Les stéréotypes Comme expliqué dans la section précédente, nous avons donc créé pour représenter un composant au niveau conceptuel, un stéréotype «WPCPComponent», spécialisation de la métaclasse Class afin de pouvoir l instancier dans le diagramme de classe. Nous avons fait de même pour le stéréotype «WPCP- CompInstance». Les stéréotypes «VCR», «SCOMP», «LCOMP», «SAGG» et «LAGG» sont des spécialisations de la métaclasse Relationship. Notons qu ils sont de même niveau car on ne peut avoir de hiérarchisation des stéréotypes. Enfin, nous avons créé les stéréotypes «Whole» et «Part» afin de pouvoir caractériser les extrémités de la relation. Le tableau 5.2 récapitule les stéréotypes Les valeurs marquées Les valeurs marquées représentent les métaattributs du métamodèle. Dans notre modèle, seules la métaclasse VerticalComponentRelationship et les métaclasses héritant de celle-ci, possèdent des attributs. Le tableau 5.3 présente les valeurs marquées. 111

124 Chapitre 5. WpcP : un profil Uml dédié à la composition logicielle Nom de l élément dans le métamodèle Component CompInstace VerticalComponent- Relationship Strong Composition Lightweight Composition Strong Aggregation Lightweight Aggregation wholemember partmember Nom du stéréotype «WPCPComponent» Classe Uml de base Class «WPCPCompInstance» Class «VCR» «SCOMP» «LCOMP» «SAGG» «LAGG» «Whole» «Part» Relationship Valeurs marquées Relationship isencapsuled = true, shareable = globalunsharing Relationship isencapsuled = true, shareable = globalsharing Relationship isencapsuled = false, shareable = globalunsharing Relationship isencapsuled = false, shareable = globalsharing AssociationEnd AssociationEnd Tab. 5.2 Liste des stéréotypes du profil Notations graphiques La relation VerticalComponentRelationship n est ni une agrégation ni une composition au sens Uml 1.x. Pour ne pas introduire d ambiguïté, nous ne pouvons pas utiliser les icônes avec losange blanc et losange noir. Nous utilisons donc la notation définie dans [BHSPLB03]. Celle-ci utilise une nouvelle icône sous la forme d un losange en pointillé Définition opérationnelle Dans cette section, nous décrivons les règles et le processus d utilisation du profil. Le processus que nous préconisons pour utiliser ce profil est constitué de deux étapes. La première consiste à définir l architecture et les règles de composition de l application. Elle ne manipule que des types de composants. La seconde consiste à spécifier la sous-architecture des instances de composants. Les définitions sont données en langage naturel. Règle 1 : Un Diagramme de Types de Composants (Dtc) ne peut pas contenir d instances de composants, et un Diagramme d Instances de Composants (Dic) ne peut pas contenir de types de composants : Règle 2 : Une relation Tout-Partie doit avoir un rôle de type wholemember et un de type partmember. Elle doit être binaire. Règle 3 : Un Dtc correspond à un et un seul Dic. Règle 4 : Lorsqu un Dtc a été défini, il faut tester que les relations ne sont pas contradictoires par rapport aux règles de composition. 112

125 5.3. Réalisation et exemple d utilisation Métaattribut Type Valeurs possibles Commentaire isencapsuled Boolean true ou false spécifie l encapsulation du souscomposant par le composé. isglobalshared Boolean true ou false spécifie le type de partage global sur la relation. islocalshared Boolean true ou false spécifie le type de partage local sur la relation. isseparable Boolean true ou false spécifie la séparabilité ismutable Boolean true ou false spécifie la mutabilité lifedependency lifedependency- Kind (1-9) La sémantique de ces valeurs correspond au rang dans la Figure 4.11, la valeur 1 signifie la dépendance existentielle Tab. 5.3 Liste des valeurs marquées du profil 5.3 Réalisation et exemple d utilisation Nous avons développé notre profil avec le module Profile Builder d Objecteering, un outil Uml développé par la société Softeam 32. Il existe de nombreux environnements de modélisation Uml, ainsi que de nombreuses études comparatives entre ces outils 33. Il n existe malheureusement pas d environnement universel offrant toutes les fonctionnalités utiles. À notre connaissance, Objecteering est le seul logiciel offrant une extension permettant le développement de profils Uml. De plus, Softeam fait partie des entreprises co-fondatrices d Uml ; elle a d ailleurs été chargée de l évaluation du concept de profil. Ces raisons justifient le choix d Objecteering Limites dues à l outil et choix techniques La version d Objecteering Profil Builder sur laquelle nous avons travaillé implémente uniquement le métamodèle Uml 1.4. Nous avons donc été contraint à des adaptations de notre métamodèle pour pouvoir utiliser l outil. Objecteering ne permet pas d implémenter de règles Ocl, aussi bien lors de la définition d un modèle que lors de celle d un profil. Les contraintes sont définies textuellement et ne peuvent pas être exécutées. Cependant, il est possible lors de la création du profil avec l outil Profil Builder de définir des contraintes dans le langage J, qui est le langage propriétaire d Objecteering. Il convient donc de traduire les contraintes Ocl dans ce langage. [ZTJ02] relève cette limitation et propose de traduire les règles Ocl en méthodes J à l aide d un compilateur. À notre connaissance, ce type de compilateur n existe pas. Une autre manière de pallier à ce problème, est d utiliser les fonctionnalités d export des modèles au format Xmi (XML Metadata Interchange) [OMG02c]. Xmi est une extension de XML (Extensible Markup Language), proposée par l Omg, qui définit un standard pour l échange des métadonnées. Le modèle pourra alors être importé dans un environnement proposant un compilateur Ocl. L exemple de code ci-dessous est une traduction possible de la règle 3 en langage J. Le premier if vérifie que la relation est binaire. Le second On peut par exemple consulter une liste sur 113

126 Chapitre 5. WpcP : un profil Uml dédié à la composition logicielle vérifie que les deux membres de la relation sont de même type et que ce type est WPCPComponent ou WPCPCompInstance. 1 boolean A s s o c i a t i o n : : checkrolesofrelation ( ) { 2 // Check r e l a t i o n s h i p s i z e 3 i f ( ConnectionAssociationEnd. s i z e! = 2 ) { 4 StdOut. write ("ERROR on ", Name, " r e l a t i o n s h i p A Composition r e l a t i o n s h i p must be binary : ", NL) ; 5 r e t u r n f a l s e ; } 6 i f (! ( ( ( wholemember. E x t e n s i o n S t e r e o t y p e. Name=="WPCPComponent") 7 && (partmember. E x t e n s i o n S t e r e o t y p e. Name=="WPCPComponent") ) 8 ( ( wholemember. E x t e n s i o n S t e r e o t y p e. Name=="WPCPCompInstance") 9 && (partmember. E x t e n s i o n S t e r e o t y p e. Name=="WPCPCompInstance") ) ) ) { 10 StdOut. write ("ERROR on ", Name, " r e l a t i o n s h i p both e x t r e m i t i e s must have same type ( components or i n s t a n c e s o f component ) ", NL) ; 11 r e t u r n f a l s e ; } 12 r e t u r n t r u e ; } D autre part, l outil oblige, pour définir un stéréotype, de le rattacher à un élément non abstrait du métamodèle Uml. Dans notre métamodèle de composition, la relation VerticalComponentRelationship hérite de la métaclasse Relationship qui est abstraite. Nous ne pouvons donc pas implémenter cet héritage sous l outil. Nous avons donc choisi d étendre la métaclasse Association, puisqu elle hérite de la métaclasse Relationship elle aussi. Pour ne pas interférer avec cette métaclasse, nous avons contraint en langage J le stéréotype correspondant pour qu il ne puisse pas implémenter un certain nombre de concepts propres à la métaclasse Association tels que la spécialisation de la relation en agrégation ou en composition. D un point de vue graphique, il n est pas possible d associer une icône à une association. La notation graphique impose donc la présence des stéréotypes «whole» et «part» sur le lien d association pour : différencier visuellement une relation Tout-Partie d une simple association ; donner visuellement le sens hiérarchique de la relation Tout-Partie. D un point de vue nommage, nous avons choisi de ne pas respecter exactement notre métamodèle. La raison principale est que l utilisation de stéréotypes surcharge les diagrammes. Nous avons donc raccourci certains noms pour qu ils prennent moins de place sur les diagrammes. Le tableau 5.4 résume ces raccourcis. Noms dans le métamodèle Noms correspondants dans le profil VerticalComponentRelationship «VCR» partmember «part» wholemember «whole» Tab. 5.4 Raccourcis de nommage du profil Exemple d utilisation Nous avons réalisé le modèle conceptuel de l étude de cas de la machine à café. Cette section donne la description de sa conception en utilisant notre profil. 114

127 5.3. Réalisation et exemple d utilisation Création du Dtc Le Dtc modélise quatre composants : CoffeeMachine, Coiner, DrinkMaker et E-Money. Pour ce faire, nous créons quatre classes que nous spécialisons avec le stéréotype «WPCPComponent». Il faut ensuite définir les relations entre ces composants. Pour cela, il est nécessaire de créer une association entre deux composants. Ensuite, à l aide de la fenêtre de propriété de l association, il faut sélectionner le stéréotype correspondant à la relation de composition voulue. Notons que la sélection d un stéréotype ne permet pas de positionner automatiquement les valeurs marquées correspondantes au sous-type de relation. Nous avons donc développé une commande en langage J affectant automatiquement les valeurs marquées en fonction de la relation spécifiée. L exemple de code suivant montre une partie de cette commande. Cette partie traite le cas de la relation de type «SCOMP». Elle ajoute à la relation les valeurs marquées isencapsuled et isglobalshared ayant respectivement pour valeur true et false. Enfin, le concepteur peut ajouter des valeurs marquées aux relations afin de spécifier de propriétés complémentaires. 1 i f ( this. E x t e n s i o n S t e r e o t y p e. Name=="SCOMP") { 2 pparameterlist. add(" t r u e ") ; 3 sessionbegin ( " A s s o c i a t i o n ", t r u e ) ; 4 this. createandaddtaggedvaluewithparams ( " ", " isencapsuled ", pparameterlist, " " ) ; 5 pparameterlist. clear ( ) ; 6 pparameterlist. add(" f a l s e ") ; 7 this. createandaddtaggedvaluewithparams ( " ", " i s G l o b a l S h a r e d ", pparameterlist, " " ) ; 8 sessionend ( ) ; 9 } Une fois le modèle spécifié, le concepteur exécutera une deuxième commande qui teste la validité du modèle vis-à-vis du modèle de composition. La Figure 5.3 montre une capture d écran du modèle généré avec notre profil. DrinkMaker est un composant spécifique de CoffeeMachine. Il n a aucun lien avec les autres composants dans l application. Nous avons donc spécifié que seul CoffeeMachine pouvait y accéder. DrinkMaker est donc encapsulé dans CoffeeMachine. Pour assurer le fait que seul le Tout puisse y accéder, la propriété d exclusion globale a été spécifiée. De même, comme ce composant ne peut servir qu à un seul composant CoffeeMachine, la propriété d exclusion locale vient renforcer cette idée. Pour assurer la continuité du service, le composant doit être existant de manière permanente. Il ne doit donc pas être séparable du Tout. Cela implique sa dépendance existentielle. Le cas de Coiner est différent. En effet, dans le cadre de notre étude de cas, le composant CoffeeMachine est couplé avec une interface utilisateur et un mécanisme de porte-monnaie électronique. Nous choisissons ici de rendre la relation CoffeeMachine - Coiner non partageable globalement et d encapsuler Coiner dans CoffeeMachine. Le composant CoffeeMachine doit dépendre existentiellement du Coiner car on ne veut pas que la destruction du Coiner permette l utilisation libre de CoffeeMachine. Enfin, la relation E-Money - Coiner est définie. Coiner n est pas encapsulé et la relation est partageable globalement Création du Dic Une fois le Dtc créé et vérifié, le concepteur spécifie l application en terme d instances de composants, et vérifie que ce modèle est bien cohérent avec le Dtc. Cela est dû à l outil qui n instancie pas automatiquement le Dtc en Dic. Les relations entre les instances de composants doivent être de même 115

128 Chapitre 5. WpcP : un profil Uml dédié à la composition logicielle <<SCOMP>> CM-DM { isseparable(false) ismutable(false) lifedependency(1) isencapsuled(true) isglobalshared(false) islocalshared(false) } <<Whole>> <<WPCPComponent>> CoffeeMachine <<Whole>> <<SCOMP>> CM-C { isencapsuled(true) isglobalshared(false) islocalshared(false) lifedependency(1) } 1 <<Part>> <<Part>> 1 <<WPCPComponent>> DrinkMaker <<WPCPComponent>> E-Money <<Whole>> <<Part>> <<LAGG>> BK-C { isencapsuled(false) isglobalshared(true) } <<WPCPComponent>> Coiner 1 Fig. 5.3 Dtc généré avec le profil Wpcp type que celles spécifiées précédemment. En premier lieu, il convient de créer les instances de composants. Le nombre d instances d un même type de composant dépend des relations qui ont été spécifiées. Par exemple, la relation entre CoffeeMachine et Coiner est de type SCOMP. Cela implique les propriétés d encapsulation et d exclusion globale. Or, le composant E-Money est également en relation avec Coiner. La non partageabilité globale dans ce cas implique l existence de deux instances de Coiner : une (Coiner1 :Coiner) en relation avec l instance de CoffeeMachine, l autre (Coiner2 :Coiner) en relation avec l instance de E-Money. DrinkMaker est seulement en relation avec CoffeeMachine, donc cela ne nécessite qu une seule instance. Une fois les instances créées, les relations doivent être spécifiées. Dans cet exemple, une relation de type SCOMP est créée entre :DrinkMaker et :CoffeeMachine, et une autre entre Coiner1 :Coiner et :CoffeeMachine. Enfin, une relation de type LAGG est créée entre Coiner2 :Coiner et :CoffeeMachine. La Figure 5.4 montre une capture d écran du modèle généré avec notre profil. Lorsque le Dic est terminé, il est nécessaire de vérifier sa cohérence avec les éléments du Dtc correspondant. Le code suivant montre une partie de la méthode réalisant ce test. Il regarde si les instances de composants correspondent bien à un composant existant défini dans le Dtc. 116

129 5.3. Réalisation et exemple d utilisation <<WPCPCompInstance>> :CoffeeMachine {referedtype(coffeemachine)} <<SCOMP>> :CM-DM { referedtype(cm-dm) } <<Part>> <<Whole>> <<Whole>> <<SCOMP>> :CM-C <<Part>> { referedtype(cm-c) } <<WPCPCompInstance>> :DrinkMaker {referedtype(drinkmaker)} <<WPCPCompInstance>> Coiner1:Coiner {referedtype(coiner)} <<WPCPCompInstance>> :E-money {referedtype(e-money)} <<Whole>> <<LAGG>> :E-C { referedtype(e-c) } <<Part>> <<WPCPCompInstance>> Coiner2:Coiner {referedtype(coiner)} Fig. 5.4 Dic généré avec le profil Wpcp 1 String strcomptype ; 2 this. TagTaggedValue { 3 // Get t h e t y p e o f t h e component i n s t a n c e 4 i f ( DefinitionTagType. Name == " referedtype ") { 5 getparameters ( ) { 6 strcomptype = Value ; 7 } 8 } else { 9 // no t y p e e x i s t i n g 10 StdOut. write ( " ERROR No r e f e r e d type f o r : ", InstanceToCheck. Name, NL) ; 11 r e t u r n f a l s e ; 12 }} 13 // i s t y p e d e f i n e d in t h e DTC 14 getallcomptypeelt ( ) { 15 i f ( strcomptype == Name) 16 r e t u r n t r u e ; 17 else 18 r e t u r n f a l s e ; La deuxième étape de la vérification consiste à évaluer la cohérence du Dic vis-à-vis des propriétés de composition du Dtc. Nous avons pour cela réalisé une commande en langage J, implémentant les contraintes sur les propriétés. Le code ci-dessous montre la traduction de l axiome whole en langage J. Pour mémoire, pour une relation Tout-Partie donnée, l axiome whole retourne pour chaque instance de composant Partie d une relation, l ensemble des instances de composants Tout. 117

130 Chapitre 5. WpcP : un profil Uml dédié à la composition logicielle 1 Class [ ] Class : : whole ( i n A s s o c i a t i o n wpr ) { 2 Class [ ] Whole ; 3 String CurrentType = this. gettype ( ) ; 4 String strrelationtype = wpr. gettype ( ) ; 5 PartAssociationEnd { 6 i f ( strrelationtype == R e l a t e d A s s o c i a t i o n. gettype ) { 7 R e l a t e d A s s o c i a t i o n. ConnectionAssociationEnd { 8 i f ( E x t e n s i o n S t e r e o t y p e. Name=="Part ") { 9 i f ( OwnerClass. gettype! = CurrentType ) { 10 Whole. add( OwnerClass ) ; 11 }}}}} 12 r e t u r n Whole ; } Le code suivant montre l évaluation de la propriété d exclusion locale en langage J. L ensemble des relations de composition est parcouru à l aide de la méthode getallwprattypelev. Pour chacune, le composant Partie est isolé à l aide de la méthode partmember. Toutes ses instances sont récupérées à l aide de la méthode getinstancesof. Sur chaque instance, la méthode whole est utilisée. 1 boolean StaticClassDiagram : : CheckLocalSharing ( ) { 2 Class [ ] P a r t I n s t a n c e s ; 3 Class PartType ; 4 A s s o c i a t i o n C u r r e n t A s s o c i a t i o n ; 5 6 getallwprattypelev{ 7 C u r r e n t A s s o c i a t i o n = this ; 8 i f ( i s P r o p e r t y S e t t e d (" i s L o c a l S h a r e d "," f a l s e ") ) { 9 PartType = partmember ( ) ; 10 PartType{ 11 g e t I n s t a n c e s O f ( PartType. Name, P a r t I n s t a n c e s ) ; 12 } 13 P a r t I n s t a n c e s { 14 i f ( whole ( C u r r e n t A s s o c i a t i o n ). s i z e >1){ 15 StdOut. write ("ERROR Local S h a r a b i l i t y non r e s p e c t e d on ", C u r r e n t A s s o c i a t i o n. Name, NL) ; 16 }}}}} 5.4 Bilan du profil Les profils Uml permettent de spécialiser le métamodèle Uml. En cela, ils créent des moyens de modélisation spécifiques à un domaine donné. Nous avons défini le profil WpcP pour réaliser le métamodèle de composition défini à la section 4.2. Nous l avons implémenté via le module Profile Builder du logiciel Objecteering. Cette implémentation a nécessité d adapter légèrement le métamodèle à l outil, à cause de problèmes techniques. Cependant, le résultat obtenu permet d utiliser opérationnellement les concepts définis via un outil graphique. Nous avons utilisé avec succès cet outil pour modéliser notre étude de cas. Le profil et le code J sont donnés en annexe. Le profil est téléchargeable à l adresse : http :// belloir/. L intérêt de cet outil est double. D une part, il offre un support graphique pour modéliser les concepts de notre modèle de composition. L utilisation d un profil, par rapport à un formalisme graphique indépen- 118

131 5.4. Bilan du profil dant, présente l avantage de garder les concepts et les éléments graphiques du langage Uml et d ajouter ses propres concepts. D autre part, il permet de vérifier la cohérence du modèle spécifié par rapport au modèle de composition, assurant ainsi un premier niveau de vérification dans le cycle de développement. 119

132 Chapitre 5. WpcP : un profil Uml dédié à la composition logicielle 120

133 Chapitre 6 Environnement de composition Java pour un déploiement de composants rigoureux Sommaire 6.1 Vers un assemblage contraint des composants logiciels : l environnement WpcE Un environnement de composition spécifique Pilotage de composants L environnement Jmx Présentation de Jmx Le service de relation Jmx Environnement de composition Java pour un développement rigoureux Construction de relations Tout-Partie Implémentation de la relation Tout-Partie Exemple d utilisation Bilan du chapitre Dans la pratique, la conformité des logiciels développés par rapport aux modèles de conception correspondants n est malheureusement pas assurée systématiquement. Le Cbd ne déroge pas à cette règle. Une des raisons à cela est que les environnements d assemblage et de déploiement n offrent pas les moyens d exprimer la totalité des concepts spécifiés au niveau modèle. L inverse est également vrai. Dans ce chapitre, nous discutons de l approche que nous préconisons pour pallier à cette déficience, dans le cas particulier de notre modèle de composition : l équipe Aoc a développé [Fab03, BR04] un environnement de pilotage de composants, nommé WpcE, permettant d implémenter, au niveau déploiement, les concepts spécifiés au niveau modèle. Le développement de cet environnement a été d abord guidé par un besoin pragmatique. Nous l avons utilisé pour implémenter et manipuler des relations Tout-Partie, afin d observer l impact des propriétés de composition sur ces relations. Dans un deuxième temps, nous avons constaté l utilité d un environnement de ce genre pour le déploiement d application, et nous l incluons donc comme partie prenante intégrale dans notre proposition. Dans ce chapitre, nous présentons notre proposition pour un environnement de composition à la section 6.1. En premier lieu, nous décrivons notre approche et la justifions. Puis, nous présentons brièvement la technologie Jmx, à la section 6.2, sur laquelle nous nous appuyons. Une présentation plus complète 121

134 Chapitre 6. Environnement de composition Java pour un déploiement de composants rigoureux est disponible en annexe B. Nous décrivons ensuite l environnement de composition que nous avons développé, à la section 6.3, et nous l illustrons à travers l exemple de la machine à café à la section 6.4. Enfin, nous présentons un bilan du chapitre à la section Vers un assemblage contraint des composants logiciels : l environnement WpcE À la manière des applications distribuées, l arrivée de nouvelles technologies amène l apparition d une nouvelle couche de niveau d abstraction supérieur. Même si les possibilités des modèles classiques (Ejb, Com/DCom,...) sont parfois très étendues, la charge en terme de calcul qu ils représentent ne les rend pas éligibles pour certaines applications, comme certaines applications embarquées par exemple. Pourtant, les avantages de cette évolution «vers le haut» sont nombreux. Notamment le développeur d applications à base de composants est déchargé de certaines phases de programmation en utilisant des primitives de plus haut niveau pour se concentrer sur des problèmes plus spécifiques. Par exemple les middlewares tels que Corba ont permis aux développeurs de ne plus se soucier de la localisation des différents services constituant une application. L administrateur d application est aidé dans sa tâche par des procédés qui étaient avant réservés à l administrateur de systèmes ou de base de données Un environnement de composition spécifique Dans ce cadre, nous pensons que fournir au développeur d application à base de composants, des primitives de haut niveau, spécifiques à la composition, lui permettrait un développement d applications plus rapide et plus sûr. Il pourrait alors se concentrer sur d autres tâches. De plus, un environnement spécifique à la composition permettrait une vérification a priori du respect des modèles. En effet, si le modèle de composition spécifie qu une composition possède telle ou telle propriété, et que l environnement de composition permet de l implémenter directement au niveau assemblage, le respect de ces propriétés est assuré, par définition, par l environnement. C est ce que nous appelons vérification a priori. À la différence d une approche purement formelle, où il faudrait établir la preuve du respect des propriétés, nous posons comme hypothèse que l environnement suffit à garantir le respect des propriétés spécifiées. Nous pondérons cependant cette remarque dans le cas de composants Cots et de composés non construits sur la base de cet environnement. En effet, l environnement de composition ne peut garantir les compositions que lorsqu elles sont explicitement définies. Or, cela n est pas le cas de ces deux types de composants. Pour pouvoir assurer le respect des compositions internes à ces deux types de composants, il faudrait les adapter, afin de décrire leurs compositions avec l environnement WpcE Pilotage de composants Dans le chapitre 1, nous avons introduit la fonction d administrateur d application pour montrer que les applications à base de composants, grâce notamment à leur modularité, pouvaient être administrées comme un système d exploitation. Cette administration nécessite des outils et des environnements adaptés. Dans ce cadre, les propriétés de composition doivent être exprimables par ces outils d administration. En effet, lors des phases de maintenance ou de mise à jour d un composant par exemple, l administrateur de l application doit être en mesure de déployer le nouveau composant, en garantissant le respect des propriétés de composition. 122

135 6.2. L environnement Jmx Le pilotage dynamique des compositions rejoint également un des besoins industriels les plus importants. Il s agit de pouvoir aider à sélectionner un composant dans une base de composants pour un besoin précis [Hig01]. Un environnement de composition permettant l assemblage et le pilotage dynamique des applications permet d évaluer plusieurs composants afin de déterminer celui qui correspond le mieux aux besoins de l utilisateur, et facilement (par maquettage par exemple). 6.2 L environnement Jmx Nous avons développé un environnement de composition basé sur les postulats énoncés dans la section précédente d une part, et sur notre modèle de composition d autre part. Cet environnement repose sur la technologie Jmx (Java Management extension) [Sun01]. Nous présentons succinctement cette technologie Présentation de Jmx La technologie Jmx, développée par Sun Microsystems, permet la gestion de composants Java, appelés MBeans (Managed Beans). Chaque MBean est référencé dans un serveur par un nom unique, son «object name». La communication inter-mbean s effectue via le serveur de MBeans grâce aux «object name». Chaque MBean dispose également d une interface de gestion dans laquelle il expose les attributs et les méthodes qui seront accessibles aux autres MBeans. L architecture de Jmx permet en outre de connecter un navigateur Web au serveur de MBeans : le serveur émet des pages HMTL permettant d administrer les MBeans, en accédant notamment à leurs interfaces de gestion. L architecture Jmx est divisée en trois niveaux : un niveau instrumentation. Il contient une spécification pour implémenter des ressources administrables par Jmx (composant ou application par exemple). Ces ressources sont manipulées par des manager au niveau suivant ; un niveau manager. Il contient une spécification pour implémenter des managers Jmx. Ces managers contrôlent directement les ressources et les rendent accessibles aux applications d administration distantes du niveau supérieur ; un niveau services distribués qui fournit les interfaces pour implémenter des administrateurs Jmx. Les pages Web d administration s appuient sur ce niveau. Notre proposition consiste à transformer un composant classique en MBean d une part, mais surtout de modifier le service de relations de Jmx afin qu il propose la spécification des propriétés de composition Le service de relation Jmx Le service de relation de Jmx [Sun01] définit les classes permettant de construire des relations entre composants MBeans, et centralise toutes les opérations sur ces relations Jmx afin de maintenir leur cohérence. 34 Nous invitons le lecteur souhaitant approfondir cette présentation à consulter l annexe B. 123

136 Chapitre 6. Environnement de composition Java pour un déploiement de composants rigoureux Relation Jmx Une relation Jmx est une association n-aire entre MBeans définie par l utilisateur. Elle se compose de rôles nommés. Chaque rôle a une valeur qui est la liste des MBeans dans ce rôle. Cette liste doit satisfaire les informations associées à ce rôle : la multiplicité et la classe des MBeans du rôle. Chaque relation Jmx est construite à partir d un type de relation dans lequel l utilisateur décrit les informations d un ou plusieurs rôles. La Figure 7.5 illustre une relation Jmx simple entre deux rôles Propriétaire et Livre, représentant le concept de possession d un livre (bibliothèque), et fournit à titre de comparaison l association Uml correspondante. Modèle JMX Modèle UML Relation Type Bibliothèque * Propriétaire 1..1 Bibliothèque 0..* Livre Role Propriétaire Role Livre Fig. 6.1 Comparaison des modèles de relations [Sun00] Les rôles des types de relation sont définis statiquement et ne peuvent évoluer à l exécution. Seule la valeur des rôles peut être modifiée par les relations en tenant compte des contraintes des rôles. Les relations et les types de relations doivent fournir les opérations nécessaires pour être utilisées par le service de relation. Jmx fournit des classes de support (RelationSupport) implémentant ces opérations. Ces classes sont implémentées par un MBean. Les opérations de ces relations peuvent être rendues alors accessibles par un navigateur Web comme n importe quel autre MBean. La section suivante décrit l utilisation de ces opérations par le service de relation Services fournis Le service de relation Jmx est implémenté par le MBean RelationService. Pour être prises en compte, les relations Jmx doivent être enregistrées dans le service de relation. Le RelationService expose ainsi des opérations pour enregistrer des types de relation ainsi que des relations (addrelationtype addrelation) et des opérations pour les supprimer (removerelationtype removerelation). Lors de la suppression d un type de relation, la cohérence est maintenue et toutes les relations de ce type sont également supprimées. L environnement maintient la cohérence lors de la mise à jour d une relation comme la modification de la valeur de ses rôles, i.e. l ajout ou la suppression de MBeans dans ses rôles, ou la destruction externe d un de ses MBeans membres par exemple. Le service de relation permet également d effectuer des recherches sur ses relations. Il est ainsi possible de déterminer à quelles relations appartient un MBean (findreferencingrelations) et inversement quels MBeans font partie d une relation donnée (findassociatedmbeans). Il fournit aussi des informations sur ses relations comme le type d une relation ou les cardinalités d une relation par exemple. 124

137 6.3. Environnement de composition Java pour un développement rigoureux 6.3 Environnement de composition Java pour un développement rigoureux Nous avons développé un environnement de composition Java. Il est composé de : l implémentation de la relation Tout-Partie et de son type : objets WholePart et WholePartType qui héritent respectivement de MBeanRegistration et de RelationTypeSupport ; interfaces spécifiant les propriétés secondaires de la relation Tout-Partie : Encapsulation, LocalUn- Sharing, LocalUnSharing, LifetimeDependency, Mutability, Separability ; exceptions utilisées lorsque des propriétés ne pouvant pas être vérifiées statiquement ne sont pas satisfaites : InstanceAsymmetryException, ShareabilityException, et TypeAntisymmetryException ; l implémentation des sous-types de relation Tout-Partie définies dans notre modèle de composition. Ces relations s appuient sur la relation Tout-Partie et sur son type. Nous présentons dans les sections suivantes la technique de construction de relations de composition offerte par cet environnement, puis les propriétés implémentées. interface Encapsulation interface LifeTime Dependency interface GlobalUnsharing interface LocalUnsharing interface Separability interface Mutability interface LCOMPMBean interface SCOMPMBean interface SAGGMBean interface LAGGMBean LCOMP SCOMP SAGG LAGG JMX WholePart étend implémente Fig. 6.2 Spécialisation de relation Tout-Partie dans l environnement WcpE Construction de relations Tout-Partie L architecture originale que nous avons conçue permet d implémenter rapidement et facilement des sous-types de la relation Tout-Partie. Nous décrivons ce processus pour les sous-types définis dans la section page 88. La relation «WholePart» est dotée par essence des propriétés primaires, tandis que les propriétés secondaires sont assignées aux sous-types «Strong Composition», «Lightweight Composition», «Strong Aggregation» et «Lightweight Aggregation». Par simplification, et pour rester cohérent par rapport au profil développé dans le chapitre précédent, nous utilisons les noms abrégés de ces sous-types. L implémentation proposée suit un modèle similaire pour spécialiser ces relations. La Figure 6.2 représente ce modèle. Les propriétés sont traduites par des interfaces. Notons que, les propriétés de séparabilité et de mutabilité étant optionnelles, elles sont intégrées par défaut à aucune relation de composition. 125

138 Chapitre 6. Environnement de composition Java pour un déploiement de composants rigoureux Les classes implémentant les sous-types de relation Tout-Partie étendent la classe abstraite WholePart et héritent ainsi de toutes les propriétés de la relation. Cela se traduit par le code suivant (pour les classes SCOMP et LAGG) : 1 public c l a s s SCOMP extends WholePart implements SCOMPMBean { 2 public SCOMP(... ) throws JMException { 3 super (... ) ; 4 }} 5 public c l a s s LAGG extends WholePart implements LAGGMBean { 6 public LAGG(... ) throws JMException { 7 super (... ) ; 8 }} Le code est extrêmement simple et il est proposé ici dans son intégralité. Seuls les paramètres des constructeurs ont été omis. Il est également similaire pour les quatre sous-types. Les différenciations entre les sous-types se situent dans l interface MBean que ces relations implémentent. L interface MBean des relations est composée des interfaces des propriétés secondaires que la relation doit satisfaire. Ainsi seules les propriétés secondaires intrinsèques de ces relations leurs sont transmises bien qu elles aient hérité de toutes les propriétés de la relation Tout-Partie. La Figure 6.2 illustre le lien direct entre les sous-types de la relation Tout-Partie et les propriétés secondaires. La séparabilité et la mutabilité n ont pas de lien direct car elles ne sont spécifiées que dans le cas de relations dynamiques. Les interfaces des sous-types de la relation Tout-Partie sont définies ainsi dans le code suivant : 1 public interface SCOMPMBean extends Encapsulation, 2 GlobalUnsharing, 3 LifetimeDependency { 4 } 5 public interface SAGGMBean extends GlobalUnSharing, 6 S e p a r a b i l i t y, 7 Mutability { 8 } Cette technique offre une grande flexibilité dans la construction de sous-types de la relation Tout- Partie et propose un cadre simple pour l expérimentation de nouvelles relations Implémentation de la relation Tout-Partie Nous définissons la relation WholePartType par un type de relation Jmx composé de deux rôles : le rôle Whole et le rôle Part. Le type d une relation Jmx n étant pas modifiable à l exécution, cela nous permet de contraindre statiquement la binarité de la relation. 126 Le code suivant implémente ce type de relation :

139 6.3. Environnement de composition Java pour un développement rigoureux 1 public c l a s s WholePartType extends RelationTypeSupport { 2 public WholePartType (... ) { 3 // r o l e Whole 4 R o l e I n f o wholeroleinfo = new R o l e I n f o ( " whole ", wholetype,... ) ; 5 addroleinfo ( wholeroleinfo ) ; 6 // r o l e Part 7 R o l e I n f o p a r t R o l e I n f o = new R o l e I n f o ( " part ", parttype,... ) ; 8 addroleinfo ( p a r t R o l e I n f o ) ; 9 [... ] 10 }} La classe WholePart représentant la relation Tout-Partie doit être abstraite pour correspondre à l architecture que nous avons définie dans la section précédente. Afin d exploiter les capacités fournies par les relations Jmx, nous avons incorporé dans WholePart une relation Jmx ainsi qu un lien au service de relation Jmx : 1 public abstract c l a s s WholePart { 2 // e n c a p s u l a t i o n d une r e l a t i o n JMX 3 private RelationSupport _relationsupport ; 4 // acces au s e r v i c e de r e l a t i o n s JMX 5 private ObjectName _relationserviceobjectname ; 6 [... ] 7 } Le service de relation nous permet de vérifier plusieurs propriétés de Tout-Partie. Pour l antisymétrie au niveau des composants d une nouvelle relation, un appel au service de relation nous renseigne sur les types de relation déjà définis. Si le symétrique du type de la nouvelle relation est déjà défini ou si le nouveau type introduit un cycle, nous levons une exception de type TypeAntisymmetryException. L asymétrie au niveau des instances de composants consiste à vérifier l irréflexivité et l antisymétrie d une relation. Le contrôle de l antisymétrie est effectué par une technique similaire au contrôle de l antisymétrie des types. Nous vérifions l irréflexivité en contrôlant la valeur des rôles de la relation Jmx encapsulée. Si l intersection de la valeur des rôles Whole et Part n est pas vide une exception de type InstanceAsymmetryException est levée. Pour vérifier l encapsulation et la partageabilité d une relation, nous faisons un appel au service de relation pour retrouver l ensemble des relations dans lesquelles sont référencés les composants Partie de cette relation. Dans le cas de l encapsulation, si cet ensemble est vide, i.e. pas de relation Tout-Partie ou tout autre relation Jmx, la propriété est vérifiée. Dans le cas d une relation partageable, si cet ensemble ne contient pas de relation Tout-Partie, la propriété est vérifiée. Dans le cas de relations non partageables et non encapsulées, cet ensemble ne doit pas contenir de relation partageable ou encapsulée. Notons que cette réalisation ne correspond pas complètement à notre modèle de composition. Notamment, l encapsulation est ici traduite comme l exclusion globale. Cela vient du fait que cet environnement a été développé en amont du modèle, notamment comme outil prospectif permettant la manipulation des propriétés de la relation Tout-Partie. L environnement a servi à manipuler de manière concrète des relations Tout-Partie et leurs propriétés, de manière à étudier leurs liens, leurs implications et leurs dépendances. Cela nous a aidé à proposer notre modèle de composition. La sémantique des propriétés implémentées est donc proche de celles de l article [BHSPLB03]. Nous ne l avons pas encore totalement adapté à notre modèle de composition actuel. Cette adaptation est en cours de réalisation. 127

140 6.4. Exemple d utilisation Fig. 6.4 Vérification d une dépendance existentielle (2) des fonctionnalités de notre environnement, nous choisissons ici de rendre la relation CoffeeMachine - Coiner partageable globalement et non encapsulée par le composant CoffeeMachine. Le composant CoffeeMachine dépend existentiellement du Coiner car on ne veut pas que la destruction du Coiner permette l utilisation libre de CoffeeMachine. Nous avons réalisé notre étude de cas dans une implémentation Java utilisant notre environnement. Cela nous permet de vérifier la cohérence des propriétés des relations que nous avons spécifiées. Selon la nature des propriétés, l environnement effectue une vérification positive ou négative : soit l environnement assure lui-même la propriété de la relation (par implémentation), et dans ce cas on est sûr qu elle est vérifiée ; soit l environnement vérifie que la propriété de la relation est cohérente avec les relations déjà définies et interdit cette relation si une incohérence est détectée. Nous allons présenter un exemple de ces deux possibilités. Premièrement, dans notre étude de cas, le composant CoffeeMachine est en dépendance existentielle avec les composants Coiner et DrinkMaker. Ainsi la destruction du composant Coiner, par exemple, entraîne la destruction des deux autres composants par propagation de la propriété de dépendance existentielle. C est un exemple de vérification positive. La Figure 6.3 et la Figure 6.4 illustre ce processus. En (a), les trois composants sont manipulables par l interface Web. Après avoir sélectionné le composant Coiner, ce composant est détruit en (b), ce que valide l environnement en (c). Nous voyons bien de retour à l interface Web en (d) qu aucun des trois composants précédents n est manipulable maintenant. Ils ont 129

141 6.5. Bilan du chapitre 6.5 Bilan du chapitre Nous avons présenté dans cette section un outil mettant en œuvre l approche compositionnelle proposée dans le chapitre 4. Cette réalisation permet de définir des relations Tout-Partie entre composants dans un environnement assurant la cohérence des relations. Cette cohérence est assuré par la vérification de leurs propriétés intrinsèques. Ces propriétés portent sur l architecture et la dynamique de l application. Bien que déjà utilisable et proposant un cadre complet pour réaliser de nouvelles relations, notre environnement n est pas encore finalisé. En effet, toutes les propriétés de composition ne sont pas implémentées et validées. Cependant, ce travail est en cours de réalisation. Nous avons implémenté au sein de notre environnement les quatre sous-types de la relation Tout-Partie utilisés pour définir des relations entre composants. L architecture de l environnement réalisé permet de définir et d intégrer facilement de nouveaux sous-types, en jouant sur les mélanges des propriétés existantes. Nous possédons ainsi un outil pour expérimenter de nouvelles relations entre composants. Les résultats obtenus par cette approche sont encourageants. Nous pensons que l insertion de propriétés explicites de composition dans les modèles de composants est une piste méritant d être étendue. 131

142 Chapitre 6. Environnement de composition Java pour un déploiement de composants rigoureux 132

143 Chapitre 7 Application de la technologie Bit pour la vérification des contrats de exprimés sur les états Sommaire 7.1 Contrats basés sur les états et vérification a posteriori Test de composant Spécificité du test de composant Le test intégré de composant La technologie Bit Le Contract testing Le State-based contract testing Outillage de la technologie Bit La librairie Bit/J Exemple d utilisation de la librairie Bit/J Bilan du chapitre Le chapitre 6 a présenté notre environnement de déploiement assurant la vérification a priori des propriétés de composition architecturales et dynamiques. Dans ce chapitre, nous présentons notre approche de vérification a posteriori, basée sur l implémentation et l évaluation de contrats portant sur les états externes du composé. Nous appelons contrats de composition comportementaux un contrat permettant la description du comportement du composé exprimés sur ses états externes. Notre approche s appuie sur la technologie Bit, développée dans le cadre du projet européen Component+. Pour cela, nous expliquons notre approche dans la section 7.1. Puis, nous discutons de la spécificité du test des composants logiciels dans la section 7.2. Nous présentons ensuite la technologie Bit (section 7.3) et la librairie (section 7.4) développée par l équipe Aoc [BBB04] et qui permet une mise en œuvre de la technologie Bit. Nous illustrons son utilisation avec un exemple concret (section 7.4.2) de réalisation de contrat, et nous dressons un bilan de cet outil (section 7.5). 7.1 Contrats basés sur les états et vérification a posteriori La vérification a priori des aspects dynamiques et architecturaux n est pas suffisante pour assurer la validité des compositions. En effet, le fait que deux composants soient bien assemblés ne veut pas dire 133

144 Chapitre 7. Application de la technologie Bit pour la vérification des contrats de exprimés sur les états que le résultat de cet assemblage a un comportement correct. Nous avons donc proposé une approche pour tester le comportement des composants et en particulier des composés. Si l on prend l exemple de la machine à café, notre approche permet de manipuler l état externe du composant CoffeeMachine pour vérifier qu il réponde bien à la spécification de son comportement. Cette vérification se fait sur la composition réalisée (c est-à-dire effective). En effet, nous cherchons à valider que le résultat final de la composition respecte bien le comportement qui lui a été spécifié. Cette vérification ne peut pas se faire sous la forme de contraintes comme pour les aspects dynamiques et architecturaux. On parle alors de vérification a posteriori. Pour mémoire, nous avons préconiser à la section l utilisation de la méthode définie par Pazzi pour modéliser le comportement externe du composé. L intérêt de cette méthode est de définir explicitement le comportement du composé à partir des comportements de ses sous-composants. Dans ce cadre, l approche retenue est de proposer l intégration de fonctionnalités de test au sein des composants. Ces fonctionnalités permettent la mise en œuvre de contrats simples, mais aussi de contrats basés sur les états. Un tel type de contrat s applique sur les compositions obtenues par notre modèle de composition, mais également aux composants boîte noire et aux composants Cots [BBB03a]. Il est basé sur l utilisation de Statecharts exécutables pour décrire le comportement des composants. Le projet Component+ a proposé de fournir les composants avec des fonctionnalités de test intégrées. Ces fonctionnalités sont livrées par le fournisseur ou ajoutées par l utilisateur. Notons que, à l ère où la concurrence entre fournisseurs est difficile, un fournisseur livrant ses composants avec des services supplémentaires tels que des services de test aura un avantage certain. Mais nous pensons que l utilisateur doit avoir lui aussi avoir la possibilité de développer ses propres fonctionnalités de test. Ainsi, leur mise en œuvre doit être aussi aisée que possible et doit permettre l expressivité la plus importante possible, en tenant compte des aspects boîte noire des composants. La technologie BIT, est basée sur une architecture de test intégré permettant la réalisation de ce type de test basé contrat. Dans ce contexte, l équipe Aoc a développé une librairie Java qui implémente cette architecture. Afin d atténuer l intégration des composants, nous soutenons un développement basé sur des machines à états complexes (côté vendeur de composants) et/ou quelques adaptations (côté utilisateur) qui permettent de lier un composant donné (même s il s agit d un Cots) à notre librairie. Dans ce contexte, un des problème vient de l impossibilité d accéder au code source des composants boîte noire et des Cots. En Java, nous pouvons utiliser les capacités de réflexion de ce langage pour accéder dynamiquement, et en exécution, aux propriétés internes d un objet. Dans notre approche, les protocoles de test sont spécifiquement écrit une fois pour toute ce qui est très intéressant pour des Cots car cela leur permet d être acquis, validés et finalement (ré)utilisés. 7.2 Test de composant Le Cbd a pour conséquence d accroître l importance des phases d assemblage, de vérification et de validation, par rapport à la seule phase d implémentation. Cependant les spécificités de l approche basée composant requièrent une adaptation des techniques de test traditionnelles Spécificité du test de composant Le test de logiciel procédural peut être divisé en trois phases successives : les tests unitaires, les tests d intégration et les tests du système complet [PK90]. En général, l utilisateur d un composant ne le teste 134

145 7.3. La technologie Bit pas lui même de manière unitaire. Il est supposé être validé, et même parfois certifié par son fournisseur [Har00]. Le fournisseur de composants dispose du code source, puisqu il en est le créateur, ce qui rend le test unitaire possible. Par contre, il voit les composants indépendamment de leur contexte : il ne peut donc pas pratiquer le test d intégration du fait de l explosion combinatoire des configurations possibles à tester [SGM02]. Il est donc essentiel de tester la bonne intégration des composants dans leur nouveau contexte d exécution. En particulier des aspects tels que la communication avec les autres composants, la correspondance des interfaces, la tolérance aux fautes, ou encore la correspondance avec un comportement attendu, doivent être vérifiés. En effet, un composant peut fonctionner dans un contexte particulier (celui de développement par exemple) et présenter des erreurs dans d autres contextes [Voa98, Wey98]. Cela se fait au niveau des phases d assemblage et de déploiement, ce qui correspond aux tests d intégration (et non au test du système complet puisqu on se concentre toujours sur un composant donné et non sur le système en entier). Malheureusement, l aspect boîte noire des composants, ainsi que le fait qu un composant a été la plupart du temps développé par une tierce personne, rendent ces tests difficiles à mettre en place et à réaliser. Il est donc fondamental d accroître la testabilité des composants, élément essentiel pour leur qualité et leur fiabilité [VM95]. La testabilité est à envisager selon deux axes [Fre91] : l observabilité et la controlabilité. Le premier de ces axes concerne la facilité à observer le comportement du composant selon son comportement opérationnel (en exécution) et ses sorties en fonction de ses entrées. Le second axe concerne la facilité à contrôler (piloter) le composant à travers ses entrées, ses sorties, ses interfaces et son comportement Le test intégré de composant Le test est une problématique de recherche complexe et active. Nous invitons le lecteur intéressé à consulter les documents [Har00, BG03, Tra04], traitant plus en détail du test des composants. Nous cherchons plutôt à fournir un composant avec un certain degré de fonctionnalité de test. Le composant ainsi livré facilitera, via ces fonctionnalités de test, sa vérification par des méthodes de test appropriées. En particulier, nous cherchons à fournir à son utilisateur des moyens d accéder à son comportement dans son environnement de déploiement. C est ce qu on appelle le test intégré, ou Built-In Test (Bit). Le composant est livré avec des tests ou des fonctionnalités de test au sein même des composants. L utilisateur de composants peut alors se servir de ces fonctionnalités pour développer ses propres tests, répondant ainsi à une demande importante de la communauté notamment pour réduire la dépendance entre l utilisateur et le développeur de composants [BG03]. L approche par test intégré a conduit à des résultats probants. Notamment citons les travaux de Wang et al. [WKF + 98], de l équipe de Jean-Marc Jézéquel [DJL99, BB00, DFJ01, JDL01] et enfin de Gao [GGGS02]. Nous avons mené une discussion plus en détail sur ces travaux dans [BBBR04]. Notre approche est similaire à cette dernière, mais nous nous en démarquons en permettant la réalisation de tests portant sur le comportement du composant (décrit sous forme de Statecharts [Har87]), basés sur les notions de contrat et de QoS. En ce sens, nous nous approchons également de l esprit de l approche proposée par Jézéquel. De plus, notre approche est indépendante de tout modèle particulier de composants, ce qui la rend plus générique. 7.3 La technologie Bit La technologie Bit vise à ajouter des capacités de test intégrées aux composants logiciels dans le but d aider à les vérifier (pour plus d information, voir le document [Bar03] sur le site du projet européen). 135

146 Chapitre 7. Application de la technologie Bit pour la vérification des contrats de exprimés sur les états Elle est conçue pour prendre en compte à la fois la manipulation des tests mais aussi leur observabilité. Elle s intéresse notamment à deux phases de test. La première, le test basé contrat (ou contract testing) [Col03, GAB + 02], concerne la vérification des composants au moment de leur assemblage. La seconde, le test orienté qualité de service (QoS testing) [VKLK02], concerne les tests ayant lieu durant le déploiement opérationnel du composant. Nous ne nous intéressons pas à ce dernier type de test dans ce document ; en effet, le QoS testing s intéresse plus généralement à des problèmes non fonctionnels qui n entrent pas directement dans notre problématique Le Contract testing Comme nous avons vu dans le chapitre 4, nous considérons un composant comme un agrégat de souscomposants. En Java, un tel composant est réalisé par une classe possédant des attributs du type de ces sous-composants. La Figure 7.1 représente l architecture dans laquelle un composant est connecté avec les classes prédéfinies de notre approche. Un composant Bit 35 est construit de telle sorte qu il acquiert toutes les propriétés du composant qu il permet de tester. Un lien de dépendance Uml est utilisé pour laisser le choix du mécanisme de programmation adéquat (l héritage est souvent utilisé). L interface du contrat de testabilité Bit est un ensemble d opérations qui sont systématiquement utilisées dans les cas de test Bit, eux-même systématiquement utilisés par le testeur Bit. Un cas de test Bit est une classe Java ayant des protocoles de test pré-définis : «initialiser le test», «établir les conditions d exécution»,«récupérer les résultats et/ou les erreurs» et «finaliser le test». Chaque BitC peut réécrire ces opérations de base en fonction des valeurs des propriétés du composant. Le testeur Bit permet de développer des scénarios de test : séquences, résultats attendus, politique d annulation/de terminaison, etc. Composant Sous-composant Composant BIT interface Contrat de testabilité BIT Cas de test BIT Testeur BIT Fig. 7.1 Dépendances en contract testing Un des grands bénéfices de cette approche est que la plupart des éléments de test sont indépendant des spécificités des composants testés. Par exemple, des composants Cots, que l on veut comparer en vue de leur achat peuvent l être en utilisant la même plate-forme. De plus, les éléments de test sont actuellement construits dans le BitC. Les BitC peuvent être déployés à la place des composants. Il faut cependant 35 Par convention, un composant Bit sera appelé un BitC dans le reste de ce document. 136

147 7.3. La technologie Bit dans ce cas tenir compte de la modification des performances et des ressources que cela peut entraîner, car un BitC crée une certaine surcharge par rapport au composant initial. Un des retours de notre approche est que le côté totalement encapsulé des composants entraîne une analyse et un diagnostique difficile à déterminer à un niveau profond d agrégation. Nous avons étendu notre librairie afin de prendre en compte les états concurrents et parallèles, de manière à avoir un meilleur accès à l intérieur du composant Le State-based contract testing La Figure 7.2 montre une interface étendue appelée contrat de testabilité Bit basé état à laquelle un BitC peut être lié. La flèche blanche en pointillé représente la relation d implémentation entre une classe et une interface. Cette deuxième manière de réaliser le contract testing est plus cœrcitive dans le sens où un automate à état est nécessaire pour le composant à tester. Bien qu un tel type de spécification soit relativement commune dans certains domaines tels que les systèmes temps réels, elle ne l est pas dans d autre. Aussi, pour pouvoir utiliser cette approche, un travail de réingénierie est parfois nécessaire afin de d extraire la spécification comportementale d un composant existant. interface Contrat de testabilité BIT Result : {#Failure,#Success,#TBD} execution_condition() : Boolean is_testable() : Boolean initialize_test() finalize_test() interface Contrat de testabilité BIT basé état is_in_state(name:string) : Boolean set_to_state(name:string) Composant BIT Fig. 7.2 Dépendances entre les interfaces de test Dans le cadre de notre approche, nous préconisons l utilisation d automates à état pour la modélisation du comportement. Nous avons pour cela identifié (en section ) les Pws de Pazzi, comme discuté précédemment, pour modéliser le comportement des composés. Nous considérons donc que le développement d une application basée composants en utilisant notre approche doit fournir les automates à état des composés (également des composants). L interface contrat de testabilité Bit basé état permet de décrire le comportement de l automate à état sous la forme de Statecharts. Les Pws sont avant tout des Statecharts. Leur différence par rapport aux Statecharts traditionnels n est pas importante dans notre 137

148 Chapitre 7. Application de la technologie Bit pour la vérification des contrats de exprimés sur les états cas. En effet, ils représentent le comportement du composé de manière explicite, et sont donc parfaitement adaptés au test basé état que nous nous proposons de mettre en place. 7.4 Outillage de la technologie Bit Dans le cadre du projet, nous avons développé au sein de notre équipe, une librairie Java, nommée BIT/J, supportant la technologie Bit. Elle permet d implémenter ces capacités pour des composants Java classiques ou des composants Cots La librairie Bit/J La Figure 7.3 est le modèle Uml de la librairie BIT/J. Elle offre deux modèles de test construits sur la même architecture : chacun implémente une interface générique de test, Ibit Query et State-based Ibit Query, implémentant respectivement les contrat de testabilité Bit présentés dans la section précédente. Des cas de test manipulent ces interfaces. Ils sont gérés par un testeur. Statechart Statechart BIT state Statechart monitor BIT state monitor BIT component Component Interface State-based IBIT_Query check(contract: Boolean) in state(string):boolean to state(string) State-Based BIT test case State-Based BIT tester Interface IBIT_Query execution condition():boolean is testable():boolean initialize test() finalize test() BIT test case BIT tester Fig. 7.3 Modèle Uml de la librairie Bit/J Le premier modèle est le modèle standard. Il est basé sur trois classes : Ibit Query, cas de test Bit et testeur Bit. Le second modèle est le modèle basé état. Il fournit les même services que le modèle standard, et en plus des facilités pour le test basé état. Le comportement du composant doit être décrit par un diagramme d état Uml (Statecharts) dans le BitC lui-même. Ce modèle est basé sur trois classes : Statebased Ibit Query, State-based BIT test case et State-based BIT tester. 138

149 7.4. Outillage de la technologie Bit La librairie BIT/J fournit également des capacités de pilotage, de configuration ainsi que de test à distance basées sur Jmx : un manager spécifique, qui est appelé manager Jmx, pilote le BitC dans son environnement. Les opérations de l interface du BitC sont accessibles via un navigateur Web sur le réseau. La libraire BIT/J est fournie avec un générateur de code. Il génère un squelette pour le code du composant Bit et également pour le code du testeur ainsi que pour le code Jmx. La Figure 7.4 montre le générateur de code. Le générateur créé quatre fichiers : le BitC, le testeur Bit, le manager Jmx nécessaire pour le test à distante et l interface Jmx fixant les opérations pouvant être testées. L utilisateur peut choisir de ne pas les rendre toutes testables. Fig. 7.4 Générateur de code de la librairie Bit/J Exemple d utilisation de la librairie Bit/J Le générateur fournit un squelette pour le BitC. L utilisateur doit alors le finaliser avant de pouvoir l utiliser. En premier, dans le cas du modèle Bit basé état, il doit décrire le Statecharts du composant. Pour faire cela, il faut modifier l opération init_behavior() du BitC. Nous utilisons un exemple de réalisation de BitC sur le composant Java CoffeeMachine. Le code suivant montre une partie du code généré pour le composant Bit CoffeeMachine : 1 protected void i n i t _ b e h a v i o r ( ) throws Statechart_exception { 2 / s t a t e d e f i n i t i o n s and formal r e l a t i o n s h i p s here / 3 } Le code suivant illustre la spécification du comportement du composant CoffeeMachine dans le BitC. Septs états sont déclarés (Ready, NoDrinkSelected, NoMoneyGiven, ReadyToPrepare, GivingDrink, PreparingDrink et Preparation). L état Preparation est un état composé (composite state) à partir de l état 139

150 Chapitre 7. Application de la technologie Bit pour la vérification des contrats de exprimés sur les états NoDrinkSelected et de l état NoMoneyGiven. L automate d état du composant CoffeeMachine contient les états possibles : 1 protected void i n i t _ b e h a v i o r ( ) throws Statechart_exception { 2 / s t a t e d e f i n i t i o n s and formal r e l a t i o n s h i p s here / 3 _Ready = new BIT_state ( "Ready" ) ; 4 _NoDrinkSelected = new BIT_state ( " NoDrinkSelected " ) ; 5 _NoMoneyGiven = new BIT_state ( "NoMoneyGiven" ) ; 6 _ReadyToPrepare = new BIT_state ( " ReadyToPrepare" ) ; 7 _GivingDrink = new BIT_state ( " GivingDrink " ) ; 8 _PreparingDrink = new BIT_state ( " PreparingDrink " ) ; 9 _ Preparation = ( BIT_state ) ( _NoMoneyGiven. xor ( _NoDrinkSelected ) ) 10. name( " Preparation " ) ; 11 _BIT_coffeeMachine = new BIT_state_monitor ( ( ( ( _ Preparation 12. xor ( _ReadyToPrepare ) ). xor (_Ready) ). xor ( _PreparingDrink ) ) 13. xor ( _GivingDrink ), " BIT_coffeeMachine " ) ; 14 _Ready. i n p u t S t a t e ( ) ; 15 } L interface de test a été générée automatiquement et aucune modification n est requise. Cependant, l utilisateur peut la modifier en cas de nécessité (pour, par exemple, ajouter des opérations de test particulières). La troisième partie du squelette est composée des opérations correspondant aux opérations publiques du composant originale. Chaque opération générée contient un appel à l opération initiale. De plus, dans le cas du modèle Bit basé état, l utilisateur doit également coder les transitions d état apparaissant dans le Statechart selon un procédé précis. L exemple suivant illustre le code correspondant aux opérations sendcoinok et cancel. 1 public void sendcoinok ( ) throws Statechart_exception { 2 super. sendcoinok ( ) ; 3 / s t a t e t r a n s i t i o n s here : _BIT_coffeeMachine. f i r e s ( fromstate, t o S t a t e ) ; / 4 _BIT_coffeeMachine. used_up ( ) ; 5 } 6 public java. lang. S t r i n g c a n c e l ( ) throws Statechart_exception { 7 java. lang. S t r i n g r e s u l t = super. c a n c e l ( ) ; 8 / s t a t e t r a n s i t i o n s here : _BIT_coffeeMachine. f i r e s ( fromstate, t o S t a t e ) ; / 9 _BIT_coffeeMachine. used_up ( ) ; 10 return r e s u l t ; 11 } L exemple suivant montre le code correspondant après modification par l utilisateur. Pour l opération sendcoinok, l utilisateur définit une transition d état obligatoire (Ready vers NoDrinkSelected). Dans le cas de l opération cancel, l utilisateur définit quatre transitions d états obligatoires (Preparation vers Ready, ReadyToPrepare vers Ready, NoDrinkSelected vers Ready et NoMoneyGiven vers Ready). Enfin, l utilisateur peut ajouter des opérations de test spécifiques dans le BitC. Il le fait manuellement sans aide du générateur. 140

151 7.5. Bilan du chapitre 1 public void sendcoinok ( ) throws Statechart_exception { 2 super. sendcoinok ( ) ; 3 / s t a t e t r a n s i t i o n s here : _BIT_coffeeMachine. f i r e s ( fromstate, t o S t a t e ) ; / 4 _BIT_coffeeMachine. f i r e s (_Ready, _NoDrinkSelected ) ; 5 _BIT_coffeeMachine. used_up ( ) ; 6 } 7 public java. lang. S t r i n g c a n c e l ( ) throws Statechart_exception { 8 java. lang. S t r i n g r e s u l t = super. c a n c e l ( ) ; 9 / s t a t e t r a n s i t i o n s here : _BIT_coffeeMachine. f i r e s ( fromstate, t o S t a t e ) ; / 10 _BIT_coffeeMachine. f i r e s ( _Preparation, _Ready) ; 11 _BIT_coffeeMachine. f i r e s ( _ReadyToPrepare, _Ready) ; 12 _BIT_coffeeMachine. f i r e s ( _NoDrinkSelected, _Ready) ; 13 _BIT_coffeeMachine. f i r e s (_NoMoneyGiven, _Ready) ; 14 _BIT_coffeeMachine. used_up ( ) ; 15 return r e s u l t ; 16 } Dans le cas du testeur Bit, des opérations de configuration peuvent être ajoutées au testeur. Nous avons ajouté une opération permettant de réinitialiser le composant dans son état initial. Ainsi, l opération reset a été ajoutée au testeur, comme illustré par l exemple suivant : 1 public S t r i n g r e s e t ( ) { 2 try { 3 _bc. c a n c e l ( ) ; 4 } 5 catch ( java. u t i l. Exception e ) { 6 try { 7 _bc. to_state ( "Ready" ) ; 8 } 9 catch ( Statechart_exception se ) { 10 return se. t o S t r i n g ( ) ; 11 } 12 } 13 catch ( Statechart_exception se ) { 14 return se. t o S t r i n g ( ) ; 15 } 16 return " S u c c e s s f u l c o n f i g u r a t i o n " ; 17 } 7.5 Bilan du chapitre Dans ce chapitre, nous avons présenté notre approche pour la mise en œuvre de contrats de composition. Ces contrats s appuient sur la technologie Bit développée dans le cadre du projet européen Component+, et la librairie BIT/J développée par l équipe Aoc. Elle permet d ajouter des fonctionnalités de test aux composants. Ces outils offrent notamment la possibilité de tester le comportement des composants deux à deux. Ce test est basé sur l exécution de machines à état directement intégrées au sein du composant à tester. Cette approche offre un complément à notre environnement de déploiement 141

152 Chapitre 7. Application de la technologie Bit pour la vérification des contrats de exprimés sur les états présenté dans le chapitre 6. En effet, l environnement assure le respect des propriétés de composition d un point de vue dynamique et architecturale. La librairie permet de vérifier le niveau comportemental d un composant. Ce type de tests peut être particulièrement intéressant pour vérifier le bon comportement d un composant Tout par exemple. 142

153 Conclusions générale et perspectives 143

154

155 Conclusion Les recherches menées par l équipe Aoc du LIUPPA, dans lesquelles s inscrivent ces travaux, portent principalement sur l amélioration de la qualité des systèmes logiciels à objets et à composants, ainsi que leur réalisation. Dans ce domaine, le Cbd est actuellement reconnu, tant par le monde académique que par le monde industriel, comme une approche prometteuse. Son utilisation contribue notamment à améliorer la réutilisabilité, la structuration des architectures logicielles et la modularité des applications. Dans ce mémoire, nous avons présenté notre étude visant à améliorer la prise en compte de la composition logicielle dans le cadre de l ingénierie logicielle basée composant. Nous nous sommes plus particulièrement intéressés au niveau conception des applications basées composants. Dans un premier temps, nous avons mené une étude terminologique sur la Cbse. Nous nous sommes positionnés sur la définition des concepts clés. Dans un deuxième temps, nous avons dressé un état de l art sur la composition logicielle. Le concept de composition est fondamental dans le domaine composant puisqu il caractérise les règles d assemblage entre les composants. Nous en avons tiré comme conclusion que les modèles de composants formaient une base, riche et mature, d outils permettant l assemblage de composants. En revanche, les moyens de conception, et en particulier le langage Uml, qui est actuellement un standard de facto de la modélisation, ne permettent pas, actuellement, de modéliser la composition de manière satisfaisante. Dans ce cadre, nous avons proposé un modèle de composition hiérarchique basé sur la spécification de propriétés de composition. Ces propriétés ont été identifiées à travers une étude de la relation Tout- Partie. Nous avons proposé d intégrer ces travaux au métamodèle Uml à travers la définition d une relation de composition hiérarchique spécifique aux composants logiciels. Cette relation est caractérisée par la spécification de propriétés de composition traitant les aspects architecturaux et dynamiques. Nous les avons décrites avec le langage Ocl. Enfin, nous avons identifié une approche, pour la spécification du comportement des composants construits par assemblage hiérarchique. Notre modèle traite donc la composition logicielle suivant trois axes : architectural, dynamique et comportemental. D un point de vue réalisation, nous avons outillé notre approche en vue de fournir une plate-forme de composition la plus complète possible. La plate-forme est basée sur un outil de modélisation et deux outils de vérification. D un point de vue modélisation, nous avons réalisé un profil Uml. Celui-ci implémente notre modèle de composition. Il définit des méthodes de vérification du modèle, basées sur les règles Ocl spécifiant les propriétés citées précédemment. Cela permet de vérifier la cohérence des propriétés de composition spécifiées par le concepteur. Notre démarche a ensuite consisté à définir des moyens garantissant le respect des propriétés de composition spécifiées dans le modèle, au niveau assemblage physique et déploiement des composants. Notre travail a porté sur deux aspects. Le premier consiste en un environnement contraint de déploiement de composants, dans lequel le développeur d applications peut spécifier les propriétés de composition entre les composants. L environnement assure le respect des propriétés architecturales et dynamiques. Nous qualifions cette approche de vérification a priori. Le deuxième travail porte sur la vérification du comportement externe de la composition. Nous avons développé une librairie permettant la mise en place de contrats de composition. Ces contrats vérifient le comportement d un assemblage de composants (un composé) à travers l exécution d un Statechart. Nous qualifions cette approche de vérification a posteriori car elle s applique sur une version assemblée d une composition. 145

156 Bilan du travail Notre travail se situe dans la dynamique actuelle qui accorde de plus en plus d importance aux modèles dans le développement des applications. Cela implique l utilisation de langages graphiques dans lesquels les éléments de notation ont une signification claire et précise. Dans ce cadre, nous avons travaillé à améliorer l expression de la composition dans Uml. Notre apport a été de définir un modèle de composition hiérarchique identifiant quatre sous-types de relation de composition, en lieu et place des concepts initiaux d agrégation et de composition. L intérêt de notre approche est de s appuyer sur des propriétés de composition clairement définies pour caractériser les sous-types de composition. Cela améliore de manière significative le pouvoir d expression d Uml, et contribue à améliorer sa «sémantique», c est-à-dire à contraindre sa syntaxe [HR04]. Le second apport de notre contribution est l outillage que nous avons développé. D une part, il offre un support pour la mise en œuvre de modèles de conception basés sur notre modèle de composition, et assure le respect des propriétés de composition au niveau réalisation. En cela, notre proposition se situe dans la mouvance actuelle, consistant à offrir des environnements intégrés pour la réalisation des applications, comme les usines logicielles [GSCK04] par exemple. D autre part, il a permis de vérifier de manière pragmatique la cohérence de notre approche. Perspectives Nos travaux ne sont certes pas un aboutissement en soi. Ils ont ouvert des voies de recherche intéressantes que nous détaillons. Dans cette section, nous présentons diverses perspectives, à court et moyen termes, que nous comptons approfondir. Amélioration de la plate-forme de composition Une de nos perspectives à court terme concerne l amélioration de notre plate-forme de composition. Nous souhaitons travailler principalement sur l amélioration de l environnement WpcE. Deux points nous semblent intéressant à traiter. Actuellement, l environnement de déploiement n est pas totalement compatible avec le modèle de composition. En effet, nous avons été contraints à des modifications récentes du modèle. Nous n avons pas eu le temps de totalement les répercuter sur l outillage. L environnement de déploiement a été développé avec une première version du modèle fortement liée au modèle initial de [BHSPLB03]. Dans cette version, d une part toutes les propriétés initiales étaient présentes et ne correspondaient plus à certaines définitions que nous avons affinées (l encapsulation par exemple). D autre part, les sous-types de la relation Tout- Partie se limitaient à la redéfinition d agrégation-composition d Uml. Nous avons commencé ce travail. Un autre point sur lequel nous avons prévu de travailler est l adaptation de notre environnement de déploiement au modèle de composants Fractal. Actuellement notre environnement est lié à la technologie Java et au modèle de composants JavaBeans. Ces choix sont liés à l utilisation de la technologie Jmx. Or, dans le chapitre 2, nous avons montré l existence de modèles de composants plus performants. L application de notre environnement de composition à un modèle de composants de ce type est donc une étape naturelle à franchir. Cette perspective est motivée également par travaux connexes menés par la communauté. Le projet Fractal a notamment développé une extension Fractal - Jmx. Cela montre la faisabilité de cette approche et nous encourage à poursuivre dans cette voie. 146

157 Application à plusieurs nœuds de déploiement Notre modèle ne traite la composition que sur un seul nœud de déploiement. Il s agit là d une limite de notre approche. En effet, la tendance actuelle tend à aller vers des applications de plus en plus distribuées. Les aspects distribués introduisent de nouvelles contraintes vis-à-vis de la composition logicielle, en terme de QoS ou de sécurité par exemple. Dans ce cadre, une thèse est actuellement menée par Oliver Constant, en partenariat entre notre équipe et France Telecom R & D. Cette thèse s intéresse en particulier aux interfaces de configuration. Nous imaginons des mécanismes de combinaison, là encore basés sur la théorie de la relation Tout-Partie, qui offrent des moyens de fixer les valeurs de QoS au niveau des assemblages. Cette préoccupation est forte en ingénierie ligne de produits [Bos00] où il est nécessaire que les composants supportent des opérations de réglage ou de personnalisation, dynamiquement en particulier au moment du déploiement. Parallèlement, une autre thèse menée par Fabien Romeo, et financée par une ACI Jeune Chercheur 36, se propose d explorer plus en détail les langages de composition. En particulier, des travaux sont menés sur la composition des composants sur des architectures distribuées hétérogènes et sans fil (de la simple lampe au supercalculateur en passant par le téléphone mobile ou encore l assistant électronique). Cette thèse vise à fournir les concepts, modèles et outils nécessaires pour administrer les composants, leurs relations et leur comportements associés sur les machines cibles. L administration est axée sur la configuration des composants et l éventuelle reconfiguration dynamique de manière à assurer un réel pilotage (actions correctives possibles) sur l architecture à composants en fonctionnement. Contraintes de composition : vers une vérification décentralisée La composition logicielle distribuée met en exergue une autre limite de notre approche, toutefois moins pénalisante sur un seul nœud de déploiement : la vérification de certaines propriétés implique une vue centralisée de l application. Par exemple, la vérification de la propriété de non partageabilité nécessite une connaissance de la totalité des composants d une application et de leurs relations. Cela pose plusieurs problèmes. D une part, plus l application est de taille importante, plus le temps de vérification est long : à chaque vérification, l environnement doit considérer la totalité des composants de l application. Nous pensons qu une première solution pourrait être apportée par les mécanismes de l Approche Orientée Aspects (AOP). Notre équipe a d ailleurs commencé à travailler sur une idée similaire [BAMR03] dans le cadre de l application de la technologie BIT. D autre part, le problème de la centralisation pose la question de la pertinence d une même vérification pour tous les composants quelle que soit leur granularité. Pour illustrer cette remarque, imaginons un système centralisé dans une entreprise. On peut se demander si, pour chaque vérification, un sous-composant de faible granularité (Pile par exemple) doit être envisagé de la même manière qu un composant de forte granularité (comme le composant Gestion des stocks). Parmi les pistes à explorer, décomposer la vérification sur plusieurs niveaux hiérarchiques est une piste particulièrement intéressante. Cet axe de recherche pourrait être mené transversalement, en couplant nos travaux avec le domaine des systèmes multi-agents [Jac95], dans lequel ces problématiques sont connues et étudiées. Une première réflexion sur ce sujet nous a permis d imaginer la définition d agents légers coopératifs (un par type de propriété) chargés de surveiller le respect des propriétés de composition. L aspect coopératif permet un échange entre les agents basés sur des protocoles normalisés. Cette approche peut être adaptée pour prendre en compte plusieurs niveaux hiérarchiques. La Figure 7.5 illustre cette proposition. On y voit trois niveaux hiérarchiques différents ; à chaque niveau sont déployés les agents (les ronds dans la figure, chacun correspondant à une propriété à vérifier). 36 http :// bruel/cml/ 147

158 E Sh Sp Mt LD component Système de Paie component Gestion de Stock E Sh Sp Mt LD component A1 component A2 component A3 E Sh Sp Mt LD component B1 component B2 component B3 Fig. 7.5 Exemple d architecture couplant agents de composition et composants Vers l approche MDA L intérêt d utiliser Uml comme langage de modélisation est double. D une part, son côté standard de facto le rend tout naturellement éligible. D autre part, son indépendance vis-à-vis de tout modèle de déploiement lui permet d être le support pour la spécification de modèles Pim (Plateform Independant Model), au sens MDA. De plus, les mécanismes d extension d Uml autorisent, lorsque le langage est couplé avec des concepts spécifiques à une plate-forme distincte (c est le cas du profil Corba, par exemple), de spécifier des modèles Psm (Plateform Specific Model). Ce point est d ailleurs observé dans l introduction à Uml sur le site de l OMG : «a UML model can be either platform-independent or platform-specific» 37. D autre part, l environnement de déploiement que nous avons proposé nécessite le codage manuel des propriétés de composition. Or, toute intervention manuelle, dans l implémentation d un modèle, induit un risque d erreur dans le produit final. La définition d un moyen permettant de passer automatiquement du modèle de composition spécifié, à une application finie (ou du moins à un squelette d application dans lequel les propriétés de composition ont été automatiquement générées) est une extension naturelle de notre travail. Dans ce cadre, l application de notre proposition à un cadre MDA semble la meilleure piste. En premier lieu, il convient de définir un modèle Psm pour notre environnement de déploiement. Ensuite, il faut définir une transformation de notre modèle Pim vers un modèle Psm. Le modèle de composition garderait donc son indépendance en terme de plate-forme. Une transformation le projetterait vers le modèle spécifique de déploiement voulu (par exemple un modèle Uml détaillé dans lequel apparaîtraient les concepts propres à l environnement WpcE ou encore à Fractal). Une seconde transformation transformerait le modèle Psm en code. Notons qu une approche similaire a été menée avec succès dans le projet 37 http :// 148

159 ACCORD 38, avec la réalisation de deux profils spécifiques à des plates-formes, l un vers Ccm et l autre vers Ejb. Cette réussite plaide en faveur de cette perspective. Les travaux présentés dans ce document s inscrivent dans une dynamique actuelle se trouvant à la croisée de deux perspectives : d une part, la nécessité de définir une réelle sémantique dans les approches à base de diagrammes [HR04] ; d autre part, l orientation que semble prendre la communauté Uml, guidée par l Omg, vers le «tout» modèle. Cette orientation est de plus en plus affirmée comme le montre de nombreux travaux présentés lors de la dernière conférence Uml , mais surtout comme l indique le changement de thématique des conférences Uml qui deviennent les conférences MoDELS 40. Nous espérons que la lecture de ce document aura apporté des perspectives intéressantes et ouvert la porte à de futures recherches en ce sens. 38 Projet RNTL ACCORD, http :// 39 Voir le programme sur le site http ://ctp.di.fct.unl.pt/uml2004/ 40 Voir le site http :// 149

160 150

161 Bibliographie [AAG01] [ABB + 01] [ACC02a] [ACC02b] [Ach02] Hervé Albin-Amiot and Yann-Gaël Guéhéneuc. Meta-modeling Design Patterns : application to pattern detection and code synthesis. In Bedir Tekinerdogan, editor, Proceedings of ECOOP Workshop on Automating Object-Oriented Software Development Methods. Springer, June Collins Atkinson, Joachim Bayer, Christian Bunse, Erik Kamsties, Oliver Laitenberger, Roland Laqua, Dirk Muthig, Barbara Peach, Jurgen Wust, and Jorg Zettel. Component- Based Product Line Engineering with UML. Component Software. Addison-Wesley, Projet ACCORD. Assemblage de composant pas contrats : état de l art et de la standardisation. Technical report, RNTL, June Ce rapport pose les définitions des concepts utilisés dans le projet ACCORD. Il dresse notammant un état de la standardisation au moment du projet. Projet ACCORD. Conventions communes aux profils uml. Technical report, RNTL, June Franz Achermann. Forms, Agents and Channels - Defining Composition Abstraction with Style. PhD thesis, University of Berne - Institute of Computer Science and Applied Mathematics, Berne, January [AIS + 78] Christopher Alexander, Sara Ishikawa, Murray Silverstein, Max Jacobson, Ingrid Fiksdahl-King, and Shlomo Angel. A Pattern Language. Oxford University Press, 1st edition, August [All97] [And98] [AP03] [ART03] [BAMR03] Robert Allen. A Formal Approach to Software Architecture. PhD thesis, School of Computer Science, Carnegie Mellon University, Pittsburg, May André van der Hoek and Dennis Heimbigner and Alexandrer L. Wolf. Software Architecture, Configuration Management, and Configurable Distributed Systems : A Ménage à Trois. Technical Report, Department of Computer Science, University of Colorado, Boulder, Colorado, USA, David. H. Akehurst and Octavian Patrascoiu. Tooling Metamodels with Patterns and OCL. In Proceedings of the Metamodelling for MDA Workshop, York, November ARTIST. Roadmap : component-based design and integration platforms. Technical report, ARTIST Project IST , May Ce document est un résumé des techniques pour traiter des propriétés fonctionnelles et extra-fonctionnelles des composants et des systèmes à base de composant. Jean-Michel Bruel, Joao Araújo, Ana Moreira, and Albert Royer. Using Aspects to Develop Built-In Tests for Components. In Proceedings of the UML 2003 Workshop on Aspect Oriented Modeling with UML, San Francisco, CA, US, October

162 Bibliographie [Bar02] Franck Barbier. Composability for Software Components : an Appoach Based on the Whole-Part Theory. In Proceedings of the 8th IEEE International Conference on Engineering of Complex Computer Systems (ICECCS 2002), Greenbelt, Maryland, December [Bar03] Franck Barbier. Built-in test vade mecum - part v. Technical report, Component + Consortium, http :// [BB00] Jean-Marc Jézéquel Benoit Baudry, Yves Le Traon. Trustable Components : Yet Another Mutation-Based Approach. In proceedings of 1st Symposium on Mutation Testing, pages 69 76, San Jose, CA, October [BBB + 98] R. Balter, L. Bellissard, F. Boyer, M. Riveill, and J. Vion-Dury. Architecturing and Configuring Distributed Applications with Olan. In In Proceedings of IFIP International Conference on Distributed Systems Platforms and Open Distributed Processing (Middleware 98), The Lake District, [BBB + 00] [BBB03a] Felix Bachmann, Len Bass, Charles Buhman, Santiago Comella-Dorda, Fred Long, John Robert, Robert Seacord, and Kurt Wallnau. Volume II : Technical Concepts of Component-Based Software Engineering, 2nd Edition. Technical Report CMU/SEI TR-008, Carnegie Mellon Software Engineering Institute, May Franck Barbier, Nicolas Belloir, and Jean-Michel Bruel. Incorporation of test functionality into software components. In Proceedings of the 2nd International Conference on Commercial Off-The-Shelf (COTS)-Based Software Systems (ICCBSS 2003), Lecture Notes in Computer Science 2580, Ottawa, Canada, February 10-12, Springer. [BBB03b] Nicolas Belloir, Jean-Michel Bruel, and Franck Barbier. Application de la théorie de la relation Tout-Partie à la composition de composants logiciels. In Actes du XXIeme congrès Inforsid, pages Inforsid, June [BBB03c] Nicolas Belloir, Jean-Michel Bruel, and Franck Barbier. Whole-Part Relationships for Software Component Combination. In Gerhard Chroust and Christian Hofer, editors, Proceedings of the 29th Euromicro Conference on Component-Based Software Engineering, pages IEEE Computer Society Press, September [BBB04] Nicolas Belloir, Jean-Michel Bruel, and Franck Barbier. Intégration du test dans les composants logiciels. Ingénierie des composants dans les systèmes d information. Numéro spécial de la revue L Objet, 10(1) :89 102, [BBBR04] [BBFM99] Jean-Michel Bruel, Franck Barbier, Nicolas Belloir, and Fabien Roméo. Test de composants logiciels. In Mourad Oussalah, editor, Ingénierie des Composants : Principes et fondements, chapter 8. Vuibert, To be published. Patrick Behm, Paul Benoit, Alain Faivre, and Jean-Marc Meynadier. Météor : A Successful Application of B in a Large Project. In proceedings of FM 99 - Formal Methods, Lecture Notes in Computer Science 1708, pages Springer-Verlag, [BCS02] Eric Bruneton, Thierry Coupaye, and Jean Bernard Stefani. Recursive and dynamic software composition with sharing. In Seventh International Workshop on Component- Oriented Programming (WCOP02), Malaga, Spain, June [BCS03] Eric Bruneton, Thierry Coupaye, and Jean-Bernard Stefani. The Fractal Component Model. technical report, ObjectWeb Consortium, September Ce rapport est un tutorial informel, présentant le modèle de composant Fractal et son implémentation. [Ber01] Didier Bert. Proposition d un groupe de travail sur la méthode B. Technical report, IMAG, May

163 [BG01] [BG03] Jean Bézivin and Olivier Gerbé. Towards a Precise Definition of the OMG/MDA Framework. In Proceedings of the Conference on Automatonous Software Engineering (ASE 01), San Diego, CA, USA, November Sami Beydeda and Volker Gruhn. State of the art in testing components. In Proceedings of the International Conference on Quality Software, pages , Dallas, USA, November, IEEE Computer Society Press. [BGMR03] Jean Bézivin, Sébastien Gérard, Pierre-Alain Muller, and Laurent Rioux. MDA components : Challenges and Opportunities. In Metamodelling for MDA, York, England, November [BHSOG01a] Franck Barbier, Brian Henderson-Sellers, A.L. Opdahl, and M. Gogolla. The Whole-Part relationships in the Unified Modeling Language : a new approach. Unified Modeling Language : System Analysis, Design and Developpement Issues, pages , [BHSOG01b] Franck Barbier, Brian Henderson-Sellers, Andreas Opdahl, and Martin Gogolla. The Whole-Part Relationship in the Unified Modeling Language : A new Approach. In K. Siau and T. Halpin, editors, Unified Modeling Language : Systems Analysis, Design, and Development Issues, pages Idea Group Publishing, Hershey, PA, [BHSPLB03] [BJPW99] [BLB02] [BM04] [BO92] [BO03] [BO04] [Boe86] [Bos00] [BR04] [BRB04] Franck Barbier, Brian Henderson-Sellers, Annig Le Parc-Lacayrelle, and Jean-Michel Bruel. Formalization of the Whole-Part Relationship in the Unified Modeling Language. IEEE Transactions on Software Engineering, 29(5) : , May Antoine Beugnard, Jean-Marc Jézéquel, Noël Plouzeau, and Damien Watkins. Making components contract aware. IEEE Computer, 32(7) :38 45, July Franck Barbier, Annig Le Parc Lacayrelle, and Jean-Michel Bruel. Agrégation et Composition dans UML - Révision basée sur la théorie Tout-Partie. TSI (Techniques et sciences informatiques), 21(10), November Ghizlane El Boussaidi and Hafedh Mili. Les patrons de conception : représentation et mise en œuvre. Technical report, Equipe Latece - UQAM, Don Batory and Sean O Malley. The Design and Implementation of Hierarchical Software Systems With Reusable Components. ACM Transactions on Software Engineering and Methodology, 1(4) : , Jean-Michel Bruel and Ileana Ober. The new UML 2.0 Component Model : Critical View. In Erwin Grosspietsch and Konrad Klöckner, editors, Proceedings of the Work in Progress Session at the 29th Euromicro Conference, September Jean-Michel Bruel and Ileana Ober. Uml 2.0 composition support. submitted to Software and Systems Modeling, Barry Boehm. A Spiral Model of Software Development and Enhancement. ACM SIG- SOFT Software Engineering Notes, August Jan Bosch. Design and Use of Software Architectures - Adopting and Evolving a Product- Line Approach. Addison-Wesley, May Nicolas Belloir and Fabien Romeo. Vérification a priori de modèle de composition logicielle. In Actes du XXIIeme congrès Inforsid, pages Hermes, May Nicolas Belloir, Fabien Romeo, and Jean-Michel Bruel. Whole-Part based Composition Approach : a Case Study. In Magnus Larsson Ivica Crnkovic, editor, Proceedings of the 30th Euromicro Conference on Component-Based Software Engineering (to be published), pages 66 73, Rennes, France, September IEEE Computer Society Press. 153

164 Bibliographie [Bre02] [Bru96] [Bru02] [Bru03] [BSW03] [CD01] [CdAHS03] [Cer04] [CFN04] Erwan Breton. Contribution à la representation de processus par des techniques de métamodélisation. PhD thesis, Thèse de Doctorat de l Université de Nantes. N , 24 June Jean-Michel Bruel. FuZE : un environnement intégré pour l analyse formelle de logiciels distribués temps réels. PhD thesis, Université Paul Sabatier - Toulouse III, Toulouse, France, December Eric Bruneton. Un support d exécution pour l adaptation des aspects non-fonctionnels des applications réparties. PhD thesis, Institut National Polytechnique de Grenoble, Grenoble, October Eric Bruneton. Developping with fractal. technical report, ObjectWeb Consortium, September Ce rapport est un tutorial informel, présentant le modèle de composant Fractal et son implémentation. Jan Bosch, Clemens Szyperski, and Wolfgang Weck. WS5. The Eighth International Workshop on Component-Oriented Programming (WCOP 2003). Workshop report, WCOP Co- Organizers, Ce rapport résume les contributions faites par les auteurs des positions papers acceptés aussi bien celles faites par tous les participants du workshop. John Cheesman and John Daniels. UML Components A Simple Process for Specifying Component-Based Software. Addison-Wesley, Arindam Chakrabarti, Luca de Alfaro, Thomas A. Henzinger, and Marielle Stoelinga. Resource Interfaces. In Proceedings of the Third International Conference on Embedded Software (EMSOFT), Lecture Notes in Computer Science. Springer-Verlag, Humberto Cervantes. Vers un modèle de composant orientés services pour supporter la disponibilité dynamique. PhD thesis, Université Joseph Fourier, Grenoble, March Cyril Carrez, Alessandro Fantechi, and Elie Najm. Contrats comportementaux pour un assemblage sain de composants. In Proceedings of Colloque Francophone sur l Ingénierie des Protocoles (CFIP 03), Paris, October [CH01] Bill Councill and George T. Heineman. Definition of a Software Component and Its Elements. In George T. Heineman and William T. Councill, editors, Component-Based Software Engineering, pages Addison Wesley, May [CHJK02a] [CHJK02b] [CJC02] Ivica Crnkovic, Brahim Hnich, Torsten Jonsson, and Zeynep Kiziltan. Basic Concepts in CBSE. In Ivica Crnkovic and Magnus Larsson, editors, Building reliable component-based software systems, pages Artech House Publishers, Boston, Ivica Crnkovic, Brahim Hnich, Torsten Jonsson, and Zeynep Kiziltan. Specification, Implementation, and Deployment of Components. Communications of the ACM, 45(10) :35 40, october Benneth Christiansson, Lars Jakobsson, and Ivica Crnkovic. Cbd process. In Ivica Crnkovic and Magnus Larsson, editors, Building reliable component-based software systems, pages Artech House Publishers, Boston, [CL00] Ivica Crnkovic and Magnus Larsson. A Case Study : Demands on Component-based Development. In Proceedings of 22th International Conference of Software Engineering Limerick, June [Col03] 154 Collins Atkinson and Hans-Gerhard Groß and Franck Barbier. Component Integration through Built-in Contract Testing. In Component-Based Software Quality : Methods and Techniques, volume 2693 of Lecture Notes in Computer Science, chapter 8, pages Springer-Verlag, 2003.

165 [Cra01] [Crn01] [Crn02] Craig B. Meyers and Patricia Oberndorf. Managing Software Acquisition : Open Systems and COTS Products. SEI Series in Software Engineering. Addisson Wesley, June Ivica Crnkovic. Component-based Software Engineering - New Challenges in Software Development. Software Focus, December Ivica Crnkovic. Component-based Software Engineering : Building systems from components. In COMPSAC 2002 Conference IEEE, August [DAC99] Jing Dong, Paulo S.C. Alencar, and Donald D. Cowan. Correct Compostion of Design Components. In Proceedings of the Fourth International Workshop on Component- Oriented Programming (WCOP 99), Lisbone, Portugal, [Dav01] [DFJ01] [DJL99] [Dup00] [DvdHT02] [EF02] [Fab03] [FHSG98] [FKV94] [FL01] [FM03] [Fow96] David Flanagan. JavaScript : The Definitive Guide. O Reilley, Cambridge, 4th edition, Daniel Deveaux, Patrice Frison, and Jean-Marc Jézéquel. Increase Software Trustability with Self-Testable Components in Java. In Proceedings 2001 australian software engineering conference (ASWEC 2001), Canberra - Australia, IEEE Computer Society Press. Daniel Deveaux, Jean-Marc Jézéquel, and Yves Le Traon. Self-testable components : from pragmatic tests to design-for-testability methodology. In in TOOLS Europe IEEE Computer Society Press, Sophie Dupuy. Couplage des notations semi-formelles et formelles pour la spécification des systèmes d information. PhD thesis, University of Grenoble I - LSR/IMAG, Grenoble, September Eric M. Dashofy, André van der Hoek, and Richard N. Taylor. An Infrastructure for the Rapid Development of XML-based Architecture Description Languages. In Proceedings of the 24th International Conference on Software Engineering (ICSE2002), pages , Orlando, FL, USA, ACM Press. Jacky Estublier and Jean-Marie Favre. Component models and technology. In Ivica Crnkovic and Magnus Larsson, editors, Building reliable component-based software systems, pages Artech House Publishers, Boston, Fabien Romeo. Composabilité des composants logiciels et test intégré. Technical report, Mémoire de DEA Programmation et Système, Université Paul Sabatier, Toulouse III, Toulouse, Donald Firesmith, Brian Henderson-Sellers, and Ian Graham. Open Modeling Language (OML) - Reference Manual. Cambridge University Press, Marteen D. Fraser, Kuldeep Kumar, and Vijay K. Vaishnavi. Strategies for incorporating formal specifications in software development. Communications of the ACM, 10(37) :74 86, October Marcus Fontoura and Carlos Lucena. Extending UML to Improve the Representation of Design Patterns. Journal of OO Programming, 13(11), March Xavier Franch and Neil A. M. Maiden. Modelling Component Dependencies to Inform Their Selection. In Proceedings of the 2nd International Conference on Commercial Off- The-Shelf (COTS)-Based Software Systems (ICCBSS 2003), Lecture Notes in Computer Science 2580, Ottawa, Canada, February 10-12, Springer. Martin Fowler. Analysis Patterns : Reusable Object Models. Object Technology Series. Addison Wesley Professional, October

166 Bibliographie [Fre91] [GAB + 02] [GAO95] [GGGS02] Roy S. Freedman. Testability of Software Components. IEEE Transactions on Software Engineering, 6(17), June Hans-Gerhard Groß, Colin Atkinson, Franck Barbier, Nicolas Belloir, and Jean-Michel Bruel. Built-in contract testing for component-based development. In Franck Barbier, editor, Business Component-Based Software Engineering, pages Kluwer Academic Publishers, David Garlan, Robert Allen, and John Ockerbloom. Architectural Mismatch, or, Why it s hard to build systems out of existing parts. In Proceedings of the 17th International Conference on Software Engineering, pages , Seattle, Washington, april Jerry Gao, Kamal Gupta, Shalini Gupta, and Simon Shim. On Building Testable Software Components. In Proceedings of First International Conference on COTS-Based Software Systems, ICCBSS 2002, Lecture Notes in Computer Science 2255, pages , Orlando, FL, USA, February 4-6, Springer LNCS. [GHJV95] Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides. Design Patterns : Element of Reusable Object-Oriented Software. Addison-Wesley, [GLAM + 04] [GMW97] Arnaud Georgin, Fabrice Legond-Aubry, Selma Matougui, Nicolas Moteau, Alexis Muller, Alexandre Tauveron, Jean-Philippe Thibault, and Bruno Traverson. Description des assemblages et des contrats pour la conception par composants - Le projet ACCORD. In Proceedings of Journées Composants (JC 04), Lille, March David Garlan, Robert Monroe, and Dave Wile. Acme : An Architecture Description Interchange Language. In Proceedings of of CASCON 97, pages , Toronto, Ontario, November [Gri97] Richard Grimes. Professional DCOM Programming. Wrox Press, Inc., Chicago, IL, [Gro91] [Gsc02] [GSCK04] HOOD Technical Group. Hood reference manual issue 3.1. Technical report, HOOD User Group, Thomas Gschwind. Adaptation and Composition Techniques for Component-Based Software Engineering. PhD thesis, Technische Universität Wien, March Jack Greenfield, Keith Short, Steve Cook, and Stuart Kent. Software Factories : Assembling Applications with Patterns, Models, Frameworks, and Tools. Wiley Publishing Inc., Indianapolis, IN, US, [Hab01] Henri Habrias. Spécification formelle avec B. Hermès, Lavoisier, [Har87] David Harel. Statecharts : a visual formalism for complex systems. Science of Computer Programming, 8 : , [Har00] Mary Jean Harrold. Testing : A Roadmap. In ICSE - Future of SE Track, pages 61 72, [Hig01] High Confidence Software and Systems Coordinating Group. High confidence software and systems research needs. Technical report, Interagency Working Group on Information Technology Research and Development, january [HR04] David Harel and Bernhard Rumpe. Meaningful Modeling : What s the Semantics of "Semantics"? IEEE Computer, 37(10) :64 72, October [HSB99a] 156 Brian Henderson-Sellers and Franck Barbier. Black and Whites Diamonds. In Robert France and Bernhard Rumpe, editors, UML 99 The Unified Modeling Language, Lecture Notes in Computer Science 1723, pages Springer-Verlag, October 1999.

167 [HSB99b] Brian Henderson-Sellers and Franck Barbier. What is this thing called agreggation. In proceedings of TOOLS EUROPE, pages , [ISO98] ISO. Open Distributed Processing - Reference Model. ISO document ISO/IEC , 2, 3, 4, ISO, [ISW02] [Jac95] [JBR99] [JDL01] James Ivers, Nishant Sinha, and Kurt Wallnau. A Basis for Composition Language CL. Technical Report CMU/SEI-2002-TN-026, Carnegie Mellon, Software Engineering Institute, Jacques Ferber. Les Systèmes Multi-Agents, vers une intelligence collective. InterEditions, Ivar Jacobson, Grady Booch, and James Rumbaugh. The unified software development process. Addison-Wesley Object Technology Series, Jean-Marc Jézéquel, Daniel Deveaux, and Yves Le Traon. Reliable objects : a lightweight approach applied to java. IEEE Software, 18(4) :76 83, July-August [Jea96] Jean-Guy Schneider and Markus Lumpe. Modelling Objects in PICT. Technical Report n : IAM , University of Bern, Institute of Computer Science and Applied Mathematics, Berne, Swiss, January [Joh94] [Joh97] [Jos98] [JPWG01] John K. Ousterhout. Tcl and the Tk Toolkit. Professional Computing Series. Addison- Wesley, Ralph E. Johnson. Frameworks = Components + Patterns. Communications of the ACM, 40(10) :39 42, Jos Warmer and Anneke Kleppe. The object constraint language : precise modeling with UML. Object Technology. Addisson Wesley, Boston, Jean-Marc Jézéquel, Noël Plouzeau, Torben Weis, and Kurt Geihs. From Contracts to Aspects in UML Designs, [Kil99] Haim Kilov. Business Specification : The Key to Successful Software Engineering. Prentice-Hall, [Kin02] [KS98] [Kur01] Joseph R. Kinitry. Semantic Component Composition. In Proceedings of the ACM SIG- PLAN/SIGSOFT Conference on Generative Programming and Component Engineering (GPCE 02), October, Rudolf K. Keller and Reinhard Schauer. Design Components : Towards Software Composition at the Design Level. Proceedings of the 1998 International Conference on Software Engineering, 40(10) : , April Kurt Wallnau and Scott A. Hissam and Robert C. Seacord. Building systems from commerical components. SEI Series in Software Engineering. Addisson Wesley, Boston, June [Lar99] Larousse, editor. Le petit Larousse grand format. Larousse, [Lar01] [Led02] Larry Wall and Tom Christiansen and Jon Orwant. Programming Perl. O Reilley, Cambridge, 3rd edition, Hung Ledang. Traduction systématique de spécifications UML en B. PhD thesis, University of Nancy 2 - LORIA, Nancy, November [Les89] Stanislaw Lesniewski. Sur les fondements de la mathématique - Fragments. Hermes, Traduction de Georges Kalinowski. 157

168 Bibliographie [LFA02] [LSS + 03] [Mar02] [MDEK95] Kevin Lano, Jose Luiz Fiadeiro, and Luis Filipe De Andrade. Software Design Using Java 2. Palgrave Macmillan, October Markus Lumpe, Jean-Guy Schneider, Bastiaan Schönhage, Markus Bauer, and Thomas Genssler. Composition Languages. In Frank Buschmann, Alejandro P. Buchmann, and Mariano A. Cilia, editors, Proceedings of Object-Oriented Technology : ECOOP 2003 Workshop Reader, pages Springer, December Raphaël Marvie. Séparation des préoccupations et méta-modélisation pour environnement de manipulation d architectures logicielles à base de composants. Thèse en informatique, Laboratoire d Informatique Fondamentale de Lille, Lille, Jeff Magee, Naranker Dulay, Susan Eisenbach, and Jeff Kramer. Specifying Distributed Software Architectures. In Proc. of 5th European Software Engineering Conference (ESEC 95), Lecture Notes in Computer Science 989, pages , Sitges, September Springer-Verlag. [Mey92] Bertrand Meyer. Eiffel : The Language. Prentice Hall, [Mey97] [Mey00] Bertrand Meyer. Object-Oriented Software Construction. Prentice Hall, Second Edition, Bertrand Meyer. Contracts for Components. Software Development, 8(7) :51 53, July [Mey03] Bertrand Meyer. The grand challenge of trusted components. In ICSE 25, Portland, Oregon, May IEEE Computer Press, [MGG97] Philippe Merle, Christophe Gransart, and Jean-Marc Geib. Using and Implementing CORBA Objects with CorbaScript. In Proceedingsd of the Object Based Parallel and Distributed Computing Workshop, Toulouse, France, October [Mic] Microsoft. Microsoft Visual Basic. http ://msdn.microsoft.com/vbasic/. [Mic97] Sun Microsystems. Java beans specification v.1.1, July Sun Microsystems, http ://- java.sun.com/products/javabeans/docs/spec.html. [Mic99] Sun Microsystems. Enterprise Java Beans Specifications, V1.1., May http ://- java.sun.com/products/ejb/. [Mic01] Sun Microsystems. Long-term persistence for javabeans, http ://- java.sun.com/products/jfc/tsc/articles/persistence/. [Mic02] Sun Microsystems. The bean builder tutorial, téléchargeable sur http ://- java.sun.com/products/javabeans/beanbuilder/. [MN98] Theo Dirk Meijler and Oscar Nierstrasz. Beyond Objects : Components. In Michael P. Papazoglou and Gunter Schlageter, editors, Cooperative Information Systems Trends and Directions, pages Academic Press, San Diego, CA, [MS03] [MSKC04] Sotiris Moschoyiannis and Michael W. Shields. Component-Based Design : Towards Guided Composition. In Proceedings of the Third International Conference on Application of Concurrency to System Design (ACSD 03), Guimarães, Portugal, June Philip K. McKinley, Seyed Masoud Sadjadi, Eric P. Kasten, and Betty H. C. Cheng. Composing Adaptive Software. IEEE Transactions on Software Engineering, 37(7) :56 64, July [MT00] Nenad Medvidovic and Richard N. Taylor. A Classification and Comparaison Framework for Software Architecture Description Languages. IEEE Transactions on Software Engineering, 26(1) :70 93, january

169 [NM95] [OBS00] [Ode94] Oscar Nierstrasz and Theo Dirk Meijler. Research Directions in Software Composition. ACM Computing Surveys, 27(2) : , June Tricia Oberndorf, Lisa Brownsword, and Carol A. Sledge. An Activity Framework for COTS-Based Systems. Technical Report CMU/SEI-2000-TR-010, Carnegie Mellon Software Engineering Institute, October James J. Odell. Six Different Kinds of Composition. Journal of Object-Oriented Programming, 7(8) :10 15, [OGJ03] Johann Oberleitner, Thomas Gschwind, and Mehdi Jazayeri. The Vienna Component Framework : Enabling Composition Across Component Models. In Proceedings of the 25th International Conference on Software Engineering (ICSE2003), Portland, Oregon, USA, May [OMG99a] [OMG99b] [OMG01a] [OMG01b] [OMG01c] OMG. CORBA Component Model, april http :// OMG. White Paper on the Profile mechanism - version 1.0. OMG document ad/ , Object Management Group, April OMG. Common Warehouse Metamodel (CWM) Specification. OMG document, Object Management Group, February OMG. UML Profile for CORBA Specification, V 1.0. Technical report, Object Management Group, October OMG. Unified Modeling Language (UML) Specification, verion 1.4. OMG document, Object Management Group, [OMG02a] OMG. Common Object Request Broker Architecture (CORBA) : Core Specification. OMG document, Object Management Group, December [OMG02b] OMG. UML Profile for Enterprise Distributed Object Computing Specification, may http :// [OMG02c] [OMG03a] OMG. XML Metadata Interchange (XMI)Specification, V 1.2. OMG document formal/ , Object Management Group, February OMG. Meta Object Facility MOF) Specification, Version 1.3. OMG document, Object Management Group, March [OMG03b] OMG. UML 2.0 Infrastructure Adopted Specification ptc-o OMG document, Object Management Group, [OMG03c] [OMG03d] [OMG03e] [OMG03f] [Omm02] OMG. UML 2.0 OCL Specification. OMG document ptc/ , Object Management Group, October OMG. UML 2.0 Superstructure Final Adopted specification ptc-o OMG document, Object Management Group, August OMG. UMLTM Profile for Schedulability, Performance, and Time Specification, Version 1.0. OMG document, Object Management Group, OMG. Unified Modeling Language (UML) Specification, verion 1.5. OMG document, Object Management Group, March Rob Van Ommering. The koala component model. In Ivica Crnkovic and Magnus Larsson, editors, Building reliable component-based software systems, pages Artech House Publishers, Boston,

170 Bibliographie [Paz00] [Paz02] [Pet03] Luca Pazzi. Part-whole statecharts for the explicit representation of compound behaviors. In Andy Evans, Stuart Kent, and Bran Selic, editors, UML The Unified Modeling Language. Advancing the Standard. Proceedings of the Third International Conference, UK, volume 1939 of Lecture Notes in Computer Science, pages , York, October Springer. Lucca Pazzi. Part-Whole Statecharts, or How I Learned to Turn the Explicit Attitude of Composition Languages on My Side. In Proceedings of Workshop on Composition languages, ECOOP02, Málaga, 11 june Dorian Petit. Génération automatique de composants logiciels sûrs à partir de spécifications formelles B. Thèse de doctorat, université de Valenciennes et du Hainaut-Cambrésis, Valenciennes, December [Pfl01] Shari Lawrence Pfleeger. Software Engineering : Theory and Practice, second edition. Prentice Hall, February [PK90] DeWayne E. Perry and Gail E. Kaiser. Adequate testing and object-oriented programming. Journal of Object-Oriented Programming, 2(5) :13 19, September [PMP03] Dorian Petit, Georges Mariano, and Vincent Poirriez. Génération de composant à partir de spécifications B. In Proceedings of the conférence on Approches Formelles dans l Assistance au Développement de Logiciels (AFADL 2003), Rennes, France, january 15-17, disponible en ligne à l adresse suivante : http :// [Rog96] Dale Rogerson. Inside COM. Microsoft Press, Redmond, WA, [SA02] [SDK + 95] [SGJ00] [SGM01] [SGM02] [SH04] Yasunobu Sanada and Rolf Adams. Representing Design Patterns and Frameworks in UML - Towards a Comprehensive Approach. Journal of OO Programming, 1(2), July Mary Shaw, Robert DeLine, Daniel V. Klein, Theodore L. Ross, David M. Young, and Gregory Zelzsnik. Abstractions for Software Architectures and Tools to Support Them. IEEE Transactions on Software Engineering, april Gerson Sunyé, Yann Le Guennec, and Jean-Marc Jézéquel. Design Pattern Application in UML. In Proceedings of 16th European Conference on Object-Oriented Programming (ECOOP 2000), pages 44 62, Malaga, Spain, June Clemens Szyperski, Dominik Gruntz, and Stephan Murer..NET Framework Essentials. Programming Series. O Reilly, June Clemens Szyperski, Dominik Gruntz, and Stephan Murer. Component Software Beyond Object-Oriented Programming Second Edition. ACM Press. Addison-Wesley, New York, NY, Jean-Guy Schneider and Jun Han. Components - the Past, the Present, and the Future. In Clemens Szyperski, Wolfgang Weck, and Jan Bosch, editors, Proceedings of Ninth International Workshop on Component-Oriented Programming (WCOP 2004), Oslo, Norway, June to appear. [Sin03] Harshit Singhal. Internal Report. Technical Report, Pramati Inc, Avaliable at [SML99] Linda Seiter, Mira Mezini, and Karl Lieberherr. Dynamic component gluing. In Ulrich Eisenecker and Krzysztof Czarnecki, editors, First International Symposium on Generative and Component-Based Software Engineering, Erfurt, Germany, Springer LNCS

171 [SN99] [Sof99] Jean-Guy Schneider and Oscar Nierstrasz. Components, Scripts and Glue. In Software Architectures - Advances and Applications, pages Leonor Barroca, Jon Hall, and Patrick Hall Editions, Springer-Verlag, Softeam. UML Profiles and the J language : Totally control your application development using UML, http :// White Paper. [Som01] Ian Sommerville. Software engineering, 6th Edition. Addison-Wesley, [Sun00] Sun. JavaTM Management Extensions Instrumentation and Agent Specification (JMX) 1.0, http ://java.sun.com/products/javamanagement/. [Sun01] Sun. JavaTM Management Extensions (JMX) 1.1, http ://- java.sun.com/products/javamanagement/. [SW02] Judith A. Stafford and Kurt Wallnau. Component composition and integration. In Ivica Crnkovic and Magnus Larsson, editors, Building reliable component-based software systems, pages Artech House Publishers, Boston, [Tea97] Rapid Design Team. Rapide 1.0 Language Reference Manuals, [TMA + 96] [Tra04] [Vil03a] [Vil03b] [VKLK02] [VM95] Richard N. Taylor, Nenad Medvidovic, Kenneth M. Anderson, E. James Whitehead, Jr., Jason E. Robbins, Kari A. Nies, Peyman Oreizy, and Deborah L. Dubrow. A componentand message-based architectural style for gui software. IEEE Transactions on Software Engineering, 22(6) : , Yves Le Traon. Contribution au test de logiciels orientés-objet. Habilitation à diriger des recherches, Université de Rennes 1, Rennes, France, July Jorge Villalobos. Fédération de composants : une architecture logicielle pour la composition par coordination, Transparents de soutenance de thèse. Jorge Villalobos. Fédération de composants : une architecture logicielle pour la composition par coordination. PhD thesis, Université Joseph Fourier, Grenoble, July Jonathan Vincent, Graham King, Peter Lay, and John Kinghorn. Principles of Built-In- Test for Run-Time-Testability in Component-Based Software Systems. Software Quality Journal, 10(2) : , September Jeffrey M. Voas and Keith W. Miller. Software testability : The new verification. IEEE Software, 12(3) :17 28, May [Voa98] Jeffrey M. Voas. Cots software : the economical choice? IEEE Software, 15(2) :16 19, [vovdlkm00] Rob van Ommering, Frank van der Linden, Jeff Kramer, and Jeff Magee. The Koala Component Model for Consumer Electronics Software. IEEE Computer, pages 78 85, March [Wal95] Walter Hürsch and Cristina Videira Lopes. Separation of concerns. Technical report, Northeastern University, February [WBGP01] Torben Weis, Christian Becker, Kurt Geihs, and Noël Plouzeau. A UML Meta-model for Contract Aware Components. In C. Kobryn M. Gogolla, editor, Proceedings of UML The Unified Modeling Language.Modeling Languages, Concepts, and Tools, Lecture Notes in Computer Science2185, pages Springer-Verlag, [WCD + 01] Sanjiva Weerawarana, Francisco Curbera, Matthew J. Duftler, David A. Epstein, and Joseph Kesselman. Bean Markup Language : A Composition Language for JavaBeans Components. In Proceedings of 6th Conference on Object-Oriented Technologies ans Systems (COOTS 2001),

172 Bibliographie [WD01] Roel Wuyts and Stéphane Ducasse. Composition Languages for Black-Box Components. In Proceedings of First OOPSLA Workshop on Language Mechanisms for Programming Software Components, [Wey98] Elaine Weyuker. Testing Issues for Component-Based Software - A Cautionary Tale. IEEE Software, 15(5) :54 59, [WKF + 98] [WS01] [ZTJ02] Yingxu Wang, Graham King, Mohamed Fayad, Dilip Patel, Ian Court, Geoff Staples, and Margaret Ross. On Built-in Test and Reuse in Object-Oriented Programming. ACM Software Engineering Notes, 23(4) :60 64, Kurt Wallnau and Judith Stafford. Ensembles : Abstractions for a new class of design problem. In Workshop in Software Model Engineering, Warsaw, Poland, September Tewfik Ziadi, Bruno Traverson, and Jean-Marc Jézéquel. From a UML Platform Independent Component Model to Platform Specific Component Models. In Jean Bézivin and Robert France, editors, Workshop in Software Model Engineering,

173 Annexes 163

174

175 Annexe A Les contraintes Ocl Cette annexe décrit les règles Ocl contraignant les définitions des propriétés de composition. Le métaschéma sur lequel elles s appliquent est donné à la page 95. La plupart des règles Ocl suivantes sont des adaptations des règles définies dans [BHSPLB03]. La sémantique des règles est sensiblement la même, puisque nous nous appuyons sur la même base sémantique, la relation Tout-Partie, mais leur contexte est différent puisqu elles ne caractérisent plus le monde général de la conception objet mais celui de la modélisation des compositions de composants, et ne s appuient donc pas sur le même métaschéma. A.1 Contraintes de la relation de composition A Nature binaire Nous considérons l existence des opérateurs part et whole, donnant respectivement l ensemble des composant Partie liées à un Tout donné et inversement, et définis dans [BHSPLB03] pour la conception orientée objet. Ce sont des ensembles duaux, c est à dire qu il s agit de deux relations mathématiques différentes mais représentant la même chose. Les deux invariants suivants permettent de matérialiser cette dualité. 1 context VerticalComponentRelationship inv : 2 s e l f. wholemember. compinstance >forall 3 (w w. part. oclistypeof ( Set ( partmember ) ) ) 4 s e l f. partmember. compinstance >forall 5 ( p p. whole. oclistypeof ( Set ( wholemember ) ) ) Cet invariant indique que self.wholemember est un composant jouant le rôle du Tout, et self.partmember est un composant jouant le rôle de la Partie. Ces deux composants appartiennent à la métaclasse Component. La navigation entre les instances des deux composants se fait via les opérateurs part et whole. Ces opérateurs incarnent en Ocl notre besoin initial. L axiome suivant, nommé Snapshot, définit formellement la dépendance entre les opérateurs part et whole. 1 context VerticalComponentRelationship inv Snapshot : 2 wholemember. compinstance >forall (w w. part >forall ( p p. whole 3 >i n c l u d e s (w) ) ) 4 partmember. compinstance >forall ( p p. whole >forall (w w. p a r t 5 >i n c l u d e s ( p ) ) ) 165

176 Annexe A. Les contraintes Ocl Soit un composant w, w.part donne les composants de w dans le cadre d une et une seule relation wp entre un type wp.wholemember (w appartient à wp.wholemember) et un type wp.partmember. On peut faire ce même raisonnement pour un composant p. L axiome précédent définit le fait que part et whole sont des fonctions symétriques. Un second axiome nommé history introduit hasforpart et hasforwhole comme deux nouvelles métapropriétés de même que leur relation. En fait, w.part correspond à l ensemble des composants du composé w au temps t, alors que w.hasforpart correspond à l ensemble des composants du composé w tout au long de son cycle de vie. Par symétrie, il en est de même pour p.whole et hasforwhole. 1 context VerticalComponentRelationship inv History : 2 wholemember. compinstance >forall (w w. hasforpart > 3 forall ( p p. hasforwhole >i n c l u d e s (w) ) ) 4 partmember. compinstance >forall ( p p. hasforwhole > 5 forall (w w. hasforpart >i n c l u d e s ( p ) ) ) Notons que w.hasforpart (respectivement p.hasforwhole) correspond à l ensemble des w.part@t (respectivement p.whole@t), où t correspond à un instant donné selon un ensemble fini discret de snapshots pour w (respectivement p). Le symbole (@) incorpore la valeur de l expression à t. Finalement, la relation entre part et hasforpart (respectivement whole et hasforwhole) est requise : 1 context VerticalComponentRelationship inv I n c l u s i o n : 2 wholemember. compinstance >forall (w w. hasforpart > 3 i n c l u d e s A l l (w. part ) ) 4 partmember. compinstance >forall ( p p. hasforwhole > 5 i n c l u d e s A l l ( p. whole ) ) A Asymétrie au niveau instance Nous devons définir la propriété d irréflexivité et d anti-symétrie. La définition de l irréflexivité est la suivante : 1 context VerticalComponentRelationship inv I r r e f l e x i v i t e : 2 thewhole. compinstance >forall (w w. ocliskindof ( partmember ) 3 implies not w. part >i n c l u d e s (w) ) 4 thepart. compinstance >forall ( p p. ocliskindof ( wholemember ) 5 implies not p. whole >i n c l u d e s ( p ) ) La définition précédente permet, dans le cas où les même composants peuvent être en même temps composant et composé, de d assurer qu un composant ne peut jamais être lié à lui-même. La définition de l anti-symétrie est la suivante : 1 context V e r t i c a l ComponentRelationship inv Antisymetrie : 2 thewhole. compinstance >forall (w w. ocliskindof ( partmember ) implies w. whole 3 >forall ( x w. part >i n c l u d e s ( x ) implies w = x ) ) 4 l e t Whole : String = s e l f. wholemember in 5 thepart. compinstance >forall ( p p. ocliskindof ( wholemember ) implies p. part 6 >forall ( x p. whole >i n c l u d e s ( x ) implies p = x ) ) 166

177 A Anti-symétrie au niveau type Le principe est d empêcher qu il existe simultanément une relation Tout-Partie X - Y et une relation Tout-Partie Y - X. Si c est le cas, il faut que ce soit la même. 1 context wp1, wp2 : VerticalComponentRelationship inv 2 AntisymetrieNiveauType : 3 wp1. wholemember = w2. partmember and wp1. partmember = wp2. wholemember 4 implies wp1 = wp2 A Encapsulation L encapsulation apporte une notion de contenance structurelle. Ocl n apporte pas de moyen permettant de traduire cette contenance structurelle. Remarquons que cette propriété est proche d une heuristique de modélisation et que sa réalisation dépend de la technologie supportant les composants. A Partageabilité Le partage locale et le partage global sont des propriétés d autorisation, c est à dire qu elles permettent de faire quelque chose. Leur spécification en terme de règle Ocl n ont donc pas d intérêt. Nous traduisons l exclusion locale en Ocl par le fait que dans une relation Tout-Partie, la cardinalité maximale du Tout est inférieure ou égale à un. Cela se traduit par : 1 context VerticalComponentRelationship inv E x c l u s i o n L o c a l e : 2 s e l f. partmember. compinstance >forall ( p p. whole. s i z e <= 1) L exclusion globale revient à dire que si deux relations Tout-Partie ont le même composant Partie, alors les composants Tout sont forcément de type différents. La traduction de l exclusion globale est : 1 context wp1, wp2 : VerticalComponentRelationship inv 2 ExclusionGlobale : 3 wp1 <> wp2 and wp1. partmember = wp2. partmember implies 4 wp1. partmember. compinstance > 5 forall ( p wp1. wholemember. compinstance > 6 e x i s t s (w w. part >i n c l u d e s ( p ) ) 7 implies wp2. wholememeber. compinstance > 8 forall (w not w. part >incudes ( p ) ) ) A Séparabilité et mutabilité La spécification Ocl de l immutabilité est la suivante. Elle est composée de deux règles Ocl et a été prouvée mathématiquement dans l article initial : 1 context VerticalComponentRelationship inv Immutability ( 1 e r e 2 p a r t i e ) : 3 partmember. compinstance >forall ( p p. hasforwhole = p. whole ) 1 context VerticalComponentRelationship inv Immutability : 2 wholemember. compinstance >forall (w w. hasforpart = w. p a r t ) 167

178 Annexe A. Les contraintes Ocl A Dépendance de cycle de vie Dans la Figure 4.11 page 81, les cas (3), (4) et (9) signifient qu aucune instance du composant Partie n existe dans la relation avant que ne soit créée l instance du composant Tout correspondante. 1 context 2 VerticalComponentRelationship. wholemember : : c r e a t i o n ( ) : Whole 3 post : r e s u l t. hasforpart >forall ( p p. oclisnew or 4 p@pre. oclundefined ) p.oclisnew indique que les composants de result sont créés en même temps que result et [email protected] que les composants de result n existent pas au départ de l opération. Pour des besoins spécifiques, nous introduisons la fonction oclundefined (non présente actuellement dans Ocl) afin de s assurer que tous les composants de result n existent pas (@) avant l exécution de l opération VerticalComponentRelationship.wholeMember : :creation(). Ensuite, dans les cas (1), (2) et (8), il y a simultanéité de naissance. Nous traduisons cela de la manière suivante : 1 context 2 VerticalComponentRelationship. wholemember : : c r e a t i o n ( ) : Whole 3 post : r e s u l t. hasforpart >forall ( p p. oclisnew ) Finalement, les cas (5),(6) et (7) donnent : 1 context 2 VerticalComponentRelationship. wholemember : : c r e a t i o n ( ) : Whole 3 post : r e s u l t. hasforpart >forall ( p p. oclisnew or not p@pre. oclundefined ) De manière similaire, nous avons analysé les relations de fin de cycle de vie entre composant et composé. Dans les cas (2),(4) et (7), tout ou partie des composants doivent être supprimés avant le composé. Si ce n est pas le cas, ils sont supprimés en même temps que le composé. 1 context VerticalComponentRelationship. wholemember : : d e l e t i o n ( ) 2 pre : s e l f. hasforpart >e x i s t s ( p p. oclundefined ) 3 post : s e l f. oclundefined and s e l p r e. hasforpart >forall ( p p. oclundefined ) Dans les cas (1),(3) et (6) sont supprimés sous conditions strictes en même temps que le composé (simultanéité de mort) : 1 context VerticalComponentRelationship. wholemember : : d e l e t i o n ( ) 2 pre : s e l f. hasforpart >forall ( p not p. oclundefined ) 3 post : s e l f. oclundefined and s e l p r e. hasforpart >forall ( p p. oclundefined ) Dans les cas (5),(8) et (9), tout ou partie des composants peuvent survivre au composé (postcondition), mais ne peuvent pas être supprimés avant lui (pré-condition) : 168

179 1 context VerticalComponentRelationship. wholemember : : d e l e t i o n ( ) 2 pre : s e l f. hasforpart >forall ( p not p. oclundefined ) 3 post : s e l f. oclundefined and s e l p r e. hasforpart >e x i s t s ( p not p. oclundefined ) 169

180 Annexe A. Les contraintes Ocl 170

181 Annexe B Présentation de Jmx Cette annexe présente Jmx et ses possibilités. B.1 Introduction à JMX Jmx permet la gestion de composants java distribués ou non appelés MBeans. Ces MBeans implémentent une interface java qui contient les attributs et les méthodes que l on peut manipuler en cours d exécution. Afin de faciliter la manipulation des MBeans, Jmx offre aussi une interface de gestion graphique accessible via un navigateur Web. L architecture Jmx se compose de trois niveaux : Instrumentation Agent Services distribués B.1.1 Le niveau instrumentation Il fournit une spécification composée d une documentation technique et d une API, pour implémenter les ressources gérables par Jmx. Ces ressources peuvent être une application, l implémentation d un service, un périphérique,... B.1.2 Le niveau agent Ce niveau correspond au niveau qui va gérer les ressources. Les agents de gestion contrôlent directement les ressources et les rendent disponibles aux applications de gestion. Un agent est composé : d un serveur de MBeans ; de MBeans ; de services agents ; d au moins un protocole adaptateur ou un connecteur. Un serveur de MBeans sert de registre de MBeans pour l agent Jmx et il fournit les services pour administrer et manipuler les MBeans. Les services agents offrent à l utilisateur des facilités pour gérer les MBeans. Les services disponibles sont : 171

182 Annexe B. Présentation de Jmx Fig. B.1 Architecture simplifiée de Jmx le Dynamic class loading qui permet le chargement de MBeans disponibles sur une machine distante ; les Monitors qui permettent de contrôler automatiquement et à intervalles réguliers que la valeur d un attribut ne dépasse pas un seuil défini ; les Timers qui permettent d envoyer des messages à des MBeans afin de les synchroniser ; le relation service qui permet d associer des MBeans. Un protocole adaptateur ou un connecteur servent d intermédiaire entre l agent et l application qui permet à l utilisateur de contrôler les MBeans, par exemple un navigateur Web. B.1.3 Le niveau services distribués La spécification n est pas encore fournie par Sun. Cependant, elle doit fournir les interfaces et les composants nécessaires aux applications de management pour opérer sur un agent. 172

183 B.2 Les MBeans B.2.1 Définition d un MBean Un MBean est une classe qui implémente son interface de gestion. Dans cette interface, on expose les attributs et méthodes qui seront manipulables via l interface graphique Web. Il existe deux principales catégories de MBeans : Standard MBean ; Dynamic MBean. B.2.2 Les Standard MBeans Ils implémentent leur propre interface de gestion java. Le nom de cette interface est le nom de la classe suffixée par MBean. Cette interface expose les attributs et les opérations rendus accessibles par des fonctions publiques. Pour apparaître en tant qu attribut dans l interface graphique, les attributs doivent se conformer à un certain modèle. Ce modèle reprend le modèle des JavaBeans. Pour un attribut accessible en lecture, il faut créer une méthode de type get ; Pour un attribut accessible en écriture, il faut créer une méthode de type set ; Pour un attribut de type boolean accessible en lecture, il faut créer une méthode de type is. La Figure B.2 donne un exemple de code pour chaque cas cité précédemment. 1 public t y p e a t t r i b u t g e t a t t r i b u t ( ) 2 {return a t t r i b u t ; } 3 4 public void s e t a t t r i b u t ( t y p e a t t r i b u t v a l e u r ) 5 { a t t r i b u t=v a l e u r ; } 6 7 public boolean i s a t t r i b u t ( ) 8 {return a t t r i b u t ; } Fig. B.2 Partie du code généré du BitC Dans cet annexe, on utilisera l exemple simple de la pile. La pile est un composant possédant 3 attributs en lecture seule qui sont activeentry, entries et max. Elle ne possède pas d attribut en écriture car aucun attribut n est associé à une opération setnomattribut. Les opérations qui sont accessibles sont les fonctions dont le prototype se trouve dans l interface. Donc dans notre exemple, seules les fonctions push et pop peuvent être invoquées. Nous rencontrons ici un premier problème qui est le passage de paramètre de type objet. En effet, nous ne pouvons pas invoquer l opération push via l interface Web. Il faudrait pour cela pouvoir passer une référence d objet en paramètre, ce qui n est pas possible (voir la solution plus loin). 173

184 Annexe B. Présentation de Jmx Interface DynamicMBean +getmbeaninfo():mbeaninfo +getattribute(attribute:string):object +getattributes(attribute:string[]):atributelist +setattribute(attribute:string) +setattributes(attribute:atributelist):atributelist +invoke(actionname:string, params:object[], signature:string[]):object Fig. B.3 Interface DynamicMBean B.2.3 Les Dynamic MBeans Ils implémentent l interface DynamicMBean, dont le métatype est donné à la Figure B.3. Au lieu d exposer directement les attributs et opérations à travers des noms de méthodes, les dynamics MBeansimplémentent une méthode qui retourne la signature de tous les attributs et opérations. L opération builddynamicmbeaninfo() liste les attributs et leurs types, les opérations et leurs paramètres. De plus elle fournit des informations complémentaires pour décrire les attributs et les opérations. Pour cela elle utilise plusieurs fonctions. La Figure B.4 donne le prototype de l opération MBeanAttributeInfo. 1 public MBeanAttributeInfo ( java. lang. S t r i n g name, 2 java. lang. S t r i n g type, 3 java. lang. S t r i n g d e s c r i p t i o n, 4 boolean isreadable, 5 boolean i s W r i t a b l e, 6 boolean i s I s ) Fig. B.4 Prototype de la fonction MBeanAttributeInfo Paramètres : name : nom de l attribut ; type : le type de l attribut ; description : description de l attribut ; isreadable : True si l attribut a une méthode getter. Autrement dit s il est accessible en lecture ; iswritable : True si l attribut a une méthode setter. Autrement dit, s il est accessible en écriture ; is : True si l attribut a une méthode "is" getter. La Figure B.5 donne un exemple pour l attribut max. Le paramètre max est de type entier et est accessible en lecture seulement. On utilise de même les opérations MBeanConstructorInfo pour lister les constructeurs et MBeanOperationInfo pour les opérations. L opération getattribute(), à partir du nom d un attribut, retourne sa valeur. Elle est implémentée comme un switch qui, à un nom d attribut, associe une méthode qui retourne sa valeur. Ainsi le nom de 174

185 1 d A t t r i b u t e s [ 0 ] = new MBeanAttributeInfo ( "max", 2 " java. lang. I n t e g e r ", 3 "max : maximal number o f e n t r i e s [ 0.. max 1]", 4 true, 5 false, 6 f a l s e ) ; Fig. B.5 Exemple pour l attribut max l opération qui retourne la valeur de l attribut n a pas besoin de se conformer à la spécification Jmx. L opération setattribute(), à partir d un objet de type attribut qui contient à la fois le nom et la valeur de l attribut, met à jour la valeur de cet attribut. Dans notre exemple nous n avons aucun attribut accessible en écriture mais la méthode doit être implémentée. Les opérations getattributes() et setattributes() ont les mêmes fonctions que les deux précédentes mais elles s appliquent sur une liste d attributs. L opération invoke() invoque l opération spécifiée en paramètre. Il faut ensuite implémenter comme pour les standards MBeans, les opérations qui permettront d accéder aux attributs et aux méthodes de l objet. Ici ce sont les opérations push, pop et top. B.2.4 Comparaison entre les Standard et les Dynamic MBeans Les Dynamic MBeans permettent au programmeur d ajouter un texte descriptif à leurs attributs et opérations contrairement aux Standard MBeanspour lesquels un message générique non pertinent est inséré. Ce texte descriptif se retrouve dans l interface graphique Web lorsque l on clique sur le nom de l attribut ou de la méthode considérés. Cela renseigne l utilisateur sur la signification d un attribut ou sur le rôle d une méthode. Ils permettent également de réaliser des MBeans sans se conformer au modèle (méthodes getter et setter). Ainsi nous pouvons rendre un composant manageable sans modifier le nom de ses méthodes. L interface de gestion des Dynamic MBeans peut évoluer au cours de l exécution, ie on peut changer le nombre et le nom des attributs et des opérations accessibles. Malgré tous ces avantages l implémentation des Dynamic MBeans est lourde et fastidieuse par rapport aux Standard MBeans. B.2.5 Identification des MBeans Jmx définit un type ObjectName qui permet d identifier de manière unique les MBeans. L ObjectName d un MBean est donné à la Figure B.6. 1 [ nomdomaine ] : p r o p r i e t e=v a l e u r [, p r o p r i e t e = v a l e u r ] Fig. B.6 ObjectName d un MBean 175

186 Annexe B. Présentation de Jmx Pour retrouver un MBean, nous pouvons utiliser son nom complet ou des requêtes permettant de le retrouver à partir de ses caractéristiques (domaine et propriétés). Voici un exemple de requête : * :* correspond à tous les MBeans ; nomdomaine :* correspond à tous les MBeansdu domaine nomdomaine. B.2.6 L agent Le principe d écriture d un agent est le même pour les Standard et Dynamic MBeans. Cette description s appuiera sur l exemple de l agent du MBean Dynamic de la pile. Voici comment implémenter l opération main. Tout d abord, il faut créer un objet de type MBean- Server en utilisant l opération creatembeanserver de la classe MBeanServerFactory. Ensuite, il faut créer l adaptateur html et l enregistrer dans le serveur afin de disposer d une interface Web. Pour cela, on utilise le constructeur de la classe HtmlAdaptorServer qui peut prendre en paramètre le port sur lequel l interface Web se trouve. Par défaut, le port est fixé à Pour procéder à son enregistrement, il faut construire son ObjectName et utiliser l opération registermbean du serveur. Pour enregistrer les MBeans à manipuler, on utilise l opération creatembean du serveur, qui crée et, à la fois, enregistre les MBeans. Dans notre exemple, un objet StackDynamic d ObjectName «Dynamic_MBeans :name=stackdynamic» est ajouté. Cette opération peut aussi être effectuée via l interface graphique fournie par Jmx. Le serveur donne la possibilité d invoquer les opérations des MBeans enregistrés directement à partir de l agent grâce à l opération invoke(). Ainsi, cela résout le problème du passage de paramètre de type Objet ou autre type non primitif. En effet, il suffit de créer une instance de chaque paramètre dans l agent et d appeler invoke() avec ces instances. C est ce que nous faisons dans notre exemple avec l opérationpush. La dernière étape consiste à démarrer l adaptateur : html.start(). B.3 L interface graphique Web B.3.1 Vue Agent La page html, montrée à la Figure B.7, affiche dynamiquement les MBeans enregistrés dans le serveur. Les MBeans sont affichés par domaine. Ainsi, dans la figure XXXX, nous pouvons voir trois MBeans : «name=html,port=8082» ; «type=mbeanserverdelegate» ; «name=stack». Ces MBeans appartiennent respectivement à leur domaine : Adaptor ; JMImplementation ; MBeans. Il est possible de filtrer les MBeans suivant leur domaine et leurs propriétés en utilisant leur Object- Name. Un lien hypertexte permet d accéder à l interface de chaque MBean. B.3.2 Vue MBean La page html, montrée à la Figure B.8, présente les attributs et les opérations manipulables du MBean sélectionné. La figure XXX présente à titre d exemple la vue du MBean du composant Stack. 176

187 Fig. B.7 Vue de l agent Jmx B Les attributs Le nom de chaque attribut est un lien qui provoque l ouverture d une boîte de dialogue qui le décrit. Pour les attributs accessibles en écriture, un champ de texte permet de saisir la nouvelle valeur qui sera effectivement affectée en appuyant sur le bouton apply. La valeur d un attribut est sa valeur au chargement de la page. Pour voir les modifications, il faut rafraîchir la page en utilisant le bouton reload. Ceci peut être automatique en indiquant un délai de rafraîchissement. B Les méthodes Le lien «description of nomméthode» provoque l ouverture d une boîte de dialogue qui la décrit. Un clic de souris sur le bouton «nom de méthode» provoque son exécution. Le résultat de l exécution est affiché dans une nouvelle page. Quand on revient dans la page Mbean view, elle a été rechargée. 177

188 Annexe B. Présentation de Jmx B.3.3 Agent Administration Cette interface permet d administrer les MBeans, i.e. les créer, les enregistrer ou les supprimer. Il est possible de choisir le constructeur invoqué lors de la création. Les classes de ces MBeans doivent être disponibles dans le classpath de l application agent. Dans les champs Domain et Keys, on définit l ObjectName du MBean que l on considère et dans le champ Java Class on donne le nom de la classe Java du MBean. Il est également possible de spécifier un Class Loader si la classe ne se trouve pas dans le classpath de l agent. B.4 Utilisation de Jmx Pour manipuler un composant via une interface Web, il suffit de respecter les étapes suivantes : Écrire le composant ; Sélectionner les attributs et les méthodes que l on veut rendre visible : pour un standard MBean, mettre les prototypes de méthode dans l interface. pour un dynamic MBean, implémenter les méthodes de l interface DynamicMBean. Créer l agent ; Enregistrer le MBeandans l agent (soit dans la fenêtre agent soit à l écriture du programme). 178

189 Fig. B.8 Vue du MBean 179

190 Annexe B. Présentation de Jmx Fig. B.9 Vue de l agent administration 180

191 Annexe C Le profil WpcP Cette annexe présente le profil Uml que nous avons développé avec le module Profile Builder du logiciel Objecteering. Le profil est écrit en respectant le formalisme défini dans [OMG99b]. C.1 Spécification du profil Profile name : Version : 0.1 Reference metamodel : Class, Association, AssociationEnd Parent profiles : none Compatible profiles : none Used profiles : none Descrition : C.2 Spécification des stéréotypes Name : Icon : Base metaclass : Description : Related constraints : Name : Icon : Base metaclass : Description : Related constraints : Name : Icon : Base metaclass : Description : Related constraints : WPCPComponent Class Représente la notion de type de composant self.connection->exists (participant.isstereotyped ("WPCPComponent")) WPCPCompInstance Class Représente la notion d instance de composant self.connection->exists (participant.isstereotyped ("WPCPCompInstance")) VCR Relationship Décrit une relation de composition hiérarchique de type Vertical Component Relationship 181

192 Annexe C. Le profil WpcP Name : Icon : Base metaclass : Description : Related constraints : Name : Icon : Base metaclass : Description : Related constraints : Name : Icon : Base metaclass : Description : Related constraints : Name : Icon : Base metaclass : Description : Related constraints : Name : Icon : Base metaclass : Description : Related constraints : Name : Icon : Base metaclass : Description : Related constraints : SCOMP VCR Décrit une relation de composition hiérarchique de sous type Strong Composition isencapsuled=true, isglobalshared=false LCOMP VCR Décrit une relation de composition hiérarchique de sous type Lightweight Composition isencapsuled=true, isglobalshared=true SAGG VCR Décrit une relation de composition hiérarchique de sous type Strong Aggregation isencapsuled=false, isglobalshared=false LAGG VCR Décrit une relation de composition hiérarchique de sous type Lightweight Aggregation isencapsuled=false, isglobalshared=true whole AssociationEnd Définit le coté de la relation correspondant à la notion de composant Tout part AssociationEnd Définit le coté de la relation correspondant à la notion de composant Partie C.3 Spécification des valeurs marquées Name : Base metaclass : Description : Related constraints : isencapsuled VCR Spécifie la propriété d encapsulation valeurs possibles true/false 182

193 Name : Base metaclass : Description : Related constraints : Name : Base metaclass : Description : Related constraints : Name : Base metaclass : Description : Related constraints : Name : Base metaclass : Description : Related constraints : isglobalshared VCR Spécifie la propriété de partage global valeurs possibles true/false islocalshared VCR Spécifie la propriété de partage local valeurs possibles true/false isseparable VCR Spécifie la propriété de séparabilité valeurs possibles true/false ismutable VCR Spécifie la propriété de mutabilité valeurs possibles true/false Name : lifedependency Base metaclass : VCR Description : Spécifie la dépendance de cycle de vie Related constraints : valeurs possibles de 1 à 9 183

194 Annexe C. Le profil WpcP 184

195 Table des figures 1 Représentation schématique de l organisation du mémoire Spécialisation de la notion de composant en fonction de son cycle de vie [CD01] Un composant et ses interfaces Exemple de définition d interface en IDL Patron de conception Adapter [GHJV95] Relation entre les concepts pour une application basée composants [BBB + 00] Cycle de développement d applications basées composants comparé avec le cycle en cascade [BBB + 00] Relations entre les composants de l application Décomposition du composant CoffeeMachine Représentation du composant Coiner Représentation du composant DrinkMaker Composition logicielle primaire en Java Différence entre intégration et composition Organisation canonique d un composé en regard d un de ses sous-composants Vue interne d un composant FractalFractal [BCS03] Architecture du Vcf [OGJ03] Le patron Composite [GHJV95] Les différents niveaux du Mof Partie d Uml 1.x modélisant le concept de composant [OMG03f, p. 2-16] Partie d Uml 1.x modélisant le concept d instance de composant [OMG03f, p. 2-96] La composition en Uml 1.x au niveau métamodèle Exemple de composite structure Notation pour un composant avec ses interfaces Notations possibles pour un composant

196 Table des figures 3.8 Utilisation des delegation connectors Définition de la métaclasse Component dans le métamodèle Uml 2.0 [OMG03d, p. 151] Lien entre composants [OMG03d, p. 151] Réalisation de la métaclasse Component dans le métamodèle Uml Le métamodèle Structured Classifier [OMG03d, p. 126] Vue boîte blanche de CoffeeMachine Behavioral state machine du composant Coiner Behavioral state machine du composant DrinkMaker Behavioral state machine du composant CoffeeMachine Le concept Tout-Partie en fonction des différents niveaux du Mof Relation de composition entre un calculateur et une centrale de mesure Illustration de la propriété d asymétrie au niveau des instances Exemple de symétrie Encapsulation du composant Horloge par le composant Tout Four Exemple Java d encapsulation de service par un composant Tout Domaine d application de l encapsulation Partageabilité locale Partageabilité globale Partageabilité séquentielle Les neuf cas de cycle de vie Transitivité sur les services et partage Différence entre agrégation et composition Autres sous-types de relation Tout-Partie Première approche intuitive de mise en œuvre de la relation Tout-Partie Orientation de la mise en œuvre de la relation Tout-Partie Ajout des métaclasses modélisant la relation de composition Détail de la métaclasse VerticalComponentRelationship Ajout des métaclasses spécialisant les différents types de relations Tout-Partie Lien entre le paquetage Core et les profils en Uml [OMG03b] Les profils vis-à-vis de l architecture Mof [OMG99b] Dtc généré avec le profil Wpcp Dic généré avec le profil Wpcp Comparaison des modèles de relations [Sun00]

197 6.2 Spécialisation de relation Tout-Partie dans l environnement WcpE Vérification d une dépendance existentielle (1) Vérification d une dépendance existentielle (2) Vérification d une non partageabilité Dépendances en contract testing Dépendances entre les interfaces de test Modèle Uml de la librairie Bit/J Générateur de code de la librairie Bit/J Exemple d architecture couplant agents de composition et composants B.1 Architecture simplifiée de Jmx B.2 Partie du code généré du BitC B.3 Interface DynamicMBean B.4 Prototype de la fonction MBeanAttributeInfo B.5 Exemple pour l attribut max B.6 ObjectName d un MBean B.7 Vue de l agent Jmx B.8 Vue du MBean B.9 Vue de l agent administration

198 Table des figures 188

199 Liste des tableaux 1.1 Résumé des différences entre un objet et un composant Activités canoniques durant un cycle de vie [Som01, CJC02] Documentation existante sur les modèles de composants Classification des propriétés de la relation Tout-PartieRelation Tout-Partie appliquée au monde OO [BHSPLB03, BLB02] Échantillon de propriétés émergentes et résultantes Classification des propriétés de composition retenues selon les dimensions architecturale et dynamique Relation entre les propriétés secondaires retenues Les différents types de la relation Tout-PartieRelation Tout-Partie Détail des valeurs prédéfinies des attributs de la métaclasse VerticalComponentRelationship Vue schématique de l outillage proposé Exemple de contenu d un profil d analyse [Sof99] Liste des stéréotypes du profil Liste des valeurs marquées du profil Raccourcis de nommage du profil

200 Liste des tableaux 190

201 Glossaire des termes techniques 191

202

203 π-calcul : Pi calcul, ADL : Architecture Description Language - Langage de description d architecture, AOP : Approche Orientée Aspects, AOP : Aspect Oriented Programming - programmation orientée aspect, BIT : Built-In Test - Test intégré, BITC : BIT Component - Composant possédant une interface de test basée sur la technologie BIT, CBD : Component Based Developpement, CBSE : Component Based Software Engineering, CCM : Corba Component Model - Modèle de composants conçu pour les environnements de composants distribués, Composant COTS : Commercial Off-The-Shelf - Il s agit de composant conçus et développés dans le but d être vendu. Ils sont généralement vendus sous forme de binaire avec une spécification de leur fonctionnement, CWM : Common Warehouse Metamodel - métamétamodèle définit par l OMG, DIC : Diagramme d Instances de composants - Diagrammes de classes spécifiques pour modéliser une architecture en terme d instances de composants, DTC : Diagramme de Types de composants - Diagrammes de classes spécifiques pour modéliser une architecture en terme de types de composants, EDOC : UmlProfile for Enterprise Distributed Object Computing - profil pour les systèmes distribués industriels standardisé par l OMG, EJB : Entreprise Java Beans - Modèle de composants conçu pour les environnements de composants distribués, JMX : Java Management extension - technologie développée par Sun Microsystems permettant la manipulation et la gestion de composants à distance à travers une page Web, MDA : Model Driven Architecture - approche proposée par l OMG. Elle envisage le développement d application uniquement par transformation de modèles. L application est conçue indépendamment de tout modèle technologique et est générée automatiquement par transformation de modèle, MOF : Méta Object Facility - métamétamodèle définit par l OMG permettant de définir tout type de métamodèle, OCL : Object Constraint Language - langage de contrainte définit par l OMG et utilisé dans Uml, PWS : Part-Whole Statecharts - Langage de composition de Statechart, QoS : Qualité de Service, UML : Unified Modeling Language - langage de modélisation graphique défini par l OMG, Uml-Rt : Uml Real Time Profile - profil temps réel standardisé par l OMG, VCF : Vienna Component Framework - plate-forme supporte l interopérabilité et la composabilité de composants développés selon différents modèles de composants, XMI : XML Metadata Interchange - extension proposée de XML (Extensible Markup Language) qui cherche à fournir un standard pour l échange de métadonnées, 193

204 194

205 Index 195

206

207 INDEX DES PERSONNALITÉS, PROJETS, LABORATOIRES ET ENTREPRISES Index des personnalités, projets, laboratoires et entreprises A ACCORD, projet Rntl AOC, Équipe de recherche, Pau, France103, 121, 133, 134, 141, 145 ARTIST, projet européen Atkinson, Collins B Bézivin, Jean Bœhm, Barry Booch, Grady Bruel, Jean-Michel , 147 C Carnegie Mellon, Pittsburgh Chessman, John CNAM, France Component+, projet européen Constant, Olivier D Daniels, John E EDF, division Recherche et développement, Clamart, France ENST, France F France Télécom R & D G Gamma, Erich Gao, Jerry Garlan, David H Habrias, Henri Harel, David , 51 I IBM INRIA, France K Keller, Rudolf K L LIFL, Laboratoire, Lille, France LIUPPA, Laboratoire, Pau, France Lumpe, Markus M Marvie, Raphaël Medvidovic, Nenad Meijler, Theo Dirk , 31, 43 Meyer, Bertrand Microsoft Corporation N Nierstrasz, Oscar , 31, 36, 43, 44 O Ober, Ileana Oberndorf, Patricia OMG , 113, 149 OMG - Object Management Group P Pazzi, Lucas Philips R Romeo, Fabien Rumbaugh, Jim S Schneider, Jean-Guy Softeam SOFTEAM, société, France Software Composition Group , 44 Software Engineering Institute , 44 Stafford, Judith A , 36 Szyperski, Clemens , 21, 23, 36 J Jézéquel, Jean-Marc , 135 Jacobson, Ivar , 51 Johnson, Ralph E , 18 T Taylor, Richard N TRISKELL, équipe de recherche, Rennes, France

208 U Université de Berne, Suisse UQAM - Université de Québec À Montreal.. 20 W Wallnau, Kurt , 36 Wang, Yingxu

209 Index des méthodes, techniques et outils INDEX DES MÉTHODES, TECHNIQUES ET OUTILS Symbols π-calcul NET , 40, 43, 55 A ACME ADL , 38-41, B Bean Markup Language BIT , BITC C C CCM , 12, 40, 41, 149 COM , 10, 12, 40, 41, 43, 122 CORBA , 55, 106, 107, 109, 122, 148, 178 D Darwin , 41, 43 DCOM , 40, 43, 122 Diagramme d Instances de Composant111, 112, Diagramme de Types de Composant111, 112, E EDOC , 107, 178 EJB , 12, 23, 32, 40, 41, 43, 110, 122, 149 Environnement de composition WPCE , 121, 122, 146, 148 F Fractal , 146, 148 J J2EE JavaBeans , 41, 43, 44, 146, 188 JavaPods , 41, 43 JMX , 121, 123, 124, , 139, 146, 187, M Model Driven Architecture MOF , 72, 92, 106, 107 O Objecteering , 113 Profile Builder , 113 OCL , 47, 48, 55, 69, 70, 73, 85, 91, 92, 96-99, 108, 113, 145, ODP , 41, 43 OLAN P Piccola PICT PIM Profil Profil WPCP , 105, 110, 118 PSM PWS , 137 R Rapide S Statecharts Part-Whole Statecharts (PWS) , 137 U UML-RT V Vienna Vienna Component Framework W Wright X xadl xarch XMI K Koala , 41,

210 Index A Acteurs Architecte de canevas Architecte du système Développeur de composants Utilisateur de composants Aggregation Lightweight Aggregation Strong Aggregation AOP Application basée composant , 9, 10, 14, 20, 21, 29, 31, 32, 137, 145 Application basée composants Cycle de vie Développement Développement à partir de composants.. 26 Développement de composants Approche Orientée Aspects B BIT , BITC C Canevas d applications CBD.... 3, 9, 10, 15, 22, 26, 65, 103, 121, 134, 145 CBSE , 9-11, 15, 21, 36, 37, 46, 48, 55, 57, 65, 76, 145 ComponentRelationship HorizontalComponentRelationship VerticalComponentRelationship , 112 Composant logiciel Cycle de vie Déploiement Différence entre objets et composants Relation entre les concepts Taille Composition composition horizontale Composition logicielle composition verticale langage de composition Lightweight Composition Strong Composition Contract testing Contrat COTS , 20, 23, 24, 26, 28, 39, 99, 122, 134, 136, 138 I IBIT Query Interface J JMX , 121, 123, 124, , 139, 146, 187, MBEAN , 124, 126, 128, M Méta Object Facility (MOF) MDA O OCL , 47, 48, 55, 69, 70, 73, 85, 91, 92, 96-99, 108, 113, 145, P Patron de conception processus de développement Modèle à spirale Modèle incrémental Modèle itératif Modèle par prototypage Processus unifié Profil Contrainte Profil Corba Profil Edoc Profil CWM Profil OLAP Profil UML-RT Stéréotype Valeur marquée Q QoS , 18, 99, 135, 136, 147 R Réutilisation Boite blanche Boite noire

211 INDEX Réutilisabilité Relation Tout-Partie.. 4, 5, 70-77, 82, 86, 88, 90-92, 96, 98, 99, 112, 114, 117, , 146, 183, 184 S Service State-based contract testing State-based IBIT Query V Vérification a priori Vienna Component Framework