La configurabilité des systèmes se trouve au cœur des préoccupations industrielles. En
ef-fet, la réutilisation de composant logiciels pour la construction de systèmes complexes requiert
que ces composants soient configurés en vertu de leur environnement de déploiement et des
autres composants du système. Ensuite, lorsque ces systèmes évoluent ou font face à des
chan-gement dans leur environnement, il est nécessaire de les reconfigurer. Dans ce contexte, il est
nécessaire de maintenir la sûreté de fonctionnement du système, de garantir sa résilience.
Une évolution importante des technologies logicielles a été constituée par l’utilisation de
la notion de réflexivité. La réflexivité est la propriété d’un système qui lui permet de raisonner
et d’agir sur lui-même. L’application de ce concept aux technologies orientées-objet mène à la
notion de protocole à méta-objets. Un méta-objet peut contrôler et agir sur un objet en
utili-sant le protocole à méta-objets. Nous avons présenté en section I.3 diverses utilisations de ces
concepts, qu’ils soient utilisés au moment de la compilation ou de l’exécution de l’application.
L’avantage majeur des protocoles à méta-objets est de permettre le développement séparé et
indépendant de l’application et de mécanismes non-fonctionnels, de tolérance aux fautes par
exemple pour ce qui nous concerne.
Dans la même lignée, des techniques d’implémentation évoluées comme la POA permettent
d’aboutir au même résultat avec cependant des capacités supplémentaires d’observation et
d’action sur le système. La POA permet de gérer la variabilité des caractéristiques non
fonction-nelles d’un système de manière transparente, configurable en encapsulant le code de gestion
de la tolérance aux fautes dans des aspects qui sont déployés dans le système en fonction des
besoins.
Le code des aspects implémentant la tolérance aux fautes doit être "zéro défaut". De
nom-breuses approches de validation par le test s’intéressent à différents problèmes posés par la
validation de la POA.
Les travaux sur les modèles de fautes donnent de précieuses indications sur les
construc-tions "dangereuses" du langage. Certains travaux exploitent ces données afin de fournir des
critères de couverture. Cependant, la majeure partie des travaux de test de systèmes orientés
aspect porte sur les interactions entre aspects et code de base. Le traitement des interactions
entre aspects lors de la validation nous semble incontournable puisqu’il s’agit d’implémenter
des mécanismes de tolérance aux fautes qui sont par hypothèse exempts de fautes (test et
vali-dation par injection de fautes). Ces travaux de thèse visent donc à couvrir une partie du modèle
de fautes de la POA, liée à la composition des aspects, peu traitée d’un point de vue de la
vali-dation par le test.
Les travaux sur le test d’intégration considèrent des petits exemples de programmes
orien-tés aspect. Déterminer les niveaux de test pour les applications de plus grande taille, dans
les-quelles les points de jonction impactés par des aspects sont plus nombreux et les aspects plus
nombreux, exige des travaux plus approfondis. L’implémentation de mécanismes de tolérance
aux fautes à grain fin nécessite de prendre en considération à la fois les dépendances (plusieurs
micro-mécanismes qui composent une stratégie) entre aspects et les éventuels conflits
(cer-tains mécanismes sont exclusifs) ou les effets de bord.
Les différentes approches de couverture de critères de test raisonnent sur des graphes de
flot de contrôle et de flot de données. Se pose alors la question de disposer de la possibilité
de construire des représentations des flots de contrôle et de données pour des programmes
complexes. Plus précisément, au regard du traitement des interactions entre aspects, quel est
le modèle logique qui permet la couverture des interactions, quels sont les critères de
couver-ture de ces modèles que l’on doit réaliser ?
En termes d’oracle, les travaux existants permettent de vérifier les propriétés nécessaires
pour valider les interactions aspect-base. Les interactions entre les aspects ne sont pas
cou-vertes par ces travaux. Se pose alors la question de disposer d’un oracle permettant de valider
les interactions entre aspects, et de l’identification des propriétés que doit vérifier cet oracle.
Le chapitre suivant aborde donc le problème des interactions entre aspects. Il s’agit de
dé-finir plus finement les fautes potentielles contenues dans les interactions entre aspects. Une
fois ces fautes identifiées, nous pourrons alors identifier les propriétés permettant de détecter
ces fautes pendant l’activité de test. Il s’agit de définir les propriétés qui serviront de base à
la construction d’un oracle pour la validation des interactions. Les propriétés liées à l’absence
d’interférences indésirables entre aspects constituent le sujet du prochain chapitre.
Chapitre 3
Interactions et interférence entre
aspects
Préambule
Ce chapitre précise la problématique et les objectifs de ce travail de thèse. La problématique est
celle de la validation des interactions entre aspects lors d’un développement à l’aide de la
pro-grammation orientée aspect. L’implémentation à grain fin des aspects de tolérance aux fautes
conduit à des interactions entre ces aspects, ce qui constitue des sources potentielles d’erreur. Afin
de valider les applications assemblées à partir de ces aspects, il est nécessaire de traiter ces
in-teractions à travers des méthodes de prévention et d’élimination de fautes. Après un bref état de
l’art des travaux autour de la détection, de la résolution et de la validation des interactions entre
aspects, la problématique et les objectifs de cette thèse sont présentés à travers un ensemble de
questions que nous nous sommes posées tout au long de ce travail. Enfin, nous terminons ce
cha-pitre en précisant l’organisation de ce mémoire.
Sommaire
3.1 Contexte : Interactions, interférences entre aspects. . . 37