Développement de composants Fractal adaptatifs

Développement de composants Fractal adaptatifs

Caractéristiques des logiciels adaptatifs

Dans cette section, nous définissons plus précisément la notion d’adaptation, en général et dans le cas du logiciel, puis nous étudions les caractéristiques spécifiques des logiciels adaptatifs et les critères qui nous servirons de grille de lecture dans le chapitre 3 qui étudie l’état de l’art. 

Adaptation et logiciels adaptatifs

D’après le dictionnaire, adapter consiste à « rendre (un dispositif, des mesures, etc.) apte à assurer ses fonctions dans des conditions particulières ou nouvelles. » Cette définition implique la présence d’un système (le dispositif), qui réalise une fonction particulière. La fa¸con dont le système réalise cette fonction dépend – au moins en partie – du contexte dans lequel il se trouve. Lorsque le contexte est modifié, créant des conditions particulières ou nouvelles, le système doit donc être adapté afin de continuer à réaliser sa fonction dans le nouveau contexte. Une adaptation est donc une modification d’un système, en réponse à un changement dans son contexte, avec l’objectif que le système résultant soit mieux à même de réaliser sa fonction dans le nouveau contexte. Il est à noter que si toute adaptation est mise en œuvre par une modification du système, une modification quelconque d’un système n’est pas systématiquement une adaptation. Elle ne peut l’être que si le nouveau système, modifié, est meilleur que l’ancien, compte tenu des nouvelles conditions. Cette distinction est fondamentale, car elle met en évidence que l’on ne peut parler de l’adaptation d’un système que si l’on dispose de critères permettant d’évaluer sa qualité, qui détermine ce que « meilleur » signifie. Plus formellement, étant donné un système S, on se donne une fonction f (pour fitness, ou adéquation), qui évalue la qualité de S. En pratique, un système n’est jamais complètement isolé, et existe dans un contexte qui influence son fonctionnement. Si C représente ce contexte, alors f(S, C) représente l’adéquation de S au contexte C. Si S se trouve dans un contexte différent C 0 , il peut arriver que f(S, C 0 ) < f(S, C), c’est-`a-dire que S est moins bien adapté à C 0 qu’`a C. Dans ce cas, nous devons donc modifier S afin d’obtenir un nouveau système S 0 tel que f(S 0 , C 0 ) ≥ f(S, C 0 ) 7 . Dans un système dynamique, le contexte évolue de fa¸con continue au cours du temps. Ce processus d’adaptation doit donc lui aussi être renouvelé pendant toute la durée de vie du système, soit de fa¸con continue, soit par étapes discrètes, suivant la nature du système. Dans la suite de cette thèse, on dira qu’un système est adaptable s’il peut être adapté par une entité extérieure (logicielle ou non), et qu’un système est adaptatif s’il s’adapte automatiquement et de fa¸con autonome. Un système adaptatif est à la fois le sujet et l’acteur de l’adaptation Ledoux et al.; Dowling and Cahill ; il se modifie donc lui-même, en fonction des évolutions de son contexte afin de toujours offrir la meilleure qualité possible relativement à ce contexte. Dans le cadre du génie logiciel, cette notion de système adaptatif correspond à un logiciel qui s’adapte dynamiquement – c’est-`a-dire au cours de son exécution – aux caractéristiques et aux évolutions de son contexte d’exécution. Un système adaptatif peut être caractérisé par : – Un ensemble d’opérations permettant de modifier le système. Etan ´ t donné un état initial, cet ensemble d’opérations définit un espace d’états regroupant tous les états possibles du système. Dans le cas du logiciel, ces opérations se traduisent par des mécanismes de reconfiguration dynamique. Les caractéristiques de différents mécanismes possibles sont décrits et discutés dans la section 1.2.2. – Un contexte, qui regroupe tous les éléments externes au système qui influencent son fonctionnement. Ce contexte est le plus généralement dynamique, évoluant de fa¸con plus ou moins prévisible au cours du temps. Bien entendu, le système peut lui-même avoir une influence sur certains éléments de ce contexte. Ce point est approfondi dans le cas du logiciel à la section 1.2.3. – Une fonction d’adéquation, qui permet à tout moment de savoir dans quelle mesure le système réalise ses objectifs relativement au contexte dans lequel il se trouve. Par définition, un système 7Le problème de l’adaptation est très proche de celui de l’optimisation, qui cherche à maximiser la fonction f en modifiant le système, c’est-`a-dire à déterminer le système Smax tel que ∀S, f(S) ≤ f(Smax). La différence est que l’optimisation se fait « à contexte constant », alors que le contexte, ses évolutions et son impact sur le système sont au cœur du problème de l’adaptation. On peut donc voir le processus d’adaptation comme une optimisation en continue, perpétuellement remise en cause (au moins partiellement) par les évolutions du contexte dans lequel fonctionne le système. est « une combinaison de composants qui agissent ensemble afin de réaliser une fonction impossible à réaliser par aucune des parties » (définition de l’ieee), et cette fonction est donc d’une certaine manière inhérente au système. En pratique, cette fonction est très rarement définie explicitement, et fait souvent appel à des critères plus ou moins subjectifs pour évaluer la qualité d’un système, qui peuvent dépendre de l’observateur. Dans notre cas particulier, cette fonction correspond à la spécification du problème pour lequel le logiciel à été con¸cu et aux critères de qualité de service. – Une stratégie d’adaptation, chargée de mettre en œuvre le processus d’adaptation dans le système, afin qu’il soit toujours le plus performant possible (tel qu’évalué par la fonction d’adéquation), relativement à son contexte d’utilisation, et ce malgré les variations de ce dernier. Dans un logiciel, elle va se traduire par un ensemble d’algorithmes et de données de l’application adaptative chargés de réaliser les adaptations. Cette stratégie utilise pour cela les autres éléments du système : sa connaissance du contexte d’exécution, et l’existence de mécanismes de reconfigurations. La nature et les caractéristiques de cette stratégie sont développés dans la section 1.2.4.

