Chapitre I

‫وزارة الت ـع ـلـيــم العــالــي وال ـب ـحــث ال ـع ـل ـمــي‬
Université Mohamed Chérif Messadia ‫جــامــعــة مـحمـد الشـريـف مساعديــة‬

Souk Ahras ‫ســـوق أهـــراس‬
Mohamed Chérif Messadia University
Souk-Ahras
Faculté des Sciences et de la Technologie

Département de Mathématiques et Informatique
Année : 2019/2020
MEMOIRE
Présenté en vue de l’obtention du Diplôme de Master
TITRE
L’Analyse de l’Historique d’Evolution de Logiciel
pour la Détection des Défauts de modularité
Filière
Informatique
Spécialité
Génie Logiciel
Par
YAGOUBI Wafia
DIRECTRICE DE MEMOIRE : CHERAIT Hanane MCB U.SOUK-AHRAS
Devant le jury
PRESIDENT: AMIRAT Abdelkrim PROF U.SOUK-AHRAS
EXAMINATEUR : MENASRIA Ahcen MAA U.SOUK-AHRAS
N°……./2020
Ce travail est l’aboutissement d’un dur labeur et de beaucoup
de sacrifices ; il n’a pu être mené à bien qu’avec le soutien de
plusieurs personnes que je voudrais, à travers ces quelques
lignes, remercier du fond du cœur.
Mes remerciements vont d’abord au Créateur de l’univers
qui m’a doté d’intelligence, et nous a maintenu en santé pour
mener à bien cette année d’étude.
Je tiens aussi à adresser mes remerciements à mes parents,
ma famille, et plus précisément à mes frères, mes beaux-frères
et mes sœurs qui m’ont toujours soutenu et poussé à continuer
mes études. Ce présent travail a pu voir le jour grâce à leur
soutien.
Je voudrai présenter mes remerciements à la directrice de ce
mémoire Dr « Hanane Cherait » pour l’orientation, la confiance,
la patience et surtout ses conseils judicieux, qui ont contribué à
alimenter ma réflexion et qui ont constitué un mémoire
considérable sans laquelle ce travail n’aurait pas pu être mené
au bon port.
Mon encadreur trouve dans ce travail un hommage vivant à
sa haute personnalité. Je voudrai également la témoigner ma
gratitude pour son soutien.
Je tiens à exprimer nos sincères remerciements à tous mes
professeurs qui nous ont enseigné et qui par leurs compétences
nous ont soutenu dans la poursuite de mes études. J’exprime
toute ma reconnaissance et gratitude à Mme le chef de
département Dr « Drissi Samia », à Mr le chef de spécialité
Dr « Noureddine Gasmallah » du département de
Mathématiques et Informatique et plus précisément de la
spécialité Master II « Génie Logiciel » et à l’administration
surtout Mme « Malika » pour leurs efforts à nous garantir la
continuité et l’aboutissement de ce mémoire.
Mes sincères remercîments s’adressent aussi à Monsieur le
président de jury pour m’avoir fait l’honneur de présider le jury.
Je tiens également à remercier les examinateurs de ce
mémoire pour m’avoir honoré de leur présence et accepté
de jury ce travail.
Enfin, on remercie tous ceux qui, de près ou de loin, ont
contribué à la réalisation de ce travail.
Dédicaces
Toutes les lettres ne sauraient trouver les mots qu’il faut …
Tous les mots ne sauraient exprimer la gratitude, l’amour, le respect, la reconnaissance…Aussi, c’est tout
simplement que je dédie ce travail…
A mes très chers parents

Aucune dédicace ne saurait être assez éloquente pour exprimer la profondeur des sentiments d’affectation,
d’estimation et de respect que je vous porte, pour l’amour dont vous m’avez toujours comblé, l’éducation et le bien
être que vous m’assurez, pour votre soutien, vos sacrifices et vos prières. Aussi fière d’y appartenir, aussi déterminé à
en être digne.
A mes très frères, mes sœurs et mes beaux-frères
Samia, Atef et ses enfants Feras et Baraa, à Mamin, Bessam, Latifa et son mari Said et leurs
enfants Djouri, Imed et Tasnim. A ma très chère tante Hakima. A ceux qui n’ont jamais cessé de
m’encouragé, me conseiller. A ceux qui n’ont jamais été avares ni de leur temps ni de leurs connaissances
pour satisfaire mes interrogations.
A mes chères amies
Pour m’avoir toujours accompagné.
Wafia
Résumé
L’objectif de l’analyse de l’historique d’évolution d’un projet logiciel est de déceler des dépendantes
logiques séduisantes et intéressantes entre ses artéfacts. Pour ce faire, l’analyse d’une seule version est
infaisable. C’est ainsi, que nous avons fondés sur ce genre de dépendances afin de proposer notre approche
d’analyse de la modularité de logiciels orientés objet (OO). Notre but est de savoir à quel point ce logiciel
est modulaire ? et de guider le développeur à prendre une décision si le logiciel nécessite une restructuration,
ou encore un refactoring pour l’obtention d’une version plus modulaire. Notre approche est subdivisée en
deux phases primordiales. Initialement, en vue de détecter les dépendances logiques entre ses classes et ses
packages, nous analysons le dépôt de versions de l’application OO. En appliquant l’algorithme Apriori sur
ces dépendances, des règles d’association seront générées à partir de ces dernières. Le résultat trouvé sera
entreposé dans une base de données (BDD). Secondement, notre outil « Logical Modularity Analyser »
intervient dans le but d’utiliser ces règles afin de mesurer la modularité du logiciel OO. Cet outil développé
depuis NetBeans va prendre en charge ces règles et génère des dépendances logiques interne qui représente
la cohésion et d’autres dépendances logiques externes décrivant le couplage. Ces dernières seront les
mesures à prendre en considération par le développeur. Dans notre étude, nous avons examinés les dépôts de
versions de trois les applications OO Open-source volumineuses dans le souci de démontrer la fiabilité, la
faisabilité et l’efficience de notre proposition.
Mots-clés : Modularité de logiciel, Historique de l’évolution, Système de contrôle de version, Mining,

Dépendance logique, Règle d’association, Apriori, NetBeans, Couplage, Cohésion.
4
Abstract
The objective of the analysis of the evolution history of a software project is to detect attractive and
interesting logical dependencies between its artifacts. To do this, the analysis of a single version is
impossible. Thus, we have based on this kind of dependencies in order to propose our approach to analyzing
the modularity of object-oriented software (OO). Our goal is to know how modular this software is? and
guide the developer to make a decision if the software requires restructuring, or even refactoring to obtain a
more modular version. Our approach is divided into two essential phases. Initially, in order to detect the
logical dependencies between its classes and its packages, we analyze the repository of versions of the OO
application. By applying the Apriori algorithm to these dependencies, association rules will be generated
from these dependencies. The result found will be stored in a database (BDD). Secondly, our «Logical
Modularity Analyser» tool intervenes in order to use these rules to measure the modularity of the OO
software. This tool developed with NetBeans will support these rules and generate internal logical
dependencies that represent cohesion and other external logical dependencies describing the linkage. These
two will be the measures to be taken into consideration by the developer. In our study, we examined the
version repositories of three large open-source OO applications to demonstrate the reliability, feasibility and
efficiency of our proposal.
Keywords: Software modularity, Evolution history, Version control system, Mining, Logical
dependency, Association rule, Apriori, NetBeans, Coupling, Cohesion.
5
‫تلخيص‬
‫إن الهدف من تحليل تاريخ تطور مشروع برمجي هو اكتشاف تبعيات منطقية مثيرة لالهتمام بين منتجاته‪ .‬ولهذا فإن تحليل نسخة واح‪WW‬دة أم‪WW‬ر‬
‫مستحيل‪ .‬ومن هذا المنطلق‪ ،‬قد قمنا باالستناد إلى هذا النوع من التبعيات من أجل اقتراح منهجنا في تحلي‪WW‬ل قابلي‪WW‬ة تع‪WW‬ديل البرمجي‪WW‬ات الموجه‪WW‬ة‬
‫إلى الكائنات‪ .‬هدفنا هو معرفة مدى تطبيق نظام الوحدات النموذجية لهذا البرنامج؟ وتوجيه المطور التخاذ قرار إذا كان البرنامج يتطلب إعادة‬
‫هيكلة أو حتى إعادة تحليل للحصول على إصدار أكثر نمطية‪ .‬إن نهجنا ينقسم إلى مرحلتين أساسيتين‪ .‬في البداية‪ ،‬من أجل الكشف عن التبعي ات‬
‫المنطقية بين فئاته وحزمه‪ ،‬نقوم بتحليل مستودع إصدارات تطبيق ‪ .OO‬ومن خالل تطبيق خوارزمية ‪ Apriori‬على هذه التبعيات‪ ،‬س يتم إنش اء قواع د‬
‫االقتران من هذه التبعيات‪ .‬سيتم تخزين النتيجة التي تم العثور عليها في قاعدة بيان ات (‪ .)BDD‬ثاني ا‪ ،‬أداة "محل ل النمطي ة المنطقي ة" تت دخل من أج ل‬
‫استخدام هذه القواعد لقياس قابلية تعديل برنامج ‪ .OO‬وستدعم هذه األداة التي تم تطويرها باستخدام ‪ NetBeans‬هذه القواعد وستنش ئ تبعي ات منطقي ة‬
‫داخلية تمثل التماسك والتبعيات المنطقية الخارجية األخرى التي تصف االرتباط‪ .‬وسيشكل هذان المعياران الذان يتعين على المطور أخ ذها في االعتب ار‪.‬‬
‫في دراستنا‪ ،‬قمنا بفحص مستودعات إصدار ثالثة تطبيقات ‪ OO‬كبيرة المساحة مفتوحة المصدر لتوضيح موثوقية اقتراحنا وجدواه وكفاءته‪.‬‬
‫‪ : Keywords‬نمطية البرمجيات‪ ،‬تاريخ التطور‪ ،‬نظام التحكم في اإلصدار‪ ،‬التعدين‪ ،‬التبعية المنطقية‪ ،‬قاعدة االتحاد‪،Apriori، NetBeans ،‬‬
‫توصيل‪ ،‬التماسك‪.‬‬
‫‪6‬‬
Table de matières
CHAPITRE I :INTRODUCTION GENERALE.................................................................................1

I.1 Contexte de Travail.....................................................................................................................1
I.2 Problématiques et Motivations...................................................................................................1
1.3 Objectifs et Contributions..........................................................................................................3
I.4 Contenu de mémoire...................................................................................................................3
CHAPITRE II :LA MODULARITE D’UN SYSTEME LOGICIEL..................................................6
II.1 Introduction...............................................................................................................................6
II.2 La Modularité............................................................................................................................6
II.2.1 La conception du logiciel....................................................................................................6
II.2.2 Les principes de la conception............................................................................................7
II.2.3 Définition de la modularité.................................................................................................7
II.2.4 Le module...........................................................................................................................8
II.2.5 Le système modulaire.........................................................................................................8
II.2.6 A quoi sert la modularité ?..................................................................................................8
II.3 L’historique de la modularité....................................................................................................9
II.4 Les préceptes de la modularité................................................................................................10
II.5 Les métriques de la modularité................................................................................................11
II.5.1 La cohésion.......................................................................................................................12
II.5.2 Couplage...........................................................................................................................13
II.5.3 Cohésion versus couplage.................................................................................................16
II.6 La modularité et les systèmes orientés objet...........................................................................17
II.6.1 Le modèle orientés objet...................................................................................................17
II.6.2 La modularité dans un logiciel orientée objet...................................................................19
II.6.3 Critères de modularisation d’un logiciel OO....................................................................20
II.6.4 Les Principes de la modularisation orientée objet............................................................20
II.7 Etat de l'Art sur les travaux traitants la modularité des systèmes orientés objet.....................24
II.8 Conclusion...............................................................................................................................26
CHAPITRE III :LA DETECTION DES DEPENDANCES LOGIQUES : FOUILLE DE DONNEES 28
III.1 Introduction............................................................................................................................28
III.2 Les Systèmes de Contrôle de Versions (SCVs).....................................................................28
III.2.1 Définition des SCVs........................................................................................................28
III.2.2 Les types des systèmes de contrôle de versions..............................................................29
i
III.2.3 Les approches de Versioning...........................................................................................31
III.2.4 Les outils de versioning...................................................................................................32
III.2.5 Principe de base des systèmes de contrôle de versions...................................................32
III.2.5.2 Principe de fonctionnement..........................................................................................33
III.3 L’analyse des dépôts des SVCs..............................................................................................35
III.3.1 Le dépôt de versions........................................................................................................35
III.3.2 Les types des dépôts de SCVs.........................................................................................35
III.3.3 Principe général de l'analyse d’un dépôt de versions......................................................36
III.3.4 Les Approches d’Analyse de l’historique de l’Evolution................................................37
III.4 Les dépendances logiques......................................................................................................38
III.4.1 Définition et objectif des dépendances logiques.............................................................38
III.4.2 Les relations logiques versus les relations statiques et sémantiques...............................39
III.4.4 Les Algorithmes de Mining.............................................................................................43
III.4.5 Etat de l'Art sur des approches de détection des dépendances logiques..........................44
III.5 Conclusion..............................................................................................................................45
CHAPITRE IV :NOTRE APPROCHE D’ANALYSE DE LA MODULARITE DES LOGICIELS OO48
IV.1 Introduction............................................................................................................................48
IV.2 Vue globale de notre approche...............................................................................................48
IV.3 La génération des dépendances logiques...............................................................................49
IV.3.1 Extraction de données.........................................................................................................50
IV.3.2 La Différenciation...............................................................................................................51
IV.3.3 Le prétraitement de données...............................................................................................51
IV.3.4 La fouille de données (Mining)...........................................................................................52
IV.4 L’analyse de la modularité des logiciels OO.........................................................................54
IV.4.1 La cohésion logique de package......................................................................................54
IV.4.2 Le couplage logique entre packages................................................................................55
IV.4.3 Les défauts de modularité................................................................................................56
IV.5 La conception de notre outil d'analyse de modularité............................................................57
IV.5.1 Diagramme de cas d’utilisation.......................................................................................57
IV.5.2 Diagramme de classes.....................................................................................................58
IV.5.3 Diagrammes de séquence................................................................................................58
IV.6 Conclusion.............................................................................................................................60
CHAPITRE V :IMPLEMENTATION ET EXPERIMENTATION..................................................63
VI.1 Introduction............................................................................................................................63
VI.2 Mise en œuvre de notre approche..........................................................................................63
ii
VI.2.1 Génération des règles d'association.................................................................................63
VI.2.2 L'outil d’analyse de la modularité logique......................................................................68
VI.3 Expérimentations...................................................................................................................71
VI.3.1 L’application Modern GPS Tracking Platform "Traccar"...............................................71
VI.3.2 L'application Bco.Bcozy.................................................................................................75
VI.3.3 L'application TEAMMATES..............................................................................................77
VI.3.4 Discussion des résultats...................................................................................................80
V.4 Conclusion...............................................................................................................................81
Chapitre VI :Conclusion & Perspectives..........................................................................................84
VI.1 Contribution...........................................................................................................................84
VI.2 Perspectives de recherche......................................................................................................85
Bibliographie......................................................................................................................................87
iii
Table de figures
Figure II-1: La modularité d’un système logiciel................................................................................8
Figure II-2: Spectre du degré de la cohésion. [PRE97].....................................................................13
Figure II-3: Couplage entre les modules............................................................................................14
Figure II-4:Types de couplage [YOU79]...........................................................................................15
Figure III-1: Conserver l’historique...................................................................................................29
Figure III-2:Travail collaboratif.........................................................................................................29
Figure III-3: Modèle des systèmes de contrôle de versions locaux...................................................30
Figure III-4:Modèle des systèmes de contrôle de versions centralisés..............................................30
Figure III-5:Modèle des systèmes de contrôle de versions distribués...............................................31
Figure III-6:Fonctionnalités de haut niveau d'un SCV [ALT09].......................................................33
Figure III-7: L’analyse de l’évolution du logiciel [CHE14]..............................................................36
Figure IV-1:Vue globale de notre approche......................................................................................49
Figure IV-2: Les étapes de la génération des dépendances logiques.................................................50
Figure IV-3: Extraction de données avec Git.....................................................................................50
Figure IV-4: Différenciation entre les versions.................................................................................51
Figure IV-5: Diagramme de classe de notre application....................................................................58
Figure IV-6: Diagramme de séquence générer les règles d’association............................................59
Figure V-1: Les étapes de génération des règles d'association..........................................................63
Figure V-2: La création de dépôt des transactions de changement en format XML.........................64
Figure V-3: Fenêtre principale de notre application..........................................................................69
Figure V-4: Interface de génération des règles d’association............................................................69
Figure V-5: Fenêtre représentant le couplage et la cohésion.............................................................70
Figure V-6: Les transactions de changement de l'application Traccar..............................................73
Figure V-7: Cohésion et couplage du logiciel Traccar......................................................................74
Figure V-8: Les règles d'association de l'application Bco.Bcozy......................................................76
Figure V-9: Cohésion et couplage du logiciel Bco.Bcozy.................................................................77
Figure V-10: Les règles d'association de l'application Teammates...................................................79
Figure V-11: Cohésion et couplage du logiciel Teammates..............................................................80
Figure V-12: Zoom-in du graphe des dépendances logiques de l'application Traccar......................81
iv
Listes des tableaux
Tableau II-1: Comparaison entre la cohésion et le couplage.............Error! Bookmark not defined.

Tableau III-1: Les logiciels de versioning [ALT09]..........................................................................32
Tableau III-2: Les types de dépôts de versions [HAS08]..................................................................36
Tableau V-1: Métriques de l'application Traccar avec Iplasma.........................................................72
Tableau V-2: Métriques de l'application bco.bcozy avec Iplasma....................................................76
Tableau V-3: Métriques de l'application Teammates avec IPlasma.:................................................78
v
Table des listings
Listing IV-1:L'algorithme Apriori [BOU09].....................................................................................53

Listing IV-2:Algorithme de génération des règles d'association [BOU09].......................................53
Listing V-1: Exemple d'un rapport XML généré par JDiff « transaction.xml »................................66
Listing V-2: Méthode de calcul des règles d'association...................................................................67
Listing V-3: Le fichier XML des règles d'association « Rules.xml »................................................68
Listing V-4: Les règles d'association de l'application Traccar...........................................................73
Listing V-5: Fichier XML résultat de la cohésion du logiciel Traccar..............................................74
Listing V-6: Fichier XML résultat du couplage du logiciel Traccar.................................................75
Listing V-7: Les règles d'association de l'application Teammates....................................................79
Listing V-8: Exemple d’une règle logique de l’application Traccar.................................................81
vi
vii
CHAPITRE I
INTRODUCTION
GENERALE
1. Contexte de Travail
2. Problématiques et Motivations
3. Objectifs et Contributions
4. Contenu de mémoire
Chapitre I : Introduction Générale
CHAPITRE I
INTRODUCTION GENERALE
I.1 Contexte de Travail

Les développeurs de logiciels étaient toujours à la recherche de techniques et méthodes leur permettant
d’améliorer la conception de leurs systèmes logiciels, et par conséquent de faciliter leur développement et
évolution. La technique qui a gagné beaucoup de succès depuis des décennies est « la modularisation ». Ce
principe stratégique a comme objectif de réduire simultanément la complexité, le temps et le coût de
développement de logiciel.
La complexité est le grand défi des développeurs. Elle peut évoluer de manière exponentielle avec la
taille du logiciel. Heureusement, la modularisation nous donne des super pouvoirs qui combattent la
complexité. Son principe consiste à décomposer de grands systèmes logiciels complexes en petites parties
gérables. Dans un système logiciel orienté objet (OO) par exemple, les classes jouent le rôle de modules qui
encapsule les méthodes et les variables. Pour les systèmes OO volumineux et complexes, un package peut
jouer le rôle d'un module qui regroupe un ensemble de classes collaboratrices pour fournir des services bien
identifiés au reste du système.
Avec une bonne conception modulaire, il n'y a pas de limite à la hauteur et à la portée du logiciel. Les
modules nous donnent la possibilité d'abstraire une complexité arbitraire derrière des interfaces propres et
simples. Il est même plus facile d'ajouter à un système logiciel des nouvelles fonctionnalités le long de son
évolution. Par conséquent, la modularité est considérée comme le facteur clés de succès de la conception de
logiciels. Elle a un impact significatif sur de nombreux attributs de qualité externes tels que la réutilisabilité,
la maintenabilité et la compréhensibilité de logiciel. Ainsi, proposer des techniques et des métriques pour
analyser et mesurer la modularité du logiciel est très important.
I.2 Problématiques et Motivations

