Modèles de composants

Transcription

1 Master 2 Recherche Informatique Université de Bretagne Occidentale Modèles de composants Nassima Saididj Encadrant : M. Beugnard 29 janvier

2 Résumé L ingénierie des composants est une discipline très prometteuse en pleine croissance dans les domaines académique et industriel. L approche de développement orientée composants consiste à concevoir et développer des applications par assemblage de composants pré-existants. Cette approche tente de réduire les coûts et délais de développement, de faciliter l évolution et la maintenance des applications en favorisant l adaptabilité pour produire de nouvelles fonctionnalités. Ce rapport présente un état de l art sur les notions de base relatives à l Ingénierie des composants et quelques modèles de composants connus tels que CCM (CORBA Component Model), EJB (Entreprise Java Bean), Fractal et SOFA. Abstract Mots clefs : composant, composant logiciel, modèles de composants. Component engineering is a very promising and growing discipline in both industry and academia. Component-based development consists on developing applications by assembling preexisting components. This approach tries to reduce costs and development time, facilitate upgrade and applications maintenance with promoting adaptability in order to produce new features. This report presents a review on the basic concepts regarding to component engineering and some known components models as CCM (CORBA Component Model), EJB (Enterprise Java Bean), Fractal and SOFA. Keywords : component, software component, component models. 2

3 Table des matières 1 Introduction 4 2 Les composants logiciels Objet vs composant Définitions Notions de base Boîte noire, boîte blanche et boîte grise Spécification d un composant Interfaces Propriétés Contrats Développement de logiciels à base de composants Cycle de vie d un composant Cycle de développement à base de composants Les modèles de composants Modèles industriels EJB CCM Modèles académiques Fractal SOFA Comparaison Conclusion et discussion 14 3

4 1 Introduction Durant les dernières années, l approche basée sur les composants a eu beaucoup de succès dans de nombreux domaines d application. Les applications web, distribuées ou encore graphiques sont des exemples typiques de domaines où cette approche a fait ses preuves. Dans ces domaines des technologies telles que. NET, EJB et CCM sont utilisées. L approche orientée composants a pour vocation d offrir des avantages là où l approche orientée objets a échoué c est-à-dire : augmenter la fiabilité des applications grâce à la réutilisation de composants préexistants et pré-testés, maîtriser le passage à l échelle, les coûts et délais de développement... Le stage se déroulera au département informatique de TELECOM Bretagne à Brest, dans l équipe CAMA (Composants pour Architectures Mobiles Adaptables) qui s intéresse aux problèmes de conception et de réalisation de logiciels répartis et adaptables à l aide de modèles et de composants. Le but de se stage est de proposer un nouveau modèle de composants qui prenne en compte l évolution du composant tout au long de son cycle de vie. Ce rapport est organisé en deux parties. Dans la première partie est présenté le concept du composant logiciel suivi de quelques notions de base. La deuxième partie de ce rapport est consacrée à la présentation de quelques modèles de composants dans les domaines industriel et académique suivie d une comparaison entre les des différents modèles présentés. Le rapport se termine avec une conclusion. 4

