Vous êtes sur la page 1sur 34

Ing´enieur En Sciences

Informatiques Rapport de Stage de


Fin d’E´ tudes 2009

COMPOSITION D’INTERFACE HOMME MACHINE POUR LA CR´EATION D’UN


NOUVEAU SERVICE : PREMIE`RES E´TAPES

Stagiaire :
Christian Brel –
brel@polytech.unice.fr (SI5 fili`ere
IHM)

Maˆıtre de stage :

Audrey Occello – occello@polytech.unice.fr


(Maˆıtre de conf´erence `a Polytech’ Nice-
Sophia)

Laboratoire :
I3S, CNRS (Sophia–Antipolis)

2 Mars 2009 – 30 Septembre 2009

R´esum´e
Les travaux dans le domaine du g´enie logiciel tendent `a offrir toujours plus de possibilit´es en terme de
r´eutilisation. Les concepteurs de sites web sont confront´es `a cette probl´ematique : construire et faire
´evoluer les applications web en combinant des services provenant de sources diverses. L’op´eration de
composition des services implique de construire une nouvelle Interface Homme Machine (IHM), c’est-
`a-dire de nouvelles pages web, afin de permettre l’acc`es et l’utilisation combin´ee de ces services
distants. Puisque le concepteur d’applications web n’a pas acc`es aux services eux mˆemes mais
seulement `a leurs IHM, il est alors plus int´eressant d’exploiter les principes de composition et de r
´eutilisation directement au niveau des IHM. Ceci est l’objet d’un sujet de th`ese dont le sujet est amorc
´e par ce stage.
Remerciements

Je tiens tout d’abord `a remercier mon encadrante Audrey OCCELLO pour avoir su me motiver,
m’´ecouter et surtout pour m’avoir fait confiance. Je tiens `a remercier les deux personnes qui ont aussi effectuer
mon encadrement durant ce stage, Anne-Marie PINNA-DERY que je remercie pour m’avoir accueilli dans son bureau
et Philippe RENEVIER-GONIN que je f´elicite pour son mariage.

Un grand merci `a Michel RIVEILL qui m’a permis d’int´egrer l’´equipe Rainbow pour ce stage et pour avoir
accept´e de me garder pour la th`ese `a venir.

Je remercie aussi C´edric JOFFROY pour les discussions et petits d´ebats que nous avons pu avoir pendant ces
6 mois. Merci d’avoir su m’´ecouter et me motiver quand il le fallait. Je n’oublie pas Micha¨el LAGUERRE pour sa
bonne humeur, son enthousiasme et les bons souvenirs surtout lors des courts partages de bureau. Merci `a l’´equipe
Rainbow pour leur accueil convivial et leur aide durant ce stage.

Je tiens ´egalement `a remercier l’´equipe Edelweiss de l’INRIA et plus particuli`erement Alain GIBOIN, Olivier
CORBY et Fabien GANDON pour leur soutien, leur aide et leur conseils avis´es sans lesquels je n’aurai pu avancer
aussi bien.

Bien ´evidemment, je remercie mes amis et ma famille qui tout au long de ce stage mais aussi tout au long de
mes ´etudes ont su me soutenir et m’accompagner dans tous ces moments de doute mais aussi dans tous ces moments
de joies. Merci `a tous !
Sommaire

1 Introduction 3

2 Description des objectifs/des besoins et ´etat de l’art 4

3 Approche et mise en oeuvre 12

4 Conclusion 21

Bibliographie 23

A Sujet de stage en images 25

B DTD (Document Type Definition) d´ecrivant la mise en page des ´el´ements d’IHM
28
Chapitre 1

Introduction

La d´emocratisation d’Internet et son adoption dans la majorit´e des foyers en fait un outil de commu- nication
puissant. Par cons´equence, Internet est une excellente vitrine pour les entreprises et les marques associ´ees. Ces
derni`eres proposent des sites Web de plus en plus ´evolu´es devenant de v´eritables applica- tions proposant de la
valeur ajout´ee (service de r´eservation ou d’achat en ligne, comparateurs de prix ou de trajets, stockage virtuel de
donn´ees, ...) pour l’utilisateur et plus seulement des pages d’informations.

Pour attirer les visiteurs, les applications web doivent ´evoluer en permanence, savoir se renouveler pour proposer
toujours plus de valeur ajout´ee. Le besoin de visibilit´e et de r´eactivit´e oblige les concepteurs d’applications web
`a repenser la mani`ere de concevoir ces applications et en particulier leurs Interfaces Homme Machine (IHM). Les
applications ne sont plus con¸cues pour un usage pr´ed´etermin´e, elles ne sont plus distribu´ees par un canal
classique d’achat mais largement diffus´ees sur internet et enfin elles ne sont plus limit´ees uniquement aux
postes de bureau. En effet, les d´eveloppeurs mettent `a disposition, sur des sites web, de plus en plus de services
qui vont permettre `a d’autres d´eveloppeurs de construire sur mesure d’autres services.

Le d´eveloppeur va construire son service par composition de services existants et va donc devoir construire de nouveau
une IHM pour le nouveau service afin de permettre l’utilisation combin´ee des diff´erents ser- vices compos´es.
L’objectif du stage est de proposer un m´ecanisme de composition semi-automatique et de proposer une IHM pour
guider cette composition.
La suite de ce document est organis´ee comme suit. Dans le chapitre 2, je pr´esente une description des besoins et
objectifs `a travers une ´etude de cas et un ´etat de l’art sur lesquelles je m’appuie pour pr´esenter le contexte du sujet.
Puis dans le chapitre 3, je pr´esente l’approche propos´ee pour r´esoudre le probl`eme lev´e par ce sujet et la
description de la preuve de concept mise en place. Enfin, la chapitre 4 conclut ce document et met en avant les
perspectives des travaux commenc´es pendant cette p´eriode de stage.
Description des objectifs/des besoins et
´etat de l’art

La large diffusion d’applications web permet `a un concepteur d’application de pouvoir r´eutiliser des services
existants afin de construire ses propres services. Un service peut ˆetre d´ecrit comme l’ensemble d’un noyau
fonctionnel, qui d´ecrit les fonctionnalit´es fournies par le service et une IHM qui va assu- rer l’interaction
entre le service et l’utilisateur. Dans ces deux mondes qui sont le noyau fonctionnel et l’IHM, lorsqu’un changement
est effectu´e, nous voulons qu’il y ait un impact d’un mon sur l’autre. Au niveau fonctionnel, beaucoup de
travaux ´etudient la composition de service notamment avec les web services (Newcomer 2002) et les
orchestrations de web services (Peltz 2003). Cependant, lorsqu’une telle composition est effectu´ee, aucun impact
n’est effectu´e sur l’IHM qui ne refl`ete alors pas toutes les possi- bilit´es en terme de fonctionnalit´es. Pour rem
´edier `a ce probl`eme des travaux sont en cours dans l’´equipe Rainbow (I3S) et mettent en place un ensemble de
mod`eles regroup´e sous la d´enomination ALIAS (Abs- tract Languages for User Interface Assembly) d´ecrit dans
Pinna-D´ery et al. (2008) qui permet de d´ecrire les IHM pour appliquer l’impact de la composition du noyau
fonctionnel sur l’IHM. La composition des IHM `a partir de la composition du noyau fonctionnel est alors possible et
nous parlons de composition de services dirig´ee par les informations donn´ees par la composition effectu´ee au niveau
du noyau fonctionnel.

Le contexte global de ce stage s’ins`ere dans la d´emarche inverse de celle d´ecrite ci-dessus, c’est-`a-dire
d’effectuer une composition de services dirig´ee par les informations donn´ees par la composition effectu´ee au niveau
de l’IHM. L’avantage de cette approche r´eside dans le fait que la plupart du temps le concep- teur d’application web
a beaucoup plus facilement acc`es `a l’interface d’un service qu’il veut r´eutiliser, partie visible du service, qu’`a
sa description fonctionnelle.

Le but du stage est d’effectuer un travail en amont, les premi`eres ´etapes, c’est-`a-dire de proposer un m
´ecanisme de composition semi-automatique et de proposer une IHM qui permettrait de faciliter la composition
des IHM des services. Pour cela, je me suis appuy´e sur les travaux existants li´es `a la com- position d’IHM dont je
vais faire une description dans ce chapitre. Ces travaux ne sont pas seulement en relation avec la composition mais
aussi avec l’adaptation des IHM en fonction de leur contexte d’utilisa- tion. Je pr´esente aussi dans ce chapitre des
travaux li´es aux placement des ´el´ements dans l’IHM, point d´elicat lors de la composition puisqu’il faut combiner
plusieurs positionnements (issus des diff´erentes IHM
Chapitre 2. Description des objectifs/des besoins et ´etat de 5
l’art

des services impliqu´es dans la composition) avec des possibles conflits de placement `a d´etecter. Enfin, je pr´esente
d’autres travaux li´es au sujet global de ce stage : les premier li´es `a la composition de services dirig´ee par la
composition de leur noyau fonctionnel, me donnant des ´el´ements de base pour effectuer la mod´elisation de mon
approche et les second sur les barri`eres d’apprentissage que peut rencontrer l’utilisateur pour utiliser un logiciel
afin de faciliter l’appr´ehension de l’IHM (guidant la composition). Afin d’expliquer clairement toutes les notions
en rapport avec la composition et l’adaptation d’IHM et les travaux que j’ai r´ealis´e durant ce stage, je vais tout
d’abord commenc´e ce chapitre par la pr´esentation d’une ´etude de cas.

2.1 Etude de cas : recherche de recettes de cuisine et calcul du prix


de revient
Cette section d´ecrit une ´etude de cas qui va nous permettre dans la suite du rapport d’expliquer les diff´erentes
notions, principes abord´es et probl´ematiques. Cette ´etude de cas utilise des services simplifi´es afin de faciliter la
compr´ehension des enjeux. L’´etude de cas met en ´eveil les talents culinaires de chacun puisqu’il s’agit d’utiliser
deux services qui vont nous permettre de confectionner de bons petits plats :
– le premier est un service de recherche de recettes, l’utilisateur renseigne le nom de la recette recherch´ee et
obtient au final la description de la recette avec notamment les ingr´edients `a utiliser ;
– le second est un service d’achat d’articles consommables, pour lequel l’utilisateur devra remplir un panier soit en s
´electionnant les articles un par un, soit en donnant directement une liste de courses, dans le but d’obtenir le
prix total de son panier.

L’IHM associ´ee au service de recherche d’une recette se d´ecoupe en trois ´ecrans 1 comme d´ecrit dans la figure
2.1. Le premier permet `a l’utilisateur de renseigner le nom de la recette et de lancer la recherche. Sur le second,
l’utilisateur voit apparaitre une liste de noms de recettes avec une petite description rapide. Il peut alors cliquer sur le
nom d’une recette et lancer la visualisation de celle-ci. Le dernier ´ecran est la visualisation de la recette en elle-
mˆeme avec son nom complet, le temps de pr´eparation et de cuisson, les ingr´edients `a utiliser et enfin les ´etapes
`a suivre pour r´eussir la recette.

Trouver une recette Liste des recettes Tarte aux pommes, raisins et cannelle
correspondants à la recherche
Préparation : 30 min: Cuisson
Préparation : 40
Mettez les min secs dans le rhum et laissez macére
raisins
e aux pommesTarte aux
et aux pommes Tarte aux pommes, raisins et cannelle Tarte aux pommes et raisin blanc
groseilles
Préparez la (pour
Ingrédients pâte 6 personnes)
: tamisez :la farine avec le sel et la cannelle, ajoutez
Travaillez du bout
--> Pâte des
brisée doigts
à la et ajoutez
cannelle : l'eau en prétrissant rapidement. ...etc..
200 g de farine
100 g de beurre...
OK --> Garniture :
1 kg de pommes reinettes
100 g de sucre...

Fig. 2.1 – IHM du service de recherche d’une recette.


1. IHM simplifi´ee provenant du site http ://www.marmiton.org
L’IHM associ´ee au service d’achat d’articles consommables se d´ecoupe en 4 ´ecrans 2 dont 3 d´ecrits dans
la figure 2 .2 . Correspondant au premier ´ecran, la premi`ere tˆache de l’utilisateur sera de remplir le panier. Pour
ce service, l’utilisateur a deux possibilit´es pour effectuer cette action, soit il ajoute des ingr´edients `a son panier en
les s´electionnant dans des cat´egories pr´ed´etermin´ees, soit il renseigne une zone de texte qui d´ecrit sa liste de
courses avec un ingr´edient par ligne. Pour cette deuxi`eme possibilit´e, une fois sa liste de course valid´ee, il va alors,
dans un second ´ecran, pour chaque ingr´edient, choisir la quantit´e voulue et ajouter l’ingr´edient au panier.
L’utilisateur valide ensuite son panier et voit apparaˆıtre, sur le troisi`eme ´ecran, la facture. Il peut alors valider la
facture et effectuer le paiement. Le quatri`eme ´ecran pour le paiement n’est pas montr´e dans la figure 2.2 car il
n’apporte rien dans le cadre de notre ´etude de cas puisque nous voulons seulement obtenir, apr`es avoir effectu´ee la
composition, le couˆt de la recette.

FraisSurgelésFruits & légumesBoissons ... Facture

Flash Liste Panier Flash Liste Panier Panier


sucre pomme poire farine sucre pomme
6 Pommes=>farine
poire Golden Origine France 1 kg Sucre blanc poudre
Sucre--blanc
1 -- 1,67€
poudre -- 1 -- 1,67€ 6 pommes Golden -- 1 -- 2,49 €
2 Ajouter
6 Pommes Royal Gala Origine Nouvelle Zélande 1 kg
1 Ajouter

6 Pommes Granny Smith Origine France 1,2 kg


1 Ajouter

...
1 Ajouter

OK Valider le panier Total facture: 4,16 €Valider la facture

Fig. 2.2 – IHM du service d’achat.

Le but est de composer ces deux services afin d’obtenir un service de recherche de recette qui nous donne aussi le
couˆt de revient de la recette. Effectivement, lorsque nous choisissons une recette, nous ne savons pas comment
´evaluer son couˆt de revient. Nous pouvons constater dans cette ´etude de cas que ces deux services sont
disponibles sur diff´erents sites web. Par cons´equent, sans composition, l’utilisateur est oblig´e de faire la visite de
plusieurs sites web pour r´ealiser une activit´e donn´ee (ici, obtenir la recette avec son prix de revient). Une solution
serait de reconstruire une application qui nous permette de faire cela. Ce d´eveloppement peut ˆetre fastidieux et
tr`es couteux. De plus, dans un monde ou` l’´evolution des applications doit ˆetre dynamique et rapide, cette solution
ne peut ˆetre satisfaisante car le d´eveloppement complet d’une application ne permet pas d’ˆetre assez r´eactif. Une
alternative est de composer des services existants et donc de composer les interfaces qui les accompagnent.

Avant de pr´esenter le travail r´ealis´e, je vais dans les prochaines sections pr´esenter un ´etat de l’art sur les
travaux li´es `a la composition d’IHM, sur les travaux li´es au placement des ´el´ements dans l’IHM et d’autres
travaux li´es au sujet pr´esent´e dans ce rapport.

2. IHM simplifi´ee provenant du site http ://www.telemarket.fr


2.2 Travaux existants li´es `a la composition d’IHM
La communaut´e IHM pr´econise de d´evelopper des interfaces `a des niveaux multiple d’abstraction de
mani`ere ind´ependante afin de produire des IHM de qualit´e et exploitables dans divers contextes (diff´erents
syst`emes d’exploitation, diff´erents langages de programmation, diff´erents supports tels que les Pcs, les PDAs
ou encore les t´el´ephones, etc) comme d´ecrit dans Calvary et al. (2003). A partir de n’importe lequel de ces
niveaux, le d´eveloppeur peut obtenir diff´erentes variantes d’une mˆeme IHM selon le contexte d’utilisation. Le
passage d’un niveau au suivant se fait plus ou moins automatiquement. Quatre niveaux d’abstraction sont identifi´es :
– les tˆaches utilisateur et concepts du domaine qui d´ecrivent l’IHM selon une perspective domaine, sans pr
´ejuger, d’une quelconque repr´esentation. Les concepts du domaine (par exemple, les notions de recette, d’ingr
´edient, d’article, de prix) sont les entit´es manipul´ees par les tˆaches (par exemple, la recherche de recettes,
la validation du panier d’article, etc) ;
– l’interface abstraite qui structure l’IHM en espaces de dialogue (une page web par exemple) et fixe la
navigation entre ces espaces. A ce niveau, on reste ind´ependant de tout contexte d’utilisation ;
– l’interface concr`ete qui affine l’IHM en introduisant les choix d’interacteurs (boutons, menus, etc.) en fonction
d’un contexte d’utilisation donn´e (l’action ”valider” peut ˆetre associ´ee `a un clic sur un bouton dans une
IHM pour un poste de travail ou `a une commande vocale dans le cadre d’une IHM sur t´el´ephone
portable dans un contexte ”mains libres” par exemple) ;
– l’interface finale, qui correspond `a impl´ementer l’interface concr`ete dans un langage donn´e (Java
SWING, Adobe Flex, HTML, etc) et un syst`eme d’exploitation sp´ecifique. C’est `a travers ce dernier niveau
de description qu’intervient g´en´eralement l’utilisateur d’une application.

2.2.1 Composition de mashups au niveau de l’interface finale


Dans le domaine du Web, les travaux autour de la composition d’IHM se font directement au niveau ”interface
finale”. Les travaux les plus r´epandus concernent les mashups c’est-`a-dire de ”petites” interfaces proposant un service
particulier (la m´et´eo, les news, pages jaunes, programmes t´el´e, etc). Il existe deux types de travaux qui se diff
´erencient par le fait d’utiliser ou non les flots de donn´ees au niveau de la composition et qui r´epondent en r
´ealit´e `a deux besoins diff´erents :
1. celui de partager des donn´ees et de faire diff´erents traitements sur ces donn´ees,
2. celui d’avoir un acc`es rapide `a diff´erents services sur une seule page.

Acc`es rapide `a diff´erents services sur une seule page

Nous pouvons citer IGoogle [3 (2007)] ou Netvibes [4 (2007)] comme outils utilisants les mashups pour r
´epondre au besoin d’acc`es rapide aux services. Pour ce type de mashups, la seule composition possible est
en r´ealit´e le regroupement de plusieurs mashups dans des cat´egories d´efinies par l’utilisateur. Ces portails Web ne
permettent pas d’effectuer des ´echanges de donn´ees entre les diff´erents mashups. Par exemple, pour notre cas
d’´etude, nous aurions un mashup pour la recherche de recettes et un autre pour l’achat d’articles consommables. Les
deux pourraient alors ˆetre mis cˆote `a cˆote, ce qui repr´esente une am´elioration puisque les deux services sont
alors accessibles tous deux sur une mˆeme page web et non plus sur deux sites web diff´erentes.
Partage et traitements des donn´ees issues des services

Popfly [1 (2008)] de Microsoft ou Yahoo Pipes [2 (2008)] utilisent les flots de donn´ees afin d’effec- tuer
l’enchaˆınement entre plusieurs mashups. Ces outils r´epondent au besoin de partage de donn´ees.
Graphiquement reli´ees au moyen de fl`eches, les sorties d’un ou de plusieurs mashups vont correspondre aux entr´ees
du mashup suivant. L’interface du dernier mashup est r´eutilis´ee comme interface r´esultat de la composition. Chaque
mashup effectue le traitement pour lequel il est con¸cu et renvoie en sortie les donn´ees trait´ees. Ici, nos deux
mashups de recherche de recettes et d’achat d’articles, seraient alors reli´es par le flux de donn´ees correspondant `a la
liste des ingr´edients qui sont aussi des articles consommables.

La r´eutilisation d’IHM fait partie int´egrante de la composition des mashups de pr´esentation mˆeme si celle-ci
correspond simplement `a une juxtaposition. Quant aux mashups avec flux de donn´ees, la com- position se fait
directement au niveau des services sous-jacents et seule l’IHM des mashups se trouvant en bout de chaine sont r
´eutilis´ees.

