Pour des raisons de maîtrise de la complexité et des coûts, les multiples dimensions de la notion de contexte imposent de mettre en place des solutions modulaires, standardisées mais suffisamment flexibles non seulement pour supporter la combinatoire qui en résulte, mais aussi pour anticiper le support de dispositifs d’interaction innovants (gants numériques, objets communicants à base de technologie RFID7, etc.).
Avec un tel objectif, les approches à base de modèles prennent une importance capitale car elles proposent des solutions modulaires dans des démarches descendantes de spécification et de construction de systèmes interactifs. Le problème dans ces approches est que les liens entre ces modèles les uns avec les autres et surtout entre le modèle du domaine et les autres modèles restent plus ou moins explicites selon les approches. Un besoin émerge alors clairement. Comment exprimer d’une façon claire et explicite les relations entre les
modèles de la présentation ou le modèle des tâches d’un côté et le modèle du domaine de l’autre ?
Pour répondre à cette question, nous nous sommes appuyés tout d’abord sur l’expertise que nous avions développée à l’occasion de la thèse de doctorat dans le domaine des modèles d’architecture logicielle (Tarpin-Bernard, 1997). En effet, le modèle d'architecture logicielle constitue un des éléments indispensables sur lequel s'appuie le génie logiciel moderne. Il systématise à la fois l'élaboration et l'utilisation des logiciels et joue un rôle primordial dans leur qualité et leur efficacité. Garlan et Perry soulignent le fait que l'utilisation de modèles d'architecture peut avoir des effets bénéfiques sur au moins cinq aspects du développement des logiciels (Garlan et al., 1995) :
o la compréhension est simplifiée en présentant la structure de grands systèmes à un niveau d'abstraction adapté. Les contraintes et choix de conception peuvent ainsi être mieux explicités et expliqués ;
o la réutilisation est favorisée. Bien sûr, la réutilisation des composants est largement encouragée par la définition d'architectures, mais il est également possible de réutiliser des structures plus complexes définies sous forme de motifs de conception ou design patterns ;
o l'évolution et la maintenance profitent largement de la définition d'architectures logicielles. En comprenant les ramifications et les connexions de chaque composant, il est beaucoup plus facile de déterminer a priori les coûts potentiels de toute modification ;
o l'analyse des systèmes est simplifiée. Suivant les modèles utilisés, on peut envisager des formes de vérification de cohérence, de respect de styles, de satisfaction de critères de qualité voire d'adaptation à des domaines spécifiques d'application ;
o la gestion des projets industriels doit s'appuyer sur cet élément essentiel pour déterminer au plus tôt la viabilité des options choisies, les prérequis indispensables et les perspectives d'évolution.
Nous adhérons à l'analyse de Garlan et Perry et nous considérons que, par le
rapprochement du modèle de fonctionnement et du modèle d'utilisation, le découpage
en entités autonomes peut servir de support d'explication et être utile non seulement aux concepteurs mais également aux utilisateurs. En intégrant les mécanismes et contraintes du système, ils peuvent mieux se l'approprier. Le modèle d'architecture constitue le pivot des activités d'élaboration (spécification, conception et réalisation). On peut ainsi spécifier quatre objectifs pour le modèle d’architecture :
o servir de support lors de la spécification (en tant que formalisme) ; o constituer l'ossature de la réalisation (en tant que framework) ; o assurer la cohérence de fonctionnement à l’exécution (au runtime)
o servir de guide d'utilisation et/ou de support à la reconfiguration par l’utilisateur. Les modèles d’architecture partent du principe qu'un système interactif comporte une partie interface et une partie noyau fonctionnel qui se réfère au domaine de l’application. Le noyau fonctionnel est considéré comme préexistant, et les modèles de systèmes interactifs décrivent essentiellement la partie interface et ses relations avec les objets du domaine.
La plupart des modèles identifient au moins trois types d'éléments : o les éléments en contact direct avec l'utilisateur (présentations) ;
o les éléments en contact direct avec le noyau fonctionnel ou qui en font partie (abstractions, interfaces du noyau fonctionnel, etc.) ;
o les éléments de communication entre les deux premiers éléments (contrôleurs, adaptateurs).
Malgré ces points communs, certains modèles procèdent d’approches différentes, et ne se limitent pas à ce découpage sommaire. Nous ne détaillerons pas ici les différents modèles d'architecture mais notons simplement qu’ils peuvent être classés en trois grandes catégories. Les modèles à couches décrivent la structure globale d'une application interactive sous forme de couches logiques (ex : Seeheim (Pfaff, 1985) et Arch (UIMS, 1992)). Ces modèles sont également appelés modèles logiques, ou sont qualifiés d'abstraits. Les modèles à agents, ou encore modèles orientés objet (ex : MVC (Goldberg, 1984), PAC (Coutaz, 1987), AMF (Ouadou, 1994)). Ces modèles proposent une décomposition de l’application en un ensemble d'agents communicants séparant en leur sein l’interface du noyau fonctionnel. Enfin, des modèles mixtes tel que PAC-Amodeus (Nigay, 1993) ou H4 (Guittet, 1995) tentent de tirer partie des avantages respectifs de ces deux approches.
Figure 3 : Les composants du modèle Arch
Rappelons rapidement les bases du modèle Arch (Figure 3). Du côté du pilier applicatif, il distingue 2 niveaux :
o le noyau fonctionnel de l’application qui gère les données internes et leur rémanence ;
o l’adaptateur du noyau fonctionnel qui est un composant médiateur entre le contrôleur de dialogue et le noyau fonctionnel. Il est responsable de la réorganisation des données du domaine dans des buts de manipulation interactive, ou de la détection des erreurs sémantiques.
Du côté du « pilier » présentation, il décompose l’interface utilisateur en 2 niveaux :
o un niveau abstrait, comportant les objets de présentation et d’interaction indépendants de l’interface concrète et donc des dispositifs d’interaction avec l’utilisateur ;
o un niveau concret, lié à un « toolkit graphique » précis, gérant le dialogue avec l’utilisateur (et donc lié à des dispositifs d’entrée/sortie précis).
Dans le modèle original (UIMS, 1992) ces deux couches sont appelées (Presentation Component ) et (Interaction Toolkit Component) ce qui, en référence à MVC, peut porter à confusion en laissant sous-entendre qu’une couche est dédiée aux sorties (affichage à l’écran) alors que l’autre se consacre aux entrées (souris, clavier) ce qui est évidement faux. C’est pourquoi, nous rencontrons dans la littérature d’autres termes comme « Présentation logique » et « Présentation physique ». Mais le mot « physique » ne nous semble pas approprié car, l’usage de ce mot peut prêter à confusion avec les objets physiques ou l’instrument d’interaction. Nous trouvons que « Présentation et Interaction abstraites » et « Présentation et Interaction concrètes » proposés par (Chalon, 2004) sont plus appropriés.
On le voit, les modèles d’architecture ont naturellement vocation à créer un lien entre le modèle du domaine (traduit par le noyau fonctionnel) et les modèles de l’IHM (traduit par la présentation). De fait, nous pensons qu’il est possible de définir un modèle d’architecture comme modèle central dans le processus de conception, de développement, d’adaptation et d’exécution, ce que nous appelons le modèle d’interaction. Les objectifs d’un tel modèle sont donc :
Noyau Fonctionnel Adaptateur du Noyau Fonctionnel Contrôleur deDialogue Présentation et interaction Abstraites Présentation et interaction Concrètes Données Utilisateur
o jouer le rôle de chef d’orchestre du système interactif en assurant le contrôle du système ;
o être composable par éléments pour se doter de capacités de réutilisation ;
o s’intégrer dans un processus de spécification descendante (conceptuel, abstrait, concret, final).
L’architecture AMF que nous avions largement enrichie à l’occasion de nos travaux sur les systèmes collaboratifs (AMF-C) apporte plusieurs éléments de réponse à nos besoins et peut être étendue pour satisfaire l’ensemble de nos prérequis. Dans les sections qui suivent, nous présentons plus en détail le modèle AMF puis son utilisation comme modèle d’interaction.