5 2 Les composants logiciels Cette première partie est consacrée à l introduction des notions de base. Dans un premier temps une comparaison est faite entre l approche à base de composants et l approche orientée objets puis les limites de cette dernière sont données. Ensuite, des notions relatives à l approche orientée composants sont présentées. Enfin, sont abordés le cycle de vie d un composant et le cycle de développement à base de composants. 2.1 Objet vs composant Une application orientée objets doit être vue comme une collection d objets collaborant dans laquelle chaque objet résume les données et le comportement d une entité de l application. L interaction avec cette entité se fait par le biais d une interface bien définie. Dans les applications orientées objets, l héritage est le mécanisme de partage et de réutilisation des modèles génériques. Malgré l avantage qu offre l héritage, il en reste qu il n est pas possible de réutiliser les classes sans la programmation de nouvelles classes [ND95]. Le faible niveau de réutilisation est dû au fort couplage des objets, qui en effet, peuvent communiquer sans passer par leurs interfaces. L approche objet présente d autres limites [O + 05]parmi lesquelles on peut citer : La plupart des mécanismes objets sont manuels (création des instances, gestion des dépendances entre classes,...) ; Seuls les services fournis sont spécifiés et l approche ne définit pas les besoins requis ; Il n existe pas d outils pour déployer les exécutables sur les différents sites ; L évolution des objets est difficilement prise en compte par l approche ; L approche a montré des limites importantes en termes de passage à l échelle. L approche orientée composants a pour vocation d offrir des avantages là où l approche orientée objets a échoué. Le principe de développement de systèmes à partir des composants n est pas nouveau étant donné que même l approche objet repose sur l identification dans un premier lieu des différentes entités du système, puis, des différents modules et classes associés à chaque entité... Toutefois, la nouveauté est que l approche orientée composants repose sur le principe de la réutilisation de composants préexistants et leur assemblage pour construire de nouvelles applications. Cette méthode basée sur l assemblage a comme principaux avantages la simplification du développement des applications complexes et la fiabilité des systèmes grâce à l utilisation de composants pré-testés. 2.2 Définitions Selon Wikipédia 1, un composant est défini comme étant «un élément de base d un ensemble complexe (structuré ou composite) lequel est un assemblage de composants souvent différents». Cette première définition quoique générale, fait apparaître deux concepts importants dans l approche dite de développement à base de composants qu on retrouve plus loin dans ce rapport. Il s agit de «composant composite» et d «assemblage de composants». Le premier désigne un composant construit à partir d un ensemble d autres composants plus élémentaires dits primitifs. 1 http ://fr.wikipedia.org/wiki/composant 5

6 L assemblage de composants constitue quant à lui avec la réutilisation le principe sur lequel repose le développement à base de composants. Tous ces concepts sont explicités plus loin dans ce rapport. Harris dans [HH99] définit un composant comme suit : «Un composant est un morceau de logiciel assez petit pour qu on puisse le créer et le maintenir, et assez grand pour qu on puisse l installer et en assurer le support. De plus, il est doté d interfaces standards pour pouvoir interopérer» 2. Meyer dans [Mey99] donne une autre définition pour le composant logiciel : «Un composant logiciel est un élément logiciel avec les propriétés suivantes : l élément peut être utilisé par d autres éléments logiciels (clients) ; les clients et leur «auteurs» n ont pas besoin de connaître l «auteur» de l élément» 3. Bien qu il n existe pas une définition consensuelle, la plus reconnue est celle de Szyperski [SBW98] : «Un composant est unité de composition avec des interfaces contractuellement spécifiées et des dépendances explicites au contexte. Un composant logiciel peut être déployé de façon indépendante et être sujet à composition par des tierces parties» 4. Cette définition souligne les propriétés suivantes : un composant constitue l unité de composition ; il est défini par ses fonctions et ce dont il a besoin qui sont définis explicitement par des contrats ; il peut être déployé de façon indépendante ; donc il est autonome ; il est composable avec d autres composants. Szyperski dans [Szy02], explique ces propriétés de la manière suivante. D abord, pour qu un composant soit à même d être déployé de façon autonome, il doit être bien séparé de son environnement et des autres composants. Un composant encapsule donc l ensemble de ses fonctions. Aussi, étant donné qu il est une unité de déploiement, un composant ne sera jamais déployé partiellement. Dans ce contexte, une tierce partie est celle qui ne peut pas avoir accès aux détails de construction dudit composant. Pour qu un composant soit composable avec d autres composants d une telle tierce partie, il doit être suffisamment autonome. Aussi, les spécifications concernant ce que le composant fournit et ce dont il a besoin doivent être claires. En d autres termes, un composant a besoin d encapsuler son implémentation et d interagir avec son environnement à travers des interfaces bien définies. Il existe également une divergence concernant la définition d un composant entre les chercheurs du milieu académique et ceux du milieu industriel. Les premiers définissent un composant comme étant une entité bien définie, souvent petite avec des propriétés fonctionnelles et nonfonctionnelles. Les seconds voient un composant comme étant une partie réutilisable du système, 2 «A component is a piece of software small enough to create and maintain, big enough to deploy and support, and with standard interfaces for interoperability» 3 «A software component is a program element with the following properties : The element may be used by other program elements (clients) The clients and their authors do not need to be known to the element s authors.» 4 «A software component is a unit of composition with contractually specified interface and explicit context dependencies only. A software component can be deployed independently and is subject to composition by third parts.» 6

