Modélisation en XML du fonctionnement des composants interactifs

Institut de la Francophonie
pour l'Informatique

MEMOIRE DE FIN D’ETUDES
Sujet :

Modélisation en XML du fonctionnement des
composants interactifs

Tuteurs
Dr. Stéphane CHATTY
Dr. Stéphane SIRE
IntuiLab, Labège, France

Etudiant
PHAM Nguyen Khang
Promotion 8
IFI, Hanoï, Vietnam

03 – 2005


Modélisation en du fonctionnement des composants interactifs

1

Remerciements
Je tiens à remercier particulièrement Monsieur Stéphane Chatty (IntuiLab) , qui m’a
accepté comme stagiaire à IntuiLab dans son équipe de projet IntuiKit et qui m’a donné
beaucoup d’aides et de conseils pendant mon séjour en France.
Je tiens à remercier aussi tous les personnels dans l’entreprise IntuiLab qui m’ont

accueilli très chaleureusement et qui me rendent à l’aise pendant mon stage à IntuiLab.
Je remercie sincèrement Monsieur Charles Durand, directeur de l’Institut de la
Francophonie pour l’Informatique (IFI) et Monsieur Ho Tuong Vinh, directeur des études
de l‘IFI qui ont fait des nécessaires pour que je puisse effectuer mon stage de fin d’études.
Je voudrais donner un grand merci à Madame Loan qui m’a aidé à la demande du visa et
qui a acheté le billet d’avion pour moi.
Les derniers mots sont consacrés à l’âme de ma mère défunte qui m’a élevé et
m’éduqué depuis que j’étais petit ; à mon père qui a travaillé très dur pour nourrir la
famille qui m’a encouragé beaucoup à continuer les études ; et à ma petite famille (ma
femme et ma fille) qui m’a appuyé moralement quand je rencontre des difficultés.

Pham Nguyen Khang, Promotion VIII, IFI – Hanoï

1


Modélisation en du fonctionnement des composants interactifs

2

Résumé
Mon travail dans le projet IntuiKit se focalise sur la recherche des modèles pour pouvoir
modéliser en XML du fonctionnement des composants interactifs (interacteurs, widgets).
Basé sur les modèles trouvés, je propose un système de thèmes pour ces composants. Le
système est en fait analogue aux systèmes de polices. Cela signifie que nous pouvons
appliquer un modèle d’apparence visuelle et de comportement à une interface d’utilisateur
indépendante de son contenu.
Ce mémoire décrit comment modéliser les widgets en XML et créer un système de
thèmes pour des widgets. Il présente aussi des modèles nécessaires pour des widgets
comme : modèle de disposition, modèle de comportement , modèle de coupure, … Nous

avons proposé d’utiliser des systèmes de contraintes à sens unique pour modéliser des
comportements continu. Tout cela nous aide à construire un système de thème qui fournit
des changements dynamiques (voire téléchargeables) de l’apparence et des comportements
pour l’interface d’utilisateur graphique.
Les expériences que j’ai effectuées sur des widgets WIMP (acronyme pour Window
Icon Menu et Pointer ) permettent d’ illustrer notre solution et de valider notre approche.
Mots clefs : Interaction Homme Machine, Interaction multimodale, Widgets, Rôle de
XML dans Interaction Homme Machine, Système de contraintes, Modèle de disposition,
Réseau de Petri, Machine à état fini, Comportements continus, Modèle d’événements

Pham Nguyen Khang, Promotion VIII, IFI – Hanoï

2


Modélisation en du fonctionnement des composants interactifs

3

Abstract
My research in the IntuiKit project is focused on finding the models in order to model in
XML the operation of the interactive components (widgets). Based on the found models , I
propose a system of theme for these components. In fact, the system is similar to the font
system. This signifies that we can apply a model of visual appearance and of behaviour to
a user interface independe nt of the content of the interface.
This paper describes how to model the widgets in XML and to create a system of
theme for widgets. It presents also models necessary for widgets such as: layout model,
behaviour model, view/clipping m odel, … We proposed to use one way constraint systems
to model dynamic behaviours. This helps us to build a system of theme which supports
dynamic (even downloadable) appearance and behaviour changes for graphical user

interface.
The experiments that I carried out on widgets WIMP (acronym for Window Icon
Menu and Pointer) allow to illustrate our solution and validate our approach.
Key words: Computer Human Interaction, Multimodal Interaction, Widgets, Role of
XML in Computer Human Interaction, Constraint systems, Layout model, Petri net, Finite
state machine, Behaviour model, Event model

Pham Nguyen Khang, Promotion VIII, IFI – Hanoï

3


Modélisation en du fonctionnement des composants interactifs

4

Table des matières
REMERCIEMENTS ........................................................................................................................................................1
RESUME..............................................................................................................................................................................2
ABSTRACT ........................................................................................................................................................................3
TABLE DES MATIERES ...............................................................................................................................................4
TABLE DE FIGURES .....................................................................................................................................................6
CHAPITRE 1 :
1.1
1.2
1.3
1.4
1.5
1.6
1.7

INTRODUCTION ....................................................................................................................................................7
M OTIVATION ET OBJECTIFS DU TRAVAIL .........................................................................................................8
E NVIRONNEMENT DE STAGE ..............................................................................................................................8
T HEMES A EXPLOITER .........................................................................................................................................8
M ETHODE DE TRAVAIL ......................................................................................................................................9
C ONTRIBUTION ....................................................................................................................................................9
STRUCTURE DE MEMOIRE ..................................................................................................................................9

CHAPITRE 2 :
2.1
2.1.1
2.1.2
2.1.3
2.1.4
2.2

INTRODUCTION .........................................................................................................................7

TRAVAUX ANTERIEURS ......................................................................................................10

DES TRAVAUX ANTERIEURS ............................................................................................................................10
O UTILS A BASE DE LANGAGE DE PROGRAMMATION ................................................................................10
O UTILS UTILISANT X M L.............................................................................................................................10
T RAVAIL DE HUDSON ..................................................................................................................................11
INTUIK IT ........................................................................................................................................................11
QUELQUES REMARQUES SUR DES TRAVAUX ANTERIEURS ..........................................................................12

CHAPITRE 3 :

METHODE ET SOLUTION ....................................................................................................13

