Stratégie de test au sein du processus d'évolution d'architecture de Sodifrance

3.2.2.2 Représentation graphique de la cartographie des tests

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... inutiisable

CNAM de Nantes - 2010 / 2011 - Mémoire d'ingénieur

CNAM de Nantes - 2010 / 2011 - Mémoire d'ingénieur

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¹⁹. 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.

¹⁹ yEd : Editeur graphique : http://www.yworks.com/.../yEd.html

CNAM de Nantes - 2010 / 2011 - Mémoire d'ingénieur

Figure 25 : Exploitation de la cartographie pour produire un graphe

Figure 26 : Graphe hiérarchique d'appels entre éléments

CNAM de Nantes - 2010 / 2011 - Mémoire d'ingénieur

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 »²⁰. 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 ».

²⁰ source documentation yEd

CNAM de Nantes - 2010 / 2011 - Mémoire d'ingénieur

yEd donne la possibilité de modifier l'aspect graphique des éléments du graphe. Ainsi, nous avons déterminé une formule²¹ 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.

²¹ 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.

CNAM de Nantes - 2010 / 2011 - Mémoire d'ingénieur