Repr´esentation de l’environnement de l’utilisateur et mod´elisation de l’architecture de services

Télécharger le fichier original (Mémoire de fin d’études)

Contributions

Nos applications de d´emonstration reposent sur notre mod`ele d’architecture distribu´ee UbiArch. Ce mod`ele s’inscrit dans la continuit´e des travaux de la communaut´e et respecte les principes fondamentaux des mod`eles conceptuels de Seeheim et Arch [Pfaﬀ, 1985, SIGCHI, 1992]. Il assure la mise en œuvre de services web interactifs utilisant les terminaux t´el´ephoniques et les clients web de l’utilisateur de mani`ere simultan´ee. Nous apportons un soin particulier a` d´efinir l’archi-tecture sous-tendant UbiArch. Nous identifions les composantes logicielles de cette architecture et impl´ementons la plate-forme mVIP, composante clef permettant l’initiation d’une session in-teractive distribu´ee a` travers le web.
Notre architecture constitue une r´eponse aux recommandations de l’« ubiquitous web do-main » [44]. Nous assemblons les dialectes du domaine autour d’un canevas, assurant ainsi l’ac-c`es au web en situation de mobilit´e, de handicap ou dans un contexte r´esidentiel. Notre travail trouve ses applications dans le domaine de l’accessibilit´e, en proposant l’int´egration de modalit´es telles que la voix afin d’assurer un rendu du service adapt´e a` chacun. Nous adressons le domaine de la mobilit´e et du travail nomade en proposant des interfaces distribu´ees dans l’espace public et rendues interactives par l’interm´ediaire du t´el´ephone mobile de l’utilisateur. Nous illustrons l’utilisation de notre plate-forme dans chacun de ces domaines au travers des d´emonstrateurs proposant des solutions d’interactions adapt´ees a` l’utilisateur.
Nos choix d’impl´ementation int`egrent les standards de la voix sur IP et du web. Ainsi, nous contribuons a` l’adoption de standards ouverts. Nous assurons du mˆeme coup l’int´egration de notre technologie dans les infrastructures existantes ; qu’elles soient web ou t´el´ephoniques. Nous d´efinissons des outils, destin´es au concepteur de services web. Nous lui permettons ainsi d’int´e-grer les fonctionnalit´es du r´eseau t´el´ephonique dans ses interfaces. Ces outils prennent la forme de couples objet graphique (widgets) et strat´egie de dialogue (diaget [Depaulis et al., 2006]).
Nous contribuons ainsi a` la construction du r´eseau ubiquitaire.
Notre mod`ele d’architecture organise l’environnement de l’utilisateur en tenant compte de sa pr´esence sur le r´eseau. Il ´etend les principes de l’espace de conception pipeline [Nigay, 1994] en int´egrant le cheminement des flux m´edia a` travers le r´eseau. Ceci nous permet de partager la responsabilit´ des infrastructures de communication entre les diﬀ´erents acteurs du service et de d´efinir une distribution des composantes logicielles a` travers le r´eseau en assurant une r´epartition de la charge adapt´ee a` l’infrastructure de communication. Nous contribuons de cette mani`ere a` int´egrer la s´ecurit´ des individus et de l’infrastructure au plus tˆot dans le processus de conception.
En r´esum´e, notre travail de recherche contribue de mani`ere significative a` la d´efinition des interfaces web de demain [Coutaz, 1998, Beaudouin-Lafon, 2004]. Notre travail met en œuvre une architecture de service s’appuyant sur les standards du web. L’architecture permet la d´efinition d’interfaces distribu´ees dans l’environnement de l’utilisateur. Notre architecture repose sur un composant clef qui permet de r´eunir dans une mˆeme session interactive des clients web et des terminaux t´el´ephoniques commut´es ou IP. L’utilisation de notre technologie se voit facilit´ee par la d´efinition d’une boˆıte a` outils destin´ee au concepteur d’applications web et permettant a` ce dernier d’´etendre les capacit´es des interfaces web classiques.
Organisation du m´emoire
Afin d’adresser ces nouveaux besoins, nous ´etudions les processus communicationnels mis en jeu lors de l’interaction entre un utilisateur et un service (chapitre 1). Nous identifions le VoiceXML comme un langage assurant la d´efinition de strat´egies de dialogues convergentes selon le mod`ele projectif du dialogue de Vernant [Vernant, 1992]. VoiceXML est un langage a` balises permettant de d´ecrire des strat´egies de dialogues. VoiceXML int`egre initialement (versions 1.0, 2.0 et 2.1) le concept de mode (vocal et DTMF14). Il est utilis´e pour d´efinir des services accessibles depuis un t´el´ephone tels que les r´epondeurs, mais il permet ´egalement de construire un sc´enario d’attente et de mise en relation… La version 3.0 de ce dialecte XML tend a` int´egrer d’autres modalit´es telles que la vid´eo comme modalit´e de pr´esentation (sortie) ou le stylet comme modalit´e de contrˆole (entr´ee). La section 1.4 montre comment VoiceXML propose des structures de contrˆole du dialogue articul´ees autour d’un canevas de requˆetes et de r´eponses.
Les fondements du web int`egrent ´egalement les concepts de requˆete et de r´eponse. Cepen-dant, le web et plus g´en´eralement l’ordinateur personnel se sont construit principalement autour de la modalit´e graphique. L’´etude des IHM a pour principal but de fournir une solution logicielle permettant a` un utilisateur d’interagir avec un ordinateur anim´e par un programme. Dans l’ar-ticle « Designing interaction, not interface », Michel Beaudouin-Lafon [Beaudouin-Lafon, 2004] r´ev`ele trois paradigmes d’interaction homme machine : la machine comme un outil (computer-as-tool), qui ´etend les capacit´es humaines a` travers la machine ; la machine comme un partenaire (computer-as-partner), qui se voit d´el´eguer des tˆaches a` travers un dialogue evolu´ ; la machine comme un medium (computer-as-medium), qui est un moyen de m´ediatiser la communication entre humains en vue d’un travail collaboratif. La section 1.1 montre comment notre probl´ema-tique adresse ces trois paradigmes. Cette section pose les fondements de notre architecture de services et ancre notre probl´ematique dans le domaine des IHM.
En introduction, nous avons identifi´ le web et les r´eseaux de t´el´ephonie comme supports 14DTMF – Dual Tone Modulaltion Frequency, signalisation associ´ee `a chacune des touches du t´el´ephone et v´ehicul´ee sur les lignes t´el´ephoniques dans les fr´equences audibles.
de notre architecture de service. Ainsi, nous ´etudions ces deux infrastructures de communica-tion (section 1.3). La premi`ere, du point de vue du W3C15, qui promeut la compatibilit´e des technologies du web ; la seconde, du point de vue de l’IETF16 qui participe `a l’´elaboration de standards pour internet, notamment les RFCs17 ayant trait `a la voix sur IP. Nous ´etudions ici de mani`ere fine les infrastructures de VoIP. N´eanmoins, l’utilisation de passerelles VoIP nous permet d’aﬃrmer que le traitement de notre probl´ematique englobe les architectures de t´el´epho-nie traditionnelle (RTC18 et GSM) sans perte de g´en´eralit´ ni impact sur la scalabilt´e de notre solution.
Par la suite, nous dressons l’inventaire des briques logicielles assurant le d´eploiement de services sur cette infrastructure (section 1.6). Nous constatons que certaines plates-formes du march´e, dˆıtes « clients l´egers », autorisent le d´eploiement de services uniquement vocaux sur la plupart des terminaux t´el´ephoniques, tandis que d’autres, dˆıtes « clients lourds », rendent compte de services exploitant le mode vocal et graphique de terminaux gourmands, coˆuteux et peu r´epandus, mais qu’aucune de ces plates-formes ne permet de connecter un terminal t´el´epho-nique `a bas coˆut et un client web dans une mˆeme session interactive. D`es lors, il convient de d´efinir une architecture de service adapt´ee.
Le chapitre 2 pr´esente notre architecture de service. Elle s’articule autour de notre mod`ele d’architecture UbiArch. La section 2.2 recense les el´ements qui composent l’environnement de l’utilisateur. Cet espace int`egre les terminaux et des nœuds du r´eseau ubiquitaire, il est struc-tur´e autour de sph`eres d’interaction d´efinies par rapport `a l’utilisateur. Les interactions entre
l’utilisateur et le service sont mod´elis´ees par des flux qui transitent sur le r´eseau. A ce titre, le mod`ele pipe-line [Nigay, 1994] rend compte de l’environnement de l’utilisateur. Les sph`eres d’in-teractions repr´esentent des sous-ensembles du r´eseau ubiquitaire impliquant `a diﬀ´erents niveaux la responsabilit´ de l’utilisateur, du fournisseur de service et de l’exploitant de l’infrastructure.
Dans la section 2.3, nous construisons notre mod`ele UbiArch a` partir des mod`eles d’in-teraction homme machine de la litt´erature [Pfaﬀ, 1985, SIGCHI, 1992] et de l’´evolution des technologies web depuis le d´ebut des ann´ees 90 a` nos jours. Notre mod`ele d’architecture homme machine r´eunit les terminaux du r´eseau ubiquitaire dans une mˆeme session interactive. Nous avons apport´e un soin particulier a` d´efinir un mod`ele impl´ementationnel adapt´e a` l’infrastruc-ture existante et a` l’usage qui en est fait. Le noyau fonctionnel d’UbiArch est mod´elis´ par un agr´egat de services web distribu´es dans le r´eseau. Un script CGI19 est en charge de construire les interacteurs qui composent l’interface du service a` partir des objets m´etiers du noyau fonction-nel. Les interacteurs sont distribu´es sur les diﬀ´erents terminaux de l’utilisateur et interagissent selon une logique de dialogue globale assur´ee par un maillage d’agents PAC20 [Coutaz, 1987].
Dans l’optique d’un d´eploiement `a court terme de notre technologie, nous concentrons nos eﬀorts sur l’int´egration du mode vocal dans les pages web. Cependant, tout au long de notre ´etude, nous gardons en tˆete la possibilit´e d’int´egrer d’autres modes de communication. Ce sou-cis de g´en´eralisation, propre `a un travail de recherche, se concr´etise par l’int´egration du mode

Table des matières

Introduction
1 Fondements du r´eseau ubiquitaire
1.1 Interaction, interfaces et dialogue homme machine
1.2 Aspects conceptuels en IHM
1.3 Infrastructure du r´eseau ubiquitaire, du web au « web 2.0 »
1.4 La navigation vocale sur le web
1.5 La diffusion de flux m´edia sur le net
1.6 Briques logicielles existantes
2 Repr´esentation de l’environnement de l’utilisateur et mod´elisation de l’architecture
de services
2.1 Vers une repr´esentation de l’environnement utilisateur
2.2 Canevas int´egrateur de la chaˆıne de traitements du flux
2.3 Mod`ele d’architecture web
2.4 Mod`ele d’architecture pour l’interaction vocale
2.5 Int´egration du mode vocal dans les interfaces web
3 Mise en oeuvre du mod´ele, sp´ecification du composant mVIP
3.1 Fonctionnement de la plate-forme
3.2 Architecture de la plate-forme mVIP
3.3 Coeur de la plate-forme mVIP
3.4 Client de reconnaissance multimodale
3.5 Boˆıte `a outils mVIP
4 Services ubiquitaires int´egrant des interfaces multimodales distribu´ees
4.1 Interface d’administration d’un syst`eme d’authentification biom´etrique
4.2 Service mATM : simulateur d’un automate bancaire
4.3 Extension de l’application web Slidy HTML
Conclusion
Bibliographie
Webographie
RFCs, recommandations et sp´ecifications
Glossaire
Annexes
A Code source du widget mSlidy
A.1 Fichier widget.css
A.2 Fichier index.html
A.3 Fichier utils.js
A.4 Fichier mvc.js
A.5 Fichier gateway.js
A.6 Fichier caller.js
A.7 Fichier numpad.js
A.8 Fichier dialogue.cgi
A.9 Fichier root.php