7 mais que celle-là n est pas nécessairement bien définie dans ses interfaces et sa conformité à un modèle de composant. La deuxième partie de ce rapport présente quelques modèles de composants des domaines industriel et académique. 2.3 Notions de base Boîte noire, boîte blanche et boîte grise Dans [Szy02], l auteur décrit les concepts de boîte noire et boîte blanche comme se référant à la visibilité des implémentations des interfaces. Ainsi, dans une boîte noire, aucun détail au-delà de l interface et de ses spécifications n est connu par le client. En revanche, dans une boîte blanche, l implémentation de l interface est complètement visible et donc permet de comprendre son fonctionnement. Une boîte grise quant à elle, révèle des propriétés de l implémentation [BW99] Spécification d un composant La spécification d un composant est donnée par trois éléments : Type : c est la définition abstraite du composant. Implémentation : l implémentation d un composant est la mise en œuvre des aspects fonctionnels et non-fonctionnels de son type. Instance : une instance d un composant est une entité exécutable du composant dans un système. La spécification d un composant repose essentiellement sur son type qui est caractérisé par deux éléments : ses interfaces et ses propriétés [O + 05] Interfaces Une interface d un composant peut être définie comme étant une spécification de ses points d accès [Szy02]. Le client accède aux services fournis par le composant via ces points d accès. Si un composant en possède plusieurs, chacun représente un service offert par ce composant. Il est important de souligner qu une interface n implémente aucune de ses opérations. En effet, une interface décrit uniquement un ensemble d opérations ainsi que leurs contrats. Il existe deux types d interfaces : les interfaces fournies et les interfaces requises. Les interfaces fournies décrivent les services offerts par le composant à son environnement tandis que les interfaces requises spécifient les services requis par le composant Propriétés On peut distinguer deux types de propriétés pour un composant, les propriétés dites fonctionnelles et les propriétés dites non-fonctionnelles. Les propriétés fonctionnelles sont celles qui décrivent la structure, le comportement et les fonctionnalités du composant. En revanche, les propriétés nonfonctionnelles concernent les services utilisés par le composant qui ne font pas partie des services applicatifs (sécurité, performance,...). 7

