Nous allons présenter dans cette section un ensemble de perspectives aux travaux présentés dans cette thèse qui nous semblent intéressantes à explorer.
6.2.1 Faire évoluer les points de coupes des AAs
Afin de gérer plus finement le tissage des Aspects d’Assemblage, leurs points de coupe peuvent être étendus dans l’optique de ne plus considérer uniquement les méta-données associées aux composants. Par exemple, des points de coupes sémantiques permettraient de prendre en compte dans
le processus d’adaptation l’hétérogénéité sémantique des dispositifs qui composent l’infrastructure logicielle d’une application. Une autre possibilité serait de leur permettre d’identifier des équivalences sémantiques ou de QoS entre les services de l’infrastructure afin d’autoriser la substitution de services par d’autres équivalents. Des travaux comme ceux présentés dans [89] pourraient alors s’appliquer.
FIGURE6.1 – Vers des points de coupe sémantiques
Une autre particularité des points de coupes des AAs est leur application opportuniste ; il pourrait être intéressant d’intégrer d’autres politiques. Par exemple, une possibilité serait de retirer, de manière opportune, les fonctionnalités reposant sur des dispositifs qui viennent de quitter l’infrastructure lo- gicielle d’une application, et, par contre, de ne pas tisser automatiquement les aspects qui peuvent l’être. Une telle politique permettrait d’augmenter la stabilité du système, les modifications pour amé- lioration du système pourraient par exemple être décidées par l’utilisateur une fois que celui-ci les juges opportunes. Il faudrait alors distinguer parmi les perturbations, les disparitions des apparitions de dispositifs.
6.2.2 « Model checking » sur les applications en entrée et sortie du tisseur
Il pourrait être intéressant de vérifier à l’aide de model checking si un modèle d’application passé en entrée du tisseur de cascades vérifie un ensemble de spécifications. Ces vérifications pourraient permettre de personnaliser le tisseur en fonction des spécifications vérifiées. Un piste de travail intéressante serait alors de choisir, parmi plusieurs mécanismes de fusion, le plus adapté à ces spécifications. Ce mécanisme de vérifications pourrait également être appliqué au modèle produit en sortie du tisseur. Il s’agirait alors de vérifier si l’application produite respecte un ensemble de propriétés souhaitées. Par exemple, il pourrait s’agir de contraintes de sécurité.
Dans le cadre de l’architecture sur 4 niveaux, la tâche de déployer les bonnes spécifications dans une situation donnée reviendrait alors au niveau tactique. Les résultats des vérifications réalisées sur le modèle produit après tissage pourraient alors être remontés au niveau tactique et pourrait entraîner le redéploiement de nouveaux réflexes externes. Ce redéploiement concernerait aussi bien les cascades
FIGURE6.2 – Model checking
d’aspects que les spécifications.
6.2.3 Un méta-modèle d’assemblage et un langage de greffon applicable au plus grand nombre de plateformes d’exécution
Il pourrait également être intéressant de travailler plus en détail le méta-modèle d’application utilisé par les Aspects d’Assemblage afin que celui-ci soit applicable au plus grand nombre de pla- teformes d’exécution. Pour cela, plusieurs approches sont envisageables. La première consisterait à étudier les méta-modèles des plateformes existantes afin d’en faire une union tandis que la seconde consisterait à identifier l’ensemble des éléments nécessaire et suffisant devant se trouver dans le méta- modèle. Cela nécessitera une étude approfondie des plateformes mais aussi des ADL (Architecture Definition Langage) existant dans la littérature. Une étude similaire pourrait être réalisée au niveau du méta-modèle des greffons des AAs ainsi que de leur langage. L’étude pourrait permettre d’améliorer l’expressivité des AAs ainsi que leur lisibilité. Ces diverses études pourraient alors mener à augmenter les capacités des AAs, comme par exemple modifier le fait qu’une liaison est obligatoire ou option- nelle. Il conviendrait alors d’étudier dans quelle mesure de telles modifications n’entrainerait pas la perte de la propriété de symétrie de l’opération de tissage.
6.2.4 Vers un mécanisme de fusion plus évolué
Nous avons vu que le mécanisme de fusion proposé dans les AAs basé sur ISL4WComp repose sur un ensemble d’opérateurs dont la composition deux à deux à été prouvée symétrique. Il serait intéressant, dans des travaux futurs, d’améliorer ce mécanisme de fusion. Un premier axe de travail consisterait à augmenter le nombre de ces opérateurs et par conséquent de règles de composition qui leurs sont associées. Pour faciliter cette tâche, il serait profitable de disposer d’un mécanisme permettant de vérifier si les règles associées aux opérateurs peuvent bien être composées avec les autres règles de manière symétrique.
Une autre piste de travail consisterait à introduire des notions de sémantique dans ce mécanisme de fusion. Pour cela, un premier axe pourrait être de sélectionner l’opérateur de fusion par défaut entre deux règles (pour rappel, lorsque deux règles sont en conflits et n’utilisent pas d’opérateur, un opérateur de parallélisme est introduit entre elles), en fonction d’informations sémantiques associées à ces deux règles. Ensuite, cela pourrait consister à ajouter des contraintes sémantiques dans les règles
de fusion. Ce point soulève également la question d’intégrer de la sémantique dans les greffons des aspects.
6.2.5 Et si on arrête plus les cascades ?
Une autre piste de travail reposerait sur l’idée de « laisser couler les cascades », c’est-à-dire d’enchaîner les cycles de tissage de manière circulaire tant qu’il est possible d’adapter (FIGURE
6.3). Dans le processus de tissage d’une cascade, une fois le dernier cycle de tissage réalisé, cela consisterait à réaliser à nouveau le cycle de tissage 0 et ainsi de suite jusqu’à ce qu’aucun aspect ne puisse plus être tissé (la propriété d’idempotence garantissant que les mêmes règles ne sont pas dupli- quées). Cela permettrait, par exemple, à des aspects d’un cycle de tissage de bénéficier des éléments instanciés par d’autres aspects de tous les cycles y compris les suivants et le sien. En particulier, cela permettrait à un aspect d’être déployé avec d’autres aspects dans un même cycle sans contraintes d’ordre, mais d’être tissés selon un ordre dirigé par l’opportunisme pour qu’un maximum d’as- pects puissent être tissés. La fonctionnalité de perception par exemple pourrait elle-même s’améliorer.
FIGURE6.3 – Laisser coules les cascades
Un tel système offrirait alors de nombreuses similitudes avec les systèmes de réécriture, la ques- tion qui se poserait alors serait de savoir si le mécanisme d’adaptation est convergent. Cette propriété de convergence se définie elle-même comme en ensemble de deux sous-propriétés : la confluence et la terminaison. Si la propriété de symétrie de l’opération de tissage peut laisser supposer que la pro- priété de confluence est vérifiée, il apparaît clairement que la propriété de terminaison de l’est pas. En effet, si nous considérons qu’un aspect A, pour un cycle de tissage, ajoute un point de jonction permettant le tissage d’un autre aspect B, d’un autre cycle, et inversement que B ajoute un point de jonction permettant le tissage de A ; alors, l’opération de tissage n’est plus terminale. Cependant, la détection d’un tel phénomène semble pouvoir être identifiée et neutralisée lors du déploiement d’une cascade en représentant les interactions entre aspects sous la forme d’un graphe et en identifiant les cycles dans ce graphe.
6.2.6 Diagramme de feature et cascades d’aspects
Nous avons vu que les cascades d’aspects, en terme de variabilité, offrent des possibilités qui peuvent être exprimées sous la forme de diagramme de feature. En particulier, nous avons vu qu’elles permettent d’exprimer deux types de relations : « et » et « ou ». Dans les diagrammes de feature, d’autres opérateurs existent, il serait alors intéressant de faire évoluer les cascades afin qu’elles per- mettent d’en exprimer tous les types. En particulier, il serait alors possible, à partir d’un diagramme de features de construire des cascades dans une approche « top-down » et inversement pour une approche
« bottom-up ». Enfin, grâce aux capacités d’extensibilité offertes par les cascades et la propriété de symétrie, serait-il envisageable d’utiliser une telle approche pour réaliser des compositions de dia- grammes de features à l’exécution ?
6.2.7 Faire cohabiter plusieurs architectures sur quatre niveaux
Nous avons vu que l’architecture sur 4 niveaux a pour objectif de gérer un assemblage de composant permettant d’orchestrer localement des dispositifs et par conséquent des services pour dispositifs. Cette architecture peut être vue comme globale lorsqu’elle orchestre l’ensemble des dispositifs du système. Cependant, il est possible d’envisager que les nœuds d’exécution sur lesquels sont déployés ces architectures sont mobiles. Il n’est donc pas possible d’anticiper leur présence. Il peut alors être envisagées d’utiliser l’architecture de manière décentralisée. Il serait ainsi possible d’avoir plusieurs nœuds d’exécution pour plusieurs architectures sur quatre niveaux qui pourraient réaliser des orchestrations locales autonomes et pourraient communiquer à travers elles de manière globale. La question de l’auto-organisation d’un tel système se pose ainsi que celle de la définition des interactions entre les différents systèmes. Les quatre niveaux de l’architecture sont-ils nécessaires ? A travers quels niveaux peuvent se faire les interactions ? Est-il envisageable d’obtenir une organisation hiérarchique ? Est-ce que l’architecture sur quatre niveaux peut être vue comme une architecture pour des agents ambiants ?
Comme nous pouvons le constater, de nombreuses pistes, à plus ou moins long terme, peuvent venir compléter les travaux réalisés dans cette thèse et ouvrent des portes vers des extensions ou collaborations dans de nombreux domaines.