Le paradigme état-transition

En utilisant le paradigme état-transition, la modélisation de l’interaction multimodale est composée d’un nombre fini d’états, de transitions et d’actions. Les états sont reliés par les transitions afin de permettre le passage d’un état à un autre et/ou provoquer une action. Chaque transition est étiquetée par un événement en entrée et la modalité d’interaction as- sociée, tandis que les états sont généralement étiquetés par les événements de sortie et leurs modalités en sortie.

3.1.1.1 SMUIML / HephaisTK

SMUIML (Synchronized Multimodal User Interaction Modeling Language) [32] est un langage basé sur XML pour modéliser les interfaces multimodales en entrée. Il a été créé afin de configurer la plateforme HephaisTK [32] pour la création rapide d’interfaces multimo- dales. Cette plateforme basée sur les agents s’intègre dans l’application multimodale cible. Selon le document de configuration SMUIML, qui décrit le dialogue homme-application, la plateforme gère les « Recognizers » de modalités, reçoit et encapsule les données à par- tir de ces « Recognizers », gère la fusion des interactions combinées et notifie l’application multimodale.

FIGURE3.1 – Notation visuelle des concepts SMUIML

SMUIML est basé sur le paradigme état-transition. Il modélise les interactions multimo- dales de la manière suivante :

– Le dialogue d’interaction est modélisé par une machine à états où les états représentent les éléments du contexte connectés par les transitions.

– Une transition définit l’évènement en entrée avec la modalité d’interaction associée. – Chaque transition permet soit le passage vers un autre état, soit de rester dans le même

état en déclenchant une action.

– Les combinaisons entre modalités d’interaction en entrée sont modélisées par les opé- rateurs « seq and », « seq or », « par and » et « par or » (« par » pour « parallel » et

« seq » pour « sequential ») (propriétés CARE).

FIGURE 3.2 – Le fonctionnement de SMUIML/HephaisTK [71]

SMUIML permet une modélisation structurée et claire [38]. Il possède un éditeur gra- phique pour modéliser graphiquement les interfaces multimodales en entrée [71]. La modé- lisation graphique a un sens de lecture bien précis. La majorité des symboles ont une trans- parence sémantique. Cependant, la distinction entre les symboles des combinaisons entre modalités (« seq and », « seq or », « par and » et « par or ») n’est pas évidente (figure 3.1). La discrimination visuelle (le troisième critère de la physique des notations) est très réduite ce qui ne permet pas de discerner facilement chaque symbole.

Après la modélisation graphique, l’éditeur SMUIML génère un script de configuration (« la productivité des modèles est limitée à la configuration de HephaisTK ») utilisé avec un autre fichier Java pour configurer HephaisTK rattaché à l’application cible. HephaisTK re- çoit et fusionne les entrées de l’application selon les combinaisons des modalités spéci- fiées et informe l’application. Ainsi, l”interaction multimodale d’entrée est gérée automa- tiquement sans la participation des développeurs (même si certaines configurations ma- nuelles sont nécessaires). Cependant, « la multimodalité en sortie n’est pas traitée dans

SMUIML/HephaisTK », c’est l’application multimodale qui s’en charge (figure 3.2).

À la base, SMUIML/HephaisTK n’a pas été créé pour permettre la modélisation des in- teractions avec des périphériques mobiles. Cependant, son adaptation pour concevoir des ap- plications mobiles multimodales en entrée a été réalisée. Dans [28], par exemple, le langage de modélisation proposé est basé sur SMUIML pour modéliser des applications mobiles mul- timodales (applications Android uniquement -pas de traitement d’hétérogénéité). Ensuite, le framework (pas encore disponible publiquement) gère automatiquement le processus de fu- sion comme le fait HephaisTK. Le problème de cette approche est qu’elle se limite au trai- tement des modalités vocale et tactile uniquement. Elle ne traite pas les interactions à base de nouveaux capteurs mobiles bien que SMUIML propose un niveau d’abstraction adapté pour les modéliser. Il définit l’interaction à deux niveaux : 1) le niveau réception (concepts Recognizer dans le méta-modèle (figure 3.3)) qui permet de définir le capteur responsable ainsi que la modalité de l’interaction ; 2) le niveau de détection d’évènement issu de cette interaction (concepts « Trigger »). L’utilisateur du langage peut ainsi modéliser les interac- tions en détail (« Recognizer »= Accéléromètre, « Modality »= Accélération et « Trigger »= Secouage, par exemple).

3.1.1.2 MMIR

Le framework MMIR (Multimodal Mobile Interaction and Rendering) [96] fonctionne presque de la même façon que HephaisTK, mais pour les applications web sur mobile. Son but est de faciliter la construction des systèmes légers de dialogue (sous le navigateur). MMIR traite les interactions en entrée et en sortie pour des modalités particulières (tactile, reconnaissance vocale et gestuelle en entrée, affichage, audio et synthèse vocale en sortie). Cependant, il ne traite pas les combinaisons entre interactions (ni en entrée ni en sortie).

En entrée, il se base sur le langage SCXML (State Chart XML) pour décrire les inter- actions utilisateurs qui seront traitées et envoyées vers l’application (un exemple est montré à la figure 3.4). En sortie, les interactions sont modélisées séparément avec des templates HTML. Le développement de MMIR est en cours. Cependant, il ne fonctionne que sous An- droid et le navigateur Chrome (il utilise des APIs qui ne fonctionnent que sous Android pour la gestion de la reconnaissance et de la synthèse vocale -pas d’hétérogénéité), alors que les applications web sont censées être multi-plateforme.

FIGURE3.4 – Un exemple d’une modélisation graphique de la procédure de connexion d’une application sous SCXML[96]