Les mauvais choix de conception aux premières phases de développement de logiciel, et l’application
des tâches de maintenance sans étudier leurs effets négatifs détériorent généralement la modularité du
logiciel et augmentent par la suite la complexité du système. Dans les logiciels orienté objet (OO), une
mauvaise répartition des classes entre les packages est un facteur clé, responsable à la dégradation de la
modularité. Par conséquent, plusieurs travaux de recherche sont effectués pour analyser la modularité des
1
systèmes logiciels afin de détecter les défauts de modularité possibles. Ce type d’analyse est très important
pour les développeurs, puisqu’il aide à localiser les parties du logiciel touchées par un défaut de modularité.
Ensuite, ils peuvent appliquer des techniques adéquates afin d’améliorer la conception en supportant
beaucoup plus la modularité.
Plusieurs travaux de recherche ont utilisé les relations statiques et sémantiques de logiciel pour analyser
sa modularité. Néanmoins, d’autres relations très intéressantes ne peuvent pas être détectées directement à
partir du code source (statiquement ou sémantiquement). De telles relations connues par « dépendances
logiques » ou « dépendances évolutionnaires » peuvent être extraites en analysant le dépôt de l’historique
de l'évolution du logiciel. L’idée consiste à extraire les dépendances cachées dans le dépôt de version i.e. si
deux artefacts logiciels sont souvent changés ensemble, donc il existe une dépendance logique entre eux.
Les dépendances logiques sont beaucoup plus intéressantes que les relations statiques et sémantiques
pour analyser le logiciel, puisqu’elles présentent réellement et explicitement les Co-changements entre les
artefacts logiciels i.e. les artefacts logiciels ont été changés pratiquement ensemble par le développeur.
Plusieurs travaux de recherche ont été effectués pour prouver ça. Parmi ces travaux, celui de Nemitari et al
[NEM17, NEM18] est le plus intéressant. Les auteurs ont analysé 79 projets logiciels orientés objet (open-
source) de différentes tailles pour étudier et comparer les dépendances logiques avec les autres dépendances
statiques et sémantiques. Les résultats de leurs études empiriques ont prouvé que :
Dans 91% des cas, les dépendances logiques impliquaient des fichiers non liés structurellement. En plus,
70% des dépendances sémantiques sont également des dépendances logiques, mais pas l'inverse.
A partir de ces résultats, nous pouvons conclu que les dépendances logiques reflètent beaucoup plus la
réalité par rapport aux autres dépendances. Une grande partie de ces dépendances structurelles et
sémantiques ne sont que des relations théoriques présentées dans la conception du logiciel seulement, mais
les artefacts reliés par ces dépendances ne se changent pas ensemble pratiquement (durant l’évolution du
logiciel). D’un autre côté, plusieurs dépendances cachées (ni statiques ni sémantiques) ne peuvent être
détectées que par une analyse de l’historique d’évolution.
Malgré la grande importance des dépendances logiques, mais elles ne sont pas encore exploitées pour
analyser la modularité de logiciel et détecter les défauts possibles. Pour cela, nous avons basé sur ces
dépendances intéressantes pour proposer notre approche d’analyse de la modularité des systèmes logiciels
OO.
2
1.3 Objectifs et Contributions

Nous nous sommes focalisés sur l’historique d’évolution d’un système logiciel OO pour proposer une
approche d’analyse de sa modularité. Le principe de base consiste à utiliser les dépendances logiques
extraites à partir d’un dépôt de version, afin de générer les relations de cohésion et de couplages logiques
pour chaque package du logiciel OO. Les résultats peuvent nous donner une vue claire sur le niveau de la
modularité du logiciel. En plus, nous pouvons détecter des défauts de modularité, qui peuvent êtes réparés
par le développeur (ou le concepteur) avec des techniques adéquates (ex. refactoring), afin d’améliorer la
modularité du système.
Nous pouvons résumer les contributions principales de notre travail dans les points suivants :
- L’analyse de l’historique de l’évolution d’un système logiciel OO :

o Extraction des transactions de changement à partir d’un dépôt de version ;
o La génération des dépendances logiques sous forme des règles d’association, en utilisant
l’algorithme de Mining « Apriori ».
- L’analyse de la modularité logique :
o L’analyse des règles d’association pour générer les relations de cohésion logique pour chaque
package ;
o L’analyse des règles d’association pour générer les relations de couplage logique pour chaque
package ;
- L’automatisation des tâches précitées à travers un outil Java, ce qui présente un point fort de notre
approche. Ceci facilite l’analyse de la modularité de grands systèmes logiciels OO.
- Nous avons analysé les dépôts de versions de trois applications OO Open-source de taille importante
pour prouver la faisabilité et l’efficacité de notre proposition, et par conséquent de notre outil réalisé.
I.4 Contenu de mémoire

Outre le chapitre Introduction Générale, ce présent mémoire est structuré en cinq chapitres organisés
comme suit :
Chapitre II ─ Nous nous concentrerons dans ce chapitre sur la notion de la modularité d’un système
logiciel de façon général : ses caractéristiques ainsi que son principe, ses mesures. Et de la modularité des
systèmes orientés objet plus spécifiquement. Nous terminerons le chapitre par un état de l’art sur les travaux
de recherches récents traitant la modularité des logiciels.
Chapitre III ─ Dans ce chapitre, nous présenterons les systèmes de contrôle de versions, ses types, les
approches et les logiciels de versioning. Ensuite, nous définirons les dépendances logiques en les
3
comparants avec les autres types de dépendances (statiques et sémantiques). Nous terminerons ce chapitre
par un état de l’art sur les approches de détection des dépendances logiques.
Chapitre IV ─ Il est consacré à notre approche proposée. Nous commencerons par une vue globale de notre
proposition. Ensuite, nous expliquerons en détail les différentes étapes de l’approche, ainsi que la conception
de notre outil réalisé.
Chapitre V ─ Dans ce chapitre, nous présenterons la mise en œuvre bien détaillée de notre approche. En
suite, des expérimentations sont effectuées pour démontrer la faisabilité et la fiabilité de notre proposition.
Chapitre VI ─ Nous clôturons notre mémoire par une conclusion générale, où nous synthétiserons les
principales contributions de notre travail. Et nous discuterons les éventuelles perspectives.
4
CHAPITRE II
LA MODULARITE D’UN SYSTEME LOGICIEL
II.1 Introduction
Tout au long du cycle de vie d’un système logiciel, plusieurs actions de maintenance et d’évolution
telles que l'ajout de nouvelles fonctionnalités, la résolution de problèmes, l'amélioration de la conception, …
etc. peuvent affecter négativement la qualité de la conception du logiciel. Plus spécifiquement la dégradation
de la modularité du logiciel, ce qui peut causer de graves problèmes pour les futurs efforts d’évolution. La
modularité a été considérée comme l'une des propriétés les plus importantes d'une bonne conception de
logiciel ; de nombreuses méthodes et techniques de génie logiciel reposent sur l'hypothèse qu'une structure
modulaire de logiciel peut améliorer sa qualité dans une certaine mesure.
Par conséquent, la modularité a joué un rôle omniprésent dans le contexte de la conception de logiciels,
elle a un impact significatif sur de nombreux attributs de qualité externes tels que la réutilisabilité, la
maintenabilité et la compréhensibilité. En résumé, la modularité peut être considérée comme un principe
fondamental d'ingénierie. Dans ce chapitre nous allons présenter et expliquer la notion de la modularité d’un
système logiciel de façon général, et des systèmes orientés objet plus spécifiquement.
II.2 La Modularité
II.2.1 La conception du logiciel
La phase de conception suit immédiatement la phase d'analyse qui vise à définir une architecture
modulaire du logiciel ou encore une décomposition en modules qui facilitera la maintenance et permettra le
développement parallèle par différents programmeurs. On regroupe en général sous le terme conception
deux étapes distinctes [MOR89] :
- Conception globale : elle permet de définir les choix fondamentaux de l'architecture du logiciel en
liaison avec l'architecture matérielle.
- Conception détaillée : elle décrit précisément chaque module, les algorithmes de mis en œuvre et les
traitements effectués en cas d'erreur. La documentation produite sera très utile en phase de maintenance.
II.2.2 Les principes de la conception

Les principes fondamentaux de conception sont [MAR02] :
La Rigueur,
La séparation des problèmes (separation of concerns),
La modularité,
L’abstraction,
L’anticipation du changement,
La construction incrémentale.
Une bonne conception se définit en termes de la satisfaction des besoins et des spécifications. Les
critères de qualités peuvent donc varier énormément d'un système à un autre ou même pour deux
implantations différentes d'un même système [BOO95].
Une bonne structuration participe largement à la production d'un logiciel qui possède ces
caractéristiques. Comme dans beaucoup de domaine, cette bonne structuration se base sur la Modularité.
II.2.3 Définition de la modularité

Bien qu’il existe plusieurs définitions de la notion de modularité dans la littérature, mais elles tombent
toutes dans le même sens. Nous citons ici les plus fameuses définitions :
Goudey et al. [GOU10] ont définit la modularité comme suit :
«The enhancement of a product can be achieved through the use and arrangement of technologies,
elements or components accessible independently: this is modularity».
Le glossaire standard de l'IEEE sur la terminologie du génie logiciel [IEEE90] définit la modularité
comme le degré auquel un programme système est composé de composants discrets de sorte qu'un
changement à un composant a un impact minimal sur les autres composants.
Donc, la modularité (Figure II-1) est faite référence à un concept consistant à grouper des fonctions en
modules reliés entre eux par des interfaces et à les combiner pour former un système complet. En conception
logicielle, la modularité est opposée au raffinement.
Figure 0II-0-1: La modularité d’un système logiciel
Selon Sosa et al. [SOS06], il existe trois niveaux au concept de modularité : un niveau logiciel, un
niveau système et un niveau composant. Le degré de modularité se mesure en se basant sur le degré de
connectivité entre les composants.
II.2.4 Le module
Un module est un élément de petite taille (un ou quelques sous-programmes) doit être cohérent et
autonome et qui sert, par assemblage à la construction de logiciels. La modularité se fait ressentir dans la
conception et dans la programmation [BOO95].
II.2.5 Le système modulaire

Un système est modulaire s’il est composé de modules. La modularité est une propriété importante de
tous les procédés et les artéfacts. Toute l’évolution des langages de programmation vise à rendre plus facile
une programmation modulaire, appelée aujourd’hui ‘programmation par composants’ [PRZ10].
En génie logiciel, on considère que le développement d’un système logiciel de qualité passe par le
respect de trois critères essentiels concernant le logiciel et ses composants (modules):
La fiabilité : Un module est considéré comme fiable quand on est certain qu’il fonctionne
correctement dans tous les cas de figure.
L’extensibilité d’un logiciel : est la facilité de pouvoir l’étendre (ajout de fonctionnalités) sans
avoir à modifier l’existant.
La réutilisabilité : est la capacité des modules logiciels à pouvoir être réutilisés en partie ou en
totalité pour construire de nouvelles applications logicielles.
II.2.6 A quoi sert la modularité ?

La modularité, comme tout concept à ses raisons, nous pouvons les classer comme suit [ALE16] :
*Raisons de conception :
Maîtrise de la complexité d’un système logiciel en forçant l’abstraction, donc la modularité
augmente la sureté.
Diminution du risque d'erreurs en divisant le logiciel en des petits composants (sous-modules).
Possibilité de tests sélectifs en spécifiant les liens entre les composantes pour rendre les gros projets
maintenables.
Découpage de l’ensemble en composants indépendants pour rendre les gros projets réalisables. Les
composants peuvent être développés et testés séparément.
*Raisons d’organisation :
Développement en équipe.
Réutilisabilité pour d'autres logiciels, par la création des morceaux de programme indépendants de la
problématique globale, donc réutilisables.
*Raisons technologiques :
Contrôle de la taille des fichiers sources et le temps de compilation.
Unité de documentation et de déploiement i.e. Découpage d’un programme en plusieurs unités

physiques (fichiers) qui présentent une unité logique (modules).
II.3 L’historique de la modularité

La programmation modulaire, sous forme de sous-systèmes et de bibliothèques de logiciels, remonte aux
premiers systèmes logiciels, où elle était utilisée pour la réutilisation du code.
Fin de 1960: La programmation modulaire s’est développée comme un analogue à plus grande échelle du
concept de programmation structurée [BRU01].
En juillet 1968 : Le terme «programmation modulaire» date au moins du Symposium national sur la
programmation modulaire, organisé à l'Institut de l'information et des systèmes par Larry Constantine
[LAR68].
En 1970 : Les modules n'étaient pas inclus dans la spécification d'origine pour ALGOL 68 qui est un
langage de programmation universel dérivé du langage Algol 60, mais ont été inclus comme extensions
dans les premières implémentations, ALGOL 68-R, puis formalisés [BRU01].
En 1972 : D'autres concepts clés étaient la dissimulation d'informations et la séparation des
préoccupations [CON07].
En 1975 : AlgolW un des premiers langages conçus dès le départ fut le Modula de courte durée, de
Niklaus Wirth [YOU79].
En 1978 : Wirth s'est inspiré de Mesa ainsi que du Modula d'origine dans son successeur, Modula2, qui a
influencé les langues ultérieures, en particulier à travers son successeur, Modula3 [YOU79].
De 1980 à 1990 : La programmation modulaire a été éclipsée par et souvent amalgamée avec la
programmation OO, en particulier en raison de la popularité de C et Java. Des versions OO des langages
existants ont été développées : C++ pour le C, ADA95 pour le ADA, Object Pascal pour le Pascal, PHP5
pour le PHP,... [JAC05].
En 1991: Python a utilisé de façon proéminente à la fois des modules et des objets dès le début, en
utilisant des modules comme unité principale d'organisation du code et des «packages» comme unité à
plus grande échelle.
En 1995 : Java prend en charge les modules sous forme de packages, bien que l'unité principale
d'organisation du code soit une classe. Cependant, Python a utilisé de manière proéminente les modules et
les objets dès le début, en utilisant les modules comme unité principale d'organisation du code et les
"packages" comme unité à plus grande échelle; et Perl 5 inclut la prise en charge des modules et des
objets, une vaste gamme de modules étant disponible auprès de CPAN [JAC05].
De 1996 à 2000 : instanciation du cadre ODP-RM (Open Distributed Processing – Reference Model) sur
le processus de réingénierie d'un EIAH (Les Environnements Informatiques pour l'Apprentissage
Humain). Le modèle de référence choisi se présente comme un cadre de coordination pour la
standardisation des processus distribués ouverts en définissant avec beaucoup de détails un ensemble de
concepts issus des pratiques de développement [JAC05].
En 2008 : La version d'UML en cours est UML 2.1.1 et les travaux d'amélioration se poursuivent
[TUR12].
De 2009 à 2014 : la modularité OO est devenue particulièrement populaire. Python, PowerShell , Ruby et
Groovy sont des langages dynamiques construits sur les principes de la POO, alors que Perl et PHP ont
été l' ajout de fonctionnalités orientées objet depuis Perl 5 et PHP 4 et ColdFusion depuis la version 6.
Ainsi que la maintenance logicielle s’est développée [BAL19].
De 2014 jusqu’à présent : La programmation modulaire est maintenant répandue et se retrouve dans
pratiquement tous les principaux langages développés depuis les années 1990.
II.4 Les préceptes de la modularité

B. Meyer a énoncé des préceptes qui sont essentiels et sont adoptés par tous ceux qui pratiquent des
méthodes de programmation modulaire [MEY16] :
Cartographie directe : La structure modulaire conçue dans le processus de construction d'un
système logiciel doit rester compatible avec toute structure modulaire conçue dans le processus
modélisant le monde réel.
Peu d'interfaces : Chaque module doit communiquer avec peu d’autres que possible. Un module
fixé doit ne communiquer qu’avec un nombre "minimum" d’autres modules du logiciel. L’objectif
est de minimiser le nombre d'interconnexions entre les modules. Le graphe établissant les liaisons
entre les modules est noté " graphe de dépendance ".
Petites interfaces (Couplage minimal) : Lorsque deux modules communiquent entre eux, l’échange
d’information doit être minimal. Il s'agit de minimiser la taille des interconnexions entre modules et
non leur nombre comme dans le précepte précédent.
Interfaces explicites : à chaque fois que deux modules A et B communiquent, cela doit être évident
à partir du texte de A ou B ou tous les deux.
Masquage des informations : Le concepteur de chaque module doit sélectionner un sous-ensemble
des propriétés du module en tant que informations sur le module, à faire disponible pour les
développeurs de modules clients.
Principe ouvert-fermé : les unités de conception et de construction doivent être à la fois ouvertes
(élargir son ensemble d'opérations et ajouter des champs à ses structures de données) et fermées (Il
possède une interface stable et bien définie).
Information publique et privée : Toute information dans un module doit être répartie en deux
catégories : l’information privée et l’information publique.
 La partie publique : doit être la description des opérations ou du fonctionnement du module.
 La partie privée : contient l’implantation des opérateurs et tout ce qui s'y rattache.
II.5 Les métriques de la modularité

