Vers les grammaires de configuration - Laurent Henocque

Université Paul Cézanne Aix-Marseille IIIN o attribué par la bibliothèque2 0 0 6 A I X 3 0 0 5 6Vers les grammaires deconfigurationTHÈSEpour obtenir le grade deDOCTEUR DE L’UNIVERSITÉ Paul CÉZANNEFaculté des Sciences et TechniquesDiscipline : Informatiqueprésentée et soutenue publiquement parMathieu ESTRATATLe 21 Novembre 2006Directeur de thèse : M. Laurent HenocqueEcole Doctorale de Mathématiques et d’Informatique de MarseilleJURYM. Philippe Blache ExaminateurM. Denys Duchier RapporteurM me Hélène FargierExaminateurM. Laurent Henocque Directeur de thèseM. Philippe Jégou ExaminateurM. Markus Stumptner RapporteurANNEE 2006

A Odette,

RemerciementsPremièrement je souhaite remercier Philippe Blache, Denys Duchier, Hélène Fargier,Philippe Jégou et Markus Stumptner pour avoir accepté de faire partie de mon juryet pour avoir fait le déplacement. Je remercie plus particulièrement Denys Duchier etMarkus Stumptner en leur qualité de rapporteurs et pour les nombreuses remarquesconstructives qu’ils ont su me faire.Je tiens tout spécialement à remercier Laurent Henocque pour son soutient et sonengagement au cours des 4 dernières années. Il a su, tout d’abord durant le dea, medonner envie de continuer puis, durant la thèse, il a su encadrer mon travail afin queje travaille de manière autonome mais sans jamais quitter mes travaux des yeux. Merciinfiniment, Laurent.Je souhaite adresser un grand merci à Philippe Jégou, pour son soutient permanentet la confiance qu’il m’a accordé, ainsi qu’à tous les membres de l’équipe InCA au sein delaquelle j’ai effectué ma thèse. C’est une équipe dynamique, où toutes les personnes sontouvertes et disponibles, qu’elles trouvent ici toute ma reconnaissance. Je remercie plusparticulièrement mon collègue de bureau et ami Mathias. Je n’oublie pas les générateursde bonne humeur générale, ni les sportifs (les deux catégories n’étant pas exclusives). Etplus généralement, toutes les personnes que j’ai côtoyé au cours de cette thèse et, avecqui, j’ai passé d’excellents moments.Je remercie chaleureusement Raphaël La Greca avec qui j’ai pu travailler dans lecadre du pôle modélisation géométrique ainsi que Marc Daniel pour m’avoir permis departiciper au Groupe de Travail sur la Modélisation Géométrique.Aurais-je terminé ces trois années sans l’aide de ma « famille » marseillaise ? Je nesaurais le dire, mais j’en remercie très chaleureusement tous les membres que je ne citeraipas, par peur d’en oublier. Je remercie également mes autres amis, plus éloignés, que jene vois que très rarement, mais qui ont su me m’apporter tout leur soutient.Que ma très chère Laure, qui a su me porter jusqu’au bout de ce travail, tant parses encouragements que par ses sacrifices, trouve dans ces quelques lignes, l’expressionde mes immenses remerciements.Et enfin, parceque sans eux, je serais perdu, je remercie Régine, Pierre, Michèle,Denise, Gérard, Jérôme, Sandra, Louise, Georges, Odette et Alfred.

Sommaire1 Introduction 121.1 Cadre scientifique général . . . . . . . . . . . . . . . . . . . . . . . . . . 141.2 Nouveauté de l’approche . . . . . . . . . . . . . . . . . . . . . . . . . . . 151.3 Démarche expérimentale . . . . . . . . . . . . . . . . . . . . . . . . . . . 151.4 Contributions originales . . . . . . . . . . . . . . . . . . . . . . . . . . . 161.5 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171.6 Plan de la thèse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172 Etat de l’art 192.1 Les grammaires . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192.1.1 Structures de traits . . . . . . . . . . . . . . . . . . . . . . . . . . 192.1.2 Les grammaires de dépendances (GD) . . . . . . . . . . . . . . . 222.1.3 Les grammaires syntagmatiques généralisées (GPSG) . . . . . . . 242.1.4 La grammaire syntagmatique guidée par les têtes (HPSG) . . . . 252.1.5 Les grammaires de propriétés (GP) . . . . . . . . . . . . . . . . . 262.2 La configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272.2.1 Présentation de la configuration . . . . . . . . . . . . . . . . . . . 272.2.2 La configuration orientée objet . . . . . . . . . . . . . . . . . . . 283 Les Modèles Objet Contraints : formalisme et formalisation 313.1 Représentation formelle des modèles objet contraints . . . . . . . . . . . 313.1.1 Les types Objet et Classe . . . . . . . . . . . . . . . . . . . . . . 323.1.2 Les attributs de classe . . . . . . . . . . . . . . . . . . . . . . . . 323.1.3 Les relations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333.2 Les contraintes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363.2.1 Opérateurs de dé-référencement . . . . . . . . . . . . . . . . . . . 373.2.2 Définition de nouveaux opérateurs . . . . . . . . . . . . . . . . . 373.2.3 Une modélisation formelle adaptée . . . . . . . . . . . . . . . . . 393.3 Sémantique de type modèles finis . . . . . . . . . . . . . . . . . . . . . . 393.3.1 Interprétation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393.3.2 Un exemple d’instance . . . . . . . . . . . . . . . . . . . . . . . . 413.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43- 4 -

SOMMAIRE4 Méthode de recherche de modèles finis pour les modèles objetcontraints 444.1 JConfigurator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 464.1.1 Domaine d’interprétation . . . . . . . . . . . . . . . . . . . . . . 464.1.2 Traduction d’un modèle objet contraint en un problème JConfigurator. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 464.1.3 Un outil correct et complet . . . . . . . . . . . . . . . . . . . . . 494.1.4 Une traduction modulaire . . . . . . . . . . . . . . . . . . . . . . 494.2 Exemple de problème de configuration : l’assemblage d’ordinateur . . . 514.2.1 Le modèle objet . . . . . . . . . . . . . . . . . . . . . . . . . . . 514.2.2 Les contraintes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 524.2.3 Modèles trouvés . . . . . . . . . . . . . . . . . . . . . . . . . . . 545 Les grammaires de configuration 605.1 Définition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 605.2 Un exemple de langage hors-contexte . . . . . . . . . . . . . . . . . . . . 645.3 Application au scrambling language . . . . . . . . . . . . . . . . . . . . . 655.3.1 Les grammaires de configuration lexicalisées . . . . . . . . . . . . 655.3.2 Le scrambling language . . . . . . . . . . . . . . . . . . . . . . . 665.3.3 Prise en compte du gap-degree . . . . . . . . . . . . . . . . . . . 695.4 Application aux grammaires de propriétés . . . . . . . . . . . . . . . . . 725.4.1 Traduction des propriétés en un modèle objet contraint . . . . . 725.4.2 Traduction automatique d’une GP . . . . . . . . . . . . . . . . . 775.5 Implémentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 915.6 Application aux grammaires de dépendances . . . . . . . . . . . . . . . 935.6.1 Formalisation des principes . . . . . . . . . . . . . . . . . . . . . 985.6.2 Traitement du lexique . . . . . . . . . . . . . . . . . . . . . . . . 996 Une approche du traitement sémantique des textes descriptifs 1016.1 Une sémantique des textes descriptifs . . . . . . . . . . . . . . . . . . . . 1016.2 Les schémas sémantiques . . . . . . . . . . . . . . . . . . . . . . . . . . . 1026.2.1 Schéma de possession . . . . . . . . . . . . . . . . . . . . . . . . 1046.2.2 Schéma d’attributs . . . . . . . . . . . . . . . . . . . . . . . . . . 1087 Une application : la modélisation déclarative de surface 1137.1 Modèle sémantique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1147.2 Implémentation et résultats . . . . . . . . . . . . . . . . . . . . . . . . . 1168 Conclusion 119A Exemple de programme ILOG JConfigurator 121A.1 Contraintes génériques . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121A.2 Résultats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126- 5 -

SOMMAIREB Une approche des HPSG 132B.1 Lists et sets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139B.2 Structures de traits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141B.3 Les principes HPSG vus comme des contraintes de modèle objet contraint 144B.3.1 Le principe des traits de tête . . . . . . . . . . . . . . . . . . . . 144B.3.2 Le principe des traits non locaux . . . . . . . . . . . . . . . . . . 144C Fragment du UML Core utilisé pour les modèles objet contraints 146Bibliographie 152- 6 -

Table des figures1.1 Sémantique formelle associée à la phrase « Le pc possède deux disquesdurs » . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121.2 Interprétation simpliste associée à la phrase « Le pc possède deux disquesdurs » . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131.3 Arbre syntaxique pour la phrase « Le pc possède deux disques durs » . . 132.1 AVM pour le trait genre du nom commun ordinateur . . . . . . . . . . 202.2 Graphe orienté pour le trait genre du nom commun ordinateur . . . . 202.3 AVM pour l’accord du déterminant et du nom dans un SN . . . . . . . . 212.4 Graphe orienté pour l’accord du déterminant et du nom dans un SN . . 212.5 Graphe des dépendances pour la phrase ”Le pc possède deux disques durs” 232.6 Entrée lexicale en DG pour le mot pc . . . . . . . . . . . . . . . . . . . . 232.7 Règle syntaxique utilisant le formalisme DI/PL . . . . . . . . . . . . . . 242.8 AVM représentant un SN . . . . . . . . . . . . . . . . . . . . . . . . . . 262.9 Un exemple de configuration - Modèle générique d’un PC . . . . . . . . 293.1 Représentation UML2 de la classe A . . . . . . . . . . . . . . . . . . . . 323.2 Une classe contenant un attribut . . . . . . . . . . . . . . . . . . . . . . 333.3 Notation UML2 de la relation d’association . . . . . . . . . . . . . . . . 343.4 Notation UML2 de la relation de composition . . . . . . . . . . . . . . . 353.5 Relation d’héritage : A et B héritent de C . . . . . . . . . . . . . . . . . 363.6 Définitions des opérateurs de dé-référencement . . . . . . . . . . . . . . 383.7 Sous-modèle objet du PC . . . . . . . . . . . . . . . . . . . . . . . . . . 393.8 Modèle objet d’une carte mère et de ses composants . . . . . . . . . . . 413.9 Une solution possible pour le modèle objet de la figure 3.8 . . . . . . . . 434.1 Un modèle objet cyclique . . . . . . . . . . . . . . . . . . . . . . . . . . 454.2 Un modèle objet non cyclique . . . . . . . . . . . . . . . . . . . . . . . . 464.3 Modèle (UML) de données générique pour représenter un PC . . . . . . 524.4 Objets disponibles pour la recherche de modèle fini dans l’exemple du pc 564.5 Résultats de la propagation des contraintes sur l’ensemble d’objets initial 574.6 Arbre de recherche pour la première solution du problème du pc . . . . 584.7 Arbre de recherche pour une autre solution du problème du pc . . . . . 59- 7 -

TABLE DES FIGURES5.1 Formalisation des classes et des attributs du modèle objet des grammairesde configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 615.2 Formalisation des relations du modèle objet des grammaires de configuration 625.3 Modèle objet des grammaires de configuration (Notation UML2) . . . . 635.4 Contraintes génériques pour toute grammaire de configuration . . . . . . 635.5 Modèle objet pour le langage a n b n . . . . . . . . . . . . . . . . . . . . . 645.6 Exemples de parsage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 655.7 Drawing appartenant à la classe D 1 . . . . . . . . . . . . . . . . . . . . . 665.8 Example de drawing codant un mot reconnu par le langage SCR . . . . 675.9 Modèle objet de la grammaire de configuration codant la grammaire SCR 685.10 Instances communes à toutes les solutions (codant l’entrée) . . . . . . . 695.11 Instances solutions pour le scrambling avec k = 3 . . . . . . . . . . . . . 705.12 Insertion du traitement des gaps dans modèle objet des grammaires deconfiguration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 715.13 SX peut avoir comme tête {A 1 , .., A n } . . . . . . . . . . . . . . . . . . . 735.14 SX peut contenir une ou plusieurs catégories parmi {B 1 , .., B m } . . . . . 745.15 Représentation de la relation de constitution . . . . . . . . . . . . . . . 755.16 AVM des catégories terminales . . . . . . . . . . . . . . . . . . . . . . . 815.17 Sous-modèle représentant les catégories terminales de la grammaire descriptive. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 825.18 Catégorie SN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 835.19 Sous-modèle pour la propriété de tête du SN . . . . . . . . . . . . . . . 835.20 Sous-modèle pour la propriété de facultativité du SN . . . . . . . . . . . 845.21 Sous-modèle pour la propriété de constitution du SN . . . . . . . . . . . 845.22 Catégorie SPrep . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 855.23 La propriété de tête du syntagme prépositionnel . . . . . . . . . . . . . 865.24 Eléments facultatifs d’un syntagme prépositionnel . . . . . . . . . . . . 865.25 Catégorie SV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 875.26 La propriété de tête du syntagme verbal . . . . . . . . . . . . . . . . . . 885.27 La propriété de facultativité du syntagme verbal . . . . . . . . . . . . . 885.28 Catégorie SAdv . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 895.29 La propriété de tête du syntagme adverbial . . . . . . . . . . . . . . . . 895.30 Catégorie Phrase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 895.31 La propriété de tête de la catégorie Phrase . . . . . . . . . . . . . . . . . 905.32 Entrée lexicale du modèle . . . . . . . . . . . . . . . . . . . . . . . . . . 905.33 Modèle objet global de l’analyseur syntaxique de descriptions . . . . . . 915.34 Exemple de quasi arbre unaire pour le N dans notre grammaire . . . . . 925.35 Modèle fini résultat de l’analyse syntaxique de la phrase « Le pc possèdedeux disques durs » . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 935.36 Fragment de grammaire de dépendance . . . . . . . . . . . . . . . . . . 945.37 Arbres ID et LP pour la phrase « Maria einen Mann wird haben liebenkönnen ». . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 955.38 Diagramme de classes pour modéliser les arbres ID et LP . . . . . . . . 975.39 Relations supplémentaires sur la classe CatDep . . . . . . . . . . . . . . 99- 8 -

TABLE DES FIGURES6.1 Schéma de règles syntaxiques pour les phrases de description . . . . . . 1026.2 Concepts de l’analyse sémantique de textes descriptifs . . . . . . . . . . 1036.3 Extrait du lexique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1046.4 Une partie du diagramme de classes pour ScDet . . . . . . . . . . . . . . 1046.5 Diagramme de classes pour ScPoss . . . . . . . . . . . . . . . . . . . . . 1056.6 Le monde construit lors de l’analyse . . . . . . . . . . . . . . . . . . . . 1076.8 Modèle objet pour le lexiconSelector . . . . . . . . . . . . . . . . . . . . 1096.9 Modèle objet pour le schéma d’attribut . . . . . . . . . . . . . . . . . . 1106.7 Instance solution du modèle syntaxico-sémantique pour la phrase « Le pcpossède deux disques durs ». . . . . . . . . . . . . . . . . . . . . . . . . 1127.1 Un plan paramétrique et une surface NURBS correspondante . . . . . . 1137.2 Processus général de modélisation déclarative de surface . . . . . . . . . 1147.3 Modèle sémantique représentant le « monde » des surfaces . . . . . . . . 1157.4 Extrait du lexique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1177.5 Extrait de la table de liaison lexique-sémantique . . . . . . . . . . . . . 1177.6 Une surface solution pour la description étudiée . . . . . . . . . . . . . . 1177.7 Solution pour le problème de modélisation déclarative de surfaces avec laphrase « La surface est rectangulaire » . . . . . . . . . . . . . . . . . . . 118A.1 Modèle (JConfigurator) générique de données pour représenter un PC . 122A.2 Modèle (UML) de données générique pour représenter un PC . . . . . . 123A.3 Boîte de dialogue permettant de spécifier les propriétés d’une relation . 124B.1 Partitions des éléments utilisés dans HPSG . . . . . . . . . . . . . . . . 133B.2 Modèle objet représentant la partition de objet . . . . . . . . . . . . . . 134B.3 Modèle objet représentant la partition de bool . . . . . . . . . . . . . . . 134B.4 Modèle objet représentant la partition de sign . . . . . . . . . . . . . . . 134B.5 Modèle objet représentant la partition de mod-sem . . . . . . . . . . . . 135B.6 Modèle objet représentant la partition de head . . . . . . . . . . . . . . 135B.7 Modèle objet représentant la partition de marking . . . . . . . . . . . . 135B.8 Modèle objet représentant la partition de case . . . . . . . . . . . . . . . 136B.9 Modèle objet représentant la partition de vform . . . . . . . . . . . . . . 136B.10 Modèle objet représentant la partition de pform . . . . . . . . . . . . . . 136B.11 Modèle objet représentant la partition de phonstring . . . . . . . . . . . 136B.12 Modèle objet représentant la partition de con-struc . . . . . . . . . . . . 137B.13 Modèle objet représentant la partition de content . . . . . . . . . . . . . 137B.14 Modèle objet représentant la partition de semdet . . . . . . . . . . . . . 138B.15 Modèle objet représentant la partition de index . . . . . . . . . . . . . . 138B.16 Modèle objet représentant la partition de person . . . . . . . . . . . . . 138B.17 Modèle objet représentant la partition de number . . . . . . . . . . . . . 138B.18 Modèle objet représentant la partition de gender . . . . . . . . . . . . . 139B.19 Modèle objet représentant la partition de qfpsoa . . . . . . . . . . . . . 139B.20 Hiérarchie de types pour les éléments list et set . . . . . . . . . . . . . . 140- 9 -

TABLE DES FIGURESB.21 Définition de la structure d’une liste non vide dans [53] . . . . . . . . . 140B.22 Modèle objet traduisant strictement la définition d’une liste . . . . . . . 140B.23 Instances créées pour une liste de trois éléments . . . . . . . . . . . . . . 141B.24 Première partie des structures de traits présentées dans [53] . . . . . . . 141B.25 Deuxième partie des structures de traits présentées dans [53] . . . . . . 142B.26 Sous-partie du modèle objet représentant les stuctures de HPSG . . . . 143C.1 Fragment du UML Core utilisé pour les modèles objet contraints - issude [35] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146- 10 -

Liste des tableaux6.1 Résultats expérimentaux . . . . . . . . . . . . . . . . . . . . . . . . . . . 107A.1 Nombre de modèles trouvés pour l’exemple de l’ordinateur en fonction dunombre de contraintes spécifiques . . . . . . . . . . . . . . . . . . . . . . 131- 11 -

Chapitre 1IntroductionCette thèse a pour objet d’utiliser la recherche de modèles finis comme un cadreunique pour l’analyse de langages naturels du double point de vue syntaxique et sémantique.Il existe des sous ensembles utiles des langages naturels, notamment ceux décrivant desscènes du monde réel, dont les phrases correctes décrivent des représentations assimilablesà des modèles finis. Par exemple, les phrases « Le camion possède huit roues. »,ou « L’oiseau a des plumes bleues. » sont naturellement associées mentalement à unereprésentation qu’il est possible de corréler avec une interprétation d’une formule logique.La figure 1.1 donne l’exemple d’une traduction logique possible attachée à laphrase « Le pc possède deux disques durs ».∃ x, y, z(y ≠ z ∧ pc(x) ∧ disque dur(y) ∧ disque dur(z) ∧ posseder(x, y) ∧ posseder(x, z))Fig. 1.1 – Sémantique formelle associée à la phrase « Le pc possède deux disques durs »La figure 1.2 illustre graphiquement une interprétation de cette formule 1.1. Dans lasuite nous appellerons « textes descriptifs » les textes construits avec de telles phrasesdescriptives. Les textes descriptifs présentent un intérêt technique général. Ils permettenten effet d’utiliser un sous ensemble réaliste du langage naturel pour interagir avec lesmachines. Ils généralisent en cela de manière pragmatique les langages impératifs deprogrammation, dont la structure syntaxique profonde est identifiée avec la sémantique.Nous en montrons une application à des textes décrivant des scènes tri-dimensionnelles,dans le contexte de la modélisation assistée par ordinateur.Le projet global du traitement automatique des langages naturels demeure l’extractionde leur sémantique. Il est souhaitable d’utiliser un cadre unifié pour l’analysesyntaxico sémantique, de façon à ce que la totalité de l’information soit disponible auparseur, afin que les ambiguïtés locales éventuelles soient éliminées au plus tôt. On peutdonc se demander si la recherche de modèles finis pourrait être appliquée au parsage detextes descriptifs dans sa généralité, combinant syntaxe et sémantique.On observe aisément que le produit de l’analyse syntaxique de phrases pour denombreuses grammaires peut également être assimilé à la construction d’un modèle- 12 -

1 : IntroductionFig. 1.2 – Interprétation simpliste associée à la phrase « Le pc possède deux disquesdurs »fini, dont les catégories et leurs relations décrivent la structure. Par exemple l’analyseillustrée par la figure 1.3 associée à la phrase « Le pc possède deux disques durs » faitintervenir des « objets » (les instances des étiquettes syntaxiques et les mots) qui entrentvia des relations de composition dans une structure ici arborescente, plus généralementun graphe orienté acyclique (DAG) enraciné. Une telle structure peut également êtrevue comme une interprétation d’une expression logique.Phrase SNSV SN Det N V Det NLe pc possède deux disques dursFig. 1.3 – Arbre syntaxique pour la phrase « Le pc possède deux disques durs »La recherche de modèles finis semble donc pouvoir être appliquée au parsage detextes descriptifs. Nous nous proposons de le vérifier, et de mesurer la richesse du cadreproposé. Si le projet de cette thèse est atteint, et l’on verra que nous pouvons considéreracquise une validation qualitative de l’approche, cela présente certains avantages :– la recherche de modèles finis peut être appliquée à des formules « quelconques »,qui ne présentent aucun des biais dénotationnels et opérationnels des langages àbase de règles, et notamment :– il n’est pas nécessaire de traduire une formulation logique arbitraire en tenantcompte de ces biais, par exemple pour produire des clauses de Horn, ou des règlesd’un langage à base de règles exploité en chaînage avant, ou des clauses avecdisjonction exploitées avec une sémantique de point fixe (par exemple les modèlesstables),– un algorithme de recherche de modèles finis générique, appliqué à une formulereprésentant les propriétés d’un langage naturel, induit de façon immédiate un- 13 -

1 : Introductionparseur, pouvant être exploité de façon mixte ou hybride analytique/générative(analyse de phrases/production de phrases).– un tel algorithme, appliqué à une expression décrivant à la fois les syntaxes etsémantiques valides, constitue de facto un parseur capable de produire des représentationssémantiques.Il est important de noter que la description formelle des représentations acceptéesd’un langage naturel donné constitue un préalable nécessaire à la définition de toutparseur. L’approche envisagée réduit voire supprime les efforts de traduction, de formulesarbitraires vers un formalisme exploitable par un outil (clauses de Horn parexemple). Elle est donc susceptible de considérablement simplifier la réalisation desparseurs/générateurs.Par ailleurs, le fait que le parseur implicitement généré soit capable de produireles entrées reconnues par des grammaires permet une utilisation de l’approche pour enassister le développement. La génération constitue en effet un outil puissant de débugdans les situations combinatoires. Alors que la trace d’une recherche énumérative est toutsimplement inexploitable, l’étude des solutions générées est très riche d’enseignements.Si le programme produit des solutions erronées, il est incorrect, ou sur-générateur : sitoutes les contraintes formulées sont exactes, la situation révèle qu’il en manque. Dansle cas inverse, le programme est sous générateur, ce qui signifie qu’une contrainte aumoins est erronnée ou surnuméraire.1.1 Cadre scientifique généralCette recherche s’inscrit dans une dynamique actuelle du traitement automatique deslangues naturelles, incarnée par le cadre du Model-Theoretic Syntactic framework[16, 54](MTS). Dans [54], l’auteur sépare en deux groupes les méthodes de résolutions utiliséespar les formalismes linguistiques : le Generative-Enumerative Syntactic framework(GES) et le Model-Theoretic Syntactic framework (MTS). Ces deux approches s’appuyentsur la logique mathématique. La première hérite de l’analyse syntaxique desformules logiques (théorie de la preuve) et la seconde de leur étude sémantique (théoriedes modèles). Les auteurs de [54] concluent que le cadre MTS est plus pertinent pourl’analyse du langage naturel que GES.La formalisation des grammaires a vu, depuis les années 80, les structures de traitsêtre utilisées pour représenter les composants intervenant dans leur définition. Une structurede traits est un ensemble de couples (attribut, valeur) où la valeur peut être soitatomique (prise dans le domaine de l’attribut) soit, récursivement, une structure detraits. Cette formalisation a été très clairement pointée par de nombreux auteurs commeassimilable à une représentation orientée objet. Nous nous plaçons dans cette filiation enutilisant la recherche de modèles finis appliquée à des expressions logiques particulièresappelées « modèles objet contraints ».- 14 -

1 : Introduction1.2 Nouveauté de l’approcheCombiner analyse syntaxique et sémantique est un objectif ancien de l’intelligenceartificielle, qui a suscité des réalisations significatives. Toutefois cela n’avait à notreconnaissance jamais été tenté dans un cadre logique exploité uniquement par la rechercheénumérative de modèles finis. Analyser syntaxiquement une phrase est à présentbien maîtrisé. Cette maîtrise est notamment due à une analyse lexicale efficace fournissantune labélisation précise des mots de l’entrée, ainsi qu’à des analyseurs syntaxiquesde plus en plus performants. Comprendre le sens d’une phrase est plus difficileet constitue la prochaine grande étape dans le traitement des langages naturels et plusgénéralement dans toutes les disciplines de l’IA. Quasiment toutes les grammaires quel’on peut trouver dans la littérature proposent un traitement de la sémantique. Des logicielstel que ILLICO [50, 51] ont été implémentés et fournissent des analyses syntaxiqueset sémantiques. De même les théories linguistiques telles que la grammaire syntagmatiqueguidée par les têtes (Head-driven Phrase Structure Grammars - HPSG)[52, 53]ou les grammaires de dépendance (Dependency grammars - DG) [17, 61] prennent encompte l’aspect sémantique de la langue soit en l’intégrant à l’analyse de la syntaxe dansHPSG soit comme un module annexe (une dimension) en XDG(eXtensible DependencyGrammar) [17]. Aucun des exemples ci dessus, et plus généralement à notre connaissanceaucune approche existante n’aborde ce problème de manière unifiée comme nousl’envisageons. Il convient de noter toutefois que les grammaires de dépendances fontexplicitement référence à la configuration comme processus de construction de l’analyse.Nous verrons plus loin que nous utilisons également la configuration à base de contraintescomme un outil de génération de modèles finis, ce qui place notre travail dans une perspectivecomparable. Une différence est que nous ne proposons pas de théorie linguistiqueparticulière à notre contexte.L’utilisation des contraintes par les formalismes et outils pour le Traitement Automatiquedu Langage Naturel s’est accrue depuis les années 80. Dans cette disciplinequi rassemble linguistes et informaticiens pour réaliser l’implémentation des théorieslinguistiques sur machine, le recours aux contraintes peut être attesté dès les grammairessyntagmatiques généralisées GPSG [31] (1985) et, bien sûr, depuis les premièresapplications du langage Prolog [15, 50]. Depuis, de très nombreuses approches y fontréférence. Pourtant, les formalismes à base de contraintes classiques, CSP (Constraintsatisfaction Problems) par exemple, sont insuffisants pour atteindre la complexité duprocessus d’analyse syntaxique et/ou sémantique, ce qui justifie l’utilisation dans cettethèse d’un formalisme plus général.1.3 Démarche expérimentalePour valider qualitativement l’hypothèse fondatrice de cette thèse, l’utilisation dela recherche de modèles finis pour le parsage de langages naturels, nous avons eu ladémarche suivante :– définir un modèle objet contraint (MOC) abstrait permettant la prise en compte- 15 -

1 : Introductionde la définition des catégories de certaines grammaires. Une présentation formellede ce MOC garantit la reproductibilité des résultats, indépendamment de la technologieconcrète choisie pour la recherche de modèles finis.– définir le programme Java supportant ce modèle, sur la base du configurateurJConfigurator. Le programme réalisé peut charger des fichiers de définition produitshors de l’outil, notamment par le parseur évoqué ci dessous,– montrer par la traduction modulaire automatique et complète d’une théorie linguistiquereposant sur les contraintes (les grammaires de propriétés) que cetteapproche couvre au moins la totalité d’une théorie grammaticale connue. Untraducteur complet a été implanté en Java, qui s’appuye sur des définitons Latexspécifiques aux grammaires de propriétés. Les exemples de grammaires depropriétés présentés dans cette thèse peuvent être parsés directement à partirdes sources Latex, le parseur isolant les constructions pertinentes et générant lesentrées correspondantes pour l’outil de recherche de modèles.– appliquer le même cadre à la théorie des grammaires syntagmatiques guidées parles têtes (HPSG), dont la traduction d’un fragment est illustrée en annexe de cedocument– ébaucher dans ce cadre l’analyse combinée de la syntaxe et de la sémantique d’unlangage de description simple. Ce travail a fait l’objet d’une implantation appliquéeà la génération de surfaces tridimensionnelles guidée par le langage naturel .1.4 Contributions originalesLes modèles objets contraints constituent une extension des problèmes de satisfactionde contraintes classiques. Il n’existe pas aujourd’hui de formalisme communémentaccepté pour définir ces modèles objets contraints. Ce concept est défini implicitementpar la sémantique opérationnelle d’outils comme JConfigurator [41] ou par la sémantiqueopérationnelle du point fixe des modèles stables dans [57, 56] par exemple. Certains formalismes,comme les Dynamic Constraint Satisfaction Problems (DCSP) [48, 2] restentdes extensions insuffisantes des CSP dans notre cadre car n’offrant pas la possibilité demanipuler des variables ensemblistes. Par ailleurs, le standard UML a popularisé uneprésentation visuelle des modèles objets, dont le langage de contraintes associé OCL estmal accepté par les chercheurs.Permettre la description de modèles objet contraints comme le requiert cette thèsea nécessité l’élaboration d’un formalisme rigoureux d’une expressivité suffisante afin depermettre la reproductibilité des résultats. Nous utilisons un sous ensemble du langagerelationnel Z à cette fin, dont nous donnons également une contrepartie visuelle standardiséepar le langage de modélisation UML, pour faciliter la compréhension des résultats.Les diagrammes UML restent toutefois optionnels. Le langage Z est au moins aussi expressifque la logique des prédicats. Cette formalisation est un apport à la communautédans le sens où nous proposons une représentation formelle à un domaine qui jusque làne disposait que des diagrammes de classes UML2, ou de langages implicitement induitspar les outils. Les diagrammes de classes (UML2) sont suffisants pour la modélisation- 16 -

1 : Introductiondes modèles objet, mais l’apport des contraintes sur ces modèles objet se doit de disposerd’un formalisme commun aux chercheurs du domaine.Un autre apport significatif de la thèse consiste en un modèle abstrait des grammaires,spécifié en Z , et dont un programme d’énumération de recherches de modèlesfinis a été réalisé. Ce modèle abstrait est organisé autour d’une classe Cat dont toutecatégorie de la grammaire hérite, et décrit également à haut niveau l’existence de liensentre entrées lexicales et grammaire.La puissance expressive des modèles objet contraints permet de construire modulairementle parseur de certains formalismes grammaticaux, notamment ceux reposant surles structures de traits. Cette modularité est mise à profit pour automatiser la prise encharge d’une grammaire formelle fournie en entrée, et générer un modèle objet contraintpouvant être utilisé directement comme analyseur par une recherche de modèles finis.Nous avons utilisé le formalisme des grammaires de propriétés [10, 11] pour illustrerl’application de notre approche.1.5 LimitationsSans trop anticiper sur les conclusions et les perspectives, nous devons dire que lathèse ne propose pas de résultats quantitatifs permettant de valider l’approche contred’autres formalismes et outils. Cette situation est partiellement due à des difficultéstechniques liées à l’utilisation d’un outil non maintenu (JConfigurator). Nous ne donnonspas de résultats compétitifs avec d’autres parseurs pour l’analyse de phrases ou de texteslongs, ni pour des grammaires de grandes tailles. La taille du lexique quand à elle resteindifférente, seules les ambiguïtés des mots jouant sur la complexité.Le traitement sémantique de textes descriptifs a été réalisé dans des cas simples, etreste embryonnaire, malgré le caractère spectaculaire et visuel de l’application réaliséedans le cadre de la modélisation déclarative de surfaces.L’utilisation de techniques de recherche de modèles finis, dans un contexte fortementcombinatoire, pose les problèmes habituels des techniques énumératives, que nousn’avons pas ou presque abordés. On peut notamment évoquer les heuristiques, les isomorphismes,les contraintes redondantes, l’utilisation de méthodes incomplètes, etc.1.6 Plan de la thèseLe chapitre 2 est un état de l’art des formalismes linguistiques et de la configuration.La section 2.1 présente les formalismes GPSG, HPSG, PG et DG, utilisés pour le traitementautomatique des langues naturelles. La section 2.2 porte sur la configuration etplus particulièrement la configuration orientée objet sous contraintes. Nous reviendronssur la configuration dans le chapitre 4 dans lequel elle sera utilisée comme méthodede recherche de modèles finis pour les modèles objet contraints dont le formalisme estdécrit dans les deux premières sections du chapitre 3. A cette formalisation, la section 3.3associe une interprétation des modèles objet contraints. Le chapitre 5 définit un cadred’analyse syntaxique, les grammaires de configuration, dont le traitement est effectué par- 17 -

