École de technologie supÉrieure universitÉ du quÉbec...

ÉCOLE DE TECHNOLOGIE SUPÉRIEURE

UNIVERSITÉ DU QUÉBEC

PRÉSENTÉE À

L’ÉCOLE DE TECHNOLOGIE SUPÉRIEURE

DANS LE CADRE DE COURS

COURS MGL804 - RÉALISATION ET MAINTENANCE DE LOGICIELS

PAR

SHABNAM MAHMOUDIMACHAKPOSHTI

MAHS08598103

ÉVALUATION DE LA MAINTENABILITÉ DES LOGICIELS AVEC SONARQUBE

MONTRÉAL, LE 17/05/2016

©Tous droits réservés, Shabnam MAHMOUDIMACHAKPOSHTI, 2016

1

ÉVALUATION DE LA MAINTENABILITÉ DES LOGICIELS AVEC

SONARQUBE

SHABNAM MAHMOUDIMACHAKPOSHTI

RÉSUMÉ

Ce rapport est l’analyse de la maintenabilité de deux projets open source à l’aide du logiciel

de l’évaluation de la qualité Sonar, en suivant les étapes d’une analyse reproductible, impartiale et

objective. Pour la mesure de la qualité de maintenabilité de logiciel, les deux projets différents

sont choisis. Les différences sont la taille, le genre de travail et le langage de programmation.

Sonar permet de visualiser les résultats de la mesure. L’analyse des résultats permet de bien

comprendre les points forts et les faibles de la qualité de la maintenabilité. Cette dernière est très

importante pour les mainteneurs qui effectuent la maintenance le logiciel.

L’approche utilisée pour réaliser ce travail est l’extraction des attributs qualité de

maintenabilité de la norme ISO 9126 qui sert de référence de la qualité et l’évaluation de qualité

des logiciels. Ensuite, l’exécution de logiciel Sonar pour obtenir des résultats de la mesure des

attributs qualité. Puis, l’analyse des résultats obtenus pour comprendre l’état de la qualité de

logiciel et décider de maintenir le logiciel. Enfin, l’émission des recommandations.

2

TABLE DES MATIÈRES

CHAPITRE 1: INTRODUCTION……….………………………………………………………..6

1.1 Objectif………………………………………………………………………………………...6

1.2 Approche………………………………………………………………………………………6

CHAPITRE 2: LA NORME UTILISÉE…………………………………………………………...7

2.1 La norme ISO 9126…………………………………………………………………………….7

CHAPITRE 3: DESCRIPTION DES PROJETS…………………………………………………..8

3.1 Pair FX………………………………………………………………………………………...9

3.2 Subirons………………………………………………………………………………………10

CHAPITRE 4: L’OUTIL CHOISI: SONAR……………………………………………………..11

4.1 Principe de Sonar……………………………………………………………………………..11

4.2 Mesure effectuée par Sonar…………………………………………………………………..11

4.3 Exécution de Sonar…………………………………………………………………………...12

CHAPITRE 5: ANALYSE DES RÉSULTATS………………………………………………….14

5.1 Taille du code source…………………………………………………………………………14

5.1.1 Résultat de la mesure……………………………………………………………………..14

5.1.2 Interprétation des résultats………………………………………………………………..14

5.2 Documentation……………………………………………………………………………….15



5.2.3 Recommandations………………………………………………………………………..15

5.3 Duplication de code…………………………………………………………………………..16




5.4 Complexité…………………………………………………………………………………...18



5.4.3 Recommandations..………………………..……………………………………………..19

5.5 Code Smell et Dette technique………………………………………………………………..20




CONCLUSION…………………………………………………………………………………..23

LISTE DE RÉFÉRENCES BIBLIOGRAPHIQUES…………………………………………….24

3

LISTE DES TABLEAUX

Page

Tableau 5.1 Les classes qui contient les blocs dupliqués de PairFX………………………..…...17

Tableau 5.2 Les classes qui contient les blocs dupliqués de Subrion………………..…………..17

Tableau 5.3 La liste de blocs avec les mauvaises odeurs dans le code de PairFX………..……..21

Tableau 5.4 La liste de blocs avec les mauvaises odeurs dans le code de Subrion…………..….21

4

