Vous êtes sur la page 1sur 96

QUALITÉ LOGICIEL

MÉTRIQUES DE QUALITÉ LOGICIEL


SONARQUBE

Professeur:
Pr HIBA ASRI
Filière:
Génie Informatique , 5 ème année
QUALITÉ LOGICIELLE
MÉTRIQUES DE QUALITÉ LOGICIEL
PRINCIPE

La Qualité logicielle est


 Selon l'IEEE : Le degré avec lequel un système, un composant ou un processus
satisfait aux besoins ou attentes de ses clients/usagers.
 Selon AFNOR : C’est l’aptitude d’un produit ou d’un service à satisfaire les besoins des
utilisateurs
 Selon ISO 9000: C’est l’ensemble des caractéristiques intrinsèques qui lui confère
l’aptitude à satisfaire les besoins et attentes exprimés ou implicites des clients et
autres parties intéressées.
MÉTROLOGIE LOGICIEL

• Métrologie (science de la mesure): ensemble de méthodes et savoir-faire qui


permettent d’effectuer des mesures et d’avoir une confiance suffisante dans leurs
résultats pour évaluer la qualité du logiciel.
• Mesure: grandeur numérique, ou quantité, généralement exprimée sous la forme
d’un multiple d’une unité.
• Les mesures peuvent remplir les différents rôles suivants :
• Rôle évaluatif, consistant à décrire l’objet de la mesure.
• Rôle vérificatif, consistant à vérifier que l’objet de la mesure est conforme à ce qui est
attendu.
• Rôle prédictif, consistant à prédire à partir du mesurage l’évolution future de l’objet
MÉTRIQUE DE QUALITÉ

 Métrique: Moyen permettant de quantifier une propriété dans le monde du


logiciel, elles peuvent être explicites ou implicites, simples ou complexes (qui se
composent d’autres métriques).
 Tout projet doit avoir des métriques qui permettent de mesurer le degré de
qualité atteint au cours de développement des logiciels.

 les métriques sont classées en trois types:


 Métriques du processus logiciel : orientées processus de développement (le coût, temps,
etc.)
 Métriques du produit logiciel : orientées produit logiciel (le code, la complexité, etc.)
 Métriques du projet : orientées projet (nombre de développeurs, l’effort, etc.)
MODÈLES DE QUALITÉ
LOGICIELLE

« Ce qui n'est pas mesurable rendez le mesurable »


Galilée 1564-1642
MODÈLE DE QUALITÉ

• Objectif: Etablir une relation entre les aspects mesurable d’un système et sa qualité.
• Modèle: fonction « f » de la forme: qualité ≈ f (attributs).
• où la qualité est une valeur et les attributs sont les métriques décrivant le système.
• la fonction dépend du type de relation qui relie la structure d'un système à sa
qualité.
• Les modèles de qualité définissent la qualité à travers :
• la qualité du produit,
• la qualité du processus,
• la qualité du service,
• La qualité des ressources.
MODÈLE DE QUALITÉ

 Modèle de qualité est basé sur un ensemble de facteurs


de qualité, où chaque facteur est décomposé d’un ou
Qualité
plusieurs critères, dont chacun y a un ensemble de
métriques associées.
 Facteur: caractéristique du logiciel, du processus ou du Facteur 1 Facteur 2 Facteur N
service contribuant à sa qualité telle qu'elle est ressentie
par l'utilisateur (vision EXTERNE ).
Critère A Critère B Critère C Critère D
 Critère: attribut du logiciel par l'intermédiaire duquel un
facteur peut être obtenu. C'est également une
caractéristique du logiciel sur laquelle le développeur
Métriques Métriques Métriques Métriques
peut agir (vision INTERNE ).
 Métrique est la mesure d'une propriété d'un critère. (par
exemple, la taille d’un module pour le critère
"Simplicité").
MODÈLE MC CALL

• Modèle de Mc Call (1977) détermine une approche de la e qualité à partir de la


définition de caractéristiques externes (facteurs de qualité) et internes (critères
de qualité) qui soient mesurables (par des métriques).
• Il a défini 23 critères répartis sur 11 facteurs, chaque critère correspond à
au moins une métrique
 OPERATIONNEL : Conformité aux besoins , Fiabilité, Efficacité, Intégrité , Facilité
d’emploi
 L'EVOLUTION : Maintenabilité, Souplesse, Testabilité
 L'ADAPTABILITE: Portabilité, Réutilisabilité, interopérabilité
MODÈLE MC CALL
MODÈLE ISO9126:2001

• Modèle composé de:


• 6 caractéristiques générales ( la capacité fonctionnelle, la fiabilité, la facilité
d’usage, l’efficacité, la maintenabilité, la portabilité)
• 27 sous-caractéristiques
NORME ISO9126

 La norme ISO9126 distingue 3 catégories de qualité :


 la qualité interne qui qualifie la qualité du logiciel à partir de mesures statiques du code.
 la qualité externe qui repose sur les mesures externes. Il s’agit des mesures effectuées lors de simulation
d’exécution du logiciel, lors des phases de tests par exemple.
 la qualité à l’utilisation qui est mesurée lors de l’utilisation du logiciel. Il s’agit de la qualité ressentie par
l’utilisateur dans des conditions spécifiques et dans un environnement spécifique.

effect of software
software product
product

influences influences
internal external quality in
quality quality use
contexts of
depends on depends on use

internal metrics external metrics quality in use


metrics
NORME ISO9126

• Capacité fonctionnelle (Functionality) : est-ce que le logiciel répond aux


besoins fonctionnels exprimés ? La capacité du produit logiciel à fournir des fonctions
qui répondent aux besoins exprimés et implicites lorsque le logiciel est utilisé dans
des conditions spécifiées.
 Pertinence(Suitability) : La capacité du produit logiciel à fournir un ensemble approprié de fonctions pour des tâches
et des objectifs utilisateur spécifiques.

 Exactitude(Accuracy) : La capacité du logiciel à fournir les bons résultats ou les résultats convenus avec le degré de
précision requis.

 Interopérabilité(Interoperability) : La capacité du produit logiciel à interagir avec un ou plusieurs systèmes


spécifiés.

 Sécurité(Security) :La capacité du produit logiciel à protéger les informations et les données afin que des personnes ou
des systèmes non autorisés ne puissent pas les lire ou les modifier, et des personnes ou des systèmes autorisés ne sont pas
interdits d'accès.
NORME ISO9126

• FIABILITE (Reliability) : est-ce que le logiciel maintient son niveau de service


