G^SEE

A
Generic
Software
Exploration
Environnement

last update: 19 november 2002

Current status

G^SEE is currently a (set of) prototype(s). Good enough to use it on large software and to explore new exciting ideas. However, as is, it is not easy to use since it is developed on a "feature-on-demand" basis. This summer a group of 3 students (Laurence Estrabeaut, Alexandre Roux, Florence Whimet, worked on a component-based framework implementing a few functions of G^SEE in a JavaBean approach, leading to G^SEE_Bean, is one part of the G^SEEenvironment and this bundle can be delivered separately.

G^SEE_Bean is shortly described in the paper submitted to CSMR'2003.

G^SEEis described in various paper, in particular in IWPC'2001 and in CSMR'2002. Other papers describe the use of in different context including industrial settings.

G^SEE is free and available on request, but unfortunately no support is available. Anyway, feel free to contact me : jmfavre@imag.fr

Related Publications

The following collection of papers constitutes the main source of information about GSEE.

J.M. Favre, H. Cervantes, "Assembling Specific Exploration Tools from Components: First Experience with JavaBeans"
Submitted to CSMR'2003

J.M. Favre, "A New Approach to Software Exploration: Back-packing with G^SEE"
European Conference on Software Maintenance and Reengineering (CSMR'2002), 2002

J.M. Favre, "G^SEE: a Generic Software Exploration Environment"
Proc. of the 9th International Workshop on Program Comprehension, IEEE, (IWPC'2001),
Toronto, Canada, May 2001, pp. 233-244

J.M. Favre, "A Flexible Approach to Visualize Large Software Products",
ICSE Workshop on Software Visualization
Toronto, Canada, May 2001
J.M. Favre, F. Duclos, J. Estublier, R. Sanlaville, J.J. Auffret, "Reverse Engineering a Large Component-based Software Product",
Proc. of European Conf. on Software Maintenance and Reengineering, (CSMR'2001)
Lisboa, Portugal, March 2001, pp. 95-104
R. Sanlaville, J.M. Favre, Y. Ledru, "Helping Various Stakeholders to Understand a Very Large Software Product"
Proc. of the European Conference on Component-Based Software Engineering
Warsaw, Poland, September 2001
J.M. Favre, H. Cervantes, F. Duclos, R. Sanlaville, J. Estublier, "Issues in Reengineering the Architecture of Component-Based Software",
Workshop on Software Architecture Recovery and Modeling (SWARM)
at the Working Conference on Reverse Engineering, (WCRE'2001),
Stutgart, October 2001
other publications

Page under construction...

If you need more information, please contact me
Si vous voulez plus d'information, n'hésitez pas à me contacter : jmfavre@imag.fr
Si quiere mas informacion, contacteme

Se habla castellano, you can also try in english
Différents autres articles sont écrits ou en cours de préparation.

transparents

GSEE : Les besoins

L'environnement GSEE a été conçu pour répondre aux besoins suivants qui le différencie des outils d'exploration traditionnels :

Exploration générique. L'environnement est indépendant du modèle de données utilisé, c'est à dire de la source des données et de la structuration de celle-ci. On doit par exemple pouvoir visualiser aussi bien des hiérarchies de classes de logiciels écrits en Java que les dépendances entre paquetages, ou entre gamme de produits.
Exploration quantitative. Sachant que l'on manipule un très grand volume d'informations, il doit être possible non seulement d'explorer les différentes entités du logiciel mais également des informations quantitatives. Par exemple, sachant qu'un logiciel de grande taille peut être formé de plusieurs milliers de classes, il est parfois préférable de visualiser non pas l'intégralité de la hiérarchie des classes, mais au contraire une vision simplifiée en traduisant des informations quantitatives, comme le nombre de classes concernées, par des attributs graphiques tels que la taille ou la couleur d'un élément graphique.
Exploration du (méta) modèle. Lorsqu'un logiciel est très complexe, le (méta) modèle de données correspondant l'est aussi : il existe de très nombreux types d'entités et de relations allant de relations déduites du langage de programmation (par exemple la relation d'héritage entre les classes), à des relations telles que la composition d'une configuration ou les dépendances entre les produits de la société. Dans de grandes entreprises il n'est pas rare que personne ne connaisse en détail l'intégralité de ce (méta) modèle. Il est alors utile de pouvoir explorer non seulement les instances du logiciel (les entités), mais également le (méta) modèle structurant ce logiciel.
Exploration multi-versions. Tout logiciel évolue et existe donc en différentes versions. Alors que la plupart des environnements existants se limitent à l'exploration d'une seule version à la fois, on souhaite pouvoir explorer simultanément différentes versions et ainsi visualiser l'évolution du logiciel, par exemple l'évolution d'une hiérarchie d'héritage au cours du temps.
Exploration active. Les outils d'exploration permettent d'améliorer la compréhension de la personne qui les utilisent, mais le résultat de cette compréhension n'est généralement pas matérialisé et est donc à la fois volatile et non parteagable. Sachant que explorer un logiciel est une activité qui peut être relativement longue et couteuse, il est important de fournir des services permettant d'ajouter des signets et des annotations aux informations explorées. Il est également souhaitable de pouvoir créer de nouvelles abstractions par exemple en regroupant des entités dans des unités logiques virtuelles. L'exploration devient alors active dans la mesure ou de nouvelles informations sont créées.
Exploration personnalisée. De très nombreuses activités en génie logiciel peuvent bénéficier d'un environnement d'exploration. Alors que certains activités, telle que la compréhension sont très "exploratoire" dans la mesure où elle ne correspondent pas à un processus défini et peuvent mettre en jeux différents aspects du logiciel, d'autres sont au contraire correspondent à un processus relativement figé et ne mettent en oeuvre que des informations spécifiques. Par exemple, un responsable qualité souhaitera pour évaluer la qualité du logiciel produit, examiner systématiquement les mêmes vues sur le logiciel. L'environnement d'exploration doit pouvoir être personnalisé afin differents outils spécialisés.

GSEE : L'approche

Plutot que de fournir un outil général essayant de répondre à tout les besoins, notre approche est basée sur les techniques modernes de dévelopement logiciels, entre autre sur l'approche composant. Plus concrètement il s'agit de proposer un environnement formé de :

un framework.
un ensemble d'outils de démonstrations paramètrables.
un constructeur d'outil d'exploration.

GSEE : Les résultats

GSEE étant indépendant de la source de données il peut être utilisé dans de très nombreux contextes (autre que l'exploration du logiciel). Pour montrer l'intérêt de l'approche nous avons développé ou intégré différentes sources de données. Intégrer une nouvelle source peut se faire dans certains cas en quelques minutes. Ci-dessous, à titre d'illustration nous montrons comment visualiser différents aspects de logiciels java.

Exemples d'exploration de logiciels java

Exemple 1: visualisation de hiérarchies de classes

A titre d'exemple voici ci-dessous une image montrant plus de 700 classes java provenant des paquetages "java.awt" et "java.swing" (les classes graphiques de java). Cette image est entièrement spécifiée par les paramètres apparaissant sur l'écran :

les noeuds représentent les différentes classes (plus de 700) appartenant aux paquetages indiqués,
les arcs représentent la relation d'héritage, la classe racine (Object) étant au bas de l'image. On voit par exemple qu'il y a jusqu'à 8 niveau d'héritage.
la couleur de chaque noeud représente le paquetage dans lequel se trouve la classe (e.g. java.awt en marron, java.swing en noir). On voit par exemple que le paquetage java.awt.event (en bleu) contient une hiérarchie entière de classe (les événements).
la hauteur d'un noeud représente le nombre de méthodes (on remarque tout de suite les classes java.awt.Component et javax.swing.JComponent),
la largeur représente le nombre d'attributs,
...

Différentes opérations permettent de modifier l'image, d'obtenir des informations supplémentaires sur les noeuds, etc.
Le rendu est similaire à l'excellent outil CodeCrawler. Grace à GSEE et à l'encapsulation de visualisateur de graphe Grappa/Dot, 4 lignes seulement sont suffisantes pour obtenir un résultat similaire (CodeCrawler propose néanmoins d'autres fonctions plein d'autres fonctions d'exploration très très intéressantes, you have to look at it).

Exemple 2: visualisation de la structure de paquetages

Ci-dessous la technique des cartes arborescentes (tree-maps) est utilisée pour afficher plusieurs milliers de classes java, l'imbrication des boites correspondant aux différents paquetages, la surface de chaque rectangle correspondant à la taille de la classe. On voit très facilement que la librairie standard (java.*) représente une partie plus petite que la librairies (javax.*), et de plus que les paquetages javax.swing.text et javax.swing.plaf représente une part significative du jdk (ces paquetages sont "fermés" sur la figure et appaissent donc en blanc).

Exemple 3: visualisation des dépendances entre paquetages java

La figure ci-dessous présente l'un des outils de démonstration associé au framework GSEE. Il s'agit d'un interpreteur d'un mini langage fonctionnel permettant d'évaluer des expressions. Il peut donc servir à la fois de langage de requête mais aussi d'outil de visualisation. Le resultat d'une expression est à la fois visualisé sous forme textuelle (dans la fenêtre historique en haut) et sous forme graphique (dans la fenêtre du bas). Dans l'exemple ci-dessous, un session complète est montrée. La première ligne consiste à charger un composant d'analyse (ici le composant JAssistant). Les lignes suivantes permettent de définir de nouvelles fonctions et de les tester interactivement. Par exemple la fonction "use" est définie entre deux paquetages comme étant la synthèse de la relation d'héritage entre classes. Autrement dit un paquetage utilise ("use"à un autre, si au moins une classe dans le premier hérite d'au moins une classe dans le deuxième. On aurait pu bien évidemment donner une autre définition. Celle-ci permet simplement de voir comment la relation d'héritage "traverse" les différents paquetages. La dernière ligne montre pour le paquetage "java.lang.reflect" le graphe correspondant. Comme on peut le voir les paquetages centraux de java sont tous connectés les uns aux autres!

Gràce au framework GSEE cet outil de démonstration ne fait que 60 lignes de code. Aucune ligne de code n'est spécifique à Java. C'est le chargement du composant adavid.jar (première ligne) qui fait que l'on peut utiliser cette source d'information. Autrement dit, en quelques minutes ont peut intégrer de nouvelles sources de données et les explorer, même si l'on ne connait pas la structure de ces sources. Dans ce cas il est nécessaire d'explorer le modèle de logiciel lui même (le composant que l'on vient d'integrer dynamiquement). GSEE permet cette exploration avec le même outil, comme cela est montré ci-dessous.

Exploration du (méta) modèle

Dans la figure ci-dessous, le modèle (ou méta modèle, tout dépend à quel niveau l'on se place) du logiciel lui même est exploré, avec exactement le même outil. On peut explorer aussi le méta-méta modèle mais ca c'est secret pour l'instant.

GSEE

A Generic Software Exploration Environnement