Introduction
Les Distribution Maps font partie des visualisations appliquées dans la rétro-ingénierie afin d’aider à la compréhension des systèmes informatiques dites ‘larges’. On avait déjà parlé dans un blog précédent de ces systèmes et de leur évolution qui peut avoir des conséquences dévastatrices sur le long terme-- si ces systèmes ne sont pas bien maintenus.
Dans ce blog nous allons explorer cette technique de visualisation et expliquer ses principes, nous allons aussi présenter un exemple concret pour montrer son utilisation en pratique. Le but ultime des visualisation est la simplification des données, leur représentation sous une forme plus compréhensible par l'être humain et de faciliter la transmission des données de l'œil au cerveau humain et la communication entre différentes personnes.
Principes des Distributions Maps
Ainsi, les Distributions Maps aident à la compréhension des codes source en analysant la distribution de certaines propriétés sur un logiciel et permet de répondre à des questions précises concernant ces propriétés.
La technique utilise des cases afin de représenter les différentes parties du système. Dans la mesure où un système est souvent structuré (par exemple des classes dans un paquetage ou des fichiers dans un répertoire), ces cases sont regroupées dans des plus grosses cases. La couleur de la case dépend de la valeur de la propriété pour cette entité. Un peu d’huile de coude permet d’ordonner les cases englobantes et les cases internes en fonction de la valeur de la propriété. En effet, il est plus facile pour le cerveau humain de réaliser le nombre de cases ayant une même couleur si elles sont à côté (principe Gestalt de similarité. Un article intéressant sur la similarité peut être trouvé ici.). Et pareil pour comparer deux cases englobantes.
Dans l’exemple suivant, on a tout le logiciel JBoss (dans une vieille version). Chaque boîte englobante correspond à un paquetage avec son nom au dessus. Chaque boîte colorée interne correspond à une classe. La couleur dépend de l’auteur de la classe. Par auteur, on entend celui qui a le plus modifié la classe.
On peut voir dans cette figure que :
L’auteur orange gère tout ce qui touche à la base de données et au SQL et uniquement ça. La connaissance sur ces paquetages est concentrée autour d’une personne. S’il vient à disparaître, cela peut être rédhibitoire pour l’entreprise. Il en est de même pour l’auteur cyan qui gère toute la partie web services.
L’auteur représenté en jaune touche à un peu tous les domaines.
A l’opposé, certains paquetages sont modifiés par différentes personnes comme le paquetage ejb (3ème ligne 8ème paquetage). Ou uniquement par une seule personne comme le paquetage query (avant dernier en bas à droite).
Il est possible de changer :
ce que représentent les boîtes englobantes, dans notre exemple des paquetages, mais ça pourrait être des classes, des répertoires, ou n’importe quoi d’autre.
ce que représentent les cases internes, dans notre exemple des classes, mais ça pourrait être des méthodes, des fichiers ou n’importe quel type d’entités contenues dans les précédentes.
ce que représente la propriété, dans notre exemple l’auteur d’une classe, mais ça pourrait être le nombre de bugs, la complexité cyclomatique, le nombre de changements. Si le nombre de valeurs est trop important, il est possible, en particulier pour les valeurs numériques, de mettre des écarts de valeurs afin de limiter le nombre de couleur ou comme dans la figure ci-dessus de ne prendre que les X premières valeurs de la propriété et de mettre toutes les autres valeurs dans une seule et même couleur. En effet, l’humain ne peut pas distinguer trop de couleur, il vaut donc mieux en limiter le nombre.
Il faut garder à l’esprit qu’une visualisation représente un état d’un système à un instant donné et qu’elle est construite dans un but particulier, ici comment une propriété se distribue sur un système.
