Comparaison

Dans cette section, nous allons comparer les résultats de l’application de notre approche (variante de la section 5.8) sur le code source de la figure 5.8, avec ceux obtenus en appliquant les approches [Bre 03] et [Qu 07] sur le même exemple.

Dans l’approche présentée dans la section 3.5.4 [Bre 03], l’analyse des traces d’exécution du code source a été utilisée afin de détecter la transversalité à partir des modèles récurrents. Cependant, les approches qui détectent les préoccupations transversales à partir des traces d’exécution sont incomplètes, car les traces du programme contiennent seulement un ensemble particulier des entrées du programme. Une analyse dynamique complète est impossible pour exécuter tous les chemins possibles, ce qui diminue les aspects candidats.

Les auteurs de l’approche présentée dans la section 3.5.7 [Qu 07] proposent l’identification d’aspects en utilisant les traces d’exécution, ainsi que l’arbre d’appels de méthodes, afin de dépasser les limites de l’approche dans [Bre 03].

Afin de démonter la contribution de notre approche présentée dans la section 5.8 par rapport aux méthodes similaires, nous allons procéder par comparaison des résultats. La table 5.6 présente les aspects candidats identifiés à partir du code source de la figure 5.8, en utilisant l’approche [Qu 07] et l’approche [Bre 03].

Les caractères « → » « ← » « ∇ » et « ∆ » désignent respectivement les relations : before, after, Inside-first et Inside-last (présentées dans la section 3.5.4).

Tab. 5.6. Aspects candidats identifies par l’approche [Qu 07] et par l’approche [Bre 03] (extrait à partir de [Qu 07])

Résultats de [Qu 07] Résultats de [Bre 03]

G→E G→H C B C D K F K L G→E G→H C B C D

En comparant les résultats obtenus par notre approche (table 5.4) avec ceux obtenus par l’approche de [Qu 07] et l’approche de [Bre 03], nous obtiendrons ce qui suit :

 L’aspect candidat 1 de la table 5.6 n’a pas été identifié par notre approche.  L’aspect candidat 2 de la table 5.6 a été identifié et supprimé par notre approche

(détection de RIM), car la méthode 𝐺 et 𝐻 sont supposées appartenir à la même classe (Class3).

 Les aspects candidats 5 et 6 de la table 5.6 qui encapsulent la méthode 𝐾 ont été identifiés par notre approche dans la table 5.4 comme l’aspect 5, tandis que les aspects 3 et 4 de la table 5.6 qui encapsulent la méthode 𝐶 n’ont pas été détectés par notre approche (identifiés comme aspect dispersé et ensuite supprimé) du fait que les méthodes 𝐵, 𝐶 et 𝐷 sont supposées appartenir à seulement deux classes différentes.

 Le reste des aspects candidats de la table 5.4 n’ont pas pu être identifiés par les approches [Qu 07] et [Bre 03].

 Les points de coupure des aspects candidats possibles de type de relation Inside- first (ainsi que Inside-last) sont difficiles de les placer dans la refactorisation des aspects.

 Les approches [Qu 07] et [Bre 03] n’identifient pas les aspects à partir des fragments conditionnels, pourtant ces aspects reflètent bien des tâches fortement liées.

5.9 Conclusion

Au cours de ce chapitre, nous avons présenté le principe de notre approche proposée, qui vise l’identification d’aspects au niveau conceptuel, en utilisant les diagrammes de séquence. En outre, afin de montrer l’applicabilité de notre approche dans un niveau d’abstraction plus bas et dans un contexte différent, nous avons présenté une autre variante de l’approche proposée, visant l’identification d’aspects au niveau implémentation d’une manière statique.

En comparant notre approche (les deux variantes) avec les approches existantes, en utilisant les mêmes critères de comparaison utilisés dans les tables 3.1 et 4.2, nous constatons le suivant :

 En se basant sur : répétition ;

 Entrée : modèles d’interactions entre les objets (invocations de méthodes) ;  Sortie : successions d’invocations de méthodes ;

 Niveau d’abstraction : modèles d’interactions ;

 Symptômes détectés : dispersion et enchevêtrement ;  Transversalité est : la transversalité se produit lorsque :

o les méthodes qui composent un RIM appartiennent au moins à deux classes différentes ;

o une condition (attribut ou méthode) et la méthode invoquée lors de la vérification de cette condition, appartiennent à deux différentes classes ;

o une méthode est invoquée plusieurs fois dans au moins deux classes différentes de sa classe où elle est définie.

 Intervention humaine : l’utilisateur peut intervenir pour choisir des aspects parmi l’ensemble des aspects candidats obtenus par notre approche, selon les résultats des métriques. Or, ce choix n’est pas nécessaire, du fait que tous les aspects obtenus doivent être refactorisés, afin d’améliorer la modularité du système logiciel, pour les raisons suivantes :

o l’existence de chaque aspect obtenu par notre approche rend au moins deux classes liées ;

o les aspects enchevêtrés relient deux classes ;

o les aspects enchevêtrés de type before, détectés à partir des conditions, encapsulent des contraintes d’intégrité référentielle qui doivent être respectées ; o Chaque méthode du code advice des aspects dispersés est invoquée dans, au moins, deux classes différentes de la classe qui la définit, et les modifications

dans la manière d’utiliser cette méthode peuvent être nombreuses, coûteuses et sujettes à erreur.

Nous avons concrétisé notre approche dans des étapes claires et précises, afin de faciliter son implémentation, qui sera présentée dans le chapitre suivant.

C

HAPITRE

6

I

MPLÉMENTATION

« To me, ideas are worth nothing unless executed. They are just a multiplier. Execution is worth millions.» (Steve Jobs)

6.1 Introduction

Afin de valider notre approche proposée, nous avons développé un outil qui l’implémente. Deux études de cas sont choisies : système de gestion de bibliothèque (Library Management System) et système de péage des autoroutes portugaises (Portuguese Highways Toll System). Dans ce chapitre, nous présentons notre outil, ainsi que les résultats de son application sur ces études de cas.

6.2 Schéma de l’outil

Dans le but de faciliter l’implémentation, nous utilisons le format XML, afin d’exploiter les transmissions de messages des diagrammes de séquence. A partir de la figure 6.1, les étapes d’obtention des aspects candidats par notre outil sont les suivantes :

1. A partir des fichiers XML (générés à partir des diagrammes de séquence), toutes les invocations de méthodes sont extraites, en spécifiant pour chaque méthode le contexte d’appel (sa classe et la classe qui l’invoque) ;

2. A partir de ces invocations, la matrice 𝑀𝑀𝑇𝑂 est construite (et éventuellement 𝑀𝑀𝑇𝑂′), ainsi que le tableau 𝑇𝐶𝑙𝑎𝑠𝑠 ;

3. Identification, d’une part, des aspects enchevêtrés et leurs métriques, à partir de la matrice 𝑀𝑀𝑇𝑂 (et 𝑀𝑀𝑇𝑂′) ; d’autre part, des aspects dispersés et leurs métriques à partir du tableau 𝑇𝐶𝑙𝑎𝑠𝑠.

Fig. 6.1. Schéma de l’outil d’identification d’aspects

6.3 Etude de cas : Système de gestion de bibliothèque