Les principes d’une approche à base de composants

L’ingénierie des composants logiciels [123] définit une application comme étant l’assemblage d’uni- tés logicielles indépendantes appelées « composants logiciels ».

Définitions Étant donné que le paradigme « composant logiciel » est relativement récent, ses concepts ne sont pas souvent exprimés clairement. Actuellement, il n’existe aucun standard. De ce fait, le terme de « composant logiciel » ne possède pas de définition unique. Voici quelques exemples de définitions qui ont été proposées dans la littérature :

Une des premières définitions du mot « composant » a été donnée en 1995 par Jed Harris, Président du CI Lab :

« un composant est un morceau de logiciel assez petit pour que l’on puisse le créer et le maintenir, et assez grand pour que l’on puisse l’installer et en assurer le support. De plus, il est doté d’interfaces standard pour pouvoir interopérer. »

D’autres définitions proposées dans la littérature insistent plus sur les notions de services fournis et services requis par le composant. Par exemple, celle proposée par Chefrour dans [45] est la suivante :

« Un composant est une entité logicielle qui fournit un service particulier via une interface séparée de l’implantation mettant en œuvre ce service. »

Une des définitions d’un composant logiciel, les plus citées dans la littérature, est celle proposée par Szyperski et al. dans [123] :

« un composant est une unité de composition avec des interfaces contractuellement spé- cifiées et des dépendances explicites sur son contexte. Un composant peut être déployé de manière indépendante et il est sujet à compositions par des parties tierces. »

Cette dernière définition met en avant les notions d’assemblage et d’autonomie des composants. En d’autres termes, un composant logiciel est une entité logicielle indépendante pouvant être installée sur différentes plates-formes, configurée et capable de s’auto-décrire. Tout d’abord, le caractère d’indépen- dance des composants est une propriété essentielle de cette technologie car elle procure aux composants une autonomie leurs permettant d’être réutilisés facilement ; ce qui est l’objectif premier de ce paradigme. Concernant la propriété d’auto-description, celle-ci procure aux composants des propriétés d’introspec- tions qui sont indispensables à la mise en œuvre de leurs adaptations. La propriété de configurabilité offre, quand à elle, à un acteur de l’adaptation (voir Section 1.4.2.5) la possibilité de modifier facilement le comportement d’un composant (en modifiant les valeurs de ses attributs configurables).

Structure d’un composant La tâche d’un composant est de fournir des services et pour cela ils peuvent avoir besoin de services fournis par d’autres composants pour assurer son fonctionnement (voir Figure 1.4). Ainsi, un composant doit pouvoir fournir une description de ses services fournis et requis ainsi que les règles d’interconnexion. De ce fait, un composant logiciel doit être construit sur deux niveaux : un niveau implémentatoire et un niveau architectural.

Le niveau implémentatoire contient le code source correspondant à l’implémentation des services fournis par le composant (i.e. hiérarchie de classes représentant le code de l’implémentation de ses ser- vices et de ses interfaces).

Quant au niveau architectural, il contient une description de la structure externe du composant (i.e. description des services fournis et requis par le composant) ainsi qu’une description de sa structure interne (i.e. description de chaque sous-composant, de leur configuration et des connexions entre ces derniers). Ces descriptions sont généralement réalisées par l’intermédiaire de langages dédiés pour la plupart basées sur XML. Ces langages permettent également de décrire soit le contenu de ses interfaces (i.e. description des services : paramètres, comportement, etc.) soit l’architecture de l’application (i.e. instanciation des composants, assemblage des composants, paramétrisation des services techniques, etc.). Les langages de description d’interfaces sont appelés IDL (Interface Description Language) et ceux de description d’architecture sont appelés ADL (Architecture Description Language) [87].

La structure d’un composant et ses propriétés dépendent du modèle utilisé pour le construire. Ces modèles peuvent être hiérarchiques ou non. Dans le cadre de modèles hiérarchiques, les composants sont de deux types : des composants composites et des composants monolithiques. Les composants com- posites disposent d’une structure externe définissant l’ensemble des services fournis et requis et d’une structure interne définissant l’ensemble des composants qu’ils encapsulent (appelés sous-composants) ainsi que leur configuration d’assemblage (voir Figure 1.4). Les composants monolithiques sont quant à eux définis par leur structure externe : ils sont construits comme un seul bloc et donc ne contiennent pas de sous-composants. Les modèles de composants non hiérarchiques ne définissent quant à eux que des composants monolithiques.

Cycle de vie d’un composant Chaque composant est doté d’un cycle de vie qui part de la spécification jusqu’à l’exécution en passant par le « packaging » et le déploiement. La prise en considération de la to- talité du cycle de vie d’un composant lui permet d’accroître son autonomie et de faciliter son adaptation.

Figure 1.4 – Architecture d’un composant logiciel de type composite

En effet, l’adaptation peut être mise en œuvre au niveau des composants à tout moment dans leur cycle de vie. De plus, la majorité des modèles composants existants offrent la possibilité, durant l’exécution des composants, de contrôler leur cycle de vie. En fait, des mécanismes permettent de démarrer, de stopper ou de mettre en pause un composant. De tels mécanismes facilitent donc l’adaptation statique. En effet, un composant peut être arrêté, adapté puis redémarré.

Modèles de composants Dans la littérature, de nombreux modèles de composants logiciels ont été proposés. Ces derniers peuvent être classifiés en trois catégories [85] : les modèles académiques tels que Fractal [39] et Darwin [83]. Leur objectif premier est de mener des études sur un ou plusieurs aspects particuliers du paradigme de « composant logiciel » ; les modèles industriels tels que JavaBean [62], Enterprise Java Beans (EJB) [86] ou COM/COM+ [31]. Ces modèles de composants répondent plus aux besoins des concepteurs d’applications industrielles ; et enfin, les modèles de références dont l’objectif principal est de définir des normes tout en tenant compte des résultats académiques tels que CCM [59]. Pour illustrer notre état de l’art sur l’adaptation de composants logiciels et d’applications conçues à base de composants, nous avons étudié un panel représentatif de ces différentes catégories de modèle de composants. L’ensemble des modèles de ce panel est présenté dans l’annexe C.