Dans la section 2.2.2, nous avons présenté l’intérêt des critères IDM (pertinence et conci- sion des concepts, guidage de modélisation, vérification des modèles, réutilisation des mo- dèles, génération de code) dans les approches à base des modèles. Ainsi, nous avons visé l’intégration de ces critères dans notre approche de modélisation et de génération d’inter- faces mobiles multimodales.
Dans le chapitre 4, nous avons montré l’intégration du premier critère (pertinence et concision des concepts) lors de la définition de notre langage de modélisation M4L. Dans ce chapitre (section 5.1.3), nous avons montré l’intégration du quatrième critère (réutilisation de modèle) lorsqu’on a présenté la bibliothèque des types d’évènements qui donne au concep- teur des modèles réutilisables. Dans les sections précédentes de ce chapitre, nous avons aussi montré l’intégration du cinquième critère (génération de code) lors de la définition des gé- nérateurs de code pour MIMIC. A présent, nous allons montrer l’intégration de deux autres critères : le guidage de modélisation et la vérification des modèles.
5.3.1
Guidage de modélisation (Model guidance)
Pour guider le concepteur et réduire son effort de modélisation, nous avons défini une notation graphique qui présente une efficacité cognitive (section 5.1.2). Nous avons aussi facilité les étapes de modélisation sous MIMIC et défini une documentation complète afin d’orienter l’utilisateur et de lui présenter des exemples de modélisation et de génération pré- existants.
Outils de modélisation. Lors de la sélection des éléments de modèles à partir de la palette et de la bibliothèque des évènements, des messages sont affichés afin de guider le concepteur pour faire les bons choix. Ces messages expliquent comment utiliser/modéliser les éléments sélectionnés (indiquer l’association à utiliser entre deux évènements, expliquer l’utilité de l’élément dans le modèle, etc.) et donnent parfois des informations techniques (indiquer les évènements à base de capteurs qui peuvent être « deprecated » sur tel ou tel système mobile, indiquer la précision des capteurs utilisés, etc.) pour augmenter la qualité des modèles et des applications générées.
ponible sur le site du framework13. Elle permet de guider le concepteur en lui présentant des « guidelines » concernant les différentes étapes d’utilisation de notre outil MIMIC. Elle commence par l’explication des étapes d’installation (Obeo Designer, Méta-modèle M4L, environnement de modélisation MIMIC et générateurs de code). Puis, à travers un exemple, elle montre les étapes de modélisation, de vérification de modèles et de génération de code de l’application modélisée.
La documentation présente aussi dix-huit exemples de modèles et d’applications géné- rées. Pour chaque exemple, l’utilisateur peut télécharger le modèle ainsi que le code généré (Android, iPhone et HTML5/CSS3).
Pour mieux guider le concepteur, nous avons comme perspective d’implémenter un assis- tant de modélisation. Il permettra de donner au concepteur des aides et des orientations selon ses besoins et sans qu’il les demande explicitement (consulter la documentation, sélectionner les éléments dans la palette pour voir les messages, etc.). Il permettra aussi de rester sur le même contexte de travail et ne pas le changer à chaque fois pour voir la documentation.
5.3.2
Vérification des modèles (Model-checking)
Dans le but d’éviter la génération de code à partir de modèles incomplets, nous avons dé- fini des contraintes OCL et les avons intégrées dans MIMIC (voir l’annexe F). Après la mo- délisation, le concepteur vérifie si son modèle est bien modélisé en exécutant ces contraintes. En cas de problème, MIMIC affiche les contraintes qui ont été violées et indique les solu- tions possibles. Le concepteur corrige les problèmes indiqués et répète la vérification jusqu’à l’obtention d’un modèle qui respecte toutes les contraintes.
On a défini deux types de contraintes. Le premier type concerne des contraintes qui véri- fient la validation des modèles par rapport au langage de modélisation M4L. Ce sont des contraintes qui ne peuvent pas être exprimées par le métamodèle et que l’on ajoute pour compléter la description du langage. Par exemple, ces contraintes sont « un évènement en entrée doit être appliqué sur un évènement en sortie ou un état », « un évènement transitoire en sortie doit être déclenché par un évènement interne ou un évènement en entrée », « une combinaison doit être entre deux évènements au moins », etc. La vérification des modèles par rapport à ces contraintes les valide syntaxiquement. Cela permet de faciliter la tâche des générateurs et d’assurer leur fonctionnement de manière correcte.
Le deuxième type concerne des contraintes qui vérifient l’ergonomie des interactions dans les modèles. Ce sont des contraintes qui aident le concepteur à ne pas modéliser des conflits. On peut trouver trois types de conflits : conflits entre les modes utilisateur, conflits entre les modalités et conflits entre évènements :
– Les modes gestuel et tactile peuvent être en conflit en cas de combinaison en complé- mentarité ou redondance si la fenêtre temporelle est très courte, car ce sont des modes qui utilisent presque les mêmes organes (mains, doigts, bras). Par exemple, utiliser la chute libre avec un « Long Touch » en complémentarité pendant une fenêtre tempo- relle très courte, peut être une source de conflit.
– Des combinaisons entre évènements du même mode peuvent provoquer des conflits. Par exemple, lancer une synthèse vocale et une musique en concurrence.
– Les modes visuel et auditif s’influencent s’ils sont en concurrence en sortie (effet Mc- Gurk14, effet ventriloque, etc.).
– Les modalités qui se basent sur le même capteur peuvent être en conflit si elles co- opèrent en concurrence (la proximité et l’éclairage par exemple).
– Les évènements qui possèdent la même modalité d’interaction peuvent être en conflit si la fenêtre temporelle est très courte.
– etc.
Nous avons défini un ensemble de contraintes OCL pour prévenir le concepteur des éven- tuels conflits qui pourraient apparaître pendant l’interaction et l’aider à modéliser des in- terfaces correctes. Cependant, les contraintes que nous avons définies ne vérifient pas tous les conflits possibles, car il n’est pas évident de trouver une formulation OCL pour chaque conflit. De plus, puisque la violation d’une contrainte OCL est toujours considérée comme une erreur de modélisation, certains conflits ne doivent pas être exprimés par des contraintes OCL, car leurs degrés de confusion peuvent changer d’un modèle à l’un autre. Par exemple, l’utilisation de la synthèse vocale et d’une musique concurrente en sortie peut provoquer un conflit pour l’utilisateur si la musique est très bruyante, mais elle peut ne rien provoquer si la musique est compatible avec la lecture du texte. Ainsi, dans ce cas, il revient au concepteur de détecter les modèles qui posent problèmes et de les corriger. Pour cela, la notation visuelle et la vue générale donnée par les diagrammes des interfaces peuvent l’aider à voir les conflits et à les résoudre.
5.4
Conclusion
Ce chapitre clôt la description de notre outil de modélisation et de génération des appli- cations mobiles multimodales, reflétant notre contribution principale. Dans ce chapitre, nous avons commencé par décrire l’environnement de modélisation des interfaces mobiles multi- modales : le choix d’outils, la notation graphique ainsi que la bibliothèque des évènements en entrée et en sortie qui sont utilisés pour la modélisation des interactions. Nous avons présenté aussi les générateurs de code associés à MIMIC. Nous avons détaillé leurs méca- nismes de fusion/fission et les règles de génération qu’ils ont suivies (pour Android, iPhone et HTML5/CSS3) puis nous les avons comparées pour détecter leurs points communs. Fina- lement, nous avons présenté les différents critères IDM et montré comment nous les avons intégrés dans notre approche.
Dans le chapitre suivant, nous présentons les évaluations de notre langage de modélisa- tion M4L et du framework MIMIC.
Chapitre 6
Évaluation
Sommaire
6.1 Évaluation du langage : un ensemble d’exemples de modélisation . . . 162
6.2 Évaluation du framework (modélisation et génération) . . . 168
6.2.1 Protocole d’expérimentation . . . 168
6.2.2 Analyses et interprétations des résultats . . . 173
6.2.3 Synthèse et discussion . . . 181
Ce chapitre est dédié à l’évaluation de nos deux contributions, M4L et MIMIC. Notre premier objectif d’évaluation consiste à montrer que le langage M4L modélise bien les dif- férents types d’interactions mobiles multimodales en entrée et en sortie. Notre deuxième objectif d’évaluation consiste à montrer d’une part que la plateforme MIMIC influe positive- ment sur le développement des applications mobiles multimodales (le facilite et/ou réduit son temps), et d’autre part qu’il respecte bien les critères IDM tels que la vérification de modèle (les contraintes OCL), le guidage (la documentation et la notation visuelle) et la réutilisation (la bibliothèque des évènements).
Nous présentons tout d’abord l’évaluation de notre langage de modélisation. Ensuite, nous décrivons l’expérimentation menée auprès de développeurs mobiles, pour évaluer MI- MIC. Nous présentons nos hypothèses de départ, le protocole d’expérimentation ainsi que les résultats obtenus.