Analyse de code: accélérez la validation de vos applications C#

Ce document est un exemple de rapport d’audit produit automatiquement

à partir des résultats de l’analyse de l’application sur la plateforme Kalistick.

Il n’intègre pas de commentaires spécifiques sur les résultats obtenus.

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.

Ce document est confidentiel, il est la propriété de Kalistick,

Il ne doit pas être diffusé ni modifié sans autorisation.

Kalistick 13 av Albert Einstein F-69100 Villeurbanne +33(0) 486 68 89 42

[email protected]

www.kalistick.com

DEMO Application SHARPDEVELOP

Rapport d’audit

01/01/2011

mailto:[email protected]

http://www.kalistick.com/

Audit de code de l’application SharpDevelop 01/01/2011

Confidentiel - Ce document est la propriété de Kalistick 2/61

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.

Synthèse - Ecart par rapport à l’objectif

Ce graphique compare la situation actuelle du projet par rapport aux objectifs fixés sur chacun des axes de qualité. L’objectif, configuré à l’initialisation de l’audit, représente l’importance de chaque axe de qualité. Il est destiné à déterminer les règles à respecter dans les développements et la tolérance acceptée.

Taux de non-conformité global

Cette jauge indique le niveau de qualité global de l’application par rapport à son objectif qualité. Elle présente le pourcentage de l’application (code) considéré comme non-conforme. Selon la configuration réalisée, un taux supérieur à 15% indique la nécessité d’approfondir l’analyse des résultats.

Origine des violations

Ce graphique identifie l’origine technique des non-conformités détectées, et les principaux domaines d’amélioration. Selon les éléments soumis lors de l’analyse, certains domaines peuvent ne pas avoir été évalués.



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.

1 Executive Summary ...................................................................................................................................... 2

2 Introduction .................................................................................................................................................. 4

2.1 Le Cockpit Qualité ................................................................................................................................. 4

2.2 La grille d’analyse ................................................................................................................................. 4

3 Objectif qualité ............................................................................................................................................. 7

3.1 Le profil qualité ..................................................................................................................................... 7

3.2 Les exigences techniques ..................................................................................................................... 7

4 Synthèse des résultats ................................................................................................................................ 10

4.1 Situation du projet.............................................................................................................................. 10

4.2 Benchmarking ..................................................................................................................................... 13

4.3 Modélisation de l’application ............................................................................................................. 17

5 Résultats détaillés ....................................................................................................................................... 20

5.1 Détail par axes de qualité ................................................................................................................... 20

5.2 Implémentation .................................................................................................................................. 21

5.3 Structure ............................................................................................................................................. 26

5.4 Test ..................................................................................................................................................... 35

5.5 Architecture ........................................................................................................................................ 42

5.6 Duplication ......................................................................................................................................... 43

5.7 Documentation ................................................................................................................................... 44

6 Plan d’action ............................................................................................................................................... 47

7 Glossaire ..................................................................................................................................................... 49

8 Annexes ...................................................................................................................................................... 51

8.1 La complexité cyclomatique ............................................................................................................... 51

8.2 Le couplage ......................................................................................................................................... 53

8.3 Le TRI et TEI ........................................................................................................................................ 54

8.4 Exigences techniques ......................................................................................................................... 56



2 Introduction

2.1 Le Cockpit Qualité Cet audit est basé sur un processus d’analyse de code industrialisé. Cette industrialisation permet de garantir

des résultats fiables et facilement comparables avec les résultats d’autres audits.

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.

2.2 La grille d’analyse L’analyse porte sur le code Java (JEE) ou C# (.Net) de l’application (code source et code binaire). C’est une

analyse statique (sans exécution), complétée par la corrélation avec des informations extraites des outils de

développement déjà mis en œuvre pour le projet : gestionnaires de versions, frameworks de tests unitaires,

outils de couverture de code.

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)

https://cockpit.kalistick.com/



2.2.1 Les axes de qualité

Les axes de qualité standardisent un ensemble de qualités auxquelles doit prétendre l’application selon la

norme ISO 912623 :

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.

Sécurité. Aptitude du logiciel à fonctionner en respectant les contraintes d’intégrité, de

confidentialité et de traçabilité requises.

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.

Efficacité. Relation entre le niveau de performance du logiciel et la quantité de ressources

nécessaires pour le faire fonctionner dans des conditions nominales.

2.2.2 Les domaines de qualité

Les domaines de qualité déterminent la nature des problèmes selon leur origine technique. Ils sont au

nombre de six :

Implémentation. Les problèmes inhérents au codage : mauvaise utilisation du langage, bugs

potentiels, code difficilement compréhensible, … Ces problèmes peuvent nuire à un ou plusieurs des

six axes de qualités.

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.

http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=22749



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.

Architecture. Problèmes liés à l’architecture logicielle de l’application. Il est possible de définir un

modèle d’architecture pour modulariser l’application en couches ou composants puis de définir des

contraintes d’appel entre ces éléments. L’analyse identifie au sein du code tous les appels ne

respectant pas ces contraintes, pour détecter les risques au niveau de la maintenabilité, de

l’évolutivité et de la sécurité.

Documentation. Problèmes liés au manque de documentation dans le code. Ce domaine impacte

essentiellement la transférabilité du code.

Duplication. Identification de tous les copier-collers importants au sein de l’application. Ceux-ci

présentent des risques sur les axes fiabilité, maintenabilité, transférabilité et évolutivité.

2.2.3 Les niveaux de sévérité

Les niveaux de sévérité sont destinés à caractériser la priorité de correction d’une non-conformité. Cette

priorité dépend de la gravité de l’impact d’une non-conformité, mais également de l’effort à fournir pour la

correction : certains problèmes moyennement critiques seront marqués avec un niveau de sévérité

important en raison de la trivialité de leur résolution.

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.

3.1 Le profil qualité Pour cet audit, le profil qualité établi est le suivant :

Voir sur le Cockpit Qualité

3.2 Les exigences techniques En se basant sur le profil qualité précédent, les exigences techniques ont été sélectionnées à partir de la base

de connaissances du « Cockpit Qualité ». Ces exigences techniques couvrent les six domaines de qualités

(implémentation, structure, test, architecture, documentation, duplication) et sont configurées en fonction

du profil qualité (seuils, niveaux de sévérité, …). L’objectif est d’assurer un calibrage des exigences qui assure

le meilleur retour sur investissement.

https://cockpit.kalistick.com/authsec/cockpit/pages/objective/qualityprofile



Voici le détail de ces exigences techniques :

Domaine Règle Explication, objectif et seuils éventuels Im

plé

me

nta

tio

n - Selon votre profil, entre 150 et 200 règles ont été sélectionnées. Elles sont

présentées exhaustivement en annexe du rapport (8.4.1 Règles d’implémentation). Objectif : éviter les mauvaises pratiques et appliquer les bonnes pratiques liées aux technologies utilisées.

Stru

ctu

re

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 : éviter les blocs de traitements difficilement compréhensibles. Le seuil retenu pour le projet est :

nombre de lignes : 100

Complexité des méthodes

Complexité cyclomatique d'une méthode. Elle mesure la complexité algorithmique d'une méthode en comptant le nombre de chemins indépendants couvrant tous les cas possibles. Plus ce nombre est élevé, plus le code est difficile à maintenir et à tester. Objectif : éviter les blocs de traitements difficilement compréhensibles, non testables et qui tendent à avoir un taux de dysfonctionnement important. Le seuil retenu pour le projet est :

complexité cyclomatique : 20

Complexité et couplage des méthodes

Identifie les méthodes difficiles à comprendre, à tester et à maintenir en raison d'une complexité moyenne (complexité cyclomatique) et à de nombreuses références à des types tiers (couplage efférent) Objectif : éviter les blocs de traitements difficilement compréhensibles et non testables. Les seuils retenus pour le projet sont :


couplage efférent : 20



Test

Couverture de test des méthodes

Taux de couverture de code d'une méthode. Cette métrique est standardisée par notre plateforme à partir des mesures brutes de couverture de code quand elles sont fournies au sein de l'archive du projet. Cette exigence associe un seuil minimal de test (couverture de code) à chaque méthode de l'application selon le TRI (TestRelevancyIndex) ; le TRI évalue pour chaque méthode le risque qu'elle contienne des bugs. Son calcul tient compte des risques métiers définis pour l'application. 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. Le détail des seuils est fourni en annexe du rapport (8.4.2 Seuils de couverture de code).