2.2.2 Composition en amont de l’interface finale


D’autres approches travaillent en amont de l’interface finale afin de d´efinir la composition ind´epen- damment
de toute contrainte li´ee au contexte ou de choix technique. Dans cette lign´ee, ComposiXML (Composition of
Applications specified in UsiXML) (Lepreux et al. 2007) permet de r´ealiser la fusion de diff´erentes IHM en une
seule grˆace `a un certain nombre d’op´erateurs (union, intersection, etc) et `a un langage de description d’interfaces
utilisateurs, USIXML (USer Interface eXtensible Markup Language) (Limbourg et al. 2004). Dans ce contexte, la r
´eutilisation des IHM de d´epart peut se faire au niveau ”interface concr`ete”. Cependant, la composition mise en
place est bas´ee sur la structure de l’IHM et ne prend pas en compte les informations fonctionnelles li´ees au
comportement du service, ce qui a pour cons´equence une grande perte d’informations utiles pour la composition
tel que les enchaˆınements entre les diff´erentes fonctions.

2.2.3 Composition au niveau des arbres de tˆaches et des concepts


D’autres travaux montent encore d’un niveau d’abstraction en r´ealisant la composition `a partir des descriptions
des tˆaches utilisateur (Lewandowski et al. 2007). Ces travaux utilisent les arbres de tˆaches pour d´ecrire
l’enchaˆınement des interactions entre l’utilisateur et l’application. Un arbre de tˆaches va per- mettre de d´efinir les
tˆaches que l’interface doit supporter afin que l’interface soit fonctionnelle. Une tˆache peut ˆetre un but ou une proc
´edure, c’est-`a-dire un ensemble de sous-tˆaches li´ees. Ainsi, la composition d’IHM consiste `a composer les
arbres de tˆaches correspondant `a chaque IHM de d´epart. La composition de deux arbres r´esulte en la cr´eation
d’un nouvel arbre avec l’ajout d’une tˆache suppl´ementaire regrou- pant les tˆaches similaires dans les deux arbres de
d´epart. Pour notre cas d’´etude, nous pouvons retrouver des tˆaches similaires lors de l’affichage des informations
sur la recette et l’affichage du prix total du panier. Pour regrouper ces deux affichages lors de la composition,
nous pouvons alors appliquer cette m´ethode et r´eunir ces deux tˆaches d’affichage sous une tˆache commune ce
qui aura pour cons´equence de regrouper ensemble les ´el´ements d’IHM correspondants par exemple la liste des ingr
´edients et leur prix.

Ces derniers travaux sont int´eressants dans la mesure ou` l’exploitation de l’arbre de tachesˆ permet
de prendre en compte l’aspect fonctionnel au niveau de la composition. Par exemple, l’enchainement des tˆaches
(voir figure 3.1) ”lancer la recherche” et ”s´electionner la recette dans une liste de recettes”, pour le service de
recherche de recettes, est une information pr´ecieuse indiquant le fait que la deuxi`eme tˆache ait besoin d’information
provenant de la premi`ere pour bien se d´erouler. Nous pouvons remarquer cependant que l’utilisation seule des arbres
de tˆaches ne suffit pas pour effectuer la composition puisque nous n’avons aucune information sur le d´ecoupage et le
placement des ´el´ements dans l’IHM.

