LLAIL-CLIC1000
Télécharger le fichier original (Mémoire de fin d’études)
Les approches de séparation avancée de préoccupations
Comme nous avons montré dans la section précédente, le principal problème des approches classiques revient à la mauvaise modularisation des préoccupations transversales, pour cette raison plusieurs nouvelles approches sont proposées pour garantir une meilleure séparation et composition de tout type de préoccupations, ces approches sont connues sous la désignation plus générale d’approches de séparation des préoccupations.
Les principales approches pour la séparation des préoccupations sont :
La programmation orienté aspect,
Les filtres de composition,
La séparation multidimensionnelle des préoccupations,
Programmation par rôles ou points de vue,
Programmation adaptative.
La programmation orientée aspect
Parmi les approches les plus connues de séparation des préoccupations, on trouve la programmation par aspects [Kiczales, 1997], Les fondements de ce paradigme ont été définis au centre de recherche (PARC) de Xerox, à Palo Alto au milieu des années 90 [Hachani, 2006].
La programmation par aspect, explore des pistes alternatives visant à corriger les défauts d’adaptation et de modularité des programmes à objets [Denier, 2007]. Elle s’intéresse au problème particulier de la modularité des préoccupations transversales. Suivant cette problématique, la décomposition d’un système informatique en préoccupations ne cadre pas toujours avec un système hiérarchique de classes : certaines préoccupations sont « forcées » dans les classes existantes. En termes de symptômes, les implémentations de ces préoccupations sont dispersées et mélangées avec les autres préoccupations. La programmation par aspects est une technique visant une bonne modularisation de ces préoccupations, en complément des mécanismes préexistant dans les langages classiques [Filman, 2005].
Le principe de la programmation orientée aspect est de coder chaque problématique séparément et de définir leurs règles d’intégration pour les combiner en vue de former un système final. Le tisseur (Weaver) est l’infrastructure qui permet de greffer le code des aspects dans le code des méthodes des classes [Amirat, 2007].
Et pour mieux comprendre ce principe, nous pouvons reprendre la description originale faite par Gregor Kiczales et ses collègues [Kiczales, 1997]. Une préoccupation qui doit être implémentée est soit:
Un composant. Si elle peut être clairement encapsulée dans un objet, ou un module. Les composants sont donc, par définition, des unités fonctionnelles d’un système. Par exemple, les services d’impression ou d’accès aux bases de données d’une librairie digitale.
Un aspect. Si elle ne peut pas être clairement encapsulée dans un composant. Les aspects correspondent donc souvent aux exigences non-fonctionnelles d’un système. Par exemple, la synchronisation, la performance et la fiabilité d’une librairie digitale.
En utilisant ces termes, on entrevoit le but de la programmation orientée aspect : aider le programmeur à séparer clairement les aspects et les composants les uns des autres en offrant des mécanismes qui permettent de les abstraire et de les composer pour obtenir le système général [Baltus, 2002]. L’indépendance de chaque problématique rend le système final bien structuré et facilite son évolution et maintenance dans l’avenir.
En général, le cycle de développement dans la programmation orientée aspect se fait en trois étapes :
La décomposition aspectuelle. Consiste à décomposer les besoins afin d’identifier et séparer les problématiques transversales et métiers.
Implantation des préoccupations. Consiste à implanter chaque problématique séparément. Les fonctionnalités métiers ont implantées moyennant les techniques conventionnelles de la programmation orientée objet, alors que les préoccupations transversales, représentées par des aspects, peuvent être exprimés selon deux approches :
– Concevoir un langage spécifique (ou étendre un langage existant par de nouvelles constructions syntaxiques),
– Fournir un cadre logiciel (framework) ajoutant le support des paradigmes aspects.
Recomposition aspectuelle. On parle ici du Tissage, c’est-à-dire la composition du système final comportant les différentes préoccupations, cette étape est basée sur des règles prédéfinies lors de l’implémentation.
La figure 5 résume ces trois étapes.
Figure 5 Intégration du code des composants et des aspects pour former le système final
Les filtres de composition
L’approche par filtres de composition [Aksit, 1998], [Bergmans, 1994] a été développée par le groupe TRESE, au département d’informatique de l’université de Twente, au Pays-Bas [Filters, Web]. Cette approche est motivée par la difficulté d’adresser, de manière indépendante et séparée, la coordination de messages complexes échangés entre objets en collaboration pour réaliser une ou plusieurs préoccupations particulières. Partant de ce constat, les filtres de composition proposent d’étendre le paradigme Objet en ajoutant le concept de filtre de messages [Hachani, 2006], ce nouveau concept ajoute aux objets de l’application des filtres qui interceptent l’envoi et la réception de messages. Les messages entrants (respectivement sortants) sont soumis à l’ensemble des filtres d’entrée (respectivement de sortie). Cette fonctionnalité est obtenue à travers la réification des envois de message.
Un filtre est lui-même un objet qui évalue et manipule des messages réifiés. Un filtre peut accepter ou rejeter un message tout en déclenchant un certain nombre d’actions. Les filtres sont ordonnés dans un ensemble (de filtres d’entrée ou de sortie), c’est leur seule capacité de composition immédiate, ils sont tous orthogonaux deux à deux.
Un message n’est reçu par l’objet destinataire qu’après avoir passé tous les filtres d’entrée. De même, un message ne quitte l’objet émetteur qu’après avoir passé l’ensemble des filtres de sortie [Quintian, 2004].
La séparation multidimensionnelle des préoccupations
L’approche de séparation multidimensionnelle des préoccupations a été proposée par Peri L. Tarr et Harold Ossher d’IBM [Tarr, 1999]. Cette nouvelle approche s’attaque aux limites des décompositions actuelles, tout en permettant une séparation souple et claire entre les multiples préoccupations.
Le terme « multidimensionnelle » dénote une séparation des préoccupations qui implique une décomposition des programmes en plusieurs dimensions arbitraires, où chaque dimension regroupe un ensemble de préoccupations particulières. L’ensemble des classes d’une application constitue, par exemple, une dimension. Il s’agit de la dimension des préoccupations des classes [Hachani, 2006].
La structure modulaire issue de la décomposition est appelée un hyperslice (hypertranche). Un hyperslice ne contient que les unités pertinentes à une préoccupation particulière, les règles de composition sont décrites dans des HyperModules, enfin, une phase de composition nommée intégration réunit tous les comportements pour former l’application finale.
Les trois activités liées à la séparation des comportements : identification, encapsulation et intégration sont prises en charge par le modèle des HyperSpaces.
L’identification est la sélection d’une préoccupation, elle contient les classes et les méthodes qui lui sont pertinentes. La préoccupation est alors représentée par un HyperSpace.
Les préoccupations sont ensuite encapsulées pour être manipulées comme des classes, dans différents HyperSlices. Un HyperSlice peut contenir une ou plusieurs préoccupations.
Finalement, pour intégrer correctement les différentes préoccupations, les HyperModules définissent les règles de composition. Notons qu’un
HyperModule peut servir d’HyperSlice pour un autre HyperModule ; on peut donc le considérer comme un HyperSlice composite. [Quintian, 2004].
Enfin un hyperespace est constitué d’un ensemble d’hypermodules qui réalisent différentes modularisation des mêmes unités. Les systèmes peuvent être composés de plusieurs façons à partir de ces hypermodules, les changements et l’ajout de fonctionnalités sont effectués par l’ajout de nouvelles unités ou/et hypermodules.
La programmation par rôles ou points de vue
La programmation par rôles [Gottlob, 1996] ou par points de vue [Bardou, 1996] et [Abiteboul, 1991] sont deux paradigmes assez proches ; ils proposent de structurer les programmes en groupes d’objets ou chaque groupe représente un point de vue du système à développer. Ils permettent de déstructurer la notion d’objets par l’introduction de vues subjectives : les rôles qu’ils jouent ou les points de vue qu’ils représentent.
Les rôles ou les vues sont donc les préoccupations dont ces deux modèles formalisent la séparation.
Il est à noter que ce paradigme ne fait pas la distinction explicite entre préoccupations de base et préoccupations transversales. En effet, chaque groupe d’objets représente une préoccupation au sens large, et toutes les préoccupations sont au même niveau. Subséquemment, même si conceptuellement, ces deux paradigmes permettent de supporter la séparation des préoccupations, leurs différentes implémentations ne permettent pas de réconcilier les problèmes de partage de données et de recouvrement de diverses définitions entre les différentes préoccupations [Quintian, 2004] [Hachani, 2006].
La programmation adaptative
La programmation adaptative a été développée par Karl Lieberherr et son équipe à l’université de Northeastern [Lieberherr, 1994], connue aussi sous le nom de programmation orientée patron.
La programmation adaptative est réalisée par l’utilisation des modèles de propagation, ces derniers sont motivés par la loi de Demeter qui suggère de ne pas relier les détails des structures des classes lors de l’écriture des méthodes. Les modèles de propagation prennent cette idée un peu plus loin en gardant les détails des structures des classes de programmes entiers autant que possible.
En se basant sur ce principe, la programmation adaptative étend le paradigme orienté objet en élevant la programmation à un niveau d’abstraction supérieur, dans une forme plus simple, ou on trouve moins de dépendances. En outre, lorsque des changements à un programme d’adaptation sont nécessaires, ils sont beaucoup plus faciles à intégrer vu la légèreté de ces programmes.
Les avantages ci-après résultent de l’utilisation des programmes d’adaptation :
Les programmes d’adaptation se concentrent sur le cœur du problème à résoudre ce qui leur permet d’être plus simples et plus courts que les programmes orientés objets classiques.
Les programmes d’adaptation améliorent la réutilisation, en effet de nombreux comportements nécessitent les mêmes caractéristiques qui sont effectivement réutilisées. [Lieberherr 1996]
Les principes de base de la programmation orientée aspect
Comme c’est déjà noté, la programmation orientée aspect prône une décomposition des programmes non seulement en unités modulaires représentant les préoccupations fonctionnelles de base, mais aussi en unités modulaires dédiées à la représentation des préoccupations transversales. Elle offre de plus des solutions adéquates de composition de préoccupations (on parle aussi de tissage), afin de construire des systèmes efficaces.
Dans ce qui suit nous allons présenter les concepts de base de ce nouveau paradigme (La plus part de ces définitions sont tirées des deux livres [Pawlak, 2004] et [Laddad, 2009]).
Le concept d’Aspect
La notion d’aspect est au cœur de la POA. En programmation procédurale, un découpage est fait selon les traitements à effectuer (i.e. procédures, fonctions). En programmation orientée objet, le découpage se fait en encapsulant les différentes entités manipulées au sein de classes comprenant les données et traitements relatifs à ces entités. En programmation orientée aspect, un aspect est une entité logicielle permettant d’encapsuler une fonctionnalité transversale d’une application, il comprend les données et les traitements nécessaires à l’exécution de cette fonctionnalité.
La définition d’un aspect est quasiment identique à celle d’une classe en programmation orientée objet, cependant la différence est que :
Les classes manipulent des entités techniques, métier et présentation,
Les aspects représentent toutes les fonctionnalités transversales de l’application
Le lien entre ces deux types d’entités se fait grâce aux points de jonction et aux coupes (ou points de coupure) que nous présenterons dans ce qui suit.
Le concept de point de jonction
Un point de jonction est un endroit dans le code du programme où seront utilisés un ou plusieurs aspects. Ce point de jonction est déterminé lors de la programmation par le développeur. L’utilisation d’un aspect pour un point de jonction se fait de manière dynamique, c’est-à-dire une fois le programme en exécution.
Il existe plusieurs types de points de jonction, selon ce que le développeur souhaite intercepter. Ainsi, un point de jonction peut intervenir pour:
Une classe
Une interface
L’exécution d’une méthode
L’accès à une variable de classe
L’exécution d’un bloc de code
L’exécution d’un mot-clé de langage (condition, boucle, …)
Potentiellement, un programme comporte un nombre important de points de jonction. Il est donc pertinent de sélectionner les plus appropriés au travers de coupes.
Le concept de coupe
Une coupe (ou un point de coupure) désigne un ensemble concret de points de jonction à prendre en compte dans une application. Une coupe est définie à l’intérieur d’un aspect. Un aspect peut contenir une à plusieurs coupes selon la complexité du projet.
Les notions de point de jonction et de coupe sont étroitement liées. Une coupe, de par sa définition, désigne plusieurs points de jonction. Un point de jonction peut quant à lui être référencé par différentes coupes.
Le concept de consigne (Advice)
Une consigne (advice en anglais) représente un comportement technique particulier d’un aspect. Concrètement, c’est un bloc de code qui sera greffé dans l’application à l’exécution d’un point de jonction définit dans une coupe.
Un aspect peut contenir une à plusieurs consignes. De même qu’un aspect peut être assimilé à une classe en programmation orientée objet, un code de consigne pourra être comparé à une méthode de l’aspect.
Comme nous l’avons vu précédemment, une coupe peut contenir plusieurs points de jonction, qui eux-mêmes peuvent référencer plusieurs aspects. Une consigne est donc susceptible d’être utilisée à plusieurs endroits dans l’application et un point de jonction peut éventuellement greffer plusieurs consignes au moment de l’interception.
Différents types de consignes peuvent être identifiés, selon la manière dont ils sont exécutés à l’apparition d’un point de jonction définit par une coupe.
Les consignes before
Une consigne de type before, exécute son bloc de code avant l’exécution du code intercepté. Le déroulement d’un type before peut être récapitulé ainsi:
exécution du programme
arrivée à un point de jonction
exécution du code de la consigne
exécution du code intercepté
fin du point de jonction, suite de l’exécution du programme
Les consignes after
Le bloc du code, d’une consigne de type after est exécuté après l’exécution du code intercepté1.
Le bloc de code de ce type est exécuté si l’exécution du code intercepté s’est correctement effectuée. Le déroulement peut être récapitulé ainsi:
exécution du programme
arrivée à un point de jonction
exécution du code intercepté
exécution du code de la consigne
fin du point de jonction, suite de l’exécution du programme
1 On peut distinguer deux types de consignes after:
– After returning : ce type est exécuté si l’exécution du code intercepté s’est correctement effectuée.
– After error : est exécuté si l’exécution du code intercepté a provoqué une erreur.
Les consignes around
Une consigne de type around, exécute son bloc de code avant et après l’exécution du code intercepté. Ainsi, une consigne around est composée de deux parties avant et après. Le déroulement d’une greffe around peut être récapitulé ainsi:
exécution du programme
arrivée à un point de jonction, exécution de la partie avant du code de la consigne
Si certains traitements de la partie avant imposent la non-exécution du code intercepté (par exemple, pour des raisons de sécurité), le point de jonction ne fera pas appel à la méthode qui permet d’exécuter le code intercepté. Cette dernière si elle n’est pas appelée, le code intercepté est remplacé par le code de la consigne.
exécution du code intercepté
exécution de la partie après du code advice
fin du point de jonction, suite de l’exécution du programme
Le concept d’introduction
Les mécanismes de coupes et de consignes que nous avons vus jusqu’à présent permettent de définir des aspects qui étendent le comportement d’une application. Les coupes désignent des points de jonction dans l’exécution de l’application (appel de méthode, exécution, lecture d’un attribut, etc.), tandis que les codes des consignes ajoutent du code avant ou après ce point.
Dans tous les cas, il est nécessaire que les codes correspondant aux points de jonction soient exécutés pour que les codes des consignes le soient également. Si les points de jonction n’apparaissent jamais, les codes des consignes ne sont jamais exécutés, c’est-à-dire ne seront jamais ajoutés à l’application.
Le mécanisme d’introduction permet d’étendre le comportement d’une application en lui ajoutant des éléments, essentiellement des attributs ou des méthodes. Contrairement aux codes des consignes, qui étendent le comportement d’une l’application si et seulement si certains points de jonction sont exécutés. Le mécanisme d’introduction est sans condition : l’extension est réalisée dans tous les cas.
Le concept de tissage
Le tissage (weaving en anglais) est une opération automatique qui est absolument nécessaire pour obtenir une application opérationnelle, cette étape sert à intégrer les fonctionnalités des classes et celles des aspects.
Le programme qui réalise cette opération est appelé un tisseur d’aspects.
L’application obtenue à l’issue du tissage est dite tissée.
Les règles de tissage
Les règles de tissage précisent la façon d’intégrer les préoccupations pour former le système final. Ces règles sont définies dans les aspects et spécifiées par le concepteur de l’application afin de recouper correctement les préoccupations entre-elles.
Le langage utilisé pour spécifier ces règles peut être une extension d’un langage standard, ou bien une chose totalement différente. Par exemple utiliser un langage basé sur XML.
Exemple :
Avant chaque opération sur le système bancaire, le client doit être authentifié.
Règle de tissage unité fonctionnelle une préoccupation
Le tisseur
Le tisseur est un outil spécial utilisé pour greffer le code des aspects dans le code des méthodes des classes suivant les règles de tissage prédéfinies.
Figure 8 Tisseur POA
On distingue deux types de tisseurs, en fonction du moment de leur utilisation.
Nous les expliquons ci-après.
Le tisseur statique (Tissage à la compilation)
Dans ce cas le tisseur est un programme qui, avant l’exécution, prend en entrée un ensemble de classes et un ensemble d’aspects et fournit en sortie une application augmentée des aspects. Un tel tisseur est donc très proche d’un compilateur, on le distingue parfois sous le terme de compilateur d’aspect.
Les classes fournies en entrée du tisseur peuvent se présenter soit sous forme de code source, soit sous forme de code intermédiaire (bytecode). Il y a aussi des solutions mixtes, dans lesquelles certaines parties de code sont du code intermédiaire. Tandis que d’autres sont du code source.
Un tisseur admettant en entrée du code intermédiaire est généralement plus intéressant qu’un tisseur n’acceptant que du code source. En effet, on est alors capable de tisser des applications, commerciales ou fournies par des tiers, dont le code source n’est pas disponible. De plus, le tisseur est plus simple à réaliser. En effet, l’analyse du code en entrée est alors une analyse de code intermédiaire plutôt qu’une analyse de code source, plus complexe. De plus, le code intermédiaire est exempt d’erreur de syntaxe, ce qui n’est pas forcément le cas de code source, une conséquence de cette simplification est que le tisseur est aussi plus performant.
La nature du code fourni en sortie par le tisseur dépend de celle des classes en entrées. Si le code en entrée est du code source, la sortie peut être soit du code source, soit du code intermédiaire. Par contre, si le code en entrée est du code intermédiaire, la sortie est nécessairement sous forme de code intermédiaire.
Lorsque la sortie est sous forme de code source, les applications produites sont lisibles. Les développeurs peuvent facilement consulter ce code source et étudier les effets des aspects sur l’application. Ce code source doit toutefois être compilé avec un compilateur traditionnel, ce qui ralenti la chaine de production et rend difficile une compilation incrémentale.
A titre d’exemple, les premières versions d’AspectJ [AspectJ, Web], généraient du code source. Depuis la version 1.1, AspectJ ne génère plus que du code intermédiaire. A moins d’utiliser un décompilateur de code intermédiaire, il n’est donc plus possible de consulter le code produit par AspectJ.
Avec le tissage à la compilation, les aspects sont pris en compte lors de la compilation pour produire une application tissée. Ils ne subsistent pas en tant que tel au moment de l’exécution. Leurs effets sont certes présents dans le code final, mais il n’y a aucun moyen de distinguer le reste du code. Il n’est donc pas possible de retirer des aspects, d’en ajouter de nouveaux ou de modifier la façon dont ils ont été tissés. Ce type de tissage est dit statique.
Le tisseur dynamique (Tissage à l’exécution)
Dans le cas du tissage à l’exécution, le tisseur est un programme qui permet d’exécuter à la fois l’application et les aspects qui lui ont été ajoutées.
La principale différence avec le tissage statique réside dans la manière dans les aspects sont associés au code métier. Dans AspectJ, par exemple, l’approche statique spécifie dans la définition de l’aspect avec quelles classes il doit être tissé. Mais les solutions dynamiques, comme JBoss AOP [JBoss AOP, Web], AspectWerkz [AspectWerkz, Web] ou encore AspectJ 5, préfèrent utilisés un document XML pour associer les aspects au code métier.
Avec un tel tisseur, application et aspects doivent nécessairement se présenter sous forme de code intermédiaire. Ils doivent donc avoir été préalablement compilés. L’avantage d’une telle technique est que les aspects peuvent être ajoutés, enlevés ou modifiés à chaud, pendant que l’application s’exécute. Cette caractéristique s’avère intéressante pour les applications qui ont de fortes contraintes de disponibilité et qui ne peuvent être arrêtées pendant de longues périodes. Tel est le cas, par exemple, des serveurs d’applications. Un tel mode de tissage est dit dynamique.
Dans la plupart des cas, le tissage à l’exécution doit être précédé d’une phase d’adaptation. Cette dernière a pour rôle de préparer l’application en vue de l’exécution des aspects. Concrètement, les parties de l’application qui sont susceptibles d’être modifiées par des aspects le sont, et le fil d’exécution normal du programme est redirigé vers le tisseur. Ce dernier détermine si une instruction d’aspect doit être exécutée. La phase d’adaptation est réalisée juste avant l’exécution, lors du chargement des classes dans la machine virtuelle.
Si l’étape d’adaptation n’était pas mise en œuvre, l’application doit être exécutée dans un mode de supervision proche de ce qui se passe avec un débogueur. La supervision aurait alors pour fonction de déterminer, à chaque pas d’exécution de l’application, si un aspect doit être ajouté ou non. Le temps d’exécution d’un tel processus serait prohibitif en termes de coût. La phase d’adaptation évite cet inconvénient en identifiant préalablement dans les applications les emplacements ou les instructions d’aspects sont applicables.
Travaux sur l’approche orientée aspect
L’apparition de l’approche aspect, a apporté de fortes motivations au monde du génie logiciel, plusieurs travaux couvrant tout les phases de cycle de développement de systèmes logiciels, ont ainsi vu le jour.
Analyse des besoins,
Conception,
Développement de logiciels
…
D’autres se sont intéressés à l’influence et les conflits causés par les interactions entre les nouveaux concepts de la programmation orientée aspect, et les classes de bases. Ces études se basent sur des méthodes formelles, plus particulièrement, la vérification formelle de ces interactions [Mostefaoui, 2007], [Chen, 2010], [Katz, 2003].
La réingénierie est aussi présente, où plusieurs travaux proposent d’analyser les applications à base d’objets déjà existantes, pour extraire des aspects en vue de les réécrire dans une approche Aspect, comme par exemple le travail de [Ettinger, 2004].
Un autre domaine de recherche qui est très actif, et qui touche un des axes de notre recherche, concerne l’implémentation des patrons de conception, comme ceux de GoF [Gamma, 1995] avec les concepts aspect. Les premiers travaux dans ce domaine ont eu comme objectif, d’éclairer et tester les apports de la programmation orientée aspect dans la réalisation des différents patrons [Hannemann, 2002], [Garcia, 2006] d’autres pour offrir aux développeurs des nouveaux patrons basés sur les nouveaux concepts de programmation [Lorenz, 1998], [Noda, 2001], [Nordberg, 2001]. Cependant, la majorité de ces travaux ont pris AspectJ comme le représentant majeur de la programmation orientée aspect, dans la plus part de leurs études.
Conclusion
Les préoccupations transversales sont le cœur des principaux problèmes observés lors de la conception et l’implémentation des logiciels avec les approches classiques. Elles se dispersent dans les différents modules constituant le système, ce qui perturbe la compréhension, et rend l’évolution et la maintenance plus complexes.
La programmation orientée aspect, les filtres de composition, la séparation multidimensionnelle des préoccupations, la programmation par rôles ou la programmation adaptative, sont toutes des nouvelles approches riches et ambitieuses, chacune d’entre elles tente de résoudre les problèmes des préoccupations transversales en offrant des modules de décomposition et d’organisation permettant d’obtenir des applications compréhensibles et facilement manipulables.
Grâce au concept d’aspect, la programmation orientée aspect permet avec élégance d’intégrer à une application orientée objet des fonctionnalités transversales en s’appuyant sur les notions complémentaires de coupes, de points de jonction et de code de consigne. L’opération d’intégration est désignée sous le terme de tissage, elle peut être réalisée au moment de la compilation, ou pendant l’exécution de l’application.
L’importance des concepts proposés par la programmation orientée aspect, ont fait apparaitre plusieurs langages pour les mettre en œuvre dans le monde réel. Le chapitre suivant, présente trois différents projets créés pour satisfaire les concepts de base de la programmation orientée aspect.
Table des matières
INTRODUCTION GENERALE
1 CONTEXTE DU TRAVAIL ET OBJECTIF
2 PROBLEMATIQUE
3 MOTIVATIONS
4 METHODOLOGIE DE RECHERCHE
5 ORGANISATION DE LA THESE
CHAPITRE 1 : LA SÉPARATION AVANCÉE DES PRÉOCCUPATIONS
1 LES LIMITES DE LA PROGRAMMATION OBJET
1.1 Les préoccupations transversales
1.1.1 L’enchevêtrement du code
1.1.2 L’éparpillement du code
1.2 Conséquences
2 LES APPROCHES DE SEPARATION AVANCEE DE PREOCCUPATIONS
2.1 La programmation orientée aspect
2.2 Les filtres de composition
2.3 La séparation multidimensionnelle des préoccupations
2.4 La programmation par rôles ou points de vue
2.5 La programmation adaptative
3 LES PRINCIPES DE BASE DE LA PROGRAMMATION ORIENTEE ASPECT
3.1 Le concept d’Aspect
3.2 Le concept de point de jonction
3.3 Le concept de coupe
3.4 Le concept de consigne (Advice)
3.4.1 Les consignes before
3.4.2 Les consignes after
3.4.3 Les consignes around
3.5 Le concept d’introduction
3.6 Le concept de tissage
3.6.1 Les règles de tissage
3.6.2 Le tisseur
3.6.3 Le tisseur statique (Tissage à la compilation)
3.6.4 Le tisseur dynamique (Tissage à l’exécution)
4 TRAVAUX SUR L’APPROCHE ORIENTEE ASPECT
5 CONCLUSION
CHAPITRE 2 : ASPECTJ & JBOSS AOP & CAESARJ
1 ASPECTJ
1.1 Le concept d’aspect
1.2 Le concept de point de jonction
1.3 Le concept de coupe
1.4 Le concept de consigne (Advice)
1.5 Le concept d’introduction
1.6 Le concept de tissage
2 JBOSS AOP
2.1 Le concept d’aspect
2.2 Le concept de point de jonction
2.3 Le concept de coupe
2.4 Le concept de consigne (Advice)
2.4.1 Les intercepteurs
2.5 Le concept d’introduction
2.6 Le concept de tissage
3 CAESARJ
3.1 Le concept des classes virtuelles
3.1.1 Le concept d’héritage implicite
3.1.2 Le concept de polymorphisme des familles
3.2 Le composant CaesarJ
3.2.1 L’interface de collaboration
3.2.2 CaesarJ implémentation
3.2.3 Binding et wrappers
3.2.4 Weavelets
3.2.5 Déploiement d’aspect
3.3 Le concept de tissage
4 BILAN
5 CONCLUSION
CHAPITRE 3 : RÉALISATION DES PATRONS DE CONCEPTION AVEC L’APPROCHE ORIENTÉE ASPECT
1 LES PATRONS DE CONCEPTION DU GANG OF FOUR (GOF)
1.1. Présentation des patrons de conception du GoF
1.1.1 Origine et histoire
1.1.2 Qu’est-ce qu’un patron de conception
1.1.3 Les patrons de conception du Gang of four
1.2 Application et limites des patrons de conception par objets
2 APPROCHE ADOPTEE DANS L’IMPLEMENTATION ORIENTEE ASPECT DES PATRONS
3 UTILISATION DES ASPECTS DANS L’IMPLEMENTATION DES PATRONS DE CONCEPTION DU GOF
3.1 La notion de rôle
3.2 Exemples de réalisation des patrons de conception avec les approches Aspect
3.2.1 Le patron de conception Observateur
3.2.2 Le patron de conception Mémento
3.2.3 Le patron de conception Adaptateur
3.2.4 Le patron de conception Fabrique abstraite
3.2.5 Le patron de conception Etat
3.2.6 Le patron de conception Façade
3.3 Application aux autres patrons du GoF
3.3.1 Groupe 1(Observateur / Médiateur /Chaine de responsabilités / Composite / Commande)
3.3.2 Groupe 2 (Singleton/ Prototype/ Mémento/ Itérateur /Poids-mouche)
3.3.3 Groupe 3 (Adaptateur/ Décorateur/ Stratégie/ Visiteur / Proxy)
3.3.4 Groupe 4 (Fabrique abstrait/ Fabrique méthode/ Méthode patron/ Constructeur/ Pont)
3.3.5 Groupe 5 (Etat / Interpréteur)
3.3.6 Groupe 6 (Façade)
4 CONCLUSION
CHAPITRE 4 : ETUDE COMPARATIVE
1 ETUDE DES METRIQUES
1.1 Questions sur la mesure des logiciels
1.1.1 Pourquoi Mesurer ?
1.1.2 Qu’est-ce qu’on peut mesurer dans un logiciel?
1.2 Métriques de l’orienté Objet
1.2.1 Métriques Structurelles
1.2.2 Incidence de l’aspect sur les métriques de l’orienté objet
1.3 Métriques de l’Approche Orientée Aspect
1.4 Métriques de performance
1.5 La qualité des logiciels
1.5.1 Les attributs internes de mesure
1.5.2 Model de qualité
2 ÉTUDE COMPARATIVE
2.1 Comparaison quantitative
2.1.1 Méthode de travail
2.1.2 Résultats obtenus
2.2 Interprétation des résultats
2.3 Comparaison qualitative
2.3.1 Méthode de travail
2.3.2 Résultats obtenus
2.4 Interprétations des résultats
2.4.1 Interprétation des résultats de l’analyse des implémentations
2.4.2 Interprétation des résultats des réponses au questionnaire
3 SYNTHESE GENERALE
4 VERS UN OUTIL GENERIQUE D’EXTRACTION DES METRIQUES
4.1 Pourquoi utiliser XML ?
4.2 Aspect conceptuel de l’approche
4.2.1 Construction des fichiers XML (du code source vers XML)
4.2.2 Tissage des fichiers XML
4.3 Extraction des métriques
5 CONCLUSION
CONCLUSION ET PERSPECTIVES
RÉFÉRENCES
ANNEXES
ANNEXE A
ANNEXE B
Télécharger le rapport complet
