Métriques sur les processus de développement

Des mesures

Le mot français mesure est un mot polysémique, comme en témoigne la longueur de l’entrée mesure dans le Petit Robert. Il recouvre à la fois une action, une définition d’action et une valeur numérique. Une mesure comme action est une suite de procédures effectuée à un moment donné, par exemple, la mesure du Mont-Blanc par satellite en 1983. La mesure comme définition d’action est une spécification d’un ensemble de règles permettant d’attribuer un nombre ou un symbole à une chose. Par exemple, la mesure de la longueur d’une voiture est la distance maximale entre le pare-choc arrière et le pare-choc avant. La mesure comme valeur numérique est le résultat d’une mesure action de mesure, par exemple La mesure du Mont-Blanc est 4808 mètres. On préfère usuellement la formulation Le Mont-Blanc mesure 4808 mètres, où le verbe mesurer est un verbe d’état, ce qui montre le caractère interne d’une mesure par rapport à la chose mesurée. Fenton [Fenton, 1991] insiste sur le fait que la mesure est toujours liée à un attribut et que l’on ne doit pas l’omettre. Dans cette perspective, il aurait fallu dire dans l’exemple précédent La mesure de hauteur du Mont-Blanc est de 4808 mètres. Notons aussi que le polymorphisme suscité disparaît partiellement en anglais. Le mot measurement est la mesure comme action, alors que measure reste polysémique en tant que mesure comme procédure et mesure comme valeur.

Enfin, plusieurs auteurs font la distinction entre mesure et métrique. Une métrique est une fonction de deux éléments satisfaisant 1) f(x, y) = 0 ⇔ x = y; 2) f(x, y) = f(y, x); 3) f(x, z) ≤ f(x, y)+f(y, z). C’est donc un concept de distance (l’étymologie lie le mot métrique au mètre) alors qu’une mesure est une fonction d’un seul élément. Pour une approche mathématique de la mesure, nous nous reportons à l’ouvrage de Krantz [Krantz et al., 1971]. En étant strict, il est donc préférable d’utiliser le terme mesure. Toutefois, nous partageons le point de vue de [Henderson-Sellers, 1996] et constatons que l’usage commun permet l’utilisation interchangeable des deux termes. Afin de surmonter les pièges sémantiques dus à la terminologie utilisée (cf. [Garcìa et al., 2006]), nous adoptons les définitions suivantes. Définition 2.2 Une métrique est un homomorphisme du monde empirique vers le monde des nombres. En tant qu’homomorphisme, une métrique préserve les relations empiriques (inspirée de [Zuse, 1991, p.16]). Définition 2.3 Une mesure est une suite d’actions effectuée afin d’assigner un nombre aux attributs des entités du monde empirique (inspirée de [Fenton, 1991, p.5]). Définition 2.4 Une valeur de mesure, ou valeur de métrique, est le résultat d’une mesure pour une métrique identifiée et un objet donné de la réalité empirique (inspiré de measurement result [CEI et ISO, 1993, p.15]).

Des modèles

L’ingénierie dirigée par les modèles place les modèles au coeur de la conception et du développement des systèmes. À ce titre, il est important de définir ce qu’est un modèle. Un tour d’horizon des articles d’encyclopédie (e.g; [Mouloud, 2006]) montre la variété des domaines dans lesquels est utilisé le mot modèle. De même, l’usage des modèles varie grandement. On trouve dans la littérature des dizaines d’articles et d’ouvrages sur les modèles. Dans cet état de l’art, nous nous appuyons sur des articles d’encyclopédie [White, 2000, Mouloud, 2006, Frigg et Hartmann, 2006] pour la vision globale de la modélisation. L’article de Jeff Rothenberg [Rothenberg, 1989] est un pont entre modèle et informatique. Enfin, nous présentons quelques travaux sur le sujet effectués par des personnes appartenant au monde du génie logiciel. Il est cependant hors du cadre de cet état de l’art d’aborder les questions épistémologiques associées à la notion de modèle. On trouve dans l’article Modèle de l’Encyclopédie Universalis [Mouloud, 2006] une classification des modèles par domaine d’application. Ils sont: mathématique; physique; sciences de la Terre; biologie; sciences sociales; psychologie; linguistique; art. Dans chaque domaine, Mouloud étudie les modèles utilisés et leurs types. Prenons l’exemple des mathématiques: un modèle en mathématique est un concept formalisé dans la théorie des modèles [Andler et al., 2006], une branche de la logique formelle.

