Le mod` ele de mapping

Une fois le mod`ele de contexte d´efini, il est important de d´efinir de quelle fa¸con il sera utilis´e durant la phase de conception des IHM, pour mettre en œuvre la personnalisation du contenu. Nous pensons que le domaine d’application est intimement li´e au contexte. Par exemple, une interface utilisateur n´ecessitant un ensemble d’informations sur l’utilisateur peut avoir recours au mod`ele de contexte utilis´e par le syst`eme (`a partir du profil de l’utilisateur inclus dans le mod`ele de contexte).

La question `a laquelle il faut r´epondre est de savoir comment on peut lier le mod`ele de contexte `a un domaine d’application sp´ecifique. Nous rappelons que le mod`ele du domaine repr´esente le vocabulaire utilis´e pour d´efinir l’ensemble des entr´ees/sorties `a travers l’inter-face utilisateur. Comme nous l’avons d´ecrit pr´ec´edemment dans le chapitre 1, le mod`ele de domaine peut ˆetre d´efini `a travers un diagramme de classes, un mod`ele entit´e-association, ou `a travers une ontologie de domaine. Dans le cadre de cette th`ese, nous avons choisi de d´efinir le vocabulaire de l’application `a travers l’utilisation des ontologies du domaine en raison de leurs capacit´es `a caract´eriser la s´emantique du domaine.

´

Etant donn´e que le domaine est d´ecrit `a travers une ontologie, nous nous sommes pench´es `

a chercher un moyen pour identifier une relation entre les ´el´ements de l’ontologie et ceux du mod`ele de contexte. Pour rem´edier `a ce probl`eme et `a partir d’une analyse de ces ´el´ements, nous avons ´etabli un ensemble de correspondances entre les deux mod`eles, que nous avons incarn´ees dans un mod`ele, appel´e le mod`ele de mapping. Le m´etamod`ele d´efinissant ce mod`ele de mapping est d´ecrit dans la Figure 3.7. Nous avons d´efini trois types de map-pings :

- Mapping direct : lorsqu’un concept de l’ontologie repr´esente exactement la mˆeme information pr´esente dans le mod`ele de contexte, sachant que parfois il peut ˆetre exprim´e avec un nom diff´erent. Cela signifie que l’´el´ement du contexte et l’´el´ement de l’ontologie de domaine ont la mˆeme signification s´emantique. Cette correspondance est faite pour n’importe quel attribut dans le mod`ele de contexte qui n’est pas de type bool´een (par exemple, l’ˆage, le nom de l’utilisateur, etc) ;

- Mapping indicatif : lorsque les informations du contexte indiquent la pr´esence ou l’absence de certaines informations. Ce type de mapping est similaire au mapping direct, sauf que dans ce cas, l’attribut du contexte doit avoir le type bool´een ; - Mapping indirect : lorsque certains ´el´ements du mod`ele de contexte pourraient avoir

une influence indirecte sur un ´el´ement de domaine. Pour d´efinir un mapping indirect, le concepteur doit v´erifier s’il y a des informations dans le mod`ele de domaine qui pourrait changer en fonction des donn´ees mod´elis´ees dans le contexte.

Nous notons que les mappings s’appliquent entre les concepts ou les attributs de l’ontologie de domaine d’une part, et entre les attributs du mod`ele de contexte d’autre part, et qu’il peut y avoir des ´el´ements (concepts ou attributs) qui ne sont dot´es d’aucun mapping. Nous signalons ´egalement la possibilit´e de r´eutilisation des mappings, ´etant donn´e qu’une ontologie de domaine est g´en´eralement utilis´ee pour plusieurs applications dans le mˆeme domaine. Des exemples de mappings seront pr´esent´es dans le chapitre 5.

