FR2913509A1 - Procede de gestion d'interactions entre des applications et des utilisateurs - Google Patents

Abstract

L'invention concerne un procédé de gestion de l'interaction d'une application avec au moins un utilisateur, le comportement de ladite application étant dépendant du contexte d'utilisation, défini notamment par un historique de l'activité de l'utilisateur, comportant :- une étape de création d'au moins un modèle, ledit modèle représentant de façon dynamique l'application et ses données,- une étape de création d'au moins une vue, ladite vue présentant les données du modèle à l'utilisateur et capturant les évènements utilisateurs,- une étape de création d'au moins un contrôleur, ledit contrôleur définissant le comportement de l'application en mettant en correspondance les évènements utilisateurs avec des altérations du modèle,caractérisé en ce qu'il comporte en outre une étape de création d'un module d'interaction effectuant l'interprétation sémantique des évènements échangés entre la vue et le contrôleur, ladite interprétation sémantique permettant d'adapter de vérifier la cohérence entre les interactions de l'utilisateur et le contexte d'utilisation.

Description

Procédé de gestion d'interactions entre des applications et des

utilisateurs L'invention concerne un procédé de gestion d'interactions entre une application et un ou plusieurs utilisateurs.

De nombreux systèmes informatiques sont actuellement basés sur le patron de conception MVC (Modèle, Vue, Contrôleur). Un patron est une solution générale à un problème de conception récurrent. Ce patron de conception permet un développement modulaire d'une application interactive en trois parties plus ou moins indépendantes selon les techniques de développement. Il permet de concevoir un logiciel interactif robuste aux évolutions comprenant : une partie concernant les données de l'application (le modèle), une partie comportement de l'application (le contrôleur) et une dernière partie pour la visualisation du comportement et des données de l'application à la fois (la vue). Le patron de conception MVC définit la répartition des fonctionnalités nécessaires à une application au sein de ces trois éléments. Le schéma de ce patron de conception est illustré en Figure 1. Chacune des parties a une vocation spécifique. Le modèle 11 a pour objectif de proposer une représentation des fonctions d'une application et de ses données. Il est en mesure de répondre aux requêtes exprimées sur ces éléments et d'informer la vue 12 sur les modifications des éléments auxquels elle est abonnée. La vue 12 a pour objectif de présenter le modèle 11 et de transmettre les évènements utilisateur au contrôleur 13. Elle peut demander des informations au modèle 11 et doit autoriser le contrôleur 13 à la sélectionner. Le contrôleur 13 définit le comportement de l'application. Il a pour charge de mettre en correspondance les évènements utilisateur avec des altérations du modèle 11. II doit de plus sélectionner la vue 12 pour la présentation des données du modèle.

Le patron de conception MVC a été développé dans un contexte de conception centré sur le développement d'applications mono-utilisateur, mono-surface (un poste de travail unique par utilisateur) et à domaine de compétence unique (i.e. le développement d'applications pour le travail de secrétariat).

