Visualisation des métriques de cohésion et de couplage

UNIVERSITÉ DE SHERBROOKE

Faculté de génie

Département de génie électrique et de génie informatique

VISUALISATION DES METRIQUES DE

COHESION ET DE COUPLAGE

Mémoire de maîtrise

Spécialité : génie électrique

Réda BENSMAIA

Jury : Ruben GONZALEZ-RUBIO (directeur)

Soumaya CHERKAOUI

Frédéric MAILHOT

RÉSUMÉ

De nos jours, les logiciels sont de plus en plus complexes. La complexité des logiciels augmente avec leur taille et de ce fait, parfois la bonne structure originale est perdue. En conséquence, la vérication continue de la qualité du développement de ces logiciels est devenue indispensable. Elle nécessite un contrôle continu de la qualité du code tout au long du processus de développement. Plusieurs métriques ont été proposées an de quantier cette qualité, dans beaucoup de cas, ces métriques interviennent une fois le logiciel ni, or le contrôle de qualité serait plus ecace s'il intervenait tout au long de la phase de codage. Les métriques logicielles renseignent sur la qualité du code. Elles sont généralement présentées sous forme de tableau de données et sont donc dicilement exploitables.

L'objectif général en développement de logiciels est de maintenir un produit de bonne qualité, qui soit extensible, d'une maintenance facile et réutilisable. Un grand problème en logiciel est constitué par les dépendances entre classes et paquets : c'est le couplage. On parlera d'architecture à couplage faible, lorsqu'elle est exible, les changements sont simples et leurs coûts ne sont pas très élevés. Par contre, l'architecture devient rigide lorsque le couplage fort rend l'ajout de nouvelles fonctionnalités et la maintenance d'un logiciel très dicile. Les coûts de cette maintenance deviennent donc très élevés.

Un autre problème connu est le manque de cohésion d'une classe, une classe est dite de bonne cohésion, si tous ses attributs sont utilisés par toutes ses méthodes. Dans le cas contraire, les méthodes et attributs ne communiquent pas susamment pour se retrouver dans une seule classe, et devrait être subdiviser en plusieurs classes.

L'objectif de notre projet est de visualiser des indicateurs capables de distinguer une architecture exible d'une architecture rigide.

Pour mener à bien notre projet, une étude des diérentes métriques déjà proposées est nécessaire, en considérant les métriques ayant un impact sur l'architecture, telle que les métriques de couplage entre classes et paquets. Pour ensuite proposer une visualisation, an de faciliter l'interprétation des résultats obtenus par les métriques facilitant ainsi le travail du développeur.

Au nal, cette visualisation devrait permettre d'identier les problèmes d'architecture. Ces zones critiques seront donc achées à l'écran. Ainsi cette visualisation permettra de mieux guider le développeur dans sa maintenance.

Mots-clés : cohésion, couplage, cyclique, métriques, visualisation, qualité logicielle.

TABLE DES MATIÈRES

1 INTRODUCTION 1

1.1 Mise en contexte et problématique . . . 1

1.2 Dénition du projet de recherche . . . 2

1.3 Objectifs du projet de recherche . . . 3

1.4 Plan du mémoire de recherche . . . 4

2 ETAT DE L'ART 5 2.1 Les métriques traditionnelles . . . 5

2.1.1 Nombre de lignes de Code . . . 5

2.1.2 Métriques de Halstead . . . 6

2.1.3 Complexité Cyclomatique de McCabe (MCC) . . . 6

2.2 Les métriques orientées objet . . . 9

2.2.1 Les métriques proposées par Chidamber et Kemerer . . . 9

2.2.2 Métrique de cohésion de Hitz et Montazeri . . . 11

2.2.3 Métriques de cohésion de Henderson-Sellers . . . 13

2.2.4 Les métriques proposées par Li et Henry . . . 14

2.2.5 Les métriques de Martin . . . 14

2.3 Visualisation des métriques . . . 16

2.3.1 CodeCrawler . . . 16 2.3.2 MetricView . . . 16 2.3.3 Metrics 1.3.8 . . . 17 2.3.4 VCC_0.1 . . . 19 2.3.5 SonarQube . . . 19 2.4 Metrics 1.3.8 , SonarQube et VCC_0.1 . . . 21 2.5 Conclusion du chapitre . . . 25

3 Le Couplage et la cohésion dans une architecture de logiciel 27 3.1 Couplage . . . 27 3.2 Cohésion . . . 29 4 Transistion de VCC_0.1 à VisualAideCC 31 4.1 État du programme VCC_0.1 . . . 32 4.1.1 Couplage . . . 32 4.1.2 Cohésion . . . 33

4.2 Validation et correction des métriques . . . 34

4.2.1 Métriques de couplage . . . 35

4.2.2 Métriques de cohésion . . . 38

4.3 Ajouts au niveau des métriques de couplage . . . 41

4.3.1 Algorithme de Tarjan . . . 42

4.3.2 Algorithme de Donald Johnson . . . 45

4.4 Ajouts au niveau des métriques de cohésion . . . 48 iii

iv TABLE DES MATIÈRES 4.5 Conclusion du chapitre . . . 50 5 Validation de VisualAideCC 53 5.1Othello-1. . . 53 5.1.1 Cohésion de Othello-1 . . . 54 5.1.2 Couplage de Othello-1 . . . 56 5.2 Othello-2 . . . 57 5.2.1Cohésion de Othello-2 . . . 57 5.2.2 Couplage Othello-2 . . . 59 5.3 JFig-1 . . . 61 5.3.1Cohésion de JFig-1. . . 62 5.3.2 Couplage de JFig-1 . . . 63 5.4 JFig-2 . . . 66 5.4.1Cohésion de JFig-2 . . . 66 5.4.2 Couplage de JFig-2 . . . 68 5.5 TddJFig . . . 70 5.6 Conclusion du chapitre . . . 72 6 CONCLUSION 75 6.1Récapitulatif . . . 75 6.2 Contributions . . . 76 6.3 Travaux futurs . . . 77

A Les métriques de tailles (Tests pour la validation)79 A.1Nombre de lignes de code . . . 79

A.2 Métriques Nombre de classes, d'interfaces d'inner-classes et de paquets . . 80

B Les métriques de couplage (Tests pour la validation)81 B.0.1Aerent et Eerent Coupling . . . 81

B.0.2 Niveaux de dépendance . . . 81

C La métrique de cohésion (Tests pour la validation)83 C.0.3 LCOM . . . 83

C.0.4 Interprétation des résultats . . . 88

D Code source pour le chapitre Validation 93 D.1Othello-1. . . 93 D.2 Othello-2 . . . 1 07 D.3 JFig-1 . . . 1 1 7 D.4 JFig-2 . . . 1 29 D.5 JFigTdd . . . 1 39

LISTE DES FIGURES

2.1 Graphe représentant le calcul de la métrique de McCabe . . . 7

2.2 Figure représentant LCOM Chidamber et Kemerer . . . 11

2.3 Example LCOM de Hitz et Montazeri . . . 12

2.4 Exemple LCOM de Histz et Montazeri 1 component . . . 13

2.5 Élements de CodeCrawler représentants les métriques [Lanza et Ducasse, 2003] . . . 16

2.6 Visalisation de CodeCrawler [Lanza et Ducasse, 2003] . . . 17

2.7 Exemple du logiciel MetricView [Termeer et al., 2005] . . . 17

2.8 Figure représentant les diérentes métriques données par Metrics 1.3.8 . . 18

2.9 Capture d'écran d'une visualisation de Metrics 1.3.8 . . . 18

2.10 Visualisation graphique du couplagecouplage de VCC_0.1 . . . 20

2.11 Example de métriques proposées par VCC_0.1 . . . 20

2.12 Metriques de taille SonarQube . . . 21

2.13 Suivi des métriques de SonarQube . . . 21

2.14 Vue des métriques calculées par Metrics 1.3.8 . . . 22

2.15 Visualisation du couplage de Metrics 1.3.8 . . . 22

2.16 Vue globale proposée par SonarQube . . . 23

2.17 Rapport de problèmes détectés par SonarQube . . . 23

2.18 Visualisation des dépendances par SonarQube . . . 24

2.19 Visualisation des métriques par VCC1.0 . . . 24

2.20 Visualisation graphique de VCC1.0 . . . 24

3.1 Classe Rigide contenant toutes les fonctionnalités . . . 27

3.2 Organisation permettant l'ajout de nouvelles fonctionnalités . . . 28

4.1 Visualisation du couplage dans VCC_0.1 . . . 32

4.2 Représentation graphique des paquets . . . 33

4.3 Legende de la visualisation graphique de VCC_0.1 . . . 33

4.4 Organigramme de la révision des métriques . . . 34

4.5 Vue de la métrique de cohésion . . . 39

4.6 Cohésion de TextBar après la première correction . . . 40

4.7 Couplage cyclique . . . 41

4.8 Technique d'inversion de dépendance . . . 42

