Modèle de composants et infrastructure

Un composant peut être amené à interagir avec d’autres composants qui ne sont pas connus à l’avance. Mais pour que des composants quelconques puissent être composés les uns aux autres dans le but de concevoir de nouveaux services, il est nécessaire qu’ils puissent se comprendre, partager un « protocole » d’interaction commun. Cet ensemble de points d’accord est appelé un modèle de composants.

2.1.5.1 Notion d’un modèle de composants

Un modèle de composants définit l’ensemble des contraintes que doivent respecter des composants développés en toute indépendance, dans des lieux différents, par des personnes différentes pour interagir. Il serait plus correct de parler de « langage » plutôt que de « modèle » de composants. Mais le terme de « modèle » est maintenant passé dans le vocabulaire commun. Cet aspect langage se retrouve d’ailleurs dans les informations dont font état les modèles de composants. Ils détaillent au minimum les informations qui suivent.

— La syntaxe et la sémantique des composants : la façon dont ils doivent être construits (par exemple qu’ils doivent posséder certaines interfaces) et décrits (en usant d’un langage de description d’interfaces qui peut être différent du langage de programmation du composant lui-même). Il s’agit de fixer la signification de concepts récurrents tels que : interface, port, conteneur, etc. ;

— La syntaxe et la sémantique de la composition : détermine comment les composants sont assemblés, leur localisation, le mode de contrôle du flot d’exécution, le protocole de communication, le format d’encodage des données échangées, les ressources universelles à disposition des composants et la manière d’en profiter.

Un modèle de composants n’est qu’une spécification de langage. Une infrastructure fournit une implantation concrète d’un modèle de composants pour une architecture matérielle et logicielle cible. L’infrastructure va fournir le support aux composants pour qu’ils puissent remplir leurs missions et interagir dans le respect du modèle de composants. Une grande variété de modèles de composants a été proposée dans le domaine du génie logiciel.

Parce que je veux être en mesure d’utiliser "tel quel" les outils d’analyse de code disponibles, il était nécessaire pour mon étude que je me place dans un modèle de com- posants reposant sur un paradigme convenablement outillé sur le plan des métriques (impératif, objet, etc). On trouvera dans [LW07] une analyse comparative de 13 mo- dèles de composants. Parmi les modèles de composants existants, plusieurs sont basés sur le paradigme objet tels que JavaBeans [DeM02], EJB [G+_{06], OSGi [All07], Sa-}

D’après Crnkovic, ceci est dû au fait que plusieurs principes issus de l’orienté-objet sont directement utilisés ou étendus dans la CBSE [CSVC11]. Dans les modèles de compo- sants basés sur l’objet, selon [ASSV10], un composant est considéré comme un ensemble de classes qui collaborent pour fournir une fonctionnalité.

Pour mes travaux, j’ai choisi de me placer dans le modèle OSGi. Les raisons qui m’ont fait choisir OSGi sont les suivantes :

1. J’admets que la partie du code qui est spécifique au modèle composant ne doit pas avoir un impact significatif sur les mesures du code source spécifique au composant. Dans OSGi, c’est le cas. Il n’y a pas de classes, autres que métier, supplémentaires pour définir un composant.

2. Le modèle OSGi utilise une granularité de niveau package pour exprimer les dé- pendances entre les composants. D’ailleurs, il est le seul modèle, à ma connais- sance, qui emploie cette granularité. Les autres modèles adoptent généralement des dépendances d’un niveau plus abstrait tel que le module. Je voulais profiter à travers OSGi de ce niveau de granularité "classique" utilisé déjà dans les para- digmes instrumentés. Cette granularité est de plus en parfaite adéquation avec le type de métriques que je désire appliquer.

2.1.5.2 Le modèle de composant OSGi

Le modèle de composant OSGi (Open Service Gateway Initiative) est un standard industriel définie par l’Alliance OSGi en 1999 pour traiter spécifiquement du manque de soutien à la modularité dans la plateforme Java [All07]. Ce modèle de composant est le fruit d’un consortium de partenaires industriels. Le modèle OSGi facilite l’obten- tion d’une architecture flexible des systèmes qui peuvent évoluer dynamiquement. Les applications OSGi peuvent ainsi, ajouter un service, en retirer ou les modifier lors de l’exécution. Ce modèle est utilisé dans une large gamme d’applications à grande échelle de l’industrie telles que celles pour les appareils mobiles et les serveurs d’applications des entreprises.

Dans OSGi, un composant est appelé un bundle. Chaque bundle, comme l’illustre la Figure 2.2, est stocké dans un seul fichier JAR qui emballe le composant : son code, ses ressources et un fichier "manifest" qui contient des méta-données supplémen- taires [HPM11].

Le fichier manifest précise principalement les dépendances du composant afin de permettre aux composants d’interagir. Un exemple de fichier manifest est présenté dans l’annexeA de ce mémoire.

L’interface d’un composant peut être définie comme une spécification de son point d’accès. Les interfaces, dans OSGi sont spécifiées à l’aide de packages.

— Les interfaces fournies sont exprimées en tant que "Export-Package" et ce sont les packages qui embarquent les services destinés à être offerts par un bundle. — Les interfaces requises sont exprimées en tant que "Import-Package" et ce sont les

services regroupés en packages importés qu’un bundle exige de l’environnement pour son bon fonctionnement.

Figure2.2 – Un bundle contient le code, les ressources, et les méta-données - Extrait

de [HPM11]