3.1.1.3 IMBuilder / MEngine

IMBuilder/MEngine [16] utilise les machines à états finis (Finite State Machine ou FSM) pour modéliser puis exécuter rapidement des interfaces multimodales (mobile ou classique). Il est composé de deux modules : IMBuilder et MEngine. IMBuilder est l’environnement graphique de modélisation. Il permet de spécifier les interactions multimodales sous forme d’automates finis. En utilisant les fichiers XML générés par IMBuilder, MEngine exécute directement les interactions des utilisateurs combinant parole et geste. MEngine lance la reconnaissance vocale ainsi que la reconnaissance des gestes (mouvement de souris unique- ment) et traite les actions utilisateurs selon les machines à états modélisées.

Cette approche ne génère pas le code des interfaces, mais permet de réaliser des proto- types rapides des interfaces afin de les tester avant l’implémentation (productivité limitée). C’est un framework destiné aux concepteurs d’interfaces. Le langage de modélisation est générique (permet de modéliser tous types d’interaction) alors que le moteur d’exécu- tion ne traite que les interactions vocales et gestuelles (gestes 2D effectués à la souris). Il traite aussi les combinaisons entre modalités, mais en entrée uniquement (combinaisons séquentielles, complémentaires (figure 3.5), équivalentes ou redondantes). Les concepteurs qui utilisent IMBuilder pour modéliser les combinaisons doivent faire attention à l’ordre des

modalités d’interaction. Si l’ordre n’est pas important dans une commande multimodale, le concepteur doit modéliser tous les ordres possibles d’utilisation des modalités.

FIGURE 3.5 – La consultation de la photo d’une note dans l’application « Prise de notes »

exprimées à l’aide de IMBuilder

Par exemple, dans la figure 3.5, nous modélisons une complémentarité pour sélectionner une photo d’une note à partir d’une liste des notes. Nous avons modélisé cette complémenta- rité entre deux interactions (vocale et tactile) en deux séquences différentes, car l’ordre n’est pas important : sélectionner la note puis dire qu’on veut voir la photo de la note ou bien parler avant de la sélectionner.

Le concepteur doit alors assimiler les règles de modélisation avec les FSMs afin de modé- liser correctement et tester différentes versions d’interaction multimodale sous IMBuilder / MEngine.

3.1.1.4 UMAR / SIHMM

L’approche UMAR (User Modalities Artefact Representation)/SIHMM (Simulateur de l’Interaction Homme-Machine Multimodale) [63] permet la description des interactions mul- timodales (avec UMAR) puis leur simulation (pas de génération de code) en utilisant la plateforme SIHMM (d’un point de vue utilisateur).

UMAR permet de modéliser à la fois les interactions multimodales en entrée et en sortie. Cependant, il ne modélise pas les interactions en détail (on ne voit pas le type de l’évènement). Les modalités sont organisées en trois catégories :

– Les modalités d’action : elles sont utilisées en entrée pour interagir avec le système comme le tactile. Elles sont notées par le 7-uplet <Cat, P, R, Co, Tr, Ti, Te> où Cat : la Catégorie de la modalité (tactile, vocale...), P : le dispositif Physique utilisé (écran, microphone...), R : le système Représentationnel (langage gestuel, langage naturel, etc.), Co : la modalité de Contrôle attachée à la modalité d’action, Tr : le Temps de réalisation, Ti : le Temps d’interprétation et Te : le Temps d’exécution.

– Les modalités de sortie (ou feedback) : elles sont utilisées pour exprimer les retours des systèmes tels que l’affichage. Elles sont modélisées par le triplet <P,R,D> où D définit le temps nécessaire pour exprimer la modalité (la durée de l’interaction en sortie). – Les modalités de contrôle : elles sont utilisées pour contrôler d’autres modalités, par

exemple, la modalité de contrôle du vocal est l’audition.

Les propriétés CARE de combinaison entre les modalités sont aussi traitées (« ˚ » pour complémentarité, « & » pour redondance et « || » pour l’équivalence).

La modélisation UMAR se base sur le paradigme d’état. Il utilise une notation de graphes à base d’états simultanés (parallèles) et hiérarchiques (figure 3.6). Le parallélisme est utilisé, car le fil du dialogue homme-machine est souvent parallèle (les modalités sont souvent indé- pendantes les unes des autres). Les modèles sont ainsi modulaires et peuvent être structurés sur des sous-diagrammes simultanés. La description modulaire et le parallélisme entre les sous-diagrammes fournissent plus de lisibilité. Cependant, le formalisme ne possède pas un sens de lecture précis.

UMAR/ SIHMM permet aussi la modélisation et la simulation des systèmes mobiles. La simulation avec SIHMM montre aux concepteurs et développeurs la réalité de l’interaction prévue au sein des systèmes interactifs multimodaux mobiles.

La synthèse des approches basées sur le paradigme état-transition est résumée dans le tableau 3.1.

FIGURE3.6 – L’application « Prise de notes » modélisée avec UMAR Interaction mul- timodale Combinaisons Interaction à base de capteurs mobiles Productivité des modèles SMUIML / He- phaisTK En entrée unique- ment CARE Oui (deux niveaux de modélisation) Interprétation (pas d’hétérogé- néite) MMIR En entrée et en sortie (deux lan- gages différents)

/ Non

Interprétation (pas d’hétérogé- néite)

IMBuilder / MEngine En entrée unique-

ment CARE Non

Prototypage uni- quement

UMAR / SIHMM En entrée et en

sortie CARE Non Simulation

TABLE3.1 – Synthèse des approches basées sur le paradigme état-transition