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 102.2 LES 5 NOUVELLES MÉTRIQUES DE LI ET HENRY 10

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

4 APPROCHES DESCENDANTES ET MÉTRIQUES RÉSULTANTES 12

4.1 L’APPROCHE INITIALE DE ABREU ET CARAPUÇA 124.1.1 CRITIQUE DE L’APPROCHE DE ABREU ET CARAPUÇA 124.2 LE MODÈLE HIÉRARCHIQUE DE BANSIYA 124.2.1 LE MODÈLE QUALITATIF DE DROMEY 124.2.2 QMOOD 124.2.2.1 Définition des propriétés 124.2.3 CRITIQUE DU MODÈLE HIÉRARCHIQUE DE BANSIYA 124.2.4 MÉTRIQUES ISSUES D’UNE DÉMARCHE ASCENDANTE 124.2.4.1 Utilisabilité 124.2.4.2 Considérations générales 124.2.5 LA PLACE PARTICULIÈRE DES PROPOSITIONS DE ABREU, GOULÃO ET ESTEVES 124.2.5.1 Méthodes descendantes 124.2.5.2 La validation 12

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

METRIQUEWMC - Weighted Methods per Class

DéfinitionC'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.

METRIQUEDIT - Depth of Inheritance Tree

Définitionc'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







METRIQUENOC - Number Of Children

Définitionc'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







METRIQUECBO - Coupling Between Object classes

Définitionnombre 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







METRIQUERFC - Response For a Class

DéfinitionC'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







METRIQUELCOM - Lack of COhesion in Methods

DéfinitionMesure 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







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

METRIQUEMPC - Message Passing Coupling

Définitionnombre 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




METRIQUEDAC - Data Abstraction Coupling

Définitionla 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




METRIQUENOM - Number Of local Methods

Définitionnombre 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




METRIQUESIZE1

Définitionnombre 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




METRIQUESIZE2

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

METRIQUEMHF - Method Hiding Factor

DéfinitionNombre 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

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






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

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






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

METRIQUEAIF - Attribute Inheritance Factor

Définition

Interprétationpourcentage 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






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

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






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

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






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 Classes

This metric is a count of the number of classes (standalone) that are not inherited by any classes in the design.

NSI Number of Single Inheritance

This metric is a count of the number of classes (sub classes) that use inheritance in the design.

NMI Number of Multiple Inheritance

This metric counts the number of instances of multiple inheritance in the design.

NNC Number of Internal Classes

This metric counts the number of internal classes defined for creating generalization-specialization structures in class hierarchies of the design.

NAC Number of Abstract Classes

This metric counts the number of classes that have been defined 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 Inheritance

This metric is the average depth of inheritance of classes in 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 Inheritance

This metric is the average number of children per class in 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 Ancestors

This metric signifies the average number of classes from 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 Modularity

This metric computes modularity based on the deviation of 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 Abstraction *

This metric is the ratio of the number of methods inherited by a class to the total number of methods accessible by members in the class.

MAA Measure of Attribute Abstraction *

This metric is the ratio of the number of attributes inherited 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 Measure

This metric is a measure of the total number of attribute and 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 (Trivial )Methods

This metric counts the number of methods that are inline (trivial) such as, methods that access and get/set attributes. These methods are marked as inline in C++.

NOP Number of Polymorphic Methods

This metric is a count of the methods that can exhibit 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 Parameter Types

This metric is a count of the number of different parameter types used in the methods of a class.

NPM Number of Parameters Per Method

This metric is an average of the number of parameters 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 Data Types

This metric counts the number of user defined objects (ADTs) used as attributes in a class and which are necessary to instantiate an object instance of the (aggregate) class.

NRA Number of Reference Attributes

This metric counts the number of pointers and references used as attributes in a class.

NPA Number of Public Attributes

This metric counts the number of attributes that are 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 Methods of Class *

This metric computes the relatedness among 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 Coupling

This metric not only includes classes that are directly 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 Based Coupling

This metric is a total count of the number of different class types that are declared as attribute references directly and indirectly inside a class.

DPC Direct Parameter Based Coupling

This metric is a count of the number of class object types that are required directly for message passing (parameters) to methods in a class.

MPC Maximum Parameter Based Coupling

This metric is a count of the number of class object 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 Based on Nodes in AST

This metric measures the complexity of a class based on the number of nodes it takes to construct the definition of a class in an AST representation.

CEC Class Entropy Complexity

This metric computes the complexity of a class 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 Based on Data

This metric computes complexity based upon the 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 Based on Method Parameters

This metric estimates complexity based upon the number of parameters required to call methods of the class. Inherited method parameters are also included in the computation of the metric value.

CCM Class Complexity Based on Members

This metric is an aggregate of the data and method 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

METRIQUECAM - Cohesion Among Methods in class

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

Documents

Synthèse OO