Introduction au formalisme des machines a états hiérarchiques

Télécharger le fichier pdf d’un mémoire de fin d’études

Des modeles pour l’interaction homme-machine

Les modeles` proposes´ par la litterature´ concernant l’interaction homme-machine sont de diverses natures. Certains mettent l’accent sur le systeme` interactif lui-memeˆ et proposent pour celui-ci des modeles` d’architecture a` des niveaux d’abstraction variable. D’autres s’interessent´ a` l’interaction elle-memeˆ et proposent de formaliser la notion d’echange´ ou de dialogue entre le systeme` et ses utilisateurs. Enfin, certains s’interessent´ a` la modelisation´ de la performance de l’utilisateur pour offrir des moyens objectifs et quantitatifs d’evaluer´ une technique d’interaction ou un systeme`. Nous abordons ici ces trois aspects successivement. Pour une vue plus large sur les modeles` pour l’interaction, on pourra se reporter au panorama dresse´ par Carrol [2003].

Modeles d’architecture

Les differents´ modeles` proposes´ pour modeliser´ les systemes` interactifs considerent` gen´eralement´ qu’une application interactive comporte un noyau fonctionnel, souvent preexistant,´ qui ne releve` pas forcement´ du modele` lui-memeˆ. Ce noyau fonctionnel realise´ toutes les fonctions liees´ au domaine de l’application, sur des objets abstraits, independants´ de la representation´ qui en est fournie aux utilisateurs. L’interface est ainsi definie´ comme la partie de l’application qui etablit,´ au travers de divers mecanismes,´ une correspon-dance entre le vocabulaire de l’utilisateur et celui du noyau fonctionnel. C’est l’architecture de cette interface qui est l’objet des modeles` present´es´ ici.

Modeles de l’interaction

Les modeles` de l’interaction s’interessent´ a` l’interaction du point de vue de l’utilisateur. S’ils ne proposent pas directement de techniques d’interaction, ils donnent par contre des principes a` suivre lors de leur conception. Ils re-groupent ainsi les techniques d’interaction au sein de grandes familles.

Les interfaces conversationnelles

