Adaptation structurelle par la ré-ingénierie de composants existants

L’adaptation d’une application peut concerner son comportement ou sa structure. Cependant, nous avons constaté que la majorité des approches existantes a pour objectif de faire évoluer le comportement en fonction de son environnement d’exécution (i.e. adaptation adaptative) ou de le rendre plus performant (par exemple, [28, 44, 73, 114]). Peu de travaux se consacrent à adapter la structure de l’application afin de la rendre plus flexible (par exemple, [9, 47, 50]). Or, c ette stratégie est grandement encouragée par le fort développement de l’informatique ubiquiste où laflexibilité est indispensable pour permettre le déploiement d’application dans certaines conditions (ressources limitées par exemple) et garantir la continuité et la qualité de service comme nous pourrons le constater dans la section 1.5.

Par ailleurs, les approches qui proposent d’adapter la structure d’une application à son environnement d’exécution se focalisent sur le placement des composants sur l’infrastructure de déploiement disponible (i.e. adaptation de l’architecture) (par exemple, [3]) et peu se proposent d’adapter l’application au niveau des composants logiciels (par exemple, [46, 47, 58]).

De plus, les approches qui permettent d’adapter la structure d’un composant logiciel présentent éga-lement d’autres limitations, notamment relatives au type de composants pris en considération. En effet, les approches destinées à adapter la structure d’un composant logiciel peuvent être catégorisées en deux parties : d’une part, les approches qui se proposent d’adapter des composants hiérarchiques (par exemple, [46, 47, 58]). Dans ce cas, l’adaptation prend généralementla même forme que l’adaptation d’une ar-chitecture (i.e. gestion des sous-composants, choix de configuration, etc.) ; d’autre part, l’adaptation de composants monolithiques. Dans ce cas, l’adaptation se traduit généralement soit par la reconfiguration de ses paramètres (i.e. attributs, etc.), soit par la mise en œuvre du patron de conce ption « Strategy » (i.e. définition de plusieurs implémentations possibles pour un même composant et sélection en fonction du contexte de l’implémentation à exécuter) qui permet de définir plusieurs comportements pour un même composant (par exemple, [28, 44, 95]). Ainsi, seul le comportement du composant peut être adapté.

A notre connaissance, il n’existe pas d’approche permettant d’adapter la structure d’un composant logiciel monolithique.

Nous avons également constaté que la majorité des travaux que nous avons recensés sont étroitement liés à un modèle de composants particulier ou proposent eux-mêmes leur propre modèle de composants adaptatifs (par exemple, [28, 44, 47, 50]). De ce fait, l’adaptation de composants logiciels existants exige généralement que ces derniers soient développés à nouveaufina de les rendre conforme à un modèle spécifique lui garantissant son adaptation. Un problème se pose alors pour les composants existants tels que les COTS [67] qui ne peuvent être adaptés que s’ils sont développés à nouveau ; ce qui ne peut être envisagé pour des raisons de coût.

Pour que ces approches puissent être utilisées dans le cadrede l’adaptation de composants existants, les travaux en question doivent fournir des mécanismes (généralement un processus de transformation) permettant de transformer tout type de composants en un composant conforme au modèle qu’ils pro-posent. Cependant, dans la majorité des travaux étudiés, auc ne méthode n’est proposée pour obtenir un tel composant. De plus, peu de travaux proposent des approches génériques i(.e. indépendantes de tout modèle de composants) pour adapter ou rendre adaptatif des composants logiciels existants (par exemple, [3, 33, 58]) bien que cette solution soit, avec la précédente(proposition d’un modèle et d’un processus permettant d’obtenir un composant existant conforme à ce mo dèle), la mieux appropriée pour favoriser la réutilisation de composants existants.

A cause de la démocratisation des terminaux mobiles tels queles téléphones portables, PDA et autres, depuis quelques années, la majorité des travaux portant surl’adaptation d’applications en général et plus récemment, d’applications conçues à base de composants log iciels se positionnent dans le cadre d’en-vironnements ubiquitaires et mobiles (par exemple, [47, 81, 95]). En effet, l’informatique ubiquitaire et mobile dispose de caractéristiques telles que l’hétérogénité des terminaux et des moyens de communi-cation, qui rendent le domaine de recherche unique et fertile.

Dans le domaine des composants logiciels, les projets existants tentent de proposer des approches visant à introduire certaines propriétés liées à l’ubiquité telles que la prise en compte du contexte ou bien la gestion des connexions et des déconnexions des ressources d’un tel réseau, à des applications existantes.