LISTE DES FIGURES

Page

Figure 2.1 Caractéristiques de la qualité ISO 9126………………………………………………...7

Figure 3.1 L’interface de PairFX…………………………………………………………...……...9

Figure 3.2 L’interface de Subrion…………………………………………………….…………..10

Figure 4.1 Les exemples de la configuration des projets en Java et PHP……………….…………12

Figure 4.2 Fenêtre de d’marrer le SonarQube…………………………………………………….13

Figure 5.1 Les résultats de taille des projets Subrion et PairFX…………………………………..14

Figure 5.2 La résultat de la mesure de documentation de deux projets Subrion et PairFX………..15

Figure 5.3 Le résultat de duplication pour l’application PairFX………………………………….16

Figure 5.4 Le résultat de duplication pour l’application Subrion…………………………………16

Figure 5.5 Le résultat de complexité pour les deux applications Subrion………………………...18

Figure 5.6 Le résultat de complexité pour les deux applications PairFX………………….………18

Figure 5.7 Le résultat de Code Smell pour l’application PairFX………………………….………20

Figure 5.8 Le résultat de Code Smell pour l’application Subrion………………………….……...20

5

LISTE DES ABRÉVIATIONS, SIGLES ET ACRONYMES

ISO : l'Organisation internationale de normalisation

API : Interface de programmation d'applications

6

CHAPITRE 1

INTRODUCTION

1.1 Objectif

Ce rapport est préparé dans le cadre de cour MGL804, la réalisation et la maintenance de

logiciels. Le but de ce projet est l’analyse de la maintenabilité de deux logiciels avec les différentes

caractéristiques. L’une est un petit projet en Java et l’autre est un grand projet en PHP. L’outil

utilisé pour l’évaluation de la qualité est Sonar. Enfin, les recommandations pour l’améliorer la

qualité de code source sera présentée.

1.2 Approche

L’approche utilisée pour ce projet est présentée dans les étapes suivantes :

Étudier la norme ISO 9126 qui est utilisée pour la qualité des logiciels;

Éliciter des attributs qualité pour la maintenabilité des logiciels;

Exécuter le Sonar pour mesurer des attributs qualité de deux logiciels;

Analyser les résultats de la mesure de qualité des codes sources;

Présenter les recommandations.

7

CHAPITRE 2

LA NORME UTILISÉE

2.1 La norme ISO 9126

La norme ISO 9126 est la norme qui définit les critères de mesure de la qualité d’un produit

logiciel. Le modèle de qualité de cette norme se base sur un ensemble de caractéristiques et de

sous-caractéristiques de la qualité. La figure 2.1 indiquant les caractéristiques et les sous-

caractéristiques de qualité interne et externe de la norme ISO 9126.

Figure 2.1 Caractéristiques de la qualité ISO 9126 [5]

La norme ISO/CEI 9126 définit six groupes d’indicateurs de la qualité d’un logiciel, qui sont

:

La capacité fonctionnelle

Ensemble d’attributs portant sur l’existence d’un ensemble de fonctions et leurs propriétés

données. Les fonctions sont celles qui satisfont aux besoins exprimés ou implicites.

La Fiabilité

Ensemble d’attributs portant sur l’aptitude d’un logiciel à maintenir son niveau de service

dans des conditions précises et pendant une période déterminée.

8

La facilité d’utilisation

Ensemble d’attributs portant sur l’effort nécessaire pour l’utilisation et sur l’évaluation

individuelle de cette utilisation par un ensemble défini ou implicite d’utilisateurs.

L’efficacité

Ensemble d’attributs portant sur le rapport existant entre le niveau de service d’un logiciel

et la quantité de ressources utilisées, dans des conditions déterminées.

La maintenabilité

Ensemble d’attributs portant sur l’effort nécessaire pour faire des modifications données.

La portabilité

Ensemble d’attributs portant sur l’aptitude de logiciel à être transféré d’un environnement à

l’autre. Comme mentionné dans la figure 2.1, il y a des sous-caractéristiques pour chaque

caractéristique. Par exemple, pour la maintenabilité les sous-caractéristiques sont les suivantes :

Facilité d’analyse;

Facilité de modification;

Stabilité;

Facilité de test;

Maintenabilité;