3.1
PROBLEMATIQUE : ............................................................................................................................................13
3.2
E NVIRONNEMENT INTUIK IT ............................................................................................................................13
3.2.1
C ONCEPTION .................................................................................................................................................13
3.2.1.1 D ECOMPOSITION D’ UN SYSTEME INTERACTIF ..........................................................................................13
3.2.1.2 M ODELE DE COMPOSITION DES FACETTES ................................................................................................14
3.2.1.3 C OMPORTEMENTS DISCRETS.......................................................................................................................15
3.2.1.4 FUSION DES VARIABLES (MERGE) ..............................................................................................................16
3.2.1.5 M ODELE D’EMIS ET D’ABONNEMENT DES EVENEMENTS........................................................................16
3.2.2
E XEMPLE .......................................................................................................................................................17
3.3
L ES MODELES MANQUANTS DANS I NTUIKIT ET SOLUTIONS .......................................................................20
3.3.1
C OMPORTEMENTS CONTINUS .....................................................................................................................20
3.3.1.1 A TTRIBUTS A BASE D’EXPRESSIONS ..........................................................................................................20
3.3.1.2 SYSTEME DE CONTRAINTES A SENS UNIQUE (ONE WAY CONSTRAINT SYSTEM) .................................22
3.3.2
M ODELE DE DISPOSITION :..........................................................................................................................24
3.3.3
M ODELE DE CONTAINER..............................................................................................................................29
3.3.4
M ODELE DE VUE /COUPURE.........................................................................................................................31
3.4
SYSTEME DE THEME..........................................................................................................................................32
3.4.1

M ODELE DE THEME ......................................................................................................................................32
3.4.2
C HANGEMENT DE SKIN D’UN WIDGET .......................................................................................................32
3.4.3
H ERITAGE DU THEME...................................................................................................................................34
CHAPITRE 4 :
4.1
4.1.1
4.1.2
4.1.3

RESULTAT ET VERIFICATION..........................................................................................35

PRESENTATION DE RESULTAT .........................................................................................................................35
L ES MODULES EN PERL ................................................................................................................................35
STRUCTURE D’UN FICHIER THEME.............................................................................................................37
U TILISATION DES WIDGETS WIMP DANS INTUIKIT ................................................................................38

Pham Nguyen Khang, Promotion VIII, IFI – Hanoï

4


Modélisation en du fonctionnement des composants interactifs
4.2

VERIFICATION ...................................................................................................................................................41

CHAPITRE 5 :
5.1

5.2

5

CONCLUSION ET PERSPECTIVES ...................................................................................43

C ONCLUSION .....................................................................................................................................................43
PERSPECTIVES ...................................................................................................................................................43

RÉFÉRENCES .................................................................................................................................................................44

Pham Nguyen Khang, Promotion VIII, IFI – Hanoï

5


Modélisation en du fonctionnement des composants interactifs

6

Table de figures
Figure 1 : Un rules avec ses 3 fils et 2 règles................................................................................................................14
Figure 2 : Définition et instanciation des modèles .......................................................................................................14
Figure 3 : Exemple du couvrement de l’arbre...............................................................................................................15
Figure 4 : FSM modélisant le comportement d’un Bouton........................................................................................15
Figure 5 : Transducteur des événements ........................................................................................................................16
Figure 6 : Modèle d’abonnement des événements recommandé par W3C..............................................................17
Figure 7 : FSM pour le comportement du bouton........................................................................................................18
Figure 8 : Structure du modèle de bouton .....................................................................................................................18
Figure 9 : Widget bouton modélisé en XML dans IntuiKit ........................................................................................20

Figure 10 : Une contrainte géométrique entre le texte et le rectangle ......................................................................21
Figure 11 : Modèle du widget « bar de défilement » (ScrollBar)..............................................................................21
Figure 12 : Un modèle du widget Fenêtre (Window)..................................................................................................23
Figure 13 : Graphe représentant les contraintes avec rang des nœuds .....................................................................24
Figure 14 : Disposition verticale.....................................................................................................................................25
Figure 15 : Disposition horizontale ................................................................................................................................25
Figure 16 : Disposition en bordure .................................................................................................................................26
Figure 17 : Disposition en bordure horizontale ............................................................................................................27
Figure 18 : Disposition en bordure verticale.................................................................................................................27
Figure 19 : Modèle d’un onglet .......................................................................................................................................28
Figure 20 : Modèle des onglets .......................................................................................................................................29
Figure 21 : Modèle d’un onglet avec container ............................................................................................................30
Figure 22 : Arbre de composants du modèle de l’onglet avec container .................................................................30
Figure 23 : Modèle de vue scrollable.............................................................................................................................31
Figure 24 : Modèle de thème et son rôle dans une application interactive..............................................................32
Figure 25 : Application d’un skin à un widget .............................................................................................................33
Figure 26 : Widgets dans des thèmes différents (dans QT)........................................................................................34
Figure 27 : Diagramme de classes du paquetage WimpKit et sa position dans IntuiKit .......................................36
Figure 28 : Un bouton modélisé en XML......................................................................................................................38
Figure 29 : Exemple du widget fenêtre..........................................................................................................................40
Figure 30 : Widget « Window » dans plusieurs thèmes différents............................................................................41
Figure 31 : Groupe des onglets ........................................................................................................................................42
Figure 32 : Formulaire ......................................................................................................................................................42

Pham Nguyen Khang, Promotion VIII, IFI – Hanoï

6


Modélisation en du fonctionnement des composants interactifs

Chapitre 1 :

7

INTRODUCTION

