RAPPORT DE STAGE DE DEA

Definition dune architecture de mediateur pour des agents

conversationnels animes
Karl LE GUERN
3 septembre 2004

R
esum
e :
Le stage de DEA se situe dans le cadre des agents dialogiques, cest-`a-dire des composants
logiciels capables de raisonner sur leur propre structure et fonctionnement pour repondre
`a des requetes (formelles ou, idealement, en langue naturelle).
Il sest deroule au sein du LIMSI-CNRS `a Orsay (91), sous la direction de J.-P. Sansonnet,
et de J.-C. Martin. Mon objectif est de definir une architecture de mediateur pour des
agents conversationnels animes. Durant ce stage, mon activite principale est detablir une
communication / synchronisation entre les trois modules principaux de notre architecture, cest-`a-dire un composant generique `a medier, un agent anime LEA, et un mediateur
contenant une representation symbolique du composant generique.
Remerciements :
`a J.-P. Sansonnet et J.-C. Martin, responsables de stage,
`a S. Abrilian, S. Buisine, pour leur aide sur LEA,
`a E. Augustin, A. Dy, O. Dy, M.-H. Papadopoulos, el`eves de lEPITA, pour leurs
Applets JAVA,
aux personnes qui ont participe `a la premi`ere experimentation de DaftLea.

Table des mati`

eres
1 Probl
ematique
1.1 Contexte de Recherche . . . . . . . . . . . . . . . . .
1.2 Objectifs du stage . . . . . . . . . . . . . . . . . . .
1.3 Le th`eme de recherche ACA : Etat de lart . . . . . .
1.3.1 Introduction . . . . . . . . . . . . . . . . . .
1.3.2 Les Agents Intelligents . . . . . . . . . . . . .
1.3.3 Les Agents Conversationnel . . . . . . . . .
1.3.4 Les Agents Assistants Personnels . . . . . .
1.4 Le th`eme de recherche Agent Dialogique : InterViews
1.4.1 Le projet InterViews . . . . . . . . . . . . . .
1.4.2 Le projet DAFT . . . . . . . . . . . . . . . .
1.5 DAFTLEA : specification du projet . . . . . . . . . .
2 Le mod`
ele darchitecture DaftLea
2.1 Architecture generale DaftLea . . . . .
2.2 Description de lagent LEA . . . . . .
2.2.1 Presentation de lagent LEA .
2.2.2 Architecture logicielle de LEA
2.3 Description de DAFT . . . . . . . . .
2.3.1 description generale . . . . . .
2.3.2 le mod`ele DAFT . . . . . . . .
2.3.3 le ScriptLanguage . . . . . . .

. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
et DAFT
. . . . . .
. . . . . .
. . . . . .

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

5
5
5
6
6
7
8
8
10
10
10
11

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

12
12
12
13
14
15
15
16
18

3 Mise en oeuvre de larchitecture DaftLea

3.1 Integration des differents modules . . . . . . . . .
3.2 Controler LEA . . . . . . . . . . . . . . . . . . .
3.2.1 Animer LEA . . . . . . . . . . . . . . . .
3.2.2 Designer un objet du composant . . . . .
3.3 Synchronisation des mod`eles . . . . . . . . . . . .
3.3.1 Communication Composant Mediateur
3.3.2 Communication Mediateur Composant
3.4 Chane globale TALN integree . . . . . . . . . . .

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

20
20
20
20
21
23
23
27
27

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

4 Exp
erimentation
28
4.1 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.2 Apport de lexperimentation pour GRASP . . . . . . . . . . . . . . . . . . . 29
4.3 Apport de lexperimentation pour DAFT . . . . . . . . . . . . . . . . . . . 29
5 Conclusion et Perspectives

30

6 Bibliographie
6.1 Th`eme : View Design Language / Mediateur / Observateurs
6.2 Architectures / Model View Controller (MVC) . . . . . . .
6.3 Th`eme : LEA (Limsi Embodied Agent) . . . . . . . . . . .
6.4 Th`eme : Les agents assistants . . . . . . . . . . . . . . . . .
6.5 Th`eme : Les agents conversationnels . . . . . . . . . . . . .

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

31
31
31
31
31
32

7 ANNEXES
33
7.1 ANNEXE I : Source du composant JAVA : Coco le compteur . . . . . . . 33
7.2 ANNEXE II : Source du mod`ele de Coco le compteur . . . . . . . . . . . 37

1
1.1

Probl
ematique
Contexte de Recherche

Ce stage se place dans le cadre dune collaboration qui demarre entre dune part le
th`eme de recherche de Jean-Claude Martin sur les agents conversationnels animes (projets NICE et HUMAINE) et le th`eme agents dialogiques de Jean-Paul Sansonnet (projet
InterViews et DAFT).
La generalisation des services via lInternet am`ene une nouvelle classe dusagers qui ont des
particularites nouvelles : populations massives, fortement heterog`enes, non specialistes de
linformatique, utilisant les services sporadiquement ; ceci engendre de nouveau besoins sur
trois plans principaux : laccueil de lusager (lui donner confiance, sadapter `a son profil),
lassistance lorsquil est perdu dans le service, voire lapprentissage lorsquil sagit dinteraction plus durable. Ceci a conduit `a proposer des outils dassistance, allant des simples
help on line actuels, dont les resultats sont notoirement decevants, aux tous nouveaux
Agents Conversationnels Animes (ACA) qui se donnent pour objectif de combler le fosse
semantique/cognitif entre lusager et lapplication. Pour ce faire, deux types detudes ont
ete menees : dune part sur la notion dagent dialogique, cest-`a-dire des composants logiciels capables de raisonner sur leur propre structure et fonctionnement pour repondre
`a des requetes (formelles ou, idealement, en langue naturelle) ; et dautre part sur la notion dagent anime, cest-`a-dire generalement des personnages utilisant les modalites
verbales et non-verbales de communication humaine qui accompagnent les applications.
Cette separation est methodologique car la problematique, dans sa generalite, est tr`es
complexe et les questions `a resoudre ne sont pas de meme nature tant au plan des outils
que des communautes scientifiques concernees (IA et TAL pour la premi`ere, IHM et ECI
pour la seconde). Nous pensons quil est necessaire de proposer une architecture logicielle
generique qui permettrait dintegrer les divers outils autour dune meme representation
mediateur, en vue de proposer une chane compl`ete dagent conversationnel anime. Le
point central reside dans la definition de la representation mediateur et surtout dans les
relations quelle etablit avec les outils. Pour donner un exemple de relation, on se pose la
question de lextraction, `a partir de lapplication, de representations (forcement imparfaites) sur lesquelles les outils dialogiques pourront raisonner : que faudrait t-il idealement
extraire ? que peut-on effectivement extraire ? que peut-on attendre de la representation
extraite ? etc.

1.2

Objectifs du stage

Lobjectif de ce stage est de definir une architecture logicielle de mediateur permettant

dintegrer des outils dinterrogation et de contr
ole dans des applications dotees dagents
conversationnel animes (ACA).
Nous disposerons donc de trois elements qui devront pouvoir communiquer, se synchroniser :
le composant (ici, une application JAVA)
le mediateur (module fourni par J.P. Sansonnet)

 un ACA, dans le cadre du projet : LEA (LIMSI Embodied Agent), fourni par J.C.
Martin
Le travail porte plus particuli`erement sur :
Letat de lart et etude des environnements logiciels des agents animes : architectures,
langages de specification, langages de contr
ole dagent.
La proposition dune architecture entre les trois entites de base (le composant effectif,
lagent conversationnel anime et le mediateur) incluant la definition des fonctions
des formats et des protocoles dinterface entre les entites
Des applications tests utilisant lagent LEA du LIMSI-CNRS .
Les applications choisies sont :
Coco le compteur : un simple compteur dont la vitesse de decompte est contr
olable.
Le classique jeu des Tours de Hano.
La representation visuelle des objectifs du stage ci-dessous permettront davoir une
vision plus claire du projet :

Fig. 1 Objectifs du stage : DaftLea

1.3
1.3.1

Le th`
eme de recherche ACA : Etat de lart
Introduction

Les agents assistants personnels font partie du grand ensemble des agents intelligents. Dans notre etude, nous commencerons par decrire ce quest un agent intelligent.
Ensuite, nous parlerons des agents conversationnels qui sont des agents intelligents dotes de
la possibilite de dialoguer avec leur utilisateur via le Traitement Automatique du Langage
Naturel. Enfin, nous decrirons les agents assistants personnels. Ces derniers disposent des
competence de dialogue de lagent conversationnel, mais peuvent aussi executer plusieurs
6

actions pour assister leur utilisateur.

1.3.2

Les Agents Intelligents

