Intégration de Composants à un AgentConversationnel … · Conversationnel Animé ... de...

Modélisation, Interaction et Usage

Stage de Spécialité

Intégration de Composants à un AgentConversationnel Animé

Auteur :

William Boisseleau

Maîtres de stage :

Alexandre Pauchet

Ovidiu �erban

10 septembre 2013

Table des matières

Remerciements 3

Introduction 4

1 Environnement de stage et contexte 51.1 Un laboratoire de recherche : le LITIS . . . . . . . . . . . . . . . . . . . . . . . . 51.2 L'équipe Modélisation, Interaction et Usage . . . . . . . . . . . . . . . . . . . . . 51.3 Le projet ACAMODIA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61.4 Objectifs du stage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2 Le système interactif AgentSlang 82.1 MyBlock : communication par composants . . . . . . . . . . . . . . . . . . . . . . 8

2.1.1 Les données . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.1.2 Les composants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.1.3 Scheduler et notions de Service/Client . . . . . . . . . . . . . . . . . . . . 102.1.4 Exemple type et analyse de code . . . . . . . . . . . . . . . . . . . . . . . 10

2.2 La plateforme AgentSlang . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142.2.1 Composants système (MyBlock) . . . . . . . . . . . . . . . . . . . . . . . 142.2.2 Composants entrée/sortie . . . . . . . . . . . . . . . . . . . . . . . . . . . 142.2.3 Composants de traitement de langage . . . . . . . . . . . . . . . . . . . . 162.2.4 Composant de traitement de rétroaction a�ective . . . . . . . . . . . . . . 162.2.5 Emplacements des composants et topics . . . . . . . . . . . . . . . . . . . 162.2.6 Les paramètres additionnels . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.3 Le module Syn !bad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.4 Un exemple d'utilisation des composants AgentSlang et Syn !Bad . . . . . . . . . 19

2.4.1 Présentation et objectifs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192.4.2 Modèle et diagrammes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192.4.3 Test du Chatbot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3 Intégration d'AgentSlang à ACAMODIA 243.1 Cadre du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3.1.1 Rappel du contexte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243.1.2 Objet et domaine d'application . . . . . . . . . . . . . . . . . . . . . . . . 243.1.3 Cadre technique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3.2 Description générale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253.2.1 Spéci�cations fonctionnelles . . . . . . . . . . . . . . . . . . . . . . . . . . 253.2.2 Cas d'utilisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253.2.3 Interface utilisateur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263.2.4 Diagramme d'activité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263.2.5 Modèle par composants proposé . . . . . . . . . . . . . . . . . . . . . . . . 273.2.6 Perspectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

3.3 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303.3.1 Organisation du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303.3.2 Paquetage data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313.3.3 Paquetage inout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333.3.4 Paquetage out . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333.3.5 Paquetage process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343.3.6 Tests unitaires . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

3.4 Saisie des données . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353.4.1 Initialisation des �chiers de données, version 1 . . . . . . . . . . . . . . . . 353.4.2 Initialisation des �chiers de données, version 2 . . . . . . . . . . . . . . . . 35

3.5 Produit et améliorations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

TABLE DES MATIÈRES TABLE DES MATIÈRES

Conclusion 37

Table des �gures 38

Liste des tableaux 38

Listings 38

Références 39

2

Remerciements

Je tiens tout d'abord à remercier l'équipe pédagogique de l'INSA de Rouen ainsi que l'équipeModélisation, Interaction et Usage pour m'avoir permis d'e�ectuer ce stage au LITIS.

Je tiens à remercier M. Laurent Vercouter, coordinateur de l'équipe MIU, pour m'avoir per-mis d'intégrer l'équipe.

Je tiens également à témoigner ma reconnaissance envers M. Alexandre Pauchet et M. Ovidiu�erban pour le suivi, l'aide en terme d'organisation, de modélisation et de développement, letemps qu'ils ont pu me consacrer, les conseils apportés et plus globalement l'expérience très en-richissante qu'ils m'ont fait vivre durant ces deux mois de stage.

En�n, je souhaite remercier M. Jean-Philippe Kotowicz pour m'avoir mis en contact avec legroupe MIU et permis d'e�ectuer ce stage au sein du laboratoire.

3

Introduction

Notre société est aujourd'hui de plus en plus dépendante des machines physiques et im-matérielles dans de nombreux domaines, tels que l'industrie, la recherche, et même les services.Par extension, l'évolution technologique et humaine est étroitement liée aux algorithmes faisanttourner ces-dites machines, et leur étude approfondie depuis seulement une cinquantaine d'an-nées a permis de grandes avancées. Il ne s'agit pas d'améliorer seulement les composants internes,propres à ces algorithmes, mais également d'implémenter une interaction homme/machine la plusoptimale, a�n d'en parfaire les résultats. Ainsi, c'est sous le thème des interactions que le stagede spécialité ici rapporté s'est déroulé.

Une des premières intelligence informatique programmée informatiquement fut ELIZA, écritau MIT entre 1964 et 1966. Elle implémente de façon relativement précoce un traitement au-tomatique du langage naturel, en utilisant un �ltrage par motif -essentiellement des séquencesde mots. C'est historiquement le premier agent conversationnel recensé (Chatbot en anglais), etdont les principes sont encore de nos jours les bases de nombreux travaux.

De ce fait et dans un tel contexte, ce rapport porte sur l'étude d'une plateforme interac-tive distribuée appelée AgentSlang et développée dans le cadre d'une thèse. La plateforme aété conçue pour reconnaître des motifs et des émotions humaines, permettant une post-gestionlogicielle davantage accomplie. De plus, un des objectifs du stage est d'intégrer ce modèle à unautre projet du nom d'ACAMODIA. Ce dernier est un logiciel assisté de lecture d'histoire à unenfant, dans lequel il n'y a pas d'intelligence arti�cielle - l'expérience étant de type Magiciend'Oz. Le �nalité de cette intégration est d'obtenir un système complètement autonome.

Pour ce faire, nous décrirons dans une première partie l'environnement de stage et le con-texte du sujet de stage proposé. Dans une seconde partie, nous expliciterons les composantes dusystème interactif AgentSlang et leur fonctionnement global. En�n, et avant de conclure, nousdévelopperons en détail notre proposition de modèle d'intégration d'AgentSlang à ACAMODIA,de la modélisation jusqu'au tests �naux.

4

1 ENVIRONNEMENT DE STAGE ET CONTEXTE

1 Environnement de stage et contexte

1.1 Un laboratoire de recherche : le LITIS

Le Laboratoire d'Informatique, de Traitement de l'Information et des Systèmes (LITIS) estun laboratoire de recherche public en Sciences et Technologies de l'Information et de la Com-munication (STIC) fondé en 2006 et réparti sur trois établissements d'enseignement supérieurde Haute-Normandie : l'Université de Rouen, l'Université du Havre et l'Institut National desSciences Appliquées (INSA) de Rouen. C'est une unité de recherche EA4108 labellisée par leMinistère de l'Enseignement Supérieur et de la Recherche dont le directeur est Thierry Paquet.

Figure 1 � Organigramme du LITIS

Le LITIS regroupe de nombreuses disciplines étant abordées de façon théorique ou pratique,que ce soit dans des domaines liés à l'informatique, reconnaissance des formes, des mathéma-tiques et du traitement du signal et images de la médecine.

Il est structuré autour de trois axes regroupant sept équipes de recherche (cf. Figure 1) :� l'axe "Combinatoire et algorithmes",� l'axe "Traitement des masses de données",� Équipe "Documents et Apprentissages",� Équipe "Traitement de l'information en Biologie Santé ",� Équipe "Quantif",� Équipe "Systèmes de transport intelligents",

� l'axe "Interaction et systèmes complexes",� Équipe "Modélisation, Interaction et Usage",� Équipe "Réseaux d'Interactions et Intelligence Collective".

1.2 L'équipe Modélisation, Interaction et Usage

L'équipe Modélisation, Interaction et Usage (MIU) est composée de 11 chercheurs, de 10 doc-torants et de 9 associés (juin 2013). Elle concentre ses recherches autour de l'accès personnalisé à

5

1.3 Le projet ACAMODIA 1 ENVIRONNEMENT DE STAGE ET CONTEXTE

l'information. Dans un contexte de besoin de gestion de Big Data, il est important de ré�échir àdes plate-formes spéci�ques permettant la distribution et la gestion de ses données, relativementà un utilisateur lambda.

Suivant les situations, une personne pourra en e�et accéder ou non à des informations. Ellepeut, par exemple, faire partie d'un groupe n'autorisant qu'un échange interne des données, etde plus avoir accès à des données publiques. A l'intérieur même de ce groupe, elle peut ne pasavoir accès à certaines données suivant son statut. Dans le même sens, elle ne pourra pas nonplus accéder à des informations d'autres groupes de recherche. Dans de tels cas, il est nécessairede structurer un accès personnalisé à l'information, un ensemble de solutions caractérisées pardes règles applicables à chaque individu.

De ce fait, l'équipe divise sa recherche sur plusieurs niveaux :� La modélisation de structures permettant le stockage et la localisation des données, telsque des travaux d'indexation automatique, ou d'évaluation de la qualité des informations ;

� Les interactions entre utilisateurs, machines, et utilisateur-machine. Ceci peut par exem-ple concerner de la formation via des environnements virtuels ou des agents conversationnels(comme abordés dans ce stage) épaulant voire remplaçant l'homme suivant les situations ;

� Les usages, dont l'étude permet de cerner les besoins des utilisateurs et en implémenter desmodèles y répondant. Il s'agit par exemple d'exploiter de manière automatique ou manuelledes traces des utilisateurs relatives à leurs tâches, dont la �nalité serait d'en proposer unoutil ayant une e�cacité optimale.

Ainsi, les domaines scienti�ques abordés par l'équipe MIU sont les systèmes multi-agents etagents autonomes et l'extraction et la gestion des connaissances. Les domaines d'applicationss'inscrivent dans l'e-learning, l'e-teaching, les communautés virtuelles et l'intelligence ambiante.

1.3 Le projet ACAMODIA

Le stage ici rapporté s'inscrit dans le cadre du projet ACAMODIA lancé en septembre 2011.Il fut développé par le LITIS en partenariat avec le Groupe de Recherche en Informatique, Image,Automatique et Instrumentation de Caen (GREYC), le laboratoire Psychologie des Actions Lan-gagières et Motrices (PALM) et le laboratoire de Psychologie et Neurosciences de la Cognition etde l'A�ectivité (PSY-NCA). Il a été lancé grâce à un �nancement Projet Exploratoires Pluridis-ciplinaires (PEPS) des instituts INS2I et INHS. Le projet se situe dans la partie interaction dugroupe de recherche MIU du LITIS, et a pour problématique l'adaptation et le perfectionnementdes interactions Homme-Machine. Son objectif est de mettre en place une plate-forme d'analysede dialogues, ainsi qu'un agent conversationnel a�ectif pour la narration d'histoires enfantines.Il s'agit également d'étudier les interactions entre l'enfant et l'agent durant la narration a�nd'améliorer le système.

La partie LITIS de ce projet est développée suivant deux thèses dont celle d'Ovidiu �erbanet celle de Zacharie Ales, et s'est échelonnée ainsi :

