Des langages pour l’interaction

Beaucoup de langages particuliers ou de formalismes ont ´et´e propos´es pour d´ecrire et sp´ecifier l’interaction. Cette prolif´eration confirme l’inadaptation d’un langage imp´eratif pour d´ecrire un comportement. Les langages propos´es se s´eparent en plusieurs grandes familles : ceux bas´es sur des mod`eles r´eactifs ou ceux bas´es sur les mod`eles `a ´etats et transitions par exemple. D’autres lan-gages, plus inspir´es des formalismes adapt´es `a la description de la concur-rence, ont aussi ´et´e propos´es.

Mod`eles r´eactifs

Dans les mod`eles r´eactifs, la m´etaphore utilis´ee est celle d’un r´eseau de cˆables au sein desquels se propagent les flux de valeurs de signaux. La propa-gation des changements de valeurs peut ˆetre synchronis´ee sur les tops d’une horloge. Les “cˆables” relient entre-eux un ensemble de “composants”, qui rec¸oivent les signaux en entr´ee, leur appliquent un traitement, et en ´emettent de nouveaux en sortie.

Ce formalisme est bien adapt´e `a la description de la cascade de traitements et de filtrages que subissent les valeurs qui caract´erisent les p´eriph´eriques d’entr´ee avant d’agir sur les ´el´ements de l’interaction. La boˆıte `a outils ICONde Dragicevic et Fekete [2001], pr´esent´ee bri`evement `a la Section 2.3.2, page 40, l’utilise ainsi avec succ`es pour permettre aux programmeurs et aux utilisateurs de configurer l’interaction suivant les p´eriph´eriques d’entr´ee dont ils disposent. ICONint`egre un ´editeur graphique qui permet de programmer cette interaction visuellement, celui-ci ´etant en effet n´ecessaire pour pouvoir manipuler la m´etaphore du r´eseau facilement.

La n´ecessit´e d’un environnement d´edi´e n’est cependant pas l’inconv´enient majeur de ce type de mod`eles. Leur principale limitation est une de leur ca-ract´eristique intrins`eque : ces mod`eles ne peuvent pas, par essence, modifier leur topologie pour refl´eter l’´etat du syst`eme. Ainsi, dans ICON, si une sortie

4.1. INTRODUCTION 65

FIG. 4.1 – Multiplication des connexions dans un formalisme r´eactif (Illustration extraite de [Dragicevic, 2004])

(la position de la souris) peut ˆetre connect´ee alternativement `a diff´erents com-posants (positions de diff´erents curseurs li´es `a diff´erents outils), cette sortie sera connect´ee en permanence `a tous les dispositifs possibles, et c’est un pa-ram`etre suppl´ementaire, un bit d’activation, qui permettra de sp´ecifier quel dispositif doit effectivement r´epondre aux modifications courantes — `a la charge alors des autres dispositifs d’ignorer les signaux qui leur parviennent tout de mˆeme. La logique de cette activation est alors diffuse au sein du reste du r´eseau. Ce probl`eme est admis par [Dragicevic, 2004] qui propose quelques am´enagements au formalisme visuel pour r´eduire la complexit´e vi-suelle que ce multiplexage cr´ee dans ICON. La Figure 4.1 n’utilise pas ces am´enagements, et montre ce que donne dans ICONla configuration de quatre outils (`a droite) associ´es `a un seul curseur, et dont le multiplexage est as-sur´e grˆace `a des touches du clavier. Dragicevic [2004] admet par ailleurs la n´ecessit´e d’int´egrer une composante bas´ee sur des ´etats `a son mod`ele pour pouvoir plus facilement g´erer l’´etat de l’interaction.

D’autres mod`eles ont ´et´e propos´es qui associent `a l’approche r´eactive un niveau de contr ˆole ´etablissant les diff´erentes connexions durant des p´eriodes donn´ees grˆace `a un mod`ele de type machine `a ´etats. C’est ce que proposent en particulier Jacob et al. [1999]. Ils pr´esentent un environnement visuel de pro-grammation, VRED, dans lequel les connexions sont soumises `a des condi-tions dont les valeurs de v´erit´e sont r´egies par les ´evolucondi-tions d’une machine `a ´etats. La Figure 4.2 montre un exemple de cet environnement, avec en haut les connexions du formalisme r´eactif et en bas la machine `a ´etats qui en active les transitions. Sur cet exemple, qui exprime simplement le d´eplacement d’un

66 CHAPITRE 4. LES MACHINES `A ´ETATS HI ´ERARCHIQUES

Figure 1 shows the specification of this simple slider in our visual notation, running on our graphical editor, VRED. The upper portion of the screen shows the continuous portion of the specification using ovals to represent variables, rectangles for links, and arrows for data flows. The name of each variable is shown under its oval, and, below that, in uppercase letters, its kind. The kind can be one of INPUT, OUTPUT,

SEM, SYNT, CONST, or INT to indicate its role in the user interface as,

respectively, an actual device input, a variable that affects the display directly, semantic data shared with the application, syntactic data shared among components within the user interface, a constant, or a random interior node of the graph. The name of each link is shown under its rectangle and, below that, in uppercase letters, the name of the condition under which it will be activated or else ALWAYS, meaning it is always active.

The lower portion shows the event handler in the form of a state diagram, with states represented as circles and transitions as arrows; further details of this state diagram notation itself are found in Jacob [1983b; 1985]. The state diagram shows, inside each state, in uppercase letters, the name of a condition that is activated when this state is entered;

Fig. 1. Specification of a simple slider, running in the VRED editor, to illustrate our graphical notation. The upper half of the screen shows the continuous portion of the specification, using ovals to represent variables, rectangles for links, and arrows for data flows. The lower portion shows the event handler in the form of a state diagram, with states represented as circles and transitions as arrows.

Non-WIMP User Interfaces • 9

ACM Transactions on Computer-Human Interaction, Vol. 6, No. 1, March 1999.

FIG. 4.2 – L’environnement visuel VRED (Illustration extraite de [Jacob et al., 1999])

objet `a l’aide du curseur, le lien entre les deux repr´esentations peut ˆetre re-trouv´e facilement (la conditionDRAGGINGest activ´ee dans l’´etat de droite de la machine, ce qui autorise la connexionmousetovalentremouseetvalue en haut `a gauche). N´eanmoins, d`es que le nombre de conditions augmente, le r´eseau de connexions et ses liens avec les ´etats de la machine, deviennent, l`a encore, difficile `a identifier et `a interpr´eter visuellement.