D
efinition
Un agent intelligent a plusieurs definitions possibles : il y a ceux qui les assimilent `a
des etre humains, et ceux qui les consid`erent comme de simple programmes. Selon certains chercheurs, un agent est une entite autorisee `a agir au nom de quelquun dautre.
concr`etement, un agent est : une entite logicielle possedant des caracteristiques propres
et agissant dans le but daccomplir une t
ache au nom dune autre entite.
Principe de fonctionnement
Les principaux composants de lagent intelligent sont les suivants :

le moteur correspond `a la representation symbolique de lagent.

les connaissances representent ce que lagent sait, croit et pense, elles sont stockees dans
les librairies
linterface utilisateur permet detablir une communication entre lagent et lutilisateur.
Quelques techniques dintelligence artificielle utilis
ees par les agents

Syst`emes de recherche (exploration des espaces de recherche),

Syst`emes expert,
T.A.L.N. (Traitement Automatique des Langues Naturelles),
Reconnaissance de pattern, data-mining,
Apprentissage automatise,
Logique floue...

1.3.3

Les Agents Conversationnel

D
efinition
Lidee des agents conversationnels est nee avec le programme ELIZA (programme simulant
un psychologue) `a la fin des annees 60. Lagent conversationnel (on dit aussi Chatterbot)
est un agent intelligent disposant dun syst`eme de dialogue lui permettant detablir une
communication verbale avec son utilisateur ce qui offre une interaction plus conviviale,
naturelle. On entend par dialogue, lutilisation des differents actes de langages tels que :
une serie de questions/reponses,
emettre une opinion/ un commentaire,
enoncer des faits,
etre declaratif, assertif, expressif...
Les agents incarn
es (i.e. disposant dune representation virtuelle) permettent en plus
de la communication verbale, une communication non-verbale (posture, expression du visage) augmentant ainsi la qualite de la conversation.
Les applications
Il existe plusieurs domaines dapplications pour les Agents conversationnels. Pour le grand
public, les agents conversationnels trouvent leur place dans les outils pedagogiques, les jeux
et lassistance personnalisee (ex : aide `a la navigation personnalisee). En ce qui concerne
les entreprises, les agents conversationnels touchent differents secteurs comme le marketing electronique, la communication entreprise/client. Un agent conversationnel peut, par
exemple, accueillir les visiteurs (internautes) 24h/24 ce qui reduit la gestion co
uteuse des
appels telephoniques et des mails. Lagent contribut aussi `a limage de marque de lentreprise en creant une relation plus humaine et en faisant passer un message aux internautes.
(remarque : le chatterbot de CocaCola est considere comme une vraie personne pour 40 `a
50% des internautes).
Etat actuel des recherches, et vision davenir
La technologie utilisee pour les agents conversationnels est aujourdhui assez simple, elle
est basee sur la reconnaissance des formes. Cependant, la recherche actuelle nous fournit
des programmes danalyse de texte (phrase) tr`es poussees. Les objectifs actuels de la
recherche sont dune part dameliorer la comprehension de texte en offrant la possibilite
de traiter nimporte quel texte (domaines varies, types varies) et, dautre part, de fournir
dautres moyens de communiquer avec lagent conversationnel (ex : telephone portable).
1.3.4

Les Agents Assistants Personnels

D
efinition
Lagent assistant personnel (IPA : Intelligent Personnal Assistant) est un agent destine
`a nous aider dans notre travail quotidien, un peu comme une secretaire virtuelle. Il nous
aide a executer des taches, il peut aussi en executer `a notre place. Grace `a cet assistant,
lordinateur devient un collaborateur intelligent, actif et surtout personnalise.
Les principaux attributs de cet agent sont :

Autonomie Il doit etre capable dintervenir sans demande de lutilisateur. Pour cela, il
doit observer les actions de lusager, et reconnatre les taches repetitives pour les
automatiser. (Apprentissage, plan daction)
Personnalisation Lagent doit sadapter `a lutilisateur. Au fur et `a mesure de son utilisation, il doit apprendre les habitudes de lutilisateur (exemple : reperer les th`emes
favoris recherches sur Internet pour laider dans la navigation web et lui proposer
des sites en rapport avec ce th`eme), et ainsi adapter son comportement.
Communication Comme un agent conversationnel, lassistant doit etre capable de tenir
un discours avec son utilisateur. La qualite de ce discours est importante : plus le
langage de lagent sera naturel, plus lutilisateur assimilera lagent `a un etre humain.
On doit pouvoir communiquer avec lui de plusieurs mani`eres (mails, web, interface,
telnet, telephone...)
Comp
etence Il doit etre competent dans son domaine dapplication. Cet attribut joue
un role important dans la confiance de lutilisateur vis `a vis du logiciel : Plus lagent
est competent, plus lutilisateur aura confiance et plus il lui donnera de taches `a
executer.
Coop
eration En cas de necessite ; lagent doit pouvoir cooperer avec dautres agents pour
executer une tache plus complexe. Actuellement, cette cooperation avec dautres
agents reste limitee.
Il existe differents types dagents assistants :
les agents semi-autonomes Cest un agent fiable, mais non-competent, lusager doit
programmer lagent (script) pour quil execute des taches.
les agents `
a bases de connaissances On doit fournir `a lassistant une base de connaissance compl`ete sur ses objectifs et sur son (ou ses) utilisateur(s). Il est cependant capable de reconnatre les plans daction de lutilisateur et de lassister durant
lexecution de ces plans. Malheureusement, la conception de ce type dagent demande
beaucoup de travail, notamment pour la creation de la base de connaissance.
les agents apprenants Ces agents poss`edent une base de connaissance initiale, mais
sont capable de lenrichir au cours de leur execution. En effet, ces agents observent
et imitent les actions de lutilisateur. ils peuvent demander conseil `a dautres agents
pour lexecution dune tache complexe. Enfin, lutilisateur peut intervenir si il ne
souhaite pas que lagent execute certaines tache. Ces agents sont consideres comme
fiable car ils sadaptent graduellement au comportement de lutilisateur et peuvent,
si on leur demande, justifier leurs actions.
Lentranement de lagent se fait par apprentissage (Machine Learning). Au debut
de cet apprentissage, lagent est peu competent, mais au fil de ses interactions avec lutilisateur, lagent se personnalise et sadapte `a lusager. Pour cela, il se programme lui
meme en recuperant des connaissances necessaires aupr`es de lusager. La recuperation de
ces connaissances peut se faire de differentes mani`eres :
9

observer/imiter lusager,
sadapter selon les feedbacks de lusager,
`a partir dexemples fournis par lusager,
en se formant aupr`es dautres agents

Les principales comp

etences dun agent personnel
Voici quelques actions que peuvent effectuer les agents assistants personnels :
etablir un dialogue (discours, conversation) avec son utilisateur,
gerer des ev`enements et procedures (gestion de rendez-vous, emploi du temp...),
executer des taches `a la demande de lusager,
assistance `a la collaboration entre differents usagers (Workflow),
former / enseigner lusager,
gestion / classement du courrier electronique,
repondre automatiquement au courrier electronique,
surveillance automatique des changements sur les sites Web,
recherche de th`eme sur Internet,
sadapter `a son utilisateur,
assister lusager dans lutilisation dautres applications
Bilan
Bien que les agents assistants soient encore peu rependus, leur utilite nest plus `a demontrer
et leur succ`es grandit. Cependant, plusieurs questions se posent :
Comment garantir la confidentialite des utilisateurs alors que les agents discutent
entre eux et sechangent des informations sur leurs proprietaires.
Comment faire communiquer des agents construits par des entreprises differentes,
ou utilisant des technologies differentes.
Comment etendre leur champ dapplication

1.4
1.4.1

Le th`
eme de recherche Agent Dialogique : InterViews et DAFT
Le projet InterViews

InterViews est un projet developpe depuis 2000 dans le groupe AMI du LIMSI-CNRS.
Il introduit la notion dagents dialogiques. Un agent dialogique est un composant ayant
connaissance de son propre fonctionnement, et etant capable de raisonner dessus. Il doit
aussi etre capable de repondre `a des questions (i.e. requetes ecrite en langue naturelle)
sur son fonctionnement. Un domaine dapplication de ce projet est lassistance des usagers
dans lutilisation des services on-line du Web.
voir page Web : http ://www.limsi.fr/Individu/jps/interviews/index.html
1.4.2

Le projet DAFT

DAFT est un projet lance en janvier 2004 dans le groupe AMI du LIMSI-CNRS.
Suite du projet InterViews, il a pour objet linterpretation et la resolution des requetes
utilisateurs dans des situations de mediation dialogique. Pour cela il sappuie sur VDL
10

(View Design Language), un langage de description de mediateur concu dans le cadre du

projet InterViews.
Parmis les evolutions par rapport au projet InterViews, nous pouvons noter les points
suivants :
separation accentuee entre le mod`ele et le composant,
traitement de questions en langue naturelle,
possibilite dint`egrer un ACA,
possibilite de medier des applications stand alone.
voir page Web : http ://www.limsi.fr/Individu/jps/research/daft/daft.htm

1.5

DAFTLEA : sp
ecification du projet

Le syst`eme DafLea est une implementation des agents dialogiques. Dans le cadre de ce
stage, certaines contraintes ont ete fixees. Dune part, notre syst`eme doit etre g
en
erique
vis `
a vis du composant, cest `a dire quil doit pouvoir sadapter `a un composant sans
avoir ete programme specifiquement pour ce composant. Enfin, Daftlea doit pouvoir etre
g
en
erique vis `
a vis de lutilisateur, cest `a dire que lutilisateur ne doit pas avoir
`a apprendre un langage precis pour pouvoir contr
oler le composant, mais doit pouvoir
communiquer avec lui en langue naturelle. Enfin, idealement, le syst`eme doit sadapter
aux differents styles linguistiques des usagers.

