Download - 04 Rapport de Stage de Dea

RAPPORT DE STAGE DE DEA

Definition dune architecture de mediateur pour des agents

conversationnels animes

Karl LE GUERN

3 septembre 2004

1

Resume :Le stage de DEA se situe dans le cadre des agents dialogiques, cest-a`-dire des composantslogiciels capables de raisonner sur leur propre structure et fonctionnement pour repondrea` 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 desagents conversationnels animes. Durant ce stage, mon activite principale est detablir unecommunication / synchronisation entre les trois modules principaux de notre architec-ture, cest-a`-dire un composant generique a` medier, un agent anime LEA, et un mediateurcontenant 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, ele`ves de lEPITA, pour leursApplets JAVA,

aux personnes qui ont participe a` la premie`re experimentation de DaftLea.

2

Table des matie`res

1 Problematique 51.1 Contexte de Recherche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.2 Objectifs du stage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.3 Le the`me de recherche ACA : Etat de lart . . . . . . . . . . . . . . . . . . . 6

1.3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61.3.2 Les Agents Intelligents . . . . . . . . . . . . . . . . . . . . . . . . . . 71.3.3 Les Agents Conversationnel . . . . . . . . . . . . . . . . . . . . . . 81.3.4 Les Agents Assistants Personnels . . . . . . . . . . . . . . . . . . . 8

1.4 Le the`me de recherche Agent Dialogique : InterViews et DAFT . . . . . . . 101.4.1 Le projet InterViews . . . . . . . . . . . . . . . . . . . . . . . . . . . 101.4.2 Le projet DAFT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

1.5 DAFTLEA : specification du projet . . . . . . . . . . . . . . . . . . . . . . . 11

2 Le mode`le darchitecture DaftLea 122.1 Architecture generale DaftLea . . . . . . . . . . . . . . . . . . . . . . . . . . 122.2 Description de lagent LEA . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.2.1 Presentation de lagent LEA . . . . . . . . . . . . . . . . . . . . . . 132.2.2 Architecture logicielle de LEA . . . . . . . . . . . . . . . . . . . . . 14

2.3 Description de DAFT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152.3.1 description generale . . . . . . . . . . . . . . . . . . . . . . . . . . . 152.3.2 le mode`le DAFT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.3.3 le ScriptLanguage . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3 Mise en oeuvre de larchitecture DaftLea 203.1 Integration des differents modules . . . . . . . . . . . . . . . . . . . . . . . . 203.2 Controler LEA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.2.1 Animer LEA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203.2.2 Designer un objet du composant . . . . . . . . . . . . . . . . . . . . 21

3.3 Synchronisation des mode`les . . . . . . . . . . . . . . . . . . . . . . . . . . . 233.3.1 Communication Composant Mediateur . . . . . . . . . . . . . . . 233.3.2 Communication Mediateur Composant . . . . . . . . . . . . . . . 27

3.4 Chane globale TALN integree . . . . . . . . . . . . . . . . . . . . . . . . . . 27

4 Experimentation 284.1 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284.2 Apport de lexperimentation pour GRASP . . . . . . . . . . . . . . . . . . . 294.3 Apport de lexperimentation pour DAFT . . . . . . . . . . . . . . . . . . . 29

5 Conclusion et Perspectives 30

3

6 Bibliographie 316.1 The`me : View Design Language / Mediateur / Observateurs . . . . . . . . . 316.2 Architectures / Model View Controller (MVC) . . . . . . . . . . . . . . . . 316.3 The`me : LEA (Limsi Embodied Agent) . . . . . . . . . . . . . . . . . . . . 316.4 The`me : Les agents assistants . . . . . . . . . . . . . . . . . . . . . . . . . . 316.5 The`me : Les agents conversationnels . . . . . . . . . . . . . . . . . . . . . . 32

7 ANNEXES 337.1 ANNEXE I : Source du composant JAVA : Coco le compteur . . . . . . . 337.2 ANNEXE II : Source du mode`le de Coco le compteur . . . . . . . . . . . 37

4

1 Problematique

1.1 Contexte de Recherche

Ce stage se place dans le cadre dune collaboration qui demarre entre dune part lethe`me de recherche de Jean-Claude Martin sur les agents conversationnels animes (pro-jets NICE et HUMAINE) et le the`me agents dialogiques de Jean-Paul Sansonnet (projetInterViews et DAFT).La generalisation des services via lInternet ame`ne une nouvelle classe dusagers qui ont desparticularites nouvelles : populations massives, fortement heteroge`nes, non specialistes delinformatique, utilisant les services sporadiquement ; ceci engendre de nouveau besoins surtrois plans principaux : laccueil de lusager (lui donner confiance, sadapter a` son profil),lassistance lorsquil est perdu dans le service, voire lapprentissage lorsquil sagit dinter-action plus durable. Ceci a conduit a` proposer des outils dassistance, allant des simpleshelp on line actuels, dont les resultats sont notoirement decevants, aux tous nouveauxAgents Conversationnels Animes (ACA) qui se donnent pour objectif de combler le fossesemantique/cognitif entre lusager et lapplication. Pour ce faire, deux types detudes ontete menees : dune part sur la notion dagent dialogique, cest-a`-dire des composants lo-giciels capables de raisonner sur leur propre structure et fonctionnement pour repondrea` des requetes (formelles ou, idealement, en langue naturelle) ; et dautre part sur la no-tion dagent anime, cest-a`-dire generalement des personnages utilisant les modalitesverbales et non-verbales de communication humaine qui accompagnent les applications.Cette separation est methodologique car la problematique, dans sa generalite, est tre`scomplexe et les questions a` resoudre ne sont pas de meme nature tant au plan des outilsque des communautes scientifiques concernees (IA et TAL pour la premie`re, IHM et ECIpour la seconde). Nous pensons quil est necessaire de proposer une architecture logiciellegenerique qui permettrait dintegrer les divers outils autour dune meme representationmediateur, en vue de proposer une chane comple`te dagent conversationnel anime. Lepoint central reside dans la definition de la representation mediateur et surtout dans lesrelations quelle etablit avec les outils. Pour donner un exemple de relation, on se pose laquestion de lextraction, a` partir de lapplication, de representations (forcement impar-faites) sur lesquelles les outils dialogiques pourront raisonner : que faudrait t-il idealementextraire ? que peut-on effectivement extraire ? que peut-on attendre de la representationextraite ? etc.