dans des conditions précises et pendant une période déterminée ? La capacité du
produit logiciel à maintenir un niveau de performance spécifié lorsqu'il est utilisé
des conditions critiques.
 Maturité (Maturity) : La capacité du produit logiciel à éviter les défaillances résultant de défauts du logiciel.
 Tolérance aux pannes(Fault tolerance) : La capacité du produit logiciel à maintenir un niveau de
performance spécifié en cas de défaillance du logiciel ou de violation de son interface spécifiée.

 Facilité de récupération(Recoverability ) : La capacité du produit logiciel à rétablir un niveau de


performance spécifié et à récupérer les données directement affectées en cas de défaillance.
NORME ISO9126

• Facilité d'utilisation (Usability ) : est-ce que le logiciel requiert peu d’effort


à l’utilisation ? La capacité du produit logiciel à être compris, appris, utilisé et
attrayant pour l'utilisateur, lorsqu'il est utilisé dans des conditions spécifiées.
 Facilité de compréhension (Understandability ) : La capacité du produit logiciel à permettre à l'utilisateur
de comprendre si le logiciel est adapté et comment il peut être utilisé pour des tâches et conditions d'utilisation
particulières

 Facilité d'apprentissage(Learnability) : La capacité du produit logiciel à permettre à l'utilisateur d'apprendre


son application.

 Facilité d'exploitation(Operability) : La capacité du produit logiciel à permettre à l'utilisateur de l'utiliser et de


le contrôler.

 Attraction (Attractiveness) : La capacité du logiciel à être attrayant pour l'utilisateur (tels que
l'utilisation des couleurs et la conception graphique).
NORME ISO9126

• Efficacité (Efficiency ) : est-ce que le logiciel requiert un dimensionnement rentable et


proportionné de la plate-forme d’hébergement en regard des autres exigences ? La capacité du
produit logiciel à fournir une performance appropriée, par rapport à la quantité de ressources
utilisées, en dessous les conditions indiquées.
• Comportement temporel (Time behaviour ) : La capacité du produit logiciel à fournir des temps de réponse et de
traitement et des débits de traitement appropriés lors de l'exécution de sa fonction conformément aux conditions indiquées.

• Utilisation des ressources(Resource utilisation) : La capacité du produit logiciel à utiliser des quantités et des types
de ressources appropriés lorsque le logiciel remplit sa fonction conformément aux conditions définies.
NORME ISO9126

• Maintenabilité(Maintainability ) : est-ce que le logiciel requiert peu d’effort à son évolution


par rapport aux nouveaux besoins ? La capacité du produit logiciel à fournir une performance
appropriée, par rapport à la quantité de ressources utilisées, en dessous les conditions indiquées.
• Facilité d'analyse(Analysability ) : La capacité du produit logiciel à être diagnostiqué pour des déficiences ou des causes de
défaillances dans le logiciel, ou pour que les pièces à modifier soient identifiées.

• Facilité de modification(Changeability) : La capacité du produit logiciel à permettre l’implémentation d'une modification


spécifiée (l'implémentation inclut le codage, la conception et la documentation des modifications).

• Stabilité(Stability) : La capacité du logiciel à éviter les effets inattendus des modifications du logiciel.
• Testabilité(Testability) : La capacité du logiciel à valider les modification.
NORME ISO9126

• Portabilité (Portability ) : est-ce que le logiciel peut être transféré d’une plate-forme ou d’un
environnement à un autre ? La capacité du produit logiciel à être transféré d'un environnement à un
autre.
• Facilité d'adaptation(Adaptability) : La capacité du produit logiciel à être adapté pour différents environnements spécifiés sans
appliquer d'actions ou de moyens autres que ceux prévus à cet effet pour le logiciel considéré.

• Facilité d'installation(Installability) : La capacité du produit logiciel à être installé dans un environnement spécifié.
• Coexistence(Co-existence) : La capacité du logiciel à coexister avec d'autres logiciels indépendants dans un environnement commun
partageant des ressources communes.

• Interchangeabilité(Replaceability) : La capacité du produit logiciel à être utilisé à la place d'un autre produit logiciel spécifié
pour le même but dans le même environnement (par exemple, la remplaçabilité d'une nouvelle version d'un produit logiciel est importante
pour l'utilisateur lors de la mise à niveau).
MODÈLE SQUARE

 Modèle ISO/CEI 25010:2011 ou bien SQuaRE (Software QUAlity Requirements and


Evaluation), est une évolution de la norme ISO9126.
• Le modèle SQuaRE propose 8 caractéristiques de qualité du produit logiciel: Capacité
fonctionnelle, Performances, Compatibilité, Utilisabilité, Fiabilité, Sécurité, Maintenabilité,
Transférabilité.
ÉVALUATION D’UN MODÈLE DE QUALITÉ

• La norme ISO 9126 définit les outils d’évaluation comme étant un ensemble d’attributs
de qualité liés à un ensemble de métriques.
• La relation entre les attributs de qualité et les métriques précise le processus
d’évaluation de qualité.

• Il existe trois niveaux d’évaluation :


• MÉTRIQUES : Indicateurs de propriétés élémentaires comparés à un seuil.
• CRITÈRES : Indicateurs de caractéristiques du produit Ic = f ( m1, m2, m3, ...)
• FACTEURS : Indicateurs d’objectifs à atteindre If = g ( Ic1, Ic2, Ic3, ....)
ÉVALUATION D’UN MODÈLE DE QUALITÉ

Les valeurs seuils associé à chaque mesure ne doivent pas être dépassées. Ces valeurs
sont comparées aux résultats des mesures pour évaluer la qualité.
PROCESSUS D’ÉVALUATION

Etape 1: Définir les exigences en établissant un modèle de qualité (facteurs et critères).


• Ces exigences peuvent varier d'un composant du produit à un autre.
Etape 2: Fixer les métriques de la qualité pour la préparation de l'évaluation
• Sélection des métriques de qualité.
• Définition des taux de satisfaction : Les échelles de valeurs doivent être divisées en portions
correspondant aux niveaux de satisfaction des exigences
• Définition des références et des critères d'appréciation.

Etape 3: Procéder à l'évaluation:


• La mesure: Les métriques sélectionnées sont appliquées au produit, donnant ainsi des valeurs.
• La notation: Pour chaque valeur mesurée, une note (de satisfaction) est attribuée.
• L’appréciation: En utilisant les critères d'appréciation, un résultat global de l'évaluation du
produit est obtenu.
NIVEAU DE QUALITÉ

• Les modèles de qualité attribuent des notes déterminant le niveau de qualité d’un logiciel en
se basant sur des métriques brutes.
• Ceci demande de résoudre deux contraintes:
• composer des métriques entre elles et qui ne sont pas définies de manière similaire.
• agréger les résultats des métriques afin de déterminer une note globale pour une
caractéristique donnée.
• Exemple: la norme ISO 9126 définit la sous-caractéristique : « facilité de modification »
comme la capacité d’un logiciel à intégrer de nouvelles implémentations".

Facilité de
modification

nombre de le nombre de la profondeur


la complexité
lignes de code méthodes par d’héritage
cyclomatique
(LOC) classe (DIT)
EVALUATION D’UN MODÈLE DE QUALITÉ

• En 1946, Stanley Smith Stevens a présenté une théorie des types de mesure employés jusqu’à présent par des
statisticiens:
1. Type Nominal : il correspond à des noms dont l’ordre n’a pas d’importance dans leur présentation, par
exemple : le sexe (féminin ou masculin), la profession (Etudiant, Enseignant, etc.), etc.
2. Type Ordinal : il permet de rajouter la notion d’ordre au type nominal. Par exemple, le niveau scolaire (Bac,
Bac+2, Bac+3, Bac+5), le degré de satisfaction (très satisfait, satisfait, insatisfait, très insatisfait), etc.
3. Type Intervalle : il permet de mesurer une propriété quantitative dont le zéro est fixé arbitrairement, un zéro
arbitraire est un zéro qui ne correspond pas à une absence comme par exemple la température (-10°, 0, +10°),
le temps (100 av. J.-C, 2015), etc.
4. Type Ratio (ou Rapport) : il permet aussi de mesurer une propriété quantitative mais cette fois-ci dont le
zéro correspond à une absence de la propriété, par exemple : l’âge, le salaire, la taille, la vitesse (0km/h,
80km/h), etc.
5. Type Absolu : C’est un cas particulier de type rapport, ce type consiste généralement à compter (1, 2, 3,…),
par exemple : le nombre d’erreurs trouvées, le nombre de machine, etc.
EVALUATION D’UN MODÈLE DE QUALITÉ

• Exemples :
mesure Interprétation
Note
Complexité 1-10 Programme simple, sans véritable risque 3
=E–N+p 11-20 Programme modérément complexe et risqué 2
21-50 Programme complexe et hautement risqué 1
> 50 Programme non testable et extrêmement risqué 0
ETUDE DE CAS

 Considérons les valeurs lues des métriques suivantes au cours de la phase de développement du logiciel X :
• Commentaires: 10/100=10%
• Nom des variables: Incompréhensibles
• Complexité : 3
• Nombre de lignes par module: >50 et < 100
• Les valeurs des métriques sont obtenues de la façon suivante :

Métrique Valeurs mesurées Tranche Valeur de


la
2 1 0
métrique
Commentaires 10/100=10% [100,20] ]20,10] ]10,0] 1
Nom des variables Incompréhensibles Significatifs Moyens Incompréhensible 0
s
Complexité 3 [0,3] ]3,5] ]5,…] 2
Nombre de lignes par module entre 50 et 100 [0,50] ]50,100[ ]100,…] 1
ETUDE DE CAS

