# Multimodal Architecture and Interfaces

Multimodal Architecture and Interfaces (« architecture multimodale et interfaces » en anglais) ou MMI-Arch est un standard ouvert en développement par le W3C depuis 2005. Depuis 2010 est une recommandation d'architecture à composants conteneurs du W3C. Le document est le rapport technique de spécification d'une architecture informatique générique et de ses interfaces pour faciliter l’intégration et la gestion des interactions multimodales dans un environnement informatique. Il a été produit par le groupe de travail en Interaction multimodale du W3C.

## Description

La recommandation Multimodal Architecture and Interfaces se concentre sur la proposition d'un cadre général pour permettre aux modules requis dans un système multimodal, de communiquer les uns avec les autres.
Cette spécification propose une architecture orientée évènement dont le principal objet est le flux de données de contrôle car en tant que cadre général de référence, elle sert à déterminer les infrastructures de base utiles pour le contrôle de l'application et des services multimodaux.
L'architecture est aussi proposée pour faciliter la tâche d'implémentation à plusieurs types de dispositifs fournisseurs de services multimodaux, comme les dispositifs mobiles et portables, les appareils électroménagers, l'internet des objets, la télévision et les réseaux domestiques, les applications d'entreprise, les applications web, les voitures "intelligentes" ou comme les applications médicales.

### Structure Logique

Multimodal Architecture and Interfaces est la description spécifiée d'une infrastructure de services plus large appelée The Runtime Framework dans laquelle sont fournies les principales fonctions dont un système multimodal a besoin et qui se trouve a un niveau d'abstraction plus haut que l'architecture MMI. Ce framework est le support d'exécution et de communication des modules du système multimodal tandis que l'architecture MMI est la description et la spécification de ses principaux modules, ses interfaces et son mode de communication.
La recommandation Multimodal Architecture and Interfaces s'inspire du patron de conception d'architecture applicative MVC qui organise la structure des interfaces utilisateur en trois parties : le Modèle, la Vue et le Contrôleur.
Une particularité de cette architecture c'est que bien que la couche de présentation représentée par la Vue a été traditionnellement appliquée aux interfaces graphiques; cette recommandation généralise l'abstraction au contexte plus large de l'interaction multimodale où l'utilisateur peut utiliser une combinaison de modalités visuelles, auditives, biométriques et/ou tactiles.
L'architecture MMI fait donc la distinction entre le contrôleur d'interaction (Interaction Manager - IM), le composant de données (Data Component - DC) et les composants modalité (Modality Components - MC). Cette distinction est similaire à la distinction entre le Contrôleur, le Modèle et les documents de présentation de la Vue dans le patron MVC.
Une autre particularité est l'imbrication. Les modules étant des boîtes noires, il est possible d'encapsuler plusieurs composants dans un composant plus complexe, qui communiquerait avec un contrôleur de plus haut niveau. De cette manière l'architecture suit le principe des poupées russes.
La recommandation propose aussi une mise en œuvre de façon distribuée sur plusieurs supports matériels en réseau ou de façon centralisée, avec tous les modules sur un même support matériel. L'échange d'information entre les différents modules se fait avec un couplage lâche qui favorise la faible dépendance entre les modules, la réduction de l'impact des changements dans un module et la réutilisation des modules. De cette manière les modules ont peu ou aucune connaissance du fonctionnement des autres modules et la communication entre les modules se fait grâce à l'échange de messages selon un protocole de communication précis à travers les interfaces de programmation fournies par l'architecture MMI.

## Les modules de l'Architecture MMI
### Le contrôleur d'interaction (Interaction Manager)

Le contrôleur d'Interaction est un composant logique, chargé de tous les échanges de messages entre les composants de modalité du système et l'infrastructure multimodale (le Runtime Framework). Il est un bus de communication et un gestionnaire d'évènements.
Chaque application peut configurer au moins un contrôleur d'interaction (Interaction Manager) pour définir la logique d'interaction souhaitée. Ce contrôleur est au cœur de l'interaction multimodale:
* Il gère les comportements spécifiques déclenchés par les messages échangés entre les différents modules d'entrée et de sortie.
* Il gère la communication entre les modules et l'application cliente.
* Il assure la cohérence entre plusieurs entrées et sorties et fournit une perception de l'état général de l’application.
* Il est responsable de la synchronisation des données.
* Il est responsable de la gestion du focus.
* Il gère la communication avec toute entité externe au système.

### Les composants de modalité (Modality Component)