2.2.4 Synth`ese
Jusqu’`a pr´esent, les travaux autour de la composition d’IHM ne s’appuient que sur un seul niveau
d’abstraction comme cela est r´esum´e sur la figure 2.3. Je propose au contraire de tirer parti des informa- tions
relatives `a diff´erents niveaux afin de proposer des r`egles de composition plus compl`etes : ´el´ements fonctionnels
du niveau ”tˆaches”, ´el´ements de d´ecoupage de l’IHM du niveau ”interface abstraite” et ´el´e- ments de
placements du niveau ”interface concr`ete”.

Fig. 2.3 – R´esum´e de l’´etude des travaux li´es `a composition d’IHM.

2.3 Travaux existants relatifs aux placements des ´el´ements dans l’IHM
L’organisation des IHM est un concept fr´equemment utilis´e. A travers mes exp´eriences de program- mation, je
retiens les propri´et´es suivantes :
– La notion de mise est page est g´en´eralement li´ee `a la notion de contenant. D’une part les deux notions
peuvent se confondre, comme par exemple dans les langages abstraits de description d’IHM. Il faut alors choisir le
bon type de contenant en fonction de l’organisation de l’IHM souhait´ee. Par
exemple, pour une organisation horizontale, il faut utiliser une ”HBox” en MXML (FLEX Adobe 2006) ou
une ”flowBox” en UsiXML (Limbourg et al. 2004). Ceci a l’inconv´enient d’avoir beaucoup d’impact sur les
objets utilis´es pour la programmation de l’IHM en cas de modification de la mise en page (il faut changer les
objets utilis´es). D’autre part, les contenants peuvent utiliser des strat´egies de mise en page, comme les
”layouts” de java. La souplesse induite par cette notion de strat´egie permet de limiter les modifications de
code en cas de changement de mise en page.
– Dans chaque langage, la notion de mise en page peut ˆetre une notion de placement pr´efix´e. Ce placement
est parfois exprim´e en coordonn´ees ”absolues” dans un rep`ere li´e `a un contenant, avec g´en´eralement
une origine en haut `a˘a gauche du contenant avec un axe des ordonn´ees invers´e (orient´e vers le
bas). Le placement peut ´egalement consister `a˘a indiquer un placement dans une zone, comme la zone
”South” du ”BorderLayout” de java (Sun 2008). Simple d’utilisation, ils ont l’inconv´enient d’ˆetre trop pr
´ecis (coordonn´ees) ou trop contraints (la taille des ´el´ements d´epend alors de la mise en page et il n’est
pas toujours facile d’obtenir le r´esultat souhait´e, si ce n’est en imbriquant des contenants avec des mises en
pages diff´erentes)
– Dans chaque langage, la notion de mise en page peut ˆetre une notion de placement relatif `a˘a
d’autres composants graphiques. Le ”BoxLayout” ou le ”GridBagLayout” de java permettent de placer des ´el
´ements graphiques les uns par rapport aux autres. Bien que permettant la r´ealisation de mise en page ´evolu
´ee, leur utilisation est compliqu´ee.

De ce tour d’horizon des diff´erentes organisations des IHM, j’en ai conclu qu’il me fallait dissocier la notion de
”mise en page” de la notion de ”contenant”. De plus, pour effectuer une composition plus fine, il faut dissocier les
IHM en ´el´ements d’IHM et afin de garder les ´el´ements d’un bout d’IHM ensemble, la notion de ”contenant” va
alors servir de lien de proximit´e entre les ´el´ements concern´es. Et `a des fins de compatibilit´e et d’´equivalence
avec les ”layouts” existants, je propose les deux types de ”mise en page” : les placements ”pr´efix´es” et les
placements ”relatifs”.