1. La numérisation de corpus de dialogues lors de la narration Parents-Enfants. 120 dialogues,représentant 20h d'enregistrements et 9584 énoncés ont été retranscrits et annotés, suivantun codage relatif à la nature de l'énoncé (question, a�rmation), sa référenciation (les per-sonnes mises en ÷uvre), l'état mental (si l'énoncé est une marque d'émotion par exemple)et les justi�cations (par cause/conséquence, par opposition).

2. La mise en place d'une expérimentation de type magicien d'Oz, dans lequel les enfantsinteragissent avec un système informatique qu'ils croient autonome, qui est en réalité con-trôlé par un humain, en l'occurrence un psychologue. L'expérimentation se déroule en deuxparties. L'agent conversationnel est d'abord représenté par un avatar pour les 8 premièresquestions, puis par la vidéoconférence du psychologue contrôlant le système pour les 8dernières.

6

1.4 Objectifs du stage 1 ENVIRONNEMENT DE STAGE ET CONTEXTE

3. La création d'une annotation automatique permettant notamment la détection d'émotion.Cette étude se base d'une part sur la classi�cation d'Ekman, selon laquelle il est possibled'identi�er certaines expressions d'une personne sur une image, émotions soit biologiquessoit universelles, telles que la tristesse, la joie, la colère, la peur, le dégoût et la surprise.Une autre classi�cation fut rendue possible grâce à l'analyse sémantique latente (LSA :Latent Sementic Analysis), qui est une technique d'analyse de relations entre un ensemblede documents (ici nos énoncés) et les termes qu'ils contiennent (les mots), produisantun ensemble de concepts. Cette analyse suppose que les mots qui sont proches de sensréapparaîtront avec un même contexte dans d'autres textes.

4. L'extraction des motifs dialogiques, permettant la construction de banques de motifs, viaune heuristique de motifs dialogiques et de clustering de ces motifs.

5. La gestion du dialogue de l'agent. Les automates sont notamment utilisés pour générer desmessages (le dialogue narratif, entre autres) et interpréter les messages reçus. Ceci peutêtre du texte, du son ou encore de la vidéo. Un composant d'écoute sensorielle a été utilisépour ce dernier élément, à savoir le projet Semaine [2] qui permet l'interaction avec unhumain via un personnage virtuel.

Figure 2 � Développement d'ACAMODIA au LITIS

1.4 Objectifs du stage

Le stage de spécialité ici rapporté a pour objectifs les points suivant :� D'une part, apprécier et analyser les composants de la plateforme AgentSlang (ci-aprèsexplicitée), en comprendre son contenu et ses composants. Ceci inclue l'étude des modulesSyn !bad, MyBlock et nécessite la compréhension de la communication entre composantsutilisée pour ce projet.

� D'autre part, implémenter un agent conversationnel de type Chatbot utilisant des élémentsdu projet AgentSlang.

� En�n, soumettre une proposition de modèle de Dialogue pour le projet ACAMODIA. Cemodèle a pour but de "remplacer le psychologue", en utilisant les éléments du projetAgentSlang et est développé en JAVA.

7

2 LE SYSTÈME INTERACTIF AGENTSLANG

2 Le système interactif AgentSlang

AgentSlang est un projet conçu et développé en Java par Ovidiu �erban dans le cadre de sathèse [3] défendue en septembre 2013.

2.1 MyBlock : communication par composants

AgentSlang utilise des méthodes de communication spéci�ques qu'il est nécessaire d'introduireavant d'expliciter son contenu. Le moduleMyBlock décrit des règles de communication génériquesétant utilisées par AgentSlang.

2.1.1 Les données

MyBlock propose une implémentation objet pour la gestion des données entre composants.Au niveau des classes, lorsque l'on travaille directement sur le code du système, on considèreles entrées comme des données de type chaîne de caractères (String Data). On peut avec ceString sortir les données sous forme de Annotation Data, ou encore sous forme de Valence Data(explicités ci-après). Ces 3 types de données sont ensuite caractérisées par un identi�ant distinct(en binaire) permettant une optimisation des échanges de données (cf. �gure 3).

Figure 3 � Diagramme simpli�é des objets Data de MyBlock

Les Annotations. Pour éviter l'utilisation d'un String, il est possible de travailler avec desannotations. Ceci consiste tout d'abord à séparer les éléments d'une chaîne de caractères suivantdes règles précises. Deux méthodes sont utilisées pour la séparation de la chaîne en entrée. Pre-mièrement, la séparation text, qui consiste à séparer la chaîne par mots ou groupes de mots. Uneliste d'identi�ants/groupes de mots (ou mot) est renvoyée : list (index, token). Deuxièmement,une séparation par phonèmes, par l'algorithme Double Metaphone et qui renvoie de la mêmefaçon une list(index, token). En�n, pour chaque token, les composants sont annotés de di�érentesfaçons :

� POS (Part Of Speech), correspondant à une catégorisation des éléments suivant leur éti-quette grammaticale (TAG), comme les verbes (VB), adjectifs (JJ), noms (NN), adverbes(RB).

� NER (Name Entity Recognition), la reconnaissance des entités nommées, qui consiste àrechercher un/des mot(s), ou un groupe de mots catégorisables dans des classes telles quenoms de personnes, noms d'organisations/d'entreprises, noms de pays, quantités, valeurs,dates, etc. C'est typiquement ce que propose Wikipedia, avec son indexation de documents.

� CHK (Chunking), qui consiste à séparer des concepts en petits morceaux, rendant lalecture d'un même contenu à la fois plus rapide et plus facile.

� SRL (Semantic Role Labelling), qui permet de séparer des phrases par groupes de rôlessémantiques, tel que le verbe, l'agent principal, le complément, etc.

� PSG (Syntactic parsing), qui est une décomposition analytique identi�ant des jetons sig-ni�catifs, les analyse, puis en construit un arbre d'analyse.

8

2.1 MyBlock : communication par ... 2 LE SYSTÈME INTERACTIF AGENTSLANG

Ces annotations sont e�ectués grâce au logiciel Senna [4].

En�n, on considère les données de type Valance Data des informations liées à des détectionsa�ectives, telles que des comportements détectés par capture de texte, voix, et vidéo grâce aulogiciel Semaine [2].

2.1.2 Les composants

Figure 4 � Composant dé�ni dans MyBlock

On dé�nit un composant comme une boite traitant un certain nombre de fonctions, boiteexplicitement déterminée par un hôte (host) et un port (cf. �gure 4). Chaque composant autoriseun nombre précis d'entrées (inBound) et de sorties (outBound), que l'on quali�era de donnéesou informations. Il existe 4 types de composants :

� Le composant Source qui publie uniquement des informations via la méthode publish. Lasource peut toutefois recevoir des informations telles que des topics, des battements dec÷ur (heartbeat) 1, ou des messages système comme, par exemple, une entrée microphone.La méthode act() du composant source permet de lancer une action suivant un tempsmort (timeout) pré-dé�ni, et ce même s'il n'y a pas d'entrée activatrice. Ce processus estdéveloppé dans la section suivante.

� Le composant Sink est un composant recevant uniquement des informations, qui sontensuite gérées via la méthode handle(data).

� Le composant Mixed correspond à l'union entre un composant Source et Sink, sans laméthode act().

� Le composant Living correspond à l'union entre un composant Source et Sink. Ce com-posant pourrait par exemple envoyer un message après une longue inactivité.

Figure 5 � Di�usion d'un message entre 2 composants

On comprend alors qu'il est possible d'implémenter nos composants de relation type clients-serveurs, qu'un serveur soit également un client, etc. Pour échanger des données entre deuxcomposants, on utilise un canal sur lequel on peut publier des données, le topic. Il existe un topicinterne qui est dé�ni dans la méthode publish du composant et un topic externe qui est utilisépar le �chier de con�guration con�g.xml. La liaison entre ces deux topics est e�ectuée par laméthode publish.

MyBlock gère automatiquement les embranchements de canaux, tel qu'un composant Sourcepuisse envoyer un topic à deux composants Sink (au même titre que le tee en bash), maisaussi dans l'autre sens, de sorte que que deux composants Source puissent envoyer à un mêmecomposant Sink (join en bash).

1. On considère ici un Heartbeat comme une donnée envoyée de façon périodique par le Scheduler à ses abonnés

9


2.1.3 Scheduler et notions de Service/Client

Les composants ci-avant explicités ne s'exécutent pas d'eux-même ; ils demandent une entréespéci�que permettant de déclencher une action spéci�que. Un composant Sink recevra par ex-emple un topic envoyé par un composant Source auquel il est abonné. Un composant source seralui activé par un heartbeat envoyé par un ordonnanceur, le Scheduler. Le Scheduler envoie unheartbeat à tous les composants Source qui y sont abonnés, et ce à chaque fois qu'une périodeen millisecondes est terminée (le timeout). MyBlock permet de gérer un ou plusieurs Schedulersur le même projet. Il peut e�ectivement être intéressant d'utiliser deux schedulers lorsque descomposants se trouvent sur deux machines di�érentes pour éviter le phénomène de Lag dû à ladistance et le chemin parcouru par le heartbeat, comme c'est le cas sur la �gure 6.

Figure 6 � Scheduler ayant 2 composants abonnés sur di�érentes machines

On considère un service comme une ligne d'information de base de données que l'on peutinterroger à distance. Deux services permettant les échanges "serveur/client" sont dé�nis dansMyBlock :

� Le Computer Name Service qui se charge de la résolution d'adresse. Les machines sontidenti�ées par des noms et ce service se charge de faire la correspondance entre leur IP etleur hostname.

� Le Topic Service qui se charge de la résolution des topics encodés, et qui met à jourune base de données de tous les topics tournants sur le réseau. En e�et, un topic prendla forme d'un string sur le �chier de con�guration. Il est ensuite encodé en un identi�antnumérique, le rendant plus facile à manipuler.

2.1.4 Exemple type et analyse de code

On souhaite implémenter deux composants dont le premier "s'auto-abonne" et s'abonne àun deuxième composant. Le deuxième composant s'abonne également au premier. La �gure ci-dessous représente cette modélisation.

Figure 7 � Modélisation de l'exemple

10


Analysons tout d'abord le code source du composant Console (cf. Listing 1).

// Console . javapub l i c c l a s s Console extends LivingComponent {

p r i va t e i n t counter ;4

pub l i c Console ( S t r ing port , ComponentConfig c on f i g ) {super ( port , c on f i g ) ;

}8

protec ted void setupComponent ( ComponentConfig c on f i g ) {t h i s . counter = 0 ;

}12

protec ted void handleData ( GenericData message ) {System . out . p r i n t l n ( " Pr in t ing on the Console ! : "+message ) ;

}16

@Overridepub l i c boolean act ( ) {

publ ishData ( "Console . data" , new Str ingData ( In t eg e r . t oS t r i ng ( t h i s . counter++)) ) ;

20 re turn true ;}

pub l i c void def ineRece ivedData ( ) {24 addInboundTypeChecker ( Str ingData . c l a s s ) ;

}

pub l i c void de f inePubl i shedData ( ) {28 addOutboundTypeChecker ( "Console . data" , Str ingData . c l a s s ) ;

}}