4.9 Couplage cyclique . . . 42

4.10 Couplage cyclique partiellement corrigé . . . 43

4.11 Vue globale des cycles détectés . . . 47

4.12 Exemple CycleID= 0 Couplage entre les classes A, B et C . . . 47

4.13 Example CycleID= 1 couplage entre les classes A et C . . . 47

4.14 Ranement de la métrique de cohésion . . . 48

4.15 LCOM après suppression de la méthode setTextLabels . . . 49

4.16 Figure de préférences de la cohésion . . . 50 v

vi LISTE DES FIGURES

5.1 Vue globale de Metrics 1.3.8 sur Othello-1 . . . 54

5.2Cohesion de Othello-1 . . . 54

5.3 LCOM de Metrics 1.3.8 sur Othello-1 . . . 55

5.4 cycle 1 sur Othello-1 . . . 55

5.5 Cycle sur Othello-1 . . . 56

5.6 Model MVC [Charon, I., 2015] . . . 57

5.7 Cohesion de Othello-2 . . . 58

5.8 Cycle sur Othello-2 . . . 59

5.9 Mauvaise implémentation du mvc . . . 60

5.10 Implémentation du mvc pour Othello-2 . . . 61

5.11 Cycle entre GameImpl et JSONGameManager . . . 61

5.12Inversion des dépendances sur GameImpl et JSONGameManager . . . 62

5.13 Cohesion de JFig-1 . . . 62

5.14 Cohesion de la classe ApplicationModel, méthode "init" . . . 63

5.15 Vue globale des cycles JFig-1 . . . 64

5.16 Vue détaillée des cycles JFig-1 . . . 64

5.17 Visualisation du couplage JFig-1 par VisualAideCC . . . 65

5.18 Couplage cyclique par Metrics 1.3.8 sur JFig1 . . . 66

5.19 Cohesion de JFig-2 . . . 67

5.20 Vue de la cohésion sur ApplicationModel . . . 67

5.21 Vue globale des cycles JFig-2 . . . 68

5.22 Vue détaillé des cycles . . . 68

5.23 Vue détaillée des cycles sur JFig-2 . . . 68

5.24 Visualisation du couplage JFig-2 . . . 69

5.25 Couplage cyclique par Metrics 1.3.8 sur JFig2 . . . 70

5.26 Cohesion de TddJFig . . . 70

5.27 LCOM de Metrics 1.3.8 sur le programme JFigTdd . . . 71

LISTE DES TABLEAUX

2.1 Tableau représentant les métriques de Chidamber et Kemerer . . . 12

2.2 Tableau représentant le LCOM de Henderson-Sellers . . . 13

4.1 Tableau montrant l'approche matricielle pour la cohésion . . . 34

4.2 Tableau Aerent Coupling de Metrics 1.3.8 et VCC_0.1 (Constantes) . . 36

4.3 Tableau Aerent Coupling de Metrics 1.3.8 et VisualAideCC (importa-tion) . . . 37

4.4 Tableau LCOM TextBar . . . 39

4.5 Nombre de méthode par Attribut . . . 40

4.6 Tableau représentant le couplage cyclique . . . 41

4.7 Étape 1 . . . 43 4.8 Étape 2 . . . 43 4.9 Étape 3 . . . 44 4.10 Étape 4 . . . 44 4.11 Étape 5 . . . 44 4.12 Étape 6 . . . 45 4.13 Étape 7 . . . 45

4.14 Tableau représentant la cohésion dans le cas de getters setters . . . 49

5.1 Tab1leau récapitulatif des problèmes détectés par VisualAideCC . . . . 53

5.2 Cohesion GameState VisualAideCC . . . 55

5.3 Cohesion GameState après suppression des Getters et setters . . . 56

5.4 Cohésion de la classe GridPanel (deux groupes identiés) . . . 58

5.5 Tableau de cohésion de la classe ShapeData . . . 71

A.1 Tableau de comparaison LOC de VCC_0.1 et Metrics 1.3.8 . . . 79

A.2 Tableau de comparaison LOC de VCC_0.1 et Metrics 1.3.8 au niveau des paquets . . . 80

A.3 Comparaison métrique de taille entre VCC_0.1 et Metrics 1.3.8 . . . 80

B.1 Comparaison des AC et EC entre VCC_0.1 et Metrics 1.3.8 . . . 81

C.1 LCOM de VCC_0.1 et Metrics 1.3.8 . . . 87

C.2 Nombre méthodes par attribut(ToolgCurvRectangle) . . . 88

C.3 Nombre méthodes par attribut(Metrics 1.3.8 ) . . . 89

C.4 Nombre méthodes par attribut(Metrics 1.3.8 ) . . . 90

LEXIQUE

Terme technique Dénition

CA Aerent Couplings

CBO Coupling Bctween Objccts

CE Eerent Couplings

DIP Dependency Inversion Principle

I Instability

ISP Interface segregation principle

LCOMLack of Cohesion of Methods

LOC Lines of code

LSP Liskov Substitution Principle

MCC McCabe's Cyclomatic Complexity

NOC Number of Classes

NOMNumber of Methods

OCP Open/closed principle

SRP Single responsibility principle

VCC Outil de Visualisation du Couplage et de la Cohésion

WMC Weighted Methods per Class

S : Single responsibility principle O : Open/closed principle

SOLID L : Liskov Substitution Principle

I : Interface segregation principle D : Dependency Inversion Principle

CHAPITRE 1

INTRODUCTION

1.1 Mise en contexte et problématique

Les logiciels sont omniprésents dans tous les domaines de la vie actuelle, et doivent donc être de bonne qualité. Les logiciels doivent donner des résultats corrects, être ables, d'une maintenance facile, extensibles par l'ajout de nouvelles fonctionnalités et réutilisables. Pour un développeur, la qualité logicielle est un attribut interne qui dépend du code ; il faut qu'un logiciel soit facilement extensible, cette extensibilité est très dicile à obtenir sans aucune aide. Le développement de logiciels a donc depuis longtemps été le sujet de beaucoup de recherches et d'études. Les chercheurs se sont mis à dénir des méthodologies, règles et standards, permettant de produire des logiciels de bonne qualité. Parmi ces méthodologies, le paradigme de programmation orientée objet POO. De ce paradigme, découlent plusieurs concepts permettant d'établir une ligne directrice pour la production de logiciels ables. Parmi ces concepts, on peut citer les patrons de conception (Design Patterns) [Gamma et al., 1993] ou encore le concept SOLID [Martin, 2003]

- S : Single responsability, le principe de responsabilité unique. - O : Open close principle, le principe d'ouverture/fermeture.

- L : Liskov substitution principle, le principe de substitution de Liskov. - I : Interface segregation principle, le principe de ségrégation des interfaces. - D : Dependency Inversion principle, le principe d'inversion des dépendances. Ces principes font partie de la stratégie du développement agile. Le développement agile est un travail par équipe, le travail doit donc être le plus homogène possible. Malgré toutes ces recherches, le développement logiciel demeure complexe, plus les systèmes à développer sont complexes plus la tâche est ardue et ainsi le coût de développement devient plus important. En utilisant les principes du Design Pattern et de SOLID, il est possible de réduire l'impact de l'eort et du coût de développement. Cela contribue donc à établir une ligne directrice permettant de développer des logiciels plus ables. Ces principes sont ecaces s'ils sont utilisés dès le début de la conception, mais qu'en est-il si le projet est déjà à un stade avancé ou bien ni ? Comment identier les zones du code qui ne

2 CHAPITRE 1. INTRODUCTION suivent pas ces principes ? C'est dans ce cas qu'interviennent les métriques logicielles. Les métriques logicielles permettent d'obtenir certaines vues quantiées à partir du code, chaque métrique met en évidence un aspect du logiciel. Le développement des métriques et surtout de leur visualisation est un domaine de recherche tout aussi important, car toute aide apportée à améliorer le codage sert aussi à réduire le temps de développement. Rombach a montré dans ses études [Rombach, 1987] [Rombach, 1990] que les métriques pouvaient être de bons prédicateurs de la qualité logicielle, à condition bien entendu de les utiliser.

1.2 Dénition du projet de recherche

