-
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