Arc

hit

ect

ure

Règles définies spécifiquement pour le modèle d’architecture de l’application.

Voir le modèle d’architecture éventuellement défini pour découvrir les contraintes d’architecture en cours. 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. NB : les violations d’architecture ne sont pas prises en compte dans le calcul de la non-conformité.

Do

cum

en

tati

on

Entête de documentation des méthodes

Identifie les méthodes de complexité moyenne qui ne disposent pas d'entête de documentation. Les méthodes prises en compte sont celles dont la complexité cyclomatique et le nombre d'instructions excèdent des seuils définis spécifiquement pour le projet. Objectif : s’assurer que la documentation est présente sur les blocs de traitements clés en vue de faciliter les éventuels changements d’équipe (transférabilité). Les seuils retenus pour le projet sont :


nombre de lignes : 50

Du

plic

atio

n Détection des

duplications

Les duplications sont invalidées au-delà de 20 instructions 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.

Domaine Règle Explication, objectif et seuils éventuels



4 Synthèse des résultats Ce chapitre synthétise la situation du projet à l’aide d’indicateurs globaux. Ceux-ci mesurent la qualité

intrinsèque du projet, mais comparent également sa situation à celle des autres projets de la base de

référence du « Cockpit Qualité ».

4.1 Situation du projet Les indicateurs suivants concernent la situation intrinsèque du projet.

4.1.1 Taux de non-conformité global

Le taux de non-conformité mesure la proportion du code de l’application considéré comme non-conforme.


Plus précisément, ce chiffre résulte du rapport entre le nombre total d’instructions, et le

nombre d’instructions des classes non-conformes. Une classe est considérée comme non

conforme si au moins un des cas suivants est rencontré :

- Une non-conformité de sévérité interdite est détectée dans la classe

- Un ensemble de non-conformités fortement déconseillées, déconseillées, ou à éviter sont

détectées dans la classe et dépassent un certain seuil. Ce calcul dépend de la sévérité de chaque

non-conformité ainsi que du profil qualité qui ajuste le seuil de tolérance.

https://cockpit.kalistick.com/authsec/cockpit/pages/dashboards/synthesis



4.1.2 Ecart par rapport à l’objectif

Ce graphique résume l’écart entre l’objectif visé tel que représenté par le profil qualité et la situation actuelle

du projet. Cet écart est présenté pour chacun des axes de qualité :


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é.

Axe de qualité Classes Violations impactantes % application

Efficacité 159 283 42%

Evolutivité 429 1794 84%

Fiabilité 425 1925 84%

Maintenabilité 54 339 18%

Sécurité 0 0 0%

Transférabilité 51 180 25%

[Total] 480 2286 87%

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.

https://cockpit.kalistick.com/authsec/cockpit/pages/objective/qualityprofile



4.1.3 Origine des non-conformités

Le graphique suivant montre la répartition des non-conformités selon leur origine technique :


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 :

Métrique Valeur Tendance

Nombre de lignes 70895 +0,14%

Nombre d'instructions 48877 +0,15%

Nombre de méthodes 7568 +0,36%

Nombre de classes 975 +0,21%

Nombre de packages 48 =


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 ({).

https://cockpit.kalistick.com/authsec/cockpit/pages/dashboards/synthesis/origin

https://cockpit.kalistick.com/authsec/cockpit/pages/dashboards/synthesis/volumetry



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.

4.2.1 Comparaison sur les problèmes d’implémentation

Le graphique suivant présente la situation du projet dans le domaine implémentation par rapport aux projets

« extra-Cockpit », donc analysés ponctuellement sur la plateforme. Pour chaque niveau de sévérité, le niveau

de qualité du projet est positionné par rapport aux autres :


https://cockpit.kalistick.com/authsec/cockpit/pages/labs/benchmarking/implementation



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.

https://cockpit.kalistick.com/authsec/cockpit/pages/labs/benchmarking/implementation



4.2.2 Cartographie de la structure

Le graphique suivant compare la cartographie de la taille des méthodes du projet avec celle des autres

projets, « intra-Cockpit » et « extra-Cockpit », en comparant la proportion de l’application (en pourcentage

d’instructions) qui est située dans des blocs de traitement (méthodes) avec un nombre d’instructions élevé :


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 ».

https://cockpit.kalistick.com/authsec/cockpit/pages/labs/benchmarking/structure



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.2.3 Comparaison des principales métriques

Le tableau suivant compare le projet avec les autres projets, « intra-Cockpit » et « extra-Cockpit », sur les

principales métriques liées à la structure du code. Les intervalles de valeurs recommandées sont fournis à

titre d’information.

Métrique Project Extra-Cockpit Intra-Cockpit Intervalle recommandé

Classes par package 20,31 10,48 10,9 6 - 26

Méthodes par classe 7,76 7,78 7,58 4 - 10

Lignes de code par méthode 6,46 12,76 10,85 7 - 13

Complexité par ligne de code 0,31 0,22 0,15 0.16 - 0.24


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



http://classes.cecs.ucf.edu/eel6883/berrios/notes/Paper%204%20(Complexity%20Measure).pdf



4.3 Modélisation de l’application Pour faciliter la restitution des résultats d’analyse, l’application est modélisée sous deux angles: un angle

fonctionnel pour mieux identifier les fonctionnalités métier de l’application et les rattacher au code, et un

angle technique pour vérifier l’architecture technique de l’application.

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).

4.3.1 Modèle fonctionnel

Le modèle fonctionnelle représente la vue métier de l’application, compréhensible par l’ensemble des

acteurs du projet.


Le modèle fonctionnel est constitué de « modules » qui représente chacun une

fonctionnalité métier, ou un groupe de fonctionnalité. Ces modules ont été identifiés à partir d’un

corpus lexical généré à partir du code de l’application et qui permet d’isoler le vocabulaire métier

de l’application.

https://cockpit.kalistick.com/authsec/cockpit/pages/objective/design/organization

https://cockpit.kalistick.com/authsec/cockpit/pages/objective/technical/architecture

https://cockpit.kalistick.com/authsec/cockpit/pages/objective/design/organization



4.3.2 Modèle technique

Le modèle technique représente l’architecture du code de l’application. Le principe consiste à définir un

modèle d’architecture cible, qui identifie des couches et/ou des composants techniques au sein de

l’application, puis établit des contraintes pour autoriser ou interdire les communications entre chacun de ces

éléments.

L’objectif est triple :

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.

https://cockpit.kalistick.com/authsec/cockpit/pages/objective/technical/architecture



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.

5.1 Détail par axes de qualité L’histogramme suivant complète l’analyse synthétique en détaillant le taux de non-conformité ainsi que le

nombre de classes non-conformes pour chaque axe de qualité. Pour rappel, le taux de non-conformité est

basé sur le volume d’instructions des classes non-conformes par rapport au volume d’instructions global du

projet.

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.

https://cockpit.kalistick.com/authsec/cockpit/pages/dashboards/details



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 ».

5.2.1 Répartition par sévérité

L’objectif de cet indicateur est d’identifier la sévérité des pratiques qui ont provoqué l’invalidation des

classes. On restreint ici les niveaux de sévérité à deux niveaux : les pratiques interdites (niveau de sévérité

Interdit) et les pratiques déconseillées (niveaux de sévérité Fortement déconseillé, Déconseillé et A éviter).

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 »


https://cockpit.kalistick.com/authsec/cockpit/pages/dashboards/details/implementation



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.

Sévérité Violations impactantes

Nouvelles violations

Violations corrigées

Autres violations

Interdit 382 5 0 0

Fortement déconseillé 176 1 0 55

Déconseillé 81 5 2 336

A éviter 202 1 1 340

Les colonnes « Nouvelles violations » et « Violations corrigées » ne sont pertinentes que

dans le cas où l’audit fait suite à un audit précédent.



5.2.2 Pratiques à corriger en priorité

Les deux tableaux suivants fournissent la liste des pratiques interdites et fortement déconseillées détectées

dans l’application. Ce sont généralement les règles à corriger en priorité.

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.

5.2.2.1 Pratiques interdites

Pratique Nouvelles Violations Classes NC

% application

AvoidRedundantCasts 1 124 83 29%

ImplementIDisposableForTypesWithDisposableFields 0 103 64 13%

DontHardcodeLocaleSpecificStrings 2 81 56 14%

UseConstInsteadOfReadOnlyWhenPossible_ 0 33 10 4%