1.1 Introduction
De nos jours, nous avons besoin de plus en plus des logiciels interactifs non seulement
pour des ordinateurs mais aussi pour des PDA, des automates (distributeurs de l’argent ,
distributeurs de billets, …). Nous voulons que l’Interaction Homme Machine devienne
plus familier de jour en jour. Pour cela , il y a eu beaucoup de recherches sur ce domaine.
On a cherché à créer des outils qui aident des réalisateurs à produire des logiciels
interactifs plus facilement et plus rapidement.
Quant aux utilisateurs, ils désirent que des applications interactives avancés soient
faciles à utiliser et à apprendre. Aujourd'hui les utilisateurs veulent pouvoir être chez eux et
utiliser des logiciels sans dépenser leur temps pour lire des manuels. Néanmoins , de telles
interfaces d’utilisateur sont difficiles à designer et à implanter. Plusieurs recherches
différentes ont montré que 48% du code de l’application est consacré à l’interface
d’utilisateurs et qu’environ 50% du temps d’implantation est consacré à l’interface
d’utilisateur [Myers92]. Quand des interfaces d’utilisateur deviennent facile à utiliser, ils
deviennent difficiles à créer. Des développeurs d’interface d’utilisateur ont besoin des
outils qui fournissent un support plus riche pour le développement des interfaces
d’utilisateurs avancées.
Au cours des dernières années, plusieurs outils ont été créés pour aider des réalisateurs
d'interface d’utilisateur, e.g. « Toolkits », « User Interface Management Systems », « User
Interface Development Environments ». D’après la classification de ces outils de B. Myers
dans [Myers95], il y a trois types des outils que nous pouvons lister comme ci-dessous :
?
?

?

Outils à base de langage (language-based tools) : exigent des développeurs de
programmer dans un langage pour un but particulier.
Outils de spécification graphiques interactifs (Interactive graphical specification
tools) : permettent de designer une interface d’utilisateur interactive.
Outils à base de modèles (model-based tools) : utilisent un modèle ou une
spécification de niveau élevé pour produire des interfaces d’utilisateur
automatiquement.

Des développeurs d’interface d’utilisa teur restent encore des difficultés en utilisant les
outils à base de langage ou de spécification graphiques interactifs car ces outils fournissent
la spécification des comportements dynamiques ou la disposition mais pas tous les deux en
même temps. D’ailleurs, ces outils fournissent seulement la phase de développement dans
le cycle de vie de l’interface d’utilisateur.
A partir des années 80s, il y a eu beaucoup de recherches sur des systèmes à base de
modèles (model based systems). Avec ces systèmes, nous voulons décomposer un système
en modèles (et en plusieurs niveau sémantique : modèle de tâches, syntaxique : modèle de
dialogues, lexique : modèle des événements, …) et chercher à les composer. L’intérêt de
ces modèles est que des logiciels peuvent être gé nérés automatiquement à partir des
modèles [O lsen93]. L’approche du développement des interfaces d’utilisateur à base de
modèles et ses outils fournissent toutes les phases dans le cycle de vie d’un logiciel
interactif. Plusieurs acteurs (graphistes, programme ur, concepteur, chef de projet, …)
peuvent participer au développement des logiciels. Malgré tout, jusqu’à maintenant il n’y a

Pham Nguyen Khang, Promotion VIII, IFI – Hanoï

7

Modélisation en du fonctionnement des composants interactifs

8

pas encore de grand succès pour ces systèmes. Soit il est difficile à générer le code à partir
des modèles, soit des interfaces d’utilisateur générées ne sont pas très jolies.
Le projet d’IntuiKit (à Intuilab) créé a pour but de concevoir un environnement pour le
développement des logiciels interactifs. IntuiKit n’a pas ambition de générer
automatiquement des logiciels à partir des modèles mais il utilise des modèles décla ratifs
pour construire des logiciels interactifs. L’objectif d’IntuiKit est de construire un
environnement (un toolkit) pour aider des concepteurs à produire des logiciels interactifs
plus facilement et plus rapidement. Pour l’instance, IntuiKit possède des briques de base
pour aider à fabriquer des logiciels. Cependant, il manque certains modèles pour devenir
un toolkit complet.
1.2 Motivation et objectifs du travail
Sensibilité à la problématique de l’Interaction Homme Machine, j’ai choisi d’effectuer
mon stage de fin d’études à Intuilab dans le projet IntuiKit. Mon travail concerne à la
modélisation en XML du fonctionnement des widgets WIMP (des interacteurs que IntuiKit
manque. Un interracteur est un composant interactif qui possède une apparence et des
comportements). L’objectif de mon travail est de faire une analyse sur des widgets,
concevoir une bibliothèque de widgets WIMP et de construire un système de thèmes pour
des widgets qui peut être téléchargeable com me celui de font.
Avec la notion de thème, la « peau » et éventuellement les comportements d’une
interface sont changés facilement sans aucune modification de code . De plus, cette
approche sépare bien la partie d’interface d’utilisateur avec le noyau d’application.
1.3 Environnement de stage
Intuilab (site web : ) est une entreprise privée très jeune (fondée
en 2002) qui se consacre à fabriquer des applications d’Interaction Homme Machine
multimodales (gestes, vocales, etc.). Intuilab développe un environnement de prototypage
et de production d’interface multimodales IntuiKit.

IntuiKit crée a pour but de faire participer les graphistes, les ergonomes, et les
programmeur à la conception et réalisation d’un logiciel interactif rapidement et
effectivement. IntuiKit propose une approche pour permettre la production d’éléments de
logiciel par des non-programmeurs (graphiste , ergonome, …). C’est l’architecture à base
de modèles (model-based architecture) où le programme est définit par une composition
des modèles. Dans sa version complète, IntuiKit sera constitué de :
?
?
?
?

Un ensemble de modèles des différentes facettes d’un logiciel interactif
Des formats XML correspondant à ces modèles
Une bibliothèque Perl constitué de moteurs de rendu de ces modèles, de parseur
XML, et d’une API pour manipuler les modèles
Un ou des éditeurs graphiques pour fabriquer des modèles (éditeur d’interface)

1.4 Thèmes à exploiter
En analysant le sujet posé, j’ai tiré la première remarque. C’est qu’il faut exploiter
plusieurs thèmes suivants : système à base de modèles, XML, langages déclaratifs, réseau
de Petri, système de contraintes, système de layout, modèle des événements, Interaction
Homme Machine, multi-modalités dans Interaction Homme-Machine, le rôle de XML dans
Interaction Homme Machine, S ystème de thèmes, …

Pham Nguyen Khang, Promotion VIII, IFI – Hanoï

8


Modélisation en du fonctionnement des composants interactifs

9

1.5 Méthode de travail
Afin d’accomplir le travail donné, j’ai recherché sur des travaux antérieurs, fait une
analyse, effectué des expériences et à la fin choisi une meilleure solution. La façon de
travail se résume comme suit :
1. Rechercher sur travaux antérieurs.
2. Faire des expériences.
Répéter ce processus jusqu’ à trouver une solution.
Il y a des parties que j’ai travaille autonome, et il y a aussi des parties que j’ai participé
à l’équipe :
?
?
?
?
?
?