1 : Introductionune recherche de modèles finis. Les grammaires de configuration permettent notammentla traduction automatique de toute instance de grammaire exprimée sous la forme d’unegrammaire de propriété en terme de modèle objet contraint et propose une résolutionutilisant la configuration. Le chapitre 6 présente une approche générique d’interfaçageentre la syntaxe et la sémantique par un sous-modèle objet contraint représentant desponts entre ces deux « univers ». Une de ces interfaces est utilisée pour le traitementd’un problème réel de modélisation déclarative dans le chapitre 7. Enfin le chapitre 8présente une synthèse du travail effectué et, s’appuyant sur des axes de recherches nonexploités ou seulement partiellement utilisés, propose des perspectives de recherches.- 18 -

Chapitre 2Etat de l’art2.1 Les grammairesL’objectif de la grammaire, en son sens premier, est de fournir un ensemble de règlesqui définissent les entrées acceptées pour un langage. Le développement du traitementautomatique du langage a amené un grand nombre de théories linguistiques visant àrendre compte de cette définition. Les travaux du domaine ont abouti à de très bonsanalyseurs syntaxiques, comme par exemple le EngCG-2 [63] qui assigne une étiquettegrammaticale à chaque mot d’une phrase passée en argument, avec un taux de fiabilitéde 99% et à une cadence de 3000 mots par seconde, ou encore, le logiciel ILLICO [50, 51]développé par R. Pasero et P. Sabatier réalise une analyse syntaxique et sémantique desphrases qu’il reçoit en entrée. ILLICO est basé sur des règles PROLOG[15]. Les analyseurssyntaxiques issus des grammaires de propriétés ont quant à eux été très bien classéslors de la campagne EASY (Campagne d’Evaluation des Analyseurs Syntaxiques).Il existe dans la littérature énormément de théories linguistiques. Depuis les années1930 et les grammaires catégorielles, jusqu’aux plus récentes grammaires de propriétés[10]ou grammaire de dépendances extensible[17], les théories linguistiques cherchent à capturerle plus précisément possible les phénomènes du langage naturel. Pour ce faire elless’adaptent très rapidement aux nouvelles techniques de représentation et de résolution.Par exemple, une grande majorité de ces formalismes (pour ne pas dire tous) utilisentles structures de traits pour représenter les composants de la grammaire.2.1.1 Structures de traitsUne structure de traits est un ensemble d’attributs permettant de caractériser unobjet du domaine étudié. Dans ce document, une structure de traits représentera unedonnée linguistique (étiquette syntaxique, fonction sémantique, étiquette phonologique,etc...). Les structures de traits sont très utilisées dans les théories linguisitiques depuis[31].Définition 1 (Structure de traits) Une structure de traits est définie par :1. Un ensemble de couples (trait, valeur), éventuellement vide.- 19 -

2 : Etat de l’art2. Un couple (trait, valeur) comme par exemple (genre masculin) consiste en untrait (genre) et une valeur de trait (masculin).3. Une valeur de trait peut être :(a) Atomique (comme masculin)(b) Complexe4. Une valeur de trait complexe est une structure de traits.Représentation d’une structure de traitsLes structures de traits sont représentées soit par des AVM (Attribute value matrices)comme sur la figure 2.1, soit par des graphes orientés (DG) comme sur la figure 2.2.Ces deux figures représentent le même trait genre du trait accord du nom communordinateur. La valeur du trait accord est complexe : sa valeur est une structure de traits(genre).⎡⎤...⎡⎤...⎢ordinateurAccord ⎣genremasculin⎦⎢⎣...⎥⎦...Fig. 2.1 – AVM pour le trait genre du nom commun ordinateur...ordinateur • Accord•genre• masculin...Fig. 2.2 – Graphe orienté pour le trait genre du nom commun ordinateurPropriété de partage de l’informationLes structures de traits permettent de structurer la représentation d’informations.Elles possèdent également une propriété de partage de leurs structures. Cette propriétépermet de contraindre des traits de structures différentes à avoir les mêmes valeurs.Par exemple, il est possible de rendre compte du fait que le nom et le déterminantdoivent s’accorder en genre et en nombre lorsqu’ils participent à la construction d’ungroupe nominal. La représentation habituelle de ce partage d’information est, pour les- 20 -

