Académique Documents
Professionnel Documents
Culture Documents
Application SHARPDEVELOP
Rapport d’audit
01/01/2011
Son objectif est de servir de modèle pour constituer des rapports personnalisés,
il illustre la capacité de la plateforme à restituer une vision claire et compréhensible
de la qualité d’une application.
Kalistick
13 av Albert Einstein
F-69100 Villeurbanne
+33(0) 486 68 89 42
contact@kalistick.com
www.kalistick.com
Audit de code de l’application SharpDevelop 01/01/2011
1 Executive Summary
Le Cockpit Qualité utilise des techniques d’analyse statique : il n’exécute pas l’application mais analyse les
éléments qui la constituent (code, résultats des tests, architecture, …). Les résultats sont corrélés, agrégés et
comparés avec les enjeux du projet pour identifier les risques liés à la qualité. Ce rapport présente les
résultats obtenus.
Organisation du rapport
Ce rapport présente les concepts du Cockpit Qualité, l’objectif fixé et les exigences techniques associées,
avant de poursuivre par les résultats synthétiques puis détaillés par domaine technique.
2 Introduction
Le processus d’analyse repose sur la plateforme « Cockpit Qualité », disponible en mode SaaS1
(https://cockpit.kalistick.com). Cette plateforme présente l’avantage d’offrir une base de connaissances
unique du fait qu’elle centralise les résultats statistiques issus de l’analyse de millions de lignes de code, base
enrichie en continu avec les nouvelles analyses. Elle permet notamment de réaliser des analyses
comparatives avec d’autres projets similaires.
Les résultats sont proposés dans une grille d’analyse qui s’articule autour de 3 dimensions principales :
Les axes de qualité, qui déterminent la nature de l’impact des non-conformités détectées, donc la
conséquence sur le niveau de qualité de l’application
Les domaines de qualité, qui précisent l’origine technique des non-conformités
Les niveaux de sévérité, qui positionnent les non-conformités sur une échelle de gravité afin de
caractériser leur priorité
1
Software as a Service : application accessible à distance via Internet (à l’aide d’un navigateur standard)
Maintenabilité. Capacité d’un logiciel à pouvoir être dépanné facilement, en fonction de l’effort
exigé pour localiser, identifier et corriger les erreurs.
Fiabilité. Aptitude d’un logiciel à fonctionner correctement en rendant le service attendu dans les
conditions normales de fonctionnement.
Evolutivité. Aptitude d’un logiciel à pouvoir évoluer, en fonction de l’effort requis pour ajouter,
supprimer, modifier des fonctions d’un logiciel déjà opérationnel.
Transférabilité. Capacité à faire réaliser la maintenance et les évolutions d’un logiciel par une
nouvelle équipe distincte de celle ayant développé le logiciel initial.
Structure. Les problèmes liés à l’organisation du code : méthodes trop longues, trop complexes, avec
trop de dépendances, … Ces problèmes impactent généralement la maintenabilité et l’évolutivité de
l’application.
2
ISO/IEC 9126-1:2001 Software engineering — Product quality — Part 1: Quality model :
http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=22749
3
L’analyse porte sur un sous-ensemble de la norme ISO 9126 afin de se focaliser sur les dimensions contrôlables de
manière automatisée.
Test. Qualifie la manière dont est testée l’application, à partir des résultats des tests unitaires (taux
d’échec, durée d’exécution, …), mais également en fonction de la nature du code couvert par
l’exécution des tests. L’objectif consiste à s’assurer que les tests couvrent les parties critiques de
l’application.
Pour simplifier leur interprétation, les niveaux de sévérité sont exprimés à l’aide d’une échelle à quatre
niveaux. Le premier correspond à une erreur, les trois suivants à des avertissements, du plus grave au moins
grave :
Interdit
Fortement déconseillé
Déconseillé
A éviter
Par rapport au niveau Interdit, les autres niveaux de sévérité sont gérés à l’aide d’un seuil de tolérance, qui
augmente inversement avec la gravité.
3 Objectif qualité
Une des particularités du « Cockpit Qualité » consiste à réaliser une analyse en fonction des besoins réels du
projet en terme de qualité, afin d’éviter des efforts inutiles de « sur-qualité » et de garantir une meilleure
pertinence sur les risques qualité.
Ces besoins sont formalisés via la définition d’un « profil qualité » de l’application, qui caractérise les niveaux
de qualité attendus sur chacun des six axes de qualités. Ce profil qualité est ensuite traduit en « exigences
techniques », qui sont des règles techniques que devront respecter les développeurs.
Taille des méthodes Nombre de ligne d'instructions. Cette mesure est différente du nombre de
ligne de code : elle n'inclut pas les lignes de commentaire ni les lignes
blanches mais seulement les lignes comportant au moins une instruction.
Objectif : orienter sa stratégie et les efforts de test sur les points sensibles
de l’application et la vérifier. Ces points sensibles sont évalués selon leur
propension à contenir des bugs et les risques métiers/fonctionnels de
l’application.
Règles définies Voir le modèle d’architecture éventuellement défini pour découvrir les
spécifiquement pour le contraintes d’architecture en cours.
Architecture
modèle d’architecture
de l’application. Objectif : s’assurer que les développements respectent le modèle
d’architecture prévu et n’introduisent pas des incohérences synonymes de
failles de sécurité, de difficultés de maintenance ou d’évolution.
duplications
Objectif : détecter l’implémentation de traitements identiques à plusieurs
endroits différents dans l’application, très souvent source d’incohérences
lorsque l’on effectue des modifications, et facteur d’augmentation des
coûts de tests et d’évolution.
Le niveau de non-conformité est calculé pour chaque axe de qualité, puis pondéré en
fonction du niveau d’exigence fixé pour l’axe concerné.
Les résultats détaillés précisent pour chaque axe de qualité : le nombre de classes non-
conformes, le nombre de violations des règles sélectionnées, et le pourcentage de l’application
présent dans les classes concernées.
Ce graphique compare chaque domaine selon l’impact des règles qui lui sont associées sur
la qualité de l’application. L’impact est mesuré à partir du nombre d’instructions des classes non-
conformes.
4.1.4 Volumétrie
Le tableau suivant précise la volumétrie de l’application analysée :
Une « ligne » correspond à une ligne physique d'un fichier de code. Elle peut concerner une
ligne blanche, ou une ligne de commentaire. Une « instruction » représente une unité de code
primaire, elle peut s’écrire sur plusieurs lignes, mais une ligne peut également contenir plusieurs
instructions. Pour simplifier, une instruction est délimitée par un point-virgule (;) ou par une
accolade gauche ({).
4.2 Benchmarking
La base de connaissance du « Cockpit Qualité » permet de réaliser une analyse comparative du projet avec
les autres projets analysés sur la plateforme. L’objectif est de mesurer son niveau de qualité par rapport à
une moyenne générale.
Cette comparaison « benchmarking » est proposée par rapport à deux catégories de projets :
Les projets « intra-Cockpit » : les projets analysés en continu sur la plateforme, donc, à priori, avec
un niveau de qualité supérieur à la moyenne
Les projets « extra-Cockpit » : les projets analysés ponctuellement sur la plateforme, en mode audit,
donc avec un niveau de qualité très hétérogène.
NB : chaque projet disposant d’un profil qualité qui lui est spécifique, on ne compare pas l’écart en fonction
de l’objectif, mais à l’aide de caractéristiques brutes, afin de donner des points de repère.
Le projet est positionné par rapport aux autres projets selon son taux de violations pour
chaque règle. La répartition est basée sur la méthode des quartiles, trois groupes sont
distingués, « Meilleur » : les 25% de projets les meilleurs, « Dans la moyenne » : les 50% de
projets médians, « Moins bon » : les 25% de projets les moins bons. Cette information est
synthétisée ensuite par niveau de sévérité. Plus le rouge domine plus le problème est important.
Les règles d’implémentation comparées ne sont pas forcément les mêmes selon les profils
de qualité, mais on compare ici les règles selon leur niveau de sévérité défini pour chaque projet.
Le graphique suivant propose la même analyse, mais cette fois avec les projets « intra-Cockpit », analysés en
continu sur la plateforme, donc avec un niveau de qualité normalement supérieur à la moyenne car dans un
processus d’amélioration où les violations détectées sont corrigées :
Une couleur rouge dominante indique que les autres projets tendent à corriger les
violations détectées sur ce projet.
Une proportion importante de l’application dans la zone droite est un indicateur de coûts
de maintenance et d’évolution plus importants.
NB : l’application analysée est indiquée sous le terme « Release ».
Une cartographie similaire est proposée à partir de la complexité cyclomatique4 des méthodes, en
comparant la proportion de l’application (en pourcentage d’instructions) qui est située dans des blocs de
traitement (méthodes) complexes :
Une proportion importante de l’application dans la zone droite indique non-seulement des
coûts de maintenance et d’évolution plus importants, mais également des problèmes de fiabilité
car ce code est difficile à tester.
4
La complexité cyclomatique mesure la complexité algorithmique du code, et donc sa facilité à le tester, cf.
http://classes.cecs.ucf.edu/eel6883/berrios/notes/Paper%204%20(Complexity%20Measure).pdf
Ces modèles sont construits à l’aide de l’assistant de modélisation disponible au sein du Cockpit. Vous
pouvez modifier ces modèles sur les pages Modélisation fonctionelle et Architecture technique (selon
vos droits utilisateurs).
Homogénéiser le comportement d'une application. Par exemple s'assurer que les écritures de logs
utilisent telle API spécifique, que les accès aux données passent par telle couche, que telle librairie
ne soit utilisée que par tel composant, ...
Assurer l'étanchéité de certains composants pour faciliter leur évolution et limiter les effets
imprévus, mais aussi les rendre mutualisables avec d'autres applications. Les cycles de dépendances
sont par exemple proscrits.
Eviter les failles de sécurité en s'assurant par exemple que des appels directs vers une couche
d'accès aux données ne sont jamais réalisés sans passer par une couche métier qui serait
responsable de contrôles de validation
Le résultat de l’analyse des contraintes d’architecture est présenté dans le chapitre 5.5 Architecture.
Les flèches vertes formalisent des communications autorisées entre modules, tandis que
les flèches rouges formalisent des communications proscrites.
5 Résultats détaillés
Ce chapitre détaille les résultats en ciblant plus précisément les règles et les éléments de code non-
conformes. Une analyse domaine par domaine est proposée.
Ces taux de non-conformité dépendent directement du profil qualité du et du niveau des exigences qui ont
été sélectionnées :
Une même classe pouvant être non-conforme sur plusieurs axes, le total ne correspond pas
nécessairement à la somme des axes.
5.2 Implémentation
Le domaine Implémentation couvre les règles se rapportant aux techniques de codage. Contrairement aux
autres domaines, ces règles sont souvent spécifiques aux caractéristiques du langage (Java / C#). Elles
identifient par exemple :
des bugs potentiels : variables non initialisées, problèmes d’accès concurrents, appels récursifs, …
des optimisations en terme mémoire ou CPU
des failles de sécurité
des utilisations de code obsolètes
des écritures s’écartant des standards recommandés
…
Les règles d’implémentations sont les plus nombreuses au sein des exigences techniques. Elles sont ici
nommées « pratiques ».
Le graphique suivant compare le nombre de classes invalidées en implémentation, selon les pratiques qui ont
participé à cette invalidation :
Si une classe ne viole que des pratiques interdites, elle est dans le groupe « Pratiques interdites »
Si une classe ne viole que des pratiques déconseillées, elle est dans le groupe « Pratiques
déconseillées »
Sinon, elle viole des pratiques des deux catégories et se trouve dans le groupe « Pratiques
déconseillées et interdites »
L’effort de correction lié aux pratiques interdites est généralement moins important par
rapport aux sévérités inférieures : une seule violation interdite suffit à générer une non-
conformité alors qu’il en faut plusieurs non interdites pour générer une non-conformité, en
fonction des seuils de tolérance.
Le tableau suivant détaille le graphique en introduisant la notion de « violation impactante ». Une violation
impactante est une violation dont la correction permet de corriger totalement ou partiellement la non-
conformité d’une classe. En effet, en raison des seuils de tolérance associés aux niveaux de sévérité, la
correction de certaines violations n’a aucune influence sur la non-conformité globale de la classe.
Ces tableaux proposent pour chaque pratique le nombre de nouvelles violations (si un audit précédent a été
réalisé), le nombre de violations au total pour cette pratique, le nombre de classes non-conformes où cette
pratique a été détectée et le pourcentage d’instructions de ces classes par rapport au volume d’instruction
global du projet.
Ces chiffres permettent d’établir un plan d’action en fonction de l’impact associé à chaque pratique.
Pour chaque classe sont associés le nombre de violations existantes (pratiques interdites ou fortement
déconseillées), le nombre de nouvelles violations (si un audit précédent a été réalisé), et l’état de conformité
de la classe.
5.3 Structure
Le domaine Structure cible les règles se rapportant à la structuration du code, par exemple :
L’objectif est de s’assurer que le code est structuré de telle manière qui puisse être facilement maintenu,
testé, et qu’il puisse évoluer.
Ces règles sont des « métriques ». Elles mesurent des valeurs (p. ex. : un nombre d’instructions) et sont
conditionnées par des seuils (p. ex. : 100 instructions / méthode). Seules les métriques qui offrent un levier
d’action facile à comprendre et à mettre en œuvre sont proposées ici. Elles s’appliquent toutes à des
méthodes.
Si des règles ont été configurées pour ne pas être prises en compte dans l’audit, elles sont
affichées dans ce graphe mais sans aucun résultat.
Le tableau suivant complète cette vision en introduisant le nombre de nouvelles violations et le nombre de
violations corrigées dans le cas où un audit précédent aurait été réalisé :
Le dernier intervalle identifie les méthodes dont le nombre d’instructions dépasse le seuil fixé. Ces méthodes
sont considérées comme non-conformes car elles sont généralement difficiles à maintenir et à faire évoluer,
et montrent également une forte propension à faire apparaître des bugs, car elles sont difficilement
testables.
Le pourcentage d’instructions est fourni car les méthodes les plus grosses concentrent généralement une
part importante de l’application :
Le tableau suivant détaille les principales méthodes non-conformes, identifiées dans le dernier intervalle du
graphique précédent :
La complexité cyclomatique est une mesure qui permet de caractériser la complexité d’un bloc de code, en
s’intéressant aux différents chemins d’exécution possibles. Ce concept a été standardisé par Mc Cabe5 mais
plusieurs modes de calcul existent. Celui retenu ici est l’un des plus répandus et l’un des plus simples : il
consiste à compter le nombre d’opérateur d’embranchements (if, for, while, ?, …) et de conditions ( ??,
&&, …).
Le dernier intervalle identifie les méthodes dont la complexité dépasse le seuil fixé. Ces méthodes sont
considérées comme non-conformes pour les mêmes raisons que pour les méthodes trop longues : elles sont
généralement difficiles à maintenir et à faire évoluer, et montrent également une forte propension à faire
apparaître des bugs.
Le pourcentage d’instructions ainsi que le pourcentage de complexité sont fournis car les méthodes les plus
complexes concentrent généralement une part importante de l’application.
Le tableau suivant détaille les principales méthodes non-conformes, identifiées dans le dernier intervalle du
graphique précédent :
5
1976, IEEE Transactions on Software Engineering: 308–320.
http://classes.cecs.ucf.edu/eel6883/berrios/notes/Paper%204%20(Complexity%20Measure).pdf.
ICSharpCode.SharpDevelop.Dom.NRefactoryResolver.NRef 53 81 28
actoryResolver.ResolveIdentifierInternal ( System.String)
ICSharpCode.SharpDevelop.Commands.ToolMenuBuilder.To 54 74 26
olEvt ( System.Object, System.EventArgs)
ICSharpCode.SharpDevelop.Dom.MemberLookupHelper.Get 32 51 26
BetterFunctionMember (
ICSharpCode.SharpDevelop.Dom.IReturnType[],
ICSharpCode.SharpDevelop.Dom.IMethodOrProperty,
ICSharpCode.SharpDevelop.Dom.IReturnType[],
System.Boolean,
ICSharpCode.SharpDevelop.Dom.IMethodOrProperty,
ICSharpCode.SharpDevelop.Dom.IReturnType[],
System.Boolean)
ICSharpCode.SharpDevelop.Dom.CSharp.CSharpExpression 51 68 26
Finder.FindFullExpression ( System.String, System.Int32)
ICSharpCode.SharpDevelop.Dom.CSharp.CSharpExpression 58 76 25
Finder.ReadNextToken ( )
5.3.4 Cartographie des méthodes selon leur complexité et leur couplage efférent
Cette règle vise à identifier les méthodes dont le code présente de nombreuses dépendances vers d’autres
classes que la classe courante. La notion de « couplage efférent » correspond à ces dépendances
« sortantes ».
Le principe est qu’une méthode accusant un fort couplage efférent est difficile à comprendre, à maintenir et
à tester d’une part parce qu’elle nécessite la connaissance des différents types tiers dépendants, d’autre par
parce que son risque de déstabilisation est plus élevé en raison de ses dépendances.
Cette règle est croisée avec la complexité cyclomatique afin d’ignorer certaines méthodes triviales, par
exemple des méthodes d’initialisation d’interfaces graphiques qui font appels à de nombreuses classes de
composants graphiques sans présenter de réelle complexité.
Cette règle considère donc qu’une méthode est non-conforme si elle excède un seuil de couplage efférent et
un seuil de complexité cyclomatique.
Le graphique suivant présente une cartographie des méthodes selon leur complexité et leur couplage
efférent. Chaque point représente une ou des méthodes avec les mêmes valeurs de complexité et de
couplage. Ils sont répartis dans quatre zones selon leur état par rapport aux deux seuils :
La zone en bas à gauche (points verts) contient des méthodes conformes qui n’ont atteint aucun des
deux seuils
La zone en bas à droite (points gris) contient des méthodes conformes ; elles ont atteint le seuil de
complexité, mais restent en-dessous du seuil de couplage
La zone en haut à gauche (points gris) contient des méthodes conformes ; elles ont atteint le seuil de
couplage, mais restent en-dessous du seuil de complexité
La zone en haut à droite (points rouges) contient les méthodes non-conformes car les deux seuils
sont atteints
L’intensité de la couleur des points dépend du nombre de méthodes partageant les mêmes
valeurs en complexité et en couplage : plus la couleur du point est marquée, plus il y a de
méthodes concernées.
L’histogramme suivant fournit une vision complémentaire de cette cartographie et précise les chiffres pour
les quatre zones, en termes de pourcentage des méthodes de l’application et en termes de pourcentage du
nombre d’instructions total de l’application. Les dernières barres correspondent à la zone de non-
conformité :
5.4 Test
Le domaine Test propose des règles pour s’assurer que l’application est suffisamment testée,
quantitativement mais surtout qualitativement, c.-à-d. que les tests ciblent les zones à risques.
5.4.1 Problématiques
Il est important de situer les problématiques inhérentes à la gestion des tests afin de comprendre les
résultats d’analyse pour ce domaine.
Un test unitaire est un test automatisé, qui teste généralement une méthode. Mais cette
méthode ayant généralement des dépendances vers d’autres méthodes ou classes, un test
unitaire peut tester un ensemble plus ou moins important de l’application (et plus cet ensemble
est large, moins le test est pertinent)
La couverture de code mesure le volume de code réellement exécuté suite à des tests, en
identifiant précisément chaque élément de code exécuté (instruction, branche conditionnelle,
fonction, …). Ces tests peuvent être des tests unitaires (automatisés), ou des tests d’intégration /
fonctionnels (manuels ou automatisés).
La couverture de code est intéressante à combiner aux tests unitaires car c’est le seul moyen de mesurer le
code réellement testé. Cependant, beaucoup de projets ne vérifient toujours pas la couverture du code, ce
qui ne permet pas de vérifier la qualité des tests dans ce type d’analyse.
Les indicateurs présentés par la suite permettent d’adresser les différents cas, que le projet mette en œuvre
ou non des tests unitaires ou de la couverture de code.
Le problème est que ces chiffres ne tiennent pas compte de la pertinence à tester le code. Par exemple une
couverture de 70% de l’application est un bon chiffre, mais le code couvert peut être trivial et sans réel
intérêt pour les tests (par exemple les accesseurs ou du code généré), alors que le code sensible pourra se
trouver dans les 30% non couverts.
L’analyse réalisée ici tient compte de la pertinence à tester chaque méthode, ce qui permet de calibrer les
exigences de couverture de code et de fixer des exigences en termes de seuil de couverture qui utilisent au
mieux l’effort de test en l’orientant sur les zones à risques.
Le TestRelevancyIndex (TRI) mesure la pertinence à tester une méthode selon ses risques techniques et ses
risques fonctionnels.
Le risque technique évalue la probabilité de trouver un défaut, il est basé sur différentes métriques qui les
favorisent telles que la complexité cyclomatique, le nombre de variables, de paramètres, le couplage
efférent, le nombre de non-conformités cumulé, …
Le risque fonctionnel associe un facteur de risque aux différents groupes de traitements fonctionnels que
l’on souhaite tester en priorité (risque majoré) ou à l’inverse ne pas tester (risque minoré). Il doit être
déterminé au début de l’audit pour être pris en compte dans les calculs de TRI. L’objectif est d’orienter
l’effort de test sur les fonctionnalités importantes.
Pour cela, le TRI permet de classer les méthodes selon une échelle de priorité de tests, et donc de bien
distinguer les méthodes réellement pertinentes à tester des méthodes triviales et sans intérêt sur ce
domaine. Pour chaque niveau de l’échelle, un seuil de couverture de code à atteindre peut être fixé
indépendamment. Ceci permet de définir un seuil exigeant pour des méthodes critiques, et un seuil bas pour
des méthodes à priorité basse.
Le TestEffortIndex (TEI) complète le TRI en mesurant le niveau d’effort pour tester une méthode. Comme le
TRI, il est basé sur un ensemble de métriques unitaires caractérisant la méthode. Il permet d’affiner les
décisions pour sélectionner le code à tester en mettant dans la balance l’effort à fournir par rapport à la
pertinence de test.
Le détail du calcul de ces deux index est fourni en annexe (8.2 Le couplage).
Cette cartographie exploite les informations de couverture de code seulement si elles ont été fournies pour
l’analyse. Pour chaque niveau de priorité est indiqué :
Le taux de couverture moyen (0 si les informations de couverture n’ont pas été fournies)
Le nombre de méthodes non couvertes (aucune couverture)
6
CETIC, Kalistick. Statistically Calibrated Indexes for Unit Test Relevancy and Unit Test Writing Effort, 2010
Le tableau suivant détaille ces chiffres pour chaque niveau de priorité, en ajoutant également un cinquième
niveau correspondant aux méthodes sans priorité de test :
Une classe peut être de couleur verte même si elle n’est pas ou peu testée, par exemple
pour des classes avec une faible probabilité de défauts ou un risque fonctionnel réduit.
Inversement, une classe déjà bien testée peut être indiquée comme insuffisante (rouge/brun) si
son objectif est très exigeant.
Une stratégie efficace pour améliorer sa couverture consiste à se concentrer sur les classes
de taille importantes et proches de l’objectif.
La taille du nom de classe dépend de son intérêt à être testée (valeur de TRI cumulée pour toutes ses
méthodes)
La couleur représente l'écart par rapport à l'objectif de couverture fixé pour la classe, tout comme
pour le TreeMap précédent
Cette représentation permet d’identifier les éléments critiques, mais si l’on souhaite tenir
compte de l’effort d’écriture des tests il faut privilégier la représentation suivante pour
sélectionner les éléments à corriger.
5.4.6 Classes les plus importantes à tester et demandant le moins d’effort (Quick Wins)
Les « Quick Wins » complémente les « Top Risks » en tenant compte de l’effort de test à fournir pour tester
la classe (TEI) :
La taille du nom de classe dépend de son intérêt à être testée (TRI), mais pondéré par l’effort
nécessaire (TEI cumulé pour toutes ses méthodes) : une classe avec un fort TRI et un fort TEI (donc
difficile à tester) apparaît plus petite qu’une classe avec un TRI moyen mais un faible TEI
La couleur représente l'écart par rapport à l'objectif de couverture fixé pour la classe, tout comme
pour le TreeMap ou les QuickWins
5.5 Architecture
Le domaine Architecture vise à contrôler le respect d’un modèle d’architecture logicielle. Le modèle
d’architecture cible a été présenté dans le chapitre 4.3.2 Modèle technique. Le schéma suivant montre les
résultats de l’analyse des contraintes d’architecture en comparant ce modèle cible avec le code de
l’application.
Actuellement, les violations des contraintes d’architecture ne sont pas prises en compte
dans le calcul de la non-conformité de l’application.
5.6 Duplication
Le domaine Duplication concerne les « copier-coller » identifiés au sein de l’application. Pour éviter les
nombreux faux-positifs dans ce domaine, seuls sont remontés les blocs dupliqués impliquant un seuil
minimal d’instructions.
Les duplications sont à proscrire pour de multiples raisons : problèmes de maintenance et d’évolutivité, coûts
de tests, défaut de fiabilité, …
Les duplications sont catégorisées par intervalles d’instructions dupliquées. Pour chaque intervalle est
présenté :
Le nombre de blocs dupliqués différents (chacun étant dupliqué au moins une fois)
Le nombre maximal de duplications d’un même bloc
5.7 Documentation
Le domaine Documentation vise à contrôler le niveau de documentation technique du code. Seule la
présence des commentaires d’entêtes standards des méthodes est vérifiée : Javadoc pour Java, XmlDoc
pour C#. Les commentaires « inline » (dans le corps des méthodes) ne sont pas évalués en raison de la
difficulté à vérifier leur pertinence (souvent du code commenté ou des commentaires générés par l’IDE).
De plus, l’entête de documentation n’est vérifié que sur les méthodes considérées comme assez longues et
complexes. Car l’effort pour documenter des méthodes triviales est rarement justifié. Pour cela, un seuil sur
la complexité cyclomatique et un seuil sur le nombre d’instructions sont définis pour filtrer les méthodes à
vérifier.
6 Plan d’action
Pour chaque domaine, une préconisation des corrections a été établie sur la base de tableaux détaillant les
règles et les éléments de code à corriger. Le graphique suivant propose une approche globale pour établir un
plan de corrections en définissant une liste d’actions. Cette liste est priorisée selon le retour sur
investissement escompté : les actions préconisées en premier lieu sont celles qui présentent le meilleur
rapport entre l’effort à produire et le gain sur le taux de non-conformité global.
7
http://blog.kalistick.fr/2009/05/decomplexifiez-votre-code.html
Le plan d’action peut être affiné sur le Cockpit Qualité en utilisant le mécanisme des
« tags ». Les tags permettent d’étiqueter les résultats d’analyse pour faciliter des opérations
telles que la priorisation des corrections, leur affectation à des développeurs ou leur lotissement
selon les versions.
7 Glossaire
Axe de qualité
Les résultats d'analyses sont ventilés sur 6 axes de qualités selon les besoins de l'application en termes de
qualité :
if (value)
{
//
}
Ce code sera couvert par branches à 100% si la condition du if a été testée dans le cas vrai et faux.
Domaine de qualité
Les résultats d'analyses sont ventilés sur 4 domaines selon la nature des violations :
Instruction de code
Une instruction de code représente une unité de code primaire, proche de la ligne de code. Pour simplifier,
une instruction est délimitée par un point-virgule (;) ou pour par une accolade gauche ({). Exemples
d'instructions en Java :
int i = 0;
if (i == 0) {
} else {
public final class SomeClass
{
import com.project.SomeClass;
package com.project;
A la différence des lignes de code, les instructions ne comprennent pas les lignes blanches et les
commentaires. De plus, une ligne peut contenir plusieurs instructions.
Ligne de code
Une ligne physique d'un fichier de code. Peut concerner une ligne blanche, ou une ligne de commentaire.
Non-conformité
Un résultat d'analyse qui ne satisfait pas les exigences techniques fixées par le projet. Une non-conformité
concerne un axe de qualité et un domaine de qualité.
Synonyme(s) : violation
8 Annexes
Sa valeur élevée est signe qu’il sera difficile à comprendre, à tester, à valider, à maintenir et à faire évoluer.
8.1.1 Définition
On produit un graphe de contrôle qui représente le code dont on veut mesurer la complexité. Une fois ce
graphe de contrôle dessiné, on compte le nombre CC de faces de ce graphe. La complexité structurelle du
code (appelée aussi complexité cyclomatique) est mesurée par CC.
8.1.2 Exemple
On souhaite mesurer la complexité du code suivant :
int x = 3;
if (x > 0) {
x++;
} else {
x--;
8
: Le S.E.I. (Software Engineering Institute, http://www.sei.cmu.edu/) est l’institut à l’origine de la norme CMMI. Ses
recherches réputées sur la qualité de code en font un acteur majeur et fiable dans le domaine. CMMi : sigle de
Capability Maturity Model + Integration, est un modèle de référence, un ensemble structuré de bonnes pratiques,
destiné à appréhender, évaluer et améliorer les activités des entreprises d'ingénierie (source : Wikipedia).
8.2 Le couplage
Le couplage permet de mesurer le déficit en indépendance des classes ou des méthodes. Si le couplage entre
les classes est élevé, alors l’application est peu modulaire et sera difficile à faire évoluer.
8.2.1 Définition
Deux classes sont couplées si les méthodes déclarées dans l’une utilisent des méthodes ou instancient des
variables définies dans l’autre. La relation est symétrique : si la classe A est couplée à B, alors B est couplée à
A. La métrique CBO (Coupling Between Classes) mesure pour une classe A donnée, le nombre de classes qui
sont couplées à cette classe A.
Le couplage efférent mesure pour une méthode donnée, le nombre de références faites à des types tiers et à
leurs méthodes dans son code. Lorsque le couplage efférent est élevé, la méthode atteint un haut niveau de
dépendance vis-à-vis des autres classes de l’application.
Le calcul du couplage efférent pour une méthode peut par exemple s’effectuer en comptant :
Les paramètres formels (dans la signature de la méthode) ayant un type tiers non primitif
Les déclarations throws
Les variables locales de la méthode utilisant un type non primitif défini hors de la classe
8.3.1.1 Objectif
L'objectif du TRI est d’affiner l’analyse de la couverture de code effectuée par les tests en corrélant la notion
brute de couverture de code à celle de pertinence à tester d'une méthode. On ne s’intéresse plus seulement
au pourcentage de code couvert, mais aussi à la pertinence dans le choix des méthodes testées. L'intérêt est
de s'assurer que l'objectif de couverture de code à atteindre ciblera les bonnes méthodes.
En fonction de cette valeur de TRI, les méthodes sont classifiées en cinq groupes de priorité de test :
Il est ainsi possible de spécifier pour les éléments critiques un objectif de test exigeant, avec le traitement
des différents cas de fonctionnement, et pour les éléments moins prioritaires, des tests qui ciblent
uniquement les traitements nominaux.
9
CETIC, Kalistick. Statistically Calibrated Indexes for Unit Test Relevancy and Unit Test Writing Effort, 2010
Couplage efférent
Nombre de violations cumulées de la méthode
8.3.2.1 Objectif
Le TEI introduit une nouvelle dimension dans la priorisation des méthodes à tester, en fournissant une
estimation de l'effort nécessaire pour tester une méthode.
Cet index n'intervient pas dans la non-conformité des méthodes, il est simplement fourni à titre indicatif.
8.3.2.2 Principe
Le TEI est un index spécifique aux méthodes, dont la valeur est obtenue en scorant les valeurs d'un ensemble
de métriques unitaires (complexité cyclomatique, nombre de paramètres, ...). En fonction de cette valeur de
TEI, les méthodes sont classifiées en cinq groupes d'effort de test :
DontRaiseExceptionInUnexpectedMe Certaines méthodes ne doivent pas jeter d'exceptions car elles Interdit
thod_ doivent effectuer des opérations simples et aboutir soit à
une valeur de retour, soit à la fin d'une opération.
DontThrowExceptionsInFinallyBlock Il ne faut pas lancer d'exception dans une clause Interdit
<code>finally</code>.
DontUseInadvisableTypes Depuis la version 2.0 du framework .NET, il est recommandé de Interdit
ne plus dériver certains types.
DontUseObjectTypeForIndexers Il faut utiliser des types entier ou string comme index pour les Interdit
indexeurs. L'utilisation d'un type Objet est à proscrire.
DontUseTooManyParametersOnGen Le nombre de paramètres génériques pour un type générique Interdit
erics_ visible de l'extérieur est limité à 2.
DontUseWin32ApiWhenManagedApi Il est préférable d?utiliser la version managée d?une méthode à la Interdit
Exist place de la version non managée lorsqu?elle est disponible.
FollowISerializableImplementationRu L'implémentation de Interdit
le <code>System.Runtime.Serialization.ISerializable</code> doit
suivre un pattern de conception afin de respecter les standards.
En effet, les champs d'instance d'un type sérialisable
doivent être intégrés au processus de sérialisation.
ISerializableTypesMustCallBaseClas Un type dérivant un type implémentant Interdit
sMethods <code>ISerializable</code> doit invoquer le traitement parent.
ImplementIDisposableForTypesWith Un type qui déclare et implémente des champs de type Interdit
DisposableFields <code>System.IDisposable</code> doit implémenter
<code>System.IDisposable</code> afin de supprimer ses
ressources non managées.
InstantiateExceptionsWithArguments Il est recommandé d'instancier les exceptions en fournissant les Interdit
paramètres adéquates pour préciser le contexte de l'exception.
OverrideEqualsWithOperatorOnValu Un type valeur doit implémenter la méthode Interdit
eTypes <code>System.Object.Equals(Object)</code>.
PInvokesMustNotBeVisible Une méthode marquée avec l'attribut Interdit
<code>System.Runtime.InteropServices.DllImportAttribute</code
> ne doit pas être visible en dehors de l'assembly.
PropertyNamesMustNotMatchGetMe Une méthode ne doit pas être nommée à partir du nom d'une Interdit
thods propriété.
TypeLinkDemandsRequireInheritanc Un type public non scellé ou une méthode virtuelle ayant une Interdit
eDemands
demande de liaison doivent avoir une demande d'héritage
sur la même autorisation.
TypeWithNativeResourcesMustBeDi Un type possèdant des champs <code>IntPtr</code>, Interdit
sposable <code>UIntPtr</code> et <code>HandleRef</code> doit
implémenter <code>System.IDisposable</code>.
UseConstInsteadOfReadOnlyWhenP Un champ déclaré en <code>static</code> et Interdit
ossible_ <code>readonly</code> dont la valeur initiale peut être
calculée à la compilation, doit utiliser <code>const</code>
au lieu de <code>static readonly</code>.
UseIsNanFunction Il ne faut pas comparer avec les valeurs Interdit
<code>Double.NaN</code> ou <code>Single.NaN</Code>.
UseIsNullOrEmptyToCheckEmptyStri Comparer une chaîne à la chaîne vide n'est pas optimal. Interdit
ngs
UseMarshalAsForBooleanPInvokeAr Il faut utiliser l'attribut Interdit
guments_ <code>System.Runtime.InteropServices.MarshalAsAttribute
</code> pour permettre la bonne conversion entre un
booléen non managé et un booléen managé.
UseStaticWhenPossible Une méthode qui n'accède pas aux données d'instance peut être Déconseillé
déclarée comme statique.
ConsiderUsingProperty Utiliser les propriétés lorsque cela est possible afin de respecter A éviter
les standards .NET.
DontCompareBooleanWithTrueOrFal Il est inutile de comparer explicitement un booléen avec A éviter
se <code>true</code> ou <code>false</code> dans une
expression conditionnelle.
DontDefinePublicGenericLists Il est préférable d'utiliser un type dérivé de A éviter
<code>System.Collections.Generic.List<T></code>.
DontDirectlyReturnArray Une propriété ne devrait par retourner de tableau. En effet, les A éviter
tableaux retournés par les propriétés sont passés par référence,
ils ne sont donc pas protégés en écriture, même si la
propriété est en lecture seule.
DontImplementConstructorForStaticT Il est inutile d'implémenter un constructeur public pour un type A éviter
ypes qui ne déclare que des membres statiques.
DontMakeRedundantInitialization_ Il est inutile d'initialiser un champ avec sa valeur par défaut. A éviter
DontMakeTypeFieldsPublic Un champ ne doit pas être déclaré avec une visibilité publique, A éviter
sauf s'il est statique, constant ou déclaré dans un type
imbriqué privé ou interne.
DontPrefixEnumValuesWithEnumNa Il n'est pas nécessaire de préfixer les champs d'une énumération A éviter
me avec le mot <code>Enum</code> pour indiquer que ce sont
des champs d'énumération.
DontUseReservedKeywordForEnum Il faut rajouter un nouveau champ à la fin d'une énumération si A éviter
l'on souhaite la modifier de façon non impactante, et non pas
utiliser le mot-clé <code>reserved</code>.
DontUseTypeNamesForNamespaces Le nom d'un type ne doit pas correspondre au nom d'un A éviter
namespace défini dans votre projet ou dans le framework .NET.
FlagsEnumsMustHavePluralNames Une énumération marquée par A éviter
<code>System.FlagsAttribute</code> doit posséder un nom
conjugué au pluriel.
IdentifiersMustNotContainTypeName Les identificateurs des paramètres d'un membre doivent A éviter
s véhiculer leur signification et non décrire leur type, qui devrait
être fourni par les outils de développement.
ImplementNamedMethodsWhenOver Lorsque l?on surcharge un opérateur, il faut prévoir A éviter
loadingOperators d?implémenter une méthode alternative correspondante, par
exemple fournir la méthode <code>Add</code> lorsque
l?on surcharge l?opérateur <code>+</code>.
InitializeStaticFieldsInline Il est préférable d?initialiser les variables statiques là où elles A éviter
sont déclarées (inline) et éviter d?utiliser des constructeurs
statiques.
OnlyFlagsEnumsMustHavePluralNa Une énumération ne possédant pas l?attribut A éviter
mes <code>System.FlagsAttribute</code> ne peut avoir qu?une
seule valeur à la fois, son identificateur doit donc être
conjugué au singulier.
PassBaseTypeAsParameters Les types des paramètres doivent être les plus génériques A éviter
possibles.
RemoveUnusedInternalClasses Un type interne jamais utilisé dans l'assembly doit être supprimé. A éviter
RemoveUnusedParameters Un paramètre de méthode qui n'est pas utilisé doit être A éviter
supprimé.
RemoveUnusedPrivateFields Un champ privé qui n'est pas utilisé dans le type doit être A éviter
supprimée.
RemoveUnusedPrivateMethods Une méthode privée qui n'est pas utilisée dans le type doit être A éviter
supprimée. De même, une méthode interne non utilisée dans
l'assembly doit être supprimée.
ReviewUnusedLocals Une variable locale qui n'est pas utilisée doit être A éviter
supprimée.
SealAttributesDeclarations Il est conseillé de sceller l'implémentation d'un nouvel attribut. A éviter
DisposeDisposableFields_ Tous les champs <em>disposables</em> (héritant de [Aucune]
<code>System.IDisposable</code>) doivent être disposés
dans la méthode
<code>System.IDisposable.Dispose()</code> de ce type.