Etudier le noyau d’IntuiKit (personnel).
Fabriquer des widgets en utilisant IntuiKit (personnel)
Concevoir la notion de jeu des widgets et de thème (personnel).
Identifier les modèles manquant dans IntuiKit (personnel)
Choisir les modèles à ajouter (travail en équipe)
Mettre en œuvre (personnel)

1.6 Contribution
La contribution de mon stage se compose de deux parties :
?
?

Théorique : faire une grille d’analyse sur des widgets. A partir de cette analyse,
trouver des modèles manquants dans IntuiKit et enfin chercher à modéliser les
widgets WIMP en XML.
Pratique : implanter des modèles trouvés et écrire une bibliothèque des widgets
classiques. Intégrer cette bibliothèque à IntuiKit.

1.7 Structure de mémoire
Ce rapport se divise en 4 parties :
?
?
?
?
?

Introduction : présente un peu sur le contexte de travail et le problème que je dois
traiter
Un état de l’art se trouve dans la partie 2 qui présente quelques travaux des autres
concernant à ce sujet
La partie 3 est la plus importante. Elle concerne à mes solutions et méthodes pour
résoudre le problème posé
Une évaluation faite en utilisation sera abordée dans la partie 4
En fin, quelques conclusions et perspectives se trouvent dans la partie 5

Pham Nguyen Khang, Promotion VIII, IFI – Hanoï

9


Modélisation en du fonctionnement des composants interactifs

Chapitre 2 :

10

Travaux antérieurs

2.1 Des travaux antérieurs
Il y a longtemps où des programmeur travaillaient sur le système d’exploitation Ms
DOS, créer un logiciel avec une interface d’utilisateur demandait beaucoup de temps et de
travail. La façon la plus classique de communiquer entre l’homme et la machine est
d’utiliser des lignes de commandes (command line). Cette façon est facile à programmer
mais l’utilisateur doit apprendre par cœur des commandes. La deuxième façon est de
composer des interacteurs (ce sont des objets à travers lesquels l’ utilisateur communiquent
avec machine) pour constituer une interface d’utilisateur.
2.1.1

Outils à base de langag e de programmation

La plus part des langages de programmation fournissent des lignes de commandes (à
travers les commandes « read » et « write »). La communication entre l’homme et la
machine est faite par le clavier et l’écran. Il existe aussi des langages de programmation
qui fournissent des boîtes à outils (collection des interacteurs) pour construire des logiciels
interactifs comme Passcal (Turbo Vision) , Foxpro, Java, Visual C++, QT de C++ sur linux,
Perl-TK, … Les widgets fournis par ces langages sont modélisés sous forme des classes
(Java, Visual C++). Leur apparence et leurs comportements sont désignés rigidement par le
code. Il n’y pas la notion de thème des widgets dans Java, Visual C++, Perl-TK, … Donc,
ses widgets dépendent du système d’exploitation. L’utilisateur n’arrive pas à modifier
l’apparence et les comportements des ces widgets. QT fournit la notion «style » que nous
pouvons utiliser pour simuler des widgets de Windows, Motif, … Nous pouvons créer des

interfaces d’utilisateur indépendantes du système d’exploitation. De plus, le style d’un
widget peut être changé dynamiquement (au cours d’exécution du programme).
L’utilisateur peut aussi définir un nouveau style à lui. Cependant, tous les widgets sont
définis par le code. Il n’ y a que des programmeurs qui peuvent modifier ou ajouter des
styles.
Le développement des logiciels en utilisant ces langages dépend beaucoup des
programmeurs. De plus, il est difficile de créer des interfaces d’utilisateur fantaisistes. Il
est compliqué de créer un bouton dont la forme est un cercle, par exemple.
2.1.2 Outils utilisant XML
a. XUL (eXtensible User Interface Langugage)
XUL (prononcé comme « zoul ») a été créé pour faire développer le browser Mozzila
plus facilement et plus rapidement. C’est un langage basé sur XML pour description le
contenu de fenêtre et boîte de dialogue. XUL possède un langage pour tous les widgets
typiques comme : toolbars, trees, progress bars, menus, button, check box, radio button, …
Ce langage a été créé pour des applications de Mozilla et est utilisé pour définir leur
interface d’utilisateur. L’implémentation de XUL et browser Mozilla sont en trains de
changer de jour en jour. XUL est un des langages désignés spécifiquement pour construire
des interfaces d’utilisateur portables. Normalement, il prend beaucoup de temps pour
construire une application pour chaque plateforme. Le temps nécessaire pour compiler et
déboguer peuvent être très long. Avec XUL, une interface peut être impléme ntée et
modifiée rapidement et facilement. CSS (Cascade Style Sheets ) peuvent être appliqués

Pham Nguyen Khang, Promotion VIII, IFI – Hanoï

10


Modélisation en du fonctionnement des composants interactifs

11

pour modifier l’apparence des interfaces d’utilisateur (ressemble le skin et le thème dans
WinAmp ou quelques manageur des fenêtres). Comme XUL est un langage pour construire
des interfaces portables, il demande donc un moteur de rendu pour chaque platforme.
b. XAML (eXtensible Application Markup Language)
XAML (prononcé comme « zammel ») : C’est un des technologies intéressantes pour
des développeurs de Microsoft 'Longhorn' Markup Language. Il est un langage de marge
basé sur XML (XML-based markup language). Les interfaces d’utilisateur dans des
applications de Longhorn sont typiquement construite en utilisant XAML.
Des interfaces d’utilisateur de XAML sont établies plus ou moins de la même façon en
tant que des interfaces d’utilisateur de Web HTML. Nous créons simplement un document
avec des balises pour des éléments d’interface d’utilisateur comme : button, text,
radiobutton, … que nous désirons.
Exemple :
<FlowPanel xmlns=“ /><Text>Bonjour tout le monde</Text>
<Button>Cliquez-moi !</Button>
</FlowPanel>

