Composition conceptuelle basée sur la relation Tout-Partie

É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

Mis en page avec la classe thloria.

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

ii

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

iv

Table des matières Introduction 1 Partie I État de l art 7 Chapitre 1 Terminologie 9 1.1 Concepts et définitions................................... 9 1.1.1 Du Cbd à la Cbse................................. 10 1.1.2 Composant logiciel................................. 11 1.1.3 Service de composant................................ 15 1.1.4 Interface....................................... 16 1.1.5 Contrat........................................ 17 1.1.6 Patrons de conception............................... 18 1.1.7 Canevas d applications............................... 20 1.1.8 Relation entre ces concepts............................. 21 1.2 Processus de développement d applications basées composants............. 22 1.2.1 La réutilisation : un principe fondateur...................... 22 1.2.2 Acteurs du processus................................ 23 1.2.3 Étude du processus de développement...................... 24 1.3 Résumé du chapitre..................................... 28 v

Table des matières Chapitre 2 Composition logicielle et composition niveau modèle 31 2.1 Composition......................................... 32 2.1.1 Illustration de la problématique par une étude de cas.............. 32 2.1.2 Éléments de définition............................... 36 2.2 Mise en œuvre de la composition logicielle........................ 39 2.2.1 Langages de script................................. 39 2.2.2 Langages de glu................................... 40 2.2.3 Modèles de composants............................... 40 2.2.4 Langages de description d architecture...................... 43 2.2.5 Langages de composition.............................. 44 2.2.6 Bilan de la composition bas niveau........................ 45 2.3 Composition au niveau conceptuel............................. 45 2.3.1 Le patron de conception Composite....................... 46 2.3.2 Contrats....................................... 47 2.3.3 Approche formelle pour la composition...................... 48 2.3.4 Bilan sur la composition au niveau conceptuel.................. 48 Chapitre 3 Uml et les composants 51 3.1 Modélisation, métamodélisation et métamétamodélisation : une question d à propos. 52 3.2 Uml 1.x........................................... 53 3.3 Uml 2.0........................................... 55 3.3.1 Aperçu des améliorations.............................. 56 3.3.2 Nouveaux concepts................................. 56 3.3.3 Diagrammes de composants............................ 57 3.3.4 Support pour la composition............................ 59 3.3.5 Nouveau métamodèle................................ 60 3.4 La composition conceptuelle en Uml 2.0......................... 61 3.4.1 Limites de la composition conceptuelle en Uml 2.0............... 61 3.4.2 Nos solutions.................................... 62 3.5 Apport d Uml 2.0 par rapport à Uml 1.x........................ 64 3.6 Problématique de notre thèse............................... 65 vi

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 69 4.1 Étude de l application de la relation Tout-Partie à la composition logicielle...... 70 4.1.1 Démarche, fondations et hypothèses de notre proposition............ 70 4.1.2 Études des propriétés de la relation Tout-Partie pour la composition logicielle 74 4.1.3 Classification des propriétés retenus selon les dimensions architecturale et dynamique....................................... 85 4.1.4 Relations entre les propriétés de composition retenues.............. 86 4.1.5 Identification de différents types de relations Tout-Partie............ 88 4.1.6 Résumé de l étude.................................. 91 4.2 Définition d un métamodèle Uml pour la Cbse basé sur la relation Tout-Partie... 91 4.2.1 Discussion sur les choix de métamodélisation.................. 92 4.2.2 Proposition de métamodèle............................. 94 4.2.3 Contraintes Ocl.................................. 96 4.2.4 Résumé de l application à Uml du modèle de composition........... 99 4.3 Conclusion.......................................... 99 Partie III Outillage appliqué à la composition 101 Chapitre 5 WpcP : un profil Uml dédié à la composition logicielle 105 5.1 Définition et démarches................................... 105 5.1.1 Définition...................................... 106 5.1.2 Éléments d un profil Uml............................. 106 5.1.3 Démarche d élaboration d un profil et éléments de description......... 110 5.2 Notre proposition : le profil WpcP............................ 110 5.2.1 Domaine du profil.................................. 111 5.2.2 Définition technique................................. 111 5.2.3 Définition opérationnelle.............................. 112 5.3 Réalisation et exemple d utilisation............................ 113 5.3.1 Limites dues à l outil et choix techniques..................... 113 5.3.2 Exemple d utilisation................................ 114 5.4 Bilan du profil........................................ 118 vii

