2.2 Les modèles d'interface de référence

La recherche en interaction homme-machine a consacré beaucoup d'énergie à développer des modèles génériques et abstraits de systèmes interactifs. L'objectif de ces modèles de référence est d'obtenir une meilleure compréhension des systèmes interactifs existants, mettre en place une base commune de communication sur le domaine, et guider le choix d'une architecture logicielle lors du développement de nouveaux systèmes interactifs.

Chaque modèle se propose d'identifier les éléments significatifs qui entrent dans la composition de la plupart des systèmes interactifs, ainsi que les relations qui les lient. Bien que les terminologies employées diffèrent sensiblement, on retrouve souvent d'un modèle à l'autre les mêmes principes de base.

Figure 2.1: Modèle primitif d'un système interactif.

Tous les modèles partent du principe qu'un système interactif comporte une partie ``interface'' et une partie ``application pure'' (figure 2.1). Cette dernière est souvent appelée noyau fonctionnel, et tout ce qui s'y réfère appartient au domaine. Le noyau fonctionnel est considéré comme préexistant, et les modèles de systèmes interactifs décrivent essentiellement la partie interface, ainsi que ses relations avec les objets du domaine.

La plupart des modèles identifient au moins trois types d'éléments dans la composition des interfaces, et distinguent un ``coté utilisateur'' et un ``côté noyau fonctionnel''. Il comprennent presque toujours des éléments en contact direct avec l'utilisateur (présentations), des éléments en contact direct avec le noyau fonctionnel ou qui en font partie (interfaces du noyau fonctionnel, abstractions, modèles), et des éléments articulatoires (contrôleurs, adaptateurs).

Malgré ces points communs, certains modèles procèdent d'approches très différentes, et on distingue communément deux grands groupes de modèles de référence. Les modèles linguistiques ou modèles à couches décrivent la structure globale d'une application interactive sous forme de couches logiques. Ces modèles sont également appelés modèles logiques, ou sont qualifiés d'abstraits. Les seconds types de modèles sont les modèles à agents ou à interacteurs, ou encore modèles orientés objet. Ces modèles s'inspirent du paradigme de programmation par objets, et proposent une décomposition modulaire de l'interface en un ensemble d'agents communicants.

Nous décrivons dans la suite ces deux groupes de modèles, ainsi que leurs principaux représentants.

2.2.1 Les modèles linguistiques

Les modèles de référence linguistiques se basent sur une approche linguistique de l'interaction, inspirée des architectures de compilateurs. L'approche linguistique identifie trois aspects dans l'interaction :

• Aspects lexicaux : ces aspects désignent tout ce qui peut être assimilé à un vocabulaire d'entrée (clic, glisser), ou de sortie (ensembles d'icônes).
• Aspects syntaxiques : ils peuvent désigner des grammaires d'entrée représentant les séquences d'actions valides, ou les aspects spatiaux et temporels de l'affichage.
• Aspects sémantiques : ils correspondent à la partie fonctionnelle de l'application, qui détermine en dernier lieu le sens d'une action et génère les erreurs.

À défaut de donner des indications précises sur la façon dont doit être structuré et implémenté un système interactif, les modèles linguistiques identifient les couches logiques qui doivent y apparaître.

Dans cette section, nous décrivons dans leurs grandes lignes et de façon chronologique les principaux modèles linguistiques, à savoir le modèle de Seeheim, le modèle Arch, ainsi que son métamodèle Slinky.

2.2.1.1 Seeheim

Figure 2.2: Le modèle de Seeheim.

Le premier modèle de référence largement accepté part d'une approche linguistique. Celui-ci est issu d'un groupe de travail sur les systèmes interactifs ayant eu lieu à Seeheim en 1985 [Pfaff, 1985]. Le modèle de Seeheim était principalement destiné au traitement lexical des entrées et sorties dans les interfaces textuelles. S'il est peu utile aujourd'hui pour décrire les systèmes interactifs hautement graphiques, il a servi de base à beaucoup d'autres modèles.

