FR2913509A1

FR2913509A1 - Interaction maintaining method for e.g. TV, involves creating interaction model forming semantic interpretation of exchanged events, between view and controller, where interpretation verifies consistency between user interaction and context

Info

Publication number: FR2913509A1
Application number: FR0701622A
Authority: FR
Inventors: David Faure; Jerome Lard; Olivier Grisvard; Celestin Sedogbo
Original assignee: Thales SA
Current assignee: Thales SA
Priority date: 2007-03-06
Filing date: 2007-03-06
Publication date: 2008-09-12

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.The invention relates to a method for managing the interaction of an application with at least one user, the behavior of said application being dependent on the context of use, defined in particular by a history of the user's activity, comprising a step of creating at least one model, said model dynamically representing the application and its data, a step of creating at least one view, said view presenting the data of the model to the user and capturing the user events, - a step of creating at least one controller, said controller defining the behavior of the application by matching the user events with alterations of the model, characterized in that it further comprises a step of creating an interaction module performing the semantic interpretation of the events exchanged between the view and the controller, said semantic interpretation allows adapting to verify the consistency between the user's interactions and the context of use.

Description

Procédé de gestion d'interactions entre des applications et desA method of managing interactions between applications and

utilisateurs L'invention concerne un procédé de gestion d'interactions entre une application et un ou plusieurs utilisateurs. The invention relates to a method for managing interactions between an application and one or more users.

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. Many computer systems are currently based on the MVC design pattern (Model, View, Controller). A boss is a general solution to a recurring design problem. This design pattern allows a modular development of an interactive application in three parts more or less independent according to the development techniques. It allows to design an interactive software that is robust to evolutions including: a part concerning the data of the application (the model), a part of the behavior of the application (the controller) and a last part for the visualization of the behavior and data of the application the application at a time (the view). The MVC design pattern defines the distribution of functionality required for an application within these three elements. The diagram of this design pattern is illustrated in Figure 1. Each of the parts has a specific purpose. The purpose of model 11 is to provide a representation of the functions of an application and its data. It is able to respond to requests expressed on these elements and to inform the view 12 on the modifications of the elements to which it subscribes. The purpose of the view 12 is to present the model 11 and to transmit the user events to the controller 13. It may request information from the model 11 and must allow the controller 13 to select it. The controller 13 defines the behavior of the application. It is responsible for matching the user events with alterations of the model 11. It must also select the view 12 for the presentation of the model data.

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). The MVC design pattern was developed in a design context centered on the development of single-user, single-surface (a single workstation-per-user) and single-domain applications (ie application development for secretarial work).

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. Therefore, the use of this pattern does not allow to easily take into account different forms of interaction with the users of an application or the specific preferences of a user. Moreover, this pattern does not allow to represent in a rich way the specificities of the context of interaction (application domain, specificities of the user, the organization, ...). Indeed, many application domains present both significant constraints on the presentation of information (visualization of information) as well as on the models of the domain themselves. This user centric and business-centric design approach requires the modification of the MVC design pattern. The invention impacts all categories of systems where the human being holds a prominent place and this in all kinds of fields of application, such as: Defense: systems of weapons, command, simulation and training; Transport: steering, supervision and reservation systems; Communications: telephony, radio, television, internet; Daily life: household electrical systems, personal vehicles, ubiquitous computing and ubiquitous computing in English; 25 Services: banking systems, e-commerce, technical assistance; Health: hospital systems, operational relief.

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. Several problems arise with the MVC design pattern used in such systems. The management of the interaction between the user and the application is diffuse. It is distributed and managed within several modules. For example, the controller decides to select a view to present model information, but the view subscribes to information of interest to the model. The controller thus has no opportunity to manage the information that will be presented.

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. Changing the behavior of the application managed by the controller requires first a controller change. Thus, a change in the role of an operator would require the change of the deployed controller in the system it uses. The application does not have the same behavior. The development of a user-centric application is complex to achieve with this design pattern in that it is necessary that the entire system is user-specific. This specificity of the system implies a view, a controller and a model specific to each user.

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. The invention aims to overcome the problems mentioned above by proposing a method for adding an interaction module between the view and the controller. This interaction module supports the management of information specific to a particular user to allow independence of the model, the view and the controller from the user, but also to the interaction surface and finally allows a simplified evolution from one area of application to another. This invention allows the use of an approach based on models external to the interaction and control modules to increase their reusability. The main advantage of this invention is to allow user centric and centric domain interaction. The management of the interaction with the user is gathered in the interaction module. This approach centralizes the user-related aspects of the interaction module to allow the controller to focus on controlling the application behavior as opposed to the user's. The second advantage of this invention is to allow interaction based on external models. Interaction management is based on non-application-based representation models such as user-recommended tasks or preferences in usage patterns. These external models can be task templates or profiles for interaction. The interaction module will use these external models through a dialogue manager itself based on a dialog template. This model-based approach enhances the generic look of different controller, interaction, and view modules. Indeed, the different modules implement processes using the descriptions of the interactions expressed in the models during the execution of the application. The third interest is to propose an increased generalization of the view and controller modules. Greater generalization therefore means simplification of the roles assigned to the view and controller modules. Their responsibilities in developing an interactive computer application are therefore clearer. The management of the human-machine interaction, previously performed in the view or in the control is delegated ~ o entirely to the interaction module. For example, the request of the view to a data of the model passing through the controller will make it possible to use the same view regardless of the model used since the controller will take care of this adaptation thanks to the interaction module. The fourth advantage of this invention is the introduction of the interaction module increasing the generic aspect of the controller. The controller can be reused regardless of the interaction proposed to the user. Only the models of the interaction module will be altered. For example, changing a user's role will only require changing the patterns of the interaction. To summarize, this invention makes it possible to increase the modularity of a conventional WC model by introducing the user centered approach and the management of the interaction and adaptations based on external models to the application. This approach allows the view, the model to be reusable regardless of the user as well as the targeted domain. Finally, the controller and Interaction modules are reusable and configurable to the extent that they are based on models.