Un modèle en mathématique est donc fondamentalement différent d’un modèle mathématique. De manière comparable, White, Frigg et Rothenberg [White, 2000, Frigg et Hartmann, 2006, Rothenberg, 1989] propose une classification des modèles. Nous proposons donc ici une synthèse des différents types de modèles: modèles physiques C’est un objet physique. Il peut être modèle réduit ou prototype12 [White, 2000, Frigg et Hartmann, 2006, Rothenberg, 1989]; modèles mathématiques Un ensemble d’équations ou d’expressions logiques [White, 2000]; modèles fictionnels (proche des métaphores conceptuels de [Rothenberg, 1989] et des modèles mentaux de [White, 2000]) C’est une vue idéalisée d’un système, par exemple une pendule sans friction, la vue d’un atome comme un système solaire miniature, ou le cerveau comme une machine [Frigg et Hartmann, 2006]; modèles iconiques Ce sont des images ou des dessins [White, 2000]; modèles textuels descriptifs C’est une description en langage naturel d’un système et/ou de sa dynamique. On peut donc avoir un modèle descriptif d’un modèle fictionnel [White, 2000, Frigg et Hartmann, 2006, Rothenberg, 1989]. Contrairement au découpage par domaine de Mouloud, où n’apparaissait pas les modèles d’ingénierie, on les trouve dans cette taxonomie. Par exemple, le modèle mathématique des équations de résistance à la charge d’un pont est un modèle d’ingénierie. Par contre, il est difficile d’y classer les modèles des logiciels, qui sont parfois des descriptions textuelles mais pas en langage naturel.

Outre la classification par domaine et la classification par type, il nous semble important de citer la classification de Seidewitz [Seidewitz, 2003]. Pour Seidewitz, on peut classer les modèles en deux catégories. Les modèles descriptifs et les modèles prescriptifs. Les modèles descriptifs réfèrent à une réalité existante. Ainsi tous les modèles explicatifs liés à l’observation sont descriptifs. On comprend alors mieux l’absence des modèles d’ingénierie dans [Mouloud, 2006], qui ne considère implicitement que les modèles descriptifs. Les modèles prescriptifs considèrent un système qui n’existe pas encore. En ce sens, ils peuvent être vus comme une spécification ou comme une base d’étude des propriétés du système à construire. Une approche de la définition d’un modèle est de lister ces attributs et ces propriétés. Sur ce point, on peut constater un consensus entre les auteurs étudiés ([Rothenberg, 1989, White, 2000, Selic, 2003]). Un modèle permet de raisonner sur un système à moindre coût que sur le système lui-même. Par exemple, il est moins coûteux de tester différentes tailles de câble pour un pont suspendu avec un modèle mathématique que de construire N ponts! Dans certains cas, un modèle permet même d’étudier des systèmes impossibles à construire ou à tester (par exemple, les modèles de courants atmosphériques et océaniques considérant des durées de plusieurs siècles). Outre l’aspect économique, Selic propose trois autres attributs d’un modèle: l’abstraction Il faut comprendre ici abstraction au sens granularité. Un modèle doit enlever ou cacher des détails;

Métriques sur les logiciels procéduraux

Dans cette section, nous présentons brièvement trois métriques traditionelles: le nombre de lignes de code, la métrique de McCabe, et les métriques de flots d’information de Henry et Kafura. Nous les avons sélectionnées pour la richesse de la littérature associée et du fait de l’existence d’évaluations empiriques. La mesure du nombre de lignes de code est une mesure très utilisée [Fenton, 1991, p. 246]. Sa définition est intuitive bien que certains auteurs ont montré que la définition unique et non-ambiguë est difficile [Fenton, 1991, p. 249], ce qui a conduit Kan [Kan, 1995] à énoncer que the lines of code (LOC) metric is anything but simple20. Les ambiguïtés sont par exemple: doit-on compter les retours à la ligne ? les commentaires ? les appels de fonction imbriqués ? En terme de validation, Kitchenham et al. [Kitchenham et al., 1990] ont mis à jour un lien empirique entre le nombre de lignes de code et la densité de défauts et de changements. De même, Withrow [Withrow, 1990] donne les résultats d’une expérience qui montre qu’un module Ada doit avoir une taille ni trop petite ni trop grande, qui correspond à un minimum en terme de densité de faute.