Les approches actuelles d'évaluation quantitative de la modularité des systèmes logiciels définissent et
utilisent des métriques intéressantes. Certaines métriques ciblent la conception architecturale et sont définies
en fonction d'abstractions telles que des composants, des modules ou des packages. D'autres mesures se
concentrent sur la modularité de la conception détaillée et sont enracinées dans des abstractions telles que les
classes et les méthodes [GUA15].
Les deux fameuses métriques utilisées sont le couplage et la cohésion. Ils ont été inventés par Larry
Constantine à la fin des années 60 dans le cadre de la conception structurée [BRI01], sur la base des
caractéristiques de bonnes pratiques de programmation qui réduisaient les coûts de maintenance et de
modification. Un faible couplage et une forte cohésion ont été considérés comme les principaux moteurs de
la conception modulaire.
II.5.1 La cohésion
II.5.1.1 Définition
La cohésion est la « connexion intérieure » entre les propriétés d'une unité de conception ou de
construction. Le principe de cohésion maximale nécessite un lien fort au sein d'une unité de conception ou
de construction [GUA15]. Si notre module effectue une seule tâche, ou a un objectif clair, notre module a
une forte cohésion. D'un autre côté, si notre module essaie d'encapsuler plus d'un objectif ou a un objectif
n’est pas clair, notre module a une faible cohésion.
La cohésion est souvent opposée au couplage. Une cohésion élevée est souvent corrélée à un faible
couplage, et vice versa.
Avantages d'une cohésion élevée :

 Complexité réduite des modules (ils sont plus simples, ont moins d'opérations).
 Maintenabilité accrue du système, car les changements logiques dans le domaine affectent moins de
modules et parce que les changements dans un module nécessitent moins de changements dans les
autres modules.
 Réutilisation accrue du module, car les développeurs d'applications trouveront plus facilement le
composant dont ils ont besoin parmi l'ensemble cohérent d'opérations fournies par le module.
II.5.1.2 Les types de la cohésion

Dans la programmation, la cohésion peut être appliquée à n’importe quel niveau de granularité. Elle a été
classée par Yourdon et Constantine [YOU79] comme suit :
Cohésion accidentelle ou aléatoire ou coïncidence : le module contient plusieurs fonctions sans

aucune liaison entre elles. Cette condition représente une absence de cohésion.
Cohésion logique : dans un module, les éléments participent à des activités de la même catégorie.
Les composants sont groupés parce qu'ils partagent des opérations.
Cohésion temporelle : dans un module, les éléments coopèrent dans des activités liées dans le
temps.
Cohésion procédurale : dans un module avec cohésion procédurale les éléments sont impliqués
dans des activités différentes et potentiellement sans lien, mais les données transitent d'un élément à
l'autre.
Cohésion communicationnelle : les divers éléments contribuent à des activités qui utilisent les
mêmes données d'entrée ou de sortie.
Cohésion séquentielle : le module effectue plus d'une fonction en suivant l'ordre défini par la
spécification.
Cohésion fonctionnelle : selon le critère de fonctionnalité, un module a une bonne cohésion si le
module accomplit une seule tâche particulière et que tous ses éléments y contribuent.
Pressman [PRE97] représente les degrés de la cohésion, introduits par Yourdon et Constantine. Sous la
forme d'un spectre :
Figure 0II-0-2: Spectre du degré de la cohésion. [PRE97].
II.5.1.3 Exemples de mesures de cohésion

Les plus mesures utilisées pour la cohésion sont : [JOH14]
La cohésion des relations (H) : mesure le nombre moyen de relations internes par type. Étant donné
N types et R relations internes : H = (R + 1) /N. Une plage appropriée est de 1,5 à 4.
Le manque de cohésion des méthodes (LCOM) : LCOM a la plage 0 à 1. Zéro est idéal. Sa
variante LCOM Henderson-Sellers (LCOM HS) a la gamme 0 à 2.
II.5.2 Couplage
II.4.2.1 Définition
Il a été défini comme la mesure de la force de l'association établie par une connexion d'un module avec un
autre [STE74]. Cette notion a évolué donnant comme définition : le degré d'interdépendance entre modules
[YOU79].
Nous pouvons dire alors que le couplage (Figure II-3) est la relation entre différentes unités de conception
ou de construction. Le couplage minimum tente de réduire la liaison entre les unités, en particulier pour
éviter une utilisation cyclique.
Figure II-0-3: Couplage entre les modules.
II.4.2.1 Propriétés du couplage

Dans le couplage, nous devons prendre en compte certaines propriétés [ZHA18] :
Degré : est le nombre de connexions entre le module et les autres.

Facilité : est à quel point les connexions entre le module et les autres sont évidentes. On veut que les
connexions soient faciles à réaliser sans avoir besoin de comprendre les implémentations des autres
modules.
La flexibilité : est la mesure dans laquelle les autres modules sont interchangeables pour ce module.
Avec le couplage, on veut que les autres modules soient facilement remplaçables pour quelque chose
de mieux à l'avenir.
Inconvénients du couplage serré :
 Un changement dans un module force généralement des changements dans d'autres modules.
 L'assemblage des modules peut nécessiter plus d'efforts ou de temps en raison de la dépendance accrue
entre les modules.
 Un module particulier peut être plus difficile à réutiliser ou à tester car des modules dépendants
doivent être inclus.
II.4.2.2 Types de couplage
Figure II-0-4:Types de couplage [YOU79]
Dans sa catégorisation, on distingue sept types de couplage, voici une brève description de
chacun [ZHO17] :
Couplage indirect : Il n'y a pas de couplage direct entre deux modules P1 et P2. Au niveau du
package, cela impliquerait que dans deux packages mesurées il n'y aura pas de références l'une vers
l'autre.
Couplage de données : lorsque les données d'un package sont transmises à un autre package, cela
s'appelle le couplage de données.
Couplage par timbre « Stamp » : ce type ressemble au couplage de données, mais dans le couplage
« stamp » les paramètres échangés sont des structures de données complètes i.e. au lieu de donner
toute la structure en paramètre il est préférable de donner seulement les membres ou les données dont
elle a vraiment besoin.
Couplage de contrôle : il existe entre deux packages si les données d'un package sont utilisées pour
diriger la structure d'exécution des instructions dans un autre.
Couplage externe : Un package est lié à quelque chose d'extérieur au logiciel. Au niveau de la
classe du package, cela se présente avec les bibliothèques externes.
Couplage commun : lorsque dans une classe il y a plusieurs méthodes qui partagent un même
ensemble de données. Un cas concret de ce type de couplage est l'utilisation des variables globales.
Couplage de contenu : le couplage de contenu existe entre deux packages s'ils partagent du code.
Pressman [PRE97] montre les degrés de couplage sous forme d’un spectre comme suit :
Figure II-5: Spectre du degré de couplage [PRE97].
II.4.2.3 Exemples de mesures de couplage

Comme la cohésion a des mesures, le couplage se mesure par [LEE95] :
Le couplage afférent (Ca) : mesure le nombre de types dans d'autres modules qui dépendent des
éléments de ce module. Une valeur élevée implique un module avec de nombreuses responsabilités.
Le couplage efférent (Ce) : mesure le nombre de types depuis l'extérieur du module utilisé dans ce
module. Une valeur élevée implique un module fortement dépendant des autres.
Ces métriques pourraient être appliquées à des types, des champs, des méthodes, des espaces de noms,
etc. Le rapport : Ce / (Ce + Ca) est appelé Instabilité, qui mesure la résilience d'un module au changement.
Une valeur de 0 est idéale.
II.5.3 Cohésion versus couplage

Vous trouverez ci-dessous un tableau illustrant la différence entre la cohésion et le couplage :
Cohésion Couplage
L’indication de la relation au sein du module. L’indication des relations entre les modules.
Montre la force fonctionnelle relative du Montre l’indépendance relative entre les

module. modules.
Un degré (qualité) auquel un module se Un degré auquel un module est connecté aux
concentre sur une seule chose autres modules
Lors de la conception, on doit viser une Lors de la conception, on doit viser un
cohésion élevée. couplage faible.
Le type d'extension naturelle du masquage Faire des champs privés, des méthodes
des données, par exemple, une classe ayant privées et des classes non publiques fournit
tous les membres visibles avec un package un fiable couplage.
ayant une visibilité par défaut.
La cohésion est un concept intra-module Le couplage est un concept inter-module
Tableau II-1: Comparaison entre la cohésion et le couplage.
Idéalement, nous devrions viser une cohésion élevée et un couplage faible. Les parties de code associées
doivent être dans le même module. Chaque module doit être indépendant des autres et interagir de manière
minimale. En pratique, un module peut être l'un de ceux-ci, à différents niveaux d'abstraction : dossier,
fichier JavaScript, classe C ++, assemblage C #, package Java, …etc. [ZHO17].
Appliquer le principe de responsabilité unique (PRU) pour une cohésion élevée. Utilisez des interfaces
bien définies et une inversion de contrôle pour un couplage faible [OFF08].
Exemple : l’exemple dans la figure II-6 montre la cohésion au sein des modules A, B et C, et le couplage
entre eux. Les sous-modules sont numérotés de 1 à 10.
Figure II-6: Exemple sur la cohésion et le couplage.
II.6 La modularité et les systèmes orientés objet

Nous sommes intéressés dans notre travail par le principe de la modularité des systèmes orientés objet.
II.6.1 Le modèle orientés objet

Le cadre conceptuel des systèmes orientés objet (OO) est basé sur le modèle objet. Il existe deux catégories
(Figure II-7) d’éléments dans un système OO [KAS11] :
Éléments majeurs : Par majeur, on entend que si un modèle n’a aucun de ces éléments, il cesse
d’être orienté objet. Les quatre principaux éléments sont les suivants :
 Abstraction : Les entités objets de la POO sont proches de celles du monde réel. Les
concepts utilisés sont donc proches des abstractions familières que nous exploitons.
 Encapsulation: masquage de la mise en œuvre effective du module, du “comment c’est fait”.
Seuls les éléments accessibles de l’extérieur sont visibles et spécifiés précisément. Ils
définissent les droits d'accès public, privée ou protégée.
 Modularité : comme nous avons déjà présenté dans les sections antérieures, c’est la capacité
qu'a un système d'être décomposé en un ensemble de modules cohérents et faiblement
couplés.
 Hiérarchie : on définit une hiérarchie comme étant un classement ou un ordonnancement des
abstractions selon :
 Héritage => généralisation / spécialisation ("genre de").
 Agrégation => composition par regroupement ("partie de")
Figure II-7: Les principes des systèmes OO
Éléments mineurs : Par mineur, on entend que ces éléments sont utiles, mais ne font pas partie
indispensable du modèle objet. Les trois éléments mineurs sont :
 Dactylographie : c’est l’application de la notion qu’un objet est une instance d’une seule
classe ou d’un seul type. Elle fait également respecter le fait que des objets de différents types
ne peuvent généralement pas être échangés que de façon très restreinte si cela est absolument
nécessaire.
 Concurrence : il y a des objets actifs et inactifs. Les objets actifs ont des threads de contrôle
indépendants qui peuvent s’exécuter en même temps avec les threads d’autres objets. Les
objets actifs se synchronisent entre eux ainsi qu’avec des séquences purement séquentielles.
 Persistance : Dans les fichiers ou les bases de données, la durée de vie de l’objet est plus
longue que la durée du processus de création de l’objet. Cette propriété par laquelle un objet
continue d’exister même après que son créateur cesse d’exister.
La figure II.8 présente un exemple de Meta modèle orienté objet.

Figure II-8: Exemple d'un méta-modèle OO
II.6.2 La modularité dans un logiciel orientée objet

Elle est définie comme la capacité qu'a un système OO d'être décomposé en un ensemble de modules
cohérents et faiblement couplés [ZEL19]. Un objet se compose d'un ensemble de variables d'instance
représentant l'état interne de l'objet et d'un ensemble de méthodes représentant le comportement externe de
l'objet. En d'autres termes, un objet est une encapsulation d'un état et d'un comportement.
Figure II-9: Modules et Classes.
II.6.3 Critères de modularisation d’un logiciel OO

Pour faciliter le transfert du concept modulaire vers l'OO, Bertrand Meyer a proposé une liste de critères et
de règles. Nous présenterons ici brièvement certains de ces derniers [MIC19] :
1 Décomposabilité: Capacité de décomposer un problème en sous-problèmes, semblable à la méthode

structurée descendante. Exemple : modules issus d'une conception descendante. Contre-exemple :
module d'initialisation globale.
2 Composabilité: Les modules peuvent facilement être utilisés et combinés, éventuellement dans des
contextes différents de ceux pour lesquels ils ont été initialement développés .Exemple :
bibliothèque de sous-programmes
3 Compréhension : Capacité à l’interprétation par un programmeur du fonctionnement d’un module
ou d’un ensemble de modules liés, sans avoir à connaître tout le logiciel. La compréhension d'un
module ne nécessite pas la compréhension des autres.
4 Continuité : Capacité à réduire l’impact de changements dans les spécifications à un minimum de
modules liés entre eux, et mieux à un seul module. Des petites modifications de spécification
n'amènent pas à revoir l'ensemble du logiciel (~ extensibilité, évolutivité). Exemple : constantes
symboliques, références uniformes.
5 Protection : Capacité à limiter les effets produits par des incidents lors de l’exécution à un nombre
minimal de modules liés entre eux, mieux à un seul module. Si une condition anormale se produit
pendant l'exécution du module, elle reste localisée au module (ou à quelques modules voisins).
Exemple : validation des données d'entrées au plus tôt.
II.6.4 Les Principes de la modularisation orientée objet

Une cohésion maximale et un couplage minimal sont les facteurs fondamentaux de la conception modulaire
traditionnelle et des logiciels OO aussi.
II.6.4.1 Cohésion orienté objet

La cohésion fait référence au degré d'appartenance des éléments à l'intérieur d'un module. Dans le
paradigme OO, c'est une mesure de la force de la relation entre les méthodes et les données d'une classe et
un objectif ou concept unificateur servi par cette classe. Dans un autre sens, c'est une mesure de la force de
la relation entre la méthode de la classe et les données elles-mêmes [HAN11].
Le principe de responsabilité unique vise à créer des classes hautement cohésives [SUR15]. La cohésion
est élevée si :
1. Les fonctionnalités embarquées dans une classe, accessibles via ses méthodes, ont beaucoup en
commun.
2. Les méthodes réalisent un petit nombre d'activités connexes, en évitant des ensembles de données à
gros grain ou sans rapport.
Exemple sur la cohésion OO
Figure II-10: Exemple sur la cohésion OO [SUR15]
La Figure II-10 illustre un exemple sur la cohésion de classe. On distingue que dans la cohésion faible,
une seule classe est chargée d'exécuter beaucoup de tâches qui ne sont pas en commun. Cela réduira les
chances de réutilisation et de maintenance. En haute cohésion, il existe une classe distincte pour exécuter
une tâche spécifique, ce qui résulte en une meilleure réutilisation et maintenance.
Les types de la cohésion de classe :

En OO, les modules désignent les classes. Les éléments de la classe peuvent être à leur tour soit des
méthodes soit des classes. Les éléments d'une méthode représentent des instructions et des variables
[EDE95]. La distinction entre la cohésion d'une méthode et la cohésion d'une classe est fondamentale
[CHI94]. La cohésion des classes décrit la liaison des éléments définis à l'intérieur de la classe.
Un modèle de classification de cohésion est établi en prenant comme modèle la cohésion des types
abstraits de données [ALE16] :
1. Séparable : la cohésion d'une classe est classifiée séparable si l'objet représente de multiples
abstractions de données n'ayant aucune relation entre elles. C'est le cas d'une classe possédant une
méthode qui n'accède à aucune variable d’instance et n'invoque aucune des autres méthodes de la
classe.
2. Multi-facette : une classe est classifiée multi-facette si ses éléments représentent de multiples
abstractions de données liées entre elles et accessibles par au moins une méthode. Effectivement, au
moins une méthode accède à une variable d’instance ou invoque une méthode appartenant à un
concept sémantique distinct.
3. Non-déléguée : une classe est classifiée non-déléguée si elle n'est pas séparable, n'est pas multi-
facette et au moins une méthode utilise une variable d’instance décrivant seulement un composant de
la classe.
4. Cachée : une cohésion est classifiée cachée si une abstraction de données est cachée dans
l'abstraction de données représentées par la classe. Des variables d’instance et des méthodes peuvent
être vues comme une nouvelle classe à part entière.
5. Modèle : la cohésion modèle est le degré le plus élevé de la cohésion de classe. Elle indique une
classe représentant un seul concept sémantique, aucune de ses méthodes ne peut être déléguée à une
classe, et elle ne renferme pas de classes cachées.
II.6.4.2 Couplage orienté objet

Le couplage est le degré d'interdépendance entre les classes (ou les packages) ; une mesure de la
proximité de modules ; ou la force des relations entre les modules. Le couplage augmente entre deux classes
A et B si :
A a un attribut qui fait référence à (est de type) B.
A fait appel aux services d'un objet B.
A a une méthode qui référence B (via un type de retour ou un paramètre).
A est une sous-classe de (ou implémente) la classe B.
Un couplage faible fait référence à une relation dans laquelle un module interagit avec un autre module
via une interface simple et stable et n’a pas besoin de se préoccuper de l’implémentation interne de l’autre
module.
A. Types de couplage entre les classes
Une catégorisation du couplage applicable à la programmation OO, notamment au niveau de la classe, a été
faite [EDE95]. Dans cette catégorisation on distingue trois types de couplage :
1. Couplage d'Interaction : il survient lorsqu’une classe invoque une ou plusieurs méthodes de l'autre.
Couplage de Contenu : c'est le pire des couplages. Il signifie qu'une méthode accède directement
à l'implantation d'une méthode appartenant à une autre classe. Une telle méthode doit donc
parfaitement connaître la structure interne de la méthode qu'elle accède. En effet, tout changement
dans une méthode influence l'autre.
Couplage Commun : il signifie que plusieurs méthodes partagent un même ensemble de
données. Le couplage commun est meilleur que le couplage de contenu, dans le sens que toutes les
communications implicites sont regroupées dans un endroit commun. Néanmoins, le nombre de
communications entre les différentes méthodes est polynomial, et le principe de localité d'une bonne
conception orientée objet n'est pas considéré.
Couplage Externe : Dans ce type de couplage, les données partagées sont structurées de telle
manière à faciliter leurs accès par les différentes méthodes. Cependant, le principe de localité
[Pres97] n'est toujours pas respecté, et la plupart des inconvénients du couplage externe sont toujours
présents.
2. Couplage d'Héritage : deux classes présentent un couplage d'héritage si une des deux classes est
directement ou indirectement une sous-classe de l'autre.
3. Couplage de Contrôle : une classe présentant un couplage de contrôle communique avec une méthode
d'une autre classe à travers le passage de paramètres.
Couplage "Stamp" : deux classes présentent un tel couplage, si deux de leurs méthodes
respectives se passent comme paramètre une structure de données entière alors qu'une partie de
cette structure aurait suffi.
Couplage de Données : deux classes présentent un couplage de données, si elles échangent des
données seulement en paramètres. Ce type de couplage est le plus recommandé dans les systèmes
orientés objet. Le couplage de données minimise l'effort de maintenance grâce aux restrictions de
la propagation des changements.
Couplage Non-direct : deux méthodes ne dépendent pas directement l'une de l'autre. Chaque
changement dans une des méthodes n'influence aucune autre méthode.
Couplage de Composant : une classe, utilisant comme variable d’instance une autre classe,
présente un couplage de composant avec cette dernière.
B. Couplage entre paquets (Packages)
Dans la programmation OO, la classe n'est jamais était un élément suffisant pour une bonne description de la
modularité d'un projet logiciel au complet. A ce niveau-là, il est indispensable de disposer d'un constituant
de granularité plus élevée et important pour une excellente représentation d’un système à une échelle
appropriée. Ces composants sont les Packages [STE17].
Dans [WAR04] un ensemble de principes qui s'appliquent au niveau des packages sont présentés. Voici
une brève description de quelques-uns :
Le principe des dépendances acycliques (ADP Acyclic Dependencies Principle) : Ici, les
dépendances entre les packages doivent, former un graphe acyclique. Ce principe est trop utilisé dans
un grand projet et les packages ont été utilisés comme éléments pour distribuer le travail.
Le principe des dépendances stables (SDP, Stable Dependencies Principle) : Selon ce principe,
une mauvaise dépendance est celle qui dépend d'éléments très volatils. Au contraire, une bonne
dépendance est celle qui dépend d'éléments très stables. Par conséquent, c’est plus difficile de
changer un module.
II.7 Etat de l'Art sur les travaux traitants la modularité des systèmes
orientés objet
Morris [MOR89] : a mesuré la cohésion du module en quantifiant le fan-in des objets que le module
contient.
Eder et coll [EDE92]: ont défini trois types de cohésion dans les systèmes logiciels OO, c'est-à-dire la
cohésion de méthode, la cohésion de classe et la cohésion d'héritage.
Patel et coll [PAT92]: ont proposé une métrique pour mesurer la cohésion des sous-programmes en
quantifiant la similitude entre différentes paires de sous-programmes.
Chidamber et Kemerer [CHI94]: ont proposé le manque de cohésion dans les méthodes (LCOM) pour
mesurer la cohésion de classe.
Chidamber et Kemerer [CHI94]: ont proposé une suite de métrique CK (Chidamber&Kemerer) pour
mesurer les couplages logiciels.
Bieman et Kang [BIE95]: ont défini deux métriques de cohésion de classe, Tight Class Cohesion
(TCC) et Loose Class Cohesion (LCC), pour mesurer la cohésion de classe en comptant le nombre de
paires de méthodes dans une classe qui accèdent aux attributs communs.
Lee et Liang [LEE95]: ont défini une métrique Information CoHesion (ICH) basée sur le flux
d'informations.
Briand et coll [BRI99]: ont appliqué un graphe d'interaction pour représenter la structure du logiciel et
proposé une suite de métriques de cohésion.
Brito et Goulão [BRI01]: ont analysé la modularité de la conception des systèmes OO. À ce niveau
d'abstraction, le module est un ensemble de classes. Ils ont utilisé les informations sur les dépendances
entre les classes pour évaluer la modularité.
Bansiya et Davis [BAN02]: ont défini une métrique, Cohesion Among Methods of Classes (CAMC),
pour mesurer la cohésion de classe en quantifiant la similitude des méthodes en fonction de leurs listes
de paramètres.
Martin [MAR02]: a défini une métrique, la cohésion relationnelle (RC), pour mesurer la cohésion d'un
package en utilisant le rapport du nombre de relations de données et du nombre de composants dans un
package.
Jenkins et coll [JEN07]: ont défini une métrique, Icc, pour mesurer la stabilité du logiciel en fonction
des classes et de leurs couplages.
Ardourel et Huchard [ARD08]: ont étudié l'encapsulation et la modularité dans les langages orientés
objet avec Access Graphs.
Jeff et al. [OFF08]: ils ont utilisé les interdépendances complexes des langages OO pour définir les
types de couplage. Ils se concentrent sur les couplages interclasses plutôt que sur les couplages intra-
classes. Les couplages intra-classes sont les mêmes pour les logiciels orientés objet et procéduraux
Varun et Chhabra [GUP10]: une nouvelle métrique est proposée pour mesurer la cohésion au niveau
des package afin d'obtenir des packages de bonne qualité.
Przybylek [PRZ10]: a réalisé une évaluation empirique de l'impact de la programmation orientée aspect
sur la modularité logicielle.
Christian et al. [KAS11]: ont distingués deux notions de modularité, de cohésion sans interfaces et
avec interfaces.
Abdeen et Ducasse [ABD11]: ont fourni un ensemble complémentaire de mesures qui évaluent certains
principes de modularité pour les packages de grands logiciels OO hérités: principes de masquage des
informations, de capacité de modification et de réutilisation.
Cherait [CHE14] : a exposé une approche basée sur l'histoire qui détecte les défauts de modularité dans
les logiciels orientés aspect évolués. Les modifications sont formulées sous forme de règles de
réécriture et enregistrées dans le dépôt lorsqu'elles sont appliquées. Ce dernier est analysé pour détecter
les patterns de changement dans l'évolution du logiciel AspectJ.
Eder et al. [EDR14]: ont introduit une taxonomie complète des propriétés de couplage et de cohésion
des systèmes orientés objet et fournir des lignes directrices pour améliorer ces propriétés.
Guan et al. [GUA15]: ont exploré la structure communautaire dans les systèmes logiciels et mesuré la
cohésion de classe à l'aide de techniques de détection communautaire.
Clyde et Lascano [CLY17]: ont proposé des définitions unifiées initiales pour la modularité,
l'abstraction et l'encapsulation qui sont applicables à plusieurs paradigmes de programmation OO. Il
montre ensuite que ces définitions unifiées ne sont pas redondantes mais complémentaires les unes des
autres.
Laval [LAV17] : a proposé une analyse des dépendances des packages dans les systèmes OO qui aide à
la re-modularisation. Elle concerne les trois domaines de recherche suivants : Comprendre les
problèmes de dépendance entre packages, mettre en évidence les dépendances cycliques au niveau des
packages et de proposer des dépendances qui devraient être changées.
Gu et al. [GU17]: une nouvelle métrique de cohésion basée sur des réseaux complexes (CBCN) pour
mesurer la connectivité des membres de la classe a été développée principalement en calculant le
coefficient de regroupement moyen de la classe à partir de graphiques représentant les modèles de
connectivité des différents membres de la classe.
Gu et al.[GU17a]: ont proposé une nouvelle métrique pour mesurer la cohésion de classe basée sur le
calcul du coefficient de regroupement moyen du réseau logiciel au niveau de la classe.
Zhang et al. [ZHA18]:ont appliqué des techniques de détection communautaire pour mesurer la
cohésion d'un système logiciel.
Xiang et al. [XIA19]: ont introduit la théorie des réseaux complexes dans l'ingénierie logicielle et ont
utilisé une métrique largement utilisée dans le domaine de la détection communautaire dans la recherche
de réseaux complexes, pour mesurer la modularité du logiciel dans son ensemble
II.8 Conclusion
Nous avons présenté dans ce chapitre, la notion de modularité en général et au niveau des systèmes OO
spécifiquement. Une forte cohésion au sein des modules et un faible couplage entre eux sont la clé vers à
une bonne modularité des systèmes logiciels. A la fin de ce chapitre, nous avons donné un bref état de l’art
sur les travaux traitants la modularité des systèmes OO.
En étudiant les travaux dans ce domaine de recherche, nous avons constaté que chaque travail utilise un
type de dépendances donnés (statiques, sémantiques, …) pour analyser la modularité du système. Mais
aucun travail n’a utilisé un type de dépendances très intéressant et qui représente un domaine de recherche
actif actuellement, ce qu’on appelle « les dépendances logiques ». Ces dépendances sont très intéressantes
puisque qu’elles sont extraites à partir de l’historique d’évolution du logiciel. Par conséquent, elles peuvent
donner une vue plus exacte sur la modularité du logiciel et son évolution à travers le temps. Cela nous a
inspiré pour proposer notre approche. Nous présenterons ce qu’on signifie par une dépendance logique et les
techniques utilisés pour les extraire dans le chapitre suivant.
CHAPITRE III
LA DETECTION DES DEPENDANCES LOGIQUES :
FOUILLE DE DONNEES
III.1 Introduction
Dans le cycle de vie d’un logiciel, l’évolution est la phase la plus importante. Le développeur fait
évoluer son logiciel pour améliorer ses fonctionnalités existantes, ou pour ajouter des nouvelles
fonctionnalités afin de l’adapter à son environnement. L’historique de l’évolution de logiciel géré par
les systèmes de contrôle de versions présente une source très riche d’information autour de ce
logiciel. L’analyse de cet historique d’évolution est une zone de recherche très active actuellement, à
travers laquelle le développeur peut extraire des méta-informations intéressantes pour l’aider à
comprendre l’évolution du logiciel et prédire ses futurs changements.
Dans ce chapitre, nous présentons le principe de fonctionnement d’un système de contrôle de

versions (SCV). Ensuite, nous explorons le domaine de l’analyse de l’historique de l’évolution d’un
système logiciel en focalisant sur la génération des dépendances logiques.
III.2 Les Systèmes de Contrôle de Versions (SCVs)

Pour un processus de développement de logiciel, et pour plus de quatre décennies, les SCVs sont
considérés comme la base de son infrastructure.
III.2.1 Définition des SCVs

Les systèmes de contrôle de versions ou connus par "Revision Control Systems" (RCSs) sont une
catégorie d'outils qui aide les équipes de développement à gérer les changements du code source à travers le
temps. Le contrôle de version garde la trace de chaque modification dans une sorte de base de données assez
spéciale [SUB18]. Si une erreur est commise, les développeurs peuvent retourner en arrière et comparer les
versions précédentes du code pour aider à la réparer tout en perturbant le moins possible l’équipe toute
entière.
Ils ont été créés pour répondre à des besoins initiaux :
La gestion de l'évolution des fichiers d'un projet et de leur historique de modifications.

Figure III-00-5: Conserver l’historique
Supporter principalement une meilleure collaboration asynchrone entre les développeurs i.e. les
SCVs permettent la gestion de différentes versions dans une équipe de développeurs coopérants, tel
que chaque membre peut extraire, modifier certains fichiers, puis les archiver à nouveau.
Figure III-00-6:Travail collaboratif
Meilleure sécurité en garantit l’intégrité, disponibilité et confidentialité. Car seuls les développeurs
autorisés peuvent avoir accès aux informations. Chacun doit prouver son identité par l'usage de
code d'accès. Les versions de logiciels doivent être exactes et complètes.
III.2.2 Les types des systèmes de contrôle de versions

Les SCVs sont classés en trois types :
Les systèmes de contrôle de versions locaux (Local VCS): La plupart des développeurs, pour
contrôler les versions de leur travail, copient les fichiers dans un autre répertoire, peut être un
répertoire associe à la date et l'heure de la modification effectuée. C'est la manière la plus simple de
le faire, mais c'est aussi la moins fiable puisqu'elle peut être une vraie source d'erreurs.
Figure III-00-7: Modèle des systèmes de contrôle de versions locaux
Il est facile d'oublier le répertoire dans lequel nous sommes et de modifier accidentellement dans le
mauvais fichier, ou bien écraser une nouvelle version de notre travail par une ancienne. Pour
remédier à ce genre de problème, les programmeurs ont développé des SCVs locaux (Figure III.3), ce
sont des petits systèmes avec une simple base de données qui garde tous les changements des fichiers
sous contrôle [CHE14]. On peut citer par exemple : CVS, Subversion et Perforce. Néanmoins, ce
genre de système souffre d’un inconvénient, c’est que, si la machine ou le disque dur qui contient la
base de données tombe en panne, tout le travail est perdu.
Les systèmes de contrôle de versions centralisés (Centralized VCS) : ils stockent toutes les
versions des fichiers dans un seul serveur central. Les développeurs interagissent avec ce dernier
pour récupérer (faire des checkout) leurs fichiers et contrôler leurs versions.
Figure III-00-8:Modèle des systèmes de contrôle de versions centralisés

Figure III-00-9:Modèle des systèmes de contrôle de versions distribués
Les systèmes de contrôle de versions distribués (Distibuted VCS) : Dans ce type de SCVs,
comme Git, Mercurial et autres, les développeurs n'extraient plus seulement (checkout) le dernier
snapshot des fichiers, mais ils dupliquent complètement le dépôt (Figure III.5). Ainsi, si un serveur
tombe en panne, l'un des dépôts des développeurs pourra être copié sur le serveur pour le restaurer.
Chaque checkout est vraiment une sauvegarde complète de toutes les données (les changements)
[CHE14].
III.2.3 Les approches de Versioning

Petra Broche et al. [BRO12] ont subdivisé les approches de versioning en quatre types :
Les approches basées texte : Ce type d’approche est basé uniquement sur la représentation
textuelle d'un artefact logiciel en termes de fichiers texte. Leurs principaux avantages sont
[BRO12] :
 Leur indépendance des langages de programmation utilisés dans les objets sous contrôle.
 La simplicité et l'efficacité.
Les approches basées graphes : Ils fonctionnent sur une représentation graphique à base d'un
artefact logiciel pour réaliser la détection des conflits et de fusionnement (Merging) plus
précisément [MES13].
Les approche basées état : Ils comparent les états (versions) d'un artefact logiciel pour identifier
les différences (delta) entre ces versions et de fusionner toutes les différences qui ne sont pas en
contradiction avec les autres [MES13]. De telles approches peuvent être appliqués à deux états,
two-way merging ou à trois états, appelé three-way merging (voir la section III.2.5.2).
Les approche basées opération : Ils ne fonctionnent pas sur les états d'un artefact, mais
sur les séquences d'opérations qui ont été appliquées simultanément à la version
originale [BRO12].
III.2.4 Les outils de versioning

Actuellement, il y a plusieurs types de SCVs désignés par deux facteurs : leurs structures et leur
démarche. On trouve généralement deux grands types : libres et propriétaires (commerciales). Le tableau
ci-dessous illustre quelques exemples :
Gestion locale GNU RCS (1982) · GNU CSSC

Libres
Client-serveur CVS (1990) · CVSNT (1992) · SVN (2000)
GNU arch (2001) · Darcs (2002) · DCVS
(2002) · SVK (2003) · Monotone (2003) · Codeville
Décentralisé
(2005) · Git (2005) · Mercurial (2005) · Bazaar (2005) · Fossil (
2007) · Veracity (2011) · Pijul (2015)
Gestion locale SCCS (1972) · PVCS (1985)

Propriétaires
Rational ClearCase (1992) · CCC/Harvest (années 70) ·

CMVC (1994) · Visual SourceSafe (1994) · Perforce (1995)
Client-serveur · AccuRev SCM (2002) · Sourceanywhere (2003) ·
Team Foundation Server (2005) · Rational Synergy (2006)
· Rational Team Concert (en) (2008)
Décentralisé BitKeeper (1998) · Plastic SCM (2007)
Tableau III-0-2: Les logiciels de versioning [ALT09].
III.2.5 Principe de base des systèmes de contrôle de versions

III.2.5.1 Concepts de base
Les notions de base sont les suivantes :
Copie locale : Copie d’une version en local (espace de travail d'un développeur).
Check-out : Chaque utilisateur a une copie d'une version particulière des fichiers, habituellement la
dernière. Il peut accomplir cette copie locale à travers la commande check-out. Cette opération crée
une copie de la révision pour être modifiée et la réserve pour le développeur [CHE15].
Commit : Envoi de modification sur le dépôt. Il peut y avoir des conflits avec la version du dépôt
lors de la fusion des modifications (merge). Les conflits doivent être résolus pour que les
modifications soient enregistrées.
Les conflits : C’est le résultat de deux modifications simultanées faites sur le même artefact logiciel.
Les types les plus fondamentaux de conflits sont [MES13] :
 Update-Update conflits : se produisent si deux éléments ont été mis à jour dans les deux
versions.
 Delete-Update conflits : se produisent si un élément a été mis à jour dans une version et
supprimé dans l’autre.
Révision : identificateur unique d'un état des données (ce n'est pas la version d'un projet).
Étiquettes (Tag) : marque symbolique sur une révision (permet de définir les versions de projet, de
nommer les branches ...).
III.2.5.2 Principe de fonctionnement

Le principe d’un SCV est fondé sur les mécanismes assistés par un travail collaboratif entre les membres
d’une équipe de développeurs, et aussi d’un dépôt archivant les artéfacts d’un logiciel ainsi que son
historique d’évolution.
Figure III-00-10:Fonctionnalités de haut niveau d'un SCV [ALT09].
D’après Kerstin Altmanninger et al. [ALT09], les fonctionnalités (Figure III-6) d’un SCV sont :
Collaboration : Cette fonctionnalité a pour but d’empêcher d'écraser accidentellement les
modifications mutuelles des artéfacts partagés entre les développeurs. Deux mécanismes sont
utilisés :
Optimiste : Cette méthode est beaucoup plus souple car elle considère que les conflits sont
l'exception et les laisse à la charge du développeur en le laissant modifier sa propre version
du fichier, et à régler les conflits lors d'une synchronisation, cas par cas.
Pessimiste : les conflits sont la règle. Elle manque de souplesse car elle empêche la
concurrence (un développeur ayant verrouillé un fichier empêche les autres d’avancer). Son
rôle est d’interdire tout changement dès qu’un des développeurs commence à modifier une
version jusqu’à ce qu’il valide ses changements.
Le fusionnement (Merging) : Lorsqu’un artefact logiciel subi une modification, ce mécanisme est
utilisé pour fusionner les deux versions. Il est appliqué seulement lorsque la condition de conflit n’est
pas satisfaite ; Il existe trois types de merging :
Raw : applique simplement une séquence d'opérations de changement. Cette dernière est une
combinaison des modifications apportées par les développeurs [ALT09].
Two-way : On compare deux versions différentes V 'et V" et les fusionne en une seule
version V sans avoir accès à la version de la quelle V' et V" origines.
Three-way : c’est le fusionnement le plus fiable, car il faut que le V « ancêtre commun de
deux versions V' et V" » soit prise en compte et donc être en mesure d'examiner les éléments
supprimés [ALT09].
Repository architecture : L'architecture du dépôt décrit comment les développeurs communiquent
leurs modifications aux artefacts les uns aux autres. Il existe deux aspects [MAI10] :
Centralisé : chaque modification effectuée exige un accès en écriture sur un dépôt central
unique. De ce fait, il est impossible de maintenir une branche parallèle d’un projet dont on
n’est pas contributeur.
Distribué (décentralisé) : Chaque utilisateur a la possibilité de créer son convenable dépôt
depuis un autre, d’accomplir des changements locaux. Ensuite, il peut récupérer les
changements ultérieurs depuis la source, voire de propager ses propres modifications si l’on
dispose d’un accès en écriture.
Branche (branching) : évolution en parallèle. Il existe deux types :

Le branchement implicite : En raison de ce mécanisme de copiage, les branches existent
comme des répertoires ordinaires du système de fichiers dans le dépôt lorsque les SCVs n’ont
aucun service de branching interne [ALT09].
Le branchement explicite : Contrairement au branchement implicite, quelques SCVs
définissent les branches en ajoutant une autre dimension « Étiquettes » à des collections de
fichiers [MES13].
III.3 L’analyse des dépôts des SVCs

III.3.1 Le dépôt de versions
Dans le développement de logiciels, un historique de logiciel est décrit à travers un dépôt des versions
(en anglais software repository). Ce dernier est un répertoire ou un espace de stockage où le projet de
logiciel peut vivre. Il peut être un endroit local directement accessible aux développeurs, ou comme une ou
plusieurs bases de données où les fichiers sont localisés en vue de leur distribution sur le réseau.
Un dépôt offre aux programmeurs un moyen structuré de stocker les fichiers de développement. Pour
chaque fichier dans le logiciel, il enregistre des indications importantes comme [HAS08] :
La date de création du fichier (date exacte de son occurrence).

Les changements au fichier avec le temps.
La taille du fichier.
Une description des lignes affectées par le changement.
Une liste d’autres fichiers qui faisaient partie du changement décrites par les commentaires du
développeur (dans quelques cas).
En validant des modifications dans un dépôt, les développeurs peuvent rapidement revenir à une version
précédente d'un logiciel si une mise à jour récente provoque des bogues. Ils peuvent annuler les nouveaux
changements trouvés sans rapport, ou même récupérer une version anicienne du code. De ce fait, cette action
rend la version perceptible à d’autres développeurs [HAS08].
III.3.2 Les types des dépôts de SCVs

Dans le tableau suivant, nous allons présenter les types des dépôts de SCVs selon la classification de
Ahmed E. Hassan [HAS08] :
Les dépôts de contrôle des sources : Ils permettent de

Tableau suivre toutes les modifications qui s'appliquent sur le code
III-0-3: Les
types de dépôts source, et toutes les métadonnées associées à chaque
Ces dépôts changement. Par exemple, le nom du développeur qui a
Dépôts historiques (Historical repositories)

de versions
[HAS08]. qui fait la modification, le moment où le changement à été mis
enregistrent en œuvre. Parmi les SCVs qui gèrent ce genre de dépôt on
III.3.3
l'historique peut citer entre autres : CVS, Subversion, Perforce,
du ClearCase et Git.
développem Les dépôts de bogues : Ce sont des rapports de bugs qui
ent d'un sont rapportés par les utilisateurs et les développeurs : tels
logiciel. que Bugzilla et Jira.
Les communications archivées : elles suivent les
discussions sur différents aspects d'un projet logiciel tout
au long de sa durée de vie : Forums, chat, Messenger.
Tels que les journaux de déploiement qui contiennent des informations
Dépôts d'exécution
sur l'exécution et l'utilisation d'une application sur un ou plusieurs sites de

repositories)
(Run-time
déploiement d'un système logiciel. Par exemple, les journaux de

déploiement peuvent enregistrer les messages d'erreurs signalés par un
système logiciel à différents sites de déploiement. La disponibilité des
journaux de déploiement continue d'augmenter à un rythme rapide en
raison de leur utilisation pour la résolution des problèmes à distance.
Dépôts de
Ils contiennent le code source de diverses applications développéespar

code
plusieurs développeurs. Ces dépôts archivent le code source d'un grand

nombrede projets. Exemple Sourceforge.net et Github sont des dépôts de
code de grandetaille.
Principe général de l'analyse d’un dépôt de versions
D’après l’étude effectuée par H. Cherait [CHE11, CHE12, CHE14], dans la zone de recherche de
l’analyse d’évolution, la majorité des techniques d’analyse des dépôts de versions suivent le même principe.
La figure suivante illustre les phases primordiales ordonnées pour l’analyse :
Figure III-00-11: L’analyse de l’évolution du logiciel [CHE14].
L’extraction des données : Cette étape consiste à avoir l’accès aux données entreposées dans les
dépôts de SCVs.
Le prétraitement des données : L’ensemble de données résultantes obtenues de la première phase

sera traité pour l’extraction des changements, et pour filtrer les grands ensembles des données.
L’analyse des données (Data Mining) : Ici les données extraites et modélisées sont employées pour
étudier l'évolution du logiciel, ou assister à sa modification et perfectionnement à travers différentes
techniques et approches.
III.3.4 Les Approches d’Analyse de l’historique de l’Evolution

Les différents travaux dans cette zone de recherche peuvent être classés dans les axes suivants :
La visualisation de l’historique de l’évolution : Il y a trois types de techniques de la visualisation :
 Le premier type comporte les techniques qui visualisent les métriques (l’âge du code source,
le nombre de bogue…etc.) sur une représentation textuelle du logiciel [TAY02].
 Le second type montre l’information structurelle [GAL99].
 Le troisième ce sont des techniques qui extraient des patrons récurrents à partir de
l'historique du logiciel en utilisant des techniques visuelles de Mining [RYS07].
L’extraction des Co-changements : nous citons ici quelques approches
 Ying et al. [YIN05] ont formulé une technique pour identifier l'impact du changement en se
fondant sur les règles d'association.
 Dans [WON10], les auteurs formalisent le couplage logique comme un processus
stochastique en utilisant un modèle de chaîne de Markov.
 Dans [ZIM05], le Data Mining est appliqué aux historiques de version pour extraire les
patrons du changement qui seront utilisés pour guider les programmeurs dans le
développement et la maintenance du logiciel.
 Weidl et Gall [WEI98] ont détecté les hot-spots possibles de maintenabilité en analysant les
relations du Co-changement des modules qui pointent aux dépendances cachées, et aux points
faibles de la structure d'un système logiciel.
L’étude de la complexité du développement : dans [HAS03] et en utilisant les concepts
mathématiques sonores de la théorie de l'information (l'Entropie de Shannon), les auteurs étudient la
complexité de processus du développement. Ils examinent les fichiers log du dépôt du code source
pour les grands projets logiciel.
III.4 Les dépendances logiques

Puisqu’un système logiciel est développé et maintenu à travers le temps, il y a un montant
croissant d'effort pour comprendre les différentes entités du logiciel, et pour faire des changements
sur elles. Ces entités peuvent être liées les unes aux autres, bien que cette relation ne soit pas
facilement détectable dans le code source du logiciel. L’analyse de l’historique d’évolution de
logiciel peut aider à extraire ces dépendances intéressantes entre ses entités appelées « dépendances
logiques » ou « couplages logiques ». Ce genre de relations évolutives est difficile à détecter
explicitement à partir de l’analyse d’une seule version du code source.
III.4.1 Définition et objectif des dépendances logiques

Les dépendances logiques sont des relations implicites et évolutionnaires entre les artefacts d'un
système logiciel. Tandis qu'ils ne soient pas structurellement reliés, ils évoluent ensemble et sont
liées par conséquent l'un à l'autre d'un point de vue évolutionnaire. Ces entités associées sont
changées ensemble dans le passé et donc vraisemblablement elles vont être changées dans le futur
[AMB09].
Par conséquent, la dépendance logique est considérée comme une mesure indiquant la
Coévolution des artéfacts logiciels. Elle est atteinte comme résultat des indications appropriées
concernant des modifications du code source extraites d’une analyse de nombreuses versions de
systèmes logiciels.
Les dépendances logiques sont les plus gênants et ont tendance à représenter des sources de
bogues dans les projets logiciels. Il existe plusieurs objectifs pour étudier ce type de dépendance :
Elles peuvent améliorer le modèle du code source. il existe beaucoup de travaux de recherche qui ont
exploité ce type de dépendances pour la détection de faiblesses architecturales [DAM06], la
détection des défauts de modularité [CHE15], …etc.
Elles vont améliorer notre conception progressivement en ajoutant de nouvelles fonctionnalités plus
fiables et correctes.
Les chercheurs ont prouvé que ces dépendances logiques sont causées principalement par des
problèmes au niveau de la conception et la modélisation du logiciel [MAR09]. Des travaux de
recherche considérables ont été réalisés pour lier les dépendances logiques avec le domaine de la
compréhension du logiciel [BRI99], la maintenabilité [GUP12], et la réutilisabilité qui sont les
propriétés clés de la maintenance et de l’évolution de logiciel.
III.4.2 Les relations logiques versus les relations statiques et sémantiques

Dans cette section nous allons montrer les avantages de dépendances logiques par rapport aux autres
types de relations existantes dans un système logiciels : statiques et sémantiques.
III.4.2.1 Les relations logiques versus les relations statiques

La relation statique est une relation directionnelle. Dans le cas de Java, cela signifie que A ne
peut pas être compilé en l'absence de B [AJI18]. Il existe plusieurs types de relations statiques entre
les entités de code source, par exemple : appels de méthode, accès de classe ou héritage de classe.
Les constructions de la plupart des langages de programmation tels que C, C++ et Java peuvent
induire ce type de relations. Ces dépendances de code structurel statique sont le plus souvent utilisées
lors de l'analyse ou de l'exploitation du couplage [AJI18].
Nous avons cité dans les sections précédentes que le couplage logique décrit les dépendances de
changement entre les entités d'un système logiciel depuis son historique d'évolution, alors que le
couplage structurel mesure les dépendances du code source induites via l'architecture du système
logiciel [LIG07].
Ajienka et al. [NEM17] ont effectué une étude empirique très intéressante sur un échantillon de
79 projets logiciels open-source afin de déterminer s'il existe une relation entre le couplage
‘structurel et logique’ entre les classes d’un logiciel orienté objet (OO). Les résultats ont prouvé
que :
Il existe un léger chevauchement entre les dépendances structurelles et logiques dans la majorité
des projets logiciels. Cependant, il y a une probabilité plus élevée de dépendances structurelles
conduisant à la coévolution des classes, mais une faible chance de pouvoir déduire un couplage
structurel à partir de la coévolution.
Il n’existe en réalité aucune preuve solide permettant de penser qu’il existe une relation linéaire
entre les points forts de différents types de couplages. Donc, un couplage structurel fort n'implique
pas une probabilité de Co-changement plus élevée.
Plus de 30% de toutes les transactions de changement n'ont rien à voir avec le couplage structurel.
Plus de 50% des transactions de changement avaient eu au moins un changement non structurel.
Dans 91% des cas, les dépendances logiques impliquaient des fichiers non liés structurellement,
la plupart des dépendances logiques n'étaient pas directement causées par des dépendances
structurelles.
Presque 80% des dépendances de classes structurelles incluent des dépendances logiques mais pas
l'inverse.
Par conséquent, nous avons conclu que les dépendances logiques sont plus intéressantes pour l’analyse
de la modularité de logiciel que les dépendances structurelles.
III.4.2.2 Relation logique versus relation sémantique

Selon diverses études, les termes « sémantique » et « conceptuelle » reflète le même concept.
Le couplage conceptuel indique dans quelle mesure les identificateurs et les commentaires de
différentes classes sont liés. Donc les identificateurs sont utilisés par les développeurs comme des
noms de classes, de méthodes, et d'autres artefacts, qui représente la moitié du code source dans les
logiciels. Et comme ces noms représentent le point de départ de plusieurs tâches de compréhension
de programme, il est donc important de les définir clairement, car les identificateurs auto-
documentés diminuent le temps et les efforts nécessaires pour acquérir un niveau de compréhension
de base pour une tâche de programmation [AJI17].
Ajienka et al. [NEM18] ont effectué aussi une recherche empirique pour savoir s’il existe une
relation logique sémantique ou non. Ils ont analysé 79 projets logiciels OO Open source. Ils n’ont
pas détecté de relation linéaire entre les dépendances sémantiques et logiques. Cependant, ils ont
identifié un lien bidirectionnel entre les deux. En d'autres termes, plus de 70% des classes liées
sémantiquement vont généralement évoluer. En même temps, les classes liées au changement
partagent généralement un certain degré de couplage sémantique.
Par conséquent, on peut déduire encore une fois que les relations logiques sont la source la plus riche pour
analyser la modularité de logiciel OO par rapport aux autres dépendances (structurelles, et sémantiques).
III.4.3 L'extraction des dépendances Logiques (Data Mining)

La technique la plus populaire pour l’analyse des dépôts de versions et la détection des dépendances
logiques est la fouille de données «DataMining». Elle est appliquée sur différentes transactions
d'événement, pour extraire des ensembles d'items qui apparaissent le plus fréquemment ensembles. Le but
principal de cette technique est descriptif ou prédictif pour découvrir des relations entre deux ou plusieurs
items stockés dans de très grandes bases de données [BEN16].
Figure III-8 : Les étapes de génération des dépendances logiques [BOU09].
Afin d’atteindre l’ensemble des dépendances logiques ciblées, il faut d’abord passer par des phases très
intéressantes (Figure III-8) comme suit :
A. Extraction des transactions des changements

Le dépôt de version contient toutes les versions d’un code source avec le temps. Dans cette étape on a
besoin d’obtenir les transactions de changement. Ces dernières sont les changements entre deux versions
consécutives du logiciel. Un changement sur le logiciel est les différentes opérations appliquées par le
développeur : ajout, suppression, modification d’une entité ou d’une opération.
B. Génération des itemsets fréquents
Le résultat de la phase d’extraction des transactions sera analysé par différents algorithmes qui peuvent
être employés dans le but de détecter l’ensemble des éléments fréquents (i.e. les dépendances logiques). Ce
sont les entités qui se changent souvent ensemble. Selon Boulanger et Alain [BOU09], les itemsets fréquents
sont générées en fixant un support minimal. Ils ont défini formellement le support et la dépendance logiques
comme suit :
Support d’une dépendance logique (frequent itemset)
Supposons IR un ensemble d'items, 𝑟 une BDD sur IR et Y⊆ IR un itemset. On note M(𝑟,Y) = {𝑡∈𝑟
| Y⊆𝑡}, le multiset de transactions qui contiennent Y. Le support de Y sur M est noté
𝑠𝑢𝑝𝑝𝑜𝑟𝑡(M,Y) =|M(𝑟,Y)| et signifie le nombre de transactions dans M correspondant à Y . Le
support peut être représenté de manière absolue, relative ou en pourcentage.
Dépendance logique (frequent itemset)