UseIsNullOrEmptyToCheckEmptyStrings 0 12 9 4%

OverrideEqualsWithOperatorOnValueTypes 0 11 11 4%

PropertyNamesMustNotMatchGetMethods 0 6 5 1%

InstantiateExceptionsWithArguments 0 5 4 2%

DontImplementWriteOnlyProperty 0 3 3 1%

DefineMessageForObsoleteAttribute 2 2 2 1%

DontUseInadvisableTypes 0 1 1 1%

DontRaiseExceptionInUnexpectedMethod_ 0 1 1 1%


https://cockpit.kalistick.com/authsec/cockpit/pages/dashboards/details/implementation/forbidden



5.2.2.2 Pratiques fortement déconseillées

Pratique Nouvelles Violations Classes NC

% application

NeverMakeCtorCallOverridableMethod 0 185 48 10%

DontUseNonConstantStaticVisibleFields 1 26 11 3%

OverrideMethodsInIComparableImplementations 0 9 6 2%

DefineAttributeForISerializableTypes 0 7 5 3%

DontNestGenericInMemberSignatures_ 0 3 2 2%

DontIgnoreMethodsReturnValue 0 1 1 1%


5.2.3 Classes à corriger en priorité sur les problèmes d’implémentation

Les deux tableaux suivants fournissent une vision complémentaire concernant l’impact des problèmes

d’implémentation en détaillant la liste des principales classes concernées par des pratiques interdites ou

fortement déconseillées.

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.

https://cockpit.kalistick.com/authsec/cockpit/pages/dashboards/details/implementation/disadvised1



5.2.3.1 Classes avec des pratiques interdites

Classe NC Nouvelles Violations Instructions

ICSharpCode.SharpDevelop.Dom.NRefactoryResolver.NRefactoryResolver

Oui 0 10 647

ICSharpCode.SharpDevelop.Dom.VBNet.VBExpressionFinder Oui 0 10 319

ICSharpCode.SharpDevelop.Dom.CSharp.CSharpExpressionFinder

Oui 0 10 600

ICSharpCode.SharpDevelop.DefaultEditor.Gui.Editor.SharpDevelopTextAreaControl

Oui 0 9 255

ICSharpCode.SharpDevelop.Gui.DefaultWorkbench Oui 0 8 387

ICSharpCode.SharpDevelop.Project.ConfigurationGuiHelper Oui 1 8 0

ICSharpCode.SharpDevelop.Widgets.TreeGrid.DynamicListItem

Oui 0 8 211

ICSharpCode.SharpDevelop.ParserService Oui 0 7 489

ICSharpCode.SharpDevelop.Gui.SdiWorkbenchLayout Oui 0 7 360

ICSharpCode.SharpDevelop.Dom.DomPersistence Oui 0 6 567

ICSharpCode.Core.MenuService Oui 0 6 78

ICSharpCode.SharpDevelop.Dom.DefaultProjectContent Oui 0 5 554

ICSharpCode.SharpDevelop.Gui.XmlForms.XmlLoader Oui 0 5 200

ICSharpCode.SharpDevelop.Refactoring.RefactoringService Oui 0 5 312

ICSharpCode.SharpDevelop.Project.ProjectService Oui 0 5 355

ICSharpCode.SharpDevelop.Project.MSBuildEngine Oui 0 5 337

ICSharpCode.SharpDevelop.Gui.FontSelectionPanelHelper Oui 0 5 101

ICSharpCode.SharpDevelop.Project.Commands.AddExistingItemsToProject

Oui 0 4 168

ICSharpCode.SharpDevelop.Debugging.DebuggerService Oui 0 4 288


https://cockpit.kalistick.com/authsec/cockpit/pages/dashboards/details/implementation/forbidden



5.2.3.2 Classes avec des pratiques fortement déconseillées

Classe NC Nouvelles Violations Instructions

ICSharpCode.SharpDevelop.Gui.ExtTreeNode Oui 0 69 248

ICSharpCode.SharpDevelop.Gui.ClassBrowser.MemberNode Oui 0 12 72

ICSharpCode.SharpDevelop.Gui.XmlForms.XmlForm Oui 0 12 22

ICSharpCode.SharpDevelop.Dom.HostCallback Oui 1 9 19

ICSharpCode.SharpDevelop.Dom.ReflectionLayer.ReflectionClass Oui 0 8 102

ICSharpCode.SharpDevelop.Dom.ExpressionContext Oui 0 6 142

ICSharpCode.SharpDevelop.Dom.ReflectionLayer.ReflectionMethod Oui 0 5 41

ICSharpCode.SharpDevelop.Project.Dialogs.NewProjectDialog Oui 0 4 274

ICSharpCode.SharpDevelop.Project.FileNode Oui 0 4 155

ICSharpCode.SharpDevelop.Gui.NewFileDialog Oui 0 3 378

ICSharpCode.SharpDevelop.Project.ProjectNode Oui 0 3 114

ICSharpCode.SharpDevelop.Dom.DefaultEvent Oui 0 3 43

ICSharpCode.SharpDevelop.Dom.ReflectionLayer.ReflectionParameter

Oui 0 3 14

ICSharpCode.SharpDevelop.Dom.DefaultProperty Oui 0 3 62

ICSharpCode.SharpDevelop.Dom.DefaultMethod Oui 0 3 84

ICSharpCode.SharpDevelop.Dom.DefaultProjectContent Oui 0 2 554

ICSharpCode.SharpDevelop.Internal.Templates.FileTemplate Oui 0 2 124

ICSharpCode.SharpDevelop.Dom.DefaultParameter Oui 0 2 76

ICSharpCode.Core.MenuCommand Oui 0 2 85


5.3 Structure Le domaine Structure cible les règles se rapportant à la structuration du code, par exemple :

La taille des méthodes

La complexité cyclomatique des méthodes

Le couplage, ou la dépendance des méthodes par rapport aux classes extérieures

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.

https://cockpit.kalistick.com/authsec/cockpit/pages/dashboards/details/implementation/disadvised1



5.3.1 Typologie des problèmes de structure

Cet histogramme montre pour chaque règle de structure le nombre de non-conformités (donc de méthodes)

ainsi que le pourcentage du volume d’instructions concernées par rapport au volume global de l’application :


Le pourcentage d’instructions représenté est intéressant dans la mesure où on constate

souvent qu’un petit nombre de méthodes concentrent une grosse partie du code de l’application.

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.

Une méthode peut-être concernée par plusieurs règles, en conséquence le total ne

correspond pas à la somme des chiffres.

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é :

https://cockpit.kalistick.com/authsec/cockpit/pages/dashboards/details/structure



Anomalie Violations

impactantes

Nouvelles violations

Violations corrigées

NC

Complexité cyclomatique supérieure à 20 41 1 0 5%


5.3.2 Cartographie des méthodes par taille

L’histogramme suivant présente une cartographie des méthodes de l’application selon leur taille. La taille est

exprimée en nombre d’instructions pour faire abstraction du format d’écriture (conventions de styles

appliquées sur le projet).

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 :

https://cockpit.kalistick.com/authsec/cockpit/pages/dashboards/details/structure

https://cockpit.kalistick.com/authsec/cockpit/pages/dashboards/details/structure/size



Méthode Instructions Lignes Complexité Nouvelle violation

5.3.3 Cartographie des méthodes par complexité

L’histogramme suivant présente une cartographie des méthodes de l’application selon leur complexité

cyclomatique (cf 8.1 La complexité cyclomatique).

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.

https://cockpit.kalistick.com/authsec/cockpit/pages/dashboards/details/structure/complexity

http://classes.cecs.ucf.edu/eel6883/berrios/notes/Paper%204%20%28Complexity%20Measure%29.pdf



Méthode Instructions Lignes Complexité Nouvelle violation

ICSharpCode.SharpDevelop.Dom.ReflectionLayer.ReflectionClass.InitMembers ( System.Type)

21 36 21 Nouvelle

ICSharpCode.SharpDevelop.Dom.MemberLookupHelper.ConversionExists ( ICSharpCode.SharpDevelop.Dom.IReturnType, ICSharpCode.SharpDevelop.Dom.IReturnType)

53 77 83

ICSharpCode.SharpDevelop.Dom.CSharp.CSharpExpression

Finder.SearchBracketForward ( System.String, System.Int32, System.Char, System.Char)

57 78 47

