9.2 MAGGLITE et les modèles

Dans cette section, nous positionnons notre boîte à outils et son modèle concret par rapport aux modèles sur lesquels elle repose (le modèle d'interface MVC et le modèle d'interaction de l'Interaction Instrumentale) et qu'elle permet de réaliser (Modèle multi-couches).

9.2.1 MVC

Le modèle MVC (Modèle, Vue, Contrôleur) [Krasner et Pope1988] est un modèle à agents interactifs devenu référence dans l'implémentation des applications interactives, par soucis d'adaptabilité et d'adéquation au langage à objets. Les applications interactives sont décomposées en agents MVC, chacun présentant:

1. un modèle, partie de son noyau fonctionnel pouvant être une donnée ou des objets plus complexes;
2. une ou plusieurs vues, les représentations perceptibles du modèle par l'utilisateur qui sont modifiées selon les changements d'état du modèle;
3. un ou plusieurs contrôleurs, qui reçoivent et traitent les actions de l'utilisateur, les propageant sur le modèle ou sur la vue.

MVC dissocie la gestion des entrées et des sorties dans ses agents, promettant une certaine indépendance entre l'aspect et le comportement des objets graphiques (le modèle PAC - Présentation, Abstraction, Contrôleur - [Coutaz1987] généralise MVC, et regroupe entrées et sorties dans le module de présentation). Toutefois, sa mise en œuvre s'est révélée complexe et une grande majorité des boîtes à outils actuelles fusionnent la vue et le contrôleur dans leurs implémentations. Elles assurent ainsi la flexibilité au niveau modèle, mais gardent une approche monolithique du point de vue de l'interaction (en entrée et en sortie).

Dans la perspective de ce modèle, les configurations d'entrée d'ICON représentent le contrôleur, laissant la gestion de la vue et du modèle aux applications. Le modèle des graphes combinés place la Vue au niveau des objets graphiques du graphe de scène. Le modèle est alors décrit dans l'application. Ce sont les Points d'accès à l'Interaction qui vont permettre d'établir la connexion entre les différents composants de MVC. Cette séparation franche des différents composants de MVC et leur connectivité dynamique est un apport important de notre modèle. Elle offre plus de flexibilité pour le développement d'interfaces et la description d'interactions mais aussi pour l'extensibilité de la boîte à outils que les autres approches basées sur MVC.

9.2.2 IAPs et l'interaction instrumentale

Le modèle de l'interaction instrumentale est un modèle d'interaction, «un ensemble de principes de règles et de propriétés qui guident la conception d'une interface» du point de vue de l'utilisateur [Beaudouin-Lafon1997,Beaudouin-Lafon2000]. Il étend et généralise le modèle de la manipulation directe [Shneiderman1983] en s'inspirant de notre façon d'interagir avec les objets du monde réel par l'intermédiaire d'outils. Par exemple, le crayon de l'architecte est un instrument qui va lui permettre d'agir sur un objet d'intérêt, son dessin.

Le modèle de l'interaction instrumentale définit, entre autres principes, les propriétés des instruments de l'interface qui vont permettre d'agir et d'interagir sur les objets du domaine, les entités du programme informatique. En particulier, il introduit la notion de réification, processus qui consiste à transformer un concept en objet (une barre de défilement, par exemple, réifie le concept de défilement d'un document).

Figure 9.1: IAPs et l'interaction instrumentale. Les IAPs définissent la partie logique des instruments, pouvant être connectée à la partie physique dans une configuration d'entrée, par l'intermédiaire d'adaptateurs. Les objets du domaine sont définis par l'application au niveau du graphe de scène.

Les points d'accès aux interactions, et la philosophie de MAGGLITE en général, correspondent bien à ce modèle. Les IAPs s'intègrent dans la description d'instruments d'interaction par leur association avec des périphériques d'entrée. Ils définissent, avec certaines parties du graphe de scène (retour graphique ou vue de l'instrument), la composante logique des instruments. La figure 9.1 illustre ce propos en mettant en correspondance le modèle des graphes combinés et l'interaction instrumentale.

Les IAPs suivent le principe de réification: ils réifient les commandes qui contrôlent soit l'objet qu'ils représentent (pour les manipulateurs), soit la classe d'objets avec lesquels ils sont compatibles (pour les dispositifs d'interaction et les outils internes). La technique des Responsive Handles que nous avons présentée dans la section 8.3.2, est un exemple d'instrument logique permettant d'interagir avec des objets graphiques. Une fois connecté à un dispositif d'entrée (souris, joystick, magellan, etc.), le dispositif d'interaction et les nœuds du graphes de scène(poignées) composent un instrument qui réifie les concepts de déplacement, redimensionnement et rotation d'objets graphiques. De plus il est polymorphe [Beaudouin-Lafon2000], car il peut être utilisé avec tous les objets pour lesquels il a du sens (les objets déplaçables), mais aussi parce qu'il peut être adapté à d'autres contextes en utilisant diverses méthodes d'entrée (périphériques, reconnaissance vocale, etc.).
Les manipulateurs permettent en plus la manipulation directe des objets avec un instrument physique (périphériques d'entrée), poussant alors l'interaction instrumentale jusqu'à sa limite: l'interaction est on ne peut plus directe, physique, et le contrôle est alors plus explicite.

Notre modèle d'implémentation permet donc de séparer explicitement les instruments physiques (périphériques d'entrée) des instruments logiques (dispositifs d'interaction, outils internes et manipulateurs) et permet leur association dynamique pour créer des instruments. Les objets du domaine sont décrits au niveau de l'application et représentés dans le graphe de scène. Ce niveau de granularité très fine est un atout pour respecter les principes de conception qui découlent de l'interaction instrumentale (réification, polymorphisme et réutilisabilité), facilitant ainsi le prototypage d'instruments basés sur un grand nombre de techniques d'interaction ainsi que leur intégration dans une même application.

9.2.3 Le modèle multi-couches

Dans [Fekete et Beaudouin-Lafon1996,Fekete1996], Jean-Daniel FEKETE a proposé une architecture d'implémentation en couches pour, entre autre, séparer la spécification de l'interaction et du graphique dans les applications interactives: le Modèle multi-couches. Comme représenté sur la figure 9.2, cette approche permet une décomposition sémantique des fonctionnalités de l'application graphique en spécialisant les interactions et/ou les visualisations pour chaque couche.

Figure 9.2: Le modèle multi-couches décompose une application en couches graphiques interactives. MAGGLITE permet de réaliser ce modèle, en offrant une approche encore plus flexible de l'interaction (une approche horizontale - flèches de gauche - par rapport à l'approche verticale du modèle).