La plupart des approches proposées dans la littérature ont ourp objectif d’adapter les applications au moment de leur exécution et ce, sans l’arrêter (par exemple,[28, 44, 47, 76]). Ceci est dû, comme nous l’avons évoqué précédemment, au fort développement de formatiquel’in ubiquitaire qui nécessite la prise en compte permanente du contexte d’exécution par l’application de manière à lui garantir une continuité de service et une qualité de service.

D’autres approches se sont focalisées sur le déploiement d’applications conçues à base de compo-sants (par exemple, [3, 46]). Cependant, comme nous l’avons évoqué, ces travaux se focalisent sur le placement des composants à déployer sur l’infrastructure disponible. A notre connaissance, aucun travail ne permet d’adapter le déploiement de composants logiciels.

Concernant les approches statiques (par exemple, [73]), elles sont destinées généralement à introduire des points de variabilité permettant à l’adaptation ou aux composants d’adapter leur comportement lors de l’exécution.

La plupart des travaux existants ont pour objectif de concevoir des applications auto-adaptatives (i.e. l’adaptation est réalisée par l’application elle-même) sdèlors qu’ils se positionnent dans un contexte d’adaptation dynamique (par exemple, [46, 47, 58]). En effet, dans de nombreux environnements tels que les environnements ubiquitaires, le contexte d’exécution est en perpétuelle évolution. De ce fait, une adaptation manuelle, réalisée par l’administrateur del’application ne peut être envisagée. Généra-lement, une couche non-fonctionnelle est intégrée aux composants afin de les rendre auto-adaptatifs. Cette couche peut prendre la forme d’un service non-fonctionnel intégré aux composants (par exemple, [47]), d’un composant non-fonctionnel ajouté au modèle (par exemple, [3, 9, 81]) ou bien d’un niveau méta (par exemple, [44, 58, 95]) permettant d’agir sur l’application pour l’adapter (i.e. déclenchement de l’adaptation, prise de décisions et réalisation de l’adaptation).

Dans la majorité des approches, l’adaptation doit être prévue dès la conception et le développement de l’application (par exemple, [28]). Par exemple, certaines stratégies d’adaptation utilisant le patron de conception « Strategy » doivent faire appel aux programmeurs qui sont chargés d’implémenter différentes versions d’un même composant de manière à ce qu’il exécute celle la mieux adaptée au contexte courant. Cependant, ce type d’adaptation est très limitatif car il ne permet pas de réagir à des évènements non prévus par les programmeurs. En effet, toutes les situation doivent être prévues dès la conception de l’application.

De plus, les politiques d’adaptation sont généralement définies par l’administrateur de l’application sous forme règles ECA (Évènement Condition Action) (par exemple, [47, 58]). Ces politiques peuvent dans certains cas être insérées pendant l’exécution de l’application. De ce fait, le rôle de l’administrateur reste prépondérant dans la majorité des approches proposée.

Les techniques d’adaptation utilisées dans le cadre des approches existantes sont étroitement liées à la cible de l’adaptation et au moment de l’adaptation.

Concernant les techniques permettant d’adapter le comportement d’une application ou d’un compo-sant, les plus utilisées dans la littérature sont la réflexion (par exemple, [44, 47, 50]) et la mise en œuvre de patron de conception (par exemple, [28, 44, 95]). En effet, la réflexion offerte, comme nous avons pu le constater précédemment, par la plupart des infrastructures logicielles permet d’adapter facilement le comportement d’une application ou des entités qui la compose de par l’utilisation des propriétés d’inter-cession qui permettent d’agir sur ces entités. Concernant esl patrons de conception, les plus utilisés sont le patron d’observation (Observer) et le patron Strategy. Ces derniers permettent d’observer le contexte d’une application et d’adapter le comportement des composants en sélectionnant celui qui est le plus adapté à la situation. Concernant les techniques permettant d’adapter la structure d’une application ou d’un composant, la plus utilisée est la reconfiguration (par exemple, [9, 47, 58, 81]). Cette technique permet de réorga-niser la structure d’une application ou d’un composant de par la modification des connexions entre ses composants ou bien l’ajout, le remplacement ou la suppression de composants. Cependant, cette tech-nique ne permet d’adapter que des assemblages de composants déjà existants (assemblages à plat ou bien assemblages hiérarchiques).