ICSharpCode.SharpDevelop.Dom.VBNet.VBNetAmbience.Convert ( ICSharpCode.SharpDevelop.Dom.IClass)

81 128 44

ICSharpCode.SharpDevelop.Dom.CSharp.CSharpAmbience.Convert ( ICSharpCode.SharpDevelop.Dom.IClass)

77 118 41

ICSharpCode.SharpDevelop.Dom.NRefactoryResolver.NRefactoryResolver.ResolveInternal ( ICSharpCode.NRefactory.Ast.Expression, ICSharpCode.SharpDevelop.Dom.ExpressionContext)

71 100 34

ICSharpCode.SharpDevelop.Widgets.SideBar.SideBarControl.ProcessCmdKey ( ref System.Windows.Forms.Message,

System.Windows.Forms.Keys)

81 97 32

ICSharpCode.SharpDevelop.Dom.MemberLookupHelper.GetBetterPrimitiveConversion (

ICSharpCode.SharpDevelop.Dom.IReturnType, ICSharpCode.SharpDevelop.Dom.IReturnType)

20 22 31

ICSharpCode.SharpDevelop.Dom.NRefactoryResolver.TypeVisitor.CreateReturnType ( ICSharpCode.NRefactory.Ast.TypeReference, ICSharpCode.SharpDevelop.Dom.IClass,

ICSharpCode.SharpDevelop.Dom.IMember, System.Int32, System.Int32, ICSharpCode.SharpDevelop.Dom.IProjectContent, System.Boolean)

53 73 31

ICSharpCode.SharpDevelop.Dom.CecilReader.CecilClass.InitMembers ( Mono.Cecil.TypeDefinition)

57 83 30

ICSharpCode.SharpDevelop.DefaultEditor.Gui.Editor.MethodInsightDataProvider.SetupDataProvider ( System.String, ICSharpCode.TextEditor.Document.IDocument,

ICSharpCode.SharpDevelop.Dom.ExpressionResult, System.Int32, System.Int32)

42 59 29

ICSharpCode.SharpDevelop.Refactoring.RefactoringService.AddReferences (

System.Collections.Generic.List<ICSharpCode.SharpDevelop.Refactoring.Reference>, ICSharpCode.SharpDevelop.Dom.IClass, ICSharpCode.SharpDevelop.Dom.IMember, System.Boolean, System.String, System.String)

55 89 29

ICSharpCode.SharpDevelop.Project.DirectoryNode.Initialize ( )

81 121 29

ICSharpCode.SharpDevelop.Project.MSBuildBasedProject.S

etPropertyInternal ( System.String, System.String, System.String, System.String, ICSharpCode.SharpDevelop.Project.PropertyStorageLocations, System.Boolean)

92 140 28



ICSharpCode.SharpDevelop.Dom.NRefactoryResolver.NRefactoryResolver.ResolveIdentifierInternal ( System.String)

53 81 28

ICSharpCode.SharpDevelop.Commands.ToolMenuBuilder.ToolEvt ( System.Object, System.EventArgs)

54 74 26

ICSharpCode.SharpDevelop.Dom.MemberLookupHelper.GetBetterFunctionMember (

ICSharpCode.SharpDevelop.Dom.IReturnType[], ICSharpCode.SharpDevelop.Dom.IMethodOrProperty, ICSharpCode.SharpDevelop.Dom.IReturnType[], System.Boolean, ICSharpCode.SharpDevelop.Dom.IMethodOrProperty, ICSharpCode.SharpDevelop.Dom.IReturnType[], System.Boolean)

32 51 26

ICSharpCode.SharpDevelop.Dom.CSharp.CSharpExpressionFinder.FindFullExpression ( System.String, System.Int32)

51 68 26

ICSharpCode.SharpDevelop.Dom.CSharp.CSharpExpressionFinder.ReadNextToken ( )

58 76 25

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.

https://cockpit.kalistick.com/authsec/cockpit/pages/dashboards/details/structure/coupling



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é :


Le tableau suivant détaille les principales méthodes non-conformes :




Méthode Couplage efférent

Complexité Nouvelle violation

ICSharpCode.SharpDevelop.Refactoring.RefactoringMenuBuilder.BuildSubmenu ( ICSharpCode.Core.Codon, System.Object)

45 22

ICSharpCode.SharpDevelop.Project.Commands.AddExistingItemsToProject.Run ( )

39 22

ICSharpCode.SharpDevelop.Dom.CecilReader.CecilClass.InitMembers ( Mono.Cecil.TypeDefinition)

36 30

ICSharpCode.SharpDevelop.Gui.NewFileDialog.OpenEvent ( System.Object, System.EventArgs)

35 17


32 26


31 34

ICSharpCode.SharpDevelop.DefaultEditor.Gui.Editor.MethodInsightDataProvider.SetupDataProvider ( System.String,

ICSharpCode.TextEditor.Document.IDocument, ICSharpCode.SharpDevelop.Dom.ExpressionResult, System.Int32, System.Int32)

30 29

ICSharpCode.SharpDevelop.Dom.NRefactoryResolver.NRefactoryResolver.CtrlSpace ( System.Int32, System.Int32, System.String,

System.String, ICSharpCode.SharpDevelop.Dom.ExpressionContext)

30 18 Nouvelle

ICSharpCode.SharpDevelop.DefaultEditor.Commands.ClassBookmarkMenuBuilder.BuildSubmenu ( ICSharpCode.Core.Codon, System.Object)

29 19

ICSharpCode.SharpDevelop.Project.MSBuildEngine.BuildRun.ParseSolution ( Microsoft.Build.BuildEngine.Project)

29 19


28 28

ICSharpCode.SharpDevelop.Dom.CecilReader.CreateType ( ICSharpCode.SharpDevelop.Dom.IProjectContent, ICSharpCode.SharpDevelop.Dom.IDecoration,

Mono.Cecil.TypeReference)

28 21

ICSharpCode.SharpDevelop.Project.ProjectService.LoadProject ( System.String)

27 15

ICSharpCode.SharpDevelop.Dom.NRefactoryResolver.TypeVisitor.CreateReturnType ( ICSharpCode.NRefactory.Ast.TypeReference,

ICSharpCode.SharpDevelop.Dom.IClass, ICSharpCode.SharpDevelop.Dom.IMember, System.Int32, System.Int32, ICSharpCode.SharpDevelop.Dom.IProjectContent, System.Boolean)

26 31

ICSharpCode.SharpDevelop.Project.DirectoryNode.Initialize ( ) 26 29

ICSharpCode.SharpDevelop.Widgets.TreeGrid.DynamicList.OnPaint ( System.Windows.Forms.PaintEventArgs)

26 21

ICSharpCode.SharpDevelop.Project.Dialogs.NewProjectDialog.OpenEvent ( System.Object, System.EventArgs)

26 20

ICSharpCode.SharpDevelop.Dom.CecilReader.CecilClass ( ICSharpCode.SharpDevelop.Dom.ICompilationUnit,

ICSharpCode.SharpDevelop.Dom.IClass, Mono.Cecil.TypeDefinition, System.String).CecilClass ( ICSharpCode.SharpDevelop.Dom.ICompilationUnit, ICSharpCode.SharpDevelop.Dom.IClass, Mono.Cecil.TypeDefinition, System.String)

26 15

ICSharpCode.SharpDevelop.Gui.GotoDialog.TextBoxTextChanged ( System.Object, System.EventArgs)

25 18




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.

5.4.1.1 Tests unitaires et couverture de code

Les résultats de ce domaine dépendent du processus de test appliqué sur le projet : si processus de tests

unitaires automatisés et/ou de la couverture de code sont mis en œuvre sur le projet, alors l’analyse

exploite les résultats de ces processus.

Pour rappel, il faut bien distinguer test unitaire et couverture de code :

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.

5.4.1.2 Pertinence de la couverture de code

La couverture de code fournit des chiffres précisant la proportion du code exécuté suite à des tests, par

exemple 68% des instructions d’une méthode sont couvertes, 57% des instructions du projet.

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.

5.4.2 Les métriques TestRelevancyIndex (TRI) et TestEffortIndex (TEI)

Pour affiner l’analyse des tests, deux nouvelles métriques ont été conçues par le Centre d’Excellence en

Technologies de l’Information et de la Communication (CETIC) en s’appuyant sur les recherches effectuées

durant les 20 dernières années et à partir de la base de connaissances du « Cockpit Qualité »6.

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).

