Projet de Programmation GENERATEUR AUTOMATIQUE DE TEXTE II

Transcription

1 Projet de Programmation MÉMOIRE GENERATEUR AUTOMATIQUE DE TEXTE II Auteurs : Ahmed Mourhri Steve Messanga Bourara Mohamed Mohammed Yessin Neggaz Mamadou Aliou Diallo Superviseur : Julien Mercadal Client : Lionel Clément 2 Avril 2012

2 Remerciements On tient à remercier dans un premier temps, toute l équipe pédagogique de l unité d enseignement Projet de Programmation et les intervenants professionnels responsables de la formation et particulièrement Monsieur Philipe Narbel, pour avoir assuré la partie théorique de celle-ci. On remercie également Monsieur Lionel Clément pour l aide et les conseils apportés au cours du développement de ce projet. On tient à remercier tout particulièrement et à témoigner toute notre reconnaissance à Monsieur Julien Mercadal, pour l aide et les conseils qu il nous a apporté lors des différents suivis pour l élaboration de ce projet. 1

3 Résumé Ce projet contribue au développement de l une des branches du traitement automatique du langage naturel : la génération automatique de texte. En effet, le but ici est de concevoir un prototype GAT-2 qui, à partir d une base de données fixée, produira un texte linguistiquement correct et compréhensible par l utilisateur. Ce texte correspondra tout simplement à la traduction en langage naturel du résultat de la requête SQL associée à la question sélectionnée par l utilisateur.

4 Table des matières 1 Introduction et Présentation du projet Introduction Présentation du projet Étude de l existant GAT Le générateur de Cristal FOG Cahier des charges Besoins Fonctionnels Partie utilisateur Partie administrateur Partie système Besoins Non-Fonctionnels Performances Utilisateurs et facilité d utilisation Robustesse Diagramme des cas d utilisation Scénario Architecture logicielle Composition du système Diagrammes de classes Diagramme de séquences Description de l implémentation L implémentation du générateur de syntaxe profonde (Prolog) Définition de la forme de la configuration (Administrateur) Définition du langage de configuration et l interpréteur Création d un prototype Configuration de la base de données et implémentation du gestionnaire des requêtes Gestion de la configuration Exceptions Interface graphique Difficultés

5 6 Tests Tests Unitaires DbConnection CommonRulesFile RequestsRulesFile PrologInterpreter Syntax GatText Tests de performance Tests de profil d exécution Conclusion 44 8 Annexe Prolog Unification Configuration, Interprétation et résultat

6 Chapitre 1 Introduction et Présentation du projet 1.1 Introduction Depuis l apparition des ordinateurs après la Deuxième Guerre mondiale, ces derniers ont peu à peu envahi notre quotidien à tel point qu ils sont devenus des interlocuteurs incontournables et communiquent sans cesse avec les utilisateurs. Au fil des années, les hommes ont ainsi trouvé qu il serait plus judicieux que ces derniers puissent leur parler dans leur propre langage. Un des exemples qui pourrait illustrer ce propos est la génération de messages préenregistrés dans les ordinateurs au moment adéquat. Un ordinateur a désormais la capacité de communiquer avec l utilisateur via un message d avertissement compréhensible lorsque sa batterie est bientôt à plat par exemple. Quoi de plus intéressant que de donner la capacité à l ordinateur de répondre intelligemment, correctement et surtout de façon compréhensible à toute demande utilisateur? Pouvons-nous ainsi donner la parole aux ordinateurs pour qu ils puissent s exprimer de façon contrôlée comme des humains? La génération automatique de texte (GAT) est une des branches du traitement automatique du langage naturel (TALN). Elle consiste en un système informatique qui produit un texte en langage naturel, compréhensible pour l utilisateur, à partir d une entrée (ensemble de données brutes) dont le domaine a été préalablement défini. Cette technique est principalement vue comme une solution qui permet de répondre aux problèmes concernant les tâches répétitives et fastidieuses. Les domaines d intervention de la génération automatique de texte sont de ce fait particulièrement divers et variés. On la retrouve notamment dans les systèmes de prévisions météorologiques, la génération massive de courriers dans les entreprises ou encore la génération de résumés textuels de rapports médicaux à partir de descriptions numériques et graphiques. Cette technologie est donc particulièrement adaptée dans les milieux industriels. Les premiers travaux en terme de génération automatique de texte ont été réalisés dans le cadre de la traduction automatique de texte, un domaine où l absence de systèmes de génération serait impensable, tout comme le résumé automatique, la simplification des textes ou encore les applications de dialogue entre l homme et la machine. 3

