Déploiement d’aspect

Après la définition de Weavelet et que les deux facettes fournie et attendue sont composées, la Weavelet doit encore être instanciée et déployée afin d'activer ses points de coupure et ses advices. En effet, et contrairement à AspectJ, les aspects en CaesarJ peuvent être instanciés explicitement, cela correspond à l'instanciation de plusieurs Weavelets. De cette façon, il est possible de créer des instances de plusieurs aspects dans la même application et de les gérer comme des objets ayant des responsabilités particulières.

36

En CaesarJ, le déploiement d'aspect peut être fait à la fois statiquement et dynamiquement, cela constitue une autre différence par rapport à AspectJ, où ce dernier ne supporte que le déploiement d’aspect statique.

En CaesarJ, le déploiement d’aspect statique est obtenu par le modificateur

deployed, ce qui permet le déploiement d’aspect en moment de la compilation. Le

déploiement dynamique peut être soit le déploiement local ou à base de déploiement fil. Pour se faire, un aspect doit d'abord être instancié par l'instanciation d'une Weavelet puis utiliser l'instruction de deploy pour préciser la portée de cet aspect.

Dans le déploiement local, le mode d'activation d'un aspect est défini par les deux des mots-clés deploy et undeploy, qui active et désactive l'aspect, respectivement.

Le mode d'activation dans le déploiement à base fil est définit par un bloc

deploy, où l’aspect est déployé suivant un contrôle de flux à l'intérieur du bloc et

qui n'a aucune influence sur les exécutions simultanées.

La figure 10 illustre la structure générale du composant CaesarJ, ainsi que la relation entre ses modules et les classes de base d’une application particulière.

Figure 10 Structure générale du composant CaesarJ

Il est intéressant de noter que la présence de toutes les parties n’est pas toujours nécessaire, à part la partie binding car c’est elle qui assure la liaison entre la partie la plus concrète de l'application et la plus abstraite qui est l’interface de collaboration.

3.3 Le concept de tissage

Le tissage en CaesarJ, est comme la plupart des approches supportant l’activation dynamique des aspects, tels que JAC [Pawlak, 2001], JBoss AOP [JBoss AOP, Web] et AspectWerkz [AspectWerkz, Web], 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.

Il y a deux possibilités pour la préparation : soit d'insérer des crochets qui se joignent à tous les points d'une classe chargée ou de limiter la zone d’activation à un ensemble fixe de points de jointure connus. Alors que la première option provoque une surcharge significative sur les performances, la seconde option nécessite une connaissance initiale sur les aspects, qui peuvent êtres activés [Aracic, 2006].

4 Bilan

Même si l’objectif des trois approches est le même, la façon qu’ils suivent pour l’atteindre diffère d’une approche à l’autre.

AspectJ et JBoss AOP ont montré une certaine ressemblance dans la mise en œuvre des concepts de base de la programmation orientée aspect, avec une légère différence au niveau de la syntaxe et le principe d’extension du langage Java.

CaesarJ, même s’il utilise les points de coupure et les advices d’AspectJ, présente une démarche totalement différente des autres. Il propose de nouvelles notions et concepts et améliore d’autres inspirés des anciens paradigmes tels que le paradigme objet.

Le tableau suivant résume quelques notions présentées auparavant :

Tableau 3 Utilisation des concepts aspect par les trois approches

AspectJ JBoss AOP CaesarJ

Langage de base Java Java Java

Extension du langage de base Oui1 Non Oui Utilisation des points de coupure Oui Oui Oui Composant comportant les

préoccupations

Aspect1 Classe java Cclass

Modules réutilisables Aspect abstrait Ceux de java Interface de collaboration et CaesarJ implémentation Mécanisme d’introduction Déclaration

Inter-type

Mécanisme Mix-in

Wrappers

Moments du tissage Compilation Chargement2 Compilation Chargement Exécution Compilation Chargement

Après avoir présenté les différents concepts d’AspectJ, JBoss AOP et CaesarJ nous pouvons montrer la méthode suivie par chacun d’entre eux afin de définir et exécuter les différentes préoccupations.

Le schéma suivant illustre d’une façon générale la procédure de travail des trois approches. Noter que suivant l’IDE supporté, le tissage peut prendre place dans

1 _{AspectJ 5 permet de travailler avec le langage Java pur.} 2

38

différents moment : au moment de la compilation, avant/après le chargement de classes ou au moment de l’exécution (figure 11).

Figure 11 Procédure générale de travail des trois approches [Debboub, 2013]

5 Conclusion

Dans ce chapitre nous avons présenté les concepts, et les méthodes de travail suivis par les trois approches : AspectJ, JBoss AOP et CaesarJ, visant à garantir une meilleure séparation des préoccupations.

AspectJ, vu qu’il présente le premier projet émergé de la programmation orientée aspect, réalise avec une façon concrète touts ses concepts et notions comme : les aspects, les points de coupure et jointure, le mécanisme d’introduction et le tissage.

A la différence d’AspectJ, JBoss AOP n’étend pas le langage Java et réalise les notions de la programmation orientée aspect, en utilisant des fichiers XML ou des annotations. Cependant, et même si la syntaxe de JBoss AOP et le choix de rester en Java pur peuvent le distinguer d’AspectJ, on trouve beaucoup de ressemblances entre les deux approches.

CaesarJ, résout le problème de séparation des préoccupations en utilisant des concepts et mécanismes qui lui sont propre. Il est parfois considéré comme une approche qui unifie la programmation orientée aspect et celle des composants.

La compréhension et la mise en œuvre des différents concepts et mécanismes présentés dans ce chapitre peuvent être cernées plus facilement en lisant le chapitre suivant, qui discute sur de la réalisation des patrons de conception de Gang of four [Gamma, 1995] avec les trois approches.

CHAPITRE 3 :

REALISATION