Les métriques du diagramme de classes (MDC) 

Les MDC sont des métriques fort intéressantes pour le développement d’une approche d’estimation et de priorisation de l’effort de test. Elles sont simples et objectives. De plus, la plupart de ces métriques sont disponibles à la phase d’analyse du processus de développement d’un logiciel [68,69]. Ces métriques ont de ce fait été largement utilisées dans la littérature pour l’estimation de la taille du code source dans les systèmes orientés objet [61-66]. Les MDC peuvent être classifiés en deux catégories selon Zhou et al. [70] : les métriques de taille et les métriques de complexité structurelle. Voici une brève description de chacune des métriques utilisées.

MDC de taille:
• Nombre de classes (NC) : Cette métrique correspond au nombre de classes d’un système orienté objet.
• Nombre d ‘attributs (NA) : Cette métrique correspond au nombre d’attributs. Elle peut être utilisée au niveau d’un système orienté objet (NA total d’ un système) ou d’une classe (NA d’une seule classe).
• Nombre de méthodes (NM) : Cette métrique correspond au nombre de méthodes. Elle peut aussi être utilisée au niveau d’un système orienté objet (NM total d’un système) ou d’une classe (NM d’une seule classe).

MDC de complexité structurelle:

• Nombre d’associations (Nassoc) : Cette métrique correspond au nombre d’associations d’une classe. Plus précisément, une classe A à une association avec une classe B si elle contient un attribut de type B. Le terme association est un terme général pouvant inclure: association, ou agrégation ou bien composition.

• Nombre d ‘agrégations (Nagg) : Cette métrique correspond au nombre de relations d’agrégation de chaque classe. Plus précisément, une classe A à une relation d’agrégation avec une classe B si un attribut qu’elle contient remplit une des conditions suivantes: (1) son type est un tableau et le type des éléments de ce tableau est de la classe B (ex: B nomTableau[]), (2) son type est un type paramétré et le type de paramètre est la classe B (ex: ArrayList nomListe).

• Nombre de compositions (Ncomp) : Cette métrique correspond au nombre de relations de composition. Plus précisément, si une classe A contient un attribut dont le type est la classe B, alors il existe une relation de composition entre A et B.

• Nombre de dépendances (Ndep) : Cette métrique correspond au nombre de relations de dépendance d’une classe. Plus précisément, si une classe A contient une méthode ayant un paramètre dont le type est la classe B, alors il existe une relation de dépendance entre A et B (A dépend de B).

• Nombre de généralisations (Ngen) : Cette métrique correspond au nombre de généralisations d’une classe. Plus précisément, si une classe A hérite d’une classe B, alors il y a une relation de généralisation entre A et B. Au niveau de la littérature,  deux métriques sont utilisées concernant les généralisations, Ngen et NgenH. La métrique NGen correspond au nombre total de relations de généralisation dans un système (somme de toutes les relations mère-fille) tandis que la métrique NGenH correspond au nombre total de généralisations hiérarchiques d’un système (somme des mères).

• Profondeur de l ‘arbre d ‘héritage (MaxDIT et DIT) : Cette métrique correspond au niveau de profondeur d’héritage. Elle peut s’appliquer à un système 00 (niveau de profondeur maximum du système (MaxDIT)) ou à une classe seule (niveau de profondeur de la classe dans le système (DIT)).

Techniques de prédiction de l’effort de développement à partir du MDC 

Comme mentionné précédemment, plusieurs techniques d’estimation de l’effort de développement des SOO basées sur les MDC existent à ce jour. Toutefois, la plupart de ces techniques ont été développées afin d’analyser l’effort global d’un système. Ce qui rend ces techniques moins intéressantes comme base pour le développement d’une approche de priorisation.

En 2014, Zhou et al. [70] ont mené une étude concernant la comparaison de la précision de 6 types de métriques provenant des diagrammes de classes pour l’estimation de l’effort de développement. Ils ont utilisé plusieurs techniques de modélisation afin de construire un modèle de prédiction permettant d’étudier les métriques suivantes: CDM (MDC), POP (Predictive object points), OOPS (Object oriented project size points), FS_CP (jast&&serious class points), O_CP (objective class points), OOFP (object-oriented function points) [61 , 71-76]. Les métriques utilisées dans leur modèle de prédiction sont les suivantes: NC, NA, NM, NAssoc, NAgg, NComp, NDep, NGen, NGenH, et MaxDIT. Il est à noter que le nombre d’associations (NAssoc) collectées correspond plutôt à la définition suivante: nombre d’associations de compositions/agrégations bidirectionnelles d’une classe. Afin de mener leur étude, ils ont collecté ces six types de métriques pour 100 systèmes Java open-source et ont ensuite utilisé leur modèle de prédiction afin d’investiguer la précision de chacune de ces types de métriques. Concernant les métriques MDC, ils ont tout d’abord constaté que toutes les métriques, exceptée MaxDIT, sont corrélées à l’effort de développement et plus particulièrement NA et NM. Finalement, leur conclusion est que les métriques MDC ainsi que les métriques OOPS et 0_ CP sont de bons prédicteurs de la taille du code source des systèmes 00.

À la lumière de ces informations, les MDC semblent très intéressantes pour l’exploration du développement d’ une approche d’estimation de l’effort de test unitaire et de priorisation à partir de celles-ci.

Techniques de prédiction de l’effort des tests à partir du DC

L’estimation de l’effort de test à partir du DC, à notre connaissance, a été peu étudiée à ce jour. Toutefois, plusieurs études ont été menées sur la testabilité ou l’effort de test à partir du code source [77-80]. Ces techniques donnent des résultats souvent très intéressants, cependant elles ne peuvent être utilisées tôt dans le processus de développement. Comme mentionné précédemment, plusieurs études ont aussi été menées à partir des DCU et des diagrammes directement dérivés de ceux-ci (diagramme de séquence et diagramme d’activités entre autres) pour l’estimation de l’effort de test [21-27,30-32]. Toutefois, l’ utilisation de ces diagrammes pose un problème de validation au niveau de la recherche dû à la faible quantité d’études de cas pour lesquelles ces diagrammes sont disponibles.

Une étude récente [67] s’est toutefois intéressée à l’estimation de l’effort de test à partir du DCU et du De. Ces auteurs proposent une technique permettant de calculer et de suivre l’effort total d’un système à partir des calculs de l’effort de test individuel basés sur le DCU et sur le De. Le calcul de l’effort de test à partir du DCU se fait à partir de la sommation du poids de chaque CU (nombre de transactions dans le scénario normal, nombre de transactions dans les scénarios exceptionnels, nombre d’acteurs), la sommation du poids des acteurs (type de communication, nombre d’interactions avec des CU), d’ un facteur de maturité technique et environnementale propre à l’organisation qui développe les tests (TEl) et de la moyenne de productivité de l’équipe de test (Prod). Le calcul de l’effort de test à partir du OC se fait quant à lui à partir du poids de chaque classe (nombre d’attributs, nombre de méthodes encapsulées, nombre de services utilisés). Cette approche d’estimation de l’effort de test est très intéressante, toutefois les auteurs ne semblent pas avoir validé leur approche .