7 Mais on pourrait se poser la question suivante : pourquoi s intéresse-t-on précisément à la génération de texte? Les textes sont des objets relativement complexes à mettre en œuvre. Ils se décrivent comme étant des canaux de communication entre un ou plusieurs émetteurs et un ou plusieurs récepteurs. La transmission de l information dans ces passerelles communicatives peut se faire à sens unique (livres, exposés) ou à plusieurs sens (dialogues entre plusieurs intervenants). Par définition, un texte est composé d un ensemble de phrases. Une phrase quant à elle s articule autour d un ou plusieurs contextes qui déterminent son sens. L ordre de ces contextes est ainsi déterminant dans la détermination du sens de la phrase et du sens du texte par la même occasion. Une rédaction bien structurée utilisant un style clair et adapté constitue une tâche qui s avère souvent être très complexe. En effet, il est primordial de respecter les règles de grammaire et de morphologie. Cette aptitude s acquiert avec l expérience en étant à l écoute de son environnement, que ce soit par des cours, ou même en assistant à des auditoires ou à des spectacles. Le principal problème de la génération automatique de texte repose cependant sur la taille et le domaine des entrées qui peut varier d une application à une autre. En effet, cette génération peut s effectuer à partir d un large éventail de données divers. Mais il n est cependant pas possible de pouvoir tout dire. Chaque application qui génère du texte fonctionne autour d un thème choisi pour réduire le nombre de données. C est pourquoi le problème de la génération de texte est avant tout un problème de choix [Danlos et Roussarie, 2000]. Ceci explique donc le fait que cette technologie ne connaisse pas un succès flamboyant dans le marché des applications logicielles, ainsi qu un réel intérêt dans le domaine de la recherche, contrairement à l analyse de texte. En effet, celui-ci diffère de la génération de texte dans la mesure où la structure donnée en point d entrée (une phrase voire un texte écrit en langage naturel) est d ores et déjà définie. Dans la génération, il est possible d avoir des entrées de nature très variée telles qu un ensemble de données brutes issues d une base de données, une suite de déductions logiques, des données numériques ou graphiques Présentation du projet L objectif de ce projet est de concevoir un prototype intitulé le générateur automatique de texte 2 (GAT-2) qui aura la tâche comme son nom l indique, de produire automatiquement des textes dans un domaine très restreint, où l information sera issue d une base de données. Après une phase de concertation, nous avons choisi de partir d une base de données contenant des informations sur les étudiants du Master 1 informatique de Bordeaux 1, leurs résultats et la gestion des emplois du temps. Les informations extraites de la base de données constituent des données brutes qui ne peuvent pas être exploitées pour générer du texte. Il va donc falloir les étudier dans un premier temps puis les interpréter, en utilisant des représentations dites sémantiques et des représentations dites syntaxiques. Ce prototype utilisera notamment le générateur automatique de texte 1 (GAT-1), un générateur de phrases, qui a été conçu l année dernière et qui sera fourni 4

8 par le client. Nous allons ici sortir du cadre principal de la génération automatique de texte qui est de libérer le quotidien de l être humain des tâches répétitives. Le principe ici sera de faire croire à de l intelligence en donnant à l ordinateur la capacité de dire quelque chose en réponse à une demande utilisateur sur le thème de la base de données. La conception du générateur automatique de texte2 est centrée, comme pour tout système similaire GAT, autour de deux principaux axes qui sont Quoi dire et Comment le dire. Répondre à la question Quoi dire consiste à filtrer dans un premier temps les données contenues dans la base de données qui seront ensuite étudiées puis interprétées dans le but de produire le texte. En effet, il serait relativement complexe, voire impossible, de concevoir un logiciel capable de tout dire en même temps. Il est donc important de se fixer un sens et de séparer les informations essentielles de celles qui ne le sont pas. Cette partie a donc pour rôle de déterminer le contenu informatif du texte généré. Elle est également déterminante pour la qualité de ce dernier et aboutit à une représentation logique de la phrase, organisée autour d un concept. La notion de représentation sémantique sera ainsi abordée. La prochaine étape consistera à passer de cette représentation logique en un texte écrit dans le langage de l utilisateur. Ce texte devra être agréable à lire pour l utilisateur dans le sens où il devra notamment respecter les règles aussi bien grammaticales que de morphologie. Réponde à la question Comment le dire consiste maintenant à donner une forme textuelle à la représentation logique issue de la partie quoi dire. Le sens de la phrase à générer a été fixé à partir de la représentation sémantique. Il s agit donc dans un premier temps d effectuer une traduction du sens vers la syntaxe. Le travail consiste donc à élaborer le texte à générer en définissant les différents champs de la phrase. On passe ainsi du sens de la phrase à la syntaxe. Cela implique nécessairement des connaissances syntaxiques. Cette phase fera ensuite appel au générateur automatique de texte 1 pour générer le texte à partir de la syntaxe obtenue. Enfin, il serait envisageable par la suite de combiner plusieurs branches du traitement automatique du langage naturel au sein du prototype. En plus de la faculté de générer automatiquement des textes, le prototype pourrait également synthétiser la parole à partir du texte généré. 5

9 Chapitre 2 Étude de l existant De nos jours, les ordinateurs font intégralement partie de notre quotidien et sont même devenus de véritables interlocuteurs fiables. Quoi de plus utile pour nous que de leur donner la capacité de s exprimer correctement grammaticalement et de façon intelligente dans notre langue? On donnerait ainsi à l ordinateur le pouvoir de produire du texte en langage naturel, c est à dire compréhensible par l utilisateur. La génération automatique de texte est un domaine en cours d exploration dans la mesure où il suscite encore aujourd hui un engouement de la part de la recherche et il intervient également dans de nombreux systèmes variés. Nous allons voir qu à travers cette étude de l existant, le fonctionnement de la quasi-totalité des applications utilisant la technologie GAT est axé sur le Comment le dire, contrairement au générateur de texte II qui devra prendre en compte le Quoi dire.enfin, toutes ces applications ont une part de contribution dans la compréhension du projet GAT-2 ainsi que sa conception. 2.1 GAT-1 Le générateur automatique de texte 1 (GAT-1) est un prototype que nous aurons à notre disposition dans le cadre de ce projet. En effet, ce logiciel nous sera fourni par notre client pour ensuite être utilisé en tant qu étape finale dans le scénario du générateur automatique de texte 2. Concernant l historique, une première version de GAT-1 a été conçue par un groupe d étudiants de Master 1 informatique de l Université Bordeaux 1, dans le cadre de l unité d enseignement Projet de Programmation. Une deuxième version améliorée et optimisée, qui s intitule désormais Synthox, a été élaborée par le client. Le générateur automatique de texte 1 fonctionne sur la partie Comment le dire de la génération automatique de texte. En effet, l entrée du logiciel qui représente une structure syntaxique profonde décrivant une phrase quelconque est déjà figée. Le Quoi dire est d ores et déjà établi avant même l utilisation du logiciel. En effet, le logiciel prend en entrée des règles de grammaire, un lexique propre au domaine d application du logiciel et enfin une représentation syntaxique du texte à générer. À partir de cette 6