La composition et l’agrégation des critères-métriques :


Nom du critère Code métrique coefficient
Auto-documentation Commentaires 0,5
Auto-documentation Nom des variables 0,5
Simplicité Commentaires 0,4
Simplicité Complexité 0,4
Simplicité Nb de lignes d’un module 0,2

La composition et l’agrégation des facteurs-critères :


Nom du facteur Nom du critère coefficient
Maintenabilité Simplicité 0,7
Maintenabilité Auto-documentation 0,3
Fiabilité Simplicité 1
ETUDE DE CAS

• Questions
• Représenter l’arborescence de cette méthode d’évaluation.
• Calculer la valeur de chaque critère
• Calculer la valeur de chaque facteur
• Calculer la valeur de la qualité mesurée du logiciel X
• Calculer la valeur de la qualité totale du logiciel X
ETUDE DE CAS

Commentaires

Simplicité Nb de SI imbriqués
Qualité du produit
Nb de lignes d’un module
Maintenabilité

Commentaires
Auto-documentation
Nom des variables

Commentaires

Fiabilité Simplicité Nb de SI imbriqués

Nb de lignes d’un module


ETUDE DE CAS
• Les critères:
• Valeur Auto-documentation = • La qualité totale (parfaite)
(1 * 0,5) + (0 * 0,5) = 0,5 • Valeur Auto-documentation = (2 * 0,5) + (2 * 0,5) = 2
• Valeur Simplicité = • Valeur Simplicité = (2 * 0,4) + (2 * 0,4) + (2 * 0,2) = 2
(1 * 0,4) + (2 * 0,4) + (1 * 0,2) = 1,4 • Valeur Maintenabilité = (2 * 0,7) + (2 * 0,3) = 2
• Les facteurs:
• Valeur Fiabilité = (2 * 1) = 2
• Valeur Maintenabilité =
• Qualité totale = (2 * 0,5) + (2 * 0,5) = 2
(0,5 * 0,3) + (1,4 * 0,7) = 1,13
• Valeur Fiabilité = (1,4 * 1) = 1,4
• La qualité mesurée:
• Pour l'évaluation de la qualité du logiciel X les
facteurs Maintenabilité et Fiabilité ont le même
poids. La valeur de la qualité du logiciel est : Qualité évaluée
• Qualité mesurée= (1,13 * 0,5) + (1,4 * 0,5) = 1,27
63%
" Vous ne pouvez pas gérer ce que vous ne contrôlez
pas, et vous ne pouvez pas contrôler ce que vous ne
mesurez pas " {DeMarco}

LA COMPLEXITÉ CYCLOMATIQUE
GRAPHE DE CONTRÔLE

• Graphe de flot de contrôle (abrégé en GFC, control flow graph ou CFG en anglais): représentation sous forme
de graphe de tous les chemins qui peuvent être suivis par un programme durant son exécution.
• Etant donné un programme S, son graphe de contrôle, noté [S], est un graphe orienté construit de la manière
suivante :
 les instructions correspondent aux nœuds (sommet)
 les conditions (des tests et boucles) sont associées aux arcs correspondants
 chaque graphe comporte un nœud «entrée» et un nœud « sortie» a
a
a c
b c

b
b d
itérative
séquentielle alternative
GRAPHE DE CONTRÔLE
GRAPHE DE CONTRÔLE
A
{
if(y<=0) B if(y<=0)
{y=x+1;} y>0 y<=0
else
{y=-x}
y=-x D C y=x+1

} A
A F while(y>=0)
B
{ B if(y<=0)
{ C x=x*2
if(y<=0) y>0 y<=0
while(y>=0) y<0
{y=x+1;} C y=x+
1 {x=x*2; D y=y-1
y=-x y=-x D y=y-1; }
} }
F F
GRAPHE DE CONTRÔLE A