8 2.3.5 Contrats Un contrat comme il a été mentionné dans [Mey00], liste l ensemble des contraintes que le composant doit maintenir (l invariant). Pour chaque opération du composant, le contrat spécifie également la liste des contraintes qui doivent être remplies par le client (la pré-condition), et ce que le composant s engage à fournir en retour (la post-condition). La pré-condition et la post-condition constituent la spécification du comportement d un composant [Crn02]. 2.4 Développement de logiciels à base de composants Bien que le développement d application à base de composants logiciels n ait commencé à émerger qu à partir des années 1990, l idée de la réutilisation est bien plus antérieure. Le premier à en avoir introduit l idée fut McIlroy lors d une conférence de l OTAN en Celui-ci, expliqua la crise que vivait l industrie du logiciel par l absence d une industrie sous-jacente de composants et qu une telle industrie pouvait être couronnée de succès 5. Le but principal de l ingénierie à base de composants, est d aborder le développement des applications comme étant un assemblage de composants réutilisables, et la maintenance de ces applications s effectue en modifiant ou en remplaçant ces composants [Crn03]. L ingénierie des composants inclut aussi bien le développement des composants que le développement de systèmes à base de composants. En effet, dans le premier cas, les composants sont développés dans le but d être réutilisés dans plusieurs applications, tandis que dans le deuxième cas, il s agit de construire des applications par assemblage de composants préexistants après leur adaptation. Dans la suite sont présentés les deux cycles de vie correspondant à chaque cas Cycle de vie d un composant Le processus de développement d un composant peut suivre un modèle de cycle de développement arbitraire. Toutefois, ce modèle nécessitera certaines modifications pour s adapter aux spécificités du développement des composants. En effet, en plus des exigences en matière de fonctionnalités du composant, celui-ci est conçu pour être réutilisé [CLC05]. Les phases du cycle de vie d un composant telles que décrites dans [O + 05] sont : Analyse des besoins en termes de composants L objectif de cette étape est de produire en sortie des composants réutilisables. Pour cela, des techniques d analyses sont utilisées pour identifier parmi les composants existants, ceux qui pourront être réutilisés. À l issue de cette étape, un langage de modélisation (tels que les diagrammes UML) est utilisé pour décrire les besoins en termes de fonctionnalités d un type de composant, un type de composant étant sa définition abstraite. Conception des types de composants Cette étape s appuie sur la définition des besoins de l étape précédente pour spécifier les types 5 «My thesis is that the software industry is weakly founded, in part because of the absence of a software components subindustry.... A components industry could be immensely successful» 8

9 de composants. Durant la phase de conception des types, un langage est utilisé pour spécifier les interfaces, les propriétés et les contrats des composants. Cette étape fait également appel à certains mécanismes qui sont : L adaptation : modification apportées aux composants afin qu ils deviennent appropriés à des utilisations particulières. L intégration : intégration d un composant à l application en cours de développement. La recherche : recherche des composants qui répondent à des besoins particuliers. La sélection : choix parmi les composants candidats, de celui qui est le plus proche des besoins. Implantation des types de composants Durant cette phase, les parties fonctionnelles d un type de composant sont implantées en respectant sa spécification et en utilisant le langage défini par le modèle de composants choisi. Paquetage et diffusion des implantations de composants Après l implantation des composants, ceux-ci sont archivés dans des paquetages. Un paquetage regroupe dans une seule unité les éléments nécessaires au déploiement d un composant. Ces éléments sont le type de composant, son implantation ainsi qu un ensemble de descripteurs qui aident à son déploiement. Un paquetage possède un format défini par le modèle utilisé pour faciliter sa diffusion et son échange. Assemblage L assemblage est l opération qui consiste à assembler tous les composants d une application. Le résultat de l assemblage est ensuite empaqueté avant sa diffusion et son utilisation. Aussi, il est nécessaire que le résultat de l assemblage soit un composant afin qu il puisse être assemblé avec d autres composants. Afin de décrire cet assemblage, des ADL (Architecture Description Language) peuvent être utilisés. Les ADL sont des langages qui, en se basant sur les notions de composant, connecteur, et de configuration permettent de décrire l architecture d un système. Un connecteur est utilisé pour modéliser de façon précise les interactions entre deux ou plusieurs composants en définissant l ensemble des conditions devant être remplies. La complexité d un connecteur peut varier en fonction des interactions entre les composants (de simple appel de procédure jusqu à des protocoles d accès à des bases de données par exemple). Une configuration quant à elle, est la description de la manière dont les composants et les connecteurs sont reliés. Déploiement On désigne par déploiement le processus d intégration d un composant dans son environnement après son extraction du paquetage le contenant. L instanciation du composant se fait en se basant sur les descripteurs qui lui ont été associés lors de son empaquetage. Ces descripteurs permettent aussi de vérifier l adéquation de la structure d accueil avec leurs spécifications. Utilisation et maintenance Après le déploiement du composant, il sera ensuite possible de l utiliser et exploiter ses services. La 9