À 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. To this end, the subject of the invention is a method of managing the interaction of at least one application with at least one user, the behavior of said application being dependent on the context of use, defined in particular by a history of the activity of the user, comprising: a step of creating at least one model, said model dynamically representing the application and its data, a step of creating at least one view, said view presenting the data from the model to the user and capturing the user events, a step of creating at least one controller, said controller defining the behavior of the application by matching the user events with alterations of the model, characterized in that it further comprises a step of creating an interaction module performing the semantic interpretation of the events exchanged between the view and the controller, said interpreter semantic state allowing to adapt the exchanged events and to check the coherence between the interactions of the user and the context of use.

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. Advantageously, the interaction module comprises in particular: means for transmitting events between the view the controller, means for creating new events, means for filtering, deleting and altering events, means for adapting the information coming from the user or to the user.

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. Advantageously, the interaction module further comprises means for transmitting events between the view and the controller by introducing a time shift.

Avantageusement, le module d'interaction est réalisé avec un modèle statique, défini à la conception de l'application. Advantageously, the interaction module is made with a static model defined at the design of the 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. Advantageously, the interaction module is made with a dynamic model that can be modified during the execution of the application. Taking into account changes in the model can be immediate or not. Advantageously, the interaction module performs the semantic interpretation of the events using a task model, said task model comprising in particular: a sequence of tasks to be performed by the user, events that may occur, a description of the interactions to be performed when an event occurs, the necessary triggering conditions of said interactions, the feedback information to be provided by said interactions, a current state of the user in his task.

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. Advantageously, the interaction module comprises: a task manager for managing in real time the task templates, a database for storing the task templates.

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. Advantageously, the interaction module further comprises a dialog manager interface between the interaction module, the view and the controller. The invention will be better understood and other advantages will become apparent upon reading the detailed description and with the aid of the figures, in which: FIG. 1 represents an MVC design pattern according to the known art. FIG. 2 illustrates a design pattern obtained with the method according to the invention comprising a model, a view, a controller and an interaction module. Figure 3 shows an example of a task template. FIG. 4 shows an exemplary connection of a user to a system made by following the method according to the 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. The invention relates to a method for adding an interaction module between a view and a controller. The pattern thus obtained is illustrated in FIG. 2. The interaction module 21 carries out the semantic interpretation of the events exchanged between the view 12 and the controller 13. To do this, the interaction module 21 stores a interaction context. Semantic interpretation makes it possible to check or adapt the coherence between the user's interactions and the context of use. The interaction module includes: means for transmitting events between the view 12 the controller 13 possibly including a time shift (for example, when the user is assigned to a task during which it should not be disturbed), means for creating new events, means for filtering and deleting events.

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. With the method according to the invention, it is possible to apply the separation between the application and the man-machine interface described in the French patent FR2845174. According to a first variant of the invention, the interaction module is: realized with a static model, defined in the design of the interaction part of the application. This static model maps events from the view to system calls to the controller. This match defines the behavior of the application according to the needs of the user. The first variant of the invention allows a decoupling between the view and the controller. However, as this model is frozen in the design of the software, it does not manage 25 dynamically during the execution of the application, the behavior of said application. According to a second variant of the invention, the interaction module is made with a dynamic model that can be modified during the execution of the 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. Advantageously, the model implemented in the interaction module is a task model that can be obtained with the method described in the French patent FR2864646. However, the semantic interpretation could potentially be made by another method than the task model, for example: a model of the activity or rules of interpretation. Indeed, the principle of the invention is to centralize the intelligent management of the interaction in a separate module. A task template describes the various steps a user can or must take to complete their overall task, role or mission. The task of the user must be described as an alternating, sequential or parallel sequence of sub-tasks with special mention for the initial state. The sub-tasks performed by the user correspond to as many states in which the user is (in the state of performing a sub-task). A task model includes: the sequence of tasks to be performed, the events that may occur, the description of the interactions to be performed, the necessary triggering conditions and the information to be provided in return. A task template further includes an initial state and a current state of the user in his task of tracking the user in his task. Figure 3 shows an example of a task model for a user, customer of an airline, wishing to connect to an application to view a list of flights. The task model considered in the example has two states. The first disconnected state 31 corresponds to the state of the user before his connection. The second connected state 32 corresponds to the state of the user after his connection. A task template includes events that change the state of the user (end of one subtask to start another). These events can be user-initiated events or external events in the environment. The environment is defined here as everything except the user: the application (s), the other users, sensors, ... Thus each transition between two states of the user is associated with a list of one or more events triggering the change of state. The task template of the example includes an event 33 corresponding to a connection request from the user. A task template includes a list of constraints needed to trigger an interaction. These constraints may be the provision of parameters or the verification of a value. In the example, a constraint 34 is the provision of two parameters: an identifier and a password. A task template includes, for each event that occurs during a user's state, an interaction to be performed with the user to handle that event. The interaction is defined as a procedure to be rolled out (querying applications, calculating a value, checking a data, etc.). In fact, the task template can refer to several different applications. Thus, the user has a single interface, and it is then the interaction procedures that are responsible for accessing the necessary applications. Each interaction procedure must provide a result to decide the next state of the user. For each possible result of the interaction procedure, a transition labeled by the result makes it possible to reach a new state of the user. In the example, the interaction procedure 35, after querying the application, provides a binary response (yes / no). If the answer is positive, the user accesses the connected state 32, otherwise he remains in the disconnected state 31. A task model includes, for each interaction procedure, the values that this interaction must provide according to the result of interaction and which must be presented to the user in return. In the previous example, the output of the interaction procedure for the connection is the list of flights 36 that the user wishes to consult. In practice, the first state 31 of the task model is associated with a first view vi representing a connection window for entering an identifier and a password. The second state 32 is associated with a second view v2 presenting the list of flights.

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. Advantageously, the interaction module includes a task manager for real-time management of the task model. It acts as a provider of the services described below. The manager is able to manage several different task templates and multiple users in parallel. The multiplicity of task templates managed by the same manager allows collaboration between multiple users with potentially different tasks. The task manager takes into account the evolution over time of a task model by providing access services for modules that could alter the models. The task manager comes in the form of a plug-in and real-time module providing access to the task templates for which it is responsible. It provides all necessary access services, such as initializing a task template when connecting a new user, identifying the task template according to the user's class, providing the next interaction procedure according to an event, providing the next state based on the result of an interaction procedure. This module is able to manage several users in parallel by memorizing the context of each one. The functional security of the task management must be ensured, for example by checking the actions of the user vis-à-vis his task. The task manager also provides write access services to the different task templates with backup of the corrupted templates. Task Manager can use an external storage module to access users' task templates.

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. Advantageously, the interaction module further comprises a dialogue manager interface between the interaction module, the view and the controller. The dialog manager uses a dialog template to support event sequences from both the view and the controller.

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). FIG. 4 shows an exemplary connection of a user to a system made by following the method according to the invention. Said system comprises a model (not shown), a view 41, a controller 46 and an interaction module 45. Advantageously, the interaction module comprises a dialogue manager 42, a task manager 43 managing the task model of the program. previous example stored in a database 44. The connection to the system proceeds as described below. The user enters a login ID and a password in a window of view 41. A first event and connection including the password and the login ID is output from view 41 to interaction module 45 and more particularly to the dialogue manager 42. The dialogue manager 42 then sends a second event e2 to the task manager 43. The second event e2 corresponds to a request to know the semantic interpretation of the first event and to determine what must be the behavior of the application. A third event e3 is issued from the task manager 43 to the dialogue manager 42 corresponding to a response to the previous request. 1 o The third event e3 specifies what is the call to the application to be performed. In this example, it is a system call if corresponding to a connection procedure. This procedure is external to the task model, and only a reference (here its name) can find it. Then it is up to the dialog manager to call this procedure. Thus, the task template is completely independent of the contents of this procedure. A fourth event e4 corresponds to the system call s, the connection procedure made by the dialogue manager 42 to the controller 46. The controller 46 responds with a fifth event e5 after the connection procedure has been executed. This procedure verifies the user's ID and password. The connection procedure provides a binary response (affirmative or negative) indicating whether the user is allowed to connect, as well as the parameters 36 required by the task template 25 (the flight list). In this example, the user is allowed to connect to the application. The dialog manager 42 then sends a sixth event e6 to the task manager 4. The sixth event e6 is a query to know the semantic interpretation of the fifth event e5. The manager only responds to requests and memorizes the state of the user. It therefore memorizes that the new state is connected and creates a seventh event e7 making this response to the dialogue manager 42 with the corresponding parameters (the flight list).

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 The dialogue manager 42 sends an e8 e8 event to the view 41 to communicate the new state of the user and the parameters to be displayed. The view can then present an appropriate window displaying the list of vol.5