Conformité réglementaire.

La mesure de la maintenabilité n’est pas une mesure directe. C’est-à-dire qu’il n’y a pas

qu’une seule mesure d’un logiciel et on se doit de mesurer plusieurs indicateurs afin d’en tirer

quelques conclusions sur la maintenabilité [9].

9

CHAPITRE 3

DESCRIPTION DES PROJETS

3.1 Pair FX

Pair FX est un logiciel open source de gestion d'appariement spécialisé dans les tournois de

jeunes administrés par les écoles et clubs d'échecs. Il est écrit en Java, Pair FX gère des tournois

qui ne sont pas organisés sous forme de ronde, c’est-à-dire qu’un joueur ayant terminé sa partie

plus tôt n’est pas obligé d’attendre tous les autres pour commencer une nouvelle partie [3]. La

figure 3.1 indique l’interface de ce logiciel.

Figure 3.1 L’interface de Pair FX [3].

Les fonctionnalités principales présentées dans le logiciel sont les suivantes :

Importer la liste des joueurs à partir d'Excel ;

Gérer des joueurs ;

Supprimer un appariement ;

Rechercher un joueur apparié ;

Exporter au format HTML ;

Activer ou désactiver l’atténuation de la couleur de l’écran ;

10

Enregistrer au format XML [3].

3.2 Subirons

Subirons est un logiciel open source pour la gestion de contenu qui permet de construire des

sites web. Il est écrit en PHP.

La figure 3.2 indique l’interface de ce logiciel.

Figure 3.2 L’interface de Subirons [4]

Les fonctionnalités principales présentées dans le logiciel sont les suivantes :

L’accès aux services pour les deux types d’utilisateurs : l’utilisateur final et l’administrateur;

La gestion de compte pour les deux types des utilisateurs;

La gestion de finance ;

11

CHAPITRE 4

L’OUTIL CHOISI : SONAR

4.1 Principe de Sonar :

SONAR est un outil open source pour la gestion de qualité du logiciel, dédié à l’analyse et

la mesure continues de la qualité du code source. [2]

L’outil permet d’effectuer une évaluation de la qualité d’un produit logiciel, en effectuant

un ensemble de mesures sur le code source, et sans exécuter le programme.

Les mesures effectuées par SONAR peuvent permettre de :

Détecter certaines erreurs potentielles, ou certaines mauvaises pratiques de programmation ;

Prendre des décisions quant à faire de factorisation de certaines composantes du Logiciel.

Il supporte plus de 20 langages de programmation et il fournit plusieurs métriques qui

permettent de mesurer la qualité des logiciels.

4.2 Mesure effectuée par Sonar

Les différents types de mesure que SONAR peut effectuer pour l’analyse de la maintenabilité

ont les suivants :

Taille du code source : nombre total de lignes de code, de packages, des classes et des méthodes.

Documentation : Nombre de lignes de commentaires pour les codes et les APIs.

Duplication de code : Cette métrique indiquant la duplication des blocs d’instructions dans le code

source.

Complexité : La complexité ou la complexité des fonctionnes et des classes. La complexité d'une

méthode est définie par le nombre de chemins linéairement indépendants qu'il est possible

d'emprunter dans cette méthode. Plus simplement, il s'agit du nombre de points de décision de la

méthode (if, case, white, ...).

Code Smell : En génie logiciel, les codes Smells ou mauvaises odeurs, sont des mauvaises

pratiques de conception logicielle qui conduisent à l'apparition de défauts. Ces défauts sont souvent

issus de mauvais choix d'implémentations ou de conceptions et conduisent à une complexification

du code source et de la maintenance et évolutivité de celui-ci. Afin de corriger, un code smell, il

https://fr.wikipedia.org/wiki/Conception_de_logicielhttps://fr.wikipedia.org/wiki/Maintenance

12

est nécessaire de procéder à une refactorisation du code source, c'est-à-dire modifier le code sans

en altérer son comportement. [8]

Dette technique : C’est une dette qui accompagne tous les projets logiciels. Ils ne sont pas des

bugs, mais plutôt des défauts de conception ne permettant pas au logiciel de se maintenir ou

d’évoluer simplement. [6]

En résumé, quand on code au plus vite et de manière non optimale, on contracte une dette