10 maintenance inclut quant à elle, la modification d un composant existant et la création d un nouveau Cycle de développement à base de composants Différents modèles de cycle de vie établis en génie logiciel peuvent être utilisés dans le développement à base de composants. Ces modèles seront modifiés pour souligner les activités centrées sur les composants de ce développement qui se concentre sur l identification des composants réutilisables et des relations entre eux à partir des exigences du système. Les différentes étapes dans le processus de développement de systèmes à base de composants telles que présentées dans [Crn03] peuvent être résumées comme suit : Recherche des composants susceptibles d être utilisés dans le système : tous les composants candidats sont listés. Afin d effectuer efficacement cette procédure des outils pour retrouver les composants candidats sont utilisés. Sélection des composants qui répondent aux exigences du système. Souvent, les exigences ne peuvent pas être remplies entièrement et une adaptation des composants existants est nécessaire afin de permettre leur utilisation. Si aucun composant ne répond aux exigences, il faut développer des composants pour qu ils soient utilisés dans le système. Adaptation des composants sélectionnés en tenant compte du modèle utilisé et des spécifications des exigences. Assemblage et déploiement des composants en utilisant un framework de composants. Ce sont généralement les modèles de composants qui offrent cette fonctionnalité. La différence entre le concept de modèle et celui de framework de composants [BBB + 00] est que le premier définit un ensemble de normes et de conventions utilisées par le développeur, tandis que le deuxième est une infrastructure de support pour un modèle de composants. Remplacement des anciennes versions de composants par des versions plus récentes ce qui correspond à la maintenance du système. Dans cette partie, nous avons présenté les principaux concepts des composants logiciels en ressortissant leurs caractéristiques, leur cycle de vie ainsi que le cycle de développement à base de composants. La suite de ce rapport est consacrée à la présentation de quelques modèles de composants. 10

11 3 Les modèles de composants Dans cette partie, nous présentons brièvement quelques modèles de composants en se focalisant sur la vision de chacun, de la conception d une application à base de composants. Cette présentation est suivie d une comparaison des avantages et inconvénients de chaque modèle par laquelle nous cherchons à mettre en avant les caractéristiques souhaitées d un modèle de composants. 3.1 Modèles industriels EJB Le modèle des composants EJB (Enterprise Java Bean) a été défini par Sun dans le cadre de J2EE avec comme objectifs la normalisation du développement, l assemblage et le déploiement des applications distribuées [Mic05]. L architecture de l environnement d exécution des EJB comprend un serveur, un conteneur ainsi que des services fournis par le serveur aux composants (services de gestion des transactions, d exceptions, de persistance et un support pour la sécurité). Un composant est défini par deux interfaces : une définissant ses fonctions et une autre contenant les opérations de création, suppression et recherche. Un composant est également défini par une classe qui réalise les fonctions du composant et des méthodes spécifiques imposées par la spécification EJB. Chaque composant est localisé dans un conteneur, qui lui assure une indépendance vis-à-vis l implantation du serveur. Un conteneur possède une EJB Home dont le rôle est de créer de nouveaux composants, de retrouver des composants existants, et de détruire des composants à l intérieur du conteneur. Les EJB Objects quant à eux, permettent aux clients d accéder aux composants encapsulés à l intérieur du conteneur. En effet, le conteneur s interpose aussi entre le composant qu il contient et les clients ; l accès au composant n est possible qu à travers les EJB Objects. Le descripteur de déploiement d un composant est un fichier dans lequel sont déclarées des propriétés de déploiement en termes de ressources nécessaires à son exécution. Il existe plusieurs implémentations de la spécification EJB parmi lesquelles : Jonas, JBoss et Tomcat CCM CCM (COBA Component Model) est le modèle spécifié par l OMG (Object Management Group) pour les composants. Ce modèle se distingue des autres par le fait qu il n est pas restreint à un langage ni à un environnement d exécution particuliers. Un composant CCM est localisé dans un conteneur qui lui offre un environnement d exécution. Chaque composant est défini par des attributs et des ports. Les attributs sont utilisés pour sa configuration et les ports représentent des interfaces à travers lesquelles les clients et les autres éléments de l environnement d une application peuvent interagir [Gro06]. Ce modèle de composants supporte les quatre types de ports suivants : Une facette : c est une interface fournie par un composant et qui peut être utilisée par des clients. Un réceptacle : c est un point de connexion qui décrit la capacité du composant à utiliser une référence fournie par d autres composants. Une source d événements : c est un point de connexion qui émet des événements à des récepteurs d événements ou dans un canal. 11