Les composants de modalité sont responsables de tâches spécifiques, notamment la manipulation des entrées et des sorties dans les diverses modalités, comme la parole, l'écriture, la vidéo, etc. Ce sont des entités logiques responsables du contrôle des entrées et des sorties des différents dispositifs matériels (microphone, tablette graphique, clavier) et logiciels (détection de mouvement, changements biométriques) associés au système multimodal. Par exemple (voir diagramme ci-dessous), un composant de modalité A peut se charger de la reconnaissance de la parole avec la gestion des entrées audio. Un autre composant de modalité B peut gérer plutôt les entrées complémentaires provenant de deux dispositifs différents : une tablette graphique et un microphone. Deux composants de modalité C, peuvent gérer séparément deux entrées complémentaires fournies par un même dispositif: une caméra vidéo. Un dernier composant de modelité D, peut utiliser un service externe de reconnaissance et ne contenir que le contrôle des échanges nécessaires à la reconnaissance.
Dans les quatre cas le système possède un composant de modalité pour la détection des commandes vocales en entrée, malgré les différences d'implémentation: le composant de modalité étant une abstraction d'un type d'entrée qui est gérée et implémentée de manière différente à chaque cas. Tout composant de modalité peut éventuellement envelopper de multiples fonctionnalités fournies par plusieurs périphériques physiques, mais aussi plusieurs composants de modalité pourraient être inclus dans un seul appareil. Pour cette raison, la recommandation du W3C dans son état actuel ne décrit pas en détail la structure ou l'implémentation des composants de modalité. Elle porte seulement sur la nécessité de prévoir une interface de communication avec le contrôleur d'interaction et une implémentation qui respecte un protocole de communication précis: les Life-Cycle Events.

### Le composant de données (Data Component)

Le composant de données a pour rôle de sauvegarder les données publiques de l'application qui peuvent être requises par plusieurs composants de modalité ou par d'autre modules (par exemple, le module de session du framework MMI).
Le composant de données peut être un module interne A au contrôleur d'interaction ou externe B (voir diagramme). Ceci dépend de l'implémentation choisie par chaque application. Toutefois le contrôleur d'interaction est le seul à avoir un accès direct au composant de données et lui seul peut consulter et modifier ses données et même communiquer avec des serveurs externes si besoin. En conséquence, les composants de modalité doivent se servir du contrôleur comme intermédiaire pour accéder aux données publiques de l'application multimodale.
En revanche, pour le stockage des données privées, chaque composant de modalité peut implémenter son propre composant de données qui lui-même peut accéder aussi à des serveurs externes B et garder les données dont le composant de modalité peut avoir besoin, par exemple, pour la tâche de reconnaissance de la parole. Ceci peut être un cas d'implémentation du principe des poupées russes de l'architecture MMI.

## Protocole de communication entre les différents modules

Dans l'architecture MMI le protocole de communication est asynchrone, bi-directionnel et il est basé sur l'échange de notifications d'événements qui sont levés par le système à la suite d'une action de l’utilisateur ou par une activité interne.
Ce protocole définit le mode de communication et la façon d'établir et de terminer la communication. Dans le cas de cette recommandation, il est reflété dans les Life-Cycle Events. Ce sont des événements de contrôle de base qui sont proposés pour la commande des dispositifs et services matériels (par exemple un lecteur vidéo ou un appareil de reproduction sonore) et des notifications pour le monitoring de l'état du système multimodal.

### Les événements de base (Standard Life-Cycle Events)

La spécification propose huit Life-Cycle Events de base qui sont spécifiés sous la forme des paires d'échanges Request > Response:
* NewContext (NewContextRequest / NewContextResponse)
    Indique la création d'un cycle d'interaction (un contexte) entre zéro, un ou plusieurs utilisateur avec une modalité ou plusieurs modalités. Le contexte représente la période la plus longue d'interaction pendant laquelle les modules doivent garder l'information.
    Le contexte est associé à la sémantique de l'activité de l'utilisateur et du système pendant le cycle d'interaction ; ceci permet de décider si garder l'information a encore un sens en vue du déroulement de l'activité courante.
    Généralement le contexte est créé à partir d'une entrée utilisateur. L'évènement est normalement envoyé par un ou plusieurs composants de modalité au contrôleur d'interaction qui devrait répondre à la requête.
    Imaginons par exemple, un composant de modalité chargé de gérer les entrées associées au déplacement du doigt (touchmove) dans une page web lue sur un écran tactile. Lors du démarrage de l'interaction le composant de modalité enverra la requête :
    À cette requête le contrôleur d'interaction donnera comme réponse :
    Il est aussi possible que le contrôleur d'interaction soit à l'origine de la requête. Dans ce cas la syntaxe reste la même mais la valeur des propriétés source et target doit changer.