Mécanismes de reconfiguration dynamique

La capacité d’un système adaptatif en général à être adapté est déterminée en grande partie par le nombre et la nature des opérations applicables au système, elles-mêmes en partie déterminées par la structure du système. Plus un système supporte d’opérations permettant de le modifier, et plus ces opérations sont « puissantes », plus il est souple et donc a priori capable d’être adapté à un grand nombre de situations. Nous nous intéressons ici aux différents mécanismes existants permettant de reconfigurer dynamiquement une application. Il existe de très nombreux mécanismes différents permettant de reconfigurer une application. Il n’est bien entendu pas possible de les citer tous ici. Nous verrons dans le chapitre suivant comment un certain nombre d’entre eux sont appliqués dans les solutions existantes pour la construction d’applications adaptatives. Dans cette section, nous tentons plutôt de dégager un certain nombre de critères qui nous permettront d’évaluer ces solutions du point de vue des mécanismes utilisés. En effet, bien que tous ces mécanismes puissent être utilisés dans le cadre d’une adaptation, la plupart n’ont rien de spécifique à cette utilisation et peuvent être utilisés pour d’autres besoins. Cependant, les contraintes spécifiques de l’adaptation les rendent plus ou moins appropriés. Garanties. Nous l’avons déj`a dit plus haut, il est important de trouver le bon équilibre entre la puissance des reconfigurations possibles et le maintient de la cohérence de l’application. Les opérations de reconfigurations utilisées pour l’adaptation doivent donc offrir des garanties quand à leurs effets sur le système. Cela implique d’une part que l’effet de chaque opération soit prévisible et d’autre part que leurs définitions se basent sur une description plus ou moins formelle de la structure et du comportement du système. Ces deux sous-critères sont essentiels pour pouvoir raisonner a priori sur les effets des différentes opérations sur le système, c’est-`a-dire sans avoir à les réaliser. On peut imaginer de nombreux types de garanties différentes, comme par exemple concernant les effets sur les performances de telle ou telle opération, mais la plus fondamentale, est la garantie du maintient de la cohérence du système adapté. Cette garantie stipule que quelles que soient les opérations appliquées au système, celui-ci continuera de fonctionner correctement. Il faut distinguer ici un système qui fonctionne correctement, c’est-`a-dire qui produit les bons résultats sans erreur, d’un système qui fonctionne bien, c’est-`a-dire qui, en plus d’être correct, utilise efficacement les ressources à sa disposition. Dans le cadre de l’adaptation, l’objectif est de faire en sorte qu’un système fonctionne au mieux, et donc le minimum que l’on doive garantir est qu’un système correct reste correct quelles que soient les adaptations qu’on lui applique. C’est ce que signifie le critère de maintient de la cohérence. Modularité. La modularité représente le fait de pouvoir appliquer des modifications à une partie du système sans affecter les autres. Ce critère est un critère général du génie logiciel, qui n’est pas spécifique à l’adaptation. Cependant, il est particulièrement important dans notre cas, car il permet d’adapter des systèmes complexes en raisonnant sur leur propriétés locales, et donc sans avoir à se préoccuper d’interactions non prévues avec l’extérieur. Cela signifie que si une adaptation est rendue nécessaire par une modification du contexte, par exemple une baisse de la qualité de connexion réseau, il est possible de n’adapter que les parties du système qui interagissent directement avec le réseau, en ayant un impact minimal (idéalement nul) sur le reste. Cela signifie aussi que l’on doit facilement adapter tous les éléments concernés. En effet, si dans l’exemple précédent du réseau on ne modifie que le côté client sans toucher au serveur, ceux-ci risquent de ne plus pouvoir communiquer. La possibilité d’effectuer des modifications de fa¸con modulaire ne dépend pas uniquement de la nature des mécanismes utilisés et de leur granularité, mais aussi de la structure de l’application. Si l’application est mal modularisée, ou modularisée d’une fa¸con incompatible avec une adaptation donnée, on retrouve ici le problème bien connu de la tyrannie de la décomposition dominante [Ossher and Tarr, 1999] qui ne peut être résolu que par des techniques de programmation par aspects. Performance. La performance des reconfigurations est cruciale. Les mécanismes utilisés pour l’adaptation dynamique doivent pouvoir d’être implémentés efficacement, aussi bien en terme de vitesse d’exécution que d’utilisation de ressources. En effet, ils ne doivent pas perturber le fonctionnement de l’application plus que nécessaire. Un mécanisme qui nécessiterait plusieurs secondes pour s’exécuter serait inutilisable dans la plupart des applications. Même si le système résultant de son utilisation était beaucoup plus performant que le système initial, son cout ˆ serait prohibitif. Au del`a des interférences avec l’exécution normale de l’application, une reconfiguration qui prend trop de temps risque de ne plus être valide une fois terminée si le contexte a évolué entre temps. Ouverture. Il est en général impossible aux programmeurs d’une application de prévoir toutes les circonstances dans lesquelles elle sera utilisée, et donc les adaptations qu’elle devra supporter. Bien que cela ne soit pas à proprement parler nécessaire pour pouvoir parler d’application adaptative, en pratique il est important pour une telle application de supporter des modifications non anticipées au moment du développement. Un système fermé, qui ne supporterait que des adaptations prévues serait forcément limité, et deviendrait rapidement beaucoup trop complexe à développer s’il devait s’adapter à des scénarios réalistes. Transparence. Enfin, notre dernier critère, lié au précédent, concerne la transparence des mécanismes du point de vue du programmeur initial de l’application. En effet, si l’on veut pouvoir adapter une application de fa¸con non anticipée, il faut éviter des mécanismes qui nécessitent que le programmeur de l’application « prépare » l’application pour ces modifications. Il est important que la création d’applications adaptatives ne se fasse pas au dépend de la complexité du développement initial, déj`a suffisamment difficile. Au contraire, notre objectif est plutôt de simplifier le travail des programmeurs en modularisant le code spécifique à l’adaptation dans un aspect, ce qui devrait rendre le code métier plus simple. 