12 Un puits d événements : c est un point de connexion qui permet au composant de recevoir des événements émis par d autres composants. Pour appeler un composant, il faut référencer un de ses ports d entrée. Les connexions sont ensuite établies entre des ports de sortie du composant appelant et des ports d entrée du composant appelé, à condition que ces ports aient des interfaces identiques. Toutes les communications s effectuent en utilisant le bus CORBA. Les interfaces des composants sont décrites en utilisant le langage de description d interface l IDL (Interface Definition Language) de CORBA. L utilisation de l IDL permet de programmer les composants dans des langages différents et indépendamment de leurs environnements d exécution. A l instar de EJB, CCM utilise aussi un descripteur de déploiement où sont spécifiées les propriétés de déploiement des composants. Il existent plusieurs implémentations de CCM parmi lesquelles : OpenCCM, MicoCCM et FreeCCM. 3.2 Modèles académiques Fractal Fractal est le modèle de composants défini par France Telecom R&D et l INRIA dont les caractéristiques principales sont motivées par l objectif de pouvoir construire, déployer et administrer des systèmes complexes [BCS04]. Un composant Fractal est formé d un contenu et d une membrane. Le contenu est constitué d un nombre fini de composants appelés sous-composants. La membrane est constituée d interfaces fonctionnelles correspondant à des fonctionnalités fournies ou requises ainsi que des interfaces de contrôle correspondant à des aspects non-fonctionnels comme l introspection, la configuration ou la reconfiguration. Les interfaces d une membrane peuvent être internes ou externes. Les interfaces externes sont accessibles depuis l extérieur du composant, tandis que les interfaces internes ne sont accessibles qu à ses sous-composants. Le modèle Fractal fournit deux mécanismes permettant de définir l architecture d une application : la liaison et l imbrication. La liaison est ce qui permet aux composants Fractal de communiquer. Il existe deux types de liaisons : Les liaisons primitives sont celles qui lient une interface client et une interface serveur de deux composants du même espace d adressage. Les liaisons composites sont des chemins de communication complexes entre deux interfaces de composants. L imbrication est possible grâce à la notion du composant composite par laquelle on désigne un composant qui contient des sous-composants. Cela permet de donner une vue uniforme d une application à différents niveaux d abstraction. En revanche, un composant primitif ne contient aucun sous-composant. Une autre caractéristique du modèle Fractal est qu il permet la construction de composants partagés. Un composant partagé est un composant inclus dans plusieurs composites et est particulièrement adapté à la modélisation de ressources. Il existe plusieurs plates-formes mettant en œuvre le modèle Fractal parmi lesquelles Julia qui est l implémentation de référence. 12

