Dans cette section, à travers un ensemble de questions et les éléments de réponse issus des différentes discussions de ce chapitre, nous présentons tout d’abord les motivations de cette thèse ; ce qui nous permet ensuite de définir précisément notre problématique et d’énoncer brièvement nos contributions.
Comment instrumenter le code des aspects ?
Au regard des différents travaux autour des interférences, il est difficile d’énoncer claire- ment comment instrumenter le code tissé pour observer les interférences à l’exécution comme on peut le faire pour les architectures réflexives commeREFLEXou les protocoles à méta-objet
comme SMALLTALK[50]. On peut toutefois affirmer que le coeur de la détection d’interférences
au niveau du code est certainement le mécanisme de séquencement des aspects. Toutefois, ce mécanisme ne présente pas la même flexibilité dans toutes les propositions, par exemple il ne permet la résolution que de manière restreinte dans ASPECTJ.
Actuellement, les approches comme celle de MAROTdécrites dans [50] et discutées ci-dessus
émettent l’idée que pour une propriété donnée un certain nombre de points d’observations sont nécessaires et leur instrumentation permet d’observer cette propriété. Se pose cependant la question concernant l’emplacement du code servant à l’instrumentation. Nous savons que l’instrumentation ne doit pas être implémenté dans les aspects. Nous savons également que le code d’instrumentation, tout comme le code de composition, est une préoccupation transver- sale. Apporter une réponse concrète à cette question est actuellement difficile car la majorité des langages de programmation orientée aspect sont des extensions de langages à objets qui permettent l’instrumentation du code des objets mais pas celui des aspects. Le code de la com- position des aspects peut être encapsulé avec succès dans des aspects dédiés comme le resolver [74]. Dans ce contexte, peut-on imaginer la même chose pour le code d’instrumentation des as- pects ? De plus, cela laisse supposer que tous les mécanismes d’instrumentation ciblant les dif- férentes propriétés de non interférence font partie intégrante de l’approche d’instrumentation. Finalement, répondre à cette question revient à identifier tous les mécanismes nécessaires et suffisants pour instrumenter la détection des interférences que nous ciblons.
Comment garantir que l’instrumentation mise en place cible correctement les interfé- rences potentielles à un point de jonction partagée ?
Comment garantir que l’instrumentation couvre les différents types de fautes potentielles aux points de jonction partagés. Les travaux sur la détection des interactions et les critères de couverture existants permettent de couvrir tous les points de jonction partagés et toutes les in- teractions de flot de données et de flot de contrôle à ces points de jonction. La couverture de points de jonctions peut donc être garantie.
La couverture des différentes fautes possibles à ces interactions requiert cependant d’avan- tage de rigueur. Nous pensons en effet que l’instrumentation doit être, d’une part, dirigée par les hypothèses faites lors de la réutilisation d’un aspect dans un contexte donné et, d’autre part, par le modèle de faute des interférences entre aspect : les interférences sont issues de la violation d’une hypothèse faite par l’intégrateur des aspects nécessaires à la réalisation d’une exigence non fonctionnelle.
En résumé, dans cette thèse nous défendons que l’assemblage d’applications rési- lientes constituées d’aspects implémentés à grain fin requiert que le code du proto- cole assemblé soit exempt de défaut. La validation d’un tel assemblage nécessite la mise en place d’une méthode et d’un outillage dédié à la validation des interactions entre aspects. Cette méthode de validation nécessite l’observation à l’exécution de propriétés de non-interférence et donc une instrumentation rigoureuse de ces pro- priétés. Notre problématique est donc la suivante :
– Identifier les points d’observation et les mécanismes d’instrumentation néces-
saires pour la détection d’interférences à l’exécution,
– outiller le processus d’instrumentation afin qu’un assemblage d’aspects puisse
être validé. Objectif .
Dans le chapitre 1 nous avons présenté les différents travaux sur la validation des systèmes construit à l’aide de la programmation orientée aspect. Nous avons mis en évidence le manque de travaux autour de la validation des interactions entre aspect.
Dans ce chapitre nous avons proposé une synthèse des travaux autour de la détection à l’exécution des interférences entre aspects. Nous concluons que le cœur d’une approche de détection d’interférence à l’exécution passe par une instrumentation adéquate.
L’instrumentation est le fer de lance d’une approche de détection d’interférences à l’exé- cution. C’est donc ce point qui sera traité en premier lieu. Le chapitre 3 présente la méthode d’instrumentation visant la détection des interférences dans un assemblage d’aspects. Ce cha- pitre commence par présenter les points d’observation requis pour l’instrumentation. Ensuite, chaque section présente l’instrumentation nécessaire pour un type d’interférence, flot de don- nées, flot de contrôle. Avant de conclure ce chapitre, une validation de l’approche d’instrumen- tation est présentée.
Chapitre 4
Évitement et détection des interférences
entre aspects
Préambule
Ce chapitre présente le cœur du travail de cette thèse qui est l’implémentation d’une approche permettant la validation d’un assemblage d’aspects.
La validation d’un assemblage d’aspects nécessite la vérification d’un certain nombre de pro- priétés de non-interférence. L’instrumentation du code tissé est donc l’élément le plus important de notre approche de validation. Dans ce chapitre nous commençons par présenter les proprié- tés de non-interférence que nous devons vérifier pour garantir qu’un assemblage d’aspects réalise bien le comportement attendu par l’intégrateur. Nous présentons ensuite les motivations et les ob- jectifs qui ont guidé nos choix techniques pour l’instrumentation. L’efficacité de notre approche est ensuite évaluée par une série d’expérimentations.
Sommaire
4.1 Introduction . . . 59 4.2 Observabilité des propriétés de non-interférence . . . 59 4.3 Composition des greffons à l’aide d’AIRIA . . . 62 4.4 Détection des interférences . . . 64 4.5 Etude de faisabilité . . . 69 4.6 Expérimentations et résultats . . . 80 4.7 Bilan . . . 83
4.1 Introduction
Les systèmes informatiques évoluent dans des environnements dynamiques, leurs fonc- tionnalités, leurs modèles de faute et les ressources évoluent durant le cycle de vie.
En effet, une implémentation de ces préoccupations dans un langage basé sur un para- digme conventionnel ne permet pas d’obtenir une implémentation facilement reconfigurable de la tolérance aux fautes. La programmation orientée aspect permet d’obtenir une implémen- tation reconfigurable du logiciel de tolérance aux fautes. La capacité de reconfiguration est ob- tenue par une implémentation à grain fin d’aspects réutilisables. Ces aspects sont utilisés pour configurer la tolérance aux fautes des systèmes par composition et reconfigurer ces systèmes par ajout ou suppression de sous-ensemble d’aspects. Cependant, la composition des aspects implémentant une stratégie de tolérance aux fautes peut contenir des interférences.
Ces interférences sont décrites dans le chapitre précédent. Nous nous concentrons sur les interférences liées à l’application de plusieurs aspects à un même point de jonction. Dans ce chapitre, nous présentons une approche combinant à la fois l’évitement et la détection des interférences. L’évitement des interférences est réalisé par l’utilisation deAIRIAqui permet de
contrôler la composition des aspects. La détection des interférences est réalisée grâce à l’utili- sation d’assertions exécutables qui exploitent les points d’observations fournis parAIRIA.
Dans ce contexte, nous devons :
– d’abord définir pour chaque type d’interférence de flot de données et de flot de contrôle, les points d’observation à observer à l’exécution pour détecter une interférence.
– Puis pour l’ensemble de ces propriétés nous définissons une stratégie d’instrumentation permettant de les vérifier à l’exécution en utilisant des assertions exécutables.
– Enfin nous validons notre approche d’instrumentation. Notre méthode d’instrumenta- tion s’inscrivant dans une approche générale, nous présentons l’organisation de cette approche et nous décrivons l’implémentation d’un prototype permettant de l’outiller.
Structure du chapitre
La section4.2définit les propriétés de non interférence à observer pour être capable de garantir qu’un assemblage d’aspects ne contient pas d’interférence. Dans cette même section nous présentons une étude comparative des langages de programmation orientés aspect pré- sentés au chapitre 2 au regard de l’observabilité des propriétés de non interférence. La section 4.3détaille le fonctionnement de AIRIA dans lequel les propriétés de non-interférence sont ob- servables. Les sections4.5.2et4.5proposent une étude de faisabilité de l’instrumentation des propriétés de non interférence identifiées en utilisant AIRIA. La section4.6présente le proces- sus de validation de notre approche d’instrumentation.