Contexte explicite

Bien que le contexte soit pas définition extérieur au système, un système adaptatif doit être conscient de celui-ci afin de pouvoir réagir à ses évolutions. Un système ne peut pas être adaptatif s’il est « aveugle » à son contexte. L’étendue et la précision – aussi bien spatiale (niveau de détail et d’exactitude) que temporelle (temps de latence) – des connaissances que possède le système sur son contexte est déterminant pour la qualité des adaptations qu’il peut mettre en œuvre. Si le système ne possède que des informations partielles, inexactes, ou obsolètes, les adaptations qu’il pourra réaliser au mieux seront non optimales, et au pire auront un effet négatif sur les performances du système. Puisque l’adaptation d’un logiciel se fait par rapport à son contexte d’exécution et aux évolutions de celui-ci, il est primordial pour une application adaptative d’avoir conscience de ce contexte [Dey and Abowd, 2000]. Ce n’est pas le cas de la plupart des logiciels; au contraire, les environnements d’exécution modernes (machines virtuelles, middlewares) essayent plutôt de les isoler le plus possible des spécificités de leur environnement. Si cette approche a de nombreux avantages, comme une meilleure portabilité, elle empêche parfois les applications de tirer partie des particularités de leur contexte d’exécution. Le premier problème concerne l’identification du contexte du logiciel. La définition que nous utilisons (voir la section 5.1, page 71) indique que le contexte d’un logiciel regroupe tout ce qui influence la qualité de son fonctionnement, mais qui ne fait pas partie explicitement du logiciel. Ainsi, les caractéristiques matérielles de l’ordinateur hôte d’une application font partie de son contexte, mais pas les objets métiers qu’elle manipule directement. Dans ce document, nous ne nous intéressons pas à ce problème d’identification, mais seulement à la fa¸con dont le contexte, une fois identifié, intervient dans l’adaptation du logiciel. Un logiciel adaptatif doit donc contenir le code nécessaire pour le rendre sensible à son contexte. Les rôles de cette partie du logiciel sont : – découvrir des caractéristiques du contexte spécifique à une exécution du logiciel ; – détecter les changements significatifs qui se produisent dans le contexte d’exécution, et déclenchent éventuellement des adaptations du logiciel ; – offrir au reste du logiciel une interface lui permettant d’obtenir ces informations. Le chapitre 5 est spécifiquement consacré à cette problématique et à la solution que nous y proposons. Nous nous contenterons ici d’énumérer rapidement les critères les plus importants permettant d’évaluer cette partie d’un logiciel adaptatif : La précision des informations obtenues, aussi bien spatiale que temporelle. La précision spatiale, correspond au niveau de détails fournis, et doit être la plus élevée possible. La précision temporelle correspond au décalage dans le temps entre le moment ou` les informations sont re¸cues par le logiciel afin d’être exploitées, et l’instant (passé) auxquelles elles se sont produites. La richesse des informations correspond à l’étendue du contexte qui est effectivement observée par le système, et doit être la plus élevée possible. La généralité et la modularité du code implémentant l’observation du contexte dans le logiciel, doit elle aussi être maximisée, afin de pouvoir être réutilisée dans d’autres applications. En effet, certains éléments, comme les caractéristiques matérielles ou logicielles de la plate-forme d’exécution font partie du contexte de tous les logiciels. Les performances du code d’observation sont primordiales, afin d’éviter les interférences de cette partie du système adaptatif avec le fonctionnement normal du logiciel. 

Stratégie d’adaptation

La stratégie d’adaptation employée par le système est d’une certaine fa¸con chargée d’« incarner » la fonction d’adéquation sur le plan opérationnel. La fonction définit un objectif à atteindre, et la stratégie d’adaptation est chargée de réaliser cet objectif au mieux. La stratégie d’adaptation est l’élément le plus important d’un système adaptatif ; même si les opérations disponibles sont extrêmement puissantes et si le contexte est connu dans ses moindres détails, tout cela ne sert à rien si la stratégie n’est pas capable de tirer partie de ces informations. Dans notre cas particulier, la stratégie d’adaptation d’un logiciel adaptatif se présente sous la forme d’un ensemble d’algorithme et de données qui sont chargés, à partir des informations connues sur le contexte d’exécution, de décider quand et comment adapter le logiciel, en utilisant au mieux les mécanismes de reconfiguration disponibles. La stratégie est donc au cœur du logiciel adaptatif, puisqu’elle fait le lien entre les deux autres éléments analysés plus haut : mécanismes de reconfiguration et informations contextuelles. Voici les caractéristiques à notre sens les plus importantes d’une stratégie d’adaptation, qui nous serviront de critères d’évaluation. Notons que certains de ces critères sont des critères « classiques » du génie logiciel ; cependant, il sont tout particulièrement importants dans le cas d’une stratégie d’adaptation. Analysabilité. La mise en œuvre d’une stratégie d’adaptation va conduire à des modifications dans l’application adaptée. Ces modifications sont a priori con¸cues pour améliorer l’application, mais rien dans les mécanismes utilisés ne peut empêcher ces modifications de nuire à la qualité du logiciel (les seules garanties que ces mécanismes peuvent nous offrir est de conserver la consistance du système). Il est donc important que la stratégie d’un logiciel adaptatif puisse être analysée avant d’être exécutée afin de vérifier certaines propriétés (dépendant de l’application) et de garantir que la stratégie n’aura pas d’effets pervers, comme de rendre l’application inutilisable ou de générer des erreurs irrécupérables. Parmi les critères les plus importants concernant la qualité d’une stratégie d’adaptation, on trouve : La stabilité. Il peut arriver que le contexte d’exécution du logiciel évolue de fa¸con abrupte et totalement imprévisible. Une stratégie d’adaptation na¨ıve risquerait par des réactions trop précipitées ou disproportionnées de rendre le système instable. L’agilité. Le temps de réaction de la stratégie par rapport aux évolutions du contexte doit être le plus faible possible, non seulement afin de ne pas perturber le fonctionnement normal du logiciel, mais aussi car si la stratégie met trop de temps à se décider, le contexte peut avoir suffisamment évolué entre temps pour rendre sa décision caduque. Dynamicité. Tout comme pour les mécanismes de reconfigurations, il est important que la stratégie d’adaptation d’un logiciel soit ouverte, afin de pouvoir elle-même être adaptée et étendue de fa¸con non anticipée sans avoir à stopper, modifier, puis recompiler le logiciel. Généricité et réutilisabilité. De la même manière qu’elles partagent une partie de leur contexte (en particulier en ce qui concerne les caractéristiques matérielles des plates-formes hôtes), beaucoup d’applications utilisent des services non-fonctionnels de type middleware similaires, voire identiques. Les stratégies d’adaptation de ces couches logicielles sont relativement indépendantes de la fonction spécifique du logiciel et doivent donc pouvoir être réutilisées, au moins en partie, dans plusieurs applications adaptatives.