De ce fait, l'utilisation de ce patron ne permet pas de prendre en compte facilement différentes formes d'interactions avec les utilisateurs d'une application ou les préférences spécifiques d'un utilisateur. De plus, ce patron ne permet pas non plus de représenter de manière riche les spécificités du contexte d'interaction (domaine d'application, spécificités de l'utilisateur, de l'organisation, ...). En effet, de nombreux domaines d'applications présentent à la fois des contraintes importantes sur la présentation de l'information (visualisation d'information) ainsi que sur les modèles du domaine eux-mêmes. Cette approche de conception centrée utilisateur et centrée domaine/métier requiert la modification du patron de conception MVC. L'invention impacte toutes les catégories de systèmes où l'humain tient une place prépondérante et ceci dans toutes sortes de domaines d'application, tels que : La défense : systèmes d'armes, de commandement, de simulation et d'entraînement ; Les transports : systèmes de pilotage, de supervision, de 20 réservation ; Les communications : téléphonie, radio, télévision, internet ; La vie quotidienne : systèmes électroménagers, véhicules individuels, informatique domestique omniprésente et diffuse ( ubiquitous computing en anglais) ; 25 Les services : systèmes bancaires, commerce électronique, assistance technique ; La santé : systèmes hospitaliers, secours opérationnel.

Plusieurs problèmes se posent avec le patron de conception MVC 30 utilisé dans de tels systèmes. La gestion de l'interaction entre l'utilisateur et l'application est diffuse. Elle est répartie et gérée au sein de plusieurs modules. Par exemple, le contrôleur décide de sélectionner une vue pour présenter une information du modèle mais la vue est abonnée aux informations qui l'intéressent dans le modèle. Le contrôleur n'a ainsi pas la 35 possibilité de gérer les informations qui seront présentées.

Le changement du comportement de l'application géré par le contrôleur impose tout d'abord un changement de contrôleur. Ainsi, une modification du rôle d'un opérateur imposerait le changement du contrôleur déployé dans le système qu'il utilise. L'application n'a en effet pas le même comportement. Le développement d'une application centrée utilisateur est complexe à réaliser avec ce patron de conception dans la mesure où il est nécessaire que l'ensemble du système soit spécifique à l'utilisateur. Cette spécificité du système implique une vue, un contrôleur et un modèle spécifique à chaque utilisateur.

L'invention vise à pallier les problèmes cités précédemment en proposant un procédé permettant d'ajouter un module d'interaction entre la vue et le contrôleur. Ce module d'interaction a en charge la gestion des informations spécifiques à un utilisateur particulier afin de permettre l'indépendance du modèle, de la vue et du contrôleur par rapport à l'utilisateur, mais également à la surface d'interaction et enfin permet une évolution simplifiée d'un domaine d'application à un autre. Cette invention permet l'utilisation d'une approche basée sur des modèles externes aux modules d'interaction et de contrôle permettant d'accroître leur réutilisabilité. Le principal avantage de cette invention est de permettre une interaction centrée utilisateur et centrée domaine. La gestion de l'interaction avec l'utilisateur est réunie dans le module d'interaction. Cette approche centralise les aspects relatifs à l'utilisateur dans le module de l'interaction afin de permettre au contrôleur de se focaliser sur le contrôle du comportement applicatif au contraire de celui de l'utilisateur. Le deuxième intérêt de cette invention est de permettre l'interaction basée sur des modèles externes. La gestion de l'interaction est basée sur des modèles de représentation externes à l'application telles que les tâches recommandées pour l'utilisateur ou les préférences dans les modes d'utilisation. Ces modèles externes peuvent être des modèles de tâches ou des profils pour l'interaction. Le module interaction utilisera ces modèles externes par l'intermédiaire d'un gestionnaire de dialogue lui-même basé sur un modèle de dialogue. Cette approche basée sur des modèles augmente l'aspect générique des différents modules contrôleur, interaction et vue. En effet, les différents modules mettent en oeuvre des processus utilisant les descriptions des interactions exprimées dans les modèles lors de l'exécution de l'application. Le troisième intérêt est de proposer une généralisation accrue des modules vue et contrôleur. Une plus forte généralisation signifie donc une simplification des rôles attribués aux modules vue et contrôleur. Leurs responsabilités dans le développement d'une application informatique interactive sont donc plus claires. La gestion de l'interaction homme-machine, auparavant réalisée dans la vue ou dans le contrôle est déléguée ~o entièrement au module d'interaction. Par exemple, la requête de la vue vers une donnée du modèle passant par le contrôleur permettra d'utiliser la même vue quel que soit le modèle utilisé puisque le contrôleur se chargera de cette adaptation grâce au module d'interaction. Le quatrième intérêt de cette invention est l'introduction du module 15 d'interaction augmentant l'aspect générique du contrôleur. Le contrôleur peut être réutilisé quelle que soit l'interaction proposée à l'utilisateur. Seul les modèles du module d'interaction seront altérés. Par exemple, le changement de rôle d'un utilisateur ne nécessitera que le changement des modèles de l'interaction. 20 Pour résumer, cette invention permet l'augmentation de la modularité d'un modèle classique WC en introduisant l'approche centrée utilisateur et la gestion de l'interaction et des adaptations basées sur des modèles externes à l'application. Cette approche permet à la vue, au modèle d'être réutilisables quel que soit l'utilisateur ainsi que le domaine visé. Enfin, 25 les modules contrôleur et Interaction sont réutilisables et configurables dans la mesure où ils sont basés sur des modèles.

À cet effet, l'invention a pour objet un procédé de gestion de l'interaction d'au moins une application avec au moins un utilisateur, le 30 comportement de ladite application étant dépendant du contexte d'utilisation, défini notamment par un historique de l'activité de l'utilisateur, comportant : une étape de création d'au moins un modèle, ledit modèle représentant de façon dynamique l'application et ses données, une étape de création d'au moins une vue, ladite vue présentant les données du modèle à l'utilisateur et capturant les évènements utilisateurs, une étape de création d'au moins un contrôleur, ledit contrôleur définissant le comportement de l'application en mettant en correspondance les évènements utilisateurs avec des altérations du modèle, caractérisé en ce qu'il comporte en outre une étape de création d'un module d'interaction effectuant l'interprétation sémantique des évènements échangés entre la vue et le contrôleur, ladite interprétation sémantique permettant d'adapter les évènements échangés et de vérifier la cohérence entre les interactions de l'utilisateur et le contexte d'utilisation.

Avantageusement, le module d'interaction comprend notamment : des moyens pour transmettre des évènements entre la vue le contrôleur, des moyens pour créer de nouveaux évènements, des moyens pour filtrer, supprimer et altérer des évènements, des moyens pour adapter les informations en provenance de l'utilisateur ou vers l'utilisateur.

Avantageusement, le module d'interaction comprend en outre des moyens pour transmettre des évènements entre la vue et le contrôleur en introduisant un décalage temporel.

Avantageusement, le module d'interaction est réalisé avec un modèle statique, défini à la conception de l'application.

Avantageusement, le module d'interaction est réalisé avec un 30 modèle dynamique pouvant être modifié lors de l'exécution de l'application. La prise en compte des modifications dans le modèle peut être immédiate ou non. 20 25 Avantageusement, le module d'interaction réalise l'interprétation sémantique des événements à l'aide d'un modèle de tâche, ledit modèle de tâche comprenant notamment : un enchaînement de tâches à réaliser par l'utilisateur, des événements pouvant survenir, une description des interactions à effectuer lorsqu'un événement survient, les conditions de déclenchement nécessaires desdites interactions, les informations à fournir en retour par lesdites interactions, un état courant de l'utilisateur dans sa tâche.

Avantageusement, le module d'interaction comprend : un gestionnaire de tâche pour gérer en temps réel les modèles de tâches, une 15 base de donnée pour stocker les modèles de tâches.

Avantageusement, le module d'interaction comprend en outre un gestionnaire de dialogue faisant l'interface entre le module d'interaction, la vue et le contrôleur. L'invention sera mieux comprise et d'autres avantages apparaîtront à la lecture de la description détaillée et à l'aide des figures parmi lesquelles : La figure 1 représente un patron de conception MVC selon l'art 25 connu. La figure 2 illustre un patron de conception obtenu avec le procédé selon l'invention comprenant un modèle, une vue, un contrôleur et un module interaction. La figure 3 représente un exemple de modèle de tâches. 30 La figure 4 montre un exemple de connexion d'un utilisateur à un système réalisé en suivant le procédé selon l'invention.

L'invention concerne un procédé permettant d'ajouter un module d'interaction entre une vue et un contrôleur. Le patron ainsi obtenu est illustré 35 par la figure 2. Le module d'interaction .21 effectue l'interprétation sémantique 10 20 des évènements échangés entre la vue 12 et le contrôleur 13. Pour ce faire, le module d'interaction 21 mémorise un contexte d'interaction. L'interprétation sémantique permet de vérifier ou d'adapter la cohérence entre les interactions de l'utilisateur et le contexte d'utilisation. Le module d'interaction comprend notamment : des moyens pour transmettre des évènements entre la vue 12 le contrôleur 13 en insérant éventuellement un décalage temporel (par exemple, lorsque l'utilisateur est affecté à une tâche pendant laquelle il ne doit pas être dérangé), des moyens pour créer de nouveaux évènements, des moyens pour filtrer et supprimer des évènements.

Avec le procédé selon l'invention, on peut appliquer la séparation entre l'application et l'interface homme-machine décrite dans le brevet 15 français FR2845174. Selon une première variante de l'invention, le module d'interaction est: réalisé avec un modèle statique, défini à la conception de la partie interaction de l'application. Ce modèle statique établit une correspondance 20 entre les événements provenant de la vue et les appels systèmes vers le contrôleur. Cette correspondance définit le comportement de l'application en fonction des besoins de l'utilisateur. La première variante de l'invention permet un découplage entre la vue et le contrôleur. Cependant, comme ce modèle est figé à la conception du logiciel, il ne permet pas de gérer 25 dynamiquement au cours de l'exécution de l'application, le comportement de ladite application. Selon une deuxième variante de l'invention, le module d'interaction est réalisé avec un modèle dynamique pouvant être modifié lors 30 de l'exécution de l'application.

Avantageusement, le modèle mis en oeuvre dans le module interaction est un modèle de tâche pouvant être obtenu avec le procédé décrit dans le brevet français FR2864646. Cependant, l'interprétation 35 sémantique pourrait potentiellement être faite par une autre méthode que le modèle de tâche, par exemple : un modèle de l'activité ou des règles d'interprétations. En effet, le principe de l'invention est de centraliser la gestion intelligente de l'interaction dans un module séparé. Un modèle de tâche décrit les différentes étapes qu'un utilisateur peut ou doit effectuer pour mener à bien sa tâche globale, son rôle ou sa mission. La tâche de l'utilisateur doit être décrite sous forme d'un enchaînement alternatif, séquentiel ou en parallèle de sous-tâches avec une mention particulière pour l'état initial. Les sous-tâches effectuées par l'utilisateur correspondent à autant d'états dans lesquels se trouve l'utilisateur (en état d'effectuer une sous-tâche). Un modèle de tâche comprend notamment : l'enchaînement des tâches à réaliser, les événements pouvant survenir, la description des interactions à effectuer, les conditions de déclenchement nécessaires et les informations à fournir en retour. Un modèle de tâche comprend en outre un état initial et un état courant de l'utilisateur dans sa tâche permettant de suivre l'utilisateur dans sa tâche. La figure 3 représente un exemple de modèle de tâche pour un utilisateur, client d'une compagnie aérienne, souhaitant se connecter à une application pour y consulter une liste de vols. Le modèle de tâche considéré dans l'exemple comporte deux états. Le premier état déconnecté 31 correspond à l'état de l'utilisateur avant sa connexion. Le second état connecté 32 correspond à l'état de l'utilisateur après sa connexion. Un modèle de tâches comprend des événements permettant un changement d'état de l'utilisateur (fin d'une sous-tâche pour en débuter une autre). Ces événements peuvent être des événements à l'initiative de l'utilisateur ou des événements externes survenus dans l'environnement. L'environnement est défini ici comme tout excepté l'utilisateur : la ou les applications, les autres utilisateurs, des capteurs,... Ainsi chaque transition entre deux états de l'utilisateur est associée à une liste d'un ou de plusieurs événements déclenchant le changement d'état. Le modèle de tâche de l'exemple comporte un événement 33 correspondant à une demande de connexion de la part de l'utilisateur. Un modèle de tâche comprend une liste de contraintes nécessaires pour déclencher une interaction. Ces contraintes peuvent être la fourniture de paramètres ou la vérification d'une valeur. Dans l'exemple, une contrainte 34 est la fourniture de deux paramètres : un identifiant et un mot de passe. Un modèle de tâches comprend, pour chaque événement survenu lors d'un état de l'utilisateur, une interaction à effectuer avec l'utilisateur pour gérer cet événement. L'interaction est définie comme une procédure à dérouler (interrogation d'applications, calcul d'une valeur, vérification d'une donnée,...). En fait, le modèle de tâche peut faire référence à plusieurs applications différentes. Ainsi, l'utilisateur a une seule et même interface, et ce sont alors les procédures d'interaction qui se chargent d'accéder aux applications nécessaires. Chaque procédure d'interaction doit fournir un résultat permettant de décider du prochain état de l'utilisateur. Pour chaque résultat possible de la procédure d'interaction, une transition étiquetée par le résultat permet d'atteindre un nouvel état de l'utilisateur. Dans l'exemple, la procédure d'interaction 35, après avoir interrogé l'application, fournit une réponse binaire (oui/non). Si la réponse est positive, l'utilisateur accède à l'état connecté 32, sinon il reste dans l'état déconnecté 31. Un modèle de tâche comprend, pour chaque procédure d'interaction, les valeurs que doit fournir cette interaction selon le résultat de l'interaction et qui doivent être présentées à l'utilisateur en retour. Dans l'exemple précédent, la sortie de la procédure d'interaction permettant la connexion est la liste des vols 36 que l'utilisateur souhaite consulter. En pratique, le premier état 31 du modèle de tâches est associé à une première vue vi représentant une fenêtre de connexion permettant de saisir un identifiant et un mot de passe. Le second état 32 est associé à une seconde vue v2 présentant la liste des vols.

Avantageusement, le module d'interaction comprend un gestionnaire de tâches permettant la gestion en temps réel du modèle de tâche. II se comporte comme un fournisseur des services décrits ci-après. Le gestionnaire est à même de gérer plusieurs modèles de tâches différents et plusieurs utilisateurs en parallèle. La multiplicité des modèles de tâches gérés par un même gestionnaire permet la collaboration entre plusieurs utilisateurs ayant des tâches potentiellement différentes. Le gestionnaire de tâches prend en compte l'évolution dans le temps d'un modèle de tâche en offrant des services d'accès pour des modules qui pourraient altérer les modèles. Le gestionnaire de tâches se présente sous forme d'un module externe et temps réel fournissant l'accès aux modèles de tâche dont il a la charge. Il fournit tous les services d'accès nécessaires, comme l'initialisation d'un modèle de tâche lors de la connexion d'un nouvel utilisateur, l'identification du modèle de tâche selon la classe de l'utilisateur, la fourniture de la prochaine procédure d'interaction en fonction d'un événement, la fourniture du prochain état en fonction du résultat d'une procédure io d'interaction. Ce module est capable de gérer en parallèle plusieurs utilisateurs en mémorisant le contexte de chacun. La sécurité de fonctionnement de la gestion de tâche doit être assurée, par exemple avec une vérification des actions de l'utilisateur vis-à-vis de sa tâche. Le gestionnaire de tâches fournit aussi les services d'accès en écriture aux 15 différents modèles de tâches avec sauvegarde des modèles altérés. Le gestionnaire de tâches peut utiliser un module de stockage externe afin d'accéder aux modèles de tâches des utilisateurs.

Avantageusement, le module d'interaction comprend en outre un 20 gestionnaire de dialogue faisant l'interface entre le module d'interaction, la vue et le contrôleur. Le gestionnaire de dialogue utilise un modèle de dialogue afin de prendre en charge les enchaînements d'évènements provenant à la fois de la vue et du contrôleur.

25 La figure 4 montre un exemple de connexion d'un utilisateur à un système réalisé en suivant le procédé selon l'invention. Ledit système comprend un modèle (non représenté), une vue 41, un contrôleur 46 et un module interaction 45. De façon avantageuse, le module interaction comprend un gestionnaire de dialogue 42, un gestionnaire de tâches 43 30 gérant le modèle de tâche de l'exemple précédent stocké dans une base de données 44. La connexion au système se déroule comme décrit ci-après. L'utilisateur saisit un identifiant de connexion et un mot de passe dans une fenêtre de la vue 41. Un premier événement et connexion comprenant le 35 mot de passe et l'identifiant de connexion est émis de la vue 41 vers le module interaction 45 et plus particulièrement vers le gestionnaire de dialogue 42. Le gestionnaire de dialogue 42 envoie alors un second événement e2 vers le gestionnaire de tâche 43. Le second événement e2 correspond à une requête pour connaître l'interprétation sémantique du premier événement et et déterminer quel doit être le comportement de l'application. Un troisième événement e3 est émis du gestionnaire de tâches 43 vers le gestionnaire de dialogue 42 correspondant à une réponse à la requête précédente. 1 o Le troisième événement e3 précise quel est l'appel vers l'application à effectuer. Dans cet exemple, il s'agit d'un appel système si correspondant à une procédure de connexion. Cette procédure est externe au modèle de tâches, et seule une référence (ici son nom) permet de la retrouver. Ensuite, c'est au gestionnaire de dialogue d'appeler cette 15 procédure. Ainsi, le modèle de tâche est totalement indépendant du contenu de cette procédure. Un quatrième événement e4 correspond à l'appel système s, de la procédure de connexion fait par le gestionnaire de dialogue 42 vers le contrôleur 46. 20 Le contrôleur 46 répond par un cinquième événement e5 après l'exécution de la procédure de connexion. Cette procédure vérifie l'identifiant de l'utilisateur et son mot de passe. La procédure de connexion fournit une réponse binaire (affirmative ou négative) indiquant si l'utilisateur est autorisé à se connecter, ainsi que les paramètres 36 requis par le modèle de tâches 25 (la liste de vol). Dans cet exemple, l'utilisateur est autorisé à se connecter à l'application. Le gestionnaire de dialogue 42 envoie alors un sixième événement e6 vers le gestionnaire de tâche 4. Le sixième événement e6 est une requête pour connaître l'interprétation sémantique du cinquième 30 événement e5. Le gestionnaire ne fait que répondre à des requêtes et mémoriser l'état de l'utilisateur. II mémorise donc que le nouvel état est connecté et crée un septième événement e7 rendant cette réponse au gestionnaire de dialogue 42 avec les paramètres correspondant (la liste de vol).

Le gestionnaire de dialogue 42 envoie un huitième événement e8 à la vue 41 pour lui communiquer le nouvel état de l'utilisateur et les paramètres à afficher. La vue peut alors présenter une fenêtre appropriée affichant la liste de vol.5

Claims (8)

REVENDICATIONS

1. Procédé de gestion de l'interaction d'au moins une application avec au moins un utilisateur, le comportement de ladite application étant dépendant du contexte d'utilisation, défini notamment par un historique de l'activité de l'utilisateur, comportant : une étape de création d'au moins un modèle, ledit modèle représentant de façon dynamique l'application et ses données, une étape de création d'au moins une vue, ladite vue présentant les données du modèle à l'utilisateur et capturant les évènements utilisateurs, une étape de création d'au moins un contrôleur, ledit contrôleur définissant le comportement de l'application en mettant en correspondance les évènements utilisateurs avec des altérations du modèle, caractérisé en ce qu'il comporte en outre une étape de création 15 d'un module d'interaction effectuant l'interprétation sémantique des évènements échangés entre la vue et le contrôleur, ladite interprétation sémantique permettant d'adapter les évènements échangés et de vérifier la cohérence entre les interactions de l'utilisateur et le contexte d'utilisation. 20

2. Procédé de gestion d'interactions d'une application avec au moins un utilisateur selon la revendication 1, caractérisé en ce que le module d'interaction comprend notamment : des moyens pour transmettre des évènements entre la vue le contrôleur, 25 des moyens pour créer de nouveaux évènements, des moyens pour filtrer, supprimer et altérer des évènements, des moyens pour adapter les informations en provenance de l'utilisateur ou vers l'utilisateur. 30

3. Procédé de gestion d'interactions d'une application avec au moins un utilisateur selon la revendication 1 ou 2, caractérisé en ce que le module d'interaction comprend en outre des moyens pour transmettre des évènements entre la vue et le contrôleur en introduisant un décalage temporel. 10

4. Procédé de gestion d'interactions d'une application avec au moins un utilisateur selon l'une des revendications 1, 2 ou 3, caractérisé en ce que le module d'interaction est réalisé avec un modèle statique, défini à la 5 conception de l'application.

5. Procédé de gestion d'interactions d'une application avec au moins un utilisateur selon l'une des revendications 1, 2 ou 3, caractérisé en ce que le module d'interaction est réalisé avec un modèle dynamique 1 o pouvant être modifié lors de l'exécution de l'application.

6. Procédé de gestion d'interactions d'une application avec au moins un utilisateur selon la revendication 5, caractérisé en ce que le module d'interaction réalise l'interprétation sémantique des événements à l'aide d'un 15 modèle de tâche, ledit modèle de tâche comprenant notamment : un enchaînement de tâches à réaliser par l'utilisateur, des événements pouvant survenir, une description des interactions à effectuer lorsqu'un événement survient, 20 les conditions de déclenchement nécessaires desdites interactions, les informations à fournir en retour par lesdites interactions, un état courant de l'utilisateur dans sa tâche. 25

7. Procédé de gestion d'interactions d'une application avec au moins un utilisateur selon la revendication 6, caractérisé en ce que le module d'interaction comprend : un gestionnaire de tâche pour gérer en temps réel les modèles de tâches, une base de donnée pour stocker les modèles de tâches. 30

8. Procédé de gestion d'interactions d'une application avec au moins un utilisateur selon la revendication 7, caractérisé en ce que le module d'interaction comprend en outre un gestionnaire de dialogue faisant l'interface entre le module d'interaction, la vue et le contrôleur.