Fig. 2 Genericite du mediateur vis `a vis de lutilisateur (`a gauche) et vis `a vis du
composant (`a droite)
Pour implementer ce syst`eme nous devrons faire appel `a plusieurs technologies, la
plupart etant developpee par le LIMSI-CNRS :
Afin doffrir la possibilite au composant de raisonner sur son fonctionnement interne,
sur sa structure, nous nous sommes inspires du projet DAFT [J.-P. Sansonnet], et du
projet InterViews [J.-P. Sansonnet] . Ces deux projets nous apportent les notions
de mediateurs, observateurs, langage de representation VDL, langage de requete
VQL.
Afin de rendre plus (( vivante )) notre application, et de faciliter ainsi laspect dialogique avec lutilisateur, nous ferons appel `a la technologie des Agents Conversationnels Animes (ACA), notamment lagent LEA (LIMSI Embodied Agent) developpe
par le LIMSI-CNRS.

11

2
2.1

Le mod`
ele darchitecture DaftLea
Architecture g
en
erale DaftLea

Dans le cadre de notre projet, le mediateur joue un role clef. En effet, il est charge de
traiter les requetes de lutilisateur et dinteragir avec le composant. Pour cela, il comporte
un module de traitement du langage naturel pour analyser les questions ecrites en langue
naturelle (module GRASP), ainsi quune representation symbolique interne du composant
et de son fonctionnement (mod`ele DAFT) pour pouvoir satisfaire aux requetes. Ci-dessous,
une vision simplifiee de la place du mediateur :

Fig. 3 Architecture generale de DaftLea

Dans le cadre de ce stage, le composant effectif est une applet Java. Les raisons de ce
choix sont simples : En java, une applet doit contenir des methodes de base pour linitialisation, le lancement, laffichage... Ce qui nous donne une premi`ere (( piste )) pour permettre
au mediateur de controler le composant. Enfin, il est plus facile, en Java dafficher une
applet dans une fenetre. En effet, dans le cadre dune application, nous ne pouvons affirmer que la classe principale (( derivera )) dune classe Frame, ou dun objet graphique
quelconque. Cependant, toute letude se fait dans le cadre dun composant, quil soit une
applet, ou une autre application.

2.2

Description de lagent LEA

Dans le projet DaftLea, LEA permet davoir une representation visuelle du mediateur.
Elle dispose aussi de quelques fonctionnalites independantes du composant, destinees `a la
rendre plus vivante. Parmis ces fonctionnalites nous avons un syst`eme de production

12

linguistique associant des animations aux reponses du mediateur (module EVA).

Dans le cadre de la mediation, LEA joue un role essentiel dans laide `a la comprehension.
En effet, lorsque le mediateur citera un objet du composant (un bouton par exemple), LEA
doit pointer cet objet, facilitant ainsi la comprehension des explications pour lutilisateur.
2.2.1

Pr
esentation de lagent LEA

Description du projet
Developpee au LIMSI-CNRS, LEA est un agent conversationnel 2D cartoon-like. Un
des objectifs finaux de ce projet est que LEA puisse adopter un comportement (expression
faciale, gestuel...) base sur une approche experimentale. En effet, si nous souhaitons une
application pedagogique pour LEA, son comportement sera base sur des caracteristiques
issues dannotation de videos (i.e. professeurs filmes pendant un cours).

Fig. 4 Lagent du LIMSI : LEA

Principe de LEA
Le principe de LEA est le suivant :
sur le plan de laffichage/animation : LEA est un personnage 2D, un affichage
dune posture de LEA est une combinaison de plusieurs images (GIF) 2D correspondant `a des positions precises de chacune des parties de son corps (corps, tete,
bouche, yeux, sourcils, bras et mains). Pour creer une animation, on decrit une serie
de position (appelees (( configuration ))) dans un fichier XML. Ce fichier est traite par

13

le programme (JAXP), et chacune des configurations est affichee sequentiellement

creant ainsi une animation.
sur le plan de la multimodalit
e : LEA peut exprimer une information de plusieurs
mani`eres (synth`ese vocale, posture du corps, phrase ecrite). Lorsque LEA souhaite,
par exemple pointer un objet, elle peut le decrire oralement, ou gestuellement (si elle
decrit un objet cubique, elle dessinera un carre avec ses mains, cf image ci-dessous),
elle peut aussi le pointer directement... En combinant ces differentes modalites nous
obtenons un eventails assez varies de mani`eres de referencer un objet. Le syst`eme
TYCOON permet de travailler avec ces differentes modalites.

Fig. 5 position des mains pour decrire un objet cubique

Les technologies de LEA : Cet agent conversationnel a ete concue en Java, et
fait appel a des technologies comme ViaVoice (reconnaissance vocale), JavaSpeech
dIBM (synth`ese vocale), JAXP (traitement de fichier XML).
2.2.2

Architecture logicielle de LEA

Lagent LEA necessite un environnement complexe pour fonctionner (synth`ese vocale

[javaSpeech], chargement des animations [javax XML]...). Enfin, pour les besoins de notre
syst`eme, nous avons integre un nouveau module : Pointeur permettant de designer des
objets du composant. Afin davoir une vision plus claire de lenvironnement de LEA, voici
une representation visuelle de larchitecture de Lea :

14

Alors que la classe Lea g`ere le comportement de LEA ainsi que les interactions entre
lutilisateur, le composant et le mediateur, la classe Display est destinee `a la gestion des
animations et de la synth`ese vocale. Elle dialogue avec la classe Lea par lintermediaire
de messages. D`es quun ev`enement se produit (saisie de requetes par lutilisateur, fin de
lanimation en cours...), Display transmet un message contenant un code `a la classe Lea qui
devra gerer la reaction de LEA. Cette transmission seffectue grace `a un appel de fonction,
avec pour arguments : le code du message et une chane de caract`ere (representant une
requete saisie, par exemple).
Lea.reaction(String requ^
ete, int code)

2.3
2.3.1

Description de DAFT
description g
en
erale

Afin de pouvoir raisonner sur le fonctionnement du composant, notre mediateur doit

avoir une representation symbolique de celui-ci. Cette representation consiste en un mod`ele
ecrit en ScriptLanguage (DAFT). Il doit decrire le fonctionnement du composant, ainsi
que son etat actuel (dynamique), ce qui implique une synchronisation entre le mod`ele reel
et le mod`ele DAFT. Ce module a ete implemente en Mathematica, ce qui a pose une
difficulte supplementaire : faire interagir un composant JAVA avec un module ecrit en
Mathematica.

Fig. 6 La place du mod`ele dans DAFT

15

2.3.2

le mod`
ele DAFT

Nous illustrerons le mod`ele DAFT grace `a un exemple de composant : Coco le compteur. Ce composant, ecrit en JAVA, est une simple application simulant un decompte.
Lutilisateur peut acc`elerer/ralentir la vitesse de decompte en agissant directement sur la
GUI du composant.

Fig. 7 GUI du composant Coco le compteur

Nous avons choisi dillustrer le mod`ele DAFT avec cet exemple pour plusieurs raisons :
Coco poss`ede un Thread interne (i.e. une horloge) qui modifie reguli`erement letat
du compteur. Cette caracteristique met en avant laspect synchronisation entre le
mod`ele DAFT de coco, et le mod`ele reel (etat du composant).
La GUI de Coco comporte plusieurs elements graphiques sur lesquels lutilisateur
pourra interagir : des boutons, une image, une scrollbar. A chacun de ces elements
correspond une action que nous pourrons exploiter dans la conception de notre
mod`ele.
Le mod`ele DAFT consiste en une description des differents objets de ce composant (boutons, entiers, vitesse,...), de leurs roles et de leur hierarchie. Ci-dessous, une representation
visuelle du mod`ele DAFT de Coco :

Fig. 8 Modelisation du composant Coco

16

Comme vous pouvez le remarquer, cette representation est tr`es proche de la GUI reelle
de Coco.
Afin detablir une communication entre le mod`ele DAFT et le mod`ele reel (JAVA),
nous devons etablir des relations entre les objets decrits en DAFT et les objets JAVA
du composant. Cet ensemble de liaisons peut etre represente grace `a la DaftOntologie
ci-dessous :

Fig. 9 La DaftOntologie de Coco

Cette representation nous montre les relations entres les differents objets DAFT (partie
gauche) et les objets JAVA (partie droite). Grace `a ce dessin, nous pouvons noter differentes
caracteristiques de la mod`elisation :
Un mod`ele peut ne pas correspondre `a 100% `a loriginal. En effet, certaines methodes
JAVA nont pas dequivalents dans le mod`ele DAFT.
Un mod`ele peut apporter de nouveaux concepts `a loriginal. Par exemple, la notion
de SWITCH presente dans le mod`ele DAFT nexistait pas dans le composant reel.
Elle est cependant compos
ee de plusieurs elements JAVA (ici, resume() et stop()).