technique que l’on rembourse tout au long de la vie du projet sous forme de temps de

développement de plus en plus long et de bugs de plus en plus fréquents. [7]

4.3 Exécution de Sonar

Pour l’utilisation de SonarQube nous avons suivi les étapes suivantes :

1. Télécharger le SonarQube de l’adresse : http://www.sonarsource.org/downloads/ et unzip le fichier

(c:\sonarqube)

2. Lancer le serveur de SonarQube :

Sur Windows, exécuter:

C:\sonarqube\bin\windows-x86-xx\StartSonar.bat

Sur autre système d’opération:

/etc/sonarqube/bin/[OS]/sonar.sh console

3. Télécharger le SonarQube Scanner et unzip le fichier (C:\sonar-scanner)

4. Pour l’analyse du projet, il faut créer un fichier qui s’appelle « sonar-project-properties » dans le

dossier principal du projet. Les contenus de ce fichier sont indiqués dans la figure 4.1.

Figure 4.1 Les exemples de la configuration des projets en Java et PHP

1. L’exécution le lien suivant :

https://fr.wikipedia.org/wiki/R%C3%A9usinage_de_codehttp://www.sonarsource.org/downloads/http://docs.sonarqube.org/display/SCAN/Analyzing+with+SonarQube+Scanner

13

Cd C:\sonar-projects\PairFx

C:\sonar-scanner\bin\sonar-scanner.bat

2. Pour afficher les résultats d’analyse, il faut ouvrir l’adresse suivant sur le navigateur :

http://localhost:9000

Figure 4.2 Fenêtre de démarrer le SonarQube

À propos de l’analyse d’un projet en PHP, il faut installer le plug-in de PHP sur SonarQube

á suivre les étapes suivantes :

3. Choisir les sections :

Settings > Update Center > Available Plugins

4. Trouver le plug-in de PHP et cliquer le bouton « Install »

http://localhost:9000/

14

CHAPITRE 5

ANALYSE DES RÉSULTATS

Dans ce parti, il existe des résultats obtenus par Sonar. Après avoir exécuté le Sonar pour les

deux logiciels, ça nous a donné les résultats suivants :

5.1 Taille du code source

5.1.1 Résultat de la mesure

Sonar permet de visualiser la taille de projet par la ligne de code, les fonctions et les classes.

La figure 5.1 indiquant les résultats détaillés de taille de deux projets Subrion et PairFX.

Subrion PairFX

Figure 5.1 Les résultats de taille des projets Subrion et PairFX

5.1.2 Interprétation des résultats

Sonar calcule cette métrique en fonction du nombre de lignes du code. La figure 5.1

indiquant Subrion contient 91,163 lignes de code en PHP et PairFX contient 4,496 lignes de code

de Java.

15

5.2 Documentation

5.2.1 Résultats de la mesure

Subrion PairFX

Figure 5.2 La résultat de la mesure de documentation de deux projets Subrion et PairFX.


La documentation dans le code source est une pointe importante pour la maintenance. Il aide

les mainteneurs de comprendre le code source d'une application. La figure 5.2 indiquant dans

l’application Subrion il existe 28,451 lignes de commentaires. C’est-à-dire pour 23.8% de codes,

il y a des commentaires.

À propos de l’application PairFX, Sonar indique le total de lignes de commentaires. Il existe

142 lignes de commentaires pour 4459 lignes de code. C’est-à-dire pour 3.1% du code, il y a des

commentaires. Ce n’est pas suffisant pour maintenir. Pour le projet PaireFX en Java, Sonar a

donné les nombres de lignes de commentaire pour les APIs.

5.2.3 Recommandations

La recommandation pour les deux projets Subrion et PaireFX est bien documenter les codes

sources, afin de facilite la compréhension les deux types de projets par l’équipe de maintenance,

ceci s’effectue à travers les commentaires du code source et la documentation API pour les

fonctions publiques générée par l’outil Java doc.

16

5.3 Duplication de code


PairFX

Figure5.3 Le résultat de duplication pour l’application PairFX

Subrion

Figure 5.4 Le résultat de duplication pour l’application Subrion

17


Sonar permit aussi de visualiser les blocs de code dupliqués à l’intérieur du code des classes.