Table des matières Chapitre 6 Environnement de composition Java pour un déploiement de composants rigoureux 121 6.1 Vers un assemblage contraint des composants logiciels : l environnement WpcE... 122 6.1.1 Un environnement de composition spécifique................... 122 6.1.2 Pilotage de composants............................... 122 6.2 L environnement Jmx.................................... 123 6.2.1 Présentation de Jmx................................ 123 6.2.2 Le service de relation Jmx............................. 123 6.3 Environnement de composition Java pour un développement rigoureux........ 125 6.3.1 Construction de relations Tout-Partie....................... 125 6.3.2 Implémentation de la relation Tout-Partie.................... 126 6.4 Exemple d utilisation.................................... 128 6.5 Bilan du chapitre...................................... 131 Chapitre 7 Application de la technologie Bit pour la vérification des contrats de exprimés sur les états 133 7.1 Contrats basés sur les états et vérification a posteriori................. 133 7.2 Test de composant..................................... 134 7.2.1 Spécificité du test de composant.......................... 134 7.2.2 Le test intégré de composant............................ 135 7.3 La technologie Bit..................................... 135 7.3.1 Le Contract testing................................. 136 7.3.2 Le State-based contract testing.......................... 137 7.4 Outillage de la technologie Bit............................... 138 7.4.1 La librairie Bit/J.................................. 138 7.4.2 Exemple d utilisation de la librairie Bit/J.................... 139 7.5 Bilan du chapitre...................................... 141 Conclusions générale et perspectives 143 Bibliographie 151 viii

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.................. 197 Index des méthodes, techniques et outils............................ 199 Index................................................ 200 ix

Table des matières x

Introduction 1

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

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

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 ://www.component-plus.org 5

6

Première partie État de l art 7

Chapitre 1 Terminologie Sommaire 1.1 Concepts et définitions............................ 9 1.1.1 Du Cbd à la Cbse............................... 10 1.1.2 Composant logiciel............................... 11 1.1.3 Service de composant.............................. 15 1.1.4 Interface..................................... 16 1.1.5 Contrat..................................... 17 1.1.6 Patrons de conception............................. 18 1.1.7 Canevas d applications............................. 20 1.1.8 Relation entre ces concepts.......................... 21 1.2 Processus de développement d applications basées composants.... 22 1.2.1 La réutilisation : un principe fondateur................... 22 1.2.2 Acteurs du processus.............................. 23 1.2.3 Étude du processus de développement.................... 24 1.3 Résumé du chapitre.............................. 28 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

Chapitre 1. Terminologie 1.1.1 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.

1.1. Concepts et définitions 1.1.2 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 1.1.2.5. 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. 1.1.2.1 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

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. 1.1.2.2 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) : 12 1. 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.

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. 1.1.2.3 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

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. 1.1.2.4 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 ://www.iccbss.org/ 7 Cots-based product en anglais 14

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. 1.1.2.5 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 1.1.4. 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. 1.1.2.6 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. 1.1.3 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 ://www.sap.com/solutions/business-suite/erp/index.aspx 15

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). 1.1.4 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 2.0 9. 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

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 1.3. 1 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 1.1.5 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 ://www.sei.cmu.edu/str/descriptions/dce_body.html 17

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 11. 1.1.6 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-2001-34820, http ://www.artist-embedded.org 18

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 2.3.1 page 46 traitant du patron Composite. 19

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 2.1.2.1) ; 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. 1.1.7 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

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. 1.1.8 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