Expressivit´e

Le formalisme choisi est le fruit d’un compromis entre sa simplicit´e et son ex-pressivit´e. Sa syntaxe textuelle permet son int´egration ais´ee dans un proces-sus de d´eveloppement classique, et ne n´ecessite pas d’environnement parti-culier pour ˆetre ´edit´ee. Les fichiers qui d´efinissent les HSM sont traduits grˆace `a un pr´eprocesseur mis au point et distribu´e avec la boˆıte `a outils HsmTk, puis compil´es comme les unit´es de compilation classiques d’un programme. Le code ainsi g´en´er´e pour le zoom au clavier est donn´e en exemple en An-nexe A. La limitation actuelle de ce processus se trouve lors de la mise au point puisque les erreurs g´en´er´ees `a la compilation ont un lien qui peut ˆetre difficile `a reconstituer avec le fichier source original. Des m´ecanismes d’anno-tation du code g´en´er´e permettant de transmettre des informations aux compi-lateurs peuvent r´esoudre ce probl`eme, mais ils ne sont pas encore standards d’un compilateur `a l’autre.

Outre la facilit´e de l’int´egrer dans un processus de d´eveloppement clas-sique, l’utilisation d’un formalisme textuel comporte d’autres avantages. En particulier, le texte poss`ede un ordre strict qui est celui de l’apparition des d´efinitions dans le texte. Le sous-´etat initial d’une machine est ainsi par d´efaut toujours le premier sous-´etat qu’elle d´efinit. Cet ordre permet aussi d’ordon-ner les transitions et fournit ainsi un moyen simple d’avoir une machine compl`etement d´eterministe. Les transitions sont en effet toujours examin´ees dans l’ordre de leurs d´efinitions et c’est la premi`ere transition franchissable qui est franchie.

Il serait certes possible de donner aux machines `a ´etats hi´erarchiques une syntaxe visuelle, en adaptant par exemple celle des statecharts mais le b´en´efice d’une telle notation n’est pas ´evident, car il faut de toute fac¸on associer du code `a cette repr´esentation. Par ailleurs, les programmeurs sont habitu´es `a ce type de syntaxe textuelle `a base de blocs inclus les uns dans les autres. Le for-malisme utilis´e ne fait qu’introduire une dizaine de mots cl´es et de tions syntaxiques particuli`eres, qui sont ais´ement assimil´ees. Ces construc-tions, tout en restant simples, permettent cependant une concision comme l’illustrent les exemples pr´esent´es. L’interaction de d´eplacement ou le com-portement du bouton n´ecessitent chacun une quarantaine de lignes, et les techniques plus complexes ou originales gu`ere plus. Ces techniques n’ont pas n´ecessit´e chacune plus d’une heure de r´ealisation et de mise au point.

Le formalisme des machines `a ´etats hi´erarchiques, utilis´e de concert avec les abstractions mises `a disposition par la boˆıte `a outils HsmTlk, nous per-met donc de r´ealiser l’´etat de l’art des techniques d’interaction classiques ainsi que celui des techniques avanc´ees, et ce facilement, rapidement, et de mani`ere concise. Il est adapt´e `a des reconnaissances simples de geste comme celle uti-lis´ee pour le multiplexage de la translation et du zoom `a l’aide du menu cir-culaire. Il nous a permis aussi de reproduire facilement des interacteurs bas´es

4.4. DISCUSSION 91

sur le franchissement. Pour des reconnaissances de gestes plus ´elabor´ees, l’int´egration de techniques comme celle propos´ee par Rubine [1991] est pos-sible, ´etant donn´e qu’elle repose sur un calcul incr´emental de caract´eristiques d’un geste, qui peut ˆetre effectu´e dans une transition activ´ee par les mouve-ments. Cependant, nous n’avons pas r´ealis´e de techniques de ce type.

Par ailleurs, les machines `a ´etats hi´erarchiques nous ont permis, comme le montre l’exemple du zoom r´ealis´e contin ˆument grˆace au clavier, de mettre au point de nouvelles techniques d’interaction avanc´ees en facilitant le pro-totypage rapide d’id´ees et leur raffinement progressif vers des versions compl`etement utilisables. Ces capacit´es sont illustr´ees sur des exemples de plus grande ampleur dans la partie suivante de ce travail.

Deuxi`eme partie