B ReadLn(x);
 Transformer un Programme P en un Graphe orienté [P]:
 e: un sommet entrée(A) C if(x<=0)
 s: un sommet sortie(J) x<=0 x>0
 Un sommet correspond à un bloc d’instructions
 Un arc correspond à la possibilité de transfert de
x:=-x
D E x:=1-x

l’exécution d’un nœud à un autre


Begin f if (x=-1)
x=-1 x!=-1
ReadLn(x);
if(x<=0) then x:=-x x:=1 G H x:=x+1

else x:=1-x;
if (x=-1) then x:=1 I WriteLn(x)
else x:=x+1;
Writeln(x)
end J
{
if(y<=0)
CHEMIN DE CONTRÔLE
{x=y+1;}
if(y>0)
{x=y-1}
 A chaque exécution correspond un chemin de contrôle dans }
le graphe. A
 Une exécution possible correspond à un chemin de
contrôle dans le graphe de contrôle : B if(y<=0)

y<=0
 [A,B,C,D,F] est un chemin de contrôle exécutable.
y>0
 [A,B,D,E,F] est un chemin de contrôle exécutable. C x=y+1

 Une exécution non possible ne correspond pas à un


chemin de contrôle dans le graphe de contrôle: D if (y>0)
y>0
 [A,B,C,D,E,F] n’est pas un chemin exécutable.
 [A,B,D,F] n’est pas un chemin exécutable.
y>=0 E x=y-1

F
SWITCH-FOR-RETURN

1. Les switch sont considérés comme des if imbriqués.


2. Les boucles for sont considérées comme des boucles while spéciales.
3. Les return sont considérés comme des sauts à la fin des fonctions.
4. Ces graphes sont planaires pour des programmes structurés (ils ne le sont plus
nécessairement avec des instructions de type goto).
5. Il est possible de simplifier ces graphes si seuls les chemins nous intéressent. On
peut fusionner les séquences d'instructions non composées (et préserver le
nombre de chemins).
COMPLEXITÉ MCCABE

 La complexité Cyclomatique également référée comme complexité de programme ou complexité de


McCabe, a été introduite par Thomas McCabe en 1976 (McCABE, 1976).
 Elle est le calcul le plus largement répandu des métriques statiques, conçue pour être indépendante du
langage et du format de langage.
 La complexité cyclomatique d’une méthode correspond au nombre de chemins linéairement
indépendants qu'il est possible d'emprunter dans cette méthode, elle est définie par :

v(G)= E-N+2P
 E = le nombre d'arêtes du graphe,
 N = le nombre de nœuds du graphe,
 P = le nombre de composantes connexes du graphe
(dans notre cas : P=1 un seul ensemble de nœuds).
Ici, N=8, E=11 et P=1 donc v(G)=11-8+2=5
COMPLEXITÉ MCCABE

• Calcul direct du nombre de McCabe


– Produire un graphe de contrôle et l’analyser peut s’avérer long dans le cas de programmes complexes
– Mc Cabe a introduit une nouvelle manière de calculer la complexité structurelle:
• C=π+1

avec π le nombre de prédicats(décisions) du code


 Remarque:
 Une instruction IF > compte 1 pour chaque décision
 Une boucle FOR ou WHILE > compte 1 décision
 Une instruction CASE traitant N cas > N-1décision

Ici, π =4 (4 décisions), donc C=4+1=5


COMPLEXITÉ MCCABE

• Complexité cyclomatique de McCabe


• – V(F) = 12 – 11 + 2
• – V(F) = 1 + 2
• – V(F) = 3
COMPLEXITÉ MCCABE

 Ce nombre est l'une des plus importantes mesures de complexité afin d’estimer l’effort (nombre
de tests) nécessaire pour tester un logiciel (la couverture du code = Code coverage).
 Plus le nombre Cyclomatique est grand, plus il y aura de chemins d'exécution dans la fonction, et
plus elle sera difficile à comprendre et à tester.
 La complexité cyclomatique d'une méthode vaut au minimum 1, puisqu'il y a toujours au moins
un chemin.
 La valeur maximum du nombre cyclomatique peut être définie comme un critère de qualité dans
le plan qualité.
 Dans la pratique, il semble que la limite supérieure du nombre cyclomatique soit de 15 environ. Si
une méthode a plus que 15 chemins d'exécution il est difficile à comprendre et à tester alors il faut
refactoriser la méthode.
COMPLEXITÉ MCCABE

Créer le graphe de programme ci-dessous et calculer le nombre cyclomatique

v(G)= E-N+2
v(G)=
alors v(G)=

C=π+1
C=
alors C=
COMPLEXITÉ MCCABE

• Calculer le nombre cyclomatique

C=π+1 v(G)= E-N+2


C=3+1 v(G)= 10-8+2
alors C=4 alors v(G)=4
EXERCICES

• Calculer le nombre cyclomatique des programmes suivants:


void rech_dico (elem cle, elem t[], int taille, boolean &trouv, int
void sort(int *px, int n){ &A)
int i, j, temp; { int d, g, m; g=0; d=taille -1; A=(d+g) /2;
for(i=2;i<n; i++){ if (t[A]==cle) trouv=true;
for(j=1; j<i; j++){ else trouv=false;
if(px[i]<px[j]){ while (g <=d && !trouv){
temp=px[i]; m= (d+g) /2;
px[i]=px[j]; if (t[m]= =cle)
px[j]=temp; { trouv=true; A=m; }
} else if (t[m]> cle) g=m+1;
} else d=m-1;
} }
} }
COMPLEXITÉ DE HALSTEAD

 Les métriques de complexité de Halstead ont été développées par l’américain Maurice Halstead en
1977.
 Elles procurent une mesure quantitative de complexité liée à la distribution des variables et
instructions.
 Toutes les métriques d'Halstead sont dérivées du nombre d’opérandes ( jetons qui contiennent une
valeur) et d’opérateurs ( tout le reste: virgules, parenthèses, operateurs arithmétiques, ...)
 n1= nombre d’opérateurs uniques
 n2= nombre d'opérandes uniques (termes, constantes, variables)
 N1= nombre total d’apparition de ces opérateurs
 N2= nombre total d’apparition de ces opérandes. Exemple : a := a + 1;
◦ 3 opérateurs + := ;
◦ 2 opérandes a 1
COMPLEXITÉ DE HALSTEAD