Listing 1 � Console.java (exemple d'utilisation des composants)

Explicitons chacun des éléments.� On constate tout d'abord que la classe Console a bien pour classe parente un LivingCom-ponent (l.2) 2

� La classe possède une variable d'instance entière, le compteur counter (l.3)� Le constructeur est un appel du constructeur de la classe parente, avec le port et la con�g(l.6)

� La variable d'instance est initialisée dans la méthode setupComponent.� La méthode handleData (l.13) dé�nit les instructions qui seront e�ectuées une fois quedes données valides (ou une seule) entrent dans le composant. Ici, on a�che simplementun message dans le terminal ainsi que le message inBound arrivé (dans notre cas de typeString).

� La méthode act (l.18) est appelée à chaque fois qu'un heartbeat parvient au composant.A chaque heartbeat, on publie le topic interne identi�é par la chaîne de caractères Con-sole.data. Le topic en question est un string, comme le noti�e le deuxième argument de laméthode publish. On retourne VRAI pour montrer qu'on est bien passé par la méthodeact().

� En�n, on assigne les types de données que l'on peut recevoir en ajoutant des inBound dansla méthode de�neReceivedData (l.24). On détermine de la même façon le type de donnéesque l'on publie dans la méthode de�nePublishedData, en ajoutant aux outBound un topic(premier argument : Console.data) et le type de donnée que l'on envoie (deuxième argu-ment : StringData.class).

2. (l.2) := ligne 2.

11


Analysons à présent le composant Test (cf. Listing 2).

// Test . javapub l i c c l a s s Test extends MixedComponent {

p r i va t e i n t tCounter ;4

pub l i c Test ( S t r ing port , ComponentConfig c on f i g ) {super ( port , c on f i g ) ;

}8

protec ted void setupComponent ( ComponentConfig c on f i g ) {t h i s . Tcounter = 0 ;

}12

protec ted void handleData ( GenericData message ) {System . out . p r i n t l n ( " Pr in t ing r e c e i v ed message on Test ! : "+message ) ;

}16

protec ted void sendMessage ( S t r ing message ) {publ ishData ( "Test . data" , new Str ingData ( In t eg e r . t oS t r i ng ( t h i s . tCounter++))

) ;}

20pub l i c void def ineRece ivedData ( ) {

addInboundTypeChecker ( Str ingData . c l a s s ) ;}

24pub l i c void de f inePubl i shedData ( ) {

addOutboundTypeChecker ( "Test . data" , Str ingData . c l a s s ) ;}

28 }

