Des models@runtime pour minimiser les modifications dans l’application

Maintenant que nous avons étudié de quelle manière sont calculées les adaptations qui doivent être portées sur l’application, nous allons détailler de quelle manière elles y sont reportées. Comme nous l’avons mis en avant dans l’état de l’art (SECTION 2.3), afin de limiter le nombre de modifications réalisées dans l’application, nous utilisons des modèles de l’application à l’exécution sur lesquels sont effectuées l’ensemble des modifications durant les différents cycles de tissage avant d’être reportées dans l’application s’exécutant comme un ensemble d’instructions élémentaires de modification de l’assemblage. Pour cela, nous présenterons dans un premier temps notre méta-modèle d’assemblage de composants dont une instance est utilisée à l’exécution pour représenter l’application s’exécutant. Ce méta-modèle n’a pas pour objectif d’être appliqué à l’ensemble des plateformes d’exécution à base de composants. Il ne s’agit ni de l’union des méta-modèles des plateformes existantes ni d’un méta- modèle contenant l’ensemble des entités nécessaire et suffisant pour exprimer tout type d’assemblage de composants. D’autres travaux se sont interessés à cette problématique, comme par exemple, le méta-modèle d’architecture proposé dans [96] qui résulte d’une analyse de modèles comme UML, SCA et de plateformes comme OSGi, Fractal, OpenCom... ou encore dans le domaine des ADL (Ar- chitecture Description Language) [137] comme le montre l’étude suivante [149]. Nous verrons ensuite l’ensemble des transformations que le processus de tissage met en jeu pour identifier parmi celles-ci les processus de synchronisation que nous détaillerons plus particulièrement.

4.4.3.1 Méta-modèle d’application

Notre modèle d’assemblage de composants prend la forme d’un graphe conforme au méta-modèle décrit en FIGURE4.37. Un nœud du graphe est un port de l’assemblage de composant qui peut avoir des paramètres. Nous noterons la présence de deux types de nœuds : les nœuds boite noire et les nœuds boite blanche dont la sémantique est connue. Ce sont les noeuds qui nous permettront de gérer la fusion de plusieurs modèles. Les arcs de ces graphes sont les liaisons entre ports d’entrée et ports de sortie. Aux ports et liaisons peuvent être associés des méta-données. Ces méta-données peuvent être par exemple le fait qu’une liaison est optional ou mandatory. Un assemblage peut être formalisé comme dans l’EQUATION 4.20. Un assemblage contient un ensemble de ports J point, qui sont les points de jonction de nos aspects, et un ensemble de liaisons L. A chaque port sont associés deux indices : (1) le premier indique le composant auquel appartient le port et (2) le second identifie le port parmi ceux du composant. Les indices des liaisons permettent d’identifier les ports qu’elles relient.

Ass= (JPoint, L) | JPoint = {port00, ..., portnz} et L = { /0, l00,01, ..., ln−1z,nz} (4.20)

Afin de pouvoir instancier un tel modèle, il est donc nécessaire de mettre en œuvre un mécanisme synchronisant la représentation réelle d’un assemblage de composants d’une plateforme à composants et sa représentation abstraite. Ceci est réalisée à l’aide de deux transformations verticales [126], du modèle de l’application s’exécutant conforme au méta-modèle de la plateforme à composants cible vers un modèle conforme à notre méta-modèle d’assemblage de composants et vice versa. Cette transformation doit être automatique [126] et réalisée à l’exécution. Le mécanisme de transformation entre les modèles est propre à chaque plateforme, des correspondances doivent être établies entre les entités de chaque modèle. La table de correspondance 4.4 donne un exemple relatif à la plateforme LCA [87]. Cette synchronisation doit être réalisée à chaque fois qu’une modification intervient dans l’assemblage à adapter et lorsque le calcul de l’adaptation a été réalisé. Le tisseur prend donc en

FIGURE4.37 – Méta-modèle d’assemblage de composants.

entrée et produit des instances de ce méta-modèle.

TABLE4.4 – Correspondance Assemblage de composants =⇒ LCA

Assemblage de LCA composants InputPort Input/Method OutputPort Output/event Node Port Binding Link WhiteBoxNode Prédéfini

BlackBoxNode Tous les autres

Parameter Parameter

MetaData Port.property

Les sections points de coupe de l’ensemble des instances de ce méta-modèle sont données en entrée au processus de pointcut matching du tisseur. Leurs sections greffon sont les entrées du proces- sus d’advice factory. Ce processus prend en entrée des modèles de greffon, un modèle d’application et produit un ensemble de modèles d’application. Les greffons peuvent être vu comme des méta-modèles d’assemblage de composants comme nous pouvons le voir dans le tableau 4.5.

TABLE4.5 – Correspondance Assemblage de composants =⇒ greffon d’AA

Assemblage de Greffon d’AA

composants

InputPort InputPort

OutputPort OutputPort

Node PoincutVariable, local Entity, operator Binding RewriteInteractionRule, AddInteractionRule

WhiteBoxNode Operator

BlackBoxNode PoincutVariable, local Entity

Parameter PointcutVariable.parameter

MetaData PointcutVariable.property

4.4.3.2 Processus de tissage, transformation et composition

Un cycle de tissage repose donc sur trois transformations : (1) les entrées sont obtenues grâce au mécanisme de synchronisation et une transformation application s’exécutant −→ modèle abstrait de l’application; (2) le traitement consiste en une transformation horizontale de modèle endogène model-to-model [126] réalisée à l’exécution ; (3) la production de sorties consiste en une transfor- mation verticale du mécanisme de synchronisation modèle abstrait de l’application −→ application s’exécutant.