1.2 Objectifs du stage

Lobjectif de ce stage est de definir une architecture logicielle de mediateur permettantdintegrer des outils dinterrogation et de controle dans des applications dotees dagentsconversationnel animes (ACA).Nous disposerons donc de trois elements qui devront pouvoir communiquer, se synchro-niser :

le composant (ici, une application JAVA) le mediateur (module fourni par J.P. Sansonnet)

5

un ACA, dans le cadre du projet : LEA (LIMSI Embodied Agent), fourni par J.C.Martin

Le travail porte plus particulie`rement sur : Letat de lart et etude des environnements logiciels des agents animes : architectures,langages de specification, langages de controle dagent.

La proposition dune architecture entre les trois entites de base (le composant effectif,lagent conversationnel anime et le mediateur) incluant la definition des fonctionsdes 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 controlable. Le classique jeu des Tours de Hano.

La representation visuelle des objectifs du stage ci-dessous permettront davoir unevision plus claire du projet :

Fig. 1 Objectifs du stage : DaftLea

1.3 Le the`me de recherche ACA : Etat de lart

1.3.1 Introduction

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

6

actions pour assister leur utilisateur.

1.3.2 Les Agents Intelligents

DefinitionUn agent intelligent a plusieurs definitions possibles : il y a ceux qui les assimilent a`des etre humains, et ceux qui les conside`rent comme de simple programmes. Selon cer-tains chercheurs, un agent est une entite autorisee a` agir au nom de quelquun dautre.concre`tement, un agent est : une entite logicielle possedant des caracteristiques propreset agissant dans le but daccomplir une tache au nom dune autre entite.

Principe de fonctionnementLes 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 dansles librairies

linterface utilisateur permet detablir une communication entre lagent et lutilisateur.

Quelques techniques dintelligence artificielle utilisees par les agents

Syste`mes de recherche (exploration des espaces de recherche), Syste`mes expert, T.A.L.N. (Traitement Automatique des Langues Naturelles), Reconnaissance de pattern, data-mining, Apprentissage automatise, Logique floue...

7

1.3.3 Les Agents Conversationnel

DefinitionLidee des agents conversationnels est nee avec le programme ELIZA (programme simulantun psychologue) a` la fin des annees 60. Lagent conversationnel (on dit aussi Chatterbot)est un agent intelligent disposant dun syste`me de dialogue lui permettant detablir unecommunication 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 incarnes (i.e. disposant dune representation virtuelle) permettent en plus

de la communication verbale, une communication non-verbale (posture, expression du vi-sage) augmentant ainsi la qualite de la conversation.

