Vers une Approche d’Aide à la Décision pour la Maintenance ... · Elle estime les éléments au...
Transcript of Vers une Approche d’Aide à la Décision pour la Maintenance ... · Elle estime les éléments au...
-
2010/2011 www.univ-oran.dz [email protected]
MEMOIRE
Présenté par
Mr DINEDANE Mohammed Zoheir
Pour obtenir
LE DIPLOME DE MAGISTER
Spécialité : Informatique Option : Diagnostic, Aide à la Décision, et Interaction Homme machine
Intitulé :
Membres de jury : M r K. BOUAMRANE Maître de Conférences, Université d’Oran, Algérie
(Président)
M r B. ATMANI Maître de Conférences, Université d’Oran, Algérie (Examinateur)
M r M. SNOUCI Maître de Conférences, Université d’Oran, Algérie (Examinateur) Mr M.K. ABDI Maître de Conférences, Université d’Oran, Algérie
(Rapporteur)
Vers une Approche d’Aide à la Décision pour la Maintenance des Systèmes à Objets
-
Dédicaces
Je dédie ce travail A :
Mon père,
Qui m’a toujours poussé et motivé dans mes études, sans lui je ne serai pas devenue ce que je suis maintenant.
Ma chère mère,
Parce qu'il est impossible de trouver les mots à la hauteur de l'amour et le soutien que vous m’avez toujours témoigné tout au long de ma vie et ma scolarité.
Ma très chère sœur Rabia,
Mes frères Hafid, Toufik et Omar,
Leurs commentaires et leurs conseils avisés ont certainement contribué à l’aboutissement de ce travail.
Mes meilleurs amis Driss, Brahim,
A toute la famille DINEDANE et RAHAL.
-
Remerciements
Toi mon Dieu Tout Puissant,
Au seuil de ce travail, nous avons l'obligation morale d'exprimer nos sentiments de gratitude et de profonds remerciements à tous ceux qui nous ont apporté leur aide tout au long de nos études et pendant la réalisation de ce travail, notamment :
Je remercie mon encadreur Mr Mustapha Kamel ABDI, Maitre de conférences à l’Université d’Oran, pour avoir accepté de diriger ce travail. Son soutien moral, ses orientations, ses précieux conseils, sa patience et la confiance qu'il m'a accordés, m'ont accompagné tout au long de cette étude. Je le remercie aussi pour ses qualités humaines et de m’avoir toujours encouragé à aller de l’avant.
J’adresse mes vifs remerciements au président de jury Mr Karim BOUAMRANE, Maitre de conférences à l’Université d’Oran, pour l’honneur qu’il me fait de présider ce jury, je garde bien plus qu’une satisfaction exclusivement scientifique, qu’il reçoive l’expression de mon profond respect.
Je suis très honoré que Mr Baghdâd ATMANI, Maitre de conférences à l’Université d’Oran, ait accepté de juger mon travail.
Mes remerciements s’adressent au même titre à Mr Mohamed SNOUCI, Maitre de conférences à l’Université d’Oran, d’avoir accepté d’être membre de mon jury.
Un grand merci aux enseignants de la PG : DADIHM spécialement Mme HAMDADOU, et Mme TAGHZOUTE.
A Mes collègues de la promotion spécialement DAHANE, AMJAD, et SEDDIK.
Je n’oublie pas mes collègues du travail a GNL4Z et GNL1Z / SONATRACH pour leurs sacrifices et encouragement.
Enfin, j'adresse mes plus sincères remerciements à mes très chers frères, qui m'ont toujours soutenu et encouragé au cours de la réalisation de ce mémoire.
Merci
-
TABLE DES MATIERES
Table des matières Introduction générale ……………………………………………………………………………………
Contexte ………………………………………………………………………………………………...
Problématique et contribution ………………………………………………………………………......
Organisation du mémoire…………………………………………………………………………..........
I. Analyse d’impact de changement……………………………………………………………………. 1. maintenance des applications………………………………………………………………………..
1.1 Types de maintenance……………………………………………………………...................
1.1.1. Activités de maintenance…………………………………………………………….
1.1.2. Problèmes de maintenance…………………………………………………………..
1.1.3. Techniques de maintenance …………………………………………………………
2. Analyse d’impact de changement………………………………………………………………..
2.1. Analyse d’impact…………………………………………………………………………….
2.1.1. Avantages d’analyse d’impact……………………………………………………….
2.1.2. Travaux connexes sur l’analyse d’impact…………………………………………….
2.1.3. Conclusion ……………………………………………………………………………
2.2. Métriques OO………………………………………………………………………………..
2.2.1. Quelques métriques OO……………………………………………………………..
2.2.1.1. Métriques d’héritage ………………………………………………………….
2.2.1.2. Métriques de couplage ………………………………………………………..
2.2.1.3. Métriques de cohésion…………………………………………………………
2.2.1.4. Métriques de complexité………………………………………………………
2.2.2. Les métriques OO et l’analyse d’impact de changement……………………………..
2.2.3. Le couplage et l’analyse d’impact……………………………………………………..
2.2.4. Conclusion ……………………………………………………………………………..
II. Méthodologie Multicritère d’Aide à la Décision………………………………………………….. 1. Introduction…………………………………………………………………………………..........
2. Aide à la décision……………………………………………………………………………….
2.1. Définition…………………………………………………………………………………...
2.2. Le processus de décision……………………………………………………………………
3. le paradigme multicritère……………………………………………………………………….....
3.1. Terminologie……………………………………………………………………………….
3.1.1. Actions potentielles…………………………………………………………………...
3.1.2. Critères……………………………………………………………….........................
3.1.3. Surclassement ………………………………………………………………………..
1
1
2
3
5
5
5
6
6
8
9
10
11
12
14
15
16
16
16
17
18
18
20
21
22
22
23
23
23
25
25
25
26
26
-
TABLE DES MATIERES
3.1.4. Préférences……………………………………………………………………………..
3.1.5. Relations de préférences particulières…………………………………………………
3.1.6. Pondération ……………………………………………………………………………
3.1.7. Agrégation …………………………………………………………………………….
3.1.8. Tableau des préférences ……………………………………………………………….
3.2. démarche générale d’une méthode multicritère …………………………………………….
3.3. Classification des différentes méthodes d’analyse multicritère ……………………………
3.3.1. Selon la méthode d’agrégation utilisée ………………………………………………..
3.3.2. Selon la problématique traitée ………………………………………………………….
3.4. La famille ELECTRE ………………………………………………………………………..
3.4.1. ELECTREI …………………………………………………………………………......
3.4.2. ELECTREII …………………………………………………………………………….
3.4.3. ELECTREIII …………………………………………………………………………...
3.4.4. ELECTRE IV ………………………………………………………………………......
3.4.5. ELECTRE TRI ………………………………………………………………………….
3.4.6. ELECTRE IS ……………………………………………………………………….......
4. Conclusion …………………………………………………………………………………...........
III. Approche décisionnelle proposée ……………………………………………………..................... 1. Introduction………………………………………………………………………………………..
2. Approche proposée………………………………………………………………………………
2.1. Extraction de métriques……………………………………………………………...........
2.1.1 Processus d’analyse du code source………………………………………………….
2.1.2. Terminologie et formalisme…………………………………………………………..
2.1.3. Description des métriques a implémentées……………………………………………
2.2. Application d’ELECTREIII………………………………………………………………
2.2.1. La phase d’agrégation ………………………………………………………………. ..
2.2.2. La phase d’exploitation……………………………………………………………......
2.3. Les phases de la procédure d’utilisation du modèle décisionnel…………………………….
3. Conclusion………………………………………………………………………………………….
IV. Conception et mise en œuvre ……………………………………………………………………… 1. Introduction………………………………………………………………………………………
2. Conception…………………………………………………………………………………………
2.1. Caractéristiques du modèle……………………………………………………………….
26
27
27
27
27
28
29
29
30
31
31
32
33
34
35
35
36
37
37
37
38
39
40
43
46
47
49
51
53 47 54 54
54
-
TABLE DES MATIERES
3. Mise en œuvre de l’outil…………………………………………………………………………
3.1. L’environnement de développement de l’outil…………………………………………..
4. Expérimentation et résultats……………………………………………………………………….
5. Conclusion………………………………………………………………………………………
Conclusion générale……………………………………………………………………………………..
Bibliographie………………………………………………………………………………………………
ANNEXE…………………………………………………………………………………………………
Résumé …………………………………………………………………………………………………..
55
55
62
64 65
68
74
i
-
TABLE DES FIGURES
Table des figures 1.1 Répartition du temps entre les différentes activités de maintenance…………………………………
2.1 Processus de décision ……………..……………..……………..……………..……………………...
2.2 Exemple d’un noyau……………..…………..……………..……………..………………………….
2.3 Graphe surclassement fort-faible……………..……………..……………..……………..…………..
3.1 schéma globale de l’approche proposée……………..……………..……………..…………………
3.2 processus d’analyse et d’extraction de métriques……..……………..……………..………………..
3.3 arbre syntaxique (AST)……………..……………..………………………………………………….
3.4 Les différentes étapes d’ELECTREIII.……………..……………..………………………………...
3.5 Phase et étapes d’utilisation du modèle décisionnel proposé.……………..……………..…………..
3.6 Structure d’un SIAD basé sur la connaissance……………..……………..………………………….
4.1 Synthèse des phases de structuration et d’exploitation du modèle ………………………………….
4.2 Menu principal ……………..……………..……………..………………..........................................
4.3 Chargement du code source ……………..……………..……………..……………………………..
4.4 Extraction de l’AST ……………..……………..……………..……………………………………..
4.5 Structure du code source ……………..……………..……………..………………………………...
4.6 calcul des différentes métriques ……………..……………..……………..…………………………
4.7 Matrice de performance ……………..……………..………………………………………………..
4.8 Insertion des changements ……………..……………..……………..…………................................
4.9 Paramètres subjectifs……………..……………..…………………………........................................
4.10 Matrice de concordance ……………..……………..……………..………………………………...
4.11 Rangement des résultats ……………..……………..……………..………………………………..
4.12 Architecture générale de BOAP …………..……………..…………….…………………………...
Figure.1 Graphe de relations entre les classes……………………………………………………………
7
23
32
33
38
39
39
50
52
53
56
57
58
58
59
59
60
60
60
61
61
62
78
-
Liste des tables
Table 2.1 : Tableau des performances……………………………………………….... 28
Table 2.2 : Les quatre problématiques de référence …………………………….......... 30
Table 3.1 : Liste des métriques implémentées ………………………………………... 43
Table 3.2 : Matrice de performance …………………………………………………... Table 4.1 : Caractéristiques du système étudié …………………………………… … Table 1 : Questionnaire du calcul d’impact …………………………………………...
Table 2 : Occurrences des changements pour le système BOAP……………………...
Table 3 : Variables indépendantes et variables dépendantes………………………......
51 63 88 89 89
-
Liste des abréviations Acronyme Description
AST Abstract Syntax Tree
BOAP Boite à Outils d’Analyse de Programmes
CRIM Centre de Recherche Informatique de Montréal
ECLIPSE Open Source Tool Platform
IEEE Institute of Electrical & Electronics Engineers
ISO International Organization for Standardization
JAVA Langage de programmation orientée objet
OO Orienté Objet
WEKA Waikato Environment for Knowledge Analysis
-
1
Introduction Générale
Contexte La maintenance a été souvent représentée comme la dernière phase du cycle de vie du
logiciel. Au cours des années, plusieurs définitions ont été proposées pour décrire la
maintenance de logiciel. Le standard IEEE pour la maintenance du logiciel [38] la définit
par : “software maintenance is the modification of a software product after delivery to correct
faults, to improve performance or other attributes, or to adapt the product to a modified
environnement”. D’un autre côté, le standard ISO/IEC12207 [40] la décrit comme: “the
process of software product undergoing modification to code and associated documentation
due to a problem or the need for improvement. The objectif is to modify existing software
product while preserving its integrity”. Enfin, Glass et Noiseux [34] définissent la
maintenance par: “software maintenance is the act of taking a software product that has
already been delivered to a customer and is in use by him, and keeping it functioning in a
satisfactory way”.
Ces définitions identifient les opérations fondamentales de la maintenance qui sont effectuées
afin de garder le système opérationnel, techniquement à jour et répondant aux besoins des
utilisateurs. En plus de la détection et de la correction des erreurs, c’est un processus
d’évolution qui permet d’assurer la continuité du logiciel à satisfaire les spécifications
actuelles et les exigences nouvelles suite aux changements fonctionnels, matériels et/ou
logiciels. Ce processus est défini par Arthur [8] comme un changement continu à partir d’un
état faible, simple ou mauvais vers un état plus haut et meilleur.
Les deux activités les plus coûteuses dans la maintenance de logiciels sont la compréhension
du problème qui est généralement liée à la compréhension du logiciel maintenu, et la maîtrise
de la totalité des effets de propagation des changements proposés [9]. En effet, un petit
changement peut avoir des effets considérables et inattendus sur le reste du système. Le
danger encouru lors de la modification, réside dans cette conséquence de l’impact d’un
changement donné. La modularité en oriente objet, adéquatement utilisée, limite les effets
-
2
relatifs aux changements. Néanmoins, ils sont subtils et difficiles à découvrir. Pour toutes ces
raisons, les concepteurs et les mainteneurs ressentent le besoin de mécanismes pour analyser
les changements et connaitre comment ils sont propagés dans le reste du système. Ce
processus s’appelle l’analyse de l’impact du changement.
Problématique et Contribution
L'impact est vu dans notre contexte comme la conséquence d'un changement. L’analyse de
l'impact est une activité dont l'objectif est de déterminer l'étendue d'une requête de
changement. Elle estime les éléments au niveau du code source et la documentation affectée
lorsqu'un changement est effectué.
Dans le domaine de Génie Logiciel, plusieurs travaux ont été élaborés pour valider les
métriques de conception O.O, comme celles de Chidamber & Kemerer [22], et les relier à
certaines propriétés de maintenabilité. Comme exemples de ces travaux, nous citons entre
autres [49], [11], [37] et [16].
La disponibilité précoce des métriques est un facteur clé pour une bonne gestion de
développement du logiciel, puisqu’elle permet :
- Une détection précoce des problèmes dans les composants (artefacts) produits dans les
phases initiales du cycle de vie (documents de spécification et de conception), et donc
une réduction du coût du changement (l’identification et la correction tardives des
problèmes sont plus coûteuses);
- Une meilleure surveillance de la qualité du logiciel dès les phases initiales du cycle de
vie du logiciel ;
- Une comparaison quantitative des techniques et amélioration empirique du processus
auquel elles sont appliquées ;
- Une planification plus précise de l’allocation des ressources, basée sur la prédiction de
la maintenabilité du système et les parties qui le constituent.
Avec l’évolution des systèmes logiciels, un flot important de changement doit être pris en
considération ainsi que leur propagation sur le reste du système. Réussir à modifier le logiciel
de façon disciplinée toute en maintenant son fonctionnement et son intégrité avec un coût
raisonnable nécessite une analyse de l’impact du changement avant son implémentation. En
effet, l’équipe de maintenance doit être en mesure de fournir des réponses aux questions
suivantes :
-
3
- De quel type de changement s’agit-il ?
- Quelle est l’étendue du changement ?
Dans la gestion des projets logiciels plusieurs changements sont proposés pour résoudre le
même problème et satisfaire le même besoin, l’utilisation de l’analyse d’impact de
changement permet de choisir le changement adéquat en prenant en considération deux
aspects : la nature de changement, et son impact sur le reste du système ; vu que plus un
changement propage plus le coût de la maintenance augmente.
A cet effet, nous proposons une approche d’aide à la décision pour les gestionnaires de
maintenance des logiciels orienté objet dans leur choix de la meilleure solution parmi des
dizaines proposées en utilisant la méthode ELECTREIII et en se basant sur certaines
métriques de couplage comme indicateurs d’impact de changement.
Organisation du Mémoire
Ce mémoire présente un travail transversal qui se situe au carrefour de deux domaines à
savoir: la maintenance de logiciels, et l’Aide MultiCritère à la Décision (AMCD). Il est
organisé en deux parties :
- La première partie (Synthèse de l’état de l’art): nous présentons dans cette partie les
concepts fondamentaux liés à nos différents axes de recherche et à la problématique abordée
par cette étude, cette partie comporte 2 chapitres :
Chapitre 1 : Analyse d’impact de changement (AI)
Présente l’état de l’art sur l’analyse d’impact du changement et introduit quelques concepts de
base de l’approche orientée objet; il sera suivi d’une étude de quelques métriques orientées
objets proposées dans la littérature.
Chapitre 2 : La Méthodologie Multicritère d’Aide à la Décision (MMCAD)
Constitue une présentation générale des concepts structurant la Méthodologie Multicritère
d’Aide à la Décision (MMCAD), une attention particulière est réservée à la description de la
famille des méthodes de type ELECTRE.
- La seconde partie de ce mémoire (Modèle proposé et Mise en œuvre) aborde notre
contribution dans l’élaboration d’un modèle d’aide à la décision permettant de répondre aux
besoins de gestionnaires de la maintenance des systèmes à objets, cette partie comporte deux
chapitres :
-
4
Chapitre 3 : Le Modèle Décisionnel Proposé
Nous présentons, dans ce chapitre, un modèle d’aide à la décision basé sur les métriques de
couplage et permettant de traiter la problématique de choix de la solution adéquate parmi
plusieurs proposées.
Chapitre 4 : Mise en Œuvre
Nous détaillons dans ce chapitre, la réalisation de notre modèle proposé ainsi que les données
utilisées relatives à des études de cas réelles tout en discutant les résultats obtenus.
Enfin, nous clôturons ce mémoire par une conclusion générale dans laquelle nous résumons
ce qui a été réalisé dans le cadre de ce travail, puis nous signalons quelques perspectives
majeurs.
-
Analyse d’impact
du changement
-
Chapitre1 Analyse d’impact
5
Chapitre1
Analyse d’impact du changement
1. Maintenance des applications
La maintenance des logiciels ne consiste pas uniquement en la correction d’erreurs. Les
modifications d’un programme dues à un changement de ses spécifications ou de son
environnement relèvent également de la maintenance. La correction d’erreurs ne constitue
qu’un faible pourcentage de l’activité de maintenance.
1.1.Types de maintenance
Généralement, trois types de maintenance se distinguent, dépendant de la nature de la
modification : corrective, perfective et adaptative. Ces types sont décrits dans les sections
suivantes.
Maintenance corrective [8] : déclenchée par la détection des erreurs ou de défauts dans le
fonctionnement du système. Ce type de maintenance permet de corriger les erreurs omises
lors de la phase de test. Elle vise à éliminer les défaillances d’implémentation, les échecs du
traitement et d’exécution, et assurer le bon fonctionnement du logiciel. À titre d’exemple, la
correction des programmes qui ne fonctionnent pas et ceux qui produisent de faux résultats.
Maintenance adaptative [49] : provoquée par une modification dans l’environnement du
travail logiciel et/ou matériel suite à des besoins nouveaux ou changeants. Ce type de
maintenance est indispensable afin de s’adapter aux besoins évolutifs du logiciel. Un
changement dans la structure du code est un changement logiciel et un changement du
système d’exploitation ou du matériel (sur lequel le logiciel est opérationnel) est un
changement matériel.
Maintenance perfective [51] : effectuée à la demande des utilisateurs, elle réfère aux
modifications apportées au logiciel afin d’augmenter ses performances ou ses fonctionnalités
et d’éliminer l’inefficacité du traitement. Elle vise l’amélioration de la qualité du logiciel, la
documentation ou autres facteurs de qualité. À titre d’exemple, l’optimisation du code source
en vue d’augmenter la rapidité de son exécution. La maintenance perfective coûte de 60 à
70% de l’effort total de la maintenance [28].
-
Chapitre1 Analyse d’impact
6
1.1.1. Activités de maintenance
L’activité d’un programmeur lors de la maintenance peut se ramener à trois taches
principales: la compréhension du code, modification, et revalidation.
• Comprendre le code et les changements à effectuer est une tache essentielle pour modifier
un programme. Le programmeur doit avoir une complète compréhension du programme,
sinon le risque d’introduise des erreurs après modification est grand.
• Le programmeur doit modifier le programme pour que ce dernier soit conforme a ses
spécifications actuelles (maintenance corrective) ou nouvelles (maintenance adaptative ou
perfective). Il doit s’assurer que ses modifications n’altèrent pas l’intégrité du système ou
n’augmentent pas sa complexité. Il doit également faire attention aux effets de bord
(introduction d’autres erreurs).
• Apres toute modification, un programme doit être re-teste (revalide) pour s’assurer que les
modifications ont été correctement effectuées et qu’il n’y pas eu d’effets de bord.
1.1.2. Problèmes de maintenance
La maintenance des logiciels se heurte à un certain nombre de difficultés. Voici quelques
facteurs qui font de la maintenance une activité délicate :
• mauvaise conception des programmes.
• utilisation de code non-structure
• utilisation de plusieurs langages de programmation dans un même programme (logiciel).
Mais une difficulté majeure est celle que pose la compréhension d’un programme (program
understanding). L’importance de ce dernier point pour notre propos fait que nous le traitons
dans la section suivante.
1.1.2.1. Compréhension de programme
Beaucoup d’organisations sont confrontées au problème de maintenir des logiciels désuets,
s’exécutant sur une grande variété de plate-forme; écrit dans des langages obsolètes et qui ont
fait l’objet de nombreuses opérations de maintenance, ce qui a conduit à une dégradation de
leur structure. La maintenance de tels systèmes est devenue très complexe et très couteuse.
Assez souvent, un programmeur qui fait la maintenance d’un logiciel n’a pas participe à sa
-
Chapitre1 Analyse d’impact
7
phase de développement. Parfois la documentation dont il dispose est incomplète, inadaptée,
voire inexistante. Il passe de ce fait un temps important a essayer de comprendre les intentions
de tous ceux qui avant lui sont intervenus sur le code.
La compréhension de programme comprend la lecture de la documentation, l’analyse du code
source et l’identification des changements à effectuer. Des trois activités de la maintenance, la
compréhension de programme est celle qui consomme le plus de temps (voir figure 1.1). Une
autre difficulté liée à la compréhension et la modification d’un système est l’évaluation de
l’impact d’un changement et des erreurs qu’il peut introduire dans le code.
Figure 1.1. Répartition du temps entre les activités de maintenance
L’objectif de la compréhension de programme est d’acquérir suffisamment de connaissances
sur un code pour pouvoir le faire évoluer de façon disciplinée. Comprendre un système
consiste essentiellement en l’identification de ses composants et des relations qui existent
entre eux. Pour faciliter la compréhension d’un programme, ce processus d’identification doit
être supporte par des techniques appropriées.
-
Chapitre1 Analyse d’impact
8
1.1.3. Techniques de maintenance
Dans le domaine du logiciel, une plus grande partie de l’effort était accordée a la phase de
développement. L’objectif était de livrer un produit qui satisfait les besoins dans les délais et
dans les limites du budget sans se préoccuper de la qualité du logiciel. Avec l’augmentation
des couts de la maintenance, de nombreuses techniques ont vu le jour. Ci-dessous, nous
présentons brièvement quelques-unes de ces techniques.
Rétro ingénierie : Généralement pour concevoir un logiciel, on passe de la conception au
code. La retro ingénierie prend le chemin inverse. Chikofsky et Cross [27] ont défini la retro
ingénierie par: “reverse engineering is the process of analyzing a subject system to identify
the system's component and their interrelationships and create representations of the system in
another form or at a higher level of abstraction”. C’est le processus d’analyse d’un logiciel
pour identifier ses composants et leurs relations dans le but de générer une représentation du
système à un plus haut niveau d'abstraction. La redocumentation et la récupération de
conception (Design recovery) représentent deux types importants de retro ingénierie.
Réingénierie : Selon Chikofsky et Cross, la réingénierie consiste en : “the examination and
alteration of a subject system to reconstitute it in a new form and the subsequent
implementation of the new form ” [27]. C’est un processus compose de l’analyse du système
et puis sa reconstitution. Ces deux étapes sont effectuées par les techniques de retro ingénierie
et de “Forward Engineering”. Cette dernière consiste à transiter d'une représentation de haut
niveau obtenue par l’étape précédente pour produire un nouveau système. Certains auteurs
ajoutent une troisième étape : la restructuration. Elle transforme la structure interne d’un
logiciel sans changer de niveau d’abstraction et sans modifier ou ajouter de nouvelles
fonctions. En outre, elle permet une meilleure compréhension du logiciel et facilite sa
maintenance [1].
Analyse d’impact : Pratiquement, lorsqu’une proposition de changement parvient à l’équipe
de maintenance, elle est transformée en terme logiciel afin de décider si le problème doit être
retenu ou rejeté. Une fois accepte, il faut localiser l’origine de l’anomalie. L’analyse d’impact
du changement s’impose à cette étape afin de (i) déterminer tous les composants du système
-
Chapitre1 Analyse d’impact
9
qui doivent changer en conséquence du changement initial, (ii) estimer les ressources
nécessaires pour implanter le changement.
Ce résultat permet aux gestionnaires de prendre une décision sur la meilleure solution à mettre
en œuvre ou annuler la requête de changement.
2. Analyse d’impact de changement
Lors de la maintenance, prédire où et comment un changement impacte le reste des
composants du système est une tâche difficile. Cette difficulté émane de la manière avec
laquelle les modifications sont traitées. Effectuer des changements sans compréhension de
leurs effets peut amener à une mauvaise estimation de l’effort, à prolonger les délais de
livraison, à dégrader la conception d’un logiciel, à entamer la fiabilité du produit, voire le
retrait prématuré du logiciel [43].
En effet, un changement peut apparaître simple, facile, nécessitant moins de temps, de budget
et de personnel. Cependant, lors de son implémentation la personne chargée de la
maintenance s’aperçoit que cette tâche est complexe, difficile, voire impossible dans certains
cas. Ainsi, l’équipe de maintenance a besoin de moyens et de mécanismes permettant
d’analyser le changement, de déterminer son impact sur le reste du système et d’étudier sa
faisabilité. L’analyse d’impact du changement est née d’une telle préoccupation. Par exemple,
pour résoudre le problème de changement de date (passage à l’an 2000), une analyse
d’impact du changement s’est avérée efficace et bénéfique en temps et effort nécessaires pour
effectuer les changements. Sans cette analyse, l’équipe de maintenance doit parcourir le code
source manuellement, détecter les variables à changer, implanter les modifications, tester la
conformité des changements et vérifier la cohérence du système afin de faire ressortir les
conséquences de ces changements.
L’analyse d’impact du changement est effectuée principalement lors de la maintenance des
programmes, en vue d’évaluer les effets du changement sur le reste du système et de réduire
le risque de s’embarquer dans des dépenses coûteuses. Cette évaluation englobe l’estimation
des ressources humaines, financières, temps, effort et plannings nécessaires pour accomplir le
changement.
-
Chapitre1 Analyse d’impact
10
2.1.Analyse d’impact
L’impact est l’effet ou l’influence d’une chose sur une autre. Dans notre étude, l’impact est la
conséquence d’un changement. L’analyse d’impact du changement est l’estimation des
conséquences d’un changement sur le reste du système. Elle a été pratiquée de différentes
manières pendant quelques années. Cependant, il n’y a pas de consensus sur sa définition [7].
Pfleeger et Bohner définissent l’analyse d’impact du changement comme : “the evaluation of
the many risks associated with the change, including effects on resources, effort, and schedule
estimates” [50]. Arnold et Bohner définissent l’analyse d’impact par : “impact analysis is the
activity of identifying what to modify to accomplish a change or of identifying the potential
consequences of a change” [7]. Turver et Munro la définissent par: “the assessment of a
change, to the source code of a module, on the other modules of the system, it determines the
scope of a change and provides a measure of complexity” [54]. Bohner la définie par :
“impact analysis identifies the consequences or ripple effects of proposed software changes”
[13].
Ces définitions adressent l’analyse d’impact selon différents points de vue. Pfleeger et Bohner
dans leur définition mettent en relief l’évaluation de l’impact et s’intéressent à l’aspect
gestion, tandis que les autres se concentrent sur l’estimation des conséquences que peut avoir
un changement sur le reste du système. L’analyse d’impact est donc une tâche prédictive
permettant de planifier les changements et d’identifier les conséquences de leurs propagations
avant leurs implémentations. Cependant, avant d’implémenter le changement, on n’est pas en
mesure de cerner l’ensemble des conséquences. C’est pourquoi la détermination de l’impact
total d’un changement se fait en deux phases : lors de l’analyse du code source et lors de
l’exécution du système après modification. Deux aspects du changement existent : quantitatif
et qualitatif. Le premier consiste à compter le nombre d’éléments touchés et le deuxième
détermine la manière avec laquelle ces éléments sont touchés [52].
L’analyse d’impact peut se faire de différentes manières. Ci-après des exemples cités dans la
littérature :
- Utiliser le “cross reference listings” pour voir quelles sont les autres parties du programme
qui contiennent les références à la variable ou à la méthode en question;
-
Chapitre1 Analyse d’impact
11
-Utiliser le “program slicing” pour déterminer le sous-ensemble du programme qui peut
affecter la valeur de la variable en question;
-Parcourir le programme par ouverture et fermeture de fichiers;
-Utiliser des relations de traçabilité pour identifier les artéfacts changés;
-Utiliser les systèmes de gestion de configuration pour suivre et trouver les changements;
-Consulter les conceptions et les spécifications pour déterminer la portée du changement.
2.1.1. Avantages d’analyse d’impact
Quand on est en face d’une nécessité de modification dans un système, il est nécessaire de
savoir l’impact ou les effets secondaires qui peuvent résulter de cette modification sur le reste
du système. Sans une bonne analyse d’impact du changement, les ingénieurs peuvent faire de
petits changements qui peuvent involontairement causer des problèmes majeurs ou avoir des
répercussions sur tout le système.
En génie logiciel, cerner les spécifications et les objectifs du projet avant son développement
diminue le risque de refaire le travail, de retarder les plannings et de dépasser le budget alloué
au projet. Le même principe se présente en analyse d’impact du changement. L’identification
des impacts du changement, la planification du changement et l’estimation des ressources
requises avant d’implémenter le changement, permettent de diminuer le risque de
s’embarquer dans des dépenses coûteuses, inutiles ou imprévisibles.
Lorsqu’un changement se présente, plusieurs solutions sont envisageables pour résoudre le
même problème. L’analyse d’impact du changement permet aux gestionnaires de qualifier
leurs choix à base d’informations recueillies par l’équipe de maintenance sur la faisabilité
technique du changement. L’analyse d’impact est donc un outil d’aide à la décision. En effet,
si un changement peut affecter un ensemble de sections disjointes du programme, les
gestionnaires peuvent choisir de ne pas l’implémenter ou de l’examiner une autre fois pour
une implémentation alternative plus sûre.
L’analyse d’impact du changement permet de diriger les tests de régression. Ces derniers
jouent un rôle intégral dans la maintenance du logiciel. Les tests de régression appliqués au
logiciel modifié, permettent d’avoir l’assurance que le code modifié continue à satisfaire les
spécifications actuelles et qu’il ne compromet pas le comportement du code non modifié [32].
-
Chapitre1 Analyse d’impact
12
Suite à une modification, il faut retester toutes les parties du code qui ont été affectées
directement ou indirectement par ce changement. Pour cela, il faut recenser toutes les classes
qui doivent être retestées pour que le système ne perde pas ses caractéristiques initiales et
continues à satisfaire les besoins des utilisateurs actuels et futurs. Sans ce recensement, on
doit retester tout le logiciel, ce qui est très coûteux et très long. Ne pas tester suffisamment
peut avoir une influence sur la qualité du logiciel.
L’analyse d’impact peut être utilisée pour déduire le coût du changement. Plus la détection du
problème est tardive dans le cycle de vie du logiciel, plus le coût de la modification augmente.
Plus on comprend l’impact, plus on contrôle le changement, et plus le changement cause
d’autres changements, plus le coût augmente. Elle peut aussi être utilisée pour indiquer la
partie (ou les parties) critique du code. Une partie dont le fonctionnement dépend d’autres
parties du programme est sensible aux modifications apportées à ces dernières.
2.1.2. Travaux connexes sur l’Analyse d’impact
Plusieurs études ont été menées sous différentes formes à propos de l’analyse d’impact. Han a
développé une approche pour calculer l’impact de changement sur la base des documents de
conception et d’implémentation [31]. Kung et al. Se sont intéressés à l’impact de changement
pour les tests de régression [40]. Ils ont classifié les changements et l’impact résultant en se
basant sur les relations d’héritage, d’association et d’agrégation. Des algorithmes formels ont
été réalisés pour calculer l’ensemble des classes impactées tout en incluant l’effet de
propagation. Une méthode a été proposée pour identifier les classes affectées suite aux
changements de structures d’une librairie de classe. Pour chaque structure de changement,
l’impact sur les classes résiduelles est calculé pour déterminer si ces classes sont affectées ou
non. Afin de calculer l’impact sur tout le système, le concept de firewall est utilisé.
Chaumun et Kabaili se sont intéressés à un des aspects de la maintenance qui est la
changeabilité [25, 26, 36]. Leur approche consiste à calculer l’impact du changement apporté
aux classes du système en utilisant un modèle d’impact. Ce modèle consiste à spécifier un
ensemble de changements pouvant intervenir dans une classe, et pour chaque classe son
impact sur les classes directement connectées à la classe changée. Par ailleurs, ce modèle
d’impact a été étendu par Kabaili pour tenir compte de l’effet de propagation et des tests de
régression afin d’obtenir une meilleure évaluation de la changeablilité du système [37]. Pour
-
Chapitre1 Analyse d’impact
13
déterminer les classes à retester, elle a utilisé une approche inspirée du concept du firewall et
basée sur les relations de dépendances entre les classes.
Li et Offut analysent l’impact des changements apportés au logiciel OO en prenant en
considération l’encapsulation, l’héritage et le polymorphisme [45]. Cette analyse accorde une
grande importance aux tests de régression en suggérant les classes et les méthodes qui ont
besoin d’être retestées. Ils ont recensé un ensemble de types de changements, analysé leurs
caractéristiques et déterminé leurs influences sur les autres parties du système. Un ensemble
d’algorithmes est proposé ayant pour objectifs l’impact à l’intérieur de la classe changée,
l’impact parmi les classes clientes et l’impact parmi les classes dérivées. Ces algorithmes
calculent la fermeture transitive pour chaque classe susceptible d’être affectée par le
changement d’un composant.
Lindvall, dans son approche de recherche, vise à comprendre les changements les plus
communs en C++ pour conduire l’analyse d’impact le plus exactement possible [46].
L’approche est répartie en deux étapes. En premier, une étude empirique a été menée afin de
détecter et d’analyser les changements effectués à un code source après que tous les
changements ont été effectués et le système livré. La deuxième étude est complémentaire où
les développeurs indiquent leurs perceptions sur l’occurrence de certains types de
changements. Les résultats de l’étude sont confirmés par les résultats de l’enquête à quelques
différences prés. En somme, ces résultats permettent de bien comprendre quels sont les
modèles qui sont stables et ne changent pas, et quels sont les modèles qui peuvent changer et
changent fréquemment.
Antoniol et al. Proposent une approche pour prédire la taille des changements des systèmes
OO en évolution, basée sur l’analyse des classes impactées par la requête du changement [6].
Ils prédisent la taille du changement en termes de nombre de lignes de code (LOC) ajoutées et
modifiées. L’approche a été évaluée empiriquement par l’analyse de la relation entre le
nombre de LOCs ajoutées/modifiées et le nombre de classes ajoutées/modifiées sur 31
versions d’un système. L’analyse des codes sources a montré que le LOCs a augmenté
considérablement de la première version à la dernière version. En outre, le nombre de LOCs
supprimées est généralement faible, comparé au nombre de LOCs ajoutées et modifiées et le
nombre de LOCs ajoutées est plus grand que le nombre de LOCs modifiées.
-
Chapitre1 Analyse d’impact
14
Pfleeger et Bohner considèrent l’analyse d’impact comme l’activité primaire dans la
maintenance du logiciel. Ils ont utilisé l’analyse d’impact pour mesurer la stabilité de tout le
logiciel avec sa documentation en proposant un nombre de métriques logicielles [50]. Le
modèle est basé sur le graphe de traçabilité. Un tel graphe montre les relations parmi le code
source, les cas de tests, les documents de conception et les spécifications. Pour chaque
workproduct (exigences, conception, code, plans de test), la traçabilité verticale exprime les
relations parmi les parties du workproduct, et la traçabilité horizontale gère les relations de ses
composants par paire de workproduct. La traçabilité (verticale et horizontale) a été
représentée en utilisant un graphe orienté.
Enfin, Arnold et Bohner définissent un modèle conceptuel composé de trois parties pour
caractériser et comparer les différentes approches d’analyse d’impact, et ressortir les forces et
les faiblesses de chacune d’elles [7]. La première partie du modèle d’analyse d’impact (IA
application) examine la méthode utilisée par une approche, pour accomplir l’analyse
d’impact. La deuxième partie (IA Parts) s’intéresse au fonctionnement de l’approche, à savoir,
ce qu’elle fait, comment elle le fait et les outils utilisés. La dernière (IA effectiveness)
s’intéresse à l’efficacité de l’approche d’analyse d’impact.
2.1.3. Conclusion
Globalement, l’analyse d’impact représente l’entrée pour effectuer le changement lors de la
maintenance. Dans un premier temps, on doit identifier le changement, puis déterminer
l’impact du changement sur le système. Cette tâche nécessite la compréhension du logiciel, en
utilisant les informations existantes dans les documents de spécification et de conception, et
dans le code source. Elle consiste à identifier les parties du système qui peuvent être
impactées par le changement et examiner les effets qu’elles peuvent produire à leurs tours. La
personne chargée de la maintenance peut estimer l’effort nécessaire pour effectuer le
changement, puis implémenter le changement. Dans cette phase, il faut être conscient des
effets de propagation que peut produire le changement (ripple effect), et finalement retester
afin de valider le logiciel. Dans cette étape, il faut trouver parmi les cas de tests existants,
ceux nécessaires pour effectuer les tests de régression, et le cas échéant créer de nouveaux
tests.
-
Chapitre1 Analyse d’impact
15
Le facteur principal qui rend la réalisation du changement difficile dans une application
orientée objet est les dépendances entre les classes. Un changement impacte la structure, les
performances, les fonctionnalités et le comportement du système. La sévérité de cet impact
peut dépendre du degré d’interdépendance entre les composants du système.
De façon générale, l’architecture d’un système est vue comme un ensemble de classes
interagissant entre elles. La nature de l’interaction entre les classes dépend du type de
relations de dépendances existantes entre elles. Plusieurs mesures orientées objets sont
utilisées pour évaluer les propriétés architecturales d’un système logiciel telles que le
couplage, l’héritage, la cohésion, la complexité, etc. Dans la section qui suit, on parle de ces
mesures ou métriques OO.
2.2.Métriques orientées objets
L’approche orientée objet est devenue de plus en plus acceptée dans l’industrie du logiciel.
Hsia et al. Ont mené une étude de cas montrant l’effet de l’architecture des systèmes orientés
objets sur la maintenance de logiciel [33]. L’étude a montré que la maintenabilité des
systèmes orientés objets est meilleure pour ceux possédant des arbres larges, i.e., arbre
d’héritage peu profond. Kiran et al. Ont procédé par comparaison de la maintenance dans le
paradigme fonctionnel et le paradigme orienté objet sur des programmes développés par des
étudiants [39]. L’expérience a montré que l’effort nécessaire pour effectuer des changements
dans le paradigme orienté objet est moins important que celui nécessaire dans le paradigme
fonctionnel.
Par ailleurs, avec l’insertion de cette technologie dans l’industrie du logiciel, de nouveaux
défis sont crées pour les compagnies qui utilisent les métriques de produits comme outils de
gestion, de contrôle et d’amélioration des méthodes de développement et de maintenance de
logiciel [11]. C’est pourquoi plusieurs chercheurs se sont dirigés à explorer de nouvelles
métriques logicielles spécifiques au paradigme OO [2, 3, 16, 21, 22, 44]. L’apport le plus
important est celui de Chidamber et Kemerer. Ils proposent une suite de métriques de
conception qui sont raffinées dans [21, 22, 23]. Cette suite de métriques a été utilisée et
expérimentée dans [11, 44]. Briand et al. Ont proposé et validé empiriquement un ensemble
de métriques de couplage au niveau classe [16]. Abreu et al. Ont défini un ensemble de
métriques qui sont empiriquement validées dans [4].
-
Chapitre1 Analyse d’impact
16
2.2.1. Quelques métriques OO
Les métriques de conception permettent d’évaluer la structure, les relations et les
fonctionnalités des composants d’un système logiciel. Un logiciel peut être analysé à deux
niveaux : au niveau système, les caractéristiques externes telles que la hiérarchie des classes et
les relations entre elles sont évaluées. Au niveau classe, les caractéristiques internes qui sont
évaluées sont les méthodes, les attributs et tous types d’interactions. Parmi les aspects les plus
importants dans une conception orientée objet on cite la cohésion, le couplage et l’héritage.
2.2.1.1. Métriques d’héritage
L’héritage permet le partage des attributs et des méthodes entre les classes du système.
Chidamber et Kemerer [22] identifient les métriques d’héritages suivantes :
Depth of Inheritance (DIT) : représente la profondeur de la classe dans l'arbre d'héritage et
montre jusqu’à quel point une classe est influencée par ses ancêtres.
Number Of Children (NOC) : réfère au nombre de descendants immédiats de la classe dans la
hiérarchie de classes. Elle reflète l’impact d’une classe sur ses descendants.
2.2.1.2. Métriques de couplage
Le couplage est défini comme le degré d’interdépendance entre les composants du système.
Deux classes sont dites couplées si une méthode de l’une utilise une méthode ou un attribut de
l’autre [22]. Diverses métriques orientées objets permettant de mesurer les différentes facettes
du couplage entre classes existent. Les principales sont les suivantes :
Chidamber et Kemerer [22] proposent :
Coupling Between Object (CBO) : représente le nombre de classes avec lesquelles une classe
est couplée. Elle reflète le degré d’interdépendance entre les composants du système.
Coupling Between Object (CBO’) : représente le nombre de classes avec lesquelles une classe
est couplée en excluant l’héritage.
Response For a Class (RFC) : représente le nombre de méthodes invoquées en réponse à un
message. RFC vaut la cardinalité de l’ensemble de réponses d’une classe et mesure la
communication entre les classes du système.
Li et Henry [44] proposent :
Message Passing Coupling (MPC) : représente le nombre de méthodes invoquées ; le nombre
de messages envoyés par une classe en direction des autres classes du système.
-
Chapitre1 Analyse d’impact
17
Data Abstraction Coupling (DAC) : correspond au nombre d’ADT (Abstract Data Type)
définis dans une classe. Une variable peut avoir le type ADT qui représente la définition
d’une autre classe.
Briand et al. pour quantifier le couplage entre les classes durant la conception des systèmes
orientés objets, ont proposé une suite de métriques de couplage [16]. Puisqu’on s’intéresse
aux applications développées avec le langage Java, le concept du friendship propre au langage
C++ n’est pas pris en considération. Cette suite de métriques, concerne l’interaction classe-
attribut, classe-méthode et méthode-méthode en tenant compte des descendants, des ancêtres
et des autres classes du système. La nomenclature de ces métriques est la suivante :
La première lettre désigne le type de la relation (A pour ancêtres, D pour Descendants et O
pour autres). En général, une classe est couplée avec tous ses descendants et ses ancêtres.
Les deux lettres suivantes indiquent le type d’interaction entre deux classes (CA, CM, MM) :
CA (Classe-Attribut) : l’interaction se manifeste à travers les attributs. Une interaction de type
CA existe entre les classes A et B, si B a un attribut de type A. Ainsi, si A change, B est
impactée via l’attribut de B qui dépend de la classe A.
CM (Classe-Méthode) : il existe une interaction de type CM entre les classes A et B, si B a
une méthode avec un paramètre de type A. Dans ce cas le couplage est fait via la méthode.
MM (Méthode-Méthode) : l’interaction se concrétise à travers les méthodes. Il existe une
interaction de type MM entre les classes A et B, si A invoque une méthode de B, ou si une
méthode de B est passée comme paramètre à une méthode de A.
Les deux dernières lettres montrent le sens du couplage (IC, EC) :
EC (export coupling) : le couplage d’exportation se présente quand une classe est utilisée par
une autre. Notons qu’une classe exporte l’impact à ses descendants et importe l’impact de ses
ancêtres.
IC (import coupling) : le couplage d’importation se présente quand la classe utilise une autre.
2.2.1.3. Métriques de cohésion
La cohésion reflète le degré d’interaction des méthodes d’une classe. Un logiciel qui obéit au
principe de forte cohésion est un logiciel de qualité. Plus la cohésion d’une classe est forte,
plus elle est cohérente et constitue une entité entière indissociable, et plus simple est sa
maintenabilité. Chidamber et Kemerer [22] proposent :
Lack of Cohesion in Methods (LCOM) : correspond au nombre de paires de méthodes ne
partageant aucune variable d’instance, moins le nombre de paires de méthodes partageant des
variables d’instances de la classe.
-
Chapitre1 Analyse d’impact
18
2.2.1.4. Métriques de complexité
Le nombre et la complexité des méthodes sont de bons indicateurs du temps et d’effort
nécessaires pour développer et maintenir une classe. Il apparaît logique que plus le nombre de
méthodes est grand, plus la classe est complexe. Plus le contrôle de flot de méthodes qu’une
classe possède est grand, plus la compréhension est difficile et la maintenance de ses
méthodes est problématique. Pour mesurer la complexité d’une classe, Chidamber et Kemerer
[22] proposent :
Weighted Methods per Class (WMC) : représente la somme des complexités de toutes les
méthodes d’une classe. Si toutes les complexités de toutes les méthodes valent 1, alors WMC
équivaut au nombre de méthodes de la classe.
2.2.2. Les métriques orientées objets et l’analyse d’impact du changement
Les métriques orientées objets pour l’analyse d’impact du changement fournissent des vues
numériques de l’effet d’un changement et permettent aux gens chargés de la maintenance
d’évaluer de façon quantitative l’effet des différents changements. Ils peuvent ainsi faire la
comparaison entre les différentes alternatives de décisions de maintenance et de conception,
aidant l’ingénieur de la maintenance à maîtriser les effets de ses actions sur la structure du
logiciel, et donnant une estimation sur l’effort nécessaire pour implémenter le changement
[43].
Plusieurs hypothèses ont été formulées sur la possibilité d’existence d’une relation entre les
caractéristiques de conception tels le couplage, l’héritage, etc. d’une application et l’impact du
changement. À titre d’exemple, un fort couplage entre les classes n’est pas désiré pour
produire un code source facilement maintenable sans beaucoup d’effort. Dans le but de
valider ces hypothèses, des métriques ont été proposées pour mesurer les caractéristiques de
conception, et des études empiriques ont été menées pour tenter d’établir une corrélation entre
ces métriques et l’impact du changement apporté au code source des systèmes OO [20, 25, 26,
36, 37, 43].
Chaumun et al. [25], dans leur étude sur la changeabilité des logiciels OO se sont basés sur le
modèle d’impact du changement défini dans [24]. Un seul changement a été retenu pour
l’expérience et l’impact a été calculé sur un système industriel. L’objectif était de tester
l’influence du WMC sur l’impact du changement. L’expérience a montré que le système
absorbe facilement le changement de signature au niveau des méthodes et que les métriques
-
Chapitre1 Analyse d’impact
19
de conception peuvent être un bon indicateur de changeablilité. Par ailleurs, une autre étude a
été réalisée en vue de trouver une relation entre la propriété d’architecture relative au
couplage et la changeabilité dans les systèmes à objets [26]. Ils ont utilisé un ensemble de
neuf métriques de conception. Cinq de Chidamber et Kemerer [22] (WMC, DIT, NOC, CBO
et RFC). Les autres sont nouvellement conçues pour détecter la changeabilité. Elles sont au
nombre de quatre et dérivées des métriques CBO et NOC; il s’agit des métriques CBO’,
NOC*, CBO-U et CBO-IUB. L’expérience a été faite sur trois systèmes industriels de tailles
différentes. Un ensemble de six changements a été défini et l’impact est calculé : c’est le
nombre de classes qui peuvent être impactées. Les résultats ont montré l’existence d’une
corrélation significative entre la changeabilité et l’accès à une classe par une autre classe via
l’invocation de méthodes ou l’accès aux variables. En outre, la métrique CBO-IUB est un bon
indicateur de changeabilité dans le système.
Michelle Lee a développé une nouvelle technique d’analyse pour dresser le problème de
l’analyse d’impact du changement des logiciels OO, plus particulièrement la détermination de
l’effet de propagation du changement après son implémentation [43]. Pour ce faire, elle a
proposé d’analyser les relations entre les composants d’un système orienté objet (utilisation
de graphe de relations) et d’appliquer une technique algorithmique d’analyse du logiciel pour
calculer la fermeture transitive de certaines relations entre les composants. Un ensemble de
métriques OO d’impact de changement a été conçu et utilisé. Ces métriques, mesurent
l’impact dans le système, la classe et les méthodes.
Briand et al. [20] ont mené leur étude sur un système commercial en C++, développé et
maintenu depuis des années. L’objectif de l’étude est de déterminer si les mesures de
couplage permettent de recenser suite à un changement dans une classe l’ensemble des classes
affectées. Pour ce faire, ils ont utilisé un ensemble de 18 mesures de couplage dont 4
nouvellement conçues pour prendre en considération les relations de couplage indirect. Ces
dernières peuvent créer l’effet de propagation et par la suite doivent être considérées dans
l’analyse d’impact; il s’agit de SIMAS, PIM, PIMAS et INAG. L’étude a montré qu’un
certain nombre de métriques de couplage en rapport avec l’agrégation et l’invocation sont
liées à une probabilité plus élevée de changements communs. En outre, ces métriques de
couplage sont de bons indicateurs de l’effet de propagation, et peuvent être utilisées pour
classifier les classes en fonction de leurs probabilités de contenir l’effet de propagation.
-
Chapitre1 Analyse d’impact
20
Kabaili et al. dans l’objectif de trouver une relation entre la cohésion et la changeabilité, ont
utilisé deux approches différentes [36]. La première analyse la cohésion en tant qu’indicateur
de changeabilité. Les métriques utilisées pour ces fins sont des métriques de cohésion [12] et
des métriques de couplage [22] (CBO, RFC, NOC, CBO-IUB, CBO’, CBO-U et NOC*). La
deuxième approche analyse la capacité de la cohésion à prédire la changeabilité basée sur
l’étude de la relation entre les métriques de cohésion et les impacts de changements obtenus
par le modèle d’impact sur les systèmes étudiés. L’expérience s’est limitée à six changements.
Les résultats des deux approches sont négatifs. Pour s’assurer des résultats, une investigation
manuelle des classes supposées être de faible cohésion a été menée. Suite à cette analyse, ils
ont conclu que les métriques de cohésion ne peuvent pas être utilisées comme indicateur de
changeabilité pour les systèmes à objets.
Enfin, en vue d’étudier la propagation de l’effet du changement, ils ont mené une expérience
avec le modèle d’impact étendu sur deux systèmes industriels avec neuf changements [37].
Des métriques ont été choisies en utilisant l’approche GQM [10]; dix d’entre elles de
Chidamber et Kemerer [22] (WMC, DIT, NOC, NOC*, CBO, CBO’, CBO_IUB, CBO-U,
RFC et LCOM), et six de Briand et al. [16] (ACAIC, OCMIC, OCAIC, AMMIC, ACMIC et
OMMIC). De cette étude, trois conclusions sont établies : (i) la complexité d’une classe prédit
sa changeabilité lorsque le changement appliqué au système concerne un changement de
méthode ou un changement de classe, (ii) il y a un lien entre la changeabilité et le couplage, et
(iii) le nombre de descendants d’une classe parait exercer une influence sur la changeabilité.
2.2.3. Le couplage vs l’analyse d’impact
Le couplage mesure la force de l’interconnexion entre les modules d’un système. Durant le
processus de maintenance de logiciel, le couplage prédit la difficulté de changement des
modules du programme et les implications pour les programmes dans les autres modules [47].
Le couplage réfère au degré d’interdépendance entre les parties d’une conception. Dans le but
d’améliorer la modularité et de protéger l’encapsulation, le couplage inter-classes doit être
gardé au minimum [22]. Plus une classe est couplée à d’autres classes, plus importante est sa
sensibilité aux changements dans ces classes.
Un logiciel de bonne qualité doit obéir au principe de faible couplage [16, 18, 22, 47]. Un
couplage faible facilite la maintenance vu que les dépendances entre les classes sont minimes.
-
Chapitre1 Analyse d’impact
21
Plus encore, il permet de minimiser les chemins de propagation du changement par lesquels
l’impact du changement initial peut se propager vers les autres classes du système. Ainsi, plus
les dépendances sont faibles, moins important est l’effet de propagation (ripple effect) du
changement, tandis qu’un couplage fort entre deux classes entraîne plus de dépendances. En
conséquence, une modification d’une classe peut entraîner une modification des classes
auxquelles elle est liée. Plus encore, la compréhension d’une classe indépendamment de son
environnement est plus difficile à cause du flot important de dépendances.
Si le nombre de méthodes d’une classe qui peuvent être invoquées en réponse à un message
est grand, la compréhension de cette classe devient plus compliquée. Ce qui rend l’impact du
changement apporté à cette classe important. Plus le couplage d’exportation (Export
Coupling) d’une classe C est élevé, plus grand est l’impact du changement apporté à C sur les
autres classes. Ces dernières dépendent de façon critique de la conception de la classe C. Plus
le couplage d’importation (Import Coupling) d’une classe C est élevé, plus grand est l’impact
du changement dans les autres classes sur C elle-même. Donc, la classe C dépend de façon
critique de ces classes, et par la suite, la compréhension de C s’avère difficile [16].
2.2.4. Conclusion
L’analyse d’impact du changement avec les métriques permettent aux gestionnaires de
confirmer si le changement répond aux exigences, conforme à la conception existante, ne
dégrade pas la maintenabilité du système existant, et est ce qu’il est implémenté de la
meilleure manière?
Les métriques permettent de mesurer les différents aspects de couplage, de la cohésion et de
l’héritage dans un système orientée objet. Plusieurs études empiriques ont montré la validité
de ces métriques comme de bons indicateurs de la maintenance. La validation empirique des
métriques permet de démontrer leurs valeurs dans la pratique.
Dans ce mémoire, l’objectif visé en collectant certaines métriques de couplage est d’estimer
l’impact du changement lors de la maintenance des systèmes à objets et les utiliser comme
critères dans la matrice de performance de la méthode ELECTREIII, qui est une méthode
d’aide multicritère à la décision que nous détaillerons dans le chapitre suivant.
-
Méthodologie Multicritère d’Aide
à la Décision (MMCAD)
-
Chapitre2 la méthodologie multicritère d’aide à la décision
22
Chapitre2
Méthodologie Multicritère d’Aide à la Décision
(MMCAD) L’objectif de ce chapitre est la présentation de la MMCAD, nous y abordons successivement
les concepts d’aide à la décision et de processus d’aide à la décision. Nous présentons ensuite,
de façon synthétique, les éléments de la MMCAD à savoir les différentes procédures
d’agrégation et les systèmes de préférence. Enfin, une attention particulière est réservée à la
description de la famille des méthodes multicritères de la famille ELECTRE.
1. Introduction Avant l’apparition des méthodes multicritère, les problèmes de décision se ramenaient le plus
souvent à l’optimisation d’une fonction économique, cette approche vit le mérite de
déboucher sur des problèmes mathématiques bien posés mais qui n’étaient pas toujours
représentatifs de la réalité car la comparaison de plusieurs actions possibles se fait rarement
suivant un seul critère et les préférences sur un critère sont, dans bien des cas difficilement
modélisables par une fonction. Les premières méthodes d’aide multicritère à la décision sont
apparues dans la année 60 et ont eu pour but de pallier aux insuffisances du calcul
économique et de la recherche opérationnelle en cherchant une solution reliant la meilleure
combinaison de critères multiple : c'est-à-dire le meilleur compromis et non la meilleure
solution d’où l’intérêt de ces méthodes.
L’aide multicritère à la décision vise, comme son nom l’indique, à fournir à un décideur des
outils lui permettant de progresser dans la résolution du problème de décision où plusieurs
critères souvent contradictoires, doivent être pris en compte, elle permet de modéliser de la
manière la plus fidèle possible les préférences d’un expert, une telle modélisation permet
ensuite la construction d’outils adaptés et capables d’assister ou de remplacer un décideur sur
des problèmes complexes. Le contexte de l'aide multicritère à la décision ainsi que les
-
Chapitre2 la méthodologie multicritère d’aide à la décision
23
différents concepts relatifs à cette discipline sont abordés dans ce chapitre tout en mettant
l’accent sur les principales méthodes de la famille ELECTRE.
2. Aide à la décision
2.1. Définition
Selon Roy [58], « L’aide à la décision est l’activité de celui qui, prenant appui sur des
modèles clairement explicités mais non nécessairement complètement formalisés, aide à
obtenir des éléments de réponse aux questions que se pose un intervenant dans un processus
de décision, élément concourant à éclairer la décision et normalement à recommander, ou
simplement à favoriser un comportement de nature à accroître la cohérence entre l’évolution
du processus d’une part, les objectifs et le système de valeur au service desquels cet
intervenant se trouve placé d’autre part».
2.2. Le Processus de décision
L’activité d’aide à la décision s’articule autour d’un processus de décision qui est un
ensemble d’activités déclenché par un stimulus, et aboutissant à un engagement spécifique à
l’action [59]. Le processus de décision peut être considéré comme une flèche qui part des
données (matériau brut) pour aller aux techniques de décision (figure2.1).
La littérature concernant les concepts des différents processus de décision est vaste.
Cependant, le processus le plus diffusé est celui de H.Simon (1960) [60]. Nous distinguons,
également, d’autres processus comme ceux proposés par Mintezberg en (1976) [59] et
Tsoukias en (2003) [59].
- Le Modèle de Simon [60]
Il est considéré comme étant le modèle le plus célèbre des processus décisionnels
disponibles dans la littérature. Ce processus opère en quatre étapes non nécessairement
séquentielles. Le processus de décision selon Simon est représenté par la figure2.1.
-
Chapitre2 la méthodologie multicritère d’aide à la décision
24
Figure2.1. Processus de décision [60]
Information : détermine l’ensemble des données nécessaires (mais pas forcement
suffisantes) qui seront utilisées lors des phases suivantes.
Conception : génère les différentes alternatives qui forment l’ensemble des possibilités.
Les différentes solutions sont donc élaborées à ce stade.
Choix : Cette phase constitue la phase de décision proprement dite. Elle consiste à
restreindre l’ensemble des possibilités au sous-ensemble des possibilités sélectionnées.
Evaluation : Cette phase a pour objet d’évaluer la qualité de la prise de décision et peut
impliquer si nécessaire un retour à l’une des phases précédentes.
- Le Modèle de Mintzberg et al [59]
Ce processus décisionnel contient sept types d’activités fondamentales regroupés en trois
phases :
Phase 1 : Identification de la situation décisionnelle : Reconnaissance et Diagnostic.
Phase 2 : Développement des solutions possibles : Recherche et Conception.
Phase 3 : Sélection d’une solution à implanter : Tamisage, Evaluation/Choix et
peut impliquer, si nécessaire un retour à l’une des phases précédentes.
- Le Modèle de Tsoukias [59]
L’auteur a introduit le concept de processus d’aide à la décision comme une extension au
processus de décision. Le processus d’aide à la décision est subdivisé en quatre phases :
1. Représentation du problème.
2. Formulation du problème.
3. Evaluation.
4. Recommandation
Information Conception Choix Évaluation
-
Chapitre2 la méthodologie multicritère d’aide à la décision
25
3. Le Paradigme multicritère
Les méthodes multicritères sont des outils d’aide à la décision, leur développement a débuté
dans le contexte militaire depuis les années 1960 pour deux essentielles raisons [61]:
L’amélioration de la gestion et la fourniture des moyens nécessaires pour les soldats. Les
méthodes utilisées à l’époque sont issues du domaine de recherche opérationnelle. Ces
méthodes permettaient d’optimiser une fonction tout en considérant un ensemble de
contraintes prédéfinies.
Par la suite, ces méthodes ont investi d’autres problématiques décisionnelles où le facteur
humain a pris une dimension importante. Malheureusement, lorsque la décision concernait un
système ouvert, qui intègre des dimensions de natures différentes telles qu’économique
(optimisation de coût, de production) et sociale (acceptation d’un groupe, impact sur la santé,
etc.), les méthodes de recherche opérationnelle ont montré certaines faiblesses auxquelles les
méthodes multicritères semblent pallier.
D’après Vincke [62]: « L’analyse Multicritère est une approche constructiviste visant à
fournir des outils permettant de progresser dans la résolution d’un problème où plusieurs
points de vue, souvent contradictoires, doivent être pris en compte ».
L’analyse Multicritère désigne un ensemble d’outils d’aide à la décision développés depuis
les années 1960. Elle Vise la résolution de problèmes avec plusieurs alternatives et en
considérant plusieurs critères de décision simultanément. Ces derniers sont souvent
conflictuels et d’importance inégale. Plusieurs méthodes d’analyse multicritère existent dans
la littérature, on peut citer : MAUT, ELECTRE, AHP, Prométhée, etc. [63].
3.1. Terminologie
Cette section définit les notions associées à l’analyse multicritère : action, préférence, critère,
matrice de performance, pondération, etc.
3.1.1. Actions Potentielles
Compte tenue de la définition proposée par [64], une action correspond aux solutions
possibles envisagées dans un processus de décision. C’est l’élément qui va faire l’objet de la
comparaison. On distingue deux types d’actions : réelles et fictives. Les actions réelles sont
issues d’un projet complètement élaboré contrairement aux actions fictives qui sont issues
d’un projet partiellement élaboré ou encore construit dans l’imagination.
-
Chapitre2 la méthodologie multicritère d’aide à la décision
26
3.1.2. Critères
La définition proposée dans [65] est la suivante « un critère est une référence par rapport à
laquelle on mesure la conséquence d’une action, en d’autres termes un critère exprime plus
ou moins les préférences du décideur relativement à un attribut donné ». On distingue
plusieurs types de critères.
-Le vrai critère : si la structure de préférence sous jacente est une structure de préordre total.
-Le pseudo critère : si la structure de préférence sous jacente est une structure de pseudo
ordre.
-Le quasi critère : si la structure de préférence sous jacente est une structure de quasi ordre
[70]. Le choix des critères n’est pas une opération évidente, il doit respecter les conditions
suivantes :
Exhaustivité : Il ne faut pas oublier un critère.
Cohérence : Il doit y avoir une cohérence entre les préférences locales de chaque critère et les
préférences globales. C'est-à-dire que si une action a est égale à une action b pour tous les
critères sauf pour un (où elle lui est supérieure), ceci signifie que l’action a est globalement
supérieure à l’action b.
Indépendance : Il ne doit pas y avoir de redondance entre les critères. Leur nombre doit être
tel que la suppression d'un des critères ne permet plus de satisfaire les deux conditions
précédentes [66].
3.1.3. Surclassement
Une action a surclasse une action b, noté aSb, si elle est au moins aussi bonne que a
relativement à une majorité de critères, sans être trop nettement plus mauvaise que b
relativement aux autres critères [65].
3.1.4. Préférences
Vincke [62] rappelle que la modélisation des préférences constitue une étape indispensable en
aide à la décision. Lorsqu’ un décideur est confronté à la comparaison de deux actions a et b
il aura alors l’une