Comme indiqué dans la figure 5.3, la duplication pour l’application PairFX est 2.3% de lignes de

code. Pour cette application, il existe 6 blocs dupliqués dans deux fichiers.

Selon le diagramme de duplication de PairFX, les deux classes qui ont beaucoup de blocs

dupliqués sont les suivants :

Tableau 5.1 Les classes qui contient les blocs dupliqués de PairFX

Nom de Classe Ligne

de code

Linges

dupliqués

Blocs

dupliqués

ToernooiOverzichtRoundRobinControl 317 69 3

ToernooiOverzichtController 356 69 3

À propos de duplication dans l’application Subrion, comme indiqué dans la figure 5.4 le

ratio de duplication pour cette application est 10%. C’est-à-dire, il n’y a pas de problème de

duplication pour 90% du code source. Pour cela, il existe 576 blocs dupliqués dans 119 fichiers.

Selon le diagramme de duplication de Subrion, les fichiers qui ont plusieurs de blocs dupliqués

sont les suivants :

Tableau 5.2 Les classes qui contient les blocs dupliqués de Subrion

Nom de fichier Ligne de

code

Linges

dupliqués

Blocs

dupliqués

smarty_internal_templateparser 3007 1775 14

smarty_internal_cofigfileparser 818 682 12

ia.core.mysqli 670 593 12

ia.core.pdo 622 590 10

ia.core.mysql 649 551 9

Comme indiqué dans la figure 5.4, la plupart de problème de duplication des blocs sont

trouvés dans les fichiers qui ont moins de 1000 lignes de codes.

18


Les recommandations pour traiter la duplication sont les suivants :

Rassembler le code dupliqué dans des méthodes réutilisables.

Revoir la conception et le découpage des traitements pour bénéficier des similarités entre les

traitements d’ajout et de modification dans la base de données.

5.4 Complexité


Subrion

Figure 5.5 Le résultat de complexité pour les deux applications Subrion.

PairFX

Figure 5.6 Le résultat de complexité pour les deux applications PairFX

19


La complexité est une pointe importante pour la maintenance. Les méthodes complexes sont

difficiles à maintenir. Ils ont un impact sur l'effort requis pour faire sa maintenance. Une méthode

avec une faible complexité, nécessite en général moins d'effort pour la maintenir qu'une méthode

avec une forte complexité. Sonar permet de visualiser les résultats de la mesure de complexité. Les

résultats sont indiqués par méthode, par fichier et par classe. À propos de l’application Subrion,

la moyenne complexité par méthode est 5.3 et la complexité totale de cette application est 25,342.

Les 1687 méthodes dans l’application Subrion ont la complexité de 1 sur un total de 4424

méthodes, ce qui est bien pour la maintenance.

À propos de l’application PairFX, comme indique dans la figure 5.5, la moyenne de

complexité est 1.9 par méthode. La complexité totale est 939. Dans cette application, il y a 281

méthodes qui ont la complexité de 1 sur un total de 496 méthodes.


Pour diminuer la complexité, il faut découper les méthodes des classes s’il y a peu

d’interaction entre elle. Il faut aussi simplifier et optimiser les algorithmes.

20

5.5 Code Smell et Dette technique


PairFX

5.7 Le résultat de Code Smell pour l’application PairFX.

Subrion

5.8 Le résultat de Code Smell pour l’application Subrion.

21


Comme indiqué dans la figure 5.7 pour l’application PairFX, il a 270 codes smells. La

plupart des mauvaises odeurs sont dans les blocs qui ont moins de 100 lignes de codes. C’est-à-

dire les petits blocs ont des problèmes comme la duplication ou des longs commentaires. Les blocs

qui ont les plus parts des codes smell sont les suivants :

Tableau 5.3 La liste de blocs avec les mauvaises odeurs dans le code de PairFX

Nom de classe Lignes de code Dette technique Code Smells

Screens 20 3h 20min 18

Messages 36 1h 46min 35

ExportFlags 19 1h 10min 7

Également, le ratio de dette technique pour cette application est 1.2 %. Sonar calcul l’effort

pour traiter les défauts de dette technique. Pour PairFX, l’effort prévu pour dette technique est les

