Synthèse OO

Published on June 2016 | Categories: Documents | Downloads: 24 | Comments: 0 | Views: 667
of 39
Download PDF   Embed   Report

Comments

Content

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 Kemerer

Les métriques proposées par Chidamber et

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

-

-

Formule et méthodes d’obtention nombre maximum de classes ancêtres de la classe pour atteindre la (une) racine 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
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é.

-

Formule et méthodes d’obtention

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

-

-

Formule et méthodes d’obtention

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

-

Formule et méthodes d’obtention 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 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
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.

-

-

Formule et méthodes d’obtention

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.

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.

Formule et méthodes d’obtention Compter le nombre de méthodes invoquées dans l’implémentation des méthode de la classe. Eléments de coûts Contexte d’utilisation

Références bibliographiques - Jagdish Bansiya – “A Hierarchical Model For Quality Assessment Of Object Oriented Designs”, 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.

Formule et méthodes d’obtention

Eléments de coûts Contexte d’utilisation

Références bibliographiques - Jagdish Bansiya – “A Hierarchical Model For Quality Assessment Of Object Oriented Designs”, 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.

Formule et méthodes d’obtention

Eléments de coûts Contexte d’utilisation

Références bibliographiques - Jagdish Bansiya – “A Hierarchical Model For Quality Assessment Of Object Oriented Designs”, 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. Formule et méthodes d’obtention

Eléments de coûts Contexte d’utilisation

Références bibliographiques - Jagdish Bansiya – “A Hierarchical Model For Quality Assessment Of Object Oriented Designs”, 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. Formule et méthodes d’obtention

Eléments de coûts Contexte d’utilisation

Références bibliographiques 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.

Formule et méthodes d’obtention 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 Contexte d’utilisation

Références bibliographiques - 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. Formule et méthodes d’obtention 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 Contexte d’utilisation

Références bibliographiques - 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 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é.

Formule et méthodes d’obtention 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 Contexte d’utilisation

Références bibliographiques - 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 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.

Formule et méthodes d’obtention 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 Contexte d’utilisation

Références bibliographiques - 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 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é. Formule et méthodes d’obtention 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 Contexte d’utilisation

Références bibliographiques - 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 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.

Formule et méthodes d’obtention 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 Contexte d’utilisation

Références bibliographiques - 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 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-QuestionMetric " : 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 Design Size Hierarchies

Definition A measure of the number of classes used in a design. 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. 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. 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. 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. 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. 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. Measures the "part-of," "has," "consists-of," or "part-whole" relationships, which are aggregation relationships in an object-oriented design. A measure of the "is-a" relationship between classes. This relationship is related to the level of nesting of classes in an inheritance hierarchy. The ability to substitute objects whose interfaces match for one another at runtime. It is a measure of services that are dynamically determined at run-time in an object. 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. A measure of the degree of difficulty in understanding and comprehending the internal and external structure of classes and their relationships.

Abstraction

Encapsulation

Modularity

Coupling

Cohesion Composition Inheritance Polymorphism

Messaging Complexity

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

4.2.2.2
SYM DSC NOH NIC NSI NMI NNC NAME Design Size in Classes Number of Hierarchies Number of Independent Classes Number of Single Inheritance Number of Multiple Inheritance Number of Internal Classes Number of Abstract Classes Number of Leaf Classes

Métriques proposées.
DESCRIPTION This metric is a count of the total number of classes in the design. This metric is a count of the number of class hierarchies in the design. This metric is a count of the number of classes (standalone) that are not inherited by any classes in the design. This metric is a count of the number of classes (sub classes) that use inheritance in the design. This metric counts the number of instances of multiple inheritance in the design. This metric counts the number of internal classes defined for creating generalization-specialization structures in class hierarchies of the design. This metric counts the number of classes that have been defined purely for organizing information in the design. This metric counts the number of leaf classes in the hierarchies of the design.

NAC NLC

Tableau 2 : Métrique de niveau système

SYM ADI

NAME Average Depth of Inheritance

DESCRIPTION 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. 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. 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. 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. 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. This metric is the ratio of the number of attributes inherited by a class to the total number of attributes in the class. This metric is the average of functional and attribute abstraction measures. MAT = (MFA + MAA) / 2 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. 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 This metric is a measure of the total number of attribute and parameter based relationships in a class. MRM = MOS+NAD. 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. 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. 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.

AWI

Average Width of Inheritance

ANA

Average Number of Ancestors

MFM

Measure of Functional Modularity

MFA

Measure of Functional Abstraction * Measure of Attribute Abstraction * Measure of Abstraction * Measure of Aggregation

MAA MAT MOA

MOS

Measure of Association

MRM

Modeled Relationship Measure Data Access Metric *

DAM

OAM

Operation Access Metric * Member Access Metric *

MAM

Tableau 3 : Métriques de niveau classe

SYM DOI NOC NOA

NAME Depth of Inheritance Number of Children Number of Ancestors

DESCRIPTION This metric is the length of the inheritance path from the root to a class. This metric is a count of the number of immediate children (sub classes) of a class. This metric counts the number of distinct classes which a class inherits.

Tableau 4 : Mesures externes de la classe

SYM NOM CIS NOI

NAME Number of Methods

DESCRIPTION

NOP

NOO NPT NPM

NOD NAD

NRA NPA CSB

CSM CAM

DCC

MCC

DAC

This metric is a count of all the methods defined in a class. Class Interface Size This metric is a count of the number of public methods in a class 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++. 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. Number of Operators This metric is a count of the number of overloaded operator methods (C++) defined in a class. Number of Unique This metric is a count of the number of different Parameter Types parameter types used in the methods of a class. 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. Number of Attributes This metric is a count of the number of attributes in a class. 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. Number of Reference This metric counts the number of pointers and references Attributes used as attributes in a class. Number of Public This metric counts the number of attributes that are Attributes declared as public in a class. 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. Class Size Metric This metric is an ordinal number that is the sum of the number of methods and attributes in a class. 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. 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. 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. 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 Direct Parameter Based Coupling Maximum Parameter Based Coupling Virtuality of Methods *

DPC

MPC

VOM

CCN

Class Complexity Based on Nodes in AST Class Entropy Complexity

CEC

CCD

Class Complexity Based on Data

CCP

Class Complexity Based on Method Parameters Class Complexity Based on Members

CCM

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. 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. 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. This metric is a measure of the number of virtual methods in a class. Overridden virtual methods are counted only once. 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. 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. 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. 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. 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 Design Size Hierarchies Abstraction Derived Design Metric Design Size in Classes (DSC) Nombre de classes dans le système. Number of Hierarchies (NOH) Nombre de hiérarchies de classes dans le système. 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 Complexity Class Interface Size (CIS) Nombre de méthodes publiques d’une classe. 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.

Formule et méthodes d’obtention

Eléments de coûts Contexte d’utilisation

Références bibliographiques

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.

Sponsor Documents

Or use your account on DocShare.tips

Hide

Forgot your password?

Or register your new account on DocShare.tips

Hide

Lost your password? Please enter your email address. You will receive a link to create a new password.

Back to log-in

Close