XAML est une abstraction des widgets. Chaque widget dans XAML correspond à une
classe de C#.
c. LASZLO
C’est un langage de la famille XML qui permet de créer des applicatons interactives en
XML. Une chose très intéressante dans LASZLO est qu’il nous fournit un mécanisme pour
pouvoir modéliser de nouveaux interacteurs (directement en XML) et les réutiliser.
Cependant, pour modéliser des comportements il nous faut écrire des scripts. LASZLO
possède quelques caractères d’un langage de programmation orienté objet comme
l’héritage, la déclaration des attributs et des méthodes, … Comme les widgets fournit par
LASZO sont prédéfinis. Nous ne pouvons que changer leur apparence par des paramètres
prédéfinis. Il n’y a pas la notion de thème dans LASZLO. Puisque LASZLO utilise des
scripts pour des comportements, il cause des difficultés pour des non-programmeurs.

2.1.3 Travail de Hudson
Hudson et al. ont proposé dans [HUDSON97] un système de thèmes pour l’apparence
des composants interactifs dans l’interface d’utilisateur. Ils ont aussi introduit un
mécanisme de composer des objets graphiques pour construire un interacteur. D’après ce
mécanisme, l’apparence d’un composant interactif est une composition des objets
graphiques (des images). Les auteurs ont aussi abordé un systèmes de contraintes entre ses
objets. Pourtant, comme le nom d’article , ce n’est pas un système de thèmes complet mais
seulement un système pour l’apparence des composants interactifs.
2.1.4 IntuiKit
C’est un environnement pour le développement des logiciels interactifs. Il permet
plusieurs acteurs (concepteur, graphiste , programmeur, …) de participer au développement
des interfaces d’ utilisateur. IntuiKit a proposé l’architecture à base des modèle XML. Le
noyau d’IntuiKit (avant mon stage) nous permet à modéliser des widgets simples en XML
comme Button, Radiobutton, CheckBox. Pour des widgets plus complexes, il ne fournit

Pham Nguyen Khang, Promotion VIII, IFI – Hanoï

11


Modélisation en du fonctionnement des composants interactifs

12

pas encore. Il manque quelques modèles nécessaires pour les restes widgets. De plus, il
s’agit de produire des widgets concrets. Donc, il est difficile (voire impossible) de les
réutiliser autant que de les étendre. Par contre, c’est une approche très intéressante pour la
composition des components interactifs. IntuiKit utilise des dessins SVG pour la
décoration. En composant des éléments SVG, nous pouvons créer des interfaces
d’utilisateur plus jolie.

2.2 Quelques remarques sur des travaux antérieurs
Les travaux considérés au-dessus me conduit à quelques remarques suivantes :
? Pour les outils à base de langage de programmation, le développement d’un logiciel
interactif dépend beaucoup des programmeurs.
? Les widgets sont modélisés comme des boîtes noires : les widgets sont implantés
sous forme des classes (de langages de programmation) ou déclarés grâce des
balises XML. Le processus de construction des widgets fait parti du code. LASZLO
nous permet de modéliser de nouveaux widgets. Mais comme il utilise des scripts
pour des comportements , ce ne sont que des programmeurs qui peuvent les écrire.
? Jusqu’à présent, il y pas de notion de thème complet pour les widgets : un thème des
widgets est une collection des guides qui participe à la construction des widgets. La
plupart des outils laisse ces guides dans la partie d’implantation. QT a introduit la
notion de thème mais malheureusement ces thèmes sont définis directement en code
de C++. C’est pour cela seulement les programmeurs peuvent créer de nouveaux
thèmes. Des thèmes dans XUL sont tout uniment des CSS qui changent seule ment
l’apparence des widgets. Les comportements et la structure des widgets
n’appartiennent pas au thème.
A partir ces analyses, notre équipe a décidé d’ajouter à IntuiKit un système complet
pour des widgets classiques (widgets de WIMP).

Pham Nguyen Khang, Promotion VIII, IFI – Hanoï

12


Modélisation en du fonctionnement des composants interactifs

Chapitre 3 :

13

Méthode et Solution

3.1 Problématique :
La plupart des toolkits qui fournissent XML (XUL, XAML) nous permet de déclarer un
widget en donnant le nom et ses attributs. Le processus de construction du widget est sousentendu, et est fait par «code arrière » (code behind). Nous n’arrivons pas à intervenir au
processus de construction. Par conséquence, il est impossible de modifier des
comportements d’un widgets (sauf que nous réécrivons le code pour le processus de
construction des widgets dans le moteur de rendu. C’est un gros travail et n’es pas
intéressant du tout !).
Nous cherchons à modéliser les widgets en XML (en plus de les noms et les attributs).
Autrement dit, nous cherchons un modèle pour des widgets afin que nous puissions décrire
leur processus de construction en XML. Et en fin, cela sert à construire un système de
thème pour des widgets. Avec cette solution, nous pouvons bien intervenir à la
construction des widgets. Il est facile de créer des différents thèmes pour les widgets (par
exemple, changer la « peau », le comportement pour un widget, … sans modifier aucun
code ). L’application sera bien séparée de d’interface. Une fois une application est écrite,
nous pouvons changer facilement l’interface sans aucune modification de l’application.
L’utilisation de XML et SVG (Scalable Vector Graphics) nous permet de rendre
téléchargeable des thèmes. Le thème est livré sous forme des fichiers XML, SVG et
éventuellement des fichiers images.
3.2
3.2.1

Environnement IntuiKit
Conception

3.2.1.1 Décomposition d’un système interactif
Dans IntuiKit, un système interactif est décomposé en plusieurs modèles qui s’appelle nt
facettes. Ces modèles sont composés grâce à un modèle de composition. La

communication entre des facette est faite par l’émis et l’abonnement de événements.
Il y a trois types de facettes principaux :
? Elément SVG : des éléments déclarés en SVG (rect, path, ..)
? FSM : machine à état finit (voir comportements discrets)
? Rules : modèle de contrôle d’affichage :
Un « rules » possède d’un état interne. L’affichage de ses fils est fait en fonction de
l’état interne.
Example :

Pham Nguyen Khang, Promotion VIII, IFI – Hanoï

13


Modélisation en du fonctionnement des composants interactifs

14

rules

idle

mask

idle ? [‘./idle’, ‘./mask’]
active ? [‘./active’, ‘mask’]

active

Figure 1 : Un rules avec ses 3 fils et 2 règles

