Modèles d’architecture logicielle pour l’interaction homme-

Un aspect incontournable

Le choix de l’architecture logicielle est central dans la conception logicielle de

sys-tèmes interactifs. Avec les progrès technologiques et la croissante complexité de

la partie interactive des systèmes logiciels au début des années 90, l’architecture

logicielle pour l’IHM a donné lieu à plusieurs travaux [Coutaz, 1993].

Le degré de complexité des systèmes interactifs atteint aujourd’hui un tel

ni-veau que même le développement de prototypes interactifs ne peut ignorer ces

considérations architecturales. Pour une approche de prototypage rapide

d’inter-faces multimodales, deux caractéristiques de l’architecture sont particulièrement

importantes : l’indépendance de la partie interactive du noyau de l’application et

la réutilisation des modules logiciels de la partie interactive.

L’indépendance interface-noyau permet idéalement de tester différents

proto-types d’interaction sans modifier le code du noyau. La réutilisation logicielle

per-met quant à elle d’accélerer le cycle de vie du prototypage par la réutilisation de

solutions déjà existantes.

Modèle de Seeheim

Le modèle de Seeheim [Pfaff et Hagen, 1985] est un des premiers patrons

d’archi-tecture logicielle à structurer l’interface homme-machine au sein d’un système

in-teractif. Ce modèle est issu d’un atelier de travail sur le thèmeUser Interface

Mana-gement Serviceorganisé dans la ville de Seeheim (Allemagne) en 1985.

10«A service is a contractually defined behavior that can be implemented and provided by any component for use by any component, based solely on the contract.»[Bieber et Carpenter, 2001]

64 CHAPITRE 3. ETAT DE L’ART DES MODÈLES CONCEPTUELS

Le modèle de Seeheim décompose le code de l’interface en trois parties

princi-pales (Figure 3.31) :

• LaPrésentationgère l’interaction avec l’utilisateur. Elle interprète les actions

de l’utilisateur (interaction en entrée) et génère l’affichage (interaction en

sor-tie).

• LeContrôleur de dialoguegère le séquencement des entrées et des sorties.

• L’Interface du noyau fonctionnel gère la communication entre les

en-trées/sorties et l’application.

F

IGURE

3.31 – Modèle de Seeheim. Illustration extraite de [Coutaz, 1993].

Le modèle de Seeheim a permis pour la première fois de séparer l’interface du

noyau fonctionnel (noté Application dans le modèle Seeheim). Cette séparation

permet entre autre de modifier l’interface sans que cela ait un impact sur le noyau

fonctionnel.

Modèle Arch

Le modèle Arch [UIMS, 1992] étend la décomposition fonctionnelle du modèle

See-heim et est aussi appelé "SeeSee-heim-revisited". En particulier, Arch reprend les

no-tions de noyau fonctionnel, de contrôleur de dialogue et de présentation. L’objectif

du modèle Arch était de proposer un modèle d’architecture qui soit indépendant

des évolutions technologiques.

Le nom du modèle répond à sa forme en arche (Figure 3.32) . Les différents

composants de l’arche sont les suivants :

• Lenoyau fonctionnelimplémente les concepts du domaine.

• L’adaptateur de domaineajuste les différences de modélisation entre le noyau

fonctionnel et le contrôleur de dialogue.

• Le contrôleur de dialogue gère l’enchaînement des tâches ainsi que le lien

entre les couches adjacentes : la couche de présentation et l’adaptateur de

do-maine.

• Lecomposant de présentationgère l’interaction avec l’utilisateur. Il interprète

les actions de l’utilisateur (interaction en entrée) et génère l’affichage

(interac-tion en sortie).

• Lecomposant d’interactiongère le contact direct avec l’utilisateur et est

sou-vent implémenté au moyen d’une boîte à outils.

3.3. MODÈLES DE CONCEPTION LOGICIELLE 65

F

IGURE

3.32 – Modèle Arch. Illustration extraite de [UIMS, 1992].

L’importance relative des cinq composants de Arch varie en fonction du cas à

traiter. Cette variation reposant sur le métamodèle Slinky permet de définir

plu-sieurs modèles d’architecture Arch.

Métamodèle Slinky

Le métamodèle Slinky [UIMS, 1992] exprime métaphoriquement la migration des

fonctions dans le modèle Arch. Le nom du métamodèle provient de ce jouet en

forme de ressort qui se déplace dynamiquement une fois mis en mouvement

(Fi-gure 3.33).

F

IGURE

3.33 – Métamodèle Slinky. Illustration extraite de [UIMS, 1992].

Slinky permet la définition de différentes instances du modèle Arch, selon la

ma-nière dont les fonctions migrent (Figure 3.33). Cela permet d’adapter l’architecture

66 CHAPITRE 3. ETAT DE L’ART DES MODÈLES CONCEPTUELS

aux critères de conception du cas à traiter, comme la performance, la réutilisation

de code, le coût de développement, la complexité de la spécification...

Modèle MVC

Le modèle MVC (Modèle-Vue-Contrôleur) [Krasner et Pope, 1988] fut

conçu au Xerox Parc à la fin des années 70 pour le système Smalltalk