Afin de compl´eter cet ´etat de l’art, je pr´esente dans la section suivante d’autres travaux desquels je me suis
inspir´e pour ma proposition en terme de mod´elisation et de conception d’IHM.

2.4 Compl´ement de l’´etat de l’art pour la mod´elisation et


pour la conception de l’IHM
2.4.1 Impact de la composition du noyau fonctionnel sur l’IHM et mod´elisation
Le mod`ele ALIAS (Pinna-D´ery et al. 2 0 0 8 ) est un mod`ele mis en place par C´edric Joffroy qui ef-
fectue actuellement une th`ese dans l’´equipe Rainbow. Ce mod`ele permet de d´ecrire une interface de
fa¸con abstraite et d’avoir le lien entre la partie logicielle (Noyau fonctionnel) de l’application et cette interface.
Ainsi, lorsque deux ou plusieurs parties logicielles sont compos´ees, une composition au niveau des interfaces
abstraites associ´ees peut ˆetre r´ealis´ee automatiquement. Ce mod`ele se d´ecoupe en trois mod`eles : ALIAS-
Behavior, coeur du mod`ele ALIAS, qui d´ecrit les entr´ees, les sorties et les actions de l’IHM ; ALIAS-Structure
qui va permettre de d´etailler les ´el´ements d´ecrit dans le mod`ele pr´ec´edent en
donnant du typage aux ´el´ements par exemple ; ALIAS-Layout qui va permettre de d´ecrire le placement des ´el
´ements dans l’IHM. Ce d´ecoupage est int´eressant puisqu’il permet de s´eparer les diff´erentes pr´eoc- cupations
que nous avons au niveau de l’IHM et fait intervenir diff´erents niveaux de conception d’une IHM (Calvary et al.
2003) que j’ai d´etaill´e dans les sections pr´ec´edentes.

Tobias Nestler dans Nestler (2008) qui utilise les mashups pour construire des applications orient´es SOA
(Service-Oriented Architecture). Il travaille avec deux vues, c’est-`a-dire qu’`a la vue ”mashup”, il rajoute la vue
”processus ex´ecut´e” en int´egrant une repr´esentation BPEL par exemple. Pour rendre acces- sible le processus `a
l’utilisateur, il utilise une repr´esentation simplifi´ee du processus. Pour cela, il d´ecrit trois pistes : la premi`ere
consiste `a utiliser une m´etaphore des story-boards, la seconde consiste `a mettre en place un langage de r`egles et la
derni`ere consiste `a utiliser un langage ayant le temps comme rep`ere (a timeline language).

2.4.2 Barri`eres d’apprentissage li´es `a l’apprentissage d’un outil de programmation


Dans le cadre d’applications Web, duˆ au fait que l’utilisation d’internet se d´emocratise de plus en plus et ce
depuis plusieurs ann´ees, duˆ au fait qu’un certain nombre d’outils de haut niveau sont fournis pour la cr´eation
d’applications Web (les ´editeurs de sites Web par exemple ou encore certains outils cit´es ci-dessus comme IGoogle
ou Netvibes), nous sommes forc´es de constater que les d´eveloppeurs d’appli- cations Web ne sont pas forc
´ement des experts informaticiens. Mˆeme si, `a priori, le sujet du stage ne mentionne pas les utilisateurs non
informaticiens, je peux cependant proposer des solutions au probl`eme pos´e en gardant `a l’esprit l’id´ee d’une
adaptation possible aux personnes non informaticiennes, la com- position d’IHM se faisant elle-mˆeme `a porter
d’une autre IHM.

Dans le cadre de la proposition d’une IHM pouvant guider les utilisateurs lors de la composition, les travaux que j’ai
´etudi´es sont ceux de Ko et a l . (2004) au sujet des barri`eres li´es `a l’apprentissage d’un outil de
programmation par des ”non informaticiens”. L’´evaluation s’est effectu´ee avec le langage Vi- sual Basic.NET
avec une liste d’objectifs plus ou moins complexes `a r´ealiser par les utilisateurs. Cette
´evaluation permet de sortir six barri`eres d’apprentissage qui sont les suivantes :
– La barri`ere ”Design” : l’utilisateur ne sait pas comment r´ealiser l’objectif,
– La barri`ere ”Selection” : l’utilisateur sait comment r´ealiser l’objectif mais ne sait pas quel ´el´ement choisir,
– La barri`ere ”Use” : l’utilisateur sait quel ´el´ement prendre mais il ne sait pas comment l’utiliser,
– La barri`ere ”Coordination” : l’utilisateur ne sait pas quel ´el´ement choisir ou comment utiliser un
´el´ement dans le cas d’objectifs complexes ou` l’utilisateur a besoin de combiner plusieurs ´el´ements pour
remplir l’objectif,
– La barri`ere ”Understanding” et la barri`ere ”Information” : l’utilisateur a des difficult´es `a analyser le r
´esultat obtenu et pourquoi cela ne correspond pas `a ce que il attend.
Chapitre 3

Approche et mise en oeuvre

L’enjeu de ce stage est de proposer une extension `a la notion d’IHM afin de faciliter la composition de services
dans le but de cr´eer une nouvelle application. Je pars de l’hypoth`ese qu’il est plus facile de composer la
partie visible des services, les IHM, plutˆot que les services eux mˆemes pour lesquels le d´eveloppeur n’a pas
toujours acc`es `a la description compl`ete.

Je vais tout d’abord pr´esent´e dans ce chapitre le mod`ele mis en place permettant de d´ecrire les IHM des services
de mani`ere `a pouvoir effectuer leur composition plus facilement. Ce mod`ele est constitu´e d’une premi`ere partie
qui permet de d´ecrire les tˆaches associ´ees `a l’IHM du service et d’une seconde partie qui permet de d´ecrire le
regroupement et le positionnement des ´el´ements dans l’IHM. Enfin, je pr´esente aussi dans ce chapitre la preuve
de concept que j’ai mise en place durant ce stage.

3.1 Approche de composition des IHM


Je propose d’utiliser de fac¸on combin´ee diff´erentes formes de composition des IHM et donc de r´euti- lisation
de ces derni`eres. Cette combinaison des approches permet d’aller vers une composition des IHM plus coh´erente car
recoupant diff´erentes informations provenant de diff´erents niveaux de conception des IHM. Cette nouvelle approche
de la composition dite ”multi-niveaux” s’appuie sur une fa¸con de d´ecrire les IHM bien particuli`ere.

Le point clef de l’approche est de mettre en relation les diff´erents niveaux d’abstraction li´es `a la concep- tion d’une
IHM (Calvary et al. 2003). Cette approche se d´ecline en deux points : le premier est celui de la conception de
l’IHM qui est la description des tˆaches auxquelles l’interface doit r´epondre ; le second est celui de la structure de
l’interface avec le regroupement et le positionnement des ´el´ements d’IHM. Le processus de composition mis en
place peut se d´ecrire comme suit :
– s´election par l’utilisateur des diff´erents ´el´ements d’IHM qu’il veut composer,
– extraction des diff´erents ´el´ements d’IHM afin de r´ecup´erer tous les ´el´ements n´ecessaires au bon
fonctionnement de l’´el´ement s´electionn´e,
– insertion des diff´erents bouts d’IHM dans l’interface compos´ee en tenant compte de leur placement dans leur
IHM de d´epart.
Chapitre 3. Approche et mise en oeuvre 13

3.1.1 Description des tˆaches auquel l’interface doit r´epondre


Comme les travaux de Lewandowski et al. (2007), je pars du principe que la conception d’une IHM passe par
l’´etablissement de l’arbre de tˆaches correspondant (id´ee admise par la communaut´e IHM). Mais encore, je
suppose que les services que j’utilise ont ´et´e con¸cus en suivant cette approche de mod´e- lisation qui passe par
l’´etablissement des arbres de tˆaches. Comme soulign´e dans le chapitre pr´ec´edent, une tˆache peut ˆetre un
but ou une proc´edure, c’est-`a-dire un ensemble de sous-tˆaches li´ees. Pour re- pr´esenter un arbre de
tˆaches, diff´erents mod`eles de tˆaches sont disponibles. J’ai choisi de m’inspirer de CTT Mori et al. (2002),
un mod`ele riche permettant d’exploiter les informations sur l’enchaˆınement des tˆaches et leur place au sein de
l’interface. J’ai extrait un sous-ensemble de CTT des ´el´ements n´e- cessaires `a la description que je voulais
obtenir pour l’arbre de tˆaches d´ecrivant l’IHM et j’ai ajout´e `a ce sous-ensemble un lien relationnel entre l’arbre
de tˆache et l’arbre des regroupement d’´el´ements d’IHM.

