Soutenance mémoire
Analyse d’impact
L’analyse d’impact de changement vient soutenir la maintenance afin de la rendre moins ardue. Cette analyse a pour mission de prédire quelles parties du code seront touchées suite à une modification [8]. Bohner and Arnold dans [19] la définissent comme étant l’identification des conséquences d’un changement, ou l’estimation de qu’est ce qui doit être modifié afin que ce changement se fasse. L’analyse de l’impact est d’autant plus importante car elle permet d’estimer le coût de développement d’un projet, d’aider à la gestion des changements, et permet de garder le système stable [19]. L’analyse de l’impact peut se faire après l’introduction du changement; on parle alors de postanalyse. Dans ce cas-ci, le changement a déjà été effectué; il en résultera donc deux versions du même système qu’on pourra comparer afin de voir quelles sont les conséquences des changements apportés. Ce type d’analyse est utile pour les tests de régression [5], mais aussi pour avoir les traces des effets de propagation (ripple effect), et prévoir les cas de test [27]. L’analyse d’ impact peut également se faire avant l’ introduction du changement. Il s’agit là de l’analyse prédictive [5]. Les impacts de changement seront mis en évidence avant que le changement ne soit effectué. Cela aura pour avantage d’être plus sure, de permettre aux développeurs de pouvoir par exemple choisir une solution parmi d’autres, estimer si oui ou non le changement vaut la peine d’être effectué, ou encore ils auront une meilleure idée des efforts nécessaires à la mise en oeuvre du changement ainsi que des coûts qui seront engendrés [8]. Deux techniques principales sont utilisées pour effectuer l’analyse d’ impact: ~ Les techniques d’analyse statiques..
Ces techniques analysent la syntaxe et les dépendances sémantiques du programme. Elles se basent pour la plupart du temps sur des représentations du système telles que les graphes d’appel, les graphes de contrôle de flot, etc. Le problème de ces techniques statiques est que le volume de données à analyser peut être énorme, rendant ainsi l’ analyse d’ impact difficile à réaliser.
~ Les techniques d’analyse dynamiques: Elles se basent sur les informations recueillies durant l’exécution du programme et présentent l’avantage d’être plus pratiques et plus précises.
Comme indiqué dans [28], ces deux techniques présentent malgré tout le même problème, à savoir donner des résultats erronés. En effet, il se peut que des parties non impactées fassent parties de l’ensemble des parties impactées. On parle alors de « faux-positifs » (false positive). Également, l’ensemble obtenu peut en omettre certaines; on parle alors de «faux négatifs » (false negative). Une analyse d’impact de changement se base sur une bonne compréhension du programme. En effet, il est nécessaire de comprendre les relations entre les différentes entités du système pour être en mesure de prédire les effets. Au niveau de la POO, les différents modules, à savoir les classes, sont liées entre elles. Grâce à ces dépendances, il est possible de retracer les impacts dus à un changement apporté dans le système. Ce changement peut concerner la suppression d’une classe. La modification d’une méthode, la suppression d’un attribut, etc. De nombreuses techniques [8][29] se basent justement sur les graphes de dépendances pour effectuer leur analyse d’impact. Avec l’avènement de la PO A, une analyse de l’impact des changements dans ces programmes sera nécessaire. La POA introduisant de nouvelles dépendances, la compréhension du système est un peu plus difficile quand on sait que les aspects sont invisibles à la partie orientée objet et que l’exécution du programme peut être complètement modifiée après le tissage. Les approches d’analyse de l’ impact présentement utilisées, en particulier les techniques d’ analyse d’ impact de programmes orientés objet, ne sont pas applicables directement sur des programmes orientés aspect. Il est donc nécessaire de développer de nouvelles techniques tenant compte des spécificités du paradigme aspect.
Retrait d’une interface: Lorsqu’on retire une interface à une classe, on n’est pas obligé de supprimer les méthodes implémentées. Si tel est le cas, on pourrait avoir des impacts sur les points de jointure correspondant à ces méthodes. Un point de jointure impacté entraine la modification ou la suppression du pointcut auquel il appartient. Et enfin, l’advice lié au pointcut en question sera soit modifié soit supprimé. Nous avons donc la règle suivante: Cir -> [Mr + JPr + PCrllPCrn + ADVrllADVrn] Après retrait d’une interface à une classe (Cir), il peut y avoir éventuellement (m le retrait de méthodes (Mr) ainsi que les points de jointure liées à ces méthodes (JPr). Il s’en suivra la suppression des pointcuts (PCr) ou (II) leur modification (PCm), puis la suppression ou la modification des advices qui pointent sur les pointcuts impactés (ADVr » ADVm). Dans cet exemple, on peut voir l’ utilisation des crochets « [] » qui indiquent l’ incertitude de l’ impact, ainsi que l’ utilisation des deux barres verticales « » » qui indiquent qu’il y aura soit une modification du pointcut (PCm) soit un retrait d’un pointcut (PCr). Aussi, soit un advice sera modifié (ADVm), soit un advice sera supprimé (ADVr).
ÉVALUATION EMPIRIQUE
Après l’élaboration des règles du modèle, nous allons faire des expérimentations visant chacune des règles. Ces expérimentations vont d’ abord porter sur des impacts objet vers aspect, suivies des impacts aspect vers aspect et enfin des impacts aspect vers objet. Le but de ces tests est de pouvoir vérifier la capacité des règles à pouvoir prédire de façon fiable les impacts suite à une modification. De plus, ces expérimentations permettront de pouvoir apporter des corrections aux éventuelles règles ayant besoin d’ajustement. Enfin, nous seront en mesure de déceler les limites du modèle. Ces expérimentations porteront sur chacune des règles. Ainsi, pour une règle donnée, nous allons créer via un petit programme le contexte de celle-ci. Suite à une modification, nous allons donc pouvoir vérifier si les éléments énoncés dans la règle répondent correctement aux résultats que nous allons constater effectivement. Certaines règles vont nécessiter plus d’un exemple. En effet, pour une modification donnée, il n’est pas toujours évident que les situations d’impact prévues par la règle soient toutes rassemblées en même temps. Nous allons donc présenter différents exemples pour une même règle d’impact afin de passer en revue toutes les situations possibles de cette règle. Par exemple, pour la suppression d’une classe, la règle d’impact indique que les impacts dans le code aspect vont concerner les points de jointure, les pointcuts, les advices, les déclarations intertypes et enfin des classes aspects héritant de la classe supprimée (Cr -> JPr + [PCr] + [ADVrll ADVm] + I-TYr + ASm(H)). Cependant, un aspect peut avoir des pointcuts, des advices, sans avoir de déclarations inter-types, ou encore les aspects n’hériteront pas forcement de la classe objet en question.
La programmation orientée aspect prend de plus en plus en plus d’ampleur. Il est donc nécessaire de se pencher sur la maintenance des logiciels élaborés sous ce paradigme de programmation, plus particulièrement sur l’analyse d’ impacts de changement. En effet, les nouvelles relations entre classes objet et aspects de ce type de programmation font ressortir un autre niveau de complexité de cette analyse d’ impact. Quatre sortes de relations d’ impact émanent de ce type de programme: les impacts objet – objet, les impacts objet – aspect, les impacts aspect – aspect et les impacts aspect – objet. Un premier modèle, le modèle d’impact du changement pour Java (MICJ), avait déjà été développé dans [5] afin de pouvoir effectuer une analyse d’impact de changements pour ce qui concerne les impacts objet – objet. Le modèle que nous proposons se veut une suite complémentaire du MICJ, mais adaptée à la programmation orientée aspect. Notre modèle permet de dire, pour chacune des relations d’ impact objet – aspect, aspect – aspect et aspect – objet, quelles parties du code seront affectées suite à un changement. Notre modèle d’analyse d’impact a pour objectif de prendre en compte l’analyse d’impact en cascade. Ainsi, les programmeurs seront en mesure d’avoir une meilleure idée de l’effet de propagation qu’auront tous les changements qu’ils apporteront à un programme.
Cela leur permettra aussi de prendre une décision quant à l’application ou non de cette modification. Ces règles d’impact concernent les changements comme la suppression d’une classe, la modification des paramètres d’une méthode, la suppression ou la modification d’un pointcut, ou encore la suppression de déclarations intertypes. Afin de montrer l’efficacité de notre modèle, des expérimentations ont été faites pour chacune de nos règles d’impact. Les résultats obtenus montrent que notre modèle est assez efficace quant à la prédiction d’impacts suite à toute modification apportée au code, que ce soit dans la partie objet ou dans la partie aspect. Même si certaines règles indiquent des impacts incertains, elles permettront tout de même au programmeur d’avoir une bonne idée des modifications à faire pour que le système demeure cohérent.
|
Table des matières
SOMMAIRE
ABSTRACT
REMERCIEMENTS
TABLE DES MATIÈRES
LISTE DES FIGURES
LISTE DES TABLEAUX
CHAPITRE 1: ANALYSE DE L’IMPACT DES PROGRAMMES ORIENTÉS ASPECT
l. PROBÉLMA TIQUE, OBJETCIFS ET DÉMARCHE
Il. Introduction
III. Problématique
Démarche
CHAPITRE 2: LA PROGRAMMATION ORIENTÉE ASPECT
1. Présentation
1. Limites de la programmation orientée objet
2. Les préoccupations transversales
3. But de la programmation orientée aspect
Il. Mécanisme de la programmation orientée aspect
Ill. Éléments de la programmation orientée aspect
1. AspectJ
2. Les aspects
3. Les points de jointure (pointcuts)
4. Les coupes (pointcuts)
5. Les advices
6. Les déclarations inter-types
7. L’ héritage dans la programmation orientée aspect
8. Les déclarations
CHAPITRE 3: ANALYSE DE L’IMPACT DES PROGRAMMES ORIENTÉS ASPECT
l. Maintenance
Il. Analyse d’ impact
III. Approches
CHAPITRE 4: MODÈLE D’IMPACT
l. Objectifs
II. MICJ
\. Modèle de Chammun
2. Relations du MICJ
3. Changements structuraux et non-structuraux
a) Les changements structuraux:
b) Les changements non structuraux:
4. Impacts certains ou incertains
5. Les cibles
6. Analyse en cascade
7. Règles d’impact du MICl
III. Extension du MICJ à la programmation orientée aspect
1. Changements structuraux et non-structuraux
2. Notion de certitude et d’incertitude
3. Analyse en cascade
4. Les règles d’impact
4.1. Impacts objet vers aspect
4.1.1. Exemples de règles :
4.2. Impact aspect vers aspect:
4.2.1 . Exemples de règles:
4.3. Impact aspect vers objet:
CHAPITRE 5: ÉVALUATION EMPIRIQUE
1. Introduction
Il. Protocole d’évaluation
III. Mesures d’évaluation
a. La précision (precision)
b. Le rappel (recall)
IV. Exemples d’expérimentations
\. Impacts objet vers aspect
1.1. Suppression d’une classe
1.2. Modification des paramètres d’une méthode
1.3. Changement du type de retour d’une méthode de « void» à type (primitif ou objet)
1.4. Suppression d’un lancement d’exception
2. Impacts aspect vers aspect
2.1. Modification du nom d’ un aspect
2.2. Passage d’aspect abstrait à non abstrait
v. Suppression d’un pointcut
3. Suppression d’un attribut
1. Ajout, modification ou suppression des paramètres d’une méthode
2.3. Impacts aspect vers objet.
2.4. Exemple 1
2.5. Exemple 2
3.1. Résultats et discussion
3.2. Impacts objet – aspect
2. Impacts aspect – aspect
3. Impacts aspect – objet
CHAPITRE 6: CONCLUSION
ANNEXE 1 LISTE DES CHANGEMENTS
ANNEXE 2 LISTE DES RÈGLES D’IMPACT
BIBLIOGRPHIE
Télécharger le rapport complet
