Choix d’une méthode de représentation

Il existe différentes manières de représenter graphiquement des structures de données complexes. Il est possible d’utiliser des techniques de rendu 2D ou 3D, d’incorporer la dimension temporelle dans la représentation, ou encore de proposer des fonctionnalités pour développer ou rétracter des parties de la structure (exemple de la vue arborescente du système de fichiers dans Windows Explorer ou du JTree Java). Nous présentons ici les différentes possibilités que nous avons explorées et les raisons qui nous ont conduit à retenir une représentation basée sur une variante des treemaps.

La représentation doit permettre d’unifier de manière assez naturelle les différentes structures mani-pulées, malgré le fait qu’elles sont à des niveaux d’abstraction différents (les DTDs sont des grammaires décrivant des classes de documents XML). Elle doit de plus être assez résistante au facteur d’échelle (sca-labilité de la représentation) puisque l’utilisateur pourra vouloir visualiser des instances de documents et des DTDs complexes. Nous avons assez naturellement opté pour une représentation bidimensionnelle non déformée, principalement pour la raison que nous n’allons pas nous contenter de visualiser la struc-ture, mais allons utiliser la représentation de cette structure de différentes manières dans le cadre de la spécification des transformations. Les représentations tridimensionnelles ou déformées (arbres hyperbo-liques, . . . ) sont intéressantes surtout dans le cadre de la visualisation, mais se révèlent moins efficaces quand il s’agit de manipuler les structures (elles peuvent par contre servir de représentation secondaire aidant à l’orientation et à la navigation dans l’espace).

Agencement spatial

Les structures arborescentes sont souvent représentées au moyen de diagrammes composés de nœuds et d’arcs reliant ces nœuds, comme dans la figure 4.1. Mais il existe une autre méthode d’agencement appelée treemap. Cette méthode, proposée par Shneiderman [130] et reprise dans d’autres travaux [215], consiste en la représentation des relations père-fils par l’emboîtement des enfants à l’intérieur de leur parent. Cette méthode a principalement été utilisée pour la visualisation de structures arborescentes de grande taille, comme les systèmes de fichiers (voir figure 4.2). Contrairement aux méthodes standard à base de diagrammes nœuds/arcs, dans lesquelles plus de 50% des pixels ne sont pas directement utilisés pour la représentation de la structure et font partie du fond d’écran, les treemaps occupent la totalité de

Langage visuel pour la représentation de documents et de classes de documents 85

FIG. 4.2 : Exemple de représentation d’une structure arborescente (système de fichiers) sous forme de

treemap

l’espace alloué, faisant ainsi meilleur usage d’une ressource limitée. Aussi, combinées à des fonctions de navigation évoluées, les treemaps permettent à l’utilisateur d’appréhender la structure de manière plus intuitive en spécifiant le niveau de détail souhaité simplement en se déplaçant dans l’espace (par exemple en modifiant son niveau de zoom, c’est-à-dire son altitude d’observation). Cette méthode pré-sente cependant quelques inconvénients qui peuvent avoir un impact plus ou moins important suivant l’utilisation que fait l’utilisateur de la représentation (absence d’ordonnancement des éléments dans leur parent, taille variable des éléments de même profondeur, variations dans le flot de développement des composants d’un élément à un autre). Certains de ces inconvénients peuvent être contournés en modifiant la méthode d’agencement initiale. Il existe en effet différentes versions des treemaps en ce qui concerne la taille et l’agencement relatif des nœuds à l’intérieur de leur parent. Nous proposons ici une nouvelle variante qui tient compte de la spécificité de notre cas.

La technique standard ne rend pas très explicite l’ordonnancement des fils d’un élément, les plaçant sur plusieurs lignes à l’intérieur du rectangle parent. Cette politique permet d’optimiser l’agencement, et donc l’utilisation de l’espace, mais n’est pas satisfaisante dans notre cas. Nous avons en effet expérimenté cette solution dans un prototype de visualisation de structure XML, dans lequel le placement des fils s’effectue sur plusieurs lignes. De cette manière, il y a un nombre égal d’éléments alignés verticalement et horizontalement et la structure se développe uniformément dans les deux directions (par exemple, si un élément contient huit fils, l’algorithme de placement en positionnera trois sur une première ligne, trois sur une deuxième ligne, et les deux derniers sur une troisième ligne). Le résultat était satisfaisant du point de vue de l’occupation de l’espace mais présentait un problème majeur au niveau de la perception de la structure. Le placement des fils d’un élément sur différentes lignes introduit en effet une discontinuité dans le flot des nœuds qui est dans notre cas ordonné. De plus certains nœuds peuvent se retrouver

