Concevoir des applications graphiques interactives distribuées avec INDIGO

Depuis une vingtaine d’années, les interfaces graphiques se sont développées de façon considérable et touchent aujourd’hui un large public. Elles sont cependant restées confinées, pour l’essentiel, à une interaction de type “desktop”, où un utilisateur est assis à son bureau face à un ordinateur individuel. Cependant, de nombreuses évolutions remettent ce modèle en cause et montrent les limites des outils et modèles actuels pour le développement d’applications interactives graphiques. Tout d’abord, de nouvelles techniques d’interaction, parfois appelées postWIMP, ont été développées afin d’améliorer la performance et l’utilisabilité des applications. Cependant, ces techniques ne sont que trop rarement utilisées dans des produits commerciaux. La raison principale en est que les boîtes à outils et constructeurs d’interface actuels sont pour la plupart fondés sur la notion de widget. Le problème de cette approche est que les widgets sont très stéréotypés et limitent l’interaction aux formes les plus simples : menus, palettes, boîtes de dialogues, etc. Des techniques aussi courantes que le drag-and-drop (glisser-déposer) ne sont pas prises en compte et imposent de lourds développements ad hoc, pour chaque application. La situation est pire pour des techniques avancées telles que l’interaction bi-manuelle.

Par ailleurs, les plates-formes actuelles offrent des capacités d’interaction très diverses en termes de dispositifs d’entrée et d’affichage : de l’ordinateur portable au PDA et au téléphone portable, de l’ordinateur de bureau à la table interactive et au mur d’images ou au système immersif. Les différences de taille d’écran, l’usage de l’interaction au stylo, la prise en compte de modalités haptique ou sonore, les exigences nouvelles de l’interaction en situation de mobilité imposent que différentes versions d’une même application soient développées pour exploiter au mieux ces dispositifs et prendre en compte la diversité des usages. Enfin, cette évolution fait que les usages sont de moins en moins individuels et la nécessité de partager des documents et de collaborer à distance, y compris avec soi-même lorsque, par exemple, on veut accéder un même document de son bureau, d’un chantier et de chez soi, est de plus en plus impérieuse. Ainsi, il est souhaitable que les aspects collecticiels fassent partie intégrante des applications interactives, au même titre que le copier-coller. Face à ces trois défis que sont l’interaction post-WIMP, la diversité des platesformes et l’intégration du collecticiel, nous avons développé et validé une architecture logicielle appelée INDIGO (Interactive Distributed Graphical Object) (Blanch et al., 2005) fondée sur les principes suivants :
• Une architecture répartie formée de serveurs spécialisés dans la gestion d’objets de l’application d’une part, dans l’interaction et le rendu graphique d’autre part ;
• La transformation des objets de l’application en un graphe de scène dont le rendu est contrôlé en fonction de la plate-forme ;
• L’interprétation des actions de l’utilisateur en commandes de haut niveau sur les objets du domaine ;
• Le contrôle de la cohérence permettant à plusieurs serveurs d’interaction et de rendu de représenter les mêmes objets.

Cet article présente l’architecture INDIGO, ses composants et son fonctionnement, puis illustre son utilisation avec quelques exemples qui nous ont permis de la valider, enfin compare INDIGO à l’état de l’art. Nous concluons avec quelques directions pour la suite de ces travaux.

Architecture

Les travaux en architecture logicielle des interfaces ont depuis longtemps insisté sur la nécessité de séparer l’interface de l’application de son noyau fonctionnel (gestion des objets du domaine). L’architecture répartie d’INDIGO1 (Figure 1) distingue deux types de serveurs : les serveurs d’objets (SERVO) et les serveurs d’interaction et de rendu (SERVIR). Le SERVO réalise le noyau fonctionnel de l’application, en utilisant un vocabulaire propre aux objets manipulés et à leur domaine d’utilisation. Il expose ces données à un ou plusieurs SERVIR. Ceux-ci, en fonction des capacités de leur plate-forme d’exécution, mettent en œuvre les représentations et les techniques d’interactions qui permettent aux utilisateurs d’interagir avec les objets du SERVO. Ce dernier maintient la cohérence de ses données (il peut refuser des modifications demandées par un SERVIR), et notifie l’ensemble des SERVIR qui utilisent ses données des modifications de leur état.

