La modélisation - Université des Sciences et de la Technologie d`Oran

République Algérienne Démocratique et Populaire
Ministère de l'Enseignement Supérieur et de la Recherche Scientifique
Université des Sciences et de la Technologie d'Oran
USTO-Mohamed Boudiaf, Faculté des Sciences,
Département d'Informatique
MEMOIRE
PRESENTE EN VUE DE L'OBTENTION DU DIPLOME DE
MAGISTER EN INFORMATIQUE
Option : Modélisation, Optimisation et Evaluation
des performances des Systèmes
Par
ELOUALI Nadia
Thème
Modélisation et développement d'une
application mobile multimodale
Sous la direction de : Mr K.Belkadi
Soutenu publiquement le : 27/11/2012
Devant le jury composé de :
Président :
Mr BENYETTOU Mohamed
Examinateurs : Mme CHOURAQUI Samira
Mr SADOUNI Kaddour
À mes très chères parents et mes très chères sœurs.
2
REMERCIEMENTS
Eternel remerciement à Allah, le clément et miséricordieux, de m'avoir permis de réaliser ce
magister.
Au président du jury, Mr BENYETTOU Mohamed, qui m'a fait l'honneur de présider le jury de ce
magister, dont la soutenance fut l'un des événements les plus importants de ma vie.
À mon encadreur, Belkadi Khaled, que je remercie de la confiance qu'il a placé en moi. Il m'a guidé
par son conseil pendant mes deux ans de magister et lors de la rédaction.
Aux examinateurs du jury, Mme CHOURAQUI Samira et Mr SADOUNI Kaddour, pour l'intérêt
qu'ils ont porté à mon travail.
À Abdelkader mon père et Fatiha ma mère, pour leurs amour et leurs confiance qui me donne
toujours le courage pour avancer.
À mes sœurs; Amel pour sa patience, Fatima Zohra pour ses encouragements et la prise en charge
de mes inscriptions administratives et la paperasse de la soutenance, Malika pour sa disponibilité et
son accompagnement, Fadela pour ses conseils et ma chère Aya pour son amour.
À Amr Khaled...
3
Sommaire
Introduction générale...........................................................................................................................8
Chapitre I : Multimodalité et mobilité................................................................................................ 11
I.1 Introduction.............................................................................................................................. 11
I.2 L'interaction multimodale.........................................................................................................11
I.2.1 Définitions et terminologie .............................................................................................. 11
I.2.1.A Mode :.......................................................................................................................11
I.2.1.B Modalitè :................................................................................................................. 12
I.2.1.C Média :......................................................................................................................12
I.2.1.D Multimédia et multimodal :......................................................................................12
I.2.2 Principales caractéristiques des interactions multimodales.............................................. 14
I.2.3 Types d'interactions et coopération entre les modalités....................................................14
I.2.3.A Propriétés CARE...................................................................................................... 15
I.2.3.B Propriétés TYCOON................................................................................................ 17
I.2.4 Fusion et fission des données multimodales.....................................................................18
I.2.5 Difficultés de conception et de développement des applications multimodales..............19
I.3 L'informatique mobile.............................................................................................................. 21
I.3.1 Classification des systèmes mobiles ................................................................................ 21
I.3.2 Intérêts et limites des systèmes mobiles .......................................................................... 22
I.3.3 Plateformes mobiles : Android & iPhone......................................................................... 23
I.3.3.A Android : la plateforme open source mobile............................................................ 23
I.3.3.A.a Historique et définition..................................................................................... 23
I.3.3.A.b L'architecture Android...................................................................................... 23
I.3.3.A.c Développement sous Android...........................................................................25
I.3.3.B iPhone ...................................................................................................................... 26
I.3.3.B.a Historique et définition..................................................................................... 26
I.3.3.B.bi Phone SDK...................................................................................................... 26
I.4 Conclusion................................................................................................................................ 27
Chapitre II : La modélisation..............................................................................................................29
II.1 Introduction............................................................................................................................. 29
II.2 La modélisation des applications informatiques..................................................................... 29
II.2.1 Modèle et modélisation................................................................................................... 29
II.2.1.A Modèle ................................................................................................................... 29
II.2.1.A.a Définition.........................................................................................................29
II.2.1.A.b Qualité des modèles........................................................................................ 29
II.2.1.B Modélisation............................................................................................................30
II.2.1.B.a Définition.........................................................................................................30
II.2.1.B.b Pourquoi modéliser?........................................................................................31
II.2.1.B.c L'ingénierie dirigée par les modèles (IDM).....................................................32
II.2.2 UML, un langage de modélisation ................................................................................. 32
II.2.2.A La notion d'objet..................................................................................................... 33
II.2.2.B Contenu d'UML...................................................................................................... 34
II.3 La modélisation en IHM......................................................................................................... 35
II.3.1 Les besoins de modélisation en IHM.............................................................................. 35
II.3.2 Les modèles en IHM....................................................................................................... 36
II.3.2.A Modèles d'architecture ........................................................................................... 36
II.3.2.A.a Modèles linguistiques......................................................................................37
II.3.2.A.b Modèles à agent ..............................................................................................40
4
II.3.2.B Modèles d'interaction.............................................................................................. 44
II.4 Conclusion...............................................................................................................................47
Chapitre III : Modélisation et développement de e-USTO.................................................................49
III.1 Introduction............................................................................................................................49
III.2 Modélisation multimodale..................................................................................................... 49
III.2.1 Modèle d'interaction pour la multimodalité................................................................... 49
III.2.2 Notre notation : le CTT annoté...................................................................................... 51
III.3 L'application mobile multimodale e-USTO...........................................................................54
III.3.1 Pourquoi e-USTO (electronic-USTO) ?.........................................................................54
III.3.2 Modélisation de e-USTO............................................................................................... 55
III.3.3 Développement de e-USTO & résultats.........................................................................58
Conclusion et perspectives................................................................................................................. 78
Bibliographie......................................................................................................................................80
5
Résumé
L'interface homme machine est un élément clé de l'utilisation des applications informatiques et
conditionne pour une large part leurs succès. Théoriquement, elle permet aux utilisateurs d'accéder à
l'application d'une façon simple et efficace en utilisant leurs différents modes de perception et de
communication. Malheureusement, les interfaces classiques d'interaction ou dite interfaces WIMP
(Windows, Icons, Menus, Pointing device) sous-exploitent une grande partie des capacités sensorimotrices de l'être humain. Ainsi, elles ne fournissent que des modalités très limitées d'interaction
alors que l'utilisateur peut parler, écouter, voir et faire des gestes simultanément.
Les interfaces multimodales cherchent à résoudre cette problématique et satisfaire l'être humain en
exploitant au maximum ses capacités communicatives. Ce sont des interfaces qui possèdent au
moins deux modalités d'interaction en entrée et/ou en sortie ce qui permet d'apporter plus de
rapidité, d'efficacité, et de confort à l'utilisateur final.
Ce mémoire de magister décrit la modélisation, la conception et la réalisation d'une interface
multimodale pour une application mobile sous Android. Cette application vise à exposer
l'Université des Sciences et de la Technologie d'Oran (USTO) afin de pouvoir donner des
informations pratiques sur l'université aux étudiants et visiteurs et donc remplacer les guides papiers
classiques. Notre travail, se veut apporter par la multimodalité de cette application une méthode de
modélisation simplifiée afin de résoudre les divers problèmes liés à l'implémentation des différentes
modalités d'interaction dans une application mobile.
Mots clés
Interaction Homme-Machine, Interfaces multimodales, Application mobile, Modélisation.
6
Abstract
The Human Machine Interface is a key element in using computer applications and determines in a
large part their success. Theoretically, it allows users to access the application in a simple and
effective way by using their different modes of perception and communication. Unfortunately,
conventional interfaces or so-called WIMP interfaces (Windows, Icons, Menus, Pointing device)
which does not exploit all the sensory-motor capabilities of humans. Thus, they provide only a very
limited interaction modalities while the user can speaks, listens, sees, feels and makes gestures
simultaneously.
Multimodal interfaces try to solve this problem and satisfy the end users by allowing them to use
their communication skills. These interfaces have at least two input/ output interaction modalities
which provide more speed, efficiency, and comfort to the end users.
This research describes the modeling, design and implementation of a multimodal interface for a
mobile application. This application aims to expose the University of Science and Technology of
Oran (USTO) in order to provide practical information about the university to their students and
visitors and thus replace the traditional paper guides. Our work aims simplify the modeling
approach and solve the various problems related to the implementation of the various interaction
modalities in a mobile application.
Keywords
Human Machine Interaction, Multimodal interfaces, Mobile application, Modeling.
7
Introduction
Un des domaines de recherche émergents en interaction homme-machine est préoccupé par
la conception et le développement des interfaces de plus en plus naturelles. Ces interfaces visent à
simplifier la communication homme-machine en offrant aux utilisateurs la possibilité d'utiliser leurs
différentes capacités sensori-motrices. En 1980, Richard Bolt a proposé un premier paradigme
naturel [Bolt, 1980] qui permet à l'utilisateur de son système d'interagir avec la voix et les gestes
simultanément en lui donnant ainsi le plaisir d'utiliser les deux capacités préférées en
communication homme-homme. Depuis, la multimodalité a été retenue pour décrire l'utilisation de
plusieurs modalités d'interaction et pour avancer vers la naturalisation des systèmes même si une
application multimodale n'est pas forcément naturelle. En plus, l'arrivée des périphériques mobiles à
donner beaucoup de succès aux interfaces multimodales, car avec leurs différents capteurs ils
offrent un nombre important de modalités d'interaction telle que le tactile, geste, vocale, etc.
Toutefois, le développement des applications multimodales reste encore une tâche difficile [Serrano
et al., 2008]. D'une part, elles demandent beaucoup de développement de bas niveau (la
manipulation des différents périphériques, les techniques de reconnaissance,...etc) et donc un effort
important des développeurs et en conséquence un coût très élevé surtout pour la combinaison des
modalités d'interaction et la fusion/fission des données en entrée/sortie qui n'ont pas encore
d'algorithmes conventionnels. D'autre part, comme l'a démontré Oviatt [Oviatt, 1999], les
utilisateurs finaux n'utilisent pas toujours les applications multimodales d'une façon multimodale.
C'est à dire que les utilisateurs ne se servent pas de la multimodalité tant qu'elle ne leur facilite pas
la tâche d'interaction. Il faut alors trouver les modalités d'interaction les plus adaptés ainsi que les
combinaisons les plus proches cognitivement et psychologiquement des utilisateurs finaux pour
s'assurer que le système est bien utilisé d'une façon multimodale.
La modélisation semble une solution adéquate pour résoudre les problèmes de développement et
simplifier la réalisation des systèmes multimodaux. C'est la solution qui était retenue depuis
quelques années pour faciliter la création des applications interactives, car même si elle nécessite un
peu plus de temps, il a été démontré que la formalisation des systèmes avant leur création diminue
significativement les problèmes rencontrés lors du développement et augmente leurs utilité et
utilisabilité. De plus, avec l'émergence de l'Ingénierie Dirigé par les Modèles (IDM) la modélisation
est devenue une piste de recherche très recommandée dans le domaine de l'interaction multimodale.
8
Dans ce mémoire de magister, on se base sur la modélisation afin de simplifier la réalisation des
applications mobiles multimodales. Notre but n'est pas de générer du code à partir des modèles,
même s'il reste un de nos futurs buts, mais de trouver une modélisation adéquate aux interactions
multimodales et accessible à tous les participants du processus de conception et de développement.
Ce mémoire est constitué de trois grands chapitres :
•
Un premier chapitre qui mettra en évidence les informations d'ordre général sur les
applications mobiles et les interfaces multimodales dans le but de présenter les différentes
définitions proposées dans la littérature à propos du domaine.
•
Un deuxième chapitre présentera les différents aspects de modélisation et les modèles déjà
existants pour modéliser les applications multimodales avec une étude comparative entre
eux.
•
Dans un troisième chapitre nous présentons notre modèle d’interaction intégrant la
dimension multimodales qui constitue notre contribution conceptuelle. Nous présentons
aussi nos résultats expérimentaux et leurs discussions. À l'issue de ce travail, une
conclusion générale comprendra les perspectives seront dégagées.
9
Chapitre I :
Multimodalité et mobilité
10
I Multimodalité et mobilité
I.1 Introduction
Depuis 1984 les interfaces WIMP sont largement répandues et représentent la majorité des
interfaces utilisées aujourd’hui. Le principe de ces interfaces se base sur la manipulation graphique
des objets d’intérêts. Cependant, le futur est annoncé aux interfaces dites post-WIMP, qui reposent
sur de nouveaux paradigmes d’interaction [Bouchet, 2006].
Dans ce chapitre nous présentons le paradigme multimodal ainsi que l'informatique mobile qui est
de plus en plus répandu et qui participe fortement à la propagation de la multimodalité.
I.2 L'interaction multimodale
I.2.1 Définitions et terminologie
La terminologie dans le domaine des interfaces multimodales n'est pas bien stabilisée. Bien que les
concepts soient identifiés par la communauté scientifique, il faut cependant souligner l'inexistence
d'un consensus général sur les termes servant à les désigner.
La littérature nous a permis de relever quatre groupes de termes directeurs : mode, modalité, média,
multimédia et multimodal.
I.2.1.A Mode :
Dans le sens commun un « mode » détermine la manière générale dont un phénomène se présente
ou dont une action se fait.
Au sens de Frohlich [Frohlich, 1991], les modes d'une interface se définissent comme des états dans
lesquels différentes actions de l'utilisateur peuvent avoir le même effet. En général et du point de
vue système, le mode évoque l'état dans lequel le système interactif se trouve à un instant donné
(avec un éditeur de texte on peut se trouver en mode « saisie » par exemple), tandis que du point de
vue usager, le mode traduit les états au travers desquels les différentes actions de l'usager peuvent
produire les mêmes effets (pour fermer une fenêtre l'utilisateur peut exécuter cette commande en
cliquant avec la souris sur la croix ou à l'aide des touches ALT et F4 du clavier).
Bellik [Belik, 1995] se positionne du côté utilisateur. Pour lui le terme mode fait référence aux cinq
sens de l'être humain : le toucher, l'ouïe, la vue, l'odorat, le goût (réception d'information), et aux
différents moyens d'expressions humains : le geste, la parole (émission d'information). Le mode
11
définit la nature des informations servant pour la communication (mode visuel, mode sonore, mode
gestuel etc).
I.2.1.B Modalitè :
Au sens large, une « modalité » est assimilée à une technique d'interaction ou une manière
d'interagir avec le système [Nigay, 1994].
Une modalité pour Bellik [Belik, 1995] est une forme concrète particulière d'un mode. Toujours
d'un point de vue utilisateur, il considère que la modalité de communication est définie par la
structure des informations échangées, telle qu'elle est perçue par l'être humain. Par exemple, en ce
qui concerne le mode auditif, on peut citer les modalités suivantes : parole, musique, bruit, chant,
etc.
Bernsen, quant à lui, la définit comme étant un système représentationnel d'information : un graphe,
un texte, etc. [Blattner et al., 1990].
La définition d'une modalité la plus communément admise est celle d'un couple <p,r> où : « p »
désigne un dispositif physique (souris, caméra, écran, etc), et « r » dénote un système
représentationnel ou langage d'interaction, c'est-à-dire un système conventionnel structuré de signes
assurant une fonction de communication (langage pseudo naturel, graphe, référentiel de
coordonnées GPS, etc). La modalité peut être active ou passive ce qui permet de déterminer si
l'utilisateur doit effectuer une action explicite pour recevoir de l'information ou pas [Rouillard,
2008].
I.2.1.C Média :
Une majorité des auteurs s'accordent à penser qu'un média est un support technique de l'information
(CD-ROM, flash disque, ...).
Pour Blattner [Blattner et al., 1990] tout véhicule d'information physique ou logique (un mail par
exemple) est un média. Mais pour Jacquet [Jacquet, 2006], un média est un dispositif informatique
qui permet l'interfaçage de la machine avec des utilisateurs, en entrée ou en sortie, selon une ou des
modalités données.
Selon cette dernière définition un média sert à véhiculer une modalité. Par exemple, un écran
permet de véhiculer des modalités visuelles, un système de synthèse vocale (haut-parleurs compris)
la modalité parole synthétique, etc.
I.2.1.D Multimédia et multimodal :
La diversité des définitions des termes média et modalité, laisse entrevoir la difficulté d'identifier
une définition consensuelle pour multimédia et multimodal.
12
Bellik [Belik, 1995] définit un système multimodal comme un système capable d'intégrer plusieurs
modes ou modalités de communication et un système multimédia comme un système capable
d'acquérir et/ou de restituer, par l'intermédiaire des médias, des informations de natures et/ou de
formes différentes (parole, musique, image vidéo, etc.).
Bouchet [Bouchet, 2006] explique que la multimodalité reflète le caractère de multiplicité (préfixe
multi) des modalités pour un même système interactif. Pour lui un système est multimodal s'il
dispose d'au moins deux modalités pour un sens donné (entrée ou sortie).
Pour la plupart des informaticiens, un système multimédia se caractérise par l'utilisation simultanée
de différents dispositifs physiques, par la gestion en parallèle des événements qui en découlent et
par la construction d'événements de haut niveau d'abstraction à partir d'événements de plus bas
niveau [Nigay et al., 1996].
Il suffit que les termes soient situés dans leur contexte d'utilisation pour valider toutes les
définitions ci-dessus. En effet, chaque définition dépend du point de vue (utilisateur ou système)
que l'on adopte et dans quelle phase il est adopté.
Par exemple, en phase de conception, le concept de média est généralement défini comme dispositif
physique associer aux qualités sensori-motrices de l'utilisateur. En revanche, pour les phases de
mise en œuvre, un média est assimilé à un dispositif d'entrée/sortie (vision purement matérielle)
assorti d'un type qui caractérise l'information brute acquise ou produite (par exemple, une chaîne de
caractères, vision logique de la perspective matérielle).
- Nous présentons ci-après notre vision afin de fixer quelques définitions :
Média : c'est un dispositif physique qui acquiert ou diffuse l'information [Belik, 1995].
Mode, modalité : ces termes sont équivalents et ils correspondent à la nature des informations
servant pour la communication et se réfèrent aux sens humains. On peut la définir également
comme un style d'interaction qui peut être utilisé en entrée (orale, gestuelle, écrite, etc) ou en sortie
(sonore, visuelle, tactile, etc) [Catinis, 1998].
Multimédia : côté machine, un système multimédia est capable d'acquérir, de stocker et de restituer
des informations de nature différente (texte image, sons, séquences vidéo, ...). Du côté utilisateur,
un système multimédia offre à l'utilisateur la possibilité d'acquérir et de manipuler des informations
de nature variée [Catinis, 1998].
Mutimodal : un système est multimodal s'il est capable d'intégrer plusieurs modalités de
communication [Belik, 1995] .
13
I.2.2 Principales caractéristiques des interactions multimodales
Les interfaces multimodales présentent beaucoup plus davantage par rapport aux interfaces
classiques. Plus précisément, l'exploitation des caractéristiques telles que le choix des modalités
adéquates et leurs combinaisons permet d'avoir les avantages suivants :
•
L'interaction multimodale en entrée et/ou en sortie permet une communication hommemachine naturelle. Par conséquence une application naturelle est forcement multimodale
mais l'inverse n'est pas toujours vrai car, une application multimodale peut avoir le clavier
ou la souris en entrée alors qu'ils ne sont pas du tout naturels.
•
La spécification de plusieurs modalités d'interaction permet d'impliquer de nouveaux
utilisateurs en interaction avec les systèmes informatiques comme les personnes âgés,
malades (maladie de Parkinson par exemple), etc.
•
La correction des erreurs et la robustesse d'interaction est augmentée significativement pour
les applications multimodales [Oviatt, 1997] car les utilisateurs peuvent choisir la modalité
qui leur semble plus sécurisée.
•
La multimodalité permet aussi l'adaptation au contexte d'utilisation. Le système peut être
adaptable, c'est-à-dire qu'il est capable de détecter les changements dans son environnement
et de modifier son fonctionnement automatiquement (il utilise automatiquement le vocale
au lieu du tactile en entrée parce qu'il détecte qu'il fait très froid), ou adaptative, c'est-à-dire
que l'utilisateur aura la possibilité de changer le mode de fonctionnement du système en
fonction de ses besoins et de son contexte (il choisie la synthèse vocale en sortie du système
au lieu de l'affichage du texte parce qu'il a oublié ses lunettes et il n'arrive pas à lire).
La littérature donne aussi d'autres avantages de l'utilisation de la multimodalité telle que
l'exploitation de toutes les capacités de calcul des ordinateurs, l'utilisation du multi-tâche, etc. Mais
les plus grands avantages sont ceux qui tombent du côté utilisateur parce que le principal but de la
multimodalité est de satisfaire l'utilisateur final.
I.2.3 Types d'interactions et coopération entre les modalités
Un système multimodal peut utiliser plusieurs modalités différentes en entrée et/ou en sortie. On
peut alors se demander quels rapports ces modalités entretiennent les unes aux autres et la façon
14
dont leur combinaison peut être mise à profit par le système.
Les types de coopération entre modalités ont été introduits par Jean-Claude Martin durant les
cinquièmes journées sur l'ingénierie des interfaces Homme-Machine [Belik, 1995]. Elles ont été par
la suite présentées de manière plus formelle dans [Coutaz et al., 1994] sous le nom de propriétés
CARE (Complémentarité, Assignation, Redondance, Equivalence) et étendu dans [Martin, 1999]
sous le nom de propriétés TYCOON (TYpes and goals of COOperatioN).
I.2.3.A Propriétés CARE
Les propriétés CARE (Complémentarité, Assignation, Redondance, Équivalence) [Coutaz et al.,
1994] permettent de décrire la façon dont les modalités sont utilisées dans un système multimodal.
Elles introduisent une caractérisation des relations qu'entretiennent entre elles les modalités. Notons
que dans les propriétés CARE, une modalité est définie comme un couple <langage d'interaction,
dispositif physique> [Jacquet, 2006].
Complémentarité :
La complémentarité entre deux modalités d'interaction implique leur utilisation simultanée pour
réaliser une tâche donnée. L'exemple le plus connu est celui de Bolt où l'utilisateur utilise la voix en
prononçant « Mets ça ici » et les gestes en indiçant l'objet à déplacer et la nouvelle position (Figure
1). L'interprétation de la phrase prononcée permet de comprendre la commande, mais ne permet pas
de connaitre l'objet et la nouvelle position. De même, l'interprétation des gestes permet de connaitre
l'objet et sa nouvelle position mais pas la commande spécifier pas l'utilisateur. Il faut alors utiliser
simultanément les deux modalités et fusionner les données provenant d'elles pour pouvoir effectuer
la commande.
15
Figure 1 : «Put that there » de Bolt
Assignation (spécialisation) :
On dit qu'une modalité est assignée à une tâche donnée si cette dernière ne peut être effectuée qu'à
l'aide de cette modalité. Par exemple, on peut affecter le tactile pour entrer les données dans une
application mobile (smartphone). Ainsi, une donnée transmise à travers une modalité assignée ne
sera pas candidate à une fusion par la suite [Belik, 1995].
Équivalence :
Deux modalités sont dites équivalentes s'il est possible d'effectuer une tâche donnée indifféremment
au moyen de l'une quelconque de ces deux modalités. Par exemple, l'utilisateur peut avoir le choix
en entrée d'utiliser le tactile ou la voix pour exprimer une commande. Formellement, l'équivalence
d'un ensemble de modalités d'interaction est vérifiée si chaque dispositif ou langage d'interaction
permet d'atteindre le même but en produisant les mêmes données.
Redondance :
Deux modalités sont dites redondantes si elles sont équivalentes (la redondance est un sous-cas de
l'équivalence), et si elles peuvent être utilisées simultanément ou successivement pour l'expression
d'une tâche donnée [Jacquet, 2006]. En entrée, la redondance d'information en provenance de
l'utilisateur implique la prise en compte d'une seule des modalités d'interaction par le système,
l'autre pouvant éventuellement contribuer à fiabiliser l'expression obtenue. Par exemple, le montage
redondant d'un microphone et d'une caméra qui observe le mouvement des lèvres d'un utilisateur
16
permet d'augmenter la robustesse d'un système de reconnaissance vocale [Bouchet, 2006]. La
redondance est beaucoup plus utilisée en sortie, par exemple un système peut afficher un texte et le
lire avec une synthèse vocale.
Les propriétés CARE autorisent la modélisation de la coopération des modalités et leurs analyses
permettent de classer et surtout d'évaluer les systèmes multimodaux, du point de vue système (SCARE, "System CARE") et du point de vue utilisateur (U-CARE, "User CARE").
I.2.3.B Propriétés TYCOON
Six types de primitives de coopération entre les modalités ont été proposés dans TYCOON :
l'équivalence, le transfert, la spécialisation, la redondance, la complémentarité et la concurrence.
Équivalence :
Deux modalités M1 et M2 coopèrent par équivalence pour un ensemble I (un ensemble de blocs
d'information) quand toute information i de I peut être traitée, soit par M1, soit par M2.
Transfert :
Deux modalités M1 et M2 coopèrent par transfert quand une information produite par M1 peut être
utilisée par M2 après traduction.
Spécialisation :
Une modalité M coopère par spécialisation dans la production d'un ensemble d'informations I s'il y
a une relation bi-univoque entre I et M : M est la seule modalité à produire I, I le seul ensemble
d'information produit par M [Martin, 1997].
Redondance :
Plusieurs modalités coopèrent par redondance si la même information est traité par ces modalités
(transmet la même information mais sous une autre forme).
Complémentarité :
17
Lorsque deux modalités M1 et M2 coopèrent par complémentarité, cela signifie que les morceaux
d'informations produits par ces deux modalités doivent être fusionnées.
Concurrence :
Quand plusieurs modalités coopérent en concurrence, cela signifie que les morceaux différents
d'informations sont traitées par plusieurs modalités dans le même temps, mais ne doivent pas être
fusionnés [Martin, 1997].
Les propriétés CARE et TYCOON approfondissent les relations d'usage des modalités d'interaction
au sein d'un système multimodal donné. Tout d'abord, l'usage combiné est défini par les propriétés
de complémentarité et de redondance. L'existence de choix est incarnée par la propriété
d'équivalence, alors que l'absence de choix est définie par l'assignation (CARE) ou la spécialisation
(TYCOON). TYCOON ajoute en plus les propriétés de transfert et de concurrence.
I.2.4 Fusion et fission des données multimodales
Dans cette section nous donnons les définitions des deux processus de la multimodalité nommées la
fusion et la fission.
Fusion
La fusion est la combinaison de plusieurs unités d'information pour former de nouvelles unités
[Nigay, 1994]. L'objectif principal de ce processus est d'extraire le sens d'un ensemble de modalités
en entrée et de le transmettre au contrôleur du dialogue de l'application comme une commande
interprétable. Par exemple, le paradigme du “mets ça ici” nécessite la fusion de l'événement parole
reçue via le microphone avec les événements gestuels via la caméra.
La fusion peut se faire à trois niveaux différents : niveau donné (directement sur le flux d'entrée),
niveau fonctionnalité (les caractéristiques extraites des données) et niveau décision. La fusion au
niveau décision est la plus utilisée, car elle s'effectue après la récupération des informations à partir
des entrées ce qui lui permet d'être plus sécurisée par rapport aux deux autres qui ont souvent le
problème de gestion du bruit (même si les deux premiers n'ont pas le problème de perte de données
comme le niveau décision).
Dans la littérature on trouve un nombre important d'algorithmes de fusion (niveau décision), mais il
n'existe pas encore un algorithme conventionnel qui permet de simplifier la tâche de développement
de ce processus.
18
Fission
La fission correspond au processus inverse de la fusion. Son objectif est de présenter les
informations en sortie à travers plusieurs modalités d'interaction. Par exemple, le système fissionne
un message en le présentant comme texte sur l'écran et en synthèse vocale avec les haut-parleurs.
Elle peut aussi avoir d'autres formes telles que l'affichage sous différents langages (texte, image,
graphe, etc) par exemple.
Selon Foster [Foster, 2002], le processus de fission est constitué de 3 étapes :
•
Sélection du contenu et la structuration des données : dans cette étape le système identifie
les données en sortie et les structures selon la présentation (les données focus, background,
etc)
•
Sélection des modalités d'interaction : après la structuration des données, le système choisit
les modalités d'interaction adéquate en se basant sur des bases de connaissances ou des
règles prédéfinies.
•
La coordination des sorties : finalement, le système coordonne les sorties afin de donner des
messages cohérents à l'utilisateur.
On remarque qu'au contraire de la multimodalité en entrée, en sortie c'est le système qui prend en
charge les choix des modalités d'interaction et la coordination des données ce qui rend la tâche
beaucoup plus difficile pour les développeurs. En plus, les trois étapes précédentes sont
généralement réalisées en ad hoc, ce qui nous explique pourquoi la multimodalité en entrée est
beaucoup plus étudiée que celle en sortie.
I.2.5 Difficultés de conception et de développement des applications
multimodales
Malgré le développement d'applications multimodales dans de multiples domaines, la conception et
le développement d'interfaces multimodales reste une tâche difficile et longue.
Parmi les principales difficultés rencontrées dans le processus de développement d'un système
interactif multimodal, nous avons :
- Nombreuses modalités :
Les interfaces multimodales font intervenir de multiples techniques d'interaction combinant le plus
souvent de façon synergique des modalités actives (parole, geste) et des modalités passives
19
(orientation et position de l'utilisateur). Cette multiplicité accroît significativement les difficultés de
conception et de développement des applications multimodales et les méthodes d'ingénierie n'étant
pas arrivées à maturité, le processus de développement est particulier à chaque réalisation. Pour
chaque système interactif multimodal, le cycle de développement est long et le niveau d'expertise
demandé est élevé et rare, entraînant une augmentation irrémédiable des coûts par rapport au
développement de systèmes interactifs classiques [Bouchet, 2006].
- Manque des méthodes et outils :
Les méthodes et outils existants pour la conception et le développement d'interfaces multimodales
sont limitées et souvent conçus pour un ensemble particulier de modalités d'interaction comme la
parole et le geste [Serrano, 2008] ou s'adressent à des problèmes techniques spécifiques tels que le
mécanisme de combinaison de différentes modalités d'interaction (comme les approches [Belik,
1995] et [Nigay, 1994]).
- Absence de réutilisabilité :
L'absence d'un modèle d'ingénierie a amené les développeurs des applications multimodales à
réaliser des développements ad hoc, souvent sans documentation. Donc l'évolution de ces
applications, comme par exemple l'ajout d'une nouvelle modalité à l'existant semble relever de
l’impossible. De plus, la plupart des avancées conceptuelles et matérielles concernant les modalités
remettent en cause les produits existants. Par exemple, lorsqu'il y a une évolution des techniques de
programmation, la réutilisation de l'existant est très difficile à maîtriser et n'est souvent pas
compatible avec les nouvelles modalités à mettre en œuvre. Au vue de ces constats, les entreprises
effectuent de nouveaux développements complets [Bouchet, 2006].
Différent utilisateurs :
Pour créer un système multimodal utilisable multimodalement par ses utilisateurs finaux il faut
commencer par étudier ces utilisateurs afin de leur donner un système proche de leur mode
d'interaction. Cela rend le processus de conception et de développement beaucoup plus compliqué
car il nécessite des connaissances psychologiques ainsi que des tests d'évaluation et beaucoup de
rapprochement des utilisateurs finaux.
La difficulté de la tâche de conception et de développement est particulièrement vrai dans le cas de
l'informatique mobile [Serrano, 2008] présenté ci-dessous.
20
I.3 L'informatique mobile
Les récentes avancées technologiques dans le domaine des terminaux portables et dans celui des
réseaux sans-fil ont conduit à une forte évolution de l'informatique mobile [Le Mouël, 2003]. Cette
évolution a commencé d'abord par l'arrivée des ordinateurs portables puis plus récemment les
téléphones cellulaires et les smartphones avec toutes leurs fonctionnalités embarquées (agenda,
calendrier, navigation sur le web, GPS, consultation des emails, de messagerie instantanée, etc).
Les applications en informatique mobile, souvent appelées aussi applications pervasives ou
ubiquitaires, sont multiples. Elles peuvent être des applications personnelles avec lesquelles les
utilisateurs peuvent accéder à tout moment à des informations publiques (trafic routier, cours de la
bourse, météo, etc) ou privées (bookmarks, données bancaires, agenda, dossier médical, etc). Elles
peuvent également rendre des services aux utilisateurs (Shazam, Siri, Convertisseur, etc) ou être des
applications professionnelles pour des entreprises particulières.
I.3.1 Classification des systèmes mobiles
Malgré la grande variété des systèmes mobiles, ils peuvent être classifiés selon [26] comme suit :
•
Client mobile – serveur fixe : ce type d'application ressemble aux applications clientserveur traditionnelles mais dans ce cas là les utilisateurs sont mobiles. Il peut par exemple
s'agir d'applications personnelles dans lesquelles un utilisateur fait appel aux services d'un
hébergeur de données. Il rentre dans cette classe surtout des applications effectuant de la
dissémination d'information à destination d'un large public d'utilisateurs mobiles (diffusion
d'informations météo, trafic routier, cours de la bourse …). Ces applications présentent
l'avantage de ne pas encombrer le dispositif mobile par leurs données par contre elles ne
marchent pas s'il y a des problèmes de connexion.
•
Client mobile – serveur mobile : cette classe couvre les applications dans lesquelles client,
serveur et données sont tous embarqués dans un calculateur mobile. Les dossiers portables
de différentes natures sont des exemples typiques de cette classe d'application. Ce type
d'application ne dépend pas de la connexion comme le premier type, mais il peut facilement
occuper beaucoup d'espaces.
•
Client fixe – serveur mobile : on peut ranger dans cette classe des applications où des
capteurs attachés à des mobiles diffusent des informations sur leur état à destination d'une
21
unité de traitement fixe et reçoivent éventuellement des commandes émanant de cette unité
(ex : contrôle à distance d'un véhicule).
•
Données mobiles dans un serveur fixe : par abus de langage, nous utilisons ici le terme
« données mobiles » pour caractériser des applications dans lesquelles les données gérées
correspondent à la localisation de mobiles (localisation de téléphones, la gestion de flottes
de véhicules, le suivi de la migration d'animaux bagués, etc).
I.3.2 Intérêts et limites des systèmes mobiles
Comme tout type d'application, les systèmes mobiles possèdent des avantages et des inconvénients
relatives à leurs conceptions, développement et utilisation. Le plus grand avantage de ces
applications est leurs mobilités qui leurs permet d'être manipulé dans n'importe quel endroit et à tout
moment. En plus, elles sont beaucoup plus rapides que les applications traditionnelles (sauf si elles
sont mal programmées) et en utilisant les composants graphiques du téléphone (boutons, barre de
titre, onglets…), leurs interfaces sont plus faciles à appréhender pour l'utilisateur. Enfin, elles
offrent plus de possibilités telles que la réalité augmentée, réaction aux mouvements du téléphone
(accéléromètre, boussole, etc), lire un code barre ou qrcode et autant de fonctionnalités qui ne sont
possibles qu'avec une application mobile.
En revanche, ces applications possèdent aussi des limites et des inconvénients relatives surtout aux
dispositifs mobiles utilisés :
✗
L'utilisation des ressources mobiles est limitée dans le temps puisqu'elle dépend d'une
source d'énergie limitée, la batterie.
✗
Une faible capacité des terminaux mobiles en terme d'affichage et de puissance de
traitement et de stockage.
✗
Il faut développer les applications mobiles pour chaque plateforme (iPhone, Android,
Blackberry, Windows Mobile, Symbian, Palm OS). Cependant, décliner une application
vers une nouvelle plateforme coûte moins cher, car une bonne partie de l'application (la
logique métier) peut être réutilisée.
✗
Le déploiement des applications est un peu compliqué et long. Apple par exemple impose
une validation des applications avant publication (environ 8 jours). Par contre, sur Android
Market il n'y a pas ce problème.
22
I.3.3 Plateformes mobiles : Android & iPhone
Ci-dessous nous présentons les deux plateformes mobiles les plus utilisées et qui ont des
pourcentages importants de parts de marché ces deux dernières années (la prévision de vente pour
2012 est de plus de 150 millions d'exemplaires des smartphones Android et iPhone).
I.3.3.A Android : la plateforme open source mobile
Le système Android connaît depuis un certain temps un succès croissant auprès des développeurs
d'applications embarquées de type smartphone, ordiphones, tablettes, téléviseurs connectes, etc.
Dans cette section nous allons présenter ce système open source et définir son architecture.
I.3.3.A.a Historique et définition
Le système Android a été développé par la société californienne Android en 2003. Mais la sortie
officielle du système n'a eu lieu qu'en 2007 par Google qui a racheté cette société en 2005. C'est le
premier système d'exploitation mobile open source qui était créée pour permettre aux développeurs
de bénéficier au maximum de tout ce que peut offrir un appareil mobile. Il est devenu totalement
open-source en octobre 2008 et est diffusée sous licence Apache. Cela a permis une utilisation
commerciale facilitée puisque les constructeurs peuvent rajouter des composants à Android sans les
soumettre aux développeurs open-source. La factorisation des compétences et l'ouverture du code a
permis également de réduire les coûts de production, de laisser les développeurs externes améliorer
ou corriger le code et de permettre à tout un chacun de modifier le système à sa guise [Mottier,
2009] . Le terme Android est d'origine grec qui désigne ce qui est de forme humaine ou
étymologiquement ce « qui ressemble à un homme ».
I.3.3.A.b L'architecture Android
Google a donné le nom Android à la pile applicative spécialement optimisée pour les appareils
mobiles. Cette pile applicative n'est pas seulement composée d'applications et d'un framework de
développement, c'est un ensemble de technologies allant du niveau machine (système
d'exploitation) au niveau utilisateur (applications) [Mottier, 2009] .
23
Figure 2 : La pile applicative Android
Nous présentons maintenant les différentes couches de la pile applicative indiquées dans la figure 2.
 Applications
Android est fourni avec un ensemble de programmes de base (aussi appelés applications natives)
permettant d'accéder à des fonctionnalités particulières telles que les courriels, les SMS, le
calendrier (synchronise avec Google Calendar), les photos, les cartes géographiques (issue de
Google Maps), le web, etc. Ces applications sont développées à l'aide du langage de programmation
Java. Pour les utilisateurs, cette couche est la seule accessible et visible [Mottier, 2009] . Google
précise que ces applications peuvent aussi être supprimées ou modifiées par les utilisateurs finaux,
même l'application Home (l'explorer sous windows) peut être modifiée.
 Le framework
Android permet aux développeurs de créer leurs propres applications. Ainsi, les programmeurs
peuvent accéder aux mêmes APIs que celles utilisées par les applications natives d'Android. C'est
24
donc à ce niveau là où ils peuvent intervenir pour développer leurs propres applications.
 Les bibliothèques
Android inclut des bibliothèques C et C++ utilisées par plusieurs composants de la plateforme
Android. Elles sont très répondues dans le monde informatique et couvrent la majorité des besoins
des développeurs qui peuvent y accéder par l'intermédiaire du framework. Parmi ces bibliothèques
on note : SQLite, libc, codecs multimédia, navigateur internet, moteur graphique 2D, Open GL ES,
rendu de polices de caractères, etc.
 Le moteur d'exécution Android
Chaque application Android tourne dans son propre processus et avec sa propre instance de machine
virtuelle (VM) Dalvik. Dalvik VM est conçue pour optimiser l'exécution multiple de machines
virtuelles. Elle repose sur le noyau Linux qui s'occupe des fonctions telles que les threads ou la
gestion bas-niveau de la mémoire [Mottier, 2009] .
 Noyau Linux
Android repose sur un noyau Linux qui gère les services système comme la sécurité, la gestion
mémoire, la gestion des processus, la pile réseau et les pilotes. Il agit également comme une couche
d'abstraction entre le matériel et la pile logicielle [Mottier, 2009] .
I.3.3.A.c Développement sous Android
Le développement sous Android s'effectue majoritairement en langage Java, ce qui contribue à la
popularité de la plateforme auprès des développeurs. Un Software development kit (SDK) est fourni
gratuitement par Google pour les trois systèmes d'exploitation majeurs (Windows, Mac OS X et
Linux). Ce SDK peut s'intégrer à Eclipse ou fonctionner en ligne de commande. Il dispose aussi
d'un émulateur (basé sur QEmu) ainsi que d'outils de mise au point puissants (comme DDMS).
Après compilation, l'utilitaire DX (fourni dans le SDK) permet de convertir le bytecode Java en
bytecode Dalvik. L'opération inverse n'est pas possible avec les outils du SDK officiel.
L'application installable sur le téléphone est empaquetée dans un fichier APK, qui inclut le bytecode
de l'application elle-même (fichier CLASSES.DEX), le manifeste d'application, ses ressources et les
signatures numériques. Le concept est identique à celui des fichiers JAR, les fichiers APK sont
d'ailleurs eux-mêmes des archives ZIP.
25
I.3.3.B iPhone
Le iPhone est devenu un accessoire à la mode mais c'est un téléphone qui, technologiquement, est
assez proche de ses concurrents.
I.3.3.B.a Historique et définition
L'iPhone, dont le premier modèle est sorti en 2007 par Steve Jobs, est le smartphone vendu par
Apple qui a rencontré un succès incontestable. L'un des points forts de cette plateforme réside dans
le nombre d'applications disponibles qui s'élève à environ 250000 avec 15000 nouvelles
applications proposées chaque semaine.
La première version de l'iPhone (et son système d'exploitation iOS (iPhone OS)) a été rendue
disponible au Royaume-Uni, en France et en Allemagne et en Irlande et en Autriche au printemps
2008. Le 11 juillet 2008, Apple a lancé l'iPhone 3G dans vingt-deux pays et depuis l'iPhone 3G est
commercialisé dans plus de quatre-vingts pays et territoires (avec un prix très élevé).
I.3.3.B.b iPhone SDK
Le SDK fourni par Apple pour le développement d'applications sur iPhone est particulièrement
complet. Il fournit l'ensemble des logiciels nécessaires au développeur pour créer des interfaces
graphiques, lire des fichiers multimédias, gérer des affichages tridimensionnels, ainsi que de lier
l'application avec d'autres applications (Safari, Mail, Maps, etc.) sans nécessiter l'inclusion du
moindre framework tiers.
Le développement s'effectue sur la base du langage Objective C avec l'IDE XCode (fourni avec
l'OS Snow Leopard) et avec l'Interface Builder.
 XCode
XCode est l'IDE d'Apple et constitue l'unique environnement de développement officiel pour le
développement sur iPhone. Il propose un éditeur de texte, le compilateur GCC, une interface à SVN
et de nombreuses autres fonctionnalités. Il est relativement facile à prendre en main pour débuter la
programmation sur iPhone, mais nécessite tout de même un certain temps pour maîtriser l'ensemble
de ses fonctionnalités avancées.
 Interface Builder
Interface Builder est un constructeur visuel d'interface graphique. Il offre la possibilité de créer
26
facilement des interfaces utilisateurs simples.
La situation d'utilisation actuelle donne encore l'avantage à l'iPhone. Mais le système d'exploitation
de Google (Android) a détrôné l'iPhone en matière d'activation de nouveaux terminaux, ce qui veut
dire que cette situation pourrait ne pas durer.
I.4 Conclusion
En résumé, nous avons présenté dans ce chapitre le paradigme multimodale dans le but de bien
identifier ses spécificités et de voir son aspect innovant. En revanche, la présentation de
l'informatique mobile nous a permis d'identifier ses avantages, limites et ses différentes
technologies. Ainsi, d'un côté nous pouvons voir que l'informatique mobile soutient vivement la
multimodalité (différents capteurs embarqués dans les smartphones : accéléromètre, boussole,
capteur de lumière....) et de l'autre côté la multimodalité offre un moyen puissant pour surmonter les
limites des systèmes et dispositifs mobiles (petit écran, petite résolution...). Un pont peut être alors
jeté entre la multimodalité et l'informatique mobile.
27
Chapitre II :
La modélisation
28
II La modélisation
II.1 Introduction
La modélisation de l'interaction homme-machine a donné lieu à une littérature riche et très diverse
[Verdurand et al., 2009]. Dans ce chapitre nous allons présenter les différentes modélisations des
applications informatiques et de l'interaction Homme-Machine définie dans la littérature comme
solution des problèmes de conception et de développement des systèmes interactifs.
II.2 La modélisation des applications informatiques
II.2.1 Modèle et modélisation
En informatique, la modélisation était initialement utilisée à des fins de communication entre les
concepteurs de systèmes et les parties prenantes [Dupuy-chessa, 2011]. De nos jours, l'industrie
tend à utiliser de plus en plus les modèles pour des tâches non contemplatives telles que la
simulation, la génération de cas de tests ou de parties de code.
II.2.1.A Modèle
II.2.1.A.a Définition
Il n'existe pas de définition universelle de ce qu'est un modèle. Dans [Kleppe et al., 2003] il est
défini comme suit : "un modèle est une description (d'une partie) d'un système écrit dans un langage
bien formé. Un langage bien formé est un langage avec une forme bien définie (syntaxe), un sens
(sémantique), qui convient pour une interprétation automatique par un ordinateur". Minsky le défini
par "pour un observateur B, M est un modèle de l'objet O, si M aide B à répondre aux questions
qu'il se pose sur O".
On trouve beaucoup d'autres définitions dans la littérature, mais la définition qui nous semble plus
adéquate est la suivante : "un modèle est une représentation abstraite d'un système, problème ou
situation pour un but donné et suivant un point de vue particulier".
II.2.1.A.b Qualité des modèles
Pour la caractérisation d'un bon modèle aussi il n'y a pas un consensus. Mais l'approche dite «
sémiotique » représente une approche très répondue qui s'appuie sur l'étude des signes et de leurs
29
significations pour structurer la qualité du modèle [Dupuy-chessa, 2011]. Elle a été initiée par
Lindland dans [Lindland et al., 1994] pour évaluer la qualité de n'importe quel type de modèle.
Lindland détaille la qualité en 3 aspects :
•
Syntaxique : la qualité syntaxique vérifie dans quelles mesures un modèle correspond aux
constructions de son langage sans considérer le sens. Son but est d'obtenir la correction
syntaxique.
•
Sémantique : elle indique le lien d'un modèle avec son domaine ou les connaissances des
spécialistes du domaine. Ses objectifs sont la validité et la complétude. La validité signifie
que toutes les assertions du modèle sont correctes et pertinentes pour le problème. La
complétude signifie que le modèle contient toutes les assertions correctes et pertinentes du
domaine.
•
Pragmatique : la qualité pragmatique est liée à l'interprétation du modèle de l'audience.
Son but est la compréhension.
Ce référentiel a été validé par une étude empirique de Moody en 2003 [Moody et al., 2003] et a
donné lieu à de nombreux travaux complémentaires.
II.2.1.B Modélisation
II.2.1.B.a Définition
La modélisation, suivant wikipedia [Wikipedia, 2011], est la conception d'un modèle. C'est alors
tout simplement la tâche qui permet d'obtenir un modèle suivant une notation particulière (un
langage).
Dans notre vie courante nous modélisons tout le temps. À chacun des êtres qui nous entourent, qu'il
s'agisse d'objets matériels, de personnes ou d'institutions, nous associons une image mentale qui
nous permet d'anticiper son comportement. Nous faisons des simulations pour évaluer les
conséquences de nos décisions et choisir parmi les décisions possibles, en tenant compte des
incertitudes. Lorsque nos modèles nous semblent faux ou trop grossiers, nous les modifions.
Cette démarche, intuitive et rapide dans la vie personnelle, n'est explicitée que lorsque l'on réalise
un travail professionnel ou scientifique. Alors, le vocabulaire devient technique, « abstrait » et
éloigné du langage courant. Cette technicité rend la modélisation (sous sa forme explicite) difficile
à comprendre pour certaines personnes.
30
II.2.1.B.b Pourquoi modéliser?
Le recours à la modélisation pour le développement logiciel est devenu indispensable depuis
longtemps, car un modèle est prévu pour arriver à anticiper les résultats du codage [Roques, 2007].
Le modèle représente un outil d'abstraction pour facilité l'étude des systèmes, leurs documentations
ainsi que la communication entre les différents intervenants au sein du projet. Chaque membre de
l'équipe, depuis l'utilisateur jusqu'au développeur utilise et enrichit le modèle différemment. En
outre, les systèmes devenant de plus en plus complexes, leur compréhension et leur maîtrise globale
dépassent les capacités d'un seul individu. La construction d'un modèle abstrait aide à y remédier.
Associé au processus de développement, un modèle représente l'ensemble des vues sur une
expression de besoins ou sur une solution technique. Pris à un niveau de détail pertinent, il décrit ou
conçoit la cible de l'étape en cours. Le modèle peut donc avoir des objectifs différents suivant
l'activité de développement et sera construit avec des points de vue de plus en plus détaillés :
•
Dans les activités de spécification des exigences, il convient premièrement de considérer le
système comme une boîte noire à part entière afin d'étudier sa place dans le système métier
plus global qui est l'entreprise. On développe pour cela un modèle de niveau contexte, afin
de tracer précisément les frontières fonctionnelles du système [Roques, 2007].
•
Dans les activités d'analyse, le modèle commence à représenter le système vu de l'intérieur.
Il se compose d'objets représentant une abstraction des concepts manipulés par les
utilisateurs. Le modèle comprend par ailleurs deux points de vue, la structure statique et le
comportement dynamique. Il s'agit de deux perspectives différentes qui aident à compléter la
compréhension du système à développer.
•
Dans les activités de conception, le modèle correspond aux concepts informatiques qui sont
utilisés par les outils, les langages ou les plates-formes de développement. Le modèle sert ici
à étudier, documenter, communiquer et anticiper une solution. Il est en effet toujours plus
rentable de découvrir une erreur de conception sur un modèle, que de la découvrir au bout
de milliers de lignes codées sans méthode. Pour la conception du déploiement enfin, le
modèle représente également les matériels et les logiciels à interconnecter.
Aujourd'hui, le standard industriel de modélisation est UML. Il est sous l'entière responsabilité de
l'OMG (Object Management Group) pour la modélisation objet (conceptions orientés objet).
31
II.2.1.B.c L'ingénierie dirigée par les modèles (IDM)
Si les modèles servent donc à représenter les besoins, documenter les systèmes, concevoir ces
systèmes,... les modèles ne sont pas que de la documentation ou de beaux dessins. Les outils actuels
savent maintenant exploiter ces modèles pour faire de la génération de code voir des allers-retours
entre le code et le modèle sans perte d'information.
L'Ingénierie dirigée par les modèles (IDM) est le domaine de l'informatique mettant à disposition
des outils, concepts et langages pour créer, transformer et générer du code à partir des modèles. La
génération n'est pas toujours parfaite, mais les outils de modélisation permettent quand même de
nous aider à générer la partie fastidieuse de ce code et de nous laisser concentrer sur les algorithmes
et sur une analyse haut niveau du problème.
Dans le contexte de l'IDM, la notion de transformation de modèle joue un rôle fondamental; aussi
de nombreux outils, tant commerciaux que dans le monde de l'open source sont aujourd'hui
disponibles pour faire la transformation de modèles. On peut grossièrement distinguer quatre
catégories d'outils :
•
Les outils de transformation générique qui peuvent être utilisées pour faire de la
transformation de modèles.
•
Les facilités de type langages de scripts intégrés à la plupart des ateliers de génie logiciel.
•
Les outils conçus spécifiquement pour faire de la transformation de modèles et prévus pour
être plus ou moins intégrables dans les environnements de développement standards.
•
Les outils de méta-modélisation (c'est l'entité concrétisant un contexte de modélisation pour
la conception et la manipulation de modèles) dans lesquels la transformation de modèles
revient à l'exécution d'un méta-programme.
Même s'il existe une longue expérience de l'utilisation de l'ingénierie des modèles dans certains
domaines, sa généralisation n'en est qu'à ses débuts. Visant à automatiser une partie du processus du
développement, elle requiert un effort d'abstraction plus important de la part des développeurs. En
contrepartie, elle permet de conserver le savoir faire de conception proche des centres de décision,
grâce aux économies d'échelle dues à l'automatisation.
II.2.2 UML, un langage de modélisation
L'intérêt donné à la modélisation des applications informatiques a permis l'apparition de plusieurs
langages de modélisation, c'est-à-dire des conventions d'écriture et de représentation formelle des
32
modèles. UML (Unified Modeling Language, que l'on peut traduire par "langage de modélisation
unifiée") représente un des langages les plus répondu qui est devenu désormais la référence en
terme de modélisation objet.
II.2.2.A La notion d'objet
La programmation orientée objet consiste à modéliser informatiquement un ensemble d'éléments
d'une partie du monde réel (que l'on appelle domaine) en un ensemble d'entités informatiques. Ces
entités informatiques sont appelées objets. Il s'agit de données informatiques regroupant les
principales caractéristiques des éléments du monde réel (taille, la couleur, ...).
On appelle classe la structure d'un objet, c'est-à-dire la déclaration de l'ensemble des entités qui
composeront un objet. Les objets de même nature ont en général la même structure et le même
comportement. La classe factorise les caractéristiques communes de ces objets et permet de les
classifier. Un objet est donc, une instanciation d'une classe (figure 3), c'est la raison pour laquelle on
pourra parler indifféremment d'objet ou d'instance (éventuellement d'occurrence).
La difficulté de cette modélisation consiste à créer une représentation abstraite, sous forme d'objets,
d'entités ayant une existence matérielle (chien, voiture, ampoule, ...) ou bien virtuelle (sécurité
sociale, temps, ...). En revanche, l'approche offre beaucoup d'avantages et de nouveaux concepts qui
permettent de simplifier la modélisation et l'implémentation par la suite tels que la modularité, la
réutilisabilité, l'extensibilité, l'héritage, etc.
Figure 3 : L'instanciation d'une classe en deux objets
33
II.2.2.B Contenu d'UML
UML comporte 12 diagrammes standards représentant autant de « vues » d'un système
d'information. Ces diagrammes se répartissent en trois catégories : quatre représentent la structure
statique de l'application (diagrammes de classe, d'objet, de composant et de déploiement) ; cinq
représentent son comportement dynamique (diagrammes de cas d'utilisation, de séquence, d'activité,
de collaboration et d'état) ; trois représentent la façon dont on peut organiser et gérer les modules
qui composent le programme (diagrammes de packages, sous-systèmes et modèles).
Ces diagrammes sont d'une utilité variable selon les cas et ils ne sont pas tous nécessairement
produits à l'occasion de la modélisation. Les plus utiles pour la maîtrise d'ouvrage sont les
diagrammes d'activité, de cas d'utilisation, de classe, d'objet, de séquence et d'état. Les diagrammes
de composants, de déploiement et de collaboration sont surtout utiles pour la maîtrise d'œuvre à qui
ils permettent de formaliser les contraintes techniques de la réalisation et la solution technique
retenue.
•
Diagramme d'activité
Représente le déclenchement d'événements en fonction des états du système. Il permet de
représenter graphiquement le comportement d'une méthode ou le déroulement d'un cas d'utilisation.
•
Diagramme de cas d'utilisation
Décrit la succession des opérations réalisées par un acteur (personne qui assure l'exécution d'une
activité). C'est le diagramme principal du modèle UML, celui où s'assure la relation entre
l'utilisateur et les objets que le système met en oeuvre.
•
Diagramme de classe
Représente l'architecture conceptuelle de l'application : il décrit les classes que l'application utilise,
ainsi que leurs liens, que ceux-ci représentent un emboîtage conceptuel (héritage), une relation
organique (agrégation) ou une simple association.
•
Diagramme d'objet
Permet d'éclairer un diagramme de classe en l'illustrant par des exemples.
•
Diagramme de séquence
Représente la succession chronologique des opérations réalisées par un acteur : saisir une donnée,
consulter une donnée, lancer un traitement ; il indique les objets que l'acteur va manipuler, et les
opérations qui font passer d'un objet à l'autre. On peut représenter les mêmes opérations par un
34
diagramme de collaboration parce que le diagramme de séquence et le diagramme de collaboration
sont deux vues différentes, mais logiquement équivalentes (on peut construire l'une à partir de
l'autre), d'une même chronologie.
•
Diagramme d'état
Représente la façon dont évoluent ("cycle de vie") durant le processus les objets appartenant à une
même classe. La modélisation du cycle de vie est essentielle pour représenter et mettre en forme la
dynamique du système.
II.3 La modélisation en IHM
En interaction homme-machine (IHM), l'activité de modélisation d'un système interactif a pour but
de produire une description du système interactif en rapport avec les besoins de l'utilisateur [AïtAmeur et al., 2005]. Cette modélisation se démarque de la modélisation en génie logiciel classique
du fait que les interactions décrites dans les modèles d'interaction se concentrent sur les relations
entre l'utilisateur et le système interactif. En effet, de manière générale, les modèles de cycle de vie
du génie logiciel classique ont principalement pour objectifs : la faisabilité associée à la difficulté et
au travail nécessaire pour produire un logiciel et la qualité du logiciel qui est souvent liée à la
correction, la consistance, la sûreté, la maintenance, etc. Alors que la modélisation en IHM
s'intéresse à l'aspect, au comportement et aux effets de bord du système interactif et non pas à son
fonctionnement interne. Ainsi, le résultat de cette activité de modélisation est un modèle décrivant
précisément les interactions attendues de l'utilisateur avec le système interactif. Elle ne requiert pas
nécessairement la présence de détails relatifs à son implantation ou à sa réalisation [Aït-Ameur et
al., 2005].
II.3.1 Les besoins de modélisation en IHM
La nécessité de réaliser l'interface d'une application avec la même rigueur que celle accordée à
l'application elle-même est primordiale dans les systèmes critiques en particulier, pour des raisons
de sécurité et dans les applications informatiques en général pour des raisons de coût et
d'utilisabilité puisque les utilisateurs finaux jugent généralement les applications selon leur
interfaces et non pas leur fonctionnement interne [Aït-Ameur et al., 2005].
L'interface doit être alors :
➢ Compréhensible.
35
➢ Facilement utilisable.
➢ Refléter exactement et fidèlement le comportement de l'application [Aït-Ameur et al., 2005].
➢ Accessible au plus grand nombre d'utilisateurs ayant des comportements différents.
➢ Facilement corrigée en cas d'erreur d'interaction.
Ainsi pour concevoir une interface il faut non seulement faire intervenir les informaticiens pour la
conception et le développement, mais aussi les ergonomes pour les choix d'ergonomie et de
disposition ou de spécifications externes et des psychologues pour capturer les comportements des
utilisateurs.
Notons que l'insertion de l'ergonomie et de la psychologie dans le processus de réalisation des IHM
permet la prise en compte des besoins et des comportements des utilisateurs, ce qui augmente
significativement l'utilité et l'utilisabilité des interfaces et donc les applications derrières.
II.3.2 Les modèles en IHM
De nombreux travaux dans le domaine de l'IHM ont adopté une approche basée sur les modèles
[Dupuy-chessa, 2011]. Ce qui a permis à ce domaine de voir naître de nombreux modèles et
notations semi-formels ou graphiques pour concevoir les interfaces Homme Machine. Ces modèles
ont été conçus pour être utilisés, en particulier par des non-informaticiens issus des communautés
citées précédemment (informaticiens, ergonomes, psychologues etc.) et ils ont suivi les différentes
évolutions matérielles et logicielles de ces dernières années.
Dans cette section nous présentons les deux classes (catégories) de ces modèles :
•
Modèles d'architecture : décrivent l'organisation logicielle du système interactif.
•
Modèles d'interaction : décrivent les différents mécanismes mis en œuvre pour réaliser le
dialogue entre l'utilisateur et le système.
II.3.2.A Modèles d'architecture
Les modèles d'architecture définissent l'organisation logicielle d'un système interactif. Le principe
de base de tous ces modèles est la séparation entre le noyau fonctionnel qui implémente les
concepts propres à un domaine d'application particulier et l'interface qui présente ces concepts à
l'utilisateur et qui lui permet de les manipuler. Ce principe doit permettre en théorie de modifier
l'interface sans affecter le noyau fonctionnel et inversement, mais en réalité cela est difficile à
concrétiser pour la totalité de l'interface. En pratique et dans la majorité des cas, seule une partie de
36
l'interface est réellement séparée du noyau fonctionnel [Belik, 1995].
Un modèle d'architecture permet de structurer un système interactif et ainsi de disposer d'une
meilleure modularité. Cette modularité est primordiale car elle facilite la réutilisation logicielle des
composants du système interactif, sa maintenance et son évolution.
Depuis les années 1970, différents modèles de ce type ont été proposés. On peut les classer en deux
catégories : Modèles linguistiques et modèle à base d'agents.
II.3.2.A.a Modèles linguistiques
Les modèles linguistiques se basent sur une approche linguistique de l'interaction, inspirée des
architectures de compilateurs. L'approche linguistique identifie trois aspects dans l'interaction :
1. Aspects lexicaux : ces aspects désignent tout ce qui peut être assimilé à un vocabulaire
d'entrée (clic, glisser), ou de sortie (ensembles d'icônes).
2. Aspects syntaxiques : ils peuvent désigner des grammaires d'entrée représentant les
séquences d'actions valides, ou les aspects spatiaux et temporels de l'affichage.
3. Aspects sémantiques : ils correspondent à la partie fonctionnelle de l'application, qui
détermine en dernier lieu le sens d'une action et génère les erreurs.
À défaut de donner des indications précises sur la façon dont doit être structuré et implémenté un
système interactif, les modèles linguistiques identifient les couches logiques qui doivent y
apparaître.
Nous décrivons ci-dessous dans leurs grandes lignes et de façon chronologique les principaux
modèles linguistiques, à savoir le modèle de Seeheim, le modèle Arch, ainsi que son métamodèle
Slinky.
•
Seeheim
Seeheim est le premier modèle d'architecture largement accepté qui part d'une approche
linguistique. Celui-ci est issu d'un groupe de travail sur les systèmes interactifs ayant eu lieu à
Seeheim en 1985 [UIMS, 1983].
37
Figure 4 : Le modèle Seeheim
Seeheim était principalement destiné au traitement lexical des entrées et des sorties dans les
interfaces textuelles. S'il est peu utile aujourd'hui pour décrire les systèmes interactifs hautement
graphiques, il a servi de base à beaucoup d'autres modèles.
Comme présente la figure 4, le modèle de Seeheim propose de diviser l'interface en trois couches
logicielles selon une approche linguistique :
1. La présentation est la couche en contact direct avec les entrées et les sorties. Elle interprète
les actions de l'utilisateur (dispositifs physiques) et génère les sorties (affichage) au niveau
lexical.
2. Le contrôleur de dialogue gère le séquencement de l'interaction en entrée et en sortie. Il
maintient un état lui permettant de gérer les modes d'interaction et les enchaînements
d'écrans.
3. L'interface du noyau fonctionnel est la couche adaptative entre le système interactif et le
noyau fonctionnel. Elle convertit les entrées en appels du noyau fonctionnel et les données
abstraites de l'application à des objets présentables à l'utilisateur.
Un autre élément a été ajouté au modèle de Seeheim pour prendre en compte le retour sémantique
rapide (le petit carré dans la figure 4) : par exemple, lors d'une opération de glisser-déposer, il peut
s'avérer utile de modifier instantanément l'apparence de l'icône-cible pour indiquer si l'opération est
valide. Dans ce cas, la couche de présentation doit court-circuiter le contrôleur de dialogue pour
accéder directement aux informations sémantiques du noyau fonctionnel.
•
Arch / Slinky
Le modèle Arch [UIMS, 1992] affine le modèle de Seeheim en s'inspirant davantage des boîtes à
outils graphiques actuelles. Ce modèle incorpore la notion de plate-forme de développement et
décrit la nature des données qui transitent entre les différents composants.
38
Le modèle Arch identifie cinq composants dans les systèmes interactifs (figure 5) :
1. Le composant d'interaction désigne l'ensemble des widgets (objets interactifs) d'une boîte à
outils, ainsi que les communications avec les périphériques physiques. Il dépend d'une plateforme donnée.
2. Le composant de présentation joue le rôle de médiateur entre le composant d'interaction et le
contrôleur de dialogue. Il maintient une représentation logique des widgets qui est
indépendante de la plate-forme.
3. Le contrôleur de dialogue joue le même rôle articulatoire que celui du modèle de Seeheim. Il
est notamment responsable du séquencement des tâches et du maintien de la consistance
entre les vues multiples.
4. L'adaptateur du domaine est un composant médiateur entre le contrôleur de dialogue et le
noyau fonctionnel. Il est responsable des tâches dépendantes du domaine qui ne font pas
partie du noyau fonctionnel, mais qui sont nécessaires à sa manipulation par l'utilisateur. Ces
tâches comprennent la réorganisation des données du domaine dans des buts de
manipulation interactive, ou la détection des erreurs sémantiques.
5. Le noyau fonctionnel représente la partie non interactive de l'application.
Figure 5 : Le modèle ARCH
Le composant d'interaction et le noyau fonctionnel constituent les deux pieds de l'arche. Les autres
composants décrivent la partie de l'interface qui doit être implémentée pour faire le lien entre la
39
partie purement fonctionnelle d'une application et les widgets et les événements de la boîte à outils.
Le modèle Arch introduit également trois types d'objets décrivant la nature des informations qui
transitent entre les composants (figure 5) :
1. Les objets du domaine contiennent des données provenant directement ou indirectement du
noyau fonctionnel (par exemple, le résultat d'une requête dans une base de donnés).
2. Les objets de présentation sont des objets d'interactions virtuels qui décrivent les
événements produits par l'utilisateur et les données qui lui sont présentées, indépendamment
des méthodes d'interaction et de visualisation.
3. Les objets d'interaction sont des instances propres à une boîte à outils et qui implémentent
des techniques d'interaction et de visualisation spécifiques.
Dans la réalité, le poids relatif des composants Arch et la répartition de leurs fonctionnalités peut
varier selon les types d'applications interactives et les choix et impératifs fixés par leurs
développeurs. Un métamodèle baptisé Slinky a été conçu au-dessus du modèle Arch afin de
suggérer l'existence de ces variantes du modèle Arch. Le métamodèle Slinky, inspiré du jouet de
même nom (figure 6), met notamment en évidence les notions de choix et de compromis inhérents
au développement des applications interactives.
Figure 6 : Le jouet Slinky
II.3.2.A.b Modèles à agent
En décomposant les interfaces en objets de même nature, les modèles à agents sont proches des
40
langages à programmation objets et des interfaces à manipulation directe modernes. Nous décrivons
ici les principaux modèles à agents : MVC, PAC et le modèle hybride PAC-Amodeus.
•
MVC
Figure 7 : Le modèle MVC
Le modèle MVC (Modèle, Vue, Contrôleur) [Krasner et al., 1988] a été introduit comme
architecture de référence dans l'implémentation des interfaces utilisateurs de l'environnement
Smalltalk. L'approche de MVC inspirera toute une lignée de modèles à base d'agents, dont les
principales motivations sont la modifiabilité et la conception itérative, ainsi que la compatibilité
avec les langages à objets.
MVC décompose les systèmes interactifs en une hiérarchie d'agents. Un agent MVC consiste en un
modèle muni d'une ou plusieurs vues et d'un ou plusieurs contrôleurs:
1. Le modèle est le noyau fonctionnel de l'agent. Il peut représenter des données brutes (entier,
chaîne de caractères) ou des objets ayant un comportement complexe. Le modèle notifie les
vues qui lui sont associées à chaque fois que son état se trouve modifié par le noyau de
l'application ou par ses contrôleurs.
2. La vue maintient une représentation du modèle perceptible par l'utilisateur, qu'elle met à jour
à chaque changement d'état du modèle. Elle est en générale constituée d'objets graphiques.
3. Le contrôleur reçoit et interprète les événements utilisateur, en les répercutant sur le modèle
(modification de son état) ou sur la vue (retour instantané).
Chacun des trois composants de la triade MVC est un objet à part entière. Au sens de la
41
programmation orientée objet, une classe de Modèle peut être compatible avec plusieurs classes de
Vues et de Contrôleurs.
•
PAC
Par rapport à MVC, le modèle à agents PAC (Présentation, Abstraction, Contrôle) [Coutaz, 1987]
réintroduit la vue et le contrôleur dans un objet monolithique, mais rend explicite la synchronisation
du modèle et de la vue/contrôleur. Il propose en outre une méthode de description récursive qui
étend le paradigme à agents avec la notion de couche d'abstraction.
Figure 8 : Le modèle PAC
Comme MVC, le modèle PAC décrit les systèmes interactifs comme une hiérarchie d'agents
composés de trois modules. Mais ici, le rôle de ces modules diffère :
1. La présentation définit le comportement en entrée et en sortie de l'agent, tel qu'il est perçu
par l'utilisateur.
2. L'abstraction encapsule la partie sémantique de l'agent.
3. Le contrôle maintient la consistance entre la présentation, l'abstraction et communique avec
les autres agents.
Notons qu'ici le composant d'abstraction est l'équivalent du composant modèle de MVC, et que la
présentation correspond à une fusion des composants vue et contrôleur. Le composant contrôle n'a
pas d'existence explicite dans le modèle MVC.
42
Par une approche récursive, le modèle PAC peut être appliqué de manière consistante à plusieurs
niveaux d'un système interactif. Une application interactive peut ainsi être décrite comme une
hiérarchie d'agents disposés sur plusieurs couches d'abstractions (figure 8). Ce type de
représentation unifie en quelque sorte les modèles à agents et les approches à couches de type
Seeheim.
•
PAC-Amodeus
PAC-Amodeus [Nigay et al., 1993] finit de réconcilier les approches linguistiques et à agents en
proposant un modèle hybride. Il réutilise le modèle Arch et décrit son contrôleur de dialogue avec
une hiérarchie d'agents PAC (figure 9). L'adaptateur de domaine et la présentation de l'Arch
communiquent directement avec chaque agent PAC à travers son abstraction (pour le premier) et sa
présentation (pour le second).
Figure 9 : Le modèle PAC-Amodeus
L'objectif de PAC-Amodeus est de combiner les avantages du modèle Arch, qui intègre des aspects
de génie logiciel comme la modifiabilité et la portabilité et du modèle PAC, qui permet de structurer
efficacement le contrôleur de dialogue jusque-là monolithique. Le modèle PAC-Amodeus a été
employé pour modéliser des plate-formes multimodales [Nigay, 1994]. Les entrées sont décrites par
des symboles, des grammaires et des mécanismes de fusion de haut-niveau sont implémentés dans
le dialogue par des agents PAC.
43
II.3.2.B Modèles d'interaction
Contrairement aux modèles d'architecture, les modèles d'interaction sont loin des implantations
informatiques et souvent utilisés par les non-informaticiens. On trouve de nombreuse notations
proposées dans la littérature mais la plupart ont pour modèle de base, l'arbre de tâches qui
représente une décomposition des activités de l'utilisateur et du système [Dupuy-chessa, 2011]. La
dimension verticale de l'arbre correspond à la hiérarchie des tâches, la dimension horizontale à leur
agencement séquentiel.
L'analyse des tâches représente un vaste champ de connaissance qui s'intéresse à plusieurs questions
telles que :
➢ Comprendre comment une personne ou un ensemble de personnes accomplissent certaines
tâches faisant partie de leur travail.
➢ Mettre en évidence les tâches qu'un utilisateur devra pouvoir accomplir avec un système
(informatique ou autre).
➢ Spécifier la manière dont les tâches seront effectuées avec le système : quelles actions faire
et dans quel ordre ? qui a l'initiative ? qui de l'humain ou de la machine effectue quelle
action ? Etc.
➢ Calculer à l'avance la charge cognitive et psycho motrice demandée à l'utilisteur pour
réaliser une tâche.
Cette analyse est essentielle pour la conception de l'interface d'un système. En effet, elle détermine
le contenu de l'interaction (ce qu'un utilisateur doit pouvoir faire), elle fournit également les
éléments de départ pour la conception détaillée de l'interaction (et donc de l'interface), et enfin et
elle fournit le canvas de base pour les tests d'utilisabilité de l'interface.
La notation ConcurTaskTrees (CTT) [Patern et al., 1997] est la notation la plus utilisée en analyse
des tâches interactives. Elle met l'accent sur les activités de l'utilisateur et le feedback système et
propose de nombreux opérateurs temporels permettant de décrire différents comportements associés
au système interactif (interruption, concurrence, désactivation, ...).
Ce modèle est généralement considéré comme le point de départ de la réalisation d'un système
interactif nouveau, ou bien de la validation d'un système interactif déjà conçu et/ou existant. Il
44
possède 4 types différents de tâche :
•
Tâche abstraite (représentée par un nuage) : c'est la tâche qui nécessite une interaction
complexe.
•
Tâche interactive (représentée par un utilisateur d'un ordinateur) : c'est la tâche réalisée par
une interaction entre utilisateur et système et initiée par l'utilisateur.
•
Tâche système (représentée par un ordinateur) : c'est la tâche entièrement réalisée par
l'application.
•
Tâche utilisateur (représentée par une personne) : c'est la tâche entièrement réalisée par
l'utilisateur.
Les sous-tâches d'une tâche T doivent être du même type que T, sauf si T est de type abstraite. Dans
ce dernier cas ses sous-tâches doivent être soit toutes abstraites, soit d'au moins deux types
différents.
Les relations entre tâches sont représentées par un nombre très complet d'opérateurs :
45
•
T1 ||| T2
imbrication: actions en parallèle
•
T1 |[]] T2
synchronisation: échange d'information
•
T1 >> T2
activation: fin de T1 déclenche T2
•
T1 |=| T2
ordre quelconque: T1>>T2 ou T2>>T1
•
T1 []>> T2
activation avec passage d'information
•
T1 [] T2
choix: soit T1 soit T2
•
T1 [> T2
désactivation: dès qu'une action de T2 se produit, T1 est désactivée
•
T1 |> T2
interruption: T2 peut interrompre T1, T1 peut reprendre à la fin de T2
•
T1*
•
T1(n) itération finie: nombre d'itérations spécifié
•
[T1]
itération
option: T1 n'est pas obligatoirement effectuée
Figure 10 : Exemple de modèle CTT (distributeur automatique de billets)
La figure 10 représente l'exemple d'un distributeur automatique de billets inspiré de l'exemple
fourni avec l'outil CTTE (ConcurTaskTrees Environment). Il modélise le fait que l'utilisateur doit
tout d'abord insérer sa carte puis saisir son code PIN avant l'accès à son compte. Cette tâche
d'autorisation est suivie par l'accès au distributeur où seule la tâche Retirer Argent est représentée.
Cette tâche est désactivable à tout moment par la tâche Terminer Accès.
Parmi les autres modèles de tâches connus nous pouvons citer encore UAN (User Action Notation),
HTA (Hierarchical Task Analysis) et GOMS (Goals, Operators, Methods and Selection). Ces
modèles modélisent les tâches d'interaction comme le CTT, mais avec des notations différentes et
des objectifs différents aussi. GOMS par exemple a pour but premier de prédire les performances de
l'utilisateur d'une interface alors que le CTT était conçue spécialement pour simplifier le design
d'applications interactive.
46
II.4 Conclusion
Dans ce chapitre nous avons présenté la modélisation des systèmes interactifs à travers les différents
modèles présents dans la littérature. Nous pouvons constater que c'est un moyen très puissant pour
l'analyse et la structuration des applications interactives. De plus, avec une approche IDM les
modèles peuvent aller beaucoup plus loin dans le processus de conception et de développement
informatique. Malheureusement, les langages de modélisation dédiés à la multimodalité et aux
systèmes multimodaux ne sont pas suffisants et ils nécessitent encore beaucoup plus de raffinement
(niveau notation et niveau conception). Ainsi, dans le chapitre suivant nous proposons notre propre
modélisation des applications multimodales qui se base sur l'arbre des tâches et qui permet de bien
analyser les interactions multimodales.
47
Chapitre III :
Modélisation et développement de e-USTO
48
III Modélisation et développement de e-USTO
III.1 Introduction
Dans ce chapitre nous présentons notre contribution conceptuelle et logiciel : une nouvelle notation
de l'arbre des tâches multimodales et l'application mobile multimodale e-USTO. La notation répond
a nos objectifs de spécification des interactions multimodales et d'être orientée utilisateur. Elle se
base sur le modèle ConcurTaskTrees (CTT) (présenté dans le chapitre II) et propose de décrire les
modalités d'interaction et leurs coopérations possibles. L'application quant à elle est réalisée suivant
la modélisation multimodale avec notre nouvelle notation et propose de présenter l'université USTO
d'une façon multimodale sur des terminaux mobiles.
III.2 Modélisation multimodale
III.2.1 Modèle d'interaction pour la multimodalité
Les applications multimodales nécessitent la modélisation d'interaction plus que tout le reste des
applications interactives. C'est d'ailleurs le moyen le plus efficace pour identifier et simuler les
interactions utilisateur ainsi que les feed-backs système attendus afin de concevoir et implémenter
des applications multimodales utiles et utilisables. La modélisation de l'architecture joue aussi un
rôle primordial dans le processus de conception, mais elle est plutôt orientée système et ne prend
pas en compte les utilisateurs finaux (ce qui ne nous intéresse pas dans notre recherche actuelle).
Dans notre recherche nous sommes intéressés par les modèles d'interaction et spécialement les
modèles de tâche dans le but de simplifier la modélisation (et donc la conception et le
développement) des applications mobiles multimodales proches des besoins de leurs utilisateurs
finaux. Les modèles des tâches existants dans la littérature spécialement pour la modélisation des
applications multimodales sont peu nombreux. Le modèle CTT était utilisé pour modéliser les
systèmes multimodaux malgré qu'il ne supporte pas la modélisation des modalités d'interaction. Par
contre, l'ensemble complet de ses opérateurs permet facilement la modélisation des coopérations
entre modalités qui seront (sans notation particulière) représentées dans le nom de la tâche
interactive, système ou abstraite. Pour éliminer les limites de cette modélisation une nouvelle
notation était proposée dans [Clerckx et al., 2007] pour adapter le CTT à la modélisation
multimodale et éviter son utilisation détournée. Cette notation annote le CTT par les modalités
d'interaction et leurs coopérations possibles. Les tâches d'interaction et de système défini dans CTT
49
ont été enrichies par les quatre relations de coopération CARE afin de permettre la modélisation des
tâches qui utilisent plusieurs modalités en coopération. Chaque propriété est annotée par sa
première lettre : C pour Complémentarité, A pour Assignation, R pour Redondance et E pour
Equivalence. Les modalités associés aux tâches ont été annotées par la lettre « m » suivie par le
numéro de la modalité qui sera à son tour définit dans une légende à part suivant la définition de
Nigay : <d,r> où « d » c'est le dispositif physique de la modalité et « r » c'est le langage
d'interaction. La Figure 11 montre l'exemple de modèle de tâche « Faire une présentation » avec ces
annotations proposées.
Le modèle montre bien les modalités d'interaction utilisées ainsi que leurs coopérations ce qui
facilite par la suite la conception et la simulation du système multimodal. Par contre on remarque
qu'il y a une redondance des notations visuelles utilisées pour définir les propriétés CARE. Par
exemple pour la tâche système «show available presentations» on trouve la lettre A à côté de l'icône
de la tâche et on la trouve en bas de la tâche aussi avec entre crochets la modalité d'interaction
utilisée.
De plus, comme le CTT se base sur une représentation sous forme d'arbre, l'ajout de nouveaux
composants (tel que le carré qui regroupe les modalités en bas de chaque tâche système ou
interactive) encombre de plus en plus sa modélisation et diminue sa visibilité surtout pour les
modèles qui représentent de grands systèmes.
Figure 11 [Clerckx et al., 2007]: Exemple de performance de présentation en CTT annoté pour les
interactions multimodales
Nous pouvons souligner alors que les modèles existants dans la littérature ainsi que leurs nouvelles
50
adaptations ont encore des limites de notation et ils ne couvrent que partiellement les besoins de
modélisation des interactions multimodales. Nous proposons alors dans la session suivante une
nouvelle notation à travers laquelle nous souhaitons couvrir les différents besoins de modélisation
des systèmes multimodaux et qui réutilise autant que possible les notations existantes, tant dans
leurs concepts que dans leurs présentations plutôt que de définir une notation entièrement nouvelle.
III.2.2 Notre notation : le CTT annoté
Tout d'abord, nous adoptons la notation de CTT (modèle de tâche hiérarchique pour décrire
l'interaction) comme une forme de base pour notre nouvelle notation. La raison derrière ce choix est
bien évidemment la complétude de ce modèle ainsi que sa popularité dans le monde de la
modélisation.
Ensuite, nous étudions les besoins particuliers à la spécification de la dimension multimodale :
1. Représentation des modalités d'interaction : comme dans [Clerckx et al., 2007] nous
suivons aussi la définition de Nigay pour définir les modalités d'interaction : <d,r> où « d »
représente le dispositif physique utilisé pour l'interaction et « r » le langage d'interaction ou
le système représentationnel. C'est la définition la plus courante et la plus adaptée, car elle
prend à la fois les deux côtés de l'interaction (système et utilisateur). Mais comme elle prend
beaucoup de place en écriture, toutes les modalités d'interaction utilisées dans les
modélisations seront définies dans une légende à côté du modèle et la lettre « m »
accompagnée par le numéro de la modalité dans le modèle comme c'est le cas dans [Clerckx
et al., 2007]. Nous pouvions aussi représenter les modalités par des symboles particuliers
comme par exemple la main pour le tactile, l'oreille pour le vocale en sortie et la bouche en
entrée, mais comme ces modèles sont destinés aux concepteurs et non pas aux utilisateurs
finaux la numérotation des modalités sera plus parlante. Le tableau 1 donne quelques
modalités d'interaction selon la définition du couple <d,r>.
51
Dispositif physique
Langage d'interaction
Ecran
Widgets
Microphone
Langage naturel
Camera
Langage gestuel
Dispositif haptique
Forces à appliquer
Haut-parleurs
Son wave
Clavier
Manipulation directe
Souris
Manipulation directe
Tableau 1 : Exemple de modalité d'interaction <d,r>
2. Représentation de la coopération entre les modalités : pour spécifier la coopération nous
adoptons les propriétés CARE avec la notation symbolique suivante pour expliciter l'usage
combiné de modalitées:
•
« + » : pour la complémentarité.
•
Aucun symbole pour l'assignation par ce qu'il s'agit d'une seule modalité (un choix
d'implémentation).
•
« & » : pour la redondance.
•
« = » : pour l'équivalence.
Les symboles ont été choisis soigneusement pour avoir une bonne transparence sémantique
(un des critères de Moody [Moody, 2009]) et pour simplifier la notation car ils implicitent
une dynamique d'enchainement des modalités qui peut être complexe. En cas de
spécification de plusieurs modalités d'interaction à la fois on utilise les crochets pour faire la
différence entre les différents symboles. Par exemple, si on a deux modalités en
complémentarité en équivalence avec une troisième on les représente comme suit : [m1 +
m2] = m3.
Nous reprenons l'exemple de la Figure 11 de la performance d'une présentation avec notre nouvelle
notation dans la Figure 12.
De la première vue on peut remarquer que le modèle est devenu plus lisible et avec moins
d'éléments visuelle alors qu'il porte la même quantité d'information que le modèle présenté dans la
figure 11. Ce qui nous assure que même avec les grands systèmes interactifs multimodaux les
notations proposées n'encombrent pas la modélisation.
52
Figure 12 : Exemple de performance d'une présentation en CTT
53
III.3 L'application mobile multimodale e-USTO
Dans cette session nous présentons l'application e-USTO que nous avons développée en se basant
sur notre modèle de tâche annoté de CTT.
III.3.1 Pourquoi e-USTO (electronic-USTO) ?
Figure 13 : Le site de l'USTO
Notre but de départ était de réaliser une application mobile multimodales en entrée et en sortie à la
base de notre contribution de modélisation afin de confirmer ou pas notre hypothèse initiale (que
notre annotation CTT aide les développeurs à concevoir et coder parfaitement leurs applications).
Le choix était porté sur une application descriptive de l'Université des Sciences et de Technologie
d'Oran (USTO) pour les raisons suivantes :
➔ L'USTO n'a que le site web représentatif (http://www.univ-usto.dz/) et il sera intéressant
d'avoir une autre vitrine à travers une application descriptive.
➔ Les guides des bacheliers sont jusqu'à présent sur papier et leurs remplacement par une
application informatique porte beaucoup plus de professionnalisme à l'université.
➔ L'USTO est une grande université, donc pas facilement accessible pour les nouveaux
étudiants, les visiteurs ou les participants à des manifestations. Il sera alors utile d'avoir une
carte électronique à la main.
➔ Les dispositifs mobiles sont de plus en plus utilisés et avoir une application dans la poche
qui nous informe des dossiers à déposer, des ouvertures/fermetures des bureaux, des gens
responsables etc. est important pas seulement au début d'année, mais aussi au milieu et fin
d'année universitaire.
54
L'application est alors purement descriptive de l'USTO. Elle définie brièvement et selon la portée
mobile les différentes facultés et laboratoires de l'université, l'administration avec toutes ses
ramifications, les services proposés dans l'université, la vie de ses étudiants et le plan universitaire.
Comme s'est mentionné ci-dessus l'application est multimodale. Le choix était porté sur deux
modalités en entrée et deux autres en sortie mais, en alternance c'est-à-dire qu'il n'y aura pas de
complémentarité entre les modalités d'interaction. En entrée l'utilisateur peut utiliser le tactile qui
représente la modalité la plus utilisée pour les smartphones ou secouer le téléphone s'il porte des
gants par exemple. En sortie le système affiche les données sur l'écran du smartphone comme il
peut aussi dicter ces données en synthèse vocales si l'utilisateur le désir.
Nous pouvons déjà voir la coopération des modalités d'interaction telle que la redondance
(affichage et synthèse vocale) et l'équivalence (tactile et geste) et bien sûr l'assignation qui apparaît
dans toutes les interactions où on ne précise qu'une modalité particulière.
III.3.2 Modélisation de e-USTO
La Figure 14 nous montre la modélisation de l'application e-USTO avec CTT alors que la figure 15
montre sa modélisation avec notre nouvelle proposition. La différence est bien claire entre les deux
modèles surtout du côté multimodale car la figure 15 explicite mieux les modalités d'interaction
ainsi que leurs coopérations possibles ce qui facilite par la suite le travail de développement. Par
contre, on peut remarquer que les deux modèles portent beaucoup d'informations et ils peuvent être
difficiles à lire. La réponse est comme reconnue dans le monde de la modélisation « S'il y a de la
complexité on ne peut pas la cacher » : c'est à dire que si l'application informatique nécessite
beaucoup d'interactions le modèle doit surement être grand et complexe (même si notre proposition
de modélisation supprime quelques tâches puisqu'elle symbolise les coopérations et ne permet pas
leurs représentations comme tâches différentes). De plus, avec la représentation arborescente du
CTT l'arbre est de plus en plus grand allant du haut vers le bas. Mais cela n'élimine pas les
avantages du modèle que ça soit pour la modélisation elle même ou pour la simulation.
55
Figure 14 : e-USTO modélisé en CTT
56
Figure 15 : e-USTO en CTT annoté
57
III.3.3 Développement de e-USTO & résultats
Pour le développement de e-USTO le choix était porté sur la plate-forme Android puisque :
•
c'est une plate-forme open source et
•
elle supporte le langage java
Sachant qu'on peut à tout moment basculer vers une autre plate-forme (iPhone par exemple) car la
logique métier de l'application reste tel quelle.
L'architecture de l'application est basée sur le modèle MVC (Modèle Vue Contrôleur) où on sépare
la présentation de l'application (la vue qui correspond aux layouts (fichier xml) sous Android) des
données (le modèle qui correspond aux values (fichier xml «string») sous Android) et le contrôle
(les classes java). Toutes les données de l'application sont intégrées dedans et non pas sur un serveur
externe car comme la connexion 3G n'existe pas encore en Algérie il est impossible d'utiliser la
connexion internet pour récupérer les données de l'application. On était alors obligé d'intégrer les
données même si cela a donné un peu de lourdeur d'installation et de démarrage de l'application.
Les figures suivantes (de 16 à 33) montrent les captures d'écran (avec une tablettes tactile Samsung
Galaxy) des différentes pages de l'application ainsi que ses différentes fonctionnalités.
La modélisation de l'application (figure 15) nous a permis d'identifier les différentes interactions des
utilisateurs et donc de comprendre comment ces derniers vont réagir et comment l'application doit
présenter les informations. La coopération entre modalités, quant à elle, été facilement développée
en se basant sur le modèle de e-USTO ainsi que les fonctionnalités intégrées dans la plate-forme
Android.
58
Figure 16 : Page d'accueil de e-USTO.
59
Figure 17 : Page d'accueil de e-USTO avec message pour indiquer qu'on peut secouer le smartphone
pour aller directement vers le plan de l'université USTO.
60
Figure 18 : La liste des facultés de l'USTO (après sélection du bouton « Facultés » du menu).
61
Figure 19 : La page qui présente la faculté de génie électronique (après sélection de cette faculté à
partir de la liste des facultés).
L'icône de l'oreille montre qu'on peut utiliser la synthèse vocale sur cette page.
62
Figure 20 : La page qui présente la faculté de génie mécanique (après sélection de cette faculté à
partir de la liste des facultés).
63
Figure 21 : La page qui présente la liste de quelques laboratoires de l'USTO (après sélection du
bouton laboratoires du menu).
64
Figure 22 : La page qui présente le laboratoire LPPMCA (après la sélection de ce laboratoire à
partir de la liste des laboratoires).
65
Figure 23 : La page qui présente le laboratoire LRTTFC (après la sélection de ce laboratoire à partir
de la liste des laboratoires).
66
Figure 24 : La page des services de l'USTO (après la sélection du bouton service à partir du menu).
67
Figure 25 : La page qui présente l'administration de l'USTO (après la sélection du bouton
administration du menu).
68
Figure 26 : La page qui présente l'organigramme administratif général de l'USTO (après sa sélection
à partir de la page d'administration).
69
Figure 27 : La page qui présente les papiers du dossier de bourse (après sa sélection de la page
d'administration).
70
Figure 28 : La page qui présente les papiers du dossier d'hébergement (après sa sélection de la page
d'administration).
71
Figure 29 : Le plan de l'USTO (après la sélection du bouton plan du menu ou secouage du
smartphone/tablette tactile).
72
Figure 30 : Le plan de l'USTO avec des zooms.
73
Figure 31 : La page qui présente la vie des étudiants de l'USTO (après la sélection du bouton vie
étudiant du menu).
74
Figure 32 : Quelques photos des activités des étudiants de l'USTO.
75
Figure 33 : Photos des soutenances de l'USTO.
76
Conclusion et perspectives
77
Conclusion
Les travaux présentés dans ce mémoire concernent la conception des systèmes interactifs mobiles
multimodaux, c'est-à-dire des systèmes permettant aux utilisateurs d'interagir à l'aide de techniques
d'interaction (modalités d'interaction) variées, parfois concurrentes. Ce travail a été motivé par le
constat qu'il existe un nombre croissant de systèmes de ce type mais que leur modélisation et
conception sont souvent ad hoc, du fait du manque de langage de modélisation adaptés aux besoins
spécifiques liés à l'interaction multimodale.
De plus, la contribution de ce travail de magister vise à combler cette lacune, en particulier par la
proposition d'une nouvelle notation de spécification couvrant cette forme d'interaction
(multimodale). Pour cela, nous avons commencé par étudier les notations des modèles de tâche
existants dans la littérature afin de modéliser les tâches d'interaction avec les utilisateurs finaux.
Nous avons retenu le modèle CTT puisque c'est le modèle le plus descriptif et le plus étudié et
utilisé en modélisation interactive. En se basant sur ce dernier, nous avons proposé des nouvelles
notations afin de l'adapter à la modélisation multimodale :
•
Notation pour la spécification des modalités d'interaction avec une légende
•
Symboles pour représenter la coopération entre les différentes modalités
Pour évaluer notre proposition nous l'avons utilisé pour modéliser une application mobile
multimodale descriptive de notre université nommée e-USTO pour « electronic-USTO ». La
modélisation a joué un rôle important pendant la phase de développement en précisant exactement
les modalités d'interaction, les moments de leurs utilisations, leurs coopérations ainsi que les
réponses systèmes souhaitées après chaque interaction.
L'application quant à elle apporte plus de professionnalisme à l'université en donnant aux étudiants,
enseignants et visiteurs de l'USTO un ensemble d'informations pratiques sur l'université.
Comme tout travail de recherche, notre contribution possède certaines limitations. En particulier,
nous signalons les points suivants :
•
L'évaluation de notre contribution était fait à travers une « petite » application mobile et
non pas par un grand projet informatique mobile multimodal pour bien montrer les
avantages du modèle de tâche (support de communication entre les participants du projet,
support de simulation de l'interaction, etc).
78
•
Notre notation proposées soufre encore des limitations du modèle CTT lui même tel que la
représentation arborescente (qui prend beaucoup de place et ne permet pas l'imbrication),
l'absence de réutilisation des tâches, etc.
•
L'application nécessite des mises à jours périodique pour donner les bonnes informations
aux utilisateurs comme elle n'est pas hébergée sur un serveur web externe.
•
L'application n'a pas été évaluée auprès des utilisateurs finaux (étudiants et/ou enseignants)
sauf quelques-uns qui l'ont bien appréciés.
Enfin, ce travail nous a permis de se positionner près du domaine des IHM (Interaction Homme
Machine) et de la modélisation et il nous a donné l'occasion de voir la corrélation entre les deux
domaines et de proposer une contribution validée par une application informatique.
Perspectives
Au sein de ce mémoire, nous avons identifié les enjeux de la réalisation de systèmes multimodaux.
Or, notre contribution traite uniquement la modélisation de l'interaction. De plus, nous identifions
une piste de recherche pour continuer et étendre nos travaux.
Sur le long terme :
Cette piste consiste à utiliser le modèle de tâche et les notations proposées pour générer le code de
l'application informatique suivant le principe de l'ingénierie dirigée par les modèles (IDM). Cette
piste pourrait conduire plus facilement aux applications multimodales comme c'est le cas du projet
UsiXML [Limbourg et al., 2004].
79
Bibliographie
[Aït-Ameur et al., 2005] Y. Aït-Ameur, I. Aït-Sadoune et M. Baron. Modélisation et Validation
formelles d'IHM, 2005.
[Belik, 1995] Y. Bellik. Interfaces multimodales : concepts, modèles et architectures, Thèse de
l'université de Paris-XI, 1995.
[Bellik et al., 1992] Y. Bellik, D. Teil, Définitions terminologiques pour la communication
multimodale. IHM'92, 1992.
[Bernard et al., 2003] G. Bernard., J. Ben-Othman., L. Bouganim., G. Canals., B. Defude., J.
Ferrié., S. Gançarski., R. Guerraoui., P. Molli., P. Pucheral., C. Roncancio., P. Serrano-Alvarado.,
and P. Valduriez. Mobilité et bases de données : état de l'art et perspectives. Technique et Science
Informatiques, 2003.
[Blattner et al., 1990] M. M. Blattner, R. B. Dannenberg, CHI'90 Workshop on Multimedia and
Multimodal Interface Design, SIGCHI Bulletin, 1990, pp. 54-58.
[Bolt, 1980] R. Bolt, Put that there: Voice and gesture at the graphics interface. Computer Graphics,
1980, pp. 262-270.
[Bouchet, 2006] J. Bouchet. Ingenierie de l'interaction multimodale en entrée - approche à
composants ICARE. Thèse de l'université Joseph Fourier – Grenoble I, 2006.
[Catinis, 1998] L. Catinis, Etude de l'usage de la parole dans les interfaces multimodales. Thèse de
Institut National Polytechnique de Grenoble, 1998.
[Clerckx et al., 2007] T. Clerckx, C. Vandervelpen, K. Coninx, Task-based design and runtime
support for multimodal user interface distribution. Proceedings of Engineering Interactive Systems,
2007.
[Coutaz, 1987] J. Coutaz, PAC, an object‐oriented model for dialog design. Proceedings of IFIP
INTERACT'87: Human‐Computer Interaction, 1987. pp. 431‐436.
[Coutaz, 1993] J. Coutaz, Software architecture modeling for user interfaces. Encyclopedia of
Software Engineering, 1993.
[Coutaz et al., 1994] J. Coutaz, L. Nigay, Les propriétés "CARE" dans les interfaces multimodales,
IHM'94, 1994.
[Dupuy-chessa, 2011] S. Dupuy-chessa., Modélisation en Interaction Homme-Machine et en
Système d'Information : A la croisée des chemins. Habilitation à Diriger les Recherches (HDR) de
l'université Joseph Fourier – Grenoble I, 2011.
80
[Foster, 2002] M.E. Foster, State of the art review: Multimodal fission, COMIC Deliverable
D6.1,COMIC consortium, 2002.
[Frohlich, 1991] D.Frohlich, The design space of interfaces, multimedia systems, Interaction and
Applications, 1er Eurographics workshop, 1991, pp. 53-69.
[Jacquet, 2006] C. Jacquet. Présentation opportuniste et multimodale d'informations dans le cadre
de l'intelligence ambiante. Thèse de l'université de Paris-XI, 2006.
[Green et al., 1987] M. Green, A Survey of Three Dialogue Models. ACM Trans, 1987.
[Kazman et al., 1994] R. Kazman, L. Bass, G. Abowd, M. Webb , SAAM: A Method for Analyzing
the Properties of Software Architectures. ICSE 16, 1994, pp. 81-90.
[Kleppe et al., 2003] A. Kleppe, J. Warmer, et W. Bast. MDA Explained : The Model Driven
Architecture - Practice and Promise. Addison-Wesley, 2003.
[Krasner et al., 1988] G. E. Krasner and S.T. Pope, A cookbook for using the model‐view‐
controller user interface paradigm in Smalltalk‐80 Journal of Object Oriented Programming, 1988.
pp. 26‐49.
[Le Bodic, 2005] L. Le Bodic, Approche de l'évaluation des sytèmes interactifs multimodaux par
simulation comportementale située. Thèse de l'université de Bretagne occidentale, 2005.
[Le Mouël, 2003] F. Le Mouël, Environnement adaptatif d'exécution distribuée d'applications dans
un contexte mobile. Thèse de l'université de Rennes 1, 2003.
[Limbourg et al., 2004] Q. Limbourg, J. Vanderdonckt, B. Michotte, L. Bouillon, M. Florins,
UsiXML: A User Interface Description Language Supporting Multiple Levels of Independence.
Proceedings of Workshop on Device Independent Web Engineering, 2004. pp. 325-338.
[Lindland et al., 1994] O. I. Lindland., G. Sindre., et A. Sølvberg. Understanding quality in
conceptual modeling. IEEE Softw. 1994. pp. 42-49.
[Martin, 1997] J-C. Martin, Towards "intelligent" cooperation between modalities. The example of
a system enabling multimodal interaction with a map. IJCAI'97 International Workshop on
Intelligent Multimodal Systems, 1997.
[Martin, 1999] J-C. Martin, TYCOON: six primitive types of cooperation for observing,
evaluating and specifying cooperations. AAAI Fall, 1999.
[Moody, 2009] D. Moody. The physics of notations: Toward a scientific basis for constructing
visual notations in software engineering. IEEE transactions on software engineering, 2009.
[Moody et al., 2003] D. L. Moody., G. Sindre., T. Brasethvik., et A. Sølvberg. Evaluating the quality
of information models : empirical testing of a conceptual model quality framework. Proceedings
pour 25th International Conference on Software Engineering, 2003. pp. 295-305.
81
[Mottier, 2009] C. Mottier., Application de domotique sur la plateforme Android (Résumé), rapport
de stage, 2009.
[Nigay, 1994] L. Nigay. Conception et modelisation logicielles des systemes interactifs : application
aux interfaces multimodales. Thèse de l'université Joseph Fourier – Grenoble I, 1994.
[Nigay et al., 1996] L. Nigay, J. Coutaz, Espaces conceptuels pour l'interaction multimédia et
multimodale. TSI, spécial Multimédia et Collecticiel, 1996, pp. 1195-1225.
[Nigay et al., 1993] L. Nigay and J. Coutaz, J. A design space for multimodal systems: Concurrent
processing and data fusion. Proceedings of ACM INTERCHI'93 Conference on Human Factors in
Computing Systems, voices and Faces, 1993. pp. 172‐178.
[Oviatt, 1997] S.L. Oviatt, Multimodal interactive maps: Designing for human performance.
Human-Computer Interaction, 1997. pp. 93-129.
[Oviatt, 1999] S.L. Oviatt, Ten myths of multimodal interaction. Communication of the ACM,
1999. pp.74-81.
[Patern et al., 1997] F. Patern, C. Mancini, S. Meniconi, ConcurTaskTrees: A Diagrammatic
Notation for Specifying Task Models. Proceedings of INTERACT, 1997. pp. 362-369.
[Roques, 2007] P. Roques., Livre : UML 2 - Modéliser une application Web, 2007. pp. 246.
[Rouillard, 2008] J. Rouillard, Adaptation en contexte : contribution aux interfaces multimodales et
multicanal. Habilitation à Diriger les Recherches (HDR) de l'université des Sciences et
Technologies de Lille1, 2008.
[Serrano, 2008] M. Serrano, D. Juras, M. Ortega, L. Nigay, OIDE : un outil pour la conception et le
développement d'interfaces multimodales. UbiMob, 2008.
[Serrano et al., 2008] M. Serrano, L. Nigay, J.Y.L Lawson, A. Ramsay, R. Murray-Smith, Denef S.,
The openinterface framework: a tool for multimodal interaction. CHI'08 extended abstracts on
Human factors in computing systems, 2008. pp. 3501-3506.
[UIMS, 1983] User Interface Management Systems: Proceedings de the Seeheim Workshop.
Springer Verlag. Workshop on User Interface Management Systems, held in Seeheim, FRG, 1983.
[UIMS, 1992] UIMS, A metamodel for the runtime architecture of an interactive system ACM
SIGCHI Bulletin, 1992. pp. 32-37.
[Verdurand et al., 2009] E. Verdurand, G. Coppin, F. Poirier, Modélisation et évaluation de
l'interactiondans les systèmes multimodaux. Revue d'Intelligence Artificielle (RIA), 2009, pp. 227255.
[Wikipedia, 2011] Site Wikipédia, l’encyclopédie libre en ligne http://fr.wikipedia.org
82