Si l’état de « rules » est « idle » les 2 fils ‘idle’ et ‘mask’ seront affiché s. Si l’état de
« rules » est « active » ‘active’ et ‘mask’ seront affichés. D’autres cas, rien n’est affiché.
En pratique, le contrôle de l’état interne de « rules » est exécuté grâce à une FSM.
3.2.1.2 Modèle de composition des facettes
a. Arbre de composants : les composants sont organisés en arbre. Nous avons choisi cette
structure pour la cohérence avec SVG. D’ailleurs, la structure d’arbre correspond bien
à la structure de XML. Dans IntuiKit, un modèle (un sous arbre de composants) peut
être défini en Perl (ou d’autres langages de programmation dans le futur) ou en XML.
Nous pouvons instancier un modèle dans Perl ou XML
Instanciation
XML

XML

Permettre de construire
une application entière en
XML

Définition

Autre langage
Séparer la partie
d’interface avec le noyau
d’application
Permettre de faire
participer des programmeurs
et des non-programmeurs

Rendre flexible l’ajout

des nouveaux modèles dans
Autre langage de XML
Programmation classique
programmation
Importer les modèles
difficile à définir en XML
Figure 2 : Définition et instanciation de s modèles

b. Couvrement de l’arbre : la référence des nœuds est faite par le langage de référence à
nous (un peu similaire au langage XPath recommandé par W3C).
Exemples :
/ : le racine
. : le nœud courrant
.. :le père du nœud courrant
./toto : le fils ‘toto’ du nœud examiné
../toto : le frère ‘toto’ du nœud examiné
Le couvrement de l’arbre sert à indiquer la source des événements dans le modèle
d’abonnement des événements.

Pham Nguyen Khang, Promotion VIII, IFI – Hanoï

14


Modélisation en du fonctionnement des composants interactifs

15

Exemple :
. = toto

.. = titi
/ = root
../tata = tata
/toutou = toutou

root
Nœud
courrant
titi

toutou

toto

tata
Figure 3 : Exemple du couvrement de l’arbre

$toto->bind ->(-source => ‘xpath(../tata)’,
-spec => ‘BLABLA’,
-action => sub {print “tata émet BLABLA\n”}) ;

Ça veut dire que $toto s’abonne sur son frère ‘tata’. Quand un événement ‘BLABLA’
est émis par ‘tata’, l’action associé e à cet événement est déclenché e.
3.2.1.3 Comportements discrets
Les comportements discrets peuvent se modéliser en utilisant des machine à état fini.
Une machine à état fini (F inite State Machine , FSM) se compose des états et des
transitions. Une transition est franchie quand un élément lié à l’état courrant a lieu. L’état
courrant va changer en fonction de transition.
Exemple :
<PRESS>

press
start
<RELEASE>

<CLICK>

<ENTER>

<LEAVE>

<RELEASE>
leave
<EVENEMENT>

: événement reçu

<EVENEMENT>

: événement émis

Figure 4 : FSM modélisant le comportement d’un Bouton

L’utilisation des FSM nous permet de concevoir des événements plus haut niveau.
Comme décrit dans [Acott], des événements en plus haut niveau (par exemple : double-

Pham Nguyen Khang, Promotion VIII, IFI – Hanoï

15

Modélisation en du fonctionnement des composants interactifs

16

clic, glisser-déplacer) à partir des événements de niveau plus bas (presse, relâche, déplace).
Cela forme un transducteur des événements.
<CLICK>

<CLICK>
click

start
<DOUBLE-CLICK>

<EVENEMENT>

: événement reçu

<EVENEMENT>

: événement émis

<TIME_OUT>

Figure 5 : Transducteur des événements

3.2.1.4 Fusion des variables (merge)
C’est un mécanisme qui permet d’exprimer quelques comportements continus. Un
changement d’un variable cause le changement des autres. Quand nous faisons une fusion
entre un attributs des fils et celui du père, cela nous donnera une encapsulation.

La synchronisation de l’état d’une FSM et d’un « Rules » est faite par ce mécanisme.
Exemple:
$fsm->merge(-name => [$fsm->current_state, $rules->current_rule]) ;

Chaque fois quand le $fsm change l’état (un événement a lieu, par exemple), l’état
interne de $rules change aussi. Par conséquence, cela constitue un modèle «control –
vue » (control - view).
Cependant, ce mécanisme ne permet pas d’exprimer tous les comportements continus. Il
n’est possible que d’exprimer des contraintes de type «égal» (a = b = …). Nous avons
donc besoin d’autres modèles pour pouvoir modéliser des comportements continus.
3.2.1.5 Modèle d’émis et d’abonnement des événements
Un événement est la représentation de asynchrone occurrence (comme un clic de souris,
une touche de clavier, …) associé avec un élément cible .
Modèle d’abonnement recommandé par W3C : en général, quand un événement a lieu
il est expédié à partir du racine à l’élément (source d’événement) qui émet l’événement
dans la phase « capturer ». Du source d’élément l’événement peux être passé l’arbre encore
une fois en direction inverse dans la phase « bubbling ». Un événement peut être répondu à
n’importe où (un observateur) dans le chemin dans n’importe quelle phase par lançant une
action et/ou en arrêtant l’événement.

Pham Nguyen Khang, Promotion VIII, IFI – Hanoï

16


Modélisation en du fonctionnement des composants interactifs

17

Figure 6 : M odèle d’abonnement des événements recommandé par W3C

Dans IntuiKit, la communication entre des facettes est effectuée par le mécanisme
d’abonnement des événements. Un événement s’identifie par une source (une facette) et
une spécification, et éventuellement est accompagné par des paramètres. Quand un
événement a lieu, le déclenchement des actions associées à cet événement est lancé.
Le modèle d’abonnement des événements dans IntuiKit utilise seulement la deuxième
phase (phase bubbling), et la propagation s’arrête quand il y a un observateur qui
consomme cet événement. Dans une action, des événements peuvent être aussi émis. Donc,
en s’abonnant sur une facette, un consommateur peut capturer tous les événements émis
par cette facette, ses fils et ses descendances (si il n’y a personne qui s’abonne sur les
derniers).
3.2.2 Exemple
Nous allons analyser et créer le widget bouton. Le bouton que nous examinons a forme
rectangle avec un texte centré. Par défaut, le bouton est en état « normal » (représenté par
la couleur bleu). Quand nous poussons sur le bouton, il va à l’état « poussé » (représenté
par la couleur rouge) et quand nous le relâchons, il revient l’état « normal ».
Analyse :
L’apparence : nous utilisons un rectangle bleu pour l’état « normal » et un rectangle
rouge pour l’état « poussé ». Tous les 2 états partagent un texte commun. De plus, un
masque (invisible) sera utilisé pour capturer des événements de la souris. Il y aura 2 règles
utilisés pour le contrôle d’affichage :
? normal ? [normal, text, mask]
? push ? [press, text, mask]
Comportement : nous nous servons un FSM à 2 états pour modéliser le comportement
du bouton.