[Goldberg et Robson, 1983]. L’objectif de ce modèle était de rendre explicite le

modèle des données et de permettre à l’utilisateur d’inspecter et modifier ces

données.

Ce modèle considère trois composants différents (Figure 3.34) :

• LeModèlereprésente le modèle de données de l’application.

• LaVuereprésente l’interface avec l’utilisateur.

• LeContrôleurgère la communication et la synchronisation entre la vue et le

modèle.

F

IGURE

3.34 – Modèle MVC tel que défini par Xerox Parc.

Le modèle MVC a été largement utilisé dans la création de systèmes interactifs.

De plus, MVC est aussi utilisé pour structurer des éléments graphiques dans des

boîtes à outils comme Swing [Tucker, 2000] ou Cocoa [Apple, 2010]. Par exemple,

les composants de la boîte à outils Swing de Java, comme les listes (JList), les tables

(JTable) ou les arbres (JTree), utilisent MVC afin de séparer les données de la

repré-sentation [Tucker, 2000].

La création de systèmes interactifs avec MVC peut s’avérer lourde à

pro-grammer, en particulier à cause de la grande quantité de classes à

implémen-ter. Cela devient encore plus évident dans le cadre d’applications complexes

[Martinet al., 2005].

Néanmoins le modèle MVC a été largement appliqué et a donné lieu à

diffé-rentes variations. La Figure 3.35 illustre l’adaptation du modèle MVC réalisée par

Apple pour Cocoa. Cette implémentation donne plus de poids au contrôleur et

sé-pare d’avantages la vue et le modèle.

Cette solution architecturale (MVC dans Cocoa) est en fait beaucoup plus proche

du modèle PAC présenté dans le paragraphe suivant que de MVC. De nombreux

3.3. MODÈLES DE CONCEPTION LOGICIELLE 67

F

IGURE

3.35 – Modèle MVC utilisé par Apple dans Cocoa.

blogs sur le www discutent cette architecture présentée comme issue du modèle

MVC et qui est plus proche du modèle PAC.

Modèle PAC

Comme MVC, le modèle PAC (Presentation-Abstraction-Contrôle) [Coutaz, 1987]

est basé sur la notion d’agent. Un agent dans PAC est composé de trois facettes :

• La Présentationdéfinit la syntaxe concrète de l’agent, c’est-à-dire l’entrée et

la sortie de l’agent.

• L’Abstraction représente la sémantique de l’agent, c’est-à-dire les fonctions

que l’agent peut réaliser (les tâches).

• LeContrôlegère la cohérence entre la Présentation et l’Abstraction.

F

IGURE

3.36 – Objet interactif dans le modèle PAC. Illustration extraite de [Coutaz, 1987].

La Figure 3.36 illustre les trois facettes d’un agent implémentant un objet

inter-actif simple. La Présentation de cet objet est composé d’une interface en sortie, un

camembert, et d’une interface en entrée, l’interaction directe avec la souris sur le

camembert. L’Abstraction de cet objet est une valeur entière comprise entre deux

limites, 0 et 400 (dans l’exemple de la Figure 3.36, valeur égale à 50). Le Contrôle

maintient la cohérence entre la Présentation et l’Abstraction. Par exemple, si

l’utili-sateur modifie la taille d’une part du camembert, le Contrôle va demander la mise

à jour de la valeur de l’entier dans l’Abstraction.

Une application interactive dans PAC est alors composée de plusieurs agents

(Figure 3.37). Les agents sont connectés entre eux à travers des Contrôles.

68 CHAPITRE 3. ETAT DE L’ART DES MODÈLES CONCEPTUELS

F

IGURE

3.37 – Application interactive structurée selon le modèle PAC. Illustration extraite

de [Coutaz, 1987].

Modèle PAC-Amodeus

Le modèle PAC-Amodeus [Nigay et Coutaz, 1991] étend le modèle Arch en affinant

la facette Contrôle par une hiérarchie d’agents PAC (Figure 3.38).

F

IGURE

3.38 – Modèle Arch (à gauche) et PAC-Amodeus (à droite). Illustration extraite de

[Nigay et Coutaz, 1991].

Le contrôleur de dialogue, souvent sous-décrit dans les autres modèles bien que

central comme en témoigne sa position dans le modèle Arch, est composé ici d’un

ensemble d’agents collaborant afin de gérer les correspondances entres les tâches

du noyau fonctionnel et l’interaction.

3.3.5 Conclusion

Comme pour les modèles de conception de l’interaction (section 3.2), nous avons

opté pour une approche ascendante dans l’analyse des modèles de conception

lo-gicielle. Pour cela nous avons d’abord étudié les modèles de programmation de

l’interaction, puis les modèles de programmation pour la réutilisation qui reposent

sur une structuration du code en briques logicielles élémentaires que ce soient des

agents, des composants ou des services. Nous finissons par les modèles

d’archi-tecture logicielle qui fournissent une décomposition fonctionnelle à haut niveau

d’abstraction d’un système interactif (Figure 3.39).

Dans le document Interaction multimodale en entrée : Conception et Prototypage (Page 84-90)