Le mod`ele de tˆaches contient une tˆache principale. Cette tˆache peut contenir des sous tˆaches ou alors ˆetre une
tˆache ´el´ementaire. Pour chaque tˆache nous pouvons lui ajouter une description, les liens de ”parent´es” qu’elle a
avec les autres tˆaches (la tˆache m`ere, les tˆaches soeurs). Une tˆache peut ˆetre optionnelle. Elle appartient `a une
cat´egorie c’est-`a-dire qu’une tˆache va ˆetre abstraite (des sous-tˆaches permettent de la d´ecrire), utilisateur (elle
doit ˆetre r´ealis´ee par l’utilisateur), interactive (elle n´ecessite une interaction de la part d’un utilisateur ou d’une
autre tˆache) ou bien applicative (elle doit ˆetre r´ealis´ee automatiquement par l’application elle-mˆeme sans
intervention de l’utilisateur).

Les tˆaches sont reli´ees entre elles par des op´erateurs temporels. Par exemple, nous allons avoir des tˆaches
qui doivent se r´ealiser l’une `a la suite de l’autre, ou encore de mani`ere parall`ele ou ind´ependante, ou bien encore
un choix peut s’effectuer entre la r´ealisation de la premi`ere ou de la deuxi`eme tˆache, etc...

Si je reprends l’interface de recherche d’une recette, je peux d´ecrire le mod`ele de tˆaches associ´e (voir figure
3.1) comme l’enchaˆınement de trois tˆaches principales : lancer la recherche (tˆache 1), s´electionner la recette dans
une liste de recettes (tˆache 2) et enfin visualiser la recette (tˆache 3). Hormis les liens de parent´es entre la tˆache
m`ere ”Recherche d’une recette” et les tˆaches principales ou entre les tˆaches principales elles-mˆeme, nous avons
trois cat´egories de tˆaches qui apparaissent : la tˆache m`ere est une tˆache abstraite, d´etaill´ee par ses trois
tˆaches filles dont les deux premi`eres sont interactives et la der- ni`ere est applicative puisque ce n’est que de
l’affichage d’informations. Les relations temporelles entre les tˆaches filles sont simples, la ”tˆache 1” devra s’ex
´ecuter avant la ”tˆache 2” et lui transmettra des in- formations, et nous retrouvons la mˆeme relation temporelle
entre la ”tˆache 2” et la ”tˆache 3”. Un autre exemple de relation temporelle est pr´esent dans cet arbre de tˆache
entre la tˆache ”AfficherNomRecette” et la tˆache ”AfficherTempsPreparationEtCuisson” ou` les tˆaches doivent
s’ex´ecuter obligatoirement (peu importe l’ordre d’ex´ecution entre elles).
Enfin, mon approche implique de mettre en relation l’arbre de tˆaches avec les ´el´ements d’IHM puisque le stage a
comme but de faire la composition d’IHM multi-niveaux. Ainsi, j’ai une propri´et´e sur les tˆaches qui permet de
relier une tˆache `a n’importe quel ´el´ement d’IHM ou regroupement d’´el´ements d’IHM.

Pour l’´etude de cas, la composition des arbres de tˆaches serait d’ajouter, `a l’arbre de tˆache de la fi-
TrouverRecette

[ ]>> [ ]>>
ChercherUneRecetteSélectionnerRecette
VisualiserRecette

>> >>
RenseignerNomRecette LancerLaRecherche CocherRecette ValiderLaVisualisation AfficherNomRecette AfficherIngredients
AfficherTempsPreparationEtCuissonAfficherLesEtapes

Fig. 3.1 – Arbre de tˆaches du service de recherche d’une recette.

gure 3.1, `a la tˆache ”VisualiserRecette” la sous-tˆache ”AfficherPrixFacture” issue de l’arbre de tˆache du service
d’achat (comme indiqu´e sur la figure 3.2). Pour cela, il faudra tenir compte des tˆaches `a remplir pour obtenir
toutes les informations n´ecessaires `a la sous-tˆache ajout´ee, les ajouter au premier arbre de tˆache et choisir le ou
les op´erateurs temporels `a appliquer `a la sous tˆache afin de garantir une coh´erence au niveau de l’arbre de tˆache
issu de la composition.

TrouverRecette

[ ]>> [ ]>>
ChercherUneRecetteSélectionnerRecette AfficherPrixFacture
VisualiserRecette

>> >>
RenseignerNomRecette LancerLaRecherche CocherRecette ValiderLaVisualisation AfficherNomRecette AfficherIngredients
AfficherTempsPreparationEtCuissonAfficherLesEtapes

Fig. 3.2 – Arbre de tˆaches du service de recherche d’une recette apr`es composition.

3.1.2 Ontologie de placement des ´el´ements dans l’IHM


Pour exprimer la mise en page, j’ai opt´e pour l’utilisation d’une ontologie associ´ee `a une structure de
regroupement des ´el´ements constituants l’IHM. Cette notion de regroupement est importante dans le cadre de mon
objectif de recomposition d’IHM. Elle peut permettre de conserver des liens de proximit´e entre les notions repr´esent
´ees. Son exploitation lorsqu’on extrait une sous partie d’une IHM est facilit´ee par la puissance d’expression des
requˆetes manipul´ees par les moteurs s´emantiques. Je pr´esente donc dans cette section la description de la
structure de l’IHM et la description de la mise en page.

La structure d’arbre permettant naturellement d’exprimer des regroupements, l’ontologie que j’ai d´e- finie
inclue cette structure d’arbre. Elle est compos´ee d’entit´es (Entity) qui sont :
– soit des ensembles (Ensemble) pouvant correspondre `a n’importe quel type de contenant,
– soit des ´el´ements d’IHM (UIObject) pouvant correspondre `a n’importe quel type d’interacteur.
Un ensemble peut contenir d’autres ensembles ou des ´el´ements d’IHM (figure 3.3). Ce mod`ele permet de d
´ecrire l’interface en la d´ecoupant en blocs et par cons´equent le fait de grouper des ´el´ements d’IHM va pouvoir
ˆetre interpr´et´e comme la volont´e de rapprocher ces ´el´ements d’IHM de mani`ere s´emantique.
Ensemble

Ensemble Ensemble

Ensemble UIObject UIObject UIObject UIObject

UIObject UIObject

Fig. 3.3 – Arbre de regroupement des ´el´ements d’IHM.

Au niveau de l’´etude de cas, nous pouvons voir dans la figure 3.4 que tous les ´el´ements d’IHM sont regroup
´es dans un ensemble ”InformationsRecette” qui exprime le fait que ces ´el´ements vont apporter des d´etails en
ce qui concerne la recette visualis´ee, puis nous avons un sous-ensemble qui est intitul´e ”Pr´eparation” dans
lequel nous allons trouver les informations n´ecessaires `a la pr´eparation de la recette afin d’ˆetre prˆet `a suivre les
´etapes de la recette.
Pour compl´eter la description de l’interface, il est n´ecessaire d’exprimer le placement des entit´es (En- tity) dans
l’interface. L’application des conclusions du tour d’horizon exprim´e dans le chapitre pr´ec´edent m’a conduit `a
abstraire les possibilit´es en terme de placement de la fa¸con suivante :
– Deux placements ”pr´efix´es”
– Placement absolu dans le parent : chaque entit´e poss`ede des coordonn´ees (exprim´ees en pixel ou en
pourcentage) par rapport au coin sup´erieur gauche (axe ”invers´e” des ordonn´ees) du parent.
– Placement relatif au parent : les parents sont d´ecoup´es en une grille `a neuf positions comme d´ecrit dans la
figure 3.5. Ce placement d’une entit´e dans son parent ne se limite pas `a l’expression d’une position, mais
plusieurs positions peuvent ˆetre utilis´ees.
– Deux placements ”relatifs”
– Placement relatif aux autres entit´es : les entit´es sont positionn´ees entre elles par une combinaison
InformationsRecette
Tarte aux pommes, raisins et cannelle InformationsRecette
NomRecette

Préparation Préparation ::30Mettez


min Cuisson : 40 min
les raisins secs dans le rhum et laissez macérer au moins 30 min.
Préparez la pâte : tamisez la farine avec le sel et la cannelle, ajoutez le beurre en morceaux.
Ingrédients (pour 6 personnes) : NomRecette PréparationEtapesDeLaRecette
Travaillez
Préparation
du -->
bout
Pâtedes doigts
brisée et ajoutez
à la cannelle : l'eau en prétrissant rapidement. ...etc...
200 g de farine
100 g de beurre...
--> Garniture :
1 kg de pommes reinettes PréparationCuisson Ingrédients
100 g de sucre...

EtapesDeLaRecette

Fig. 3.4 – Ensembles des ´el´ements d’IHM pour la visualisation de la recette.

