(« 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 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 vignette|L'architecture dans le MMI Runtime Framework|250px|gauche 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.

vignette|Le Modèle MVC dans MMI-Arch|250px|droite La recommandation 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.

vignette|L'imbrication dans l'architecture MMI|250px|droite

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 vignette|Modules de l'Architecture|250px|droite 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.

vignette|Abstraction des entrées avec les Modality Components|1094px|centré

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.

vignette|Le composant de données publiques et privées|250px|droite 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'autres 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.

vignette|Les événements définis dans l'architecture MMI|250px|droite 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 : <mmi:mmi xmlns:mmi="http://www.w3.org/2008/04/mmi-arch" version="1.0"> <mmi:newContextRequest requestID="myReq1" source="myPointerMC.php" target="myIM.php" data="myMCStatus.xml" /> </mmi:mmi> À cette requête le contrôleur d'interaction donnera comme réponse : <mmi:mmi xmlns:mmi="http://www.w3.org/2008/04/mmi-arch" version="1.0"> <mmi:newContextResponse requestID="myReq1" source="myIM.php" target="myPointerMC.php" context="myContextID1" status="success" /> </mmi:mmi> 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 : <mmi:mmi xmlns:mmi="http://www.w3.org/2008/04/mmi-arch" version="1.0"> <mmi:clearContextRequest requestID="myReq2" source="myPointerMC.php" target="myIM.php" context="myContextID1" /> </mmi:mmi> Lors de la réception de la requête le composant de modalité peut donner comme réponse : <mmi:mmi xmlns:mmi="http://www.w3.org/2008/04/mmi-arch" version="1.0"> <mmi:clearContextResponse requestID="myReq2" source="myPointerMC.php" target="myIM.php" context="myContextID1" status="success" /> </mmi:mmi>