5.4.3 Cartographie des méthodes par priorité de test

L’histogramme suivant présente une cartographie des méthodes selon leur priorité de tests, à l’aide d’une

échelle de quatre niveaux basée sur le TRI des méthodes (chaque niveau correspondant à un intervalle de

TRI).

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 nombre de méthodes insuffisamment couvertes (taux de couverture inférieur au taux fixé en

objectif pour ce niveau de priorité)

Le nombre de méthodes suffisamment couvertes (taux de couverture supérieur ou égal au taux fixé

en objectif pour ce niveau de priorité)

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 :


5.4.4 Couverture de l’application par les tests

Ce graphique, appelé « TreeMap », restitue une vision de la couverture de l’application par les tests par

rapport aux objectifs. Il permet d’identifier facilement les parties de l’application qui ne sont pas assez

testées par rapport aux risques identifiés. Il regroupe les classes du projet par sous-ensembles techniques, et

les caractérise selon deux dimensions :

la taille, qui dépend de leur nombre d'instructions

la couleur, qui représente l'écart par rapport à l'objectif de test fixé pour la classe : la couleur rouge

indique que le taux de couverture actuel est loin de l’objectif, la couleur verte indique que l’objectif

est atteint

Priorité de test Couvertes Non couvertes Insuffisamment couvertes

Critique 0 1373 0

Haute 0 515 0

Moyenne 0 10 0

Basse 0 14 0

Aucune 0 5656 0

[Total] 0 7568 0

https://cockpit.kalistick.com/authsec/cockpit/pages/dashboards/details/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.

5.4.5 Classes les plus importantes à tester (Top Risks)

Le graphique suivant permet d’identifier rapidement les classes les plus pertinentes à tester, les « Top

Risks ». C’est une représentation dite en « nuage », qui affiche les classes à l’aide de deux dimensions :

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

https://cockpit.kalistick.com/authsec/cockpit/pages/dashboards/details/test/coverage




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.4.7 Méthodes à tester en priorité

Le tableau suivant détaille les principales méthodes à tester en priorité. A chaque méthode sont associés son

taux de couverture actuel, sa valeur brute de TRI, et son niveau de TEI échelonnée de 0 à 4 :




Méthode Couverture Pertinence (TRI)

Priorité Effort Nouvelle violation

ICSharpCode.SharpDevelop.Refactoring.RefactoringMenuBuilder.BuildSubmenu ( ICSharpCode.Core.Codon, System.Object)

0% 37.00 Critique Elevé

ICSharpCode.SharpDevelop.Project.Solution.SetupSolution ( ICSharpCode.SharpDevelop.Project.Solution, System.String)

0% 37.00 Critique Très élevé

ICSharpCode.SharpDevelop.Project.MSBuildBasedProject.SetPropertyInternal ( System.String, System.String, System.String, System.String, ICSharpCode.SharpDevelop.Project.PropertyStorageLocations, System.Boolean)




ICSharpCode.SharpDevelop.Commands.SharpDevelopStringTagProvider.Convert ( System.String)


ICSharpCode.Core.AddInTree.Load ( System.Collections.Generic.List<System.String>, System.Collections.Generic.List<System.String>)


ICSharpCode.SharpDevelop.Project.Commands.AddExistingItemsToProject.Run ( )


ICSharpCode.SharpDevelop.Dom.CecilReader.CreateType ( ICSharpCode.SharpDevelop.Dom.IProjectContent, ICSharpCode.SharpDevelop.Dom.IDecoration, Mono.Cecil.TypeReference)




ICSharpCode.SharpDevelop.DefaultEditor.Gui.Editor.MethodInsightDataProvider.SetupDataProvider ( System.String, ICSharpCode.TextEditor.Document.IDocument, ICSharpCode.SharpDevelop.Dom.ExpressionResult, System.Int32, System.Int32)


ICSharpCode.SharpDevelop.Refactoring.RefactoringService.AddReferences ( System.Collections.Generic.List<ICSharpCode.SharpDevelop.Refactoring.Reference>, ICSharpCode.SharpDevelop.Dom.IClass, ICSharpCode.SharpDevelop.Dom.IMember, System.Boolean, System.String, System.String)


ICSharpCode.SharpDevelop.Dom.ReflectionLayer.ReflectionReturnType.Create ( ICSharpCode.SharpDevelop.Dom.IProjectContent, ICSharpCode.SharpDevelop.Dom.IDecoration, System.Type, System.Boolean)






ICSharpCode.SharpDevelop.Dom.NRefactoryResolver.TypeVisitor.CreateReturnType ( ICSharpCode.NRefactory.Ast.TypeReference, ICSharpCode.SharpDevelop.Dom.IClass, ICSharpCode.SharpDevelop.Dom.IMember, System.Int32, System.Int32, ICSharpCode.SharpDevelop.Dom.IProjectContent, System.Boolean)


ICSharpCode.SharpDevelop.Dom.CSharp.CSharpExpressionFinder.SearchBracketForward ( System.String, System.Int32, System.Char, System.Char)


ICSharpCode.SharpDevelop.DefaultEditor.Gui.Editor.AbstractCodeCompletionDataProvider.CreateItem ( System.Object, ICSharpCode.SharpDevelop.Dom.ExpressionContext)


ICSharpCode.SharpDevelop.Project.MSBuildEngine.BuildRun.ParseSolution ( Microsoft.Build.BuildEngine.Project)

0% 34.00 Critique Normal

ICSharpCode.SharpDevelop.Project.ProjectService.LoadProject ( System.String)


ICSharpCode.SharpDevelop.Project.ProjectBrowserControl.FindDeepestOpenNodeForPath ( System.String)



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.





Les violations de contraintes de communication entre deux éléments sont représentées à

l’aide de flèches. Le point de départ est l’élément appelant, le point de destination est l’appelé.

Les flèches oranges concernent une communication directe entre une couche haute et une

couche basse non adjacente (parfois acceptables). Les flèches noires concernent des

communications totalement prohibées.

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é, …

5.6.1 Cartographie des duplications

Le graphique suivant présente une cartographie des duplications au sein de l’application. Il ne tient pas

compte des duplications impliquant un nombre d’instructions inférieur au seuil, car celles-ci sont

généralement nombreuses et peu pertinentes (par exemple les duplications d’accesseurs entre différentes

classes partageant des propriétés semblables).

https://cockpit.kalistick.com/authsec/cockpit/pages/dashboards/details/architecture



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.6.2 Duplications à corriger en priorité

Le tableau suivant détaille la liste des principales duplications à corriger en priorité. Chaque bloc est identifié

par un numéro unique, et chaque duplication est localisée dans le code. Si un audit précédent a été réalisé,

un indicateur indique si la duplication est nouvelle ou non.

N° duplication

Nb lignes dupliquées

Classe impliquée Lignes Nouvelle violation


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

https://cockpit.kalistick.com/authsec/cockpit/pages/dashboards/details/duplication

https://cockpit.kalistick.com/authsec/cockpit/pages/dashboards/details/duplication



la complexité cyclomatique et un seuil sur le nombre d’instructions sont définis pour filtrer les méthodes à

vérifier.

5.7.1 Cartographie des problèmes de documentation

Le graphique suivant présente une cartographie de la documentation des méthodes du projet avec une

complexité supérieure au seuil fixé. Les méthodes sont regroupées par intervalles de taille (nombre

d’instructions). Pour chaque intervalle sont indiqués le nombre de méthodes avec entête de documentation

et le nombre de méthodes sans entête de documentation. La zone rouge du dernier intervalle correspond

aux méthodes non documentées donc non-conformes.

5.7.2 Méthodes à documenter en priorité

Le tableau suivant détaille la liste des principales méthodes à documenter en priorité :



Méthode Instructions Complexité Nouvelle violation

ICSharpCode.SharpDevelop.Project.MSBuildBasedProject.SetPropertyInternal

92 28

ICSharpCode.SharpDevelop.Project.DirectoryNode.Initialize 81 29

ICSharpCode.SharpDevelop.Dom.VBNet.VBNetAmbience.Convert

81 44

ICSharpCode.SharpDevelop.Widgets.SideBar.SideBarControl.ProcessCmdKey

81 32

ICSharpCode.SharpDevelop.Commands.SharpDevelopStringTagProvider.Convert

81 25

ICSharpCode.SharpDevelop.Dom.CSharp.CSharpAmbience.Convert

77 41