Ainsi la première phase d’un cycle de tissage fait partie du mécanisme de synchronisation ap- plication s’exécutant←→ modèle abstrait de l’application. Dans cette phase, à chaque modification de l’assemblage s’exécutant, son modèle abstrait est mis à jour. Il s’agit d’une approche de synchro- nisation en mode push [96]. Le modèle peut alors être mis-à-jour de manière incrémentale, ce qui permet de faire évoluer en parallèle le modèle abstrait et l’application s’exécutant et évite d’intros- pecter l’ensemble de l’application s’exécutant pour identifier tous les changements (cf. 2.3.2.2). La seconde phase est une transformation horizontale de modèle endogène model-to-model [126] réalisée à l’exécution. Il s’agit d’une transformation automatique [126] d’un modèle assemblage de compo- sants vers un modèle assemblage de composants. Cette transformation est paramétrée par les Aspects d’Assemblages. Sans paramètre ou si aucun AA n’est applicable alors la transformation n’introduit aucune modification de l’assemblage initial. Il s’agit donc d’une approche par transformation décla- rative [126]. Enfin, lors de la troisième phase, lorsque le modèle abstrait est modifié, l’assemblage s’exécutant est mis à jour. Afin de ne modifier dans l’application que les parties qui ont changé, le modèle de l’application est comparé au modèle de l’application adaptée. Les mises à jour, afin de garantir la consistance de l’application et la mise œuvre de l’ensemble des reconfigurations, réalisent les règles de modification de l’architecture dans cet ordre :

1. retraits de liaisons ; 2. retraits de composants ; 3. ajouts de composants ; 4. ajouts de liaisons ;

5. modifications des propriétés.

La gestion du cycle de vie des composants est laissée à la charge soit de la projection spécifique vers une plateforme soit à la charge de la plateforme comme dans LCA. Puisqu’un cycle de tissage est

toujours réalisé sur l’assemblage initial tel que précédemment défini, les entités de la représentation abstraite de l’assemblage de composants sont identifiées comme étant ou non le résultat de l’adap- tation. Pour cela, il convient de vérifier si les entités appartiennent à l’espace de nommage de l’AA et non pas à l’espace de nommage global auquel appartiennent les entités de l’assemblage initial. L’ensemble de ces processus est décrit en FIGURE4.38.

FIGURE4.38 – Un cycle de tissage est une transformation endogène model-to-model.

Plus précisément, le processus de transformation model-to-model précédemment décrit se compose de deux transformations comme nous pouvons le voir en FIGURE4.39. La première étape est une transformation endogène paramétrée par les AAs. Elle a pour but de transformer l’assemblage initial en plusieurs assemblages qui sont les instances de greffons. Cette transformation est réalisée dans une approche déclarative. La seconde étape est la composition endogène de ces instances de greffon afin de produire un unique assemblage de composants. Cette composition est dépendante des règles de fusion et des opérateurs de composition du moteur de composition. Il s’agit d’une transformation dans une approche opérationnelle [126]. Le moteur de composition travaille au niveau instances de greffon et non pas au niveau AA. En effet, au niveau type, toutes les interactions ne peuvent être identifiées puisque certaines sont dues aux duplications des AAs. A l’inverse, les règles données en paramètre au moteur de composition sont génériques et travaillent sur les types. Dans ces processus tous les assemblages produits sont conformes à notre méta-modèle d’assemblage de composants. Les deux transformations ont pour objectif de garantir la correction de l’application résultante des transformations. L’approche nous permet de définir à l’aide d’aspects des variantes d’architecture d’un système et de tisser les instances de ces variantes dans le modèle architectural [132].

Lors d’un tissage multi-cycles d’une cascade les transformations que nous venons de voir sont donc enchaînées les unes à la suite des autres comme cela est présenté en FIGURE 4.40. Dans ce cas, la synchronisation entre l’application modifiée et l’application s’exécutant ne se fait qu’une fois

FIGURE4.39 – Détail des transformations de modèles.

l’ensemble des transformations réalisées. Nous pouvons ainsi observer clairement qu’une adaptation est réalisée à l’aide de plusieurs processus de tissage. Pour cela, lors des trois phases du cycle de tissage, trois modèles d’assemblage sont finalement utilisés :

1. l’assemblage initial ; 2. l’assemblage courant ;

3. l’assemblage résultant de l’adaptation.

Le processus de synchronisation utilisant ces trois modèles peut donc être détaillé comme suit en cinq grandes étapes :

1. Mettre à jour l’application initiale. Pour cela, il faut filtrer les éléments de l’assemblage courant de ceux dus à une adaptation.

2. Mettre à jour l’image de l’application courante afin qu’elle soit à la disposition du mécanisme de synchronisation modèle de l’application −→ application s’exécutant.

3. Si premier cycle de tissage alors transmettre l’application initiale aux chaînes de traitement des AAs du premier cycle. Pour les cycles suivants, transmettre le modèle résultat provenant de l’adaptation précédente. Le cycle en cours est déterminé par un compteur.

4. Après composition, mettre à jour le modèle représentant le résultat de l’application et déclen- cher le cycle suivant.

5. Une fois tous les cycles réalisés, faire une comparaison entre les modèles résultat et de l’appli- cation courante pour projeter dans l’application s’exécutant les différences.

Les cascades d’AAs respectent donc l’ensemble des contraintes que nous nous étions fixés en SECTION4.1. L’ensemble de ces contraintes a pour conséquence de complexifier les processus mis en œuvre par le mécanisme d’adaptation et nécessairement sur les temps de réponse offerts. Nous allons maintenant étudier les temps de réponse des différents mécanismes que nous avons étudiés dans la présentation détaillée de notre tisseur.

FIGURE4.40 – Transformations mises en œuvre lors d’une adaptation à l’aide de cascades.