17

2.3.3

le ScriptLanguage

La description du mod`ele seffectue grace `a un script DAFT. Ce script est compose

dune serie de declarations dobjets avec leurs attributs. Etudions un extrait de la description de Coco :
NEW[$cocorange,$_,jref_,label_,val_,min_,max_]:=
(
(* definition de la classe *)
INHERIT[$top,$cocorange,$];
$[JREF]=jref;
$[STRUCT]=VAR;
$[TYPE]=INT;
$[VAL]=val;
$[INIT]=val;
$[MIN]=min;
$[MAX]=max;
$[LABEL]=label;
$[BKGCOLOR]=GRAY;
$[LAYOUT]=FEATURE[LABEL,VAL];
(* Methode INCR: augmentation de la vitesse du compteur *)
$[INCR,LEACALL]=JAVACALL["LEA","PARLE","la vitesse a
et
e augment
ee"];
$[INCR,JCALL]=JAVACALL["Coco","incrSpeed"];
$[INCR,PRE]=($[VAL]<$[MAX])&;
$[INCR,SCRIPT]=($[VAL]++)&;
(* M
ethode DECR: diminution de la vitesse du compteur *)
$[DECR,LEACALL]=JAVACALL["LEA","PARLE","la vitesse a
et
e diminu
ee"];
$[DECR,JCALL]=JAVACALL["Coco","decrSpeed"];
$[DECR,PRE]=($[VAL]>$[MIN])&;
$[DECR,SCRIPT]=($[VAL]--)&;
(* M
ethode MODIFY: changement direct de la valeur de la vitesse *)
$[MODIFY,JCALL]=JAVACALL["Coco","setSpeed",$[VAL]];
$[MODIFY,PRE]=($[MIN]$[VAL]$[MAX])&;
$[MODIFY,SCRIPT]=($[VAL]=#)&;
(* M
ethode MONTRE: LACA pointe lobjet *)
$[MONTRE, LEACALL]=JAVACALL["LEA","POINTE",$[JREF]<>"| cest ici."];
(* M
ethode RESET: re-init de la vitesse *)
$[RESET,LEACALL]=JAVACALL["LEA","PARLE","la vitesse a
et
e r
einitialis
ee"];
$[RESET,JCALL]=JAVACALL["Coco","setSpeed",1];
$[RESET,SCRIPT]=($[VAL]=$[INIT])&;
$)

Cet extrait est la description dun objet de type cocorange. Il sagit dun entier
appartenant `a un interval donne. En observant cette description, nous pouvons noter deux
parties :
la premi`ere consiste en la definition de lobjet avec, par exemple, sa valeur initiale
([INIT] ), son label ([LABEL] )...
la deuxi`eme partie contient la description des methodes associees `a lobjet. Une
methode contient un script DAFT agissant sur lobjet, ainsi que la declaration des
liens vers le composant JAVA ([*,JCALL] ), et vers lACA ( [*,LEACALL] ).
La description compl`ete du mod`ele de Coco est disponible en Annexe avec le code source
JAVA de lapplet.
Ce mod`ele permet au mediateur de traiter les requetes qui lui sont envoyees. Une
requete DAFT pourra faire reference aux objets declares de deux mani`eres :
F [x] o`
u F est un acte de langage, et x est le nom de lobjet
F [REF [expr]] o`
u F correspond `a un acte de langage, et REF [expr] est une expression referentielle. Cette methode permet de designer un objet en fonction de ses
caracteristiques (couleur, position dans la GUI, contenu, type, role...).
18

Actuellement, DAFT ne sait traiter quun acte de langage (EXEC) sur les 23 actes prevus :
SPEECH ACT
WANT, NEED, CAN
EXEC, UNDO
ASK, EXIST, CHECK, WHYEXIST, WHYNOTEXIST
WHY, WHYIF, WHYINSTD, HOW
REPLY, ACK, NACK, AGREE, DESAGREE
TELL, LIKE, DISLIKE
HELLO

Cat
egorie
les desirs
les commandes
les questions
largumentation
les opinions
ouverture de session

Fig. 10 Speech Acts de DAFT

oOo

19

Mise en oeuvre de larchitecture DaftLea

3.1

Int
egration des diff
erents modules

Comme nous lavons defini dans la presentation de la probl`ematique, notre syst`eme

DaftLea est compose de plusieurs modules (LEA, le composant et le mediateur) qui devront
pouvoir communiquer ensemble et se synchroniser. Une premi`ere difficulte apparue dans
limplementation de DaftLea fut la variabilite de ces differents modules :
Le m
ediateur est un module concu en Mathematica, ceci implique une communication
entre deux modules ecrit dans deux langages differents : JAVA et Mathematica
Le composant est generique, ce qui signifie que nous ne pouvons pas connaitre `a lavance
son principe de fonctionnement, ni son contenu (methodes, attributs, objets...). Ceci
implique de pouvoir etablir une communication entre le mediateur et un composant
inconnu.
Lea representant la GUI du mediateur. La difficulte majeure est de pouvoir int`egrer au
sein de cette GUI, la GUI (active) du composant sans supprimer pour lutilisateur
la possibilite dinteragir directement avec le composant.
La resolution de lensemble de ces probl`emes composent lobjectif principal du stage.
Elle sera decrite dans lensemble des sections qui suivent.

3.2
3.2.1

Contr
oler LEA
Animer LEA

Le comportement de LEA est gere par un automate deterministe. Nous avons choisi
dutiliser un automate pour des raisons de simplicite. En effet, lutilisation de cette technologie permet une gestion simple et rapide des evenements. Pour contr
oler Lea, lanimer, il
suffit denvoyer des messages `a lautomate qui lancera lanimation appropriee au contenu
du message. Un message contient deux param`etres : le code et la commande. Le code
est un entier permettant didentifier le type de message envoye (lancement dune nouvelle
animation, fin de lanimation en cours...), et la commande est une chane de caract`eres.
Dans le cadre de DaftLea, lautomate recoit deux categories de messages :
Les messages provenant de mediateur : Ils sont destines `a lancer une nouvelle animation o`
u demander `a LEA de designer un objet. Le code dun message contient
le numero de lanimation `a executer, et la commande contient la phrase qui devra etre
synthetisee (JavaSpeech) durant lanimation. Par exemple, le message {HELLO,bonjour,
je suis LEA} demande `a LEA deffectuer lanimation HELLO en disant la phrase
bonjour, je suis LEA.
Les messages internes : Ces messages permettent de gerer lanimation en cours. Ils
peuvent avertir lautomate que lanimation est terminee (code : FIN ANIMATION),
ou que la synth`ese vocale en cours est achevee (code : FIN PARLE). Si lutilisateur saisie une question dans la GUI de LEA, un message sera envoye `a lautomate
qui transmettra la requete au mediateur.

20

Fig. 11 Automate de LEA : les flux de messages

3.2.2

D
esigner un objet du composant

Dans certaines situations (faire reference `a un objet, interagir avec un element graphique du composant), notre ACA, Lea, doit pouvoir designer un objet (i.e. un element
graphique du composant, comme un bouton, une zone de saisie...). Pour cela, nous pensions pouvoir le faire en superposant LEA au composant, et en lui faisant pointer, avec
le doigt, lobjet voulu. Mais, suite aux difficultes rencontrees pour superposer LEA au
composant, nous avons decide dutiliser une autre methode : LEA dirige sa main en direction de lelement graphique `a pointer, et lelement graphique est mis en surbrillance. (cf
screenshot ci-dessous)

Fig. 12 LEA designant un objet : le curseur

21

Pour arriver `a cela, il a fallu surmonter deux difficultes techniques :

modifier la couleur dun element graphique du composant (dynamique),
connatre la position des objets graphiques dans la GUI du composant en temps reel
(dynamique) afin que LEA dirige sa main dans la bonne direction.
La premi`ere difficulte a ete surmontee grace `a la methode setBackground(Color c) fournie par Java.awt. Cette methode permet de modifier la couleur de fond dun objet (en la
mettant en rouge, par exemple).
La deuxi`eme difficulte fut resolue grace au gestionnaires dev`enements de JAVA (ActionListener) qui, en plus dinformer sur les actions de lutilisateur, nous permet de connatre
de mani`ere dynamique, lemplacement des elements subissant les actions de lutilisateur.
Donc, quand notre mediateur souhaite demander `a lACA de pointer un objet, il envoi un
message `a lautomate de Lea :
Code : POINTE
Commande : "idObjet | phrase `
a dire"
Ici, idobjet est lidentificateur (dans le source du composant) correspondant `a lelement
graphique. Enfin, Lea, par lintermediaire de lidentificateur de lobjet, change sa couleur,
et recup`ere ses coordonnees. Il lui reste plus qu`a afficher lanimation permettant de pointer
un objet. Dans cette version de Lea, nous disposons de 3 animations :

22

3.3

Synchronisation des mod`

eles

Lune des difficultes majeures, auquelles nous avons ete confronte dans la conception de
DaftLea, fut la synchronisation des deux mod`eles : DAFT et reel (JAVA). En effet, lorsque
lutilisateur interagit directement avec la GUI du composant, notre mediateur doit etre
averti du changement detat du mod`ele JAVA. De meme, lorsque lutilisateur envoit une
requete au mediateur, par lintermediaire de LEA, letat du mod`ele DAFT change, il faut
donc modifier letat du mod`ele JAVA pour les synchroniser. Ce probl`eme est resolu grace
`a larchitecture ci-dessous :

Fig. 13 architecture logique de DaftLea

Nous pouvons classer les differentes liaisons de cette architecture en deux categories :
dune part la communication Composant vers le Mediateur, et, dautre part, la communication Mediateur vers le Composant.
3.3.1

Communication Composant M
ediateur

Cette communication seffectue dans deux situations :

interaction de lutilisateur avec la GUI du composant Lorsque lutilisateur agit avec
un element de la GUI, letat du composant evolue, il faut donc mettre `a jour letat du
mod`ele en fonction de lelement active. Pour cela, lors de linitialisation du mediateur,
nous scannons le code source du composant et associons `a chacun des elements
de linterface (bouton, champ de saisie...) une methode espion lui envoyant un
message en cas daction de lutilisateur sur cet element. Actuellement les elements
marques sont les suivant :
BUTTON: java.awt.Button (un simple bouton)
TEXTFIELD: java.awt.TextField (une zone de saisie)
TEXTAREA: java.awt.TextArea (une zone de texte)
CANVAS: java.awt.Canvas (une zone graphique)
LABEL: java.awt.Label (une
etiquette)
SCROLLBAR: java.awt.ScrollBar (une barre de d
efilement)

Un message est envoye au mediateur si une action est effectuee sur lun de ses objets.
Les actions capturees sont le click sur lelement et le survol de la souris au-dessus.
23

Le format du message est le suivant :

{METHOD, typeAction, idObect}
Lelement typeAction correspond au type dinteraction effectuee par lutilisateur
(click ou fly) et idObjet correspond au symbole (i.e. identificateur) de lobjet dans
le code source du composant.
ex
ecution dune commande interne au composant Ne capturer que les interactions
entre lutilisateur et le composant ne peut suffire `a synchroniser la representation
symbolique du composant, et son etat reel. Par exemple, si le composant dispose
dune horloge (Thread en Java) executant en interne des appels de methode reguliers,
nous devons pouvoir mettre reguli`erement `a jour le mod`ele du composant. Nous
avons donc implemente un syst`eme capturant les appels de methodes effectues au sein
du composant. Cela seffectue grace au marquage de son code source qui consiste
en le modifier afin de lui demander de transmettre des messages au mediateur lors
de ses appels de fonction. Ainsi, le mediateur pourra synchroniser son mod`ele en
fonction des executions internes au composant.
La premi`ere etape du marquage consiste en extraire les classes public de chaque
fichier Java. Pour cela nous utilisons un automate que voici :

Fig. 14 automate dextraction de classe public

24

Ci-dessous, le code source associe `a lautomate

public static String getClassePrincipale(String s){
//--- init des variables
String cp=""; // le retour
int ic=0; // pointeur sur le char
int etat=0; // etat initial
int nbracc=0; // nbr de { non ferm
es
//--- automate permettant de r
ecup
erer la classe principale
for (ic=0; ic<s.length(); ic++){
char c=s.charAt(ic);
switch(etat){
case 0:
//--- si la classe d
ebute par "public class"
if (s.startsWith("public class",ic)){
etat=1;
cp="public class ";
ic+=(new String("public class")).length();
}
break;
case 1:
if (c=={){
etat=2;
nbracc++;
cp+=c;
} else cp+=c;
break;
case 2:
//--- on compte les accolades fermantes/ouvrantes
if (c=={) nbracc++;
if (c==}) nbracc--;
//--- aucune accolade ouverte donc
//--- fin de la classe
if ((c==})&&(nbracc==0)) etat=3;
//--- on m
emorise le contenu de la classe
cp+=c;
break;
case 3:
// ignore tt le reste
break;
}
}
//--- fin, et retour du resultat
return cp;
}

Apr`es avoir recupere le code source de la classe public, notre syst`eme rep`ere les appels de methode afin de les (( marquer )). Encore une fois, nous utilisons un automate
permettant de les extraire(nom, arguments, objet). Apr`es chaque appel extrait, un
morceau de code est ajoute. Il est destine `a transmettre un message au mediateur
une fois lappel de methode effectue. Le format du message est le suivant :
{METHODE, nomMethode, nomObjet, arg1, arg2...}

25

Ci-dessous, lautomate permettant dinserer ces lignes de code dans le source du

composant :

Fig. 15 automate de marquage des appels de methodes

Ci-dessous, un exemple de code avant le marquage des appels :
public void RAZ(){
//--- Remise `
a z
ero des valeurs
initVariable();
_lSpeed.setValue(String.valueOf(_speed));
repaint();
}

et apr`es le marquage des appels :

public void RAZ(){
initVariable();
/******************************************/
if (_kernel!=null){
_kernel.analyseAction("{METHOD,initVariable,Coco}");
}
/******************************************/
_lSpeed.setValue(String.valueOf(_speed));
repaint();
/******************************************/
if (_kernel!=null){
_kernel.analyseAction("{METHOD,repaint,Coco}");
}
/******************************************/
}

26

3.3.2

Communication M
ediateur Composant

Lorsque lutilisateur envoit une requete DAFT au mediateur, letat du mod`ele peut
changer. Il faut donc mettre `a jour letat reel du composant. Cette synchronisation seffectue en faisant appel aux methodes du composant associees aux commandes DAFT
executees.

3.4

Chane globale TALN int

egr
ee

Le module de traitement des requete DAFT nest quune partie du syst`eme DAFT.
En effet, DAFT consiste en une chane de traitement renvoyant une reponse en langue
naturelle `a partir dune question en langue naturelle.

Fig. 16 Automate de LEA : les flux de messages

La suite des analyses est la suivante :
GRASP : traduire une question (langage naturel) en une requete DAFT formelle.
DAFT : traitement de la requete DAFT formelle, action sur le composant, renvoi dune
reponse formelle
EVA : construction dune reponse en langue naturelle `a partir dune reponse formelle

oOo

27

Exp
erimentation

4.1

Description

Une version test de DaftLea fut creee au debut de la conception du module de traitement du langage naturel. Ne disposant pas `a ce moment l`a de mediateur actif (DAFT
desactive), tout dialogue entre lutilisateur et LEA etait donc impossible. Cependant, lutilisateur pouvait interagir avec le composant (ici, Coco le compteur).

Fig. 17 Interface de DaftLea avec le composant Les Tours de Hano

Description du protocole exp
erimental
Lechantillon des utilisateurs `a ete choisis sans selection particuli`ere. Lexperience a ete
effectuee aupr`es dune quinzaine dutilisateurs. Elle etait composee de plusieurs etapes :
1. Lutilisateur devait poser des questions dordre general sur lapplication, Lea, DaftLea... lexperimentateur repondait `a la place de Lea, permettant ainsi de simuler une
sorte de dialogue.
2. Pour une serie dobjets graphique donnees (boutons du composant, personnage de
Lea, fenetre...), lutilisateur devait saisir une requete/question faisant reference `a cet
objet.
3. enfin, lutilisateur devait terminer lapplication grace `a un dialogue de fermeture
(bye,salut,...)
Bilan de lexp
erience
Lors de cette experience, nous avons reussi `a obtenir plus de 750 requetes/questions qui
nous ont ete tr`es utiles pour le traitement des requetes, aussi bien dun point de vue
formulation des questions que dun point de vue objet des requetes. Enfin, cette experience
a permis de mettre en avant de quelques defauts de DaftLea dans le domaine de linterface
Homme-Machine. Bien entendu, ces defauts ont ete corriges.

28

4.2

Apport de lexp
erimentation pour GRASP

Letude du corpus resultant de lexperience nous a permis de connatre le vocabulaire

et le style linguistique le plus utilise lors dune interaction entre lutilisateur et LEA.
Concretement, nous avons pu deduire des 793 phrases du corpus :
734 verbes dactions
135 adverbes
208 mots grammaticaux (nombres, negation, prepositions...)
2387 lemmes dont 1250 relies `a des concepts/mots cles de DAFT
29710 flexions
556 r`egles de locutions (il y a, parce que, ...)
Le corpus nous a aussi permis detablir un ensemble de bi-grammes et tri-grammes pour
la desambig
uation des mots mal rediges.

4.3

Apport de lexp
erimentation pour DAFT

Ce corpus nous a permis de connatre les types de requete les plus frequement posees
au syst`eme. Nous avons pu lister les 23 Speech Acts les plus frequents [cf figure 10]. Enfin,
dans le cadre du traitement de la reference extensionnelle, le corpus a permis de mettre en
evidence les moyens utilises par les utilisateurs pour designer les entites (aussi bien objet
physique que concept logique) de lapplication .

oOo

29

Conclusion et Perspectives

Durant ce stage, nous avons developpe une implementation du projet DAFT : DaftLea, permettant ainsi `a J.-P. Sansonnet dappliquer ses etudes sur la chane GRASP et
le traitement de la reference. De plus, nous avons pu integrer un ACA (LEA) et assurer
une interaction (communication/synchronisation) entre les trois elements principaux du
projet : le composant, le mediateur et un ACA.
Lors de limplementation de DaftLea, nous avons d
u faire face `a plusieurs difficultes :
Probl`emes de communication entre des modules ecrits dans des langages differents
(Mathematica/Java),
Probl`emes de synchronisation semantique entre un mod`ele et le composant : etablir
un maximum de liens entre le mod`ele DAFT et les objets du composant,
Probl`emes de synchronisation physique entre un mod`ele et le composant : mise `a
jour synchrone entre le mod`ele DAFT et letat du composant.
Une deuxi`eme experimentation est prevue pour octobre 2004. Contrairement `a la
premi`ere experience, le module DAFT sera active ce qui permettra `a lutilisateur de
veritablement interagir avec DaftLea. Enfin, une nouvelle version de DaftLea est prevue
pour octobre-novembre 2004, il sagit de DaftWeb, une version On-line de DaftLea. Lenvironnement de LEA etant trop complexe pour etre integre dans une page web, cette
nouvelle version utilisera la technologie Microsoft Agent.
r
esum
e du travail effectu
e:
Dans le cadre de ce stage, mes travaux ont ete principalement orientes vers la communication et la synchronisation entre les modules : LEA, le composant, le mediateur. Lenchanement des etapes pour realiser ceci fut le suivant :
1. Etat de lart sur les agents assisants,
2. Communication entre deux programmes : Java et Mathematica,
3. Prise en main de la technologie LEA,
4. Int`egration dun composant generique dans une interface contenant un agent LEA,
5. Implementation de la premi`ere version de DaftLea contenant : un composant, un
Mediateur et LEA,
6. Mise en place de la communication entre le Mediateur (Mathematica) et le composant,
7. Implementation des premiers mod`eles des composants : Coco le compteur,
8. Resolution des probl`emes de synchronisation entre le composant et le mediateur.

30

Bibliographie

6.1

Th`
eme : View Design Language / M
ediateur / Observateurs

1. N. Sabouret, Requetes de bon sens sur le fonctionnement, Chapitre du cours commun

aux DEA I3 et Sciences Cognitives de Paris XI, dec 2002.
2. N. J-P. Sansonnet, Presentation de VDL 0.1 ,Technical Report, LIMSI report n9910, june 1999.
3. J-P. Sansonnet, Notes sur VDL 0.4, Technical Report, april 2001.
4. J-P. Sansonnet, Notes sur VQL 0.4, Technical Report, may 2001.
5. S. Gerard, J-P. Sansonnet, Reference Resolution in Human-Computer Interaction :
An Integrated Model Based on Intention unpublished paper, feb 2001.
6. G. Pitel, J-P. Sansonnet, Mod`ele dinterpretation constructionnelle par observateurs
pour les syst`emes de dialogue avec support visuel, Workshop AGENTAL, Paris,
march 13, 2004.
7. J.-P. Sansonnet, Composants dialogiques generiques : perspectives et methodes pour
une approche integree des outils assistants langagiers et de la programmation objet,
Conference Langages et Mod`eles `a Objets, LMO 04, Lille 2004.
8. J.P. Sansonnet, G. Pitel, N. Sabouret, Un Langage de Description dAgents Destine
`a lInteraction Dialogique Demo session at JFIADSMA 02, lille 2002.

6.2

Architectures / Model View Controller (MVC)

1. Documentation JAVA SUN, Model View Controller, Java BluePrints - J2EE Patterns, Sun Microsystems.
2. W. Greg Phillips, Architectures for Synchronous Groupware , Technical report 1999425, Department of Computing and Information Science, Queens University.

6.3

Th`
eme : LEA (Limsi Embodied Agent)

1. Sarkis Abrilian, Specification et developpement dinteractions multimodales bidirectionnelles avec un agent conversationnel, rapport de stage de DEA
2. Sarkis Abrilian, Jean-claude Martin, Stephanie Buisine, Algorithms for controlling
cooperation between output modalities in 2D ECA, AAMAS 2002

6.4

Th`
eme : Les agents assistants

1. Emerson PARAISO, Developpement dinterfaces conversationnelles utilisant la parole : application aux agents assistants personnels, journee Heudiasyc, UTC/2003
2. Pattie MAES, lagent reduit le travail et la surcharge des informations, [en ligne],
http ://www.ift.ulaval.ca/ kone/Cours/AM/AM-Present02.ppt
3. Claire GAUZENTE, Veronique GUILLOUX, Marketing relationnel sur Internet :
quelle place pour les agents dinterface ?
31

4. AgentLand, le portail des agents intelligents [en ligne], http ://www.agentland.fr

5. Filippo Menczer, W. Nick Street, Alvaro E. Monge , Adaptative Assistants for Customized E-Shopping, http ://www.computer.org/intelligent/ex2002/pdf/x6012.pdf
6. Daniele Maraschi, Stefano A. Cerri, Relations entre les technologies de lenseignement et les agents,AFIA2001

6.5

Th`
eme : Les agents conversationnels

1. Site Internet, Agent Intelligent.com, http ://www.agentintelligent.com/index.html

2. Chritophe Goderaux, Pierre-Olivier El Guedji, Frederic Revolta, Pierre Nugues, Un
agent intelligent pour naviguer dans les mondes virtuels
3. Grant Sherson, Intelligent Agents In Education, Part of Assessment for Master of
Communications Victoria University of Wellington (1999)
4. Site Internet, GT ACA, http ://www.limsi.fr/aca/
5. Site Internet, Les agents assistants, Karl Le Guern,
http ://www.limsi.fr/Individu/jps/enseignement/examsma/2004/LEGUERN/index.html

32

7
7.1

ANNEXES
ANNEXE I : Source du composant JAVA : Coco le compteur

//========================================================================
//--------------------------------COCO le compteur-----------------------//========================================================================
// - applet avec un Thread
// - m
Ime structure que ds mod
Elisation DAFT
//========================================================================
//====================================================================
// initialisation
// -> public void initVariable(): initialisation des variables
// -> public void RAZ(): reinit du compteur
// -> public void init(): premi
Ere init du compteur
//====================================================================
//====================================================================
// GESTION DE LAPPLET
// -> public void fermer(): fermeture de lapplet
// -> public void incr(): compteur+=speed
// -> public void incrSpeed(): speed++
// -> public void decrSpeed(): speed-// -> public void setSpeed(int s): definition direct de la speed
// -> public void stop(): arr
It du d`
Ecompte
// -> public void start(): premier lancement du d`
Ecompte
// -> public void resume(): reprise du decompte
//====================================================================
//========================================================================
// chargement des librairies
import java.awt.*;
import java.awt.event.*;
import java.applet.*;
import javax.swing.*;
// cr`
Eation de lapplet
public class Coco extends Applet {
//====================================================================
// les attributs GRAPHIQUE
//====================================================================
public Button _bFermer;
public Button _bStart;
public Button _bStop;
public Button _bRaz;
public Titre _titre;
public Label _lCompteur;
public CLabel _lSpeed;
public CLabel _lEtat;
public Scrollbar _sSpeed;
public Clock _thread;
//====================================================================
// les attributs Moteur
//====================================================================
public int _speed;
public String _etat;
public int _compteur;
//====================================================================
// initialisation
// Aux -> public void initVariable()
// Aux -> public void RAZ()
// Prin -> public void init()
//====================================================================
public void initVariable(){
//--- init des valeurs
_compteur=0;
_speed=1;
_etat="compte";
}
public void RAZ(){
//--- Remise z`
Ero des valeurs

33

initVariable();
_lSpeed.setValue(String.valueOf(_speed));
repaint();
}
public void init(){
initVariable();
//--- init de la fenetre
setLayout(new GridLayout(3,1));
setSize(400,400);
//--- affichage du titre
_titre=new Titre();
add(_titre);
//--- affichage du compteur
add(_lCompteur=new Label(String.valueOf(_compteur)));
_lCompteur.setFont(new Font("Helvetica",Font.PLAIN,40));
_lCompteur.setAlignment(Label.CENTER);
//--- le panneau de contr`
Ule
JPanel pc=new JPanel();
pc.setBackground(Color.LIGHT_GRAY);
pc.setLayout(new GridLayout(1,2));
// le contr`
Ule de vitesse
JPanel ps=new JPanel();
ps.setLayout(new GridLayout(5,1));
ps.add(new JLabel());
ps.add(_lSpeed=new CLabel("speed", String.valueOf(_speed)));
ps.add(_sSpeed=new Scrollbar(Scrollbar.HORIZONTAL,
1,10,0,100));
ps.add(new JLabel());
ps.add(_bFermer=new Button("Fermer"));
pc.add(ps);
// le contr`
Ule de lapplet
JPanel pb=new JPanel();
pb.setLayout(new GridLayout(5,1));
pb.add(new Label());
pb.add(_lEtat=new CLabel("etat",_etat));
pb.add(_bStart=new Button("start"));
pb.add(_bStop=new Button("stop"));
pb.add(_bRaz=new Button("RAZ"));
pc.add(pb);
add(pc);
// finalise la fen
Itre
setSize(640,480);
repaint();
//--------- on associe les m`
Ethodes aux boutons
_bFermer.addActionListener(new ActionListener(){
public void actionPerformed(ActionEvent event){
fermer();
}
});
_bStart.addActionListener(new ActionListener(){
public void actionPerformed(ActionEvent event){
resume();
}
});
_bStop.addActionListener(new ActionListener(){
public void actionPerformed(ActionEvent event){
stop();
}
});
_bRaz.addActionListener(new ActionListener(){
public void actionPerformed(ActionEvent event){
RAZ();
}
});
_sSpeed.addAdjustmentListener(new AdjustmentListener(){
public void adjustmentValueChanged(AdjustmentEvent e){
System.out.println("Value: "+e.getValue()+" / "+e.getAdjustmentType());
int sp=e.getValue();
setSpeed(sp);
}
});
//------------------ Le THREAD

34

_thread=new Clock(this);
}
//====================================================================
// GESTION DE LAPPLET
// -> public void fermer()
// -> public void incr()
// -> public void incrSpeed()
// -> public void decrSpeed()
// -> public void decrSpeed()
// -> public void setSpeed(int s)
// -> public void stop()
// -> public void start()
// -> public void resume()
//====================================================================
public void fermer(){
System.exit(0);
}
public void incr(){
_compteur+=_speed;
_lCompteur.setText(""+_compteur);
_lCompteur.repaint();
}
public void incrSpeed(){
_speed+=1;
_lSpeed.setValue(String.valueOf(_speed));
_lSpeed.repaint();
}
public void decrSpeed(){
_speed-=1;
_lSpeed.setValue(String.valueOf(_speed));
_lSpeed.repaint();
}
public void setSpeed(int s){
_speed=s;//.intValue();
_lSpeed.setValue(String.valueOf(_speed));
_lSpeed.repaint();
}
public void stop(){
if (_thread!=null){
_thread.suspend();
_etat="pause";
_lEtat.setValue(_etat);
}
}
public void start(){
if (_thread!=null){
_thread.start();
_etat="compte";
_lEtat.setValue(_etat);
}
}
public void resume(){
if (_thread!=null){
_thread.resume();
_etat="compte";
_lEtat.setValue(_etat);
}
}
}
//====================================================================
// ELEMENTS GRAPHIQUES
//====================================================================
class Titre extends Canvas{
ImageIcon _titre;
public Titre(){
_titre=new ImageIcon("applet/titre.gif");
}
public void paint(Graphics g){
_titre.paintIcon(this,g,0,0);
}
}
class CLabel extends Canvas{
ImageIcon _statut;
String _label;
String _value;

35

public CLabel(String l,String v){

_statut=new ImageIcon("applet/statut.gif");
_label=l;
_value=v;
}
public void setValue(String v){
_value=v;
repaint();
}
public void paint(Graphics g){
_statut.paintIcon(this,g,20,0);
g.drawString(_label, 40,10);
g.drawString(_value, 110,10);
}
}
//====================================================================
// GESTION DU THREAD
//====================================================================
class Clock extends Thread{
Coco _coco;
public Clock(Coco co){
_coco=co;
}
public void run(){
for (;;){
topClock();
}
}
public void topClock(){
try{
_coco.incr();
this.sleep(1000);
}catch(Exception e){}
}
}

36

7.2

ANNEXE II : Source du mod`

ele de Coco le compteur

D
efinition des classes de coco
Initialisation: INITCLASS
On nutilise pas le ground
INITCLASS["NOGROUND",
$top,
$cocorange,$cocobool,$cocobutton,(* base *)
$cursor,$switch,$counter,$coco (* compos
ees *)
]
Classe $top
NEW[$top,x_]:=(
With[{u=x},Clear[u]];
viewQ[x]=True;
THEVIEWS=Union[Append[THEVIEWS,x]];
x[IKO]=$top;
x[_]=UNKNOWN;
x
);
Classes de base
NEW[$cocorange,$_,jref_,label_,val_,min_,max_]:=(
(* definition de la classe *)
INHERIT[$top,$cocorange,$];
$[JREF]=jref;
$[STRUCT]=VAR;
$[TYPE]=INT;
$[VAL]=val;
$[INIT]=val;
$[MIN]=min;
$[MAX]=max;
$[LABEL]=label;
$[BKGCOLOR]=GRAY;
$[LAYOUT]=FEATURE[LABEL,VAL];
$[USAGE]=JAVACALL["LEA","SPEAK","en r`
eglant la vitesse,
je compterai plus ou moins vite"];
(* Methode INCR: augmentation de la vitesse du compteur *)
$[INCR,LEACALL]=JAVACALL["LEA","SPEAK","la vitesse a
et
e augment
ee"];
$[INCR,JCALL]=JAVACALL["Coco","incrSpeed"];
$[INCR,PRE]=($[VAL]<$[MAX])&;
$[INCR,SCRIPT]=($[VAL]++)&;
$[INCR,MANUAL]=JAVACALL["LEA","POINTE","_sSpeed|pour augmenter la vitesse,
il suffit de cliquer ici"];
(* M
ethode DECR: diminution de la vitesse du compteur *)
$[DECR,LEACALL]=JAVACALL["LEA","SPEAK","la vitesse a
et
e diminu
ee"];
$[DECR,JCALL]=JAVACALL["Coco","decrSpeed"];
$[DECR,PRE]=($[VAL]>$[MIN])&;
$[DECR,SCRIPT]=($[VAL]--)&;
$[INCR,MANUAL]=JAVACALL["LEA","POINTE","_sSpeed|en cliquant ici, vous
pouvez diminuer la vitesse"];
(* M
ethode MODIFY: changement direct de la valeur de la vitesse *)
$[MODIFY,LEACALL] := JAVACALL["LEA","SPEAK","la vitesse a
et
e modifi
ee"];
$[MODIFY,JCALL] := JAVACALL["Coco","setSpeed","INT["<>ToString[$[VAL]]<>"]"];
$[MODIFY,PRE]=($[MIN]$[VAL]$[MAX])&;
$[MODIFY,SCRIPT]=($[VAL]=#)&;
$[INCR,MANUAL]=JAVACALL["LEA","POINTE","_sSpeed|cette scrollbar vous permettra
de r
egler la vitesse"];
(* M
ethode MONTRE: LACA pointe lobjet *)
$[MONTRE, LEACALL]:=JAVACALL["LEA","POINTE",$[JREF]<>"| cest ici."];
(* M
ethode RESET: re-init de la vitesse *)
$[RESET,LEACALL]=JAVACALL["LEA","SPEAK","la vitesse a
et
e r
einitialis
ee"];
$[RESET,JCALL]=JAVACALL["Coco","setSpeed","INT[1]"];
$[RESET,SCRIPT]=($[VAL]=$[INIT])&;
$)
NEW[$cocobool,$_,jref_,label_,val_]:=(
(* D
efinition de la classe *)
INHERIT[$top,$cocobool,$];
$[JREF]=jref;
$[STRUCT]=VAR;
$[TYPE]=INT;
$[VAL]=val;
$[INIT]=val;
$[LABEL]=label;
$[BKGCOLOR]:=If[$[VAL],GREEN,RED];
$[LAYOUT]=FEATURE[LABEL,VAL];
$[LEX]={"etat"};
$[USAGE]:=JAVACALL["LEA","POINTE",$[JREF]<>"|ce panneau vous permet

37

de contr^
oler letat du compteur"];
(* M
ethode ON: activation du d
ecompte *)
$[ON,LEACALL]=JAVACALL["LEA","OK","le compteur est lanc
e"];
$[ON,JCALL]=JAVACALL["Coco","resume"];
$[ON,SCRIPT]=($[VAL]=True)&;
$[ON,MANUAL]=JAVACALL["LEA","POINTE","_bStart|Vous pouvez activer le
compteur en cliquant sur ce bouton"];
(* M
ethode OFF: mise en pause du compteur *)
$[OFF,LEACALL]=JAVACALL["LEA","OK","le compteur a
et
e stopp
e !"];
$[OFF,JCALL]=JAVACALL["Coco","stop"];
$[OFF,SCRIPT]=($[VAL]=False)&;
$[ON,MANUAL]=JAVACALL["LEA","POINTE","_bStop|Pour mettre le compteur
en pause, il vous suffit de cliquer sur ce bouton"];
(* M
ethode SWITCH *)
$[SWITCH,JCALL]:=If[$[VAL],
JAVACALL["Coco","stop"],
JAVACALL["Coco","resume"]
];
$[SWITCH,SCRIPT]=($[VAL]=$[V AL])&;
(* M
ethode RESET: remise `
a z
ero du compteur *)
$[RESET,JCALL]=JAVACALL["Coco","RAZ"];
$[RESET,SCRIPT]=($[VAL]=$[INIT])&;
$[RESET,MANUAL]=JAVACALL["LEA","POINTE","_bRaz|ce bouton vous
permet de r
einitialiser le compteur"];
$)
NEW[$cocobutton,$_,jref_,label_,jcall_,script_]:=(
(* d
efinition de la classe *)
INHERIT[$top,$cocobutton,$];
$[JREF]=jref;
$[ISA]=BUTTON;
$[STRUCT]=CST;
$[LABEL]=label;
$[BKGCOLOR]=darkgray;
$[LAYOUT]=FEATURE[LABEL];
$[LEX]={"bouton"};
(* M
ethode MONTRE: permet de pointer le bouton *)
$[MONTRE, LEACALL]=JAVACALL["LEA","POINTE",$[JREF]<>"| cest ici."];
(* M
ethode CLICK: simule un click sur le bouton *)
$[CLICK,JCALL]=jcall;
$[CLICK,SCRIPT]=script;
$)
Classes compos
ees
$Cursor g`
ere la vitesse du compteur
NEW[$cursor,$_,jref_,val_]:=Module[{speed,bup,bdown},
(* D
efinition de la classe *)
INHERIT[$top,$cursor,$];
$[JREF]=jref;
$[ISA]=CURSOR;
$[LEX]={"cursor","speed","vitesse","scrollbar"};
(* init des
el
ements composant le cursor *)
NEW[$cocorange,speed,"_lSpeed","speed",1,val,100];
NEW[$cocobutton,bup,"_sSpeed","faster",JAVACALL[],DO[speed,INCR]&];
NEW[$cocobutton,bdown,"_sSpeed","slower",JAVACALL[],DO[speed,DECR]&];
(* mise en place des
el
ements *)
$[STRUCT]=SCOPE;
$[PARTS]={speed,bup,bdown};
R
$[ALIAS]={SPEEDspeed};
$[BKGCOLOR]=pink;
$[LAYOUT]=FRAME[DOWN[speed,RIGHT[bup,bdown]]];
(* m
eta op
erateurs **)
$[INCR,SCRIPT]=DO[speed,INCR]&;
$[DECR,SCRIPT]=DO[speed,DECR]&;
$[MODIFY,SCRIPT]=DO[speed,MODIFY,#]&;
$[RESET,SCRIPT]=DO[speed,RESET]&;
(* M
ethode MONTRE: permet de pointer l
el
ement *)
$[MONTRE, LEACALL]=JAVACALL["LEA","POINTE",$[JREF]<>"| cest ici."];
$]
$Switch permet de stop/lancer le compteur
NEW[$switch,$_,jref_,val_]:=Module[{run,bon,boff,braz},
INHERIT[$top,$switch,$];
$[JREF]=jref;
NEW[$cocobool,run,"_etat","running",val];

38

NEW[$cocobutton,bon,"_bStart","start",JAVACALL[],DO[run,ON]&];
NEW[$cocobutton,boff,"_bStop","stop",JAVACALL[],DO[run,OFF]&];
NEW[$cocobutton,braz,"_bRaz","RAZ",JAVACALL[],(DO[run,RESET];
DO[THEMAIN.SPEED.SPEED,RESET])&];
(* lexique associ
e aux elements *)
GLUE[bon,LEX,"start"];
GLUE[boff,LEX,"stop"];
GLUE[boff,LEX,"pause"];
GLUE[boff,LEX,"arr^
et"];
GLUE[braz,LEX,"RAZ"];
$[LEX]={"switch"};
$[STRUCT]=SCOPE;
$[PARTS]={run,bon,boff,braz};
R
$[ALIAS]={STATUSrun};
$[BKGCOLOR]=pink;
$[LAYOUT]=FRAME[DOWN[run,bon,braz,boff]];
(* m
eta op
erateurs **)
$[START,SCRIPT]=DO[run,ON]&;
$[STOP,SCRIPT]=DO[run,OFF]&;
$[SWITCH,SCRIPT]=DO[run,SWITCH]&;
$[RESET,SCRIPT]=DO[run,RESET]&;
$]
$counter repr
esente le compteur (sa valeur)
NEW[$counter,$_,jref_,val_]:=With[{
b=THEMAIN.SWITCH.STATUS,
s=THEMAIN.SPEED.SPEED},
INHERIT[$top,$counter,$];
$[JREF]=jref;
$[LEX]={"counter","compteur"};
$[STRUCT]=VAR;
$[TYPE]=INT;
$[VAL]=val;
$[INIT]=val;
$[BKGCOLOR]=GRAY;
$[LAYOUT]=FEATURE[TYPE,VAL];
$[CLOCK,JCALL]=JAVACALL["_thread","topClock"];
$[CLOCK,PRE]=(GET[b,VAL])&;
$[CLOCK,CODE]=($[VAL]=$[VAL]+GET[s,VAL])&;
(* mapping de m
ethodes *)
$[MAP,"setText"]= ($[VAL]=#)&;
$]
$titre repr
esente le titre du compteur (une simple image dans le composant)
NEW[$titre,$_,jref_]:=Module[{},
INHERIT[$top,$titre,$];
$[JREF]=jref;
$[STRUCT]=VAR;
$[TYPE]=TITRE;
$[VAL]="Coco, le compteur";
$[INIT]="Coco, le compteur";
$[LABEL]="titre";
$[BKGCOLOR]:=BLUE;
$[LAYOUT]=FEATURE[LABEL,VAL];
$[LEX]="titre";
$[MONTRE, LEACALL]=JAVACALL["LEA","POINTE",$[JREF]<>"| la barre
de titre est ici."];
]
Classe Principale: coco
NEW[$coco,$_]:=Module[{t,i,s,b,f},
(* coco est un objet qui d
erive de $top *)
INHERIT[$top,$coco,$];
$[JREF]="Coco";
(* cr
eation des
el
ements composant coco *)
(* le titre *)
NEW[$titre,t,"_titre"];
(* le compteur *)
NEW[$counter,i,"_lCompteur",0];
(* la vitesse *)
NEW[$cursor,s,"_sSpeed",1];
(* le panneau de contr^
ole *)
NEW[$switch,b,"**jref**",True];
(* le bouton de fermeture *)
NEW[$cocobutton,f,"_bFermer","Fermer",
JAVACALL["Coco","fermer"],DAFTCLOSESESSION];

39

(* le lexique associ
e `
a lobjet coco *)
$[LEX]={"coco","compteur"};
$[ABOUT]="Je suis Lea, jai
et
e con
cue par Karl Le Guern, au LIMSI-CNRS";
$[USAGE]="Ma fonction est de vous assister dans lutilisation de
Coco le compteur";
(* mise en place des
el
ements *)
$[STRUCT]=SCOPE;
$[PARTS]={i,s,b};
$[ROLES]={SPEED[s,i],CONTROLSWITCH[b,i]};
R
R
$[ALIAS]={SPEEDs,SWITCH
b};
$[LAYOUT]=FRAME[DOWN[t,i,RIGHT[DOWN[s,f],b]]];
(* m
eta op
erateurs *)
$[CLOCK,SCRIPT]=DO[i,CLOCK]&;
(* mapping de m
ethodes *)
$[MAP,"setSpeed"]= DO[s,MODIFY, #]&;
$]
LAUNCH["coco"]:=INITRUN[$coco]
Launch de coco
Ouverture de la session "Coco"
DAFTOPENSESSION["coco"];

40