Académique Documents
Professionnel Documents
Culture Documents
Stagiaire :
Christian Brel –
brel@polytech.unice.fr (SI5 fili`ere
IHM)
Maˆıtre de stage :
Laboratoire :
I3S, CNRS (Sophia–Antipolis)
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
4 Conclusion 21
Bibliographie 23
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.
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...
...
1 Ajouter
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.
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.
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”.
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.
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).
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
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.
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
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
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.
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
UIObject UIObject
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
EtapesDeLaRecette
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)
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.
– 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
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.
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).
W3C WORKING GROUP 2004a OWL Web Ontology Language Reference. http://www.w3.org/TR/
owl-ref/.
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
A.5 Comment ?
<!DOCTYPE ALIAS-LAYOUT [
]>
Table des mati`eres
1 Introduction 3
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
B DTD (Document Type Definition) d´ecrivant la mise en page des ´el´ements d’IHM
28
Table des figures
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.