Chaque couche contient des outils qui lui sont propre et qui vont gérer l'interaction. Les événements d'interaction traversent les couches de la plus proche de l'utilisateur à la plus éloignée (de haut en bas) et sont interceptés et bloqués par les outils capables de les traiter (voir figure 9.2). Cette organisation sépare les outils et objets graphiques de nature différente dans des couches séparées. Cela permet une description claire de l'interaction, mais aussi de facilement adapter la visualisation aux actions (masquage ou transformation d'une couche, par exemple).

MAGGLITE ne repose pas exclusivement sur ce modèle multi-couches, mais permet de le réaliser efficacement et d'en tirer partie pour deux objectifs: réaliser des applications pour lesquelles ce modèle est adapté (des éditeurs comme TicTacToon [Fekete et al.1995] où notre application SVALABARD) ou étendre les capacités graphiques et interactives de composants.

9.2.3.1 La réalisation d'applications

Nous proposons d'utiliser ce même paradigme des couches pour le développement d'applications graphiques appropriées avec MAGGLITE. SVALABARD en est un exemple, avec le paradigme des feuilles d'interaction. Notre approche permet la même gestion verticale de l'interaction (par traversée des couches), mais autorise aussi une approche horizontale, par connexion directe de dispositifs ou d'interactions aux outils et propriétés de la couche (voir figure 9.2). Ainsi, la réalisation de cette architecture est encore plus simple et flexible, permettant même la redéfinition interactive du comportement des couches et de leurs outils.

9.2.3.2 L'extension des composants

Mais au delà de la construction d'applications, ce principe de couches est aussi l'un des fondements de l'extension des composants de la boîte à outils. Comme nous l'avons montré avec l'exemple des calques de dessin, les capacités graphiques et interactives des composants de la boîte à outils peuvent être augmentées par l'ajout dynamique de calques (ou couches) et de leurs outils associés. Cette approche évite de devoir développer plusieurs classes pour ajouter une même propriété à différents types d'objets, tout en favorisant leur composition dans un but exploratoire.