de ”`a gauche de”/”`a droite de” et ”au dessus de”/”au dessous de” et ”au centre de”. Ce placement
d’une entit´e par rapport `a un autre ne se limite pas `a l’expression d’une position, mais plusieurs positions
peuvent ˆetre utilis´ees.
– Placement par ancrage `a une autre entit´e : deux coordonn´ees sont utilis´ees, la premi`ere pour l’entit
´e que l’on place, la seconde pour l’entit´e sur laquelle on attache la premi`ere.
Les placements relatifs ont l’avantage de pouvoir exprimer la proximit´e des concepts de fa¸con ex- ploitable
par un raisonnement de recomposition d’IHM. En effet cela permet de facilement retrouver les concepts proches ”g
´eographiquement” dans une IHM et de conserver cette coh´erence de proximit´e et d’affichage lors de leur
extraction. Ces aspects sont illustr´es dans la section suivante par la mise en place d’une IHM permettant de
construction l’interface guid´ee par les notions de proximit´e sous entendu par la mise en page des IHM r´eutilis´ees.

Entité
Parent
Entité Entité
(en haut à gauche dans) (en haut dans) (en haut à droite dans)

Entité Entité Entité


(à gauche dans) (centré dans) (à droite dans)

Entité Entité Entité


(en bas à gauche dans) (en bas dans) (en bas à droite dans)
Fig. 3.5 – Grille de placement relatif au parent.
Pour le cas d’´etude, en appliquant un placement sur la grille, comme nous pouvons le voir sur la figure 3.4,
nous allons avoir l’ensemble ”Pr´eparation” qui va se positionner `a gauche dans l’ensemble p`ere
”InformationsRecette”, puis l’´el´ement ”NomRecette” qui va se positionner en haut dans l’ensemble p`ere et enfin,
l’´el´ement ”EtapesDeLaRecette” qui va se situer au centre de ce mˆeme ensemble p`ere.

3.2 Preuve de concept


La preuve de concept que j’ai mis en place durant ce stage apparaˆıt en r´ealit´e sous la forme de 2 preuves
de concept. La premi`ere consiste `a montrer l’exploitation de l’ontologie de placement pour la s´election des ´el
´ements d’IHM `a composer et la seconde consiste `a montrer l’exploitation de l’ontologie de placement et de
l’ontologie de tˆaches lors de la composition de deux services.

3.2.1 S´election des ´el´ements d’IHM `a composer