Dans le modèle architectural de référence ARCH (Arch, 1992), l’architecture INDIGO consiste à localiser les composants du domaine (une des branches de l’arche) dans le SERVO, et les composants de présentation et d’interaction (l’autre branche) dans le SERVIR. Le contrôleur de dialogue (la clé de voûte de l’arche), quant à lui, est réparti entre SERVO et SERVIR : le contrôle du dialogue de bas niveau est localisé dans le SERVIR tandis que le contrôle de dialogue de haut niveau est localisé dans le SERVO. Le contrôle de bas niveau est celui qui est mis en œuvre au niveau des interactions élémentaires, comme par exemple une commande d’un menu qui fait apparaître une boîte de dialogue ou la navigation dans un ensemble d’objets par défilement ou de façon hiérarchique. Le contrôle de haut niveau concerne plutôt la logique globale du dialogue, comme la disponibilité de certaines commandes en fonction du mode. La distinction entre ces deux niveaux de dialogue n’est pas stricte, ce qui laisse une certaine liberté au concepteur pour décider de la localisation exacte du contrôleur de dialogue. Ce choix de répartition architecturale repose sur la constatation que de nombreux processus applicatifs présentent une façade abstraite, en grande partie indépendante de l’interface utilisateur concrète. Cette façade peut s’assimiler au modèle conceptuel de l’application, c’est-à-dire la collection des objets et opérations ayant un sens pour l’utilisateur. Dans INDIGO, le modèle conceptuel est un graphe d’objets comprenant des attributs et des opérations possibles sur ces objets, dénommé le graphe d’objets conceptuels (COG pour Conceptual Object Graph) et représenté par un arbre XML. Chaque SERVO gère un graphe d’objets conceptuels et maintient sa cohérence en réponse aux demandes de mise à jour qu’il reçoit. Pour être manipulable par l’utilisateur, ce modèle conceptuel doit être transformé en une forme perceptible appelée graphe d’objets perceptuels (POG pour Perceptual Object Graph). Pour une représentation graphique, ce graphe utilise par exemple SVG (Scalable Vector Graphics), le standard de graphique vectoriel du Web (W3C, 2003). L’architecture n’est cependant pas restreinte aux représentations graphiques, et peut intégrer d’autres graphes encodant des percepts, comme des dispositifs tactiles ou sonores.

La transformation d’un COG en POG est appelée concrétisation. Elle est contrôlée par une ou plusieurs feuilles de style. Les feuilles de style dites primaires sont stockées dans le SERVO, qui doit choisir la feuille la plus adaptée à la plate-forme et au contexte de l’interaction ; elles peuvent être complétées par des feuilles de styles secondaires stockées dans le SERVIR. Ces feuilles sont propres à la plateforme ou à l’utilisateur et permettant une adaptation de la présentation à leurs besoins propres. La concrétisation a lieu dans le SERVIR : celui-ci gère une copie du COG appelée SCOG (Synchronized COG) et applique la transformation localement afin d’obtenir le POG. Cela permet de réduire le trafic entre SERVO et SERVIR en échangeant uniquement des informations de haut niveau, mais aussi de gérer au sein du SERVIR un unique POG contenant les concrétisations des COGs de plusieurs SERVO gérant des objets de natures différentes. Ainsi, un SERVIR peut donner accès à des objets de différents SERVO, de même que les objets d’un même SERVO peuvent être présentés (de façons différentes) par différents SERVIR. Cette dernière situation permet de mettre en œuvre des applications collecticielles, le SERVO gérant le partage d’objets et notifiant chaque SERVIR client lorsqu’un objet est modifié. Si l’on utilise un seul SERVO, l’architecture est centralisée, avec les problèmes qu’on lui connaît. Rien n’empêche cependant le SERVO de se répliquer à chaque nouvelle connexion d’un SERVIR, mais nous n’avons pas encore testé cette approche.

Conception d’applications avec INDIGO

Concevoir une application avec INDIGO consiste à définir le modèle conceptuel des objets de cette application et ses feuilles de style primaires pour les plates-formes (et donc les SERVIR) visés. Le reste de cette section détaille ces deux étapes.

Définir le modèle conceptuel 

Le modèle conceptuel d’une application INDIGO est un ensemble de classes d’objets et de méthodes qui définissent les objets et les commandes qui seront offertes à l’utilisateur à travers l’interface. Par exemple, pour l’interface d’un système de fichiers, les objets sont les fichiers et les répertoires, les méthodes sont la création, le changement de nom, le changement de répertoire, la copie et la destruction. Les objets conceptuels pourront être désignés par l’utilisateur, par exemple par manipulation directe dans une interface graphique, ou par reconnaissance vocale si l’on utilise une interface de ce type. Les méthodes du modèle conceptuel seront déclenchées par des commandes de l’interface, telles que la sélection dans des menus ou des palettes ou la reconnaissance de gestes. Aussi, même si le modèle conceptuel se veut indépendant du type d’interface qui sera mis en œuvre, il ne peut être correctement défini que si l’on a une idée du ou des interfaces concrètes qui l’utiliseront. L’objectif est que les objets du modèle conceptuel coïncident avec les objets du modèle mental de l’utilisateur. L’identification de ces objets nécessite donc des méthodes de conception centrées sur l’utilisateur, classiques en IHM. Une situation fréquente lors de la conception d’une application interactive est celle où un noyau fonctionnel existe déjà, par exemple le système de fichiers d’un système d’exploitation ou une base de données. Dans ce cas, le SERVO se comporte comme un adaptateur du domaine dans le modèle Arch, en fournissant une façade aux objets du noyau fonctionnel préexistant. Les objets de l’application et les objets conceptuels de la Figure 1 peuvent alors ne pas être localisés dans le même processus, voire s’exécuter sur des machines différentes. Cette situation possède un avantage, à savoir la possibilité de créer plusieurs modèles conceptuels, chacun implémenté par un SERVO différent, pour interagir avec les mêmes données. Cela peut s’avérer utile si l’on envisage des interfaces tellement différentes qu’elles ne peuvent utiliser le même modèle conceptuel.

Table des matières

I)INTRODUCTION
II) GENERALITES
III) METHODOLOGIE
IV) RESULTATS
V) COMMENTAIRES ET DISCUSSION
VI) CONCLUSION  
VII) REFERENCES
ANNEXES
RESUME

Lire le rapport complet