Claims

A method for managing the interaction of at least one application with at least one user, the behavior of said application being dependent on the context of use, defined in particular by a history of the user's activity, comprising: a step of creating at least one model, said model dynamically representing the application and its data, a step of creating at least one view, said view presenting the data of the model to the user and capturing the events users, a step of creating at least one controller, said controller defining the behavior of the application by matching the user events with alterations of the model, characterized in that it furthermore comprises a step of creating 15 an interaction module performing the semantic interpretation of the events exchanged between the view and the controller, said semantic interpretation making it possible to adapt er the events exchanged and check the consistency between the user's interactions and the context of use. 20

2. A method of managing interactions of an application with at least one user according to claim 1, characterized in that the interaction module comprises in particular: means for transmitting events between the view the controller, means for creating new events, means for filtering, deleting and altering events, means for adapting information from the user or to the user. 30

3. A method for managing interactions of an application with at least one user according to claim 1 or 2, characterized in that the interaction module further comprises means for transmitting events between the view and the controller by introducing a time shift. 10

4. A method for managing the interactions of an application with at least one user according to one of claims 1, 2 or 3, characterized in that the interaction module is produced with a static model, defined in the design. of the application.

5. A method for managing interactions of an application with at least one user according to one of claims 1, 2 or 3, characterized in that the interaction module is made with a dynamic model 1 o can be modified when the execution of the application.

6. A method of managing the interactions of an application with at least one user according to claim 5, characterized in that the interaction module realizes the semantic interpretation of the events using a task model. said task model comprising in particular: a sequence of tasks to be performed by the user, events that may occur, a description of the interactions to be performed when an event occurs, the necessary triggering conditions of said interactions, the information to be provided back by said interactions, a current state of the user in his task. 25

7. A method for managing interactions of an application with at least one user according to claim 6, characterized in that the interaction module comprises: a task manager for managing in real time the task models, a database of given to store task templates. 30

8. A method for managing interactions of an application with at least one user according to claim 7, characterized in that the interaction module further comprises a dialog manager interface between the interaction module, the view and the controller.