Architecture MDA de l’approche propos´ee
3.4 Le niveau PIM : mod` ele PIIM
´
Etant donn´e que le niveau PIM est ind´ependant de la plateforme, il est important de trouver un mod`ele permettant de respecter un compromis entre les contraintes suivantes : a) Pouvoir traduire les aspects du mod`ele des tˆaches, du niveau CIM ;
c) ˆEtre suffisamment g´en´erique pour garder son ind´ependance de toute plateforme parti-culi`ere.
L’approche traditionnelle pour r´esoudre le probl`eme de description d’une IHM, ind´ependamment de la plateforme, consiste `a ´ecrire diff´erentes versions pour chaque type de plateforme. Cela n´ecessite le d´eveloppement de nombreuses versions autant que le nombre de plateformes, ce qui peut induire des probl`emes de maintenance et de coh´erence. Afin de pallier `a ces probl`emes, il sera int´eressant de faire appel `a un format g´en´erique, flexible qui permet la description de tout type de plateformes. Pour r´epondre aux contraintes (a) et (b), nous avons propos´e le PIIM (Platform Independent Interaction Model) qui repose sur le langage UIML (cf. chapitre 3, §3.4.1) et afin de r´epondre `a la troisi`eme contrainte (c), nous avons eu recours `a un vocabulaire g´en´erique (cf. chapitre 3, §3.4.2).
3.4.1 Le mod`ele PIIM
Afin de d´efinir notre mod`ele PIIM, nous avons eu recours au langage UIML. Ce langage a retenu notre int´erˆet ´etant donn´e que :
– UIML est un m´eta-langage. Il d´efinit un ensemble de balises qui sont ind´ependantes de toute modalit´e d’interaction, de toute plateforme cible (PC, t´el´ephone, etc.) et de tout langage de d´eveloppement (Java, C#, etc.). La sp´ecification d’une interface utilisateur se fait `a travers un vocabulaire qui sp´ecifie un ensemble de parties qui constituent l’interface ainsi que l’ensemble des propri´et´es de ces parties.
– UIML s´epare les ´el´ements d’une interface utilisateur et identifie l’ensemble des parties composant l’interface et leurs styles de pr´esentation ; le contenu de chaque partie ainsi que sa liaison avec des ressources externes ; et le comportement de chaque partie, exprim´e comme un ensemble de r`egles avec des conditions et des actions.
– UIML permet de grouper les diff´erentes parties de l’interface sous forme d’arbre dont la structure peut changer dynamiquement.
– UIML permet aux diff´erentes parties de l’interface d’ˆetre d´efinies dans des mod`eles (template) : ces mod`eles peuvent ˆetre r´eutilis´es, par la suite, dans la mod´elisation d’autres IHM.
– UIML fournit la possibilit´e de travailler avec des informations dynamiques et de traduire le passage du flux d’information entre les tˆaches du mod`ele CIM. En effet, la notion de variable introduite dans la version 4.0 de UIML peut ˆetre exploitable pour ce passage de flux (cf. chapitre 4, §4.3).
– Il existe plusieurs outils permettant la conversion du code UIML vers d’autre langages de programmation (cf. chapitre 4, §4.1.2.3).
Notre mod`ele PIIM est compos´e des parties structure, behavior, content, et style. Pour manipuler le contenu, UIML offre deux choix : soit de l’int´egrer dans la partie style, soit de le s´eparer dans la partie content. La seconde alternative est utile uniquement si les concepteurs veulent attribuer plusieurs contenus `a un ´el´ement d’interaction et seulement si le contenu en sortie est connu d’avance. Pour cette raison, nous avons adopt´e le premier
choix en y int´egrant le contenu dans la partie style. Dans le PIIM, la partie style contient uniquement les propri´et´es li´ees au contenu.
En UIML, la partie structure est compos´ee d’un ensemble de parties nomm´ees parts. Chaque part est dot´ee d’un ensemble de propri´et´es qui permettent de la caract´eriser. Afin que notre mod`ele PIIM soit ind´ependant de la plateforme, nous avons eu recours `a un vocabulaire g´en´erique permettant de sp´ecifier l’ensemble des parts ainsi que leurs propri´et´es d’une mani`ere ind´ependante de la plateforme. Dans ce qui suit, nous pr´esentons ce vocabulaire.
3.4.2 Vocabulaire g´en´erique
Le but du vocabulaire g´en´erique est de fournir aux concepteurs, un moyen qui leur permet de cr´eer des IHM ind´ependamment de toute plateforme et de tout langage de d´eveloppement. Un vocabulaire g´en´erique permet de :
- Fournir un ensemble de widgets g´en´eriques communs entre les diff´erentes plateformes. Ces widgets peuvent par la suite ˆetre mapp´es vers d’autres qui sont sp´ecifiques `a une plateforme cible. Ces widgets peuvent ˆetre divis´es en deux types : les conteneurs qui repr´esentent les ´el´ements qui peuvent en contenir d’autres ; les contrˆoleurs qui repr´esentent les widgets ´el´ementaires. Le Tableau 3.6 d´efinit l’ensemble des widgets g´en´eriques dont les pluparts ont ´et´e propos´es par (Harmonia, 2002) ;
Table3.6 – D´efinitions des widgets g´en´eriques ´
El´ement D´efinition
C
on
te
n
eu
rs G :TopContainer Le conteneur g´en´erique qui contient tous les autrescomposants de l’IHM G :Area Il repr´esente une partie de son conteneur
G :SplitArea Il repr´esente une sous-partie du G :Area G :Menu Il d´ecrit tout type de menu
G :Group Il regroupe un ensemble d’autres ´el´ements d’une mani`ere logique
G :List Il d´ecrit une s´equence ordonn´ee d’autres ´el´ements
C
on
tr
ˆol
eu
rs G :ButtonG :Dialog Le contrˆole qui repr´esente un seul mode d’interactionUn ´el´ement qui permet de contenir un ensemble d’informations `a retourner `a l’utilisateur
G :Label Il contient le label de n’importe quel autre ´el´ement d’interaction
G :MenuItem Il repr´esente une partie ´el´ementaire du G :Menu G :CheckBoxButton Il permet de choisir ou pas un ´el´ement
G :TextRegion Il fournit `a l’utilisateur la possibilit´e d’entrer des informations
- Cr´eer un ensemble g´en´erique de propri´et´es pour d´efinir tous les aspects de base de chaque widget g´en´erique (ex. la propri´et´e g :text permet de sp´ecifier le texte associ´e `a un widget ; g :selected permet de v´erifier si un widget est s´electionn´e ou pas ; et g :enabled permet de d´ecider si le widget est autoris´e pour ˆetre affich´e...). Pour connaitre la totalit´e des propri´et´es disponibles, le lecteur peut se r´ef´erer au (Harmonia, 2002).