C’est le principe de Boucle d’Or en référence au conte éponyme. Nous rappelons aussi le lien fort qui existe entre la mesure du nombre de lignes de code et les modèles d’estimation de coût des logiciels (e.g.; [Boehm et al., 1995]). Notons l’existence de points de vue critiques dans la littérature sur la pertinence de cette métrique [Khoshgoftaar et Munson, 1990] pour prédire la densité de fautes. La mesure de McCabe [McCabe, 1976] est une mesure très connue [Henderson- Sellers, 1996, p. 92]. Elle est basée sur la théorie des graphes et est présentée dans l’article original comme le nombre de chemins linéairement indépendants. Plusieurs auteurs ont discuté de la formule, mais reste l’idée principale de compter les points de branchements dans le code (e.g.; le instructions conditionnelles ou les boucles). Kitchenham et al. [Kitchenham et al., 1990] ont trouvé une corrélation empirique (coefficient de Spearman) entre la mesure de McCabe et trois attributs de qualité (le nombre de changements, le nombre de fautes, et la complexité subjective). Enfin, il faut noter les métriques fan-in et fan-out de Henry et Kafura [Henry et Kafura, 1981]. Elles sont définies par le nombre de dépendances entrantes et sortantes pour un artefact donné. La précision de cette définition est donc directement liée à la précision des frontières de l’artefact et de la notion de dépendance. Ferneley [Ferneley, 1997] a trouvé une relation empirique entre ces mesures et le temps de développement, la densité de faute et la qualité du design (évaluée subjectivement). Notons la présence de résultats bien moins probants dans [Kitchenham et al., 1990] (coefficient de corrélation bien plus faible).

Table des matières

1 Introduction
2 État de l’art
2.1 Le contexte
2.1.1 Pourquoi mesurer ?
2.1.2 L’ingénierie dirigée par les modèles
2.2 Précisions sur les concepts utilisés
2.2.1 Des mesures
2.2.2 Des modèles
2.2.3 Des métamodèles
2.3 Quelques exemples de métriques
2.3.1 Métriques sur les processus de développement
2.3.2 Métriques sur les ressources
2.3.3 Métriques sur les produits
2.4 Spécification et implémentation des métriques
2.4.1 Avec le langage naturel
2.4.2 Avec un langage de programmation généraliste
2.4.3 En utilisant l’introspection ou un MOP
2.4.4 En utilisant un métamodèle
2.4.5 En détournant un langage dédié
2.4.6 En définissant un langage dédié à la mesure
2.4.7 Par une approche générique et générative
2.5 Synthèse et conclusion
3 La mesure des modèles dirigée par les modèles
3.1 Définition du problème
3.1.1 Mesurer les modèles de l’IDM
3.1.2 Indépendamment du domaine d’application
3.1.3 À un coût acceptable
3.1.4 Exemple d’une instance du problème
3.2 L’approche MDM : produits et processus
3.2.1 Une vue produit
3.2.2 Une vue processus
3.2.3 L’aspect génératif du processus
3.3 Le métamodèle de spécification de métriques
3.3.1 Les types de métriques
3.3.2 Les métriques dérivées
3.3.3 Les prédicats
3.3.4 Conclusion
3.4 Architecture logicielle de l’approche MDM
3.4.1 Le concept de marcheur
3.4.2 La chaîne de génération de l’outil de mesure de modèles
3.4.3 Solutions aux exigences d’un outil de mesure
3.4.4 Vue globale de l’architecture logicielle de l’approche MDM
3.5 Analyse de la contribution
3.5.1 Environnement de mesure
3.5.2 Validation
3.5.3 Processus
3.5.4 Orientation modèle de la solution
3.5.5 Domaine d’application
4 Validation de l’approche 85
4.1 Méthode de validation
4.1.1 Mesurer des modèles
4.1.2 Montrer l’indépendance par rapport au domaine
4.1.3 Montrer l’indépendance par rapport au cycle de vie
4.1.4 Identifier et éviter les biais
4.2 Étude de cas: la mesure des programmes Java
4.2.1 Métamodèle considéré
4.2.2 Métriques
4.2.3 Résultats de mesure
4.2.4 Travaux similaires
4.3 Étude de cas: la mesure des modèles d’architecture temps-réel
4.3.1 Métamodèle considéré
4.3.2 Métriques
4.3.3 Résultats de mesure
4.3.4 Travaux similaires
4.4 Étude de cas: la mesure d’un modèle de système de surveillance maritime
4.4.1 Métamodèles considérés
4.4.2 Métriques
4.4.3 Travaux similaires et conclusion
4.5 Étude de cas: la mesure des exigences
4.5.1 Pourquoi mesurer des exigences ?
4.5.2 La mesure des exigences dans la littérature
4.5.3 L’application de notre approche à la mesure des exigences
4.5.4 Métamodèle d’exigences
4.5.5 Discussion
4.6 Un cas particulier: la mesure des métamodèles Ecore
5 Conclusion & Perspectives
A Glossaire
B Annexe

Cours gratuitTélécharger le document complet

Télécharger aussi :

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *