Synthèse OO

Synthèse des métriques
pour qualifier
l’Orienté-Objet
1 LES MÉTRIQUES PROPOSÉES PAR CHIDAMBER ET KEMERER 3
2 LES MÉTRIQUES PROPOSÉES PAR LI ET HENRY 10
2.1 MÉTRIQUES REPRISES DES PROPOSITIONS DE CHIDAMBER ET KEMERER ......................................10

2.2 LES 5 NOUVELLES MÉTRIQUES DE LI ET HENRY .......................................................................10
3 LES MÉTRIQUES PROPOSÉES PAR ABREU, GOULÃO ET ESTEVES (MOOD)

15
4 APPROCHES DESCENDANTES ET MÉTRIQUES RÉSULTANTES 24
4.1 L’APPROCHE INITIALE DE ABREU ET CARAPUÇA ......................................................................24

4.1.1 CRITIQUE DE L’APPROCHE DE ABREU ET CARAPUÇA .................................................................25
4.2 LE MODÈLE HIÉRARCHIQUE DE BANSIYA ..................................................................................25
4.2.1 LE MODÈLE QUALITATIF DE DROMEY ......................................................................................25
4.2.2 QMOOD ..........................................................................................................................26
4.2.2.1 Définition des propriétés ..............................................................................................27
4.2.2.2 Métriques proposées. ...................................................................................................28
4.2.2.3 Méthodes d’obtention de ces métriques........................................................................32
4.2.3 CRITIQUE DU MODÈLE HIÉRARCHIQUE DE BANSIYA ....................................................................35
4.2.4 MÉTRIQUES ISSUES D’UNE DÉMARCHE ASCENDANTE ...................................................................36
4.2.4.1 Utilisabilité ...................................................................................................................36
4.2.4.2 Considérations générales ..............................................................................................37
4.2.5 LA PLACE PARTICULIÈRE DES PROPOSITIONS DE ABREU, GOULÃO ET ESTEVES ...............................37
4.2.6 MÉTHODES DESCENDANTES ....................................................................................................37
4.2.7 LA VALIDATION ...................................................................................................................38
4.2.7.1 Validation théorique .....................................................................................................38
4.2.7.2 Validation empirique ....................................................................................................39
La référence dans le domaine est la proposition S. R. Chidamber et C. F. Kemerer dans " A
metrics suite for object oriented design " [S. R. Chidamber & C. F. Kemerer - 1994]. Cette
proposition est en effet systématiquement citée dans les bibliographies des travaux récents sur
les métriques orientées objets. Elle est également utilisée industriellement [NASA - SATC -
1997].
Une présentation des 6 métriques proposées par ces auteurs est donc incontournable.
1 Les métriques proposées par Chidamber et

Kemerer
METRIQUE
WMC - Weighted Methods per Class
Définition
C'est la somme des complexités de toutes les méthodes. WMC est égal au nombre de méthodes
locales lorsque la complexité de toutes les méthodes est égal à 1.
Interprétation
WMC est un reflet de la complexité
Attributs mesurés
- Prédiction du temps et de l’effort nécessaire au développement et à la maintenance d’une classe,
plus une classe a de méthodes, plus elle demandera de travail.
- Impact sur la réutilisabilité, par le nombre de méthodes dont vont hériter les classes dérivées.
- Evaluation de la réutilisabilité. Un WMC élevé étant le signe d’une limitation de cet attribut, la
spécificité de l’application étant plus grande.
Formule et méthodes d’obtention

Soit c1,…,cn la complexité des méthodes M1,…,Mn de la classe C. WMC= ∑ci
Eléments de coûts
Contexte d’utilisation
Références bibliographiques
- S. R. Chidamber et C. F. Kemerer - “A Metric Suite for Object Oriented Design”, IEEE
Transactions on Software Engineering, Juin 1994.
- Dr. Linda H. Rosenberg - “Applying and Interpreting Object Oriented Metrics”, IEEE
- V. R. Basili, L. C. Briand et W. L. Melo- “A validation of Object-Oriented Design Metrics as

Quality Indicators”, IEEE.
- Jagdish Bansiya – “A Hierarchical Model For Quality Assessment Of Object Oriented Designs”,
Juin 1998.
METRIQUE
DIT - Depth of Inheritance Tree
Définition
c'est la profondeur de l’héritage de la classe.
Interprétation
DIT est un reflet de la complexité (cf. Note) via la portée des ancêtres.
Attributs mesurés
- Evalue la complexité de la classe. Le comportement de la classe étant plus difficile à comprendre
quand le nombre de méthodes héritées croît.
- Evalue la complexité globale. La conception est plus complexe puisqu’il y a plus de classes et de
méthodes à développer.
- Evalue la réutilisabilité de la classe. Plus une classe est loin dans la hiérarchie, moins elle est
générique et moins son comportement est prévisible..

nombre maximum de classes ancêtres de la classe pour atteindre la (une) racine
Eléments de coûts

Juin 1998.
METRIQUE
NOC - Number Of Children
Définition
c'est le nombre de classes immédiatement dérivées d’une classe.
Interprétation
NOC est un reflet de l’impact potentiel d’une classe sur ses descendants.
Attributs mesurés
- Evalue la réutilisabilité. Une classe ayant de nombreux enfants étant très générique.
- Evalue une mauvaise abstraction. Une classe ayant de nombreuses classes dérivées ayant une plus
grande probabilité d’être improprement abstraite.
- Evalue l’influence sur le système et sur l’effort de test. Une classe ayant de nombreuses classes
dérivées a un impact fort sur la hiérarchie de classes. Un effort de tests particulier devra lui être
appliqué.
Eléments de coûts

Juin 1998.
METRIQUE
CBO - Coupling Between Object classes
Définition
nombre de couplages entre une classe et toutes les autres classes du système, hors les classes dans
la hiérarchie d’héritage. Deux classes sont dites couplées si une méthode de l’une utilise une
méthode ou un attribut de l’autre.
Interprétation
CBO est un reflet de l’interdépendance entre les constituants du système.
Attributs mesurés
- Evalue la modularité et la réutilisabilité. Plus une classe est couplée aux autres, moins elle est
modulaire et réutilisable.
- Evalue la modularité et l’effort de maintenance. Plus une classe est couplée aux autres, plus une
modification de celle-ci risque d’affecter d’autres parties du système.
- Evalue la testabilité. Plus une classe est couplée aux autres, moins il sera aisé de vérifier toutes les
interactions possibles.
Eléments de coûts

Juin 1998.
METRIQUE
RFC - Response For a Class
Définition
C'est le nombre de l’ensemble des méthodes potentiellement appelées par une classe en réponse à
un message d’un objet de la classe ou d’une méthode de la classe, y compris les méthodes
accessibles dans la hiérarchie des classes.
Interprétation
RFC est un reflet du niveau de communication potentiel entre une classe et les autres.
Attributs mesurés
- Evaluation de la testabilité. Plus une classe invoque de méthodes de diverses origines, plus elle est
compliquée à comprendre.
- Evaluation de la complexité. Plus une classe invoque de méthodes, plus elle est complexe.
- Evaluation de l’effort de test. Plus une classe est complexe, plus l’effort de test sera important

Nombre de méthodes dans la classe + celles dans la hiérarchie + méthodes potentiellement
appelées par les méthodes de la classe.
Eléments de coûts

Juin 1998.
METRIQUE
LCOM - Lack of COhesion in Methods
Définition
Mesure la non corrélation des méthodes et des variables de la classe. C'est le nombre de méthodes
prisent deux à deux ne partageant pas des instances de variables de la classe, moins, le nombre de
méthodes prisent deux à deux partageant des instances de variables de la classe. Si cette valeur est
négative, LCOM est fixée égale à zéro.
Interprétation
une classe est cohérente (a de la cohésion) si ses méthodes agissent sur le même ensemble de
données.
Attributs mesurés
- Evalue l’encapsulation. Une classe cohérente promouvant celle-ci.
- Evalue les défauts de conception de classes. Une classe peu cohérente devant sans doute être éclatée
en plusieurs autres classes plus cohérentes.
- Evalue la complexité. Une classe disparate augmentant la probabilité d’erreur durant le

développement.
- Evalue la réutilisabilité. Une forte cohésion implique une réutilisation simple.
Eléments de coûts

Juin 1998.
Notes : Plusieurs particularités fondamentales de la conception des systèmes orientés objets

ne sont pas ou peu capturées :
• Abstraction (classes abstraites par exemple) ;
• Encapsulation (parties privées d’une classe par exemple) ;
• Polymorphisme (méthodes virtuelles d’une classe) ;
• Service offert (partie publique d’une classe) ;
• Terminaison d’arborescence (classes non dérivables) ;
• Configurations spécifiques des classes proches et éloignées de la racine.
2 Les métriques proposées par Li et Henry
Cette proposition reprend cinq des six métriques de Chidamber et Kemerer, en y ajoutant cinq
nouvelles. Parmi ces dernières, deux sont centrées sur la mesure du couplage entre objets, les
trois autres évaluant leur taille.
2.1 Métriques reprises des propositions de

Chidamber et Kemerer
Il s’agit des métriques DIT, NOC, RFC, LCOM et WMC. La métrique CBO n’étant pas
retenue dans cette suite puisque d’autres sont proposées pour évaluer le couplage.
Le couplage par héritage est quant à lui estimé correctement appréhendé par les indicateurs
DIT et NOC.
Le mode de calcul de la métrique LCOM étant modifié pour devenir : le nombre de jeux
disjoints de méthodes locales à la classe dont au moins une instance de variable de classe est
partagée entre elles.
2.2 Les 5 nouvelles métriques de Li et Henry

METRIQUE
MPC - Message Passing Coupling
Définition
nombre de messages envoyés par une classe en direction des autres classes du système (nombre
de méthodes invoquées).
Interprétation
le nombre de messages envoyés par une classe peut indiquer combien l’implémentation de ses
méthodes dépend des autres classes.
Attributs mesurés
- Evalue le couplage sortant d’une classe.

Compter le nombre de méthodes invoquées dans l’implémentation des méthode de la classe.
Eléments de coûts
Juin 1998.
METRIQUE
DAC - Data Abstraction Coupling
Définition
la définition de cette métrique est ambiguë. C’est pourquoi les deux interprétations possibles sont
fournies :
1) nombre de types de données abstraites définit dans une classe (classes dont la définition est
incluse dans la définition d’une autre classe),
ou 2) attribut d’une classe qui est une autre classe.
Le texte des auteurs accréditerait plutôt la définition 1).
Interprétation
le nombre de classes ainsi 1)définies ou 2)utilisées indique la dépendance d’une classe à la
définition d’autres classes.
Attributs mesurés
- Evalue le couplage "interne" d’une classe avec d’autres classes.
Eléments de coûts
Juin 1998.
METRIQUE
NOM - Number Of local Methods
Définition
nombre de méthodes localement définies dans une classe (hors méthodes héritées).
Interprétation
ce nombre indique l’incrément de l’interface apporté par cette classe.
Attributs mesurés
- Evalue les propriétés opérationnelles d’une classe (interface).
- Evalue la complexité de la classe : plus NOM est élevée, plus une classe est complexe.
Eléments de coûts
Juin 1998.
METRIQUE
SIZE1
Définition
nombre de points virgule dans l’implémentation d’une classe.
Interprétation
ce nombre est directement dérivé de la métrique traditionnelle LOC (Lines Of Code).
Attributs mesurés
Evalue la complexité d’une classe.
Eléments de coûts
Juin 1998.
METRIQUE
SIZE2
Définition
cumul du nombre d'attributs et du nombre de méthodes locales (NOM) d’une classe.
Interprétation
Attributs mesurés
Evalue la complexité d’une classe.
Eléments de coûts
Jagdish Bansiya – “A Hierarchical Model For Quality Assessment Of Object Oriented Designs”, Juin
1998.
3 Les métriques proposées par Abreu, Goulão et