Supposons IR un ensemble d'items, 𝑟 une BDD sur IR et Y ⊆ IR un itemset. On note par S un seuil
de support minimum défini par un utilisateur. On définit un ensemble d'itemsets fréquents I
comme suit: I (𝑟, S) = {Y | Y ⊆ IR ⋀𝑠𝑢𝑝𝑝𝑜𝑟𝑡(𝑟,Y) ≥ S}. [BOU09]
C. Génération des règles d'association

Soit une dépendance logique entre deux entités X, Y, une règle d'association X ⇒Y signifie que lorsque
l'entité X est modifiée, l'entité Y doit être modifiée également. Pour générer cette règle, on doit fixer un
support et une confiance minimaux. La définition formelle d'une règle d'association est la suivante [BOU09]
:
Soient IR un ensemble d'items et, A i et Cj ϵ IR. Une règle d'association basée sur IR est une expression
de la forme {A1, A2, ... , An} ⇒ {C1 , C2, ... , Cn}, où {A1, A2, ... , An } et {C1 , C2, ... , Cn } sont des
ensembles disjoints d'éléments. Par disjoint, on entendque {A 1, A2, ... , An }∩ C1 , C2, ... , Cn = ∅. Une
règle d'association se note commesuit, X ⇒Y, où X = {A1, A2, ... , An } et Y = {C1 , C2, ... , Cn }. Dans le
cas d'unerègle d'association, X est appelé l'antécédent et Y le conséquent. Une règle d'association,pour
être valide, doit avoir Y ≠∅. [BOU09]
Support d’une règle d’association