* ClearContext (ClearContextRequest / ClearContextResponse)
    Envoyé par le contrôleur d'interaction, l'évènement indique la fin du cycle d'interaction (le contexte) et demande la libération des ressources qui étaient allouées au contexte d'interaction courant. L'évènement ClearContext peut être associé à la fin de l'activité de l'utilisateur ou du système. Par exemple :
    Lors de la réception de la requête le composant de modalité peut donner comme réponse :
* Prepare (PrepareRequest / PrepareResponse)
    Envoyé par le contrôleur d'interaction cet événement de contrôle signale au composant de modalité qu'il doit se préparer pour le démarrage de sa tâche et qu'il peut charger les données qui seront nécessaires à l'exécution de la même. Par exemple :
    S'il y a plusieurs documents ou données à charger lors de la phase de préparation, le contrôleur d'interaction pourrait déclencher plusieurs fois l'évènement PrepareRequest sans pour autant démarrer la tâche après chaque envoi. Néanmoins, à chaque envoi il devra recevoir une réponse. Dans notre exemple, si le contenu a été correctement préchargé la réponse est :
* Start (StartRequest / StartResponse)
    Envoyé par le contrôleur d'interaction cet événement de contrôle signale au composant de modalité qu'il peut démarrer sa tâche. Par exemple :
    Si pendant l'exécution de sa tâche le composant de modalité reçoit un nouvel évènement StartRequest il peut, soit démarrer au nouveau sa tâche, soit signaler l'échec. Dans le cas d'une exécution réussie la réponse doit être :
    Dans le cas d'un échec la réponse peut être, par exemple :
* Cancel (CancelRequest / CancelResponse)
    Envoyé par le contrôleur d'interaction, cet événement de contrôle signale au composant de modalité qu'il doit arrêter le processus en cours. Par exemple :
    La réponse du composant de modalité peut être :
* Pause (PauseRequest / PauseResponse)
    Envoyé par le contrôleur d'interaction, cet événement de contrôle signale au composant de modalité qu'il doit mettre en pause le processus en cours. Par exemple, la requête pour une composant qui gère les entrées d'une tablette graphique peut être :
    Et la réponse du composant de modalité peut être :
* Resume (ResumeRequest / ResumeResponse)
    Envoyé par le contrôleur d'interaction, cet événement de contrôle signale au composant de modalité qu'il doit reprendre la tâche précédemment mise en pause par un évènement Pause.
    La réponse du composant de modalité peut être :
* Status (StatusRequest / StatusResponse)
    Il est envoyé indifféremment par le contrôleur d'interaction ou par les composants de modalité. Cet événement indique si le cycle d'interaction est encore en cours, c'est-à-dire, si le contexte est "en vie". Par exemple, un composant de modalité peut avoir besoin de surveiller l'état du système pour arrêter un processus en cas de faille ou mise en veille du système. Dans ce cas, il peut envoyer cette requête au contrôleur d'interaction :
    Étant donné que la requête n'indique pas le paramètre context, le contrôleur d'interaction doit fournir l'état du système ou du serveur hôte et pas du contexte courant d'interaction. À cette requête le contrôleur d'interaction peut donc donner comme réponse :

### Les notifications

La spécification propose aussi deux types de notifications dont une, l'Extension Notification, peut contenir des données de contrôle ou de commande des dispositifs ou services matériaux et pour cette raison cette notification est considérée comme un évènement de base qui exceptionnellement n'est pas décrit comme une paire Request > Response (dans des versions précédentes il était appelé l'évènement data). Ces deux notifications sont:
* Extension (ExtensionNotification)
    Cet évènement est utilisé pour communiquer des données de contrôle spécifiques à chaque application. Il peut être généré par le contrôleur d'interaction ou par l'un des composants de modalité indifféremment. Il assure l'extensibilité de l'architecture, dans le sens de donner une API générique dédié aux besoins propres des applications. Par exemple, un composant de modalité qui gère un lecteur DVD peut indiquer au système l'interaction avec le menu principal:
* Done (DoneNotification)
    Cette notification est envoyée par le composant de modalité au contrôleur d'interaction dès qu'il a fini sa tâche. Par exemple, lorsqu'un composant de modalité a fini sa reconnaissance d'image (un visage):