10 structure syntaxique donnée en entrée, une série d opérations linguistiques ont lieu afin de générer le texte en sortie. Ce dernier devra être compréhensible et grammaticalement correct. On note ainsi l absence de travaux sur la représentation sémantique précédant la représentation syntaxique. 2.2 Le générateur de Cristal Le générateur de Cristal est une application développée par l équipe de l enseignantchercheur Laurence Balicco à l université Stendhal-Grenoble 3. Il s agit d un générateur de texte en français dont le principe de fonctionnement repose sur la traduction d un contenu sémantique en forme linguistique. Cette traduction permet ainsi la génération de plusieurs versions équivalentes d un même contenu sémantique. En effet, les ressources linguistiques constituent un domaine relativement vaste dans la mesure où il est possible d exprimer la même chose différemment en français comme dans n importe quelle autre langue. Il existe plusieurs façons de formaliser sous forme textuelle un sens précis. Cet outil est indépendant de toute application et est implémenté en Prolog, un langage de programmation logique particulièrement adapté dans l analyse du langage naturel. Tout comme le générateur de texte 1, le générateur de cristal est un logiciel qui fonctionne sur la partie Comment le dire de la génération automatique de texte. La représentation sémantique du contenu est en effet figé d entrée. Ce générateur de texte utilise en plus de ce dernier des ressources linguistiques telles qu une grammaire et un lexique propre à chaque application. 2.3 FOG FOG est un système de prévisions météorologiques développé par CoGenTex. Son fonctionnement se base sur celui d un générateur automatique de texte dans la mesure où il prend en entrée une description graphique et numérique du temps et retourne un résumé textuel présentant les prévisions météorologiques en langues françaises et anglaises. Ce type de logiciel permet ainsi de libérer l utilisateur des tâches assez répétitives qu est la rédaction des bulletins météorologiques à partir de données graphiques et numériques. Ainsi, le système FOG a la capacité de s exprimer comme tout humain dans un langage naturel en exploitant des données informatisées qui se révèlent être inexploitables. Encore une fois, seule la partie Comment le dire est exploitée dans ce système dans la mesure où FOG prend en entrée une série de données numériques et graphique en relation avec la météorologie. Le domaine d application du contenu est donc déjà fixé. 7

11 Chapitre 3 Cahier des charges Notre projet constitue le développement d une partie d un large système de génération de texte. L analyse des besoins sera donc limitée à la partie nous concernant. La seule contrainte sera que le système ait la connaissance de la banque d informations sur laquelle il lui sera demandé de générer du texte. Dans notre cas, nous nous appuierons sur une base de données contenant des informations sur les étudiants du Master 1 informatique de l université de Bordeaux 1. Pour mener à bien notre projet, nous avons établi un certain nombre de besoins répartis en besoins fonctionnels et en besoins non fonctionnels. 3.1 Besoins Fonctionnels L objectif de ce projet est de concevoir un logiciel permettant la génération de texte à partir de données brutes récupérées depuis une base de données. Le logiciel est destiné à deux types d utilisateurs, l utilisateur simple et l utilisateur administrateur Partie utilisateur Dans le souci de rendre notre logiciel plus accessible, nous ferons en sorte que l utilisateur puisse accéder aux fonctionnalités du système via une interface graphique utilisateur. Il pourra donc effectuer diverses opérations telles que présentées ci-dessous. Sélection d une phrase écrite en français portant sur le domaine de connaissance permettant d orienter le générateur sur le type d informations à générer. Une fois la sélection faite, il aura en sortie un texte en français dont le contenu est en adéquation avec la phrase choisi par l utilisateur. Enregistrement du texte dans un fichier au format PDF, qu il nommera lui même. Le résultat doit pouvoir être transformé en une parole en activant la synthèse vocale Partie administrateur Le rôle de l administrateur est de configurer le système dans le but de rectifier certaines anomalies ou d y effectuer des mises à jour afin de mieux répondre aux besoins utilisateurs. Pour faciliter le travail de l administrateur, le système met à sa disposition 8

12 une interface graphique administrateur accessible par authentification. L administrateur doit pouvoir : Visualiser les phrases telles qu elles seront vu par l utilisateur, les modifier, les supprimer ou en rajouter. Visualiser les requêtes SQL correspondantes à chaque question, les modifier ou en rajouter. Visualiser les règles sémantiques des différentes questions, les modifier ou en rajouter. Visualiser le texte à générer telle qu il sera vu par l utilisateur afin de vérifier s il répond aux attentes et dans le cas échéant, y remédier en essayant de voir si l erreur provient d une faute de syntaxe, d un concept mal attribué ou bien d une requête SQL mal implémenté. Visualiser les règles générales permettant d apporter plus d informations au concept sémantique en rajoutant des entités. Visualiser les règles syntaxiques donnant la représentation en syntaxique profonde du sens. Actualiser les règles générales ou syntaxiques pour récupérer la version de la dernière mise à jour effectuée au cas où il effacerait par erreur l une des règles. Effectuer les mises à jour des différentes modifications effectuées. Modifier la configuration de la base de données ou la changer en indiquant l URL de l endroit où se trouve la nouvelle base avec le nom de l utilisateur et le mot de passe associé. Modifier la configuration du générateur automatique de texte 1 (Gat-1) en indiquant le chemin menant à l endroit où se trouvent les fichiers contenant la grammaire,le lexique et la postédition Partie système La partie système contient les besoins fonctionnels suivants : Donner à l utilisateur simple et l administrateur une interface pour pouvoir accéder aux différentes fonctionnalités. Récupérer à partir du fichier de configuration la liste des requêtes et leur description pour pouvoir les mettre à la disposition de l utilisateur. Garder la configuration des requêtes, la configuration syntaxique et générale dans des fichiers de configurations ainsi que les paramètres de fonctionnement comme la configuration GAT-1 et la base de données. Donner à l administrateur une syntaxe de configuration. Mettre à jour, après des modifications, les fichiers de configuration. Récupérer au démarrage les configurations dans des structures manipulables par le système. Interagir avec la base de données : Se connecter à la base de données. Récupérer la table correspondante à la requête depuis la base de données, en envoyant la requête après toute demande de la part de l utilisateur. 9