ICSharpCode.SharpDevelop.Refactoring.RefactoringMenuBuilder.BuildSubmenu

74 22

ICSharpCode.SharpDevelop.Project.Solution.Save 74 11

ICSharpCode.SharpDevelop.Dom.NRefactoryResolver.NRefactoryResolver.ResolveInternal

71 34

ICSharpCode.SharpDevelop.Widgets.TreeGrid.DynamicList.OnPaint

71 21

ICSharpCode.SharpDevelop.DefaultEditor.XmlFormattingStrategy.TryIndent

70 24

ICSharpCode.SharpDevelop.Project.Commands.AddExistingItemsToProject.Run

70 22

ICSharpCode.SharpDevelop.Project.Solution.SetupSolution 64 20

ICSharpCode.Core.AddInTree.Load 62 21

ICSharpCode.SharpDevelop.DefaultEditor.Commands.ClassMemberMenuBuilder.BuildSubmenu

60 23

ICSharpCode.SharpDevelop.Dom.Refactoring.NRefactoryRefactoringProvider.GetFullCodeRangeForType

58 24

ICSharpCode.SharpDevelop.Dom.CSharp.CSharpExpressionFinder.ReadNextToken

58 25

ICSharpCode.SharpDevelop.Dom.CecilReader.CecilClass.InitMembers

57 30

ICSharpCode.SharpDevelop.Dom.CSharp.CSharpExpressionFinder.SearchBracketForward

57 47


https://cockpit.kalistick.com/authsec/cockpit/pages/dashboards/details/documentation



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.

Voici l’explication de chaque étape :

1. Correction des pratiques interdites

Ces pratiques sont souvent simples à corriger, et du fait qu’elles invalident directement les classes,

leur correction conduit généralement à améliorer significativement le taux de non-conformité global

(si les classes ne sont pas invalidées par d’autres règles).

2. Eclatement des méthodes trop longues

A l’aide de certains IDE, il est souvent facile d’éclater une méthode trop longue en plusieurs

méthodes unitaires. Ceci est réalisé à l’aide d’opérations automatisées réalisant des refactorings7,

évitant tout risque de régression lié à une intervention manuelle.

3. Documentation des méthodes complexes

Cette étape consiste à documenter les méthodes identifiées comme non-conformes dans le domaine

Documentation, opération simple mais potentiellement fastidieuse.

4. Correction des pratiques déconseillées

Correspondent à toutes les pratiques restantes après correction des pratiques interdites : pratiques

fortement déconseillées, déconseillées et à éviter.

7 http://blog.kalistick.fr/2009/05/decomplexifiez-votre-code.html

http://blog.kalistick.fr/2009/05/decomplexifiez-votre-code.html



5. Suppression des duplications

Cette opération est plus ou moins compliquée suivant les cas : il faut au préalable déterminer si la

duplication doit réellement être factorisée (deux composants peuvent partager une même base de

code mais être indépendants). Ensuite l’opération peut être automatisée selon les IDE et selon le

type de duplication (difficile si la duplication est à cheval sur plusieurs méthodes).

6. Modularisation des traitements complexes

Cette opération est proche de l’éclatement des méthodes trop longues, mais est souvent plus

délicate à réaliser en raison de la complexité du code.

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é :

Efficacité : l'application assure-t-elle les performances d'exécution attendues ? Evolutivité : les évolutions du code nécessitent-t-elles un coût de développement croissant ? Fiabilité : l'application présente-t-elle des bugs qui nuisent à son comportement attendu ? Maintenabilité : les mises à jour de maintenance nécessitent-t-elles un coût de développement

constant ? Sécurité : l'application présente-t-elle des failles de sécurité ? Transférabilité : la reprise de l'application par de nouveaux intervenants est-elle problématique ?

Couverture par blocs

La couverture par blocs mesure le taux de blocs exécutés lors des tests par rapport au nombre total de blocs.

Un bloc de code est un chemin de code avec un point d'entrée unique, un point de sortie unique et un jeu

d'instructions exécutées en séquence. Il se termine lorsqu'il atteint une instruction conditionnelle, un appel

de fonction, une levée d'exception, ou un try/catch.

Couverture par branches

La couverture par branches mesure le taux de branches exécutées lors des tests par rapport au nombre total

de branches.

if (value)

{

//

}

Ce code sera couvert par branches à 100% si la condition du if a été testée dans le cas vrai et faux.

Couverture par lignes

La couverture par lignes (ou instructions) mesure le taux de lignes exécutées lors des tests par rapport au

nombre total de lignes. Cette mesure est insensible aux instructions conditionnelles, la couverture par lignes

peut être de 100% sans que l'ensemble des conditions soit exécuté.



Domaine de qualité

Les résultats d'analyses sont ventilés sur 4 domaines selon la nature des violations :

Implémentation : concerne des problèmes liés à l'utilisation du langage ou à l'algorithmie Structure : concerne des problèmes liés au découpage de l'application : taille des méthodes,

complexité cyclomatique, ... Test : concerne les problèmes liés aux tests unitaires du code et à sa couverture Architecture: concerne les problèmes liés l’architecture logicielle Documentation : concerne les problèmes liés à la documentation du code : commentaires d'entête,

commentaires de code, ... Duplication : correspond aux copier-coller découverts dans le code

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

8.1 La complexité cyclomatique La complexité cyclomatique est un indicateur du nombre de chemins possibles d’exécution.

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 :

Code analysé Graphe de contrôle équivalent

int x = 3;

if (x > 0) {

x++;

} else {

x--;

}

Le graphe contient 4 arcs, 4 nœuds et 2 faces (1

intérieure, 1 extérieure). Le nombre CC vaut donc 2.

8.1.3 Corollaire de la définition

CC = nb de décisions du code + 1

Une instruction if compte pour 1 décision

Une instruction for ou while compte pour 1 décision

Une instruction case compte n décisions.

8.1.4 Diagnostic à effectuer

Valeur de la Complexité Cyclomatique

Evaluation des risques selon le S.E.I.8

1-10 Programme simple, sans trop de risque

11-20 Complexité et risque modéré

21-50 Complexe, risque élevé

Supérieure à 50 Non testable, risque très élevé

.

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).

http://www.sei.cmu.edu/



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.

8.2.2 Exemple de calcul de couplage

Le calcul du couplage entre des classes peut par exemple s’effectuer en comptant :

Les déclarations d’attributs avec des références sur les classes

Les paramètres formels (dans les signatures des méthodes par exemple)

Les déclarations throws

Les variables locales

Les types

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 Le TRI et TEI Le TRI (TestRelevancyIndex) et le TEI (TestEffortIndex) sont deux index permettant de mesurer

respectivement la pertinence à tester du code et l’effort à produire pour implémenter ces tests. Ils ont été

conçus en partenariat avec le Centre d'Excellence en Technologies de l'Information et de la Communication

(CETIC) à partir des millions de lignes de code analysées par la plateforme Cockpit Qualité9.

8.3.1 Le TRI (TestRelevancyIndex)

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.

8.3.1.2 Principe et groupes de priorités de test

Le TRI 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, couplage afférent, ...) et en appliquant un facteur de

criticité. Ce facteur de criticité est associé à des sous-ensembles fonctionnels auxquels contribue l'élément

de code. Il est déterminé de manière spécifique à l’application.

En fonction de cette valeur de TRI, les méthodes sont classifiées en cinq groupes de priorité de test :

Critique : méthodes complexes et/ou sensibles à tester obligatoirement Haute Moyenne Basse Aucune : méthodes triviales inutiles à tester

Chaque groupe de priorité de test fixe pour les méthodes concernées :

un seuil de couverture à atteindre.

une sévérité en cas de violation

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.

8.3.1.3 Détail des métriques unitaires

Le TRI est calculé à partir des métriques unitaires suivantes :

Complexité cyclomatique de la méthode

Nombre de paramètres de la méthode

Nombre de variables locales de la méthode

Couplage afférent

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 Le TEI (TestEffortIndex)

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 :

Très faible: méthodes triviales à tester

Faible

Normal

Élevé

Très élevé: méthodes complexes très difficilement testables exhaustivement

8.3.2.3 Détail des métriques unitaires

Le TEI est calculé à partir des métriques unitaires suivantes :

Complexité cyclomatique de la méthode

Nombre de paramètres de la méthode

Nombre de variables locales de la méthode



8.4 Exigences techniques

8.4.1 Règles d’implémentation