Comme les mod`eles r´eactifs n´ecessitent une repr´esentation visuelle pour ˆetre manipul´es facilement, et qu’ils ne peuvent mod´eliser facilement `a eux seuls tous les aspects de l’interaction, nous nous sommes tourn´e vers les for-malismes `a base de machines `a ´etats.

Mod`eles `a base d’´etats et de transitions

Les mod`eles `a base d’´etats et de transitions proviennent tous de variantes ou de g´en´eralisations des automates d´eterministes finis (DFA). L’automate passe d’´etat en ´etat en franchissant des transitions activ´ees par la r´eception d’un ´ev´enement particulier. Les machines `a ´etats permettent d’associer des actions aux transitions (mod`ele de Mealy [1955]) et/ou `a l’entr´ee et la sortie des ´etats (mod`ele de Moore [1956]). Elles ont le mˆeme pouvoir d’expression que les automates (celui des langages r´eguliers), mais en pratique les actions peuvent avoir des effets de bord, et suivant la port´ee de ces derniers, le pou-voir d’expression peut ˆetre compl`etement diff´erent. Cependant, d`es lors qu’un syst`eme interactif est en jeu, il faut garder `a l’esprit que ce sont toujours des effets de bord qui permettent in fine l’interaction avec l’utilisateur. On peut par exemple reproduire la propagation des variations de la valeur d’une variable — qui est la base de mod`eles r´eactifs — en associant `a un ´etat une transition

4.1. INTRODUCTION 67

FIG. 4.3 – La machine `a ´etats qui sp´ecifie le comportement des interacteurs de Myers

(Illustration extraite de [Myers, 1990])

l’ayant `a la fois pour origine et pour cible. Si cette transition est d´eclench´ee par les ´ev´enements notifiant le changement de l’entr´ee, et que l’action associ´ee `a la transition r´epercute ces modifications sur une variable cible, la propagation a bien lieu d`es que la machine est dans cet ´etat.

Les machines `a ´etats sont couramment utilis´ees pour d´ecrire les compor-tements interactifs. Green [1986] montre ainsi que l’utilisation des syst`emes de transitions augment´es et r´ecursifs (ATN et RTN) peuvent ˆetre utilis´es pour sp´ecifier le dialogue d’une application interactive. Myers [1989, 1990] a uti-lis´e les machines `a ´etats pour d´ecrire le comportement de ses interacteurs (Fi-gure 4.3). Les ´etats sont repr´esent´es par les rectangles aux coins arrondis, les transitions par les fl`eches. Celles-ci sont ´etiquet´ees par les ´ev´enements qui les activent et par les actions qu’elles d´eclenchent.

D’autres mod`eles essaient de rem´edier `a certains des d´efauts des ma-chines `a ´etats. L’un de ces probl`emes est l’explosion combinatoire qui fait augmenter exponentiellement le nombre de transitions possibles lorsque le nombre d’´etats augmente. Pour r´esoudre ce probl`eme, on peut introduire une hi´erarchisation des ´etats en permettant d’inclure r´ecursivement des machines `a l’int´erieur des ´etats. On obtient alors les machines `a ´etats hi´erarchiques. Elles ont le mˆeme pouvoir d’expression que les simples machines `a ´etats puisqu’on peut toujours d´edoubler les transitions que la hi´erarchie permet de factori-ser, mais elles permettent de structurer davantage la machine. Les statecharts de Harel [1987] proposent d’autres modes de composition des ´etats. Ils per-mettent notamment d’avoir plusieurs ´etats actifs concouramment. Wellner [1989] les a utilis´es pour sp´ecifier l’interaction dans son outil Statemaster. Si les statecharts ont un pouvoir d’expression tr`es fort, qui leur vaut d’ˆetre utilis´e comme formalisme par UML pour sp´ecifier les comportements dynamiques, leur s´emantique est complexe et parfois difficile `a appr´ehender.