Un indicateur de "fiabilité" de la règle. Soient IR un ensemble d'items, une BDD basée sur IR, 𝑟, X
et Y ⊆IR respectivement l'antécédent et le conséquent d'une règle d'association. Le support d'une
règle d'association X ⇒ Y se définit comme suit : support (𝑟, X⇒Y) = support (𝑟, X U Y). [BOU09]
Support d’une règle d’association

Un indicateur de "précision" de la règle. Soient IR un ensemble d'items, une BDD basée sur IR,𝑟, X et
Y ⊆IR tels que définis précédemment. La confidence représente le nombre de transactions supportant
la règle (antécédent et conséquent) sur le nombre de transactions supportant le conséquent. On note
comme suit : confidence (𝑟, X⇒Y) = support (𝑟, X U Y)/support (𝑟, X). [BOU09]
III.4.4 Les Algorithmes de Mining

Il existe plusieurs algorithmes pour la génération des items récurrents ou des règles d’association. On
peut citer les cinq algorithmes les plus populaires [PAS00] :
A. L’algorithme Apriori : est un algorithme classique de recherche de règles d’association. Comme tous
les algorithmes d’extraction des règles d’associations, il travaille sur des bases de données transactionnelles.
C’est l’algorithme que nous allons utiliser dans notre approche.
B. L’algorithme FP-Growth(Frequent-Pattern Growth) : est un algorithme complètement innovant

par rapport aux autres algorithmes. Il utilise une structure de données spéciale appelée « Fréquent-Pattern
tree ». En stockant l’ensemble des éléments fréquents de la base de transactions dans cette structure,
l’algorithme n’a pas besoin de parcourir de façon répétée la base de transactions, et la recherche est
accélérée.
C. L’algorithme Eclat : est le fondateur de la seconde grande famille d’algorithmes de recherche de

règles d’associations avec l’algorithme Apriori. L’algorithme démarre avec la liste des éléments fréquents,
puis l’algorithme est réitéré en rajoutant les ensembles fréquents à l’ensemble des candidats jusqu’à ce que
cet ensemble soit vide.
D. L’algorithme SSDM (Semantically Similar Data Miner) : est un algorithme de la famille de

l'algorithme Apriori auquel il rajoute des notions d'ensembles flous afin de renforcer la recherche de règles
d'associations sur des bases plus robustes.
E. L’algorithme kDCI (k Direct Count & Intersect) : est un algorithme hybride multi-stratégies basé
sur l’algorithme DCI. L’algorithme recueille des informations sur la base de données durant l’exécution afin
de déterminer la meilleure stratégie à adopter selon quelles données sont denses ou éparses.
F. L’algorithme FIN : Au cours des dernières années, deux nouvelles structures de données ont été
proposées Nlist et Nodelist pour représenter les itemsets. Les deux structures sont basées sur une structure
arborescente appelée PPC-Tree, qui stockent les informations pour chaque motif fréquent.
III.4.5 Etat de l'Art sur des approches de détection des dépendances logiques
Parmi les approches et les techniques les plus récents et les plus intéressants dans un ordre chronologique
croissant (de l’ancien vers le plus à jour) nous pouvons trouver :
Piatetsky et Shapiro [PIA91] : En se basant sur le concept de relations fortes. Ils présentent des
règles d'association exceptionnellement fortes, découvertes dans des bases de données en usant des
distinctes mesures d'intérêt.
Gall et al. [GAL98] : ont détecté les points possibles de maintenabilité en analysant les relations du
Co-changement des modules qui pointent aux relations cachées, et aux points faibles de la structure
d'un système logiciel, en fonction de l'historique de version du code source.
Bieman [BIE03] : a présenté une étude fondée sur des métriques pour détecter les classes sujettes au
changement, i.e. les classes qui se changent continuellement et les groupes de classes qui se changent
fréquemment ensemble.
Hassan et al. [HAS04] : ont utilisé une variété des heuristiques, comme la relation basée sur les
développeurs, l'historique, la disposition de code (basée sur le fichier) pour découvrir les entités
candidates à un changement en raison du changement d'une entité données.
Ying et al. [YIN04] : Au niveau du fichier, ils ont proposé une approche de prédiction de
changement de code source. Une technique d'extraction par association basée sur l'extraction
d'ensembles d'éléments d'arbres FP est utilisée. Pour indiquer leur intérêt, les règles minées sont
classées dans des catégories surprenantes, neutres ou évidentes. La technique est évaluée sur
l'historique des versions des projets Mozilla et Eclipse.
Ying et al. [YIN05] : En se basant sur les règles d'association, ils ont proposé une technique pour
déterminer l'impact du changement.
Ratzinger et al. [RAT05] : ont exploité des données historiques extraites à partir des dépôts et se
concentrent sur les couplages du changement (change couplings).
Zimmermann et al. [ZIM05] : ont appliqué le Data Mining aux historiques de version pour extraire
les patrons du changement. Ces derniers sont utilisés pour guider les programmeurs dans le
développement et la maintenance du logiciel.
Kagdi et al. [KAG06] : ont appliqué l'exploration de modèles séquentiels pour découvrir les fichiers
fréquemment modifiés avec les informations supplémentaires de leur ordre de modification.
Askari et Holt [ASK06] : ont désigné une approche théorique de l'information pour évaluer les
modèles probabilistes. Ceci a été utilisé pour deviner les changements et les bugs dans les fichiers
logiciels. Le modèle est évalué en comparant la distribution des valeurs prédites (par exemple, les
changements de fichiers) avec la vraie distribution (i.e. les observations réelles).
Gino Chénard [CHE07] : a réalisé une approche automatique pour l'extraction des règles
d'association d'un logiciel.
Wong et al. [WON10] : les auteurs formalisent le couplage logique comme un processus
stochastique en utilisant un modèle de chaine de Markov.
Abdou Maïga [MAI10] : a fait la détection et correction automatique des défauts de conception au
moyen de l’apprentissage automatique pour l’amélioration de la qualité des systèmes.
Ben nedjema et Benlaiter [BEN12] : ont proposés une approche qui fait l’extraction des règles
d’association pour l’aide à la décision.
Cherait et Bounour [CHE15] : ont proposé des approches pour extraire les patrons du changement
et les dépendances logiques au niveau des logiciels orientés aspect (OA). Ces dernières sont utilisées
pour détecter les défauts de modularité au niveau de ces logiciels OA.
Guendouzi Wassila [GUE17] : a réaliser une approche bio-inespérée pour la détection d’intrusions
dans un réseau d’ordinateurs.
Mokhtari et Moulkhaloua [MOK18] : ont proposé un système DE Détection D'intrusions
Informatiques par Système Multi-Agents.
III.5 Conclusion
Nous avons présenté dans ce chapitre les systèmes de contrôle de version qui aident les
développeurs à entreposer et gérer leurs versions du logiciel au fil du temps. Nous avons aussi
exploré le domaine e l’analyse d’historique d’évolution, plus spécifiquement la détection des
dépendances logiques : son principe, ses étapes primordiales, et les algorithmes de Mining. Nous
avons clôturé par un état de l'art sur des approches de détection des dépendances logiques.
Dans le chapitre suivant nous allons présenter en détails notre approche proposée. Nous visons à
utiliser les dépendances logiques extraites entre les classes (et par conséquent entre les packages) à
partir d’un dépôt de version d’un logiciel OO pour étudier sa modularité.
CHAPITRE IV
NOTRE APPROCHE D’ANALYSE
DE LA MODULARITE DES LOGICIELS OO
IV.1 Introduction
Nous présentons dans ce chapitre, notre approche d’analyse de la modularité des logiciels OO. Cette
analyse permet de détecter les défauts de modularité possibles. Le principe consiste à analyser l’historique
d’évolution du logiciel OO pour générer les dépendances logiques entre ses classes. Ensuite, ces
dépendances sont analysées afin de visualiser : 1) les relations de cohésion dans les packages, et 2) les
relations de couplage entre les packages. Le couplage et la cohésion seront les mesures de la modularité
utilisées dans notre approche. Les résultats obtenus seront délivrés au développeur du logiciel, qui peut
appliquer des techniques adéquates dans le but d’améliorer sa modularité.
Nous commençons par une vue globale de notre proposition. Ensuite, nous présenterons soigneusement
et de manière approfondie les différentes étapes de notre approche.
IV.2 Vue globale de notre approche

L’aperçu général de notre approche est illustré dans la figure IV.1. L’étude suggérée est fondée
sur deux étapes fondamentales qui sont :
1. L’analyse du dépôt de versions du logiciel OO pour générer les dépendances logiques entre
ses classes sous forme de règles d’association.
2. L’analyse des dépendances logiques générées dans l’étape précédente pour détecter les
relations de cohésion et de couplage :
a. Relations de cohésion ou dépendance interne : les dépendances logiques entre des
classes qui appartiennent au même package.
b. Relations de couplage ou dépendance externe : les dépendances logiques entre des
classes qui n’appartiennent pas au même package.
Les résultats obtenus par notre approche peuvent nous donner une idée claire sur la modularité du logiciel
OO. Les relations de cohésion et de couplage nous aident à détecter les défauts de modularité.
Une bonne modularité = forte cohésion dans les packages + faible couplage entre
packages
Ces résultats seront exploités par le développeur du logiciel dans le but d’améliorer sa modularité.
Figure IV-012:Vue globale de notre approche.
IV.3 La génération des dépendances logiques

Le couplage logique entre deux classes est fondé sur l’historique de leurs évolutions. Deux classes A et
B sont dépendantes logiquement si un changement dans une classe A implique souvent un changement dans
une autre classe B, on dit que B dépend de A.
Nous devons analyser le dépôt d’un système de contrôle de version d’un projet OO pour extraire les
dépendances logiques entre ses classes sous forme de règles d’association. Cette étape est constituée des
quatre sous-étapes suivantes :
1 . Extraction de données
2 . Différenciation entre les versions du logiciel OO
3 . Prétraitement des données
4 . La fouille de données (Mining)
Figure IV-13: Les étapes de la génération des dépendances logiques.
IV.3.1 Extraction de données

Comme nous avons déjà expliqué dans le chapitre III, le dépôt d'un système de contrôle de version doit
englober tout l'historique des versions d'un logiciel au fil du temps. Pour analyser l’historique de l’évolution
d’une application OO, nous devons tout d’abord extraire ses différentes versions à partir de son dépôt de
versions. Ici, nous exigions l’obtention d’une copie de code source de ce dépôt afin de l’analyser avec notre
approche. Actuellement, il existe une multitude de SCVs, parmi lesquels nous avons désigné un des plus
réputé systèmes qui est « Git ».
Figure IV-14: Extraction de données avec Git.

Git est un logiciel de gestion de versions distribué (SCVD) qui suit l’évolution des fichiers sources et
garde les anciennes versions de chacun d’eux sans rien écraser. Cela permet de retrouver les différentes
versions d'un fichier depuis la création de l'application jusqu'à la version actuelle sous forme de Tags
[ANC17].
IV.3.2 La Différenciation
Dans l’objectif de faire évoluer et maintenir le logiciel, le développeur applique des changements qui
peuvent êtres : un ajout, une modification ou une suppression d’un artefact logiciel ou d’une association.
Afin d’extraire les transactions de changement dans le dépôt de version, nous appliquons la différenciation
entre chaque deux versions consécutives d’un logiciel OO. Comme résultat est à partir de N versions du
logiciel, nous obtenons N-1 transactions de changement.
Figure IV-15: Différenciation entre les versions.
IV.3.3 Le prétraitement de données

Les transactions extraites dans l’étape précédente doivent êtes filtrées pour les préparer à l’étape
suivante (Mining). Cette étape est très importante puisque les résultats du Mining dépendent de la qualité
des données. Les informations nécessaires à garder sont celles relatives aux changements des classes et leurs
packages en ajustant le format des transactions de changement conformément à nos requis. Par conséquent,
nous devons éliminer toutes les données inutiles, incomplètes, ou qui peuvent êtres des éléments
perturbateurs pour notre processus de Mining.
Les algorithmes de Mining cités dans le chapitre précèdent (section III.3.5.4) exigence un format
spécifique pour les transactions de changement. Donc, nous devons se focaliser sur le format de l’algorithme
que nous allons utiliser. Dans notre cas c’est l’algorithme « Apriori ».
IV.3.4 La fouille de données (Mining)
Les résultats obtenus dans l’étape précédente (transactions de changement filtrées), doivent êtes
analysées pour détecter les dépendances logiques entre les classes du logiciel OO. Le principe est exprimé
dans l’exemple suivant :
Exemple : soit les trois transactions de changement T1, T2 et T3 définies comme suit :
- T1=C1, C2, C3, C6.
- T2=C1, C3, C5, C7.
- T3 =C1, C8, C3, C4.
A partir de ces transactions, nous pouvons remarquer que les classes C 1 et C3 sont changées ensemble
dans les trois transactions. Cela signifie que lorsque les développeurs ont changé la classe C 1, ils ont
également changé la classe C3. Puisque ces classes sont changées souvent ensemble, nous pouvons déduire
qu’il existe une relation de dépendance logique entre eux.
Dans notre approche, nous avons choisi d'utiliser l'algorithme Apriori pour faire le Mining. Cet
algorithme expose nettement les classes fréquemment changées ensemble avec leurs packages sous forme de
règles d'association.
A. L'algorithme Apriori
L'algorithme Apriori [AGR94] est un algorithme d'exploration de données conçu en 1994, par Agrawal
et Sikrant, dans le domaine classique de recherche de règles d'association. Malgré qu’il est un ancien
algorithme ; mais il est toujours considéré comme l’un des algorithmes les plus performant dans le domaine
de Mining, et c’est pour ça il est très utilisé dans les travaux récents. Apriori sert à reconnaitre des propriétés
qui reviennent fréquemment dans un ensemble de données, Pour révéler la pertinence d'une règle on utilise
deux concepts qui sont « le support » et « la confiance » (confidence) (voir la section III.3.5.1).
Afin d'être retenue, chaque règle devra avoir un support supérieur à minSupp et une confiance
supérieure à minConf. Ces deux valeurs étant définies empiriquement par l'utilisateur de l'algorithme.
L'algorithme Apriori (Listing IV.1) est conçu pour opérer sur les bases de données qui contiennent des
transactions. Donné un ensemble d'items « Itemsets », l'algorithme essaie de trouver des sous-ensembles qui
sont communs à au moins un nombre minimum C d'itemsets.
L1 = { large1 - itemsets };
for (k=2; lk-1 ≠; k++) do begin
ck = apriori - genL k-1; // New Candidates
for all transactions t ϵ D do begin
Ct = subset(Ck ,t) // candidates contained in t
for all candidates c ϵ Ct do c.count ++;
end
Lk = {c ϵ Ck│c.count_ minsup }
end
Answer =*$Uk Lk$*
Listing IV-1:L'algorithme Apriori [BOU09]
Pour générer les dépendances logiques entre les classes de l'application OO avec l'algorithme Apriori,
nous avons suivi le principe suivant : soit C={c1, c2,…,cn} un ensemble des classes du logiciel OO, et X ⊆ C
un sous ensemble de classes. Nous définissons le dépôt D comme un ensemble de transactions de
changement D={t1, t2,…tm}, où ti = {ci1, ci2,…,cik} et cijϵ C. Donc, soit s(X) l'ensemble de transactions qui
contient l'ensemble des classes X, formellement s(X)={YD│Y⊆X}. Finalement, le support de l'ensemble
de classes X est la fraction de transactions dans le dépôt qui contient X :
¿
Support(X)=¿ s(X )∨ ¿ D∨¿¿ ¿
Donc, X est appelé une dépendance logique quand son support est plus grand qu'un support minimum
donné : support(X) ≥ minsupport.
Dans d'autre terme, la force d'une dépendance logique {c1, c2,…,cn} où chaque ci est une classe, est
mesurée par le support qui est le nombre (ou pourcentage) de transactions qui contiennent les classes c 1, c2,
… ,cn.
B. Règles d'association entre les classes

Nous avons utilisé l'algorithme dans le Listing IV.2 pour générer les règles d'association à partir des
dépendances logiques, en fixant une confiance minimale.
Function generate_rules (F, minconf )
Rules ←∅
Foreach frequent itemset Fi in F Do
Foreach IS subset of the Fi loop itemset
generate rules IS ⇒ Fi / IS
support rules (IS ⇒ Fi / IS) support (Fi)
confidence rules (IS ⇒ Fi / IS)support (Fi) / support (IS)
if ( confidence (IS⇒ Fi/IS) ≥ minconf ) then
rules ← rules U rule
return rules
Listing IV-2:Algorithme de génération des règles d'association [BOU09]
Une règle d'association est une relation unidirectionnelle de la forme C 1⇒C2 entre deux ou plusieurs
classes. La partie gauche de la règle C 1 est appelée les antécédents, ce sont les classes qui peuvent être
changés, et la partie droite C2 est appelée les conséquents, qui représentent les classes touchées par le
changement des antécédents de la règle.
Après la génération des dépendances logiques sous forme de règles d’association, elles seront
entreposées dans une base de données. Cette dernière sera utilisée par notre outil d’analyse de modularité
pour détecter les différentes relations de cohésion et de coulage dans le logiciel OO.
IV.4 L’analyse de la modularité des logiciels OO
Cette phase utilise les règles d’association générées dans l’étape précédente afin d’aider le développeur à
analyser la modularité du logiciel OO d’une façon correcte. Cette analyse est basée sur la décomposition
structurelle du logiciel OO en tant que packages. Nous pouvons distinguer deux types de dépendances
logiques (Figure IV.5) :
 Dépendance logique interne : met en relation deux classes appartenant au même package dans la