Référence Description courte Sévérité AlwaysCallGetLastErrorAfterPInvoke Il faut toujours appeler la méthode

<code>System.Runtime.InteropServices.Marshal.GetLastWin32Err

or()</code> ou la fonction équivalente Win32 <code>GetLastError()</code> après l'appel P/Invoke afin d'éviter de récupérer une mauvaise erreur.

Interdit

AlwaysDeclareNamespace Toujours organiser les types dans des namespaces. Interdit AvoidRedundantCasts Il faut éviter de réaliser plusieurs transtypages identiques sur un

même objet. Interdit

CallSuppressFinalizeInDisposeMethods

Il faut appeler la méthode <code>System.GC.SuppressFinalize()</code> dans l'implémentation de la méthode

<code>System.IDisposable.Dispose()</code> afin que le Garbage Collector n'appelle pas le finaliseur de l'objet.

Interdit

DeclareUsageForAttribute Un attribut personnalisé doit être marqué par l'attribut <code>System.AttributeUsage</code> afin d'indiquer au

développeur où il peut être appliqué (type, méthode, assembly...).

Interdit

DeclareVersionForAssembly_ La version de l'assembly doit être déclarée. Interdit DefineMarshalingForPInvokeStringArguments

Il faut spécifier la conversion des arguments de type chaines de

caractères lors d'appel à du code non managé. Interdit

DefineMessageForObsoleteAttribute Il faut utiliser l'argument <code>message</code> de l'attribut <code>System.ObseleteAttribute</code> afin d'indiquer à

l'utilisateur quel est l'élément à utiliser à la place.

Interdit

DontAccessAnyReferenceTypeInDestructor

L'accès à des champs référencés dans le finaliseur peut ne pas aboutir.

Interdit

DontAccessOrModifyObjectMoreThanOnceInAExpression

Il ne faut pas accéder ou modifier un objet plus d'une fois dans

une expression. Interdit

DontChangeVisibilityOfInheritedMember

Il ne faut pas réduire la visibilité d'une méthode que l'on surcharge (avec le mot clé <code>new</code>).

Interdit

DontCompareFloatWithEquals Les comparaisons entre nombres flottants (<code>float</code>,<code>double</code>,

<code>decimal</code>) ne doivent pas être réalisées avec les opérateurs <code>==</code> et <code>!=</code>.

Interdit

DontDeriveExceptionFromSystemException

Il ne faut pas créer une nouvelle exception héritant de <code>System.SystemException</code>, préférer l?utilisation de <code>System.Exception</code>.

Interdit

DontHardcodeLocaleSpecificStrings Il ne faut pas coder en dur des chemins de dossiers systèmes spécifiques à l'environnement d'exécution

Interdit

DontHideBaseClassMethod Une méthode dans un type de base est masquée dans un type dérivé par une méthode dont les paramètres sont des sous-types de la méthode de base.

Interdit

DontImplementEmptyFinalizers Il est inutile d'implémenter des finaliseurs vides. Interdit DontImplementWriteOnlyProperty Il est déroutant de déclarer des propriétés en écriture seulement. Interdit DontOverloadOperatorEqualsOnReferenceType

La surcharge de l'opérateur <code>==</code> est à utiliser avec parcimonie.

Interdit



DontRaiseExceptionInUnexpectedMethod_

Certaines méthodes ne doivent pas jeter d'exceptions car elles doivent effectuer des opérations simples et aboutir soit à une valeur de retour, soit à la fin d'une opération.

Interdit

DontThrowExceptionsInFinallyBlock Il ne faut pas lancer d'exception dans une clause <code>finally</code>.

Interdit

DontUseInadvisableTypes Depuis la version 2.0 du framework .NET, il est recommandé de ne plus dériver certains types.

Interdit

DontUseObjectTypeForIndexers Il faut utiliser des types entier ou string comme index pour les

indexeurs. L'utilisation d'un type Objet est à proscrire. Interdit

DontUseTooManyParametersOnGenerics_

Le nombre de paramètres génériques pour un type générique

visible de l'extérieur est limité à 2. Interdit

DontUseWin32ApiWhenManagedApiExist

Il est préférable d?utiliser la version managée d?une méthode à la

place de la version non managée lorsqu?elle est disponible. Interdit

FollowISerializableImplementationRule

L'implémentation de <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.

Interdit

ISerializableTypesMustCallBaseClassMethods

Un type dérivant un type implémentant

<code>ISerializable</code> doit invoquer le traitement parent. Interdit

ImplementIDisposableForTypesWithDisposableFields

Un type qui déclare et implémente des champs de type

<code>System.IDisposable</code> doit implémenter <code>System.IDisposable</code> afin de supprimer ses ressources non managées.

Interdit

InstantiateExceptionsWithArguments Il est recommandé d'instancier les exceptions en fournissant les paramètres adéquates pour préciser le contexte de l'exception.

Interdit

OverrideEqualsWithOperatorOnValueTypes

Un type valeur doit implémenter la méthode

<code>System.Object.Equals(Object)</code>. Interdit

PInvokesMustNotBeVisible Une méthode marquée avec l'attribut <code>System.Runtime.InteropServices.DllImportAttribute</code

> ne doit pas être visible en dehors de l'assembly.

Interdit

PropertyNamesMustNotMatchGetMethods

Une méthode ne doit pas être nommée à partir du nom d'une propriété.

Interdit

TypeLinkDemandsRequireInheritanceDemands

Un type public non scellé ou une méthode virtuelle ayant une demande de liaison doivent avoir une demande d'héritage sur la même autorisation.

Interdit

TypeWithNativeResourcesMustBeDisposable

Un type possèdant des champs <code>IntPtr</code>,

<code>UIntPtr</code> et <code>HandleRef</code> doit implémenter <code>System.IDisposable</code>.

Interdit

UseConstInsteadOfReadOnlyWhenPossible_

Un champ déclaré en <code>static</code> et

<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>.

Interdit

UseIsNanFunction Il ne faut pas comparer avec les valeurs <code>Double.NaN</code> ou <code>Single.NaN</Code>.

Interdit

UseIsNullOrEmptyToCheckEmptyStrings

Comparer une chaîne à la chaîne vide n'est pas optimal. Interdit

UseMarshalAsForBooleanPInvokeArguments_

Il faut utiliser l'attribut <code>System.Runtime.InteropServices.MarshalAsAttribute

</code> pour permettre la bonne conversion entre un booléen non managé et un booléen managé.

Interdit



UseParamsKeywordInsteadOfArglist Utiliser le mot clé <code>params</code> pour un nombre

variable de paramètres au lieu de la notation <code>__arglist</code> qui n'est pas conforme CLS.

Interdit

UseSTAThreadAttributeForWindowsFormsEntryPoints

Le point d'entrée d'une application Windows Forms doit être marqué avec l'attribut

<code>System.STAThreadAttribute</code>.

Interdit

DeclareFinalizerForDisposableTypes Il faut implémenter le finaliseur car ce type

est<code>System.IDisposable</code> et contient des champs non managés.


DefineAttributeForISerializableTypes Un type héritant de <code>System.Runtime.Serialization.ISerializable</code> doit être marqué de l'attribut

<code>System.SerializableAttribute</code>.


DefineDeserializationMethodsForOptionalFields

Les champs de sérialisation optionnels doivent être gérés dans les

méthodes marquées <code>System.Runtime.Serialization.OnDeserialized</code> et <code>System.Runtime.Serialization.OnDeserializing</code>.


DontIgnoreMethodsReturnValue La valeur de retour d'une méthode ou d'un constructeur n'est ni

utilisée, ni assignée à une variable alors qu'un nouvel objet est retourné.


DontMakePointersVisible Un type pointeur doit être privé ou doit être en lecture seule. Fortement déconseillé

DontNestGenericInMemberSignatures_

Il faut éviter les types génériques imbriqués comme paramètres

de méthode. Fortement déconseillé

DontTouchForLoopVariable Attention à ne pas modifier la variable d'itération d'une boucle <code>for</code> à l'intérieur de celle-ci.


DontUseMultidimensionalIndexers Il est conseillé de ne pas déclarer plusieurs dimensions à un indexeur.


DontUseNonConstantStaticVisibleFields

Les champs statiques <code>public</code> ou

<code>protected</code> doivent être en lecture seule ou constants.


EnumeratorMustBeStronglyTyped Un type implémentant l'interface <code>System.Collections.IEnumerator</code> doit fournir une