Une fois que le code a été écrit, cette mesure peut être appliquée pour prédire la difficulté d’un
programme et d’autres métriques, en employant les équations de Halstead :
 Vocabulaire du programme (Vocabulary size) n = n1 + n2
 Taille observée du programme (Program length) N = N1 + N2
 Volume du programme (Program volume): Estimation du nombre de bits nécessaires pour coder
le programme mesuré: V = N Log2 (n1 + n2) bits
 Taille estimée du programme Le = n1Log2(n1) + n2Log2(n2)
COMPLEXITÉ DE HALSTEAD

• Ces chiffres (n1, n2, N1, N2) sont aussi la base pour calculer les métriques suivantes:
𝒏𝟏 𝑵𝟐
 Le Niveau de difficulté (Difficulty level), où D = × .
𝟐 𝒏𝟐
𝟏
 Niveau du programme (Program level), où L = .
𝑫
 Effort d’implémentation (Effort to implement), où : E = V x D .
𝑬
 Temps d’implémentation (Implementation time) en seconde , où : T = .
𝟏𝟖
 Nombre de bugs estimés dans un module ou une fonction (Number of delivered bugs), où :

𝑬𝟐/𝟑
B= , (S représente l'habileté du développeur).
𝑺
COMPLEXITÉ DE HALSTEAD

 Exercice : Calculer les mesures de Halstead pour le Opérateurs Opérandes


programme suivant :
z = 0; = 3 z 4
while x > 0
z = z + y; ; 5 0 2
x = x - 1;
end-while;
w/ew 1 x 3
print (z); > 1 y 1
 Solution:
+ 1 1 1
– Opérateurs : = ; while/end-while > + - print ()
- 1
• – Opérandes : = z 0 x y 1
• – η1 = 8, η2 = 5 alors η=13 print 1
• – N1= 14, N2=11 alors N=24 () 1
COMPLEXITÉ DE HALSTEAD

• Volume de programme:
V = N×log2(η1+η2)
V = 24×log2(14)= 24 × 3.8 = 91.38 bits
Le volume d’une fonction devrait être compris entre 20 et 1000.
• Le Niveau de difficulté (Difficulty level):
𝑛1 𝑁2
D = × = (8/2)X(11/5)=8.8
2 𝑛2
• Effort d’implémentation :
E = V x D = 91.38X8.8=804.14
• Temps d’implémentation :
𝑬
T = = 804.14/18 =44.67 secondes
𝟏𝟖
• Estimation de la taille de programme
Le = η1log2(η1) + η2log2(η2)
Le = 8×log2(8) + 5×log2(5) = 8×3+5×2.32=35.6
Ici, Le est supérieure de N (35.6>24)
COMPLEXITÉ DE HALSTEAD
operators occurrence operands occurrence

sort 1 x 7
int sort (int x[ ], int n) int 4 n 3
{
() 5 i 8
int i, j, save, im1;
/*This function sorts array x in ascending order */ , 4 j 7
If (n< 2) return 1; [] 7 save 3
for (i=2; i< =n; i++) if 2 im1 3
{
< 2 2 2
im1=i-1;
for (j=1; j< =im1; j++) ; 11 1 3
if (x[i] < x[j]) for 2 0 1
{ = 6
Save = x[i];
– 1
x[i] = x[j];
x[j] = save; <= 2
} ++ 2
} return 2
return 0;
{} 3
}
n1=15 N1=54 n2=9 N2=37
COMPLEXITÉ DE HALSTEAD
operators occurrence operands occurrence

sort 1 x 7
• Program Length int 4 n 3
N =N1 + N2= 91 () 5 i 8
• Vocabulary , 4 j 7
n =n1 + n2= 24
[] 7 save 3
• Program Volume
if 2 im1 3
V =N * log2(n)= 417.23 bits
• estimated program length < 2 2 2
Le= n1log2(n1) + n2log2(n2)= 86.51 ; 11 1 3
• Program Difficulty for 2 0 1
D =(n1/2)*(N2/n2)=1/L=37.03 = 6
• Program Level – 1
L =1/D= 0.027 <= 2
• Programming Effort
++ 2
E = V / L = D * V = 15450
return 2
• Programming Time
T =E/18= 1931 seconds = 32 minutes {} 3
n1=15 N1=54 n2=9 N2=37
" Vous ne pouvez pas gérer ce que vous ne contrôlez
pas, et vous ne pouvez pas contrôler ce que vous ne
mesurez pas " {DeMarco}

MÉTRIQUES DE CODE
MÉTRIQUES DES LIGNES DE CODE

 Les mesures des lignes de code (LOC, Lines of Code) sont les mesures les plus
traditionnellement utilisées pour quantifier la complexité d’un logiciel. Elles sont simples,
faciles à compter et très faciles à comprendre.
 Elles ne prennent cependant pas en compte le contenu d'intelligence et la disposition du code.
 On peut distinguer les types de lignes suivantes:
• LOCphy (Number of physical lines): le nombre total des lignes physiques dans tous les
fichiers source.
• LOCpro (Number of program lines): le nombre de lignes de programme comme : les
déclarations, les définitions, les directives et les code.
• LOCcom (Number of commented lines): le nombre de lignes de commentaires,
• LOCbl (Number of blank lines): le nombre de lignes vides.
• DC=LOCcom/LOCphy : densité de commentaire.
" Vous ne pouvez pas gérer ce que vous ne contrôlez
pas, et vous ne pouvez pas contrôler ce que vous ne
mesurez pas " {DeMarco}

CHIDAMBER ET
LES MÉTRIQUES DE
KEMERER
CONCEPTION OBJET

• Chidamber et Kemerer (en 1994), ils proposent six métriques fortement


liées aux concepts orientés objets :

Manque de
Réponses
cohésion des
pour une
méthodes
classe RFC
LOCM

Nombre Couplage
d’enfants entre classes
NOC CBO

Méthodes Profondeur
pondérées de l’arbre
par classe d’héritage
WMC DIT
PRINCIPES AVANCÉS DE CONCEPTION OBJET

Responsabilité unique (SRP, single responsability principle)

• «Une classe ne doit avoir qu'une seule et unique raison de changer». Il


stipule qu'une classe ne doit comporter qu'une seule responsabilité.
• La classe ne doit offrir que des services fortement reliés. À l'évidence, ce
principe est la mise en pratique de l'idée de garder une cohésion forte.
• Si une classe possède plusieurs responsabilités, il est possible de la diviser. En
séparant les responsabilités en différentes classes, le code source devient plus
clair, modulaire et facile à maintenir et tester.
PRINCIPES AVANCÉS DE CONCEPTION OBJET

Principe de ségrégation des interfaces (ISP, Interface Ségrégation


Principle)

• «un client ne doit pas être forcé à dépendre d'interfaces qu'il n'utilise pas». Le but
de ce principe est d'éviter que les classes qui se servent des services d'une classe
donnée n'aient une visibilité sur tous les services rendus par la classe.
• chaque client ne doit voir que les services qu'il utilise réellement. Lorsque ce n'est
pas le cas, chaque client voit une interface trop riche dont une partie ne l'intéresse
pas. Par la suite, le client peut être affecté par des changements de l'interface.
• Dans cet ordre d'idées, de nombreuses interfaces particulières aux besoins de la
classe cliente sont meilleures qu'une grande interface générique. Ce principe est
également lié à la cohésion forte.
COUPLAGE & COHÉSION

Couplage:

• «le degré d’interaction entre deux modules » ou bien «le degré


d'interdépendance entre modules» .
• Caractériser la réutilisabilité et la réponse à la modification d’un module,
notamment dans le cas d’opérations de maintenance.
• Le but de mesurer le couplage est d'identifier les dépendances entre les classes
d'un système; et de pouvoir localiser, par exemple, les classes qui sont trop
dépendantes.
COUPLAGE & COHÉSION

Cohésion :

• «le degré de similitude qu’ont les actions de ses différents composants».

• La mesure de la cohésion d’un module est un bon indicateur pour évaluer la robustesse,
la fiabilité ou encore la compréhensibilité d’un programme. C'est un signe que les
responsabilités ont été distribuées de manière inappropriée.
• Un haut degré de cohésion correspond souvent à un faible degré de couplage et vice
versa.
• La forte cohésion favorise :
• la compréhension de la classe,
• la maintenance de la classe,
• la réutilisation des classes ou modules.
MÉTRIQUE DE CHIDAMBER ET KEMERER
LOCM: LACK OF COHESION OF METHODS

• Le nombre de méthodes prises deux à deux (paires de méthodes) ne partageant pas des
instances de variables de la classe.
• une cohésion élevée est favorable dans la conception orientée objet, parce qu'elle tend à promouvoir
l'encapsulation dans la classe, ceci apportant une simplicité et une réutilisabilité élevées de la classe.

• Une définition plus formelle et utilisant la théorie des ensembles est la suivante.
• Soit 𝑙𝑖 l'ensemble des variables d'instance employées par la méthode 𝑀𝑖 . Soit P l'ensemble des intersections
vides entre 𝑙𝑖 et 𝑙𝑗 et Q l'ensemble des intersections non vides entre 𝑙𝑖 et 𝑙𝑗 .
• On calcule la métrique de la manière suivante :

𝑳𝑪𝑶𝑴 = 𝑷 − 𝑸 , Si 𝑷 > 𝑸 autrement 0.


MÉTRIQUE DE CHIDAMBER ET KEMERER
LOCM: LACK OF COHESION OF METHODS

𝑳𝑪𝑶𝑴 = 𝑷 − 𝑸 , Si 𝑷 > 𝑸 autrement 0.

•On considère une class C avec 3 méthodes M1, M2 et M3.


•Les attributs utilisés pour chaque méthode sont:
•{l1}={a, b, c, d, e}
•{l2}={a, b, c}
•{l3}={x, y, z}

•Alors : {I1}  {I2} est un ensemble non vide, mais {I1}  {I3} et {I2} 
{I3} sont des ensemble vide.
•Donc : LCOM = | P | - | Q | = 2 – 1 = 1
MÉTRIQUE DE CHIDAMBER ET KEMERER
public class TestCohesion{
LOCM: LACK OF COHESION OF METHODS
private int attributeA;
private int attributeB;
private int attributeC;
private int attributeD;
private int attributeE;
Graphe de classe TestCohesion public void method1() {
System.out.println(attributeA);
method1 attributeA System.out.println(attributeC);}
public void method2() {
System.out.println(attributeA);
method2 attributeB System.out.println(attributeC);}
public void method3() {
method3 attributeC System.out.println(attributeB);
System.out.println(attributeD);
attributeD System.out.println(attributeE);}
method4 public void method4() {
System.out.println(attributeB);
attributeE System.out.println(attributeD);}
method5
public void method5() {
System.out.println(attributeB);
System.out.println(attributeD);
la classe compte cinq attributs et cinq méthodes. System.out.println(attributeE);}
}
MÉTRIQUE DE CHIDAMBER ET KEMERER
L O C M : L AC K O F C O H E S I O N O F M E T H O D S

• Soit 𝑙𝑖 l'ensemble des variables d'instance employées par la méthode 𝑀𝑖 . Soit P l'ensemble des
intersections vides entre 𝑙𝑖 et 𝑙𝑗 et Q l'ensemble des intersections non vides entre 𝑙𝑖 et 𝑙𝑗 .

Les paires de méthodes n'ont pas d'attributs en commun


Method1, Method3 ={ }
Method1, Method4 = { } Graphe de classe TestCohesion
Method1, Method5 = { }
Method2, Method3 = { } method1 attributeA
Method2, Method3 = { }
Method2, Method3 = { } method2 attributeB
donc P est égale à six (P = 6)
Les paires de méthodes ont au moins un attribut en commun : method3 attributeC
Method1, Method2 = {attributeA, attributeC}
Method3, Method4 = {attributeB, attributeD} method4 attributeD
Method3, Method5 = {attributeB, attributeD, attributeE }
Method4, Method5 = {attributeB, attributeD} attributeE
method5
donc Q est égal à quatre (Q = 4).
MÉTRIQUE DE CHIDAMBER ET KEMERER
LOCM: LACK OF COHESION OF METHODS

Graphe de classe TestCohesion


• Les paires de méthodes n'ont pas d'attributs en
commun method1 attributeA
• P est égale à six (P = 6)
• Les paires de méthodes ont au moins un attribut en method2 attributeB
commun :
• Q est égal à quatre (Q = 4). method3 attributeC

method4 attributeD

attributeE
method5
𝑳𝑪𝑶𝑴 = 𝑷 − 𝑸 = 𝟔 − 𝟒 = 2
Plus la valeur est élevée, plus le manque de cohésion est élevé, c'est-à-dire qu'il y a plus
de méthodes sans attributs en commun que de méthodes utilisant des attributs en
commun
MÉTRIQUE DE CHIDAMBER ET KEMERER
CBO: COUPLING BETWEEN OBJECT

• Mesurer la dépendance entre classes dans la conception du système,


• La mesure du couplage d'une classe est représentée par le nombre de classes
couplées avec celle-ci.
• Un fort couplage représenté par une grande valeur indique que la classe sera plus
complexe et plus difficile à comprendre tout en ayant une réutilisabilité diminuée,
moins de facilité de modification et moins de facilité de maintenance.
MÉTRIQUE DE CHIDAMBER ET KEMERER
CBO: COUPLING BETWEEN OBJECT

public class ClassA extends ClassB


• Pour une classe A, CBO(A) est le nombre de classes auxquelles la implements InterfaceF {
classe A est couplée, on inclut le couplage avec la superclasse. ClassC classC;

• Ex: la ClassA a une relation de couplage avec les classes : ClassB, public ClassA(ClassC classC) {
ClassC, ClassD, ClassE et InterfnceF. this.classC = classC;
}
• Donc, CBO(ClassA )= 5.
public ClassE faire(ClassD classD) {
return new ClassE();
}

public int foo() {


return classC.get.Value();
}

public void foo(int var) {


classC.add(var);
}
}
MÉTRIQUE DE CHIDAMBER ET KEMERER
WMC: WEIGHTED METHODS PER CLASS

• Mesure la complexité d’une classe en se basant sur la complexité de ses méthodes.


Elle est formalisée par : WMC = σ𝒏𝒊=𝟏 𝑪𝒊 , si la classe définit n méthodes, Ci dénote la
complexité individuelle de chaque méthode.
• Le nombre de méthodes et leurs complexités dans une classe permettra de prédire
le délai et l'effort exigés dans la construction et la maintenance de cette classe.
• Si toutes les complexités de la méthode sont considérées comme une unité,
• alors WMC = n, le nombre de méthodes.
MÉTRIQUE DE CHIDAMBER ET KEMERER
WMC: WEIGHTED METHODS PER CLASS

Class foo {
int local_var;
int *pInt;
public:
foo(){local var = 1; Supposons toutes les méthodes avec la même
pInt = new int;} complexité:
WMC (foo) = 4
int f1(){return local_var;}

int f2(){return ++local_var;}

int f3(){return 1/f1();}


}
MÉTRIQUE DE CHIDAMBER ET KEMERER
DIT: DEPTH OF INHERITANCE TREE

• La distance maximale entre un nœud et la racine de


l’arbre d’héritage de la classe concernée.
• Une classe ayant une valeur plus élevée impliquera une
complexité plus grande et une certaine difficulté à
prédire le comportement de la classe;
• En Java, où toutes les classes héritent de Object, la valeur
minimale de DIT est 1

DIT (D1)=4
MÉTRIQUE DE CHIDAMBER ET KEMERER
NOC: NUMBER OF CHILDREN

• le nombre de sous-classes dépendant


immédiatement (directement) d’une classe
donnée par une relation d’héritage.
• Un nombre de classes descendantes plus élevé
montrera certains problèmes qualitatifs et de
performance dans la conception du système.

NOC (B1)=2
MÉTRIQUE DE CHIDAMBER ET KEMERER
RFC: RESPONSE FOR CLASS

• l’ensemble des méthodes qui peuvent être exécutées Class C1{


en réponse à un message reçu par un objet de la M1(){…};
classe considérée.
M2 (){…};
• Réunion de toutes les méthodes de la classe avec toutes
M3(){… C2.M1()};}
les méthodes appelées directement par celles-ci ({RS}).
Class C2{
RFC = |RS|
M1(){…};}
• Un nombre de méthodes invoquées plus élevé
en réponse au message signifie une complexité
RFC = 3 + 1 = 4
de classe plus élevée.
MÉTRIQUE DE CHIDAMBER ET KEMERER
RFC: RESPONSE FOR CLASS
public class ClassA
{
• Réponses
private ClassB classB = pour une classe
new ClassB(); RFC (Response For Class)
public void doSomething(){ RFC=6
System.out.println ( "doSomething"); 1. new ClassB()
}
public void doSomethingBasedOnClassB(){ 2. doSomething()
System.out.println (classB.toString()); 3. System.out.println(..)
}
} 4. doSomethingBasedOnClassB()
5. ClassB.toString()
public class ClassB
{ 6. Le constructeur ClassA()
private ClassA classA = new ClassA();
public void doSomethingBasedOneClassA(){
System.out.println (classA.toString());
}

public String toString(){


return "classB";
}
}
" Vous ne pouvez pas gérer ce que vous ne contrôlez
pas, et vous ne pouvez pas contrôler ce que vous ne
mesurez pas " {DeMarco}

MÉTRIQUES DE STABILITÉ ET
D’ABSTRACTIVITÉ
INDICE D’INSTABILITÉ

 L'indice d'instabilité d'un paquetage est défini par la formule suivante :

𝑪𝒆
𝑰=
𝑪𝒆 + 𝑪𝒂
 Avec :
 Ca : Couplage afférent, le nombre de classes en dehors du paquetage qui
dépendent de classes de ce paquetage.
 Ce : Couplage efférent, le nombre de classes de ce paquetage qui dépendent
de classes en dehors de ce paquetage.
INDICE D’INSTABILITÉ

• Plus une classe est référencée (Afferent coupling), plus elle est importante dans le code
source. Plus cette valeur est élevée, plus l’impact des modifications effectuées sur cette classe
sera grand. Une valeur de zéro signifie que personne n’utilise cette classe et qu’il s’agit
peut-être de code mort.
• Un couplage efférent (Efferent coupling) important indique que la classe ne respecte pas le
principe de responsabilité unique (Single responsability principle). En outre, plus le nombre de
dépendances augmente, plus le risque d’instabilité est élevé.

𝑪𝒆
𝑰=
𝑪𝒆 + 𝑪𝒂
INDICE D’INSTABILITÉ

 l’Afferent coupling : 𝑪𝒆
𝑰=
 Forme : 2 𝑪𝒆 + 𝑪𝒂
 Rectangle : 1
 Carre et Cercle : 0
 L’Efferent coupling :
 Forme : 0
 les autres classes: 1
 Si on reprend l’exemple, toute modification de Forme impactera directement Rectangle et
Cercle, et indirectement Carre
INDICE D’INSTABILITÉ

𝑪𝒆 𝟒 𝑪𝒆 𝟐
𝑰= = =0.67 𝑰= = =0.33
𝑪𝒆+𝑪𝒂 𝟒+𝟐 𝑪𝒆+𝑪𝒂 𝟒+𝟐
INDICE D’INSTABILITÉ

• Package 3 : Ce = 0; Ca =1; Instabilité = 0


𝑪𝒆
• Package 1 : Ce = 1; Ca =3; Instabilité = 1/4 =0,25 𝑰=
𝑪𝒆 + 𝑪𝒂
• Package 2 : Ce = 3; Ca =0; Instabilité = 1
INDICE D’INSTABILITÉ

Dans l'exemple suivant on va calculer la stabilité du paquet Pl.

• Il y a deux relations des classes intérieures du


paquet qui ont comme destination des classes
extérieures au paquet,
• Donc : Ce = 2
• on a 7 classes externes au paquet qui ont
dépendance avec les classes internes
• Donc Ca = 7.
𝑪𝒆 𝟐
• 𝑰= = = 𝟎. 𝟐𝟐
𝑪𝒆+𝑪𝒂 𝟐+𝟕
INDICE DE SPÉCIALISATION

• L'indice de spécialisation d'une classe est défini par la formule suivante :

𝑵𝑶𝑹𝑴 × 𝑫𝑰𝑻
𝑵𝑶𝑴
• Avec :
 NORM : Number of Overriden Methods, le nombre de méthodes redéfinies.
 DIT : Depth in Inheritance Tree, la profondeur dans l'arbre d'héritage.
 NOM : Number Of Methods, le nombre de méthodes de la classe.
• Il est ensuite possible d'effectuer des moyennes pour un paquetage, un ensemble de paquetages, ou un
projet.
INDICE DE SPÉCIALISATION

Cet indice augmente quand :


 le nombre de méthodes redéfinies augmente, 𝑵𝑶𝑹𝑴 × 𝑫𝑰𝑻
 la profondeur d'héritage augmente. 𝑵𝑶𝑴
Il diminue quand :
 le nombre de méthodes spécifiques à la classe augmente,
 le nombre de méthodes redéfinies diminue.
Cet indice peut-être considéré comme trop élevé lorsqu'il est supérieur à 1.5.
INDICE DE SPÉCIALISATION

• Calcul de l'indice 𝑵𝑶𝑹𝑴 × 𝑫𝑰𝑻


• Pour la classe 3 de cet exemple, on a donc : 𝑵𝑶𝑴
• NORM = 3, puisqu'on redéfinit trois méthodes.
• DIT = 3, il s'agit de la profondeur de la classe 3 dans
l'arbre d'héritage.
• NOM = 3, puisqu’au total, la classe 3 possède trois
méthodes (les trois méthodes redéfinies).
• Dans cet exemple, l'indice de spécialisation vaut donc (3*3/3) = 3.
• Il s'agit d'un indice de spécialisation élevé et cette classe gagnerait à être
refactorisée.
" Vous ne pouvez pas gérer ce que vous ne contrôlez
pas, et vous ne pouvez pas contrôler ce que vous ne
mesurez pas " {DeMarco}

ANALYSE QUALITATIVE DU LOGICIEL


ANALYSE QUALITATIVE DU LOGICIEL

 Effectuer une série de revues du logiciel, la plupart du temps manuellement.


 Cette analyse qualitative se fonde sur les informations recueillies au cours de
l’analyse quantitative afin de cibler les revues sur les points sensibles du logiciel.
 Une revue est un examen détaillé d’une spécification, d’une conception ou
d’une implémentation par une personne ou un groupe de personnes, afin de
déceler des fautes, des violations de normes de développement ou d'autres
problèmes.
REVUE D’ARCHITECTURE

 Analyser la structuration des composants du logiciel de manière à détecter


d’éventuels points d’inefficience pouvant être corrigés par refactoring.
 Pour analyser cette structuration, il est nécessaire de se fonder sur la documentation
du logiciel. Généralement, l’architecture d’un logiciel peut être représentée
efficacement au travers de diagrammes UML permettant de s’abstraire du code et de
dégager ainsi la structure du logiciel.
 Les problèmes détectés par les revues d’architecture sont souvent très difficiles à
corriger, car ils touchent à la conception même du logiciel.
 Malheureusement pour remédier à ce genre de problème, il faut généralement
effectuer une réécriture complète.
REVUES DE CODE

 Les revues de code peuvent être pour partie automatisées, mais elles nécessitent toujours le
jugement humain pour déterminer si du code doit être refondu ou non.
 Les revues de code automatisées
• Il existe plusieurs outils capables d’analyser le code d’un logiciel pour identifier de mauvaises
pratiques de programmation.
 Les revues de code manuelles.
 Les revues de code manuelles consistent tout simplement à lire le code.
 Idéalement, ces revues de code doivent être menées par une ou plusieurs personnes d’expérience
extérieures au projet:
 l’expérience permet de détecter plus facilement les problèmes.
 le fait d’être extérieur au projet permet d’avoir un œil neuf sur ce qui a été fait.
DÉFAUTS TYPIQUES

Parmi les défauts typiques détectés par la revue de code:


• code mort : variables ou paramètres inutilisés, importations de packages inutiles.
• règles de nommage : respect des bonnes pratiques dans le nommage des différentes entités de
programmation (classes, méthodes, packages, variables).
• règles de formatage du code : lignes de code trop longues, mauvaise utilisation des délimiteurs
de code, etc.
• règles sur la taille du code : classes ou méthodes trop longues, listes de paramètres excessives,
etc.
• règles sur la gestion des exceptions : clauses catch sans contenu, utilisation abusive de la classe
Exception, etc.
• règles sur la documentation javadoc : vérification de la présence de documentation, vérification
de l’exhaustivité de la documentation, etc.
EXEMPLE

Programme 1 Programme 2 Programme 3


Trouver les 4 Trouver les 5 erreurs Trouver les 5 erreurs
erreurs
EXEMPLE
DÉFAUTS TYPIQUES
EXEMPLE
EXEMPLE
SONARQUBE
INTÉRÊT

• Logiciel open source de gestion de la qualité du code.


• Inspecter le code source des logiciels et applications en développement
• détecter des bugs, vulnérabilités de sécurités, instances de code dupliqué et autres anomalies
pouvant nuire à la qualité du code source, et ainsi au fonctionnement de l’application qui en résulte.
• Aider les développeurs à créer un code d’une meilleure qualité, tout en simplifiant le processus
de développement.
RAPPORTS

SonarQube génère 7 types de rapports chacun


couvrant un aspect de sa qualité :

• Architecture et design de l’application


• Test unitaire (analyse de parties précises du code)
• Codes dupliqués
• Bugs potentiels
• Code complexe
• Règles de programmation (les bonnes règles du
langage en question)
• Commentaires
UTILISATION

Travaux Pratiques

Vous aimerez peut-être aussi