Listing 2 � Test.java (exemple d'utilisation des composants)

On constate à nouveau que :� La classe Test a pour classe parente un MixedComponent (l.2).� On a choisi un entier tCounter comme variable d'instance (l.3).� Le constructeur appelle le constructeur de la classe parente (l.6).� La méthode setupComponent permet d'initialiser les variables d'instance, ici le compteur.� Lorsqu'une donnée entre dans le composant, la méthode handleData est appelée, et traiteun certain nombre de tâches (l.13). Dans notre cas, il s'agit simplement d'une sortie sur leterminal.

� Le composantmixed renvoie des données via la méthode sendMessage (l.17). Cette méthodepublie le topic Test.data, qui est de type StringData.

� En�n, on dé�nit les types d'entrées et de sorties grâce aux méthodes de�neReceivedDataet de�nePublishedData (l.21 et l.25).

La communication entre ces composants est gérée via deux �chiers XML. Le premier cnsSer-vice.xml (cf. Listing 3) correspond au service Computer Name Service de résolution de nom.

<!−− cn sSe rv i c e . xml −−><dns>

<machine>machine1@localhost</machine>4 </dns>

Listing 3 � cnsService.xml (exemple d'utilisation des composants)

La machine1 est localisée sur le localhost, correspondant en IPv4 à l'adresse 127.0.0.1. Il estpossible d'ajouter autant de machines que nécessaire dans ce �chier.

Le deuxième �chier con�g.xml (cf. Listing 4) décrit la façon dont est lancé le projet exemplepar MyBlock, dont l'exécution du LivingComponent et du MixedComponent.

12


<!−− c on f i g . xml −−><pro j e c t>

<p r o f i l e name=" p r o f i l e 1 " hostname="machine1">4 <schedu l e r>

<port>1222</port><timeout>100</ timeout>

</ schedu l e r>8

<s e r v i c e s><s e r v i c e name="org . ib . s e r v i c e . cns . CNService">

<port>1221</port>12 <con f i g>cnsSe rv i c e . xml</ con f i g>

</ s e r v i c e><s e r v i c e name="org . ib . s e r v i c e . t op i c . Top icServ i ce ">

<port>1220</port>16 </ s e r v i c e>

</ s e r v i c e s>

<c l i e n t s>20 <c l i e n t name="org . ib . s e r v i c e . cns . CNClient">

<host>12 7 . 0 . 0 . 1</host><port>1221</port>

</ c l i e n t>24 <c l i e n t name="org . ib . s e r v i c e . t op i c . TopicCl ient ">

<host>machine1</host><port>1220</port>

</ c l i e n t>28 </ c l i e n t s>

<components><component name="org . ib . gu i . monitor . MonitorComponent">

32 <port>1233</port><schedu l e r>machine1:1222</ schedu l e r><subs c r i b e>Connexion . Element . Console . debug@machine1:1234</ subs c r i b e><subs c r i b e>Connexion . Element . Console . heartbeat@machine1:1234</

subs c r i b e>36 <subs c r i b e>Connexion . Element . Test . debug@machine1:1235</ subs c r i b e>

<subs c r i b e>Connexion . Element . Test . heartbeat@machine1:1235</ subs c r i b e>

</component>

40 <component name="Connexion . Element . Console "><port>1234</port><schedu l e r>machine1:1222</ schedu l e r><pub l i sh>StringData . Text@Console . data</ pub l i sh>

44 <subs c r i b e>Str ingData . Text@machine1:1234</ subs c r i b e><subs c r i b e>Str ingData . Text@machine1:1235</ subs c r i b e>

</component>

48 <component name="Connexion . Element . Test "><port>1235</port><schedu l e r>machine1:1222</ schedu l e r><pub l i sh>StringData . Text@Test . data</ pub l i sh>

52 <subs c r i b e>Str ingData . Text@machine1:1234</ subs c r i b e></component>

</components></ p r o f i l e>

56 </ p ro j e c t>

Listing 4 � con�g.xml (exemple d'utilisation des composants)

Analysons chacun de ses composants.� On constate tout d'abord qu'on a déterminé un pro�l pro�le1 sur la machine1. On compteau moins un pro�l par machine. Il peut y avoir plusieurs machines de citées dans ce �chierde con�guration, pourvu qu'elles soient ajoutées au service de résolution de nom.

13

2.2 La plateforme AgentSlang 2 LE SYSTÈME INTERACTIF AGENTSLANG

� Un scheduler est dé�ni sur le port 1222. On peut régler la fréquence des heartbeat via leparamètre timeout. Dans notre cas, un heartbeat est envoyé toutes les 100 millisecondes.

� Les deux services système (ci-avant explicités) sont déclarés, le CNClient et le TopicClient,respectivement sur le port 1221 et 1220. Concernant le premier service, la con�guration larésolution d'adresse est chargée en paramètre.

� On assigne ensuite à chaque service un String de connexion, à savoir un nom référent àune machine et un port. L'adresse localhost 127.0.0.1 a été choisie pour le service CNS etla machine pour le service de topic. Les ports correspondent à ceux indiqués à la créationdu service.

� On liste ensuite les composants. On détermine d'abord sur quel port on le déclare, surquelle machine et quel port se trouve le scheduler étant lié à lui (et par conséquent surquelle machine), et en�n quels sont ses abonnements et ses publications. Concernant ladé�nition de ces deux derniers points, une convention facilitant la lecture est demandée.� pour la publication d'abord :TypeDeDonné[email protected], ou encoretopicExterne@topicInterne

� pour l'abonnement ensuite :TypedeDonnées.nomDuComposant@nomDeMachine : port

Ainsi, MyBlock rend facile une réutilisation de composants créés, pourvu que les formatsd'entrée et sortie soient respectés. AgentSlang a été développé suivant ce concept. Il est doncpossible de réutiliser certains de ses composants pour d'autres projets, comme nous allons ledécrire dans les parties suivantes.

2.2 La plateforme AgentSlang

Dans la partie précédente, nous avons compris que la structure MyBlock et, par extension,AgentSlang permettait une large réutilisation des composants, pourvu qu'on en connaisse lesentrées, sorties. Nous détaillerons dans cette partie la fonction de chaque composant, les typesde données requis en entrée et en sortie. La table 1 de la page suivante répertorie les composantssuivant leurs types, les données publiées et reçues.

2.2.1 Composants système (MyBlock)

Tout d'abord, on répertorie 3 composants gérés MyBlock étant utilisés dans AgentSlang sanspour autant être spéci�ques à celui-ci.

� Le composant SystemMonitorComponent est la plateforme permettant de connaîtreles statuts de tous les composants auxquels il est abonné. Les statuts sont renvoyés à tousles composants abonnés.

� Le composant LogComponent fourni trois niveau de debug à tous les composants, àsavoir critical, debug et uniform. Les messages reçus par le LogComponent sont renvoyésdirectement à la console par défaut, mais il est possible de les faire suivre à un élément.

� Le composant ComponentMonitor étend le LogComponent, il permet d'a�cher des li-aisons entre les composants sous la forme d'un graphe mais aussi de �ltrer les messages dedebug.

2.2.2 Composants entrée/sortie

AgentSlang gère di�érents types d'entrée/sortie via des composants, comme le montre la listesuivante :

� Le composant TextComponent étant Mixed, il peut soit envoyer une chaîne de caractèresdans le cas ou il se comporte comme un Source, ou a�cher un message reçu s'il est considérécomme un Sink.

� Le composant VoiceProxyComponent permet de transcrire une voix en texte. Il estactuellement basé sur une application Android, en particulier l'API Google Speech.

14


Composant

Fonction

Type

Donnéesreçues

Donnéespubliées

LogComponent

Debug/Logging

Sink

(in)DebugD

-System

MonitorComponent

EventMonitoring

Mixed

(out)

system.m

onitor.data,

(in)System

Event

System

Event

MonitorComponent

Platform

Monitoring

Sink

(in)DebugD

-

TextComponent

TextInput/Output

Mixed

(in)GenericD

(out)

text.data,StringD

VoiceProxyComponent

Speech

Input

Source

-(out)

voice.data,StringD

Mary

Component

Speech

Synthesis

Mixed

(in)StringD

(out)

voice.data,AudioD

(in)GenericTextA

nnotation

iSpeechTTSComponent

Speech

Synthesis

Mixed

(in)StringD

(out)

voice.data,AudioD

(in)GenericTextA

nnotation

SennaComponent

POSTagging,Chunking,NER

Mixed

(in)StringD

(out)

senna.data,

GenericTextA

nnotation

MetaphoneEncodingComponent

PhoneticEncoding

Mixed

(in)GenericTextA

nnotation

(out)

metaphone.data,

(in)StringD

GenericTextA

nnotation

Tem

plate

Extractor

Know

ledgeExtraction

Mixed

(in)GenericTextA

nnotation

(out)

templateExc.command.data,

Tem

plateD

(out)

templateExc.dialogue.data,

Tem

plateD

DialogueInterpreter

DialogueGeneration

Mixed

(in)Tem

plateD

(out)

dialogue.data,

StringD

CommandInterpreter

DialogueandCommandGeneration

Mixed

(in)Tem

plateD

(out)

command.data

StringD

Valence

ExtractorComponent

Valence

Extraction

Mixed

(in)GenericTextA

nnotation

(out)

valence.data

ValenceD

Table1�Résum

édescomposants

AgentSlang

15


� Le composant MaryComponent prend en entrée un StringData et un AnnotatedData etgénère une voix. La voix est générée par le toolkit marytts, qui fut par ailleurs utilisé pourle projet SEMAINE [2].

� Le composant iSpeechTTSComponent est un composant fournissant une voix naturelleparmi une liste assez complète de langues. L'API iSpeech TTS (Text To Speech) [5] est iciappelée.

2.2.3 Composants de traitement de langage

Une fois les données récupérées, elles sont traitées par certains composants.� Le composant SennaAnnotator permet une segmentation et annotation de chacun descomposants comme explicité dans la partie 2.1.1.

� Le composant MetaphoneEncodingComponent autorise la découpe par phonèmes.L'API ici utilisée est Metaphone3.

� Le composant TemplateComposantExtracter réfère au projet Syn !bad que nous ex-pliciterons par la suite. Syn !bad permet l'identi�cation de motifs dans des phrases, motifslistés à l'avance par le concepteur et suivant lesquels il est possible de réagir de façonpré-dé�nie, notamment grâce aux composants suivants.

� Le composant DialogueInterpreter peut, suivant un motif identi�é, répondre explicite-ment soit par une phrase soit par une commande via le CommandInterpreter.

2.2.4 Composant de traitement de rétroaction a�ective

Le composant ValenceExtractorCompenent permet d'extraire de la valence à partir den'importe quel type de données. Cette notion de valence est explicitée dans la section (2.1.1.) .

2.2.5 Emplacements des composants et topics

Voici un arbre répertoriant les emplacements et les topics mis à disposition par les com-posants, pour le module MyBlock (�gure 8) et la plateforme AgentSlang (�gure 9).

org.ib

logger

LogComponent

component

SystemMonitorComponent

gui

monitor

MonitorComponent

system.monitor.data

Figure 8 � Emplacements Composants et Channels sur le Module MyBlock

Dans ces �gures, les n÷uds simples représentent les paquetages, les n÷uds en gras les com-posants et les n÷uds en italique les di�érents channels publiés par les composants. Par exemple,le composant TextComponent se trouve dans le paquetage org.agent.slang.inout et publie sur lechannel text.data. Les composants autorisant la réception de ce type de données peuvent s'inscrireà ce channel, et agir en conséquence dès qu'un élément passe par le channel.

16

2.3 Le module Syn !bad 2 LE SYSTÈME INTERACTIF AGENTSLANG

org.agent.slang

inout

TextComponent

in

VoiceProxyComponent

out

maryTTS

MaryComponent

isSpeech

isSpeechTTSComponent

annotation

SennaComponent

MetaphoneEncodingComponent

dm.template

TemplateExtractor

DialogueInterpreter

CommandInterpreter

feedback

ValenceExtractorComponent

text.data

voice.data

voice.data

voice.data

senna.data

metaphone.data

templateExc.dialogue.data templateExc.command.data

dialogue.data

command.data

valence.data

Figure 9 � Emplacements composants et channels sur la plateforme AgentSlang

2.2.6 Les paramètres additionnels

Le système propose également la possibilité d'ajouter des paramètres pour chacun des com-posants (autres que de l'a�ectation) sur un port, de l'inscription sur le Scheduler ou sur un autrecomposant (subscribe), de la publication (publish), et qui permet d'ajouter de l'information com-plémentaire sur le composant.

� Composant VoiceProxyComponent : voiceBTuuid pour l'identi�ant bluetooth du pé-riphérique et voiceBTmac pour l'adresse matérielle du périphérique (Bluetooth Device Ad-dress).

� Composant SennaComponent : sennaPath pour l'emplacement physique de Senna etsennaParams pour le type de tokenisation choisie

� Composant TemplateExtractor : commandModel sur lequel on y trouve les réponsesrelatives aux motifs, listés suivant un identi�ant et dialogueTemplate listant les motifs.

� Composant CommandInterpreter : commandModel� Composant DialogueInterpreter : dialogueModel

2.3 Le module Syn !bad

Syn !bad (acronyme de Synonyms [are] not bad) ou Synnbad est un module créé dans l'optiquede simpli�er et d'améliorer la reconnaissance de mots et de motifs. Il est intégré à AgentSlang,mais il est également possible de l'utiliser seul. La reconnaissance de motifs se base sur l'exactesimilitude entre des caractères ou des séquences de caractères (ici des mots), mais aussi la qualitégrammaticale des mots ou groupes de mots dans une phrase et leurs synonymes.

17

2.3 Le module Syn !bad 2 LE SYSTÈME INTERACTIF AGENTSLANG

Le c÷ur de l'algorithme se base sur l'utilisation d'expressions rationnelles (POSIX RegularExpression). Une expression rationnelle est une suite de caractères typographiques aussi appeléemotif (pattern), chargée de décrire une chaîne de caractères pour la trouver dans un bloc de texte.On peut assimiler les motifs à des automates de mots ou encore de types de mots. Une syntaxespéci�que est dé�nie pour Syn !bad. Elle permet de dé�nir des classes de caractères, à savoir descaractères ou des séquences de caractères qu'il est possible de rechercher dans des chaînes. Cesclasses sont notamment dé�nies grâce à des opérateurs standards, comme listés dans la table 2.

Opérateur Description Exemple

|Opérateur de restriction par éti-quette grammaticale

[word|NN*] permet de reconnaître le motword ou un nom synonyme de word.

$ ou #Notion de variable pour post-utilisation

$nom permet de pouvoir récupérer lavaleur de nom dans un motif

[ ]Prend en compte tous les syn-onymes de la chaîne entre crochets

[manger] sera reconnu avec les motsavaler ou dévorer

{}Prend en compte l'élément précé-dent un nombre de fois dé�ni surun intervalle

a{2, 4} permet de reconnaître aa, aaa etaaaa

< >Permet de gérer des structuresdé�nissant des types de mots

< <POS>1 ('#' <variable>2) >

?Signi�e "zéro ou un" du précédentélément

x y? z permet de reconnaître x z et x y

z.

*Signi�e "zéro ou plus" du précé-dent élément

x y* z permet de reconnaître x z, x y z,x y y z, x y y y z, etc.

+Signi�e "un ou plus" du précédentélément

x y+ permet de reconnaître x y, x y y, xy y, etc.

Table 2 � Liste des opérateurs proposés par Syn !Bad

Prenons un exemple pour expliciter son fonctionnement. Considérons la phrase Ovidiu eatsgood candies. Elle peut être décrite en termes grammaticaux tels que <nom> <verbe> <adjec-tif> <nom>. Si l'on souhaite généraliser la phrase tout en gardant son sens (ou un sens proche)sans pour autant utiliser les mêmes mots, il est possible de créer un motif. On peut par exempledé�nir le motif suivant : $name <VB*>* [good|JJ*] candies <#*>?

Explicitons chacun des termes de ce motif :� $name est une variable libre de contexte, représentant tout mot (non conditionné) et ayantpour contenu le premier mot de la phrase reconnue par le motif,

� <VB*>* correspond à un "zéro ou plusieurs" verbes, VB* référant à la catégorie des verbes,� [good|RB*] réfère à un synonyme de good conditionné par JJ*, à savoir uniquement lesadjectifs synonymes de good,

� candies doit apparaître explicitement dans la phrase,� <#*>? est un marqueur de ponctuation, #* représentant le groupe générique de ponctuationdu POS. Le ? signi�e "un ou aucun", ce token est donc optionnel, il peut ne pas y avoir designe de ponctuation.

Ainsi, une phrase sera dite reconnue (matched) si elle respecte séquentiellement chacune des

1. <POS> := <PennPOS> | <GenericPOS>avec <PennPOS> := 'JJ' | 'RB' | 'DT' | 'TO' | 'RP' | 'RBR'| 'RBS' | 'LS' | 'JJS' | 'JJR' | 'FW' | 'NN' | 'NNPS' | 'VBN' | 'VB'| 'VBP' | 'PDT' | 'WP$' | 'PRP' | 'MD' | 'SYM' | 'WDT' | 'VBZ' | '"' | '#' | 'WP' | ''' | 'IN' | '$' | 'VGB' | 'EX' | 'POS' | '(' | 'VBD'| ')' | '.' | ',' | 'UH' | 'NNS' | 'CC' | 'CD' | 'NNP' | 'PP$' | ':' | 'WRB'et <GenericPOS> := '#*' | 'VB*' | 'RB*' | 'NN*' | 'JJ*'

2. <variable> := [a-z0-9]

18

2.4 Un exemple d'utilisation ... 2 LE SYSTÈME INTERACTIF AGENTSLANG

caractéristiques des n÷uds de ce motif, tel un automate.

Par exemple, la phrase Ovidiu likes great candies ! sera reconnue par le motif, tel que le$name←"Ovidiu", <VB*>*↔"likes" en tant que verbe, [good|JJ*]↔"great" en tant que synonymede good et adjectif, "candies" est présent explicitement et en�n <#*>?↔" !".

Lorsqu'un motif est reconnu, l'identi�ant de celui-ci est retourné, ainsi que toutes les variablessauvegardées. On distingue deux types de variables, les variables locales comme $name et lesvariables globales comme #name :

� Le motif $name is nice autorise premièrement la reconnaissance de n'importe quel pre-mier mot ou ponctuation (sans conditionnement) qui est stocké dans la variable $name puisis nice en brut.

� Le motif <NN*#name>* is nice autorise tout d'abord la reconnaissance d'un nom unique-ment, qui est stocké dans la variable #name puis de is nice en brut.

En�n, il est possible d'assigner aux motifs des étiquettes pouvant caractériser le motif, ap-pelées style. Un style est une liste de paires étiquette/valeur assignée à chaque motif. Ceci permetd'ajouter une information supplémentaire au motif, et suivant celle-ci proposer des actions spé-ci�ques. Un motif ayant un style relation (étiquette) quali�é de familier (valeur) provoquerapar exemple un choix de réponses et/ou commandes particulières, qui n'auraient pas été choisiesdans le cas ou l'étiquette relation eut été soutenu.

2.4 Un exemple d'utilisation des composants AgentSlang et Syn !Bad

2.4.1 Présentation et objectifs

A�n de se familiariser avec la plateforme AgentSlang et les méthodes de Syn !Bad, nous pro-posons de mettre en place un agent conversationnel type Chatbot répondant à quelques unes desréactions de l'utilisateur, et rendant possible le lancement d'actions sur notre ordinateur.

Le programme doit notamment répondre aux principales spéci�cations suivantes :� Le Chatbot doit être testable sur le système Linux, et est développé en Java.� Le Chatbot doit utiliser quelques composants d'AgentSlang et doit en proposer un nouveau.Il doit également appeler en direct des composants du module Syn !Bad a�n d'en appréciersa logique. Le tout doit rester le plus simple possible.

� Les composants MyBlock permettant la communication entre composants doivent êtreutilisés.

� Le Chatbot doit pouvoir récupérer du texte entré au clavier, éventuellement de la voix, etêtre capable de reconnaître son contenu grâce à l'appel des méthodes Syn !Bad.

� Les motifs du Chatbot sont stockés dans un �chier XML. Le �chier contient une listed'éléments, dont chacun est décrit par l'identi�ant du motif, le motif lui-même, et une listede réponses liées à celui-ci.

� Le Chatbot doit pouvoir lancer une action suivant l'identi�ant du motif. On considéreraune action comme une commande texte exécutable dans un terminal. Les actions sontstockées dans un �chier XML, et sont déterminables par un identi�ant.

� Suivant les réactions de l'utilisateur, les réponses lui seront envoyées de façon textuelle(a�chage à l'écran) et vocale. De plus, elles sont choisies aléatoirement parmi la liste deréponses relatives à un motif. Il doit être possible de choisir une réponse spéci�que, pourpermettre sur une version plus évoluée (non demandée) de répondre suivant l'humeur del'utilisateur.

2.4.2 Modèle et diagrammes

La �gure 10 montre une proposition de modèle que nous avons pu développer. On compte troiscomposants tous abonnés au Scheduler (Monitor) : Le TextComponent (Text) qui publie un

19


String.data sur le port 1234, le composant Jarvis qui publie aussi un String.data sur le port 1236,le MaryComponent (Mary) qui publie un Audio.data sur le port 1235. Le TextComponent estabonné au String.data du composant Jarvis et à l'Audio.data du MaryComponent, le composantJarvis est abonné au String.data du TextComponent, et en�n le MaryComponent est abonné auString.data du composant Jarvis.

Figure 10 � Modèle d'interaction des composants du chatbot

Concrètement, le texte envoyé par l'utilisateur est tout d'abord récupéré grâce au composantTextComponent. Ce texte est ensuite traité en interne par le composant Jarvis en appelant desméthodes du module Syn !Bad. Une fois le procédé terminé, la réponse choisie par le composantJarvis est envoyée au TextComponent pour un a�chage sur la fenêtre, mais aussiMaryCompo-nent qui va créer une donnée audio correspondant à la chaîne de caractères reçue. Cette donnéeaudio est adressée au TextComponent qui va la lire.

Ainsi, seul le composant Jarvis est à créer, les autres étant fournis par la plateforme AgentSlang.Pour alléger le composant, nous avons développé trois classes en parallèle qui décrivent di�érentesétapes du traitement de la chaîne de caractères en entrée. La �gure 11 dé�nit ces classes à traversun diagramme de classes.

Figure 11 � Diagramme de classes développé pour le Chatbot

20


� La classe SynnMatch permet d'utiliser et d'appeler les variables d'instance et méthodesSyn !bad pour un traitement en interne. A l'initialisation, on charge les di�érents motifs(matcher). Suivant l'entrée (input), on la sépare en tokens, qui sont ensuite testés danschacun des motifs. Si un des motifs est reconnu, on assigne la réponse requise à la variableoutput

� La classe JDomSynn permet le traitement et la récupération des données XML de partl'utilisation de la bibliothèque JDOM [6], spéci�quement aux besoins de tests sur les motifset récupération de réponses dans le �chier patterns.xml. Il s'agit principalement de getterssur le �chier à traiter.

� La classe JProcess gère l'accès et le lancement de commandes, en l'occurrence commandesenvoyées à l'interpréteur de commande Unix Shell. Les commandes sont également stockéesdans un �chier XML, commands.xml.

� En�n, la classe Jarvis est dé�nie comme un composant qui traite en entrée une chaînede caractères (texte envoyé par le composant TextComponent) et publie une chaîne decaractères correspondant à la réponse du Chatbot. Nous expliciterons 3 méthodes de laclasse, les autres étant codées suivant le même principe que décrit en 2.1.4 .

1. La méthode setupComponent (cf. Listing 5) permet con�gurer le composant en initial-isant notamment les booléens, l'entrée (input), la construction par défaut du JProcesset du SynnMatch.

// Ext ra i t de l a c l a s s e Ja rv i s . java : methode setupComponentprotec ted void setupComponent ( ComponentConfig c on f i g ) {

t h i s . inputV="" ;4 t h i s . weContinue=f a l s e ;

t h i s . keybordOnly=f a l s e ;t h i s . p = new JProcess ( ) ;t h i s . f i r s t c a l l=true ;

8 t h i s . synn= new SynnMatch ( ) ;}

Listing 5 � Jarvis.java (extrait 1 - composant Jarvis)

2. La méthode act (cf. Listing 6) est appelée à chaque fois qu'un heartbeat est reçu.On a choisi de l'appeler uniquement lorsqu'une chaîne de caractères (même vide) estenvoyée par l'intermédiaire du TextComponent. Au premier heartbeat reçu, on avertisimplement l'utilisateur qu'il peut soit appuyer sur la touche Entrée pour parler aumicrophone, soit taper le texte de son choix pour clavarder(l.15). Il eut également étépossible de le noti�er à l'initialisation. Dans le cas où le texte envoyé est vide (l.5),on lance la commande 0 correspondant tout d'abord à l'enregistrement du son viaun microphone puis à un traitement de ce son par l'intermédiaire l'API google dereconnaissance vocale (l.7). Le texte reconnu est ensuite chargé en tant que chaînede caractères dans inputV (l.8). On génère le retour grâce à la classe SynnMatch,que l'on publie avec la méthode sendMessage. En�n, à chaque �n d'act, on assigneFAUX à weContinue (l.12). En e�et, le heartbeat sera envoyé de façon périodique etsans arrêt, et l'on souhaite pouvoir appeler les précédentes commandes uniquementlorsqu'un texte (même vide) est envoyé par le TextComponent.

// Ext ra i t de l a c l a s s e Ja rv i s . java : methode act@Overridepub l i c boolean act ( ) {

4 i f ( weContinue ) {i f ( ! keybordOnly ) {

sendMessage ( " ( ( ( Recording ) ) ) " ) ;p . launchCommand (0) ;

8 t h i s . inputV=p . l o adF i l e ( " output . txt " ) ;}t h i s . synn = new SynnMatch ( inputV ) ;sendMessage ( t h i s . synn . getOutput ( ) ) ;

12 t h i s . weContinue=f a l s e ;

21


}

i f ( f i r s t c a l l ) {16 sendMessage ( " [NOTE: p r e s s ente r to ta lk , or wr i t e in the

chat ] " ) ;t h i s . f i r s t c a l l=f a l s e ;

}re turn true ;

20 }


3. La méthode handleData (cf. Listing 6) est appelée à chaque fois qu'un élément estpublié sur un ou plusieurs channels dont le composant est abonné. A chaque donnéereçue, dans notre cas une chaîne de caractères publiée par le TextComponent, onvéri�e tout d'abord qu'il s'agit bien d'une chaîne de caractères. Si c'est le cas, alorson véri�e si elle est vide ou non. Si elle est vide alors on assigne FAUX à keybordOnly,sinon on lui assigne VRAI (l.11), et on assigne à inputV la chaîne de caractèresrecueillie (l.6).

// Ext ra i t de l a c l a s s e Ja rv i s . java : methode handleDataprotec ted void handleData ( GenericData data ) {

System . out . p r i n t l n ( data . t oS t r i ng ( ) ) ;4 i f ( data i n s t an c e o f Str ingData ) {

i f ( ! data . t oS t r i ng ( ) . isEmpty ( ) ) {t h i s . inputV=data . t oS t r i ng ( ) ;t h i s . keybordOnly=true ;

8 }e l s e {

t h i s . keybordOnly=f a l s e ;}

12 t h i s . weContinue=true ;}

}


Le projet Chatbot n'étant pas l'objectif ultime de ce stage et considérant le reste des con-stituants comme non indispensables pour sa compréhension globale, nous ne développerons pasdavantage l'explication de ses éléments.

2.4.3 Test du Chatbot

La �gure 12 montre le moniteur de texte lors de l'exécution du Chatbot, et notamment unéchange entre un utilisateur (entrées "<<<") et l'agent conversationnel (sorties ">>>").

22


Figure 12 � Clavardage sur le moniteur de texte du Chatbot

Ci-dessous une description des éléments de clavardage de la �gure 12 :

1. Le Chat est initialisé. (Sound playing) réfère aux éléments e�ectivement lus par la synthèsevocale.

2. L'utilisateur envoie au clavier "Hello !". Il est reconnu par le motif [hello]*, et une réponseliée à ce motif et choisie aléatoirement est donnée, et lue par la synthèse vocale.

3. L'utilisateur envoie au clavier "Hello my friend !". Il est à nouveau reconnu par le motif[hello]*, même procédure.

4. L'utilisateur envoie au clavier "Who are you ?". Cette chaîne de caractères est reconnuepar le motif who are you ?, et une réponse liée est renvoyée par le chatbot puis lue par lasynthèse vocale.

5. L'utilisateur appuie sur entrée, sans envoyer de texte. Un système d'enregistrement estlancé. L'utilisateur dit "I am feeling better". Le son est envoyé à google, reconnu puisretourné au Chatbot. Le motif i am [feeling] [better] est reconnu, et une réponse liéeest renvoyée et lue par la synthèse vocale.

6. L'utilisateur envoie au clavier "Bye". Le motif [goodbye]* est reconnu, une réponse liéeest renvoyée et lue par la synthèse vocale.

23

3 INTÉGRATION D'AGENTSLANG À ACAMODIA

3 Intégration d'AgentSlang à ACAMODIA

3.1 Cadre du projet

3.1.1 Rappel du contexte

L'expérience e�ectuée dans le cadre du projet ACAMODIA était, pour rappel, la narrationd'une histoire à un enfant, ceci en déroulant un certain nombre de diapositives. Pour chaque étapedu scénario, le conteur virtuel raconte un morceau de l'histoire, et, pour passer à la suivante, soitpose une question à l'enfant relative à l'histoire, soit attend une réaction corporelle quelconquede l'enfant. Jusqu'alors, c'est un psychologue qui sélectionnait les réponses appropriées suite auxréactions des enfants. L'objectif de ce stage est d'utiliser certains composants d'AgentSlang etd'en créer de nouveaux pour remplacer les actions du psychologue sur l'interface graphique.

Figure 13 � Interface graphique sur l'ordinateur du psychologue

Comme montré sur la Figure 13, à chaque étape de l'histoire, le psychologue peut interagirde trois façons di�érentes avec l'interface graphique :

� Lors de la narration de l'histoire, le psychologue peut insister sur des éléments importants(lieux, personnages) en pointant la souris sur ceux-ci.

� Si l'enfant donne la réponse attendue ou une réaction corporelle relative à la situation, lepsychologue passe à l'étape suivante par un clic sur l'étape consécutive.

� Sinon, et dans tous les autres cas, le psychologue peut envoyer une réponse hors contexteparmi une liste de réponses pré-dé�nies. Par exemple, ceci comprend les cas où l'enfantn'est pas attentif et ou lorsqu'il n'a pas répondu correctement. Il est également possible derelancer une étape par un clic sur celle-ci.

3.1.2 Objet et domaine d'application

La �nalité à long terme de ce projet est d'automatiser les actions du psychologue dans le pro-jet ACAMODIA par une intelligence arti�cielle. L'objet de ce rapport est tout d'abord de dé�nirles spéci�cations fonctionnelles détaillées du projet d'intégration de la plateforme AgentSlang auprojet ACAMODIA. Il décrit l'ensemble des fonctionnalités de l'application, les éléments créés(leurs principes et utilités) et l'interface utilisateur. Toutes les fonctionnalités prévues pour ceprojet d'intégration sont décrites ici. La maquette a été travaillée avec les commanditaires etapprouvée, et c'est sur celle-ci que nous nous baserons lors de la phase de conception.

Ce rapport est applicable lors de la phase de développement de l'application. Ses fonctionssont conformes aux éléments et spéci�cités détaillées ci-après.

3.1.3 Cadre technique

L'application est exécutable sur un système d'exploitation de type Linux (démonstration surUbuntu 13.04), tournant sur un ordinateur possédant des entrées et sorties son. La version de laplateforme d'exécution et de compilation Java utilisée est la 1.7.0_21. Les bibliothèques JDom[6] (v. 2.0.5) et ZeroMQ [7] (v. 3.2.3) doivent être également installées. En�n, la dernière versionde la plateforme AgentSlang est nécessaire pour un accès aux composants déjà implémentés.

24

3.2 Description générale 3 INTÉGRATION D'AGENTSLANG À ACAMODIA

3.2 Description générale

3.2.1 Spéci�cations fonctionnelles

L'application devra être capable de dérouler les di�érentes étapes du scénario suivant lesréactions de l'utilisateur, à savoir être capable de :

� Lancer une étape. On dé�nit une étape par la lecture d'une partie de l'histoire par synthèsevocale, accompagnée d'un diaporama. Il ne peut y avoir qu'un et un seul type d'histoire àlire par étape, mais une même diapositive peut servir à plusieurs étapes.

� A�cher le numéro de l'étape courante à l'écran.� Gérer la transition entre les étapes. On considère que l'on peut passer à l'étape suivante àpartir du moment où l'utilisateur réagit. On appelle réaction une entrée texte par l'utilisa-teur. Si l'utilisateur réagit, alors l'application :

1. Récupère le texte de réaction de l'utilisateur

2. Véri�e si cette réaction est reconnue parmi les motif stockés dans un �chier XML� Si un des motifs est reconnu, alors la synthèse vocale lit la réponse qui s'y réfère.Dans le cas où le motif correspond à celui permettant de passer à l'étape suivante,on envoie la diapositive suivante si nécessaire.

� Si aucun des motifs n'est reconnu, alors l'application avertit l'utilisateur qu'elle n'apas compris, et attend à nouveau une réponse.

� Relancer, au bout d'un certain temps, l'utilisateur en cas de non réaction de sa part, parl'intermédiaire de réponses prédé�nies l'y encourageant. Suivant les situations, il doit êtrepossible de passer à une nouvelle étape.

� Avoir la possibilité de passer à l'étape suivante sans pour autant avoir de réaction.� Gérer des groupes de motifs ayant des groupes de réponses prédé�nies.� Avoir la possibilité de considérer de la voix comme réaction en entrée.

De plus, la modélisation devra prévoir (implémentation toutefois non demandée) les pointssuivants, pour un développement ultérieur :

� Avoir la possibilité de remplacer la synthèse vocale par un agent conversationnel virtuelpersonni�é, au même titre que GRETA [8] du projet SEMAINE.

� Avoir la possibilité de considérer en entrée la visioconférence pour la récupération desréactions.

� Animer des éléments du scénario, notamment le pointeur pour rendre le projet plus inter-actif.

3.2.2 Cas d'utilisation

Comme on peut le constater sur la �gure 14, l'utilisateur n'aura que très peu d'interactionsavec l'application si ce n'est une expression textuelle au clavier, puis audiovisuelle pour uneversion ultérieure (non incluse dans la version 1). Cette spéci�cité est conforme à notre projet,étant donné que l'application est développée pour être la plus autonome possible.

Figure 14 � Diagramme de cas d'utilisation de l'application

25


3.2.3 Interface utilisateur

En dé�nitive, l'interface utilisateur à développer se présentera de la même façon que la �gure15. La diapositive courante est a�chée. Le titre du scénario et le numéro de l'étape courantesont a�chés en haut à gauche de l'écran. Une souris peut également être a�chée pour pointerdes parties de la diapositive à l'enfant.

Figure 15 � Interface utilisateur proposée

La taille de la fenêtre est celle de la diapositive, en l'occurrence de 965x721 pixels, et lalargeur de l'agent conversationnel qui sera ajouté dans les versions suivantes. Il n'y a pas deplein écran de prévu ni de dé�lement horizontal/vertical. Les données utilisateurs seront entréessur le moniteur du composant TextComponent de la plateforme AgentSlang. Par la suite, uncomposant de reconnaissance vocale et visuelle pourra remplacer le TextComponent.

3.2.4 Diagramme d'activité

La �gure 16 décrit par étapes explicites et commentées les activités de l'application.

Figure 16 � Diagramme d'activité de l'application

26


L'intelligence arti�cielle de l'application se base, à chaque étape, sur la réaction de l'utilisa-teur 3. On catégorise et stocke les réactions dans deux types de �chiers : d'une part les réactionsque l'on quali�era de hors contexte, à savoir les réactions qui ne dépendent pas de l'étape danslaquelle nous nous trouvons 4 (�chier OutOfContext.xml), et d'autres part les réactions dépen-dant du contexte (à l'étape i, �chier Step_i.xml).

Ainsi, le �chier Step_i.xml comprend, pour chaque étape i, une liste de réactions spéci�quespour lesquels on dé�nit des réponses spéci�ques et une commande. Les motifs considérés peuventêtre tels que :

� les réactions amenant à l'étape suivante,� les réactions amenant la répétition de l'étape courante,� les réactions relatives à des réponses fausses,� les réactions vides, qui peuvent parfois permettre de passer à l'étape suivante.

3.2.5 Modèle par composants proposé

Figure 17 � Proposition de modèle d'intégration d'AgentSlang à ACAMODIA

Nous avons pu identi�er di�érentes étapes pour modéliser les interactions du psychologue, etnous avons tout d'abord proposé un Minimum Working Example (MWE) dont les composantssont décrits sur la Figure 17.

1. On considère se trouver à une étape i du scénario. La partie de l'histoire relative à l'é-tape i a été lue, et l'enfant réagit, dans un premier temps au clavier, grâce au composantTextComponent (Text) au clavier d'AgentSlang, et/ou oralement grâce au composantSpeechToTextComponent (SpeechToText), qui gère la capture audio et la transcriptionde la voix en texte. Le composant TextComponent pourra être remplacé par n'importe quelautre composant de capture et lecture audio, et/ou de vidéo conférence (développement icinon demandé).

2. Comme sur AgentSlang, le composant TextComponent publie un String.data. Celui-ciest reçu par le composant SennaComponent (Senna) qui l'annote puis publie un Anno-tated.data.

3. NB : après quelques secondes, une réaction peut être considérée comme e�ective ou comme vide, telleque, quelque soit les moyens d'acquisition (textuel/vocal/visuel), l'utilisateur ne laisse transparaître d'altérationtextuelle, orale ou visuelle.

4. Une réaction non comprise sera considérée comme une réaction hors contexte également.

27


3. L'Annotated.data est reçu par un nouveau composant : PatternMatchingComponent(PatternMatching). Il s'agit d'un composant de type Living. Il va traiter l'annotation de lafaçon suivante :� Il véri�e tout d'abord si l'annotation est reconnue parmi une liste de motifs attendus.Ces motifs sont classés suivant des catégories (<state>) (cf. listing 8). Chaque identi�antest lié à un ou plusieurs motifs (<lPatterns>), une ou plusieurs réponses (<lAnswers>),une commande (<command>) et un statut explicite déterminant vers quelle étape on sedirige (<next>).

<!−− Step_i . xml −−><s ta t e>

<lPat t e rn s>4 <pattern>oui ∗</pattern>

<pattern>j e peux l e [ vo i r ]</ pattern></ lPat t e rn s><lAnswers>

8 <answer>Bravo !</answer><answer>Tres bien</answer><answer>Je te f e l i c i t e</answer>

</ lAnswers>12 <command>command1</command>

<next>2<next></ s t a t e>. . .

Listing 8 � Exemple de stockage XML des motifs attendus, reponses et commandes

� Dans le cas où l'annotation est reconnue par un des motifs du �chier Step_i.xml, lecomposant :-> Soit appelle une étape suivante, le composant publie la réponse relative correspon-dante à l'étape i, et publie une donnée Command.data, commande relative au motif,bien souvent pour passer la diapositive suivante si c'est nécessaire. Il est potentielle-ment possible de passer à n'importe quelle étape pourvu que ceci soit noti�é par le<next>.

-> Soit reste sur la même étape, et dans ce cas on ne publie qu'une réponse correspon-dante.

-> En cas de non réaction, le silence sera considéré comme un motif e�ectif (ie. commeune réaction) suivant une période prédé�nie grâce à la méthode act du composant.

� S'il n'a pas trouvé de motif correspondant dans ce premier �chier, alors ceci signi�e quela réaction est hors contexte. On compare alors notre Annotated.data avec les motifs d'undeuxième �chier correspondant aux réponses "hors contexte". Ce �chier s'organise de lamême façon que le listing 8. Le créateur du scénario pourra ainsi exceptionnellementautoriser le passage à l'étape suivante. Dans tous les autres cas, il pourra répéter lescénario, proposer des pistes à l'utilisateur, lui demander de se concentrer, etc. sanspasser au scénario suivant.

� Quelque soit le type de réaction, le composant PatternMatchingComponent renvoie unString.data correspondant à la réponse proposée par le système.

4. Dans le cas ou une donnée Command.data est publiée, la méthode handleData() du com-posantHandleCommandComponent (HandleCommand) est lancée. Celui-ci coordonneles actions telles que les changements de diapositives, la lecture du script dialogique relatif àl'histoire et tous autres éléments interactifs suivant les besoins. Il est lié à une classe gérantl'interface graphique (uniquement a�chage des diapositives dans un premier temps). Lescommandes sont listées dans un �chier et sont spéci�ques à un identi�ant, donné par l'en-trée Command.data, comme le montre le listing 9. On note également que le processustellStory permet l'appel d'un autre �chier XML répertoriant le script global de l'histoire,script lu dans tous les cas lors des étapes i du scénario, suite à la réponse de l'agent auxréactions des utilisateurs.

28


<!−− Commands . xml −−><s ta t e>

<command>command 1</command>4 <lLaunches>

<launch>t e l l S t o r y 1</ launch><launch>changeTit l e Le ba l l on perche</ launch><launch>changeStepName Etape 1</ launch>

8 <launch>d i s p l a yS l i d e 1</ launch></ lLaunches>

</ s t a t e>. . .

Listing 9 � Exemple de stockage XML des commandes et de leurs actions

5. Le composant MaryComponent récupère la réponse publiée par PatternMatching-Component et/ou par le HandleCommandComponent et en crée un son, qui seraen�n lu par le TextComponent. Le composant MaryComponent peut être remplacé parun autre lisant des sons pré-enregistrés, ou encore par un agent conversationnel virtuel,comme ce fut le cas initialement avec le projet ACAMODIA.

6. En�n, on peut remarquer la publication de Command.data par le composant TextCompo-nent. Cette commande permet d'une part d'activer le composant de reconnaissance vocale,et d'autre part d'initialiser et lancer le chronomètre de reconnaissance de "non-réaction"du PatternMatchingComponent.

Les données pouvant être maintenues par de tierces personnes seront donc stockées et struc-turées dans des �chiers XML. Ainsi, on compte au total n �chiers (où n nombre d'étapes duscénario) décrivant les motifs dépendant du contexte (type listing 8), 1 �chier décrivant les mo-tifs hors contexte (type listing 8), un �chier de stockage de commandes (type listing 9), un �chierdécrivant le script du scénario à raconter étape par étape. Cette organisation permet de proposerun outil évolutif et incrémental.

3.2.6 Perspectives

L'application pourra être pourvue de tous les éléments non développés mais cités dans laspéci�cation fonctionnelle. De plus, il pourrait être intéressant de :

� Proposer une gestion et sauvegarde des entrées de l'enfant� Proposer une interface graphique pour la création de scénarios suivant le modèle proposéci-avant.

29

3.3 Conception 3 INTÉGRATION D'AGENTSLANG À ACAMODIA

3.3 Conception

Nous allons à présent expliciter les di�érents éléments développés durant la phase de concep-tion.

3.3.1 Organisation du projet

L'application utilise un certain nombre de données qui doivent être facilement accessibles parl'utilisateur. Ces données sont réparties comme le montre la �gure 18.

IntegrationAA : : data

commands

Commands.xml

outOfContext

OutOfContext.xml

slides

Slide1.png

...

steps

Step_1.xml

...

story

Story.xml

...

Figure 18 � Organisation des données éditables par l'utilisateur

On retrouve les �chiers XML dé�nis précédemment, ainsi que les �chiers images étant a�chéssur chaque diapositive (slide). A noter qu'il peut y avoir autant de �chiers slide et de step quenécessaire. On y trouve également les scripts permettant la génération automatique des données.

Le code source du projet se décompose quant à lui suivant les paquetages présentés en �gure19.

30


scr : : org.ACAMODIA_AgentSlang.integration

data

commands

CommandData

CommandState

CommandStates

patterns

PatternsState

PatternsStates

story

StoryState

StoryStates

GenericStates

inout

TextTerminal

TextToSpeechComponent

out

IntegrationJPanel

SlideFrame

process

HandleCommandComponent

PatternMatchingComponent

SpeechToTextComponent

String.data Command.data

String.data

String.data Command.data

String.data

Figure 19 � Organisation des sources du projet InsertionAA.

3.3.2 Paquetage data

Le paquetage data permet, comme son nom l'indique, de regrouper la gestion des données enprésence. La �gure 20 en présente ses classes.

La classe GenericData tout d'abord, est une classe générique initialisant l'acquisition dedonnées, à savoir l'ouverture des �chiers XLM. On récupère d'une part le nom du �chier, on créépar ce biais un nouveau Document (Jdom) et on initialise la racine XML. Le nombre d'étatsdans ce �chier est ensuite compté, et on initialise la liste des n÷uds correspondant à ces étatsdans une collection. Les autres méthodes sont spéci�ques au type de �chier, et sont implémentéesdans les classes étendant la classe GenericData.

Dans le paquetage commands, la classe CommandsState regroupe les éléments d'un étatlisté du type de ceux de Commands.xml (cf. listing 9) : la commande faisant o�ce d'identi�ant etune liste d'éléments correspondant à des processus à lancer. Cette classe les charge puis permetleur récupération de façon optimale. La classe CommandsStates a pour variable d'instanceune liste de CommandsState. Concernant les méthodes principales, une méthode permet de

31


retourner une CommandsState spéci�que, une autre permet de retourner une liste de processusrelativement à une commande. Ainsi, dans les cas où l'utilisateur a choisi de séparer une mêmecommande (même identi�ant) en deux listes de processus, ceux-ci seront tout de même touschargés. On compte également la classe CommandData dans ce paquetage, nouveau type dedonnées utile à la communication entre les composants PatternMatching et HandleCommand.

Figure 20 � Diagramme de classes du paquetage data

Le paquetage patterns regroupe les classes gérant des �chiers XML de type listing 8, à savoirdes Step_i.xml ou le OutOfContext.xml. La classe PatternsState implémente, relativement àchaque état, une liste de motifs, une liste de réponses, une commande et un entier correspondantà l'étape suivante. Cette classe permet leur initialisation, et leur récupération via des méthodesget. Une méthode permet également de véri�er si un des motifs est reconnu, et de retourner lesréponses qui s'y réfèrent, notamment via les méthodes des classes Matcher et TemplateMatchRe-sult de Syn !bad. La classe PatternsStates a pour variable d'instance une liste de PatternsState,qui rend ainsi exploitables les données entières du �chier. La méthode checkMatching e�ectueune véri�cation globale de ce qui est énoncé par l'utilisateur sur la base de données courante.Parmi la liste de réponses possibles retournées, une réponse est choisie aléatoirement.

32


En�n, le paquetage story regroupe les classes StoryState et StoryStates permettant l'accèsaux données de l'histoire stockées dans Story.xml. Ce sont de simples classes d'accès aux données,un scénario dé�ni par des étapes numérotées, décrivant la base de l'histoire.

3.3.3 Paquetage inout

Le paquetage inout regroupe les classes gérant à la fois des entrées et sorties interfacéesutilisateur (cf. �gure 21).

Figure 21 � Diagramme de classes du paquetage inout

Les classes TextTerminal et TextToSpeechComponent sont des copies des classes aumême nom du projet AgentSlang, à quelques modi�cations près. D'une part elles permettentl'empilement des entrées audio et leur lecture progressive a�n d'éviter l'écrasement d'une donnéeà lire lors d'une nouvelle arrivée d'audio. De plus, le composant TextToSpeechComponentpublie une commande dès réception d'une donnée du SpeechToTextComponent, a�n quece dernier relance la capture audio et que le PatternMatchingComponent commence le dé-compte de "non réaction".

3.3.4 Paquetage out

Le paquetage out montré �gure 22 regroupe les classes gérant les sorties interfacées utilisateur.

Figure 22 � Diagramme de classes du paquetage out

33


Tout d'abord, la classe IntegrationJPanel dé�nit l'a�chage global décrit en 3.2.3, ini-tialisant un panneau sur la droite a�chant la diapositive courante, un panneau sur la gauchedéterminant l'étape courante, et un emplacement libre pour la future intégration d'un agentanimé conversationnel. La classe SlideFrame permet le changement de certains de ses élémentssuivant les commandes décrites par le scénario, telles que displaySlide, changeTitle, tellStory,changeStepName, launch. On pourrait par ailleurs implémenter tout nouveau type de commandedans cette classe, tel que le fait de pointer un emplacement de l'écran avec une souris.

3.3.5 Paquetage process

Le paquetage process montré �gure 23 contient les composants décrits dans la section 3.2.5 àsavoir la classe PatternMatchingComponent, la classe HandleCommandComponent etla classe SpeechToTextComponent.

Figure 23 � Diagramme de classes du paquetage process

Noter que nous avons opté d'identi�er le motif de "non réponse" 5 par wxcvbn. Ainsi, si lecréateur du scénario souhaite, à partir d'une étape i, passer à une étape i+k, il devra ajouterdans le �chier Step_i.xml un état dont le motif est wxcvbn, avec les commandes et les étapeschoisies.

En�n, la classe SpeechToTextComponent appelle deux composants externes pour l'ac-quisition et le traitement des données vocales, le logiciel Sox [10] et le projet Java-Speech-API[11].

3.3.6 Tests unitaires

La majorité des méthodes développées étant de l'accès et/ou du traitement de l'information,nous avons développé des méthodes d'a�chage de données dans chacune de nos classes au coursdu développement. Celles-ci se sont avérées fonctionnelles et peuvent être à tout moment testéesvia un main a�chant ces données dans le terminal.

Le debugger du logiciel Intellij IDEA 12.1.4 s'est avéré également très utile et e�cace dansles phases de débogage des classes, et la résolution de problèmes annexes.

5. silence appuyé de x secondes, ou le fait de taper sur "Entrée" dans le TextTerminal avec une chaîne decaractères vide.

34

3.4 Saisie des données 3 INTÉGRATION D'AGENTSLANG À ACAMODIA

3.4 Saisie des données

La campagne de saisie de données du stage ici présenté repose sur di�érentes étapes :� La récupération de retranscriptions faites durant les expériences ACAMODIA avec lespsychologues et les enfants,

� La création d'une table globale répertoriant explicitement ces données, étant ensuite validéepar les maîtres de stages,

� L'entrée de ces données dans les �chiers XML pour un traitement par le logiciel développé.

3.4.1 Initialisation des �chiers de données, version 1

Nous avons développé un script bash, qui, suivant le scénario global de l'histoire classi�ée dansun �chier ou chaque ligne correspond à une étape du scénario, créé et initialise les �chiers Com-mands.xml, Story.xml et toutes les Steps_i.xml. Ces �chiers contiennent uniquement l'histoire,et non les motifs, commandes, etc. L'utilisateur doit rentrer "à la main" toutes ces informations.Nous avons ainsi décidé d'automatiser davantage cette procédure de génération, a�n de simpli�erl'accès aux données et leur gestion.

3.4.2 Initialisation des �chiers de données, version 2

Nous proposons la procédure suivante pour la génération automatique des données :

1. L'auteur doit tout d'abord dé�nir les étapes du scénario dans un �chier type listing 10,pour lequel une ligne correspond à une étape.

Bonjour , j e m' appe l l e Anne .Et to i , comment t ' a pp e l l e s tu ?Je s u i s t r è s contente de f a i r e ta conna i s sance

4 Quel âge est− ce que tu as ?

Listing 10 � Scénario A

2. Grâce à un script Bash fourni et au scénario précédemment créé, l'auteur génère ensuiteun �chier de type listing 11, correspondant à une base de données vide.

# ID ; Etape ; Moti f ; Ré ponse ; Commandes ; Suivant ;

1 ; Bonjour , j e m' appe l l e Anne . ; ; ; t e l l S t o r y 2 | ; 2 ;2 ; Et to i , comment t ' a pp e l l e s tu ? ; ; ; t e l l S t o r y 3 | ; 3 ;

4 3 ; Je s u i s t r è s contente de f a i r e ta conna i s sance ; ; ; t e l l S t o r y 4 | ; 4 ;4 ; Quel âge est− ce que tu as ? ; ; ; t e l l S t o r y 5 | ; 5 ;

Listing 11 � Base de données générée du scénario A

Il est composé de 6 champs par ligne : un identi�ant numéraire de l'étape, le texte devantêtre lu et correspondant à cette étape, le motif devant être reconnu ainsi que la réponsedevant être donnée suivant ce motif, un champ de commande(s) devant être séparées parle caractère "|", et en�n l'étape suivante correspondante.

3. L'auteur complète ensuite ce �chier suivant ses besoins comme montré dans le listing 12.Pour une même étape (dé�nie par son identi�ant id), il est possible d'avoir di�érents motifs,di�érentes réponses, di�érentes commandes .

# ID ; Etape ; Moti f ; Ré ponse ; Commandes ; Suivant ;

1 ; Bonjour , j e m' appe l l e Anne . ; ; ; t e l l S t o r y 2 | ; 2 ;2 ; Et to i , comment t ' a pp e l l e s tu ? ; $nom ; Bonjour $nom ! ; t e l l S t o r y 3 | ; 3 ;

4 2 ; Et to i , comment t ' a pp e l l e s tu ? ; $nom ; Sa lut $nom ! ; t e l l S t o r y 3 | d i s p l a yS l i d e2 | ; 3 ;

3 ; Je s u i s t r è s contente de f a i r e ta conna i s sance ; ; ; t e l l S t o r y 4 | ; 4 ;3 ; Je s u i s t r è s contente de f a i r e ta conna i s sance ;Moi au s s i ; ; t e l l S t o r y 4 | ; 4 ;4 ; Quel âge est− ce que tu as ? ; $age ans ; ; t e l l S t o r y 5 | ; 5 ;

Listing 12 � Base de données complétée par le créateur du scénario A

4. En�n, l'auteur exécute un dernier script Bash fourni qui génère les données suivant la basede données complétée, en respectant les spéci�cations précédemment rapportées.

35

3.5 Produit et améliorations 3 INTÉGRATION D'AGENTSLANG À ACAMODIA

3.5 Produit et améliorations

Le logiciel a été développé et testé suivant le scénario d'ACAMODIA et les retranscriptionsdes réactions des enfants traduites en anglais. En e�et, le module TextToSpeech et le dictionnaireWordnet d'AgentSlang n'est pour l'instant disponible qu'en anglais 6. Cependant, une base dedonnées française retraçant le scénario Le ballon perché et comprenant l'ensemble des retran-scriptions fournies par les psychologues a été préparée.

Figure 24 � Capture d'écran du logiciel en cours d'exécution - Interface

La �gure 24 montre le programme en exécution. On y voit les logs du chat vocal sur la gauche,la fenêtre principale au centre et la fenêtre de capture son sur la droite.

Un didacticiel vidéo de génération de données est également fourni pour les utilisateurs. Ildécrit comment créer, étape par étape, notre base de données suivant un scénario pré-dé�ni.Une autre vidéo montrant une session d'interaction avec le logiciel est également à disposition.Elle souligne notamment plusieurs exceptions pouvant être rencontrées : la non-réaction, la noncompréhension, l'utilisation de variables rendant l'échange plus interactif, et le fait de parler enmême temps que la lecture virtuelle courante.

Le projet développé pourra être quant à lui amélioré sans di�culté (étant donné le carac-tère objet de sa conception) consécutivement aux propositions données en 3.2.1 et 3.2.6. L'in-tégration d'un agent virtuel tel que Marc [9], la mise à jour régulière des données, et l'ajoutd'autres fonctionnalités interactives permettra de compléter l'objectif initial : reproduire l'ex-périence ACAMODIA de manière automatique, sans l'aide d'un contrôleur humain externe.

En�n, il faut noter que le programme pourra être réutilisé suivant tout autre type de scénario,pourvu que l'utilisateur prévoit, répertorie et classi�e les possibles réactions des utilisateurs. Dece fait, il pourrait être intéressant de rendre "intelligent" notre modèle en intégrant les réactionsalors non répertoriées de façon automatique, à chaque fois où elles se présentent. De plus, onpourrait doter l'outil d'un module de gestion de "mémoire", tel que, suivant chaque utilisateur,l'agent puisse à nouveau accéder à certaines données précédemment abordées avec celui-ci, etrépondre à ses réactions de manière optimale.

6. Un support français est en développement et est prévu pour une prochaine version.

36

Conclusion

Ce stage au sein du LITIS fut très enrichissant dans de multiples domaines. D'abord d'unpoint de vue humain, être intégré dans un laboratoire de recherche, avoir un suivi aussi com-plet et régulier est fructueux et permet d'être davantage productif. La grande disponibilité desmaîtres de stage m'a notamment permis de clari�er certaines de mes méthodes de travail, faitdécouvrir de nouvelles pistes ou solutions en terme de modélisation. Ce fut également l'occasionde revoir les notions de génie logiciel, de développement, et de souligner l'importance du dé-tail dans l'expression de rapport de projet. J'ai pu aussi découvrir l'environnement et le contenud'une section de thèse, puis comprendre et en assimiler des méthodologies spéci�ques s'y référant.

Concernant le thème de stage, le domaine des interactions homme/machine fut en grandepartie une découverte pour ma part. Les applications possibles m'ont grandement intéressées,car celles-ci ne se bornent pas uniquement à un projet spéci�que tel qu'ACAMODIA, mais peu-vent dans de nombreux autres cas être réutilisées.

En terme de résultats opérationnels, nous avons pu d'une part étudier l'agencement du projetAgentSlang grâce à des méthodes de reverse engineering, d'implémentations de tests, et d'expli-cations du concepteur, puis fourni une documentation en français de celui-ci. Nous avons ensuitedéveloppé un programme intégrant l'AgentSlang au projet ACAMODIA, suivant des spéci�ca-tions précises dé�nies avec les commanditaires. Tous les composants listés pour une interfaceACAMODIA complète n'ont pas pu être développés dans notre logiciel. Je regrette par exemplede n'avoir pu étudier le projet MARC et l'intégrer au programme. Toutefois, la modélisationproposée permet de tous les intégrer, ceci étant une des lignes de conduite du stage.

En�n, d'un point de vue plus personnel, ce stage m'a permis de prendre du recul sur mon pro-jet professionnel, notamment d'apprécier mes forces et faiblesses en terme de ré�exion ingénieuret application des méthodologies acquises, et qui plus est de renforcer ma volonté de centrer mesétudes et mon futur travail autour du domaine de l'informatique.

37

Table des �gures

1 Organigramme du LITIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 Développement d'ACAMODIA au LITIS . . . . . . . . . . . . . . . . . . . . . . . 73 Diagramme simpli�é des objets Data de MyBlock . . . . . . . . . . . . . . . . . . 84 Composant dé�ni dans MyBlock . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 Di�usion d'un message entre 2 composants . . . . . . . . . . . . . . . . . . . . . . 96 Scheduler ayant 2 composants abonnés sur di�érentes machines . . . . . . . . . . 107 Modélisation de l'exemple . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108 Emplacements Composants et Channels sur le Module MyBlock . . . . . . . . . . 169 Emplacements composants et channels sur la plateforme AgentSlang . . . . . . . 1710 Modèle d'interaction des composants du chatbot . . . . . . . . . . . . . . . . . . 2011 Diagramme de classes développé pour le Chatbot . . . . . . . . . . . . . . . . . . 2012 Clavardage sur le moniteur de texte du Chatbot . . . . . . . . . . . . . . . . . . . 2313 Interface graphique sur l'ordinateur du psychologue . . . . . . . . . . . . . . . . . 2414 Diagramme de cas d'utilisation de l'application . . . . . . . . . . . . . . . . . . . 2515 Interface utilisateur proposée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2616 Diagramme d'activité de l'application . . . . . . . . . . . . . . . . . . . . . . . . 2617 Proposition de modèle d'intégration d'AgentSlang à ACAMODIA . . . . . . . . . 2718 Organisation des données éditables par l'utilisateur . . . . . . . . . . . . . . . . . 3019 Organisation des sources du projet InsertionAA. . . . . . . . . . . . . . . . . . . 3120 Diagramme de classes du paquetage data . . . . . . . . . . . . . . . . . . . . . . . 3221 Diagramme de classes du paquetage inout . . . . . . . . . . . . . . . . . . . . . . 3322 Diagramme de classes du paquetage out . . . . . . . . . . . . . . . . . . . . . . . 3323 Diagramme de classes du paquetage process . . . . . . . . . . . . . . . . . . . . . 3424 Capture d'écran du logiciel en cours d'exécution - Interface . . . . . . . . . . . . 36

Liste des tableaux

1 Résumé des composants AgentSlang . . . . . . . . . . . . . . . . . . . . . . . . . 152 Liste des opérateurs proposés par Syn !Bad . . . . . . . . . . . . . . . . . . . . . . 18

Listings

1 Console.java (exemple d'utilisation des composants) . . . . . . . . . . . . . . . . 112 Test.java (exemple d'utilisation des composants) . . . . . . . . . . . . . . . . . . 123 cnsService.xml (exemple d'utilisation des composants) . . . . . . . . . . . . . . . 124 con�g.xml (exemple d'utilisation des composants) . . . . . . . . . . . . . . . . . . 135 Jarvis.java (extrait 1 - composant Jarvis) . . . . . . . . . . . . . . . . . . . . . . 216 Jarvis.java (extrait 2 - composant Jarvis) . . . . . . . . . . . . . . . . . . . . . . 217 Jarvis.java (extrait 3 - composant Jarvis) . . . . . . . . . . . . . . . . . . . . . . 228 Exemple de stockage XML des motifs attendus, reponses et commandes . . . . . 289 Exemple de stockage XML des commandes et de leurs actions . . . . . . . . . . . 2910 Scénario A . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3511 Base de données générée du scénario A . . . . . . . . . . . . . . . . . . . . . . . . 3512 Base de données complétée par le créateur du scénario A . . . . . . . . . . . . . . 35

Références

[1] Wordnet, grande base de données lexicales de la langue anglaise (noms, verbes, adjectifs etadverbes)http://wordnet.princeton.edu/.

[2] Projet Semaine, développement d'un agent conversationnel comprenant les signaux sociauxfaciauxhttp://www.semaine-project.eu/.

[3] Ovidiu �erban, Detection and Integration of a�ective feedback into distributed interactive sys-tems.Institut National des Sciences Appliquées de Rouen, Laboratoire d'Informatique de Traite-ment de l'Information et des Systèmes.Universitatea Babes

,-Bolyai, Facultatea de Matematic s

,i Informatic .

[4] Projet SENNA, logiciel non commercial de traitement automatique de langagehttp://ml.nec-labs.com/senna/.

[5] iSpeech Text To Speech, logiciel non commercial de synthèse vocalehttp://www.ispeech.org.

[6] JDOM, bibliothèque open source pour manipulation de �chiers XML en Javawww.jdom.org.

[7] ZeroMQ, bibliothèque pour les échanges de messages asynchroneshttp://www.zeromq.org/.

[8] GRETA, agent conversationnel personni�é en 3 dimensionhttp://perso.telecom-paristech.fr/~pelachau/Greta/.

[9] Multimodal A�ective and Reactive Characters, agent conversationnel de traitement et con-ception et d'interaction en temps réel avec des agents virtuels expressifs visuellement réalisteshttp://marc.limsi.fr.

[10] SoX, logiciel de traitement de son en ligne de commande.http://sox.sourceforge.net/.

[11] Java-speech-api, api java incluant capture, reconnaissance et synthèse vocale. Les servicesGoogle sont utilisés pour la synthèse et la reconnaissance vocale. Requiert une connexioninternet.https://github.com/The-Shadow/java-speech-api.

http://wordnet.princeton.edu/

http://www.semaine-project.eu/

http://ml.nec-labs.com/senna/

http://www.ispeech.org

www.jdom.org

http://www.zeromq.org/

http://perso.telecom-paristech.fr/~pelachau/Greta/

http://marc.limsi.fr

http://sox.sourceforge.net/

https://github.com/The-Shadow/java-speech-api

Intégration de Composants à un AgentConversationnel … · Conversationnel Animé ... de...

Documents

Transcript of Intégration de Composants à un AgentConversationnel … · Conversationnel Animé ... de...