Serge Fleury

Maître de Conférences en linguistique informatique Sorbonne nouvelle, Paris 3
Membre du SYLEDED268

ILPGA / Sorbonne nouvelle
  .; .; ; > > ; >

 

 

 

 

 

 

 

 

 

Chapitre 9

 

 

 

La réflexivité pour une évolution des représentations dans le traitement automatique du langage naturel

9.1. Réflexivité, une introduction

 

 

L'énigme MU est présentée dans (Hofstadter 1986) pour illustrer les limites des systèmes formels. Au départ une question : "Pouvez-vous produire MU ?". Pour cela on dispose des éléments suivants :

 

L'axiome MI, les symboles M, U, I et les règles :

 

• Règle 1 : si vous possédez une chaîne se terminant par I, vous pouvez lui ajouter un U à la fin.

• Règle 2 : supposons que vous ayez Mx. Vous pouvez alors ajouter Mxx à votre collection.

• Règle 3 : si la chaîne des symboles III apparaît dans votre collection, vous pouvez former une nouvelle chaîne en remplaçant III par U.

• Règle 4 : si le groupe de symboles UU apparaît dans l'une des sous-chaînes, vous vous pouvez le supprimer.

 

La démarche raisonnable pour commencer à produire MU (en s'aMUsant) est de travailler à l'intérieur du système ainsi défini. C'est à dire à produire des dérivations successives à partir de MU :

 

règle 2 règle 2 règle 3

MI ----> MII ----> MIII ----> MIIIU ....

 

Jusqu'où peut-on aller dans cette dérivation sans perdre patience ? Il est préférable en fait d'examiner ce système et son fonctionnement à un niveau extérieur au processus de dérivation, pour évaluer pourquoi il est si difficile de produire MU. Si on regarde ce système de l'extérieur, on peut remarquer que :

 

• 1. Les nombres 2 et 3 jouent un rôle important, puisque les séries de trois I et de deux U sont éliminées.

• 2. Le système utilise des tendances opposées : des règles d'allongement (1 et 2), et des règles de raccourcissement (3 et 4).

 

Pour résoudre l'énigme il faut aller encore plus loin et utiliser un outil extérieur au système : la théorie des nombres. Si on compte le nombre de I des théorèmes du système, on s'aperçoit très vite qu'il n'est jamais nul : on ne peut pas éliminer tous les I. Les règles 1 et 4 n'ont aucun effet sur le nombre de I. Seules les règles 2 et 3 influent sur ce nombre. La règle 3 diminue de 3 le nombre de I. Dans une application de la règle 3, le nombre de I pourrait très bien être un multiple de 3 si le nombre initial de I était lui aussi un multiple de 3 : cette règle ne peut créer un multiple de 3 qu'à condition de commencer avec un multiple de 3. La règle 2 double le nombre de I. De même, elle ne produira pas de multiple de 3 s'il n'y en avait pas un avant.

 

Pour résumer :

 

• 1. Le nombre de I initial est 1, et 1 n'est pas un multiple de 3.

• 2. Deux des quatre règles n'ont aucun effet sur le nombre de I.

• 3. Les règles 2 et 3 modifient le nombre de I de telle sorte qu'aucun multiple de 3 ne peut être produit.

 

La conclusion s'impose : le nombre de I ne peut jamais devenir un multiple de 3 et il est impossible que le nombre de I soit nul. C'est la méta-représentation du système MU dans la théorie des nombres qui a permis de résoudre cette énigme. Il faut se reculer pour observer l'ensemble de la situation. Puis choisir la méta-représentation qui servira de base de travail.

 

9.2. Concepts fondamentaux de la réflexivité : l'apport de Pattie MAES (MAES 1987)

9.2.1. (Méta) Système (Réflexif)

 

 

Réflexivité

"Il y a réflexivité chaque fois qu'un système s'applique à lui-même."

 

On parle de système pour décrire un mécanisme lié à une certaine partie du monde (le domaine). Ce système comprend une représentation des objets liés à ce domaine et les moyens de travailler avec/sur ces objets. Un méta-système est un système dont le domaine d'activité est lui-même un système lié à un domaine. On dira qu'un système est réflexif s'il raisonne et agit sur lui-même. Un système est réflexif si le méta-système associé est ce même système.

 

 

Figure 9.1 : (Méta) Système (Réflexif).

 

 

Ainsi on parle de réflexivité quand :

 

• Une partie d'un système fait référence au système dont elle fait partie, un énoncé déclaratif fait référence à une partie du système dont il fait partie :

 

"Cette phrase contiendrait sept mots si elle en avait cinq de moins."

 

• Le système crée une copie de lui-même : dans les mécanismes cellulaires, les enzymes interviennent dans des créations de copie d'elles-mêmes (cf infra).

 

• Une partie A d'un système peut modifier une autre partie B de ce système, si A est capable d'apprendre à modifier B en vue d'obtenir de meilleures performances pour B.

 

• Le système s'observe sans se modifier pour évaluer son propre comportement (expertise de diagnostic, d'édition, d'interprétation...). On trouve très fréquemment dans les gros systèmes informatiques des outils de surveillance de l'activité de l'ensemble du système : CPU disponible, prise en compte des entrées sorties,...(que l'on trouve par exemple sous forme de "Monitoring", ou d'outils chargés de détecter des erreurs spécifiques (problèmes d'écriture sur disque...) et capables d'avertir le responsable (humain) du système pour qu'il intervienne.

 

La biologie moléculaire est d'ailleurs un très bon exemple de domaine où les phénomènes de différences de niveau de représentation agissent les uns sur les autres. On peut ainsi illustrer ce phénomène par l'exemple de la synthèse des protéines. Le gène provoquant la ou les protéines, fait partie d'un ensemble permettant de réguler la production des protéines en fonction des besoins de la cellule. Cet ensemble s'appelle l'opéron, il est composé d'une séquence d'ADN, appelé gène promoteur, d'une autre, le gène opérateur, et d'une troisième, le ou les gènes de structure. Un gène régulateur est associé à ce mécanisme. L'ADN se trouve dans le noyau des cellules. Il se compose de longues chaînes de molécules appelées nucléotides. Or si quelques protéines sont fabriquées dans le noyau, la plupart d'entre elles sont synthétisées à l'extérieur (dans le cytoplasme) pour y être utilisées. Il existe donc nécessairement des intermédiaires exécutant dans le cytoplasme le programme se trouvant dans le noyau. Une protéine est une suite d'acides aminés (aa). Avec les vingt aa existant, des milliers de protéines différentes peuvent se constituer : elles seront différentes de par leurs séquences d'aa et auront donc des rôles différents dans la cellule. Un programme inscrit sur le gène est très strict : il s'agit de déterminer avec précision l'ordre des aa composant la protéine produite. A chaque groupe de trois nucléotides correspond un aa particulier. En pratique, une copie du message du gène de structure est constituée sous la forme d'une molécule d'ARN-Messager (ARN-M). Cette molécule est capable de traverser la membrane nucléaire. D'autres intermédiaires (ARN de transfert) vont chercher dans le cytoplasme des aa qui s'assembleront selon la suite des nucléotides de l'ARN-M et donc de l'ADN. Ce qui est remarquable dans ce mécanisme, c'est que la cellule peut doser la production des substances dont elle a besoin. Lorsque la cellule n'a pas à produire une certaine protéine, la copie du gène de structure l'ARN-M ne peut pas s'effectuer. Lorsque la synthèse doit reprendre, les produits bloquant l'opéron du gène opérateur sont inactivés et l'ARN-M peut de nouveau produire.

9.2.2. Langages de programmation informatique et réflexivité

 

 

Un programme réflexif se définit au travers d'une reproduction intérieure des représentations construites et des modifications qu'il y apporte.

 

Plusieurs approches existent pour construire des systèmes réflexifs. Tout d'abord, certains systèmes incluent une part de réflexivité. Depuis peu les Systèmes d'Apprentissage sont implémentés en prenant en compte de manière adéquate les processus réflexifs. Il y a ensuite les systèmes qui font usage de processus réflexifs du fait qu'ils sont implémentés dans des langages de programmation qui fournissent des facilités pour l'utilisation de ces processus. LISP est un exemple d'un tel langage. Certaines fonctions lispiennes permettent un accès sur leur propre fonctionnement. Par exemple considérons les fonctions suivantes :

 