13 Les données résultantes sont sous forme de table, le logiciel doit pouvoir mettre ces dernières dans une structure adaptée aux modifications. Interpréter les relations de la table et les règles écrites par l administrateur dans les configurations chargées, en des règles et structures manipulables. Les règles syntaxiques et générales doivent être communes à toutes les configurations des questions proposées aux utilisateurs. Les règles doivent être écrites séparément dans des fichiers différents (la configuration syntaxique, générale dans deux fichiers différents et les règles sémantiques dans le fichier de configuration des requêtes). Créer à partir de la table des relations sémantiques utilisables par les règles sémantiques pour fournir du sens. Créer à partir des règles sémantiques et les données de la table une structure de dépendance (graphe) sémantique formant le sens du texte à générer. Créer à partir des règles syntaxiques des règles de traduction permettant le passage du sens à une syntaxe profonde exploitable pour la création du texte. Mettre la structure syntaxique profonde dans une forme acceptable par le générateur automatique GAT-1. Interpréter les règles générales et les mettre dans une forme compatible pour pouvoir s en servir lors de la génération. Avoir un outil pour la manipulation des graphes et des relations logiques. Un graphe sémantique est formé de nœuds qui sont les informations extraites de la base de données et des informations rajoutées en utilisant des règles logiques rajoutant du sens au concept, les arrêtes entre les nœuds étant les liens sémantiques donnant un sens a la structure. Une structure syntaxique profonde est formée de nœuds contenant des données du graphe sémantique ainsi que d autres données rajoutées par les règles syntaxiques pour avoir une information complète permettant de générer un texte compréhensible. Le graphe sémantique peut donner plusieurs façons de dire les choses, d où plusieurs graphes syntaxiques. Le logiciel doit pouvoir faire face aux différentes ambiguïtés. Pouvoir interagir avec le générateur de phrases GAT-1. passer la structure syntaxique profonde à GAT-1 pour générer du texte, et pouvoir récupérer le résultat. Afficher le texte généré sur l interface utilisateur. Pouvoir produire, à partir du texte, un fichier PDF pour l enregistrement des données. Mettre le résultat de l opération dans un fichier choisi par l utilisateur. Pouvoir générer de la parole à partir du texte final, en passant le texte à un module de synthèse vocale. Pouvoir gérer les exceptions possibles : Ne pas laisser de bugs se propager dans le système. Récupérer une exception et connaître son type. Utilisateur simple : Générer un message d erreurs disant simplement qu il y a une erreur dans la génération. 10

14 Administrateur : Générer des messages d erreurs pertinents permettant à l administrateur de localiser l erreur. Pouvoir récupérer quand c est possible le déroulement de processus après une exception. 3.2 Besoins Non-Fonctionnels Le générateur automatique de texte 2 est destiné à des utilisateurs qui souhaiteraient obtenir des réponses pertinentes à des questions en rapport avec les étudiants de master 1 informatique à Bordeaux 1. Ce prototype devra donc comporter un certain nombre de qualités Performances Le prototype à réaliser est un générateur d objets relativement complexes à mettre en œuvre : les textes. Celui-ci peut être vu par l utilisateur comme une forme d intelligence artificielle qui, à partir d une question associée à une requête SQL, lui renvoie une réponse syntaxiquement correcte, la plus claire et la plus précise possible. De l extraction des données brutes stockées dans la base de données jusqu à la génération du texte en réponse, on dénombre un nombre important d étapes à réaliser. Le générateur automatique du texte 2 devra entre autres se servir du prototype existant, le générateur automatique de texte 1, qui jouera dans ce cas présent le rôle d un générateur automatique de phrases. Celui-ci transforme en effet une structure syntaxique profonde en un texte lisible et compréhensible, en utilisant un lexique et un ensemble de règles de grammaire. Cette dernière étape s exécute avec un temps moyen de 0.15 seconde (cf GAT-1). En tenant compte de tous ces facteurs, nous pourrions estimer un temps d exécution du prototype ne dépassant 1 minute Utilisateurs et facilité d utilisation Le générateur automatique du texte 2 doit cibler un public d un âge mûr et assez expérimenté tel que les étudiants, les professeurs ou encore le personnel administratif de l université Bordeaux 1. Ces personnes n ont pas toutes forcément de grandes connaissances en informatique d où l importance que l interface graphique proposée par le prototype soit ergonomique. La totalité de son contenu visuel mise à la disposition de l utilisateur doit eneffet être compréhensible. Ces personnes ciblées n utilisant pas forcément les mêmes systèmes d exploitation, il serait problématique de contraindre le choix de l utilisateur sur le système à utiliser. Le prototype doit donc pouvoir s exécuter sur les principaux systèmes d exploitation tels que Linux et Windows pour satisfaire tous ses potentiels utilisateurs. 11

