Nous vous proposons une série d’articles qui traitent le problème de compréhension des logiciels en utilisant une approche différente que la lecture séquentielle du code source classique. Comme la littérature l’indique, plus de 70% du temps de la maintenance des logiciels est dédié à la lecture et la compréhension du code, l’une des approches que nous adoptons devant ce problème est l’utilisation des visualisations.
Ce blog résume un article scientifique publié en conférence VISSOFT 22.
- Class Blueprint V1
La première version de Class Blueprint a été conçue par Michele Lanza et Stéphane Ducasse il y a 20 ans. Cette visualisation repose sur le principe de graphe d’appel entre les méthodes d’une classe ainsi que ses attributs. Elle a connu un grand succès grâce à la classification des éléments de la classe en couches, la représentation des éléments de la classe en nœuds, le lien entre les éléments et finalement les couleurs pour désigner le type de chaque nœud. La visualisation est l'une des classiques qui reste utile et jusqu'à aujourd'hui.
Afin de mieux comprendre l'évolution de la visualisation après deux décennies, allons voir d'abord la version originale. La figure ci-dessous montre un exemple de la visualisation.
Les couches :
La lecture de la visualisation se fait de gauche à droite. Elle est composée de cinq couches :
Initialization: Toute méthode d'initialisation ou constructeur,
Externals: Les méthodes appartenant à l'interface publique de la classe,
Internals: Les méthodes privées de la classe,
Accessors: porte bien son nom, une couche dédiée aux accessors des attributs,
Attributs: Une couche pour les attributs.
Les noeuds :
Chaque méthode ou attribut est représenté par un nœud, le lien entre ces entités correspond à un appel entre méthodes ou un accès à un attribut. De plus, le nœud de chaque entité comporte deux métriques comme expliqué dans la figure ci-dessous.
La légende des couleurs :
Finalement, à chaque type de méthode est attribuée une couleur. Par type, on veut exprimer si la méthode est abstraite, si elle étend ou surcharge une autre méthode, si elle. fait une délégation, si elle renvoie une valeur constante etc. Vous trouverez la description des couleurs dans la figure à droite.
- Class Blueprint V2
Afin d’améliorer la qualité de la visualisation et la rendre plus pertinente pour les développeurs, il nous a fallu discuter avec des mainteneurs de projets afin d’identifier de nouvelles exigences pour la nouvelle génération de la visualisation. Ces exigences sont basées sur de nouveaux concepts informatiques qui se sont développés depuis la création de la visualisation originale. Ces concepts (qu’on va élaborer plus tard) sont importants pour une meilleure compréhension des classes et l'évaluation de leurs qualités. La figure en dessous démontre la nouvelle génération de Class Blueprint sur la même classe présentée que précédemment.
Afin de lire la visualisation, nous allons d’abord expliquer ces couches qui constituent la grande différence entre la V1 et la V2. Puis, nous allons mettre en évidence la suite des concepts conçus dans la V2.
Les couches:
La V2 est désormais composée de trois couches. Une en haut, une au milieu ayant quelques détails proches de la V1 et une en bas.
Intéressons nous à la couche du milieu qui représente la partie instance de la classe . Elle reprend les trois premières colonnes de la V1 : Initialisation, Externals, Internals et Attributs. Cependant, on voit bien qu’il n’y a plus que quatre colonnes et que cette dernière est divisée en deux. En effet, la colonne des accesseurs a été éliminée. Concernant la dernière colonne, toujours dans la partie centrale, qui est divisée en deux parties, celle en haut avec un nœud vert rassemble les attributs de la superclass accédés dans cette classe, et celle juste en bas contenant trois attributs en bleu représente les attributs qui sont définis dans la classe elle-même. Maintenant, si on se demande où sont partis les accesseurs ? Les accesseurs sont les petits rectangles qui entourent le nœud de l’attribut quand il est défini dans la classe. Le setter de l’attribut se retrouve en haut du nœud, quant au getter ou lazy initializer est en bas du nœud de l’attribut. Le concept même du lazy initializer est une nouvelle particularité de la V2, la version originale de la visualisation ne couvrait pas cette information. Quant aux couleurs des attributs, contrairement aux attributs en bleu, les attributs en vert ne sont pas seulement accédés dans la classe sous analyse mais aussi dans ses sous classes. Ceci permet aux développeurs d’extraire de mieux comprendre la structure et la relation hiérarchique des classes.
Revenons à la couche tout en haut qui représente les éléments static de la classe. A gauche c’est la partie correspondant aux méthodes, à droite celle dédiée aux attributs statiques. Encore une fois, la division entre la partie statique et la partie instance n’était pas prise en compte dans la V1. Toutefois, cette division permet aux développeurs de mieux voir les échanges entre le côté statique de la classe et le côté instance.
Dernier point, mais pas le moindre, c’est bien la couche inférieure de la visualisation qui représente le dead code de la classe. Là encore, les méthodes (mortes) sont à gauche et les attributs (morts et leurs accesseurs) à droite. L’idée est de mettre en évidence le dead code car il risque de distraire les développeurs de la fonctionnalité réelle de la classe. De plus, les développeurs peuvent passer du temps à lire et essayer de comprendre un code qui n’est pas réellement utilisé et qu’ils ne vont probablement pas réutiliser. Bref, inutile. Finalement, cette particularité de dead code leur permet de pouvoir nettoyer leur code.
Cette répartition des couches permet de mieux catégoriser les méthodes de la classe pour une bonne compréhension du code source. De plus, ça permet de ne pas avoir tous les nœuds au centre afin de donner plus d’espace pour le graphe d’appel entre les méthodes/attributs de la classe.
Les annotations :
Passons maintenant aux annotations des nœuds et couleurs. Une nouvelle annotation des nœuds a été introduite dans la V2, comme pour le nœud tout en haut à gauche en cyan. Les nœuds en cyan représentent les méthodes abstraites. Quant aux nœuds en cyan avec un tout petit carré en pêche pâle à l’intérieur, ils représentent les méthodes abstraites qui sont re-définies dans le sous-système. Ceci permet de différencier encore une fois quelles sont les méthodes redéfinies et celles qui ne le sont pas. Une autre annotation de nœud a été introduite, comme pour le nœud en orange dans la couche Externals. Cette annotation en vert indique qu’une méthode est testée (et non que le test passe, c’est de l’analyse statique et non dynamique du code !). Les tests sont importants car ils permettent, entre autres, de mieux mesurer la fiabilité du logiciel. Voir quelles sont les méthodes testées et les non testées permet aux développeurs de non seulement évaluer le logiciel mais de le renforcer en cas d'insuffisance de tests.
La bordure :
Dernier point, nous avons joué sur la taille et la couleur de la bordure des nœuds correspondant aux méthodes. Les nœuds avec une bordure rouge sont les méthodes avec une complexité cyclomatique élevée. La taille de la bordure varie en fonction du polymorphisme de la méthode. Plus une méthode partage sa signature avec d’autres méthodes plus la bordure sera épaisse. Trois tailles de bordures sont prévues. Par exemple, la méthode toString() aura une bordure très épaisse car elle est souvent redéfinie.
Les couleurs :
Finalement, les couleurs de la V2 sont légèrement différentes de la V2. Le noir par exemple ne represente plus les méthodes d’implementation interne mais plutot les méthodes mortes. Les méthodes d'implémentation interne sont dorénavant en violet. Les nœuds en pale orange dans la V2 représente les méthodes “hooks” qui sont les méthodes non abstraites re-définies dans le sous-système.
NB. L’utilisateur n’est pas censé utiliser ni apprendre toutes ces couleurs, mais cela dépend de ses besoins, son analyse et attentes de la visualisation. Prenons par exemple un développeur qui souhaite chercher toutes les méthodes abstraites et redéfinies dans le système et alors dans ce cas il n'aurait qu'à surveiller le nœud de ce type de méthode dans le défilement des Class Blueprint.