Partant de ces observations, il est entendu que l'utilisation des métriques aide beaucoup à maintenir une bonne qualité logicielle. Procéder au calcul manuel de ces diérentes mé-triques sur un logiciel de taille moyenne est bien évidemment impossible à réaliser. An d'automatiser ce procédé, plusieurs outils ont été conçus, l'un d'eux Metrics 1.3.8 , est un plug-in pour Eclipse qui analyse le code source Java d'un projet et procède au calcul de certaines métriques. Les métriques calculées par Metrics 1.3.8 sont achées de façon tabulaire, ce qui rend leur lecture assez dicile à exploiter. De plus, les visualisations graphiques qu'il propose ne sont ecaces que pour des programmes de petite taille (d'une dizaine de classes avec environ 1000 à 2000 lignes de code). C'est dans ce contexte qu'un premier prototype que l'on va nommer VCC_0.1 a été développé à l'Université de Sher-brooke dans le cadre d'une maîtrise par Mejia-Lopez [Mejia-Lopez, 2011]. Cet outil qui est aussi un plug-in Eclipse pour code Java, permet d'apporter certaines vues des métriques, et propose une visualisation graphique de toutes les classes d'un projet.

Dans ce mémoire nous allons plus loin, nous avons repris et corrigé certaines erreurs de VCC_0.1 ; ce plug-in étant un prototype, nous devions nous assurer de la validité des va-leurs, et pour cela chaque métrique, chaque algorithme de calcul de ce plugin-in a dû être testé. Nous avons réalisé des extensions ; en implémentant d'autres algorithmes tels que la détection de cycles et le calcul de cohésion et surtout nous proposons de nouvelles visuali-sations : visualivisuali-sations ltrées, visualisation des cycles et la visualisation d'indicateurs au niveau de la métrique de cohésion.

Les étapes nécessaires pour la réalisation de ce projet de recherche sont présentées dans la partie des objectifs du projet de recherche.

1.3. OBJECTIFS DU PROJET DE RECHERCHE 3

1.3 Objectifs du projet de recherche

Les questions auxquelles nous nous proposons de répondre avec ces travaux sont : est-ce qu'il est possible de diérencier un couplage cyclique d'un couplage sans cycle ? Est-il possible de visualiser les métriques de couplage de telle manière qu'un développeur puisse voir le problème, corriger le problème et identier que le problème est résolu ? Le tout grâce à une visualisation ecace.

La plupart des métriques sont validées par les chercheurs [Gursaran, 2001][Li et Henry, 1993][Basili et al., 1996][Chidamber et Kemerer, 1994][Duraiswamy et Shanthi, 2011], ce qui constitue une bonne base pour l'évaluation du couplage.

Les métriques de couplage sont :

- Couplage entre objets (CBO, Coulping Between Objects) - Couplage par héritage (CTI, Coupling through inheritance)

- Couplage par transmission de message (MPC, Message Passing Coupling) - Couplage par abstraction (DCA, Data Abstraction Coulping)

- Eerent Coupling(CE) - Aerent Coupling (CA)

Ces métriques sont dénies au chapitre de l'État de l'art.

Pour arriver à maintenir un couplage tolérable entre les composants du programme, et ce durant toute la phase de codage, il faudrait donc avoir une visualisation ecace des métriques. Ainsi les développeurs auront les outils nécessaires pour détecter d'éventuels problèmes dans le code dès leur apparition. En identiant les zones critiques du code. Une des pistes de solution que nous proposons est de ltrer l'achage, n'acher que les parties des paquets et classes à corriger. Par exemple pour un couplage cyclique, une visualisation adéquate serait de montrer uniquement les paquets et classes concernés par ce couplage et non pas la totalité des paquets et classes. Une visualisation ciblée permettrait au développeur d'identier rapidement le problème et pourrait utiliser les principes de conception orientée objet pour l'éliminer. Pour la réalisation de cet objectif, plusieurs points spéciques sont à voir :

- Interpréter les valeurs des métriques : les métriques donnant des valeurs parfois non signicatives ou erronées, seront soumises à des tests an de les corriger.

4 CHAPITRE 1. INTRODUCTION - Identier le couplage cyclique : implémenter les algorithmes an de détecter les cycles présents dans le projet, l'identication de ce couplage étant nécessaire pour sa visualisation.

- Proposer une visualisation adéquate des paquets et classes : il s'agit donc de proposer une visualisation signicative, ecace, facilement exploitable par le développeur en tenant compte des zones importantes à acher.

1.4 Plan du mémoire de recherche

Ce mémoire de recherche est organisé de la façon suivante, nous commencerons par présen-ter dans un premier temps les diérentes métriques logicielles, en passant des métriques traditionnelles aux métriques spéciques au développement orienté objet, ainsi que les diérentes visualisations des métriques proposées. Par la suite, après une brève dénition du couplage et de la cohésion, nous dénirons les métriques utilisées dans ce projet et les améliorations apportées à VCC_0.1 . Nous procéderons ensuite au chapitre suivant à la validation de notre version de l'outil que l'ont va nommer VisualAideCC, en l'appliquant sur des programmes réalisés au laboratoire de génie logiciel eXit de l'Université de Sher-brooke. Nous terminerons ce mémoire par une conclusion, un rappel sur les contributions faites ainsi que les perspectives de travaux futurs.

CHAPITRE 2

ETAT DE L'ART

Pour entreprendre notre recherche, une synthèse des diérentes approches proposées dans la littérature est nécessaire.

Nous allons donc commencer par présenter les premières métriques proposées, dites, tra-ditionnelles comme la métrique Nombre de lignes de code, nous aborderons ensuite les métriques proposées par diérents chercheurs, notamment Chidamber et Kemerer qui ont été les premiers àproposer des métriques spéciques au développement Orienté Objet [Chidamber et Kemerer, 1991]. Li et Henry ont proposé une étude [Li et Henry, 1993] des métriques de Chidamber et Kemerer, en proposant de redénir une de ces métriques. Nous parlerons ensuite des métriques de Martin qui dans son livre [Martin, 2003] a proposé de nouvelles métriques sur la stabilité et le couplage des paquets et enn, nous aborde-rons les diérentes visualisations graphiques proposées notamment celle de Metrics 1.3.8 , SonarQube et VCC_0.1 .

2.1 Les métriques traditionnelles

Les métriques traditionnelles sont des métriques proposées avant l'évolution du paradigme de conception orientée objet, et ne sont donc pas spéciques àce dernier, même si beaucoup de métriques orientées objet sont inspirées des métriques traditionnelles. Les métriques traditionnelles sont répertoriées en deux groupes : les métriques mesurant le volume et la

taille d'un logiciel, comme la métrique Lines Of Code (LOC) 1_{, et les métriques mesurant}

la complexité d'un logiciel comme celle proposée par McCabe [McCabe, 1976]. Il existe aussi les métriques de Halstead [Halstead, 1977] qui a déni une façon de calculer l'eort d'implémentation en utilisant les opérateurs et les opérandes d'un programme.

2.1.1 Nombre de lignes de Code

C'est certainement la métrique la plus ancienne et la plus couramment utilisée, en raison de sa simplicité et de sa facilité d'utilisation. Cette métrique calcule le nombre de lignes

1_{Nous allons garder les noms des métriques en anglais, car les sigles sont tirés de noms anglais.}

6 CHAPITRE 2. ETAT DE L'ART de code (LOC) d'un programme, elle peut être représentative de l'eort de compréhension du code.

2.1.2 Métriques de Halstead

En 1977, Maurice Halstead [Halstead, 1977] a proposé quatre métriques issues de l'analyse lexicale du code source, selon lui, il existe une forte corrélation entre le nombre d'opérateurs et opérandes d'un programme et le nombre d'erreurs contenues dans les algorithmes. Les quatre métriques proposées sont :

n₁ = nombre d'opérateurs distincts utilisés.

n₂ = nombre d'opérandes distincts utilisés.

N₁ = nombre total d'utilisations d'opérateurs.

N₂ = nombre total d'utilisations d'opérandes.

À partir de cette dénition des métriques, il a développé un ensemble de formules pour évaluer la taille du vocabulaire, le volume, l'eort et la durée de codage. Les équations déduites sont respectivement :

La taille du vocabulaire (n) : n = n1+ n2

La longueur du programme (N) : N = N1+ N2

Le volume du programme (V ) : V = N ∗ log2(n)

Le niveau de diculté (D) : D = n1

2 ∗Nn22

L'eort à l'implémentation (E) : E = V ∗ D

Ces équations ont fait l'objet de critiques de la part de Fenton et Peeger. Dans leur livre [Fenton et Peeger, 1996] les auteurs considèrent que Halstead ne donne pas de réelles indications sur les relations des composants de sa théorie, et que la relation entre le système empirique et le modèle mathématique n'est pas claire, de plus, les phases de spécication et de conception ne sont pas prises en considération dans son étude, bien qu'elles requièrent souvent un eort considérable

2.1.3 Complexité Cyclomatique de McCabe (MCC)

Proposée par Thomas McCabe en 1976 [McCabe, 1976], basée sur la théorie des graphes, cette métrique mesure le nombre de chemins possibles dans l'exécution d'une fonction.

2.1. LES MÉTRIQUES TRADITIONNELLES 7 Indicatrice de la complexitéd'une fonction, elle nous renseigne sur l'eort nécessaire aux tests. En eet, une fonction avec une grande valeur de ComplexitéCyclomatique nécessi-tera plus de tests, puisque chaque chemin est une nouvelle fonction à tester.

V = E − N + 2P

Où : V = complexitécyclomatique

E= le nombre d'arêtes du graphe

N= le nombre de noeuds présent dans le graphe

P= le nombre de composants connexes du graphe

Pour mieux comprendre ces valeurs, nous proposons de construire le graphe sur une condi-tion if. Le graphe est représenté sur la gure 2.1.

if A = 5 then if C > D then A= C else A= D end if end if P rintA

Dans ce cas, le nombre d'arêtes E = 8, le nombre de noeuds N = 7 et le nombre de composants connexes du graphe P = 1.

Cela nous donne : V = 8 − 7 + 2 = 3.

Pour que tous les chemins soient testés, il est nécessaire d'avoir un nombre de tests qui soit au moins égal au nombre de complexités Cyclomatique de McCabe. Donc plus le nombre de complexités de McCabe est grand plus le nombre de tests sera grand. Cette métrique donne une idée sur la diculté de lecture d'une fonction. Plus elle est complexe, plus elle est dicile à comprendre.

8 CHAPITRE 2. ETAT DE L'ART

Figure 2.1 Graphe représentant le calcul de la métrique de McCabe

2.2 Les métriques orientées objet

Avec l'évolution des paradigmes de conception logicielle, le concept orienté objet est devenu le paradigme dominant de ces trente dernières années. Ce concept dénit l'interaction d'objets, considérés comme toute entité ayant un comportement spécique. De nouvelles métriques devaient donc être dénies, des métriques prenant en considération à la fois la combinaison de la fonction et des données en terme d'objets. Dans ce registre, plusieurs travaux ont été eectués, on peut citer les travaux de Chidamber et Kemerer [Chidamber et Kemerer, 1991], les travaux de Hitz et Montazeri [Hitz et Montazeri, 1996], les travaux de Henderson-Sellers [Henderson-Sellers, 1996], les travaux de Li et Henry [Li et Henry, 1993] et les travaux de Martin [Martin, 2003].

2.2.1 Les métriques proposées par Chidamber et Kemerer

Les métriques proposées sont considérées comme les premiers dans le domaine de mesure de qualité spécique au développement orienté objet. Ils ont proposé six métriques qui sont présentées comme suit.

Nombre de méthodes par classe, Weighted Method per Class(WMC)

Dérivée de la métrique de complexité de McCabe MCC, cette métrique calcule la somme des MCC par classe, elle nous renseigne sur la complexité et l'eort nécessaire à la créa-tion et la maintenance d'une classe. Elle nous renseigne aussi sur la réutilisabilité d'une classe, en eet une classe contenant beaucoup de méthodes pourrait être spécique à une application. Il serait intéressant de la diviser en sous-classes.

2.2. LES MÉTRIQUES ORIENTÉES OBJET 9 Nombre d'ancêtres d'une classe, Depht of inheritence tree(DIT)

Dénit la position d'uneclasseau sein dela hiérarchied'héritage, calculéeà partir du nombred'ancêtres d'uneclasse. Uneclasseavec un grand DIT requiert souvent plus d'ef-fort de compréhension, du fait du nombre important de méthodes héritées.

Nombre de classes dérivées, Number Of Children(NOC)

Cettemétriqueidentielenombredeclasses directement dérivées d'une classe, elle cal-culela largeur d'unehiérarchiealors queleDIT calcule la profondeur. Elle nous renseigne sur la réutilisation d'uneclasse. Un nombreimportant declasses dérivées est lesigned'une forteréutilisation, l'héritageétant uneformederéutilisation.

Couplage entre objets, Coupling Between Object(CBO)

Deux classes sont dites couplées si l'une utilise au moins une méthode ou un attribut de l'autre. Le couplage est intéressant à détecter, car un code contenant des classes fortement couplées serait dicile à réutiliser, un fort couplage se faisant au détriment de la modula-rité. De plus, tout changement dans le code nécessitera des eorts considérables et donc perdrait de son extensibilité. Tout changement sur une classe aecterait l'ensemble des autres classes qui y sont couplées.

Communication des classes, Response for Class (RC)

Cettemétriquereprésenteuneautreformedecouplage, ellecalculel'ensembledeméthodes qui peuvent être appelées à partir d'une classe, et reète le niveau de complexité d'une classe et donc l'eort à fournir durant les tests.

Cohésion des classes, Lackof Cohesion in Method (LCOM)

Cettemétriquemesurela cohésion d'uneclasse. Uneclasseest considéréedebonnecohé-sion, si ses méthodes agissent sur le même ensemble de données, cela indique une bonne subdivision de la classe. Le manque de cohésion augmente la complexité et les possibilités d'erreur lors du développement. Chidamber et Kemerer ont déni cette métrique comme suit :

UneclasseC contenant l'ensemble de méthodes {M1, M₂....M_n}, pour chaqueméthode

nous obtenons l'ensemble d'attributs auxquels elle accède {A1, A₂....A_n}, nous obtenons

ensuite les deux ensembles P et Q, tel que :

P = {A_iA_j} = ∅ Q= {A_iA_j} = ∅

10 CHAPITRE 2. ETAT DE L'ART

LCOM = {|P | − |Q|} , si |P | > |Q|

LCOM = 0 sinon.

Si on applique cette métrique sur une classe C1 représentée par la gure 2.2 qui contient

3 méthodes M = {M1, M₂, M₃} et 4 attributs A = {a, b, c, d, e}.

Figure 2.2 Figure représentant LCOM Chidamber et Kemerer

M₁ accède à A₁ = {a, b, c}

M₂ accède à A2 = {c, d}

M₃ accède à A3 = {e}

Nous prenons les méthodes par paires,

M₁ et M2 ⇒ {A₁A₂} = {c}

M₁ et M₃ ⇒ {A₁A₃} = ∅

M₂ et M3 ⇒ {A₂A₃} = ∅

Cela nous donne :

Deux ensembles vides, donc |P | = 2 et un ensemble non vide |Q| = 1

|P | − |Q| = 1

LCOM = 1 .

Récapitulatif des métriques de Chidamber et Kemerer

Ces métriques ont fait l'objet de plusieurs études, notamment par les auteurs eux-mêmes qui les ont validées par une étude empirique [Chidamber et Kemerer, 1994]. Le tableau 2.1

2.2. LES MÉTRIQUES ORIENTÉES OBJET 11 représente un récapitulatif des diérentes métriques proposées par Chidamber et kemerer. Les travaux de Basili, Briand et Melo [Basili et al., 1996], ont présenté les résultats d'une

Acronyme Nom Description

CBO Coulping Between Object Le nombre de classesdépendantes d'une

classe.

DIT Depht of inheritence tree La profondeur d'une_{classe dans l'héritage}

LCOM Lack of Cohesion in Method

Cohésion des classes, calculée à partir des connexions entre méthodes et attributs

NOC Number Of Children Le nombre de classesdérivées directement

d'une classe

RC Response for Class L'ensemble de toutesles méthodes appelées

à partir d'une classe

WMC Weighted Method per Class La somme de MCCdes méthodes de la

classe

Tableau 2.1 Tableau représentant les métriques de Chidamber et Kemerer

étude empirique réalisée sur l'ensemble des métriques de Chidamber et Kemerer. Cette étude statistique destinée à montrer la corrélation entre les erreurs de conception de classe et les métriques proposées, leur a permis de valider cinq des métriques de Chidamber et Kemerer, seule la métrique de cohésion des classes (Lack Of Cohesion in Method ) qui dans chacun des cas donnait des résultats insigniants, n'a pas été validée.

2.2.2 Métrique de cohésion de Hitz et Montazeri

Cette métrique proposée par Hitz et Montazeri [Hitz et Montazeri, 1996], calcule le nombre de composants liés. Une liaison est dénie soit entre méthodes et méthodes, soit entre méthodes et attributs. Ces liaisons forment des composants liés connected components. Si la classe compte un seul groupe de composants liés, elle est donc de bonne cohésion, sinon si ce nombre est supérieur à 1, la classe devrait être subdivisée en deux classes ou plus. L'exemple de la gure 2.3 montre une classe contenant 3 méthodes et 3 attributs.

La méthode-1 utilise les attributs 1 et 2. La méthode-2 utilise l'attribut 2.

12 CHAPITRE 2. ETAT DE L'ART

Figure 2.3 Example LCOM de Hitz et Montazeri La méthode-3 utilise l'attribut 3.

Dans ce cas, on le voit clairement, il existe deux groupes, le premier entre la méthode 1 et 2 et le deuxième concerne uniquement la méthode 3. Donc LCOM = 2.

Maintenant si là méthode-1 fait appel à la méthode-3 (Figure 2.4), nous obtiendrons une seule interconnexion, qui regroupe les trois méthodes, et donc LCOM sera égale à 1 .

Figure 2.4 Exemple LCOM de Histz et Montazeri 1 component

2.2.3 Métriques de cohésion de Henderson-Sellers

Henderson-Sellers [Henderson-Sellers, 1996] a proposé une nouvelle dénition du LCOM comme suit :

Une classe est parfaitement cohésive si toutes ses méthodes accèdent à tous ses attributs.

Soit C une classe contenant l'ensemble de méthodes {Mi} (i = 1, ..., m) et l'ensemble

d'at-tributs {Aj} (j = 1, ..., a), en considérant m(Aj) comme le nombre de méthodes accédant

à chaque attribut. LCOM =  1 a _a j=1m(Aj)  − m m− 1 (2.1)

2.2. LES MÉTRIQUES ORIENTÉES OBJET 13 Le LCOM prend ses valeurs de [0, 2], 0 étant une classe parfaitement cohésive, supérieure à 1 indique une classe de mauvaise cohésion.

Soit l'exemple précédent de la gure 2.3 représenté par le tableau 2.2, un "X" représente un accès de la méthode à l'attribut.

Méthode-1 Méthode-2 Méthode-3

Attribut-1 X

Attribut-2 X X

Attribut-3 X

Tableau 2.2 Tableau représentant le LCOM de Henderson-Sellers  1 a _a j=1m(Aj)  = 1 3(2 + 1 + 1) = 43 LCOM = 1.33−3₁₋₃ = 0.83

2.2.4 Les métriques proposées par Li et Henry

Li etHenry ontvalidé les métriques de Chidamber etKemerer, etontproposé de redénir la métrique de couplage selon trois critères, le couplage par héritage, le couplage par transmission de messages et le couplage par abstraction [Li et Henry, 1993]

Le couplage par héritage, Coupling Through Inheritance (CTI)

Cette métrique dénit le couplage selon les métriques de Chidamber et Kemerer Depht of inheritence tree et Number of Children.

Le couplage par transmission de message, Message Passing Coupling (MPC) Le nombre de messages envoyés peut indiquer le degré de dépendance d'une méthode à l'intérieur d'une classe, vers les méthodes des autres classes.

Le couplage par abstraction, Data Abstraction Coupling (DAC)

Calcule le nombre de types abstraits déni dans une classe, ces types abstraits étant dénis dans d'autres classes entraînent un couplage, ce type de couplage peut-être indicateur de violation de l'encapsulation. Cette proposition a permis de mieux dénir le couplage, en eet, prendre en compte les diérents critères de couplage permet d'aner le traitement de calcul de qualité.

14 CHAPITRE 2. ETAT DE L'ART

2.2.5 Les métriques de Martin

Martin [Martin, 2003] s'est lui, intéressé àla stabilité des paquets, un paquet stable étant considéré comme plus extensible. Il a donc déni les métriques suivantes

Eerent Coupling (EC)

À partir d'un paquet, cette métrique mesure le nombre total des paquets utilisés par les classes internes de ce paquet (les classes du paquet qui utilisent les classes situées à l'extérieur du paquet )

Aerent Coupling (AC)

À partir d'un paquet, cette métrique mesure le nombre total de paquets qui utilisent les classes situées dans ce paquet (les classes àl'extérieur du paquet qui utilisent les classes du paquet).

Instability (I)

Mesure le ratio des Eerent Coupling (EC) par le total de (EC + AC)

I = EC

(EC + AC) (2.2)

Une classe avec une valeur approchant du zéro est considérée comme une classe plus stable, elle ne dépend pas de beaucoup de classes externes au paquet (valeur du (EC ) petite par rapport àla somme (EC+AC )) Une classe avec une valeur approchant de un, est considérée comme une classe instable, implique que le AC se rapproche du zéro, et donc qu'il ya une forte dépendance des classes internes du paquet avec les classes externes.

Abstractness (A)

Mesure le ratio du nombre de classes abstraites et d'interfaces sur le nombre total de

classes dans un paquet. A = ClassesAbstraites+Interfaces

NombreT otalClasses

P. M. Shanthi, K. Duraiswamy [Duraiswamy et Shanthi, 2011] ont validé par une étude empirique la métrique de McCabe [McCabe, 1976] ainsi que les métriques de Martin à savoir :

- Eerent Coupling(Ce) - Aerent Coupling (Ca) - Instability (I)

CHAPITRE 3

Le Couplage et la cohésion dans une

architec-ture de logiciel

Dans ce chapitre, nous allons dénir plus en détail le couplage et la cohésion et décrire leur relation avec l'architecture du logiciel, ainsi que leur relation avec le concept SOLID.

3.1 Couplage

Le couplage a été déni comme le degré d'interdépendance entre les modules d'un logiciel [Yourdon et Constantine, 1979]. Dans leur livre Design Patterns, [Freeman et al., 2004]ont déni que le couplage faible nous permet de construire des systèmes exibles en minimisant les interdépendances entre objets.

Dans son livre, Martin [Martin, 2003]présente des principes avancés de conception ob-jet. Ces principes ont pour objectif d'éviter les problèmes produits par l'évolution des applications. Ces problèmes sont connus comme :

- La rigidité ou non-extensibilité

L'application doit être codée de façon à faciliter une éventuelle évolution. Par exemple, une application codée pour dessiner des rectangles devrait faciliter l'ajout de fonc-tionnalités, comme le dessin d'autres formes.

Figure 3.1 Classe Rigide contenant toutes les fonctionnalités

Dans la gure 3.1, la classeDessindénit les propriétés d'un rectangle et ses fonctions.

L'ajout des nouvelles formes se fait donc en modiant la logique de cette classe, ce

qui induit des modications dans les classes dépendantes ClasseA et ClasseB. Par

contre, si on dénit la classe Dessincomme une classe abstraite, l'ajout de nouvelles

formes se fera par héritage. Ces ajouts n'aecteront pas les classes ClasseAetClasseB,

puisque la classe abstraite Dessin ne sera pas modiée.(voir gure 3.2).

26CHAPITRE 3. LE COUPLAGE ET LA COHÉSION DANS UNE ARCHITECTUREDE LOGICIEL

Figure 3.2 Organisation permettant l'ajout de nouvelles fonctionnalités

- La fragilité : La modication d'une fonctionnalité génère des erreurs sur d'autres fonctionnalités, car les fonctionnalités sont fortement liées.

- L'immobilité (non-réutilisabilité) : si par exemple la fonctionnalité de dessiner des rectangles est utile pour d'autres applications, sa réutilisation devrait être possible, Par dénition, un logiciel extensible est un logiciel auquel on ajoute une nouvelle fonc-tionnalité qui n'a pas été prévue au début de la conception. La cause principale de la non-extensibilité d'un logiciel est le couplage entre classes et paquets. En eet, un cou-plage fort, synonyme d'une forte interaction entre les classes et entre les paquets du logiciel, rend les modications diciles et donc coûteuses, tant en terme de temps, d'argent et de main d'oeuvre.

Ces modications de type ajout de nouvelles fonctionnalités et maintenance conduisent en général à une réaction en chaîne sur toute l'architecture du logiciel. Une telle architec-ture est dite Rigide.

Certain des principes SOLID sont liés au couplage, comme le principe d'ouverture ferme-ture, le principe de substitution de Liskov et le principe d'inversion de dépendances.

- Principe d'ouverture fermeture [Meyer, 1997] : signie évoluer sans modication, le module doit être à la fois ouvert aux évolutions et fermé aux modications. Ouvert aux évolutions comprend toute extension du module à des comportements non pré-vus. Fermé aux modications, signie que l'évolution se fait sans modication du code existant. Ce principe se fait généralement par une abstraction, qui contient le code xe qui ne change pas alors que les extensions peuvent être des classes qui héritent cette abstraction.

3.2. COHÉSION 27 - Principe de substitution de Liskov : Liskov [Liskov, 1988] a déni ce principe comme

suit : Si pour chaque objet o1 du type S, il y a un objet o2 du type T, tel que pour

tout programme P déni en termes de T, si le comportement de P ne change pas si

o₁ est substitué par o2, alors S est un sous type de T.

- Principe d'inversion de dépendance : dans son article [Martin, 1996] décrit le principe d'inversion de dépendance en deux critères.

- Les modules de haut niveau dans la hiérarchie ne doivent pas dépendre des modules de bas niveau, tous deux doivent dépendre d'abstractions.

- Les abstractions ne doivent pas dépendre de détails, les détails doivent dé-pendre d'abstractions. Au contraire, le non-respect de ces principes conduit à un couplage fort, rendant ainsi l'architecture rigide.

Ces trois principes sont donc liés et aident à maintenir un couplage faible avec l'utilisation des abstractions.

3.2 Cohésion

La cohésion est le degré de liaison entre les diérents éléments d'un module. Une bonne cohésion veut dire qu'une classe contient uniquement des attributs et des méthodes forte-ment liés. La cohésion est dénie selon plusieurs types [Yourdon et Constantine, 1979] :

- Cohésion accidentelle : les éléments sont regroupés arbitrairement dans les classes. - Cohésion logique : les éléments ayant des fonctions similaires, sont regroupées dans

une même classe, les éléments n'ont pas de lien entre eux.

- Cohésion temporelle : les éléments sont regroupés par fonctionnalités qui coopèrent dans le temps.

- Cohésion procédurale : lorsque les éléments sont regroupés parce qu' ils suivent un ordre d'exécution précis.