15 3.2.3 Robustesse Le système doit faire face à tous les bugs et doit afficher un message pour informer l utilisateur ou l administrateur. Pour l utilisateur simple, le message doit être le même quelque soit le type d erreur renvoyée. Le message doit juste mentionner qu il y a eu un problème lors de la phase de génération du texte. Pour l administrateur, la seule personne habilitée à pouvoir apporter des modifications systèmes, le message doit pouvoir préciser le type de l erreur. 3.3 Diagramme des cas d utilisation Ce diagramme présente entre autres les fonctionnalités générales offertes par le système aux différents utilisateurs que sont l administrateur et l utilisateur. Figure 3.1 Diagramme des cas d utilisation 12

16 3.4 Scénario Notre programme, comme mentionné précédemment, doit générer un texte à partir des fichiers de configuration édités par l administrateur. Pour se faire, le processus doit passer par plusieurs étapes : Chargement de la configuration syntaxique et générale. Chargement de la configuration de la base de données. Chargement de la configuration pour la génération du texte à partir de la structure syntaxique profonde, à partir des fichiers contenant la grammaire à utiliser, le lexique et la postédition. Selon la demande de l utilisateur pour la génération, chargement de la configuration correspondante à la phrase choisie par l utilisateur. Récupération de la table en envoyant la requête de la configuration. Production à partir de la table, des relations sémantiques à partir des règles syntaxiques des règles de traduction (Sémantique vers Syntaxique) et à partir des règles sémantiques des graphes sémantiques permettant de donner un sens et d utiliser les bons résultats de la table. Génération de la structure syntaxique profonde après l appel de la règle de traduction Envoi de la structure syntaxique profonde au générateur de phrase (GAT-1) pour obtenir un texte. Figure 3.2 Déroulement général du processus de la génération 13

17 Chapitre 4 Architecture logicielle L architecture est composée de cinq packages plus la partie Prolog, correspondant aux différentes parties du programme. Chaque package contient des classes qui assurent le fonctionnement du processus associé. Cette structure est faite pour une question de modularité et de ré-utilisabilité. Vu que notre système est composé de parties de différente nature et interagie avec des systèmes externes (SQL, Prolog, GAT1), il est nécessaire de rendre la structure modifiable en touchant au minimum de classes. Par exemple, si l on veut changer la base de données pour utiliser une autre qui n est pas SQL, il suffit de changer la partie qui s en occupe, même chose pour les autres parties Prolog, la gestion de configuration (parsers, writers) et le générateur GAT Composition du système Le système est composé de trois grandes parties dont une partie pour la gestion des configurations et des demandes utilisateur, une partie responsable de la génération d une structure syntaxique profonde à partir des concepts sémantiques et les données résultantes de la requête de la base de données et enfin une autre partie, un interpréteur, qui lie les deux premières parties en donnant à partir des configurations de l administrateur le résultat de la base de données,les informations et les instructions nécessaires à la deuxième partie qui s en sert pour la génération. La première partie se compose essentiellement des parties suivantes : Partie principale gérant l ordonnancement du processus. Générateur de tables (gestion de la base de données). Partie de gestion de la configuration. Cette partie s occupe du chargement et de la modification des configurations à partir des fichiers édités par l administrateur. Générateur de phrases (à partir d une structure syntaxique profonde), qui utilise un synthétiseur (GAT1). Cette partie permet de gérer la connexion au serveur de génération et la récupération du texte après l envoi de la requête (structure syntaxique profonde + grammaire + lexique + postédition). 14

18 La deuxième partie se constitue : d une partie définissant les relations représentant les résultats de la base de données. d une partie contenant des règles générales (logique). d une partie qui contient les concepts sémantiques. d une partie permettant le passage de la sémantique vers une structure syntaxique profonde. d une partie gérant les structures de données et leur manipulation. d un moteur Prolog qui se sert de ces parties et des règles définies pour la génération. L interpréteur : Il s agit de la partie qui s occupe de la traduction de la table résultante et des règles mises par l administrateur (écrites dans un langage spécial) en des graphes sémantiques et des règles de générateur de structure syntaxique profonde. 15

19 Figure 4.1 Composition système Figure 4.2 Légende 16

20 4.2 Diagrammes de classes 17

21 Figure 4.3 Diagramme de classe 18

22 Interface Gat2 : Cette interface offre toutes les fonctionnalités du programme vu par l utilisateur. Classe GatText : Il s agit de la classe principale qui s occupe de la gestion du processus et de l ordonnancement des tâches. Cette classe implémente l interface Gat2 qui donne une vue du programme de l extérieur. Elle fournit également toutes les méthodes nécessaires pour les demandes de l utilisateur et de l administrateur. L interface graphique où un autre programme n utilise de l extérieur que cette classe et ConfigLine. Classe ConfigLine : Une instance de cette classe contient la configuration associée à une requête (phrase, requête base de données et règles sémantiques). Classe RequestsRulesFile : Une instance de cette classe est utilisée pour lire les fichiers de configuration des requêtes, et y écrire du contenu. Classe CommonRulesFile : Un objet de cette classe est utilisé pour lire et écrire dans les autres fichiers de configuration, pour charger et modifier cette dernière. Interface DbConnectionItf : Cette interface offre les fonctionnalités pour la gestion de la connexion à la base de données. Classe DbConnection : Cette classe qui implémente l interface DbConnectionItf gère la connexion à la base de données. Classe Syntaxe : Cette classe assure l ordonnancement de tâches d interprétation et l interaction avec Prolog pour la récupération de la structure syntaxique profonde. À chaque requête de génération, elle prend la table SQL associé et la règle sémantique pour demander à l interpréteur de lui construire les prédicats Prolog, puis demande à ce dernier (en passant par Linux, via la règle de demande crée lors de l interprétation de la règle sémantique) de fournir la structure syntaxique profonde. Interface Interpreter : Cette interface offre les méthodes pour l interprétation des règles mises par l administrateur et la tables en des règles acceptables par Prolog et des relations logiques. Classe PrologInterpreter : Cette classe qui implémente l interface Interpreter permet d interpréter les règles pour générer le code Prolog. Interface Gat1 : Cette interface donne les méthodes nécessaires pour l interaction avec le générateur GAT1. Classe GatSynthesiser : Cette classe implémente l interface GAT1, gère la connexion au serveur GAT1 et la récupération du texte généré selon la configuration mise par l administrateur (il y a une configuration par défaut enregistrée dans les fichiers de configuration). 19

23 4.3 Diagramme de séquences Au démarrage du système, les configurations sont chargées à partir des fichiers de configuration syntaxique, générale et le fichier de configuration des requêtes, via des objets des classes RequestRulesFile et CommonRulesFile. Puis des objets Interpréter, DbConnection et Gat1 sont créés et les règles syntaxiques et générales sont interprétées en appelant les méthodes de PrologInterpreter addgeneralerules() et addsyntacticrules(). À la demande d une génération, suivant le numéro de la requête choisie, la requête SQL est extraite de la configuration (ConfigLine associé) et une table SQL est générée en demandant à DbConnection. Une fois la table récupérée, elle est passée avec les règles sémantiques (extraites de la configuration) à Syntaxe qui les passe à sont tour à PrologInterpreter pour les interpréter. Après l interprétation, Syntax demande à Prolog de s exécuter avec une consultation des fichiers créés à l interprétation. Le résultat est ainsi renvoyé après l appel à la règle Prolog getsyntaxstruct (défini dans le fichier result.pl). La structure syntaxique profonde est donnée ensuite au synthétiseur (Objet de type Gat1) via la méthode generate() qui récupère le texte final en envoyant au serveur une requête post. 20

24 Figure 4.4 déroulement du démarrage 21

25 Figure 4.5 déroulement du processus de la génération 22

26 Chapitre 5 Description de l implémentation Vu que notre système est composé de plusieurs parties avec chacune un rôle affecté, on à conclu que le langage à utiliser pour l implémentation doit être modulaire. La dépendance entre les parties et le passage des informations entre les différents composants nous impose un langage orienté objet. On a choisi donc Java pour sa compatibilité avec Prolog et son style adapté pour la manipulation des structures. Pour la partie concernant la génération de la structure syntaxique, on a trouvé que la programmation logique est la plus adaptée pour la sélection du contenu et le passage du sens à une syntaxe profonde. Ce genre de programmation donne une efficacité et une simplicité qu on ne trouve pas dans la programmation impérative ou objet. Après une étude comparative sur plusieurs langages de programmation comme LISP, Prolog (programmation logique) et CamL, nous avons conclu que Prolog fut le plus adapté. Le choix des informations de la table et la traduction du sens en une syntaxe peuvent se faire en définissant des règles logiques et des faits élémentaires donnant une souplesse et une simplicité contrairement à la définition d une suite d instructions. Prolog peut en effet faire moins de choses, mais plus simplement. Cette forme de programmation se base sur le quoi plutôt que le Comment. Prolog offre aussi,grâce à sa syntaxe simple et adaptée, et son moteur d inférence, une efficacité et une facilité. La sémantique fait partie du domaine de la logique et de la linguistique de la programmation. Initialement, Prolog est créé de la volonté d automatiser le raisonnement humain, en utilisant la logique. Vu que nous n avons jamais utilisé le langage Prolog, une initiation a été faite pour apprendre les fonctionnalités de base. 5.1 L implémentation du générateur de syntaxe profonde (Prolog) Comme première phase, on a commencé à implémenter un programme en Prolog qui, à partir d un concept avec des entités, génère une syntaxe profonde associée. Les gram- 23

27 maires permettant la génération étaient fixes dans le programme et les essais se faisaient en changeant des parties du programme représentant les règles de traduction qui utilisent la grammaire de génération et des prédicats représentant les relations (base de données). Cette phase a été abordée en premier pour avoir une idée de la configuration et de sa syntaxe, qu on peut donner a l administrateur et pour assurer le bon déroulement de l implémentation (on ne peut pas s engager dans une implémentation utilisant un moteur Prolog pour la génération sans réussir à l implémenter). Après que nous ayons réussi à mettre en place un générateur de syntaxe profonde, on devait lier celui-ci à l autre partie du système en créant un interpréteur (décrit après) rendant la génération plus dynamique. Le rôle de cet interpréteur est de donner à l administrateur un langage pour l écriture de la configuration et convertir cette dernière pour obtenir les règles logiques et les faits correspondants que Prolog utilise pour la génération. Les fichiers Prolog : Des fichiers sont définis contenant des prédicats logiques et des fonctions utilisées lors de l exécution de Prolog pour pouvoir manipuler les règles du programme générées par l interpréteur. Fichier list.pl : Ce fichier contient les prédicats essentiels pour la manipulation des listes (concaténation, appartenance... ), la manipulation des listes utilisée des fois dans le passage du sens à la structure syntaxique profonde parce que les grammaires DCG génèrent des listes d atomes et non pas des chaînes de caractères. De plus, la modification des structures et les données syntaxiques profondes avant d être affichées et basées sur la manipulation des listes. Fichier print.pl : Ce fichier contient des prédicats pour l affichage ou la conversion des structures générées en des chaînes de caractères exploitables par GAT1 et GAT1, il contient aussi des prédicats permettant la transformation d autres structures particulières en des structures générales ou une conversion de type comme tointeger qui permet la transformation d une chaîne de caractère en un entier, par exemple. Une demande d un nombre génère de la base de données une table qui est transformée en des relations sémantiques qui contiennent les résultats, dans l exécution à la demande, la règle sémantique demande le nombre à partir de la relation sémantique qui renvoie un atome (ex : 108 ). Si l utilisateur veut générer une information comme plus grande ou plus petite en utilisant le résultat tel qu il est généré, la comparaison échoue ; pour cela il doit indiquer dans la règle générale utilisée que le résultat extrait doit être converti en un entier en appelant le prédicat tointegtointeger. Le fichier dcg.pl : écrit par Peter Van Roy et Tom Getzinger. Ce fichier contient un interpréteur qui facilite l écriture des grammaires en utilisant une forme plus simple et efficace. Dans des grammaires simples, c est facile de les faire sans cette interprétation et ça permet le passage de l information du côté droit de la grammaire au côté gauche automatiquement. Par exemple au lieu d écrit : 24