décomposition logicielle.
 Dépendance logique externe : relie deux classes appartenant à deux packages logiciels différents
(indépendants).
Pour évaluer l’interdépendance des packages du logiciel OO, nous nous sommes basés sur les dépendances
précitées pour proposer deux concepts intéressants : la cohésion logique, et le couplage logique.
Figure IV-5 : Types de dépendances logiques
IV.4.1 La cohésion logique de package

La cohésion logique est une métrique mesurant à quel point les classes appartenant à un même package
sont liées. Par conséquent, elle concerne les dépendances logiques internes : s’il existe un grand nombre de
dépendances logiques internes dans un package, donc il a une cohésion forte et vice versa.
Une dépendance logique interne dans le logiciel OO peut être définie formellement comme suit :
Définition d'une dépendance logique interne : soit A un package. S’il existe une dépendance (x, y)
entre les deux classes x, y tel que x ϵ A et y ϵ A, donc elle est une dépendance logique interne au
package A.
Si nous remarquons l’exemple illustré dans la figure IV.6, nous pouvons conclure que :
Le package A possède une faible cohésion avec une seule dépendance interne ;
Le package B a une forte cohésion avec 7 dépendances logiques internes, c’est le cas parfait.
Le package C dispose de 3 dépendances logiques internes, nous pouvons dire que c’est une cohésion
moyenne.
Figure 0IV-6 : cohésion logique de packages
IV.4.2 Le couplage logique entre packages

Un couplage logique mesure l’interdépendance entre deux packages. Donc, nous parlons ici des
dépendances logiques externes. Un ensemble de packages est faiblement couplé si les dépendances logiques
externes entre les packages sont peu nombreux et vice versa.
Si nous constatons l’exemple illustré dans la figure IV.7, nous pouvons déduire que :
Les packages P2 et P4 sont fortement liés avec 3 dépendances logiques externes ;

P1 et P2 sont faiblement couplés avec une seule dépendance externe ;
Le package P3 n’est pas couplé carrément avec les autres packages, c’est le cas idéal.
Figure IV-7: Packages couplés.
Une dépendance logique externe dans le logiciel OO peut être définie formellement comme suit :
Définition d'un couplage logique externe: soit A et B deux packages. S’il existe une dépendance
logique entre les deux classes x, y (x,y) tel que x ϵ A et y ϵ B, donc elle est une dépendance logique
externe entre les deux packages A et B.
Le couplage logique d’un package est mesuré par le nombre de dépendances logiques externes reliant ce
package avec le reste des packages du logiciel OO. Formellement, un ensemble de dépendances
logiques externes DLE pour un package A est défini comme suit:
DLE (A) = {(𝑒i, 𝑒𝑗) | 𝑒i∈A, 𝑒𝑗∈X}, tel que AX.
Puisque chaque dépendance logique a une force (support). Ainsi, nous pouvons dire que deux packages
sont fortement liés si le support de la dépendance entre eux est grand et vice versa. Par conséquent, et à
travers notre analyse nous pouvons détecter les packages fortement liés et ceux faiblement liés.
IV.4.3 Les défauts de modularité

Dans notre approche nous classifions les dépendances logiques générées afin d’analyser la modularité du
logiciel OO. Cette analyse nous permet de détecter des défauts de modularité possibles dans le logiciel :
Défauts de modularité = faible cohésion dans un package OU fort couplage entre des
packages
Une faible cohésion : les classes qui appartiennent au même package ne se changent pas ensemble,
ce qui conduit à une faible cohésion du package. Cela est considéré comme un défaut de modularité
puisqu’une bonne modularité nécessite une forte cohésion dans les packages du logiciel.
Un fort couplage : l'existence des couplages logiques dans un système logiciel présente des défauts
de modularité possibles dans ce système. Deux packages qui sont censés être modifiés
indépendamment sont modifiés ensemble, i.e. un changement dans une classe qui appartient à un
package spécifique nécessitera des changements dans une ou plusieurs autres classes qui
appartiennent à d'autres packages. Plus le couplage est fort, plus il y a de possibilité qu’il s’agisse
d’un vrai défaut de modularité.
En résumé, un fort couplage ou une faible cohésion dans un logiciel OO montrent que la modularité dans
ce système est violée. Les packages concernés seront des candidats à la restructuration ou à la
refactorisation. Ici, les défauts de modularité détectés sont utilisés pour orienter les développeurs à effectuer
des améliorations ; afin d'obtenir une meilleure stabilité avec très peu de dépendances, i.e. une situation
idéale permettrait de changer chaque package indépendamment des autres. Ceci est très utile pour
reconstruire une meilleure modularisation pour le système logiciel OO et une bonne réutilisabilité de leurs
packages.
IV.5 La conception de notre outil d'analyse de modularité

Nous avons automatisé les étapes précitées dans les sections précédentes à travers notre outil Java (Figure
IV-8). Premièrement l’outil génère les dépendances logiques sous forme de règles d’association et les
entrepose dans une BDD. Ensuite, il utilise les résultats générés pour la visualisation des relations de
cohésion et de couplage logique pour chaque package, en basant sur la structure du logiciel (les packages et
leurs classes).
Figure 0-8: Outil d'analyse de la modularité.
Dans ce qui suit des diagrammes UML sont utilisés pour refléter notre conception.
IV.5.1 Diagramme de cas d’utilisation
Les fonctionnalités fondamentales de l'application à élaborer sont présentées dans le diagramme de cas
d'utilisation présenté dans la figure IV-9 :
1. Générer les règles : dans le but de générer les règles d'association d'une application Java à partir de
son dépôt de versions.
2. Visualiser les règles : le développeur (l’utilisateur de l’outil) peut consulter toutes les règles
d'association d'une application Java.
3. Générer et visualiser la cohésion d’un package : analyse les règles d’association pour un package
donné pour déduire et visualiser ses relations de cohésion logique.
4. Générer et visualiser le couplage d’un package : analyse les règles d’association pour un package
donné pour déduire et visualiser ses relations de couplage logique.
Figure 0-9: Diagramme de cas d'utilisation de notre application.
IV.5.2 Diagramme de classes

Nous démontrons chaque partie de notre application dans le diagramme de classe illustré dans la figure
suivante :
Figure IV-0-160: Diagramme de classe de notre application.
IV.5.3 Diagrammes de séquence

Dans cette sous-section, nous présentons les diagrammes de séquence de nos quatre cas d'utilisation cités
précédemment.
Figure IV-0-171: Diagramme de séquence générer les règles d’association.
Figure 0-12: Diagramme de séquence visualiser les règles d’association.

Figure IV-13: Générer et visualiser la cohésion d’un package.
Figure 0-14: Générer et visualiser le couplage d’un package.
IV.6 Conclusion
Nous avons présenté dans ce chapitre les étapes détaillées de notre approche d’analyse de la
modularité logique pour les logiciels OO. Notre proposition est subdivisée en deux phases
primordiales : l’analyse du dépôt de versions du logiciel OO pour générer les dépendances logiques
entre ses classes sous forme de règles d’association. Ensuite, l’analyse des dépendances logiques
générées dans l’étape précédente pour détecter les relations de cohésion (dépendances logiques
internes) et de couplage (dépendances logiques externes).
Dans le chapitre suivant, nous allons présenter l’implémentation de notre proposition, ainsi que
les expérimentations effectuées dans le but de prouver à quel point notre approche est faisable et
efficace.
CHAPITRE V
IMPLEMENTATION ET EXPERIMENTATION
VI.1 Introduction
Dans ce chapitre nous présentons la mise en œuvre de notre approche d’analyse de modularité des
logiciels OO. Nous avons réalisé un outil Java « Logical Modularity Analyser » contenant deux sous-
outils : un pour la génération des règles d’association en se basant sur l’algorithme Apriori, et un deuxième
qui a comme objectif la génération des relations de couplage et de cohésion logiques.
Les résultats obtenus par notre outil facilitent l’analyse de modularité pour le développeur de logiciel OO.
Ce dernier peut décider si le logiciel nécessite une simple restructuration, ou même un refactoring pour
obtenir une version plus modulaire.
Notre outil est validé à travers des expérimentations afin de prouver son efficacité. Nous avons analysé
les dépôts de versions de trois applications Java Open-source de grande taille.
VI.2 Mise en œuvre de notre approche

VI.2.1 Génération des règles d'association
Dans cette section, nous allons illustrer l’assortiment des phases dont nous avons fait appel tout au long
de la mise en œuvre de notre approche ; qui sert à générer les règles d’association (figure V.1).
Figure V-018: Les étapes de génération des règles d'association.

A. Extraction des versions à partir du Git
En vue d’analyser l’historique de l’évolution d’un logiciel OO, nous sommes chargés en premier lieu
d’extraire ses diverses versions depuis son dépôt de versions. Nous avons désigné le dépôt Github
précisément en raison de sa richesse, sa réputation et sa célébrité. Ce dernier est connu comme une
plateforme sur le web à distribuer plusieurs applications et ses codes source du projet.
B. Différenciation et préparation de données
Principe
Cette étape répond à la question : « Qu'est-ce qui a vraiment changé entre deux versions du logiciel OO
? ». De ce fait, nous avons utilisé un outil vigoureux afin d’effectuer la comparaison du code source Java.
Cet outil est « JDiff » basé sur doclet Javadoc qui émet un rapport de tous les packages, classes, méthodes,
etc., qui sont changés (la partie "diff") lorsque deux API Java sont comparées. Idéal pour signaler ce qui a
changé entre deux versions ; qui produit un rapport décrivant exactement les changements précis entre deux
versions d'un logiciel OO [JDI20].
Les Doclets sont des programmes qui fonctionnent avec l’outil Javadoc pour générer des documents à
partir du code écrit en Java.
Figure V-019: La création de dépôt des transactions de changement en format XML.
Pour quelle raison nous avons choisi le JDiff ?
Dans ce domaine, nous trouvons différents mécanismes de différenciation. Parmi ces outils nous avons
désigné JDiff en raison des avantages ci-dessous [CHR11] :
 Quel que soit le niveau de granularité : packages, classes, méthodes ; JDiff peut décrire parfaitement
ce qui a changé dans chaque version du logiciel.
 Il est basé sur Javadoc standard aussi simple et rapide dans son utilisation.
 La plupart des outils de comparaison de fichiers de code source exercent une différenciation
textuelle. Ils prennent en considération n'importe quel changement dans le texte du fichier. il en
résulte que même les changements qui ne touche pas vraiment le fonctionnement du code source sont
détectés, par exemple : les commentaires. En revanche, JDiff est utilisé spécialement dans la
différenciation entre les fichiers Java en appliquant une différenciation sémantique et en éliminant
les changements qui ne touchent pas le déroulement du logiciel. [BOU19].
 Facile à intégrer dans d’autres outils à cause de l’utilisation en ligne de commande.
 Possibilité de sa configuration pour réaliser une différentiation particulière d’un objectif ciblé car
JDiff est un outil Open-Source.
 JDiff a la possibilité d’avoir un rapport en format XML (Extensible Markup Language) qui est
facile dans son analyse prochainement dans les phases de notre approche.
Précepte de déroulement de JDiff
JDiff utilise l'API de doclet Javadoc, qui offre aux développeurs de doclet une arborescence prête à
l'emploi et facile à utiliser de tous les packages et les classes Java des fichiers analysés par Javadoc.
Le doclet JDiff a deux modes de fonctionnement :
 Dans le premier mode, il agit comme un doclet générant du XML qui traverse tous les packages et
les classes de l'application et écrit autant d'informations dans un fichier XML.
 Le deuxième mode de fonctionnement utilise deux fichiers XML de ce type en tant qu'entrée dans un
analyseur XML, tel que l'analyseur XML Xerces, et les compare soigneusement. Les résultats de la
comparaison sont ensuite utilisés par un certain nombre de classes JDiff pour générer la sortie XML
en détectant tous les types de changements entre deux versions d'un projet Java.
Chaque changement dans l'application Java est signalé, des nouvelles méthodes, champs, ou
changements dans les types de paramètres et les exceptions levées . . . etc. [JDI20].
Application de JDiff dans notre approche
Pour l’extraction des transactions de changement, chaque deux versions d’un projet Java doivent être
différenciées. C’est pourquoi, nous avons appliqués l’outil « JDiff ». Par ailleurs, et dans le but d’appliquer
l’algorithme Apriori sur les transactions de changement générées par JDiff, nous avons exigés de les
formater au maximum en vue de garder seulement les informations indispensables au Mining. Nous sommes
censés de laisser dans chaque transaction uniquement les classes changées ainsi que les packages auxquels
elles s'affilient.
Dans la mesure où JDiff est un outil Open-source, nous l'avons configuré pour générer un rapport XML
englobant ce que nous avons exigé précisément pour le Mining i.e. les classes changées entre les deux
versions.
En supplément, nous avons configuré JDiff pour faire la différenciation entre toutes les versions du dépôt
de l'application Java (N versions) d’une manière automatique. Le résultat est un seul rapport XML contenant
toutes les transactions de changement. Ce rapport sera prêt à être analysé facilement avec l'algorithme
Apriori.
Le Listing V.1 illustre un exemple du rapport XML de différenciation généré par JDiff:

L’ensemble de transactions est identifié par la balise <transactions>;
Chaque transaction dans l'ensemble de transactions est identifiée par la balise <transact>;
L’ensemble des éléments de chaque transaction sont identifiés par la balise <classe>, contient la
classe changée ainsi que le package auquel elle appartient.
1 <? xml version ="1.0 " encoding ="UTF -8"?>
3 <transactions>
4<transact><classe package = 'org.traccar' action = 'changed'> BasePipelineFactory</c
lasse>
5 <classe package = 'org.traccar' action = 'changed'> Context</classe>
6 <classe package = 'org.traccar' action = 'changed'> MainEventHandler</classe>
7 <classe package = 'org.traccar' action = 'changed'> MainModule</classe>
8<classe package = 'org.traccar'action = 'changed'> WebDataHandler</classe>
9</classe>
……
</transact>
</transactions>
Listing 0V-03: Exemple d'un rapport XML généré par JDiff « transaction.xml ».
C. Mining avec Apriori
Nous pouvons subdiviser l’algorithme qui génère les règles d’association en deux phases principales :
1. Extraction des itemsets fréquents
C’est la détermination de l’ensemble des itemsets fréquents dans la base de transaction. À la
lumière de cette approche, nous avons implémenté l'algorithme Apriori avec le langage Java. Ce
programme génère des dépendances logiques à partir des transactions de changement. Par
conséquent, il analyse le rapport XML généré dans l'étape précédente (la différenciation). À
posteriori, nous présenterons le principe de fonctionnement de cet algorithme tout en éclaircissons
ses distinctes fonctions essentielles.
Nous avons un fichier XML nommé « transaction.xml » (Listing V.1) qui fournit la structure du
fichier XML englobant les transactions de changement. Dans cette partie, nous devons fixer un
support minimum (minsup) et une confidence minimale (minconf).
1. public AprioriCalculation(String data, int numItems, int numTransaction
s,
2. double minSup, double confidence) throws IOException {
3. this.data = data;
4. this.numItems = numItems;
5. this.numTransactions = numTransactions;
6. this.minSup = minSup /= 100.0;
7. this.confidence = confidence;
8. oneVal = new String[numItems];
9. for (int i = 0; i < numItems; i++) {
10. oneVal[i] = "1";
11. }
12. FileWriter fw;
13. BufferedWriter file_out;
14. fw = new FileWriter(outputFile);
15. file_out = new BufferedWriter(fw);
16. file_out.write(numTransactions + "\n");
17. file_out.write(numItems + "\n******\n");
18. file_out.close(); }
Listing V-04: Méthode de calcul des règles d'association.
2. Génération des règles d'association

La seconde phase du processus de recherche des règles d’association est la génération des règles
d’association. Elle s’accomplie à partir des itemsets fréquents générés précédemment. Le résultat
obtenu de cette étape est un fichier XML « Rules.xml » comportant toutes les règles d’association
générées par des requêtes présentées dans le Listing V.3. Comme nous pouvons le voir, les données à
l'intérieur du document de règles sont autos descriptives. Nous donnons comme exemple, l’ensemble
de règles est identifié par la balise <rules> et chaque règle est identifiée par la balise <rule>. Tel que
chaque règle contient :
Confidence (confiance) : la confiance de la règle d'association est supérieure à la confiance
minimale.
Support : le support de la règle d'association est supérieur au support minimum.
Id : identificateur de la règle d’association.
Antécédent : les classes à changer en premier.
Item : package de chaque classe antécédent et conséquent.
Conséquent : les classes qu'on doit changer après le changement de la (les) première(s) classe(s)
(antécédent).
1. <?xml version="1.0" encoding="UTF-8"?>
2. <rules><rule confidence="0.7" support="0.3333333333333333" id="0"><anteceden
t>
3. <item package="org.traccar">MainEventHandler</item></antecedent><consequent>
<item
4. package="org.traccar.database">IdentityManager</item></consequent></rule>
5. <rule confidence="0.875" support="0.3333333333333333" id="1"><antecedent><it
em
6. package="org.traccar.database">IdentityManager</item></antecedent><consequen
t>
7. <item package="org.traccar">MainEventHandler</item></consequent></rule>
8. <rule confidence="0.6" support="0.2857142857142857" id="2"><antecedent><item
9. package="org.traccar">MainEventHandler</item></antecedent><consequent><item
10. package="org.traccar.protocol">HuabaoProtocolDecoder</item></consequent></ru
le>
11. <rule confidence="0.8571428571428571" support="0.2857142857142857" id="3">
12. <antecedent><item package="org.traccar.protocol">HuabaoProtocolDecoder</item
>
13. </antecedent><consequent><item package="org.traccar">MainEventHandler</item>
14. </consequent></rule>
15. ….
16. </rules>
Listing 0V-05: Le fichier XML des règles d'association « Rules.xml ».
VI.2.2 L'outil d’analyse de la modularité logique

Notre outil fourni des interfaces simple à utiliser pour soutenir le développeur à :
générer les règles d'associations,
visualiser la base des règles d'association,
effectuer l’analyse de la modularité de l’application, en se basant sur le couplage et la cohésion.
La figure V.3 présente l’interface graphique principale de notre application. Elle affiche les opérations
primordiales à effectuer :
Chargement du fichier de transactions.
Génération des règles d’association.
Génération des règles internes (cohésion) et les règles externes (couplage).
Dans ce qui suit, nous allons bien détaillés chaque opération avec sa propre fenêtre.
Figure V-020: Fenêtre principale de notre application.
A. Génération des règles d’association
La figure V.4 illustre l'interface graphique qui permet au développeur de générer les règles d'association à
partir d'une base de transactions sauvegardé antérieurement dans le fichier « transaction.xml ». Tout
d’abord, le développeur doit fixer un support et une confidence minimaux. Le résultat sera le fichier
« Rules.xml » qui sera enregistré dans le répertoire de notre application.
Figure V-021: Interface de génération des règles d’association.
B. Chargement des règles d’association
Le développeur à ce stade, a la possibilité de visualiser les règles d’association auparavant générées.

Dans la figure V.5, nous affiche l’interface graphique qui permet d’établir cette tâche. De ce fait, une vue
globale de toutes les règles d’association peut orienter le développeur à saisir et maîtriser la progression de
l’application OO.
C. Couplage et cohésion
Cette phase est la plus importante dans notre approche. Elle constitue la base de l’analyse de la modularité
du logiciel OO avec notre outil « Logical Modularity Analyser ». À ce niveau-là, le développeur charge
l’ensemble des règles d’association en fixant un support et une confidence minimaux. Le résultat trouvé sera
dispatché en deux grands titres :
Le premier indique la cohésion qui illustre les règles logiques internes reliant les classes dans le
même package du logiciel OO. Dans ce cas, nous pouvons sélectionner dans la liste déroulante tous
les packages pour afficher toutes les règles logiques internes ou bien celles qui concernent seulement
un package désiré par le développeur.
Le deuxième représente le couplage qui indique l’ensemble des règles logiques externes reliant les
différents packages de l’application. Idem pour la liste de choix, nous pouvons sélectionner le nom
du package et une opération de filtrage vas nous donner seulement les règles logiques externes qui
peut contenir ce package quel que soit dans la partie Antécédents ou Conséquents.
Figure V-022: Fenêtre représentant le couplage et la cohésion.
À la fin de chaque procédure il y aura une force ‘strength’ qui est considéré comme un repère
indiquant le niveau de la modularité du logiciel OO ; qui est le support de chaque règle. Le résultat trouvé
sera enregistré dans deux fichiers XML, un pour les relations logiques internes « Cohésion.xml » et l’autre
pour les relations logiques externes « Couplage.xml ».
VI.3 Expérimentations
Dans cette partie, c’est notre tour de prouver la faisabilité, la fiabilité, et l’efficacité de notre projet. Nous
avons appliqué notre approche sur trois cas d'étude. Dans les sections qui suivent, nous allons détailler ces
cas en présentons leurs descriptions et les résultats obtenus.
VI.3.1 L’application Modern GPS Tracking Platform "Traccar"