Esteves (MOOD)
Le projet MOOD (Metrics for Object Oriented Design) [Abreu & Goulão & Esteves - 1995]
consiste en une proposition de 6 métriques dont les principales caractéristiques sont :
• Une forte corrélation avec les concepts objet ;
• Une évaluation d’un système dans sa globalité ;
• Une évaluation possible en dehors de toute implémentation ;
• Une expression en pourcentage, éliminant les questions de signification quant à la
valeur d’une métrique.
Ces métriques reposent sur le principe suivant :
métrique = Nombre d'occurrences dans le système / Nombre maximal d’occurrence dans le système
Elle s’appuie sur l’hypothèse que la mesure de fréquence d’emploi de certains facteurs de
construction orientés objets reflète la qualité de la conception.
Ces métriques ont été jaugées sur des réalisations commerciales prises comme étalons d’une
bonne conception orientée objets. Il en résulte des recommandations quant aux fourchettes
dans lesquelles doivent se trouver chacune de ces métriques.
METRIQUE
MHF - Method Hiding Factor
Définition
Nombre de méthodes cachées par rapport au nombre de méthodes définies
Interprétation
pourcentage de méthodes cachées.
Attributs mesurés
- Evalue l’encapsulation.

C’est une fraction. Le numérateur est le degré d’invisibilité des méthodes définies dans toutes les
classes. Le degré d’invisibilité d’une méthode est le pourcentage de classes pour lesquelles cette
méthode est invisible. Le dénominateur est le nombre total de classes définies dans le projet.
Eléments de coûts
- Fernando Brito e Abreu – “Design Metrics for Object-Oriented Software Systems”, INESC/ISEG,
1995
- Rachel Harrisson, Steve J. Councell – “An evaluation of the MOOD Set of Object-Oriented
Software Metrics”, IEEE Transactions on Software Engineering, vol. 24, n° 6, Juin 1998.
- Tobias Mayer, Tracy Hall - “Measuring OO Systems : A Critical Analysis of the MOOD Metrics”,
IEEE, Proceeding of Technology of Object-Oriented Languages and systems, 1998.
Formule et méthodes d’obtention de MHF - Method Hiding Factor

METRIQUE
AHF - Attribute Hiding Factor
Définition
Interprétation
pourcentage d’attributs cachés.
Attributs mesurés
Evalue l’encapsulation.

C’est une fraction. Le numérateur est le degré d’invisibilité des attributs définies dans toutes les
classes. Le degré d’invisibilité d’un attribut est le pourcentage de classes pour lesquelles cet
attribut est invisible. Le dénominateur est le nombre total de classes définies dans le projet.
Eléments de coûts
1995
Formule et méthodes d’obtention de AHF - Attribute Hiding Factor

METRIQUE
MIF - Method Inheritance Factor
Définition
Interprétation
pourcentage de méthodes héritées.
Attributs mesurés
- Evalue l’abstraction.
- Evalue la fonctionnalité.

C’est une fraction. Le numérateur est la somme des méthodes héritées dans toutes les classes du
projet. Le dénominateur est le nombre de méthodes disponibles (locale + héritée) dans le projet.
Eléments de coûts
1995
Formule et méthodes d’obtention de MIF - Method Inheritance Factor

METRIQUE
AIF - Attribute Inheritance Factor
Définition
Interprétation
pourcentage d’attributs hérités.
Attributs mesurés
- Evalue l’abstraction.

C’est une fraction. Le numérateur est la somme des attributs hérités dans toutes les classes du
projet. Le dénominateur est le nombre d’attributs disponibles (local + hérité) dans le projet.
Eléments de coûts
1995
Formule et méthodes d’obtention de AIF - Attribute Inheritance Factor

METRIQUE
PF - Polymorphic Factor
Définition
Interprétation
pourcentage de méthodes polymorphes par rapport au nombre total de méthodes
potentiellement polymorphes.
Attributs mesurés
Evalue la flexibilité.

C’est une fraction. Le numérateur est la somme des méthodes surchargées de toutes les
classes. Le dénominateur est le nombre de méthodes disponibles.
Eléments de coûts
- Fernando Brito e Abreu – “Design Metrics for Object-Oriented Software Systems”,
INESC/ISEG, 1995
- Tobias Mayer, Tracy Hall - “Measuring OO Systems : A Critical Analysis of the MOOD
Metrics”, IEEE, Proceeding of Technology of Object-Oriented Languages and systems, 1998.
Formule et méthodes d’obtention de PF - Polymorphic Factor

METRIQUE
CF - Coupling Factor
Définition
Interprétation
pourcentage de classes couplées aux autres classes autrement que par l’héritage.
Attributs mesurés
- Evalue l’interdépendance.

C’est une fraction. Le numérateur représente le nombre de couplage sans héritage. Le
dénominateur est le nombre maximum de couplage.
Eléments de coûts
1995
Formule et méthodes d’obtention de COF - Coupling Factor

4 Approches descendantes et métriques résultantes
Les métriques présentées ci-avant s’inscrivaient dans un raisonnement ascendant : imaginer
des métriques, puis observer ce qu’elles peuvent véhiculer comme informations.
Une approche s’inscrivant dans une démarche qualité plus globale est également possible.
Elle part des attributs qualitatifs de haut niveau qu’un chef de projet dans un environnement
industriel souhaite atteindre, puis elle corrèle ces besoins avec des métriques mesurables.
Cette seconde voie de recherche, non contradictoire avec la première, apparaît néanmoins plus
cohérente avec le domaine de la métrologie logicielle, notamment avec les recommandations
de [N. E. Fenton & S. L. Pfleeger - 1996 - p84] relatives au paradigme " Goal-Question-
Metric " :
1. List the major goal of the development or maintenance project.
1. Derive from each goal the questions that must be answered to determine if the goals
are being met.
1. Decide what must be measured in order to be able to answer the questions
adequately.
Dans cette voie plusieurs propositions de cadre de travail ont été faites parmi lesquelles celles
de :
• Abreu et Carapuça [F.B. Abreu & R. Carapuça - 1994] ;
• Dumke et Winker ;
• Plus récemment celle de J. Bansiya [J. Bansiya - 1997] (projet QMOOD).
Deux de ces propositions sont présentées ici.
4.1 L’approche initiale de Abreu et Carapuça