- Cohésion communicationnelle : lorsque les éléments regroupés travaillent sur le même ensemble de données

- Cohésion séquentielle : des méthodes peuvent être regroupées dans le cas où chaque méthode utilise la sortie d'une autre méthode, par exemple lire un chier et faire son traitement.

28CHAPITRE 3. LE COUPLAGE ET LA COHÉSION DANS UNE ARCHITECTUREDE LOGICIEL - Cohésion fonctionnelle : ce type de cohésion regroupe des éléments selon leur

fonc-tionnalité.

Dans son livre [Martin, 2003], Martin relie la dénition de la cohésion à certains prin-cipes SOLID, dont le principe de responsabilité unique et le principe de ségrégation des interfaces.

- Principe de responsabilité unique : Martin [Martin, 1996] relie la cohésion aux élé-ments qui peuvent amener une classe à changer et dit qu'une classe ne devrait avoir qu'une seule raison de changer, ce qui représente une seule responsabilité. Si une classe a plus d'une responsabilité, les responsabilités deviennent fortement liées, leurs modications peuvent entraîner des modications sur les autres. Ceci conduit à des conceptions fragiles qui deviennent très vite diciles à maintenir. Distribuer les res-ponsabilités en plusieurs classes permet de rendre le code plus clair et plus facile à tester, car les responsabilités seront isolées les unes des autres.

- Principe de ségrégation des interfaces : Ce principe identie l'inconvénient d'avoir des interfaces trop riches qui contiennent plus d'informations qu'il ne le faut. Un client héritant de cette interface aurait donc accès à des informations dont il n'a pas besoin. Ces interfaces peuvent être subdivisées en groupe de méthodes, chaque groupe servant des clients diérents. Ces interfaces conduisent à avoir une mauvaise cohésion.

En respectant les principes de responsabilité unique et ségrégation des interfaces, nous pouvons garder une architecture de bonne cohésion. Au contraire, une classe avec beau-coup de responsabilités ou d'interfaces trop riches conduit à une architecture de mauvaise cohésion.

Après avoir revu les métriques de logiciels dans le chapitre deux, nous avons déni plus en détail ce qu'est le couplage et la cohésion ainsi que leurs liens pour développer une archi-tecture de logiciel exible. Dans le chapitre suivant, nous allons présenter l'outil VCC_0.1 et les ajouts eectués pour produire l'outil présenté dans ce mémoire, VisualAideCC.

CHAPITRE 4

Transistion de VCC_0.1 à VisualAideCC

Comme mentionné dans les chapitres précédents, ce projet de maîtrise est une suite du projet de Mejia-Lopez [Mejia-Lopez, 2011], réalisé en 2011, le travail consistait à faire une étude des métriques et de leurs visualisations. Le développement du prototype VCC_0.1 a démontré l'utilité d'avoir des représentations diérentes de celles proposées par Metrics 1.3.8 [Metrics Open source project, 2009]. Les représentations de VCC_0.1 sont plus ex-plicites et proposent certaines vues graphiques, tandis que Metrics 1.3.8 est simplement tabulaire. Dans ce projet, nous allons plus loin, avec l'implémentation de l'outil VisualAi-deCC. Nous avons repris les visualisations que proposaient VCC_0.1 et qui ont montré un avantage certain par rapport à Metrics 1.3.8 . Nous avons donc repris certains de ces aspects qui étaient nécessaires, comme la visualisation en rectangle des classes et paquets ainsi que la visualisation tabulaire des métriques de cohésion et de couplage, pour ainsi donner des résultats plus utiles. Nous avons ajouté des tests et découvert des erreurs de va-leurs dans certains cas isolés et nous avons ajouté de nouvelles représentations graphiques en particulier pour détecter les cycles les classes. Le cheminement du développement réalisé est décrit par les étapes suivantes :

1. État du programme VCC_0.1 .

VCC_0.1 étant un prototype existant, une description de ce dernier est présentée dans ce chapitre, an de mieux identier l'apport eectué dans ce mémoire.

2. Validation et correction des métriques.

Avant de reprendre les métriques proposées par VCC_0.1 , nous devions nous assurer de l'exactitude de leurs calculs. Dans cette section, nous proposons de revoir plus en détail la procédure réalisée pour la validation de ces métriques.

3. Ajouts réalisés au niveau des métriques de couplage.

Après avoir déni les métriques à utiliser et réalisé des corrections dans certains cas, nous parlerons de VisualAideCC en détaillant les ajouts réalisés au niveau des métriques de couplage de VisualAideCC.

4. Ajouts eectués au niveau des métriques de cohésion. 29

32 CHAPITRE 4. TRANSISTION DE VCC_0.1 À VISUALAIDECC Methode-1 Methode-2 Methode-3 Methode-4

Attribut-1 X X

Attribut-2 X X

Attribut-3 X X

Tableau 4.1 Tableau montrant l'approche matricielle pour la cohésion

4.2 Validation et correction des métriques

Après avoir présenté l'outil VCC_0.1 telque récupéré au début de ce mémoire, nous avons poursuivi par la vérication de tous les algorithmes permettant de calculer les diérentes

métriques. Pour réaliser cette étape, nous avons utilisé le framework de test JUnitet comme

code à tester un projet nommé JFigréalisé au sein du laboratoire de génie logiciel eXit. Ce

logiciel ayant été développé par des étudiants sans trop d'expérience dans le développement logiciel. La qualité du code est limitée.

Figure 4.4 Organigramme de la révision des métriques

Cette étape, représentée par l'organigramme 4.4 s'est déroulée comme suit : Après avoir

4.2. VALIDATION ET CORRECTION DES MÉTRIQUES 33 pour la création des tests unitaires ont été récupérées. La validation ou la correction de ces métriques se fait donc grâce à ces tests unitaires.

Note : Dans ce mémoire, nous n'allons représenter que certains cas, le reste peut être consulté en annexe A (les métriques de taille), annexe B (les métriques de couplage) et annexe C (les métriques de cohésion).

4.2.1 Métriques de couplage

Le couplage provient de toute communication entre les diérents modules d'un projet. Il est donc nécessaire au bon fonctionnement d'un programme, d'un programme. Cependant, mal utilisé, le couplage peut rendre très ardus l'ajout de nouvelles fonctionnalités, les modications ou la maintenance. Dans cette partie, nous avons procédé à l'analyse des métriques de couplage existants dans VCC_0.1 soit, le Aerent Coupling (AC) et le Eerent Coupling (EC).

À partir d'une classe, le AC représente le nombre de classes en dehors du paquet qui dépendent de cette classe alors que le EC représente le nombre de classes en dehors du paquet dont cette classe dépend. Le test de cette métrique a permis de repérer un cas particulier où la dépendance envers les classes contenant uniquement des constantes n'était pas prise en compte, ce qui bien entendu ne reète pas l'état réel des dépendances. Pour représenter ce cas, un exemple est présenté dans ce chapitre au tableau 4.2, le reste des cas peut être consulté dans l'annexe B. Le tableau 4.2 montre que pour le paquet

jfig.utilitiesdu programmeJFig, le plug-in Metrics 1.3.8 trouve un AC de 18, alors que

VCC_0.1 trouve AC = 0. Le test a bien évidemment échoué. En analysant les classes se trouvant dans ce paquet, nous trouvons 2 classes.

La classe ArrowTypes et la classe FigureTypes

le code source de ces classes :

Listing 4.1  Code source de la classe ArrowTypes

1 package ca.sixs.jfig.utilities; 2

3 public final class ArrowTypes { 4 public static final int ARROW = 20;

5 public static final String ARROW_STR = "arrow"; 6 public static final int ARROWDOUBLE = 21;

7 public static final String ARROWDOUBLE_STR = "arrowDouble"; 8 public static final int ARROWFILL = 22;

34 CHAPITRE 4. TRANSISTION DE VCC_0.1 À VISUALAIDECC

9 public static final String ARROWFILL_STR = "arrowFill"; 10 public static final int ARROWFILLDOUBLE= 23;

11 public static final String ARROWFILLDOUBLE_STR = "arrowFillDouble"; 12 }

Listing 4.2  Code source de laclasse FigureTypes

1 package ca.sixs.jfig.utilities; 2

3 public final class FigureTypes {

4 public static final int RECTANGLE = 11;

5 public static final String RECTANGLE_STR = "rectangle"; 6 public static final int ROUNDRECTANGLE = 12;

7 public static final String ROUNDRECTANGLE_STR = "roundRectangle"; 8 public static final int OVAL = 13;

9 public static final String OVAL_STR = "oval"; 10 public static final int CIRCLE= 14;

11 public static final String CIRCLE_STR = "circle"; 12 public static final int LINE= 15;

13 public static final String LINE_STR = "line"; 14 public static final int TEXTFIG = 16;

15 public static final String TEXTFIG_STR = "txt"; 16 }

Nom du paquet VisualAideCC Metrics 1.3.8

jg.utilities 0 18

