Visualisation de l’évolution du logiciel

L’évolution du logiciel est une partie de l’analyse qui se prête particulièrement bien à la visualisation puisqu’il faut rapidement trouver des informations pertinentes parmi la grande quantité d’informations. VERSO traite d’ailleurs de l’évolution du logiciel tant par la visualisation de plusieurs versions que dans un contexte affichant des métriques sur l’historique des versions.

Les approches automatiques d’analyse du logiciel sont en mesure de considérer de grandes quantités de données rapidement. C’est pourquoi ce genre d’approche s’est in- téressé à l’évolution du logiciel, où il est possible d’extraire des informations sur le pro- cessus de développement d’un logiciel et sur sa maintenance. Les approches visuelles n’ont pas tardé à emboîter le pas pour pallier les manques des analyses entièrement ma- nuelles ou entièrement automatiques. Curieusement, peu d’entre elles ont su exploiter l’animation discutée dans la sous-section précédente.

Une façon classique de représenter les informations des logiciels et de leur évolution est d’utiliser une matrice où l’axe des Y représente les entités et l’axe des X le temps ou encore les différentes versions. Aux intersections ligne-colonne, on place un point de couleur ou un élément graphique plus complexe possédant plusieurs caractéristiques. Un bon exemple de la première technique est présenté par Wu et al. [97] alors qu’un exemple de la deuxième peut être retrouvé à l’intérieur des travaux de Lanza et Ducasse [55]. Une comparaison entre les deux approches est présentée à la figure 2.7. Plusieurs travaux utilisent une ligne du temps [19, 57, 64] avec des configurations semblables aux matrices. D’autres approches sont utilisées pour représenter l’évolution du logiciel. Dans ce cas, on agrège plutôt les informations dans une image unique et on présente les infor- mations sur l’évolution elle-même plutôt que de la présenter à travers les transitions. Par exemple, Fischer et Gall [28] étudient les changements simultanés à l’aide de graphes suivant le principe d’attraction et de répulsion. Plus les éléments sont près, plus ils ont tendance à être modifiés ensemble. Pinzger et al. [76] utilisent des diagrammes de Kiviat en représentant les versions par de nouvelles couches sur le diagramme (voir figure 2.8). D’Ambros et al. [20] utilisent des figures fractales pour représenter la contribution des

23

Figure 2.7 – Visualisation de l’évolution du logiciel à l’aide d’une matrice. Les objets peuvent être aussi simples que des pixels [97] (gauche) ou encore être des symboles plus complexes montrant plusieurs métriques à la fois [55] (droite).

auteurs pour les différents fichiers. Plus un auteur participe à un fichier, plus sa bande de couleur sera importante.

Lungu et al. [58] présentent une approche basée sur une application web et compo- sée de plusieurs visualisations simples incluant des tableaux, des lignes de temps et des graphes. Les informations observées sont en relation avec des répertoires reliés à un sys- tème de contrôle de versions. Plutôt que d’observer un projet unique, ils choisissent d’ob- server tout l’écosystème d’un projet regroupant plusieurs répertoires. Greevy et al. [34] présentent une visualisation simple pour étudier l’évolution du logiciel, mais du point de vue d’entités plus abstraites que la classe (features). Ils utilisent des boîtes englo- bantes pour représenter les features et ajoutent les classes comme des petits carrés de couleur selon une caractérisation des entités. Plus spécifiquement pour l’évolution, des vues historiques et des vues d’additions montrent les classes retirées ou ajoutées sur une période de temps. De plus, un graphe d’évolution montre les tendances des propriétés pour une entité calculées en fonction des classes présentes dans l’entité. Ils évaluent leur approche à l’aide d’études de cas impliquant l’évolution de différentes branches pour le projet SmallWiki.

Kuhn et al. [48] proposent pour leur part une méthode de placement des éléments pour que les utilisateurs se créent une carte mentale du programme. Ils utilisent la si-

Figure 2.8 – Représentation de l’évolution de métriques à l’aide d’un diagramme de Kiviat [76]. Les métriques sont distribuées de façon équidistante autour du cercle et chaque couche de couleur représente une version.

milarité lexicale pour regrouper les classes entre elles et des techniques de réduction de dimensions pour arriver à les positionner en deux dimensions. L’utilisation de la proxi- mité lexicale a pour but de réduire les écarts entre les placements des différentes versions. Selon les auteurs, cette proximité lexicale donne de meilleurs résultats pour la stabilité que la structure des programmes. Pour ajouter à cette stabilité, les résultats des place- ments aux étapes précédentes sont pris en compte lors du calcul des positions, résultant en des déplacements lents et progressifs.

Par ailleurs, quelques approches utilisent l’animation comme nous entendons le faire dans la partie traitant de l’évolution de cette thèse. Dans un premier temps, D’Ambros et Lanza [18] présentent une approche appelée Evolution Radar qui montre aussi les chan- gements simultanés. Un fichier est placé au centre de la visualisation et pour une période donnée, on peut voir quels fichiers ont changé en même temps selon leur distance du centre du cercle (voir figure 2.9). Ces images peuvent être générées et montrées en sé- quence. Ensuite, Collberg et al. [14] ont développé une manière de visualiser les graphes de flux de contrôle et les graphes d’appels. Pour conserver une cohérence entre les diffé- rentes représentations, les versions de chaque noeud sont reliées par des liens invisibles,

25 ce qui réduit leur mouvement par effet de bord de l’algorithme de placement basé sur des ressorts. Beyer et Hassan [4] utilisent le principe du story-board pour présenter chaque étape de la visualisation. Ils utilisent aussi le principe de l’attraction et de la répulsion pour placer les éléments dans un univers en deux dimensions. Cette approche est utilisée dans le cadre de la représentation des informations extraites des systèmes de contrôle de versions.

Figure 2.9 – Exemple de l’Evolution Radar [18]. Avec cette visualisation, un fichier est placé au centre du cercle et les autres fichiers du programme se rapprochent de ce dernier s’ils font l’objet d’un même commit.

Enfin, Ogawa et Ma [71] utilisent aussi l’animation pour représenter l’évolution du logiciel, plus particulièrement en s’intéressant aux systèmes de contrôle de versions. Leur approche met le programmeur (de logiciels à source ouverte) au centre de la visua- lisation avec les fichiers modifiés qui gravitent autour de lui. La métaphore utilisée est celle de l’astronomie où les fichiers sont plus gros quand ils sont modifiés plus souvent et dont la brillance à l’écran représente le temps passé depuis la dernière modification. Les auteurs insistent sur l’importance de l’esthétique et sur une durée optimale des petits films représentant l’évolution du logiciel. Ils veulent être en mesure de montrer ces films à un public qui n’est pas nécessairement analyste en informatique et discutent même de l’esthétique d’une visualisation organique pour des utilisateurs qui ne connaissent pas

les informations sous-jacentes. La génération des films est très longue et ne peut donc pas être utilisée pour une analyse immédiate et continue d’un projet, mais plutôt pour résumer les points culminants de l’évolution d’un logiciel. Une image illustrant leur ap- proche est présentée à la figure 2.10.

Figure 2.10 – Une image de l’évolution d’Eclipse telle que représentée dans le logiciel code swarm [71] où les fichiers gravitent autour de leurs auteurs.