Elle consiste en une approche par étape commençant par une identification des objectifs de
management, prolongée par l’imagination intuitive de métriques qui représentent ces
objectifs.
Une classification des métriques selon 6 dimensions (conception, taille, complexité,
réutilisabilité, productivité et qualité) et 3 niveaux de granularité (méthode, classe et système)
est proposée. Il en résulte 18 classes de métriques.
Pour chacune de ces classes un ensemble de métriques est proposé, sensé être représentatif de
la classe.
4.1.1 Critique de l’approche de Abreu et Carapuça

La manière dont cette voie de recherche a été menée apparaît très directe puisqu’elle relie
immédiatement des propriétés qualitatives générales, de haut niveau d’abstraction donc, avec
des éléments mesurables des systèmes orientés objets.
Cette démarche ignore donc les propriétés propres introduites par le paradigme objet tels que
l’héritage, l’encapsulation, etc. Toutes propriétés " intermédiaires " qui concourent aux
qualités générales d’un logiciel.
Pour reprendre la métaphore du solide utilisée au § 2.3, c’est un peu comme si un mécanicien
tentait d’évaluer directement la fiabilité d’une bille de roulement à partir de la structure du
réseau cristallin du matériau, de son agencement moléculaire, des atomes le constituant ; sans
se servir de propriétés intermédiaires telles que la sphéricité, la résistance à l’écrasement, la
rugosité, etc.
C’est un raccourci théoriquement faisable, mais particulièrement ambitieux, surtout dans un
domaine neuf tel que celui des systèmes orientés objets.
Comme les métriques de Chidamber et Kemerer, certains indicateurs proposés nécessitent que
l’implémentation logicielle soit faite. Ce qui interdit leur usage en phase de conception pure.
Le modèle proposé dans [F.B. Abreu & R. Carapuça - 1994] présente par ailleurs
l’inconvénient majeur de ne faire l’objet d’aucune validation (mesurabilité, fiabilités).
4.2 Le modèle hiérarchique de Bansiya

J. Bansiya a établi un modèle qualitatif de la conception des systèmes orientés objets via une
démarche d'analyse descendante.
Afin d’évaluer l'intérêt de ce modèle QMOOD (Quality Model for Object-Oriented Design),
une description succincte de la démarche suivie est nécessaire.
Des métriques originales ont également été développées pour ce modèle. Les principales
seront présentées dans ce rapport.
4.2.1 Le modèle qualitatif de Dromey

G.F. Dromey a récemment proposé un nouveau cadre pour construire des modèles qualitatifs
basés sur l'hypothèse que la qualité d'un produit est grandement influencée par celle de ses
constituants.
Le cadre de Dromey comprend 5 étapes :
1. Identifier un jeu d'attributs qualitatifs de haut niveau pour le produit.
2. Identifier les composants du produit.
3. Pour chaque composant, identifier et classifier les plus significatives et les plus
tangibles des propriétés porteuses de qualité.
4. Proposer un ensemble d'axiomes pour relier les propriétés du produit aux
attributs qualitatifs.
5. Evaluer le modèle, identifier ses faiblesses puis, soit le raffiner, soit le rejeter.
4.2.2 QMOOD
Les systèmes orientés objets ayant une architecture plus riche que les systèmes classiques, J.
Bansiya a enrichi le cadre de base proposé par Dromey.
Une contrainte supplémentaire étant posée pour établir ce modèle : la disponibilité des
métriques dès la phase de conception du système (en dehors de toute implémentation).
4.2.2.1 Définition des propriétés
Ce tableau présente les différents critères à évaluer.
Design Property Definition

Design Size A measure of the number of classes used in a design.
Hierarchies Hierarchies are used to represent different generalization-specialization
concepts in a design. It is a count of the number of non-inherited classes that
have children in a design.
Abstraction A measure of the generalization-specialization aspect of the design. Classes in
a design which have one or more descendants exhibit this property of
abstraction.
Encapsulation Defined as the enclosing of data and behavior within a single construct. In
object-oriented designs the property specifically refers to designing classes
that prevent access to attribute declarations by defining them to be private,
thus protecting the internal representation of the objects.
Modularity It is a measure of the deviation from the average number of services provided
by classes within a project. The intent is to identify designs that have classes
with large deviations from the average number of services.
Coupling Defines the interdependency of an object on other objects in a design. It is a
measure of the number of other objects that would have to be accessed by an
object in order for that object to function correctly.
Cohesion Assesses the relatedness of methods and attributes in a class. Strong overlap in
the method parameters and attribute types is an indication of strong cohesion.
Composition Measures the "part-of," "has," "consists-of," or "part-whole" relationships,
which are aggregation relationships in an object-oriented design.
Inheritance A measure of the "is-a" relationship between classes. This relationship is
related to the level of nesting of classes in an inheritance hierarchy.
Polymorphism The ability to substitute objects whose interfaces match for one another at run-
time. It is a measure of services that are dynamically determined at run-time
in an object.
Messaging A count of the number of public methods that are available as services to
other classes. This is a measure of the services that a class provides.
Complexity A measure of the degree of difficulty in understanding and comprehending the
internal and external structure of classes and their relationships.
Tableau 1 : définition des propriétés.

4.2.2.2 Métriques proposées.
SYM NAME DESCRIPTION