Le modèle de Seeheim[Pfaff, 1985] propose de diviser l'interface en trois couches logicielles selon une approche linguistique (figure 2.2):

• La présentation est la couche en contact direct avec les entrées et sorties. Elle interprète les actions de l'utilisateur (dispositifs physiques) et génère les sorties (affichage) au niveau lexical.
• Le contrôleur de dialogue gère le séquencement de l'interaction en entrée et en sortie. Il maintient un état lui permettant de gérer les modes d'interaction et les enchaînements d'écrans.
• L'interface du noyau fonctionnel est la couche adaptative entre le système interactif et le noyau fonctionnel. Elle convertit les entrées en appels du noyau fonctionnel et les données abstraites de l'application en des objets présentables à l'utilisateur.

Un autre élément a été ajouté au modèle de Seeheim pour prendre en compte le retour sémantique rapide : par exemple, lors d'une opération de glisser-déposer, il peut s'avérer utile de modifier instantanément l'apparence de l'icône-cible pour indiquer si l'opération est valide. Dans ce cas, la couche de présentation doit court-circuiter le contrôleur de dialogue pour accéder directement aux informations sémantiques du noyau fonctionnel.

2.2.1.2 Arch / Slinky

Figure 2.3: Le modèle Arch.

Le modèle Arch [UIMS, 1992] affine le modèle de Seeheim en s'inspirant davantage des boîtes à outils graphiques actuelles. Ce modèle incorpore la notion de plate-forme de développement, et décrit la nature des données qui transitent entre les différents composants.

Le modèle Arch identifie cinq composants dans les systèmes interactifs (figure 2.3) :

• Le composant d'interaction désigne l'ensemble des widgets (objets interactifs) d'une boîte à outils, ainsi que les communications avec les périphériques physiques. Il dépend d'une plate-forme donnée.
• Le composant de présentation joue le rôle de médiateur entre le composant d'interaction et le contrôleur de dialogue. Il maintient une représentation logique des widgets qui est indépendante de la plate-forme.
• Le contrôleur de dialogue joue le même rôle articulatoire que celui du modèle de Seeheim. Il est notamment responsable du séquencement des tâches et du maintien de la consistance entre les vues multiples.
• L'adaptateur du domaine est un composant médiateur entre le contrôleur de dialogue et le noyau fonctionnel. Il est responsable des tâches dépendantes du domaine qui ne font pas partie du noyau fonctionnel mais qui sont nécessaires à sa manipulation par l'utilisateur. Ces tâches comprennent la réorganisation des données du domaine dans des buts de manipulation interactive, ou la détection des erreurs sémantiques.
• Le noyau fonctionnel représente la partie non interactive de l'application.

Le composant d'interaction et le noyau fonctionnel constituent les deux pieds de l'arche. Les autres composants décrivent la partie de l'interface qui doit être implémentée pour faire le lien entre la partie purement fonctionnelle d'une application et les widgets et les événements de la boîte à outils.

Le modèle Arch introduit également trois types d'objets décrivant la nature des informations qui transitent entre les composants (figure 2.3) :