Exemples de r´ealisations utilisant

la boˆıte `a outils HsmTk

Chapitre 5

Le projet INDIGO

Le projet INDIGO a pour but de proposer une architecture permettant de r´ealiser des applications graphiques interactives distribu´ees. La boˆıte `a outils HsmTk a ´et´e utilis´ee dans ce contexte et a montr´e son adaptation `a la conception de telles applications.

5.1 L’architecture d’INDIGO . . . 95 5.1.1 Architectures existantes . . . 96 5.1.2 INDIGO . . . 98 5.2 Applications . . . 102 5.2.1 Explorateur de fichiers . . . 102 5.2.2 Jeu interactif . . . 103 5.3 Discussion . . . 104 5.3.1 Adaptation des abstractions . . . 104 5.3.2 Processus de d´eveloppement . . . 105 5.3.3 Conclusion . . . 107

Le projet INDIGO (pour INteractive DIstributed Graphic Objects ou objets graphiques interactifs distribu´es) propose une architecture pour r´ealiser des applications graphiques interactives distribu´ees [Blanch et al., 2005]. Celle-ci s´epare le noyau fonctionnel de l’application de son interface au sein de pro-cessus distincts et ´eventuellement distants : les serveurs d’objets applicatifs et les serveurs d’interaction et de rendu. Dans cette architecture, le protocole de communication entre les deux types de serveurs est de haut niveau, celui de la s´emantique des actions sur les objets applicatifs.

Pour r´ealiser les serveurs d’interaction et de rendu dans une r´ealisation prototype, nous avons utilis´e la boˆıte `a outils HsmTk. Elle nous a permis de d´evelopper plusieurs applications qui sont pr´esent´ees ici, apr`es avoir donn´e une vue d’ensemble de l’architecture INDIGO. Nous discuterons ensuite des apports de HsmTk pour ce projet.

5.1 L’architecture d’INDIGO

La s´eparation entre le noyau fonctionnel et l’interface d’une application est mise en avant depuis longtemps maintenant par les travaux en architecture logicielle des syst`emes interactifs. C’est ce pr´ecepte qui a permis en particulier l’apparition des boˆıtes `a outils, qui permettent de faciliter le d´eveloppement

96 CHAPITRE 5. LE PROJET INDIGO

de l’interface ind´ependamment du noyau fonctionnel. Cette s´eparation a conduit, comme on l’a vu, `a une standardisation a minima de l’ensemble des interacteurs disponibles.

Avec l’apparition de nouvelles plates-formes — des t´el´ephones mobiles aux murs interactifs, en passant par les assistants num´eriques (PDA), les ta-blettes num´eriques, ou les tables interactives — les dispositifs d’entr´ee et d’af-fichage sont devenus d’une grande diversit´e, et les capacit´es de calcul tr`es variables. Le but d’INDIGO est de permettre de prendre en compte la diver-sit´e de ces plates-formes pour pouvoir proposer des interactions adapt´ees, ´eventuellement post-WIMP et collecticielles, en tirant partie d’une s´eparation adapt´ee du noyau fonctionnel et de l’interface. Pour cela, l’architecture logi-cielle INDIGO se base sur quatre principes :

– une architecture r´epartie form´ee de serveurs sp´ecialis´es dans la gestion d’objets de l’application d’une part, et dans l’interaction et le rendu gra-phique d’autre part ;

– la transformation des objets de l’application en un graphe de sc`ene dont le rendu est contr ˆol´e en fonction de la plate-forme ;

– l’interpr´etation des actions de l’utilisateur en commandes de haut niveau sur les objets du domaine ; et

– le contrˆole de la coh´erence permettant `a plusieurs serveurs d’interaction et de rendu de repr´esenter les mˆemes objets.