représentées sans discontinuité en surimpression, ne s’adapteraient pas visuellement à la structure source. Pour ces raisons, notre variante ne développe les fils d’un élément que sur une seule ligne, de gauche à droite, de manière à éliminer toute discontinuité et à illustrer le fait que ces fils sont ordonnés (voir figure 4.4).

L’autre modification concerne la taille des nœuds. Les représentations à base de treemap ont l’inconvé-nient de représenter l’information de profondeur d’un nœud de manière assez peu explicite, puisqu’elle n’est reflétée que par le niveau d’emboîtement du nœud dans la structure géométrique. Cette informa-tion peut être difficile à extraire de la représentainforma-tion graphique, et requiert de la part de l’utilisateur un effort mental qui rend la perception globale de la structure moins intuitive. Dans le cas des représenta-tions à base de diagrammes nœuds/arcs, les nœuds de même profondeur absolue sont souvent alignés (figure 4.1), ce qui rend l’extraction de cette information bien plus facile. Nous proposons ici d’adapter la taille des éléments en fonction de leur profondeur dans l’arbre. Cet indice visuel, même s’il est un peu moins évident que l’alignement mentionné précédemment, devrait améliorer la perception globale de la structure par l’utilisateur. L’algorithme en charge de calculer l’agencement des éléments assigne donc la même hauteur à tous les nœuds ayant la même profondeur absolue. La hauteur assignée à l’ensemble des nœuds de profondeur n est la hauteur de l’élément le plus haut à cette profondeur, la taille initiale des éléments étant calculée en fonction du contenu et donc de la taille des éléments de profondeur n + 1 (puisque les éléments doivent contenir complètement l’ensemble de leurs fils).

La figure 4.4 donne deux exemples d’utilisation de cette méthode, qui représente un compromis : elle fournit une représentation plus fidèle de la structure, mais consomme aussi plus d’espace d’affichage que les treemaps standard. Cet inconvénient est cependant compensé par le fait que nous proposons une représentation dynamique de la structure offrant de bonnes capacités de navigation et de zoom, qui sont aussi rendues nécessaires du fait que les nœuds situés aux niveaux les plus profonds peuvent être difficiles à percevoir depuis la racine. Ces fonctionnalités seront fournies par XVTM, la boîte à outils pour la conception d’interfaces zoomables décrite dans le chapitre 5.

Note : avant de retenir cette méthode d’agencement, nous avions envisagé une autre option consistant à

appliquer la politique de taille égale pour tous les nœuds de même profondeur aussi bien à la hauteur qu’à la largeur. Cette méthode s’est rapidement révélée inutilisable, du fait que la représentation a déjà une assez forte tendance à se développer horizontalement. Ainsi, pour certaines configurations de structures XML, cette alternative utilisait parfois des quantités importantes d’espace horizontal supplémentaire sans

Langage visuel pour la représentation de documents et de classes de documents 87

Type de nœud Élément Attribut #PCDATA Section CDATA

Représentation graphique

Name

Name

PCDATA CDATA

FIG. 4.3 : Représentation des types de nœud des arbres XML

nécessité du point de vue du contenu mais uniquement pour répondre à la contrainte d’égalité de largeur des éléments de même profondeur.

Dimensions perceptuelles

