Télécharger le fichier original (Mémoire de fin d’études)
EV interactifs
Cette sous-section a pour but de donner les grands principes qui guident la mise en place d’objets virtuels avec lesquels il est possible d’interagir. La Section 2.1.1 de nit la collaboration et présente des mécanismes qui la rendent possible. La Section 2.1.2 présente le concept de modèles objets-relations, qui permet la de finition d’interactions. La Section 2.1.3 présente les techniques d’interactions conformes a ces modèles et permettant la manipulation d’objets virtuels.
Définition et gestion de la collaboration en EV
Les applications de RV doivent permettre la collaboration d’utilisateurs physiquement presents au meme endroit, ou bien repartis sur des sites distants, et meme avec des humains virtuels. On distingue alors trois niveaux de collaboration [Margery et al., 1999] :
1. les utilisateurs sont conscients les uns des autres (e.g gr^ace a une representation sous forme d’avatars) et peuvent communiquer entre eux. C’est un niveau de base qui peut ^etre su sant pour des applications de teleconference comme MASSIVE [Greenhalgh and Benford, 1995] ou des reseaux sociaux par exemple ;
2. les utilisateurs peuvent en plus interagir avec des objets de l’environnement de maniere individuelle. Il est par exemple possible a un utilisateur d’attraper et de deplacer un objet ou de changer sa couleur. la collaboration se fait a ce niveau encore par la communication entre les utilisateurs, mais elle n’a pas une vocation uniquement sociale. Les utilisateurs peuvent en e et communiquer pour se mettre d’accord sur des transformations a operer sur l’environnement, en vue d’atteindre un but donne. C’est le cas de Calvin [Leigh and Johnson, 1996], une application de conception architecturale permettant a plusieurs utilisateurs de s’immerger dans un m^eme environnement a n de modi er et de visualiser en direct l’apparence d’une scene d’interieur ;
3. les interactions avec les objets de l’environnement peuvent ^etre collaboratives. Il est par exemple possible de manipuler un objet a plusieurs. On distingue en general deux sous-niveaux : (3.1) seules des interventions independantes sont permises en simultane sur un m^eme objet (e.g., deplacement et changement de la couleur) ou (3.2) le systeme gere les interventions interdependantes (e.g., co-manipulation d’un objet, ou la position de l’objet depend des e orts qui lui son appliques par plusieurs utilisateurs). La Figure 2.6 illustre ce dernier niveau de collaboration.
Figure 2.6 { Niveau 3.2 de la collaboration : deux operateurs deplacent un objet de maniere collaborative [Aguerreche et al., 2009]. Le mouvement resultant prend en compte les deux interactions simultanees.
La gestion de la collaboration ne peut pas se passer de mecanismes de synchronisation. En e et, la transmission des evenements sur un reseau peut conduire a des ordres di erents de reception et donc a des incoherences entre les etats de chaque processus. Selon le niveau de collaboration, les mecanismes de synchronisation ne sont pas les m^emes. Au premier niveau, qui ne permet que la communication entre les utilisateurs, il n’y a pas besoin de mecanismes particuliers. Au deuxieme niveau, permettant des interactions individuelles avec les objets, il faut munir ces derniers de verrous qui emp^echent l’intervention de plus d’une personne. Le troisieme niveau,
2. Structure des applications de RV
permettant des interactions simultanees sur un m^eme objet, a et traite par Margery et al. [Margery et al., 1999]. Il faut garantir deux proprietes :
1. tous les processus doivent s’accorder sur l’ordre d’execution des operations sur un m^eme objet
2. tous les processus doivent s’accorder sur la simultaneit des operations sur un m^eme objet, c’est a dire que si un processus considere que deux operations ont eu lieu simultanement, alors tous les processus doivent considerer la m^eme chose. Cette propriet est utile pour le niveau 3.2, qui permet les interactions simultanees interdependantes.
Avant tout, il faut de nir ce qu’est une operation sur un objet. Margery et al. la de nissent comme etant le changement de valeur d’un handler 8 [Margery et al., 1999]. Ainsi les operations peuvent ^etre associees a des evenements ordonnes dans le temps.
La premiere propriet est garantie a l’aide d’une contrainte qui doit ^etre imposee sur les messages echanges sur le reseau 9 et dont se charge l’objet concern : il faut que les messages soient di uses en ordre complet, c’est a dire que tous les processus les
recoivent dans le m^eme ordre.
La deuxieme propriet s’obtient gr^ace a un mecanisme d’inscription / desinscription au moment ou un utilisateur commence a interagir avec un objet (resp. termine son interaction). A chaque execution d’operation, l’objet considere que tous les utilisateurs inscrits sont en activite simultanee et opere d’abord la di usion d’un message contenant le nombre d’inscrits. Ensuite, a chaque operation e ectuee, la valeur du handler correspondant est a son tour di usee. Chaque processus attend donc le nombre d’operations correspondant au nombre recu au prealable, avant de calculer la transformation resultante. Si un utilisateur reste trop longtemps \detenteur » d’un handler sans pour autant realiser d’interaction, la valeur du handler est consideree constante et un signal special est di use a n de ne pas faire attendre inutilement les processus.
Les modeles objets-relations
Les modeles objets-relations permettent de de nir les interactions comme des realisations de relations de nies entre des objets (dont certains sont des acteurs). Par exemple, on peut de nir la relation Taper qui permet de lier un acteur, un marteau et un clou. La realisation de cette relation correspond a l’action de l’acteur qui tape le clou avec le marteau a n de l’enfoncer. Une realisation modi e les caracteristiques d’un ou plusieurs objet. En general, les realisations ont un but precis, i.e., les changements provoques sur les objets font changer l’etat de ceux-ci, e.g., pour provoquer un evenement dans l’application de RV et faire avancer la simulation (i.e., faire avancer le scenario, voir Section 2.2). Il peut exister des preconditions pour une realisation, e.g., dans le cas de la relation Taper, le clou ne doit pas ^etre deja enfonc . Des exemples de frameworks implementant cette
8. Entite logicielle qui permet de detecter une requ^ete d’interaction et qui en gere les parametres. Un handler peut ^etre materialis dans l’application de RV par une boule de couleur par exemple (voir la Figure 2.6).
approche sont STORM [Mollet et al., 2007], VEHA [Chevaillier et al., 2012], Domain-DL [Carpentier, 2015] et #FIVE [Bouville et al., 2015].
Ces modeles possedent trois avantages majeurs :
| collaboration : la modelisation d’interactions collaboratives au niveau 3.2 est rendue possible par la de nition de relations impliquant plusieurs acteurs,
| utilisation de plusieurs objets : il est facile de de nir des interactions liant plusieurs objets (e.g., la relation Taper necessite un marteau et un clou),
| genericit : les relations sont en general de nies sur des types d’objets plut^ot que sur des objets individuels (e.g., tout objet ayant la capacite de taper peut ^etre utilise dans la relation Taper, e.g., un marteau ou une batte).
Les modeles objets-relations sont une evolution d’autres modeles d’interactions qui ont et proposes, notamment celui des objets synoptiques [Badawi and Donikian, 2004, Willans and Harrison, 2001] pour lequel les objets ne sont pas caracterises par des types, mais par les actions que l’on peut realiser en les utilisant, en fonction de leur etat interne. Par exemple un objet \interrupteur » porterait les actions \allumer la lumiere » et \eteindre la lumiere », disponibles en fonction de l’etat de la lumiere (\eteinte » ou \allumee »). Cette approche est adaptee aux interactions impliquant un acteur et un objet. Mais pour les interactions plus complexes, il faut lister explicitement tous les objets qui peuvent entrer en jeu. Par exemple, si on attache une action Taper a un objet, il faut lister tous les objets de l’environnement permettant de realiser cette action, e.g., tous les marteaux et toutes les battes. De plus, M^eme s’il est possible de de nir des interactions collaboratives au niveau 3.2 [Willans and Harrison, 2001], les implementations existantes de ces approches ne le permettent pas toutes [Badawi and Donikian, 2004].
Techniques d’interaction
Les modeles qui ont etes presentes dans cette section doivent ^etre mis en uvre, ce qui implique de developper des techniques d’interaction et des metaphores. Foley et al. de nissent une technique d’interaction comme la maniere d’utiliser un dispositif d’interaction pour accomplir une t^ache sur un ordinateur [Foley et al., 1996]. Plus recemment, Hachet la de nissait comme une methode permettant d’executer une interaction en EV [Hachet, 2003]. Plus precisement, une technique d’interaction implique d’utiliser des interfaces reelles, virtuelles ou hybrides (i.e., m^elant composants reels et virtuels). Une metaphore est une representation symbolique, souvent visuelle, dont l’objectif est de transmettre une information aux utilisateurs d’un EV (e.g., mettre en surbrillance des objets pour inciter les utilisateurs a les manipuler) [Arnaldi et al., 2006].
Table des matières
1 Introduction
2 Etat de l’art
1 Ingenierie Dirigee par les Modeles
1.1 Lignes de Produits Logiciels
1.2 Modelisation de domaines
1.3 Langages dedies
2 Structure des applications de RV
2.1 EV interactifs
2.2 Modelisation de scenarios
2.3 Evaluations experimentales en RV
3 Synthese
3.1 Limites des pratiques de developpement et d’evaluation en RV
3.2 Limites de l’IDM
3.3 Contributions de la these
3 Lignes de Produits Logiciels Orientes Scenario
1 Approche
1.1 Objectif de l’approche LPLOS
1.2 Vue d’ensemble
1.3 Cas d’illustration : guidage d’un robot
1.4 Specication et implementation du domaine
1.5 Modele de scenarios
1.6 Synthese d’un logiciel
2 Cas d’utilisation : production de documentation pour DSL
2.1 Introduction au cas d’utilisation
2.2 Conception de la LPLOS
2.3 Implementation
3 Synthese du chapitre
4 Lignes de Produits Logiciels pour la RV
1 Approche
1.1 Cas d’illustration
1.2 Vue d’ensemble
1.3 Denition du domaine
1.4 FM et modele de scenarios
1.5 Synthese de l’application de RV
2 Cas d’utilisation : generation de protocoles experimentaux pour la RV
2.1 Motivations
2.2 Analyse du domaine
2.3 Vue d’ensemble
2.4 Cas d’illustration
2.5 Modele du domaine, modele objets-relations et FM
2.6 Mise en correspondance avec la bibliotheque de composants RV
2.7 Modele de scenarios
2.8 Compilation et synthese
2.9 Evaluation d’AGENT
3 Cas d’utilisation : production d’une application de formation aux procedures chirurgicales
3.1 Motivations
3.2 Vue d’ensemble
3.3 Modelisation du domaine par une ontologie
3.4 Production du modele objets-relations
3.5 Generation de la bibliotheque objets-relations
3.6 Scenarios
3.7 Synthese du projet Unity
3.8 Discussion
4 Synthese du chapitre
5 Conclusion et travaux futurs
1 Conclusion
2 Travaux futurs
A Publications de l’auteur
B DSL Robot
Table des figures
Bibliographie
