Niveau Réflexe externe : Designer de Cascades d’AAs

Le designer de cascades d’AAs est lui-même implémenté à l’aide de WComp. Il utilise l’interface de contrôle d’un service composite pour ajouter ou retirer des composants ou liaisons dans l’assem- blage applicatif.

5.2.3.1 Architecture du Designer de Cascades d’AAs

Ce designer se compose de deux services composites (FIGURE 5.7). Le premier joue le rôle d’interface tandis que le second est le tisseur à proprement parler. Le premier conteneur contient un pointeur vers le dépôt des cascades. Il permet à un utilisateur ou à un mécanisme externe, via l’interface fonctionnelle du service composite, de sélectionner les cascades à appliquer. Une fois les cascades sélectionnées, une chaîne de traitement allant du pointcut matching à la fabrique de greffon est déployée pour chaque AA qui la compose. Chacun de ces processus, que nous avons détaillés en SECTION 4.3.2, est implémenté sous la forme d’un composant. Au déploiement, lorsqu’une politique de combinaison est associée à un AA, le composant mettant en place cette dernière sera déployé. Par défaut, la politique de calcul de toutes les combinaisons est appliquée. Pour instancier ces composants, le service composite d’interface contient un proxy vers l’interface de contrôle du service composite du tisseur. Nous pouvons voir dans la FIGURE 5.7 que seule une cascade a été sélectionnée. Cette cascade contient trois AAs, par conséquent trois chaînes (visibles à gauche du conteneur 2) sont créées.

Le service composite qui implémente le tisseur est donc dynamiquement modifié en fonction des cascades sélectionnées. Il a pour objectif d’adapter le service composite applicatif. Pour ce faire, il dis- pose d’un composant proxy vers l’interface de contrôle du service composite. En plus des composants de la chaîne allant du pointcut matching à la fabrique de greffon, le composant AdviceToUPnP gère la synchronisation entre le modèle de l’application et l’application s’exécutant. Inversement, le compo- sant FormatingEntryBean et le composant proxy vers le service applicatif gèrent la synchronisation entre l’application et son modèle. Ce composant est notifié via l’interface de contrôle du service appli- catif de toute modification compositionnelle intervenant dans le conteneur applicatif. De plus, il gère le modèle de l’application intermédiaire c’est-à-dire représentant le résultat de l’adaptation entre les différents cycles de tissages. Le composant dispatcher a pour objectif de gérer le bon ordonnancement des cycles de tissage et de transmettre le modèle de l’application sur lequel le cycle doit être réalisé (cf. SECTION4.4.3.2). Enfin les composant superposition et conflict manager réalisent les processus de superposition et de fusion.

5.2.3.2 Application au scénario

Nous exprimons les comportements déployés par le niveau tactique avec la décomposition classique des boucles d’auto-adaptation : perception, décision et action. Cette décomposition nous permet de gérer finement la portée des différents aspects composant les cascades et offre la capacité à un aspect de réutiliser des éléments instanciés par d’autres aspects. Nous utiliserons ce points pour

FIGURE5.6 – Le conteneur constituant l’interface du designer de cascades d’AAs.

les parties de décision et de perception, par exemple afin de pouvoir agréger et analyser en un point les données provenant de plusieurs capteurs (cf. SECTION4.2.3.4). D’autre part, cette décomposition nous permet de réduire le nombre de règles d’adaptation à écrire grâce à une forte réutilisation des aspects dans les cascades.

Nous allons étudier plus précisément ici, les cascades permettant de décrire les comportements pour la gestion des fenêtres qui sont les plus complexes. Les autres comportements sont présentés en ANNEXE ??. Ces deux cascades sont indépendantes et prennent la forme suivante : Cascade-

FenetreTemp={{moyenneTemp},{calcul_moyenneTemp},{gestion_fenetreTemp}} et CascadeFenetre- Pluie={{moyennePluie},{calcul_moyennePluie},{gestion_fenetrePluie,gestion_fenetrePluiePrioritaire}}. Les aspects sont donc répartis dans les différents cycles comme présenté en FIGURE5.9.

Dans ces cascades, les deux aspects pour le premier cycle de tissage (FIGURE 5.10 et FIGURE

5.11) sont simples et instancient des composants de type Moyenne et BooleanBuffer.

Les deux aspects de ces cascades, destinés au second cycle de tissage, consistent à relier les capteurs aux composants de moyenne qui leurs sont associés. La politique de combinaison qui leur est associée est de type n :n.

FIGURE5.7 – Le conteneur constituant le tisseur du designer de cascades d’AAs.

mécanisme de fusion et des opérateurs du langage. L’AA présenté en FIGURE 5.14 met en place le système d’ouverture des fenêtres en fonction de la moyenne des températures observées. Un composant seuil (threshold) est instancié afin de déterminer si la température est suffisante pour ouvrir la fenêtre. Le comportement décrit à la ligne 10 est alors le suivant : lors d’une variation de la température (événement provenant de moyenne), si le seuil est dépassé alors la demande d’ouverture est transmise au BooleanBuffer, sinon il s’agit d’une demande de fermeture. Le BooleanBuffer, lorsqu’il change d’état, déclenche alors sur les fenêtres l’ordre d’ouverture ou de fermeture en fonction de son état.

