Nous pr´esentons dans un premier temps l’extension de Fractal qui permet d’associer dynamiquement une ou plusieurs politiques d’adaptation `a un composant Fractal, puis nous d´ecrivons la structure des politiques d’adaptation elles-mˆemes. Enfin, nous justifions en quoi safran peut ˆetre consid´er´e comme un syst`eme `a aspects, et ce qui le diff´erencie des autres syst`emes.
4.4.1
Un contrˆoleur Fractal pour g´erer l’adaptation
safranintroduit une extension au mod`ele Fractal qui permet d’associer (tisser) dynamiquement des politiques d’adaptation aux composants m´etiers d’une application. Cette extension est con¸cue pour ˆetre minimale et g´en´erique, et son interface ne d´epend donc pas de la forme exacte des politiques utilis´ees. Ainsi, bien que safran fournisse un langage d´edi´e pour la programmation de politiques d’adaptation,
d’autres approches sont possibles et peuvent utiliser l’interface d´ecrite ici (par exemple des politiques programm´ees de fa¸con ad hoc, ou bien des agents logiciels).
Comme toutes les extensions du mod`ele Fractal, celle-ci se traduit par la d´efinition d’une nouvelle interface de contrˆole, qui sera impl´ement´ee par les composants safran. C’est la pr´esence de cette interface qui en fait des composants adaptatifs : l`a o`u un composant Fractal standard fournit des interfaces de contrˆole pour permettre `a un acteur externe de le reconfigurer (et donc de l’adapter), un composant safran int`egre grˆace `a cette interface le code d’adaptation et devient ainsi adaptatif, i.e. acteur de sa propre adaptation.
Si elle est pr´esente, cette interface de contrˆole doit ˆetre identifi´ee sous le nom adaptation-controller et avoir la signature suivante :
interface AdaptationController {
void attachFcPolicy(any policy) throws InvalidPolicyException; void detachFcPolicf(any policy) throws NoSuchPolicyyException; any[] getFcPolicies();
}
Les m´ethodes de cette interface permettent d’inspecter et de manipuler dynamiquement l’ensemble des politiques d’adaptation qui s’appliquent au composant :
– attachFcPolicy() permet d’attacher une nouvelle politique au composant. Puisque notre extension est `a ce stade g´en´erique et doit pouvoir ˆetre utilis´ee avec diff´erents types de politiques, le type du param`etre est any. En pratique, une impl´ementation donn´ee de cette interface, comme par exemple safran, n’accepte qu’un type bien d´efini de politiques. Cette m´ethode l`eve une exception de type InvalidPolicyException si la politique ne peut pas ˆetre ajout´ee au composant. Cela peut se produire si l’impl´ementation de la politique ne correspond pas `a celle de l’interface, ou bien par exemple si la nouvelle politique est incompatible avec celles d´ej`a associ´ees au composant. S’il n’y a pas d’erreur, la nouvelle politique prend effet imm´ediatement et jusqu’`a ce qu’elle soit retir´ee. – detachFcPolicy() permet de d´etacher une politique du composant afin qu’elle ne s’y applique plus.
Une exception de type NoSuchPolicyException est lev´ee si la politique pass´ee en param`etre n’est pas associ´ee au composant.
– Enfin, getFcPolicies() permet de connaˆıtre l’ensemble des politiques actuellement associ´ees au composant. Cette sp´ecification abstraite de l’interface n’indique pas l’ordre dans lequel les politiques sont renvoy´ees, mais une impl´ementation particuli`ere peut sp´ecifier cet ordre s’il a un sens dans son cas.
Lorsqu’une politique est associ´ee `a un composant donn´e, elle est charg´ee d’adapter ce composant, et uniquement celui-ci. En effet, l’un des int´erˆets principaux de la conception par composants est d’isoler tr`es fortement les diff´erents ´el´ements d’une application, en ne les laissant interagir que par l’interm´ediaire d’interfaces bien d´efinies. L’ajout dans une application de politiques d’adaptation ne remet pas en cause cette conception, et une politique associ´ee `a un composant donn´e ne doit pas ˆetre capable de modifier les autres parties de l’application. Si cela ´etait le cas, il deviendrait impossible de raisonner localement sur les effets d’une politique sans connaˆıtre l’int´egralit´e de l’application. Nous introduisons donc une r`egle qui restreint la port´ee des politiques, quelle que soit son impl´ementation : une politique d’adaptation li´ee `a un composant c n’a le droit de modifier que ce composant-ci et ses sous-composants directs s’il s’agit d’un composite. Ainsi, l’ajout d’une politique `a un composant ne brise pas l’encapsulation. Cette r`egle peut sembler au premier abord tr`es restrictive, surtout en regard de ce que nous avons dit `a propos de l’aspect d’adaptation, qui est souvent transverse `a la d´ecomposition de l’application. Cependant, le support du partage de composants par le mod`ele Fractal associ´e `a la possibilit´e de cr´eer des composites `a l’ex´ecu- tion permet facilement de cr´eer des politiques d’adaptation qui agissent sur des composants autrement dispers´es dans le code, tout en respectant la restriction ci-dessus. Il suffit pour cela de regrouper tous les composants `a adapter dans un composite auquel sera associ´ee la politique10. Ce nouveau composite,
10
On retrouve un m´ecanisme similaire dans les politiques applicatives du syst`eme d´ecrit dans [David and Ledoux, 2002], qui permet de regrouper des objets selon certains crit`eres afin de les adapter de la mˆeme fa¸con.
qui ne sert qu’`a regrouper des composants, mat´erialise le fait que ces composants ont quelque chose en commun (un aspect) qui impose de les adapter de fa¸con synchronis´ee.
4.4.2
Structure de politiques d’adaptation
L’extension de Fractal pr´esent´ee ci-dessus d´ecrit de fa¸con abstraite la s´eparation et la composition de l’aspect d’adaptation sans expliquer comment ce dernier est sp´ecifi´e. L’impl´ementation concr`ete des politiques d’adaptation que fournit safran se pr´esente sous la forme d’un langage d´edi´e.
La nature de ces politiques safran (forme et s´emantique) d´ecoule de notre analyse du domaine de l’adaptation et plus particuli`erement du processus d’adaptation. En effet, jusqu’`a pr´esent, nous avons iden- tifi´e, analys´e (Sect. 1.2) et ´evalu´e (Chapitre 3) les diff´erents ´el´ements qui constituent un logiciel adaptatif s´epar´ement : (i) sensibilit´e au contexte, (ii) pr´esence de m´ecanismes de reconfiguration dynamique, et (iii) politiques d’adaptation. Cependant, cette vision statique n’est pas suffisante, car l’adaptation est avant tout un processus, qui modifie continuellement l’application pendant son ex´ecution pour qu’elle soit `
a tout moment la mieux adapt´ee aux circonstances pr´esentes.
D’une fa¸con g´en´erale, on peut d´ecomposer ce processus en trois ´etapes successives :
1. Observation de l’environnement (contexte d’ex´ecution) de l’application et/ou de l’application elle- mˆeme, et d´etection de l’occurence de certaines circonstances n´ecessitant une adaptation. Cette ´etape peut ˆetre impl´ement´ee grˆace `a la sensibilit´e au contexte d’une application adaptative.
2. Prise de d´ecision : ´etant donn´ees d’une part l’´etat actuel de l’application et d’autre part les nou- velles circonstances d´etect´ees dans la premi`ere phase, l’application doit d´ecider des op´erations de reconfiguration `a effectuer pour s’adapter aux nouvelles circonstances. Cette ´etape correspond `a la strat´egie d’adaptation de l’application.
3. Action : une fois que les op´erations de reconfiguration ont ´et´e d´etermin´ees, il reste `a les appliquer concr`etement `a l’application, tout en ´evitant de perturber son bon fonctionnement « normal ». Cette ´etape correspond aux m´ecanismes de reconfiguration dynamique de l’application adaptative. Une politique d’adaptation doit donc ˆetre r´eactive, d´etecter les ´ev´enements significatifs qui se pro- duisent dans le contexte, et en fonction de ces ´ev´enements et de l’´etat actuel du syst`eme, agir sur l’appli- cation en la reconfigurant pour l’adapter. Afin de r´epondre `a tous ces besoins, les politiques d’adaptation de safran sont structur´ees sous la forme d’ensembles de r`egles r´eactives de la forme
when <event> if <condition> do <action>
Ce type de r`egles est similaire `a ce que l’on peut trouver dans le domaine des bases de donn´ees actives [Dittrich et al., 1995; Collet, 1996] sous la d´enomination de r`egles eca : Event, Condition, Action. Une r`egle d’adaptation indique que lorsque un ´ev´enement correspondant `a l’expression <event> se produit, si l’expression <condition> concernant l’´etat du syst`eme est vraie, alors la reconfiguration <action> est ex´ecut´ee, modifiant ainsi le syst`eme afin de l’adapter `a la nouvelle situation r´esultant de l’occurence de l’´ev´enement.
La sp´ecification de l’´ev´enement correspond `a la fonctionnalit´e d’observation et de d´etection des chan- gements du contexte d’ex´ecution. La condition et l’action sp´ecifient comment r´ealiser l’adaptation. La r`egle dans son ensemble, qui relie un ´ev´enement `a une action (conditionnelle) correspond `a la prise de d´ecision.
Dans le syst`eme safran, les politiques d’adaptation associ´ees dynamiquement aux composants Fractal adaptatifs sont constitu´ees de s´equences (ordonn´ees) de r`egles d’adaptation ;
policy example() = {
rule { when <event1> if <cond1> do <action1> }; rule { when <event2> if <cond2> do <action2> }; rule { when <event3> if <cond3> do <action3> };
... }
Lorsqu’une telle politique est associ´ee `a un composant safran grˆace `a son interface adaptation- -controller, le contrˆoleur du composant se met `a l’´ecoute des ´ev´enements mentionn´es dans la politique. D`es qu’un de ces ´ev´enements se produit, la ou les r`egles correspondantes sont activ´ees, leurs conditions ´evalu´ees, et pour celle qui sont vraies, leurs actions ex´ecut´ees en s´equence.
4.4.3
SAFRAN en tant que syst`eme `a aspects
Le point de d´epart de notre approche est de consid´erer l’adaptation comme une aspect, c’est-`a-dire une pr´eoccupation transverse mais n´eanmoins modularis´ee grˆace `a des techniques de composition (tissage) appropri´ees (cf. Section 2.1). Un aspect est constitu´e d’un ensemble de couples (coupe, action), o`u une coupe est un ensemble de points de jonction. [Douence et al., 2002] ont montr´e que ces points de jonction pouvaient ˆetre vus comme de ´ev´enements relatifs `a l’ex´ecution du programme. Jusqu’`a aujourd’hui, presque tous les syst`emes `a aspects ont choisi de ne consid´erer que des ´ev´enements au niveau du langage de programmation : invocation de fonction ou de m´ethode, cr´eation d’objet, etc.11 Or, une application
n’est jamais totalement isol´ee : elle est affect´ee par le contexte dans lequel elle s’ex´ecute et avec lequel elle interagit (cf. Section 1.1).
safranse distingue des autres syst`emes `a aspects par l’extension du domaine des points de jonction `
a l’ensemble du contexte de l’application. Les ´ev´enements endog`enes (li´es `a l’ex´ecution du programme lui-mˆeme) d´etectables par safran correspondent ainsi aux points de jonction « traditionnels », alors que les ´ev´enements exog`enes (li´es au contexte d’ex´ecution) constituent un nouveau type de points de jonction qui permet de r´eagir aux ´evolutions du contexte, enrichissant par l`a mˆeme le pouvoir d’expression des aspects.
En ce qui concerne les actions (advices) d´eclench´ees par la d´etection d’un point de jonction, la plu- part des syst`emes `a aspects sont g´en´eriques et les aspects qu’ils permettent de programmer ne sont pas li´es `a un domaine sp´ecifique. En cons´equence, leurs actions sont en g´en´eral programm´ees avec le mˆeme langage que le programme de base (Java pour AspectJ par exemple), parfois l´eg`erement ´etendu (fonction sp´eciale proceed() en AspectJ). Dans notre cas particulier, le domaine est restreint aux adaptations par reconfiguration de l’architecture. Ainsi, le langage safran peut ˆetre consid´er´e aussi bien comme un dsl que comme un asl12, le domaine ou la classe d’aspects consid´er´e ´etant l’adaptation. safran fournit des
constructions sp´ecifiques pour exprimer les coupes (´ev´enements endog`enes et exog`enes) et un langage d´edi´e aux actions (FScript).
Une fois qu’un aspect a ´et´e programm´e, ici sous la forme d’une politique d’adaptation, il doit ˆetre int´egr´e, ou tiss´e dans l’application `a laquelle il est destin´e. Dans le cas de safran, les politiques sont tiss´ees et d´etiss´ees dynamiquement dans le contrˆoleur d’adaptation de leur composant cible (cf. figure 4.4). En effet, le contrˆoleur d’un composant Fractal est destin´e `a g´erer toutes les interactions entre ce composant et son environnement. Dans le cadre du mod`ele Fractal standard, cela signifie essentiellement g´erer les messages entrant et sortant, mais puisque safran ´etend justement cette notion d’environnement afin d’y inclure le contexte d’ex´ecution, il est normal que le code destin´e `a g´erer ces interactions, c’est-`a-dire les politiques d’adaptation, soient « tiss´ees » dans le contrˆoleur du composant. Notons tout de mˆeme que le verbe « tisser » n’implique pas, comme par exemple c’est le cas pour AspectJ, de transformation de code ; le contrˆoleur d’un composant Fractal, en particulier lorsqu’il est impl´ement´e avec Julia, offre d´ej`a les niveaux d’indirection n´ecessaires pour y int´egrer du code facilement.
Une fois qu’une politique (aspect) est int´egr´ee (tiss´ee) dans le contrˆoleur d’un composant, ce dernier devient adaptatif. L’ex´ecution du code correspondant est r´eactive : lorsque des ´ev´enements, qu’ils soient endog`enes ou exog`enes, sont re¸cus par le contrˆoleur d’adaptation, ce dernier d´etermine la r´eaction appro- pri´ee en fonction des diff´erentes r´egles pr´esentes `a cet instant, puis ex´ecute cette r´eaction afin d’adapter
11
Il existe aussi quelques travaux comme [Ostermann et al., 2005] qui essayent d’exprimer des coupes s´emantiques, plus abstraites et moins d´ependantes des m´ecanismes du langage sous-jacent.
12
Fig. 4.4 – Int´egration des politiques dans le contrˆoleur d’un composant adaptatif.
le composant aux nouvelles circonstances (cf. Section 7.4 pour les d´etails du mod`ele d’ex´ecution). Ce sch´ema d’ex´ecution est en accord avec la nature r´eactive du processus d’adaptation, dont il reprend les diff´erentes phases : observation, d´ecision, puis action.