Afin de faciliter la r´eutilisation d’IHM guid´ee par le layout, j’ai d´evelopp´e une IHM sp´ecifique (fi- gure
3.6). Il s’agit d’une extra-IHM selon la d´efinition 1 de Sottet (2008). Cette IHM est constitu´ee de 3 parties : la
partie qui permet de naviguer dans les ´el´ements d’interfaces et ensembles pour extraire les parties d’interfaces `a
recomposer, la partie qui permet de positionner les ´el´ements choisis dans une grille respectant l’ontologie de
placement pr´ec´edemment d´ecrite et une partie v´erification de coh´erence en fonction des layouts des
interfaces initiales.
La partie extraction se pr´esente sous forme d’arborescence, l’extraction d’un ´el´ement entraˆıne les v
´erifications suivantes :
1. Si l’´el´ement s´electionn´e appartient `a un ensemble, l’ensemble est d´esign´e au concepteur afin qu’il v
´erifie si les liens de proximit´e sous jacents doivent ˆetre pr´eserv´es et donc l’ensemble extrait dans sa
globalit´e.
2. Si le concepteur choisit l’ensemble, le positionnement interne `a l’ensemble est conserv´e lors du
placement de l’ensemble dans la grille de placement centrale. Le concepteur peut explicitement changer le
placement initial s’il le souhaite.
3. Si le concepteur choisit l’´el´ement seul, le placement est libre. La partie placement est construite en fonction
des placements d´efinis dans l’approche.

Les regroupements et le placement des entit´es sont d´efinis avec les trois langages de web s´emantique RDFS
(Resource Description Framework Schema) [W3C Working Group 2004c], RDF (Resource Des- cription
Framework) [W3C Working Group 2004b] et OWL (Web Ontology Language) [W3C Working Group 2004a]. Ces
langages me permettent d’exprimer la transitivit´e, la sym´etrie des propri´et´es. Ainsi, si je d´efinis que la propri
´et´e ”`a gauche de” est sym´etrique de la propri´et´e ”`a droite de” alors, si une entit´e e1 est plac´e `a
gauche d’une entit´e e2, de mani`ere automatique, e2 sera plac´e `a droite de e1. C’est grˆace `a ce genre de propri
´et´es qu’il va ˆetre possible d’effectuer l’extraction des diff´erents ´el´ements d’IHM.

1. ”Une extra-IHM est une interface qui repr´esente et donne le contrˆole sur ou par l’interm´ediaire d’un
mod`ele a` un syst`eme concret (c’est-`a-dire une IHM). C’est en quelque sorte l’interface de configuration d’une IHM.”
Fig. 3.6 – Ecran de l’extra-IHM pour le placement des entit´es.

L’interpr´etation de ces propri´et´es est effectu´ee par un moteur s´emantique comme le moteur CORESE (C orby
et al. 2004) d´evelopp´e par l’´equipe Edelweiss (INRIA) que j’utilise. Grˆace `a ce moteur, je peux effectuer
des requˆetes en SPARQL 2 (SPARQL Protocol and RDF Query Language) [W3C Working Group 2 0 0 8 ]
permettant par exemple d’obtenir toutes les entit´es pr´esentes `a droite de tel autre entit´e ou encore toutes les entit
´es situ´ees `a une position pr´ecise dans leur parent. Ce sont ces requˆetes qui vont permettre d’assurer le lien de
proximit´e entre les ´el´ements d’IHM lors de l’extraction de ceux-ci.

2. Langage qui permet l’expression de requˆetes sur une base de donn´ees de type RDF
3.2.2 Une premi`ere composition d’IHM avec l’approche propos´ee
J’ai d´evelopp´e en JAVA, une premi`ere composition d’IHM en appliquant l’approche propos´ee. Comme
indiqu´e dans la section pr´ec´edente, j’ai utilis´e le moteur CORESE (Corby et al. 2 00 4) afin de pouvoir
effectuer des requˆetes en SPARQL (W3 C Wo r king Gro up 2 0 0 8 ) me permettant de r´ecup´erer les liens entre
les tˆaches que doit remplir l’IHM du service ainsi que les liens entre les diff´erentes entit´es (Ensemble ou UIObject)
contenues dans l’IHM.

En entr´ee de ce moteur de composition, nous avons les diff´erents services impliqu´es, un service ´etant d´efini
par la description de l’arbre de tˆache associ´ee `a l’interface ainsi que par la description des diff´e- rents
regroupements et positionnements des ´el´ements d’IHM. Le deuxi`eme argument de ce moteur de composition est
l’ensemble des paires de morceaux d’IHM que nous voulons voir fusionner/ins´erer lors de la composition (le second
´el´ement de la paire ´etant l’´el´ement `a garder, le premier ´etant celui `a fusion- ner/ins´erer).

Apr`es avoir copi´e les services concern´es par la composition (afin d’´eviter toute alt´eration de ceux-ci lors
du processus de composition), je traite les deux briques composant les services de mani`ere s´epar´e et ceci pour
chaque paire de morceaux d’IHM `a traiter. Dans un premier temps, j’effectue donc la com- position des arbres de
tˆaches des services. Comme indiqu´e dans la figure 3.7, cette composition peut se d´ecouper en 8 ´etapes d´efinies
comme suit :
1. `a partir de chaque morceau d’IHM pr´esent dans la pair, nous r´ecup´erons les tˆaches li´es,
2. nous supprimons le lien entre la tˆache parente de la tˆache 1 et la tˆache 1,
3. nous ajoutons un lien de parent´e entre la tˆache parente `a la tˆache 1 et la tˆache 2,
4. nous supprimons le lien ´eventuel entre la tˆache pr´ec´edent la tˆache 1 et la tˆache 1,
5. nous lions avec ce lien la tˆache pr´ec´edent la tˆache 1 et la tˆache 2,
6. nous supprimons le lien ´eventuel entre la tˆache suivant la tˆache 1 et la tˆache 1,
7. nous lions avec ce lien la tˆache suivant la tˆache 1 et la tˆache 2,
8. nous supprimons la tˆache 1.
Dans un second temps, j’effectue la composition des ”mises en page” des ´el´ements des IHM des
services. Cette composition est constitu´ee de 2 ´etapes comme l’indique la figure 3.8 et qui sont d´efinies comme
suit :
1. nous supprimons le lien entre l’entit´e parente au morceau d’IHM 1 et le morceau d’IHM 1,
2. nous supprimons le morceau d’IHM 1.
Ces 2 ´etapes sont suffisantes puisque le but est de conserver le deuxi`eme morceau d’IHM intact et de supprimer
l’utilisation du premier morceau d’IHM de la pair.

Ce premier moteur ”na¨ıf” permet de valider l’utilisation des langages pr´esents dans le monde du web s
´emantique malgr´e son manque de finesse en ce qui concerne la composition `a proprement parler.
Task 1 3 Task 2

parent parent

7
X2
Task 1 4 6 Task 1 Task 2 Task 2

X Task 1
X Task 2

X8
Previous After Previous After

1
linkedTo
5
1 linkedTo

IhmPiece 1 IhmPiece 2

Fig. 3.7 – Les 8 ´etapes de la composition des arbres de tˆaches des IHM lors du traitement d’une pair de morceau d’IHM.

IhmPiece 1

parent

1X
IhmPiece 1
X2
Fig. 3.8 – Les 2 ´etapes de la composition des regroupements d’´el´ements d’IHM lors du traitement d’une paire de
morceau d’IHM.
Chapitre 4

Conclusion

Mes contributions au dmaine de la composition d’IHM durant ce stage sont l’approche multi-niveaux propos´ee
mais aussi la d´efinition d’une ontologie de placement des ´el´ements dans l’IHM.

4.1 Une approche multi-niveaux


Cette approche met en place l’utilisation d’arbre de tˆaches permettant de d´ecrire les buts dont l’IHM doit tenir
compte, buts li´es `a la description des ´el´ements d’IHM qui se fait au moyen d’une politique de regroupements
mˆelant aussi l’utilisation d’un placement afin de d´ecrire la position des ´el´ements dans l’interface. En
utilisant cette approche de description des IHM, ce stage a pour but de faciliter la composition des IHM. Pour
cela, je me rapproche du monde des ontologies, afin de d´ecrire les trois points clefs de notre approche dans un
langage qui va me permettre grˆace `a un moteur s´emantique, de pouvoir faire des manipulations des deux arbres
(arbre de tˆaches et arbre de regroupements d´ecor´e par les propri´et´es de placement) plus fines qu’une
manipulation des fichiers XML traditionnellement utilis´es par les travaux de description d’IHM bas´es sur les
langages `a balises.

4.2 Expression de la proximit´e et du regroupement des ´el


´ements `a travers une ontologie de placement
Notre abstraction de la mise en page v´erifie les propri´et´es identifi´ees par notre tour d’horizon de
l’expression traditionnelle des mises en page. Sauf exceptions que je n’ai pas encore identifi´ees, toute mise en
page usuelle peut ˆetre exprim´ee dans l’ontologie de placement. En cas d’impr´ecisions, il est toujours
possible d’exprimer tout ”layout” par des traductions en placements ”pr´efix´es”. Cependant, le recours `a de tels
placements est `a ´eviter puisqu’ils inhibent l’int´erˆet de la d´emarche. En effet, les requˆetes (et donc les
manipulations en vue de la recomposition) seraient alors inexploitables car sans liaison entre les ´el´ements graphiques.
Par exemple pour une mise en page en ligne horizontale de 3 ´el´ements graphiques e1, e2 et e3 dans un contenant c1, il
est possible de l’exprimer de diff´erentes mani`eres :
– par des propri´et´es ”`a gauche” : e1 est `a gauche de e2, e2 est `a gauche de e3 et e1 est en haut `a
gauche de c1,
– par des placements ”absolus” : e1 est en (0,0) de c1 e2 est en (100 pixels, 0) de c1 et e3 est en (200 pixels, 0) de
c1,
Chapitre 4. Conclusion 22

– etc.
Dans le premier cas, comme les ´el´ements e1, e2 et e3 sont reli´es, il est possible de les s´electionner tous
ensemble. Dans le second cas, il n’est pas possible de faire de liaison entre e1, e2 et e3. Ainsi, selon l’objectif souhait
´e, la mise en page pourra s’exprimer diff´eremment.

Mon approche laisse des impr´ecisions. J’ai fait ce choix afin de simplifier l’expression et l’utilisation de la
mise en page. Ainsi, des notions comme le remplissage des espaces vides sont des ´el´ements ”am- bigu¨s”. Par
exemple, lorsqu’un ´el´ement graphique e1 est `a gauche d’un ´el´ement graphique e2, comment doit ˆetre positionn
´e e1 s’il est plus petit que e2 ? Doit-on aligner le haut de e1 avec celui de e2, leurs centres ? leurs bas ? etc. Cette
d´ecision, ainsi que la d´etection des incoh´erences dans l’expression de la mise en page, sont d´el´egu´es au
moteur de rendu. Notons toutefois que l’utilisation de l’extra-IHM l`eve in fine les impr´ecisions grˆace `a
l’intervention de l’utilisateur face aux v´erifications effectu´ees.

4.3 Perspectives
Ce stage ´etant l’amorce `a une th`ese financ´ee par une allocation MESR obtenue sur le concours de Juin
2009, les perspectives sont multiples.

L’approche pr´esent´ee permet d’exprimer les liens de proximit´e et de regroupement des ´el´ements d’IHM. La
solution propos´ee exploite les propri´et´es des ontologies pour permettre de raisonner par requˆetes `a des fins
d’extraction et de manipulation de parties d’IHM.

Les possibilit´es qui s’offrent sont prometteuses. En particulier, l’´etape suivante est l’enrichissement de
l’association s´emantique ”Entity” - ”Placement” par l’ajout d’informations li´ees aux concepts du domaine manipul
´es par l’utilisateur via les ´el´ements graphiques. Ainsi, je pourrai recomposer les IHM `a partir d’´el´ements
graphiques choisis par utilisateur, identifier les ´el´ements graphiques connexes (et le degr´e de liaison),
conserver leur placements et probablement l’ergonomie initiale. Une ´etude doit aussi ˆetre effectu´ee sur les
expressions de placements ”relatifs” et sur la traduction des layouts (cod´es en java ou MXML par exemple) avec
de tels placements.

Dans un cadre plus g´en´eral, des pr´ecisions devront ˆetre apport´ees sur les diff´erentes formes de com-
positions possibles (fusion, flow, etc...) en ce qui concerne les arbres de tˆaches associ´es `a chaque IHM ainsi que
sur les diff´erentes possibilit´es ou conflits lors de la composition des mises en page associ´ees `a chaque IHM. Ces
pr´ecisions concerneront les 3 points principaux que je peux faire ressortir du sujet plus global de la th`ese qui sont :
– la d´efinition d’un formalisme pour la s´election des ´el´ements d’IHM `a fusionner,
– la d´efinition des r`egles et des op´erateurs de composition,
– l’identification des cas ´eventuels de conflit et les solutions ´eventuelles pour y rem´edier.

Pour terminer ce tour d’horizon des diff´erentes perspectives, je peux signaler une extension possible `a ces travaux
qui serait de travailler avec des ensembles de services non stables et toute la probl´ematique de la d´ecouverte
dynamique de services.
Bibliographie

1 2008 Popfly (Microsoft). http://www.popfly.com.

2 2008 Yahoo Pipes (Yahoo). http://pipes.yahoo.com/pipes.

3 2007 IGoogle. http://www.google.com/ig.

4 2007 Netvibes. http://www.netvibes.com.

ADOBE 2006 Adobe Systems Inc. http://www.adobe.com/products/flex/.

CALVARY, G., COUTAZ, J., THEVENIN, D., LIMBOURG, Q., BOUILLON, L. & VANDERDONCKT, J.
2003 A Unifying Reference Framework for Multi-Target User Interfaces. Interacting with Computers
15 (3), 289–308.

CORBY, O., DIENG-KUNTZ, R. & FARON-ZUCKER, C. 2004 Querying the semantic web with the
CORESE search engine. 16th European Conference on Artificial Intelligence A˘ Z´2004), IOS
(ECAIaˆ Press, Valencia, Spain.

KO, A. J., MYERS, B. A. & AUNG,


H. H. 2004 Six Learning Barriers in End-User Programming
Systems. Visual Languages and Human Centric Computing, 2004 IEEE Symposium on, pp. 199–206.

LEPREUX, S., HARIRI, A., ROUILLARD, J., TABARY, D., TARBY, J.-C. & KOLSKI, C. 2007 Towards
Multimodal User Interfaces Composition based on UsiXML and MBD principles. Lecture Notes in Computer
Science 4552 (134), 134–143.

LEWANDOWSKI, A., LEPREUX, S. & BOURGUIN, G. 2007 Tasks Models Merging for High-Level Com-
ponent Composition. Human-Computer Interaction, Part I, HCII 2007, Lecture Notes in Computer
Science (LNCS) 4550, 1129–1138.

LIMBOURG, Q., VANDERDONCKT, J., MICHOTTE, B., BOUILLON, L., FLORINS, M. & TREVISAN, D. 2004
UsiXML : A User Interface Description Language for Context-Sensitive User Interfaces. AVI’2004 Workshop
”Developing User Interfaces with XML : Advances on User Interface Description Languages”
UIXML’04 pp. 55–62.

MORI, G., PATERNO` , F. & SANTORO, C. 2002 CTTE : Support for Developing and Analyzing Task
Models for Interactive System Design. IEEE Transactions on Software Engineering pp. 797–813.
BIBLIOGRAPHIE 24

NESTLER, T. 2008 Towards a mashup-driven end-user programming of SOA-based applications. iiWAS ’08 :
Proceedings of the 10th International Conference on Information Integration and Web-based Applications &
Services, pp. 551–554. New York, NY, USA : ACM.

NEWCOMER, E. 2002 Understanding Web Services : XML, WSDL, SOAP, and UDDI. Addison-Wesley
Professional .

PELTZ, C. 2003 Web services orchestration and choregraphy. Computer 36 (10), 46 – 52.

PINNA-DE´RY, A.-M., JOFFROY, C., RENEVIER, P., RIVEILL, M. & VERGONI, C. 2008 ALIAS : A Set
of Abstract Languages for User Interface Assembly. 9th IASTED International Conference Software
Engineering and Applications (SEA’08), pp. 77–82. IASTED, Orlando, Florida, USA : ACTA Press.

SOTTET, J.-S. 2008 M´ega-IHM : mall´eabilit´e des Interfaces Homme-Machine dirig´ees par les mod`eles. PhD
thesis, Universit´e Joseph Fourier, th`ese de doctorat Informatique pr´epar´ee au Laboratoire d’In- formatique de
Grenoble (LIG).

SUN 2008 Laying Out Components Within a Container. http://java.sun.com/docs/books/tutorial/


uiswing/lay\discretionary{-}{}{}out/index.html.

W3C WORKING GROUP 2004a OWL Web Ontology Language Reference. http://www.w3.org/TR/
owl-ref/.

W3C WORKING GROUP 2004b Resource Description Framework (RDF). http://www.w3.org/RDF/.

W3C WORKING GROUP 2004c Resource Description Framework SCHEMA (RDFS). http://www.w3.
org/TR/rdf-schema/.

W3C WORKING
GROUP 2008 SPARQL Query Language for RDF. http://www.w3.org/TR/
rdf-sparql-query/.
Annexe A

Sujet de stage en images

A.1 Large diffusion d’applications web

Fig. A.1 – Large diffusion d’applications web.


Chapitre A. Sujet de stage en images 26

A.2 Construire une nouvelle application

Fig. A.2 – Construire une nouvelle application.

A.3 Association de 2 services

Fig. A.3 – Association de 2 services.


A.4 Composition d’actions

Fig. A.4 – Composition d’actions.

A.5 Comment ?

Fig. A.5 – Comment ?


Annexe B

DTD (Document Type Definition) d


´ecrivant la mise en page des ´el
´ements d’IHM

<!-- version monocible (une seul ecran) -->

<!DOCTYPE ALIAS-LAYOUT [

<!ELEMENT ALIAS-LAYOUT (TOP_CONTAINER,COMPONENT_PLACEMENT*,CONTAINER_GROUPEMENT*)>

<!ELEMENT COMPONENT_PLACEMENT (COMPONENT_ID, (PLACE_IN_CONTAINER | COORD_IN_CONTAINER | RELAT

<!-- l’id d’un component que l’on veut positionner -->


<!ELEMENT COMPONENT_ID (#PCDATA)>
<!-- l’id du container dans lequel on veut positionner le component -->
<!ELEMENT CONTAINER_ID (#PCDATA)>
<!-- une entite pour un positionnement par localisation dans ou par rapport a -->
<!ENTITY % loc "(top|right|bottom|left|center|top-left|top-right|bottom-right|bottom-left)">
<!-- une entite pour dire quoi chevauche quoi -->
<!ENTITY % deep "(above|under)">
<!-- une entite pour definir les degrees de liberte, rotation et/ou translation -->
<!ENTITY % lib "(rotx|roty|rotz|transx|transy|transz)">

<!-- PLACE_IN_CONTAINER -->


<!-- definition des 9 positions dans la container parent-->
<!-- possibilit´e de multiplier par 3 avec audessus, endessous -->
<!ELEMENT PLACE_IN_CONTAINER (CONTAINER_ID, LOCALISATION*) >
<!ELEMENT LOCALISATION %loc;>
Chapitre B. DTD (Document Type Definition) d´ecrivant la mise en page des ´el
´ements d’IHM 29

<!-- COORD_IN_CONTAINER -->


<!-- position absolue dans un container par rapport au coin superieur gauche, rep`ere "invers
´e
<!ELEMENT COORD_IN_CONTAINER (CONTAINER_ID, COORD, DIMENSION?) >
<!ELEMENT COORD (x, y, z) >
<!ELEMENT x (#PCDATA)> <!-- un nombre (pixel ? reel ? cm ? % ? etc.) -->
<!ELEMENT y (#PCDATA)> <!-- un nombre -->
<!ELEMENT z (#PCDATA)> <!-- un nombre -->
<!-- z = 0 : background , sinon z = 1 pour tout le monde -->
<!ELEMENT DIMENSION (width, height, depth?) >
<!ELEMENT width (#PCDATA)> <!-- un nombre -->
<!ELEMENT height (#PCDATA)> <!-- un nombre -->
<!ELEMENT depth (#PCDATA)> <!-- un nombre -->

<!-- RELATIVE_TO_COMPONENT -->


<!-- pour se positionner par rapport `a un autre -->
<!ELEMENT RELATIVE_TO_COMPONENT (COMPONENT_ID, LOCALISATION*) >

<!-- ATTACH_TO_COMPONENT -->


<!ELEMENT ATTACH_TO_COMPONENT (COMPONENT_ID, POINTS, DEGREE*, DEPTH) >
<!ELEMENT POINTS (COORD, COORD)>
<!-- deux coordonnees, la premiere pour (et dans) le component qu’on place, la seconde pour (
<!ELEMENT DEGREE %lib;>
<!ELEMENT DEPTH %deep;>

]>
Table des mati`eres

1 Introduction 3

2 Description des objectifs/des besoins et ´etat de l’art 4


2.1 Etude de cas : recherche de recettes de cuisine et calcul du prix de revient.....................................................5
2.2 Travaux existants li´es `a la composition d’IHM .....................................................................................7
2.2.1 Composition de mashups au niveau de l’interface finale....................................................................7
2.2.2 Composition en amont de l’interface finale.........................................................................................8
2.2.3 Composition au niveau des arbres de tˆaches et des concepts .........................................................8
2.2.4 Synth`ese ...................................................................................................................................9
2.3 Travaux existants relatifs aux placements des ´el´ements dans l’IHM ........................................................9
2.4 Compl´ement de l’´etat de l’art pour la mod´elisation et pour la conception de l’IHM ...........................10
2.4.1 Impact de la composition du noyau fonctionnel sur l’IHM et mod´elisation ................................10
2.4.2 Barri`eres d’apprentissage li´es `a l’apprentissage d’un outil de programmation ..........................11

3 Approche et mise en oeuvre 12


3.1 Approche de composition des IHM................................................................................................................12
3.1.1 Description des tˆaches auquel l’interface doit r´epondre ............................................................13
3.1.2 Ontologie de placement des ´el´ements dans l’IHM ...................................................................14
3.2 Preuve de concept...........................................................................................................................................17
3.2.1 S´election des ´el´ements d’IHM `a composer ..........................................................................17
3.2.2 Une premi`ere composition d’IHM avec l’approche propos´ee ...................................................19

4 Conclusion 21
4.1 Une approche multi-niveaux...........................................................................................................................21
4.2 Expression de la proximit´e et du regroupement des ´el´ements `a travers une ontologie de placement...21
4.3 Perspectives.....................................................................................................................................................22

Bibliographie 23

A Sujet de stage en images 25


A.1 Large diffusion d’applications web.................................................................................................................25
A.2 Construire une nouvelle application................................................................................................................26
TABLE DES MATIE` RES 31
A.3 Association de 2 services................................................................................................................................26
A.4 Composition d’actions....................................................................................................................................27
A.5 Comment ?.......................................................................................................................................................27

B DTD (Document Type Definition) d´ecrivant la mise en page des ´el´ements d’IHM
28
Table des figures

2.1 IHM du service de recherche d’une recette...................................................................................................................... 5


2.2 IHM du service d’achat.................................................................................................................................................... 6
2.3 R´esum´e de l’´etude des travaux li´es `a composition d’IHM ................................................................................9

3.1 Arbre de tˆaches du service de recherche d’une recette. ............................................................................................14


3.2 Arbre de tˆaches du service de recherche d’une recette apr`es composition. .............................................................14
3.3 Arbre de regroupement des ´el´ements d’IHM .........................................................................................................15
3.4 Ensembles des ´el´ements d’IHM pour la visualisation de la recette. ........................................................................16
3.5 Grille de placement relatif au parent.............................................................................................................................. 16
3.6 Ecran de l’extra-IHM pour le placement des entit´es. ...............................................................................................18
3.7 Les 8 ´etapes de la composition des arbres de tˆaches des IHM lors du traitement d’une pair de morceau
d’IHM............................................................................................................................................................................ 20
3.8 Les 2 ´etapes de la composition des regroupements d’´el´ements d’IHM lors du traitement d’une paire
de morceau d’IHM.................................................................................................................................................20

A.1 Large diffusion d’applications web................................................................................................................................ 25


A.2 Construire une nouvelle application............................................................................................................................... 26
A.3 Association de 2 services............................................................................................................................................... 26
A.4 Composition d’actions................................................................................................................................................... 27
A.5 Comment ?..................................................................................................................................................................... 27
Abstract

Software Engineering composition principles allow for the construction of new applications by reusing
other application building blocks. Following such principles, webmasters aggregate services to create a
website quickly. Composing services implies creating a new User Inter- face (UI) - in our case a new
web page - to use them. Webmasters cannot access services’ description directly but they can leverage
information about services’ UI easily. Thus, it is more interesting to reuse and compose UIs than the
services themselves. This is basis of a phD Thesis whose subject is started by this internship.

Vous aimerez peut-être aussi