Traccar est connu comme un système de suivi GPS open source. Il peut supporter plus de 170 protocoles
GPS et plus de 1500 modèles de dispositifs de suivi GPS. Ce logiciel peut être utilisé quel que soit le
système de base de données SQL majeur. Il fournit pareillement une API REST facile à utiliser. Les autres
composants de la solution Traccar incluent :
Traccar web app.
Traccar Manager Android app.
Traccar Manager iOS app.
Nous avons téléchargé le dépôt de cette application depuis le Git [GIT20]. Il contient 24 versions. Le
tableau V.1 présente les différentes versions de l'application "traccar".Nous avons calculé les métriques les
plus importantes pour chaque version en utilisant les outils Iplasma [IPL08] qui permet de calculer les
métriques des projets java. Ces indicateurs sont : le nombre de package, classe, et le nombre de ligne de
code.
N Nombre de ligne de
Numéro de version Nombre de package Nombre de classe
° code
01 traccar-3.0 8 258 16360
02 traccar-3.1 8 341 13491
03 traccar-3.2 8 388 14114
04 traccar-3.3 11 428 15289
05 traccar-3.4 11 444 15732
06 traccar-3.5 11 459 16231
07 traccar-3.6 13 493 17609
08 traccar-3.7 16 539 20011
09 traccar-3.8 16 579 22096
10 traccar-3.9 16 590 22599
11 traccar-3.10 17 621 23954
12 traccar-3.11 18 642 25035
13 traccar-3.12 19 686 26902
14 traccar-3.13 19 687 26917
15 traccar-3.14 19 696 27367
16 traccar-3.15 19 726 29014
17 traccar-3.16 19 742 29465
18 traccar-3.17 19 772 30930
19 traccar-4.0 21 810 31741
20 traccar-4.1 21 830 31826
21 traccar-4.2 21 837 32118
22 traccar-4.3 21 852 33260
23 traccar-4.4 22 874 34725
24 traccar-4.5 22 879 34813
Tableau V-00-4: Métriques de l'application Traccar avec Iplasma.
Suite à l’étape de différenciation en utilisant JDiff, les transactions de changement sont générées et
enregistrées dans un fichier XML. Ces transactions sont analysées suivant la première phase de notre
approche, en fixant un support minimum de 15% et une confidence à 100%. Le résultat trouvé après la
génération des règles d’association est plus que 331 règles comme nous montre la figure V.6.
Figure V-023: Les transactions de changement de l'application Traccar.
Nous avons mis la structure des règles d’association générées dans le listing suivant :
2. <rules>
package="org.traccar.database">LdapProvider</item></antecedent><consequent><it
em package="org.traccar">MainEventHandler</item></consequent></rule>
package="org.traccar.web">WebServer</item></antecedent><consequent><item packa
ge="org.traccar">MainEventHandler</item></consequent></rule>
5. …….
6. <rule confidence="1.0" support="0.19047619047619047" id="330"><antecedent><ite
m package="org.traccar.protocol">WatchFrameDecoder</item></antecedent><consequ
ent><item package="org.traccar.geocoder">AddressFormat</item><item package="or
g.traccar.model">User</item><item package="org.traccar.notification">JsonTypeE
ventForwarder</item><item package="org.traccar.model">Server</item></consequen
t></rule>
7. <items minsup="0.15" minconf="100.0">LdapProvider, WebServer, Checksum, Meitra
ckProtocol, Position, Gt06ProtocolDecoder, Group, WrapperInboundHandler, Serve
r, WatchFrameDecoder, CommandsManager, JsonTypeEventForwarder, MainEventHandle
r, IdentityManager, HuabaoProtocolDecoder, WatchProtocolEncoder, AddressFormat
, User, KhdProtocolDecoder, CharacterDelimiterFrameDecoder</items>
8. </rules>
Listing V-06: Les règles d'association de l'application Traccar.

Dans la dernière ligne dans chaque fichier « Rules.xml », nous avons met l’ensemble des itemsets
fréquents, contenant un minimum support et une minimale confidence i.e. l’ensemble des classes
fréquemment changées.
Ce niveau est considéré comme le noyau de notre approche. Maintenant, nous pouvons extraire les
relations logiques internes avec un support minimal de 0.1 et une confidence de 1 et extraire les relations
logiques externes avec les mêmes mesures. Finalement, l’outil affiche cinq relations logiques internes pour
la cohésion et 326 relations logiques externes pour le couplage.
Figure V-024: Cohésion et couplage du logiciel Traccar.
Le résultat trouvé sera enregistré dans deux fichiers XML différents. L’un sera nommé « cohésion.xml »
et l’autre « couplage.xml » comme nous montre le Listing V.5 et Listing V.6.
2. <rules>
3. <rule confidence="1.0" id="5" support="0.19047619047619047"><antecedent><item package="
org.traccar.database">LdapProvider</item></antecedent><consequent><item package="org.tr
accar.database">IdentityManager</item></consequent></rule>
4. <rule confidence="1.0" id="10" support="0.19047619047619047"><antecedent><item package=
"org.traccar">WrapperInboundHandler</item></antecedent><consequent><item package="org.t
raccar">CharacterDelimiterFrameDecoder</item></consequent></rule>
"org.traccar.model">Position</item></antecedent><consequent><item package="org.traccar.
model">User</item></consequent></rule>
"org.traccar.model">Group</item></antecedent><consequent><item package="org.traccar.mod
el">User</item></consequent></rule>
"org.traccar.model">Server</item></antecedent><consequent><item package="org.traccar.mo
del">User</item></consequent></rule>>
8. </rules>
Listing 0V-07: Fichier XML résultat de la cohésion du logiciel Traccar.
2. <rules>
3. <rule confidence="1.0" id="0" support="0.19047619047619047"><antecedent><item
package="org.traccar.database">LdapProvider</item></antecedent><consequent><it
em package="org.traccar">MainEventHandler</item></consequent></rule>
4. <rule confidence="1.0" id="1" support="0.23809523809523808"><antecedent><item
package="org.traccar.web">WebServer</item></antecedent><consequent><item packa
ge="org.traccar">MainEventHandler</item></consequent></rule>
5. …
6. <rule confidence="1.0" id="329" support="0.19047619047619047"><antecedent><ite
m package="org.traccar.model">Server</item><item package="org.traccar.protocol
">WatchFrameDecoder</item></antecedent><consequent><item package="org.traccar.
geocoder">AddressFormat</item><item package="org.traccar.model">User</item><it
em package="org.traccar.notification">JsonTypeEventForwarder</item></consequen
t></rule>
7. <rule confidence="1.0" id="330" support="0.19047619047619047"><antecedent><ite
m package="org.traccar.protocol">WatchFrameDecoder</item></antecedent><consequ
ent><item package="org.traccar.geocoder">AddressFormat</item><item package="or
g.traccar.model">User</item><item package="org.traccar.notification">JsonTypeE
ventForwarder</item><item package="org.traccar.model">Server</item></consequen
t></rule>>
8. </rules>
Listing 0V-008: Fichier XML résultat du couplage du logiciel Traccar.
VI.3.2 L'application Bco.Bcozy

Elle est considérée comme une interface Smart Home basée sur l'emplacement BCozy développé dans le
but d’organiser et de contrôler notre environnement intelligent via une carte 2D [BCO20]. Nous avons
téléchargé le dépôt de cette application contenant 20 versions. Le tableau V.2 illustre des informations sur
les différentes versions ainsi que les métriques nécessaires sur ce logiciel.
Nombre de Nombre de ligne de

N° Numéro de version Nombre de package
classe code
01 bco.bcozy-0.1.0 8 25 1200
02 bco.bcozy-0.2.0 9 34 1200
03 bco.bcozy-0.2.1 9 34 1218
04 bco.bcozy-0.2.2 9 34 1218
05 bco.bcozy-0.2.3 9 32 1140
06 bco.bcozy-1.3.0 9 32 1214
07 bco.bcozy-1.4.0 13 50 1517
08 bco.bcozy-1.4.1 13 50 1484
09 bco.bcozy-1.4.2 13 50 1487
10 bco.bcozy-1.4.3 13 50 1484
11 bco.bcozy-1.4.4 14 49 1448
12 bco.bcozy-1.4.5 13 48 1418
13 bco.bcozy-1.4.6 13 48 1418
14 bco.bcozy-1.5.0 18 62 1672
15 bco.bcozy-1.5.1 18 62 1672
16 bco.bcozy-1.6.0 18 62 1672
17 bco.bcozy-1.6.1 18 62 1662
18 bco.bcozy-1.6.2 18 59 1504
19 bco.bcozy-1.6.3 18 59 1504
20 bco.bcozy-1.6.4 18 59 1407
Tableau V-00-5: Métriques de l'application bco.bcozy avec Iplasma.
Résultat
Nous avons fixé une valeur minimale de 25% pour le support, et pour la confidence sa valeur minimale
fixée est de 100%. Suite de la génération des règles d’association, nous avons découvrit 1543 règles. La
figure V.8 Montre ce résultat.
Figure 0V-025: Les règles d'association de l'application Bco.Bcozy.
La structure des règles d’association générées pour Bco.Bcozy est présentée comme suit :
2. <rules>
3. <rule confidence="1.0" support="0.3333333333333333" id="0"><antecedent><item p
ackage="org.openbase.bco.bcozy.model">LanguageSelection</item></antecedent><co
nsequent><item package="org.openbase.bco.bcozy.util">AuthorizationGroups</item
></consequent></rule>
4. <rule confidence="1.0" support="0.3333333333333333" id="1"><antecedent><item p
ackage="org.openbase.bco.bcozy.util">AuthorizationGroups</item></antecedent><c
onsequent><item package="org.openbase.bco.bcozy.model">LanguageSelection</item
></consequent></rule>
5. …….
6. <rule confidence="1.0" support="0.3333333333333333" id="1542"><antecedent><ite
m package="org.openbase.bco.bcozy.controller">UserSettingsController</item></a
ntecedent><consequent><item package="org.openbase.bco.bcozy.model">LanguageSel
ection</item><item package="org.openbase.bco.bcozy.util">AuthorizationGroups</
item><item package="org.openbase.bco.bcozy.util">BundleLanguagesDetector</item
><item package="org.openbase.bco.bcozy.view">FloatingButton</item><item packag
e="org.openbase.bco.bcozy.view.pane.unit">AbstractUnitPane</item><item package
="org.openbase.bco.bcozy.view.pane.unit">ColorableLightPane</item></consequent
></rule>
7. <items minsup="0.25" minconf="100.0">LanguageSelection, AuthorizationGroups, B
undleLanguagesDetector, FloatingButton, AbstractUnitPane, ColorableLightPane,
UserSettingsController, LoadingPane, UserActionPane.State</items>
8. </rules>
Listing 0-7 : Les règles d'association de l'application Bco.Bcozy.
L’application de notre outil « Logical Modularity analyser » (Figure V.9) avec un support minimal de
0.1 et une confidence de 1 pour extraire les relations logiques internes et externes, nous induit plus de
quatre relations logiques internes pour la cohésion et 1539 relations logiques externes pour le couplage.
Figure 0V-026: Cohésion et couplage du logiciel Bco.Bcozy.
VI.3.3 L'application TEAMMATES

Teammates est un outil de gestions des retours d’expériences. Pour plus d’informations vous pouvez
consulter son site [TEA20]. Nous avons téléchargé le dépôt de versions de ce logiciel depuis Git [GIT20]
contenant 18 versions. Dans le tableau V.3, nous trouvons les diverses versions de l’application
« Teammates ». Comme nous avons fait le calcul des métriques dans les applications précédentes, nous
appliquons la même chose pour Teammates aussi en utilisant IPlasma [IPL08]. Pour chaque version, nous
présentons le nombre de package, classe, et le nombre de ligne de code.
Nombre de Nombre de ligne de

N° Numéro de version Nombre de package
classe code
01 teammates-5.57 31 310 85456
02 teammates-5.58.01 31 310 85499
03 teammates-5.58.02 31 310 85629

04 teammates-5.58 31 310 85618
05 teammates-5.59 31 310 85686
06 teammates-5.60 31 310 85678
07 teammates-5.61 31 310 58678
08 teammates-5.64 31 312 86786
09 teammates-5.65 31 312 86553
10 teammates-5.66 31 312 86575
11 teammates-5.67 31 312 86589
12 teammates-5.68 31 312 86598
13 teammates-5.69 31 312 86311
14 teammates-5.71 31 314 86765
15 teammates-5.72 31 314 86962
16 teammates-5.72.01 31 314 86952
17 teammates-5.72.02 31 314 86959
18 teammates-5.73 31 686 87599
Tableau 0V-0-6: Métriques de l'application Teammates avec IPlasma.:
Résultats
Dans ce cas, nous avons fixé un support minimum de 10% et la confidence de 100%. Au-delà de la
génération des règles d’association, nous avons détecté neuf règles (Figure V.10).
Figure 0-27: Les règles d'association de l'application Teammates.
L’ensemble des règles d’association et les itemsets fréquents sont illustrés dans ce listing :
2. <rules>
3. <rule confidence="1.0" support="0.125" id="0"><antecedent><item package="teamm
ates.ui.controller">InstructorFeedbackCopyAction</item></antecedent><consequen
t><item package="teammates.storage.api">FeedbackQuestionsDb</item></consequent
></rule>
4. …..
5. <rule confidence="1.0" support="0.125" id="8"><antecedent><item package="teamm
ates.ui.controller">InstructorFeedbackCopyAction</item><item package="teammate
s.ui.controller">StudentFeedbackSubmissionEditPageAction</item></antecedent><c
onsequent><item package="teammates.storage.api">FeedbackQuestionsDb</item></co
nsequent></rule>
6. <items minsup="0.1" minconf="100.0">InstructorFeedbackCopyAction, Const, Instr
uctorPrivileges, TimeHelper, FeedbackQuestionsDb, StudentFeedbackSubmissionEdi
tPageAction</items>
7. </rules>
Listing V-09: Les règles d'association de l'application Teammates.

Notre outil « Logical Modularity analyser » (figure V.11) s’est appliqué avec un support minimal de
0.1 et une confidence de 1 pour extraire les relations logiques internes et externes, nous induit une seule
relation logiques internes pour la cohésion et huit relations logiques externes pour le couplage.
Figure V-028: Cohésion et couplage du logiciel Teammates.
VI.3.4 Discussion des résultats

Par le biais de la mise en service de notre approche qui consiste à analyser la modularité logique des
logiciels OO, nous avons pu atteindre une rapidité d’analyse des applications (presque des millisecondes).
De ce fait, nous avons l’aptitude d’effectuer une analyse des importantes et grandes applications Java
engendrant un nombre remarquable des packages et des classes d’une allure simple et facile. Cet aspect est
considéré comme un point fort de notre implémentation.
Après l’application de divers scénarios d’analyse sur les trois logiciels depuis NetBeans, nous avons
constaté que notre outil est un appui pour la génération des transactions, les règles d’association ainsi que
des règles logiques internes (cohésion) et des règles logiques externes (couplage).
En revanche, graduellement au cours du temps ça nous a favorisés et facilités infiniment la

compréhension de ces applications sans que nous connaissions d'avance leurs codes source.
Plusieurs études ont utilisé des graphes de dépendances statiques entres les entités des applications OO
comme l’application Sourcetrail afin de visualiser les différentes relations statiques entres les packages et
leurs classes. Nous avons comparé les résultats de ces outils avec notre outil. Le résultat trouvé nous
implique que l’utilisation de notre outil dégage une vision explicite et réelle sur les dépendances concrète sur
chaque application et qu’il y on a des dépendances logiques inexistantes dans le mode statique. Enfin, la
mesure de la modularité logique du logiciel à ce stade sera plus fidèle et ciblée.
Prenant par exemple, la règle logique dans l’expérimentation sur l’application « Traccar » dans le Listing
V-8 :
<rule confidence="1.0" id="6" support="0.3333333333333333"><antecedent><item package="org.trac
car.helper">Checksum</item></antecedent><consequent><item package="org.traccar">MainEventHandl
er</item></consequent></rule>
Listing V-10: Exemple d’une règle logique de l’application Traccar.
Pour effectuer la comparaison, nous avons pris un zoom-in dans le graphe des dépendantes statiques de
cet exemple (figure V-12). Nous avons découvert que cette règle n’existe pas dans le graphe.
Figure V-29: Zoom-in du graphe des dépendances logiques de l'application Traccar.
V.4 Conclusion
Dans ce chapitre, nous avons présenté la mise en œuvre des différentes phases de notre approche : la
génération des règles d’association, la production des règles logiques internes nommé « cohésion » et des
règles logiques externes « couplage » avec un minimum support et une minimum confidence.
Nous avons automatisé ces étapes via notre outil « logical modularity Analyzer ». Par la suite, nous avons
analysé trois cas d’étude dans le but de manifester la fiabilité et l’efficience de notre suggestion pour évaluer
et analyser la modularité logique des logiciels OO. Les aboutissements et les performances ont été très
encourageants.
Le chapitre suivant clôture notre mémoire, en présentant les contributions de notre travail et ses
perspectives.
Chapitre VI
Conclusion & Perspectives
L’évolution des grands systèmes logiciels OO dégraderait et modifierait avec le temps, sa structure et sa
modularité. Par conséquent, parmi les principaux problèmes en génie logiciel, l’analyse et l’évaluation de la
modularité du système logiciel présente un vrai défi i.e. le logiciel OO évolué a-t-il encore une modularité
adéquate ? Sinon, c’est quoi les défauts de modularités existants ? En revanche, l'automatisation de cette
tâche offre une assistance énorme aux développeurs. Afin d’atteindre cet objectif, nous nous sommes basées
sur un type intéressant de dépendances connues par les dépendances logiques en vue de proposer notre
approche d’analyse de la modularité des logiciels OO.
VI.1 Contribution
A travers notre travail, nous avons approuvé et déduit les avantages primordiaux des dépendances
logiques extraites à partir d’un dépôt de versions du logiciel, pour aider le développeur à identifier son
niveau de modularité et détecter les éventuelles parties touchées par un défaut de modularités.
Notre objectif principal était l’automatisation des tâches de l’analyse de la modularité logique dans le but de
faciliter et soutenir considérablement cette analyse pour le développeur. Nous pouvons synthétiser les
contributions fondamentales de notre travail dans les points suivants :
L’analyse du dépôt de versions d'un système logiciel OO afin de générer les dépendances logiques
entre ses classes :
Extraction des transactions de changement.
La génération des règles d'association en utilisant l'algorithme Apriori.
Le stockage des règles d'association dans une BDD accessible par notre outil d'analyse.
Nous avons proposé une approche basée sur les dépendances logiques pour analyser la modularité
logique du logiciel OO. Cette analyse permet de détecter les relations de cohésion logique et de
couplage logique pour chaque package.
L’automatisation des tâches précitées à travers notre outil réalisé par le langage Java, nous a facilité
l’analyse de la modularité de grands systèmes logiciels OO.
Dans l'intention de prouver la faisabilité et l’efficacité de notre approche proposée ; nous avons analysé
les dépôts de versions de trois applications OO Open-source de grande taille. Les résultats trouvés étaient
très encourageants car notre outil automatise convenablement les fonctions de la génération des règles
d’association, l’analyse de la modularité logique et la détection les défauts de modularité.
VI.2 Perspectives de recherche