28 P(B(X,Y),L0,L) :- S(X,L0,L1), T(Y,L1,L), not(x=r(_,x). on écrit : P(B(X,Y)) :- S(X), T(Y), {not(x=r(_,x)}. Ce qui est entre les accolades doit être des prédicats ordinaires utilisés généralement pour faire des conditions. L exemple donné est trop simple pour voir l utilité, mais avec des grammaires plus compliquées, c est trop compliqué avec la première méthode, puis dans la construction de notre interpréteur Prolog, ça nous rend plus simple l implémentation 5.2 Définition de la forme de la configuration (Administrateur) Comme mentionné précédemment l administrateur via l interface graphique doit pouvoir modifier la configuration des règles associées aux requêtes, les règles syntaxiques et les les règles générales. À chaque requête (question), l administrateur associe une phrase de description, une requête écrite en langage SQL et des règles sémantiques. Une étape a été de définir la forme générale dans laquelle les règles sont écrites en se basant sur le fonctionnement du générateur de syntaxe profonde (partie Prolog) et les besoins fonctionnels. Ensuite, nous avons défini une syntaxe simple pour la configuration. Les règles sémantiques : L administrateur peut créer des concepts sémantiques en leur donnant des noms et le sens associés. Cela se fait en précisant sur quoi le concept est appliqué. L administrateur utilise sa vue de la table pour les composants du concept sémantique. Ex : avoir_lieu(x,y) -> X est une U.E ET Y et une date. Qui est exprimé par : avoir_lieu(x,y) -> (X est dans première colonne de la table) ET (Y est dans la deuxième colonne de la table) Ce concept doit avoir une définition, qui le lie à sa représentation syntaxique profonde. Cette définition est faite au niveau de la configuration syntaxique. Chaque concept défini peut donner le sens du texte à générer. Pour cela, l administrateur doit indiquer que ce concept est le principal (pour lequel on veut générer du texte ), ou contribue au sens du texte en faisant partie d autres concepts. 25

29 Une règle sémantique peut également utiliser une autre règle en l appelant par son nom et ses paramètres. EX : dans(x,y) -> (et une Salle ET Y et un B^atiment) avoir_lieu(x,y, Z) -> X est une U.E ET Y et une Salle ET dans(y,z). La règle principale : avoir_lieu(x,y,z). En appelant des règles logiques (générales), communes pour toutes les configurations des requêtes, l administrateur peut aussi rajouter du sens au concept sémantique, ce qui donne des nouvelles informations. avoir_lieu(x,y,z) -> (X est une U.E) ET ( Y est une date ) ET temps(y,z). Dans cet exemple, le prédicat temps rajoute une information,qui sera variable selon les résultats, au sens qui est le temps dans laquelle serait exprimée la phrase (utilisé dans la syntaxe profonde pour avoir un texte avec des verbes conjugués avec le bon temps.) Z(X,Y) -> (si X \Leftarrow date actuelle Y=futur) sinon Y=passé ; Des Super règles peuvent être utilisées sans les définir dans la configuration sémantique. Ils prennent comme argument des concepts sémantiques définis pour lier ces derniers en donnant un sens général. Par exemple, le concept cause n a pas besoin d être défini, car il n utilise pas directement les résultats de la table, mais il utilise des concepts définis pour générer un sens de cause (concept A parce que concept B). Règles générales : L administrateur peut définir des règles logiques utiles pour fournir des informations aux autres règles. Ces règles sont communes à toutes les autres. 5.3 Définition du langage de configuration et l interpréteur Dans la configuration, ceux sont les règles qui seront interprétées (règles sémantiques, règles syntaxiques et règles générales). Les règles syntaxiques et générales sont interprétées au démarrage. Les règles sémantiques sont interprétées après le choix de la requête par l utilisateur et la demande de la génération. Les règles Prolog correspondants aux règles interprétées sont mises dans un fichier différent. Les règles syntaxiques se trouvent dans le fichier prolog syntax.pl. Les règles sémantiques se trouvent dans le fichier prolog semantic.pl. Les règles générales se trouvent dans le fichier prolog general.pl. 26

30 Les relations représentant le contenu de la table se trouvent dans le fichier prolog table.pl. Le résultat est demandé via l appel à une règle prolog fixe syntaxe écrite dans un fichier result.pl avec toutes les déclarations des fichiers à consulter. La classe PrologInterpreter est la classe qui assure la génération du code Prolog permettant la génération de la structure syntaxique profonde. La table SQL est représentée sous forme de relations logiques (prédicats, relation(x,y,z) ) via la méthode addsemantictable(). Les règles sémantiques et les règles générales sont transformées en des règles logiques en utilisant,respectivement les méthodes addsemantiquerules() et addgeneral- Rules(). Les règles syntaxiques sont quant à elles transformées en des règles d écriture permettant le passage du sens à la syntaxe profonde via la méthode addsyntacticrules(). Les règles générées sont écrites dans les fichiers prolog cités précédemment. Syntaxe : Pour rendre la syntaxe plus simple pour l administrateur, nous sommes restés sur les règles représentées sous forme de prédicats (clauses). Des mots clés sont utilisés pour exprimer les différentes configurations citées précédemment. and et or pour exprimer et et ou. Dans la configuration syntaxique : listed : avant une règle, c est pour dire que le résultat de cette règle va être listé en fonction du contenu de la table. Dans les exemples ci-dessous, on en monte l utilité. super : la règle qui suit est une super règle qui utilise des règles pour se construire et ne doit pas être définie dans les règles sémantiques. var(x) : utiliser la valeur de la variable X. list(p(x),x,y) : Ceci renvoie une suite de résultats de la règle p(x) avec les différentes variables X trouvées dans les relations de la table en fonction de la variable Y. Par exemple, un enseignant peut enseigner 4 U.E. Pour les utiliser tous dans la règle syntaxique avec la bonne syntaxe, on met la partie répétitive dans la règle P(X) et on l appelle avec une liste (avec X U.E et Y enseignant). Call (X) : Cette règle est utilisée pour appeler une règle X dans une autre règle. Dans la configuration sémantique : main : la règle qui suit est la règle principale pour laquelle on veut générer le texte. call[p(x,y,... )] : pour appeler une règle définie dans la configuration sémantique. #n=(x) : X et dans la colonne n de la table.\\ Voici un exemple d une configuration : Règles générales : //donner le genre (pluriel,singulier) en fonction de la valeur de X. 27

31 nbre(x,y) -> (=(X,1) and =(Y,sg)) or =(Y,pl); //donner le temps en fonction de la valeur de X. tense(x,z) -> (tointeger(x,y) and ( (>(Y,100) and =(Z,futer)) or (<(Y,100) and =(Z,past)))); //activer la négation en fonction du résultat (X). reusir_neg(x,y) -> (>(X,10), =(Y, no)) ; =(Y, yes) ; Règles syntaxiques : enseigner(x,y) -> [PRED=enseigner, tense=present, subj=[form="var(y)"], obj=[pred=ue, number=pl, def=yes, mod=([pred=stronget, list(p(x),x,y)] ) ] ]; listed:p(x) -> [FORM="var(X)"]; avoir(x,y) -> [PRED=avoir, tense=present, subj=[form="var(x)"], obj=[form="var(y)"] ; reussir(x,y,z) -> [PRED=reussir, tense=past, neg=var(x), subj=[form="var(x)"]] ; nbr(x,y) -> [PRED=var(X), number=pl, quant=[form="var(y)"]]; super:cause(x,y) -> [PRED=cause, arg1=call(x), arg2=call(y)]; règles sémantiques : //l administrateur connaît les champs de la table résultante. Pour la première question : //quelle sont les UE enseignées par tel enseignant? enseigner(x,y) -> [#1=(X),#2=(Y)]; main:enseigner(x,y); Pour la deuxième question : //quelle est le nombre d étudiants inscrits en master 1 informatique? nbr(x,y) -> [#1=(Y)]; main:nbr(étudiant,y); Pour la troisième question : 28

32 //est-ce qu un tel étudiant a validé son semestre? avoir(x,y) -> [#1=(X),#2=(Y)]; réussir (X,Y,Z) -> [#1=(X),#2=(Y)] and reusir_neg(y,z); main:cause(call[réussir (A,B)],call[avoir(C,D)]); NB : Le résultat de l interprétation dans l annexe. 5.4 Création d un prototype Pour permettre le bon déroulement de l implémentation et rendre claire la structure du système, un prototype était fait avec une implémentation minimale de chaque partie. Ce Prototype donne aussi une vue utilisateur pour prévoir le résultat attendu. Classe GatText c est la classe qui assure le bon déroulement du processus et gère les différentes demandes des utilisateurs. Nous nous sommes basés sur cette classe pour avoir une représentation similaire du fonctionnement attendu. 5.5 Configuration de la base de données et implémentation du gestionnaire des requêtes En parallèle avec la phrase citée précédemment, une base de données contenant les données sur le domaine traité par notre système (cité précédemment) a été créée. Un script a été écrit pour l automatisation et la sauvegarde de la configuration. Une classe permettant la gestion de la connexion à la base de données a été créée avec des méthodes permettant la connexion et l envoie des requêtes. Le type de la table après la récupération est laissé ResultSet (SQL). Ce type offre en effet des méthodes simples et utile pour faire un parcours de la table au niveau de l interprétation. La classe DbConnection gère la connexion à la base de données SQL. Elle parse le fichier de configuration pour récupérer l URL, le nom d utilisateur et le mot de passe qui permettront la connexion à la base (lors de la création de l objet, via la méthode connecte). Pour chaque demande de génération, une requête SQL correspondante à la requête est envoyée à la base de données, via la méthode gettable(), pour récupérer la table (la règle SQL est passée par GatText). 5.6 Gestion de la configuration Pour gérer la configuration (chargement et écriture) d une manière efficace, on a pensé à créer des structures manipulables par le système pour l exploitation de ces dernières. 29