DSC Design Size in Classes This metric is a count of the total number of classes in the design.
NOH Number of Hierarchies This metric is a count of the number of class hierarchies in the
design.
NIC Number of Independent This metric is a count of the number of classes (standalone) that
Classes are not inherited by any classes in the design.
NSI Number of Single This metric is a count of the number of classes (sub classes) that
Inheritance use inheritance in the design.
NMI Number of Multiple This metric counts the number of instances of multiple
Inheritance inheritance in the design.
NNC Number of Internal This metric counts the number of internal classes defined for
Classes creating generalization-specialization structures in class
hierarchies of the design.
NAC Number of Abstract This metric counts the number of classes that have been defined
Classes purely for organizing information in the design.
NLC Number of Leaf Classes This metric counts the number of leaf classes in the hierarchies
of the design.
Tableau 2 : Métrique de niveau système

ADI Average Depth of This metric is the average depth of inheritance of classes in
Inheritance the design. It is computed by dividing the summation of
maximum path lengths to all classes by the number of
classes. The path length to a class is the number of edges
from the root to the class in an inheritance tree
representation.
AWI Average Width of This metric is the average number of children per class in
Inheritance the design. The metric is computed by dividing the
summation of the number of children over all classes by the
number of classes in the design.
ANA Average Number of This metric signifies the average number of classes from
Ancestors which a class inherits information. This metric is similar to
the ADI measure and differs only when there are instances
of multiple inheritance in the design.
MFM Measure of Functional This metric computes modularity based on the deviation of
Modularity the number of methods in a class from the average number
of methods per class in the design. A value closer to zero is
preferred for this metric. A lower value indicates a smaller
deviation among classes in the number of services provided.
MFA Measure of Functional This metric is the ratio of the number of methods inherited
Abstraction * by a class to the total number of methods accessible by
members in the class.
MAA Measure of Attribute This metric is the ratio of the number of attributes inherited
Abstraction * by a class to the total number of attributes in the class.
MAT Measure of Abstraction * This metric is the average of functional and attribute
abstraction measures. MAT = (MFA + MAA) / 2
MOA Measure of Aggregation This metric measures the extent of the part-whole
relationship, realized by using attributes. The metric is a
count of the number of data declarations whose types are
user defined classes.
MOS Measure of Association This metric is a measure of the number of direct
relationships a class has to objects of other classes. The
metric value is the same as the DCC measure in functional
systems, MOS = DCC
MRM Modeled Relationship This metric is a measure of the total number of attribute and
Measure parameter based relationships in a class. MRM =
MOS+NAD.
DAM Data Access Metric * This metric is the ratio of the number of private (protected)
attributes to the total number of attributes declared in the
class. A high value for DAM is desired.
OAM Operation Access Metric This metric is the ratio of the number of public methods to
* the total number of methods declared in the class. A high
value for OAM is desired.
MAM Member Access Metric * This metric computes the access to all the members
(attributes and methods) of a class. A high value for MAM
is desired. MAM = ((1-DAM) + OAM) / 2.
Tableau 3 : Métriques de niveau classe

DOI Depth of Inheritance This metric is the length of the inheritance path from the root
to a class.
NOC Number of Children This metric is a count of the number of immediate children
(sub classes) of a class.
NOA Number of Ancestors This metric counts the number of distinct classes which a
class inherits.
Tableau 4 : Mesures externes de la classe

NOM Number of Methods This metric is a count of all the methods defined in a
class.
CIS Class Interface Size This metric is a count of the number of public methods
in a class
NOI Number of Inline This metric counts the number of methods that are inline
(Trivial )Methods (trivial) such as, methods that access and get/set
attributes. These methods are marked as inline in C++.
NOP Number of This metric is a count of the methods that can exhibit
Polymorphic Methods polymorphic behavior. Such methods in C++ are marked
as virtual. NOP = VOM + Overridden Virtual Methods.
NOO Number of Operators This metric is a count of the number of overloaded
operator methods (C++) defined in a class.
NPT Number of Unique This metric is a count of the number of different
Parameter Types parameter types used in the methods of a class.
NPM Number of Parameters This metric is an average of the number of parameters
Per Method per method in a class. It is computed by summing the
parameters of all methods and dividing by the number of
methods in a class.
NOD Number of Attributes This metric is a count of the number of attributes in a
class.
NAD Number of Abstract This metric counts the number of user defined objects
Data Types (ADTs) used as attributes in a class and which are
necessary to instantiate an object instance of the
(aggregate) class.
NRA Number of Reference This metric counts the number of pointers and references
Attributes used as attributes in a class.
NPA Number of Public This metric counts the number of attributes that are
Attributes declared as public in a class.
CSB Class Size in Bytes This metric computes the size of the objects in bytes that
will be created from a class declaration. The size is
computed by summing the size of all attributes declared
in a class.
CSM Class Size Metric This metric is an ordinal number that is the sum of the
number of methods and attributes in a class.
CAM Cohesion Among This metric computes the relatedness among
Methods of Class * methods of a class based upon the parameter list of
the methods. The metric is computed using the
summation of the intersection of parameters of a
method with the maximum independent set of all
parameter types in the class. A metric value close
to 1.0 is preferred.
DCC Direct Class Coupling This metric is a count of the different number of
classes that a class is directly related to. The metric
includes classes that are directly related by attribute
declarations and message passing (parameters) in
methods.
MCC Maximum Class This metric not only includes classes that are directly
Coupling related to a class by attributes and methods, but also
classes that are indirectly related through the directly
related classes.
DAC Direct Attribute Based This metric is a direct count of the number of
Coupling different class types that are declared as attribute
references inside a class.
MAC Maximum Attribute This metric is a total count of the number of
Based Coupling different class types that are declared as attribute
references directly and indirectly inside a class.
DPC Direct Parameter Based This metric is a count of the number of class object
Coupling types that are required directly for message passing
(parameters) to methods in a class.
MPC Maximum Parameter This metric is a count of the number of class object
Based Coupling types that are required directly and indirectly for
message passing (parameters) to methods in a class.
VOM Virtuality of Methods * This metric is a measure of the number of virtual
methods in a class. Overridden virtual methods are
counted only once.
CCN Class Complexity This metric measures the complexity of a class based
Based on Nodes in AST on the number of nodes it takes to construct the
definition of a class in an AST representation.
CEC Class Entropy This metric computes the complexity of a class
Complexity based upon the information content of the class. The
information content of the class is measured by
counting the occurrences of different name strings in
a class definition.
CCD Class Complexity This metric computes complexity based upon the
Based on Data number of components (attributes) that are defined
in the class. All component declarations (including
ADT’s) are resolved to the basic primitives
(integers, doubles and characters). The metric value
is a count of the number of primitives.
CCP Class Complexity This metric estimates complexity based upon the
Based on Method number of parameters required to call methods of the
Parameters class. Inherited method parameters are also included
in the computation of the metric value.
CCM Class Complexity This metric is an aggregate of the data and method
Based on Members parameter complexities. CCM = CCD + CCP
Tableau 5 : Mesures internes de la classe
4.2.2.3 Méthodes d’obtention de ces métriques
1. Identifier un jeu d'attributs qualitatifs de haut niveau pour le produit.

