L’adaptation comme une préoccupation transverse

David et al avec SAFRAN [71] ont montré que la logique d’adaptation pouvait être séparée de la logique applicative. La logique d’adaptation est une préoccupation particulière du système et peut avoir des effets sur plusieurs autres préoccupations. Il s’agit donc bien d’une préoccupation transverse. Cette logique d’adaptation englobe elle même un ensemble de préoccupations d’adap- tation liées à des besoins divers. Nous avons également vu que dans les approches transparentes, les mécanismes d’adaptation sont sortis des applications puisque suffisamment génériques. Les entités d’adaptation doivent donc être externes aux applications et gérées comme des préoccupations transverses. En raison de la complexité de ces systèmes et de la multiplicité des dispositifs proposant des fonctionnalités parfois équivalentes, une même adaptation peut être dupliquée en plusieurs endroits de l’application. Il faut donc augmenter la réutilisabilité et la modularité de ces adaptations de manière à ne pas devoir écrire explicitement toutes les configurations du système ou encore d’écrire de manière ad-hoc chaque adaptation permettant d’atteindre ces configurations.

Dans le cadre de l’informatique ambiante, Zambrano et al dans [26] expliquent comment l’AOP peut être utilisée pour la création d’applications ubiquitaires. Puisque l’AOP permet d’offrir un bonne modularisation et séparation des préoccupations transverses, elle permettrait, dans le cadre de

l’informatique ambiante, d’isoler des préoccupations variables de l’application. C’est-à-dire qu’une application en informatique ambiante à une base et celle-ci peut être agrémentée ou adaptée par des aspects. Ils permettent alors d’isoler, réutiliser ou encore échanger ces préoccupations en fonction de l’environnement de l’application. La préoccupation de prise en compte du contexte peut alors être séparée du reste de l’application. Comparée à la programmation orientée objet ou composant, il n’y a plus de dépendance entre prise en compte du contexte et logique métier.

De plus l’informatique ambiante met en jeu des systèmes dont les designers doivent considérer les caractéristiques suivantes : mobilité, variabilité des ressources et de leur accessibilité. Tous ces critères, lorsque pris en compte, impactent la manière dont l’application va être mise en place. Ces variabilités ont pour conséquence, dans une approche classique de conception, de forcer la réécriture de même préoccupations pour chaque variante. L’AOP permet de réduire la réécriture de ces préoccu- pations grâce à l’abstraction offerte par les points de coupe. Les avantages des aspects identifiés sont les suivants :

• la partie adaptation est transparente pour l’application de base,

• les préoccupations en relation avec l’ubiquité du système peuvent évoluer indépendemment les unes des autres,

• la représentation du contexte est conservée coté client,

• cela permet une réutilisabilité des représentations et des stratégies d’adaptation.

La mise en œuvre de la séparation des préoccupations est alors un premier moyen de gérer la variabilité des systèmes ambiants. A l’inverse les inconvénients sont les suivants :

• comment garantir que le comportements de divers aspects ne sont pas conflictuels ? • le choix des aspects peut introduire des interférences entre applications de base et aspects. Nous rajoutons à ces inconvénients le suivant :

• les aspects peuvent interférer entre eux.

De nombreuses plateformes proposent d’utiliser des aspects comme moyen de mettre en œuvre des adaptations dynamiques et décrivent les adaptations dans des entités réutilisables et séparées de l’application. Le tableau 2.1 présente quelques unes de ces plateformes. Nous allons maintenant détailler trois d’entre elles.

SAFRAN [71] est une extension de Fractal ayant pour objectif de faciliter la conception de systèmes adaptatifs. Pour ce faire, ils utilisent des aspects d’adaptation. Ils peuvent être ajoutés/retirés à l’exécution. Le modèle de point de jonction de SAFRAN ne se limite pas au flot d’exécution de l’application. Les adaptations peuvent être déclenchées par des événements relatifs au contexte de l’application. Les événements exogènes sont relatifs aux informations externes à l’application tandis que les événements endogènes sont relatifs aux informations internes à l’application. L’architecture de SAFRAN comprend deux parties : (1) un langage d’adaptation appelé FScript pour reconfigurer des assemblages de composants Fractal garantissant les propriétés ACID [72] ; et (2) une boîte à outils pour l’observation du contexte appelée WildCAT [70]. Enfin, un contrôleur est intégré à la membrane afin de lier, à l’aide de règles de type ECA (event-condition-action), ces deux parties et gère les dépendances entre adaptations de manière explicite.

La « plugin architecture » proposée dans [6] se base sur AO4BPEL [7] qui est un langage orienté aspects de workflow. AO4BPEL permet l’adaptation dynamique d’orchestration de services. Les approches d’orchestration classiques ont les limitations suivantes [156] : (a) manque de moyens pour

FIGURE2.12 – Contrôleur d’adaptation dans la membrane d’un composant Fractal [68].