Figure3.7 – M´etamod`ele de mapping entre le contexte et l’ontologie de domaine

Dans ce qui suit, nous nous r´ef´erons un ´el´ement de l’ontologie (concept ou attribut) par “o” et un attribut du mod`ele de contexte par “c”. Afin de cr´eer un mod`ele de mapping le concepteur pourrait suivre la logique suivante :

. Si “o” et “c” ont le mˆeme sens s´emantique et le type de “c” est diff´erent de Bool´een alors cr´eer un mapping direct entre “o” et “c”.

. Si “o” et “c” ont le mˆeme sens s´emantique et le type de “c” est Bool´een alors cr´eer un mapping indicatif entre “o” et “c”.

. Si la valeur de “o” peut changer en fonction de la valeur de “c” alors cr´eer un mapping indirect entre “o” et “c”.

3.2.3 Le mod`ele d’interaction

Comme indiqu´e dans le chapitre 3, §3.1, ´etant donn´e que nous nous int´eressons `a la per-sonnalisation du contenu d’une mani`ere semi-automatique, il est important de prendre en compte la mani`ere avec laquelle l’information sera pr´esent´ee et par cons´equent consid´erer les ´el´ements d’interaction lors de la conception des IHM. En effet, la mani`ere avec la quelle l’information va ˆetre pr´esent´ee pourrait prendre de nombreuses formes et elle est totalement d´ependante du type de l’´el´ement d’interaction.

Pour cette raison, nous avons propos´e le mod`ele d’interaction (cf. Figure 3.8), qui repr´esente une abstraction des ´el´ements d’interaction pouvant ˆetre utilis´es lors de la conception des IHM d’une mani`ere ind´ependante de toute plateforme d’interaction. Ce mod`ele a ´et´e d´efinit en se basant sur la proposition de (Brossard et al., 2007) `a la quelle nous avons apport´e quelques extensions.

Figure3.8 – Mod`ele d’interaction

Ces ´el´ements d’interaction sont group´es sous le type UIGroup qui repr´esente un groupe-ment logique des ´el´egroupe-ments d’interaction. Ces groupes contiennent des unit´es d’interaction, nomm´ees UIUnit. De mani`ere similaire, les UIUnits sont constitu´es des UIElements qui sont des ´el´ements d’interaction ´el´ementaires comme les ´el´ements de navigation, les ´el´ements d’Entr´ee/Sortie, etc. Ces ´el´ements d’interaction sont pr´efix´es par le terme UIField. Un UI-Field est une abstraction d’un ´el´ement de l’IHM permettant `a l’utilisateur d’interagir avec celle ci. Tous ces ´el´ements sont suppos´es ˆetre r´eutilisables par plusieurs applications `a fin de permettre la cr´eation des applications `a travers leur assemblage. Le Tableau 3.4 pr´esente la d´efinition des ´el´ements du mod`ele d’interaction.

Table 3.4 – Les ´el´ements du mod`ele d’interaction ´

El´ement

d’interaction ^{Sp´ecification}

UIGroup ^{Repr´esente l’espace de travail qui permet de grouper} logiquement des UIUnits et des UISubUnits.

UIUnit ^{Permet de regrouper des ´el´ements d’interaction en groupes} logiques du point de vue des interactions

UIFieldInManual ^{Repr´esente un ´el´ement d’interaction permettant `a} l’utilisateur d’effectuer une entr´ee manuellement.

UIFieldStatic ^{Repr´esente un ´el´ement d’interaction capable d’afficher des} informations statiques ne pouvant pas ˆetre chang´ees. UIFieldOneChoice ^{D´efinit un ´el´ement d’interaction permettant `a l’utilisateur}

de s´electionner ou pas une alternative unique. UIFieldMultiChoices ^{II s’agit d’un ´el´ement d’interaction permettant `a}

l’utilisateur de s´electionner une alternative parmi plusieurs. UIFieldOut ^{Constitue un ´el´ement d’interaction permettant au syst`eme}

d’effectuer une sortie d’informations.

UIFieldAction ^{Est un ´el´ement d’interaction permettant de d´emarrer une} action.

UIFieldMenuItem ^{D´ecrit un ´el´ement d’interaction qui permet de naviguer} entre les UIUnits, les UISubUnits et les UIgroups. UIFieldMenu ^{Repr´esente un ensemble de UIFieldMenuItems qui sont}

regroup´es.