3 jours et 3heurs. C’est-à-dire un programmeur doit travailler 27 heures pour remédier les dettes

techniques de PairFX.

Comme indiqué dans la figure 5.8 pour l’application Subrion, il a 11,375 codes smells. La

plus part des mauvaise odeurs sont dans les blocs qui ont moins de 1000 lignes de codes. Les blocs

qui ont les plus parts des codes smell sont les suivants :

Tableau 5.4 La liste de blocs avec les mauvaises odeurs dans le code de Subrion

Nom de classe Lignes de code Dette

technique Code Smells

adminer.script.php 780 14j 1600

fields.php 985 2j 4h 84

ia.core.field.php 884 2j 115

Également, le ratio de dette technique pour cette application est 2.7 %. Sonar calcul l’effort

pour traiter les défauts de dette technique. Pour Subrion, l’effort prévu pour dette technique est les

22

154 jours. C’est-à-dire un programmeur doit travailler 1232 heures pour remédier les dettes

techniques de Subrion.


La plus part des problèmes de code smells et dette technique sont la duplication des

fonctions. La recommandation est de diminuer la duplication dans les méthodes et entre les blocs.

Également, les commentaires dans le code devraient être utilisés pour indiquer le "pourquoi" et

non pas le "quoi".

23

CONCLUSION

Nous a fait l’évaluation de la qualité de maintenabilité pour les deux l’application avec les

caractéristiques différents. Nous avons utilisé l’outil Sonar pour évaluer. Sonar nous a permis de

visualiser les mesures. L’équipe de maintenance peut prendre des décisions à propos de maintenir

de logiciels avec les résultats de la mesure.

Les résultats de la mesure indiquent le niveau de maintenabilité des logiciels analysés,

PairFX et Subrion sont A. Ce résultat est un bon niveau de maintenir en théorique. Selon les

résultats de l’estimation de dette technique de projet PairFX, ce projet a besoin de 3 jours d’effort

d’un programmeur. Ce n’est pas beaucoup pour réviser les codes source pour éliminer les

problèmes de dette technique d’un projet avec 4 KLOC. Également, le résultat de l’estimation des

efforts de dette technique de projet Subrion indiquent ce projet a besoin de 154 jours de l’effort

d’un programmeur pour résoudre les problèmes de dette technique. C’est beaucoup pour un projet

de 91 KLOC. En général, les outils de l’analyse de la qualité de logiciel ne peuvent pas dire

exactement, est ce que le niveau de maintenabilité d’un logiciel est bonne ou non. Mais ils peuvent

nous donner une estimation pour la décision de statut de la maintenance.

24

LISTE DE RÉFÉRENCES BIBLIOGRAPHIQUES

[1] ISO/CEI 9126-1. « Modèle de qualité : 2001 », dans Technologie de l’information : Qualité

de produits logiciels, Partie 1, Genève, Norme Internationale, ISO, 2001.

[2] Documentation de SONAR : http://sonar.codehaus.org/ (consulté le 15 Mai 2016)

[3] Documentation de PairFX : http://sourceforge.net/projects/pairfx/?source=directory

[4] Documentation de Subrion : http://www.subrion.org/

[5] https://www.researchgate.net/figure/254916205_fig3_Figure-3-ISO-9126-Internal-and-

External-Quality-Characteristics-Level-5-Major-review

[6] http://blog.dollon.net/la-dette-technique/

[7] http://blog.octo.com/maitriser-sa-dette-technique/

[8] https://fr.wikipedia.org/wiki/Code_Smell

[9] Pressman, R. S. Software Engineering: A Practitioner’s Approach, 3th edition, McGraw-Hill,

1992.
http://sonar.codehaus.org/http://sourceforge.net/projects/pairfx/?source=directoryhttps://www.researchgate.net/figure/254916205_fig3_Figure-3-ISO-9126-Internal-and-%20%20%20%20%20External-Quality-Characteristics-Level-5-Major-reviewhttps://www.researchgate.net/figure/254916205_fig3_Figure-3-ISO-9126-Internal-and-%20%20%20%20%20External-Quality-Characteristics-Level-5-Major-reviewhttps://fr.wikipedia.org/wiki/Code_Smell

École de technologie supÉrieure universitÉ du quÉbec...

Documents