• Les objets du domaine contiennent des données provenant directement ou indirectement du noyau fonctionnel (par exemple, le résultat d'une requête dans une base de donnés).
• Les objets de présentation sont des objets d'interaction virtuels qui décrivent les événements produits par l'utilisateur et les données qui lui sont présentées, indépendamment des méthodes d'interaction et de visualisation.
• Les objets d'interaction sont des instances propres à une boîte à outils, et qui implémentent des techniques d'interaction et de visualisation spécifiques.

Figure 2.4: Le jouet Slinky ayant inspiré le modèle du même nom.

Dans la réalité, le poids relatif des composants Arch et la répartition de leurs fonctionnalités peut varier selon les types d'applications interactives et les choix et impératifs fixés par leurs développeurs. Un métamodèle baptisé Slinky [UIMS, 1992] a été conçu au-dessus du modèle Arch afin de suggérer l'existence de ces variantes du modèle Arch. Le métamodèle Slinky, inspiré du jouet de même nom (figure 2.4), met notamment en évidence les notions de choix et de compromis inhérents au développement des applications interactives.

2.2.2 Les modèles à agents

En décomposant les interfaces en objets de même nature, les modèles à agents sont proches des langages à programmation objets et des interfaces à manipulation directe modernes. Dans cette section, nous décrivons les princpaux modèles à agents, à savoir MVC, PAC et le modèle hybride PAC/Amodeus.

2.2.2.1 MVC

Figure 2.5: Le modèle MVC.

Le modèle MVC (Modèle, Vue, Contrôleur) [Schmucker, 1986,Krasner and Pope, 1988] a été introduit comme architecture de référence dans l'implémentation des interfaces utilisateur de l'environnement Smalltalk [Goldberg and Robson, 1981]. L'approche de MVC inspirera toute une lignée de modèles à base d'agents, dont les principales motivations sont la modifiabilité et la conception itérative, ainsi que la compatibilité avec les langages à objets.

MVC décompose les systèmes interactifs en une hiérarchie d'agents. Un agent MVC consiste en un modèle muni d'une ou plusieurs vues, et d'un ou plusieurs contrôleurs:

• Le modèle est le noyau fonctionnel de l'agent. Il peut représenter des données brutes (entier, chaîne de caractères) ou des objets ayant un comportement complexe. Le modèle notifie les vues qui lui sont associées à chaque fois que son état se trouve modifié par le noyau de l'application ou par ses contrôleurs.
• La vue maintient une représentation du modèle perceptible par l'utilisateur, qu'elle met à jour à chaque changement d'état du modèle. Elle est en général constituée d'objets graphiques. La figure 5 donne plusieurs exemples de vue pour un modèle simple.
• Le contrôleur reçoit et interprète les événements utilisateur, en les répercutant sur le modèle (modification de son état) ou sur la vue (retour instantané).

Figure 2.6: Plusieurs exemples de look & feels pour un modèle consistant en une valeur entière et son domaine.

Chacun des trois composants de la triade MVC est un objet à part entière. Au sens de la programmation orientée objet, une classe de Modèle peut être compatible avec plusieurs classes de Vues et de Contrôleurs. Les composants interactifs d'une boîte à outils (widgets) sont la plupart du temps livrés avec un ensemble de paires Contrôleur/Vue, appelées look & feels. Un entier comportant une valeur minimale et une valeur maximale peut être ainsi représenté par une jauge, un curseur, un champ de saisie, ou une barre de défilement (figure 2.6).

2.2.2.2 PAC

Figure 2.7: Le modèle PAC.

Par rapport à MVC, le modèle à agents PAC (Présentation, Abstraction, Contrôle) [Coutaz, 1987] ré-introduit la vue et le contrôleur dans un objet monolithique mais rend explicite la synchronisation du modèle et de la vue/contrôleur. Il propose en outre une méthode de description récursive qui étend le paradigme à agents avec la notion de couche d'abstraction.

Comme MVC, le modèle PAC décrit les systèmes interactifs comme une hiérarchie d'agents composés de trois modules. Mais ici, le rôle de ces modules diffère (figure 2.7) :

• La présentation définit le comportement en entrée et en sortie de l'agent, tel qu'il est perçu par l'utilisateur.
• L'abstraction encapsule la partie sémantique de l'agent.
• Le contrôle maintient la consistance entre la présentation et l'abstraction, et communique avec les autres agents.

Notons qu'ici le composant d'abstraction est l'équivalent du composant modèle de MVC, et que la présentation correspond à une fusion des composants vue et contrôleur. Le composant contrôle n'a pas d'existence explicite dans le modèle MVC.

Figure 2.8: Hiérarchie d'agents PAC.

Par une approche récursive, le modèle PAC peut être appliqué de manière consistante à plusieurs niveaux d'un système interactif. Une application interactive peut ainsi être décrite comme une hiérarchie d'agents disposés sur plusieurs couches d'abstractions (figure 2.8). Ce type de représentation unifie en quelque sorte les modèles à agents et les approches à couches de type Seeheim.

2.2.2.3 PAC/Amodeus

Figure: Le modèle PAC/Amodeus

PAC/Amodeus [Nigay and Coutaz, 1993] finit de réconcilier les approches linguistiques et à agents en proposant un modèle hybride. Il réutilise le modèle Arch et décrit son contrôleur de dialogue avec une hiérarchie d'agents PAC (figure 2.9). L'adaptateur de domaine et la présentation de l'Arch communiquent directement avec chaque agent PAC à travers son abstraction (pour le premier) et sa présentation (pour le second).

L'objectif de PAC/Amodeus est de combiner les avantages du modèle Arch, qui intègre des aspects de génie logiciel comme la modifiabilité et la portabilité, et du modèle PAC, qui permet de structurer efficacement le contrôleur de dialogue jusque-là monolithique. Le modèle PAC/Amodeus a été employé pour modéliser des plate-formes multimodales [Nigay and Coutaz, 1995]. Les entrées sont décrites par des symboles et des grammaires, et des mécanismes de fusion de haut-niveau sont implémentés dans le dialogue par des agents PAC.

2.2.3 Conclusion

Nous avons présenté dans cette section les principaux modèles d'interfaces de référence, dont l'objectif est de fournir des stratégies de décomposition fonctionnelle et structurelle pour les interfaces utilisateur afin de simplifier leur conception et constituer un support de raisonnement.

Les modèles linguistiques décomposent les interfaces en un petit nombre de couches, chaque couche possédant un rôle spécifique et traduisant un niveau d'abstraction. Cette approche est encore utile pour comprendre le fonctionnement de l'interaction, mais elle trop monolithique, abstraite et peu structurante. En outre, cette approche qui trouve son origine dans les interfaces textuelles est de plus en plus difficile à appliquer telle quelle aux interfaces modernes et encore plus aux interfaces Post-WIMP. C'est en particulier le cas de Seeheim. L'approche Arch est néanmoins plus pragmatique, car elle s'inspire des architectures concrètes des systèmes interactives, avec les notions de plate-forme et de boîte à outils.

Les modèles à agents décrivent un autre style de décomposition pour les interfaces utilisateur (dite aussi horizontale par opposition aux modèles à couches): ces agents modélisent le système de façon homogène. Cette approche est particulièrement adaptée aux styles de programmation par objets, et permet de décrire des aspects tels que la modularité, le parallélisme et la distribution. La nécessité, cependant, de prendre en compte l'hétérogénéité des systèmes interactifs a conduit au modèle PAC/Amodeus. PAC/Amodeus emprunte à Arch des principes de génie logiciel essentiels telles que la modifiabilité et la portabilité, incarnées par ses adaptateurs de domaine et son composant de présentation.

Malgré leurs apports, les modèles de référence ne sont pas d'une grande aide pour décrire les aspects bas-niveau de l'interaction, aussi bien du point de vue sorties qu'entrées, ces aspects étant systématiquement encapsulés dans des blocs monolithiques. Rien n'est dit non plus sur les techniques d'interaction. Arch et PAC/Amodeus, en particulier, ne décrivent pas la façon de répartir les techniques d'interaction entre le composant de Présentation, le composant d'Interaction, et leur protocole de communication.

MVC est le seul modèle à dissocier la gestion des entrées de celle des sorties dans chacun de ses agents, ce qui permet conceptuellement de décrire l'apparence ou le comportement en entrée d'un objet interactif de façon indépendante. Si cette séparation est très avantageuse du point de vue de la modifiabilité, elle est souvent difficile à mettre en uvre: dans la plupart des composants visuels, la façon dont les entrées sont interprétées est très liée à l'affichage. MVC ne décrivant pas de protocole de communication entre les deux composants, la plupart des boîtes à outils existantes préfèrent fusionner la vue et le contrôleur en une entité unique [Fowler, 1999].