Très peu d’approches s’intéresse à adapter des composants sous forme monolithique. En fait, dans l’ingénierie des composants logiciels, seul le projet Coign [69] propose une approche permettant de dis-tribuer automatiquement des composants COM sous format binaire. Coign est basé sur la construction d’un graphe représentant les interactions entre les différents composants d’une application. Des algo-rithmes de découpage sont alors appliqués sur ce graphe afin de minimiser le nombre de communica-tions susceptibles d’être réalisées entre différentes tiespar du graphe ainsi que les délais d’attentes liés à l’infrastructure distribuée. Il dispose également d’algorithmes d’optimisation. Cependant, Coign ne traite pas tous les problèmes liés au partitionnement de code. Par xemple, le processus ne peut pas s’appliquer des composants partageant des données au travers de pointeurs mémoires. De plus, il est spécifique à un modèle en l’occurrence le modèle COM ; ce qui exclut donc la grande majorité des composants existants.

Ainsi, nous pouvons constater qu’aucune approche proposéedans la littérature ne permet d’adapter la structure de tout type de composants logiciels existants (monolithiques et composites). L’adaptation de la structure a cependant été étudiée dans domainele de l’orienté objet où de nom-breuses approches permettant de partitionner des applications existantes ont été proposées. Jamwal et Iyer proposent dans [71] de construire des objets « cassables » appelésBobs permettant de construire des architectures flexibles. Un Bob est une sorte d’objet qui possède une structure simplifiée de manière à pouvoir restructurer facilement ses fonctionnalités (i.e. son code). L’objectif est d’intégrer à ces objets des mécanismes permettant de mettre en œuvre leur fragmentation (découpage en sous-entités) et leur redéploiement. Dans leur implémentation réaliséen eJava, les Bobs sont des classes Java Standard ayant des caractéristiques restreintes (pas d’héritage, asp d’objet actif, pas d’attribut public, etc.). Pour chaque Bob, le programmeur doit fournir les méthodes publiques de la classe et une spécification des  méthodes qui ne peuvent pas être séparées lors d’une fragmentation. Ces données sont alors compiléesl’aide d’un outil fourni par le projet, afin d’obtenir le cod e source Java correspondant. Une application construite dans le cadre de cette approche est donc constituée d’objets Java standard et deBobs.

Pangaea [120] est un système qui permet de rendre distribué des programmes Java standard. Il est basé sur l’analyse statique de code source et permet de déterminer la stratégie de distribution la mieux adaptée au contexte et d’introduire des mécanismes de distribution, indépendamment de la plate-forme et de manière transparente et automatique. Ce système ne pose pas de restriction sur les objets Java utilisés ; cependant, il requiert l’utilisation d’un compilateur spécifique fourni dans le cadre du projet. Pangaea se focalise plus particulièrement sur les applications de type client/serveur. Par ailleurs, Pangaea comporte un outil graphique permettant de représenter la structure d’un programme comme un graphe d’objet.

Le projet Addistant [124] est également consacré au partitionnement de code binaire Java. En effet, le système Addistant permet de distribuer du code Java qui a été conçu pour être exécuté sur une seule machine virtuelle. Les utilisateurs du système doivent d’une part indiquer les sites sur lesquels les ins-tances de classe doivent être allouées, d’autre part, définir comment sont implémentés les références sur des objets distants. Addistant transforme alors automatiquement le code binaire de l’application au mo-ment de son chargement dans la machine virtuelle, en fonction des fichiers de configuration fournis par l’utilisateur. Addistant utilise une approche basée sur des proxys générés automatiquement pour établir des références distantes. Cependant, Addistant impose certaines restrictions au niveau des classes qui doivent être modifiables afin d’être traitées.

J-Orchestra [125] est également un système permettant de partitionner automatiquement des pro-grammes Java. Il est relativement similaire au projet Addistant. En fait, il réside dans la transformation de code Java sous un format binaire en application distribuée pouvant être exécutée sur des machines virtuelles différentes. Ainsi, les appels locaux sont transformés en appels distants, les références di-rectes à des objets locaux sont transformées en références ersv des proxys, etc. Il utilise des fichiers de configurations similaires à ceux utilisés dans le cadre du pr ojet Addistant. Cependant, ces derniers sont automatiquement générés De plus, J-Orchestra offre un support pour la migration d’objets et l’optimi-sation dynamique de la configuration de distribution. En eff et, une fois le déploiement de l’application réalisé, J-Orchestra offre à l’utilisateur la possibilitéde déplacer les classes d’un site à un autre. Des outils d’analyse et de supervision vérifient en permanence la validité du partitionnement.

D’autres projets tels que Orca [6] et JavaParty [105] ont pour objectifs d’automatiser les décisions permettant de paralléliser une application centralisée.