Les résultats de notre travail exposé dans notre mémoire fournissent des nombreuses perspectives de
recherche au niveau théorique et au niveau pratique. Dans cette partie, nous exposons sommairement une
poignée de ces perspectives qui nous semblent être plus précieuses :
Une perspective directe à ce travail est l’analyse des grands dépôts de versions, afin de valider plus
notre proposition, et par conséquent notre outil réalisé.
Nous avons appliqué notre travail au niveau de granularité classes et packages qui nous fournit des
résultats idéals pour le logiciel OO. Par ailleurs, nous avons la possibilité d’exercer notre idée à un
niveau de granularité plus fin : méthodes, attributs . . . etc. Cela, peut donner plus de richesses à nos
résultats d’analyse.
Notre approche est destinée aux logiciels OO, mais elle est adéquatement générale pour être
appliquées sur d'autres paradigmes de programmations. Ce qui présente une perspective intéressante
à ce travail.
D’autres techniques plus sophistiquées de Mining peuvent être utilisées. Par exemple et puisque les
techniques basées sur l’intelligence artificiel (IA) gagnent beaucoup de succès dernièrement, nous
pouvons les utiliser pour améliorer plus la phase d’extraction de dépendances logiques (ex. Deep
Learning).
Finalement, nous pensons que la proposition de métriques bien précises et automatiquement
calculées pour la cohésion et le couplage logique basées sur les notions de support et de confiances
des règles d’associations, ça sera très intéressant.
Bibliographie
[1] [ADA11] Adam Przybylek .AN EMPIRICAL ASSESSMENT OF THE IMPACT OF ASPECT-
ORIENTED PROGRAMMING ON SOFTWARE MODULARITY Department of Business.2011.
[2] [AJI17] Nemitari Ajienka, Andrea Capiluppi. \Understanding the interplay between the logical and
structural coupling of software classes". Journal of Systems and Software, Volume 134, Issue C, Pages
120-137, December 2017.
[3] [AJI18] Nemitari Ajienka, Andrea Capiluppi, Steve Counsell. \An empirical study on the interplay
between semantic coupling and co-change of software classes". Journal of Empirical Software
Engineering, Volume 23, Issue 3, pp 1791{1825, June 2018.
[4] [ALE64] Alexander, C. (1964), Notes on the synthesis of form, Harvard University Press, Cambridge.
[5] [ALE16] Mesure et évolution de la modularité dans les projets open-source orientés objet. Alenezi et
Zarour.2016.
[6] [ALT09] Kerstin Altmanninger, Martina Seidl, Manuel Wimmer, "A Survey on Model Versioning
Approaches. International Journal of Web Information Systems, vol 5(3), pp. 271-304, 2009.
[7] [AMB09] M. D'Ambros, M.Lanza, R.Robbes. \On the Relationship Between Change Coupling and
Software Defects". In Proceedings of 16thWorking Conference on Reverse Engineering, Lille, France,
2009.
[8] [ANC17] Alexandre Ancel Introduction à Git .IHU Strasbourg - Institut de Chirurgie Guidée par
l’Image / IRCAD. 2017.
[9] [ANT20] Ant, available from : http ://www.chicoree.fr/w/Premiers pas avec Ant [accessed 26 August
2020].
[10] [BAL19]. Proceedings of the 9th International Conference on Foundations of Computer-Aided Process
Design. Michael Baldea, ... Tam T. Do, in Computer Aided Chemical Engineering, 2019.
[11] [BAN02] Bansiya, J.; Davis, C. A hierarchical model for objectoriented design quality
assessment. IEEE Trans. Softw. Eng. 2002, 28, 4–17.
[12] [BAS10] A. BASK, M. RAJAHONKA, M. TINNALA. “The concept of modularity: diffusion from
manufacturing to service production.” Journal of Manufacturing Technology Management, Vol. 21 Iss3,
2010, pp. 355- 375.
[13] [BCO20] available from :https ://github.com/openbase/bco.bcozy [accessed 31 August 2020].
[14] [BEN12] Ben nedjema et Benlaiter. EXTRACTION DES REGLES D’ASSOCIATION POUR L’AIDE
A LA DECISION. UNIVERSITE DE M’SILA FACULTE DES MATHEMATIQUES ET DE
L’INFORMATIQUE. Département d’Informatique 2012.
[15] [BIE95] Bieman, J.M.; Kang, B.K. Cohesion and reuse in an objectoriented system. In Proceedings of
the Symposium on Software Reusability (SSR 1995), Seattle, WA, USA, 29–30 April 1995; pp. 259–
262.
[16] [BOO95] Technologie Objet — Abstraction et Modularité : Classes. UML : Unified Modeling
Language. Auteurs: Grady Booch, Ivar Jacobson, James Rumbaugh (1995).
[17] [BOU09] Boulanger, Alain . Génération des règles d'association : treillis de concepts denses Mémoire.
Montréal (Québec, Canada), Université du Québec à Montréal, Maitrise en informatique,2009.
[18] [BOU16] Amina Boudjedir. Utilisation des Systèmes de Réécriture pour la Modélisation et la
Vérification des Applications Orientées Aspect. UNIVERSITÉ BADJI MOKHTAR-ANNABA.2015-
2016.
[19] [BON19] M Boni, 2019. Les séries québécoises : modularité, circulation et transnationalisme.
[20] [BOU19] Boumenkar Amina. MEMOIRE Présenté en vue de l’obtention du Diplôme de Master
ASSISTANCE À L’ÉVOLUTION DU LOGICIEL BASÉE SUR SON HISTORIQUE DES
CHANGEMENTS. Université Mohamed Chérif Messadia Souk-AhrasFaculté des Sciences et de la
Technologie. 2019.
[21] [BRI99] Briand, L.C.; Morasca, S.; Basili, V.R. Defining and validating measures for object-based
high-level design. IEEE Trans. Softw. Eng. 1999, 25, 722–743.
[22] [BRI01] Coupling and Cohesion as Modularization Drivers: Are We Being Over-Persuaded? Fernando
Brito e Abreu- LisboaMiguel Goulão. Universidade NOVA de Lisboa Instituto Universitário. January 2001.
[23] [BRU01] Brusoni, S. Et Prencipe, A. (2001), Unpacking the black box of modularity.
[24] [CHE07] Gino chénard université du québec à montréal vers une approche automatique pour
l'extraction des règles d'affaires d'une application. octobre 2007.
[25] [CHE11] H. Cherait, and N. Bounour, “Toward a Version Control System for Aspect Oriented
Software”, In Proceedings of 1st International Conference on Platform Architecture. Amrit Tiwana, in
Platform Ecosystems, 2014.
[26] [CHE12] H. Cherait, and N. Bounour, “Modeling Software Evolution through Version Control
System”, In Proceedings of Colloque Africain sur la Recherche en Informatique et Mathématiques
Appliquées (CARI’12), Alger, Algérie, 13-16 Octobre 2012.
[27] [CHE14] H. Cherait. « Gestion des Preoccupations dans le Contexte de Maintenance". These de
Doctorat, Faculte des sciences de l'ingéniorat, Departement d'informatique, Universite UBMA, Juin
2014.
[28] [CHE15] H. Cherait, and N. Bounour, “History-based Approach for Detecting Modularity Defects in
Aspect Oriented Software”, Informatica: An International Journal of Computing and Informatics, 2015,
Vol 39(2), pp. 187–194.
[29] [CHI94] Chidamber, S.R.; Kemerer, C.F. A metrics suite for object-oriented design. IEEE Trans. Softw.
Eng. 1994, 20, 476–493.
[30] [COM93] Computer Society Press, Standards Collection (1993). Software Engineering, The Institute of
Electrical and Electronics Engineers, Inc
[31] [CON07] Larry Constantine, Usage Centered Design Archived 2008-10-10 at the Wayback Machine at
qconlondon.com. 2007.
[32] [DAM06] Marco D'Ambros, Michele Lanza. “Reverse Engineering with Logical Coupling”. In
Proceedings of 13th Working Conference on Reverse Engineering, Benevento, Italy, 2006.
[33] [EDE92] Eder, J.; Kappel, G.; Schre, M. Coupling and cohesion in object-oriented systems.
In Proceedings of the Conference on Information and Knowledge; ACM Press: New York, NY, USA,
1992.
[34] [EDE95] Eder, J., Kappel, G. et Schrefl, M. (1995). Coupling and cohésion in object-oriented systems.
Technical report. Johannes-Kepler. University, Linz, Austria.
[35] [FAY96] Fayyad, U., Piatetsky-Shapiro, G., Smyth, P., and Uthurusamy, R.,editors (1996). Advances in
Knowledge Discovery and Data Mining. AAAI/MIT Press.1, 5.
[36] [FLU05] B. Fluri, H. C. Gall, and M. Pinzger (2005). Fine-grained analysis of change couplings. In
Proceedings of 5th WICSA’05, pp. 66–74.
[37] [GAL99] H. Gall, M. Jazayeri, and C. Riva, “Visualizing software release histories: The use of color
and third dimension”, In Proceedings of International Conference on Software Maintenance (ICSM),
Oxford, 1999, pp. 99—108. [BAL&CLR01] C Baldwin, K Clark, 2001.Modularity after the Crash.
[38] [GIT20] https://git-scm.com/[accessed 31 August 2020].
[39] [GOU10] Goudey, A., Bonnin, G. and Biausser, H., 2010. Marketing Pour Ingénieurs. Paris: Dunod.
[40] [GUA15] Guan, X.H ;Qu, Y.;.; Zheng, Q.H.; Liu, T.; Wang, L.D.; Hou, Y.Q.; Yang, Z.J. Exploring
community structure of software call graph and its applications in class cohesion measurement. J. Syst.
Softw. 2015, 108, 193–210.
[41] [GUE17] Guendouzi Wassila. Approches bio-inespérée pour la détection d’intrusions dans un réseau
d’ordinateurs. Université des sciences et de la technologie Houari Boumedien Alger. 2017.
[42] [HAN11] Hani Abdeen & Stéphane Ducasse. Modularization Metrics: Assessing Package Organization
in Legacy Large Object-Oriented Software Conference: 18th Working Conference on Reverse
Engineering, WCRE 2011, Limerick, Ireland, October 17-20, Université de Montréal 2011.
[43] [HAS08] The Road Ahead for Mining Software Repositories Ahmed E. Hassan Software Analysis and
Intelligence Lab (SAIL) School of Computing, Queen’s University, Canada ahmed@cs.queensu.ca
(2008). pp. 48–57.
[44] [HIN09] K Hinsen, K Läufer, G Thiruvathukal. Essential Tools: Version Control Systems., 2009.
[45] [IPL20] Iplasma, available from : http ://loose.upt.ro/iplasma/ [accessed 31 August 2020].
[46] [IEEE90] Proceedings. Workshop on the Management of Replicated Data. G.J. Popek Auteurs.1990.
[47] [JAC05] Jacobson, I. and Ng, P., 2005. Aspect-Oriented Software Development With Use Cases.
Boston: Addison-Wesley.
[48] [JAN17] Jannik Laval .Package Dependencies Analysis and Remedia7ion in Object-Oriented Systems.
Laboratoire d'Informatique Fondamentale de Lille, Inria Lille - Nord Europe 2017.
[49] [JEN07] Jenkins, S.; Kirk, S.R. Software architecture graphs as complex networks: A novel parttion
scheme to measure stability and evolution. Inf. Sci. 2007, 177, 2587–2601.
[50] [JER93]Jerry Fodor, La Modularité de l'esprit : essai sur la psychologie des facultés, collection
Propositions, Les Éditions de Minuit, Paris, 1993.
[51] [JDI20] JDiff, available at : www.jdiff.org, [accessed 23 august 2020].
[52] [JOH14] Johann Eder, Gerti Kappel & Michael Schre . Coupling and Cohesion in Object-Oriented
Systems. Institut fur Witschaftsinformatik, Universitat Linz Altenbergerstr. 69, A-4040 Linz, Austria,
2014.
[53] [KAG07] H. Kagdi, M. L Collard, and J. I. Maletic (2007). A Survey and Taxonomy of Approaches for
Mining Software Repositories in the Context of Software Evolution. Journal of Software Maintenance
and Evolution: Research and Practice, Vol. 19, No. 2, pp. 77-131.
[54] [KAS11] The Road to Feature Modularity? Christian Kästner Philipps University Marburg Sven Apel
University of Passau Klaus Ostermann Philipps University Marburg.2011.
[55] [LAN07] M. Lanza, and R. Robbes, \A Change-based Approach to Software Evolution",
Electronic Notes in Theoretical Computer Science (ENTCS). Elsevier, Vol. 166, pp. 93-109,3 janvier 2007.
[56] [LEE95] Lee, Y.S.; Liang, B.S. Measuring the coupling and cohesion of an object-oriented program
based on information flow. In Proceedings of the International Conference on Software Quality,
Maribor, Slovenia, 6–8 November 1995; pp. 81–90.
[57] [MAI10] Détection et correction automatique des défauts de conception au moyen de l’apprentissage
automatique pour l’amélioration de la qualité des systèmes. Abdou Maïga
[58] [MAR94] Martin, R. C. (1994). Object oriented dcsing quality metrics an analysis of dependeneies.
Www.objectmentor.com.
[59] [MAR94] Martin, R. C. (1994). Object oriented dcsing quality metrics an analysis of dependeneies.
Www.objectmentor.com.
[60] [MAR97] Martin, R. C. (1997). Stability. Www.objectmentor.com.
[61] [MAR98] Harrison, R.. Counsell, S. et Nithi. R. (1998). Coupling metrics for object,-oriented design.
Dans METRICS '98 : Proceedings of the 5th International Symposium on Software Metrics. IEEE
Computer Society, Washington, DC, USA, p. 150.
[62] [MAR02] Martin, R. Agile Software Development, Principles, Patterns, and Practices; Prentice-Hall:
New York, NY, USA, 2002.
[63] [MAR03] Martin, R. C. (2003). Agile Software Development. Prentiee-Hall.
[64] [MAR09] Marco D’Ambros, Michele Lanza, Romain Robbes. “On the Relationship Between Change
Coupling and Software Defects”. In Proceedings of 16th Working Conference on Reverse Engineering,
Lille, France, 2009.
[65] [MES13] Messaadi Saber. « Une approche de détection des patrons de changement a partir d’un dépôt
base sur les règles de réécriture», Mémoire de Master Mathématiques, Informatique et Applications aux
Sciences ,2013.
[66] [MET20] http://metrics2.sourceforge.net/, [accessed 31 august 2020].
[67] [MEY16] Meyer, Bertrand. and Nordio, Martin. Software Engineering. 2016. Cham: Springer
International Publishing AG.
[68] [MIC16] Investigating software modularity using class and module level metrics. Michael English, ...
J.J. Collins, in Software Quality Assurance, 2016.
[69] [MOK18] Mokhtari et Moulkhaloua Système DE Détection D'intrusions Informatiques par Système
Multi-Agents. Institut des Sciences. Département des Mathématiques et de l'Informatique. [MUL15] G
Müller, 2015. Liberté, Egalité, Modularité: In Memory of Werner Callebaut (1952–2014).
[70] [MOR89] Morris, K. Metrics for Object-Oriented Software Development Environments. Master’s
Thesis, Sloan School of Management, MIT, Cambridge, MA, USA, 1989.
[71] [OFF08] JEFF OFFUTT, AYNUR ABDURAZIK , STEPHEN R. SCHACH . Quantitatively
Measuring Object-Oriented Couplings. Department of Electrical Engineering and Computer Science,
Vanderbilt University, Nashville, TN 37235, USA.
[72] [PAT92] Patel, S.; Chu, W.C.; Baxter, R. A measure for composite module cohesion. In Proceedings of
the 14th International Conference on Software Engineering, Melbourne, Australia, 11–15 May 1992;
pp. 38–48.
[73] [PAS00] Nicolas Pasquier. Data Mining : algorithmes d'extraction et de réduction des règles
d'association dans les bases de données. January 2000.Authors: Nicolas Pasquier. Université Côte
d'Azur.
[74] [PFL90] Pfleeger, S. L. (1990). A Framework for Software Maintenance Metrics. IEEE Transactions on
Software Engineering, pp. 320-327.
[75] [PRE97] Pressman, R. S. (1997). Software Engineering A Practitioncr's Approach, 4e édition. McGraw-
Hill.
[76] [PRZ10] AN EMPIRICAL ASSESSMENT OF THE IMPACT OF ASPECT-ORIENTED
PROGRAMMING ON SOFTWARE MODULARITY Adam Przybylek Department of Business
Informatics, University of Gdansk, Piaskowa 9, 81-824, Sopot, Poland 2010.
[77] [RYS04] F.V. Rysselberghe, and S. Demeyer. “Studying software evolution information by visualizing
the change history”. In Proceedings of International Conference on Software Maintenance, 2004, pp. 328—
337.
[78] [SOU20] www.sourcetrail.com [accessed 07 September 2020].
[79] [SOS06] M. SOSA, S. EPPINGER, C. ROWLES. “A network approach to define component
modularity.” Working Paper Series, INSEAD, p. 34. 2006.
[80] [STE74]. Structured design | IBM Systems Journal - ACM Digital Library.Stevens et Constantine, 1974.
[81] [STE17] Stephen W. Clyde & Jorge Edison Lascano. Unifying Definitions for Modularity, Abstraction,
and Encapsulation as a Step Toward Foundational Multi-Paradigm Software Engineering Principles.
Logan, Utah, USA. 2017.
[82] [SUB18] Subversion, avalable at: http:subversion.tigris.org [online May 2018].
[83] [SUR15] Modularization Smells. Girish Suryanarayana, ... Tushar Sharma, in Refactoring for Software
Design Smells, 2015.
[84] [TAY02] C.M.B. Taylor and M. Munro. “Revision towers”. In Proceedings of Workshop on
Visualizing Software for Understanding and Analysis VISSSOFT, Paris, France, 2002, pp. 43-50.
[85] [TEA20] available from :https ://github.com/TEAMMATES/teammates/[accessed 05 September 2020].
[86] [TUR12] W Turkel, A Crymble, 2012. Code Reuse and Modularity in Python.
[87] [VOI07] L. Voinea and A. Telea. “Visual data mining and analysis of software repositories”. Journal of
Computers & Graphics, 2007, Vol 31, pp.410–428. technologies, products and organizations, Industrial and
Corporate Change, 10(1).
[88] [WEI98] J. Weidl, and H. C Gall. “Binding object models to source code: An approach to object-
oriented re-architecting”. In Proceedings of the 22nd International Computer Software and Applications
Conference, 1998, pp. 26–31.
[89] [WAR04] Ware. C. (2004). Information Visualization : Perception for Design. Morgan Kaufmann.
[90] [WIL92] Wilde, N. et R. Huitt (1992). Maintenance support for object-oriented programs. IEEE
Transactions on Software Engineering, Vol. 18, Issue 12, pp. 1038-1044.
[91] [WON10] S. Wong,Y.Cai,and M. Dalton. “Change Impact Analysis with Stochastic Dependencies”.
Department of Computer Science, Drexel University, Technical Report DUCS-10-07, October 2010.
[92] [XIA19] Measuring Software Modularity Based on Software Networks. Y Xiang, W Pan, H Jiang, Y
Zhu, H Li, Entropy 2019, 21, 344.Department of Computer Science, Western Michigan University,
Kalamazoo, MI 49008, USA.
[93] [YIN05] A.T.T. Ying, J.L. Wright, and S. Abrams. “Source code that talks: an exploration of Eclipse
task comments and their implication to repository mining”. In Proceedings of International Workshop on
Mining Software. Repositories (MSR), Saint Louis, Missouri, USA, 2005, pp. 1-5.
[94] [YOU79] Yourdon, E. et Constantine, L. (1979). Straetured Design. Prentice Hall.
[95] [ZEL19]Zellagui Soumia. Reengineering Object Oriented Software Systems for a better
Maintainability. Awarded by University of Montpellier. July 2019.
[96] [ZHA18] Zhang, J.; Wu, J.J.; Xia, Y.X.; Ye, F.H. Measuring cohesion of software systems using
weighted directed complex networks. In Proceedings of the 2018 IEEE International Symposium on
Circuits and Systems (ISCAS 2018), Florence, Italy, 27–30 May 2018; pp. 1–5.
[97] [ZHO17] Zhou Gu, A.H;, X.F.; Li, Z.H.; Li, Q.F.; Li, L. Measuring Object-Oriented Class Cohesion
Based on Complex Networks. Arab. J. Sci. Eng. 2017, 42, 3551–3561.
[98] [ZIM05] T. Zimmermann, P. Weissgerber, S. Diehl, and A. Zeller. “Mining version histories to guide
software changes”. IEEE Transactions on Software Engineering, 2005, Vol 31(6), pp. 429–445.

Chapitre I

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Chapitre I

Transféré par

Droits d'auteur :

Formats disponibles

‫وزارة الت ـع ـلـيــم العــالــي وال ـب ـحــث ال ـع ـل ـمــي‬

Université Mohamed Chérif Messadia ‫جــامــعــة مـحمـد الشـريـف مساعديــة‬

Faculté des Sciences et de la Technologie

DIRECTRICE DE MEMOIRE : CHERAIT Hanane MCB U.SOUK-AHRAS

A mes très chers parents

A mes très frères, mes sœurs et mes beaux-frères

Mots-clés : Modularité de logiciel, Historique de l’évolution, Système de contrôle de version, Mining,

CHAPITRE I :INTRODUCTION GENERALE.................................................................................1

Tableau II-1: Comparaison entre la cohésion et le couplage.............Error! Bookmark not defined.

Listing IV-1:L'algorithme Apriori [BOU09].....................................................................................53

I.1 Contexte de Travail

I.2 Problématiques et Motivations

1.3 Objectifs et Contributions

- L’analyse de l’historique de l’évolution d’un système logiciel OO :

I.4 Contenu de mémoire

II.2.2 Les principes de la conception

II.2.3 Définition de la modularité

Figure 0II-0-1: La modularité d’un système logiciel

II.2.5 Le système modulaire

II.2.6 A quoi sert la modularité ?

Unité de documentation et de déploiement i.e. Découpage d’un programme en plusieurs unités

II.3 L’historique de la modularité

II.4 Les préceptes de la modularité

II.5 Les métriques de la modularité

Avantages d'une cohésion élevée :

II.5.1.2 Les types de la cohésion

Cohésion accidentelle ou aléatoire ou coïncidence : le module contient plusieurs fonctions sans

Figure 0II-0-2: Spectre du degré de la cohésion. [PRE97].

II.5.1.3 Exemples de mesures de cohésion

Figure II-0-3: Couplage entre les modules.

II.4.2.1 Propriétés du couplage

Degré : est le nombre de connexions entre le module et les autres.

Inconvénients du couplage serré :

II.4.2.2 Types de couplage

Figure II-0-4:Types de couplage [YOU79]

Figure II-5: Spectre du degré de couplage [PRE97].

II.4.2.3 Exemples de mesures de couplage

II.5.3 Cohésion versus couplage

Montre la force fonctionnelle relative du Montre l’indépendance relative entre les

Figure II-6: Exemple sur la cohésion et le couplage.

II.6 La modularité et les systèmes orientés objet

II.6.1 Le modèle orientés objet

 Agrégation => composition par regroupement ("partie de")

Figure II-7: Les principes des systèmes OO

La figure II.8 présente un exemple de Meta modèle orienté objet.

Figure II-8: Exemple d'un méta-modèle OO

II.6.2 La modularité dans un logiciel orientée objet

Figure II-9: Modules et Classes.

II.6.3 Critères de modularisation d’un logiciel OO

1 Décomposabilité: Capacité de décomposer un problème en sous-problèmes, semblable à la méthode

II.6.4 Les Principes de la modularisation orientée objet

II.6.4.1 Cohésion orienté objet

Exemple sur la cohésion OO

Figure II-10: Exemple sur la cohésion OO [SUR15]

Les types de la cohésion de classe :

II.6.4.2 Couplage orienté objet

B. Couplage entre paquets (Packages)

Dans ce chapitre, nous présentons le principe de fonctionnement d’un système de contrôle de

III.2 Les Systèmes de Contrôle de Versions (SCVs)

III.2.1 Définition des SCVs

Ils ont été créés pour répondre à des besoins initiaux :

La gestion de l'évolution des fichiers d'un projet et de leur historique de modifications.

Figure III-00-5: Conserver l’historique

Figure III-00-6:Travail collaboratif