¬ Réutilisabilité, flexibilité, compréhensibilité, fonctionnalité, extensibilité,
efficacité.
2. Identifier les composants de la conception orientée objets qui déterminent la
qualité du produit.
¬ Attributs, méthodes, objets (classes), relations, groupes, modèles,
hiérarchies, système.
3. Pour chaque composant, identifier et classifier les plus significatives et les plus
tangibles des propriétés porteuses de qualité.
4. Identifier un jeu de propriétés de conception, fondamentales et tangibles, qui
reflète les caractéristiques qualitatives des composants.
¬ Abstraction, encapsulation, modularité, couplage, cohésion, complexité,
taille, messages, composition, héritage, polymorphisme, hiérarchies.
5. Mettre en relation les propriétés de conception aux propriétés qualitatives des
composants.
6. Lier les propriétés de conception aux attributs qualitatifs du système, en se
basant sur l'expérience, des axiomes, des raisonnements et des évidences
empiriques.
7. Identifier ou définir des métriques orientées objets pour estimer les propriétés
de conception. Choisir parmi ces métriques les plus pertinentes :
Design Property Derived Design Metric

Design Size Design Size in Classes (DSC)
Nombre de classes dans le système.
Hierarchies Number of Hierarchies (NOH)
Nombre de hiérarchies de classes dans le système.
Abstraction Average Number of Ancestors (ANA)
Nombre moyen d’ancêtres en tenant compte des héritages
multiples.
Encapsulation Data Access Metric (DAM)
Pourcentage d’attributs non accessibles des classes du
système.
Modularity Measure of Functional Modularity (MFM)
Déviation du nombre de méthodes d’une classe par rapport au
nombre moyen de méthodes dans les classes du système.
Coupling Direct Class Coupling (DCC)
Nombre de classes en relation directe avec une classe en tant
qu’attribut ou comme paramètre de méthode.
Cohesion Cohesion Among Methods in Class (CAM)
Calcul de la familiarité des méthodes en se basant sur le type
de leurs paramètres (§ 3.2.3.2).
Composition Measure of Aggregation (MOA)
Nombre d’attributs d’une classe dont le type est défini dans le
système.
Inheritance Measure of Functional Abstraction (MFA)
Pourcentage de méthodes héritées par rapport à toutes les
méthodes d’une classe.
Polymorphism Number of Polymorphic Methods (NOP)
Nombre de méthodes polymorphiques (y compris
surchargées).
Messaging Class Interface Size (CIS)
Nombre de méthodes publiques d’une classe.
Complexity Number of Methods (NOM)
Nombre de méthodes définies dans une classe.
Tableau 2: métriques retenues
Le modèle présenté par Bansiya permet de définir des liens pondérés entre les propriétés de
conception orientées objets et les attributs qualitatifs de haut niveau.
Pour la réutilisabilité par exemple la pondération s’opère ainsi :
Reusability = -0.25 * Coupling + 0.25 * Cohesion + 0.5 * Messaging + 0.5 * Design Size
METRIQUE
CAM - Cohesion Among Methods in class
Définition
pourcentage de types d’attributs partagés entre les méthodes d’une classe.
Interprétation
Attributs mesurés
- Evalue la cohésion d’une classe.
Eléments de coûts
Définition :
4.2.3 Critique du modèle hiérarchique de Bansiya