13 3.2.2 SOFA SOFA (Software Appliances) est un projet [PBJ98] dont l objectif est de fournir une plateforme pour les composants logiciels. Dans le modèle de composants SOFA [Con08], les applications sont considérées comme une hiérarchie de composants imbriqués. Un composant peut être primitif (ne contient pas de sous-composant) ou composite (contient des sous-composants). Toutes les fonctionnalités sont définies dans les composants primitifs. Un composant est décrit par son frame et son architecture. Le frame est une vue «boîte noire» du composant. Il définit des interfaces fournies et requises, et déclare éventuellement des propriétés pour le paramétrage du composant. L architecture reflète une vue «boîte grise» du composant. Elle définit le premier niveau d imbrication dans une hiérarchie de composants. L ensemble de la hiérarchie de composants de l application (tous les niveaux d imbrication) est décrit dans le descripteur de déploiement. Les interfaces, les frames et les architectures des composants SOFA sont décrites en utilisant un langage de définition de composants appelé CDL (Component Definition Language). Ce langage est basé sur l IDL de l OMG qu il étend avec d autres caractéristiques pour permettre les spécifications des composants logiciels. Les composants sont reliés par des connecteurs. En SOFA, les connecteurs sont des entités comme les composants. Chaque connecteur est décrit de la même manière qu un composant, i.e. par un frame et une architecture. SOFA 2.0 [BHP06], est le successeur de SOFA, qui a amélioré certains concepts déjà existants et a introduit d autres concepts omis dans la première version (comme la reconfiguration dynamique). 3.3 Comparaison Dans cette partie, un aperçu sur quatre modèles de composants logiciels est présenté en mettant l accent sur la vision de chacun des modèles, de la conception d une application à base de composants. Cette section discute des principaux avantages et inconvénients de ces modèles [O + 05]. EJB,CCM et SOFA utilisent tous un descripteur de déploiement dans lequel ils précisent les propriétés de déploiement en termes de ressources nécessaires. Cela confère aux modèles une capacité de configuration. Dans EJB, le travail de l utilisateur est facilité par la génération automatique de plusieurs classes (classes fournies par le conteneur et le fournisseur du composant). Il reste cependant, toute une partie de code à mettre en œuvre à cause de la non-prise en compte des propriétés non-fonctionnelles. EJB et Fractal ont une limite qui réside dans le fait qu ils n utilisent pas de langage de description d interface ce qui fait qu ils sont dépendants du langage d implantation (Java). Par contraste CCM semble être le plus indépendant vis-à-vis des langages d implantation grâce à l utilisation de l IDL et des règles de projection vers différents langages de programmation. CCM supporte plus ou moins l assemblage. En effet, celui-ci définit séparément les interfaces requises (dans un modèle conceptuel) et les connecteurs (dans un modèle de déploiement). La réutilisation et l assemblage sont moins supportés par EJB qui ne définit aucun moyen de description des interfaces requises et des connecteurs, ni de référentiel de composant. Les modèles Fractal et SOFA fournissent des avantages de réutilisation et tendent plus à offrir une composition hiérarchique. La notion de configuration n existe pas dans Fractal, l architecture est définie comme un composant composite. Un autre inconvénient de ce modèle est le fait qu il se limite à une définition implicite des connecteurs en ne considérant que les composants et leurs structures. 13

14 En revanche, SOFA définit des connecteurs adaptables aux interfaces, mais il présente l inconvénient d ignorer l implémentation et de se concentrer sur la partie interface/connecteur. Les propriétés nonfonctionnelles ne sont pas prises en compte ni dans Fractal ni dans SOFA. Cependant, SOFA est le seul parmi les modèles présentés, à prendre en compte la mise à jour dynamique des composants. Fractal quant à lui, a la particularité d être introspectable et d autoriser le partage de composants. 4 Conclusion et discussion À travers les avantages et inconvénients présentés précédemment, les qualités et caractéristiques principales [O + 05] devant être satisfaites dans un modèle de composants sont la réutilisabilité et l adaptabilité. Par la réutilisabilité, on désigne le degré de réutilisation permis par un modèle de composants. L adaptabilité quant à elle, exprime l aptitude à contrôler et permettre à un modèle de composant d évoluer dynamiquement. Pour accroître la réutilisabilité d un modèle de composants, certains critères sont préconisés comme : L extensibilité : traduit le fait que l ajout de nouveaux services ne doit pas interférer ceux déjà existants. L évolutivité : signifie que la mise à jour de l implémentation d un composant ne doit pas avoir d impact sur les composants utilisant ses services. La compositionalité : est obtenue par exemple si un composant inclut d autres composants et délègue et envoie ses services d interfaces aux interfaces de ses composants internes. La remplaçabilité : est la possibilité de remplacer un composant par un autre composant qui réalise la même interface. Plusieurs modèles de composants ont été proposés. Ces modèles offrent différentes façons de concevoir une application. Dans ce rapport, nous avons présenté des exemples de modèles issus d initiatives industrielles et d autres issus de travaux d équipes de recherche académiques. D autres modèles de composants ont aussi été développé. Des exemples de modèles existants sont :.Net, Darwin, OSGi, UniCon, Wright... Cependant, ces modèles sont caractérisés par le fait qu ils sont trop proches de la mise en œuvre et imposent des choix de conception dès les premières phases du développement. Or, nous pensons qu il serait utile d introduire ces contraintes progressivement. Dans la première partie de ce rapport, on a vu qu un composant connait plusieurs changements depuis sa spécification jusqu à son utilisation. L objectif de ce stage est de proposer un nouveau modèle de composant qui prend en compte les changements et l évolution du composant. Nous souhaiterions donc élaborer un modèle qui prenne en compte le cycle de vie du composant et qui soit, en outre abstrait. Nous pensons qu il serait ensuite possible d utiliser un langage de méta-modélisation et de transformation comme Kermeta 6 pour raffiner notre modèle vers des modèles concrets. 6 http :// 14