Pham Nguyen Khang, Promotion VIII, IFI – Hanoï

17

Modélisation en du fonctionnement des composants interactifs

18


normal

push
<release>
<click >

Figure 7 : FSM pour le comportement du bouton

De l’état « normal », FSM changera son état en état « press » si l’événement « press » a
lieu. Et de l’état «press » si l’événement « release » se produit FSM reviendra à l’état
« normal ». la synchronisation entre FSM et Rules est faite par le mécanisme de fusion des
variables.
Structure des composants :
Root

text
Fusion des
variables

current_rule
FSM

Rules
current_state

text
norm al

push

label

mask

Figure 8 : Structure du modèle de bouton

Création en XML (fichier button.xml)
<component xmlns=“component”>
<!-- definitions des modèles -->
<definitions>
<!-- rules -->
<model id=“rules” xmlns=“rules”>
<rule id=“normal”>
<renderpart part-xpath=“normal”/>
<renderpart part-xpath=“label”/>
<renderpart part-xpath=“mask”/>
</rule>
<rule id=“push”>
<renderpart part-xpath=“push”/>
<renderpart part-xpath=“label”/>
<renderpart part-xpath=“mask”/>
</rule>
</model>
<!-- modèle de fsm -->

<model id=“fsm” xmlns=“fsm”>
<inputs>

Pham Nguyen Khang, Promotion VIII, IFI – Hanoï

18


Modélisation en du fonctionnement des composants interactifs

19

spec=“<ButtonPress-1>”/>
spec=“<ButtonRelease-1>”/>
</inputs>
<transitions>
<transition from=“normal” on=“press” to=“push”/>
<transition from=“push” on=“release” to=“normal” output=“click”/>
</transitions>
</model>
</definitions>
<!-- arbre de composants -->
<structure>
<!-- fsm référence sur le modèle -->

<!-- rules -->

<rect id=“normal” width=“200” height=“50” fill=“blue” xmlns=“svg”/>

<rect id=“push” width=“200” height=“50” fill=“red” xmlns=“svg”/>
xmlns=“svg”/>
<text id=“label” position=“100,25” text=“Button” anchor=“cente”/>
</part>
</structure>
<!-- fusion des variables -->
<variables>
< !-- synchronisation entre « FSM » et « Rules » -->
<var id=“state” default-value=“normal”>
<importvar part-id=“button_fsm” variable=“current_state”/>
<importvar part-id=“button_rules” variable=“current_rule”/>
</var>
< !-- encapsulation d’attribut pour réutilisation -->
<var id=“text” default-value= “OK”>
<importvar part-id=“label” value=“text”/>
</var>
</variables>
</component>

La paire <component> et </component> définit le racine du modèle. Les modèles de
FSM et de Rules sont définis dans la partie <definitions>. Les événements sont définis par
des balises <input> . Un événement s’identifie par une source (une référence sur un
composant)
et
une
spécification.
Les
expressions
de

XPath
(e.g.
xpath(../button_rules/mask) ) sont utilisés ici pour indiquer la source des événements.
La partie <structure> déclare la structure du modèle de bouton. La fusion de la variable
current_state et variable current_rule est décrite dans la partie <variables>

Pham Nguyen Khang, Promotion VIII, IFI – Hanoï

19


Modélisation en du fonctionnement des composants interactifs

20

Résultat :

Figure 9 : Widget bouton modélisé en XML dans IntuiKit

3.3 Les modèles manquants dans IntuiKit et solutions
IntuiKit manque quelques modèles pour pouvoir modéliser des widgets en XML. En
analysant des besoins et donnant des scénarios d’utilisateur, j’ai trouvé enfin les modèles
suivants :
? Modèle de comportements continus : nous permet d’exprimer des contraintes plus
flexibles que fusion des variables.
? Modèle de disposition (layout model) : organise des facettes graphiques grâce au
système de contraintes.
? Modèle de conteneur : il y a certaines widgets comme TabBox, Window, … qui
peuvent contenir d’autres widgets. C’est la raison pour laquelle nous avons besoin
d’un modèle pour de tels widgets.

? Modèle de vue /coupure (view/clipping) : définit une vue pour un composant
graphique. En changeant la vue, nous pouvons faire des widgets scrollables.
? Modèle de thèmes pour des widgets : nous cherchons à modéliser un système de
thèmes pour des widgets qui fonctionne comme un système de polices pour des
textes.
3.3.1 Comportements continus
Il est impossible d’exprimer tous les comportements en utilisant simplement des FSM.
Par exemple : dans le widget « bar de défilement » (scrollbar), le déplacement du bar de
défilement est associé à celui de la souris ; un autre exemple, c’est que nous voulons
modéliser un widget dont la taille peut être changé en fonction du déplacement de la souris.
A ce propos, il demande un modèle pour décrire ces contrainte s. Après avoir beaucoup
travaillé sur ce problème, j’ai trouvé que le systè me de contraintes à sens unique est un des
bons choix. Ce système est aussi utilisé pour organiser des facettes graphiques (voir
modèle de disposition).
3.3.1.1 Attributs à base d’expressions
Exemple 1 : nous voulons modéliser le widget Button avec un texte centré sachant que
le Button a forme d’un rectangle et le texte est aligné au centre. Donc, nous obtenons 2
contraintes suivantes :
Text.x = Rectangle.x + Rectangle.width / 2
Text.y = Rectangle.y + Rectangle.height / 2

Pham Nguyen Khang, Promotion VIII, IFI – Hanoï

20


Modélisation en du fonctionnement des composants interactifs

21

Et sont modélisés en XML comme suit :

y = “# #rectangle.y# + #rectangle.height# / 2 #” … />

Push Button
Figure 10 : Une contrainte géométrique entre le texte et le rectangle