Plusieurs points positifs sont à relever dans cette proposition. Au premier rang desquels figure
l’approche descendante employée, qui définit d’abord ce que l’on veut mesurer, puis
recherche l’instrument de mesure adéquat.
En second lieu le soucis de disposer d’indicateurs disponibles dès les premiers temps de la
conception d’un système orienté objets.
De plus ce modèle a été mis en pratique avec le logiciel QMOOD++ qui automatise la
collecte des métriques et le calcul des attributs qualitatifs de haut niveau d’un logiciel spécifié
en C++.
Le mode de validation du modèle QMOOD est également original puisqu’il combine :
• Une validation en prenant comme étalon des systèmes orientés objets de très large
diffusion commerciale : Les MFC de Microsoft et les OWL de Borland. Au travers
des versions successives de ces librairies de classes, le modèle QMOOD rend bien
compte des évolutions qualitatives attendues.
• Une validation sur un même projet en C++ effectué par des classes d’étudiants sur 3
ans. Cette validation met notamment en parallèle les notes affectées par les
professeurs, et les classements résultant ; avec l’évaluation que fait QMOOD de ces
mêmes projets. Ces classements sont corrélés dans 85% des cas.
• La métrique CAM a été validée en comparant ses résultats avec ceux fournis par la
métrique LCOM de Chidamber et Kemerer améliorée par Li et Henry. Dans 90% des
cas étudiés ces indications sont corrélées, avec comme avantage essentiel pour CAM
qu’elle peut être mesurée en dehors de toute implémentation.
En dépit de ces points positifs, le modèle de Bansiya n’est pas exempt de lacunes :
• Le calcul pondéré des attributs qualitatifs de haut niveau fait appel à des opérations
arithmétiques (multiplication et addition) entre des valeurs dont les unités ne sont pas
clairement définies et par conséquent probablement non homogènes.
• Indépendamment de la critique précédente, cette pondération mériterait sans doute
d’être affinée.
• La profusion de métriques évoquées nécessiterait sans doute des études individuelles
plus approfondies.
• Une adaptation à des phases plus avancées du cycle de vie du logiciel enrichirait et
affinerait le modèle.
• Certaines métriques, bien que judicieuses, sont liées à un langage de programmation
particulier. C’est le cas notamment du nombre de méthodes triviales détectées en C++
par l’occurrence du mot clé "inline ".
• Une validation de ce modèle quant à sa capacité à prévoir la fiabilité et la
maintenabilité, à l’image des travaux de W. Melo sur les métriques de Chidamber et
Kemerer ainsi que de F. B. Abreu et al. , assoirait sa crédibilité.
4.2.4 Métriques issues d’une démarche ascendante
4.2.4.1 Utilisabilité
Ces métriques ont été validées empiriquement sur des échantillons non industriels de petites
tailles. Dans ce contexte ils apparaissent comme des prédicateurs de la fiabilité et de la
maintenabilité d’un système orienté objets.
Des débuts de déploiement industriel de ces métriques sont en cours notamment à la NASA.
Les résultats de ces travaux donneront une première indication sur l’utilisabilité de ces
nouveaux outils.
Néanmoins les points évoqués ci-après montrent qu’une certaine prudence est de rigueur.
4.2.4.2 Considérations générales

Les métriques issues d’une démarche ascendante (Chidamber et Kemerer par exemple)
partent de ce qui est mesurable. A partir de ces outils il est alors tenté de faire correspondre un
"besoin induit " par cette mesure.
Cette façon de procéder trouve sans doute son origine dans le prolongement des métriques
imaginées dans le cadre de la programmation structurée. C’est-à-dire dans le cadre de logiciel
n’exhibant pas leurs caractéristiques architecturales.
Bien que les travaux réalisés dans ce sens puissent révéler des métriques fructueuses, ils
relèvent essentiellement d’une démarche empreinte d’empirisme. Il est en effet souvent
délicat de répondre aux questions de H. Habrias (§ 2.2) :
• Quel attribut de quelle entité ?
• Est-ce que cette valeur représente bien cette entité ?

Ainsi les auteurs de ces métriques s’appuient marginalement sur les apports du paradigme
orienté objets, au lieu de les placer au centre du raisonnement.
4.2.5 La place particulière des propositions de Abreu,

Goulão et Esteves
Parmi les métriques proposées, celles-ci se caractérisent notamment par leur expression en
pourcentage.
Cette unité ne peut évidemment recouvrir tous les types de mesures (comme la taille par
exemple), mais son emploi présente plusieurs caractéristiques décisives dans une évaluation
qualitative :
• Un nombre sans dimension élimine de fait le recours à des unités artificielles et
subjectives. Par la même, une partie de la validation théorique de ces métriques s’en
trouve simplifiée.
• La qualité d’un attribut peut être aisément appréciée cognitivement. Le concepteur
souhaite savoir si la qualité d’un système est excellente, bonne, moyenne, mauvaise ou
très mauvaise. Souvent une valeur brute ne lui permet pas de trancher entre ces
catégories, ce qu’autorise un nombre sans unité compris entre 0 et 1.
• Des encadrements typiques de ces métriques peuvent être établis à partir de projets
pris comme étalon de bonnes conceptions. Ceci facilite et objective l’interprétation des
métriques, la rendant automatisable plus aisément.
4.2.6 Méthodes descendantes

Initié par Abreu et al. , cette approche a été développée récemment par J. Bansiya. Elle pose
en premier lieu ce qu’il est souhaitable de mesurer, puis sélectionne des métriques supportant
les attributs qualitatifs à évaluer.
Ceci permet de maîtriser :
• La conception dans son ensemble, en évaluant des attributs qualitatifs de haut niveau
d’abstraction.
• La conception à différents niveaux de granularités (méthode, classe, système, etc.).
• La complexité de la conception en mettant à profit les qualités intermédiaires exhibées
par les systèmes orientés objets (encapsulation, héritage, etc.).
• Les phases du cycle de vie du logiciel dans lesquelles les outils doivent fonctionner.
Elle devrait ainsi faciliter la conception par itération, fréquemment employée pour
développer les logiciels orientés objets. Une telle capacité pourrait se révéler
déterminante dans le cadre d’une automatisation des améliorations qualitatives de la
conception.
• La souplesse de l’instrument puisque la disponibilité d’un modèle global permet de
réviser telle ou telle partie du modèle sans remettre en cause tous les travaux
précédemment réalisés.
Néanmoins cette démarche n’en est encore qu’à ses débuts puisque la première étude
exhaustive rendue publique date de décembre 1997 [J. Bansiya - 1997]. Elle devra donc
démontrer son efficacité dans un cadre plus large que le laboratoire.
Quoiqu’il en soit cette approche ouvre une nouvelle voie de recherche appelant de nouveaux
travaux. Elle constitue un pas significatif vers l’automatisation des améliorations qualitatives
dans la conception des logiciels. Notamment par l’accompagnement du cycle de vie du
logiciel qui lui aussi est descendant dans sa première phase (cycle en V).
4.2.7 La validation
La validation théorique et pratique des modèles de mesure et des métriques demeure le point
le plus critique des recherches actuelles.
4.2.7.1 Validation théorique