Tableau 4.2 Tableau Aerent Coupling de Metrics 1.3.8 et VCC_0.1 (Constantes)

D'après le code Listing 4.1 et Listing 4.2, on remarque que ces deux classes ne contiennent que des constantes. VCC_0.1 ne prenant pas en compte ce genre de dépendance, les deux classes étaient considérées comme non liées. Ceci ne reète donc pas le couplage réel des classes. Nous avons procédé à la modication de cette métrique pour ensuite la tester à nouveau et la valider.

Le tableau 4.3 représente un autre exemple des diérences remarquées entre VCC_0.1 et Metrics 1.3.8 .

En rappelant que le Aerent Coupling compte le nombre de classes situées à l'intérieur du

paquet jfig.app qui dépendent de classes situées à l'extérieur de ce paquet.

Le paquet jfig.app contient deux classes, la classe JFig et laclasse SaveStartPostition

4.2. VALIDATION ET CORRECTION DES MÉTRIQUES 35 Nom du paquet VCC_0.1 Metrics 1.3.8 VCC_0.1 Metrics 1.3.8

AC AC EC EC

jg.app 1 3 1 2

Tableau 4.3 Tableau Aerent Coupling de Metrics 1.3.8 et VisualAideCC (importation)

que pour VCC_0.1 , le paquet jfig.app dépend d'une classe externe, alors que pour

Me-trics 1.3.8 , il dépend de trois classes externes. En vériant le code source de la classe

JFig, nous identions bien une dépendance vers une classe externe, cependant la classe

SaveStartPostition ne dépend pas d'autres classes. le Aerent Coupling devrait donc être

égal à 1.

Voici le code source de ces deux classes an de mieux comprendre cette diérence. Listing 4.3  Classe SaveStartPosition

1 package ca.sixs.jfig.app; 2 import java.util.prefs.*;

3 import static org.junit.Assert.assertEquals; 4 import org.junit.Test;

5 import ca.sixs,jfig,models; 6 public class SaveStartPosition {

7 Preferences prefs = Preferences.userNodeForPackage(SaveStartPosition.class); 8

9 public int[] setInitalState() throws Exception { 10 int[] state = new int[4];

11 state[0] = prefs.getInt("x", 200); 12 state[1] = prefs.getInt("y", 200); 13 state[2] = prefs.getInt("w", 500); 14 state[3] = prefs.getInt("h", 500); 15 16 return state; 17 } 18

19 public void saveFramePositions(int getX, int getY, int getWidth, 20 int getHeight) { 21 prefs.putInt("x", getX); 22 prefs.putInt("y", getY); 23 prefs.putInt("w", getWidth); 24 prefs.putInt("h", getHeight); 25 } 26 27 @Test

36 CHAPITRE 4. TRANSISTION DE VCC_0.1 À VISUALAIDECC

28 public void SavePreferencesTest() { 29

30 saveFramePositions(200, 100, 50, 12); 31 try {

32 int[] state = setInitalState();

33 assertEquals("SavePreferencesTest", state[0], 200); 34 assertEquals("SavePreferencesTest", state[1], 100); 35 assertEquals("SavePreferencesTest", state[2], 50); 36 assertEquals("SavePreferencesTest", state[3], 12); 37 prefs.putInt("x", 300); 38 prefs.putInt("y", 300); 39 prefs.putInt("w", 500); 40 prefs.putInt("h", 500); 41 } catch (Exception e) { 42 43 e.printStackTrace(); 44 } 45 } 46 }

D'après le code source, nous identions quatreimportsdéclarés dans la classeSaveStartPostition

Listing 4.4  imports déclarés dans la classe SaveStartPosition

1 import java.util.prefs.*;

2 import static org.junit.Assert.assertEquals; 3 import org.junit.Test;

4 import ca.sixs,jfig,models;

En réalité, le paquet ca.sixs.jfig.modelsest non utilisé par cette classe. Ces diérences de

valeur sont dues à des diérences d'implémentations entre VCC_0.1 et Metrics 1.3.8 . Ce dernier considère le couplage grâce aux paquets importés, alors que VCC_0.1 recherche les références en parcourant le corps de chaque classe [Mejia-Lopez, 2011].

4.2.2 Métriques de cohésion

La métrique de LCOM 1 _{sert à identier le manque de cohésion dans les diérentes classes}

d'un projet. Le calcul de cette métrique se fait en se basant sur le nombre d'attributs, le nombre de méthodes et le lien entre eux. Le LCOM de VCC_0.1 se calcule à l'aide de la

LCOM =  1 a _a j=1m(Aj)  − m m− 1

38 CHAPITRE 4. TRANSISTION DE VCC_0.1 À VISUALAIDECC

9 if ((styletex == 4) || (styletex == 5) || (styletex == 6)

10 || (styletex == 7)) { 11 styletex = styletex - 4; 12 bold.setBackground(null); 13 } else { 14 styletex = styletex + 4; 15 bold.setBackground(java.awt.Color.GRAY); 16 } 17 acontroller.setOptionTxt(styletex); 18 } 19 }

Nous voyons bien que l'attribut int styletex est bel est bien utilisé parcette méthode

alors que VCC_0.1 ache le contraire. Nous avons donc implémenté une autre version de LCOM qui prend considération ce cas.

La nouvelle vue achée par VCC_0.1 est représenté par la gure 4.6.

Figure 4.6 Cohésion de TextBar après la première correction

De la gure 4.6 on peut déduire les diérentes valeurs utilisées dans la formule 4.1. Nombre Attributs Color styletex acontroller FONTS classLoader

M(A_i) 0 1 1 1 1

Tableau 4.5 Nombre de méthode par Attribut d'attributs

M ean= 0 + 1 + 1 + 1 + 1

5 = 0.8 (4.2)

LCOM = 0.8 − 2

1 − 2 = 1.2 (4.3)

4.3. AJOUTS AU NIVEAU DES MÉTRIQUES DE COUPLAGE 39

4.3 Ajouts au niveau des métriques de couplage

À partir de cette étape, nous décrivons l'outil VisualAideCC. Les ajouts représentent ce qui a été eectué dans le cadre de ce travail de recherche.. La cause principale de la non-extensibilité d'un logiciel est le couplage entre classes et paquets. Il existe deux types de couplage

- Le couplage sans cycle qui sert à la communication des diérents modules d'un logiciel. Ce couplage est nécessaire au bon fonctionnement du logiciel.

- Le couplage cyclique : ce couplage est facilement identiable lorsque le nombre de classes est faible. Le tableau 4.6, montre un enchaînement de dépendances de classes,

la dernière classe N dépend à son tour de la classe 1. Sur cet exemple, le couplage

est représenté par une matrice. Cet exemple est simple an de montrer le couplage cyclique, par contre il est évident que ce couplage est très dicile à voir lorsqu'on parle de centaines de classes.

Classe 1 Classe 2 Classe 3 Classe 4 Classe 5 ... Classe N

Classe 1 0 1 0 0 0 0 0 Classe 2 0 0 1 0 0 0 0 Classe 3 0 1 0 1 0 0 0 Classe 4 0 1 0 0 1 0 0 Classe 5 0 0 0 0 1 0 ... 0 0 0 0 0 0 1 Classe N 1 0 0 0 0 0 0

Tableau 4.6 Tableau représentant le couplage cyclique

La gure 4.7 montre un couplage cyclique entre deux classes A et B. La classe A dépend

de la classeB et la classe B dépend de la classe A. Une fois le couplage cyclique détecté, le

Figure 4.7 Couplage cyclique

développeur peut utiliser le principe d'inversement des dépendances pour éliminer ce lien

cyclique. En ajoutant une interface de B par exemple. Les deux classes A et B dépendent

maintenant de l'interface de B.

Après que les métriques calculées par VCC_0.1 corrigées et validées, nous passons à la proposition de nouvelles visualisations des métriques. VCC_0.1 ore une visualisation

{B, C} P ile= [A]

{C} P ile= [A, B]

42 CHAPITRE 4. TRANSISTION DE VCC_0.1 À VISUALAIDECC Successeur de C = {D}

P ile = [A, B, C]

Sommet number lowLink

A(0) 0 0

B(1) 1 1

C(2) 2 2

D(3) -

-Tableau 4.9 Étape 3

Étape 4 : Le sommet D : on initialise ces valeurs numberD etlowLinkD.

Le sommet D est placé dans une pile P.

P ile = [A, B, C, D]

Comme D n'a pas de successeurs et que ces numberD et lowLinkD sont de même valeur,

on dépile la pile P jusqu'à retirer le sommet D. Les sommets ainsi dépilés forment une

composante fortement connexe.

La composante est donc [D], constituée d'un seul élément, nous ne la prendrons pas en considération.

Sommet number lowLink

A(0) 0 0

B(1) 1 1

C(2) 2 2

D(3) 3 3

Tableau 4.10 Étape 4

Étape 5 : Nous avons terminé avec le sommet D, on aecte au lowLinkC la plus petite

