La résolution de conflits est associée à la composition d’assemblages de composants. Elle permet de gérer les cas précédemment énoncés où la superposition des assemblages de composants s’appuie sur les mêmes points de jonction. Il existe alors un conflit d’utilisation de ces composants logiciels. C’est à partir des composants spécifiques ‘⊕’ que le mécanisme de résolution de conflit va construire sa solution. Le résultat de la résolution de conflits est un assemblage de composants.
Reprenons l’assemblage C de l’exemple précédent contenant deux composants ‘⊕’. Nous propo-sons de résoudre ces conflits en produisant une solution en terme d’assemblage aux points identifiés selon un ensemble de règles logiques pré-définies. Nous énonçons pour cet exemple deux exemples de règles logiques de manière intuitive :
1. tout port en conflit avec le point d’entrée de f détient la priorité d’exécution et le flot de contrôle doit être retardé avant d’arriver à f
2. tout port en conflit avec l’événement de g doit être synchronisé et l’on doit effectuer une sommation de leurs paramètres avant toute diffusion
La résolution de conflits produit à partir de ces règles un assemblage final noté D ayant certains conflits résolus. Dans cet exemple, un composant de séquence (seq) a été ajouté à l’événement de a suivi d’un composant retardant le flot d’événement (delay) avant d’atteindre f. De la même manière, on retrouve un composant de synchronisation et de mémorisation des paramètres (Buffer) après l’événement de g suivi d’un composant de sommation (sum).
Dans cette partie, nous nous intéressons aux conflits entre les préoccupations transverses [146]. Nous analysons graduellement les approches pour la résolution de ces conflits vers les approches les plus intrusives. Enfin, nous proposons notre approche qui s’appuie sur la notion de fusion [30].
5.4.1 Les conflits entre les aspects dans la littérature
Il y a plusieurs catégories de conflit entre les aspects [199] : – Spécifications
– Entre aspects
– Entre le programme de base et l’aspect – Entre les préoccupations
Ainsi, lorsqu’un conflit se passe au niveau des spécifications, il peut être soit accidentel au niveau des points de jonction soit au niveau de la récursivité. Entre les aspects, cela concerne l’exécution conditionnelle, l’exclusion mutuelle, l’ordonnancement statique ou dynamique. Entre les préoccu-pations, cela signifie qu’il y eu changement des fonctionnalités, des comportements inconsistants ou des anomalies de composition.
Un premier niveau de gestion de la superposition est la description d’un aspect d’assemblage par un composant blackbox [136, 189, 190]. Dans ce cas, on gère les conflits en spécifiant localement les aspects qui sont prioritaires. On parle de précédence d’un aspect sur un autre. Cette gestion est réalisée de manière externe au tissage en identifiant les composants blackbox prioritaires. Voici un exemple de gestionnaire de précédence entre les ports de composants :
blackbox1.Input + blackbox2.Input = ( blackbox1.Input ; blackbox2.Input ) blackbox1.Input + A = ( blackbox1.Input ; A )
blackbox1.Input + A = ( blackbox2.Input in A) and ( blackbox1.Input ; blackbox2.Input )
Ce programme est ensuite traduit en règles logiques et est utilisé par le tisseur. Par exemple, Aspec-tualACME [200] propose deux opérateurs : précédence (priorité) et XOR. Hyper/J [201] propose une gestion par programmation de la résolution. Mais ces approches demandent soit l’apprentissage d’un nouveau langage dédié soit de choisir de manière ad hoc entre plusieurs adaptations.
5.4.2 Gestion des conflits d’aspects d’assemblage
Pour éviter de traiter les conflits de manière ad hoc, nous proposons une approche qui permet de composer les greffons en les considérant comme des whitebox. Des opérateurs spécifiques dont on connaît la sémantique de composition sont mis en œuvre. Cela permet de composer automatique-ment les greffons.
5.4.2.1 Notre motivation
L’état de l’application à un instant donné ne doit pas dépendre de l’ordre d’application des AAs. C’est le but que nous nous sommes fixés pour favoriser une approche où l’on ne fixe pas à priori de priorité entre les adaptations, une approche où une partie des décisions peut être prise par le système tel que des choix de coordination purement logiques par exemple.
Pour ce faire, nous cherchons à mettre en œuvre la propriété de symétrie dans l’opération de composition des aspects d’assemblage. Cette propriété peut être décomposées en trois sous-propriétés qui sont l’associativité, la commutativité et l’idempotence. Nous proposons donc une approche qui permet de composer symétriquement des assemblages de composants. L’avantage pour notre approche est de promouvoir une approche déclarative à l’utilisateur final (cf. page 5.3) des aspects d’assemblage pour une adaptation dirigée par l’utilisateur ou par l’environnement.
5.4.2.2 Fusion ISL
Les opérations de fusion des greffons sont régies par un ensemble de règles logiques. Ces règles sont regroupées dans la matrice que nous retrouvons dans la figure 5.16. Les propriétés de cette fusion sont la commutativité, l’associativité et l’idempotence (cf. Annexe).
Nous avons construit, à partir du modèle de Berger [30], un nouveau modèle de fusion d’interac-tions qui s’applique à notre modèle de composant. Comme un aspect classique peut être représenté dans le modèle de composant, un comportement peut également être représenté dans notre modèle. Un comportement est un arbre composé d’un sommet qui sont les entêtes des règles de réécriture. Ces entêtes caractérisent les méthodes à rediriger dans [30]. Chaque opérateur de Berger est modélisé par un composant dont la sémantique opérationnelle est la même.
Nous nous sommes inspirés de ce langage afin de construire un moteur de fusion qui s’appuie sur la fusion de programmes écrits sous la forme d’assemblages de composants. Chaque composant logiciel réalise dans l’assemblage un ensemble d’instructions. Le moteur de fusion d’ISL est un moteur de composition permettant de composer plusieurs schémas d’interaction indépendamment de leur ordre de fusion.
De part la capacité réduite des calculateurs envisagés, nous avons réduit le nombre d’opérateurs que nous utilisons pour la fusion au strict minimum (séquence, indéterminisme, conditionnel, call, message et délégation). Les règles de fusion sont également différentes et des propriétés supplémen-taires sont en jeu (comme l’idempotence). La fusion est associative, commutative et idempotente et permet de gérer les cas pratiques de superposition de descriptions de scénarios applicatifs dans le cas d’un système informatique ambiant. Cette fusion est décrite dans ce chapitre.
Nous avons vu que les aspects d’assemblage décrivent des adaptations indépendantes. Ces adaptations sont exprimées en juxtaposant les schémas d’assemblage. Nous voyons dans cette section une fonction qui permet de fusionner plusieurs schémas d’assemblage dans le but de construire un unique schéma d’assemblage. Le schéma d’assemblage ré-sultant peut être ambigu.
Notion de pivot. Nous ajoutons aux spécifications la notion de pivot qui permet de contrôler la manière dont la fusion s’opère. Le pivot sert à guider la fusion afin qu’elle se fasse en des points précis des espaces.
Conflits non résolus. Lorsque plusieurs AAs utilisent les mêmes points de jonction, le mécanisme de composition détecte ces conflits et ajoute au niveau de ces points de jonction provoquant le conflit, un composant spécifique mémorisant ainsi l’endroit où se situe le conflit.
Nous allons, dans un premier temps, construire cette fonction de fusion. La fonction de fusion bi-naire est notée ⊗ et prend deux espaces d’interaction en entrée pour fournir un espace d’interaction. Nous désirons pour notre cas d’étude construire ⊗ de sorte qu’elle soit idempotente, commutative et associative. Nous démontrerons ensuite qu’elle satisfait bien ces trois propriétés. Nous avons regroupé les différents axiomes définissant la fonction ⊗. Nous notons que ⊗ se définit à partir de règles logiques qui sont décrites en annexe.
Limites d’ISL : Les problèmes de superposition peuvent se gérer à plusieurs niveaux. Nous
dis-tinguons trois niveaux de gestion de superposition. Le premier niveau est semblable aux approches actuelles des aspects dans lequel nous gérons la concurrence entre les aspects soit à l’intérieur des aspects même ou bien de manière externe (dans un fichier de configuration par exemple). Le deuxième niveau concerne une amélioration par la gestion de la concurrence des aspects au niveau de la diffusion d’événements. Enfin, le troisième niveau permet de gérer plus finement la superposition des aspects en proposant une fusion interne des greffons.
Les composants mis en œuvre peuvent modifier et contrôler la manière dont les communications vont se passer entre les composants du système. La fusion analyse les composants selon leur position dans l’assemblage de composants constituant le greffon. Le moteur de fusion idéal serait capable de déduire automatiquement la composition finale sans avoir recours à la mise en concurrence des schémas. Il n’est cependant pas possible d’atteindre cet idéal, car les paramètres pour prendre les décisions ne sont pas complètement disponibles.
parL(~β)
parL( ~[a]) parL(~β)
parL([β1]) ∪parL( ~[a]) ⊕parL(~β \ β1)
si a = β1
si a 6= β1
(1.1) (1.2)
parK(~∅) parL(~β) (1.3)
parK(~α) parK(~α) ∪parL(~β) si K 6= L (1.4)
(a) Règles de concurrence
if~b, ~β if (~a, ~α) if ~[b], ~[β] ∪ ~[α 1]⊕ if (~a \ a1, ~α \ α1) if ~[a 1], ~[α1]∪if if ~[b], ~[β] ⊕ if (~a \ a1, ~α \ α1) si b = a1 si b 6= a1 (1.5) (1.6) if~∅,~∅ if~b, ~β (1.7) (b) Règles conditionnelles β del(β) β β (1.8) commuter (1.14)
del(α) del(α) (1.10) erreur ! si α 6= β (1.9)
call β (1.11) commuter (1.14)
nop β (1.12) commuter (1.14)
α erreur ! (1.13) commuter (1.14)
(c) Règles finales
(d) Classement des opérateurs
Exemples Le premier exemple concerne la fusion d’une alarme et d’un système de distribution d’événements. Deux points de coupe spécifient respectivement la variable observed et la variable worker qui sont en conflit (c’est-à-dire, produisent les mêmes points de jonction).
advice Alarm (observed,alarm):
observed.^Out −> ( if( alarm.Check ) call ) alarm.Check −> ( alarm.Start ; call ) advice Dispatcher (producer,worker,consumer):
producer.^Out −> ( worker.In ) worker.^Out −> ( consumer.In )
Les règles de spécifications (RSs) ne sont pas en conflit. Ainsi, elles sont recopiées dans le greffon résultant. Cependant, les RSs sont en conflit parce qu’ils redéfinissent le même événement ^Out du composant confondu observed/worker. Par conséquent, leur programme de spécification respec-tif sont fusionnés de manière logique et le greffon résultant AA0+Ex est calculé en utilisant la matrice de fusion de la Figure 5.16. L’opérateur + correspond à un couple non-ordonné d’opéra-tions à exécuter. Le processus de fusion remplace CALL à la ligne 3 par CALL+consumer.In dans AA0+Ex. L’AA résultant est alors traduit dans un ensemble de MSEs. Par exemple, l’opérateur IF est interprété comme l’ajout d’un composant générique de type IF.
Code en sortie :
adviceEx+AA0 (observed,alarm,producer,consumer): observed.^Out →( if( alarm.Check ) call ) alarm.Check →( alarm.Start ; call ) producer.^Out →( observed.In )
Nous avons vu le processus de conception spécifique aux AAs ainsi qu’un cycle d’adaptation d’une application pour l’informatique ambiante. Dans la partie suivante, nous présentons les cycles du processus d’auto-adaptation. La composition dans ce cas se fait à partir des composants spéci-fiques que nous utilisons pour composer l’assemblage.
5.4.2.3 Fusion BSL
L’extension du tissage vient ici du fait qu’il se révèle nécessaire dans plusieurs cas de gérer les conflits lorsque plusieurs aspects d’assemblage émettent un événement vers un même point d’entrée (c’est à dire la précédence au niveau des sorties). Nous avons mis en place quelques opérateurs qui permettent de gérer de manière locale les conflits en sortie des greffons. Ces opérateurs peuvent être combinés afin d’affiner la fusion.
Un premier exemple représente la connexion d’un composant variable commande à un compo-sant variable lampe. Cette connexion est arbitrée. Cela signifie que l’événement On du compocompo-sant variable commande doit être spécifié également par les autres greffons sinon, il ne sera pas pris en compte dans le schéma de composition final. D’autre part, le second exemple décrit la composition en cascade de deux composants spécifiques : l’arbitrage et le découpage. Comme le premier exem-ple, le composant variable commande est arbitré. Le second composant variable n’est pas sujet à l’arbitrage. Les deux sources d’événements sont sujets au découpage temporel de période p.
Nous avons deux opérateurs de coordination : l’opérateur d’arbitrage noté A et l’opérateur de découpage temporel noté H. Chacun de ces deux opérateurs est constitué de deux entrées. Il y a une entrée In qui permet de cascader les opérateurs et une entrée event qui est connectée aux sorties des composants variables ou blackbox. Cette opération est régie par un ensemble de règles de fusion que nous avons réunies dans une matrice. Les opérations de fusion des greffons sont régies par un ensemble de règles logiques. Ces règles sont regroupées dans la matrice que nous retrouvons dans la figure 5.17. Les propriétés de cette fusion sont la commutativité, l’associativité et l’idempotence. Ces propriétés sont étudiés dans le chapitre suivant.
Cette fusion modifie la manière dont le tissage s’opère. Nous l’analysons dans la section suivante. Le tissage est donc incrémenté d’un gestionnaire de conflit sur les sorties des composants et prend
a(~y) o(~y) conc(~y)
a(~x) a(tri1(~x, ~y)) (1.14)
o(~x) o(tri2(~x, ~y)) (1.15)
conc(~x) conc(concat1(~x, ~y)) (1.16)
(a) Règles de fusion des opérateurs BSL
Classement Opérateur Règles de transformation
1 Arbitrage a(~a)
2 Découpage b(~d) ∀x ∈ ~a, x 6∈ ~d
3 Concurrence conc(~c) ∀x ∈ ~a, x 6∈ ~d et ∀y ∈ ~d, y 6∈ ~c
(b) Fusion des opérateurs BSL
Figure 5.17 – Matrices de fusion BSL
en compte les composants spécifiques tels qu’ils sont décrits dans ce chapitre. Le reste du mécanisme de tissage par unification et par duplication reste identique. Ce mécanisme de gestion est rajouté à la fin du tissage.