Télécharger le fichier pdf d’un mémoire de fin d’études
Le moment de l’adaptation comme critère de classification
Une phase d’adaptation peut être provoquée par la découvertou l’évolution du contexte d’exécution d’une application. Elle peut être également déclenchée parl’intervention d’une personne physique telle que l’administrateur de l’application ou l’utilisateur, à tout moment dans le cycle de vie d’une appli-cation. Ainsi, on peut distinguer différents moments clefsau cours desquels une application peut être adaptée :
avant le déploiement
L’adaptation de l’application peut être réaliséeau moment de sa conception et de son développe-ment. En effet, si le ou les concepteurs possèdent des informations sur le contexte d’utilisation (i.e. contexte d’exécution), il peut adapter l’application en fonction de ces données. Plus généralement, pendant cette étape du cycle de vie de l’application, les concepteurs construisent l’application de manière à autoriser des adaptations ultérieures. Ils ont pour tâche de prévoir les possibilités d’adap-tation afin d’agir en conséquence.
De plus, l’adaptation de l’application peut également êtreffectuéeavant la compilation de son code source. L’entité physique ou logicielle chargée d’adapter l’application peut alors modifier le code de manière à prendre en compte les données connues sur lecontexte d’exécution.
Enfin, l’adaptation peut être réaliséeaprès la compilation de son code source. Deux cas sont pos-sibles : soit le code source est disponible ; dans ce cas l’adaptateur pourra manipuler ce dernier (i.e. techniques de refactorisation et de transformation de code), puis recompiler les nouveaux fichiers sources de l’application adaptée. Soit, le code source de l’application n’est pas disponible ; dans ce cas, il faut appliquer des méthodes de «reengineering » ;
pendant le déploiement
Le déploiement est une phase importante d’un cycle de vie d’une application. Le déploiement comporte un ensemble de tâches qui doivent être réalisées avnt l’exécution de l’application afin d’assurer son fonctionnement. Parmi ces activités, nous pouvons citer la copie des fichiers binaires sur la machine sur laquelle va être exécutée l’application,la mise en place des connexions entre
les différents éléments qui composent l’application, etc.
L’adaptation de l’application au moment de son déploiement revêt une importance cruciale car à cet instant précis de son cycle de vie, l’application découvre l’environnement dans lequel elle va être exécutée. De nombreux travaux sont consacrés à l’acquisition et à la prise en compte du contexte notamment au moment du déploiement. Ces derniers ont pour objectif majeur de conce-voir des outils permettant à l’application de prendre en com pte son contexte afin de s’y adapter ;
pendant l’exécution
Le contexte d’exécution d’une application peut changer en permanence et c’est notamment le cas pour des applications destinées à fonctionner dans des environnements ubiquitaires et mobiles. Ainsi, l’adaptation pendant l’exécution peut se révéler obligatoire pour certains types d’applica-tion. Comme pour le déploiement, il existe de nombreux outils permettant à l’application d’acqué-rir en continu (i.e. tout au long de son exécution) des connaissances sur son environnement ainsi que sur son comportement.
La dynamicité de l’adaptation comme critère de classification
L’adaptation d’une application peut être réalisée à la volée ou bien nécessiter l’arrêt de l’application. On parle d’adaptation dynamique lorsque celle-ci est réalisée sans arrêter l’application ed’adaptation statique lorsqu’il est nécessaire de stopper l’application pour procéder à l’adaptation :
l’adaptation statique
Les modifications opérées pour réaliser l’adaptation sont ffectuées lorsque l’application est à l’arrêt. Généralement, elles sont effectuées avant la phase de déploiement de l’application sur sa plate-forme d’exécution. Après son déploiement, il est également possible de réaliser une phase d’adaptation statique : pour cela, il suffit de stopper l’exécution de l’application, puis opérer les transformations adéquates et enfin redémarrer l’application ;
l’adaptation dynamique
Adapter dynamiquement une application consiste à introdui re des modifications pendant l’exécu-tion d’une application. Cette activité est également appelée reconfiguration dynamique. L’adapta-tion est donc réalisée après la phase de déploiement dans leycle de vie de l’application. Cette approche ne nécessite pas l’arrêt de l’application contrairement à l’approche statique. Pour qu’une application soit adaptable dynamiquement, il faut que les éléments qui la composent et les modèles utilisés dans sa conception supportent la dynamicité.
Le niveau d’automatisation de l’adaptation comme critère de classification
Ce critère fait référence au degré d’automatisation d’un ocessuspr d’adaptation à savoir la place de l’utilisateur de l’adaptation dans un processus d’adaptation ; l’utilisateur de l’adaptation pouvant être le concepteur/programmeur de l’application, l’administrateur de l’application ou bien l’utilisateur de l’ap-plication. Une adaptation peut être désignée comme manuell(i.e. le processus d’adaptation est entière-ment réalisé par l’utilisateur de l’adaptation), semi-automatique (i.e. le processus d’adaptation nécessite l’intervention de l’utilisateur de l’adaptation) ou automatique (i.e. le processus d’adaptation ne nécessite pas d’intervention de l’utilisateur de l’adaptation).
Il dépend notamment des acteurs de l’adaptation. En fait, unacteur de l’adaptation est une entité physique ou logicielle capable de démarrer, de modifier, de stopper, d’annuler ou bien de superviser une phase d’adaptation. Elle peut intervenir à différents niveaux dans le cycle de vie d’une application (voir Figure 1.7). Nous distinguons cinq acteurs de l’adaptation :
l’utilisateur
Dans certains cas, l’utilisateur peut être un acteur de l’adaptation ; notamment dès lors qu’il est inclus dans un processus décisionnel (déclenchement d’unephase d’adaptation, spécification du résultat de l’adaptation, etc.) ;
le concepteur / programmeur
Il est chargé de concevoir la manière dont l’application va ‘adapters dans un contexte particulier. En fait, il doit définir les règles et les mécanismes qui vont permettre à l’application de s’adap-ter. De plus, il a la possibilité de figer certaines étapes de l’adaptation (i.e. de par la création des règles). Le problème, généralement rencontré dans la création ou la maintenance d’application, réside dans le fait que dans la majorité des cas, ce n’est pas al même personne qui a écrit le code de l’application ou du composant et celle qui souhaite adapter ce code, d’où une certaine difficulté pour réaliser l’adaptation ;
l’administrateur
Il s’agit de la personne qui a la possibilité de déclencher une phase d’adaptation de l’application. Cette opération est généralement réalisée par l’appel à un oplusieurs services fournis par l’ap-plication elle-même et dédiés à cet effet. Par exemple, il peut détecter une anomalie et prendre les mesures nécessaires pour y remédier en adaptant le code de l’application ou bien en démarrant une procédure d’adaptation ;
un adaptateur
Un adaptateur est un outil chargé de réaliser toutes les tâches contenues dans un processus d’adap-tation. Il peut être autonome ou bien contrôlé par l’un des autres acteurs de l’adaptation ; l’application
L’application est l’acteur qui subit l’adaptation généralement déclenchée et réalisée par ceux cités précédemment. Par ailleurs, elle a la possibilité de s’auto-adapter par exemple par le déclenche-ment de capteurs ou d’évènements. Cette procédure passe obligatoirement par une phase d’acqui-sition et d’analyse de son contexte d’exécution. Ainsi, uneapplication peut modifier son propre comportement en observant ses ressources ainsi que les changements de son environnement d’uti-lisation.
Une application est qualifiée d’adaptative lorsqu’elle fournit les moyens à un acteur externe ( i.e. concepteur, administrateur, etc.) de réaliser des adaptations, alors qu’elle est qualifiée d’auto-adaptative lorsque l’adaptation est réalisée de façon interne et qu’elle est déclenchée par des variations de son contexte d’exécution.
Le niveau d’automatisation de l’adaptation dépend également de la profondeur (quels sont les étapes pour chaque travail) et de la pertinence de la décision (quels sont les éléments de décisions).
L’environnement d’exécution de l’application comme critère de classification
Les travaux existants se positionnent généralement dans lecadre d’environnement particulier de manière à répondre à une problématique spécifique. En fait, ‘objectifl et la réalisation de l’adaptation peuvent être très différents selon l’environnement d’exécution dans lequel elle est positionnée. Nous avons recensé quatre types d’environnements sur lesquels se sont focalisées les approches existantes ; chaque type d’environnement est doté de caractéristiques pécifiques sur lesquelles doit se baser l’adap-tation :
les environnements mono-machine
Dans le cadre d’un environnement mono-machine, l’application est déployée et exécutée sur une seule machine (i.e. l’application utilise uniquement les services et les données fournies par la ma-chine sur laquelle elle est installée). Dans ce cadre précis, l’adaptation peut consister par exemple à charger ou à décharger certaines parties d’un composant si les ressources nécessaires à son dé-ploiement ne sont pas suffisantes pour permettre un déploiement intégral du composant. Dans ce cas, on parle d’adaptation au support ;
les systèmes distribués standard, les grilles de calculs etles clusters
Dans un environnement réparti, une application peut être déployée et exécutée sur plusieurs ma-chines d’un réseau qui peut être filaire i(.e. réseaux physiques) ou sans fil (Wifi , Bluetooth, IR, etc.). Elle peut donc utiliser des données ou des services qui sont disponibles sur des sites (i.e. machines) différents par l’intermédiaire du réseau. Les incipauxpr problèmes à résoudre lors de la création d’applications destinées à être exécutées dansce type d’environnement sont la gestion des communications distantes (i.e. appel à des services distants par l’intermédiaire du réseau), la tolérance aux fautes (i.e. gestion des transactions, tolérance aux pannes, etc.), la disponibilité des ressources et services (i.e. éviter les problèmes de privation liés à la gestion de la cohérence et de la concurrence des transactions), la gestion des ressources distantes (i.e. gestion des caches, bases de données distribuées) et enfin la sécurité.(e. authentification, transactions sécurisées, etc.).
Une grille informatique ou grid est une infrastructure matérielle constituée d’un ensembl co-ordonné de ressources potentiellement partagées, distribuées, hétérogènes, externalisées et sans administration centralisée.
Dans ce type d’environnement, l’adaptation est généralement utilisée afin d’améliorer les perfor-mances de l’application ou de certains composants. Ce résultat peut être obtenu en permettant l’exécution parallèle de certains morceaux de code en fonction du contexte ;
les environnements mobiles
L’informatique mobile (en anglais « Mobile Computing » ) est un domaine qui concerne la fa-brication et l’utilisation d’ordinateurs de taille réduite que l’on peut transporter avec soi dans ses déplacements et qui, le plus souvent, peuvent être reliés nssa fil à un réseau ou à d’autres ordina-teurs. Ainsi, la grande problématique des approches mettan en jeu ce type de réseau consiste à garantir à l’utilisateur qu’il puisse continuer d’accéder à l’information fournie par une infrastruc-ture distribuée sans tenir compte de son emplacement.
L’informatique mobile se focalise sur la mobilité du matériel, des données et du logiciel dans des applications informatiques et leur possible apparition et disparition (i.e. liée aux connexion/décon-nexions des machines) durant toute la durée de vie de l’application.
De ce fait, elle peut être considérée comme une classe spécialisée des systèmes répartis où quelques nœuds peuvent désengager des opérations distribuées communes, se déplacer librement dans l’es-pace physique et se reconnecter ultérieurement à un autre segment probablement différent d’un réseau informatique afin de reprendre des activités suspendues ;
les environnements ubiquitaires
Un environnement ubiquitaire (voir Section 1.5) correspond à un réseau ambiant se caractérisant par des entités mobiles communicantes et parfois de très petite taille et possédant des caractéris-tiques techniques très différentes les unes des autres allant du téléphone portable aux capacités réduites (i.e. puissance de calcul faible, batterie à faible autonomie, ta ille de l’écran limitée, capa-cité de stockage faible, etc.) à l’ordinateur de bureau. L’informatique ubiquitaire consiste à faire fonctionner une application dans n’importe quel environnement physique tout en réalisant l’adap-tation de manière totalement transparente aux yeux de l’utilisateur [132].
Les techniques de mise en œuvre des approches d’adap tation comme critère de classifiction
Les techniques utilisées pour mettre en œuvre l’adaptation d’une application conçue à base de com-posants logiciels varient en fonction de nombreux paramètres tels que la cible de l’adaptation, le moment de l’adaptation, etc.
Présentation des techniques existantes Afin de présenter les techniques d’adaptation existantes, nous les avons classifiées en fonction de leur cible à savoir les co mposants, les connecteurs ou l’architecture logicielle.
Adaptation des composants
BCA (Binary Component Adaptation)
BCA [73] est une technique d’adaptation qui agit sur le code binaire des composants. Elle ne nécessite pas le code source. Le système BCA a été implémentéJava. L’adaptation peut être réalisée à tout moment dans le cycle de vie du composant. Poureffectuer l’adaptation d’un com-posant après le déploiement, l’application doit construire un fichier de spécification contenant les éléments que l’on souhaite modifier tels que les méthodes, interfaces, champs, etc. Un compilateur fournit alors un fichier binaire contenant le code binaire mo difié qui est nécessaire pour que le composant soit adapté. Ensuite, les autres classes qui fontréférences au composant adapté doivent être recompilées. L’assemblage des fichiers de type.class peut alors être effectué puis exécuté.
La paramétrisation
Cette technique d’adaptation réside dans la modification des paramètres d’exécutions d’une ins-tance de composant (i.e. changer les valeurs des propriétés des composants). Elle nécessite la création d’interfaces dédiées.
Les interfaces actives
Une interface active [63] est une interface qui peut ajouter des opérations à effectuer quand une méthode est invoquée i(.e. avant ou après l’appel). Par exemple, lorsqu’une méthode est appelée avec une série de paramètres, ces derniers peuvent subir desprétraitements ou être renvoyés vers d’autres méthodes. Chaque composant est associé à un composant chargé d’assurer l’appel aux méthodes définies par les interfaces actives. Ces deux composants communiquent au travers d’une interface spéciale.
La transformation
La transformation consiste à modifier l’implémentation d’u n composant (i.e. son code source). Cette opération peut être réalisée par l’intermédiaire nd’uoutil d’analyse et de transformation du code, séparé de l’application. Elle peut également être mise en œuvre au travers d’un service fourni par le composant à adapter. Il existe de multiples technique s permettant de réaliser la transforma-tion de code :
la modification sur place « open-source »
Cette technique réside dans le fait que le constructeur de l’application puisse si nécessaire mo-difier directement le code source des composants. Aussi, le c onstructeur doit être capable d’ana-lyser le code d’un composant et de l’interpréter de manière àopérer des changements ;
l’utilisation de langages de script
Les langages de script tels que Perl ou Tcl/Tk permettent de générer de nouveaux fichiers sources qui vont contenir la nouvelle implémentation du composant après adaptation. Le code va être modifié en fonction de règles prédéfinies par le programmeur. Ils permettent de réorganiser les composants en agissant directement sur le code source. Ils sont généralement utilisés pour spécifier comment un composant interagit avec un autre composant et comment les structures de données échangées doivent être transformées. Ils peuvent être utilisés pour générer les liens entre les composants pendant la phase d’assemblage d’une application ;
l’utilisation de langage de composition
Ce sont des langages qui possèdent un plus haut niveau d’abstraction qui permet de travailler sur la composition des composants. Ils doivent être capablede manipuler à la fois des objets et des composants dont le contenu peut être distribué. Par exemple, PICT [113] et BML (Bean Markup Language) [129] sont des langages de composition ;
la restructuration
La restructuration de logiciels, aussi appelée refactorisation (refactoring) quand elle est utili-sée dans le contexte d’applications orientées objets, est neu transformation d’une représenta-tion existante en une représentation sémantiquement équivalente sans changement de niveau d’abstraction [53]. Cette technique est généralement utiséel pour améliorer la structure d’un système [99] afin d’augmenter sa maintenabilité. De ce fait, le système devient plus facile à comprendre et donc certaines parties deviennent plus réutilisables [55]. De même, l’ajout de nouvelles fonctionnalités est alors plus aisé. Parmi les différentes applications à la restructura-tion, nous pouvons citer l’élimination du code dupliqué en uev d’améliorer sa lisibilité ou bien le partitionnement de code afin de permettre une exécution parallèle. Cette dernière opération consiste à fragmenter une application en différentes portions tout en préservant la sémantique de l’application initiale.
L’héritage
Une technique d’adaptation pour la réutilisation est l’héritage. Cette technique, issue du monde objet, [130] permet à un composant d’acquérir les caractéristiques d’autres composants et ainsi d’obtenir des composants dotés de comportements analogues. Cependant, l’héritage est très peu utilisé par la communauté de « composants logiciels » au profit de la composition pour faciliter la réutilisation.
Le « wrapping »
Un wrappeur [56, 70] est un conteneur d’objets qui encapsule le composant et qui fournit des interfaces qui permettent d’étendre les services proposéspar le composant qu’il contient. Il peut donc contenir d’autres interfaces destinées à contrôler le composant qu’il contient ou à fournir de nouvelles fonctionnalités. Il n’y a aucune frontière claire entre l’emballage et l’agrégation, mais l’emballage est employé pour adapter le comportement du composant inclus tandis que l’agréga-tion est employée pour composer la nouvelle fonctionnalitéhors des composants existants four-nissant la fonctionnalité appropriée. Généralement, cettechnique est utilisée pour étendre une classe ou bien transformer une interface d’une classe par une autre. Il existe plusieurs approches comme l’héritage pour les composants, l’agrégation, les filtres de composition ou les adaptateurs.
Classification des approches existantes suivant la cible de l’adaptation
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.
Classification des approches existantes suivant le ur prise en considération de composants existants
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.
Classification des approches existantes suivant l’ environnement d’exécution
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.
Classification des approches existantes suivant le moment et la dynamicité de l’adaptation
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.
Classification des approches existantes suivant le niveau d’automatisation de l’adaptation
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.
Classification des approches existantes suivant le s techniques d’adaptation utilisées
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.
|
Table des matières
— Corps du document —
Introduction
1 État de l’art : l’adaptation dans l’ingénierie des composants logiciels
2 Adaptation structurelle de composants logiciels : contexte et problématique
3 Adaptation structurelle par la ré-ingénierie de composants existants
4 Auto-adaptation structurelle de composants logiciels
5 Implémentation et expérimentation de l’adaptation structurelle dans des environnements ubiquitaires
Conclusion et perspectives
— Annexes —
A Glossaire
B Travaux représentatifs de l’adaptation de composants et d’architectures logiciels
C Modèles de composants logiciels
— Pages annexées —
Bibliographie
Télécharger le rapport complet