L’un des premiers modeles` d’interaction utilise´ fut celui de l’interaction conversationnelle. C’est ce modele` qui est utilise´ par les langages de com-mandes : l’utilisateur specifie´ a` l’invite du systeme` une commande ainsi que ses arguments. Il rec¸oit en reponse´ le resultat´ de cette commande ou, si le resultat´ est uniquement en un effet de bord modifiant l’etat´ du systeme,` un retour le renseignant sur l’accomplissement de la commande. Ce retour n’est d’ailleurs pas toujours fourni, auquel cas seule l’experience´ de l’utilisateur ou une l’utilisation d’une commande explicite permettra de connaˆıtre le resultat´ de l’action.
Ce type d’application est maintenant reserv´e´ a` des domaines specifiques,´ en gen´eral´ proches du systeme` informatique lui-memeˆ. Il structure par ailleurs l’application assez directement autour d’une boucle qui effectue la lec-ture ligne a` ligne d’une commande dans une console, l’evalue,´ et affiche son resultat´. C’est sans doute le systeme` interactif le plus primitif tant l’interface (une simple invite) est peu suggestive et requiert de l’utilisateur une connais-sance prealable´ du vocabulaire et de la syntaxe compris par le programme.
Pour reduire´ cet effort de memorisation,´ il est possible de placer les com-mandes dans des menus. Une autre alternative, pour effectuer des tachesˆ par-ticulieres,` et de donner l’initiative a` la machine qui demande alors simplement la saisie de parametres` graceˆ a` une succession de formulaires. Ces styles d’in-teraction peuvent etreˆ entremelˆes´ et cohabitent souvent dans les applications.

La manipulation directe

La manipulation directe de Shneiderman [1983, 1998], partant de l’obser-vation des systemes` interactifs de l’epoque,´ et notamment des tableurs qui viennent d’apparaˆıtre, et des jeux repandus´ sur les bornes d’arcade, propose quelques principes pour les interfaces graphiques. Ces principes doivent gui-der la realisation´ des interfaces et se declinent´ ainsi :
– les objets de l’application doivent posseder´ une repr´esentation graphique persistante (par exemple un fichier sera represent´e´ par un icone dans un explorateur de fichiers) ;
– les actions sur ces objets doivent se realiser´ par des actions physiques et non par l’invocation de commandes d’un langage (par exemple, la sup-pression d’un fichier se fera en le deplac´¸ant dans une poubelle, cette derniere` incarnant la commande de suppression) ;
– Les actions doivent etreˆ incr´ementales (donc rapides) et r´eversibles (on peut “sortir” un fichier de la poubelle).
Ces principes facilitent l’apprentissage en reduisant´ les risques et en encou-rageant ainsi la decouverte´ par l’exploration de l’interface.

Techniques d’interaction

Les techniques d’interaction utilisees´ par les applications et par l’en-vironnement des ordinateurs personnels n’ont pratiquement pas evolu´e´ depuis l’apparition de la metaphore´ du bureau et sa popularisation [Beaudouin-Lafon, 2004]. Pourtant, les techniques facilitant l’interaction foi-sonnent dans la litterature´ de l’interaction homme-machine. Il est parti-culierement` frappant de noter comme la plupart des techniques d’interac-tion recentes´ — certaines, comme les menus circulaires [Callahan et al., 1988, Hopkins, 1991] ont tout de memeˆ plus de quinze ans — ne sont pas adoptees´ dans les logiciels d’utilisation courante, alors que leurs apports ont souvent et´e´ demontr´es´ par des analyses et des experimentations´ controlˆees´. L’infor-matique grand public ayant pourtant comme principal moteur commercial l’ajout de fonctionnalites´ “visibles”, il s’agit la` d’un paradoxe, ou du moins d’un symptomeˆ du fait que de telles interactions sont difficiles a` mettre en œuvre dans un systeme` existant.
Pour pretendre´ offrir des outils permettant de realiser´ facilement des techniques d’interaction, ainsi que d’en concevoir de nouvelles, il nous faut etudier´ les techniques existantes et degager´ les aspects necessaires´ a` leur realisation´. En explorant la diversite´ de ces techniques d’inter-action avancees,´ memeˆ si nous nous limitons ici a` celles qui ont leur place sur le bureau d’aujourd’hui1, nous pouvons remarquer une tendance gen´erale´. Alors que l’interacteur classique est caracteristique´ d’une interac-tion completement` sequenc´ee,´ les techniques recentes´ tendent vers une in-teraction de plus en plus continue, qui a et´e´ qualifiee´ de “fluide” (voir par exemple [Guimbretiere` et al., 2001, Ramos et Balakrishnan, 2003]). Nous presentons´ quelques exemples illustrant cette marche vers la fluidite´ de l’in-teraction.

Facilitation du pointage

Le modele` de Fitts a permis de prendre conscience de l’importance de la dis-position des cibles par rapport au curseur pour la facilite´ avec laquelle elles peuvent etreˆ atteintes. Ce resultat´ de psychologie experimentale´ a une in-fluence directe sur bon nombre de techniques qui cherchent a` reduire´ le temps de pointage necessaire´ a` la realisation´ de certaines tachesˆ (Balakrishnan [2004] en a repertori´e´ un vaste echantillon)´. Nous presentons´ quelques-unes des plus significatives ici.

Syst`emes et boˆıtes a` outils avanc´es

L’inter´etˆ des techniques d’interaction present´ees´ ci-dessus a souvent et´e´ demontr´e,´ memeˆ si c’est parfois sur des exemples d’utilisation parti-culierement` bien choisis pour mettre en valeur les avantages de chacune des techniques, comme le montre Appert et al. [2004]. Quelques systemes` ont ce-pendant et´e´ realis´es´ qui integrent´ plusieurs techniques d’interaction avancees,´ permettant ainsi de mieux se rendre compte de l’impact que peut avoir la conception complete` d’une interface sans a priori WIMP sur l’utilisabilite´ d’une application.
Par ailleurs, l’experience´ acquise lors de la realisation´ de ces systemes` a permis de jeter les bases de la realisation´ de boˆıtes a` outils qui auraient permis, si elles avaient existe,´ de realiser´ ces systemes`. Nous presentons´ ici quelques-uns de ces systemes,` puis un ensemble de boˆıtes a` outils qui ont et´e´ proposees´ pour faciliter divers aspects du developpement´ d’applications interactives post-WIMP.

Syst`emes pr´ecurseurs

La mise au point d’outils pour le developpement´ d’applications interac-tives necessite´ de cerner les besoins de celles-ci. C’est ainsi que souvent des systemes` mettant en œuvre des interactions complexes ont et´e´ developp´es´ sans le support direct d’une boˆıte a` outils, celles-ci faisant soit completement` defaut´ a` l’epoque,´ ou ne presentant´ pas les qualites´ requises pour realiser´ cer-taines techniques d’interaction.

Syst`emes historiques

Certains systemes` ont marque´ l’histoire de l’interaction homme-machine par leur qualite´ visionnaire et les perspectives de recherche qu’ils ont ouvert. Les premiers ont vu le jour dans les annees´ soixante, alors que l’interaction homme-machine se resumait´ a` la perforation de cartes et a` l’attente de la sortie des imprimantes.
Sketchpad. Fruit du travail de these` de Ivan Sutherland le systeme` Sketch-pad date de 1963. Sa these` a et´e´ re´edit´ee´ en 2003 par l’universite´ de Cambridge [Sutherland, 2003]. Sketchpad propose en particulier un systeme` d’edition´ de schemas´ vectoriels utilisant la manipulation directe a` l’aide d’un crayon optique et un systeme` de resolution´ de contraintes pour realiser´ diverses operations´ de placement geom´etrique´. La Figure 2.24 montre a` gauche Ivan Sutherland utilisant Sketchpad et a` droite un exemple de schema´ utilisant le systeme` de contraintes pour modeliser´ la resistance´ mecanique´ d’un objet). Sketchpad est sous doute le premier systeme` interactif graphique, et il utilise dej´a` la manipulation directe.
NLS/Augment. Autre systeme` marquant, NLS/Augment a et´e´ developp´e´ lui aussi dans les annees´ soixante sous l’impulsion de Douglas Engelbart. Ce systeme` a et´e´ le premier a` utiliser certains objets ou concepts qui nous sont familiers de nos jours. Nous pouvons noter parmi ceux-ci la souris, une ar-chitecture client/serveur distribuee,´ ou encore la gestion de versions de do-cuments [Engelbart, 1998]. Ce systeme` a et´e´ conc¸u pour le travail collaboratif, y compris distant, avec l’integration´ d’un lien video´ entre les sites, la possi-bilite´ d’annoter les documents, la presence´ du courrier electronique´. Un tel environnement reste pratiquement inegal´e´ de nos jours bart presentant´ l’ensemble des fonctionnalite´ de NLS/Augment . A gauche, on note l’integration´ d’un flux video´ dans l’espace travail permettant de com-muniquer avec un collaborateur distant. On peut aussi discerner sur cette image la presence´ d’un tel´epointeur´ montrant l’activite´ de ce collaborateur.
A droite, la Figure 2.25 montre les periph´eriques´ d’interaction du systeme`. Outre le clavier, on note la presence´ d’une souris comportant trois boutons a` la main droite, et a` la main gauche un ensemble de 5 touches pour composer des accords permettant la selection´ d’outils et de fonctions.
Xerox “Star”. Au debut´ des annees´ quatre-vingts, un autre systeme` al-lait marquer l’histoire : le Xerox “Star” (Johnson et al. [1989] proposent une retrospective´ de ce systeme)`. Ce systeme,` lui aussi fonctionnant en reseau´ et disposant d’une souris, offre une interface utilisateur graphique proposant en particulier un systeme` de fenetrage,ˆ et le WYSIWYG (what you see is what you get ou “vous obtiendrez ce que vous voyez”3). L’interface du Xerox “Star” re-pose sur la metaphore´ du bureau (Figure 2.26), et propose des icones pour representer´ les objets d’inter´etˆ — documents, boˆıtes de courrier, imprimantes— sur celui-ci. L’interaction est centree´ sur les documents, permettant de com-poser a` partir d’images, de formules, de tableaux et de texte des documents qui apparaissent a` l’ecran´ tels qu’ils seront imprimes´.
Du point de vue de l’interaction, le Star propose un ensemble de com-mandes gen´eriques´ qui peuvent s’appliquer a` divers objets, accessibles graceˆ a` des touches dedi´ees´ situees´ sur la gauche du clavier. L’interaction, utilisant la souris, le clavier et ces touches de fonctions, repose sur la manipulation di-recte et bimanuelle : les touches de fonctions modifient en effet les actions de la souris.

Composant composite

La notion de composant permet de structurer la logique des applications en offrant un support a` leur decomposition´ en unites´ formant des ensembles coherents´ du point de vue fonctionnel. Cependant, comme l’illustre la plu-part des methodes´ d’analyse et de conception, cette decomposition´ est sou-vent recursive,´ ce qui permet de descendre dans les details´ sans etreˆ submerge´ par la complexite´ de l’ensemble du systeme`. Pour permettre une structuration des composants plus forte que celle introduite par les relations d’abonnement aux ev´enements,´ les composants peuvent etreˆ regroupes´ au sein d’un compo-sant de plus haut niveau : le composant composite.
Cette structure est recursive´ et permet ainsi de creer´ des arbres de compo-sants de profondeur arbitraire. Au sein de cette structure, chaque composant nœud est abonne´ automatiquement a` l’ensemble de ses fils. La boˆıte a` ou-tils HsmTk met par exemple a` disposition du programmeur, comme nous le detaillons´ a` la Section 3.2.1, une representation´ structuree´ de la souris : elle peut etreˆ vue comme l’assemblage d’une position, d’un ensemble de boutons, et de la valeur de la molette si celle-ci est presente´. Si seule la position de la souris est interessante´ pour le programmeur, il peut ne considerer´ que ce sous-ensemble du composant representant´ la souris. Plus finement, si seul le deplacement´ le long de l’axe droite/gauche est pertinent pour la technique d’interaction qu’il realise,´ il peut ne s’interesser´ qu’a` cette sous-partie de la position et ne recevoir ainsi que les notifications concernant le deplacement´ choisi.

Valeurs actives

Au niveau d’abstraction le plus simple, la boˆıte a` outils offre des valeurs ac- tives (des grandeurs numeriques´ ou de simples booleens)´ qui notifient les composants abonnes´ lorsqu’elles changent de valeur. Il est possible de fixer une resolution´ aux valeurs numeriques,´ ce qui permet de ne recevoir de notifications que si la modification depasse´ un certain seuil en valeur absolue. Ainsi, pour des periph´eriques´ dont le signal est bruite,´ la quantite´ d’ev´enements´ produits est reduite´ en fixant un seuil superieur´ au niveau du bruit. Cela est particulierement` utile pour les periph´eriques´ lies´ aux tablettes graphiques dont la resolution´ est tres` superieure´ a` celle de l’ecran´. C’est le pro-grammeur qui choisit alors un niveau de compromis : en rester a` la resolution´ de l’ecran´ et reduire´ la quantite´ d’ev´enements´ a` transmettre et a` traiter, ou gar-der la resolution´ maximale de la tablette si elle est necessaire´ a` son application particuliere`.
Par composition, ces valeurs actives sont regroupees,´ offrant ainsi la no-tion d’enregistrement ou de “record”. Par exemple, on dispose ainsi de points (grandeurs a` plusieurs dimensions) et de “boˆıtes a` boutons” (qui permettent de regrouper les boutons de la souris ou l’ensemble des touches d’un clavier). Le principal inter´etˆ de ces compositions, outre qu’elles permettent de structu-rer logiquement les composants, reside´ en ce qu’elles permettent de controlerˆ la granularite´ des notifications. Ainsi, alors qu’a` chaque deplacement´ de la souris ou presque, ses deux coordonnees´ sont modifiees,´ une seule notification sera envoyee´ aux composants abonnes´ au niveau de la position de la souris.

Machines a` etats´ hi´erarchiques

Les machines a` etats´ hierarchiques,´ a` la description detaill´ee´ desquelles le Chapitre 4 est consacre,´ sont mises en œuvre par composition de composants el´ementaires´ specialis´es,´ et s’appuient sur les mecanismes´ de ces composants el´ementaires´ : notification et composition hierarchique´.
La notification est utilisee´ par les machines a` etats´ hierarchiques´ pour com-muniquer avec l’exterieur,´ tant pour recevoir les modifications de ses entrees´ que pour notifier ses changements d’etats´. Les machines a` etats´ hierarchiques´ peuvent ainsi etreˆ utilisees´ pour realiser´ des fonctions de traitement et de fil-trage sur les ev´enements´ provenant de leurs entrees´. La composition des com-posants est, elle, naturellement utilisee´ pour structurer les machines a` etats´ de maniere` hierarchique´ et realiser´ leur structure d’arbre.

Peripheriques et interaction

Pour echafauder´ une application interactive, les abstractions el´ementaires´ present´ees´ ci-dessus ne suffisent pas. Par sa nature meme,ˆ une application interactive repond´ aux entrees´ de l’utilisateur, les interprete` pour effectuer des actions, et fournit a` l’utilisateur un retour refletant´ l’etat´ interne de l’ap-plication et son evolution´. Comme nous l’avons vu a` la Section 2.2, les tech-niques d’interaction post-WIMP sont parfois adaptees´ a` des configurations particulieres` de dispositifs d’entree´ et necessitent´ donc une representation´ as-sez fine des entrees´ au sein de l’application pour etreˆ realis´ees´. De meme,ˆ elles necessitent´ aussi souvent un modele` graphique elabor´e´ pour etreˆ mises en œuvre.
Nous presentons´ ici les abstractions des periph´eriques´ d’entree´ et de sortie mises a` disposition du programmeur par la boˆıte a` outils HsmTk. Ensuite, nous presentons´ la structure qui est proposee´ pour etablir´ le lien entre les entrees´ et les sorties, c’est-a`-dire pour supporter l’interaction proprement dite.

Table des matières

Table des figures
1 Introduction 
1.1 Problematique
1.1.1 Pret-a-porter
1.1.2
1.2 Proposition
1.3 Resultats
1.4 Organisation de la these
I HsmTk, une boite a outils pour les interactions avancées 
2 Motivations 
2.1 Des modeles pour l’interaction homme-machine
2.1.1 Modeles d’architecture
2.1.2 Modeles de l’interaction
2.1.3 Modeles de performance de l’utilisateur
2.1.4 Conclusion
2.2 Techniques d’interaction
2.2.1 Facilitation du pointage
2.2.2 Manipulation a l’aide de p ` eriph ´ eriques non-standard
2.2.3 Conclusion
2.3 Systemes et bo ` ˆıtes a outils avanc ` es
2.3.1 Systemes pr ` ecurseurs
2.3.2 Boˆıtes a outils pour l’interaction
2.3.3 Conclusion
2.4 Feuille de route
2.4.1 Trois directions
2.4.2 Cahier des charges
3 L’abstraction du syst`eme 
3.1 Abstractions el ´ ementaires
3.1.1 Composant de base
3.1.2 Composant composite
3.1.3 Valeurs actives
3.1.4 Machines a` etats hi ´ erarchiques
3.2 Periph ´ eriques et interaction
3.2.1 Entree
3.2.2 Sortie
3.2.3 Interaction
3.3 Services de bas niveau
3.3.1 Concurrence
3.3.2 Chargement dynamique de modules
3.3.3 Fenetres
3.4 Conclusion
4 Les machines a etats hierarchiques 
4.1 Introduction
4.1.1 Des langages pour l’interaction
4.1.2 Introduction au formalisme des machines a etats hierarchiques
4.1.3 Conclusion
4.2 Le formalisme des HSM
4.2.1 Etats
4.2.2 Transitions
4.2.3 Prise en compte des ev enements
4.3 Exemples
4.3.1 Le deplacement
4.3.2 Le deplacement/redimensionnement multiplex ´ e
4.3.3 Le zoom continu au clavier
4.4 Discussion
4.4.1 Reutilisabilit ´ e
4.4.2 Expressivite
II Exemples de réalisations utilisant la boite a outils HsmTk 
5 Le projet INDIGO 
5.1 L’architecture d’INDIGO
5.1.1 Architectures existantes
5.1.2 INDIGO
5.2 Applications
5.2.1 Explorateur de fichiers
5.2.2 Jeu interactif
5.3 Discussion
5.3.1 Adaptation des abstractions
5.3.2 Processus de developpement
5.3.3 Conclusion
6 Le pointage s´emantique 
6.1 Presentation du pointage s ´ emantique
6.1.1 Principe du pointage semantique
6.1.2 Le CD ratio comme echelle de l’espace moteur
6.1.3 Modele
6.2 Experimentation
6.2.1 Protocole experimental
6.2.2 Resultats
6.3 Implications pour la conception d’interfaces
6.3.1 Deux tailles pour un meme objet
6.3.2 Reconception d’interacteurs traditionnels
6.3.3 Prolongements
6.4 Utilisation de HsmTk
6.4.1 Prototypage du pointage semantique
6.4.2 Realisation de l’exp ´ erimentation contr ´ ol ˆ ee
6.4.3 Conclusion
7 Conclusions et perspectives 
7.1 Problematique
7.2 Notre contribution
7.3 Validation
7.4 Perspectives
Annexes 
A Traduction des HSM en C++
B Concr´etisation d’un graphe conceptuel en graphe perceptuel
C Fonction d’´echelle de l’exp´erimentation du pointage s´emantique
Bibliographie 

Télécharger le rapport complet