Exemple 2 : en modélisant le widget « bar de défilement », j’utilise un variable « pos »
pour indiquer la position du bar. La position du bar dans l’écran peut s’exprimer par la
formule :
Bar.y = pos * length / max + margin
margin

Bar.y
Domaine de vue et
contrôle

0

pos

Bar.y+ dy

pos’

margin + length

max

Domaine de données

Figure 11 : Modèle du widget « bar de défilement » (ScrollBar)

Et quand nous déplaçons le « bar » (faire un glisser-déplacer sur le « bar »), la nouvelle
valeur de « pos » sera calculé e par :
pos’ = pos + dy * max / length
Cela se modélise en XML comme suit :
<dragger part_id=“bar” … >
<do op=“adjust” variable=“root.pos” value=“#mouse.dy#” …/>
</dragger>

Ça veut dire que quand nous faisons un glisser-déplacer sur la facette « bar », la valeur
de « root.pos » est recalculée par la formule ci-dessus.
Dans le noyau actuel d’IntuiKit, nous ne pouvons exprimer ces contrainte s qu’en code
mais pas en XML. C’est la raison pour laquelle j’ai cherché à trouver une solution pour ce
problème. Et en fin, la solution d’utiliser les attributs à base d’expressions a été choisie.
D’après cette solution, les attributs d’un widget peuvent accepter une expression comme sa
valeur. Et la vraie valeur sera calculée quand nécessaire. En utilisant les attributs à base
d’expressions, il est capable d’exprimer presque tous les contraintes calculables.
Cependant, ce choix n’est pas très facile pour les non-programmeurs. A long te rme, il
demande d’autres modèles plus efficace, un nouveau langage pour la description des
contraintes , par exemple.

Pham Nguyen Khang, Promotion VIII, IFI – Hanoï

21


Modélisation en du fonctionnement des composants interactifs

22

3.3.1.2 Système de contraintes à sens unique (One way constraint system)
L’utilisation de s attributs à base des expressions demande un mécanisme d’ évaluation
des expressions. Autrement dit, les attributs à base d’expressions forment un système de
contraintes et nous cherchons à les résoudre. Pour simplifier, je propose que les contraintes
que nous pouvons décrire ne forment pas de boucle. Ça veut dire qu’il n’existe pas le cas
où un attribut A1 dépend d’un attribut A2 qui dépend d’un autre attribut A3, et ainsi de suite
jusqu’à l’attribut An et An dépend de l’attribut A1.
Avec cette limite, notre système de contraintes est un système de contraintes à sens
unique (ou un flot de données). Grâce à l’algorithme d’arrangement de graphe, j’ai trouvé
une solution que nous pouvons voir ci-dessous pour résoudre de tels systèmes de
contraintes. Cet algorithme est plus rapide que l’algorithme paresseux décrit dans
[Hudson96] car tous les nœuds à calculer sont examinés une seule fois.
Description : un tel système de contraintes peut se représenter par un graphe orienté
sans boucle . Chaque nœud est lié à une variable (attribut d’un widget). Une arrête de i à j
signifie que la variable i dépend de la variable j (j est présent dans l’expression de ).
i
L’évaluation de i est réalisée après celle de j.
Exemple :
toto.width = tata.width/2 + 10
Le nœud associé à la variable « toto.width » est examiné après le nœud associé à la
variable « tata.width ».
Solutionneur des contraintes (Constraints solver) : a pour but de résoudre des
contraintes.
Algorithme d’évaluation des variables :
1. Arranger le graphe par l’algorithme d’arrangement de graphe.
2. Evaluer les variables (basé sur leur rang ). Les variables qui ne dépendent de rien
(leur rang est le plus élevé) seront évaluées d’abord. Ensuite les variables dont le

rang est moins de 1, et ainsi de suite, … En fin c’est le tour des variables don trien
ne dépend.
Propagation des changements : quand il y a un changement pour une variable. Ce
changement doit être propagé pour toutes les variables qui dépendent de cette variable pour
maintenir des contraintes. En bref, toutes variables dépendant de cette variable doit être
recalculées.
Algorithme de propagation des changements :
Appelons :
?
?

N : le nœud qui cause le changement
Q : la file d’attente contenant les nœuds à évaluer. Les nœuds dans Q sont triés par
leur rang.

Algorithme :
Q contient les nœuds « père » de N (ceux qui dépendent directement de N)
Tant que « Q n’est pas vide » faire
1. A ?le premier nœud dans Q

Pham Nguyen Khang, Promotion VIII, IFI – Hanoï

22


Modélisation en du fonctionnement des composants interactifs

23

2. Enlever A de Q

3. Evaluer A
4. Insérer tous les nœuds « père » de A à Q (faire attention à l’ordre des nœuds
dans Q)
Fin
Examinons un exemple suivant : nous avons l’intention de modéliser une fenêtre
(widget Window) comme le dessin ci- dessous.

Figure 12 : Un modèle du widget Fenêtre (Window)

Pour simplifier, nous ne décrivons que les contraintes pour la partie en haut.
Left
Center
Right

Les contraintes:
Center.x = Left.width
Center.y = Left.height – Center.height
Center.width = Window.width – Left.width – Right.width
Right.x = Window.width – Right.width
Right.y = Center.y

Pham Nguyen Khang, Promotion VIII, IFI – Hanoï

23


Modélisation en du fonctionnement des composants interactifs

24

Left.width
Center.x

Left.height
Right.y
Center.y

Root
Window.width
Center.width

Center.height
Right.x

Right.width

Rang 0

Rang 1

Rang 2

Rang 3

Figure 13 : Graphe représentant les contraintes avec rang des nœuds

Travail similaire : CSVG (Constraint Scalable Vector Graphics) [McCormack] utilise
aussi des attributs à base d’expressions et système de contraintes à sens unique pour créer
des documents adaptés à la taille de l’écran.
3.3.2 Modèle de disposition :

Pour simplifier l’organisation des facettes graphiques, la notion de disposition est
introduite. En fait, le modèle de disposition nous aide à organiser des morceaux
graphiques. Une disposition se traduit en quelques contraintes géométriques (les attributs
x, y, largeur, hauteur ) entre des facettes graphiques.
Les types de disposition : dans mon travail j’ai implémenté quelques types de
disposition suivants :
?

Disposition verticale : organise les objets en direction y.

Pham Nguyen Khang, Promotion VIII, IFI – Hanoï

24