valeur entrelowLinkCet lelowLinkD, on revient vers le sommet C qui avait comme deuxième

successeur le sommet A.

Sommet number lowLink

A(0) 0 0

B(1) 1 1

C(2) 2 2

D(3) 3 3

Tableau 4.11 Étape 5

Étape 6 : Comme le sommet A existe dans la pile, on aecte au lowLinkC la plus petite

4.3. AJOUTS AU NIVEAU DES MÉTRIQUES DE COUPLAGE 43

P ile= [A, B, C]

Sommet number lowLink

A(0) 0 0

B(1) 1 1

C(2) 2 0

D(3) 3 3

Tableau 4.12 Étape 6

Étape 7 : On a terminé avec le sommet C, on aecte aulowLinkBla plus petite valeur entre

lelowLinkC et le lowLinkB.

P ile= [A, B, C]

Sommet number lowLink

A(0) 0 0

B(1) 1 0

C(2) 2 0

D(3) 3 3

Tableau 4.13 Étape 7

Étape 8 : On a terminé avec le sommet B, on aecte aulowLinkAla plus petite valeur entre

lelowLinkA et le lowLinkB.(aucun changement)

P ile= [A, B, C] Comme le numberA = lowLinkA, on dépile la pile P jusqu'à arriver au

sommet A.

Les sommets ainsi dépilés forment une composante fortement connexe. La composante est donc [A, B, C]

Un deuxième traitement est nécessaire, en utilisant l'algorithme de Johnson[Johnson, 1975] an de détecter tous les cycles présents dans le projet.

4.3.2 Algorithme de Donald Johnson

Donald Johnson [Johnson, 1975] s'est basé sur l'algorithme de Tarjan pour la détection des composants fortement connexes. Une fois détectés, ces composants sont utilisés pour rechercher les cycles élémentaires présents dans un graphe. L'algorithme procède en créant un graphe élémentaire à partir du sommet s, les sommets du graphe élémentaire sont gardés dans une pile stack. Un nouveau sommet est ajouté au graphe élémentaire par appel récursif

44 CHAPITRE 4. TRANSISTION DE VCC_0.1 À VISUALAIDECC de la méthode ndCycles. Pour éviter la duplication deschemins, lessommetsajoutéssont bloquéspar l'aectation.

this.blocked[v] = true; //Sommet v bloqué

Une foisqu'un cycle est détecté, la pile stack est dépilée, ces sommets-là forment un cycle. Listing 4.6  implémentation de l'algorithme de Johnson

1 private boolean findCycles(int v, int s, Vector[] adjList) { 2 boolean f = false;

3 this.stack.add(new Integer(v)); 4 this.blocked[v] = true;

5

6 for (int i = 0; i < adjList[v].size(); i++) { 7 int w = ((Integer) adjList[v].get(i)).intValue(); 8 if (w == s) {

9 Vector cycle = new Vector();

10 for (int j = 0; j < this.stack.size(); j++) {

11 int index = ((Integer) this.stack.get(j)).intValue(); 12 cycle.add(this.graphNodes[index]);

13 }

14 this.cycles.add(cycle); 15 f = true;

16 } else if (!this.blocked[w]) {

17 if (this.findCycles(w, s, adjList)) { 18 f = true; 19 } 20 } 21 } 22 23 if (f) { 24 this.unblock(v); 25 } else {

26 for (int i = 0; i < adjList[v].size(); i++) { 27 int w = ((Integer) adjList[v].get(i)).intValue(); 28 if (!this.B[w].contains(new Integer(v))) {

29 this.B[w].add(new Integer(v)); 30 }

31 } 32 } 33

34 this.stack.remove(new Integer(v)); 35 return f;

N = 7

Atrribut= 3 M ean= 9₃ LCOM = 3−7₁₋₇

4.5. CONCLUSION DU CHAPITRE 49 eectués au niveau du couplage, avec l'implémentation des algorithmes de Tarjan [Tarjan, 1972] et de Johnson [Johnson, 1975] utilisés pour la détection de composants fortement connexes et déduire les cycles élémentaires dans ces composants. Par la suite, nous avons présenté les ajouts eectués au niveau de la cohésion. Le premier consiste à proposer à l'utilisateur d'acher les méthodes non utilisées dans le projet, alors que le deuxième

permet de paramétrer l'outil. Ce paramétrage permet d'inclure les getter(s), setter(s)

dans le calcul du LCOM et de congurer l'avertisseur couleur du LCOM pour qu'il réagisse à un nombre minimum de méthodes et d'attributs. Dans le chapitre de validation, nous analysons cinq programmes réalisés à l'Université de Sherbrooke, pour tenter de démontrer l'ecacité d'un tel outil, en comparant dans certain cas les visualisations que propose Metrics 1.3.8 avec les visualisations que nous proposons dans VisualAideCC.

CHAPITRE 5

Validation de VisualAideCC

Dans ce chapitre nous tenterons de démontrer la pertinence de l'utilisation des visuali-sations pour mieux interpréter les métriques, nous nous proposons d'appliquer Visua-lAideCC sur des programmes réalisés au laboratoire eXit ou dans le cours de Génie Logiciel. Nous ne représenterons pas tous les résultats obtenus, mais seulement les plus intéressants. Le tableau 5.1résume le nombre de problèmes potentiels détectés à l'aide de VisualAideCC sur chacun des programmes testés, soit Othello-1, Othello-2, jFig-1, jFig-2 et TddJFig.

Tableau 5.1Tab1leau récapitulatif des problèmes détectés par VisualAideCC

LOC Cohésion Couplage cyclique

Othello-1 2641 3 2 Othello-2 2788 12 6 JFig-1 9025 4 16 JFig-2 9434 2 16 TddJFig 2680 2 0

5.1 Othello-1

Ce programme est le jeu d'Othello, avec une interface graphique. Ce programme a été réalisé par une équipe qui avait peu de notions sur le développement agile, après analyse de ce programme avec notre plug-in, nous discutons les résultats obtenus dans ce qui suit. Pour avoir une vue globale du code source, VisualAideCC ache les informations sui-vantes :

- Nombre de lignes de code = 2641 - Nombre de paquets = 13

- Nombre de classes = 38 - Nombre d'interfaces= 2

LCOM = 0.951

54 CHAPITRE 5. VALIDATION DE VISUALAIDECC mauvaise cohésion alors que la plupart des attributs ne sont utilisés que dans les getters

et setters. En choisissant d'ignorer les getter(s) et setter(s) dans la conguration des

préférences, nous obtenons le résultat représenté par le tableau 5.3 Attributs Id C M 0 X 1 X X 2 X X 3 X 4 X 5 X X

Tableau 5.3 Cohesion GameState après suppression des Getters et setters

le nouveau LCOM devient :

M ean= 1+2+2+1+1+2₆ = 3

Le nouveau M : nombre de méthodes devient M = 2. Donc d'après la formule 4.1

LCOM = 3−2₁₋₂ = 0, 5

5.1.2 Couplage de Othello-1

VisualAideCC identie un cycle entre la classe OthelloViewet la classeOthelloController.

Figure 5.5 Cycle sur Othello-1

Ce cycle est représenté sur la gure5.5, l'utilisateur peut voir directement les classes concer-nées par le cycle ; une infobulle ache le nom de la classe et le paquet auquel elle appartient. En sélectionnant une classe, on peut aussi voir les dépendances, dans ce cas précis nous avons seulement deux classes qui dépendent l'une de l'autre. Il faut signaler que ce cycle n'aurait pas pu être repéré avec le plug-in Metrics 1.3.8 , car ce dernier ne détecte que les

cycles existants entre les paquets. Or, les deux classes OthelloView et OthelloController se

5.2. OTHELLO-2 55 Au vu de la structure des classes, l'équipe a utilisé le modèle de conception MVC (Modèle Vue Contrôleur). Le modèle MVC fonctionne comme suit :

Après interaction de l'utilisateur avec la vue, cette dernière prévient le contrôleur qui charge le modèle de procéder à la logique de l'algorithme. Le contrôleur notie la vue, qui va à son tour chercher les nouvelles valeurs à acher. Le modèle est représenté par la gure 5.6 Dans ce genre de modèle, il n'existe pas de cycle. Or, un cycle est détecté

Figure 5.6 Model MVC [Charon, I., 2015]

entre la vue et le contrôleur, ce qui démontre une mauvaise implémentation du modèle de conception MVC (Modèle vue contrôleur).

5.2 Othello-2

Ce programme est aussi le jeu d'Othello avec une interface graphique. Ce programme a été réalisé par une équipe qui avait plus de notions sur le développement agile que la première équipe.

Pour avoir une vue globale du code source, VisualAideCC ache les informations sui-vantes :

- Nombre de lignes de code = 2788 - Nombre de paquets = 7

- Nombre de classes = 43 - Nombre d'interfaces= 17

La grande diérence avec Othello-1 est le nombre d'interfaces.

5.2.1 Cohésion de Othello-2