Au plan théorique, sans entrer dans des détails sortant du cadre de ce rapport, le débat entre
experts demeure ouvert ([B. Kitchenham, S.L. Pfleeger, N. Fenton - 1995]). Certaines
méthodes de validation étant même déclarées non respectueuses de la démarche scientifique !
Dans ce contexte, il est possible tout au plus de dégager quelques grandes règles à
respecter [N. E. Fenton, S. L. Pfleeger - 1996 - p28 et suivantes] dont voici les principales :
• Une mesure est une transposition du monde empirique dans un monde formel.
• Cette transposition doit respecter certaines règles. Ainsi une mesure doit spécifier :
• Un domaine, le monde réel capturé ;
• Une convention d’unité, le monde mathématique formel ;
• Une procédure de réalisation de la mesure.
• La transposition doit respecter dans tous les cas la condition de représentation. C’est-
à-dire que les relations empiriques doivent être reproduites dans le monde formel.
• L’attribut de l’entité mesurée doit être clairement identifié dans le monde empirique.
Par voie de conséquence la mesure doit être bien adaptée à l’attribut de cette entité.
o Les mesures valides doivent respecter la théorie de la mesure. C’est-à-dire
notamment être sensées et justes.
Les conclusions de l’article "towards a framework for software measurement validation " [B.
Kitchenham, S.L. Pfleeger, N. Fenton - 1995] fournissent également quelques règles
additionnelles qui bien que discutées, paraissent à suivre.
4.2.7.2 Validation empirique

Afin de valider les modèles et métriques développés, il est toujours fait appel à une validation
au travers d’exemples de conceptions orientées objets sensés être représentatifs de la réalité
industrielle.
Dans ce domaine chaque proposition est validée suivant des procédures spécifiques. Cette
disparité ne facilite pas une reconnaissance universelle des qualités et défauts réels des
métriques et modèle présentées dans ce rapport. L’adoption d’une plate-forme de validation
empirique normalisée constituerait sans doute un grand pas dans ce sens.

Synthèse OO

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Synthèse OO

Transféré par

Droits d'auteur :

Formats disponibles

Synthèse des métriques

2 LES MÉTRIQUES PROPOSÉES PAR LI ET HENRY 10

2.1 MÉTRIQUES REPRISES DES PROPOSITIONS DE CHIDAMBER ET KEMERER ......................................10

3 LES MÉTRIQUES PROPOSÉES PAR ABREU, GOULÃO ET ESTEVES (MOOD)

4 APPROCHES DESCENDANTES ET MÉTRIQUES RÉSULTANTES 24

4.1 L’APPROCHE INITIALE DE ABREU ET CARAPUÇA ......................................................................24

1 Les métriques proposées par Chidamber et

Formule et méthodes d’obtention

- V. R. Basili, L. C. Briand et W. L. Melo- “A validation of Object-Oriented Design Metrics as

Formule et méthodes d’obtention

- V. R. Basili, L. C. Briand et W. L. Melo- “A validation of Object-Oriented Design Metrics as

Formule et méthodes d’obtention

- V. R. Basili, L. C. Briand et W. L. Melo- “A validation of Object-Oriented Design Metrics as

Formule et méthodes d’obtention

- V. R. Basili, L. C. Briand et W. L. Melo- “A validation of Object-Oriented Design Metrics as

Formule et méthodes d’obtention

- V. R. Basili, L. C. Briand et W. L. Melo- “A validation of Object-Oriented Design Metrics as

- Evalue la complexité. Une classe disparate augmentant la probabilité d’erreur durant le

- Evalue la réutilisabilité. Une forte cohésion implique une réutilisation simple.

Formule et méthodes d’obtention

- V. R. Basili, L. C. Briand et W. L. Melo- “A validation of Object-Oriented Design Metrics as

Notes : Plusieurs particularités fondamentales de la conception des systèmes orientés objets

2.1 Métriques reprises des propositions de

2.2 Les 5 nouvelles métriques de Li et Henry

Formule et méthodes d’obtention

Formule et méthodes d’obtention

Formule et méthodes d’obtention

Formule et méthodes d’obtention

Formule et méthodes d’obtention

3 Les métriques proposées par Abreu, Goulão et

Formule et méthodes d’obtention

Formule et méthodes d’obtention de MHF - Method Hiding Factor

Formule et méthodes d’obtention

Formule et méthodes d’obtention de AHF - Attribute Hiding Factor

Formule et méthodes d’obtention

Formule et méthodes d’obtention de MIF - Method Inheritance Factor

Formule et méthodes d’obtention

Formule et méthodes d’obtention de AIF - Attribute Inheritance Factor

Formule et méthodes d’obtention

Formule et méthodes d’obtention de PF - Polymorphic Factor

Formule et méthodes d’obtention

Formule et méthodes d’obtention de COF - Coupling Factor

4.1 L’approche initiale de Abreu et Carapuça

4.1.1 Critique de l’approche de Abreu et Carapuça

4.2 Le modèle hiérarchique de Bansiya

4.2.1 Le modèle qualitatif de Dromey

Ce tableau présente les différents critères à évaluer.

Design Property Definition

Tableau 1 : définition des propriétés.

SYM NAME DESCRIPTION

Tableau 2 : Métrique de niveau système

Tableau 3 : Métriques de niveau classe

Tableau 4 : Mesures externes de la classe

Tableau 5 : Mesures internes de la classe

4.2.2.3 Méthodes d’obtention de ces métriques

1. Identifier un jeu d'attributs qualitatifs de haut niveau pour le produit.

Design Property Derived Design Metric

Tableau 2: métriques retenues

Formule et méthodes d’obtention

4.2.3 Critique du modèle hiérarchique de Bansiya

4.2.4 Métriques issues d’une démarche ascendante

4.2.4.2 Considérations générales

• Est-ce que cette valeur représente bien cette entité ?

4.2.5 La place particulière des propositions de Abreu,