Les AAs destinés au troisième cycle de tissage, pour le comportement de gestion des fenêtres en fonction de la pluie, dans une approche semblable aux précédents, ils peuvent être écrits comme en FIGURE 5.15 et 5.16. Le premier (FIGURE 5.15) met en place le mécanisme suivant : si la

moyenne des capteurs d’humidité est supérieure à un certain seuil, alors dans un premier temps les fenêtres sont fermées (fenetre.Close) et un BooleanBuffer, qui servira aux autres mécanismes d’ouverture à identifier s’ils sont autorisés à ouvrir les fenêtre est placé à faux. Sinon il est placé à vrai. Le second AA (FIGURE 5.16) utilisera ce BooleanBuffer afin d’ajouter, à tous les mécanismes permettant de gérer l’état des fenêtres à l’aide de l’opérateur call, un contrat dont le comportement est le suivant : la gestion des fenêtres est autorisée si et seulement si il ne pleut pas.

FIGURE5.8 – Le tisseur de cascades d’AAs.

FIGURE5.9 – Répartitions des AAs dans les cycles de tissages

Lorsque les techniciens arriveront sur les lieux, ces deux comportements seront retirés. Dans le cas de fonctionnement habituel du système l’assemblage de composants déployé au niveau réflexe

Advice:

2 schema moyenneTemp () :

MoyenneTemp:BasicBean.Moyenne BBufferTemp:BasicBean.BooleanBuffer

FIGURE5.10 – Partie décision du comportement

de gestion des fenêtres en fonction de la tempé- rature.

Advice:

2 schema moyennePluie () :

MoyennePluie:BasicBean.Moyenne BBufferPluie:BasicBean.BooleanBuffer

FIGURE5.11 – Partie décision du comportement

de gestion des fenêtres en fonction de la pluie.

Pointcut:

2 temp:=/temperature∗.^Evented_NewValue/ moyenne:=/MoyenneTemp.∗/

5 Advice:

schema calcul_moyenneTemp (temp,moyenne) : temperature −> moyenne.SetValue

FIGURE 5.12 – Partie perception du comporte- ment de gestion des fenêtres en fonction de la température.

Pointcut:

2 pluie:=/humidite∗.^Evented_NewValue/ moyenne:=/MoyennePluie.∗/

5 Advice:

schema calcul_moyennePluie (pluie,moyenne) : pluie −> moyenne.SetValue

FIGURE 5.13 – Partie perception du comporte- ment de gestion des fenêtres en fonction de la pluie. Pointcut: 2 fenetre:=/fenetre[[:digit:]].∗/ moyenne:=/MoyenneTemperature.^AverageEvent/ BBufferTemp:=/BBufferTemp.∗/ 5 Advice:

schema gestion_fenetreTemp (fenetre,moyenne,BBufferTemp) : threshold: BasicBeans.Threshold(threshold=10) 8 moyenne −> if(threshold.IsReached){BBufferTemp.SetTrue} else{BBufferTemp.setFalse} 11 moyenne −> threshold.SetValue BBufferTemp.^StateChange −> fenetre.SetState

FIGURE5.14 – Partie action du comportement de gestion des fenêtres en fonction de la température.

interne prendra la forme présentée en FIGURE5.5.

Le designer de Cascade nous permet de répondre à une partie des challenges proposés par notre scénario : extensibilité de l’ensemble des adaptations à l’exécution ; les dynamiques sont séparées entre l’application et le mécanisme d’adaptation ; l’ensemble des adaptations variables et la prise en compte de la variabilité de l’infrastructure ; l’ensemble des adaptations et la manière dont elles sont composées est non-anticipée. D’autre part, les temps de réponse offerts par ce mécanisme d’adaptation sont adaptés, dans le cadre de notre scénario, le temps de calcul des adaptations est de l’ordre de 200ms. La gestion des comportements et donc des cascades d’AAs à déployer revient au niveau tactique. Ce dernier, à travers l’interface fonctionnelle du service composite d’interface du designer de peut sélectionner et déployer de nouveaux comportements.

Pointcut:

fenetre:=/fenetre[[:digit:]].∗/

3 moyenne:=/MoyennePluie.^AverageEvent/ BBufferPluie:=/BBufferPluie.∗/

Advice:

6 schema gestion_fenetrePluie (fenetre,moyenne,BBufferPluie) : threshold: BasicBeans.Threshold(threshold=10)

9 moyenne −> if(threshold.IsReached)

{fenetre.Close ; BBufferPluie.SetTrue} else {BBufferPluie.setFalse} moyenne −> threshold.SetValue

FIGURE5.15 – Partie action du comportement de gestion des fenêtres en fonction de la pluie.

1 Pointcut:

fenetre:=/fenetre[[:digit:]].∗/ BBufferPluie:=/BBufferPluie.∗/ 4 Advice:

schema gestion_fenetrePluiePrioritaire (BBufferPluie,fenetre) : fenetre.SetState −> (if (BBufferPluie.GetState) call)

FIGURE 5.16 – Partie action prioritaire du comportement de gestion des fenêtres en fonction de la pluie.