Nous avons vu dans le chapitre 3 l’importance du choix de dimensions perceptuelles adéquates pour représenter différents types de données en fonction de leur nature. Dans le cadre des documents XML, nous nous intéressons principalement à des structures arborescentes. La seule relation existant entre les nœuds d’un arbre XML est le lien père-fils, si l’on considère, comme c’est le cas dans DOM, que les attributs attachés à un élément ne font pas partie de la structure principale. Cette relation sera donc relativement facile à représenter puisqu’elle est unique. Il existe par contre différents types de nœuds : éléments, feuilles texte (section CDATA, #PCDATA), attributs, processing-instructions, auxquels il faut ajouter les constructions spécifiques aux DTD encodant la cardinalité des éléments, les séquences et les choix.

Pour représenter les différents types de nœuds et leurs caractéristiques, nous proposons l’utilisation des dimensions perceptuelles suivantes. Le type de nœud (élément, attribut, etc.), une information qualitative, est encodé par la forme géométrique de l’objet graphique associé au nœud. Des teintes différentes sont utilisées pour préciser4 ce type, en conservant la même forme. Comme nous l’avons vu dans la section précédente, les relations père-fils sont représentées par l’emboîtement des nœuds. La profondeur d’un nœud dans la structure (information quantitative) est alors représentée par sa hauteur. Le tableau de la figure 4.3 illustre les différentes constructions utilisées pour la représentation d’instances de documents XML, et la première treemap de la figure 4.4 donne un exemple d’instance de document XML.

Les DTD nécessitent des constructions abstraites additionnelles (séquence et choix) ainsi que l’ajout d’information sur la cardinalité des éléments (constructions ?, ∗ et +). Les séquences sont représentées par des rectangles bleu contenant les éléments de la séquence ordonnés de gauche à droite ; les choix par un alignement vertical de rectangles verts contenant les différentes options du choix. La cardinalité est encodée par le style du contour des nœuds (continu (solid) ou discontinu (dashed)) et par l’utilisation dans certains cas d’un rectangle additionnel. Ces deux styles peuvent être assignés indifféremment à tous les types de nœuds, y compris les séquences et les choix puisque les DTD autorisent la spécification

4Les feuilles de type texte peuvent être soit des sections CDATA soit des sections PCDATA, les DTD (et autres langages de schéma) peuvent aussi préciser le type du contenu des attributs (et des feuilles texte pour certains langages) ; il s’agit dans tous les cas d’une information qualitative.

1..n +

Constructions additionnelles pour les DTD

Représentation visuelle d’une instance de document XML mail

Représentation visuelle de la DTD pour les documents mail

1. <!ELEMENT mail (date,recipient,sender,subject,textbody)> 2. <!ELEMENT date (#PCDATA)>

3. <!ELEMENT recipient (#PCDATA)> 4. <!ELEMENT sender (#PCDATA)> 5. <!ELEMENT subject (#PCDATA)> 6. <!ELEMENT textbody (p)+>

7. <!ELEMENT p (#PCDATA | cite)*> 8. <!ELEMENT cite (#PCDATA)>

9. <!ATTLIST mail ref CDATA #REQUIRED>

DTD pour les documents mail

Langage de transformation visuel à base de règles 89 d’information de cardinalité au niveau de ces constructions. Le rectangle additionnel symbolise la possibilité d’avoir entre 0 et n occurences en plus de la première. Nous avions exploré dans un premier temps une autre alternative, utilisant la représentation proposée par Blackwell dans son langage visuel pour expressions régulières Perl [26] qui consistait à superposer avec un léger décalage trois icônes quasi-ment identiques comme suit : . Mais cette représentation avait l’inconvénient de donner l’impression que le flot d’éléments se développait suivant l’axe perpendiculaire au plan de l’écran. Nous avons donc opté pour la méthode précédente qui illustre mieux le fait que le flot se développe horizontalement. Le tableau de la figure 4.4 résume les différentes constructions spécifiques aux DTD, qui s’ajoutent à celles définies dans le tableau 4.3. Cette même figure donne un exemple d’instance de document mail et la DTD correspondante accompagnée de sa version textuelle.

Ce langage visuel sert de base au langage VXT pour la spécification des règles de transformation. Pour plus d’informations, le lecteur intéressé peut se référer à l’article [221] présenté en annexe B qui en propose une étude formelle. Cette étude servira par ailleurs de base partielle à la définition formelle de VXT, développée dans la section 4.4.

4.3 Langage de transformation visuel à base de règles