15 Références [BBB + 00] F. Bachmann, L. Bass, C. Buhrman, S. Cornella-Dorda, F. Long, J. Robert, R. Seacord, and K. Wallnau. Volume II : Technical Concepts of Component-based Software Engineering. Carnegie Mellon University, Software Engineering Institute, [BCS04] E. Bruneton, T. Coupaye, and J. Stefani. The fractal component model specification. ObjectWeb Consortium, February, 5, [BHP06] T. Bureš, P. Hnětynka, and F. Plášil. SOFA 2.0 : Balancing Advanced Features in a Hierarchical Component Model. In Proc. of SERA, [BW99] [CLC05] M. Buchi and W. Weck. The greybox approach : When blackbox specifications hide too much. Turku Centre for Computer Science, I. Crnkovic, S. Larsson, and M. Chaudron. Component-based Development Process and Component Lifecycle. JOURNAL OF COMPUTING AND INFORMATION TECHNO- LOGY, 13(4) :321, [Con08] ObjectWeb Consortium. SOFA Component Model. Technical report, [Crn02] I. Crnkovic. Building Reliable Component-Based Software Systems. Artech House, [Crn03] I. Crnkovic. Component-Based Software Engineering :New Challenges in Software Development. Journal of Computing and Information Technology, 11(3) : , [Gro06] Object Management Group. Corba component model 4.0 specification. Specification Version 4.0, Object Management Group, April [HH99] J. Harris and A. Henderson. A better mythology for system design. In Proceedings of the SIGCHI conference on Human factors in computing systems : the CHI is the limit, pages ACM New York, NY, USA, [Mey99] B. Meyer. On To Components [Mey00] B. Meyer. Contracts for Components Interface Definition Languages as we know them today are doomed. SOFTWARE DEVELOPMENT-SAN FRANCISCO-, 8(7) :51 53, [Mic05] S. Microsystems. Enterprise JavaBeans Specification Version 3.0. Technical report, [ND95] O. Nierstrasz and L. Dami. Component-Oriented Software Technology. Object-Oriented Software Composition, 1 :3 28, [O + 05] M. Oussalah et al. Ingénierie des composants : concepts, techniques et outils. Vuibert informatique, [PBJ98] F. Plášil, D. Bálek, and R. Janecek. SOFA/DCUP : Architecture for Component Trading and Dynamic Updating. In Proceedings of the International Conference on Configurable Distributed Systems, [SBW98] C. Szyperski, J. Bosch, and W. Weck. Component Oriented Programming. Springer, [Szy02] C. Szyperski. Component Software : Beyond Object-Oriented Programming. Addison- Wesley Professional,