Les applicationsIl existe plusieurs domaines dapplications pour les Agents conversationnels. Pour le grandpublic, les agents conversationnels trouvent leur place dans les outils pedagogiques, les jeuxet lassistance personnalisee (ex : aide a` la navigation personnalisee). En ce qui concerneles entreprises, les agents conversationnels touchent differents secteurs comme le marke-ting electronique, la communication entreprise/client. Un agent conversationnel peut, parexemple, accueillir les visiteurs (internautes) 24h/24 ce qui reduit la gestion couteuse desappels telephoniques et des mails. Lagent contribut aussi a` limage de marque de lentre-prise 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 davenirLa technologie utilisee pour les agents conversationnels est aujourdhui assez simple, elleest basee sur la reconnaissance des formes. Cependant, la recherche actuelle nous fournitdes programmes danalyse de texte (phrase) tre`s poussees. Les objectifs actuels de larecherche sont dune part dameliorer la comprehension de texte en offrant la possibilitede traiter nimporte quel texte (domaines varies, types varies) et, dautre part, de fournirdautres moyens de communiquer avec lagent conversationnel (ex : telephone portable).

1.3.4 Les Agents Assistants Personnels

DefinitionLagent assistant personnel (IPA : Intelligent Personnal Assistant) est un agent destinea` nous aider dans notre travail quotidien, un peu comme une secretaire virtuelle. Il nousaide 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 :

8

Autonomie Il doit etre capable dintervenir sans demande de lutilisateur. Pour cela, ildoit observer les actions de lusager, et reconnatre les taches repetitives pour lesautomatiser. (Apprentissage, plan daction)

Personnalisation Lagent doit sadapter a` lutilisateur. Au fur et a` mesure de son utili-sation, il doit apprendre les habitudes de lutilisateur (exemple : reperer les the`mesfavoris recherches sur Internet pour laider dans la navigation web et lui proposerdes sites en rapport avec ce the`me), et ainsi adapter son comportement.

Communication Comme un agent conversationnel, lassistant doit etre capable de tenirun discours avec son utilisateur. La qualite de ce discours est importante : plus lelangage de lagent sera naturel, plus lutilisateur assimilera lagent a` un etre humain.On doit pouvoir communiquer avec lui de plusieurs manie`res (mails, web, interface,telnet, telephone...)

Competence Il doit etre competent dans son domaine dapplication. Cet attribut joueun role important dans la confiance de lutilisateur vis a` vis du logiciel : Plus lagentest competent, plus lutilisateur aura confiance et plus il lui donnera de taches a`executer.

Cooperation En cas de necessite ; lagent doit pouvoir cooperer avec dautres agents pourexecuter une tache plus complexe. Actuellement, cette cooperation avec dautresagents reste limitee.

Il existe differents types dagents assistants :

les agents semi-autonomes Cest un agent fiable, mais non-competent, lusager doitprogrammer lagent (script) pour quil execute des taches.

les agents a` bases de connaissances On doit fournir a` lassistant une base de connais-sance comple`te sur ses objectifs et sur son (ou ses) utilisateur(s). Il est cepen-dant capable de reconnatre les plans daction de lutilisateur et de lassister durantlexecution de ces plans. Malheureusement, la conception de ce type dagent demandebeaucoup de travail, notamment pour la creation de la base de connaissance.

les agents apprenants Ces agents posse`dent une base de connaissance initiale, maissont capable de lenrichir au cours de leur execution. En effet, ces agents observentet imitent les actions de lutilisateur. ils peuvent demander conseil a` dautres agentspour lexecution dune tache complexe. Enfin, lutilisateur peut intervenir si il nesouhaite pas que lagent execute certaines tache. Ces agents sont consideres commefiable 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 debutde cet apprentissage, lagent est peu competent, mais au fil de ses interactions avec luti-lisateur, lagent se personnalise et sadapte a` lusager. Pour cela, il se programme luimeme en recuperant des connaissances necessaires aupre`s de lusager. La recuperation deces connaissances peut se faire de differentes manie`res :

9

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

Les principales competences dun agent personnelVoici quelques actions que peuvent effectuer les agents assistants personnels :

etablir un dialogue (discours, conversation) avec son utilisateur, gerer des eve`nements 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 the`me sur Internet, sadapter a` son utilisateur, assister lusager dans lutilisation dautres applications

BilanBien que les agents assistants soient encore peu rependus, leur utilite nest plus a` demontreret leur succe`s grandit. Cependant, plusieurs questions se posent :

Comment garantir la confidentialite des utilisateurs alors que les agents discutententre 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 Le the`me de recherche Agent Dialogique : InterViews et DAFT

1.4.1 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 ayantconnaissance de son propre fonctionnement, et etant capable de raisonner dessus. Il doitaussi 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 usagersdans 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 requetesutilisateurs 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 duprojet InterViews.Parmis les evolutions par rapport au projet InterViews, nous pouvons noter les pointssuivants :

separation accentuee entre le mode`le et le composant, traitement de questions en langue naturelle, possibilite dinte`grer 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 : specification du projet

Le syste`me DafLea est une implementation des agents dialogiques. Dans le cadre de cestage, certaines contraintes ont ete fixees. Dune part, notre syste`me doit etre generiquevis a` vis du composant, cest a` dire quil doit pouvoir sadapter a` un composant sansavoir ete programme specifiquement pour ce composant. Enfin, Daftlea doit pouvoir etregenerique vis a` vis de lutilisateur, cest a` dire que lutilisateur ne doit pas avoira` apprendre un langage precis pour pouvoir controler le composant, mais doit pouvoircommuniquer avec lui en langue naturelle. Enfin, idealement, le syste`me doit sadapteraux differents styles linguistiques des usagers.

Fig. 2 Genericite du mediateur vis a` vis de lutilisateur (a` gauche) et vis a` vis ducomposant (a` droite)

Pour implementer ce syste`me nous devrons faire appel a` plusieurs technologies, laplupart 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 projetDAFT [J.-P. Sansonnet], et duprojet InterViews [J.-P. Sansonnet] . Ces deux projets nous apportent les notionsde mediateurs, observateurs, langage de representation VDL, langage de requeteVQL.

Afin de rendre plus (( vivante )) notre application, et de faciliter ainsi laspect dialo-gique avec lutilisateur, nous ferons appel a` la technologie des Agents Conversation-nels Animes (ACA), notamment lagent LEA (LIMSI Embodied Agent) developpepar le LIMSI-CNRS.

11

2 Le mode`le darchitecture DaftLea

2.1 Architecture generale DaftLea

Dans le cadre de notre projet, le mediateur joue un role clef. En effet, il est charge detraiter les requetes de lutilisateur et dinteragir avec le composant. Pour cela, il comporteun module de traitement du langage naturel pour analyser les questions ecrites en languenaturelle (module GRASP), ainsi quune representation symbolique interne du composantet de son fonctionnement (mode`le 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 cechoix sont simples : En java, une applet doit contenir des methodes de base pour linitiali-sation, le lancement, laffichage... Ce qui nous donne une premie`re (( piste )) pour permettreau mediateur de controler le composant. Enfin, il est plus facile, en Java dafficher uneapplet dans une fenetre. En effet, dans le cadre dune application, nous ne pouvons af-firmer que la classe principale (( derivera )) dune classe Frame, ou dun objet graphiquequelconque. Cependant, toute letude se fait dans le cadre dun composant, quil soit uneapplet, 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` larendre plus vivante. Parmis ces fonctionnalites nous avons un syste`me 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), LEAdoit pointer cet objet, facilitant ainsi la comprehension des explications pour lutilisateur.

2.2.1 Presentation de lagent LEA

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

Fig. 4 Lagent du LIMSI : LEA

Principe de LEALe principe de LEA est le suivant :

sur le plan de laffichage/animation : LEA est un personnage 2D, un affichagedune posture de LEA est une combinaison de plusieurs images (GIF) 2D corres-pondant 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 seriede position (appelees (( configuration ))) dans un fichier XML. Ce fichier est traite par

13

le programme (JAXP), et chacune des configurations est affichee sequentiellementcreant ainsi une animation.

sur le plan de la multimodalite : LEA peut exprimer une information de plusieursmanie`res (synthe`se vocale, posture du corps, phrase ecrite). Lorsque LEA souhaite,par exemple pointer un objet, elle peut le decrire oralement, ou gestuellement (si elledecrit 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 nousobtenons un eventails assez varies de manie`res de referencer un objet. Le syste`meTYCOON 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, etfait appel a des technologies comme ViaVoice (reconnaissance vocale), JavaSpeechdIBM (synthe`se vocale), JAXP (traitement de fichier XML).

2.2.2 Architecture logicielle de LEA

Lagent LEA necessite un environnement complexe pour fonctionner (synthe`se vocale[javaSpeech], chargement des animations [javax XML]...). Enfin, pour les besoins de notresyste`me, nous avons integre un nouveau module : Pointeur permettant de designer desobjets du composant. Afin davoir une vision plus claire de lenvironnement de LEA, voiciune representation visuelle de larchitecture de Lea :

14

Alors que la classe Lea ge`re le comportement de LEA ainsi que les interactions entrelutilisateur, le composant et le mediateur, la classe Display est destinee a` la gestion desanimations et de la synthe`se vocale. Elle dialogue avec la classe Lea par lintermediairede messages. De`s quun eve`nement se produit (saisie de requetes par lutilisateur, fin delanimation en cours...), Display transmet un message contenant un code a` la classe Lea quidevra 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 caracte`re (representant unerequete saisie, par exemple).

Lea.reaction(String reque^te, int code)

2.3 Description de DAFT

2.3.1 description generale

Afin de pouvoir raisonner sur le fonctionnement du composant, notre mediateur doitavoir une representation symbolique de celui-ci. Cette representation consiste en un mode`leecrit en ScriptLanguage (DAFT). Il doit decrire le fonctionnement du composant, ainsique son etat actuel (dynamique), ce qui implique une synchronisation entre le mode`le reelet le mode`le DAFT. Ce module a ete implemente en Mathematica, ce qui a pose unedifficulte supplementaire : faire interagir un composant JAVA avec un module ecrit enMathematica.

Fig. 6 La place du mode`le dans DAFT

15

2.3.2 le mode`le DAFT

Nous illustrerons le mode`le DAFT grace a` un exemple de composant : Coco le comp-teur. Ce composant, ecrit en JAVA, est une simple application simulant un decompte.Lutilisateur peut acce`lerer/ralentir la vitesse de decompte en agissant directement sur laGUI du composant.

Fig. 7 GUI du composant Coco le compteur

Nous avons choisi dillustrer le mode`le DAFT avec cet exemple pour plusieurs raisons : Coco posse`de un Thread interne (i.e. une horloge) qui modifie regulie`rement letatdu compteur. Cette caracteristique met en avant laspect synchronisation entre lemode`le DAFT de coco, et le mode`le reel (etat du composant).

La GUI de Coco comporte plusieurs elements graphiques sur lesquels lutilisateurpourra interagir : des boutons, une image, une scrollbar. A chacun de ces elementscorrespond une action que nous pourrons exploiter dans la conception de notremode`le.

Le mode`le DAFT consiste en une description des differents objets de ce composant (bou-tons, entiers, vitesse,...), de leurs roles et de leur hierarchie. Ci-dessous, une representationvisuelle du mode`le DAFT de Coco :

Fig. 8 Modelisation du composant Coco

16

Comme vous pouvez le remarquer, cette representation est tre`s proche de la GUI reellede Coco.

Afin detablir une communication entre le mode`le DAFT et le mode`le reel (JAVA),nous devons etablir des relations entre les objets decrits en DAFT et les objets JAVAdu composant. Cet ensemble de liaisons peut etre represente grace a` la DaftOntologieci-dessous :

Fig. 9 La DaftOntologie de Coco

Cette representation nous montre les relations entres les differents objets DAFT (partiegauche) et les objets JAVA (partie droite). Grace a` ce dessin, nous pouvons noter differentescaracteristiques de la mode`lisation :

Un mode`le peut ne pas correspondre a` 100% a` loriginal. En effet, certaines methodesJAVA nont pas dequivalents dans le mode`le DAFT.

Un mode`le peut apporter de nouveaux concepts a` loriginal. Par exemple, la notionde SWITCH presente dans le mode`le DAFT nexistait pas dans le composant reel.Elle est cependant composee de plusieurs elements JAVA (ici, resume() et stop()).

17

2.3.3 le ScriptLanguage

La description du mode`le seffectue grace a` un script DAFT. Ce script est composedune serie de declarations dobjets avec leurs attributs. Etudions un extrait de la descrip-tion 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 ete augmentee"];

$[INCR,JCALL]=JAVACALL["Coco","incrSpeed"];

$[INCR,PRE]=($[VAL]$[MIN])&;

$[DECR,SCRIPT]=($[VAL]--)&;

(* Methode MODIFY: changement direct de la valeur de la vitesse *)

$[MODIFY,JCALL]=JAVACALL["Coco","setSpeed",$[VAL]];

$[MODIFY,PRE]=($[MIN]$[VAL]$[MAX])&;

$[MODIFY,SCRIPT]=($[VAL]=#)&;

(* Methode MONTRE: LACA pointe lobjet *)

$[MONTRE, LEACALL]=JAVACALL["LEA","POINTE",$[JREF]"| cest ici."];

(* Methode RESET: re-init de la vitesse *)

$[RESET,LEACALL]=JAVACALL["LEA","PARLE","la vitesse a ete reinitialisee"];

$[RESET,JCALL]=JAVACALL["Coco","setSpeed",1];

$[RESET,SCRIPT]=($[VAL]=$[INIT])&;

$)

Cet extrait est la description dun objet de type cocorange. Il sagit dun entierappartenant a` un interval donne. En observant cette description, nous pouvons noter deuxparties :

la premie`re consiste en la definition de lobjet avec, par exemple, sa valeur initiale([INIT]), son label ([LABEL])...

la deuxie`me partie contient la description des methodes associees a` lobjet. Unemethode contient un script DAFT agissant sur lobjet, ainsi que la declaration desliens vers le composant JAVA ([*,JCALL]), et vers lACA ( [*,LEACALL]).

La description comple`te du mode`le de Coco est disponible en Annexe avec le code sourceJAVA de lapplet.

Ce mode`le permet au mediateur de traiter les requetes qui lui sont envoyees. Unerequete DAFT pourra faire reference aux objets declares de deux manie`res :

F [x] ou` F est un acte de langage, et x est le nom de lobjet F [REF [expr]] ou` F correspond a` un acte de langage, et REF [expr] est une ex-pression referentielle. Cette methode permet de designer un objet en fonction de sescaracteristiques (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 CategorieWANT, NEED, CAN les desirsEXEC, UNDO les commandesASK, EXIST, CHECK, WHYEXIST, WHYNOTEXIST les questionsWHY, WHYIF, WHYINSTD, HOWREPLY, ACK, NACK, AGREE, DESAGREE largumentationTELL, LIKE, DISLIKE les opinionsHELLO ouverture de session

Fig. 10 Speech Acts de DAFT

oOo

19

3 Mise en oeuvre de larchitecture DaftLea

3.1 Integration des differents modules

Comme nous lavons defini dans la presentation de la proble`matique, notre syste`meDaftLea est compose de plusieurs modules (LEA, le composant et le mediateur) qui devrontpouvoir communiquer ensemble et se synchroniser. Une premie`re difficulte apparue danslimplementation de DaftLea fut la variabilite de ces differents modules :

Le mediateur est un module concu en Mathematica, ceci implique une communicationentre deux modules ecrit dans deux langages differents : JAVA et Mathematica

Le composant est generique, ce qui signifie que nous ne pouvons pas connaitre a` lavanceson principe de fonctionnement, ni son contenu (methodes, attributs, objets...). Ceciimplique de pouvoir etablir une communication entre le mediateur et un composantinconnu.

Lea representant la GUI du mediateur. La difficulte majeure est de pouvoir inte`grer ausein de cette GUI, la GUI (active) du composant sans supprimer pour lutilisateurla possibilite dinteragir directement avec le composant.

La resolution de lensemble de ces proble`mes composent lobjectif principal du stage.Elle sera decrite dans lensemble des sections qui suivent.

3.2 Controler LEA

3.2.1 Animer LEA

Le comportement de LEA est gere par un automate deterministe. Nous avons choisidutiliser un automate pour des raisons de simplicite. En effet, lutilisation de cette techno-logie permet une gestion simple et rapide des evenements. Pour controler Lea, lanimer, ilsuffit denvoyer des messages a` lautomate qui lancera lanimation appropriee au contenudu message. Un message contient deux parame`tres : le code et la commande. Le codeest un entier permettant didentifier le type de message envoye (lancement dune nouvelleanimation, fin de lanimation en cours...), et la commande est une chane de caracte`res.Dans le cadre de DaftLea, lautomate recoit deux categories de messages :

Les messages provenant de mediateur : Ils sont destines a` lancer une nouvelle ani-mation ou` demander a` LEA de designer un objet. Le code dun message contientle numero de lanimation a` executer, et la commande contient la phrase qui devra etresynthetisee (JavaSpeech) durant lanimation. Par exemple, le message {HELLO,bonjour,je suis LEA} demande a` LEA deffectuer lanimation HELLO en disant la phrasebonjour, je suis LEA.

Les messages internes : Ces messages permettent de gerer lanimation en cours. Ilspeuvent avertir lautomate que lanimation est terminee (code : FIN ANIMATION),ou que la synthe`se vocale en cours est achevee (code : FIN PARLE). Si lutilisa-teur saisie une question dans la GUI de LEA, un message sera envoye a` lautomatequi transmettra la requete au mediateur.

20

Fig. 11 Automate de LEA : les flux de messages

3.2.2 Designer un objet du composant

Dans certaines situations (faire reference a` un objet, interagir avec un element gra-phique du composant), notre ACA, Lea, doit pouvoir designer un objet (i.e. un elementgraphique du composant, comme un bouton, une zone de saisie...). Pour cela, nous pen-sions pouvoir le faire en superposant LEA au composant, et en lui faisant pointer, avecle doigt, lobjet voulu. Mais, suite aux difficultes rencontrees pour superposer LEA aucomposant, nous avons decide dutiliser une autre methode : LEA dirige sa main en direc-tion de lelement graphique a` pointer, et lelement graphique est mis en surbrillance. (cfscreenshot 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 premie`re difficulte a ete surmontee grace a` la methode setBackground(Color c) four-nie par Java.awt. Cette methode permet de modifier la couleur de fond dun objet (en lamettant en rouge, par exemple).La deuxie`me difficulte fut resolue grace au gestionnaires deve`nements de JAVA (Action-Listener) qui, en plus dinformer sur les actions de lutilisateur, nous permet de connatrede manie`re dynamique, lemplacement des elements subissant les actions de lutilisateur.Donc, quand notre mediateur souhaite demander a` lACA de pointer un objet, il envoi unmessage a` lautomate de Lea :

Code : POINTECommande : "idObjet | phrase a` dire"

Ici, idobjet est lidentificateur (dans le source du composant) correspondant a` lelementgraphique. Enfin, Lea, par lintermediaire de lidentificateur de lobjet, change sa couleur,et recupe`re ses coordonnees. Il lui reste plus qua` afficher lanimation permettant de pointerun objet. Dans cette version de Lea, nous disposons de 3 animations :

22

3.3 Synchronisation des mode`les

Lune des difficultes majeures, auquelles nous avons ete confronte dans la conception deDaftLea, fut la synchronisation des deux mode`les : DAFT et reel (JAVA). En effet, lorsquelutilisateur interagit directement avec la GUI du composant, notre mediateur doit etreaverti du changement detat du mode`le JAVA. De meme, lorsque lutilisateur envoit unerequete au mediateur, par lintermediaire de LEA, letat du mode`le DAFT change, il fautdonc modifier letat du mode`le JAVA pour les synchroniser. Ce proble`me est resolu gracea` 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 communi-cation Mediateur vers le Composant.

3.3.1 Communication Composant MediateurCette communication seffectue dans deux situations :

interaction de lutilisateur avec la GUI du composant Lorsque lutilisateur agit avecun element de la GUI, letat du composant evolue, il faut donc mettre a` jour letat dumode`le en fonction de lelement active. Pour cela, lors de linitialisation du mediateur,nous scannons le code source du composant et associons a` chacun des elementsde linterface (bouton, champ de saisie...) une methode espion lui envoyant unmessage en cas daction de lutilisateur sur cet element. Actuellement les elementsmarques 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 defilement)

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 dansle code source du composant.

execution dune commande interne au composant Ne capturer que les interactionsentre lutilisateur et le composant ne peut suffire a` synchroniser la representationsymbolique du composant, et son etat reel. Par exemple, si le composant disposedune horloge (Thread en Java) executant en interne des appels de methode reguliers,nous devons pouvoir mettre regulie`rement a` jour le mode`le du composant. Nousavons donc implemente un syste`me capturant les appels de methodes effectues au seindu composant. Cela seffectue grace au marquage de son code source qui consisteen le modifier afin de lui demander de transmettre des messages au mediateur lorsde ses appels de fonction. Ainsi, le mediateur pourra synchroniser son mode`le enfonction des executions internes au composant.La premie`re etape du marquage consiste en extraire les classes public de chaquefichier 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 fermes

//--- automate permettant de recuperer la classe principale

for (ic=0; ic

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

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` zero des valeurs

initVariable();

_lSpeed.setValue(String.valueOf(_speed));

repaint();

}

et apre`s le marquage des appels :public void RAZ(){

initVariable();

/******************************************/

if (_kernel!=null){

_kernel.analyseAction("{METHOD,initVariable,Coco}");

}

/******************************************/


repaint();

/******************************************/

if (_kernel!=null){

_kernel.analyseAction("{METHOD,repaint,Coco}");

}

/******************************************/

}

26

3.3.2 Communication Mediateur ComposantLorsque lutilisateur envoit une requete DAFT au mediateur, letat du mode`le peut

changer. Il faut donc mettre a` jour letat reel du composant. Cette synchronisation sef-fectue en faisant appel aux methodes du composant associees aux commandes DAFTexecutees.

3.4 Chane globale TALN integree

Le module de traitement des requete DAFT nest quune partie du syste`me DAFT.En effet, DAFT consiste en une chane de traitement renvoyant une reponse en languenaturelle 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 dunereponse formelle

EVA : construction dune reponse en langue naturelle a` partir dune reponse formelle

oOo

27

4 Experimentation

4.1 Description

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

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

Description du protocole experimentalLechantillon des utilisateurs a` ete choisis sans selection particulie`re. Lexperience a eteeffectuee aupre`s dune quinzaine dutilisateurs. Elle etait composee de plusieurs etapes :

1. Lutilisateur devait poser des questions dordre general sur lapplication, Lea, Daft-Lea... lexperimentateur repondait a` la place de Lea, permettant ainsi de simuler unesorte de dialogue.

2. Pour une serie dobjets graphique donnees (boutons du composant, personnage deLea, fenetre...), lutilisateur devait saisir une requete/question faisant reference a` cetobjet.

3. enfin, lutilisateur devait terminer lapplication grace a` un dialogue de fermeture(bye,salut,...)

Bilan de lexperienceLors de cette experience, nous avons reussi a` obtenir plus de 750 requetes/questions quinous ont ete tre`s utiles pour le traitement des requetes, aussi bien dun point de vueformulation des questions que dun point de vue objet des requetes. Enfin, cette experiencea permis de mettre en avant de quelques defauts de DaftLea dans le domaine de linterfaceHomme-Machine. Bien entendu, ces defauts ont ete corriges.

28

4.2 Apport de lexperimentation pour GRASP

Letude du corpus resultant de lexperience nous a permis de connatre le vocabulaireet 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 re`gles de locutions (il y a, parce que, ...)

Le corpus nous a aussi permis detablir un ensemble de bi-grammes et tri-grammes pourla desambiguation des mots mal rediges.

4.3 Apport de lexperimentation pour DAFT

Ce corpus nous a permis de connatre les types de requete les plus frequement poseesau syste`me. 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 enevidence les moyens utilises par les utilisateurs pour designer les entites (aussi bien objetphysique que concept logique) de lapplication .

oOo

29

5 Conclusion et Perspectives

Durant ce stage, nous avons developpe une implementation du projet DAFT : Daft-Lea, permettant ainsi a` J.-P. Sansonnet dappliquer ses etudes sur la chane GRASP etle traitement de la reference. De plus, nous avons pu integrer un ACA (LEA) et assurerune interaction (communication/synchronisation) entre les trois elements principaux duprojet : le composant, le mediateur et un ACA.

Lors de limplementation de DaftLea, nous avons du faire face a` plusieurs difficultes : Proble`mes de communication entre des modules ecrits dans des langages differents(Mathematica/Java),

Proble`mes de synchronisation semantique entre un mode`le et le composant : etablirun maximum de liens entre le mode`le DAFT et les objets du composant,

Proble`mes de synchronisation physique entre un mode`le et le composant : mise a`jour synchrone entre le mode`le DAFT et letat du composant.

Une deuxie`me experimentation est prevue pour octobre 2004. Contrairement a` lapremie`re experience, le module DAFT sera active ce qui permettra a` lutilisateur deveritablement interagir avec DaftLea. Enfin, une nouvelle version de DaftLea est prevuepour octobre-novembre 2004, il sagit de DaftWeb, une version On-line de DaftLea. Len-vironnement de LEA etant trop complexe pour etre integre dans une page web, cettenouvelle version utilisera la technologie Microsoft Agent.

resume du travail effectue :Dans le cadre de ce stage, mes travaux ont ete principalement orientes vers la communi-cation et la synchronisation entre les modules : LEA, le composant, le mediateur. Len-chanement 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. Inte`gration dun composant generique dans une interface contenant un agent LEA,

5. Implementation de la premie`re version de DaftLea contenant : un composant, unMediateur et LEA,

6. Mise en place de la communication entre le Mediateur (Mathematica) et le compo-sant,

7. Implementation des premiers mode`les des composants : Coco le compteur,

8. Resolution des proble`mes de synchronisation entre le composant et le mediateur.

30

6 Bibliographie

6.1 The`me : View Design Language / Mediateur / Observateurs

1. N. Sabouret, Requetes de bon sens sur le fonctionnement, Chapitre du cours communaux DEA I3 et Sciences Cognitives de Paris XI, dec 2002.

2. N. J-P. Sansonnet, Presentation de VDL 0.1 ,Technical Report, LIMSI report n 99-10, 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, Mode`le dinterpretation constructionnelle par observateurspour les syste`mes de dialogue avec support visuel, Workshop AGENTAL, Paris,march 13, 2004.

7. J.-P. Sansonnet, Composants dialogiques generiques : perspectives et methodes pourune approche integree des outils assistants langagiers et de la programmation objet,Conference Langages et Mode`les a` Objets, LMO 04, Lille 2004.

8. J.P. Sansonnet, G. Pitel, N. Sabouret, Un Langage de Description dAgents Destinea` 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 Pat-terns, Sun Microsystems.

2. W. Greg Phillips, Architectures for Synchronous Groupware , Technical report 1999-425, Department of Computing and Information Science, Queens University.

6.3 The`me : LEA (Limsi Embodied Agent)

1. Sarkis Abrilian, Specification et developpement dinteractions multimodales bidi-rectionnelles avec un agent conversationnel, rapport de stage de DEA

2. Sarkis Abrilian, Jean-claude Martin, Stephanie Buisine, Algorithms for controllingcooperation between output modalities in 2D ECA, AAMAS 2002

6.4 The`me : Les agents assistants

1. Emerson PARAISO, Developpement dinterfaces conversationnelles utilisant la pa-role : 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 Cus-tomized E-Shopping, http ://www.computer.org/intelligent/ex2002/pdf/x6012.pdf

6. Daniele Maraschi, Stefano A. Cerri, Relations entre les technologies de lenseigne-ment et les agents,AFIA2001

6.5 The`me : 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, Unagent intelligent pour naviguer dans les mondes virtuels

3. Grant Sherson, Intelligent Agents In Education, Part of Assessment for Master ofCommunications 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 ANNEXES

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

//========================================================================

//--------------------------------COCO le compteur------------------------

//========================================================================

// - applet avec un Thread

// - mIme structure que ds modElisation DAFT

//========================================================================

//====================================================================

// initialisation

// -> public void initVariable(): initialisation des variables

// -> public void RAZ(): reinit du compteur

// -> public void init(): premiEre 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(): arrIt du dE`compte

// -> public void start(): premier lancement du dE`compte

// -> public void resume(): reprise du decompte

//====================================================================

//========================================================================

// chargement des librairies

import java.awt.*;

import java.awt.event.*;

import java.applet.*;

import javax.swing.*;

// crE`ation 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 zE`ro des valeurs

33

initVariable();


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 contrU`le

JPanel pc=new JPanel();

pc.setBackground(Color.LIGHT_GRAY);

pc.setLayout(new GridLayout(1,2));

// le contrU`le 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 contrU`le 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 fenItre

setSize(640,480);

repaint();

//--------- on associe les mE`thodes aux boutons

_bFermer.addActionListener(new ActionListener(){

public void actionPerformed(ActionEvent event){

fermer();

}

});

_bStart.addActionListener(new ActionListener(){


resume();

}

});

_bStop.addActionListener(new ActionListener(){


stop();

}

});

_bRaz.addActionListener(new ActionListener(){


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.repaint();

}

public void decrSpeed(){

_speed-=1;


_lSpeed.repaint();

}

public void setSpeed(int s){

_speed=s;//.intValue();


_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";


}

}

public void resume(){

if (_thread!=null){

_thread.resume();

_etat="compte";


}

}

}

//====================================================================

// 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 mode`le de Coco le compteurDefinition des classes de coco

Initialisation: INITCLASS

On nutilise pas le ground

INITCLASS["NOGROUND",

$top,

$cocorange,$cocobool,$cocobutton,(* base *)

$cursor,$switch,$counter,$coco (* composees *)

]

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_]:=(


INHERIT[$top,$cocorange,$];

$[JREF]=jref;

$[STRUCT]=VAR;

$[TYPE]=INT;

$[VAL]=val;

$[INIT]=val;

$[MIN]=min;

$[MAX]=max;

$[LABEL]=label;

$[BKGCOLOR]=GRAY;


$[USAGE]=JAVACALL["LEA","SPEAK","en re`glant la vitesse,

je compterai plus ou moins vite"];

(* Methode INCR: augmentation de la vitesse du compteur *)

$[INCR,LEACALL]=JAVACALL["LEA","SPEAK","la vitesse a ete augmentee"];

$[INCR,JCALL]=JAVACALL["Coco","incrSpeed"];

$[INCR,PRE]=($[VAL]$[MIN])&;

$[DECR,SCRIPT]=($[VAL]--)&;

$[INCR,MANUAL]=JAVACALL["LEA","POINTE","_sSpeed|en cliquant ici, vous

pouvez diminuer la vitesse"];

(* Methode MODIFY: changement direct de la valeur de la vitesse *)

$[MODIFY,LEACALL] := JAVACALL["LEA","SPEAK","la vitesse a ete modifiee"];

$[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 regler la vitesse"];

(* Methode MONTRE: LACA pointe lobjet *)

$[MONTRE, LEACALL]:=JAVACALL["LEA","POINTE",$[JREF]"| cest ici."];

(* Methode RESET: re-init de la vitesse *)

$[RESET,LEACALL]=JAVACALL["LEA","SPEAK","la vitesse a ete reinitialisee"];

$[RESET,JCALL]=JAVACALL["Coco","setSpeed","INT[1]"];


$)

NEW[$cocobool,$_,jref_,label_,val_]:=(

(* Definition de la classe *)

INHERIT[$top,$cocobool,$];

$[JREF]=jref;

$[STRUCT]=VAR;

$[TYPE]=INT;

$[VAL]=val;

$[INIT]=val;

$[LABEL]=label;

$[BKGCOLOR]:=If[$[VAL],GREEN,RED];


$[LEX]={"etat"};

$[USAGE]:=JAVACALL["LEA","POINTE",$[JREF]"|ce panneau vous permet

37

de contro^ler letat du compteur"];

(* Methode ON: activation du decompte *)

$[ON,LEACALL]=JAVACALL["LEA","OK","le compteur est lance"];

$[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"];

(* Methode OFF: mise en pause du compteur *)

$[OFF,LEACALL]=JAVACALL["LEA","OK","le compteur a ete stoppe !"];

$[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"];

(* Methode SWITCH *)

$[SWITCH,JCALL]:=If[$[VAL],

JAVACALL["Coco","stop"],

JAVACALL["Coco","resume"]

];

$[SWITCH,SCRIPT]=($[VAL]=$[V AL])&;

(* Methode RESET: remise a` zero du compteur *)

$[RESET,JCALL]=JAVACALL["Coco","RAZ"];


$[RESET,MANUAL]=JAVACALL["LEA","POINTE","_bRaz|ce bouton vous

permet de reinitialiser le compteur"];

$)

NEW[$cocobutton,$_,jref_,label_,jcall_,script_]:=(


INHERIT[$top,$cocobutton,$];

$[JREF]=jref;

$[ISA]=BUTTON;

$[STRUCT]=CST;

$[LABEL]=label;

$[BKGCOLOR]=darkgray;$[LAYOUT]=FEATURE[LABEL];

$[LEX]={"bouton"};

(* Methode MONTRE: permet de pointer le bouton *)


(* Methode CLICK: simule un click sur le bouton *)

$[CLICK,JCALL]=jcall;

$[CLICK,SCRIPT]=script;

$)

Classes composees

$Cursor ge`re la vitesse du compteur

NEW[$cursor,$_,jref_,val_]:=Module[{speed,bup,bdown},

(* Definition de la classe *)

INHERIT[$top,$cursor,$];

$[JREF]=jref;

$[ISA]=CURSOR;

$[LEX]={"cursor","speed","vitesse","scrollbar"};

(* init des elements 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 elements *)

$[STRUCT]=SCOPE;

$[PARTS]={speed,bup,bdown};

$[ALIAS]={SPEED Rspeed};$[BKGCOLOR]=pink;$[LAYOUT]=FRAME[DOWN[speed,RIGHT[bup,bdown]]];

(* meta operateurs **)

$[INCR,SCRIPT]=DO[speed,INCR]&;

$[DECR,SCRIPT]=DO[speed,DECR]&;

$[MODIFY,SCRIPT]=DO[speed,MODIFY,#]&;

$[RESET,SCRIPT]=DO[speed,RESET]&;

(* Methode MONTRE: permet de pointer lelement *)


$]

$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 associe aux elements *)

GLUE[bon,LEX,"start"];

GLUE[boff,LEX,"stop"];

GLUE[boff,LEX,"pause"];

GLUE[boff,LEX,"arre^t"];

GLUE[braz,LEX,"RAZ"];

$[LEX]={"switch"};

$[STRUCT]=SCOPE;

$[PARTS]={run,bon,boff,braz};

$[ALIAS]={STATUS Rrun};$[BKGCOLOR]=pink;$[LAYOUT]=FRAME[DOWN[run,bon,braz,boff]];

(* meta operateurs **)

$[START,SCRIPT]=DO[run,ON]&;

$[STOP,SCRIPT]=DO[run,OFF]&;

$[SWITCH,SCRIPT]=DO[run,SWITCH]&;

$[RESET,SCRIPT]=DO[run,RESET]&;

$]

$counter represente 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 methodes *)

$[MAP,"setText"]= ($[VAL]=#)&;

$]

$titre represente 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;


$[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 derive de $top *)

INHERIT[$top,$coco,$];

$[JREF]="Coco";

(* creation des elements 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 contro^le *)

NEW[$switch,b,"**jref**",True];

(* le bouton de fermeture *)

NEW[$cocobutton,f,"_bFermer","Fermer",

JAVACALL["Coco","fermer"],DAFTCLOSESESSION];

39

(* le lexique associe a` lobjet coco *)

$[LEX]={"coco","compteur"};

$[ABOUT]="Je suis Lea, jai ete concue par Karl Le Guern, au LIMSI-CNRS";

$[USAGE]="Ma fonction est de vous assister dans lutilisation de

Coco le compteur";

(* mise en place des elements *)

$[STRUCT]=SCOPE;

$[PARTS]={i,s,b};

$[ROLES]={SPEED[s,i],CONTROLSWITCH[b,i]};

$[ALIAS]={SPEED Rs,SWITCH Rb};$[LAYOUT]=FRAME[DOWN[t,i,RIGHT[DOWN[s,f],b]]];

(* meta operateurs *)

$[CLOCK,SCRIPT]=DO[i,CLOCK]&;

(* mapping de methodes *)

$[MAP,"setSpeed"]= DO[s,MODIFY, #]&;

$]

LAUNCH["coco"]:=INITRUN[$coco]

Launch de coco

Ouverture de la session "Coco"

DAFTOPENSESSION["coco"];

40