Download Introduction

VII.2. Interfaces Personne / logiciel
gestionnaires d'événements se synchronisent en accédant en lecture et en écriture à un ensemble
de données globales qui définissent l'état courant du dialogue.
On peut résumer cette différence fondamentale en disant que dans une application conventionnelle le
contrôle est fondé sur l'historique alors que dans une application dirigée par événement le contrôle
est fondé sur l'état [Cowan…90].
Le problème auquel est confronté le concepteur du dialogue est justement de modéliser cet état, qui
représente l'évolution du dialogue entre application et utilisateur ; il lui faut notamment pallier
l'absence de structure de contrôle explicite par un formalisme qui lui permette de valider sa
modélisation, et notamment de prouver l'absence de blocage (cas ou une commande ne peut plus
redevenir accessible), ou d'assurer une rétroaction (feedback) informative et permanente : a tout
instant, l'interface doit montrer quelles actions sont légales, et lesquelles sont provisoirement inhibées.
Les solutions éprouvées en matière de spécification du dialogue dans les applications conventionnelles
(Augmented Transition Networks [Parnas 69, Denert 77] ou grammaires [Olsen 83]) sont
malheureusement inadéquates dans le domaine des applications dirigées par événements : elles tendent
en effet à modéliser l'utilisateur comme un fichier séquentiel que l'on peut soumettre à une analyse
syntaxique, alors que les interfaces modernes souhaitent favoriser un comportement non séquentiel de
l'utilisateur, qui peut à volonté interrompre ou différer une tâche, et entretenir des dialogues
concurrents avec plusieurs parties de l'application.
2.3. Interprétation du formalisme
Nous nous proposons de donner quelques indications méthodologiques pour guider la conception du
dialogue d'une application interactive par les Objets Coopératifs. Dans la suite, nous traitons
uniquement de la conception du module Dialogue (en référence au modèle Seeheim) de l'application ;
bien entendu, le module Abstraction peut lui aussi être modélisé par Objets Coopératifs, si le domaine
d'application s'y prête (par exemple, si l'on modélisait l'interface-utilisateur d'un procédé concurrent).
Une interface sera conçue comme un système d'Objets Coopératifs, dont les objets primitifs publient
des services d'interface (cf §IV.1.2). Pour compléter sa conception, le modélisateur doit définir des
liens entre les widgets, éléments de la Présentation (boutons, menus, etc…) et ces services d'interface,
en spécifiant par l'intermédiaire de quels éléments un service d'interface est invoqué. Trois types de
relation existent entre widgets et services d'interface :
•
relation 1→1 : un widget est associé à un service d'interface et à un seul. C'est le cas, par
exemple, ou un service est déclenché par le clic de l'utilisateur sur un bouton, ou par la
sélection d'un élément de menu ;
•
relation n→1 : plusieurs widgets sont associés au même service. Un tel cas signifie que
plusieurs actions différentes de l'utilisateur provoquent la même évolution du dialogue.
L'exemple traité plus loin dans ce chapitre présente une relation de ce type ;
•
relation 1→0 : un widget n'est associé à aucun service d'interface. L'interaction de l'utilisateur
avec le widget n'a donc aucune influence sur l'avancement du dialogue. C'est la cas des
214