2 : Etat de l’artAVM, une boîte contenant un identifiant liant les structures partageant l’informationet, pour les graphes orientés, un arc orienté vers le noeud correspondant. Les figures 2.3et 2.4 illustrent, sur l’exemple de l’accord du nom et du déterminant dans un syntagmenominal (SN), les représentations citées ci-dessus pour les AVM et les graphes orientésrespectivement. Ces représentations sont libres de tout formalisme et ne sont présentesque pour donner une idée du partage d’information au sein d’une structure de traits. Ace titre, nous supposons qu’un SN contient exactement un N et un Det. Nous utiliserons⎡ [⎤"Accordgenre1nombreSN ⎢N⎣]Det[Accord : 1] #masculin ;fémininsingulier ;plurielFig. 2.3 – AVM pour l’accord du déterminant et du nom dans un SN⎥⎦genre• masculin ;féminin • N Accord • nombre• singulier ;plurielAccordSN • • DetFig. 2.4 – Graphe orienté pour l’accord du déterminant et du nom dans un SNau cours de ce document la notation sous forme d’AVM. Ces représentations ne suffisentpas à définir la totalité de l’information nécessaire à l’analyse linguistique. Pour ce faire,il faut ajouter les règles de grammaire représentant les constructions autorisées. Dansce domaine, les contraintes prennent une part de plus en plus importante, elles sont dedifférents types :– les contraintes d’égalité sur les valeurs de traits (partage des valeurs de traits)– les contraintes de position (précédence linéaire)– les contraintes de formation– les contraintes de dépendancesChaque formalisme dispose de ses propres attributs et de ses propres contraintes enfonction du but recherché. L’analyse du langage naturel peut être appréhendée de deuxmanières différentes : soit en utilisant les structures des phrases et les compositionsd’éléments d’un point de vue syntagmatique (organisation de la phrase en groupes demots (syntagmes)), soit en utilisant les dépendances entre les éléments de la phrase et- 21 -

2 : Etat de l’artles fonctions de ces éléments. Le premier groupe est appelé grammaires syntagmatiques(GS), le deuxième grammaires de dépendances(GD). Les descriptions de ces deux « courants» l’un nord américain, l’autre français, sont contemporaines et datent des années1960. Les grammaires de dépendances 1 furent formalisées par Lucien Tesnière [61] tandisque le formalisme des GS prit naissance avec les grammaires génératives[13].2.1.2 Les grammaires de dépendances (GD)Les grammaires de dépendances utilisent les relations entre les différents mots d’unephrase pour analyser celle-ci. Ces relations sont appelées dépendances. Il est possiblede trouver plusieurs définitions du mot dépendance dans la littérature, ainsi [47] lesdéfinit ainsi : « [..] the wordforms in an utterance are linked by DEPENDENCIES : onewordform must depend on another for its linear position and its grammatical form. Thatis how the concept of dependency appears in linguistics ». Cependant les grammairesde dépendances utilisent le fait qu’il est possible de se libérer totalement de l’ordre desmots [19, 17]. Il est malgré tout parfois utile de conserver cette propriété de précédencelinéaire et [20] le présente comme un module de traitement adjoint à une grammaire dedépendances.La différence majeure entre les grammaires de dépendances et les grammaire syntagmatiquesest que les premières permettent de se libérer de l’ordre des mots. [42] est unebonne introduction à ce formalisme, le premier chapitre de [17] également. Ce dernierprésente, également, un état de l’art des techniques linguistiques dont nous nous sommesinspirés. [17] poursuit avec la description d’un formalisme de DG moderne, l’« ExtensibleDependency Grammar » (XDG). Ce formalisme est conçu de manière modulaireafin de permettre des traitements variés comme par exemple une analyse syntaxiqueseule ou avec une étude de la sémantique ainsi par exemple que le choix de prendre encompte ou non l’ordre des mots. Les dépendances sont représentées à l’aide de graphes.La figure 2.5 présente le graphe de dépendances 23 associé à la phrase « Le pc possèdedeux disques durs ». Sur cette figure disques durs est analysé comme un mot composé 4 .Les grammaires de dépendances s’articulent autour de la notion de valence. Pourtoute étiquette, la valence est le nombre d’arêtes entrantes (in) et sortantes (out)nécessaires à la bonne formation de l’étiquette 5 . Une arête entrante représente un élémentdont dépend l’étiquette courante, tandis qu’une arête sortante est liée à un élémentdépendant de celle-ci. Ces valences sont spécifiées pour chaque mot du lexique. Parexemple, la figure 2.6 présente une entrée du lexique pour le mot pc. Sur cette figure, lemot pc peut être qualifié soit de sujet (Subj ) soit d’objet (Obj ). Il doit donc dépendre1 Lucien Tesnière est le premier à formaliser les grammaires de dépendences, cependant de nombreuxauteurs font référence à des traitements des dépendences remontant au X ième siècle.2 Sur cette figure le graphe est réduit à un arbre. Les graphes de dépendances sont des DAG (DirectedAcyclic Graph)3 Ce graphe a été réalisé avec le style latex dtree.sty de Denys Duchier.4 « disque dur » peut aussi être reconnu comme le nom disque qualifié par l’adjectif dur.5 Nous reprenons ici l’utilisation des valences d’entrée et de sortie comme proposé dans [17] mais ilest possible de trouver également les seules valences de sortie- 22 -

2 : Etat de l’artFig. 2.5 – Graphe des dépendances pour la phrase ”Le pc possède deux disques durs”d’un verbe. D’autre part il a besoin d’un déterminant (Det). Le point d’interrogation(?)suit un label d’arête optionnel tandis que le point d’exclamation(!) marque l’obligationde présence de cette arête.⎧⎨⎩mot = pcin = {Subj ?, Obj ?}out = {Det!}⎫⎬Fig. 2.6 – Entrée lexicale en DG pour le mot pc[19] propose la définition d’une grammaire de dépendances comme le 7-tuple :〈Words, Cats, Agrs, Comps, Mods, Lexicon, Rules〉où– Words est un ensemble fini de chaînes de caractères représentant l’ensemble desformes fléchies pour tous les mots– Cats est un ensemble fini de catégories (n, det, ...)– Agrs est un ensemble fini de tuples d’accord tel que 〈masc sing 3〉– Comps est un ensemble fini de rôles compléments tel que sujet– Mods est un ensemble fini de modifieurs tel que Adj . Mods et Comps sont deuxensembles disjoints. L’ensemble des rôles est noté roles = Comps ⊎ Mods. Lesrôles servent à étiqueter les branches d’un arbre de dépendances, tel que celui dela figure 2.5.– Lexicon est un ensemble fini d’entrées lexicales– Rules est une famille de prédicats binaires indexés par les noms des rôles et exprimantles principes grammaticaux logiques de telle sorte que ∀ ρ ∈ Roles, ∃ Γ ∈Rules | Γ(w 1 , w 2 ) caractérise l’admissibilité grammaticale d’une arête étiquetée ρdu noeud père w 1 vers le noeud fils w 2 .Noam Chomsky est considéré comme le père des grammaires génératives [13]. Atravers elles, il présente la grammaire comme l’étude des procédés de génération propresau locuteur et non plus comme un simple système de génération de phrases. Il décritd’ailleurs les grammaires génératives comme telles :« La grammaire d’une langue propose d’être une description de la compétence intrinsèquedu locuteur-auditeur idéal. Si la grammaire est, de plus, parfaitement explicite⎭- 23 -

2 : Etat de l’art(en d’autres termes, si elle ne fait pas simplement confiance à la compréhension dulecteur intelligent, mais fournit une analyse explicite de l’activité qu’il déploie), nouspouvons, non sans redondance, l’appeler grammaire générative. »extrait de [14].N. Chomsky introduit de plus la notion de compétence-performance du locuteurauditeur.Cette notion représente la dualité entre les connaissances de structuration desphrases du locuteur-auditeur et la manière dont ce dernier les formule (locuteur) ou lesentend (auditeur).2.1.3 Les grammaires syntagmatiques généralisées (GPSG)Les Generalised Phrase Structure Grammars (GPSG) constituent une étape fortedans la création des grammaires syntagmatiques. Les notations présentées seront reprisespar tous ses descendants. L’architecture de cette grammaire repose sur des structuresde traits en utilisant une représentation bi-valente des relations liant une catégorie syntaxiqueet les catégories la constituant. Les GPSG introduisent également les conceptsde dominance immédiate et de précédence linéaire, elles se séparent ainsi des règles syntaxiquesclassiques. Le formalisme contenant ces deux concepts est nommé formalismeDI/PL. Dans les règles syntaxiques classiques, la règle A → B C D spécifie que toutnoeud étiqueté A domine 3 noeuds b,c et d étiquetés respectivement B, C et D et deplus, que le noeud b est à gauche du noeud c qui est lui-même à gauche du noeud d. Lathéorie propose un partage de ces informations sous la forme :– dominance immédiate : définit des règles de dominance : A → B, C , D où la partiedroite n’est pas ordonnée et signifiant que tout noeud a labélisé A domine troisnoeuds b,c,d labélisés respectivement B,C et D.– précédence linéaire : permet de spécifier sans question de dominance l’ordonnancementdes constituants. Par exemple B ≺ C signifie que tout noeud labélisé Bne pourra pas apparaître après un noeud labélisé C . La précédence linéaire estantisymétrique et transitive.Bien évidemment la règle A → B C D peut se réécrire avec le formalisme DI/PL,ce que montre la figure 2.7 6 .(1) A → B, C , D (ii) B ≺ C ≺ DFig. 2.7 – Règle syntaxique utilisant le formalisme DI/PLCe formalisme utilise des arbres et cherche des sous-arbres parmi un certain nombreautorisé satisfaisant l’ensemble des contraintes définies par les « règles ». Ces règles sontd’une part les règles de dominance immédiate et de précédence linéaire mais elles sontégalement définies par des principes portant sur les structures de traits et de portéeuniverselle 7 . Ces principes sont au nombre de trois : Foot Feature Principle, ControlAgreement Principle et Head Feature Convention régissant respectivement :6 L’exemple 2.7 est tiré de [31]7 Valables pour toute langue, bien que dans la pratique les principes puissent être adaptés aux languestraitées- 24 -

2 : Etat de l’art– les traits FOOT qui servent à représenter les éléments tels que les mots en Whenanglais, qui n’ont pas un rôle noyau dans le syntagme mais qui justifient saconstruction.– les traits CONTROLS qui ne peuvent être que de type SLASH (éléments absents)ou de type AGR (Agreement).– les relations entre les traits HEAD d’une catégorie mère et de ses catégories filles.2.1.4 La grammaire syntagmatique guidée par les têtes (HPSG)Le formalisme des « Head driven Phrase Structure Grammar » (HPSG) est sûrementle plus utilisé des formalismes inspirés des grammaires de Chomsky[12]. Leur article fondateur[52] date de 1987. Une version révisée est proposée en 1994[53] par les mêmesauteurs. C’est cette dernière version qui est utilisée à l’heure actuelle par une grande partiedes chercheurs du domaine. Nous donnons ci-dessous les grandes lignes de la théorieen nous reportant à l’article [8] qui donne une présentation claire, rapide et en françaisde la théorie des HPSG. Les HPSG héritent des GPSG, en ce qu’elles représentent l’informationpar des structures de traits (typées), implémentent les principes de dominanceimmédiate et de précédence linéaire ainsi que des principes dont notamment le principedes traits de tête.HPSG utilise des structures de traits typées pour représenter l’ensemble des informations.Une structure de traits typée est une structure dont tous les traits (atomiques oucomplexes) possèdent un type. Ces types sont organisés en hiérarchie et tous les traitsdoivent être bien typés. La propagation des valeurs de traits entre une structure de traitsfille et une structure de traits père 8 est assurée par un mécanisme de partage des valeursde traits. Les différents niveaux d’analyse (phonologique, syntaxique, sémantique) sontinscrits dans cette structure.Avec les structures de traits typés, les schémas de dominance immédiate et les principesforment les trois briques générales de HPSG.Les schémas de dominance immédiate correspondent à des types de construction desyntagmes génériques basés sur les traits des syntagmes et non sur les syntagmes euxmêmes.Ils sont nommés « de dominance immédiate » car ils caractérisent les relationsqu’entretient un signe (syntagme ou mot) avec ses fils directs (fils tête, comps, marqueur,adjoint, ...).Les Principes ont une portée ”universelle”. Ces principes sont des contraintes que certainstypes de structures doivent vérifier. Ils assurent une bonne formation des syntagmeset permettent la complétion des données manquantes, par unification. Par exemple, ilest tout à fait possible d’analyser une phrase partielle comme possède deux disques dursen générant une structure qui attend un sujet pour former une phrase.8 Une structure de traits s 1 est fille d’une structure de trait s 2 lorsque s 1 apparaît comme valeur d’untrait de s 2 ou d’une de ses structures de traits filles. s 2 est appellée structure de trait père de s 1.- 25 -

2 : Etat de l’art2.1.5 Les grammaires de propriétés (GP)Les grammaires de propriétés[10, 11](GP par la suite) ont été définies et sont maintenuesau Laboratoire Parole et Langages d’Aix en Provence. Cette théorie s’exprimeexclusivement à base de contraintes. Les variables proposées sont nommées catégorieset servent à représenter les étiquettes syntaxiques attachables à chaque mot ou groupede mots. Les contraintes, nommées propriétés, portent sur ces catégories.Les catégoriesLes catégories sont les variables du formalisme utilisé. Elles sont représentées par desstructures de traits. Ces structures contiennent à la fois les attributs « classiques » deséléments de la langue, comme le trait d’accord, mais également un trait complexe quiexprime l’ensemble des propriétés attachées à cette catégorie. La figure 2.8 représentela catégorie SN pouvant représenter un syntagme nominal.2traitsSNprops64"#3genre fem ;mascnombre sing ;plur23têteN ;Profacultativité Det ;SAdjunicité Det ;SAdjexigence Det ⇒ Nexclusion SAdj ProDet Prolinéarite Det ≺ N64accordN.gen ≡ Det.gen75N.nb ≡ Det.nbFig. 2.8 – AVM représentant un SNLes propriétésLes propriétés sont des contraintes sur les catégories. Sept propriétés principales permettantde traiter la syntaxe sont détaillées dans [10]. La théorie n’exclut cependant pas laspécification de nouvelles propriétés si elles sont nécessaires et justifiées. Elles peuventêtre utilisées pour inclure, par exemple, le traitement de la sémantique dans la formalisation.D’autre part il est possible de proposer des grammaires ne contenant qu’unsous-ensemble de ces propriétés. La figure 2.8 nous servira de support pour illustrer lespropriétés listées ci-dessous.– Tête :Une tête est obligatoire et unique dans un syntagme. La propriété de tête définitl’ensemble des éléments pouvant être tête dans le syntagme traité. La tête estl’élément qui dirige le syntagme. Par exemple, dans un SN nous pouvons préciserque seul un N ou un Pro peuvent être tête. Cette contrainte se présente sous laforme : tête(SN) ∈ {N,Pro}.- 26 -

2 : Etat de l’art– Facultativité :La propriété de facultativité définit l’ensemble des catégories pouvant être présentesdans un syntagme et n’étant pas une tête. Par exemple, les deux catégories Detet SAdj sont optionnelles dans un SN. Cette contrainte est notée : facult(SN) ={Det,SAdj}– Unicité :Cette propriété définit l’ensemble des catégories facultatives qui ne peuvent pasapparaître plus d’une fois. Pour l’exemple du SN, seulement un Det et seulementun Adj peuvent être présents : uniq(SN) = {Det, SAdj}– Exigence :Cette contrainte est exprimée avec le symbole ⇒ : {A 1 , A 2 , ..., A n } ⇒ {B 1 , B 2 , ..., B m }où les A i sont des catégories et les B j des ensembles de catégories. Cette propriétésignifie que si tous les éléments A i sont présents dans le syntagme alors au moinsun sous-ensemble B j doit être présent. Dans l’exemple du SN, la présence d’undéterminant oblige la tête à être de type N .– Exclusion :Cette contrainte est notée A B où A et B sont des ensembles de catégories.Cette propriété définit l’obligation de non co-occurrence entre tous les élémentsde A et tous ceux de B.– Linéarité :Cette propriété est notée A ≺ B et permet de définir la précédence linéaire entreles éléments d’un syntagme. A et B représentent des ensembles de catégories. Lapropriété de linéarité signifie que chaque élément de l’ensemble A présent dans lesyntagme doit apparaître avant tout élément de B également présent.– Accord 9 :Cette contrainte porte sur l’accord des catégories au sein d’un même syntagme.2.2 La configuration2.2.1 Présentation de la configurationHélène Fargier et Laurent Henocque proposent dans [28] une définition générale dela configuration : « Configurer consiste à simuler la réalisation d’un produit complexe àpartir de composants choisis dans un catalogue de types ». Daniel Mailharro dans [46]complète cette définition en spécifiant les interconnections des composants et va plusen avant dans leur spécification : « La configuration d’un produit est un ensemble decomposants inter-connectés choisis parmi un ensemble prédéfini de types de composants,appelé le catalogue des types de composants. Chaque type de composants est défini parun ensemble d’attributs qui décrivent ses caractéristiques internes, un ensemble de portsde connections qui décrivent ses relations avec les autres composants et un ensemble decontraintes sur ses attributs et ses ports. Les contraintes décrivent les restrictions de9 La propriété d’accord est transcrite dans [11] par une propriété plus générale nommée propriété dedépendance.- 27 -

2 : Etat de l’artcompatibilités de connections entre composants, les limitations de types production/consommationde ressources, les conditions d’existence, etc. . . ».La configuration peut ainsi être vue comme une extension des problèmes de satisfactionde contraintes (CSP) dans lesquels les variables et les contraintes sont ensemblisteset où l’instanciation de toutes les variables n’est pas systématique. La solution d’unproblème de configuration est un produit satisfaisant à la fois les contraintes généralesde réalisation et les contraintes et objectifs particuliers de l’utilisateur. Ce produit peutêtre totalement ou seulement partiellement instancié. Lorsqu’un problème de configurationn’admet pas de solution, il peut être intéressant d’expliquer pourquoi en donnant,par exemple, un ensemble minimal de contraintes contradictoires.Un problème de configuration s’apparente à un problème de la logique des prédicats.En effet, chercher une solution contenant au moins un composant de tel type requiertun quantificateur existentiel de la logique des prédicats. A partir de cette constatation,[28] pose le problème de l’indécidabilité de ces problèmes dans l’absolu. Différentslangages ont été proposés pour traiter la configuration, notamment CLP (ConstraintLogic Programming) basé sur le formalisme Prolog [15] et le chaînage arrière, ou encoreles modèles stables [32], qui peuvent être combinés aux règles pondérées (« Weightedrules ») [56].D’autre part, le cadre des CSP (Constraint Satisfaction Problem) a été étendu pourprendre en compte l’aspect dynamique intrinsèque aux problèmes de configuration. Ainsiles DCSP (Dynamic CSP) [2], les CSP génératifs [30, 60], les CSP stucturaux [1] ou lesCSP composites [55] sont autant d’approches capturant les composants non utilisés lorsde l’élaboration du modèle et permettant un traitement ensembliste, techniques nonimplémentées dans les CSP « classiques ».La résolution technique d’une requête dans le cadre d’un problème de configurationpeut également utiliser des approches basées sur la connaissance [59] ou les logiquesterminologiques [49].Ces méthodes de résolution de problèmes de configuration sont présentés dans [28]qui fait le point sur les différentes approches de la configuration. L’approche qui sembleêtre la plus appropriée est apparue lorsque les langages orientés objet se sont développés.La configuration orientée objet [46] mélange les concepts des CSP et ceux des paradigmesorientés objet. Elle possède l’avantage de représenter plus facilement les composants dumodèle générique et procure la dynamique nécessaire à leur traitement.2.2.2 La configuration orientée objetLa figure 2.9 est une représentation graphique d’un modèle générique de PC : unPC comprend une carte mère, une alimentation, un écran et un ou plusieurs disquesdurs. La carte mère supporte un ou plusieurs processeurs ainsi qu’une ou plusieurs barrettesde mémoire. Chaque composant cité ci-dessus est une classe du domaine traité(ici un environnement matériel informatique). Chaque classe peut contenir des attributscaractérisant des données particulières (energieconsommee est un attribut de la classeConsommateurDEnergie dont le domaine est ). Les classes sont liées entre elles pardes relations. Toutes ces liaisons ne sont pas les mêmes, par exemple, sur ce diagramme,- 28 -

2 : Etat de l’artFig. 2.9 – Un exemple de configuration - Modèle générique d’un PCla classe « ConsommateurDEnergie » possède cinq liaisons particulières aux composants« Ecran, DisqueDur, Processeur, Ram » et « CarteMere ». Ce sont des relationsd’héritage. Elles permettent de factoriser les éléments communs à un ensemble de composants.Pour notre exemple, toute pièce hérite de l’attribut « energieConsommee ». Lareprésentation est allégée puisque cet attribut ne réapparait pas dans la représentationdes classes filles. Les autres relations sont des relations ensemblistes aux cardinalitésexplicites entre les différents composants. Toute classe supporte des contraintes décritesséparément et d’ajouter les contraintes de l’utilisateur.Les contraintes de l’utilisateur sont de deux sortes. Les premières sont un type decontraintes fortes correspondantes aux spécifications obligatoires que l’utilisateur veutvoir satisfaites pour le produit final. Ces contraintes sont appelées contraintes spécifiques.Les secondes forment un ensemble de contraintes plus souples et pouvant être violées. Cescontraintes représentent les souhaits de l’utilisateur mais en aucun cas une nécessité. Ellesont également nommées préférences. Le configurateur doit donc essayer de satisfaire aumaximum ces contraintes sans aller à l’encontre des contraintes structurelles (génériques)et spécifiques. U.Junker dans [39] et [40] propose des stratégies de recherche de « bonne »décision pour le choix des préférences à satisfaire (ou à enfreindre). Pour notre exemple,représenté en figure 2.9, les préférences peuvent être du type : « choisir un disque durSCSI de préférence à un disque dur IDE ». Cependant, si la seule carte mère disponible,à cause des contraintes structurelles, ne supporte pas le SCSI, cette requête devra resterinsatisfaite.Cette approche est, à notre connaissance, la plus appropriée au traitement desproblèmes de configuration. C’est pourquoi nous nous plaçons dans ce formalisme pour- 29 -

2 : Etat de l’artrésoudre les problèmes issus de la linguistique que nous montrerons équivalents à desproblèmes de configuration. Nous nous servirons du logiciel ”Jconfigurator” [46, 41] de lasociété Ilog pour nos expérimentations dans le cadre de l’analyse syntaxico-sémantiquede description.- 30 -

Chapitre 3Les Modèles Objet Contraints :formalisme et formalisationL’objectif de ce chapitre est de proposer tout d’abord une représentation formelle desmodèles objet contraints puis de décrire formellement leur résolution afin d’assurer lareproductibilité des résultats présentés dans cette thèse. Le langage de spécification choisiest le langage Z [58] 1 . Les diagrammes de classes UML2[35] 2 seront mis en relation avec lareprésentation proposée pour fournir une meilleure lisibilité. Cependant leur utilisationn’est pas une nécessité mais fournit un confort de lecture et une représentation utilisablepar d’autres applications. Nous poursuivons ici les travaux de Laurent Henocque dans[36] où il propose une première méthode de formalisation reposant sur l’utilisation desschémas de Z [58]. Ces travaux mènent à l’utilisation d’une combinaison de UML2[35]et de Z pour représenter les modèles objet contraints.3.1 Représentation formelle des modèles objet contraintsLes modèles objet contraints permettent de représenter des problèmes où interviennentdes variables ensemblistes ainsi que des contraintes sur ces ensembles et danslesquels certaines variables peuvent ne pas participer à la solution.Définition 2 (Modèle Objet Contraint) Un modèle objet contraint est un ensemblede classes et de relations entre ces classes dont les règles de bonne formation sont expriméespar des contraintes.Définition 3 (Classe) Une classe définit les propriétés communes à un ensemble d’objetsDéfinition 4 (Relation) Une relation entre deux classes est un ensemble de couplesd’objets appartenant respectivement à chacune des deux classes.1 Nous renvoyons le lecteur non familier au langage Z à ce livre disponible électroniquement à l’adressehttp ://spivey.oriel.ox.ac.uk/mike/zrm/index.html2 Une large documentation sur UML est disponible sur le site de l’OMG et plus particulièrement àl’adresse http ://www.omg.org/technology/documents/formal/uml.htm- 31 -

3 : Les Modèles Objet Contraints : formalisme et formalisationNous présentons dans un premier temps les modèles objet , la définition de contraintesera donnée dans la section 3.2.3.1.1 Les types Objet et ClasseLe type le plus général est Objet. Ce type est non interprété, c’est à dire qu’aucunesémantique n’y est associée naturellement. La section 3.3 présente une interprétation dece type. La déclaration d’un type non-interprété en Z se fait de la manière suivante :[Objet]Classe est l’ensemble des sous-ensembles finis de [Objet] :Classe == ObjetUne classe A est définie comme un élément de l’ensemble Classe.A : ClasseLa figure3.1 représente la modélisation UML d’une telle classe.Fig. 3.1 – Représentation UML2 de la classe A3.1.2 Les attributs de classeUn attribut de classe est une variable locale à la classe prenant ses valeurs dans desensembles possiblement infinis d’entiers (,) ou de chaînes de caractères (String). Letype String est un type non-interprété définit comme le type Objet ci-dessus.[String]Un attribut de classe est décrit par une fonction définie sur la classe à laquelle il estassocié et à valeurs dans , ou String (dom représente ici le domaine de valeur del’attribut) :att : A " domUML2 décrit les attributs de classe dans le corps de la classe comme présenté sur lafigure 3.2.- 32 -

3 : Les Modèles Objet Contraints : formalisme et formalisationFig. 3.2 – Une classe contenant un attribut3.1.3 Les relationsLa notation Z pour une relation ArelB liant deux classes A et B quelconques est lasuivante :ArelB : A # BArelB est un ensemble de couples d’objets a de type A et b de type B : A # B =(A × B).RôlesLa définition d’une relation peut être complétée par la définition de deux rôles. Unrôle définit à partir d’un élément a de type A l’ensemble des éléments de type B enrelation avec a par la relation précédente.Définition 5 (Rôle) Etant données deux classes A et B et ArelB une relation entreces classes, les rôles, notés arbitrairement roleAB et roleBA sont définis par :roleAB : A " B∀ a : A • roleAB(a) = ArelB{a}roleBA : B " A∀ b : B • roleBA(b) = ArelB{b} est l’opérateur d’image relationnelle. Pour la relation ArelB et unOù l’opérateurélément a de type A, ArelB{a} est l’ensemble B des objets de type B tels que ∀ b ∈B, (a, b) ∈ ArelB.La classe sur laquelle est projetée la relation est dit classe source du rôle, la seconde estdite classe cible du rôle.Cette définition permet de donner des détails sur la lecture des prédicats en notationZ . Un prédicat est exprimé sous la formeQvar[| restriction] • predicat- 33 -

3 : Les Modèles Objet Contraints : formalisme et formalisationCardinalité d’un rôleIl est possible de compter pour chaque élément d’une classe source le nombre d’élémentslui étant associés par un rôle. L’opérateur de cardinalité d’un ensemble est le #. Ainsipour tout élément a d’une classe source A d’un rôle roleAB, le nombre d’éléments associésà a par ce rôle est : #roleAB(a). La contrainte suivante force tout objet a detype A à être associé à au moins x et au plus y objets de type B :∀ a : A • x ≤ #(roleAB(a)) ≤ yLa cardinalité du rôle roleBA se définit de la même manière (en la supposant compriseentre x’ et y’) :∀ b : B • x ′ ≤ #(roleBA(b)) ≤ y ′La relation que nous venons de définir est une relation d’association du paradigmeorienté objet. La notation UML2 pour ces relations est présentée sur la figure 3.3.Fig. 3.3 – Notation UML2 de la relation d’associationRelation de CompositionUne relation de composition est plus contrainte que la relation d’association. Toutobjet de la classe cible intervenant dans la relation ne peut pas être partagé par deuxobjets différents de la classe source, cette propriété est nommée propriété d’exclusivité.La cardinalité côté source ne peut être que 0..1 ou 1..1 (noté également 1). Les relationsde composition sont définies par des fonctions. Soient deux classes C et D,C : ClasseD : Classetelles que C soit composée de au minimum x et au maximum y objets de type D,CcompoD : C " D∀ c : C • x ≤ #(CcompoD(c)) ≤ yLa cible d’une relation de composition ne peut pas être partagée par plusieurs sources,ceci se traduit par la définition de la fonction partielle CcompoDrev inverse de CcompoD :- 34 -

3 : Les Modèles Objet Contraints : formalisme et formalisationCcompoDrev : D C∀ c : C ; d : D • d ∈ CcompoD(c) ⇔ c = CcompoDrev(d)CcompoDrev étant une fonction partielle, si elle possède une image dans C alors celle-ciest unique. CcompoDrev assure ainsi la propriété d’exclusivité de la relation de compositionCcompoD.La figure 3.4 représente la relation de composition entre les classes C et D sous lanotation UML2. Le losange plein se situe du côté de la classe source de la relation.Fig. 3.4 – Notation UML2 de la relation de compositionLorsque les relations d’association ou de composition possède une cardinalité d’exactement1, il est conseiller d’utiliser à la place de la combinaison, fonction injective versun ensemble de parties, plus contraintes de cardinalité (=1), une fonction injective versla classe cible. Par exemple si la relation de composition CcompoD présentée ci-dessuspossède une cardinalité d’exactement 1, plutôt que de la noter comme précédement, onpeut écrire :etCcompoD : C " DCcompoDrev == CcompoD ∼Relation d’HéritageLes relations d’héritage permettent de spécifier des caractéristiques communes à unensemble de classes sans avoir à redéfinir ces caractéristiques pour chacune d’entre elles.Nous utilisons des ensembles d’objets pour représenter les classes, la relation d’héritageest donc traduite par le fait que l’ensemble d’objets appartenant à la classe fille est inclusdans l’ensemble d’objets représentant la classe mère. Supposons que la classe A définiedans la section 3.1.3 hérite de la classe C définie ci-dessus. Cette relation sera décriteainsi :A ⊆ CSi deux classes héritent d’une même classe mère, les deux ensembles doivent être disjoints.Par exemple, si la classe B définie dans la section 3.1.3 hérite elle aussi de la- 35 -

3 : Les Modèles Objet Contraints : formalisme et formalisationclasse C , il faut préciser que les deux ensembles d’objets représentant respectivementles classes A et B sont disjoints :B ⊆ Cdisjoint 〈A, B〉La notation UML des relations d’héritage est présentée sur la figure 3.5 où les classes Aet B héritent de la classe C . Dans la plupart des modèles objet que nous utilisons, seulesFig. 3.5 – Relation d’héritage : A et B héritent de Cles feuilles des hiérarchies de types sont utilisées et les classes de rangs supérieurs (lesclasses mères) sont dites abstraites et ne peuvent pas contenir d’objets. Cette notion estdéfinie par l’opérateur partition. Dans le cas de notre exemple où A et B héritent deC , si C est abstraite et que les classes A et B sont terminales nous devons écrire :〈A, B〉 partition CNous venons de définir formellement le modèle objet générique, support des modèlesobjet contraints à l’aide du langage de spécification Z . Nous avons de plus montréque tous ces modèles pouvaient se représenter par des diagrammes de classes UML2.Cependant nous n’utilisons pas toutes les relations présentes dans UML2, comme larelation d’aggrégation par exemple. De plus les relation UML2 peuvent être n-aire tandisque nous nous limitons aux relations binaires. Nous rappelons que l’utilisation de UML2n’est pas une nécessité. Dans la suite du document nous considèrerons comme connusles types de bases (entiers et chaînes de caractères).3.2 Les contraintesIl n’existe pas de formalisme spécifique défini pour les modèles objet contraints. Ducôté de la modélisation orientée objet UML2, l’OMG 3 a proposé le langage OCL 4 pour3 Object Management Group - http ://www.omg.org4 Object Constraints Language - Dernière version : http ://www.omg.org/docs/ptc/03-10-14.pdf- 36 -

3 : Les Modèles Objet Contraints : formalisme et formalisationaugmenter le pouvoir expressif des modèles objet représentés en UML2. Cependant,ce langage reste moins expressif qu’un langage formel. L’approche que nous proposonspour représenter les contraintes repose de nouveau sur le langage de spécification Z .L’avantage de ce choix est triple : (1) le langage Z est au moins aussi expressif quela logique des prédicats et fournit une grande liberté d’expression, (2) son caractèreformel assure la reproductibilité des résultats et (3) ce choix constitue une propositiond’uniformisation des représentations des modèles objet contraints afin de faciliter leséchanges au sein de la communauté.Une contrainte est exprimée par un prédicat du langage Z (Predicate [58], p.67)sur des éléments de type , , String,Objet, Objet et [|Objet |].Les opérations classiques sur les entiers (+, −, ...,

3 : Les Modèles Objet Contraints : formalisme et formalisation[U , X ]. : (U × (U # X )) " X. : (U × (U " X )) " X→ : ( U × (U # X )) " X→ : ( U × (U " X )) " X→ : ( U × ( U " X )) " X : ( U × (U # X )) " bag X : ( U × (U " X )) " bag X∀ e1 : U ; e2 : (U " X ) • e1.e2 = e2(e1)∀ e1 : U ; e2 : (U # X ) • e1.e2 = e2{e1}∀ e1 : U ; e2 : (U " X ) • e1 → e2 ={x : U | x ∈ e1 • e2(x)}∀ e1 : U ; e2 : (U # X ) • e1 → e2 = e2e1∀ e1 : U ; e2 : ( U " X ) • e1 → e2 = e2(e1)∀ f : U " X • f = ∀ f : U " X ; s : 1U • ∀ u : s • s f = (s \ {u}) f ⊎ f (u)∀ f : U # X • f = ∀ f : U # X ; s : 1U • ∀ u : s • s f = (s \ {u}) f ⊎ {x : X | (u, x) ∈ f • x ↦→ 1}Fig. 3.6 – Définitions des opérateurs de dé-référencementbagsum : ( " ) " bagsum() = 0∀ b : " • ∀ x : dom b • bagsum(b) = x ∗ b(x) + bagsum(b ! {x ↦→ b(x)})Le symbole ! est l’opérateur de différence pour les bags([58] p.126) qui signifie quel’ensemble formé du couple (x, b(x)) est retiré du bag b. Par exemple, soit le modèleobjet de la figure 3.7 et la contrainte spécifiant que pour toute carte mère, la somme descapacités des barettes de mémoire doit être supérieure ou égale à 512. Cette contraintes’exprime de la manière suivante :∀ cm : CarteMere • bagsum(cm.ram capacite) ≥ 512cette contrainte peut également s’écrire avec l’opérateur → défini sur la figure 3.6.∀ cm : CarteMere • (cm.ram capacite) → bagsum ≥ 512L’expression cm.ram représente l’ensemble des éléments de type Ram liés à l’objetcm par le rôle cmRam. L’application de l’opérateur de dé-réfencement à cet ensemblecrée le bag composé des couples (valeur de l’attribut capacite,nombre d’occurrences decette valeur dans le bag).- 38 -

3 : Les Modèles Objet Contraints : formalisme et formalisationFig. 3.7 – Sous-modèle objet du PC3.2.3 Une modélisation formelle adaptéeLa modélisation proposée permet de représenter le modèle objet de manière graphiquedans un standard du domaine (UML2) afin de faciliter la lecture et l’ouverturevers d’autres méthodes tout en gardant l’avantage d’une représentation formelle. Deplus la formalisation des contraintes grâce au langage Z dispose d’une puissance expressivesuffisante pour les types de problèmes que traitent les modèles objet contraints.Un sous-ensemble d’objets est une solution d’un modèle objet contraint lorsqu’aucunecontrainte n’est violée par cet ensemble. Une méthode pour la résolution d’un modèleobjet contraint est la recherche arborescente de modèles finis.3.3 Sémantique de type modèles finisDéfinition 6 (Modèle fini) Un modèle fini est un ensemble fini d’objets satisfiantl’ensemble des contraintes définies sur ces objets.Définition 7 (Satisfaction de contrainte) Une contrainte ct est dite satisfaite sison interprétation I est vraie (I( ct) = true).Toute contrainte est exprimée sous la forme d’un prédicat, une contrainte est doncsatisfaite si le prédicat la définissant est satisfait.3.3.1 InterprétationLes contraintes disposent de l’interprétation définie par la notation Z elle même.Cette interprétation est celle de la logique des prédicats. L’interprétation d’un modèleobjet contraint sera, par analogie à celle-ci, notée I . Nous détaillons l’interprétation deséléments que nous avons introduits, les Objets, les String, les Classes, les attributs et lesrelations.Interprétation de Objet, de String et de ClasseI projette les types non interprétés sur un ensemble fini d’entiers. Tous les objetssont distincts deux à deux. La fonction d’interprétation associe à tout élément de typeObjet un entier naturel différent. Cette fonction est injective (le symbole inj représenteune fonction injective).- 39 -

3 : Les Modèles Objet Contraints : formalisme et formalisationI : Objet De même, tout élément de type String est interprété comme un entier.I : String L’interprétation d’un nombre entier est le nombre entier lui-même :∀ n : • I (n) = n.Les interprétations des autres éléments découlent naturellement de I : Par définition,toute Classe est un ensemble fini d’Objets et IClass associe à tout élément de ce typeun ensemble d’entiers.IClass : Classe ∀ c : Classe • IClass(c) = Icoù est l’opérateur d’image relationnelle ([58] p.101). L’image relationnelle RS d’unensemble S sur une relation R est l’ensemble de tous les objets y tels que (x, y) ∈ R,pour x ∈ S.Interprétation des attributsTout attribut est interprété comme un couple (entier interprétant l’objet, interprétationde la valeur d’attribut)Attribut de type entier :IAtt : (Objet " ) ( × )∀ att : (Objet " ) • IAtt(att) = ⋃ {o : Objet | o ∈ dom att • {(I (o), att(o))}}Attribut de type String :IAttString : (Objet " String) ( × )∀ att : (Objet " String) • IAttString(att) =⋃ {o : Objet | o ∈ dom att • {(I (o), I (att(o)))}}Interprétation des relations d’associationToute relation d’association est interprétée comme un ensemble de couples d’entiers.Irel : (Objet # Objet) ( × )∀ rel : (Objet # Objet) •Irel(rel) =⋃ {o1 , o 2 : Objet | (o 1 , o 2 ) ∈ rel • {(I (o 1 ), I (o 2 ))}}- 40 -

3 : Les Modèles Objet Contraints : formalisme et formalisationInterprétation des rôles et des relations de compositionTout rôle est interprété comme un ensemble de couples d’entiers et d’ensemble d’entiers.Irole : (Objet " Objet) ( × )∀ role : (Objet " Objet) •Irole(role) = ⋃ {o : Objet | o ∈ dom role • {(I (o), I{o})}}Interprétation des relations de compositionUne relation de composition comme un rôle est une fonction associant un ensembled’objets à un objet, leurs interprétations sont de même type. La fonction partielle inversed’une relation de composition est égale à un ensemble de couples d’entiers.Irev : (Objet Objet) ( × )∀ comporev : Objet Objet •Irev(comporev) = ⋃ {o : Objet | o ∈ dom comporev • {(I (o), I (comporev(o)))}}A partir des interprétations données ci-dessus et de l’interprétation des prédicats,nous disposons d’une interprétation totale d’un modèle objet contraint. Nous présentonsci-après un exemple d’interprétation pour un modèle objet contraint très simple, issudu modèle objet utilisé pour présenter la configuration dans l’état de l’art. Une interprétationsatisfaisant toutes les contraintes d’un modèle objet contraint est nomméeune instance de celui-ci.3.3.2 Un exemple d’instanceSoit le modèle objet représenté sur la figure 3.8 (sous modèle objet de la figure 2.9de la section 2.2.2) et l’ensemble de contraintes suivant :Fig. 3.8 – Modèle objet d’une carte mère et de ses composants- 41 -

3 : Les Modèles Objet Contraints : formalisme et formalisation∀ cm : CarteMere ; r : Ram | r ∈ cm.ram • cm.typeRam = r.type∀ cm : CarteMere ; r : Ram ; p : Processeur| r ∈ cm.ram ∧ p ∈ cm.processeur• cm.prixTotal =cm.prix + bagsum((cm.ram) prix) + bagsum((cm.processeur) prix)∀ cm : CarteMere | #(cm.processeur) = 2 •∀ p 1 , p 2 : Processeur | p 1 ∈ cm.processeur ∧ p 2 ∈ cm.processeur •p 1 .vitesse = p 2 .vitesseSoit l’ensemble d’objets fini E f suivant : E f = {cm 1 : CarteMere, p 1 : Processeur, r 1 :Ram} tel que1. cm 1 .ram = {r 1 }, cm 1 .processeur = {p 1 },2. cm 1 .prixTotal = 205, cm 1 .typeRam = SDR, cm 1 .energieConsommee = 205,cm 1 .prix = 803. r 1 .capacite = 256, r 1 .type = SDR, r 1 .energieConsommee = 5, r 1 .prix = 504. p 1 .vitesse = 2000, p 1 .energieConsommee = 10, p 1 .prix = 75Interprétation des objets et des classesNous supposons pour des raisons de lisibilité que les trois objets de cet exemple sontassociés aux chiffres 1, 2 et 3.I (cm 1 ) = 1I (r 1 ) = 2I (p 1 ) = 3Ainsi les interprétations des classes sont les suivantes :IClass(CarteMere) = {1}IClass(Ram) = {2}IClass(Processeur) = {3}IClass(Composant) = {1, 2, 3}IClass(ConsommateurDEnergie) = {1, 2, 3}DDR et SDR sont deux éléments de type String, leur interprétation est :I (SDR) = 1I (DDR) = 2Interprétation des relations de compositionIrole(ram) = {(1, {2})}Irole(processeur) = {(1, {3})}- 42 -

3 : Les Modèles Objet Contraints : formalisme et formalisationInterprétation des attributsIAtt(prixTotal) = {(1, 205)}IAttString(typeRam) = {(1, 1)}IAttString(type) = {(2, 1)}IAtt(capacite) = {(2, 256)}IAtt(vitesse) = {(3, 2000)}IAtt(energieConsommee) = {(1, 205), (2, 5), (3, 10)}IAtt(prix) = {(1, 80), (2, 50), (3, 75)}Cette interprétation satisfait toutes les contraintes, c’est donc bien une instance dumodèle objet contraint.La notation UML2 permet de représenter de tels modèles, la figure 3.8 présente lemodèle décrit ci-dessus. Nous avons opté pour une représentation où les attributs desobjets apparaissent.Fig. 3.9 – Une solution possible pour le modèle objet de la figure 3.83.4 ConclusionAu cours de ce chapitre, nous avons présenté les modèles objet contraints et proposéune méthode formelle nouvelle, à notre connaissance, pour les représenter. L’interprétationdes objets comme un ensemble fini d’entiers est, quant à elle, une projectionclassique d’un ensemble fini d’éléments quelconques dans un ensemble d’entiers. L’interprétationdes fonctions crée les couples d’entiers ou d’entiers et d’ensembles d’entiers,représentant les tuples autorisés pour le modèle considéré. Les notations présentées dansce chapitre sont utilisées dans toute la suite du document. En particulier pour présenterla configuration, un outil de recherche de modèles finis, qui nous permet d’énumérerl’ensemble des solutions possibles pour les modèles objet contraints.- 43 -

Chapitre 4Méthode de recherche de modèlesfinis pour les modèles objetcontraintsLa méthode de recherche de modèles finis retenue est la configuration. Son objectifest de décrire des asssemblages de composants choisis dans un catalogue de types de composantsafin de créer un objet complexe. Cet assemblage est soumis à des contraintesinhérentes à chaque composant mais également fonction du produit que l’on chercheà construire. Cette notion de production est directement issue de l’industrie qui agénéré le besoin de cette discipline. La configuration a, entre autre, été utilisée pourle système XCON [6]. Un problème de configuration s’articule autour d’un modèlegénérique permettant de représenter l’ensemble des objets productibles et d’un ensemblede contraintes. Les contraintes sont de deux types :– contraintes inhérentes aux composants :ces contraintes permettent de spécifier quels sont, pour tout produit que l’oncherche à modéliser, les assemblages autorisés et ceux interdits– contraintes spécifiques à l’instance traitée :ces contraintes représentent les « choix » de l’utilisateur pour la configuration duproduit qu’il désireLa configuration s’inscrit pleinement dans le domaine de la programmation par contrainteset dans celui de l’intelligence artificielle. Nous utilisons la configuration orientée objet[46] ;celle-ci tire profit des paradigmes orientés objet et de la programmation par contraintes.Elle utilise les relations d’héritage (relations taxonomiques) et les relations d’associationet de composition (relations partonomiques) des modèles objet ainsi que la programmationpar contraintes pour décrire les relations autorisées. La taille d’une solution(lorsqu’il en existe une) d’un problème de configuration n’est pas connue au départ de larecherche et place directement ce problème dans la classe des problèmes semi-décidables.Cependant, dans les problèmes pratiques, il est souvent possible de donner une bornemaximale à la taille de la solution, le problème appartient alors à la classe NP-complet.La recherche de modèles finis est organisée de la sorte : l’utilisateur fournit au configu-- 44 -

4 : Méthode de recherche de modèles finis pour les modèles objet contraintsrateur l’ensemble des composants dont il dispose. Puis, il choisit d’une part un ensembled’objets, éventuellement vide, plus ou moins interconnectés et plus ou moins totalementinstanciés, devant apparaître dans la solution et d’autre part un objet racine quisera le point de départ de la recherche. A partir de cet objet, la recherche « brute » 1cherche à instancier les relations en premier et avec la cardinalité la plus petite d’abord.Lorsqu’un objet atteint ne possède plus de relation non instanciée, ses attributs sontinstanciés à leur tour puis la recherche remonte à l’objet qui avait permis d’atteindrecet objet et continue l’instanciation. La semi-décidabilité des problèmes de configurationFig. 4.1 – Un modèle objet cycliqueprovient du fait qu’un modèle objet peut éventuellement posséder des solutions infinies,par exemple, la figure 4.1 présente un modèle objet simple qui possède (sans contraintesupplémentaire) des solutions finies et des solutions potentiellement infinies.1. Une solution finie : soit a 1 une instance de la classe A telle que R(a) = a alorsl’objet a ainsi configuré est une solution du modèle objet.2. Une solution infinie : soit l’ensemble A = {a i : A | i ∈ } tel que ∀ i, R(a i ) = a i+1 ,l’ensemble A est une solution infinie du modèle objet.D’autre part, si on rajoute la contrainte ∀ x, y : 1 • (x, y) ∈ R + ⇒ x ≠ y, 2 ce modèleobjet contraint n’est satisfaisable que par un ensemble infini d’objets de type A telque l’ensemble A ci-dessus. Cette remarque illustre le fait que la configuration permetde représenter de manière finie des problèmes ne disposant que de solutions infinies etjustifie sa semi-décidabilité.A contrario, le modèle objet de la figure 4.2 ne possède que des solutions finies. Unesolution de ce modèle est, par exemple, le triplet (a, b 1 , b 2 ) où a est une instance de laclasse A et b 1 , b 2 des instances de la classe B tels que ab(a) = {b 1 , b 2 }.L’entrée d’un problème de configuration est un ensemble de composants que l’utilisateursouhaite voir apparaître dans la solution. A partir de cette entrée le configurateurpeut choisir dans sa base de composants autant d’éléments qu’il lui est permis1 Des heuristiques sont possibles notamment pour fixer les cardinalités des relations avant de configurerles objets liés par cette relation ou l’ordre de parcours des relations.2 R + est la fermeture transitive de la relation R, cette contrainte définit son irréflexivité. Dans notreexemple, la contrainte spécifie qu’aucun A ne peut être utilisé deux fois dans la relation R.- 45 -

4 : Méthode de recherche de modèles finis pour les modèles objet contraintsFig. 4.2 – Un modèle objet non cycliqueet nécessaire pour compléter le sous-modèle (l’entrée) afin d’obtenir une solution satisfaisantl’ensemble des contraintes génériques et spécifiques. La configuration est uneméthode de recherche de modèles finis. A partir d’un objet racine, la recherche de solutionparcourt l’arbre de recherche jusqu’à trouver une instance du modèle objet contraintassocié, si il en existe une. Il est également possible de demander toutes les solutionspossibles pour une entrée donnée. Nous utilisons le configurateur JConfigurator de lasociété ILOG [41] 3 .4.1 JConfiguratorJConfigurator combine d’une part les logiques de description et d’autre part laprogrammation par contraintes. Ce configurateur repose sur les description logics [3] 4et plus précisément sur un langage proche de FPC[45]. L’utilisation des TBox estréservée à la représentation des concepts et des rôles tandis que les ABox sont associéesaux contraintes. La résolution, quant à elle, est dirigée par la méthode des tableauxgénéralisée. [41] est un article entièrement consacré à la logique utilisée dans JConfigurator.4.1.1 Domaine d’interprétationDans JConfigurator, les composants disponibles pour la recherche appartiennent auplus petit ensemble d’objets maximisant les cardinalités récursivement sur les objetsatteignables à partir d’un ensemble d’objets racines (instances d’une même classe). [41]appelle cet ensemble un Partonomic Herbrand Universe. Cette définition implique quele domaine traité est fini dès lors qu’il n’existe pas de cycle dans les relations.4.1.2 Traduction d’un modèle objet contraint en un problème JConfiguratorLes Objets et les Classes ainsi que les fonctions définissant les attributs sont directementreprésentés dans le modèle objet de JConfigurator. Cependant il est également pos-3 Le configurateur JConfigurateur est implémenté en JAVA4 http ://dl.kr.org est un site dédié exclusivement aux activités de recherche autour des logiques dedescription- 46 -

4 : Méthode de recherche de modèles finis pour les modèles objet contraintssible de définir ces éléments par des commandes, c’est cette syntaxe que nous présentonsici. Elle permet de mettre en évidence le caractère modulaire et biunivoque de la traductiond’un modèle objet contraint sous la forme d’un problème de configuration.Création de classes et d’instances dans JconfiguratorA toute déclaration de classe en Z de la forme :uneClasse : Classecorrespond la déclaration suivante en JConfigurator 5 :makeClass(uneClasse)Par définition, les classes JConfigurator ne peuvent pas partager leurs instances (lesobjets qu’elles contiennent) sauf si il existe un lien de parenté entre ces deux classes (l’uneest ancètre de l’autre dans la hiérarchie de classes). Le type Objet de la formalisation estun type non-interprété général, dans JConfigurator, les instances de classes sont généréesà partir des classes de la manière suivante :makeInstance(nom instance, nom classe)Création d’attributs de classes dans JConfiguratorEn formalisation Z de modèle objet contraint, un attribut est une fonction de laclasse vers le domaine de l’attribut. Dans JConfigurator, un attribut est représenté parun champ (field) de la classe à laquelle il est rattaché. La syntaxe pour définir un attributest la suivante :makeField(nom classe, nom attribut, domaine)Création de rôles dans JConfiguratorLes seules relations autorisées dans un modèle objet de JConfigurator sont les rôles,ils sont nommés ports et sont implémentés, comme les attributs, par des champs, de typeObject (instance de classe) ou ObjectSet (ensemble d’instances). La syntaxe généralepour définir un port est la suivante :makeField(nomClasseSource,nomChamp,domaine(cardMin, CardMax, objectDomain(nomClasseCible)))5 Dans cette partie nous omettons volontairement certaines lourdeurs d’écriture. L’annexe A présentela syntaxe utilisée par JConfigurator à travers l’exemple de l’assemblage d’ordinateurs présenté à la finde ce chapitre.- 47 -

4 : Méthode de recherche de modèles finis pour les modèles objet contraintsUn exempleAfin de replacer dans leur contexte d’utilisation les déclarations données ci-dessus,nous détaillons le problème de configuration associé au diagramme de la figure 4.2 dontnous rappelons la formalisation en Z :A : ClasseB : Classeatt : A " ∀ a : A • a.att ≤ 1000ab : A " B∀ a : A • 0 ≤ #(a.ab) ≤ 4∀ a 1 : A, a 2 : A | a 1 ≠ a 2 • ∀ b : B • b ∈ a 1 .ab ⇒ b /∈ a 2 .abLa contrainte ∀ a 1 : A, a 2 : A | a 1 ≠ a 2 • ∀ b : B • b ∈ a 1 .ab ⇒ b /∈ a 2 .ab traduitla sémantique du losange noir (relation de composition) de la figure 4.2. Ce problèmeconfiguration est défini par les instructions 6 suivantes :makeClass("A");makeClass("B");makeField("A","att",intDomain(0,1000));makeField("A","ab",setDomain(0, 4, objectDomain("B")));a_1,a_2 = var(getClass("A"));b = var(getClass("B"));forall(a_1,a_2,neq(a_1,a_2),forall(b, imply(member(b,a_1.getObjectSetField("ab")),notMember(b,a_2.getObjectSetField("ab")))));où :– objectDomain représente le domaine contenant tous les objets de type B.– setDomain définit un ensemble avec ses cardinalités maximales et minimales et ledomaine des éléments contenus dans cet ensemble.– intDomain définit un ensemble d’entiers.– var(C) est la fonction permettant de créer une variable représentant une instancede classe C.6 JConfigurator n’implémente pas la génération d’instances dynamique. Une borne maximale doit êtredéfinie pour les cardinalités des relations se terminant par ∗ et les bornes maximales et minimales desdomaines des attributs doivent être finis.- 48 -

4 : Méthode de recherche de modèles finis pour les modèles objet contraints– getClass(name) retourne la classe dont le nom est name.– forall est la représentation JConfigurator de ∀.– imply est la représentation JConfigurator de ⇒.– member(x,y) est une contrainte satisfaite si x appartient à l’ensemble y.– notMember(x,y) est une contrainte satisfaite si x n’appartient pas à l’ensemble y.Cet exemple illustre l’aspect modulaire de la traduction d’un formalisme vers l’autre. Achaque déclaration Z correspond une déclaration JConfigurator. De plus, toute déclarationJConfigurator peut être traduite en Z par la traduction inverse. Cette dernière est directecar tout élément d’un formalisme trouve son équivalent dans l’autre.La traduction des prédicats possède la même propriété. Supposons que pour un objetde type A, l’attribut (att) représente le nombre d’objets de type B dont il est composé.En Z cette contrainte s’écrit :∀ a : A • a.att = #(a.ab)La syntaxe JConfigurator pour cette contrainte est la suivante :a = var(getClass("A"))forall a, eq(a.getIntField("att"),a.getCardinality("ab"))Là encore la traduction est directe. Les deux seules différences sont la déclaration desvariables avant leur utilisation et la syntaxe préfixe des opérateurs.4.1.3 Un outil correct et completL’algorithme utilié par JConfigurator a été prouvé correct et complet.Proposition 1 Pour tout problème de configuration, tout modèle solution trouvé parJConfigurator est une solution du problème initial.Proposition 2 Pour tout problème de configuration, si le problème possède une solutionatteignable alors JConfigurator est capable de l’atteindre (éventuellement en un tempsinfini).Pour un modèle objet contraint quelconque, il est possible de traduire modulairementce modèle en un problème de configuration. Nous nous appuyons sur la modularité dela traduction d’un formalisme à l’autre pour montrer que le problème de configurationreprésente bien le modèle objet contraint.4.1.4 Une traduction modulaireComme nous avons vu dans la section 4.1.2, la configuration et les modèles objetcontraints partagent les notions de classes, d’instances (ou objet), d’attributs et de relations(modulo une expression plus laborieuse en JConfigurator qui n’utilise que les ports).Ces notions communes ne diffèrent d’un formalisme à l’autre que dans la représentation.La traduction de l’un à l’autre est directe par réécriture syntaxique. L’exemple de traductionde la section 4.1.2 propose notamment le passage d’un prédéciat Z à sa forme en- 49 -

4 : Méthode de recherche de modèles finis pour les modèles objet contraintsJConfigurator, cette traduction est généralisable à tout prédicat Z . Tous les opérateurspermettant de construire des prédicats Z (utilisés pour formaliser les contraintes) ontleurs équivalents dans JConfigurator. Sans en faire une liste exhaustive, nous proposonsquelques équivalences :Les contraintes sur les ensemblesLe traitement des ensembles est naturel dans Z , l’union et l’intersection d’ensemblescomme le test d’appartenance d’un élément à un ensemble sont des opérations aisémentreprésentables, elles sont, de plus, très utilisées dans les modèles objets contraints (pardéfinition ensemblistes). JConfigurator définit les opérations d’union, d’intersection etd’appartenance sur les ports d’un objet ou d’un ensemble d’objets. L’union (respectivementl’instersection) de deux ports est réalisée par l’opérateur union(port 1 , port 2)(intersect(port 1 , port 2)). Le test d’appartenance est quant à lui rendu parl’opérateur member(objet, port).Les quantificationsLes seules quantifications utilisées dans les modèles objets sont les quantificationsuniverselles. Ces quantifications sont réalisées par l’opérateur forall de JConfigurator.Cependant ce dernier traite des variables ayant un type prédéfini, alors qu’en Z unevariable est définie localement à la contrainte. Cependant, il est tout de même raisonnabled’associer à chaque classe du modèle JConfigurator une variable du bon type quila représentera.Les opérateurs logiquesLes quatres opérateurs logiques, ∧, ∨, ⇒, ¬ disposent de leurs équivalents en JConfigurator: and,or,implies,notCorrection et complétude globalesIl existe une équivalence entre tout prédicat Z exprimable dans un modèle objetcontraint et les opérateurs de JConfigurator. L’ensemble des prédicats et des élémentsformant le modèle objet contraint sont donc traduisibles en un problème de configuration.La traduction est reversible dans le sens où tout problème de configuration estexprimable sous la forme d’un modèle objet contraint. Cette propriété provient de lamodularité des traductions. Nous avons d’autre part vu que l’outil de configuration utiliséest correct (proposition 1). A partir de ces deux remarques, nous pouvons donner laproposition suivante :Proposition 3 Soient M un modèle objet contraint, sol l’ensemble de ses solutions etP le problème JConfigurator associé à M , toute instance atteignable par P appartientà sol (à un renommage près).- 50 -

4 : Méthode de recherche de modèles finis pour les modèles objet contraintsEn effet, à partir d’une instance Inst d’un problème de configuration (exprimé en JConfigurator)P, traduction d’un modèle objet contraint M , on peut associer à chaque instancede classe un entier et interpréter les relations et les attributs comme des couplesd’entiers (ou des couples (entier,ensemble d’entiers)). On peut vérifier que cette interprétationde Inst est bien solution de M , par la méthode vue dans le chapitre 3,section 3.3. D’autre part, la recherche de modèles finis de JConfigurator est complète(proposition 2), la traduction d’un formalisme à l’autre étant biunivoque, nous disposonsde la proposition suivante :Proposition 4 Pour tout modèle objet contraint M et sa traduction en problème deconfiguration P, toute instance de M appartient à l’ensemble des instances (à un renommageprès) atteignables par la recherche de modèles finis de JConfigurator appliquée àP.Les deux propositions ci-dessus permettent de dire que l’outil JConfigurator est adaptéà la résolution des modèles objet contraints.4.2 Exemple de problème de configuration : l’assemblaged’ordinateurDans cet exemple, les composants possibles pour configurer un PC sont choisisparmi l’ensemble : {carte mère, disque dur, processeur, barette de mémoire, alimentation,écran}. Bien évidemment d’autres composants pourraient entrer en compte tels que lacarte son, la carte vidéo ou la carte réseau. Cependant l’ensemble choisi est de taillesuffisamment grande pour présenter précisément le type de problèmes traités et suffisammentrestreinte pour ne pas se perdre sous une trop grande quantité de contraintes.La configuration orientée objet nous permet de représenter le modèle générique via unmodèle de classes que l’on peut représenter en utilisant la notation UML2[34, 29] 7 . Lamodélisation UML+Z vue au précédent chapitre permet de modéliser parfaitement unproblème de configuration.4.2.1 Le modèle objetLa figure 4.3 est un rappel de la figure 2.9 vue au chapitre 2. Cette figure présentele modèle objet générique modélisant tout type de pc. Nous pouvons remarquer quele modèle objet utilisé est du même type que ceux utilisés pour la présentation desCOMs. Les deux seuls types de relations utilisés ici sont les relations de composition etd’héritage.Nous pouvons notamment noter pour les relations de composition que la relation quilie les classes CarteMere et Processeur signifie que toute instance de CarteMere doitcontenir (être liée à) au moins une et au plus deux instances de la classe Processeur.La relation de composition est exclusive : un processeur composant d’une carte-mère nepeut appartenir à une autre carte-mère. Les classes représentent les types de composants7 Unified Modeling Language- 51 -

4 : Méthode de recherche de modèles finis pour les modèles objet contraintsFig. 4.3 – Modèle (UML) de données générique pour représenter un PCcités plus haut. Cependant deux classes supplémentaires sont présentes : la classe Composantet la classe consommateurDEnergie. Ces classes sont appellées abstractions carelles ne représentent pas d’objet « concret » mais permettent de factoriser des élémentscommuns aux autres classes : les attributs prix et energieConsommée. L’héritage permetde transmettre ces attributs aux autres classes. Tout composant a un prix. Seule laclasse Alimentation ne possède pas l’attribut energieConsommee. En effet, cette dernièretransmet l’énergie aux autres composants. Nous détaillerons plus loin les liens entre lesattributs energieConsomee et energieFournie. Tout ordinateur peut être représenté parle schéma de la figure précédente. Cependant, il est nécessaire de préciser certainescontraintes pour renforcer la cohérence du modèle.4.2.2 Les contraintesCertaines contraintes sont définies implicitement sur le modèle objet vu ci-dessus viales cardinalités des relations. Cependant, d’autres contraintes sont nécessaires, commepar exemple la contrainte spécifiant que la somme des valeurs des attributs energieConsomeede chaque composant d’un ordinateur donné doit être inférieure à la valeur de l’attributenergieFournie de l’alimentation associée au PC. Il est aussi important de préciserles compatibilités de types entre la carte mère et les disques durs utilisés, de même queles types de barettes de mémoire. Le modèle et les contraintes génériques permettentde modéliser un « monde » encapsulant toutes les solutions possibles pour l’ensembledes problèmes potentiels sur ce monde. D’un autre côté, les contraintes spécifiques sontpropres à une instance de problème issu du monde. Lorsqu’un utilisateur cherche à configurerun pc, il va pouvoir spécifier certains critères (comme « le pc a deux disques durs », ou « Tout disque dur est de type SATA » ). Ces critères sont spécifiés sous la forme de- 52 -

4 : Méthode de recherche de modèles finis pour les modèles objet contraintscontraintes.Nous présentons dans un premier temps les contraintes communes à tout pc. Cescontraintes sont exprimées en Z de la même manière que dans le chapitre précédent.Les contraintes génériquesCes contraintes représentent l’ensemble des règles de bonne formation d’un ordinateur,quel qu’il soit.– Contrainte sur la puissance fournie par l’alimentation :Cette dernière doit être supérieure à la somme des énergies consommées par lescomposants de l’ordinateur.∀ o : Ordinateur • o.alimentation.puissanceFournie ≥(o.ecran.energieConsommee+bagsum(o.disqueDur energieConsommee)+o.carteMere.energieConsommee+bagsum(o.carteMere.processeur energieConsommee)+bagsum(o.carteMere.ram energieConsommee))– Contrainte sur les compatibilités de type entre l’ordinateur et les disques durs :Les valeurs des attributs typeDD d’Ordinateur et type de DisqueDur sont égalespour des instances en relation.∀ o : Ordinateur • ∀ dd : o.disqueDur • dd.type = o.typeDD– Contrainte sur les compatibilités de type entre la carte mère et les barettes demémoire De même que pour la contrainte précédente : les valeurs des attributstypeRam de CarteMere et type de Ram sont égales pour des instances en relation.∀ cm : CarteMere • ∀ r : cm.ram • r.type = cm.typeRam– Le prix total de la carte mère est égal à la somme des prix de ses composants :∀ cm : CarteMere • cm.prixTotal = cm.prix+bagsum(cm.processeur prix)+bagsum(cm.ram prix)– Le prix total de l’ordinateur est égal à la somme des prix de ses composants :∀ o : Ordinateur • (o.prixTotal) = o.carteMere.prixTotal+o.ecran.prix + o.alimentation.prix+bagsum(o.disqueDur prix)L’ensemble formé par ces cinq contraintes permet de représenter toutes les instancesde pc valides. Voyons à présent trois contraintes spécifiques. Nous allons chercher àconfigurer un ordinateur qui possède deux disques durs et dont tous les disques dursreliés sont de type SATA. Toutes les autres caractéristiques ne sont soumises qu’auxcontraintes génériques.- 53 -

4 : Méthode de recherche de modèles finis pour les modèles objet contraintsLes contraintes spécifiques à une instance de problème– Le pc a deux disques dursOn peut définir dans une même définition les contraintes spécifiques à l’ordinateurou alors définir l’instance pc d’ordinateur et poser des contraintes par la suite,nous présentons pour cet exemple les deux méthodes :ou alors :suivit de :pc : Ordinateur#(pc.disqueDur) = 2pc : Ordinateur#(pc.disqueDur) = 2– Tout disque dur relié au pc est de type SATA∀ dd : DisqueDur | dd ∈ pc.disqueDur • dd.type = SATA4.2.3 Modèles trouvésLe problème de configuration présenté est peu contraint : nous obtenons 1026 modèlesfinis solutions pour la configuration d’un ordinateur avec seulement cinq disques durs,trois écrans, cinq processeurs, trois cartes mères, six barettes de ram et trois alimentations.Le détail des instances choisies ainsi que la syntaxe des contraintes sous JConfiguratorsont présentés dans l’annexe A. Avec ces mêmes instances et les contraintessuivantes :1. le prix du pc est inférieur ou égal à 7502. l’alimentation a une puissance inférieure ou égale à 3003. la carte mère a deux processeursil existe une seule solution.Arbre de rechecheLes objets disponibles lors de la recherche sont présentés sur la figure 4.4. Nousconsidérons l’exemple contenant les cinq contraintes. L’objet racine est l’objet pc. Unmécanisme de propagation est effectué à chaque affectation de variable afin de filtrerles domaines. A titre d’exemple, nous présentons le résultat d’une propagation descontraintes avant tout choix de variables sur la figure 4.5. Le résultat de cette propagationest donné sous la forme de tuples représentant les attributs et les ports définissur les tableaux de la figure 4.4. Seuls les composants restant disponibles sont affichés.La recherche démarre donc de l’objet pc choisi comme racine. Le port ecran est un de- 54 -

4 : Méthode de recherche de modèles finis pour les modèles objet contraintsses ports non instanciés, la valeur e2 lui est attribuée. e2 ne contient qu’un seul portnon instancié : le port ordinateur qui reçoit la valeur pc (seul ordinateur disponible parrelation inverse de la relation de composition). Ainsi de suite, les différents composantsdu pc sont choisis. L’arbre de recherche aboutissant à la solution est présenté sur lafigure 4.6. Aucun retour n’est effectué et la recherche mène directement à l’unique solution.L’arbre de la figure 4.7 montre la fin de la recherche. Pour des raisons de lisibilité,sur cette figure, seuls les nouveaux arcs sont étiquettés. Le symbole □ représente unéchec. Les arcs en pointillés représentent les retours du programme (« backtracks ») surdes variables déjà instanciées. Enfin, les noeuds sont étiquetés par l’étape de la rechercheà laquelle ils ont été visités.- 55 -

4 : Méthode de recherche de modèles finis pour les modèles objet contraintsnom puissanceFournie prix ordinateura1 300 40 ?pca2 350 50 ?pca3 400 65 ?pc(a) Instances de la classe Alimentationnom prixTotal ecran disqueDur carteMere alimentation typeDDpc 0..10000 ?e1 ?e2 ?dd1 ?dd2 ?dd3 ?dd4 ?dd5 ?cm1 ?cm2 ?cm3 ?a1 ?a2 ?a3 ?SATA ?IDE(b) Instance de la classe Ordinateur - l’objet racinenom typeRam prix eC eCT ordinateur prixTotal processeur ramcm1 SDR 115 40 - pc ? - ?p1 ?p2 ?p3 ?p4 ?p5 ?r1 ?r2 ?r3 ?r4 ?r5 ?r6cm2 SDR 190 45 - pc ? - ?p1 ?p2 ?p3 ?p4 ?p5 ?r1 ?r2 ?r3 ?r4 ?r5 ?r6cm1 DDR 245 50 - pc ? - ?p1 ?p2 ?p3 ?p4 ?p5 ?r1 ?r2 ?r3 ?r4 ?r5 ?r6(c) Instances de la classe CarteMere - eC représente l’attribut energieConsommee et eCT l’attributenergieConsommeeTotalenom vitesse prix eC carteMerep1 1500 115 30 ?cm1 ?cm2 ?cm3p2 2000 150 35 ?cm1 ?cm2 ?cm3p3 2500 230 45 ?cm1 ?cm2 ?cm3p4 3200 345 60 ?cm1 ?cm2 ?cm3p5 1500 115 30 ?cm1 ?cm2 ?cm3(d) Instances de la classe Processeurnom capacite type prix eC carteMerer1 256 SDR 40 25 ?cm1 ?cm2 ?cm3r2 512 SDR 70 30 ?cm1 ?cm2 ?cm3r3 512 DDR 75 35 ?cm1 ?cm2 ?cm3r4 1024 DDR 95 37 ?cm1 ?cm2 ?cm3r5 1024 SDR 85 33 ?cm1 ?cm2 ?cm3r6 512 DDR 80 28 ?cm1 ?cm2 ?cm3(e) Instances de la classe Ramnom capacite type prix eC ordinateurdd1 80 IDE 40 15 ?pcdd2 120 IDE 50 20 ?pcdd3 250 IDE 75 25 ?pcdd4 80 SATA 70 30 ?pcdd5 160 SATA 95 35 ?pc(f) Instances de la classe DisqueDurnom taille prix eC ordinateure1 17 50 25 ?pce2 17 250 27 ?pce3 19 320 35 ?pc(g) Instances de la classe EcranFig. 4.4 – Objets disponibles pour la recherche de modèle fini dans l’exemple du pc- 56 -

4 : Méthode de recherche de modèles finis pour les modèles objet contraints〈pc, 625..750, ?e1?e2, dd4dd5, ?cm1?cm2?cm3, a1, SATA〉〈a1, 300, 40, pc〉〈cm1, SDR, 115, 40, 95..271, ?pc, 270..1090, ?p1?p2?p3?p4?p5, ?r1?r2?r3?r4?r5?r6〉〈cm2, SDR, 190, 45, 100..276, ?pc, 345..1165, ?p1?p2?p3?p4?p5, ?r1?r2?r3?r4?r5?r6〉〈cm3, DDR, 245, 50, 105..281, ?pc, 400..1220, ?p1?p2?p3?p4?p5, ?r1?r2?r3?r4?r5?r6〉〈p1, 1500, 115, 30, ?cm1?cm2?cm3〉〈p2, 2000, 150, 35, ?cm1?cm2?cm3〉〈p3, 2500, 230, 45, ?cm1?cm2?cm3〉〈p4, 3200, 345, 60, ?cm1?cm2?cm3〉〈p5, 1500, 115, 30, ?cm1?cm2?cm3〉〈r1, 256, SDR, 40, 25, ?cm1?cm2?cm3〉〈r2, 512, SDR, 70, 30, ?cm1?cm2?cm3〉〈r3, 512, DDR, 75, 35, ?cm1?cm2?cm3〉〈r4, 1024, DDR, 95, 37, ?cm1?cm2?cm3〉〈r5, 1024, SDR, 85, 33, ?cm1?cm2?cm3〉〈r6, 256, DDR, 80, 28, ?cm1?cm2?cm3〉〈dd4, 80, SATA, 70, 30, pc〉〈dd5, 160, SATA, 95, 35, pc〉〈e1, 17, 50, 25, ?pc〉〈e2, 17, 250, 27, ?pc〉Fig. 4.5 – Résultats de la propagation des contraintes sur l’ensemble d’objets initial- 57 -

4 : Méthode de recherche de modèles finis pour les modèles objet contraintse1.ordinateur=pcpc.carteMere=cm1cm1.ordinateur=pc (5) (4)pc.ecran=e1 (3)(1) (2)cm1.ram=r1 (6)r1.carteMere=cm1p1∈cm1.processeurp1.carteMere=cm1p5∈cm1.processeurp5.carteMere=cm1 •(11) (10) (9) (8) (7)Fig. 4.6 – Arbre de recherche pour la première solution du problème du pc- 58 -

4 : Méthode de recherche de modèles finis pour les modèles objet contraints(1)(18)(22) (2)e2(19)e2.ordinateur=pc (3)(15)(17)(20) (4)pc.carteMere=cm2pc.carteMere=cm1□(16)□ (21) (5) (6) (7)(12)(14)cm1.processeur=p2 (8)□(13) (9) (10) •(11)Fig. 4.7 – Arbre de recherche pour une autre solution du problème du pc- 59 -

Chapitre 5Les grammaires de configurationNous avons vu dans les chapitres précédents que la configuration fournissait dessolutions de type modèle fini aux modèles objet contraints. Nous nous interessons maintenantau traitement de la syntaxe par des modèles objet contraints. Cette approchetrouve sa motivation dans les trois points suivants :1. Utilisation d’un même formalisme pour traiter la syntaxe et la sémantique.2. Le pouvoir expressif des modèles objet contraints.3. Appartenance de la méthode de résolution à MTS.Les grammaires de configuration définissent un cadre générique de traitement de toutegrammaire dès lors qu’elle supporte un traitement par contraintes. Elles proposent unlien entre l’entrée (le texte et son organisation en phrases constituées de listes ordonnéesde mots) et le formalisme linguistique utilisé qui est factorisé au niveau d’une uniqueclasse nommée Cat. La grammaire est ensuite déclinée en classes héritant de Cat et enrelations entre ces classes. La puissance expressive des modèles objet contraints permet,dès lors que l’on s’accorde sur le fait que les grammaires du langage naturel sont desgrammaires contextuelles (type 1 de la hiérarchie de Chomsky), de modéliser ces grammaireset de fournir les analyses adéquates en fonction des entrées. Pour toute entréedont l’interprétation est sujette à ambiguité, la recherche de modèles finis permet defournir autant d’analyses que d’interprétations différentes et maintient ainsi l’ambiguité.L’indépendance du formalisme grammatical, provenant de l’utilisation d’un modèle objetcontraint abstrait pour le représenter, est un des points forts du système proposé.Une grammaire de configuration est un modèle objet contraint. L’analyseur syntaxiqueest obtenu par la simple utilisation d’un algorithme générique de recherche de modèlesfinis pour ce modèle objet contraint.5.1 DéfinitionDéfinition 8 (Grammaire de configuration) Une grammaire de configuration estun modèle objet contraint comprenant :- 60 -

5 : Les grammaires de configuration– un modèle objet décrivant l’organisation des mots et des phrases au sein du texteainsi que leurs relations avec une classe abstraite mère de toute classe représentantune étiquette syntaxique. La figure 5.1 définit les classes et les attributs et la figure5.2 les relations en Z . Ce modèle est représenté sous sa forme UML2 sur lafigure 5.3.– l’ensemble de contraintes définissant les règles de bonne composition des élémentsdu modèle suivantes :1. Pour toute phrase, le premier mot appartient à la liste de mots2. Tout mot et la catégorie lui étant associée ont la m^eme valeurpour l’attribut phon3. Tout mot et la catégorie lui étant associée ont les m^emes valeurspour les attributs debut et fin4. Si un mot possède un suivant, la valeur de son attribut fin est égaleà la valeur de l’attribut debut de son suivantLa définition Z de ces contraintes est donnée sur la figure 5.4.Texte : ClassePhrase : ClasseMot : ClasseCat : ClassePhrase ⊆ Catphon : Mot " Stringdebut : Mot " fin : Mot " phon : Cat " Stringdebut : Cat " fin : Cat " Fig. 5.1 – Formalisation des classes et des attributs du modèle objet des grammaires deconfiguration- 61 -

5 : Les grammaires de configurationconstituants : Texte " PhraseconstituantsRev : Phrase Texte∀ t : Texte • #(t.constituants) ≥ 1∀ t : Texte ; p : Phrase • p ∈ constituants(t) ⇔ t = constituantsRev(p)catsAssociees : Phrase " CatcatsAssocieesRev : Cat Phrase∀ p : Phrase • #(p.catsAssociees) ≥ 1∀ p : Phrase ; c : Cat • c ∈ catsAssociees(p) ⇔ p = catsAssocieesRev(c)premierMot : Phrase " MotpremierMotRev == premierMot ∼listeDeMots : Phrase " MotlisteDeMotsRev : Mot Phrase∀ p : Phrase • #(p.listeDeMots) ≥ 1∀ p : Phrase ; m : Mot • m ∈ listeDeMots(p) ⇔ p = listeDeMotsRev(m)suivant : Mot " MotsuivantRev : Mot Mot∀ m : Mot • 0 ≤ #(m.suivant) ≤ 1∀ m 1 : Mot ; m 2 : Mot • m 2 ∈ suivant(m 1 ) ⇔ m 1 = suivantRev(m 2 )catAssociee : Mot " CatcatAssocieeRev : Cat Mot∀ m : Mot • 0 ≤ #(m.catAssociee) ≤ 1∀ m : Mot ; c : Cat • c ∈ catAssociee(m) ⇔ m = catAssocieeRev(c)Fig. 5.2 – Formalisation des relations du modèle objet des grammaires de configurationSur la figure 5.1, les attributs debut, fin et phon ont les sens suivants :Phon représente :– pour une instance de Mot, la chaîne de caractères associée au mot lui même– pour une instance de Cat :– si elle est associée à une instance de Mot, la valeur de l’attribut phon de cette- 62 -

5 : Les grammaires de configurationinstance– à l’union des valeurs des attributs phon des catégories qu’elle contientLes attributs debut et fin représentent, respectivement, le début et la fin d’un mot oud’une catégorie. Pour un mot m, m.fin = m.debut + 1. Pour une catégorie associéeà un mot, les attributs debut et fin sont égaux à ceux du mot. Pour une catégorie ccontenant d’autres catégories, c.debut (resp. c.fin) est égal au plus petit debut (resp. àla plus grande fin) des catégories contenues.Fig. 5.3 – Modèle objet des grammaires de configuration (Notation UML2)1. ∀ p : Phrase • ∀ m : p.premierMot • m ∈ p.listeDeMots2. ∀ m : Mot • ∀ c : m.catAssociee • m.phon = c.phon3. ∀ m : Mot • ∀ c : m.catAssociee • (m.debut = c.debut) ∧ (m.fin = c.fin)4. ∀ m : Mot | #(m.suivant) = 1 • ∀ m ′ : m.suivant • (m ′ .debut = m.fin)Fig. 5.4 – Contraintes génériques pour toute grammaire de configurationUne grammaire de configuration définit un noyau de grammaire qui est étendu parhiérarchisation et spécification de la relation catsAssociees entre les classes Phrase etCat (définissant les relations que peut entretenir le syntagme le plus général avec leséléments de la grammaire). Pour un formalisme linguistique donné, la grammaire deconfiguration est l’union du modèle objet contraint défini par les figures 5.1, 5.2 et5.4 et du sous-modèle objet contraint représentant le formalisme traité. L’analyseursyntaxique provient, quant à lui, de la traduction du modèle objet contraint en unproblème de configuration et de l’utilisation de la recherche de modèle finis pour uneentrée donnée.- 63 -

5 : Les grammaires de configurationPour une grammaire donnée, il est nécessaire de disposer d’un lexique spécifiant quelssont les types de catégories associables à un mot. Ce lexique sera plus ou moins détailléen fonction des éléments nécessaires à la grammaire. Les catégories sont des classes fillesde la classe Cat.5.2 Un exemple de langage hors-contextePour illustrer les grammaires de configuration à partir d’un exemple simple, nousproposons l’étude d’un micro-langage. Le langage a n b n est un langage archétypal desgrammaires hors-contexte. La grammaire associée est S → aSb | ɛ , avec S un symbolenon-terminal, a et b deux symboles terminaux et ɛ le mot vide. La grammaire deFig. 5.5 – Modèle objet pour le langage a n b nconfiguration implémentant ce langage est constituée du modèle objet présenté sur lafigure 5.5 et de l’ensemble de contraintes, exprimées en Z , suivant :1. La cardinalité de la relation catsAssociees est exactement 1∀ p : Phrase • #(p.catsAssociees) = 12. Le type de la catégorie liée à une phrase est S∀ p : Phrase • (p.catsAssociees) ∩ S ≠ 3. Une phrase et le S lui étant associé ont les m^emes valeursde debut et de fin∀ p : Phrase • ∀ c : (p.catsAssociees) • (p.debut = c.debut) ∧ (p.fin = c.fin)- 64 -

5 : Les grammaires de configuration4. Tout A et le S lui étant associé ont les m^emes valeurs de début∀ a : A • ∀ s : a.contientArev • a.debut = s.debut où contientArev définit le rôleinverse de la relation de composition contientA.5. Tout B et le S lui étant associé ont les m^emes valeurs de fin∀ b : B • ∀ s : b.contientBrev • b.fin = s.fin où contientBrev définit le rôle inversede la relation de composition contientB.6. Tout S contenant un autre S possède un debut plus petit que luiet une fin plus grande∀ s : S | #(s.contientS) = 1 • ∀ s ′ : s.contientS •(s.debut < s ′ .debut) ∧ (s.fin > s ′ .fin)7. Un S ne peut contenir qu’un a ou qu’un b∀ s : S • (#(s.contientA) + #(s.contientB)) mod 2 = 0Le programme résultant des spécifications précédentes autorise un fonctionnement analytique,génératif ou hybride dans le sens où il est capable de compléter des entréesincomplètes. La figure 5.6 illustre ce comportement. Les états du système y sont décritspar des tuples 〈mots, syntaxe〉 (le caractère ? dénote un objet inconnu et le caractère⋄ un mot inconnu) et son comportement par des règles état entrée ↦→ état sortie. Cesrésultats sont issus de l’article [24].⎧⎨⎩〈aaabbb, ?〉 ↦→ 〈aaabbb, S(A, S(A, S(A, null, B), B), B)〉〈abbb, ?〉 ↦→ false〈⋄ a ⋄ b, ?〉 ↦→ 〈aabb, S(A, S(A, null, B), B)〉Fig. 5.6 – Exemples de parsage5.3 Application au scrambling languageNous venons de voir que les grammaires de configuration permettaient de traiter leslangages hors contexte, qui sont par définition projectifs. A présent, nous allons nousintéresser à la non projectivité, et prendre comme exemple la permutation des argumentsdes groupes verbaux en allemand (scrambling). Dans un premier temps , nous présentonsles grammaires de configuration lexicalisées [33], qui utilisent le concept de gap (trouentre les mots associés à une catégorie) pour rendre compte de la projectivité d’ungraphe donné. Nous montrerons que l’approche par modèle objet contraint englobe lathéorie des grammaires de configuration lexicalisées, enfin nous montrerons comment lesgrammaires de configuration sont utilisées pour modéliser le scrambling language.5.3.1 Les grammaires de configuration lexicalisées[33] présente les grammaires de configuration lexicalisées. Ces grammaires s’appuientsur le concept de drawings.- 65 -

5 : Les grammaires de configurationUn drawing est une forêt dont les noeuds sont totalement ordonnés. Un drawing Dest dénoté par D = (V ;⊳, ≺). Le couple (V ;⊳) forme une forêt et le couple (V ;≺)forme un ordre total. La figure 5.7 présente un drawing. Sur cette figure, chaque noeudest associé à un mot (a, ... , f), l’ordre utilisé tel que a ≺ b ≺ c ≺ e ≺ f ≺ d. Une notionFig. 5.7 – Drawing appartenant à la classe D 1importante présentée dans cet article est celle de gap. La notion de gap est à rapprocherde la notion de projectivité des arbres de dépendance. Par exemple le drawing présentésur la figure 5.7 est non-projectif et contient un gap (entre les noeuds c et d) contenantdeux éléments (e et f ). Les drawings peuvent être classifiés par leur gap-degree. Le gapdegreed’un drawing est le nombre de maximal de gap sur l’ensemble de ses noeuds. Onreprésente par D g la classe des drawings dont aucun noeud ne possède plus de g gap.Le drawing de la figure 5.7 appartient à la classe D 1 .Une grammaire de configuration lexicalisée est constituée d’une classe de drawing etd’un ensemble de contraintes lexicales. Elle est notée G := (Σ, Π, Lex) où Σ et Π sont desensembles d’étiquettes de noeuds et de relations, respectivement, et Lex un ensemblede contraintes lexicales. Lex est constitué de triplets de la forme 〈I , Ω ;φ〉, où I et Ωsont des bags d’étiquettes de relations codant, respectivement, les relations entrantes etsortantes et φ un ensemble de contraintes.5.3.2 Le scrambling languageDans [33] les auteurs font référence au problème de la permutation des arguments(de type nominal) des groupes verbaux en allemand en se reposant sur l’article [7], quiprécise que ce phénomène est également présent dans les langues telles que le koréen oule japonnais. Ce phénomène de « permutation autorisée » est connue sous le terme descrambling. Dans l’article [7], les auteurs montrent qu’un formalisme peut modéliser lescrambling s’il est capable de générer le langage suivant :SCR = {π(n [0] , . . . , n [k] )v [0] , . . . , v [k] | k ≥ 0 et π une permutation}où les indices (de 0 à k, donnés en exposants pour rester en accord avec l’expressionoriginale) mettent en relation un verbe (v) avec son argument de type nom (n). Lagrammaire de configuration lexicalisée proposée pour traiter ce problème est G SCR :=({n, v}, {n, v}, Lex). Lex contient les entrées suivantes :1. 〈{n}, ; t〉 (où t représente la contrainte toujours vraie)Cette entrée signifie que tout noeud étiqueté par n est une feuille.- 66 -

5 : Les grammaires de configuration2. 〈, {n, v} ; n ≺ ω ∧ ω ≺ v ∧ w ⋊⋉ v〉 (ω est l’étiquette d’un noeud satisfiant cettecontrainte)Cette contrainte spécifie que le noeud racine (ici ω) est plus grand qu’un noeudétiqueté par n et adjacent à un noeud étiqueté par v.3. 〈{v}, {n, v} ; n ≺ ω ∧ ω ≺ v ∧ w ⋊⋉ v〉Cette entrée possède la même signification que la précédente mais appliquée, nonpas à la racine, mais à tout noeud atteint par une relation étiquetée v.4. 〈{v}, {n} ; n ≺ ω〉Cette contrainte précise que tout noeud atteind par une relation étiquetée v etétant source d’une relation étiquetée n doit être situé après un noeud étiqueté n.La figure 5.8 présente le drawing d’une analyse d’un mot appartenant au langage SCR.Fig. 5.8 – Example de drawing codant un mot reconnu par le langage SCRNous proposons de montrer que notre formalisme englobe le formalisme des grammairesde configuration lexicalisées. Pour ce faire, dans un premier temps, nous présentonsune grammaire de configuration qui prend en compte, très naturellement, le problèmedu scrambling et que la sémantique des contraintes présentées ci-dessus possède unéquivalent immédiat dans notre formalisme. Les catégories à introduire sont les catégoriesn et v. Le modèle objet est présenté sur la figure 5.9. Tout mot pourra donc être associéà une catégorie n ou v en fonction du lexique. Lors de la lecture de l’entrée le lexiqueassocie, à tout mot, une catégorie du type adéquat, en fonction de l’attribut « phon »,dont les attributs début et fin ont les même valeurs que ceux du mot. Traduction descontraintes lexicales présentées plus haut :1. 〈{n}, ; t〉 - cette contraire est directement représentée sur le modèle objet. Eneffet, la classe n ne possède pas de relation.2. 〈, {n, v} ; n ≺ ω ∧ ω ≺ v ∧ w ⋊⋉ v〉La contrainte de précédence entre ω et n est traduite par une contrainte deprécédence entre toute instance de v et l’instance de n dont il est composé.∀ v i : v •(v i .n.fin ≤ v i .debut)La contrainte de juxtaposition (⋊⋉) est traduite par la contrainte exprimant l’ordresur les v :∀ v i : v •(v i .v.debut = (v i .fin) + 1)- 67 -

5 : Les grammaires de configurationFig. 5.9 – Modèle objet de la grammaire de configuration codant la grammaire SCRL’ordre des v est directement lié à l’ordre des mots :Pour tout v, soit le mot associé à v n’a pas de suivant, soit la catégorie associée à son suivant appartientà la relation réflexive de v (et est donc de type v)∀ v i : v •(#(v i .catAssociee ∼ .suivant) = 0) ∨(v i .v = v i .catAssociee ∼ .suivant.catAssociee)Enfin, cette entrée lexicale correspond à la racine, pour traiter ce cas, nous utilisonsune contrainte spécifiant que la phrase (p) est liée à une catégorie v et que cettecatégorie ne compose pas une autre catégorie.p.catAssociee ∩ v ≠ ∀ v i : v | v i = p.catAssociee • #(v i .v ∼ ) = 03. Les deux autres contraintes lexicales expriment les possibilités pour un noeud v.Les contraintes données ci-dessus prennent en compte leur signification.Ce modèle objet contraint permet de fournir les k! solutions d’une entrée de taille 2k. Cessolutions correspondent aux permutations des n dans le langage SCR. Nous présentonsles analyses solutions fournies par l’implémentation de cette grammaire de configuration,avec Ilog JConfigurator, pour k de taille 3 sur les figures 5.10 et 5.11 (sur ces figuresseules les relations entre les instances de v et de n sont explicitées, la structure de l’entréeétant celle présentée en 5.10).- 68 -

5 : Les grammaires de configurationFig. 5.10 – Instances communes à toutes les solutions (codant l’entrée)5.3.3 Prise en compte du gap-degreeNous avons vu en section 5.3.1 que les drawings peuvent être classés par leurs gapdegree.Chaque noeud du drawing est associé à un mot de la phrase, nous sommespartis du constat que, pour un noeud non-feuille donné, un gap est constitué de motsconsécutifs non-atteints situés entre des mots atteints par le noeud lui même ou par sesfils. Pour capturer la notion de gap-degree par les grammaires de configuration il fautdéfinir les éléments suivants :– une catégorie Gap qui représente un gap, i.e. une suite de mots contigüs nonatteints (relation motsI ) par le noeud courant ou par ses fils– une catégorie GapCat qui hérite de Cat et contenant les attributs :– min et max : qui représentent les bornes du sous ensemble de mots à analyserpour chercher un gap pour le noeud considéré– gapDegree est le nombre de gap associés au noeud courant– gapDegreeMax correspond au nombre maximal de gap sous le noeud courantet les relations :– relation qui représente l’ensemble des fils du noeud courant– gaps associant au noeud courant les gaps lui correspondant– motsI représentant l’ensemble des mots non-atteints par le noeud courant ouses filsDéfinition des classesGapCat : ClasseGap : ClasseGapCat ⊆ Cat- 69 -

5 : Les grammaires de configuration(a) Solution 1 (b) Solution 2 (c) Solution 3(d) Solution 4 (e) Solution 5 (f) Solution 6Fig. 5.11 – Instances solutions pour le scrambling avec k = 3Définition des attributs et des relationsmax : GapCat " min : GapCat " gapDegree : GapCat " gapDegreeMax : GapCat " gap : GapCat " GapCatmotsI : GapCat " MotmotsI : Gap " Motrelation : GapCat " GapCatLe modèle objet associé au traitement des gap par les grammaires de configuration estprésenté sur la figure 5.12.Contraintes sur GapCatContraintes sur les valeurs min, max et cardinalité de gap de GapCat. Ces attributsreprésentent les bornes de la suite de mots qu’il faut analyser pour chercher un gap ;∀ c : GapCat • c.max =max({n : | ∀ c ′ : c.relation • n = (c ′ .debut)} ∪ {c.debut})∀ c : GapCat • c.min = min({n : | ∀ c ′ : c.relation • n = (c ′ .fin)} ∪ {c.fin})∀ c : GapCat | #(c.relation) = 0 • #(c.gap) = 0Contraintes sur les attributs gapDegree et gapDegreeMax. Le premier représente le gap-Degree pour un noeud donné, le second correspond à une information remontante des- 70 -

5 : Les grammaires de configurationFig. 5.12 – Insertion du traitement des gaps dans modèle objet des grammaires deconfigurationfeuilles à la racine pour déterminer le gap-degree du graphe obtenu.∀ c : GapCat • c.gapDegree = #(c.gap)∀ c : GapCat • c.gapDegreeMax =max({n : | ∀ c ′ : c.relation • n = (c ′ .gapDegreeMax)} ∪ {c.gapDegree})Contraintes définissant les mots inutilisés pour une catégorie. Cette contrainte est définieen fonction des constituants de la catégorie. Si une catégorie ne contient pas de constituants,alors c’est une feuille et les mots qu’elle n’utilise pas sont tous les mots de laphrase sauf lui même. Si une catégorie contient des constituants alors l’ensemble desmots qu’elle n’utilise pas est défini récursivement par les mots inutilisés de ses fils, privééventuellement du motlié à la catégorie courante.∀ c : GapCat | #(c.relation) = 0 •c.motsI = Mot \ {c.catAssocieeRev}∀ c : GapCat | #(c.relation) > 0 •c.motsI = ( ⋂ (c.relation → motsI )) \ {c.catAssocieeRev}Contrainte liant tout mot inutilisé et compris entre max et min (bornes atteignables parla catégorie ou un de ses successeurs) de la catégorie courante et un gap. Tout motsinutilisé doit appartenir à un gap.∀ c : GapCat • ∀ m : Mot |((m ∈ c.motsI ) ∧ (m.debut ≥ c.debut) ∧ (m.fin ≤ c.fin)) •m ∈ ⋃ (c.gap → motsI )- 71 -

5 : Les grammaires de configurationContraintes sur GapCette contrainte définit que tous les mots liés à un gap sont contigüs.∀ g : Gap • #(g.motsI ) = max(g.motsI → fin) − min(g.motsI → debut)Sur le modèle objet contraint ainsi défini, le gap-degree d’un modèle est porté par lacatégorie liée à la phrase, grâce à l’attribut gapDegreeMax. En effet cette catégorie estla racine du sous-graphe correspondant aux drawings des grammaires de configurationlexicalisées. Il est donc possible de forcer les types de graphes générés lors de la rechercheen fixant simplement la valeur du gapDegreeMax de la catégorie associée à la phrase.Par exemple pour le scrambling language, fixer le gapDegreeMax à 0 ne fournira aucunmodèle. Le fixer à 1, fournira les les modèles des figures 5.11(a), 5.11(b), 5.11(e)et 5.11(f). Finallement fixer le gapDegree supérieur ou égal à 2 fournira les six modèles.5.4 Application aux grammaires de propriétésNous avons présenté dans le chapître 2 le formalisme des grammaires de propriétés etvu la manière la plus élégante de représenter les structures de traits par une modélisationorientée objet. Nous allons à présent montrer l’utilisation des grammaires de configurationpour traiter les grammaires de propriétés.Dans un premier temps, suppposant acquise la représentation de toute structurede traits en un modèle objet, nous présentons la traduction des sept propriétés vuesprécédemment en contraintes modélisées en Z . Ainsi toute GP pourra être modélisée enun modèle objet contraint. Dans un second temps, nous présentons un algorithme detraduction automatique de toute GP en un modèle objet contraint. Puis, nous traduironsle modèle objet contraint résultant en une instance de problème de JConfigurator.Finalement nous présenterons des résultats sur l’utilisation des modèles objet contraintspour l’analyse syntaxique du langage naturel. Ces résultats sont une première étape dansle traitement des textes descriptifs, et nous verrons dans les chapitres suivants commentces analyses vont pouvoir coopérer avec la sémantique des descriptions.5.4.1 Traduction des propriétés en un modèle objet contraintDans le chapitre précédent nous avons montré que les structures de traits peuventse représenter par un modèle objet restreint aux constructions utilisées dans les modèlesobjet contraints. Nous allons présenter maintenant une traduction des propriétés desGP en contraintes et relations dans le formalisme des modèles objet contraints.Dans la suite de cette section, nous adopterons les notations suivantes :– SX représente un syntagme générique– A i , B j , C k ; i ∈ [1, n] ; j ∈ [1, m] ; k ∈ [1, p] représentent des catégoriesLes traductions génériques des contraintes des grammaires de propriétés vers un modèleobjet contraint ont été présentées dans [26] et [25].- 72 -

5 : Les grammaires de configurationTêtePour tout syntagme SX les catégories pouvant être tête sont présentées comme unensemble dont exactement un élément doit être choisi. Supposons que cet ensemble soitA = {A 1 , .., A n }. Dans ces conditions, la propriété de tête s’écrit :⎡⎤...⎡⎤... ...SX}⎢Props⎢⎣ ⎣Tête{A 1 , .., A n ⎥⎦... ...Nous savons donc qu’il existe au moins n+1 catégories dans le modèle générique :SX , A 1 , .., An. Et nous pouvons représenter la contrainte de tête comme une fonction dela classe SX vers l’ensemble A :SXTete : SX " {A 1 , .., A n }Cette fonction garantit l’obligation de présence et l’unicité de la tête pour le syntagmeSX .Cependant, cette contrainte peut être exprimée d’une manière différente. En effet,il est possible d’utiliser n relations de composition de SX vers chacune des catégoriesA i , i ∈ [1, n], comme présenté sur la figure 5.13, et la contrainte suivante qui assurel’unicité de la tête :∀ sx : SX • #(sx.SXTeteA 1 ) + ..#(sx.SXTeteA n ) = 1Fig. 5.13 – SX peut avoir comme tête {A 1 , .., A n }FacultativitéDe même que pour la propriété de tête, les éléments facultatifs sont présentés sousla forme d’un ensemble. Supposons que l’ensemble B = {B 1 , .., B m } soit l’ensemble descatégories facultatives du syntagme SX . Nous avons donc la formulation suivante :- 73 -

5 : Les grammaires de configuration⎡...SX⎢Props⎣⎤⎡⎤... ...}⎢⎣Facult{B 1 , .., B m ⎥⎦... ...De même que pour la propriété de tête, deux formulations sont possibles :– la première consiste en une fonction unique de la classe SX vers l’ensemble desparties de l’ensemble B :SXFacult : SX " {B 1 , .., B m }– la seconde est un ensemble de relations de compositions sur le modèle objetgénérique entre la classe SX et chacune des classes représentant les catégoriesB i , comme présenté sur la figure 5.14.Fig. 5.14 – SX peut contenir une ou plusieurs catégories parmi {B 1 , .., B m }ConstitutionOriginellement, cette propriété permet de représenter tous les éléments, qu’ils soienttête ou facultatifs, intervenant dans la constitution d’un syntagme. Cette propriété remplacecelle de facultativité dans [11]. Nous proposons, pour faciliter le traitement, l’utilisationdes deux propriétés conjointement, afin de rendre le plus accessible possible lesinformations dont nous aurons besoin. Supposons que les têtes sont l’ensemble A etles facultatifs l’ensemble B. Cette contrainte peut, tout comme les deux précédentes etplus généralement comme toute propriété ayant une sémantique de constitution, êtrereprésentée de deux manières différentes :– par une fonction :SXConst : SX " Objet∀ sx : SX • sx.SXConst = ({sx.SXTete} ∪ sx.SXFacult)- 74 -

5 : Les grammaires de configuration– par une relation de composition entre SX et la classe Cat, représentée sur lafigure 5.15, ainsi que par les contraintes :∀ sx : SX • (sx.SXTeteA 1 ) ⊆ sx.SXConst...∀ sx : SX • (sx.SXTeteA n ) ⊆ sx.SXConst∀ sx : SX • (sx.SXFacultB 1 ) ⊆ sx.SXConst...∀ sx : SX • (sx.SXFacultB m ) ⊆ sx.SXConstFig. 5.15 – Représentation de la relation de constitutionUnicitéLa propriété d’unicité se présente elle aussi comme un ensemble de catégories. Chacunedes catégories de cet ensemble ne peut avoir qu’une seule instance dans la partiefacultativité. Supposons que l’ensemble C = {C 1 , .., C p }, un sous-ensemble de l’ensembleB des facultatifs de SX , représente les éléments facultatifs de SX , nous avons alors l’expressionde la propriété d’unicité de la manière suivante :⎡⎤...⎡⎤...SX}⎢Props⎢⎣ ⎣Unic{C 1 , .., C p ⎥⎦...Cette propriété est une contrainte portant sur le nombre d’éléments présents dans l’intersectionde l’ensemble SXConst et de l’ensemble d’objets de C i , ∀ i ∈ [1, p] :∀ sx : SX • #(sx.SXConst ∩ C 1 ) ≤ 1...∀ sx : SX • #(sx.SXConst ∩ C p ) ≤ 1- 75 -

5 : Les grammaires de configurationExigenceLa propriété d’exigence lie un ensemble de catégories et un ensemble d’ensemblesde catégories. Elle signifie que, si tous les éléments de l’ensemble de catégories sontprésents dans le syntagme, alors, tous les éléments d’au moins un ensemble de l’ensembled’ensembles de catégories doivent être également présents. La représentation génériquede cette propriété est la suivante :⎡⎤...⎢ ⎡⎤⎥SXProps⎢⎣... ...Exig⎢⎣ ...... ...{A 1 , .., A n}⇒{ {B 11 , .., B 1l},..,} {B }k1 , .., B kq ⎥⎦où chaque B ij est une catégorie. La traduction de cette propriété en contrainte de modèleobjet contraint exprimée en Z est la suivante : rappelons que l’ensemble {A 1 , .., A n } estnoté A et notons SB 1 l’ensemble {B 11 , .., B 1l }, ... ,SB k l’ensemble {B k1 , .., B kq } ; pourfinir B ′ l’ensemble {SB 1 , .., SB k }.Exclusion∀ sx : SX •∀ a : A | (sx.SXConst ∩ a ≠ ) •#{b ′ : B ′ | ∀ b : b ′ • sx.SXConst ∩ b ≠ } ≥ 1La propriété d’exclusion engage deux ensembles de catégories et signifie que ces deuxensembles ne peuvent pas cooccurrer dans un même syntagme. Cette propriété se note :⎡⎤...⎡⎤... ...}}SXExcl{A 1 , .., A n {B 1 , .., B m Props⎢ ⎢⎣ ⎣ ...⎥⎦... ...En notant de nouveau A l’ensemble {A 1 , .., A n } et B l’ensemble {B 1 , .., B m }, cette propriétése traduit par la contrainte :∀ sx : SX • ∀ a : A ; b : B •((sx.SXConst ∩ a ≠ ) ⇒ (sx.SXConst ∩ b = )) ∧((sx.SXConst ∩ b ≠ ) ∧ (sx.SXConst ∩ a = ))- 76 -

5 : Les grammaires de configurationLinéaritéLa propriété de linéarité spécifie des ordres de précédence linéaire pour deux ensemblesde catégories. Pour traduire la linéarité, nous utilisons une contrainte portantsur les attributs debut et fin présents dans toute catégorie. En effet, ces deux attributssont définis dans la classe Cat dont toutes les catégories héritent. La propriété delinéarité se présente sous la forme⎡⎤...⎢ ⎡⎤⎥SXProps⎢⎣et se traduit par la contrainte :Accord... ...Lin⎢⎣ ...... ...{A 1 , .., A n}≺}{B 1 , .., B m ⎥⎦∀ sx : SX • ∀ a : A ; b : B •((sx.SXConst ∩ a ≠ ) ∧ (sx.SXConst ∩ b ≠ )) ⇒(∀ a ′ : a ; b ′ : b • a ′ .fin ≤ b ′ .debut)La propriété d’accord porte sur l’égalité de valeurs de traits. Les traits concernés sonttraités dans notre formalisme comme des attributs des classes. La propriété se note :⎡⎤...⎡⎤... ...SXAcc acc1(X) ≡ acc1(Y)⎢Props⎢⎣ ⎣ ...⎥⎦... ...où acc1 représente un des traits d’accord, comme genre ou nombre par exemple, et Xet Y sont des catégories. Cette propriété est traduite par la contrainte suivante :∀ sx : SX ; x : X ; y : Y | (x ∈ sx.SXConst) ∧ (y ∈ sx.SXConst) • x.acc1 = y.acc1Il est possible d’ajouter tout type de propriétés selon les besoins. Toute autre contrainteportant sur les relations entre les catégories constitutives d’un syntagme ou sur les attributsde ces mêmes catégorie sera traduite de la même manière que celle que nousvenons de voir.5.4.2 Traduction automatique d’une GPPour pouvoir traduire automatiquement une grammaire, il faut un langage pourdécrire cette grammaire. Nous proposons l’écriture de la grammaire en LaTeX. Cette- 77 -

5 : Les grammaires de configurationapproche permet, d’une part, de décrire la grammaire le plus formellement possiblepar des structures de traits grâce notamment au package avm 1 et, d’autre part, decommenter celle-ci.Nous avons développé un package LaTeX 2 qui permet de décrire toute grammaire depropriétés. A partir du fichier source LaTeX, nous avons implémenté un traducteur quipermet de créer le modèle objet contraint associé à la grammaire ainsi que le problèmede configuration qui permet de chercher des solutions lorsqu’une entrée est proposée.Cette traduction suit strictement la même présentation que précédemment ; nous endonnons ci-après les règles de réécriture.Les traits d’attributsLes traits d’attributs sont des traits qui correspondent directement à des attributs [de classes dans le modèle objet. Ce sont les traits définis dans la partie Trait ...]detoute catégorie. Il est soit possible d’établir une liste de tous les traits autorisés 3 , soitde créer les attributs correspondants directement lors de la lecture. Dans les deux cas,les règles de réécriture se représentent de manière similaire :– il faut obligatoirement être placé dans la valeur de l’attribut trait– le syntagme en train d’être défini est SX– att1 représente l’attribut et domatt1 son domaine de valeurs[att1 domatt1]=⇒ (SXatt1 : SX " domatt1)Ajout à la classe SX de l’attribut att1.Les traits de propriétés[Les traits de propriétés sont des valeurs du trait complexe Props ...]. Comme nousavons vu dans la section 5.4.1, les propriétés disposent d’une traduction automatisable ;nous en rappelons ci-dessous les règles de réécriture :Traduction 1 (Tête)[Tête{A 1 , .., A n} ] =⇒ (SXTete : SX " {A 1 , .., A n })Ajout à la classe SX des relations avec les Ai1 avm.sty de Chris Manning’s disponible électroniquement à l’adresse http ://nlp.stanford.edu/ manning/tex/2 gp.sty - disponible électroniquement à l’adresse http ://www.lsis.org/∼estratatm/configuration/pgp/gp.sty3 ce que nous proposons dans le fichier attributs.def disponible surhttp ://www.lsis.org/∼estratatm/configuration/pgp/featuresValues.def- 78 -

5 : Les grammaires de configurationTraduction 2 (Facultativité)[Facult{B 1 , .., B m} ] =⇒ (SXFacult : SX " {B 1 , .., B m })Ajout à la classe SX des relations avec les BiLes propriétés qui suivent nécessitent la relation SXConst définie dans le chapitre 5.4.1.SXConst : SX " Objet[Unic{C 1 , .., C p} ] =⇒Traduction 3 (Unicité)∀ sx : SX • #(sx.SXConst ∩ C 1 ) ≤ 1...∀ sx : SX • #(sx.SXConst ∩ C p ) ≤ 1Restriction des cardinalités des relations de SXvers les CiTraduction 4 (Exigence)[Exig} { { }} {A 1 , .., A n ⇒ B 11 , .., B 1l ,..,{B }] =⇒k1 , .., B kq∀ sx : SX •∀ a : A | (sx.SXConst ∩ a ≠ ) •#{b ′ : B ′ | ∀ b : b ′ • sx.SXConst ∩ b ≠ } ≥ 1Si tous les Ai sont présents dans SX au moins un ensemble de Bidoit ^etre présentTraduction 5 (Exclusion)[Excl} { } {A ] 1 , .., A n B 1 , .., B=⇒ m∀ sx : SX • ∀ a : A ; b : B •((sx.SXConst ∩ a ≠ ) ⇒ (sx.SXConst ∩ b = )) ∧((sx.SXConst ∩ b ≠ ) ∧ (sx.SXConst ∩ a = ))L’ensemble des Ai et l’ensemble des Bi ne peuvent pas ^etreprésents en m^eme temps dans SX- 79 -

5 : Les grammaires de configuration[LinTraduction 6 (Linéarité)} { } {A ] 1 , .., A n ≺ B 1 , .., B=⇒ m∀ sx : SX • ∀ a : A ; b : B •((sx.SXConst ∩ a ≠ ) ∧ (sx.SXConst ∩ b ≠ )) ⇒(∀ a ′ : a ; b ′ : b • a ′ .fin ≤ b ′ .debut)Tout élément Ai doit ^etre placé avant tout élément Bi dans SXTraduction 7 (Accord)[Acc acc1(X) ≡ acc1(Y)]=⇒∀ sx : SX ; x : X ; y : Y | (x ∈ sx.SXConst) ∧ (y ∈ sx.SXConst) • x.acc1 = y.acc1Tout X et tout Y s’accordent en acc1 dans SXUn exemple complet de définition et traduction d’une grammaireLa grammaire proposée ici permet de traiter un sous-ensemble du français. Ce sousensemblecorrespond au fragment du langage naturel dont nous aurons besoin pouranalyser des descriptions.Pour chaque catégorie, nous présentons sa définition puis sa traduction en modèleobjet contraint. Il est à noter que toute catégorie possède un début et une fin ; cesattributs sont factorisés dans la classe Cat et lors de la traduction, toutes les classescorrespondantes aux catégories héritent de Cat.Les catégories terminales :Ces catégories sont attachées aux mots. Nous nous autorisons les étiquettes suivantes :Nom(N), Adjectif(Adj), Adverbe(Adv), Pronom(Pro), Déterminant(Det), Verbe(V) etPréposition(Prep). Les avm de ces étiquettes sont présentées sur la figure 5.16.Ces catégories ne contiennent pas de propriété, ainsi leur traduction est immédiateet consiste simplement à la création des classes correspondantes, avec les attributsadéquats. La figure 5.17 présente ce sous-modèle.Les catégories non-terminales :Les catégories non-terminales que nous utilisons sont : Syntagme Nominal(SN), SyntagmeVerbal(SV), Syntagme Prépositionnel(SPrep), le syntagme Adjectival(SAdj) etle syntagme Adverbial(SAdv). Toutes ces catégories héritent de la classe Cat, cependantpour des raisons de lisibilité des diagrammes, nous cacherons cette classe.- 80 -

5 : Les grammaires de configuration26N 4traits23genre fem, masc, neut674nombresing, plur5personne 1, 2, 3hCommun heritagehPropre heritageiNiN26Adj 4traits23genre fem, masc, neut674nombresing, plur5personne 1, 2, 3Adv []26Pro 4traits26Det 4traits26V 4traits23genre fem, masc, neut674nombresing, plur5personne 1, 2, 323genre fem, masc, neut674nombresing, plur5personne 1, 2, 323genre fem, masc, neut674nombresing, plur5personne 1, 2, 3Prep []Fig. 5.16 – AVM des catégories terminalesLe syntagme nominal est décrit par l’avm de la figure 5.18. Il est traduit par lacréation d’une classe héritant de Cat, contenant les attributs genre et nombre ainsi quepar les éléments suivants :– TêteLes relations SNTeteN et SNTetePro sont présentées sur la figure 5.19. Une têteest unique et obligatoire, ce qui est transcrit par la contrainte :∀ sn : SN • (#(sn.SNTeteN ) + #(sn.SNTetePro)) = 1- 81 -

5 : Les grammaires de configurationFig. 5.17 – Sous-modèle représentant les catégories terminales de la grammaire descriptiveLes attributs genre, nombre et personnes prennent les valeurs de ceux de la tête :∀ sn : SN • (#(sn.SNTeteN ) = 1) ⇒(∀ n : N | n ∈ (sn.SNTeteN ) •((sn.SNGenre) = (n.NGenre)) ∧((sn.SNNombre) = (n.NNombre)))∀ sn : SN • (#(sn.SNTetePro) = 1) ⇒(∀ pro : Pro | pro ∈ (sn.SNTetePro) •((sn.SNGenre) = (pro.NGenre)) ∧((sn.SNNombre) = (pro.NNombre)))– FacultativitéLes relations SNFacultDet, SNFacultSAdj et SNFacultSPrep sont représentées surla figure 5.20. La définition des catégories SAdj et SPrep est présentée plus bas.Cependant il est raisonnable d’utiliser les classes correspondantes pour représenterla propriété de facultativité du SN .– ConstitutionLa relation SNConst est définie sur la figure 5.21. A cette relation, il faut associerles contraintes :∀ sn : SN • sn.SNTeteN ⊆ sn.SNConst∀ sn : SN • sn.SNTetePro ⊆ sn.SNConst∀ sn : SN • sn.SNFacultDet ⊆ sn.SNConst∀ sn : SN • sn.SNFacultSAdj ⊆ sn.SNConst∀ sn : SN • sn.SNFacultSPrep ⊆ sn.SNConst– UnicitéLa propriété d’unicité se traduit par une restriction des cardinalités pour leséléments présents dans la relation de constitution : les éléments Det, SAdj et- 82 -

5 : Les grammaires de configuration2traitsSNprops64"#3genre fem ;mascnombre sing ;plur23têteN ;Profacultativité Det ;SAdj ;SPrepunicité Det ;SAdj ;SPrepexigence Det ⇒ N [Commun]N [Commun] ⇒ Detexclusion Adj ProDet ProN [propre] Detlinéarite Det ≺ NN ≺ PrepPaccord Det.genre ≡ N.genreDet.nombre ≡ N.nombreSAdj.genre ≡ N.genre64SAdj.nombre ≡ N.nombre75Fig. 5.18 – Catégorie SNFig. 5.19 – Sous-modèle pour la propriété de tête du SNSPrep ne peuvent apparaître qu’une fois.∀ sn : SN • #(sn.SNConst ∩ Det) ≤ 1∀ sn : SN • #(sn.SNConst ∩ SAdj ) ≤ 1∀ sn : SN • #(sn.SNConst ∩ SPrep) ≤ 1– ExigenceCette propriété spécifie que, si un Det est présent, alors un noyau de type Ndoit forcément être présent. La notation complète de cette propriété devrait être :{Det} ⇒ {{N ∗}} mais par abus de notation les accolades les plus extérieures dumembre de droite ont été omises. La génération automatique de cette contraintefournit la contrainte suivante :∀ sn : SN • ∀ a : {Det} | (sn.SNConst ∩ a ≠ ) •#{b : {Commun} | (sn.SNConst ∩ b ≠ )} ≥ 1- 83 -

5 : Les grammaires de configurationFig. 5.20 – Sous-modèle pour la propriété de facultativité du SNFig. 5.21 – Sous-modèle pour la propriété de constitution du SN– Exclusion∀ sn : SN • ∀ a : {Commun} | (sn.SNConst ∩ a ≠ ) •#{b ′ : {{Det}} | ∀ b : b ′ • (sn.SNConst ∩ b ≠ )} ≥ 1∀ sn : SN • ∀ a, b : Classe | (a ∈ {Det}) ∧ (b ∈ {Pro}) •((sn.SNConst ∩ a ≠ ) ⇒ (sn.SNConst ∩ b = )) ∧((sn.SNConst ∩ b ≠ ) ∧ (sn.SNConst ∩ a = ))∀ sn : SN • ∀ a, b : Classe | (a ∈ {SAdj }) ∧ (b ∈ {Pro}) •((sn.SNConst ∩ a ≠ ) ⇒ (sn.SNConst ∩ b = )) ∧((sn.SNConst ∩ b ≠ ) ∧ (sn.SNConst ∩ a = ))∀ sn : SN • ∀ a, b : Classe | (a ∈ {Det}) ∧ (b ∈ {Propre}) •((sn.SNConst ∩ a ≠ ) ⇒ (sn.SNConst ∩ b = )) ∧((sn.SNConst ∩ b ≠ ) ∧ (sn.SNConst ∩ a = ))– LinéaritéLes deux propriétés de linéarité du SN ordonnent les éléments Det et N ainsi queles éléments N et SPrep. Pour traduire ces précédences linéaires, nous utilisons les- 84 -

5 : Les grammaires de configurationattributs debut et fin définis dans la classe Cat :∀ sn : SN • ∀ a, b : Classe | a ∈ {Det} ∧ b ∈ {N } •((sn.SNConst ∩ a ≠ ) ∧ (sn.SNConst ∩ b ≠ )) ⇒(∀ a ′ : a ; b ′ : b • a ′ .fin ≤ b ′ .debut)∀ sn : SN • ∀ a, b : Classe | a ∈ {N } ∧ b ∈ {SPrep} •((sn.SNConst ∩ a ≠ ) ∧ (sn.SNConst ∩ b ≠ )) ⇒(∀ a ′ : a ; b ′ : b • a ′ .fin ≤ b ′ .debut)– AccordDans un syntagme nominal, le déterminant et le syntagme adjectival s’accordenten genre et en nombre avec le nom :∀ sn : SN ; x : Det ; y : N |(x ∈ sn.SNConst) ∧ (y ∈ sn.SNConst) • x.genreDet = y.genreN∀ sn : SN ; x : Det ; y : N |(x ∈ sn.SNConst) ∧ (y ∈ sn.SNConst) • x.nombreDet = y.nombreN∀ sn : SN ; x : SAdj ; y : N |(x ∈ sn.SNConst) ∧ (y ∈ sn.SNConst) • x.genreSAdj = y.genreN∀ sn : SN ; x : SAdj ; y : N |(x ∈ sn.SNConst) ∧ (y ∈ sn.SNConst) • x.nombreSAdj = y.nombreNLe syntagme prépositionnel est représenté sous la forme d’avm sur la figure 5.22.Cette catégorie est traduite en une classe SPrep héritant de Cat et ne contenant aucunattribut propre. Cette catégorie ne permet pas de prendre en compte les syntagmes2traits []2têteSPrepfacultativitépropsunicité6 64 4exigencelinéarite33PrepSNSNPrep ⇒ SN75Prep ≺ SNFig. 5.22 – Catégorie SPrepprépositionnels utilisant des circonstancielles. Nous n’aurons pas besoin de ce genre deconstructions pour traiter les phrases descriptives. La catégorie SPrep met en jeu cinqpropriétés, décrites ci-après.– TêteL’ensemble des éléments tête ne contient qu’un singleton. Cependant, la traductionautomatique produit la contrainte suivante :∀ sprep : SPrep • #(sprep.SPrepTetePrep) = 1- 85 -

5 : Les grammaires de configurationCette contrainte représente bien le fait qu’un SPrep doit contenir une tête de typePrep. La relation entre les classes SPrep et Prep est représentée sur le diagrammede la figure 5.23.Fig. 5.23 – La propriété de tête du syntagme prépositionnel– FacultativitéLe syntagme prépositionnel ne contient qu’une seule relation de facultativité :SPrepFacultSN . Cette relation est présentée sur la figure 5.24Fig. 5.24 – Eléments facultatifs d’un syntagme prépositionnel– ConstitutionLa propriété de constitution est alors créée en fonction de la tête et de l’élémentfacultatif :∀ sprep : SPrep • sprep.SPrepTetePrep ⊆ sprep.SPrepConst– UnicitéUn seul SN peut être facultatif :∀ sprep : SPrep • #(sprep.SPrepConst ∩ SN ) ≤ 1- 86 -

5 : Les grammaires de configuration– Exigence :Cette propriété permet de spécifier que la forme d’un SPrep est Prep + SN .∀ sprep : SPrep • ∀ a : Classe | a ∈ {Prep} • (sprep.SPrepConst ∩ a ≠ ) ⇒#{b ′ : {{SN }} | ∀ b : b ′ • (sprep.SPrepConst ∩ b ≠ )} ≥ 1– LinéaritéLa propriété de linéarité spécifie que la préposition doit être avant le syntagmenominal.∀ sprep : SPrep • ∀ a, b : Classe | a ∈ {Prep} ∧ b ∈ {SN } •((sprep.SPrepConst ∩ a ≠ ) ∧ (sprep.SPrepConst ∩ b ≠ )) ⇒(∀ a ′ : a ; b ′ : b • a ′ .fin ≤ b ′ .debut)Le syntagme verbal est décrit sur la figure 5.25. Cette catégorie est traduite en laclasse SV qui hérite de Cat et ne contient pas d’attribut propre.2SVprops642têtefacultativitéunicité64linéarite33VSN ;SAdvSN ;SAdv7V ≺ SN ;SAdv575Fig. 5.25 – Catégorie SV– TêteLa propriété de tête oblige à disposer d’un verbe dans un SV :∀ sv : SV • #(sv.SVTeteV ) = 1Le diagramme associé est représenté sur la figure 5.26.– FacultativitéLes deux seules catégories pouvant apparaître dans un SV , hormis le verbe tête,sont les syntagmes nominaux et adverbiaux associés aux relations SVFacultSN etSVFacultSAdv. La figure 5.27 représente le modèle objet correspondant.– UnicitéLes deux catégories facultatives ne peuvent pas apparaître plus d’une fois chacune :∀ sv : SV • #(sv.SVConst ∩ SN ) ≤ 1∀ sv : SV • #(sv.SVConst ∩ SAdv) ≤ 1– LinéaritéLe verbe doit être placé avant tout autre élément(SN ou SAdv) :∀ sv : SV • ∀ a, b : Classe | a ∈ {V } ∧ b ∈ {SN , SAdv} •((sv.SVConst ∩ a ≠ ) ∧ (sv.SVConst ∩ b ≠ )) ⇒(∀ a ′ : a ; b ′ : b • a ′ .fin ≤ b ′ .debut)- 87 -

5 : Les grammaires de configurationFig. 5.26 – La propriété de tête du syntagme verbalFig. 5.27 – La propriété de facultativité du syntagme verbalLe syntagme adverbial est présenté sur la figure 5.28. La catégorie SAdv estreprésenté uniquement par une tête de type Adv. L’ensemble des syntagmes adverbiauxde la langue française ne sont pas reconnus dans cette grammaire. Cette catégorie necontient qu’un seul élément et pourrait être supprimée et remplacée par l’adverbe luimême.∀ sadv : SAdv • #(sadv.SAdvTeteAdv) = 1Le modèle objet associé est défini sur la figure 5.29.La catégorie Phrase représente les structures de plus haut niveau des phrases quel’utilisateur est autorisé à formuler. Dans notre exemple, les phrases doivent être obligatoirementconstituées d’un syntagme nominal, qui sera le sujet, et d’un syntagme verbal.Nous avons vu précédemment que le syntagme verbal pouvait contenir éventuellementl’objet du verbe. L’avm de la catégorie phrase est présenté sur la figure 5.30.– TêteDe même que pour toutes les catégories possédant une seule tête, la contrainte- 88 -

5 : Les grammaires de configuration2SAdv 4 traits [] hprops tête3i5AdvFig. 5.28 – Catégorie SAdvFig. 5.29 – La propriété de tête du syntagme adverbialsuivante associée au diagramme de la figure 5.31 est nécessaire et suffisante :∀ phrase : Phrase • #(PhraseTeteSV ) = 1– FacultativitéLe syntagme nominal doit précéder le syntagme verbal :∀ phrase : Phrase • ∀ a, b : Classe | a ∈ {SN } ∧ b ∈ {SV } •((sv.PhraseConst ∩ a ≠ ) ∧ (sv.PhraseConst ∩ b ≠ )) ⇒(∀ a ′ : a ; b ′ : b • a ′ .fin ≤ b ′ .debut)L’ensemble des catégories présentées ci-dessus permettent d’analyser des phrasesque nous nommerons ”phrases de description”. En effet, le type de phrases que nouscherchons à manipuler est de type : sujet verbe complément(s), comme par exemple :”Le pc a deux disques durs”.2traits []2têtePhrasefacultativité6props64 4unicitélinéarite33SVSNSN75SN ≺ SV*Fig. 5.30 – Catégorie Phrase- 89 -

5 : Les grammaires de configurationFig. 5.31 – La propriété de tête de la catégorie PhraseNous présentons à présent la partie entrée du modèle objet contraint. Nous avons vuqu’une catégorie phrase était utilisée pour spécifier le type de syntagmes que celle-ci étaitautorisée à contenir. A présent regardons comment nous traitons le domaine lexical.Le modèle objet contraint attend comme entrée un texte contenant des phrases, cesphrases contenant elles-mêmes des mots qui seront associés à des catégories terminales.La figure 5.32 décrit cette partie de notre modèle.Fig. 5.32 – Entrée lexicale du modèleNous disposons ainsi d’un modèle objet contraint permettant d’analyser syntaxiquementtoute phrase de description contenant des mots du lexique. Tout mot inconnu serapar défaut associé à un nom propre. La figure 5.33 rassemble l’ensemble des sous-modèlesprésentés ci-dessus, en un seul diagramme de classes. La section suivante présente lesrésultats obtenus lors de l’implémentation sous la forme d’un problème de configurationdu modèle objet contraint présenté ici.- 90 -

5 : Les grammaires de configurationFig. 5.33 – Modèle objet global de l’analyseur syntaxique de descriptions5.5 ImplémentationDe nombreuses implémentations ont déjà été réalisées pour traiter le français en utilisantles grammaires de propriétés [62, 5, 4]. L’intérêt que nous portons au traitement dela syntaxe par les modèles objet contraints est, dans un premier temps, « alimentaire »pour le traitement de la sémantique. Nous avions besoin de valider l’approche d’unemanière formelle et de tester des implémentations afin de pouvoir s’assurer de la viabilitédu projet. La validation formelle est présentée en début de chapitre, où l’ensemblede la théorie est traduite en terme de modèle objet contraint. Tout modèle satisfaisantune instance de modèle objet contraint dédié à l’analyse syntaxique sera une analysevalide du point de vue des GP. La recherche de modèles finis présente l’avantage de proposerde nombreux algorithmes pour éliminer les symétries, de nombreuses heuristiquespour le parcours des arbres de recherche ainsi que la possibilité d’utiliser les souhaitsprésentées dans le chapitre 2. Dans [11], l’auteur propose l’utilisation de quasi-arbresunaires[9](QAU) pour faire remonter l’information associée à une catégorie. L’utilisationde la modélisation objet nous permet d’accéder directement à ces éléments sans avoir àconstruire une nouvelle structure. La figure 5.34 représente le quasi arbre unaire associé,dans notre grammaire, à l’étiquette N. Dans notre approche, la notion de ”QAU” estintrinsèque à la modélisation utilisée. Ainsi l’exemple de la figure 5.34 est directementreprésenté par les relations entre les classes SN et N d’une part et la classe SN et lesclasses Phrase, SV et SPrep d’autre part.Nous avons testé la grammaire présentée au début de ce chapitre pour analyser la- 91 -

5 : Les grammaires de configurationSXNPNFig. 5.34 – Exemple de quasi arbre unaire pour le N dans notre grammairephrase « Le pc possède deux disques durs ». La figure 5.35 représente l’unique modèletrouvé pour l’analyse de cette phrase.L’écriture d’une grammaire sous la forme d’un modèle objet contraint (ou d’unproblème de configuration pour la résolution pratique) est facilité par un traducteurque nous avons développé [23]. Pour ce travail, nous proposons un style L A TEX 4 permettantde représenter les grammaires de propriétés sous la forme d’avm. A partir dece fichier, le programme génère le problème de configuration associé. L’intérêt de cetraducteur est multiple :– l’implémentation des grammaires est facilitée 5 et les règles présentées en section5.4.2 garantissent une traduction valide,– cette traduction est totalement modulaire et permet, comme le propose PhilippeBlache, de n’utiliser que certaines propriétés– cette traduction est faite en un temps linéaireUn problème à l’heure actuelle est l’espace mémoire demandé par le configurateurdès que le nombre d’instances devient trop important. Le nombre de points de choix, etainsi, une partie de l’espace mémoire demandé, pourront être réduits, d’une part, pardes heuristiques de choix de variables ou de valeurs, d’autre part, par des algorithmesd’élimination de symétries ou encore de recherche locale. Les recherches de techniquesde résolution dans le domaine sont soutenues et leur adaptation à notre problème seranaturelle puisque les parties modélisation et résolution sont disjointes.Nous avons proposé une méthode de modélisation de la grammaire et une méthodede résolution basée sur la recherche de modèle. Cette grammaire simple montre que lesgrammaires de configuration sont capables de traiter l’analyse syntaxique sur la based’une grammaire de propriétés.4 Le style, disponible electroniquement à l’adresse http ://www.lsis.org/∼estratatm/configuration/pgp/gp.sty,utilise le style avm.sty de Christopher Manning5 Un autre avantage mineur est l’utilisation du même code pour écrire la grammaire et pour ladocumenter - l’exemple détaillé ici et le problème de configuration associé partagent le même codesource L A TEX- 92 -

5 : Les grammaires de configurationFig. 5.35 – Modèle fini résultat de l’analyse syntaxique de la phrase « Le pc possèdedeux disques durs »5.6 Application aux grammaires de dépendancesNous présentons le traitement des grammaires de configuration appliquées à la grammairede dépendances présentée sur la figure 5.36. Cette grammaire est définie dans [20].Ce formalisme s’articule autour d’arbres de précédence linéaire (LP tree) et de dominanceimmédiate (ID tree). Les liens entre les noeuds d’un ID tree sont de type rôlesyntaxique, tandis que que ceux d’un LP tree sont de type topologique. Un ID tree estnon-ordonné et non-projectif, tandis qu’un LP tree est partiellement ordonné et projectif.Nous présentons ci-dessous les classes du modèle objet, puis ses attributs et sesrelations, pour la grammaire de configuration associée à cet exemple de grammaire dedépendances.ClassesTrois classes sont nécessaires, une pour les noeuds des deux arbres(CatDep), unepour les arètes de l’arbre syntaxique (IDEdge) et la dernière pour les arètes de l’arbretopologique (LPEdges) :- 93 -

5 : Les grammaires de configurationGrammar SymbolsR = {det, subject, object, vinf , vpast, zuvinf }F ext = {df , mf , vc, xf }F int = {d, n, v}d ≺ df ≺ n ≺ mf ≺ vc ≺ v ≺ xf(Syntactic Roles)(External Topological Fields)(Internal Topological Fields)(Topological Ordering)LexiconWord Syntax TopologyIN S OUT S ON IN T OUT Teinen {det?} {} {d} {df ?} {}Mann {suject?, object?} {det!} {n} {mf ?} {df ?}Maria {subject?, object?} {} {n} {mf ?} {}lieben {vinf ?} {object?} {v} {vc?} {}geliebt {vpast?} {object?} {v} {vc?} {}können 1 {vinf ?} {vinf !} {v} {vc?} {vc?}können 2 {vinf ?, vpast?} {vinf !} {v} {xf ?} {mf ∗, vc?, xf ?}wird {vinf ?} {subject!, vinf !} {v} {vc?} {mf ∗, vc?, xf ?}haben {vinf ?} {vpast!} {v} {xf ?} {mf ∗, vc?, xf ?}hat {vinf ?} {subject!, vpast!} {v} {vc?} {mf ∗, vc?, xf ?}zulieben 1 {zuvinf ?} {object?} {v} {vc?} {}zulieben 2 {zuvinf ?} {object?} {v} {xf ?} {mf ∗, xf ?}versucht {vfin?} {subject!, zuvinf !} {v} {vc?} {mf ∗, vc?, xf ?}Fig. 5.36 – Fragment de grammaire de dépendanceCatDep : ClasseCatDep ⊆ CatIDEdge : ClasseLPEdge : ClasseLes relations sont représentées par des classes car il fallait pouvoir leur asocier uneétiquette. Ainsi, chaque arète et chaque noeud possède un label, les noeuds sont étiquetéspar les fonctions des mots auxquels ils sont associés (n, v, d), tandis que les arètes del’arbre ID sont étiquetées par des rôles syntaxiques (det, subject, object, vinf , vfin, vpast, zuvinf )et les arètes de l’arbre LP par les fonctions topologiques (df , mf , vc, xf ).[Label]- 94 -

5 : Les grammaires de configuration(a) ID Tree(b) LP TreeFig. 5.37 – Arbres ID et LP pour la phrase « Maria einen Mann wird haben liebenkönnen ».R : LabelFint : LabelFext : Labeldet, subject, object, vinf , vfin, vpast, zuvinf : Labeldf , mf , vc, xf : Labeld, n, v : LabelR = {det, subject, object, vinf , vfin, vpast, zuvinf }Fext = {df , mf , vc, xf }Fint = {d, n, v}L’union des labels topologiques et des labels de noeuds forme un ensemble totalementordonné, nous définissons donc la relation d’ordre (≺) :≺: Label # Label∀ x, y, z : Label • (x ≺ y ≺ z) ⇒ (x ≺ z)∀ x : Label • x ≺ x∀ x, y : Label | x ≠ y • x ≺ y ⇒ ¬ y ≺ xd ≺ df ≺ n ≺ mf ≺ vc ≺ v ≺ xfRelations et attributsLes relations de l’arbre ID sont outid et inid, elles représentent les arètes sortanteset entrantes pour un noeud donné.outid : CatDep " IDEdgeoutidrev : IDEdge " CatDep∀ e : IDEdge • e ∈ e.outidrev.outid- 95 -

5 : Les grammaires de configurationinid : CatDep " IDEdgeinidrev : IDEdge " CatDep∀ c : CatDep • #(c.inid) ≤ 1∀ e : IDEdge • e ∈ e.inidrev.inidLa cardinalité de inid est inférieure ou égale à un car les structures sont des arbres.Les relations de l’arbre LP sont outlp et inlp, elles représentent les arètes sortantes etentrantes pour un noeud donné.outlp : CatDep " LPEdgeoutlprev : LPEdge " CatDep∀ e : LPEdge • e ∈ e.outlprev.outlpinlp : CatDep " LPEdgeinlprev : LPEdge " CatDep∀ c : CatDep • #(c.inlp) ≤ 1∀ e : LPEdge • e ∈ e.inlprev.inlpDe même que pour inid, la cardinalité de inlp est inférieure ou égale à un car lesstructures sont des arbres. Trois attributs pour représenter les étiquettes sont définis :les étiquettes pour les arètes de l’arbre syntaxique (idEdgeLabel), celles pour les arètes depour l’arbre topologique (lpEdgeLabel) et enfin les étiquettes pour les noeuds de l’arbre(onLabel) :idEdgeLabel : IDEdge " RlpEdgeLabel : LPEdge " FextonLabel : CatDep " FintLe diagramme de classe UML2 associé à ces définitions est présenté sur la figure 5.38.Projectivité de l’arbre topologiqueAfin de pouvoir définir la propriété de projectivité de l’arbre topologique, il estnécessaire de définir une relation représentant l’ensemble des enfants d’un noeud dansl’arbre topologique : lpChildren.lpChildren : CatDep " CatDep∀ c : CatDep | c.outlp = • lpChildren(c) = {c}∀ c : CatDep | c.outlp ≠ •lpChildren(c) = {c} ∪ ⋃ {e : LPEdge | e ∈ c.outlp • lpChildren(e.inlprev)}La propriété de projectivité est garantie par une seule contrainte définissant que pourtout noeud de l’arbre LP, le nombre d’enfants du noeud est égal à la position de l’enfant- 96 -

5 : Les grammaires de configurationFig. 5.38 – Diagramme de classes pour modéliser les arbres ID et LPle plus à droite moins la position de l’enfant le plus à gauche. On garantit ainsi que lesenfants du noeud sont contigüs.∀ c : CatDep • #(lpChildren(c)) =max(lpChildren(c) → debut) − min(lpChildren(c) → debut)Ordre topologique∀ c : CatDep • ∀ e : c.outlp • e.lpEdgeLabel ≺ c.onLabel ⇔ e.inlprev.debut < c.debutLa relation host représente la source d’une relation de type outlp dans l’arbre syntaxique.host : CatDep " CatDep∀ c : CatDep • #(c.host) ≤ 1∀ c : CatDep • host(c) = {e : LPEdge | e ∈ c.inlp • e.outlprev}La relation head représente la source d’une relation de type outid dans l’arbre syntaxique.head : CatDep " CatDep∀ c : CatDep • #(c.head) ≤ 1∀ c : CatDep • head(c) = {e : IDEdge | e ∈ c.inid • e.outidrev}Les notations head et host sont introduites par [20].- 97 -

5 : Les grammaires de configuration5.6.1 Formalisation des principesLes principes permettent de définir des « règles » générales de correspondance entrel’arbre syntaxique et l’arbre topologique.ancestor est définie comme la fermeture reflexive-transitive de la relation head.Principe 1ancestor : CatDep " CatDep∀ c : CatDep | c.inid = • ancestor(c) = {c}∀ c : CatDep | c.inid ≠ •ancestor(c) = {c} ∪ ancestor((µ c2 : CatDep | c2 ∈ head(c) • c2))« A node must land on a transitive head ».La relation ancestor définie juste ci-dessus, représente une « transitive head ».∀ c : CatDep | host(c) ≠ • host(c) ⊆ ancestor(c)Principe 2« A node may not climb throught a barrier ». Le terme « barrière » n’est pas clairementdéfinie dans l’article [20]. L’idée de barrière est présentée comme une frontièrepropre à certaines catégories, telles que certaines catégories ne peuvent pas dépasser.Par exemple, un nom est une barrière pour un déterminant et les verbes de type vfinsont générallement des barrières pour tout type de catégories dont elle est ancêtre. Nepossédant pas de détail supplémentaires sur ce principe, nous ne pouvons en présenterune traduction en Z . Nous supposons que l’ajout d’un attribut barrier permettraitde préciser quels éléments ne pouvent pas avoir un père, dans l’arbre topologique, ledépassant.Principe 3« A node must land on, or climb higher than, its head ». Pour traiter ce principe,il est nécessaire d’introduire la fermeture réflexive-transitive de la relation host :hostAncestor :hostAncestor : CatDep " CatDep∀ c : CatDep | c.inlp = • hostAncestor(c) = {c}∀ c : CatDep | c.inlp ≠ •hostAncestor(c) = {c} ∪ hostAncestor((µ c2 : CatDep | c2 ∈ host(c) • c2))Le principe 3 se formalise ainsi :∀ c : CatDep • host(c) ⊆ hostAncestor((µ c2 : CatDep | c2 ∈ head(c) • c2))Les relations lpChildren, head, host, ancestor et hostAncestor sont représentées graphiquementsur la figure 5.39.- 98 -

5 : Les grammaires de configurationFig. 5.39 – Relations supplémentaires sur la classe CatDep5.6.2 Traitement du lexiqueA chaque mot, rencontré dans une phrase, correspond la création d’une ou plusieursinstances de la classe CatDep, nous notons cette instance par le mot lui même,éventuellement suivi par un indice si le mot possède plusieurs entrées dans le lexique.Pour chaque entrée w du lexique, IN S (w), OUT S (w), ON (w), IN T (w), OUT T (w)représentent, respectivement, les étiquettes des arètes syntaxiques entrantes et sortantes,le label topologique du noeud et les étiquettes des arètes topologiques entrantes et sortantes.Toute création d’une instance w de CatDep, via le lexique, est associée à un ensemblede contraintes portant sur les étiquettes (labels), ainsi, w.inid → idEdgeLabel ⊆ IN S (w).Il faut de plus contraindre les marques de valence (?, !, ∗). Soit l un label,– si l est optionnel ( ?) il lui correspond la contrainte :#{e : w.inid | e.idEdgeLabel = l} ≤ 1– si l est obligatoire ( !) alors il faut écrire la contrainte :#{e : w.inid | e.idEdgeLabel = l} = 1– enfin si l peut être plusieurs fois présent, cela se traduit par la contrainte :#{e : w.inid | e.idEdgeLabel ≥ l} ≥ 0De même, pour les autres étiquettes (OUT S , IN T et OUT T ) associées aux relationscorrespondantes (outid, inlp et outlp) :– w.outid → idEdgeLabel ⊆ OUT S (w)– w.inlp → lpEdgeLabel ⊆ IN T (w)– w.outlp → lpEdgeLabel ⊆ OUT T (w)Enfin, l’étiquette portée par ON est associée à la catégorie, soit o cette étiquette :w.onLabel = oA titre d’exemple, nous présentons, ci-dessous, l’instance crée à la lecture du mot« hat » dans une phrase.- 99 -

5 : Les grammaires de configurationhat : CatDephat.inid → idEdgeLabel ⊆ {vinf }#{e : hat.inid | e.idEdgeLabel = vinf } ≤ 1hat.outid → idEdgeLabel ⊆ {subject, vpast}#{e : hat.outid | e.idEdgeLabel = subject} = 1#{e : hat.outid | e.idEdgeLabel = vpast} = 1hat.onLabel = vhat.inlp → lpEdgeLabel ⊆ {vc}#{e : hat.inlp | e.lpEdgeLabel = vc} ≤ 1hat.outlp → lpEdgeLabel ⊆ {mf , vc, xf }#{e : hat.outlp | e.lpEdgeLabel = mf } ≥ 0#{e : hat.outlp | e.lpEdgeLabel = vc} ≤ 1#{e : hat.outlp | e.lpEdgeLabel = xf } ≤ 1De plus, il faut rajouter que le mot (hatW ) possède un début (d) et une fin (f ),connus ainsi qu’une valeur pour l’attribut phon (ph). Ces trois valeurs sont égales pourl’instance (mot − hat) du mot et l’instance (hat) de CatDep associée :hat.debut = dhat.fin = fhat.phon = phEnfin, pour une grammaire, telle que celle présentée dans cette dernière section,un lexique, celui de la figure 5.36, et une phrase comme « Maria einen Mann zuliebenversucht », nous générons une contrainte C représentant l’ensemble des arbres syntaxiqueset topologiques valides pour cette phrase. Suivant le modèle proposé pour hat,les contraintes pour chaque mot, rencontré dans la phrase, sont posées. La contrainteC est la conjonction, d’une part, des contraintes globales définies, notamment pour lesprincipes mais également, les contraintes sur les cardinalités des relations, etc . . .et,d’autre part, des contraintes générées pour chaque instance de CatDep associée à unmot par le lexique.- 100 -

Chapitre 6Une approche du traitementsémantique des textes descriptifsLe cadre général de notre étude est susceptible de permettre la prise en compte detextes dont la sémantique serait assimilable à la construction d’un modèle fini. En effet,cette situation devrait permettre d’intégrer syntaxe et sémantique au sein d’un mêmemodèle objet contraint, afin que la construction d’une analyse produise en même tempsune structure conforme à la grammaire et un modèle du monde décrit. Il doit être notéque dans les cas d’utilisation de ce type d’approche, le modèle objet contraint décrivantla grammaire comme celui décrivant le monde sont tous deux nécessairement connus.La question posée est donc celle de leur articulation.Nous devons prévenir tout de suite le lecteur que nous n’avons pu faire émergerde propriétés générales dans ce cadre, et que la présentation qui suit est ad hoc, etexpérimentale. Les approches classiques de la sémantique demandent de formaliser lecaractère compositionnel de la construction de la formule associée à une phrase, à laquellechaque entrée lexicale ou noeud syntaxique contribue. L’approche strictement formellela plus utilisée reste dans ce cadre le lambda calcul, qui permet d’associer à tout élémentpertinent une expression valide du lambda calcul qui représente un fragment (invalide)du langage logique cible choisi. La composition des constructions syntaxiques guide alorsl’application des expressions du lambda calcul entre elles.Egalement, nous avons restreint le cadre syntaxique choisi à des phrases descriptivestrès simples.6.1 Une sémantique des textes descriptifsNous restreignons le cadre de notre étude à des phrases que nous nommons phrases dedescription. Cette approche est motivée par la demande constante d’aide au développement,afin d’alléger les tâches de programmation souvent fastidieuses. Un bon exemple est l’aideau designer dans le contexte de la modélisation déclarative, voir notamment [43, 44].Une phrase de description est, pour nous, une phrase dont tous les mots sont soit connus,soit traités comme des noms propres et dont la structure syntaxique s’articule autour- 101 -

6 : Une approche du traitement sémantique des textes descriptifsd’un sujet d’un verbe et d’un complément. Une phrase de description suivra le schémade règles décrit sur la figure 6.1. La syntaxe de ces phrases est simple et ne couvrePhrase → SN SVSN → N [propre] | Det N [commun] | Det N [commun] Adj | Det N [commun] SPrep |Det N [commun] Adj SPrepSPrep → Prep SNSV → V SN | V Adv | V AdjFig. 6.1 – Schéma de règles syntaxiques pour les phrases de descriptionqu’une partie très restreinte du langage naturel mais autorise tout de même des decriptionssuffisamment complexes pour définir les problèmes qui nous intéressent. En effet,leur représentation sémantique est typiquement une instanciation d’un modèle objetcontraint. Pour tout domaine où la modélisation déclarative est utilisable, l’ensembled’objets pouvant être décrits appartient à l’ensemble des modèles d’un modèle objetcontraint représentant génériquement le domaine. Le chapitre 7 présente une applicationde ces travaux à la modélisation déclarative de surfaces.L’analyse syntaxique apporte un support à l’analyse sémantique. Nous nous basonssur des phrases de descriptions valides présentées par la définition 9.Définition 9 (Texte descriptif valide) Un texte descriptif est dit valide si son analysesyntaxique fournit un et un seul modèleDéfinition 10 (Sémantique d’un texte descriptif) La sémantique d’un texte descriptifvalide est dite consistante si il existe au moins un modèle satisfaisant les contraintesexprimées par le texte.Les mondes de la syntaxe et de la sémantique sont disjoints et peuvent être traitésindépendamment. Nous disposons par ailleurs d’un modèle objet contraint décrivantla grammaire d’une part, et d’un modèle objet contraint décrivant les représentationsvalides du monde décrit. Pour les relier entre elles, nous proposons d’introduire unmodèle objet contraint intermédiaire, qui crée un pont entre les deux précédents. Lesclasses de ce modèle intermédiare sont appelées des schémas.Intuitivement, les schémas décrivent des fragments de la sémantique véhiculée par leséléments syntaxiques et contraignent le modèle du monde. Ils établissent un lien directentre syntaxe et sémantique.La figure 6.2 représente ces concepts de manière graphique.6.2 Les schémas sémantiquesNous nommons schéma sémantique un modèle objet contraint qui, une fois intégréentre le modèle objet contraint gérant la syntaxe et le modèle objet contraint gérant lasémantique, permettra de faire le lien entre ces deux « mondes »pour une construction- 102 -

6 : Une approche du traitement sémantique des textes descriptifsFig. 6.2 – Concepts de l’analyse sémantique de textes descriptifsdonnée. Nous avons isolé pour l’instant deux constructions récurrentes dans les phrasesde description : les schémas de possession et les schémas d’attributs. Un schéma depossession permet à l’utilisateur de spécifier un lien de composition entre deux élémentsdu monde qu’il décrit ; une phrase type exemple de ce schéma est « Le pc possède deuxdisques durs ». Un schéma d’attributs permet quant à lui d’utiliser la fonction attributdu sujet dans une phrase pour modifier soit une valeur d’attribut, soit une relationentre deux objets ; une phrase type est « La surface est rectangulaire ». Pour utiliser cesschémas, il est nécessaire de disposer d’un lexique où seront décrits les liens entre lesmots et les objets du monde. La figure 6.3 présente un extrait de lexique. Tous les objetsdu modèle objet contraint représentant la sémantique héritent d’une classe racine. Nousallons à présent donner une définition plus formelle d’un schéma sémantique :Définition 11 (Schéma sémantique) Un schéma sémantique (Sc) se définit par ladonnée d’un sextuplet Sc = {comSynt, RSem, moSc, C, L, R} où– comSynt représente le modèle objet contraint traitant la syntaxe– RSem représente la racine du modèle objet sémantique– moSc représente le modèle objet associé au schéma.– C est l’ensemble des contraintes sur moSc– L représente l’ensemble des contraintes liant la syntaxe et le schéma– R représente l’ensemble des contraintes liant les éléments du schéma à RsemLes schémas sont liés aux constructions syntaxiques, aux éléments du monde et auxautres schémas. Ils peuvent être spécialisés grâce à des relations d’héritage, commeillustré sur la figure 6.4.- 103 -

6 : Une approche du traitement sémantique des textes descriptifsMot Catégorie genre nombre personne sémantiqueLe Det masculin singulier 3 indetLe Pro masculin singulier 3 indet...pc N masculin singulier 3 Ordinateur...Fig. 6.3 – Extrait du lexiqueFig. 6.4 – Une partie du diagramme de classes pour ScDet6.2.1 Schéma de possessionDans un premier temps, nous présentons les schémas et contraintes pour des phrasesdu type « sujet + avoir/posséder + complément possédant une cardinalité » telles que :« Le PC a(possède/contient/...) deux disques durs ». Ces phrases sont donc formées denoms, de déterminants et de verbes.Pour traiter les schémas de possession, il faut tout d’abord extraire l’information importante.Pour cela, une hiérarchie de classes représentant les éléments mettant en jeu descardinaux est définie. Ces classes possèdent un attribut de type entier val représentantla valeur portée par le déterminant cardinal.Le schéma ScPoss contraint la cardinalité de la relation entre l’objet représenté parle nom du sujet et ceux représentés par le complément, en fonction de la valeur dudéterminant cardinal. Pour des raisons de modularité de l’implémentation, les associationsentre schémas et catégories peuvent être définies à un niveau d’abstraction 1 . Parexemple, le schéma ScDet présenté sur le figure 6.4 est une classe abstraite pour tousles schémas de déterminants, en relation elle-même avec la classe Det représentant lesdéterminants.Pour rester le plus général possible, les schémas sémantiques ne peuvent pas être1 JConfigurator réalise le typage dynamique durant la recherche et supporte les contraintes de type(contraintes dites de classification).- 104 -

6 : Une approche du traitement sémantique des textes descriptifsFig. 6.5 – Diagramme de classes pour ScPossdirectement liés aux composants du modèle sémantique (PC, CarteMère, etc...), ceciexplique pourquoi les schémas sont liés à la classe WorldObject (notée également WOpar la suite) dont les classes précédemment citées héritent. Ainsi pour parser des phrasesdécrivant des instances d’un autre ”monde” sémantique, il suffit de ”charger” le modèleobjet contraint et le lexique associés à ce monde. La classe WO possède une relationde composition cyclique, possede représentant les relations de composition entretenuespar les différents composants du monde sémantique. Les constructions proposées, si ellesrestent ad hoc et simplistes, restent toutefois réutilisables.Le diagramme de classes pour le schéma de possession est présenté sur la figure 6.5.Ce diagramme est dirigé par la classe ScPoss qui orchestre les liens entre les différentséléments. Une instance de cette classe contiendra un schéma représentant le possesseur(par la relation scPossScSn), et un schéma représentant la partie cardinale de la phrase 2(par la relation scPossScSvCard).Les classes ScPoss, ScSvCard, ScSn, ScN et ScDet sont respectivement en relationavec les éléments Phrase, SV, SN, N et Det de la syntaxe. Lors de la lecture de l’entrée,lorsqu’un déterminant cardinal sera lu, l’instance de Det associée à ce mot sera liée àune instance de ScDetCard dont la valeur de l’attribut val sera affectée grâce au lexique.Les autres éléments devront attendre la recherche de solutions pour être associés. Parexemple, un mot pouvant avoir plusieurs étiquettes ne pourra pas générer de liens avec2 La partie cardinale est constituée du verbe et des éléments possédés- 105 -

6 : Une approche du traitement sémantique des textes descriptifsles schémas avant la recherche. Le seul élément pré-instancié est l’attribut name deScN, celui-ci prend la valeur associée, dans le lexique, au N auquel il pourrait être lié.La même position est prise vis à vis des syntagmes, comme le ScSn qui ne sera caractériséen ScSnIndef ou ScSnCard qu’en fonction des éléments constituant le syntagme nominalauquel il sera lié.Les contraintesDétaillons la manière dont les relations entre les éléments du monde sont décritesavec la relation « générale » possede. Pour définir, dans le monde sémantique, qu’unobjet a de type A est composé de au minimum x et au maximum y objets de type B, ilsuffit de définir la contrainte :∀ a : A • x ≤ #(a.has ∩ {b : B}) ≤ yLes liaisons entre les mots et les objets du monde sont effectuées en fonction desattributs name des ScN et WorldObject :∀ sc : ScN • sc.scNWo.name = sc.name∀ sc : scSvCard •∀ wo : WO | wo ∈ sc.scSvCardScSnCard.scSnCardWo •wo.name = sc.scSvCardScSnCard.scSnScN .scNWo.nameEnfin, nous pouvons définir la contrainte qui permet de lier les éléments syntaxiqueset les « objets du monde ».∀ s : ScPoss •#((s.scPossScSnIndef .scSnScN .scNWo.possede)∩(s.scPossScSvCard.scSvCardScSnCard.scSnScN .scNWo))= s.valRésultats expérimentauxNous avons implémenté un programme de configuration à partir des spécificationsprécédentes et en utilisant l’outil de programmation par contraintes JConfigurator.Nous présentons les résultats expérimentaux obtenus en utilisant ce programme deconfiguration pour analyser des phrases dans le domaine sémantique du PC. Les résultatsprésentés correspondent aux trois phrases :(1) Le PC a deux disques durs.(2) La carte mère possède un processeur.(3) La carte mère a trois barettes de mémoire.Le résultat de la lecture de ces trois phrases à la suite est présenté sur la figure 6.6,où les éléments sur fond blanc représentent les objets introduits dans la solution aprèslecture de la phrase (1), les rectangles Ram 2 et Ram 3 sont adjoints au modèle après- 106 -

6 : Une approche du traitement sémantique des textes descriptifsFig. 6.6 – Le monde construit lors de l’analyselecture de la phrase (3). Les autres objets sont introduits implicitement pour satisfaireles contraintes de cardinalité. Les objets du domaine introduits par une phrase sontréutilisés autant que possible dans la suite du traitement du texte. Par exemple, la cartemère, nécessaire implicitement pour ”comprendre” la phrase (1) est la même que celleà qui réfèrent les phrases (2) et (3).phrase échecs points de choix temps(1) 2 7 0,81 s(2) 1 5 0,84 s(3) 1 5 0,81 s(1) + (2) 2 21 1,02 s(1) + (2) + (3) 1946 1979 3,19 sTab. 6.1 – Résultats expérimentauxLe tableau 6.1 liste les statistiques d’éxécution obtenues 3 lors de la résolution duproblème pour des phrases isolées ou en tant que texte. La première colonne décrit queltype de test est effectué tandis que les deuxième et troisième colonnes listent respectivementle nombre d’échecs et le nombre de points de choix. La dernière colonne présenteles temps d’éxécution en seconde. Le temps d’éxécution est lié d’une part à la taille duproblème de configuration et d’autre part, bien sûr, au nombre de points de choix. IlogJconfigurator n’implémente pas la ”création d’objets à la demande”. Cette limitationforce le programme à pré-créer autant d’instances de chaque classe abstraite qu’il pourraiten avoir besoin au cours de la recherche (le typage dynamique est réalisé lors de la3 Ordinateur : P4 2.4GHz, 512 Mo RAM, Windows XP SP2, Ilog JConfigurator 2.1- 107 -

6 : Une approche du traitement sémantique des textes descriptifsrecherche). L’absence de contrainte brisant les symétries est une cause parmi d’autresdu nombre important de points de choix. Dans le cas de la lecture de phrases enchaînées,le nombre important de points de choix est au fait que les résultats ne sont pas figésde l’analyse d’une phrase à l’analyse de la suivante et que ces travaux n’utilisent pasd’heuristiques de recherche. Ce dernier point soulève une remarque importante, cellede savoir si il est utile ou non de figer ces phrases. Notamment pour les dépendancesentre des éléments de phrases différentes (dépendances non bornées). Dans le cadre del’étude nous nous sommes affranchis de ces dépendances et supposons qu’elles n’ont paslieu d’être dans une description qui doit être la plus précise possible. A ce titre, elle nedoit pas utiliser de référents dépassant le cadre de la phrase courante. Enfin, soulignerque ces travaux n’utilisent pas d’heuristiques de recherche, implique que le programmeeffectue ici ce qu’il doit calculer par défaut.6.2.2 Schéma d’attributsLa définition des compositions entre éléments est une étape clé dans le traitement desphrases descriptives. Nous venons de voir que ce point était envisageable par l’utilisationdes schémas de composition. Cependant, caractériser un objet, c’est aussi décrire sesattributs et utiliser pour ce faire les constructions du type « sujet verbe [être] Adj ».Nous présentons dans cette section les schémas permettant de traiter certaines de cesdescriptions, nous les nommons les schémas d’attributs [21].Dans le cadre de cette étude, nous supposons que les domaines des attributs sonténumérables et sont exprimés sous forme de classes. Cette approche est motivée par le faitque tout modèle objet sous la représentation UML est une instance d’un méta-modèleoù les attributs des classes sont représentés par des classes. Le noyau d’uml nomméUML Core est présenté dans [35]. Un sous-modèle objet du UML-Core présentant lesdéfinitions des classes et des attributs est proposé en annexe sur la figure C.1Dans un premier temps, nous proposons l’introduction d’un nouveau sous-modèleobjet contraint le lexiconSelector pour lier les données du lexique.Le lesxiconSelectorLe lexiconSelector permet de faire le lien entre les éléments du modèle syntaxique etceux du modèle sémantique. Il n’a pas été présenté dans la section précédente pour lesschémas de possession car leur fonctionnement est compréhensible sans ce dernier. Unattribut (syntaxiquement parlant) peut se rapporter soit à une instance de classes, soità un attribut d’une instance de classe. La figure 6.8 décrit le modèle de classes associéau lexiconSelector.- 108 -

6 : Une approche du traitement sémantique des textes descriptifsFig. 6.8 – Modèle objet pour le lexiconSelectorLe lexique est fortement sollicité pour créer ces liens. Nous ajoutons au lexique unetable de paramètres pour chaque mot. Cette table est nommée table de liaisons lexiquesémantique.Cet ensemble regroupe les liens sémantiques entretenus avec le modèle dumonde. Une ligne de cette table contient les éléments suivants :mot [C , I , A] NomClasse/[NomAtt/valAtt, −] [nomInst]La première valeur est l’entrée lexicale (pc par exemple), la deuxième une lettre spécifiantde quelle nature est l’objet sémantique à associer : une classe (C), un attribut (A) ouune instance de classe (I), la troisième valeur va spécifier, pour chaque élément, la classedu modèle objet dont il est question, puis, éventuellement, le nom d’attribut et la valeurd’attribut associée. Si ces informations ne sont pas requises, elles sont remplacées parun tiret « - ». La quatrième valeur n’est présente que lorsqu’il s’agit d’un attribut d’uneinstance. Elle représente le nom associé à l’instance dans le modèle sémantique. La tablede liaison lexique-sémantique peut nécessiter des mises à jour au cours de l’analyse. Eneffet, les instances de classes ne sont pas définies à priori et tout nouvel élément doitêtre spécifié dans la table.Nous allons décrire à présent le sous modèle objet contraint correspondant auxschémas d’attributs. Nous nous limitons aux attributs du sujet de type adjectif. Cemodèle est présenté sur la figure 6.9.- 109 -

6 : Une approche du traitement sémantique des textes descriptifsFig. 6.9 – Modèle objet pour le schéma d’attributLes contraintes sont basées sur les relations entretenues par les instances de LexiconSelector.Nous avons isolé deux cas possibles : soit l’attribut porte sur un attributde classes, soit sur une instance de classes.Si le complément du verbe est associé à un attribut d’une classe, alors les instances dela classe WorldObject liées à l’attributeSelector et à l’instanceSelector sont les mêmes.C’est l’attribut de l’instance représentée par le sujet qui est caractérisé.∀ s : ScAtt •s.scAttScVAtt.scVAttScAdjAtt.scAdjAttLexSel ∩ AttributeSelector ≠ ⇒s.scAttScVAtt.scVAttScAdjAtt.scAdjAttLexSel.aSWo =s.scAttScSn.scSnScN .lSWoPour tout ScAtt, les valeurs des attributs index du WO associé à l’attributeSelectoret celle du WO associé à l’instanceSelector sont égales.∀ s : scAtt • s.scAttScSN .scSnScN .scNLexSel.lSWo.index =s.scAttScVAtt.scVAttscAdjAtt.scAdjAttLexSel.lSWo.indexSi le complément du verbe est associé à une instance de classe, alors les valeurs desattributs name du ScN et name du WO lié à l’InstanceSelector sont identiques. Cette- 110 -

6 : Une approche du traitement sémantique des textes descriptifsphrase provoque la création d’une instance 4 .∀ s : ScAtt •s.scAttScVAtt.scVAttScAdjAtt.scAdjAttLexSel ∩ InstanceSelector ≠ ⇒s.scAttscSn.scSnScN .scnName =s.scAtt.scAttLexSel.lSWo.woNameAssocier à chaque élément syntaxique une « sémantique » devrait permettre deprendre en compte des constructions plus complexes et aux schémas de partager del’information.Nous terminons ici la présentation de l’approche du traitement de la sémantique desdescriptions par les grammaires de configuration. De nombreux autres schémas restentà être identifiés et définis. Notamment une gestion plus fine de la syntaxe apportera denombreuses autres problématiques quant à la question du traitement de la sémantique.L’idée générale étant de rendre compte des liens entre des mots et des fonctions au seind’une phrase d’une part et les objets décrits d’autre part pour arriver à un produitfini ayant une sémantique propre dans le domaine modélisé. Nous en fournissons unmodèle consistant, lorsqu’il existe, satisfaisant les contraintes de bonne formation descomposants du monde.Ces techniques ont été implémentées pour le traitement des descriptions dans le cadrede la modélisation déclarative de surface. Le chapitre suivant présente cette approche etainsi que des exemples d’utilisation.4 JConfigurator n’acceptant pas la génération d’instance à la « volée »lors de l’analyse, il est nécessairede créer un pool d’instances suffisant au départ de la recherche et cette phase de création nécessaire parl’inexistence d’une classe portant ce nom est remplacée par un lien entre deux objets existants le motet l’instance spécifiée via le schéma d’attribut- 111 -

6 : Une approche du traitement sémantique des textes descriptifsFig. 6.7 – Instance solution du modèle syntaxico-sémantique pour la phrase « Le pcpossède deux disques durs ».- 112 -

Chapitre 7Une application : la modélisationdéclarative de surfaceCette application repose sur des travaux menés au sein du laboratoire LSIS entre leséquipes InCA et LXAO, dans le cadre du pôle modélisation géométrique. Elle a donnélieu à une publication à la conférence 3IA’06[27].Elle concerne la modélisation de surfaces NURBS 1 . Ces surfaces sont les plus utiliséesdans le domaine de la Conception Assistée par Ordinateur. Cependant, bien quela modélisation soit de bonne qualité, le processus de modélisation implique pour ledesigner de nombreux mouvements de points de contrôles qui brident sa créativité. Lessurfaces NURBS sont en effet contrôlées par un plan paramétrique dont chaque point2D correspond à exactement un point 3D de la surface modélisée. La figure 7.1 2 présenteun plan paramétrique et une possible surface NURBS correspondante. La modélisationPolyèdre de controlePoint de controlev100v 0u 0S(u 0, v 0)00u100Surface NURBSFig. 7.1 – Un plan paramétrique et une surface NURBS correspondantedéclarative est un outil qui va permettre au designer de se libérer de ces contraintes techniqueset pouvoir laisser libre cours à ses qualités créatives. Le processus de modélisationdéclarative se présente comme suit : après la description de la surface et un processusde résolution de cette description, une ou plusieurs surfaces sont proposées à l’utilisateurqui peut reprendre sa description jusqu’à obtenir la surface désirée. La descriptionest transmise au modeleur déclaratif par un module de traduction sémantique. C’est sur1 Non Uniform Rational B-Spline2 Les figures 7.1 et 7.6 nous ont été fournies par Raphaël La Greca- 113 -

7 : Une application : la modélisation déclarative de surfacecette partie que repose le travail de l’analyse syntaxico-sémantique. Cette partie est ellemêmeconstituée de trois sous-parties : le modèle syntaxique, le modèle sémantique et lemodèle des ponts syntaxico-sémantiques (ou schémas). Une instance valide du modèlesémantique sera utilisée par le modeleur pour représenter la surface. Le processus généralde modélisation déclarative est présenté sur la figure 7.2.IdéeTraductionsémantiqueDescriptionGénérateurComplétionModification dela descriptionPlanificationInstantiationdes solutionsPrésentation dessolutionsFig. 7.2 – Processus général de modélisation déclarative de surfaceLe modèle syntaxique et la grammaire utilisée sont ceux présentés en section 5.4.2 ; lesschémas utilisés dans cette partie sont les schémas d’attributs présentés dans le chapitreprécédent (chapitre 6). Présentons alors le modèle sémantique utilisé pour représenterles surfaces.7.1 Modèle sémantiqueLe modèle sémantique constitue le monde sur lequel l’utilisateur pourra faire desdescriptions. Ce monde est représenté par un modèle objet présenté sur la figure 7.3.Sur cette figure, nous pouvons lire les informations suivantes :– une surface est associée à exactement une zone– une zone peut contenir plusieurs zones mais ne peut être contenue qu’au maximumdans une seule– toute zone possède une forme, une position et une déformationLes relations entre les éléments sont spécifiées sur le modèle. Cependant, pour l’utilisationdes schémas, il est nécessaire de factoriser ces relations sous la relation cycliquepossede de la classe WO, classe mère de toutes les classes.Certaines instances sont connues avant même de lancer la résolution :- 114 -

7 : Une application : la modélisation déclarative de surfaceFig. 7.3 – Modèle sémantique représentant le « monde » des surfaces– il existe une seule instance de Surface pour un problème donné :surf : Surface– à cette surface est associée une Zone d’index 0 :Z 0 : Zone((surf .possede) ∩ Zone) = Z 0Z 0.index = 0– à Z0 est associée une forme F0 dont la valeur de l’attribut index est 0 mais dontnous ne connaissons pas la classification :F 0 : Forme((Z 0.possede) ∩ Forme) = F 0F 0.index = 0– à Z0 est associée une position P0 dont la valeur de l’attribut index est 0 mais dontnous ne connaissons pas la classification :- 115 -

7 : Une application : la modélisation déclarative de surfaceP0 : Position((Z 0.possede) ∩ Position) = POP0.index = 0– à Z0 est associée une déformation D0 dont la valeur de l’attribut index est 0 maisdont nous ne connaissons pas la classification :D0 : Deformation((Z 0.possede) ∩ Deformation) = DOD0.index = 0Les contraintes génériques sont les suivantes :– toute zone est contenue dans une autre, sauf celle qui est associée à la surface∀ z : Zone | z ≠ (surf .associeeA) • #(z.dans) = 1∀ z : Zone | z = (surf .associeeA) • #(z.dans) = 0– une zone ne peut être positionnée par rapport à elle même :∀ z : Zone • z ≠ z.est.de7.2 Implémentation et résultatsDes tests sur le modèle objet contraint de la sémantique seul, fournissent les résultatsattendus. Cependant lors des tests d’implantation de l’analyse syntaxico-sémantique, desproblèmes de mémoires ont limités les expérimentations. Les résultats présentés ci-aprèssont issus de tests réalisés à partir de phrases étiquetées syntaxiquement.Les phrases descriptives utilisées sont les suivantes :1. Z0 est rectangulaire2. Z1 est une zone3. Z1 est à droite de Z04. Z1 est bombéeUn extrait du lexique est présenté sur la figure 7.4. La table de liaison lexique-sémantiqueest présentée sur la figure 7.5. La figure 7.7 représente la solution associée à l’instance deproblème avec la phrase « La surface est rectangulaire ». Sur cette figure, les instancesde mots ne sont pas spécifiées car l’analyse syntaxique est fournie comme entrée duprogramme. La figure 7.6 représente une surface solution possible pour cet ensembled’entrées.- 116 -

7 : Une application : la modélisation déclarative de surfaceMot Catégorie genre nombre personne sémantique...est V ETRE indet singulier 3 V ETRE...rectangulaire Adj indet singulier 3 Rectangle...Fig. 7.4 – Extrait du lexiqueMot C/I/A NomClasse/NomAtt/valAtt nomInst indexInstZ0 I Zone Z0 0rectangulaire A Zone/Forme/Rectangle - -zone C Zone - -bombée C Bombee - -Fig. 7.5 – Extrait de la table de liaison lexique-sémantiqueFig. 7.6 – Une surface solution pour la description étudiée- 117 -

7 : Une application : la modélisation déclarative de surfaceFig. 7.7 – Solution pour le problème de modélisation déclarative de surfaces avec laphrase « La surface est rectangulaire »- 118 -

Chapitre 8ConclusionLa description des modèles objet contraints en utilisant la notation Z permet unereprésentation formelle et indépendante de tout outil. Elle présente l’avantage de permettrel’utilisation de méthodes de validations formelles, de vérifications des types (typechecking)pour assurer une cohérence de la modélisation. L’équivalence entre les modèlesobjet contraints représentés en Z et les problèmes de configuration assure la correctionet la complétude des modèles fournis par l’outil.L’utilisation du paradigme des modèles objet contraints pour traiter les langagesde description s’avère intéressante bien que limitée en implémentation par l’outil derésolution qui ne nous permet pas, pour l’heure, de fournir des résultats comparables àceux fournis par d’autres analyseurs syntaxiques.Les deux apports du travail présenté dans cette thèse sont : (1) un cadre formelde traitement des problèmes et (2) la création d’un modèle abstrait de grammairespermettant la résolution par recherche de modèles finis. La représentation objet d’unmonde donné semble naturelle par la nature même de ce paradigme, conçu pour favoriserles intéractions entres les objets. D’un point de vue sémantique, il est clair que le sensdes descriptions est bien représenté par une instance du modèle objet contraint dumonde. Une première étape importante était de valider le traitement de la syntaxe parla configuration.Le terme grammaire de configuration possède un double sens :– d’une part, les grammaires de configuration définissent un cadre de résolution, surla base de la recherche de modèles finis, pour l’analyse syntaxico-sémantique– d’autre part, un problème de configuration peut lui aussi être décrit en utilisantles grammaires de configuration avec, comme monde, un modèle génériquereprésentant tout modèle objet contraint.Le type de modélisation choisi et l’utilisation de la recherche de modèles finis inscriventdirectement cette approche dans le domaine des MTS. La modularité des traductionsde grammaires permet une adaptation des problèmes, grâce à la grammaire,aux différents types de corpus étudiés.- 119 -

8 : ConclusionPerspectivesTout d’abord, il est à noter que les problèmes de configuration, par nature, disposent,le plus souvent, de sous-arbres de recherche isomorphes. L’utilisation de cettereprésentation permettra l’utilisation de techniques de filtrages telles que celles présentéesdans [38, 37], au moins au niveau du domaine de la sémantique mais très certainementaussi au niveau des schémas.Sylvain Kahane dans [42] rappelle une équivalence formelle entre les arbres de dépendanceset les structures syntagmatiques avec tête. De plus, Denys Duchier, dans [19, 18],analyse la bonne formation d’un arbre de dépendance par un problème de configurationfini et le traite par un CSP. Une piste de recherche est ainsi d’analyser de quelle manièrele traitement des grammaires de dépendance est effectivement un simple problème de satisfactionde contraintes ou si la recherche de modèles finis peut permettre une plus largecouverture des phénomènes linguistiques. Ceci soulève un autre point, qui est d’étudierles phénomènes linguistiques et non plus, simplement, les structures des grammaires.Comme le fait remarquer [62], une phrase agrammaticale peut être tout de mêmeacceptée et « comprise ». Pour ce faire, l’auteur introduit les notions de densité desatisfaction locale et de densité de satisfaction propagée, qui représentent, en pourcentagepour chaque catégorie, les quantités de contraintes (propriétés) insatisfaites (violées)par rapport à ses propres contraintes (satisfaction locale) et en faisant remonter lesdensités de satisfactions locales de ses composants (satisfaction propagée). Il suffit alorsde fixer un seuil à partir duquel les phrases sont trop agrammaticales pour être acceptées.Cette approche nous semble tout à fait adéquate au domaine étudié. Les souhaits del’utilisateur, ensemble de contraintes lâches, se rapprochent de ce concept. L’applicationdes méthodes de choix des « bons » souhaits comme celles proposées par [39, 40] doiventpermettre d’intégrer ces taux d’agrammaticalité.Le traitement de la sémantique que nous avons proposé s’appuie sur un « monde »sémantique entièrement défini. L’utilisation d’un méta-modèle décrivant la partie sémantiquede manière abstraite permet une définition totalement abstraite des relationsentre les composants. Ainsi, la reconnaissance d’un schéma de composition et l’identificationdes classes mises en jeu dans le schéma fournissent les informations nécessairesà la création de la relation. D’autre part, la définition d’un méta-modèle, tel que celuiprésenté dans l’annexe C, peut permettre la création complète du monde sémantique.- 120 -

Annexe AExemple de programme ILOGJConfiguratorNous présentons dans cette section le détail de l’implémentation du problème del’assemblage d’ordinateurs avec JConfigurator. Le modèle objet générique utilisé parJConfigurator n’est pas un modèle UML standard, bien qu’il s’en approche fortement.La figure A.1 présente le modèle objet de JConfigurator correspondant à celui de lafigure 4.3, que nous rappelons sur la figure A.2.Dans ce modèle, nous pouvons remarquer qu’un seul type de relations est présent etque ces relations sont orientées. Seuls les rôles sont exprimables sur cette modélisation.Cependant ce modèle représente exactement celui utilisant la notation UML, avec lesspécifications suivantes :– pour toute relation où les deux rôles sont spécifiés, il est nécessaire de spécifier queces deux rôles sont inverses l’un de l’autre.– pour une relation d’association, les deux rôles sont représentés avec leurs cardinalitésrespectives.– pour une relation de composition, les deux rôles sont représentés avec leurs cardinalitésrespectives et il faut en plus préciser la sémantique de cette relation.Celle-ci est représentée par une option signifiant que le rôle de la classe cible de larelation de composition vers la classe source est exclusif. Etre exclusif signifie quedeux instances différentes de la source ne peuvent pas partager une même instancede la cible.Les options inverse et exclusif sont spécifiées via des boîtes de dialogues comme présentésur la figure A.3. Les contraintes sont explicitées dans un fichier annexe et sont présentéesci-dessous. Elle représentent exactement les contraintes définies dans la section de présentationdes modèles objet contraints (chapitre 4).A.1 Contraintes génériquesSe basant sur le modèle objet de la figure A.1 pour pouvoir définir des contraintes surles éléments de ce modèle, il faut tout d’abord définir des variables qui vont représenter- 121 -

A : Exemple de programme ILOG JConfiguratorFig. A.1 – Modèle (JConfigurator) générique de données pour représenter un PCles instances de classes du modèle.La déclaration d’une telle variable suit la syntaxe suivante :IloLogicObjectVar nomVar = om.logicObjectVar(VarClasse);où nomVar représente le nom de la variable en train d’être définie, VarClasse un objetreprésentant une classe du modèle.VarClasse est un objet de type IloCLass qui est obtenu par la méthode getClass(String)de la classe IloConfigurationModel. Dans la suite de cette annexe, om représentera uneinstance de la classe IloConfigurationModel. VarClasse peut être défini également dela manière suivante :IloClass nomDeClasse = om.getClass("Ordinateur");IloClass classOrdinateur = om.getClass("Ordinateur");IloLogicObjectVar varOrdinateur = om.logicObjectVar(classOrdinateur);IloClass classCarteMere = om.getClass("CarteMere");IloLogicObjectVar varCarteMere = om.logicObjectVar(classCarteMere);- 122 -

A : Exemple de programme ILOG JConfiguratorFig. A.2 – Modèle (UML) de données générique pour représenter un PCIloClass classRam = om.getClass("Ram");IloLogicObjectVar varRam = om.logicObjectVar(classRam);IloClass classProcesseur = om.getClass("Processeur");IloLogicObjectVar varProcesseur = om.logicObjectVar(classProcesseur);IloLogicObjectVar varProcesseur2 = om.logicObjectVar(classProcesseur);IloClass classDD = om.getClass("DisqueDur");IloLogicObjectVar varDD = om.logicObjectVar(classDD);A présent que nous disposons des variables nécessaires, nous allons pouvoir transcrireles contraintes présentées en Z dans le chapitre 4.Pour tout ordinateur, son prix total est égal à la somme des prix de ses différentscomposants :om.add(om.forAll(varOrdinateur,om.eq(varOrdinateur.getIntField("prixTotal"),om.sum(varOrdinateur.getObjectField("ecran").getIntField("prix"),om.sum(varOrdinateur.getObjectSetField("disqueDur"),"prix"),varOrdinateur.getObjectField("carteMere").getIntField("prixTotal"),varOrdinateur.getObjectField("alimentation").getIntField("prix"))));Les différents opérateurs sont expliqués ci-dessous :- 123 -

A : Exemple de programme ILOG JConfiguratorFig. A.3 – Boîte de dialogue permettant de spécifier les propriétés d’une relation– add déclare au configurateur l’ajout d’une contrainte.– forAll est l’opérateur ∀ de la logique classique ; il permet de définir une contraintepour toutes les valeurs de la variable.– eq est l’opérateur d’égalité entre les deux valeurs passées en paramètre.– getIntField récupère la valeur d’un champ de type entier.– getObjectField accède à une instance de la classe liée par la relation de cardinalitéinférieure ou égale à 1 passée en paramètre.– getObjectSetField renvoie l’ensemble des objets liés à l’instance courante par larelation ensembliste passée en paramètre– sum(rel,att) retourne la somme des valeurs de l’attribut att sur toutes les instancesprésentes dans la relation ensembliste rel.Pour toute carte mère, son prix total est égal à la somme des prix de ses composants :om.add(om.forAll(varCarteMere,om.eq(varCarteMere.getIntField("prixTotal"),om.sum(om.sum(varCarteMere.getObjectSetField("processeur"),"prix"),om.sum(varCarteMere.getObjectSetField("ram"),"prix"),varCarteMere.getIntField("prix")))));Les barrettes de mémoires connectées à la carte mère doivent être du bon type :om.add(om.forAll(varCarteMere,om.eq(om.cardOf(- 124 -

A : Exemple de programme ILOG JConfiguratorvarRam,varCarteMere.getObjectSetField("ram"),om.eq(varRam.getAnyField("type"),varCarteMere.getAnyField("typeRam"))),varCarteMere.getCardinality("ram"))));L’opérateur cardOf est utilisé ici : Il permet de retourner le nombre d’éléments dans unensemble qui satisfait une contrainte donnée :cardOf(var,ens,ct) où var est la variable représentant un élément de l’ensembleens et ct est la contrainte.Cet opérateur est utilisé ici pour permettre de spécifier que toute barrette de ramprésente dans la relation ram entre les classes CarteMere et Ram doit satisfaire la contrainte.Il n’existe pas en JConfigurator de contrainte ”pour tout x dans un certain ensemble” ;elle doit être traduite de la manière précédente.Si la carte mère possède deux processeurs, ces derniers doivent être du même type :om.add(om.forAll(varCarteMere,varProcesseur,varProcesseur2,om.and(om.member(varProcesseur,varCarteMere.getObjectSetField("processeur")),om.member(varProcesseur2,varCarteMere.getObjectSetField("processeur"))),om.and(om.eq(varProcesseur.getIntField("energieConsommee"),varProcesseur2.getIntField("energieConsommee")),om.eq(varProcesseur.getIntField("vitesse"),varProcesseur2.getIntField("vitesse")))));Chacun des deux processeurs doit consommer la même énergie et avoir la mêmevitesse. Les opérateurs utilisés ici sont :– forAll(var,ct1,ct2) ici ct1 est une contrainte conditionnant la contrainte ct2.C’est une implication logique entre ct1 et ct2 : forAll(var, ct1 ⇒ ct2).– and opérateur binaire réalisant le ET logique entre les contraintes passées en paramètre.and retourne vrai si et seulement si les deux contraintes sont satisfaites.– member retourne vrai si le premier paramètre appartient à l’ensemble passé endeuxième paramètrePour tout ordinateur, tout disque dur connecté doit avoir le bon type :om.add(om.forAll(varOrdinateur,om.eq(- 125 -

A : Exemple de programme ILOG JConfiguratorom.cardOf(varDD,varOrdinateur.getObjectSetField("disqueDur"),om.eq(varDD.getAnyField("type"),varOrdinateur.getAnyField("typeDD"))),varOrdinateur.getCardinality("disqueDur"))));La puissance fournie par l’alimentation de l’ordinateur doit être supérieure à lasomme de l’énergie concommée par chacun des composants :om.add(om.forAll(varOrdinateur,om.ge(pc.getObjectField("alimentation").getIntField("puissanceFournie"),om.sum(pc.getObjectField("ecran").getIntField("energieConsommee"),pc.getObjectField("carteMere").getIntField("energieConsommee"),om.sum(pc.getObjectSetField("disqueDur"),"energieConsommee")))));L’opérateur ge représente l’opérateur de comparaison ≥ entre deux valeurs.La valeur de l’attribut energieConcommeeTotale de la carte mère est égale à la sommede l’énergie consommée par la carte mère et de celles consommées par les éléments quilui sont liés :om.add(om.forAll(varCarteMere,om.eq(varCarteMere.getIntField("energieConsommeeTotale"),om.sum(varCarteMere.getIntField("energieConsommee"),om.sum(varCarteMere.getObjectSetField("processeur"),"energieConsommee"),om.sum(varCarteMere.getObjectSetField("ram"),"energieConsommee")))));L’ensemble de ces contraintes assure la bonne formation des ordinateurs configurés.Dans la section suivante nous allons présenter les résultats que l’on obtient selon lenombre de contraintes spécifiques que l’utilisateur choisit. Nous verrons notamment quele nombre d’ordinateurs, potentiellement grand même avec très peu d’instances, se voittrès rapidement réduit dès lors que les requêtes de l’utilisateur sont précises.A.2 RésultatsPour pouvoir tester ce modèle, il faut générer des instances. Différentes méthodesde création d’instances sont à notre disposition, notamment, il est possible de générer- 126 -

A : Exemple de programme ILOG JConfiguratorsoit des instances nommées, soit des instances anonymes. Il est également possible dene considérer que des instances choisies dans un catalogue. Ce dernier choix s’avère trèsbien adapté à notre exemple. Cependant, pour des raisons de clarté nous utiliserons desinstances nommées. Ainsi, nous définissons :– une instance d’Ordinateur qui sera l’ordinateur à configurerIloObject pc = om.makeInstance("Ordinateur","pc");Toutes les instances se déclarent de cette manière :IloObject nomObjet = om.makeInstance("nomClasse","nomInstance");où IloObject est le type représentant les objets, nomObjet est le nom associéà cette instance dans la définition des contraintes, om.makeInstance est uneméthode de la classe IloConfigurationModel qui permet de créer des instancesde classes. Cette méthode attend comme entrée le nom de la classe (nomClasse)ainsi que le nom de l’instance pour l’affichage (nomInstance).– cinq instances de DisqueDur :IloObject dd1 = om.makeInstance("DisqueDur","dd1");om.add(om.eq(dd1.getIntField("capacite"),80));om.add(om.eq(dd1.getAnyField("type"),"IDE"));om.add(om.eq(dd1.getIntField("prix"),40));om.add(om.eq(dd1.getIntField("energieConsommee"),15));IloObject dd2 = om.makeInstance("DisqueDur","dd2");om.add(om.eq(dd2.getIntField("capacite"),120));om.add(om.eq(dd2.getAnyField("type"),"IDE"));om.add(om.eq(dd2.getIntField("prix"),50));om.add(om.eq(dd2.getIntField("energieConsommee"),20));IloObject dd3 = om.makeInstance("DisqueDur","dd3");om.add(om.eq(dd3.getIntField("capacite"),250));om.add(om.eq(dd3.getAnyField("type"),"IDE"));om.add(om.eq(dd3.getIntField("prix"),75));om.add(om.eq(dd3.getIntField("energieConsommee"),25));IloObject dd4 = om.makeInstance("DisqueDur","dd4");om.add(om.eq(dd4.getIntField("capacite"),80));om.add(om.eq(dd4.getAnyField("type"),"SATA"));om.add(om.eq(dd4.getIntField("prix"),70));om.add(om.eq(dd4.getIntField("energieConsommee"),30));IloObject dd5 = om.makeInstance("DisqueDur","dd5");om.add(om.eq(dd5.getIntField("capacite"),160));om.add(om.eq(dd5.getAnyField("type"),"SATA"));om.add(om.eq(dd5.getIntField("prix"),95));om.add(om.eq(dd5.getIntField("energieConsommee"),35));- 127 -

A : Exemple de programme ILOG JConfiguratorNous remarquons ici que les déclarations des instances sont suivies par une sériede lignes non présentes dans la définition de l’instance de l’ordinateur. Ces lignesreprésentent des contraintes, spécifiant les attributs des objets créés. On remarquenotamment que tous les opérateurs sont infixes dans la syntaxe de JConfigurator.Chacune des instances possède ses propres valeurs d’attributs. Ce genre depropriétés serait facilement traitable par un catalogue spécifiant, pour chaque instance,la liste de ses valeurs d’attributs.– trois instances d’Ecran :IloObject e1 = om.makeInstance("Ecran","e1");om.add(om.eq(e1.getIntField("taille"),17));om.add(om.eq(e1.getIntField("prix"),150));om.add(om.eq(e1.getIntField("energieConsommee"),25));IloObject e2 = om.makeInstance("Ecran","e2");om.add(om.eq(e2.getIntField("taille"),17));om.add(om.eq(e2.getIntField("prix"),250));om.add(om.eq(e2.getIntField("energieConsommee"),27));IloObject e3 = om.makeInstance("Ecran","e3");om.add(om.eq(e3.getIntField("taille"),19));om.add(om.eq(e3.getIntField("prix"),320));om.add(om.eq(e3.getIntField("energieConsommee"),35));– cinq instances de Processeur :IloObject p1 = om.makeInstance("Processeur","p1");om.add(om.eq(p1.getIntField("vitesse"),1500));om.add(om.eq(p1.getIntField("prix"),115));om.add(om.eq(p1.getIntField("energieConsommee"),30));IloObject p2 = om.makeInstance("Processeur","p2");om.add(om.eq(p2.getIntField("vitesse"),2000));om.add(om.eq(p2.getIntField("prix"),150));om.add(om.eq(p2.getIntField("energieConsommee"),35));IloObject p3 = om.makeInstance("Processeur","p3");om.add(om.eq(p3.getIntField("vitesse"),2500));om.add(om.eq(p3.getIntField("prix"),230));om.add(om.eq(p3.getIntField("energieConsommee"),45));IloObject p4 = om.makeInstance("Processeur","p4");om.add(om.eq(p4.getIntField("vitesse"),3200));- 128 -

A : Exemple de programme ILOG JConfiguratorom.add(om.eq(p4.getIntField("prix"),345));om.add(om.eq(p4.getIntField("energieConsommee"),60));IloObject p5 = om.makeInstance("Processeur","p5");om.add(om.eq(p5.getIntField("vitesse"),1500));om.add(om.eq(p5.getIntField("prix"),115));om.add(om.eq(p5.getIntField("energieConsommee"),30));– trois instances de CarteMereIloObject cm1 = om.makeInstance("CarteMere","cm1");om.add(om.eq(cm1.getAnyField("typeRam"),"SDR"));om.add(om.eq(cm1.getIntField("prix"),115));om.add(om.eq(cm1.getIntField("energieConsommee"),40));IloObject cm2 = om.makeInstance("CarteMere","cm2");om.add(om.eq(cm2.getAnyField("typeRam"),"SDR"));om.add(om.eq(cm2.getIntField("prix"),190));om.add(om.eq(cm2.getIntField("energieConsommee"),45));IloObject cm3 = om.makeInstance("CarteMere","cm3");om.add(om.eq(cm3.getAnyField("typeRam"),"DDR"));om.add(om.eq(cm3.getIntField("prix"),245));om.add(om.eq(cm3.getIntField("energieConsommee"),50));– six instances de RamIloObject r1 = om.makeInstance("Ram","r1");om.add(om.eq(r1.getIntField("capacite"),256));om.add(om.eq(r1.getAnyField("type"),"SDR"));om.add(om.eq(r1.getIntField("prix"),40));om.add(om.eq(r1.getIntField("energieConsommee"),25));IloObject r2 = om.makeInstance("Ram","r2");om.add(om.eq(r2.getIntField("capacite"),512));om.add(om.eq(r2.getAnyField("type"),"SDR"));om.add(om.eq(r2.getIntField("prix"),70));om.add(om.eq(r2.getIntField("energieConsommee"),30));IloObject r3 = om.makeInstance("Ram","r3");om.add(om.eq(r3.getIntField("capacite"),512));om.add(om.eq(r3.getAnyField("type"),"DDR"));om.add(om.eq(r3.getIntField("prix"),75));om.add(om.eq(r3.getIntField("energieConsommee"),35));IloObject r4 = om.makeInstance("Ram","r4");- 129 -

A : Exemple de programme ILOG JConfiguratorom.add(om.eq(r4.getIntField("capacite"),1024));om.add(om.eq(r4.getAnyField("type"),"DDR"));om.add(om.eq(r4.getIntField("prix"),95));om.add(om.eq(r4.getIntField("energieConsommee"),37));IloObject r5 = om.makeInstance("Ram","r5");om.add(om.eq(r5.getIntField("capacite"),1024));om.add(om.eq(r5.getAnyField("type"),"SDR"));om.add(om.eq(r5.getIntField("prix"),85));om.add(om.eq(r5.getIntField("energieConsommee"),33));IloObject r6 = om.makeInstance("Ram","r6");om.add(om.eq(r6.getIntField("capacite"),256));om.add(om.eq(r6.getAnyField("type"),"DDR"));om.add(om.eq(r6.getIntField("prix"),80));om.add(om.eq(r6.getIntField("energieConsommee"),28));– trois instances d’AlimentationIloObject a1 = om.makeInstance("Alimentation","a1");om.add(om.eq(a1.getIntField("puissanceFournie"),300));om.add(om.eq(a1.getIntField("prix"),40));IloObject a2 = om.makeInstance("Alimentation","a2");om.add(om.eq(a2.getIntField("puissanceFournie"),350));om.add(om.eq(a2.getIntField("prix"),50));IloObject a3 = om.makeInstance("Alimentation","a3");om.add(om.eq(a3.getIntField("puissanceFournie"),400));om.add(om.eq(a3.getIntField("prix"),65));Le nombre d’instances est très nettement inférieur au nombre « normal » que l’onpourrait trouver chez un assembleur d’ordinateur. Cependant ces instances permettentd’appréhender aisément la configuration. Le tableau A.1 fournit le nombre de modèlesobtenus sans contrainte spécifique, avec deux contraintes sur les disques durs et enfinavec les deux contraintes précédentes et trois autres concernant le prix de l’ordinateur,la puissance de l’alimentation et enfin le nombre de processeurs. Nous présentons, dansun premier temps, ces cinq contraintes :Le pc a deux disques durs :om.add(om.eq(pc.getCardinality("disqueDur"),2));Le pc n’a que des disques durs SATA :om.add(om.eq(pc.getAnyField("typeDD"),"SATA"));Le pc a un prix inférieur ou égal à 750 :om.add(om.le(pc.getIntField("prixTotal"),750));Le pc a une alimentation de puissance inférieure ou égale à 300 :- 130 -

A : Exemple de programme ILOG JConfiguratorom.add(om.le(pc.getObjectField("alimentation").getIntField("puissanceFournie"),300));La carte mère a deux processeurs :om.add(om.eq(om.cardOf(varProcesseur,pc.getObjectField("carteMere").getObjectSetField("processeur"),om.trueConstraint()),2));Sans contrainte Contraintes DD 5 contraintesNombre de modèles 9234 1026 1Tab. A.1 – Nombre de modèles trouvés pour l’exemple de l’ordinateur en fonction dunombre de contraintes spécifiquesOn peut se rendre compte que le nombre de modèles peut rapidement exploser. Onpeut également s’interroger sur le nombre de modèles possibles sans aucune contrainteni générique, ni spécifique. Dans ces conditions, il existe 340200 modèles. Ce chiffrecorrespond au nombre maximal de combinaisons entre tous les composants, sans tenircompte des éventuelles restrictions contenues dans les contraintes génériques. De même,le nombre de modèles décroît considérablement dès lors que l’utilisateur spécifie sespréférences : avec seulement 5 contraintes, le nombre de pc disponibles, passent de 9234(nombre de pc correctement configurables) à 1 seul.- 131 -

Annexe BUne approche des HPSGNous avons présenté les grammaires de propriétés comme exemple d’application auxgrammaires de configuration. Cependant, bien que ce choix ait été motivé par l’utilisationexplicite et systématique des contraintes dans la théorie, il est intéressant de voir dequelle manière les grammaires de configuration peuvent capturer un formalisme majeurtel que HPSG. Nous présentons ici une première approche du traitement du formalismeHPSG par des techniques de configuration (présenté brièvement dans [22]). L’objectifici n’étant pas de présenter les HPSG, nous supposerons le formalisme des HPSG connuet renvoyons à [53] pour une description en détail des éléments utilisés.Les éléments linguistiques sont nommés Signs en HPSG. [53] précise que les Signsont composés d’informations phonologiques, syntaxiques, sémantiques ainsi que sur lediscours et la structure des syntagmes. Les Signs sont représentés par des structures detraits typées.Comme vu tout au long de ce manuscrit, les structures de traits sont représentéessur un modèle objet. Les Signs de HPSG, représentés par des structures de traits typésseront définis de la même manière. L’utilisation des structures de traits typés est unemotivation supplémentaire pour l’utilisation d’un modèle objet pour les représenter.Les signes sont partitionnés, ce qui signifie que seules les feuilles de la hiérarchie sont« instanciables » et que deux types différents sont disjoints. La partition des signs estenracinée sur un élément nommé Object. La figure B.1 représente les partitions utiliséesdans [53].- 132 -

B : Une approche des HPSGPartition de object : list(σ), set(σ), boolean (bool), sign, phoneme-string(phonstring), constituentstructure(con-struc), mod-sem,local (loc), nonlocal (nonloc), nonlocall (nonlocl), category(cat), head, marking, verbform (vform), case, preposition-form (pform), content (cont),context (conx), contextual-indices (c-inds), quantifier-free-parametrized-state-of-affairs (qfpsoa),semantic-determiner (semdet), index (ind), person (per), number (num), gender (gen)Partition de list(σ) : nonempty-list(σ)(nelist(σ)), empty-list(elist ou 〈 〉)Partition de set(σ) : nonempty-set(σ)(neset(σ)), empty-set(eset ou { })Partition de boolean : plus (+), minus (−)Partition de sign : word, phrasePartition de mod-sem : syntax-semantic (synsem), nonePartition de head : substantive (subst), functional (func)Partition de substantive : noun, verb, adjective (adj), preposition (prep), relativizer (reltvzr)Partition de functional : marker (mark), determiner (det)Partition de marking : unmarked, markedPartition de marked : complementizer (comp), conjunction (conj), ...Partition de complementizer : that, forPartition de case : nominative (nom), accusative (acc)Partition de vform : finite (fin), infinitive (inf), gerund (ger), base (bse), present-participle (prp),past-participle (psp), passive-participe (pas)Partition de pform : to, of, ...Partition de phonstring : kIm, sændi, krIs, ...Partition de con-struc : headed-structure(head-struc), coordinate-structure (coord-struc)Partition de head-struc : head-complement-structure(head-comp-struc), head-marker-structure(head-mark-struc), head-adjunct-structure (head-adj-struc), head-filler-structure (head-fillerstruc)Partition de content : parametrized-state-of-affairs (psoa), nominal-object (nom-obj), quantifier(quant)Partition de semdet : forall, exists, the, ...Partition de index : referential (ref), there, itPartition de person : 1st, 2nd, 3rdPartition de number : singular (sing) , plural (plur)Partition de gender : masculine (masc), feminine (fem), neuter (neut)Partition de qfpsoa : control-qfpsoa, ...Partition de control-qfpsoa : influence, commitment, orientationPartition de influence : persuade, appeal, cause, ...Partition de commitment : promise, intend, try, ...Partition de orientation : want, hate, expect, ...Partition de nom-obj : nonpronoun (npro), pronoun (pron)Partition de pron : personal-pronoun (ppro), anaphor (ana)Partition de ana : refl, recpFig. B.1 – Partitions des éléments utilisés dans HPSGA partir de cette figure, nous pouvons définir les modèles objet des figures B.2 à- 133 -

B : Une approche des HPSGB.19. Comme tout modèle objet de modèle objet contraint ces modèles implémentent lesclasses concrètes sur les feuilles de la hiérarchie et rend ainsi bien compte des partitionsexprimées sur la figure B.1.Fig. B.2 – Modèle objet représentant la partition de objetFig. B.3 – Modèle objet représentant la partition de boolFig. B.4 – Modèle objet représentant la partition de sign- 134 -

B : Une approche des HPSGFig. B.5 – Modèle objet représentant la partition de mod-semFig. B.6 – Modèle objet représentant la partition de headFig. B.7 – Modèle objet représentant la partition de marking- 135 -

B : Une approche des HPSGFig. B.8 – Modèle objet représentant la partition de caseFig. B.9 – Modèle objet représentant la partition de vformFig. B.10 – Modèle objet représentant la partition de pformFig. B.11 – Modèle objet représentant la partition de phonstring- 136 -

B : Une approche des HPSGFig. B.12 – Modèle objet représentant la partition de con-strucFig. B.13 – Modèle objet représentant la partition de content- 137 -

B : Une approche des HPSGFig. B.14 – Modèle objet représentant la partition de semdetFig. B.15 – Modèle objet représentant la partition de indexFig. B.16 – Modèle objet représentant la partition de personFig. B.17 – Modèle objet représentant la partition de number- 138 -

B : Une approche des HPSGFig. B.18 – Modèle objet représentant la partition de genderFig. B.19 – Modèle objet représentant la partition de qfpsoaSur ces figures, nous remarquons que certaines classes sont labelisées « ... ». Cesclasses représentent un ensemble de classes non définies entièrement par [53]. Nous pouvonsciter, par exemple, la partition de marked : les « ... » sont présents car les auteurslaissent volontairement ouverte la question de savoir quels autres éléments, hors-mis lescomp et les conj, sont des marqueurs. De même, la partition de pform est incomplète caril n’existe pas de liste exhaustive de toutes les prépositions non prédicatives de l’anglais.Nous avons ainsi obtenu une première partie du modèle objet support. Nous allonsmaintenant voir comment nous pouvons le compléter avec une partie des structures detraits.B.1 Lists et setsCertains Signs n’ont pas de rapport avec des éléments de la linguistique. C’est le caspar exemple de list et de set qui sont cependant très utilisés dans HPSG, comme nouspourrons le constater sur les figures B.24 et B.25. La figure B.20 rappelle la hiérarchie detype pour les lists et les sets présentée dans [53] sous la forme de partitions d’ensembles.- 139 -

B : Une approche des HPSGPartition de list(σ) : nonempty-list(σ) (nelist(σ)), empty-list (elist or 〈 〉)Partition de set(σ) : nonempty-set(σ) (neset(σ)), empty-set (eset or | |)Fig. B.20 – Hiérarchie de types pour les éléments list et setLa modélisation UML prend naturellement en compte les ensembles. Les associationsbinaires définissent, de manière implicite pour chaque objet, l’ensemble des objets quilui sont connectés. Ainsi les sets ne nécessitent pas de structure particulière.[53] définit les listes par une structure de traits présentée sur la figure B.21. La[]FIRST σnonempty-list(σ) :REST list(σ)Fig. B.21 – Définition de la structure d’une liste non vide dans [53]représentation de cette définition est le modèle objet représenté sur la figure B.22. Nousn’utilisons pas de classe elist mais la cardinalité 0 pour définir une liste vide. A cetteFig. B.22 – Modèle objet traduisant strictement la définition d’une listefigure, il faut ajouter la contrainte spécifiant que les types des éléments sont de mêmenature :∀ l : list | (#(l.FIRST ) = 1) ∧ (#(l.REST ) = 1) •∀ l1 : object ; l2 : object | (l1 ∈ l.FIRST ) ∧ (l2 ∈ l.REST ) •l1.type = l2.typeSi nous supposons un objet O contenant une liste L de trois éléments : {l 1 , l 2 , l 3 }, lafigure B.23 représente les instances créées à partir du modèle de la figure B.22. Nousremarquons que la liste se termine par une instance de la classe list qui ne possède pasd’élément dans sa relation REST. Une liste vide sera représentée par une instance de laclasse list n’ayant ni élément FIRST ni élément REST.- 140 -

B : Une approche des HPSGFig. B.23 – Instances créées pour une liste de trois élémentsB.2 Structures de traitsLes figures B.24 et B.25 illustrent les déclarations de structures de traits pour lagrammaire de l’anglais proposée dans [53].⎡⎤PHONOLOGY list(phonstring)SYNSEM synsemsign : ⎢⎥⎣QSTOREset(quantifier) ⎦RETRIEVED list(quantifier)[]nonlocal :TO-BIND nonlocallINHERITED nonlocall[]context :BACKGROUNDset(psoa)CONTEXTUAL-INDICES c-inds[]CONJ-DTRSset(sign)coord-struc :CONJUNCTION-DTR word[]HEAD-DTR signhead-struc :COMP-DTR list(phrase)⎡HEAD⎢category : ⎣SUBCATMARKING[phrase : DAUGHTERS⎤head⎥list(synsem) ⎦marking]con-struc⎡⎤SLASH set(local)⎢⎥nonlocall : ⎣RELset(ref) ⎦QUE set(npro)[]LOCAL localsynsem :NONLOCAL NonLocal⎡⎤CATEGORY category⎢⎥local : ⎣CONTENTcontent ⎦CONTEXT contextFig. B.24 – Première partie des structures de traits présentées dans [53]- 141 -

B : Une approche des HPSG⎡⎤SPEAKERref⎢⎥c-inds : ⎣ADDRESSEEref⎦UTTERANCE-LOCATION ref⎡⎤HEAD-DTR phrase⎢⎥head-adjunct-struc : ⎣ADJUNCT-DTRphrase⎦COMP-DTR elist⎡⎤HEAD-DTR phrase⎢⎥head-filler-struc : ⎣FILLER-DTRphrase⎦COMP-DTRS elist⎡⎤HEAD-DTR phrase⎢⎥head-mark-struc : ⎣MARKER-DTRword ⎦COMP-DTRS elist[]functional : SPEC synsem⎡⎤VFORM vform⎢⎥verb : ⎣AUXboolean⎦INV boolean⎡⎤PERSON person⎢⎥index : ⎣NUMBERnumber⎦GENDER gender[]INFLUENCE refinfluence :INFLUENCED ref[]orientation : EXPERIENCER refsubstantive :[noun : CASE[PRDMOD]case[preposition : PFORMquantifier :[DETRESTIND]booleanmod-synsem]pform]semdetnpro[]INDEX indexnom-object :RESTR set(psoa)[]QUANTS list(quantifier)psoa :NUCLEUS qfpsoa[control-qfpsoa : SOA-ARG[commitment : COMMITOR]psoa]refFig. B.25 – Deuxième partie des structures de traits présentées dans [53]Contrairement aux notations habituelles de la modélisation objet, qui utilise desmajuscules pour les classes (au moins pour les premières lettres) et des minuscules pourles relations et les attributs, nous avons conservé les notations de HPSG.Il est intéressant de noter l’utilisation des relations de type ensemble pour les traitsayant une valeur de type set (comme SQTORE de sign).Il faut ajouter à ce modèle les contraintes de conception spécifiant les types d’éléments- 142 -

B : Une approche des HPSGFig. B.26 – Sous-partie du modèle objet représentant les stuctures de HPSG- 143 -

B : Une approche des HPSGpour les listes. Prenons par exemple la liste PHONOLOGY de la classe sign.∀ s : sign | (#(s.PHONOLOGY .FIRST ) = 1) •(s.PHONOLOGY .FIRST .type) ∩ phonstring ≠ B.3 Les principes HPSG vus comme des contraintes demodèle objet contraintLes HPSG introduisent des contraintes « universelles » nommées principes. Ces principesdéfinissent les constructions autorisées pour toute structure de traits. Nous présentonsmaintenant deux principes, ainsi que leurs représentations en tant que contraintes surle modèle objet.B.3.1Le principe des traits de têteCe principe est défini dans [53] de la manière suivante :Définition 12 (The Head Feature Principle) In a headed phrase 1 the values of SYN-SEM | LOCAL | CATEGORY | HEAD and DAUGHTERS | HEAD-DTR | SYNSEM |LOCAL | CATEGORY | HEAD are token-identical∀ p : Phrase •p.SYNSEM .LOCAL.CATEGORY .HEAD =p.DAUGHTERS.HEAD − DTR.SYNSEM .LOCAL.CATEGORY .HEADCette contrainte montre que la notion de token identical (partage de valeur de traits)est totalement prise en compte par la modélisation. Pour ce faire, les relations utiliséessont des relations d’associations qui n’implémentent pas la propriété d’exclusivité.B.3.2Le principe des traits non locauxCe principe est défini ainsi :Définition 13 (The nonlocal Feature Principle) In a headed phrase, for each nonlocalfeature F = SLASH, QUE or REL, the value of SYNSEM|NONLOCAL|INHERITED|Fis the set difference of the union of the values on all the daughters and the value ofSYNSEM|NONLOCAL|TO-BOND|F on the HEAD-DAUGHTER.Une headed phrase possède les traits : HEAD-DTR et une liste de phrases COMP-DTR. Ainsi le principe des traits non locaux (NLFP) doit être défini de manière récursivesur l’ensemble des éléments de la liste.Commençons par définir une fonction récursive (funRecsl) qui prend en paramètreune fonction et retourne l’union des résultats fournis par son application à tous leséléments de la liste :1 Une headed phrase est un syntagme dont le trait DAUGHTERS est de type headed-structure.- 144 -

B : Une approche des HPSGfunRecsl : ((object " object) × list) " object∀ l : list ; f : object " object •∀ h : l.FIRST ; g : l.REST • funRecsl(f , l) = f (h) ∪ funRecsl(f , g)Nous pouvons maintenant définir une fonction qui crée l’ensemble des élémentshérités (F représente, comme dans la défintion 13, les traits SLASH, REL ou QUE)NLFPrec : phrase " Object∀ P : phrase | NLFPrec(P) =P.DAUGHTERS.HEAD − DTR.SYNSEM .NONLOCAL.INHERITED.F∪funRecsl(NLFPrec, P.DAUGHTERS.COMP − DTR)Enfin nous pouvons définir la contrainte établissant que chaque phrase ayant uneheaded-struc répond au principe des traits non locaux :∀ P : phrase | P.DAUGHTERS.type ∩ head − struc ≠ (P.SYNSEM .NONLOCAL.INHERITED.F ) =NLFPrec(P) \ (P.SYNSEM .NONLOCAL.TO − BIND)- 145 -

Annexe CFragment du UML Core utilisépour les modèles objet contraintsFig. C.1 – Fragment du UML Core utilisé pour les modèles objet contraints - issu de[35]- 146 -

Bibliographie[1] Nareyek Alexander. Structural constraint satisfaction. In AAAI Press, editor, the1999 AAAI Workshop on Configuration, Technical Report, WS990, pages 76–82,1999.[2] Jérôme Amilhastre, Hélène Fargier, and Pierre Marquis. Consistency restorationand explanations in dynamic csps—-application to configuration. Artificial Intelligence,135(1-2) :199–234, 2002.[3] F. Baader and W. Nutt. Basic description logics, 2003.[4] Jean Marie Balfourier, Philippe Blache, Marie-Laure Guénot, and Tristan VanRullen.Comparaison de trois analyseurs symboliques pour une tâche d’annotationsyntaxique. In TALN’05, pages 41–48, 2005.[5] Jean Marie Balfourier, Philippe Blache, and Tristan VanRullen. From shallow todeep parsing using constraint satisfaction. In COLING’02, pages 36–42, 2002.[6] Virginia Barker, Dennis E. O’Connor, Judith Bachant, and Elliot Soloway. Expertsystems for configuration at digital : Xcon and beyond. Communications of theACM, 32 :298–318, 1989.[7] Tilman Becker, Owen Rambow, and Michael Niv. The derivational generative powerof formal systems, or, scrambling is beyond LCFRS. Technical Report IRCS-92-38,Institute for research in cognitive science, Philadelphia, PA, 1992.[8] Philippe Blache. Une introduction ‘a hpsg.[9] Philippe Blache. Parsing ambiguous structures using controlled disjunctions andunary quasi-trees. In COLING-ACL, pages 124–130, 1998.[10] Philippe Blache. Property grammars and the problem of constraint satisfaction. InESSLLI-2000 workshop on Linguistic Theory and Grammar Implementation, pages47–56, 2000.[11] Philippe Blache. Les Grammaires de Propriétés : des contraintes pour le traitementautomatique des langues naturelles. Hermès Sciences, 2001.[12] Noam Chomsky. Systems of syntactic analysis. The Journal of Symbolic Logic,18(3) :242–256, September 1953.[13] Noam Chomsky. Aspects of the Theory of Syntax. MIT Press, 1965.[14] Noam Chomsky. Aspects de la Théory Syntaxique. Seuil, 1971.- 147 -

BIBLIOGRAPHIE[15] Alain Colmerauer. An introduction to prolog 3. communication of the ACM,33(7) :69–90, 1990.[16] Thomas Cornell and James Rogers. Model theoretic syntax, 1998.[17] Ralph Debusmann. Extensible Dependency Grammar — A Modular Grammar FormalismBased On Multigraph Description. PhD thesis, Universität des Saarlandes,4 2006.[18] Ralph Debusmann, Denys Duchier, and Marco Kuhlmann. Multi-dimensional graphconfiguration for natural language processing. In Constraint Solving and LanguageProcessing, Sept 2004.[19] Denys Duchier. Axiomatizing dependency parsing using set constraints. In SixthMeeting on Mathematics of Language, Orlando, Florida, pages 115–126, 1999.[20] Denys Duchier and Ralph Debusmann. Topological dependency trees : A constraintbasedaccount of linear precedence. In proceedings of the 39th Annual Meeting ofthe Association for Computational Linguistics (ACL 2001), pages 180–187, 2001.[21] Mathieu Estratat and Laurent Henocque. Comprendre des descriptions simples àl’aide d’un configurateur. In Premières Journées Francophones de Programmationpar Contraintes, JFPC’2005, pages 325–334, Université d’Artois, Lens, Juin 2005.[22] Mathieu Estratat and Laurent Henocque. An intuitive tool for constraint basedgrammars. In Henning Christiansen, Peter Rossen Skadhauge, and Jorgen Villadsen,editors, Revised Selected and Invited Papers, Constraint Solving and LanguageProcessing, First International Workshop, CSLP 2004, Roskilde, Denmark, September1–3, volume 3438 of Lecture Notes in Computer Science, pages 121–139.CSLP, Springer, 2005. isbn 3–540-26165–6.[23] Mathieu Estratat and Laurent Henocque. Traduction automatique de grammairesde traits en un problème de configuration syntaxique. In Deuxièmes JournéesFrancophones de Programmation par Contraintes, JFPC’2006, pages 139 – 148,Ecole des Mines d’Ales - site EERIE, Nîmes, juin 2006.[24] Mathieu Estratat and Laurent Henocque. Application des programmes decontraintes orientés objet à l’analyse du langage naturel. In Proceedings of TraitementAutomatique des Langues Naturelles, TALN 2004, pages 163–172, Fes, Morocco,April 2004.[25] Mathieu Estratat and Laurent Henocque. Parsing languages with a configurator.In proceedings of the European Conference for Artificial Intelligence ECAI 2004,pages 591–595, Valencia, Spain, August 2004.[26] Mathieu Estratat and Laurent Henocque. Parser des languages avec un configurateur.In Proceedings of the 10 ièmes journées Nationales sur la résolution pratiquedes problèmes NP-complets, JNPC’04, pages 155–167, Angers, France, June 2004.[27] Mathieu Estratat and Raphaël La Greca. An interfacing module using configurationfor declarative design of nurbs surfaces. In The Ninth International Conference onComputer Graphics and Artificial Intelligence (3IA’2006), pages 85 – 96, Limoges,France, mai 2006.- 148 -

BIBLIOGRAPHIE[28] Hélène Fargier and Laurent Henocque. Configuration à base de contraintes. InInformation Interaction Intelligence, Actes des 2ièmes Assises nationales du GdRI3, pages 141–159. Cépadues-éditions, 2002.[29] Alexander Felfernig, Gerhard Friedrich, Dietmar Jannach, and Markus Zanker.Configuration knowledge representation using UML/OCL. In Proceedings of the5th International Conference on The Unified Modeling Language, pages 49–62.Springer-Verlag, 2002.[30] Gerhard Fleischanderl, Gerhard Friedrich, Alois Haselböck, Herwig Schreiner, andMarkus Stumptner. Configuring large-scale systems with generative constraint satisfaction.IEEE Intelligent Systems - Special issue on Configuration, 13(7), 1998.[31] Gerald Gazdar, Ewan Klein, Geoffrey Pullum, and Ivan A. Sag. Generalized PhraseStructure Grammar. Blackwell, Oxford, 1985.[32] Michael Gelfond and Vladimir Lifschitz. The stable model semantics for logic programming.In 5th International Conférence and Symposium on Logic Programming,pages 1070–1080, Cambridge, 1988. MIT Press.[33] Robert Grabowski, Marco Kuhlmann, and Mathias Möhl. Lexicalised configurationgrammars. In Second International Workshop on Constraint Solving and LanguageProcessing (CSLP 2005), Sitges, Spain, 2005.[34] Object Management Group. UML. Technical Report 2.0, OMG, 2004.[35] Object Management Group. UML 2.0 Infrastructure Specification. Technical Report2.0, OMG, 2004.[36] Laurent Henocque. Modeling object oriented constraint programs in Z. RACSAM(Revista de la Real Academia De Ciencias serie A Mathematicas), special issueabout Artificial Intelligence and Symbolic Computing, page to appear, 2004.[37] Laurent Henocque, Mathias Kleiner, and Nicolas Prcovic. Advances in polytimeisomorph elimination for configuration. In proceedings of Principles and Practice ofConstraint Programming - CP 2005,, pages 301–313, Sitges Barcelona, Spain, 2005.Springer.[38] Laurent Henocque and Nicolas Prcovic. Practically handling configuration automorphisms.In proceedings of ICTAI 2004, The 16th IEEE Internatioanl Conferenceon Tools for Artificial Intelligence, Boca Raton, Florida, November 15–17 2004.[39] Ulrich Junker. Preference programming for configuration. In AAAI/IAAI 2000,pages 904–909, 2000.[40] Ulrich Junker. Preference-based search for scheduling. In IJCAI 2001 Workshopon Configuration, 2001.[41] Ulrich Junker and Daniel Mailharro. The logic of ilog (j)configurator : Combiningconstraint programming with a description logic. In IJCAI 2003 Workshop onConfiguration, 2003.[42] Sylvain Kahane. Grammaires de dépendences formelles et théorie sens-texte - tutoriel.In TALN’01, 2001.- 149 -

BIBLIOGRAPHIE[43] Raphaël La Gréca. Approche déclarative de la modélisation de surfaces. thèse dedoctorat, Université Aix-Marseille II, octobre 2005. directeur : Marc Daniel.[44] Raphaël La Greca and Marc Daniel. A declarative system to design preliminarysurfaces. In WSCG’06, volume 80-86943-03-8, pages 17–24, University of WestBohemia, Czech Republic, january 30 – february 3 2006.[45] Diego Magro and Pietro Torasso. Decomposition strategies for configuration problems.Artif. Intell. Eng. Des. Anal. Manuf., 17(1) :51–73, 2003.[46] Daniel Mailharro. A classification and constraint based framework for configuration.AI-EDAM : Special issue on Configuration, 12(4) :383 – 397, 1998.[47] Igor Mel´cuk. Levels of dependency in linguistic description : Concepts and problems.In V. Agel, L. Eichinnger, H.-W. Eroms, P. Hellwig, H. J. Herringer, andH. Lobin, editors, Dependency and Valency - An International Handbook of ContemporaryResearch, volume 1, pages 188–229, 2003.[48] Sanjay Mittal and Brian Falkenhainer. Dynamic constraint satisfaction problems.In Proceedings of AAAI-90, pages 25–32, Boston, MA, 1990.[49] Bernhard Nebel. Reasoning and revision in hybrid representation systems. LectureNotes in Artificial Intelligence, 422, 1990.[50] Robert Pasero and Paul Sabatier. Illico : un système générique de compréhensiond’un sous-ensemble du français. Technical report, LIM, November 1999.[51] Robert Pasero and Paul Sabatier. Illico : Principes, connaissances et formalismes.Technical report, LIF, Décembre 2005.[52] Carl Pollard and Ivan A. Sag. Information-based Syntax and Semantics. TheUniversity of Chicago Press, Chicago, 1987.[53] Carl Pollard and Ivan A. Sag. Head-Driven Phrase Structure Grammar. The Universityof Chicago Press, Chicago, 1994.[54] Geoffrey K. Pullum and Barbara C. Scholz. On the distinction between modeltheoreticand generative-enumerative syntactic frameworks. In Philippe de Groote,Glyn Morrill, and Christian Retoré, editors, ’Logical Aspect of Computational Linguistics: 4th International Conference’ (Lecture Notes in Artificial Intelligence -2099), pages 17–43, 2001.[55] Daniel Sabin and Eugène C. Freuder. Configuration as composite constraint satisfaction.In Artificial Intelligence and Manufacturing Research Planning Workshop,pages 153–161, 1996.[56] Timo Soininen, Ilkka Niemelä, Juha Tiihonen, and Reijo Sulonen. Unified configurationknowledge representation using weight constraint rules. In Workshop Notesof the ECAI’2000 Configuration Workshop, pages 79–84, Berlin, Germany, August2000.[57] Timo Soininen, Ilkka Niemela, Juha Tiihonen, and Reijo Sulonen. Representingconfiguration knowledge with weight constraint rules. In Proceedings of the AAAISpring Symp. on Answer Set Programming : Towards Efficient and Scalable Knowledge,pages 195–201, March 2001.- 150 -

BIBLIOGRAPHIE[58] J. M. Spivey. The Z Notation : a reference manual. Prentice Hall originally, nowJ.M. Spivey, 2001.[59] Markus Stumptner. An overview of knowledge-based configuration. AI Communications,10(2) :111–125, June 1997.[60] Markus Stumptner and Alois Haselböck. A generative constraint formalism forconfiguration problems. Advances in Artificial Intelligence : Proceedings of theThird Congress of the Italian Association for Artificial Intelligence AI*IA’93, pages302–313, 1993.[61] Lucien Tesnière. Eléments de syntaxe structurale. Klincksiek, Paris, 1959.[62] Tristan VanRullen. Vers une analyse syntaxique à granularité variable. Thèse dedoctorat, Université de Provence (Aix-Marseille I), 12 décembre 2005.[63] Atro Voutilainen. Engcg tagger, version 2. Sprog og Multimedier, 1997.- 151 -

Vers les grammaires de configurationRESUMECette thèse a pour objet d’utiliser la recherche de modèles finis comme un cadre uniquepour l’analyse de langages naturels du double point de vue syntaxique et sémantique.Pour la syntaxe, les grammaires de configuration que nous proposons offrent un cadreformel de représentation et d’étude de grammaires. Elles autorisent notamment laréalisation d’un analyseur syntaxique par simple définition de la grammaire. Le traitementde la sémantique est envisagé, quant à lui, sur des textes descriptifs (décrivantdes objets). Ces traitements syntaxico-sémantiques sont décrits par des modèles objetscontraints, formalisés grâce au langage Z . Cette méthode, nouvelle à notre connaissancedans le domaine de l’analyse du langage naturel, présente l’avantage d’être indépendantedes techniques de résolution. Nous avons choisi une méthode de recherche de modèlesfinis, la configuration, pour la recherche de solutions à partir d’une interprétation dumodèle objet contraint.DISCIPLINE : InformatiqueMOTS-CLES : Configuration, Modèles objet contraint, grammaires de configuration,analyse du langage naturel, syntaxe, sémantiqueABSTRACTThe goal of this thesis is to use finite models search as a single natural language parsingframework at both syntactical and semantical points of view. For the syntax, theconfiguration grammars we propose offer a formal framework for the representation andstudying of grammars. They allow the implementation of a syntactical parser, just bydefining the grammar. The semantics treatment is based on descriptive texts (whichdescribe objects). These syntactico-semantic treatments are described by constrainedobject models, formalized with the Z language. This method, new to the best of ourknowledge in natural language analysis, presents the advantage of being independantfrom resolution technics. We are using a finite model search method, called configuration,for searching a solution out of an interpretation of the constrained object model.KEYWORDS : Configuration, Constrained object models, configuration grammars,natural language parsing, syntax, semanticsLaboratoire des Sciences de l’Information et des Systèmes (LSIS) - UMR CNRS 6168