la représentation de préoccupations transverses et (b) pas d’adaptation dynamique de la composition de service. AO4BPEL propose alors un langage plus flexible pour la composition des Web services. Dans ces travaux, la problématique de gestion des interférences entre aspects n’est pas gérée. La gestion se fait de manière classique à l’aide des opérateurs before, after.... Puisque ces travaux s’appliquent aux workflows, ils ne prennent pas en compte l’évolution de l’infrastructure logicielle du système. Dans l’architecture, nous pouvons identifier deux types d’aspects : (1) les monitoring aspectsqui sont capables d’activer ou désactiver des (2) adaptation aspects à l’exécution. Les aspects peuvent être ajoutés ou retirés ou parfois générés à l’exécution.

AspectOpenCOM [11] est une extension du modèle à composant OpenCOM [66]. Elle ajoute deux fonctionnalités au modèle. La première est la possibilité de réaliser des compositions par aspects. La seconde est la définition d’un « aspect-MOP » qui permet l’introspection des aspects et leur adaptation. Il est alors possible d’observer et de modifier la logique de composition de ces aspects et les comportements qu’ils décrivent. Ce mécanisme offre, par exemple, la possibilité de réordonner les greffons lorsqu’ils sont en interaction. Les aspects prennent la forme de composants. La mise en place de ces aspects consiste en l’interception des invocations sur les ports fournis/requis de composants, et en la réalisation de traitements avant ou après.

Nous voyons dans le TABLEAU 2.1 que la plupart des approches sur les composants permettent d’utiliser des aspects sans violer la propriété de boîte noire des composants de l’application. D’autre part, dans ces approches, la gestion des interférences entres aspects est laissée à la charge d’un développeur ou d’un mécanisme externe.

TABLE2.1 – Caractéristiques des plateformes d’adaptations à base d’aspects. Plateforme Paradigme associé Forme du greffon invasive/non- invasive Gestion des interférences

FAC [101] Composants Un aspect est

un composant non-invasive A la charge du développeur PRISMA [20] Composants Un compo-

sant est décrit

comme une agrégation d’aspects in- terchangeables dynamique- ment invasive et non-invasive A la charge du développeur AO4BPEL [7] Services Activité spéci-

fié en BPEL non-invasive

A la charge du développeur

Aspect- OpenCOM [11]

Composants Un aspect est

un composant non-invasive L’aspect-MOP permet de modifier la logique de composition des aspects SAFRAN

[71] Composants Script Fscript non-invasive

A la charge du développeur Munnelly

[18] Objets code invasive

A la charge du développeur ' & $ %

La séparation des préoccupations transverses permet d’augmenter la réutilisabilité ainsi que la modularité des adaptations et permet de les composer. Il s’agit d’un pre- mier moyen de gérer la variabilité de l’infrastructure et du système associé. Il n’est plus nécessaire de spécifier de manière ad-hoc toutes les configurations que nous souhaitons atteignables par le système. En effet, il est possible de composer dyna- miquement des entités réutilisables pour des fonctionnalités clairement identifiées. Comme nous l’avons déjà évoqué, leur combinatoire est trop grande (voir non-bornée) pour que cela puisse être envisagé. Les deux grandes approches que nous avons pré- senté pour réaliser cette séparation des préoccupations ne sont pas incompatibles, au contraire elles peuvent être combinées et permettre ainsi la gestion des préoccu- pations transverses hétérogènes (FOP) comme des préoccupations transverses homo- gènes (AOP). Entre autre, l’AOP peut permettre une bonne mise en œuvre de la FOP. Dans le cadre de l’informatique ambiante, la gestion des préoccupations transverses hétérogènes peut autoriser l’adaptation et la prise en compte des dispositifs hétéro- gènes ou encore permettre la gestion de variantes d’adaptations pour une même fonc- tionnalité. D’un autre coté, la gestion des préoccupations transverses homogènes peut favoriser la gestion de la multiplicité des dispositifs composant l’infrastructure du sys- tème et permettre de dupliquer une adaptation en plusieurs endroits dans le système.

Comme nous l’avons vu, quelque soit l’approche utilisée, des interférences entre entités d’adap- tations peuvent intervenir et les approches classiques pour gérer ces interférences reposent sur la définition explicite des dépendances entre entités d’adaptation, par exemple avec les notions de pré- cédence ou de contrats. Ce type d’approche limite les capacités du mécanisme d’adaptation à prendre en compte l’imprévisibilité de l’environnement, de l’infrastructure et de l’ensemble des adaptations à mettre en œuvre. En raison de la grande combinatoire des adaptations à considérer, il peut vite deve- nir difficile de spécifier toutes ces dépendances comme d’en ajouter de nouvelles, limitant ainsi leur extensibilité. De plus, toutes ces dépendances ne peuvent être connues a priori. Quelque soit la tech- nique utilisée pour réaliser cette séparation des préoccupations transverses, elle nécessite la mise en place d’un mécanisme, que nous appellerons de décision, définissant, parmi les adaptations déployées, quelles sont celles qui doivent être appliquées et de quelle manière les composer. Un tel mécanisme a nécessairement des répercussions sur les temps de réponse de l’adaptation.