(defun integer-stream () '(0))

(defun integer-stream-element ()

(let* (( list-of integers (integer-stream))

(last-generated-integer (car list-of-integers)))

(eval `(defun integer-stream ()

',(cons (1+ last-generated-integer)

list-of-integers)))

last-generated-integer))

 

Au premier appel de la fonction integer-stream-element, celle-ci retourne 0, et elle redéfinit la fonction integer-stream qui devient :

 

(defun integer-stream () '(1 0))

 

et donc, au prochain appel de la fonction integer-stream-element, celle-ci retourne 1 ....

 

Il y a enfin les systèmes implémentés dans des langages dont la structure interne inclut une spécification explicite de la réflexivité (à l'image du langage 3-LISP, développé par B. C. Smith (1982)). Tout système implémenté avec un de ces langages peut raisonner et agir sur lui-même. On dit que de tels systèmes ont une architecture réflexive. Une caractéristique des langages construits avec une architecture réflexive est l'identité de représentation du niveau de l'activité liée à la réflexité et le niveau lié à l'exécution propre au système.

9.2.3. Architecture réflexive

 

 

On dit qu'un langage dispose d'une architecture pour X si le langage donne de l'importance au concept X et donc s'il fournit des primitives adéquates pour des activités réflexives. Ainsi un langage de programmation fournit une architecture réflexive si la réflexivité est un concept fondamental du système. Ceci implique que le langage produit du code spécifique au processus de réflexivité compréhensible par l'interpréteur de ce langage. Un langage possédant une architecture réflexive est tel que toute activité du système a une représentation d'elle-même au moment de son exécution. Une architecture réflexive permet par exemple d'utiliser des processus de réflexivité à un certain moment d'élaboration d'un programme pour par exemple mettre au point celui-ci. Une analyse automatique développée dans ce cadre pourrait ainsi construire des méta-représentations liées aux différents stades de l'analyse et ainsi permettre d’évaluer par exemple la circulation des traits manipulés par la grammaire. Les systèmes informatiques utilisent certains processus réflexifs pour par exemple : établir des statistiques sur les ressources utilisées ou disponible par ou pour le système, prévenir les utilisateurs si certaines erreurs sont détectées (problème d'écriture sur un disque...), permettre le traçage d'un programme, le "debuggage", etc. Mais à la différence des systèmes à architecture réflexive, les systèmes informatiques classiques n'ont pas été implémentés en prenant en compte la réflexivité comme un concept fondamental. Pour les systèmes à architecture réflexive, les processus de réflexivité sont développés de manière plus modulaire ce qui rend les efforts d'implémentation moins ardus et produit des systèmes plus élégants et plus ouverts. Le langage 3-LISP (Smith 1982), est conçu avec deux types de fonctions. Les fonctions simples construites avec define-SIMPLE ou lambda-SIMPLE et qui construisent des objets fonctionnels "classiques" pour le calcul informatique. Les fonctions réflexives construites avec define-REFLECT sont des fonctions dédiées au processus de réflexivité. Celles-ci ont accès à une représentation globale de l'environnement du système en activité. Ces fonctions travaillent sur des variables qui représentent l'environnement et peuvent les inspecter et les modifier.

9.2.4. Développement d’une architecture réflexive

9.2.4.1. Comment se fait l'auto-représentation du système ?

 

 

Etre capable de générer des informations sur l'état courant d'un processus en cours, cela signifie par exemple que l'interpréteur du langage qui dispose d'informations sur toutes les primitives du langage doit aussi être capable de construire des représentations de ces primitives lorsqu'elles sont instanciées (i.e une méta-représentation de ces primitives). De plus, il n'est pas suffisant de produire des informations sur l'état d'un système encore faut-il que cette représentation soit accessible. Comme on l'a dit précédemment le fait d'utiliser les mêmes schémas de représentation pour la partie réflexive et pour la partie exécution d'un système permet une interaction cohérente entre les deux niveaux de représentation. Il est cependant nécessaire d'établir des "frontières" entre ces deux niveaux de représentation. Ce que l'on peut illustrer de la manière suivante :

 

He said I'll do the job

He said : "I'll do the job"

 

Les guillemets ci-dessus introduisent cette différence de niveau entre les deux parties de l'énoncé. Dans le travail présenté dans DINOSOR (Fleury & al. 1992) on dispose de trois niveaux de représentation de la grammaire : une représentation associée à la grammaire initiale, une représentation associée à la grammaire normalisée et une représentation associée à la grammaire compilée. Chacune de ces représentations est attachée à un objet spécifique et les trois objets ainsi créés sont nettement dissociés.

9.2.4.2. Comment programmer la partie réflexive ?

 

 

Un système doit être capable de modifier ses propres auto-représentations. Il doit aussi être possible d'effectuer un va-et-vient permanent entre la phase d'exécution d'un processus et la phase de réflexivité liée à ce processus.

9.2.4.3. Quel lien existe-t-il entre le système et la partie réflexive ?

 

 

Les données liées au domaine de la réflexivité doivent être liées au système de telle sorte qu'une fois achevées les manipulations dans une phase d'activité réflexive, le retour à l'exécution d'un processus du système implique que le système ait accès à ces données mises à jour (et réciproquement). Un travail de maintenance permanente est donc nécessaire pour la cohérence des deux niveaux de représentation. Il faut pouvoir disposer de programmes qui peuvent modifier le flot de contrôle quand ils sont en train de fonctionner. Il ne suffit pas de constater que quelque chose ne fonctionne pas dans le déroulement d'un programme, il faudrait pouvoir y remédier : on retrouve là le problème de la mise au point des programmes ou encore, dans le cas des analyseurs, le fait de savoir pourquoi ça ne marche pas comme on le voudrait... Avec 3-Lisp, il est possible d'indiquer comment changer le processus d'interprétation : si le programme détecte un certain type d'erreurs, il peut changer le comportement de l'interpréteur de façon à remédier à cette erreur sans passer par un programmeur pour modifier le programme.

9.2.5. Utilisation de la réflexivité

 

 

Il faut pouvoir se servir de ce que l'on a obtenu dès qu'on l'a obtenu. Pour passer d'une étape à une autre, on se sert des résultats que l'on vient d'obtenir. On verra infra comment la mise en place d'une représentation de la grammaire sous une forme normalisée s'est révélée primordiale pour la mise au point des modifications apportées au code initial. On doit donc pouvoir accéder aux représentations du système lui-même à tout moment de l'activité du système. Ce qui doit être accessible au processus de réflexivité :

 

• Les programmes du système.

 

• Les données du système.

 

• Le programme d'un processus en cours d'exécution.

 

• Les données d'un processus en cours d'exécution.

 

• La réflexivité rend possible le contrôle du flux des calculs de manière modulaire.

 

Un système réflexif peut comporter plusieurs modules et l'un d'entre eux modifie un autre. C'est le cas d'un système capable d'apprendre contenant une partie performance qui résout les problèmes et une partie apprentissage qui modifie la précédente au vue de ses résultats. Le système se modifie même si en réalité la partie qui modifie est distincte de la partie modifiée. Il est clair que pouvoir accéder aux représentations des programmes d'un système pendant leur déroulement est un moyen efficace de contrôle. La maintenance, l'acquisition et la communication de l'information contenue d'un système est une tâche qui suppose une connaissance importante sur toutes les activités d'un système donné et les interactions possibles entre certaines activités.

9.2.6. Dangers de la réflexivité

 

 

Si un système est capable de modifier son comportement, est-ce que cela entraîne un transfert de contrôle définitif de l'activité du système vers lui-même? Il faut ainsi remarquer que la réflexivité peut entraîner une perte d'informations. En effet si un système peut modifier son état courant quand il détecte une erreur, une incorrection ou quand les valeurs attachées à certaines variables provoque cette modification de l'état courant, on perd toute trace de l'environnement initial (à moins de mettre en place une nouvelle couche qui stocke les représentations des états précédents du système!). Or il arrive fréquemment que le programmeur (ou l'utilisateur) souhaite avoir accès à la représentation de l'environnement de l'état en cours du système pour évaluer par exemple la valeur attachée à une certaine variable. Ou, par exemple, lors d'une erreur du système qui nécessite sa réinitialisation, à la représentation du fichier généré par cet arrêt de la machine. Aussi l'auto-modification permanente d'un système peut entraîner une impossibilité d'accès aux représentations du système. On voit pourtant très bien l'intérêt que pourrait représenter l'existence de processus réflexifs notamment dans les périodes de mise au point de programme, c'est à dire à un moment où l'on souhaite avoir accès à tous les paramètres que le système en cours de mise au point manipule.

 

Un autre problème dans l'utilisation des processus réflexifs est celui de la gestion efficace des interactions entre les différents niveaux de représentation d'un système. Comment faire en sorte qu'il n' y ait pas de confusion entre les informations liées au système propre et les informations liées aux processus de réflexivité ? Dans le cas de l'analyse automatique, OLMES (Habert 1993) opère une transcription de la grammaire initiale. En plus de cette représentation de la grammaire, il faut pouvoir produire une représentation dédiée à la réflexivité et contenant les mêmes informations. Il convient donc d'établir une distinction nette entre ces deux niveaux de représentation. Même si le système en question est construit de telle sorte que les différents niveaux de représentation manipulent des primitives distinctes, il n'est pas évident que l'existence de ces deux niveaux de représentation rende la compréhension de tout ce qui est en jeu dans le système très claire pour le programmeur et/ou l'utilisateur.

9.2.7. Comment programmer la partie réflexive?

 

 

Les langages à architecture réflexive construisent une auto-représentation du système. Cette méta-représentation doit prendre en compte la formalisation des aspects sémantiques, syntaxiques, opérationnels, des phénomènes d'inférence propres au système. L'auto-référence peut-être implicite ou explicite. On parle de réflexivité implicite si le bon fonctionnement du système nécessite une activité réflexive permanente. Dans ce cas il est impératif d'assurer une cohérence constante et systématique entre le système et sa méta-représentation. (Le système s'applique à lui-même mais il ne le sait pas) On parle de réflexivité explicite si les processus réflexifs sont utilisés comme des fonctionnalités possibles mais non obligatoires. Ils interviennent que si l'on fait explicitement appel à eux. Il faut ensuite établir le type de lien entre le système et sa méta-représentation. Deux types de solution sont possibles :

 

• La réflexivité procédurale, le lien est implémenté.

 

• La réflexivité déclarative, le lien est spécifié.

9.2.7.1. Réflexivité procédurale

 

 

L'auto-représentation du système sert à implémenter le système. Le problème de la maintenance de cohérence des deux niveaux de représentations ne se pose donc pas. Il y a une seule représentation du système qui sert à l'implémenter et aussi à agir et réfléchir sur lui-même.

9.2.7.2. Réflexivité déclarative

 

 

Un système développé avec une architecture à réflexivité déclarative doit être capable de prendre en compte au moment de son exécution des contraintes et de poursuivre son exécution après avoir satisfait ces contraintes. Le système fournit les moyens de créer des méta-représentations et de récupérer le référent de celles-ci. La cohérence des deux niveaux de représentation est assurée par un mécanisme qui maintient la relation entre ces deux niveaux. Le niveau méta-représentation est dédié à la description du système.

9.2.8. Vers une mise en place de processus réflexifs dans une analyse automatique

 

 

Le choix de la méta-représentation à adopter est extrêmement important car il implique la mise en place d'outils réflexifs spécifiques. Il faut rappeler que les langages à architecture réflexive permettent une plus grande modularité dans l'implémentation. Ces langages doivent être ouverts à toute extension qui permette de fournir de l'information sur l'activité d'un processus quelconque d'un système. Sans revenir sur les problèmes cruciaux qui existent pour la construction de langage à architecture réflexive, on peut quand même conclure provisoirement en disant que :

 

• La réflexivité est un outil utile pour toute activité de surveillance, de mise au point, de présentation raisonnée des résultats.d'un système.

 

• Les processus réflexifs doivent être limités et déterminés par des choix précis : les besoins de l'utilisateur ou du programmeur définiront ces processus. Leur implémentation doit d'ailleurs être introduite de manière modulaire et/ou ponctuelle.

 

• La réflexivité est envisageable dans les programmes orientés Objet (PàO et PàP) en raison de caractéristiques propres à ces langages : ce type de langage permet de développer la mise en place de méta-représentations, comme nous le verrons infra. Nous verrons plus loin comment mettre en place des processus réflexifs au sein d'un analyseur syntaxique développé avec le langage orienté objet CLOS puis avec le langage à prototypes SELF.

 

Dans le cas de l'analyse automatique, les processus réflexifs peuvent être développés pour mettre en place des activités de suivi ou de mise au point de l'analyse. Pour cela, il importe de construire différents niveaux de représentation des connaissances manipulées par l'analyseur. On peut par exemple construire plusieurs représentations de la grammaire utilisée par l'analyse à différents stade de celle-ci. On peut aussi envisager de construire des niveaux de représentations dédiés au pistage des transferts d'informations entre les différents acteurs de l'analyse. Les outils mis en place doivent présenter, de manière raisonnée, les différents états pertinents de l'analyse.

 

9.3. Qu’est-ce qu’on ne peut pas faire sans la réflexivité ?

 

 

"Le thème de la représentation des connaissances envahit aujourd'hui le champ des travaux en IA. Les ambiguïtés n'en sont pas pour autant levées : de quelles connaissances s'agit-il? Et qu'appelle-t-on représentation ? Savoir répondre à une liste de questions ne signifie pas forcément connaître un sujet. Toute vraie connaissance suppose l'usage à bon escient des informations qui sont les nôtres. Quant aux représentations qu'on pourra se faire de ces informations, elles dépendront de nombreux facteurs dont chacun, isolément, pourra les orienter différemment : la situation, le domaine concerné, la personne visée, les notions organisant la connaissance, le langage dont on dispose,.... Les classifications de savoir sur un domaine n'ont ainsi d'autre vertu que celle de nous aider à ranger nos idées. Comment ensuite les organiser, les orienter, tel est effectivement le problème des métaconnaissances nécessaires pour apprendre à savoir utiliser les connaissances et, par suite, à délier les moteurs d'inférence inhérents à de multiples systèmes experts" (Vignaux 1991).

 

La tradition langagière considère souvent qu'il est nécessaire de "prendre du recul" pour évaluer le cours des choses. Il va de même pour la mise en place de dispositifs informatiques qui tentent de réaliser une représentation matérielle de l'analyse de certains faits de langue. L’utilisation qui est faite de la réflexivité dans les langages informatiques de haut niveau est de permettre de "parler des objets" manipulés (par les programmes mis en oeuvre dans ce langage) plutôt que de parler aux objets (via l’envoi de messages). Dans certaines étapes de développement d’un programme, il est souhaitable de pouvoir examiner la structure des objets et donc de disposer d’outils qui permettent l’activité réflexive sur le programme en cours de développement. Cette étape peut aussi se révéler souhaitable lors de l’exécution d’un programme en vue d’améliorer les processus mis en oeuvre par le programme.

 

9.4. Connaissance et réflexivité en IA

9.4.1. De la méta-connaissance

 

 

Comme il est très difficile d’envisager d’inclure au sein d’un même module l’ensemble des connaissances que l’on peut avoir sur le langage naturel, il semble nécessaire d’envisager une expression déclarative des connaissances pour le TALN. On sépare ainsi les connaissances de leur mode d’emploi. Une telle approche implique donc que le système qui les utilise puisse avoir des connaissances pour manipuler ces connaissances (pour recréer le lien entre les connaissances et leur mode d’emploi, il s’agit ici de construire le mode d’emploi). Quand un système raisonne sur ce qu’il fait, il lui faut des connaissances sur les connaissances, appelées méta-connaissances. Un système doit pouvoir manipuler les connaissances dont il dispose afin d’expliquer ce qu’il a trouvé, d’apprendre en comprenant les raisons de ses succès et de ses échecs. Cela demande de travailler à deux niveaux : une niveau de base dans lequel on essaie de résoudre un problème et un niveau méta dans lequel on observe ce que l’on fait pendant que l’on résout le problème en question. Il est souvent bon de manipuler l’énoncé pour résoudre un problème. L’énoncé d’un problème est un sujet d’étude, étude qui se fait grâce à des métaconnaissances. Il en est de même pour notre propre utilisation du langage naturel. Nous ne naissons pas avec la connaissance d’une langue mais avec des métaconnaissances qui nous permettent d’apprendre une langue. Un nouveau problème fondamental surgit à ce stade de développement d’une approche déclarative de manipulation des connaissances. L'utilisation d’un très grande nombre de modules de connaissance implique un très grand nombre de méta-connaissances sur ces modules de connaissances pour pouvoir les manipuler. Il s’agit donc dans une telle approche de découvrir des ensembles de métaconnaissances pour traiter les connaissances déclaratives. Cette tâche n'est évidemment pas triviale. D'ailleurs (Pitrat 1993) souligne très bien la difficulté de travailler sur les métaconnaissances dans le cadre du langage naturel : dans ce domaine de savoirs, il est en effet difficile de manipuler et de maîtriser un grand nombre d’éléments de manière efficace. Le problème principal étant de trouver des métaconnaissances capables de produire de nouvelles connaissances.

9.4.2. Faciliter la production de méta-connaissances sur les entités linguistiques et l'analyse : Illustration avec OLMES (1993)

 

 

OLMES (Habert 1991b) est un analyseur général pour le langage naturel. Il peut être utilisé pour des grammaires hors contexte comme pour des grammaires d'unification (Shieber 1986a). Il appartient à la famille des analyseurs à graphe actif. OLMES est écrit en CLOS - Common Lisp Object System (Keene 1989), (Steele 1990) - le système à objets de Common Lisp. Le recours à la programmation à objets, et particulièrement à l'héritage multiple, a permis la production de points de vue différents sur le parsage. A chaque occurrence de symbole de la grammaire correspond une classe. Une règle est représentée de la façon suivante : une classe est créée pour la partie gauche. Elle en mémorise l'étiquette. Dans une version de OLMES aujourd’hui modifiée, c'etait la super-classe de classes représentant les éléments de la partie droite, qui, elles, mémorisent l'étiquette de chacun de ces éléments. La figure qui suit donne le sous-graphe de classes traduisant GN -> Det N Adj. GN7 est la super-classe des classes Det8, N9 et Adj10.

 

Figure 9.2 : Le sous-graphe de classes représentant GN -> DET N ADJ.

 

Une analyse montante de gauche à droite se déroule de la manière suivante. Chaque fois qu'est rencontré un mot ayant la même étiquette que l'une des classes correspondant à un terminal premier élément de partie droite de règle, une instance de cette classe est créée. Par exemple, si un Dét(erminant) est rencontré, une instance de Det8 est créée, qui cherche le Dét(erminant) en cause (a) et le trouve. Cette instance crée alors une instance de la classe suivante dans le réseau, N9, qui cherche un N(om) et domine le Dét trouvé (b). Si l'instance de N9 trouve un N(om), elle crée à son tour une instance de Adj10, cherchant un Adj(ectif) et dominant le Dét et le N trouvés aux pas précédents (c). Si cette dernière instance trouve un Adjectif, elle crée une instance de GN7, qui domine les mots ainsi reconnus (d), et qui déclenche de nouvelles règles, par le biais de la création de deux instances de GN2 et GN15. Et la suite de l'analyse se poursuit de la même façon.

 

Figure 9.3 : Analyse par les instances d'un réseau de classes.

 

 

L'important est ici que l'entité "règle" est représentée en tant que telle, et peut donc être manipulée. La distinction est nette entre les choix que peut faire l'utilisateur en termes d'utilisation de la grammaire : direction d'exploration (gauche-droite, droite-gauche, bi-directionnelle) et stratégie (ascendante, descendante), choix qui se traduisent par des chaînages différents des classes représentant les éléments de la grammaire, et la structuration fondamentale de la grammaire par règles. Par ailleurs, une entité "méta-grammaire" est également créée, qui donne accès aux entités "règles" par le biais de leurs parties gauches.

 

 

Figure 9.4 : Méta-grammaire et règles.

 

 

En OLMES, il y a donc une bijection entre les entités présentes à l'exécution et les éléments des règles définies par le linguiste, comme dans (Yonezawa & Ohsawa 1990). La transformation opérée dans (Yonezawa & Ohsawa 1990) est cependant à sens unique : elle manifeste le lien entre le comportement des unités de traitement et la grammaire de départ, elle ne permet pas pour autant une rétro-action sur la grammaire de départ à partir de l'observation de ce comportement. Le fait de constituer des méta-représentations des règles et de la grammaire en tant que telles rend possible au contraire en OLMES une telle action en retour. Toutefois, avant d'explorer les potentialités d'une telle architecture, il convient de réinterroger les notions de méta-connaissance et de réflexivité selon les cadres qui peuvent y faire appel.

9.4.3. Intelligence artificielle, formalismes d'unification, langages de programmation : des réflexivités distinctes ?

 

 

Le choix d'une architecture donnée pour un analyseur n'est pas purement technique. Il incarne également une certaine "idée" de la langue et de son traitement, tant naturel qu'automatique, et, partant, fixe le rôle que peuvent y avoir méta-connaissances et réflexivité. A l'inverse, il est nécessaire d'examiner le détail des architectures pour faire sortir les notions de réflexivité et de méta-connaissances de leur abstraction, et pour montrer les conditions techniques précises de leur emploi, au delà des espoirs ou des agacements que la perspective réflexive peut susciter. Ainsi se justifie la minutie du développement qui suit : limiter autant que faire se peut le risque de prendre ses désirs pour la réalité. Certains parseurs entendent fournir des représentations des structures de données présentes à l'exécution aussi "proches" que souhaitable des entités lexicales et syntaxiques définies par les utilisateurs linguistes. L'extension de telles architectures permet de produire des méta-connaissances sur les données linguistiques et éventuellement sur leur utilisation. Peut-être pourrait-on en effet contraster utilement les approches issues de l'intelligence artificielle, celles découlant des formalismes d'orientation linguistique et enfin celles autour des langages de programmation les plus évolués. En effet, si la recherche sur la réflexivité constitue une dimension de l'intelligence artificielle depuis une quinzaine d'années, si depuis près de dix ans, elle représente un courant dans la conception des langages de programmation, par contre, elle semble marginale dans l'évolution récente de la linguistique informatique. C'est ce constat que nous voulons développer et questionner, en restant bien conscients des passerelles et des interférences entre des problématiques que nous présentons comme distinctes, voire divergentes.

Domaines de la réflexivité.

 

 

Il n'est pas sûr que tous les types d'analyse aient à gagner à recourir à la réflexivité. Quel pourrait être son rôle dans un analyseur LR, par exemple ? Dans les analyseurs pour langages de programmation, une fois la grammaire définie, on n'a pas de raison, a priori, d'y revenir. On peut ne s'intéresser qu'au résultat : le compilateur produit pour le langage en cause. Pour le langage naturel, c'est rarement le cas. Les connaissances utilisées par l'analyseur sont sans cesse à affiner. La perspective réflexive paraît donc plus fructueuse pour les domaines où les connaissances résistent à la formalisation.

Constituer et articuler des points de vue.

 

 

Le système multi-agents CARAMEL (Sabah 1990, 1993) fournit un bon exemple. Il est destiné à réaliser diverses tâches liées au traitement automatique du français. Il part de l'hypothèse que le type de connaissances à employer pour traiter une phrase ne peut être déterminé a priori, ce qui exclut un enchaînement fixe de couches (morphologique, syntaxe, sémantique, pragmatique, par exemple), et également une intégration fixée à l'avance des divers types de connaissances. Dans le but de réaliser "une architecture où chaque module [puisse] avoir accès aux connaissances et aux résultats d'autres modules selon ses besoins" (Sabah 1993), CARAMEL comprend alors un ensemble d'agents, simples ou complexes, qui sont autant de systèmes-experts coopérant à la construction du sens de l'énoncé. Les agents complexes peuvent déclencher d'autres agents. Ils constituent autant de "méta-systèmes contrôlant un ensemble d'agents pour l'accomplissement de leur but" (ibid.). Un superviseur général contrôle l'analyse. La réflexité est ici fondamentale : aussi bien au niveau du superviseur général qu'à celui de n'importe quel agent complexe, il s'agit d'évaluer les représentations déjà produites, les capacités des agents déclenchables par l'agent complexe concerné et partant, les meilleurs moyens d'obtenir le but fixé, en déclenchant tel ou tel agent, en gérant le va-et-vient d'informations entre les agents contrôlés, et en adaptant la stratégie selon les informations reçues des agents déclenchés. Par ailleurs, "dans sa mémoire de travail, le superviseur construit /./ une représentation globale du déroulement dynamique du raisonnement (une indication des agents qui ont été nécessaires pour mener à bien une tâche donnée), ce qui lui permet de donner par la suite des explications sur la stratégie qui a été employée". CARAMEL permet d'articuler différents savoirs linguistiques et non-linguistiques.

9.4.3.1. IA : la réflexivité pour la modularisation et l'articulation des savoirs

 

 

L'intelligence artificielle, plus directement confrontée aux relations entre les différents composants du savoir linguistique, et entre celui-ci et le savoir "sur le monde", a cherché à articuler ces différents types de savoirs, en utilisant par exemple l'activation de modules spécialisés, la mise en oeuvre ou le retrait de tel ou tel paquet de règles, et à essayer, depuis longtemps, de recourir aux méta-connaissances et à la réflexivité. Le développement des systèmes-experts (Laurière 1987) en particulier a très tôt poussé à représenter les connaissances que les experts ont sur leurs propres connaissances, en les formulant sous la forme de méta-règles guidant le moteur d'inférence. S'est avérée aussi fondamentale la capacité pour un système-expert donné de pouvoir expliquer comment il arrive à une conclusion donnée.

9.4.3.2. Les formalismes d'unification : peu de réflexivité

 

 

Au rebours de cette représentation modulaire et réflexive des connaissances et des traitements, les formalismes dits d'unification tendent à intégrer au long de l'analyse les différentes facettes de l'analyse linguistique. Ainsi dans la grammaire syntagmatique guidée par les têtes, HPSG (Pollard & Sag 1987), un "signe", entrée lexicale ou syntagme, comprend volets phonologique, syntaxique et sémantique. En tant que tels, ces formalismes ne favorisent guère, voire ne permettent pas, la séparation en différents modules explicites, destinés à interagir. Tout se passe comme si l'accord sur la manière de représenter les connaissances linguistiques et de s'en servir que constituent les formalismes d'unification s'était accompagné d'un certain enfermement sur syntaxe et sémantique pris dans un sens relativement restreint, et parallèlement, d'une mise entre parenthèses de l'articulation des savoirs linguistiques entre eux et avec d'autres types de savoirs. La possibilité de fournir sous une forme relativement déclarative un certain nombre de contraintes sur la combinaison des constituants entre eux a relégué paradoxalement au second plan la réflexion sur les stratégies d'utilisation des connaissances linguistiques. Si bien qu'au total, l'intégration d'une approche réflexive aux analyseurs basés sur des formalismes d'unification paraît difficile, et en danger de rester "accessoire".

 

Les formalismes d'unification comprennent un certain nombre de principes, qui contrôlent la bonne formation des différents constituants. Au sein d'un formalisme donné, certains de ces principes peuvent être pensés comme universels, tandis que d'autres sont vus comme propres à une langue donnée. On trouve ainsi dans la grammaire lexicale-fonctionnelle, LFG (Bresnan 1982), les principes de complétude et de cohérence (toutes les "places" d'un prédicat verbal doivent être occupées, et il ne doit pas y avoir d'"argument" surnuméraire), dans la grammaire syntagmatique généralisée, GPSG (Gazdar & al. 1985), des principes d'instanciation de traits d'accord, de pied et de tête, ou les règles de précédence linéaire. Au delà de la règle générale que les principes doivent tous être simultanément satisfaits, la réalisation concrète de leur interaction, par exemple leur ordonnancement peut se révéler fort complexe, comme le montre S.Shieber (1986b). Pour tout dire, on voit réapparaître les problèmes de contrôle que la déclarativité des règles de réécriture annotées avait poussés dans l'ombre. Le Principle-Ordering Parser de S.Fong et R.Berwick (1991) a précisément pour objectif de permettre de tester des ordonnancements possibles des principes de la théorie du Gouvernement et du Liage en tenant compte de leurs dépendances logiques : "Le PO-Parser a été délibérément construit d'une manière extrêmement modulaire pour permettre un maximum de flexibilité dans l'exploration des ordonnancements alternatifs de principes". Les principes d'une théorie gagneraient sans doute à changer de statut et à constituer un méta-savoir explicite et utilisable en tant que tel au cours de l'analyse. Un tel méta-savoir pourrait veiller par exemple à l'application des différents principes d'unicité de la théorie du Gouvernement et du Liage (un seul noyau, une seule catégorie X par domaine, un seul support de fonction dans S etc.). Face aux deux réalisations possibles du GV avec objet direct en français, clitique préposé ou GN postposé au verbe, le méta-savoir incluant ce principe d'unicité éliminerait une configuration des hypothèses possibles si l'autre s'est réalisée.

9.4.3.3. Réflexions sur la réflexivité

Réflexivité approchée / implicite / explicite

 

 

Bascule d'un mode simple à un mode plus élaboré, envisageant davantage d'hypothèses, pondération des hypothèses, traitement des exceptions en tant que telles, adaptation aux énoncés traités, ces processus trouvent dans l'immédiat des approximations dans des analyseurs actuels : parsage auto-adaptatif (Lehman 1992), parsage probabiliste (Liberman 1991), dispositifs d'acquisition lexicale (Zernik 1991) ... Sans contester les apports de ce courant empiriste, numérique, non-symbolique, on peut faire l'hypothèse que l'intégration d'une approche réflexive dans la conception d'analyseurs peut permettre également de mettre en oeuvre ces dispositifs et ces fonctionnements, en leur donnant un statut plus clair. A ce titre, la comparaison entre CARAMEL et TALISMAN (Stefanini & al. 1992) est éclairante. TALISMAN repose aussi sur une architecture multi-agents, pour les mêmes raisons que CARAMEL : "compose[r] différentes phases d'analyse", "ordonner convenablement les divers sous-ensembles de règles et /./ les activer au bon moment". Les deux systèmes s'inscrivent donc dans le cadre de l'Intelligence Artificielle Distribuée (Bond & Gasser 1988), où l'"intelligence est répartie entre des agents. Ceux-ci sont des entités autonomes capables d'agir rationnellement sur elles-mêmes et sur leur environnement en fonction de leurs observations, de l'état de leurs connaissances et de leurs interactions" (Stefanini & al. 1992). Alors que CARAMEL repose sur des tableaux noirs pour le partage d'informations, TALISMAN s'appuie sur la communication par messages entre agents. Pour éviter les problèmes de synchronisation, de concurrence, de partage de ressources que fait naître une trop grande autonomie des agents, TALISMAN se voit contraint d'ajouter des "lois". "Les lois régulent et modifient les échanges de messages entre les agents. Elles sont explicites et modifiables " (ibid.). Ces lois jouent en fait le rôle des superviseurs de CARAMEL : elles "activent un agent spécialisé, en fonction d'indices prélevés dans le texte et de caractéristiques d'un problème d'analyse particulier" (ibid.), elles évitent certains conflits entre agents et en gèrent d'autres. Il s'agit bien de méta-savoirs. Leur reconnaître ce statut pose de manière plus nette la question de la constitution de la méta-connaissance au cours des traitements, c'est-à-dire en définitive le problème d'architectures réflexives qui aident à dégager des modes de coopération optimaux entre les agents, en notant par exemple les conflits rencontrés, les duplications d'informations etc. Thématiser la réflexivité en tant que telle paraît en définitive plus fructueux que d'y recourir implicitement ou d'utiliser des approximations.

Réflexivité naturelle et réflexivité artificielle

 

 

Nous sommes restés précédemment (relativement) agnostiques sur le rapport entre la réflexivité "naturelle" dont semble faire preuve le locuteur lors de l'analyse d'un énoncé, et que marque la constante activité métalinguistique, et la réflexivité qui nous semble devoir intervenir dans les analyseurs. A cela, au moins trois raisons. Les arguments psycho-linguistiques sont tout d'abord fréquemment suspects : la diversité tant des hypothèses que de leur utilisation rend prudent. En outre, mimer le comportement humain n'est pas forcément la meilleure solution. Enfin, ce sont plutôt les raisons internes à la conception d'analyseurs de recourir à la réflexivité qui nous paraissent pertinentes. C'est a priori dans le cadre d'une vision modulaire de l'analyse automatique que les apports de la réflexivité sont les plus évidents. Pourtant, le courant actuel des grammaires d'unification peut également en bénéficier. Pour reprendre les termes de P. Maes (1987a), "une implémentation réflexive ne contribue pas directement à la résolution des problèmes du domaine représenté par le système. Elle contribue plutôt à l'organisation interne du système ou à son interface avec le monde extérieur. Son but est de garantir un fonctionnement efficace et harmonieux des calculs liés au problème traité". Les divers cadres de pensée des travaux sur la réflexivité offrent donc des perspectives stimulantes. Pour reprendre P. Maes (1987a) : "le calcul réflexif est tellement constitutif des systèmes en vraie grandeur qu'il doit être développé comme un outil fondamental dans les langages de programmation". Pourquoi n'en irait-il pas de même pour l'analyse automatique du langage naturel ? En gardant en mémoire l'avertissement de J. Pitrat (1992) "Travailler sur l'utilisation des métaconnaissances est un détour qui aura des conséquences pour les systèmes manipulant les langues naturelles, mais nous ne devons pas en attendre des résultats spectaculaires à court terme".

 

9.5. Tradition de la programmation réflexive

9.5.1. Réflexivité et Méta-niveau dans les langages orientés Objet

 

 

On étudie ici certains langages dotés d'une capacité d'"introspection" permettant à un système conçu dans de tels langages de s'adapter et de s'optimiser. Est visée une adaptation non seulement statique mais aussi dynamique (au cours de l'évolution des calculs). On entend en outre contrôler le comportement d'un système non pas à un très bas niveau d'expression mais à un niveau au moins équivalent à celui du système lui-même. Un méta-niveau représente et décrit alors l'exécution du niveau de base, c'est-à-dire le déroulement du programme. Il est possible que le méta-niveau ait lui-même un méta-niveau et ainsi de suite, ce qui construit éventuellement ce qu'on appelle une tour réflexive (d'autant qu'il y a identité de langage entre niveau de base et méta-niveau).

 

 

Figure 9.5 : Une tour réflexive.

 

 

Le fait qu'un langage soit explicitement doté d'une méta-représentation de lui-même permet par exemple d'obtenir un langage qui puisse évoluer de manière contrôlée, et servir ainsi de terrain d'expérimentation tout en gardant les avantages de la standardisation. C'est le cas par exemple en CLOS où les classes sont elles-mêmes des instances de métaclasses qui déterminent leur comportement et leur structure. Créer de nouvelles métaclasses permet alors d'introduire de nouveaux comportements (autres schémas de calcul de l'héritage multiple, classes connaissant leurs instances ...), sans modifier pour autant le fonctionnement normal du système (Cointe & Graubé 1988, Graubé 1989, Kickzales & al. 1991). La plupart des langages orientés Objets mettent en avant les notions conjointes de Classes et Métaclasses. Cette approche s’est révélée une solution adéquate pour mettre en place des mécanismes de réflexivité (cf infra avec CLOS), que l’on peut qualifier de réflexivité structurale. Cela signifie que toutes les données présentes dns le système sont réifiées (données et programmes). Le développement des langages à prototypes tels Self a mis en avant de manière plus précise la notion de reflexivité comportementale qui introduit la notion de réification de l’exécution d’un objet : cet aspect n’a pas été résolu dans le premier type de langage et est en cours de développement avec le second (Self (the Self Group 1987-1996), Moostrap (Cointe & Mulet 1993)). Il importe de préciser tout de suite que le développement de réflexivité et d’architectures à méta-niveaux ne signifie qu’il soit nécessaire de développer ou utiliser des langages qui soient eux-mêmes complètement réflexifs. Il s’agit plus précisément que ces langages permettent de spécifier ou d’engendrer des activités réflexives pour répondre à des sollicitations précises et à des besoins particuliers prédéfinis.

9.5.2. Clos et la Réflexivité

 

 

CLOS encourage un style de programmation qui fasse de chaque classe une sorte de boite noire à laquelle les utilisateurs n'ont accès que par l'interface fourni par les fonctions génériques sans qu'ils puissent connaître le détail de l'implémentation. CLOS ne force cependant pas à séparer nettement les comportements "privés" de la classe, accessibles par ses instances et les instances de ses sous-classes, et les savoir-faire "publics", utilisables par le tout-venant, sauf à recourir au Meta-Object-Protocol (MOP par la suite).

9.5.2.1. Méta-Object

9.5.2.2. Le MOP de CLOS

 

 

CLOS est défini en termes d'objets : aux classes, aux définitions de champs, aux méthodes, aux fonctions génériques correspondent des méta-objets qui réalisent le méta-protocole. Ce méta-protocole permet à l'utilisateur de se définir ses propres méta-classes (par exemple des classes qui connaissent toutes leurs instances) et d'écrire des extensions portables de CLOS. L'apport CLOS est que ces sur-langages gardent comme sous-bassement les potentialités de CLOS, tout en les redéfinissant. L'utilisation du MOP pour construire une couche supplémentaire de la représentation des informations dans l'analyse syntaxique faite par Olmes a permis d’enrichir considérablement la connaissance de l'utilisateur sur ce qui est en jeu dans l'analyse syntaxique (-> annexe chapitre 9 : trace d'une analyse). Le Méta-protocole de CLOS est construit de telle sorte que l’utilisateur de processus réflexifs peut spécifier les éléments sur lesquels il a besoin de définir une utilsation de tels mécanismes. "For this class, this slot, perform slot access in this different way" plutôt que "To all accesses, this different way" (Kiczales 1990). La structure méta définie en CLOS s’inscrit dans le même modèle que celui dans lequel CLOS est construit. Les éléments de base de CLOS (classes, méthodes, fonctions génériques) sont définis comme des objets : i.e, chaque classe, chaque fonction générique, chaque méthode est représenté sous la forme d’un métaobjet. Le terme "Classe métaobjet" réfère aux classes dont les instances sont des métaobjets. Chaque classe est représentée par une Classe métaobjet qui enregistre ses superclasses, les slots définis dans la classe et les slots hérités. Et tous les mécanismes qui définissent les comportements des objets (héritage de slot, structure des instances, accès au slot, initialisation d’instance...) sont codés au niveau du métaprotocole par le biais de fonctions génériques qui agissent sur les Classes métaobjet.

 

 

Figure 9.6 : Classes MetaObject en CLOS.

 

 

Il est possible de d'envisager de mettre en place des outils de "surveillance" de toutes les informations présentes au cours de l'activité d'un processus en cours. Par exemple si on envisage de ne manipuler au cours de l'analyse que des objets, il est possible d'établir un historique des accès aux champs des classes manipulées. Si les traits utilisés dans la grammaire sont associés à des objets, on peut ainsi tracer la circulation de ces traits au cours de l'analyse. Le MOP fournit cette possibilité en utilisant ce que (Bobrow & al. 1990) nomment le Monitoring-Slot-Access. Pour ce faire il faut définir un métaobjet. Les classes dont on souhaite faire un historique de l'accès à leurs champs héritent de cette classe. L'utilisation habituelle du protocole d'accès permet ainsi de mettre en place ce travail d'enregistrement des accès aux champs. La généricité étant ce qu'il convient d'utiliser sous CLOS, on peut aussi envisager de construire un compteur qui enregistre le nombre de fois où une fonction générique et les méthodes associées sont appelées. Pour ce faire on peut en effet définir au niveau du MOP des fonctions génériques et des méthodes qui réalisent cette incrémentation. On peut ainsi établir complètement l'historique des interactions entre les objets. Ces informations ajoutées aux informations fournies par le Monitoring-Slot-Access pourraient donc produire une importante trace de l'activité d'un analyseur syntaxique. Il serait alors possible d'établir un relevé de toutes les opérations exécutées et d'identifier par exemple les performances de ces opérations.

9.5.2.3. Les limites de change-class

 

 

Si on change la définition d'une classe donnée, cette opération peut conduire à perdre des informations mémorisées par des instances déjà créées (Habert 1996). A moins de définir des prologues ou des épilogues qui accompagnent les redéfinitions de classe (Ibid.). Ces accompagnements posent malgré tout des problèmes d'une extrême finesse, et impliquent une attention particulière pour mettre à jour les classes existantes. Surtout si on envisage de modifier dynamiquement les définitions des structures définies dans un processus de classification automatique ou de gérération dynamique des savoirs associées. De plus changer la définition des classes existantes nécessite un méta-regard sur le processus de représentation en cours pour évaluer les interactions ou concurrences à l'oeuvre dans les savoirs à représenter et dans les objets déjà exitants. Une maîtrise totale des savoirs en jeu implique un méta-contrôle sur les objets construits ou à construire (et donc les méta-outils associés) qu'il n'est évidemment pas trivial de définir. S'il est possible de changer la définition d'une classe et de propager ce changement aux instances d'icelle (en respectant les mises en garde précédentes), il est aussi possible de changer la classe d'une instance donnée (Ibid.). La fonction générique change-class est l'outil qui réalise cette opération. Cette fonction générique a malgré tout des limites. Elle opère un transfert d'information entre les attributs communs aux deux classes en jeu (les valeurs des attributs de la classe d'origine passent dans les attributs de la nouvelle classe), et initialise les attributs spécifiques à la nouvelle classe avec les valeurs définies par défaut dans celle-ci. Par contre les attributs spécifiques à la classe d'origine sont oubliés. Cette opération peut donc conduire à une perte d'information. Et il n'est pas sûr que cette perte d'informations soit justifiée/voulue dans tous les cas. On peut ainsi vouloir, pour une instance donnée, changer sa classe pour y préciser certaines caractéristiques que l'on ne possède pas encore (du type : moulin devient +humain dans moulin à paroles), tout en conservant certaines informations déjà présentes.

9.5.3. Self et la réflexivité

 

 

Comme on l’a vu dans la présentation de Self faite précedemment, une des caractéristiques de Self est que les objets manipulés sont complètement déterminés par les comportements qui leur sont associés. Cette priorité de représentation permet une extension et une flexibilité dans le développement de nouvelles applications. Self dispose aussi d’une facette fondamentale : on peut souhaiter pouvoir examiner ou manipuler les objets au cours d’un processus de calcul. On utilise les objets comme des données et non plus seulement comme des entités associées à la représentation d’un concept. Ce type de réflexivité permet de "parler" à propos d’un objet plutôt que de lui parler (via l’envoi de messages en Self). Cette action est faite en Self avec des objets appelés miroirs.

9.5.3.1. Réflexion de structure en Self

 

 

La notion de reflect

 

Un objet Self est essentiellement un dictionnaire (association attributs et valeurs). Les attributs peuvent être constants ou modifiables, parents ou non, privés ou publics. Ces informations sont conservées dans des entités appelées maps. Une réflexion de structure est introduite en Self par des entités appelées miroirs. Ces entités rendent visibles au niveau du langage les informations contenues dans la représentation interne des objets. Un miroir sur un objet x permet essentiellement de faire des requêtes sur la représentation interne de cet objet. Dans la réalité, les miroirs sont des objets qui ne contiennent aucune information en eux-mêmes. Un miroir est simplement un receveur capable de répondre à un ensemble de primitives du système qui donnent accès en lecture aux informations sur l'objet.

9.5.3.2. Réflexion de comportement

 

 

Dans les langages à taxonomie de classes, les classes et les méta-classes définissent la réflexion de structure. Dans les langages à prototypes de type Self, la notion de classe n’existe pas pour définir un modèle d’auto-représentation des objets. (Cointe & al. 91) propose une implémentation de la réflexion de comportement en Self. Ce protocole est basé sur l’utilisation de méta-objets pour décrire le comportement des objets lors de la réception des messages. A chaque objet Self est associé un méta-objet dont la fonction est d'expliciter la manière dont l'objet se comportera à la réception d'un message. Le problème de la régression infinie par le lien "méta" est réglé par l'introduction un méta-objet de base, BasicMetaObject, qui s'admet lui-même comme son propre méta-objet et qui définit les comportements de base pour la recherche des attributs et leur application. Le lien "méta" peut être explicite (via un attribut metaobject) ou implicite (dans ce cas l'objet a pour méta-objet BasicMetaObject).

 

A l'envoi d'un message, l'interprète effectue les opération suivantes :

 

• 1. Il envoie au méta-objet du receveur le message

 

`lookup: From: SendingMethodHolder:`

 

effectuant la recherche de l' attribut et retournant un descripteur de l'attribut représentant l'attribut trouvé.

 

• 2. Il envoie ensuite à ce descripteur d'attribut le message

 

`slotApplyTo: WithArgs:`

 

qui déclenche l'exécution du contenu de l'attribut trouvé.

 

 

Figure 9.7 : Exécution de message en Self.

 

 

Ce protocole réifie l'exécution des messages en paramétrant la recherche des attributs et leur application. Les messages

 

`lookup: From:SendingMethodHolder:`

et

`slotApplyTo: WithArgs:`

 

fournissent les points d'entrée nécessaires pour introduire les modifications voulues par l'utilisateur. Le protocole de réflexion de comportement est donc basé sur l'utilisation de méta-objets pour décrire le comportement des objets lors de la réception de message. L'exécution d'un message est décomposé en deux phases : une phase de recherche de l'attribut correspondant au sélecteur (lookup) et une phase d'application de l'attribut trouvé dans le contexte de l'objet receveur. Cette extension pose des problèmes fondamentaux sur le développement de protocole de réflexion de comportement : la notion de lien méta est à étudier, une réification totale des attributs semble difficile à mettre en place en Self. La réflexivité comportementale pose deux problèmes fondamentaux. D’une part, ce type de mécanisme doit décrire le comportement d’un objet agissant sur d’autres objets. D’autre part, on doit pouvoir disposer de moyens pour intervenir sur l’exécution d’un processus affectant les objets du système pour éventuellement modifier le cours des évènements.

9.5.3.3. Moostrap : un noyau réflexif pour un langage à prototypes

 

 

(Cointe & Mulet 1993) propose, avec le langage à prototypes réflexif MOOSTRAP, une nouvelle approche pour une étude de la réflexion de comportement dans un langage à prototype. Il ne s’agit plus de construire une extension d’un langage existant mais de construire directement un langage dans lequel le protocole de réflexion de comportement s’inscrit comme un choix fondamental dans le développement d’un langage à prototypes.

 

9.6. Outils disponibles pour le TALN

9.6.1. Un lien Méta

 

 

Méta-classe : homogénéité du paradigme, toute entité est un objet, ie une instance d’une classe.

 

Définir un lien méta est assurément le plus sûr moyen pour pouvoir disposer de mécanismes qui coopèrent dans un système de représentation des connaisssances réflexif. La question fondamentale que pose ce type de système est le type de distinction qui doit exister entre le niveau méta et le niveau de base. On peut définir un système à architecture méta :

 

• 1°) On met en place un niveau méta de référence. Il s’agit de définir les mécanismes d’inteaction de référence entre le niveau méta et le niveau de base.

 

• 2°) On dispose de plusieurs méta-niveaux indépendants (par rapport au lien méta qu’ils entretiennent avec le niveau de base) et il s’agit dans ce cas de définir les interactions entre ces différents méta-niveaux.

 

Dans le premier cas de figure, on définit un certain méta-niveau et on s’y tient, et parallèlement on met en place les processus réflexifs sur le niveau de base. Dans le second, chaque type de problème étudié dans le niveau de base définit son propre méta-niveau et les processus réflexifs évaluent les interactions entre ces méta-niveaux.

 

 

Figure 9.8 : Un lien Méta.

9.6.2. Analyse Automatique et Méta-niveau

 

 

OLMES offre des points d'entrée distincts pour le linguiste qui affine la grammaire et pour le programmeur qui met au point l'analyseur. Les entités actives lors de l'analyse combinent en effet de nombreuses facettes structurelles ou comportementales : structure de base d'une unité de traitement (type de constituant cherché...), structure et comportement nécessaires aux relations de dominance, mémorisation d'hypothèses syntaxiques et capacité à les déclencher si nécessaire, direction d'exploration (gauche-droite ou inversement), étape dans la vérification d'une règle ou construction du constituant correspondant à la vérification complète de la règle, chaînage avec les étapes précédente et suivante... L'héritage multiple sert alors à organiser le comportement et les structures utilisés par les éléments de la grammaire. Chaque classe créée pour une occurrence de symbole dans la grammaire hérite en effet de différentes classes abstraites qui représentent les différentes facettes du comportement et de la structure de cet élément de la grammaire pendant l'analyse. L'héritage a pour rôle ici de structurer les méta-connaissances. La tâche du compilateur est alors, au vu de la grammaire et des choix de l'utilisateur, de donner les ancêtres adéquats à chaque classe correspondant à un élément de la grammaire, de manière à lui fournir les structures et les comportements pertinents. Ce recours intensif à l'héritage multiple fait coexister des points de vue différents et indépendants sur une règle de grammaire représentée par un graphe de classes et sur son utilisation possible. La multiplicité, organisée, des points de vue possibles sur le réseau de classes permet de créer différents protocoles d'accès nettement distincts. L'utilisateur en particulier doit seulement connaître l'existence du réseau de classes et d'une bijection entre les occurrences de symboles dans la grammaire et les noeuds de ce réseau. Il lui faut connaître en outre un sous-ensemble des facettes que peut comporter un noeud de ce réseau, les facettes les plus proches de sa propre représentation de ce qu'est une grammaire. Enfin, il lui faut connaître la partie correspondante du protocole qu'emploient au moment de l'analyse les entités produites par la compilation, pour pouvoir y greffer traçage et pas à pas, par le biais de prologues et d'épilogues. En CLOS, il est possible en effet d'ajouter des prologues et/ou des épilogues aux fonctions disponibles (cf supra) : ces ajouts sont utilisés pour produire des effets de bord, et, sauf exception, ne changent pas pour le reste le fonctionnement ou la valeur retournée par les fonctions en cause (Muller & al. 1989). Grâce à ce savoir à dessein restreint, et sans devoir pour autant connaître l'ensemble des choix faits pour l'implémentation, l'utilisateur dispose de "vues" orthogonales pour pister le comportement de la grammaire au cours de l'analyse. Dans ce contexte, "orthogonal" signifie qu'il est possible d'observer une facette particulière d'un élément du réseau sans pour autant ouvrir la "boîte noire" et sans être confronté à des détails implémentatoires non pertinents. L'accès donné à l'implémentation se situe à un niveau d'abstraction suffisamment élevé (Kickzalez & al 1991). Il s'oppose aux deux approches qui sont disponibles habituellement lorsque, contrairement à toute attente, l'analyseur ne produit pas de dérivations pour la phrase proposée ou produit des dérivations erronées. La première revient à ouvrir la "boite noire" que constitue l'analyseur : on a recours alors aux outils de traçage et de mise au point du langage d'implémentation. La seconde approche consiste à enrichir la boite à outils de fonctionnalités de traçage spécifique (Boguraev & al. 1988), (Bouchard & al. 1992a). Ces deux approches présentent pourtant de sérieux inconvénients. La première force le linguiste utilisateur à manipuler des structures de données sans rapport évident avec les entités définies dans la grammaire et le lexique, et qui de toute façon sortent de son domaine de compétence propre. La seconde l'oblige à maîtriser une nouvelle couche logicielle qui s'ajoute à l'analyseur proprement dit.

 

Donnons quelques exemples d'utilisation de ce type de pistage :

 

• Lorsque l'utilisateur veut connaître l'utilisation effective des règles de la grammaire sur un corpus donné, le compilateur ajoute un prologue déclenché à la création des instances de la classe correspondant au premier élément d'une règle, et un autre à la création de celle correspondant à la construction du constituant (dans l'exemple choisi et présenté infra, à chaque création d'une instance de DET5 et de GN7). Ces prologues incrémentent des compteurs, ce qui permet de savoir le nombre de fois où chaque règle a été déclenchée et le nombre de fois où elle a réussi. Les résultats fournissent des aperçus instructifs sur l'organisation de la grammaire et permettent de l'améliorer, en ordonnançant les règles par ordre de probabilité. Tracer une règle donnée se traduit par l'ajout de prologues et d'épilogues aux fonctions de combinaison des entités représentant les constituants déjà trouvés avec celles qui représentent les constituants dont la présence est en cours de vérification.

 

• L'insertion de points d'arrêt dans de tels ajouts permet d'examiner en mode pas à pas le fonctionnement de la règle, et donne l'occasion d'explorer à loisir l'environnement d'exécution précisément quand et où c'est pertinent. En outre, il est souvent important dans des formalismes qui associent des contraintes arbitraires aux éléments des règles, comme c'est le cas pour les formalismes d'unification, de pouvoir pister non une règle ni même un ensemble de règles, mais des éléments au sein de différentes règles qui ont recours à un même attribut, de manière à observer la percolation de cet attribut au cours de la dérivation. Un pistage lié aux règles n'est pas approprié : il produit trop d'information. Dans notre modèle, il est aisé d'attacher des instructions de pistage aux seules entités pertinentes, et ceci à travers toute la grammaire.

 

Cette approche de la mise au point est efficace du point de vue de l'utilisateur, dans la mesure où elle repose sur une relation causale et immédiate entre la grammaire de départ et les entités présentes à l'exécution. (Carroll & al. 1991) indiquent d'ailleurs qu'un travail efficace n'est possible que si l'on peut revenir des règles fautives pendant l'exécution à l'endroit de la grammaire où elles sont définies. Par contraste, le traçage proposé par exemple par (Bouchard & al. 1992) permet de voir le graphe évoluer, pas de suivre une règle dans son fonctionnement, tandis que (Boguraev & al. 1988) font le lien entre la grammaire et ses résultats par le biais d'étiquettes attachées aux règles et l'ajout de ces étiquettes aux structures produites... En outre, la distinction est claire entre les traitements normaux et les comportements ajoutés en phase de mise au point.

 

Au total, par la constitution de points de vue, on peut voir dans une approche réflexive une façon de donner une meilleure prise sur des systèmes touffus. Pour reprendre les termes de (Sabah 1993) : "[La méta-représentation] est /./ sélective (ce qui permet une réduction de la complexité du système. En outre, le contenu de la méta-représentation dépend du type de raisonnement qui va l'utiliser : elle est spécialisée (un système 'conscient' a donc la possibilité de disposer de plusieurs méta-modèles du même objet). En conséquence, cette représentation est partielle (ce n'est pas une simple image complète du système, mais une représentation des seuls éléments pertinents pour la tâche considérée)".

 

9.7. Réflexivité : modification des programmes

9.7.1. Hétéro-modifications

9.7.1.1. Savoir ce qui se passe, vers des traces pour linguistes

Etape de mise au point de traceurs.

 

 

Cette phase de mise au point du code de Olmes a permis l’affinement de la présentation des résultats dans le but prédéfini de fournir des informations pertinentes pour les premiers utilisateurs de OLMES à savoir des linguistes. Il fallait mettre en place des mécanismes qui soient capables de tracer les points cruciaux de l’analyse et de fournir des résultats intermédiaires et terminaux pertinents pour les utilisateurs. De plus, la mise au point progressive d’un méta-niveau de l’analyse a permis de garder au delà de l’analyse des informations présentes au moment de l’analyse et donc de pouvoir procéder à une rétro-lecture de ces informations à l’issue de l’analyse.

Les traceurs.

 

 

Les traceurs pour l’analyse avec OLMES utilisent principalement la potentialité offerte par CLOS d’ajouter ou de supprimer des méthodes.

 

• 1. Ajout de méthodes :

 

CLOS permet de réaliser l’ajout d’une méthode à une fonction générique en aval de la création de ces deux entités. Cet ajout se fait grâce à la fonction générique add-method. Cette fonction générique réalise les vérifications de congruence de lambda-list, d’existence d’une méthode utilisant la même forme de discrimination et de l’unité d’utilisation de cette méthode.

 

 

• 2. Retrait de méthode :

 

Les traceurs peuvent à certains moments produire des informations non-pertinentes : on doit pouvoir les activer et les désactiver en fonction de certains besoins particuliers. CLOS offre la possiblité d’exécuter une extraction de méthode en utilisant la fonction générique remove-method. Cette action est rendue possible car CLOS dispose de plus d’une fonction générique (find-method) capable de retrouver une méthode utilisant une certaine forme de discrimination sur ses arguments.

 

L’ajout et le retrait de méthodes before et after s’est révélé être un outil fondamental pour fournir des résultats au cours de l’analyse. On rappelle que la combinaison des méthodes par défaut en CLOS (dite standart) accepte quatre catégories de méthodes, les méthodes primaires, les post-méthodes (:after), les pré-méthodes (:before) et les méthodes englobantes (:around). Les outils de traçage manipulent les post et pré méthodes qui permettent des effets de bord. Les méthodes définies pour l'analyse automatique peuvent être étendues en y adjoignant des pré-méthodes ou des post-méthodes dédiées à fournir des résultats ou des informations sur les objets manipulés par ces méthodes tout au long de leur activité. Les traceurs mis en place ont été développés pour fournir aussi bien des résultats terminaux que des résultats intermédiaires d’une analyse. Un exemple du code défini pour les traceurs est donné en annexe, accompagné des différents résultats produits correspondants aux différentes étapes de développement de ces outils de traçage (-> annexe partie 3 chapitre 9 : une analyse complète est donnée précédée du code complet de l’interface des outils associés à OLMES).

Un méta-niveau dans OLMES.

 

 

La première phase de développement d'un méta-niveau pour OLMES (DINOSOR (Fleury & al. 1992), (GASPAR (Fleury 1992)) a permis d'introduire la nécessité de disposer d'informations sur la grammaire compilée à l'issue de l'analyse. Ce travail a donc consisté à introduire une méta-grammaire pour l'analyse. Il s'agissait de "garder" un point d'entrée sur la grammaire à l'issue de l'analyse. Cette phase de développement d'un méta-niveau a permis de mettre en lumière l'importance de travailler à un méta-niveau pour la mise au point des modifications opérées sur le code initial : c'est grâce au développement d'un méta-niveau intermédiaire (la grammaire normalisée) que la mise au point de la méta-grammaire a été facilitée. Le schéma ci-contre illustre cette première phase de développement d'un méta-niveau pour l'analyse :

 

 

Figure 9.9 : DINOSOR 92 : un premier méta-niveau pour OLMES.

 

Cette phase de développement a permis de mettre en évidence les défauts de cette présentation (<- le problème mentionné de dépendance hiérarchique entre partie gauche d'une règle et partie droite). La solution retenue dans (Habert & Fleury 1993) maintient la définition d'un méta-niveau pour la grammaire comme suit :

 

 

Figure 9.10 : OLMES 93 : une méta-grammaire pour OLMES.

 

 

Cette version a permis de prendre en compte de manière fondamentale la nécessité de mettre en place un méta-niveau pour l'analyse (Habert & Fleury 1993). Les défauts déjà mentionnés sur cette version ont été repris et une version ultérieure a amplifié cette notion de méta-niveau. Le point principal a été de ne plus considérer la partie gauche d'un règle comme la super-classe des éléments de la partie droite d'une règle.

 

 

Figure 9.11 : OLMES 94 : un méta-niveau pour l'analyse avec OLMES.

 

 

Le fait d'éclater la règle en autant d'objets qu'il y a d'éléments dans cette règle a permis notamment dans le travail de traçage de pouvoir isoler la création de chacun de ces éléments pour par exemple pouvoir compter le nombre d'instanciation de ces éléments. Cette phase de mise au point d’outils pour une lecture et une compréhension active de l’analyse a aussi pris en compte la nécessité de disposer d’une interface graphique des résultats fournis par les outils développés.

9.7.1.2. De la méta-connaissance à la réflexivité

 

 

Montrons avec OLMES comment passer de la production de méta-connaissances à une réelle réflexivité, c'est-à-dire à la modification dynamique du comportement de l'analyseur en fonction de ces méta-connaissances. L'objectif d'une approche réflexive est en effet que chaque entité active non seulement possède les moyens d'observer son comportement à l'exécution, mais qu'elle utilise ces "notes" pour modifierm si nécessaire, cs n'est pas ap. CLOS donne des outils pour unetvelle approche réflexive. Il dispose en effet duen Mét-Pprotocole (Kickzalsl & al. 1991):e chaque entité de la cauche'objer-class,e méthode ou h&am - 'est une instance ' une méta-class,e donr, end'’autres terme,t un objes. Pacet que chaque-classe est éaplement un objet, les classes représentant la grammaire de départ possèdant une mémaire proprt, et peuventpPar conséqueet npter leurs'obsermations sur l'analyse. le nombre de règles 'éclenchésn et desuaccès pour une règle peut être mémorité" au sein de chaque règl"). La figurs qui suitmcontre les changements quiens résultent pou, les classes GN7 et (<- exemple présenté supra)ete la mémorisation ;sn essase et dessuaccès dans la version de OLMESeprésentée dans (Habert & Fleury 1993) :

 

Figure 9.92 : Analyse par les instances dans un réseau de classS.

 

 

Figure 9.93 :Mmémorisation ;sn essase et dessuaccès dans les classes d'une règle.

 

 

de nouvelles méta-classes peuvent alorsbseroir à’affiner le comportement dences’unitéts. c'est cette xiste rormettause qui puet permetrde la ré'organisation du réseau par lui-même en fonction dse probabilitées attachées à chaque règle rprèns le aessage des règles sur un corpus ' essas et l'obsermatio dles 'éclencgementsest réaussttes des règle;. Les trnsnformationsrapporhées au modèle le Yonezawat &Ohsawat 190>), le lien entre la grammaire de départ et les entités qui la représenment lort de l'analys,i permettent précisémentcCette action nr retout de l'analyse sur la grammairs.

9.7.2. auto modificatios

9.721.1. Gas;pa

 

 

(<- partie2s chapitres4, 6)e sur la(re) construction ' une représentationisétanmiquesque l on peut'attacher à oulint,iIl s'agte ici d'évalurS commentiIl etrait possible dmérendreceette représentationisétanmique aux nose d'insrgument):e comment mettre enopeuire une catégorisation plus géné lde toue en présrvsant une'ésolution potentvelledreceette représentation initiae ?. La représentationisétanmique proposée supr ;ren; à ;dendifier( à isole)r les comportementsisétanmiqusesque l on peut'attacher à oulint,iIlnconirendsait de restructurer l'organisation des représentatiotsisétanmiquse attachées aux entités représenhées pour disposer d une représentationrouvetre et c'héeante du domaine à représenmr). La figursci- desnons rappelle l'opération de r catégorisation présenhét.

 

Figure 9.94 : Moulint

 

 

,iIlnconiret; de ne ans perdre devque la place decet icro-p'hé novènn dans un système plus compleue, us tout aumsoins de déngagut de lrétude particulière de celuici,r les éléments qui de dépissen).

 

 

Le problème à réoudrle peutsue poser de la manière suivantt :

 

oulinteffecteur cette ré'organisation du savoir? Qquel'est l'im acr d unet;elle ré'organisation sur les savoi;s représenhésr? IIlnconiret; pour cea; de disposer es savoi;s capables de dérectresquet;en comportement attachér à oulint,iIl s'agte enuitre de définir les odnalités ' une ré'organisation des savoi;s para gés. La questiondde savoirsie'uet;en'aménagement est sohsaipable n'est d'ailleurs pas àréaorter:l neori qu-t-ion cas de définir des rgtroptements ;létatoires dont la pertine(ce n'est pasjustlifiée? IIl peut en effety savoir des recoptements entre les comportementsisétanmiqusedde plusieurs classes dx nos>,iIl;faut pouvoir y retrouver une c'héeance àmsoins 'ys perdre toute;soronté de classir les hosses" raisonpablemen").

Un méta-niveau pour l'analyse avec

 

 

>

' approche présentée supr (<- partie2s chapitres7, 8)e réalise une géné ation dynamique des représentatiots prototymiqusn des savoi;s linguismiqusn à parter es données reumeililes sur un corpus. Cillicin met enavtant la nécessité de disposer d’un méta-niveau de représentation pour la uestionddes objets crééts ou àmsodifiee. On doit pouvoirajustter::

 

• des représentatiotsddes objets associés àdces’unitétn de lnogue(’ajout ou retrait d'information)e.

• des processus qui gnissent sur ces’unitéts

• des liets quieexistets entre ces’unitétn( modifierm'ajouter des lietsdl'héritage ou autre sur ces’unitét)t.

 

capable s'agrs dynamiqumsent sur ces-mêmes objett, on doit disposer d outils qui troduslent les-mêmes résultats mais qui gnissent de manière trns paeante pour permetrde une modification dynamique des représentatiots construstes.Oon présenrsci- desnons une uitre l'opératioes qui permettent s'agrs sur les objets représenhésu sans lassir par l interface graphique dn Sele (-> annexe partie 3 chapitre 9 : trace use( méta)'opératioesvias as;pa ).Oon choiste;soronrairement cette solution pour donner à ensrecet que le programms construse réalise qui de manière dynamiqu.

> U2>

 

 

>

), les structures de représentation construstee pourpreprésenmrr les unitétn de lnogue peuvent ésolner à touu moment de leur’existence:, on peutajustte, >remdeoler la représentation des objets en y ajouaint, en y suppritant o, en y modiftant les'informations associétes. Il est doct impossible e;epréuvoir touts, les facettes '’un objet donné:sionne;epréuvoir touts, les ésolatioes que peuventsubnir les représentatiotsddes unitétn de lnogus. Par contle, il reste possible à touu moment de connaître la structure de cet objee. le dispoictif permet à touuu momen,sviasluse( méta)'outils construstt,dl inteproeur les objetspPour connaître leur structure. On donne en annexe (-> annexe partie 3 chapitre )s uneeprésentation us prototyle lexcpal associét aumset as;pa

>

 

 

>

,iIl suffet dt modifier d'objee suivantlles besoin. Nnotre approcheexopéiamentales' accrdei bienaavec la possibilité dans l'environnement programmatique choisi dt modifier interactvtement les représentatiots informatiqusn crééces. L’interface ds Sele permet unevisualnisation des objett, et l utilisateur peut" aui uluer" les coetentsddes différents attributs'u, des méthodes associés aux objet. IIl peut aussi'agrs sur ces différentes facettes '’un obje. Nnunssavnts déjà indiqté qde certaines phasls de travail maquel peuvent être réalihées pour affiner les résultats construstt quand'une cation directs sur les représentatiots produites est nécessair. IIln'enl reste as;msoins qu'ute;part importance de nntre programmsgière automatiquement les savoi;s rn conthéss. Il doit donc pouvoirsdébecatioiner les savoi;s à traitrnsl ln doit'agrs sureaus. Pour réaliserace(type desdébecatio), le dispoictif utiliselles méta outils mis en place par Sele Pour inteproeur la structure '’un objet donné. P rnoans un exemple :

 

B2>

 

 

•[. Cconnaître psur un prototyle les lietsdl'héritage qui qui sont associée

•Ο. Réuopéeretnunssuse parente

•Τ. Reeinir lrduestnatmairevlihét.

 

IT>Oobje parenCchois.

>

 

 

>

effecthées par ces'opératioes dynamiquas de changemens d'éats '’un obje.

>

 

 

>

).Oon dispose avec Sele de mécanismes qui permettentdl inteproeur les attributs '’un objee, on peut en particulier savoirsie'ue attribut donné'est ut attribut qui déblègtue des comportemente. le dispoictif utiliseddonc les mécanismespPour réaliser des opératiotsdeu suppcessioe de liee de débléngction entre objet. Ddans le système as;pa

>

 

 

>

 

as;paMetaLookt qrryForAactvtTtraceAactvtOutputTtrace(<-stre/false

>

 

 

>

as;pa

 

 

effecthé, ’une inte;vention maquelel estinnds enpable Pour interpréner les résultats construst). Leslimiuert de l'automatisationmar;queetleu h&am de travail qu'il reste à>effecteur maqueleement pou,emener à bienlLe classementddes unitétn lexcpaee;. Le classementjà mettre en place estfportement dépendats des informations quisont permis de définircLe classemens. Il reste doct nnds enpable de l inteproeur sur la atturr des informations linguismiqusnqqui sont manipulérsu psurcLe classemens.Ldes informations reumeililesacntuelumsent e amoent oiuvent être einfoclérsucet affi;éces.Nnotre travail ;oit u'ute;part précitresquelel est la atturr des informations à traitrnjee suivantlles informations manipulérs,esque (type de classement Onobntien,u et que (type de classement veu-oun ou veu-oun btvenir sur labhase de ces informations. Il doit aussi mettre en place des processustprènsfoins de classement capables de mettre de loerdre dans les structures construstes.Pplus précisémen, puri qunlLe classement présenté suprs met en place des lietsdds débléngction entre des prototylus et des rôles uencomportements para gé, ’une'automatisation plusffins decde classementddoit lassir par la mise en place d’unvaeste et compleus réseau des lietsdds débléngctios. Il reste doct àrévvalurS les interactions>nt cocur;eancns qu'uet;en réseau inrus. IIlnel suffet cas ''ajouter des lietsdds débléngction danstnuns lessents pour troduire de classementesccompné. IIl;faut pouvoirrévvalurS les mplficatious de la mise en place>effectvtn de plusieurs lietsdds débléngction sur un même prototyle donné:siIl;faut par exemples'lasturersque l onuneeproduit cas rbi trarnementdme l'mbiguïe;té dans les liets mis en placs. La questiondde l'ettentationros de lanon-'ettentatio,e par le système lui-mêm,s desuse propres représentatiots'est ut pointctrui ls pourls'justtement co;epaques.Oon coaçoit donc qu'il ;oit nécessairc de disposer es processus qui gnissent à un méta-niveau et qui ;oment har gér de cs notrrôl (Bachimoent 1992>. Les outilseprésenhésu précédmementune consicuenst qu'ute première phase de développement uet;ees outils en notrrôl.

 

 

> U2>

 

 

>

des objets construste oiuvent évvalurS leurs fonctiongementsest leursncomportements patr appore aux’autres objet. IIlnconiret; donc de mettre en place des processusfints pour permetrde aux objete construste er donner unebdonne decriptsnn; ' au--mêmesafinesql ls purisment comp;ere cettedeecriptsnn; àcel;les usx’autres objet. Sie deux objeta(reeprésentant des mtes ou des rb;es); oiuvent"dtiaogquer" psurrévvalurS lours decriptsnnes rspfectvtns>nt el;les ut leursncomportemente,iIlnconiret; qde ces objetspurismentractvtur des processus capables de troduirecers decriptsnne. De plus, dans la;meturro&uagrave; des objets construste sontssu;epanibles d'ésolnee,iIlnconiret; qde les processus ''aut eecriptsionddes objets construstt urisment être affi;ést dynamiqumsent psurtvenir compte de ces ésolatioes potentvellt. Sele permet la mise en place de mécanismes qui réalisent cettedeecriptsionddes attributs '’un objet donné à touu moment de son’existence dans le systèms. La mise enopeuirednet;elles opératiotsiuretnuns les objets ue système construse reste àfsair. Dde mêmeiIlnconiret; de psussuivre la mise en place de processus capables l inteproeurpplus précisémens les attributs( uencomportement)e attachéts aux mtesmet àceaux des rb;ess associésssi l'on veut donner ue iets aux savoi;naionir représenhéss

> U2>

 

 

>

ae phase de travail qui consises à reférur les savoi;s comuons uris àddéfinirmet àc réner les rôles uencomportements para gée peut êtrelasrmiulérs à une première'éape, dans la construction re nouv aux savoi;s. Cillicin restemalg;té touu à’affinermet à développre. Ces rgtroptements es savoi;n para gér par un ensemble de prototylus lexcpauxour par un ensemble de prototylus ' rb;ennei sonteen effet cas ;dendifgérourncomtéte. l'opération qui consises àrévvalurS la rsnsembtancencomportemenagle entre les otes me qaplifne ansaees rsnsembtancts conscatéess

> U2>

 

 

>

> U2>

 

 

>

ae phase de réné ation de prototylus mise en place suprs (<- partie2s chapitr 8)tireconstruse systétatiquementmet detnuuts,pmiè ces’un nouv ar prototyle l lnn'’exists ac un eeprésentant ei aafnamlgle catégorelgle sansvhérifeurpplusavtantssi ees prototylus exisaenti sont capables defpouinir des informations pour la réné ation ci re nouvls élémen. IIl etrait en aietmpossible e; modifier cette réné ation de prototyli en utilisant de manière plusffins les savoi;sddéjà construsse. Ce qui permetrsait de plus ' mtélio;rur les penformances ue système construseienlimiusant par exemple le nombre d'écrictures sur ri qun d'informatione rénéhées Pour réaliser la réné ation '’un nouvln obje. Ent effe,eeen examisant plus précisémens la structure des objets déjà construsse,iIlnel etrait plunnnécessairc deireconstruure detnuuts,pmiè ces’un nouvln objee, En l ispirsant de la structure des objets construsse,iIl sufftrait d'justter ces structures pour troduire de nouv aux objets en utilisant par exemple ees règles de réné ation suivantst :

 

 

> > > > >

 

oulle ' rb;enjàxs comosanst

oulle En lappuyannt sur ce prototyl:

 

 

oulle ' rb;enjàxs comosanstu>

oulle En lappuyannt surA;t.

 

>
>
>
>
>

> U2>

 

 

>

Cette trace useerrleurelasrmiude l'appretiessagr mis en place à un processus quienbrgisntrt le poictif et lennéngctf

 

 

 

 

as;pa

 

 

 

Figure 9.5 : Sachémla lobpalddes activitétsgas;pairenmes.

 

 

 

 

as;pa as;pa)t c

 

• Uun oou llddecalculnisétanmiquedres séquences ueotyle ouline àN2e

 

• Uun oou ll pour la réné ation automatique de prototylus dt mtsete de prototylus ' rb;enjà parter es savoi;n’etrsaisr sur corput (<- partie2s chapitr 8)t.

 

• Uun oou lldLe classementddes prototylus construss, usddisponibles (<- partie2s chapitr 8)t.

 

• Uun oou ll mét (<- paa grapees précédens)t.

 

Ces objets sont lort maniputiblesent modiftiblesjà;sorontéent de manière dynamiqu

 

 

• Uun oou lldl'analysf yentxmiqus (<- partie2s chapitres5,s6)t.

 

ae arosour permee plusieursauluenactvtns lort d une'analysf::

 

• IIl peut travailler( à a; d madr)naavec ees cotrsaentes préddéfinees (<- partie2s chapitr 5,s6)s ou avec les cotrsaentes rénéhées automatiquement (<- partie2s chapitr 8)t.

 

• IIl peut utiliserldes différenes'opéraieurs mis en place pour la construction automatique l rb;ess parsubnsicuationrosadjfonctiot (<- partie2s chapitr 8)t.

 

• IIl peut'actvtur( à a; d madr)nlue mou ll particulier decalculnisétanmique sur les séquences ueotyle ouline àN2

 

• Lee arosour poue efine utiliser( à a; d madr)nlues représentatiotsddéjà construstee pourene troduire dynamiqumsent ue nouvl les (<- partie2s chapitr 8 fet caa grapees précédens)t.

 

as;pa ).>aefFigure qui duit présenrspplus précisémens les activitétsgas;pairenmes mis;n en place pour ''analysf::

 

Figure 9.69 :Aactvvitétsgas;pairenmee pour ''analyss.

 

 

 

 

. Les outilsdde eeprésentationdoiuvent doct et as;fi eur les savoi;s représenhésr:s les structures de représentatios construsteedoiuventirsnlérsuouvneuts,jet ésolctvtns. La mise en place det;elles structures de représentatios ésolctvtns pour us traitemene automatique ue lno;agenatturee osmt le robltème fondamentae du notrrôl eormaueet à définir pour maineinir une c'héeanceddans ledo maide représenré. Et, on praçoitacisémens les diffi ultése auqqueles cneeest cofrronté Pour réaliserune dispoictifdde traitemene automatiqur:s ae lnogueparticue: unagrand nombre es connaissancenjet"smtjpot"r de leurs représentatiot. ;

 

;

 

Figure 9.7r:s Mét- pespfectvts.

 

 

 

 

 

 

I2>

 

.;