J’ai étudié et maquetté sous forme de services Java plusieurs types de représentations graphiques.
A partir des données de la cartographie d’application, j’ai produit un modèle UML qui exporté au
format XMI puis importé dans MagicDraw, permet d’obtenir un diagramme de classe et de
visualiser les relations entre les opérations (cf. Figure 22).
Figure 23 : Exploitation de la cartographie de test pour produire un diagramme de séquence
Figure 24 : Exploitation de la cartographie pour produire un diagramme de classes… inutilisable
Ensuite, à partir de la cartographie de test, j’ai produit un diagramme de séquence, plus approprié à
représenter les cas de tests, car il permet de garder la chronologie entre les appels. Contrairement à
UML 1.3, UML 2 n’intègre plus lors dans son format d’import de fichier XMI la description des
diagrammes. Elles sont déportées dans des extensions spécifiques à chaque modeleur. J’ai donc
utilisé la version UML 1.3 et le modeleur Star UML afin d’importer le diagramme de séquence (cf.
Figure 23).
Ces deux types de représentation, bien que reconnues de par leur formalisme, ne conviennent pas ou
ne répondent pas de façon satisfaisante à nos besoins. On observe aisément que les problèmes de
volumétrie vont vite devenir rédhibitoires. Sur une application un peu plus conséquente, le
diagramme de classe mis en forme de manière automatique devient très rapidement illisible (cf.
Figure 24).
On arrive au même souci avec le diagramme de séquence sur des cas de test plus imposants,
d’ailleurs la Figure 23 n’est qu’un extrait d’un diagramme beaucoup plus important. Partant du
principe que le besoin initial est de représenter des objets et leurs relations, je me suis orienté vers
un logiciel de graphe reconnu : yEd(19). Bien sûr l’idée n’est pas d’opposer MagicDraw et yEd, ces
deux logiciels ayant chacun leurs fonctionnalités, mais de chercher à obtenir une représentation de
l’information exploitable, même en cas de volumes de données important.
Figure 25 : Exploitation de la cartographie pour produire un graphe
Figure 26 : Graphe hiérarchique d’appels entre éléments
yEd est un logiciel spécialisé dans la représentation et la mise en forme des graphes. Les graphes
sont composés de noeuds reliés entre eux par des arcs. Par exemple, la Figure 25 a les mêmes
données d’origine que la Figure 24, simplifié puisqu’on ne détaille pas les méthodes, et mise en
forme selon l’algorithme « organique » définit par yEd. Il a pour particularité de donner un « graphe
groupé, une répartition équilibrée des noeuds et peu de croisements d’arcs »(20). Outre les nombreuses
options de mises en forme, il y a des fonctionnalités poussées de recherche et de sélection des
noeuds, selon des critères aussi divers que leurs noms, leurs couleurs, les prédécesseurs de, les
successeurs de.
Par exemple, il est très simple de sélectionner un noeud ainsi que tous ses descendants, et ensuite de
créer un nouveau graphe à partir de cette sélection. Ici, la Figure 26 reprend les éléments
sélectionnés dans un graphe beaucoup plus important et les disposent sous forme hiérarchique.
Figure 27 : Exploitation de la cartographie de test pour produire un graphe hiérarchique
Un inconvénient tout de même si on compare le graphe hiérarchique au diagramme de séquence, on
peut voir qu’on perd la chronologie exacte des appels de méthodes. En fait l’ordre général est
conservé, mais quand une méthode en appelle deux autres, on ne peut plus savoir laquelle des deux
a été appelée en premier. Dans la Figure 27, on ne sait pas quel élément de « GE_1.0.D_GECONN »
ou « GE_1.0.W_GEMENU » est appelé en premier à partir de « GE_1.0.DTR01 Référentiel
Etablissement_08_04_2011__9_53_39 ».
yEd donne la possibilité de modifier l’aspect graphique des éléments du graphe. Ainsi, nous avons
déterminé une formule(21) donnant une valeur, un poids, en fonction de la complexité des
composants. Le poids d’une classe ou d’un écran correspond à la somme des poids de ses méthodes.
Il est ensuite très facile de modifier la taille d’un élément en fonction de son poids, et donc de sa
complexité. Il en ressort des graphes dans lesquels les composants les plus complexes, en général
ceux qui devront recevoir une attention particulière, sont facilement identifiables (cf. Figure 27).
La troisième piste utilisée pour représenter les informations de cartographie a été le développement
d’un plugin Eclipse par un stagiaire en Master 2 Informatique que M. Pacaud et moi-même avons
encadré, sous la responsabilité de M. Breton. Ce plugin décrit plus en détail dans le § 4.1, est plutôt
à destination des chefs de projet qui souhaitent suivre l’avancement de l’intégration des projets.
On y retrouve sous forme arborescente la cartographie de l’application ainsi que les scénarios de tests et
l’avancement de l’intégration de chaque composant. L’outil est complété par des vues donnant des
indications de volumétrie selon des angles différents : nombre de composants graphiques par type,
nombres d’événements graphiques par type d’événement et de composant, etc.
19 yEd : Editeur graphique : http://www.yworks.com/…/yEd.html
20 source documentation yEd
21 Cette formule met en relation le nombre de lignes de code (Source Line Of Code, SLOC), le nombre cyclomatique, et
pour un écran, le nombre de composants graphiques.
Page suivante : 3.2.3 Objectif 2 : automatisation des tests
Retour au menu : Stratégie de test au sein du processus d’évolution d’architecture de Sodifrance