propriété <code>Current</code> fortement typée afin que l'utilisateur n'ait pas à transtyper le type retourné par la propriété fournie par l'interface.


ImplementGenericInterfaceForCollections

Un type implémentant <code>System.Collections.IEnumerable</code> doit également

implémenter <code>System.Collections.Generic.IEnumerable<T></code>.


ListMustBeStronglyTyped Un type implémentant <code>System.Collections.IList</code>

doit fournir des méthodes fortement typées. Fortement déconseillé

NeverMakeCtorCallOverridableMethod

Le constructeur d'un type non scellé ne devrait jamais appeler une méthode virtuelle.


OverrideGetHashCodeWhenOverridingEquals

Un type qui surcharge la méthode <code>System.Object.Equals(Object)</code> doit aussi surcharger la méthode <code>System.Object.GetHashCode()</code>.




OverrideMethodsInIComparableImplementations

Un type implémentant l'interface

<code>System.IComparable</code> doit surcharger la méthode <code>System.Object.Equals(Object)</code> et les opérateurs <code>==</code>, <code>!=</code>, <code><</code>, <code>></code>.


ReviewParametersAttributeStringLiteral_

Il faut revoir les valeurs des attributs. Les valeurs des paramètres « version », « guid », « uri », « urn », ou « url » doivent correspondre à des valeurs correctes attendues.


AttributeArgumentShouldBeLinkedToAccessor

Chaque membre d'un attribut personnalisé doit être lié à une accesseur afin d'indiquer à l'utilisateur le caractère optionnel ou non de celui-ci.

Déconseillé

DefineAttributeForNonSerializableFields

Il faut marquer les champs qui ne doivent pas être sérialisés de

l'attribut <code>System.NonSerializableAttribute</code>. Déconseillé

DefinePrivateConstructorForStaticClass

Un type qui ne contient que des méthodes et propriétés statiques ne devrait pas définir de constructeur d'instance public.

Déconseillé

DefineZeroValueForEnum La valeur par défaut d'une énumération est 0. Déconseillé DontCatchTooGeneralExceptions Il n'est pas recommandé d'attraper des exceptions avec un type

trop général. Déconseillé

DontDeclareRefAndOutParameters Ne pas déclarer des paramètres avec <code>out</code> ou

<code>ref</code>. Déconseillé

DontThrowBasicException Certaines exceptions ne doivent pas être utilisées car ne fournissent pas assez d'informations sur l'erreur levée.

Déconseillé

DontThrowRuntimeException Certaines exceptions ne doivent pas être utilisées car elles sont réservées à la CLR.

Déconseillé

DontUseCaseToDifferPublicIdentifiers

Il est déconseillé de différencier les identifiants seulement par leur casse de caractère.

Déconseillé

DontUseReservedKeywordsForIdentifiers

Les identifiants de namespaces et de types ne doivent pas

correspondre à des mots réservés des langages du CLR (casse de caractère non comprise).

Déconseillé

FollowSerializationMethodsImplementationRule

Une méthode gérant un événement de sérialisation n'a pas la

signature, le type de retour ou la visibilité appropriée. Déconseillé

FollowSuffixStandardForIdentifiers Nommer le type à l'aide du suffixe attendu pour le type de base. Déconseillé OverrideLinkDemandMustBeIdenticalToBase

Lorsque l'on surcharge ou implémente une méthode, les demandes de liaison doivent correspondre.

Déconseillé

OverrideOperatorEquals Il faut surcharger l'opérateur <code>==</code> dans les cas suivants : Lorsque la méthode

<code>System.Object.Equals(Object)</code> est surchargée dans un type valeur ou lorsque les opérateurs <code>+</code> et <code>-</code> sont surchargés dans un type référence.

Déconseillé

PreserveStackTraceWhenThrowingNewException

Une exception lancée à partir d'une autre exception devrait

toujours stocker la pile d'erreur originale. Déconseillé

ProvideTypeParameterForGenericMethods

Le type générique déclaré pour une méthode générique doit être au moins utilisé dans un type d'un paramètre.

Déconseillé

StaticTypesShouldBeSealed Un type ne contenant que des membres statiques doit être scellé. Déconseillé UseGenericEventHandler_ Il faut utiliser le délégué générique

<code>System.EventHandler<TEventArgs>(Object

sender,TEventArgs e)</code>.

Déconseillé

UseInt32ForEnumStorage Il est inutile de modifier le type pour le stockage des énumérations, ceci n'apporte aucun gain de performance

Déconseillé

UseInterfaceRatherThanClasses_ Dans un souci de généricité, il est bien plus flexible d'utiliser les

interfaces plutôt que les classes les implémentant. Déconseillé



UseStaticWhenPossible Une méthode qui n'accède pas aux données d'instance peut être

déclarée comme statique. Déconseillé

ConsiderUsingProperty Utiliser les propriétés lorsque cela est possible afin de respecter les standards .NET.

A éviter

DontCompareBooleanWithTrueOrFalse

Il est inutile de comparer explicitement un booléen avec

<code>true</code> ou <code>false</code> dans une expression conditionnelle.

A éviter

DontDefinePublicGenericLists Il est préférable d'utiliser un type dérivé de

<code>System.Collections.Generic.List<T></code>. A éviter

DontDirectlyReturnArray Une propriété ne devrait par retourner de tableau. En effet, les

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.

A éviter

DontImplementConstructorForStaticTypes

Il est inutile d'implémenter un constructeur public pour un type qui ne déclare que des membres statiques.

A éviter

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,

sauf s'il est statique, constant ou déclaré dans un type imbriqué privé ou interne.

A éviter

DontPrefixEnumValuesWithEnumName

Il n'est pas nécessaire de préfixer les champs d'une énumération

avec le mot <code>Enum</code> pour indiquer que ce sont des champs d'énumération.

A éviter

DontUseReservedKeywordForEnum Il faut rajouter un nouveau champ à la fin d'une énumération si

l'on souhaite la modifier de façon non impactante, et non pas utiliser le mot-clé <code>reserved</code>.

A éviter

DontUseTypeNamesForNamespaces Le nom d'un type ne doit pas correspondre au nom d'un

namespace défini dans votre projet ou dans le framework .NET. A éviter

FlagsEnumsMustHavePluralNames Une énumération marquée par <code>System.FlagsAttribute</code> doit posséder un nom conjugué au pluriel.

A éviter

IdentifiersMustNotContainTypeNames

Les identificateurs des paramètres d'un membre doivent

véhiculer leur signification et non décrire leur type, qui devrait être fourni par les outils de développement.

A éviter

ImplementNamedMethodsWhenOverloadingOperators

Lorsque l?on surcharge un opérateur, il faut prévoir

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>.

A éviter

InitializeStaticFieldsInline Il est préférable d?initialiser les variables statiques là où elles sont déclarées (inline) et éviter d?utiliser des constructeurs statiques.

A éviter

OnlyFlagsEnumsMustHavePluralNames

Une énumération ne possédant pas l?attribut

<code>System.FlagsAttribute</code> ne peut avoir qu?une seule valeur à la fois, son identificateur doit donc être conjugué au singulier.

A éviter

PassBaseTypeAsParameters Les types des paramètres doivent être les plus génériques possibles.

A éviter

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

supprimé. A éviter

RemoveUnusedPrivateFields Un champ privé qui n'est pas utilisé dans le type doit être supprimée.

A éviter



RemoveUnusedPrivateMethods Une méthode privée qui n'est pas utilisée dans le type doit être

supprimée. De même, une méthode interne non utilisée dans l'assembly doit être supprimée.

A éviter

ReviewUnusedLocals Une variable locale qui n'est pas utilisée doit être supprimée.

A éviter

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

<code>System.IDisposable</code>) doivent être disposés dans la méthode <code>System.IDisposable.Dispose()</code> de ce type.

[Aucune]

8.4.2 Seuils de couverture de code

Le tableau suivant présente les seuils de couverture de code attendus selon la priorité de test des méthodes

(TRI). Cette priorité de test est échelonnée selon cinq niveaux, en fonction d’intervalles de TRI :

Priorité de test [ TRI Min. TRI Max.[ Seuil Sévérité

Aucune 0 6 0 Pour information

Basse 6 11 60% Pour information

Moyenne 11 16 70% Pour information

Haute 16 21 80% Pour information

Critique 21 [Infini] 90% Pour information

Technology

Analyse de code: accélérez la validation de vos applications C#