Visualisation du logiciel

La visualisation du logiciel est étroitement en lien avec les travaux de cette thèse. Notre objectif est de représenter le logiciel pour que des utilisateurs puissent efficace- ment accéder à des informations pour les aider à progresser rapidement dans leurs tâches ou à créer de meilleurs logiciels. Par contre, les travaux énumérés dans cette section se concentrent souvent sur des aspects précis du logiciel et ils ne sont pas intégrés dans le processus de développement, mais plutôt dans une phase d’analyse subséquente.

La visualisation du logiciel fait partie de la visualisation d’informations, puisque les logiciels sont des entités abstraites et la représentation binaire ou textuelle des pro- grammes n’apporte pas de nouvelles informations intéressantes au processus de déve- loppement et d’analyse des logiciels. C’est pourquoi il faut créer des représentations

17 de toutes pièces pour afficher des informations pertinentes. Knight et Monroe [46] font d’ailleurs état de ces faits et ils discutent des apports de la réalité virtuelle sur la com- préhension du logiciel. Plusieurs auteurs ont développé des outils de visualisation pour aider les programmeurs et les analystes à mieux comprendre le logiciel ou à interpréter les analyses faites sur celui-ci. On visualise tantôt les lignes de code elles-mêmes, tantôt des métriques sur des composants plus grands comme les méthodes ou les classes. L’ana- lyse peut se faire de façon statique (code) ou dynamique (trace d’exécution). Bien que la visualisation dynamique soit plus difficilement généralisable et que la visualisation sta- tique ne représente pas toujours l’utilisation réelle d’un programme, il reste que les deux façons de procéder amènent des informations intéressantes et parfois complémentaires.

Avec l’outil SEESOFT [2] (voir figure 2.4), Ball et Eick ont été parmi les premiers à représenter le logiciel, et ce, principalement au niveau de la ligne de code, en utilisant des lignes de couleurs. Ces lignes sont arrangées dans des rectangles représentant les fichiers. Ils sont en mesure d’afficher jusqu’à 50 000 lignes en même temps. Marcus et al. [60], pour leur part, ont transformé ces lignes de couleurs en bandes de couleurs pré- sentées en trois dimensions. Cette fois-ci, les bandes représentent plutôt des méthodes où la hauteur et la couleur sont associées à des valeurs calculées sur chaque méthode. Ils montrent aussi une vue plus traditionnelle en deux dimensions, qui correspond à la vue aérienne de leur représentation en trois dimensions. Lanza et Ducasse [54] utilisent un procédé qu’ils nomment Polymetric Views, où les éléments sont représentés par des rectangles. Jusqu’à cinq valeurs peuvent être associées à des caractéristiques graphiques d’un rectangle soient la couleur, la hauteur, la largeur et la position dans les deux dimen- sions. Selon la tâche d’analyse, les éléments peuvent être triés ou encore on peut voir la structure hiérarchique à l’aide de liens sous forme de lignes entre les rectangles. Cette recherche est basée sur le métamodèle MOOSE [69] qui a d’ailleurs engendré toute une panoplie d’outils de visualisation appliqués à la rétro-ingénierie et à la présentation des métriques. Certaines approches se sont aussi intéressées à l’évolution du logiciel et aux informations tirées des logiciels de contrôle de versions. Lienhard et al. [56] proposent un outil d’aide à la rédaction des tests unitaires. Une fenêtre de sélection, où les mé- thodes sont arrangées sous forme d’arbre montrant le fil d’exécution, permet de choisir

une méthode pertinente. Une fois la méthode sélectionnée, un graphe des types utilisés dans les appels et les sous-appels de cette méthode est créé. Ce graphe est appelé Test Blueprint et, avec l’aide d’informations fournies sur demande, il assiste les utilisateurs dans la création de tests.

Figure 2.4 – Visualisation des lignes de code à l’aide de bandes de couleurs avec l’outil SEESOFT [2].

Termeer et al. [91] sont partis d’une visualisation traditionnelle du logiciel, c’est-à- dire le diagramme de classes UML, et l’ont améliorée grâce à la visualisation en trois dimensions et grâce à l’utilisation des métriques de classes. En fait, ils présentent le diagramme de classes UML sur un plan et ajoutent des cubes émergeant de ce plan. Chaque entité représente une métrique et la transparence permet de lire le diagramme UML sous-jacent. Rilling et Mudur [83] ont utilisé le program slicing 1 _{et une repré-}

sentation de sphères en trois dimensions reliées entre elles pour visualiser le logiciel. La couleur permet de représenter une information supplémentaire. Le program slicing permet de réduire la quantité des informations présentées et ainsi de réduire les possibles

19 occultations dues à la troisième dimension.

Ensuite, Wettel et Lanza [95] ont utilisé la métaphore de la ville pour représenter le logiciel, et plus particulièrement la facilité de maintenance du logiciel. Dans leur re- présentation, les classes sont des édifices et les lotissements sont des paquetages. Ils visualisent les métriques à l’aide de la largeur, de la hauteur et de la couleur des édi- fices(voir la figure 2.5). Les auteurs ont par la suite étendu leur approche à l’évolution des logiciels [96]. Panas et al. [74] avaient énoncé une idée semblable sur la métaphore de la ville, en présentant des travaux où l’importance du réalisme immerge mieux les utilisateurs lors de ses analyses. Le principe des métaphores permet aux utilisateurs de transférer des connaissances sur un sujet qu’ils maîtrisent bien (par exemple la ville) vers un sujet qui leur est nouveau (par exemple la qualité du logiciel). L’influence de la mé- taphore sur l’apprentissage et l’assimilation d’informations est étudiée par Mason [61].

Figure 2.5 – Représentation de ArgoUML avec Code City [95]. Dans cette visualisation, la hauteur et la taille de la base des éléments représentent des métriques. Ces éléments sont placés selon la hiérarchie de paquetages. La métaphore de la ville est utilisée reliant les éléments représentés à des édifices.