Interprétations des résultats

2.4.1 Interprétation des résultats de l’analyse des implémentations

L’analyse des implémentations, peut donner une idée sur la démarche suivie par chaque approche, ainsi, elle peut être utilisée pour déduire des lignes directives pour chacune elle.

 Pour AspectJ

Les programmes avec AspectJ sont construits généralement comme suit :

 Tout d'abord, il faut mettre la partie la plus abstraite de l’application (dans nos exemples, ces parties sont les rôles attribués par les patrons de conception) dans les aspects abstraits. Les méthodes de cette partie sont souvent abstraites.

On peut déclarer aussi des interfaces internes suivant les rôles des patrons, ou même des points de coupures abstraits afin de les identifier plus tard.

 Ensuite, utiliser des aspects concrets qui héritent des aspects abstraits et qui implémentent les différents méthodes et points de coupure déclarés abstraits dans la première partie.

Afin de lier ce code avec les classes de base, on peut rajouter des méthodes, des points de coupure, des advices, des déclarations inter-type selon le besoin.

 Pour JBoss AOP

JBoss AOP, suit la même démarche que celle d’AspectJ, en revanche et puisque JBoss AOP n’étend pas le langage Java, on se trouve obligé d’utiliser les éléments de ce langage, surtout en ce qui concerne les partie réutilisables et qui se résument en interfaces et en classes abstraites. En générale un programme avec JBoss AOP se construit comme suit :

 Tout d'abord, il faut mettre la partie la plus abstraite de l’application sous forme de signatures dans des interfaces (dans nos exemples, ces parties sont les rôles attribués par les patrons de conception).

 Ensuite, on implémente les méthodes déclarées dans les interfaces dans des classes Mix-In.

 On crée les relations entre les classes de base, et les différentes préoccupations implémentées dans les classes Mix-in dans des fichiers XML (ou des annotations). On ajoute aussi les points de coupure, les déclarations des classes aspect ainsi que l’identification des codes advice.

 Pour CaesarJ

La structure de composant CaesarJ fournit un guide précis de l'endroit où chaque morceau de code doit être placé et propose le procédé suivant:

 Tout d'abord, il faut mettre la partie la plus abstraite de l’application (dans nos exemples, ces parties sont les rôles attribués par les patrons de conception) dans l’interface de collaboration. Cette partie ne doit en aucun cas être reliée a une application ou un type de donné spécifique.

 Ensuite, placer tout le code qui ne dépend pas des types spécifiques dans la partie implémentation CaesarJ. A la différence de l’interface de collaboration les méthodes des classes de cette partie peuvent être implémentée et reliées à un grand nombre d’applications.

 Placer le code spécifique à une application dans la partie Binding, et établir les liaisons entre ce code et les classes de base en utilisant les points de coupure ou les wraps.

 Créer le composant complet à travers une classe vide de CaesarJ (i.e. weavelet) qui hérite des deux parties implémentation et Binding.

2.4.2 Interprétation des résultats des réponses au questionnaire

Nous allons dans ce qui suit analyser les différents résultats des réponses au questionnaire.

 Compréhension de l'approche

Suivant les résultats obtenus dans le tableau précédent (Tableau 13), AspectJ était le plus facile à comprendre. Contre notre attente, qui est allée plutôt vers JBoss AOP puisque il utilise du Java pur et il n’introduit pas de nouveau mots clé, les réponses des étudiants montrent que les nouveaux termes d’AspectJ sont faciles à comprendre et à maitriser. CaesarJ est un peu plus difficile à comprendre par rapport à AspectJ, surtout au début, comme le dit un étudiant en laissant un commentaire sur la première question « j’ai

trouvé la compréhension de CaesarJ plus difficile qu’AspectJ, mais une fois que les concepts de base de CaesarJ sont bien compris il peut être très utile ». La difficulté de JBoss AOP réside dans les relations entre les classes

java et les fichiers XML.

La majorité des étudiants ont trouvé des difficultés pour trouver des documents sur JBoss AOP et CaesarJ, comparé à AspectJ, cela est un facteur important et il peut même expliquer la mauvaise note obtenue par ces deux approches dans cette première catégorie.

 Les concepts de l'approche