Les r´eseaux de Petri [1962] permettent d’augmenter l’expressivit´e des au-tomates en repr´esentant explicitement l’´etat du syst`eme par la position de je-tons (marquage) qui ´evoluent de place en place. Ces jeje-tons ne peuvent

fran-68 CHAPITRE 4. LES MACHINES `A ´ETATS HI ´ERARCHIQUES

FIG. 4.4 – L’environnement PetShop

chir les transitions qui s´eparent les places que si celles-ci remplissent certaines conditions (nombre suffisant de jetons en particulier). Les r´eseaux de Petri res-tent dans un cadre compl`etement formalis´e, ce qui a l’avantage de permettre de mettre en œuvre des m´ethodes de v´erification de certaines propri´et´es des syst`emes ainsi sp´ecifi´es. Cependant, la contrepartie de la puissance d’expres-sion de ce formalisme est, l`a encore, la n´ecessit´e d’un environnement d´edi´e, car seule la programmation visuelle est envisageable avec les r´eseaux de Pe-tri. Ils sont utilis´es par exemple par le formalisme ICO (Interactive Coopera-tive Objects) [Palanque et Bastide, 1993], en conjonction avec une approche par objets, pour d´ecrire les aspects dynamiques de syst`emes interactifs. Ce forma-lisme est int´egr´e `a un environnement de programmation visuelle, PetShop (Fi-gure 4.4), qui permet de mettre au point et d’ex´ecuter des syst`emes sp´ecifi´es `a l’aide du formalisme ICO [Bastide et al., 2002].

Langages concurrents et `a base de r`egles

Le langage squeak [Cardelli et Pike, 1985], de mˆeme que ERL (Event Res-ponse Language) propos´e par Hill [1986], est un des langages `a syntaxes textuelles inspir´e des langages utilis´es pour programmer des programmes concurrents comme CSP [Hoare, 1978]. Olsen [1990] propose aussi une no-tation `a base de r`egles de productions, qui combine des aspects des langages concurrents, et la d´efinitions d’´etats, il s’agit de PPS (Propositional Production Systems). Il l’utilise en particulier pour d´ecrire le comportement des inter-acteurs standards [Olsen, 1998, Chapitre 8]. Squeak d´efinit pour sa part des

4.1. INTRODUCTION 69

DoubleClick = DN? .

wait[clickTime] UP? .

wait[doubleClickTime] DN? .

wait[clickTime] UP? . doubleClick! . DoubleClick || click! . down! . UP? . up! . DoubleClick || click! . DoubleClick

|| down! . UP? . up! . DoubleClick

FIG. 4.5 – Le double-clic exprim´e dans le langage squeak (Listing extrait de [Cardelli et Pike, 1985])

canaux permettant de communiquer avec les p´eriph´eriques : position de la souris, changements d’´etat des boutons, caract`eres saisis `a l’aide du clavier. Il permet aussi de d´efinir des zones rectangulaires et d’ˆetre notifi´e lorsque le curseur y entre ou en sort. Il permet enfin de fixer des d´elais d’attente. La Figure 4.5 montre un processus squeak qui, `a partir des informations de changement d’´etat d’un bouton (vers le hautUPet vers le basDN), g´en`ere des ´ev´enementsdoubleClicks’ils respectent un certain motif temporel contr ˆol´e par des d´elais ; et qui, sinon, ´emet les ´ev´enementsclick,upetdownpour qu’un autre processus puisse les traiter. Ce langage a l’avantage d’avoir une s´emantique formellement d´efinie. On peut mettre `a son cr´edit sa concision, mais la mise au point d’interactions complexes paraˆıt d´elicate pour les non-experts de ce formalisme.

Compromis

Parmi les mod`eles pr´esent´es, nous en avons choisi un sur la base d’un compromis dont les crit`eres principaux sont :

– la puissance d’expression ; – la simplicit´e de la s´emantique ; et

– le degr´e d’int´egration avec le langage de programmation.

Pour la simplicit´e, nous avons choisi les machines `a ´etats, en utilisant la va-riante qui limite son principal inconv´enient en permettant une meilleure struc-turation des ´etats : les machines `a ´etats hi´erarchiques (HSM pour Hierarchical State Machines). Ce choix est ´egalement motiv´e par le fait qu’on peut faire de ces machines `a ´etats hi´erarchiques une repr´esentation textuelle. Nous ver-rons que cette syntaxe permet de lever implicitement certaines ambigu¨ıt´es pr´esentes dans les syntaxes visuelles en introduisant un ordre naturel sur les divers ´el´ements des machines `a ´etats hi´erarchiques. Cette repr´esentation tex-tuelle permet aussi d’int´egrer facilement le formalisme au reste du processus de cr´eation d’application, et notamment au langage de programmation lui-mˆeme.

4.1.2 Introduction au formalisme des machines `a ´etats