D’après les réponses des étudiants, les nouveaux concepts d’AspectJ sont plus faciles à comprendre et à utiliser. Pour CaesarJ ils trouvent que pour le maitriser il faut d’abord comprendre ses composants et les relations entre leurs classes internes. Comme suggère un étudiant « vous devez seulement

comprendre l’objectif de chaque partie de composant CaesarJ »

Concernant l’adaptabilité des nouveaux concepts de ces approches avec les patrons de conceptions, AspectJ et CaesarJ semblent avoir la même appréciation et il sont bien vu par rapport à JBoss AOP. Voici deux réponses de deux étudiants sur la cinquième question : « Oui, puisque AspectJ gère la

séparation des préoccupations d’une façon très efficace » et « «Absolument, CaesarJ est très utile, il simplifie les patrons de conception, et rend le patron bien organisé dans les différentes parties du composant CaesarJ »

Concernant la possibilité de créer des éléments réutilisables, les aspects abstraits d’AspectJ semblent insuffisants. Par contre CaesarJ offre plusieurs niveaux de réutilisation (i.e. Interface de collaboration, implémentation). Les éléments de réutilisation dans JBoss AOP sont ceux de java ce qui explique

96

le mauvais résultat pour cette approche dans la note et les commentaires obtenus.

 IDE et outil support

L’IDE utilisé été Eclipse qui été adéquat avec les trois approches, les extensions plug-in pour AspectJ et CaesarJ sont faciles. Par contre JBoss AOP ne possède pas de plug-in récent, ce qui nécessite de faire quelques modification dans la class path avant l’utilisation de ce dernier.

L’éditeur et le programme de visualisation avec AspectJ sont plus faciles à utiliser et très sophistiqués, les relations entre les aspects et le reste du code sont très claires. Cela été très apprécié par les étudiants qui le trouvent mature et complet. Pour le plug-in CaesarJ, les étudiants ne le trouvent pas complet comme celui d’AspectJ, mais il est facile à utiliser aussi. Peu d’entre eux ont signalé quelques problèmes comme cet étudiant qui dit « «Il

y a quelques problèmes lors du refactoring des projets CaesarJ »

 Les patrons de conception

Les nouveaux concepts introduits avec les trois approches simplifient la réalisation des différents patrons de conception, et cela été bien vu dans différents travaux comme [Hannemann, 2002] [Garcia, 2006] [Hachani, 2005].

Ces concepts sont capables de réduire radicalement l’implémentation de quelques patrons, cela peut être le cas pour AspectJ où l’utilisation de son mécanisme d’introduction réduit l’implémentation des deux patrons Adaptateur et Visiteur.

Nous avons noté quelques observations sur ces implémentations :

 Plusieurs castings dans le code final des patrons réalisés avec JBoss AOP, cela réduit la compréhension générale des implémentations.

 Les solutions proposées en AspectJ réduisent de manière significative le nombre de participants impliqués dans un patron. En effet, le mécanisme d’introduction offert par AspectJ nécessite de définir un seul aspect, alors qu’on doit définir trois différents éléments avec le mécanisme mix-in de JBoss AOP, qui sont l’interface contenant les éléments à introduire, la classe implémentant ces derniers, et enfin le fichier XML qui assure la liaison.

 le déploiement dynamique offert par JBoss AOP et CaesarJ, donne plus d’avantages pour certains patrons de conceptions. A titre d’exemple, le patron de conception Décorateur a bénéficié de cette façon de tisser pour ajouter ou supprimer des fonctionnalités supplémentaires dynamiquement.

 L’analyse de résultats de patron de conception Observateur montre que l’utilisation des aspects abstraits comme les seuls éléments de réutilisation n’est pas toujours suffisante. En effet, la gestion des différents observateurs dans l’aspect abstrait n’est pas toujours la même dans toutes les applications et nécessite d’être changée pour s’adapter à une application spécifique.

 Les implémentations CaesarJ des deux patrons : Fabrication abstraite et Pont sont essentiellement basées sur les concepts de CaesarJ, ce qui place le code entier de ces deux patrons dans le composant CaesarJ y compris les classes de base.