Contribution à la programmation générative. Application dans le générateur SmartTools : technologies XML, programmation par aspects et composants

Texte intégral

(1)Contribution à la programmation générative. Application dans le générateur SmartTools : technologies XML, programmation par aspects et composants Carine Courbis. To cite this version: Carine Courbis. Contribution à la programmation générative. Application dans le générateur SmartTools : technologies XML, programmation par aspects et composants. Autre [cs.OH]. Université Nice Sophia Antipolis, 2002. Français. �tel-00505412�. HAL Id: tel-00505412 https://tel.archives-ouvertes.fr/tel-00505412 Submitted on 23 Jul 2010. HAL is a multi-disciplinary open access archive for the deposit and dissemination of scientific research documents, whether they are published or not. The documents may come from teaching and research institutions in France or abroad, or from public or private research centers.. L’archive ouverte pluridisciplinaire HAL, est destinée au dépôt et à la diffusion de documents scientifiques de niveau recherche, publiés ou non, émanant des établissements d’enseignement et de recherche français ou étrangers, des laboratoires publics ou privés..

(2) U NIVERSITÉ. DE. N ICE S OPHIA -A NTIPOLIS - UFR S CIENCES École Doctorale STIC. C ONTRIBUTION À LA PROGRAMMATION GÉNÉRATIVE A PPLICATION DANS LE GÉNÉRATEUR S MART T OOLS : TECHNOLOGIES XML, PROGRAMMATION PAR ASPECTS ET COMPOSANTS. THÈSE. DE. Présentée pour obtenir le titre de D OCTEUR EN S CIENCES L’U NIVERSITÉ DE N ICE S OPHIA -A NTIPOLIS Spécialité I NFORMATIQUE. par Carine C OURBIS. Thèse dirigée par Didier PARIGOT et Isabelle ATTALI, à l’INRIA Sophia-Antipolis Soutenue publiquement, le 10 décembre 2002, à 11 heures devant le jury composé de. Président Rapporteurs Examinateur Directeurs. Michel Jean Jean-Marc Daniel Didier Isabelle. R IVEILL B ÉZIVIN J ÉZÉQUEL DARDAILLER PARIGOT ATTALI. Université de Nice Sophia-Antipolis Université de Nantes Université de Rennes - IRISA W3C INRIA Sophia-Antipolis INRIA Sophia-Antipolis.

(3)

(4) Remerciements Voila une page se tourne. Je voudrais remercier toutes les personnes qui m’ont formée au cours de ces années et qui m’ont guidée vers le monde de l’informatique et de ses insectes. J’ai une pensée particulière pour les enseignants du département ISI de l’IUT de Valence et pour ceux de l’INSA de Lyon qui m’ont aidée à partir en Suède en année d’échange. Pour cette thèse, j’aimerais remercier : Didier PARIGOT1 , mon directeur de thèse. Je lui serai toujours redevable pour avoir accepté, se plaçant dans une situation assez inconfortable, de m’encadrer à son arrivée à Sophia en 2000. Sans lui, cette thèse n’aurait pas été achevée. Comment le remercier pour sa gentillesse, son écoute attentive, son soutien et son aide au cours de ces années ? Ce fut un bonheur de travailler avec lui et d’être traitée en égale. Sa capacité à tisser des points de synergie entre différents domaines et son aisance déconcertante à «surfer» sur de nouvelles technologies font mon admiration2 . Alexandre FAU et Pascal D EGENNE, les «petites-mains» de S MART T OOLS, qui codent plus vite que leurs ombres3 . Je leur suis reconnaissante pour m’avoir, si rapidement, adoptée dans la Smarties-team et pour m’avoir toujours aidée surtout dans mes traques d’insectes. Merci aussi pour tous les conseils photo et les fous rires. L’équipe que nous formions tous les quatre avec Didier va me manquer, surtout pour nos «tempêtes de cerveaux» si stimulantes et pour l’ambiance de travail si chaleureuse. Cette thèse leur doit beaucoup. Les membres de mon jury dont Michel R IVEILL (président de jury), Jean B ÉVIZIN, Jean-Marc J ÉZÉQUEL (rapporteurs), et Daniel DARDAILLER (examinateur) pour avoir accepter de juger mon travail alors qu’ils avaient des emplois du temps surchargés. Les membres et ex-membres du projet OASIS et plus particulièrement Bernard S ER PETTE pour avoir bien voulu «jouer aux cartes» avec du Lisp, Maryse R ENAUD pour sa bonne humeur quotidienne et son énergie, et Henrik N ILSSON pour m’avoir initiée à l’écriture d’un article scientifique. Les membres de ex-projet CROAP et plus particulierement Yves B ERTOT pour nos discussions de début de thèse, Valérie PASCUAL pour son aide avec Centaur, et Francis M ONTAGNAC pour sa hotline si efficace. Mes amis pour m’avoir soutenue pendant cette dernière année et plus particulièrement : 1. Note pour Didier : STP, exauce rapidement mon premier souhait de Docteur. Son secret, c’est peut-être son modèle abstrait : les grammaires attribuées :)) 3 J’ai le droit de les traiter de Lucky Luke de la programmation. Eux, ils faisaient bien pire :)) tel que «retourne à ta thèse», «touche pas à ma souris» ou Carine.getContext(). 2. iii.

(5) – Fabrice H UET et Sara A LOUF pour nos folles soirées à l’INRIA. – Diane L INGRAND et Johan M ONTAGNAT, Céline et Brice C AZAUX pour toutes les expériences culinaires (avec des brocolis, bien sûr) et les sorties ciné/dvd. Je n’oublierai pas non plus les adorables Sophie et Emilie, déjà si présentes dans nos discussions, nées finalement avant la fin de ce manuscrit. – Hanane NACIRI pour son amitié indéfectible depuis mon arrivée à l’INRIA. – Rabéa B OULIFA, ma co-bureau, pour m’avoir supportée durant cette dernière année (pas la meilleure, c’est sûr) et pour avoir crû en moi. – Guillaume D UFAY et Ludovic H ENRIO pour toutes les randos de folie dans le Mercantour, pour les «bidouilles» LATEX4 , pour les répétitions de soutenance le week-end, et pour un certain vendredi noir (merci aussi à Simão D E S OUSA et à Rabéa). Je voudrais aussi souhaiter bon courage, pour leur fin de thèse, à Ludo, Guillaume, Rabéa, Aubin JARRY, Céline H UDELOT, Manuéla P EREIRA, Laurent BADUEL, Arnaud C ONTES, Tomas BARROS, Félipe L UNA D EL AGUILA 5 , Carolina M ÉDINA -R AMIREZ, Victor R A MOS, et Karine ROBBES. Ma famille et plus particulièrement mes parents qui m’ont toujours encouragée à poursuivre mes études.. Carine6. 4. Ce manuscrit a été réalisé avec LATEXpour la mise en forme et dia pour les schémas. Note pour Félipe : prends bien soin de waha. C’est une gentille machine. 6 Dite aussi cc (surnom donné par Fab), Idéfix (par Alex pour «sauver les arbres» et idée fixe), Calimodo (toujours par Alex pour «c’est vraiment trop injuste» tel Caliméro et une démarche à la Casimodo à cause d’une tendinite à chaque genou), et enfin Fée Bleuphame (par Nicolas D EY, disciple de Fabien G ANDON pour les jeux de mots, pour me faire accélérer dans la descente du Mont Capelet). 5. iv.

(6) Table des matières Liste des acronymes Introduction Contexte et présentation de la thèse . Contribution . . . . . . . . . . . . . Justificatifs de notre démarche . . . Plan du manuscript . . . . . . . . . 1. 2. xiii. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. Présentation générale de S MART T OOLS 1.1 Syntaxe abstraite et outils . . . . . . . . . . . . . . . . . . . . . . 1.1.1 Langage de définition de syntaxe abstraite . . . . . . . . . 1.1.2 Implémentation au-dessus de l’API DOM . . . . . . . . . 1.1.3 Passerelles pour importer des DTDs ou des XML schemas 1.1.4 Outils générés . . . . . . . . . . . . . . . . . . . . . . . . 1.2 Traitements sémantiques . . . . . . . . . . . . . . . . . . . . . . 1.2.1 Le patron visiteur . . . . . . . . . . . . . . . . . . . . . . 1.2.2 Programmation par aspects . . . . . . . . . . . . . . . . . 1.3 L’architecture de SmartTools . . . . . . . . . . . . . . . . . . . . 1.4 Environnement interactif . . . . . . . . . . . . . . . . . . . . . . 1.4.1 Modèle document/vues . . . . . . . . . . . . . . . . . . . 1.4.2 Construction des vues et de l’interface graphique . . . . . 1.4.3 Le langage Xpp . . . . . . . . . . . . . . . . . . . . . . . 1.5 Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.5.1 Une application d’interconnexion avec un afficheur Web . 1.5.2 Environnements dédiés . . . . . . . . . . . . . . . . . . . Présentation des technologies XML 2.1 Les langages de définitions de structure : DTD et XML Schema 2.1.1 DTD . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.2 XML Schema . . . . . . . . . . . . . . . . . . . . . . . 2.2 Langage de transformation : XSLT (et XPath) . . . . . . . . . . 2.3 Autres langages . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.1 BML . . . . . . . . . . . . . . . . . . . . . . . . . . . v. . . . . . .. . . . .. . . . . . . . . . . . . . . . .. . . . . . .. . . . .. . . . . . . . . . . . . . . . .. . . . . . .. . . . .. . . . . . . . . . . . . . . . .. . . . . . .. . . . .. . . . . . . . . . . . . . . . .. . . . . . .. . . . .. 1 1 3 5 8. . . . . . . . . . . . . . . . .. 11 12 12 14 16 16 17 18 20 21 24 24 24 27 29 29 30. . . . . . .. 33 37 37 40 45 50 50.

(7) TABLE DES MATIÈRES 2.3.2 3. 4. 5. CSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. Outils syntaxiques 3.1 Le langage de définition d’AST : A B S YNT . . . . . . . . . . . . . . 3.1.1 Notions de base : constructeur, type et attribut . . . . . . . . 3.1.2 Détails d’implémentation . . . . . . . . . . . . . . . . . . . 3.1.3 Perspectives . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2 Traduction de DTD en A B S YNT . . . . . . . . . . . . . . . . . . . 3.2.1 Rapprochement des notions . . . . . . . . . . . . . . . . . 3.2.2 Structures de données et algorithme de traduction . . . . . . 3.2.3 Implémentation et résultats . . . . . . . . . . . . . . . . . . 3.3 Quelques indications pour traduire un XML Schema en A B S YNT . . 3.3.1 Rapprochement des notions . . . . . . . . . . . . . . . . . 3.3.2 Structures de données et algorithme d’importation envisagés 3.4 Génération de parseurs et d’afficheurs . . . . . . . . . . . . . . . . 3.4.1 C O S YNT ou comment décrire une forme concrète . . . . . . 3.4.2 Génération d’afficheurs . . . . . . . . . . . . . . . . . . . . 3.4.3 Génération d’analyseurs syntaxiques . . . . . . . . . . . . .. 53 55 55 56 59 59 59 63 66 67 67 72 75 76 77 77. . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . .. Outils sémantiques : visiteurs et aspects 4.1 Contexte et présentation de notre approche . . . . . . . . . . . . . . . . 4.1.1 Principes du patron de conception visiteur pour le langage Java 4.1.2 Nos approches . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2 Visiteur configurable et à aspects . . . . . . . . . . . . . . . . . . . . . 4.2.1 Signatures des méthodes visit configurables . . . . . . . . . 4.2.2 Parcours configurable . . . . . . . . . . . . . . . . . . . . . . . 4.2.3 Ajout dynamique d’aspects . . . . . . . . . . . . . . . . . . . . 4.2.4 Détails d’implémentation . . . . . . . . . . . . . . . . . . . . . 4.3 Visiteur découplé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3.1 Séparation parcours/sémantique et composition de sémantiques 4.3.2 Détails d’implémentation et perspectives . . . . . . . . . . . . 4.4 Visiteur générique . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . .. 83 . 86 . 86 . 89 . 91 . 92 . 95 . 96 . 97 . 99 . 99 . 101 . 104. . . . . . . . .. 107 109 110 111 113 123 123 125 133. Architecture par composants 5.1 Positionnement des travaux . . . . . . . . . . . . . . . . . . . 5.2 Le modèle abstrait de composants de S MART T OOLS . . . . . 5.2.1 Le modèle de composants . . . . . . . . . . . . . . . 5.2.2 Les principaux types de composants de S MART T OOLS 5.3 La mise en oeuvre . . . . . . . . . . . . . . . . . . . . . . . . 5.3.1 Le générateur de conteneur . . . . . . . . . . . . . . . 5.3.2 Le gestionnaire de composants . . . . . . . . . . . . . 5.4 Évaluation du modèle . . . . . . . . . . . . . . . . . . . . . . vi. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . . . . . . . . .. 51. . . . . . . . .. . . . . . . . .. . . . . . . . ..

(8) TABLE DES MATIÈRES Conclusion 137 Perspectives d’applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137 L’intérêt de l’approche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139 A S MART T OOLS mini-HowTo A.1 Short presentation . . . . . . . . . . . . . . . A.2 How to run the S MART T OOLS platform . . . A.2.1 What you need to run S MART T OOLS A.2.2 Running S MART T OOLS . . . . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. B Exemples de visiteurs L’environnement utile pour la vérification de type du langage T INY . Visiteur configurable pour la vérification de type . . . . . . . . . . . Visiteur découplé pour la vérification de type . . . . . . . . . . . . Visiteur découplé pour la vérification de l’initialisation des variables. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. 147 147 148 148 148. . . . .. 149 149 151 153 155. Bibliographie. 157. Résumé - Abstract. 164. vii.

(9) TABLE DES MATIÈRES. viii.

(10) Table des figures 1. Vue fonctionnelle de S MART T OOLS . . . . . . . . . . . . . . . . . . . . .. 1.1 1.2 1.3 1.4 1.5 1.6 1.7 1.8 1.9 1.10 1.11 1.12 1.13 1.14 1.15 1.16 1.17 1.18. Une partie de la définition d’AST de notre langage jouet T INY . . . . . Définition du constructeur assign avec les sucres syntaxiques . . . . Schéma du graphe d’héritage du constructeur assign . . . . . . . . . Interface AssignNode générée . . . . . . . . . . . . . . . . . . . . . Programme T INY (table de multiplication par 2) . . . . . . . . . . . . . L’ensemble des spécifications générées à partir d’une définition d’AST . Partie du fichier de personnalisation de l’évaluateur de T INY . . . . . . Evaluation du constructeur while sans profil . . . . . . . . . . . . . . Evaluation du constructeur while avec un profil . . . . . . . . . . . . Code d’un aspect traçant les méthodes visit appelées . . . . . . . . . L’architecture de S MART T OOLS . . . . . . . . . . . . . . . . . . . . . Interface utilisateur montrant différentes vues du même AST . . . . . . Communication entre le document et ses vues . . . . . . . . . . . . . . Processus de transformation. . . . . . . . . . . . . . . . . . . . . . . . Exemple de règle Xpp. . . . . . . . . . . . . . . . . . . . . . . . . . . Règle de la figure 1.15 exprimée en XSLT. . . . . . . . . . . . . . . . . Processus de génération des feuilles de style . . . . . . . . . . . . . . . Différent types d’accès à S MART T OOLS . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . .. 13 13 15 15 17 18 19 19 20 21 23 25 25 26 28 28 28 30. 2.1 2.2 2.3 2.4 2.5. Exemple de document bien formé . . . . . . . . . . . . . . . . . Exemple de DTD externe . . . . . . . . . . . . . . . . . . . . . . Exemple de document valide par rapport à la DTD de la figure 2.2 Exemple de XML Schema . . . . . . . . . . . . . . . . . . . . . Exemple de feuille de style XSLT . . . . . . . . . . . . . . . . .. . . . . .. . . . . .. 35 39 39 45 50. 3.1 3.2 3.3 3.4 3.5 3.6 3.7. Correspondance entre un document XML et les objets Java . . . . . . . . . Spécifications générées à partir d’une spécification A B S YNT ou d’une DTD Définition A B S YNT du langage T INY . . . . . . . . . . . . . . . . . . . . Graphe d’héritage d’une classe d’un nœud non atomique . . . . . . . . . . Graphe d’héritage d’une classe d’un nœud atomique . . . . . . . . . . . . . Exemple de spécification C O S YNT du langage T INY . . . . . . . . . . . . Représentation des transformations de l’AST à l’arbre d’objets graphiques .. 54 54 57 58 58 79 80. ix. . . . . .. . . . . .. . . . . .. 4.

(11) TABLE DES FIGURES 3.8 3.9. Représentation plus détaillée des transformations . . . . . . . . . . . . . . Chaîne de génération de vues et d’analyseurs syntaxiques . . . . . . . . . .. 4.1 4.2 4.3 4.4 4.5 4.6 4.7 4.8 4.9 4.10 4.11 4.12 4.13 4.14 4.15 4.16 4.17 4.18 4.19. Mécanisme d’indirection du patron de conception visiteur . . . . . . Diagramme de séquence de la visite d’un nœud d’affectation . . . . Vérification de type du nœud assign avec une visite classique. . . . Vérification de type du nœud assign avec notre première approche. . Fichier V I P ROFILE associé au vérificateur de type du langage T INY Mécanisme d’appel des méthodes . . . . . . . . . . . . . . . . . . Exemple de diagramme de séquence d’un visiteur configuré . . . . Spécification d’un parcours en V I P ROFILE . . . . . . . . . . . . . . Code d’un aspect traçant les nœuds visités . . . . . . . . . . . . . . Exemple de lancement d’un visiteur avec branchement d’un aspect . Détails de l’étape 3 du mécanisme d’appel de la figure 4.6 . . . . . Diagramme de séquence détaillé de la figure 4.7 . . . . . . . . . . . Structure d’un visiteur découplé et principales méthodes . . . . . . Sémantique de la vérification de type du constructeur assign . . . . Exemple de diagramme de séquence d’un visiteur découplé . . . . . Sémantique de la vérification d’initialisation de variable pour assign Sémantique d’évaluation du constructeur while . . . . . . . . . . . Création d’un visiteur découplé à sémantiques composées . . . . . . Graphe d’héritage de nos visiteurs . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . .. 88 88 91 92 94 94 95 96 97 97 98 99 100 101 102 103 103 103 104. 5.1 5.2 5.3 5.4 5.5 5.6 5.7 5.8 5.9 5.10 5.11 5.12 5.13 5.14 5.15 5.16 5.17 5.18 5.19 5.20 5.21. Syntaxe abstraite de notre modèle de composants . . . . . . . . . . . Description du composant abstrait abstractContainer . . . . . Ports communs à tous les composants . . . . . . . . . . . . . . . . . Description du composant graph . . . . . . . . . . . . . . . . . . . Schéma du composant graph . . . . . . . . . . . . . . . . . . . . . Ports communs à tous les composants de visualisation . . . . . . . . . Vue d’un programme du langage T INY avec le menu spécifique . . . . La vue d’édition structurée du langage T INY . . . . . . . . . . . . . . Schéma du composant de la vue d’édition structurée . . . . . . . . . . La vue de debug. . . . . . . . . . . . . . . . . . . . . . . . . . . . . Schéma du composant de la vue de debug . . . . . . . . . . . . . . . Exemple d’interface graphique . . . . . . . . . . . . . . . . . . . . . Composant de l’interface utilisateur . . . . . . . . . . . . . . . . . . Ports communs à tous les composants de type Document. . . . . . . . Descriptif du composant T INY . . . . . . . . . . . . . . . . . . . . . Le conteneur GraphContainer généré . . . . . . . . . . . . . . . Schéma de fonctionnement du gestionnaire . . . . . . . . . . . . . . Le gestionnaire de composants . . . . . . . . . . . . . . . . . . . . . Exemple de mise en relation entre un port et une méthode de la façade Vue physique du processus de connexion . . . . . . . . . . . . . . . . Vue logique (ou électrique) après le processus de connexion . . . . .. . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . .. 111 112 112 114 114 116 116 117 118 118 118 119 120 121 122 124 126 127 127 128 129. x. 80 81.

(12) TABLE DES FIGURES 5.22 5.23 5.24 5.25 5.26 Cl.1 Cl.2. Exemple de descriptif de lancement . . . . . . . . . . . . . . . . . . . . Exemple d’un arbre de l’interface graphique (boot.lml) . . . . . . . . Composants chargés et instances créées avec leurs connexions . . . . . . Exemple de services pour le langage T INY à rajouter à un composant vue Exemple de descriptif de composant . . . . . . . . . . . . . . . . . . . . Les différents modèles de S MART T OOLS et leurs transformations . . . . Relations des différents domaines . . . . . . . . . . . . . . . . . . . . .. xi. . . . . . . .. 130 131 131 132 133 141 143.

(13) TABLE DES FIGURES. xii.

(14) Liste des acronymes. AOP API ARC AST BML BSML CCM CML CORBA CSS DCOM DDML DOM DSL DT4DTD DTD EBNF EJB HTML IDE JAXB MDA MOF MOP MathML OCL OFX OMG OMT. Aspect-Oriented Programming Application Programming Interface Action de Recherche Coopérative Abstract Syntax Tree Bean Markup Language Bioinformatic Sequence Markup Language CORBA Component Model Chemical Markup Language Common Object Request Broker Architecture Cascading Style Sheet Distributed Component Object Model Document Definition Markup Language Document Object Model Domain-Specific Language DataTypes for DTDs Document Type Definition Extensible Backus Naur Form Entreprise JavaBeans Hyper Text Markup Language Integrated Development Environment Java Architecture for XML Binding Model-Driven Architecture Meta-Object Facility Meta-Object Protocol Mathematical Markup Language Object Constraint Language Open Financial eXchange Object Management Group Object Modeling Technique xiii.

(15) Liste des acronymes OOSE PDA PIM PPML PSM QoS RDF RELAX RNTL SAX SGBD SGML SMIL SOAP SOX SVG TREX UML URI VTP W3C WSDL XML XPath XSL XSL-FO XSLT. Object-Oriented Software Engineering Personal Digital Assistant Plateform-Independant Model Pretty Printing Meta Language Platform-Specific Model Quality of Service Resource Description Framework Schema Regular Language Description for XML Réseau National de recherche et d’innovation en Technologies Logicielles Simple API for XML Système de Gestion de Base de Données Standard Generalized Markup Language Synchronized Multimedia Integration Language Simple Object Access Protocol Schema for Object-oriented XML Scalable Vector Graphics Tree Regular Expression for XML Unified Modeling Language Uniform Resource Identifier Virtual Tree Processor World Wide Web Consortium Web-Service Description Language Extensible Markup Language XML Path language Extensible Stylesheet Language XSL Formatting Object XSL Transformation. xiv.

(16) Il était une fois un arbre . . ..

(17)

(18) Introduction Contexte et présentation de la thèse Contribution . . . . . . . . . . . . . Justificatifs de notre démarche . . . Plan du manuscript . . . . . . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. 1 3 5 8. Contexte et présentation de la thèse La qualité du logiciel et sa capacité à évoluer, ainsi que la rapidité du développement, sont des soucis majeurs pour les industriels. Un logiciel bien conçu doit pouvoir s’adapter rapidement aux demandes des clients et aux nouvelles technologies pour pouvoir lutter contre la concurrence. Il doit aussi être capable d’échanger des données très variées avec d’autres applications, particulièrement depuis l’avènement d’Internet. En quelques années, l’informatique confinée aux domaines scientifiques s’est démocratisée. Ses utilisateurs ont maintenant des besoins, des connaissances et des domaines d’activité différents. De plus, la pression du marché impose des temps de développement de logiciel plus courts et des coûts plus faibles. Cette évolution a bouleversé la manière de concevoir et de réaliser les logiciels. Il n’est plus possible de les développer entièrement sauf dans les domaines tels que la défense ou les transports où la surêté de l’ensemble du code doit être vérifiée. Les technologies propriétaires sont à bannir car elles isolent les logiciels et freinent leurs évolutions. Les exigences vis-à-vis des logiciels ont aussi été modifiées à cause des disparités de connaissances des utilisateurs et des programmeurs, des contraintes de temps et de financement, et des nécessités d’adaptation rapide aux besoins du marché. Pour satisfaire ces exigences, les logiciels doivent être : conviviaux grâce à une interface utilisateur interactive ; faciles à utiliser avec peu de compétences informatiques et basés sur des techniques connues ou des standards ; ouverts grâce à un format d’échange de données standard utilisé pour communiquer entre les composants et avec les applications externes ; Afin de les adapter rapidement, leurs développements doivent impérativement s’appuyer sur une implémentation modulaire et flexible, basée sur des composants génériques et réutilisables. 1.

(19) Introduction Pour prendre en compte ces bouleversements, de nouvelles techniques de développement ont émergé. Tout d’abord, il y a eu la programmation par objets avec les notions d’encapsulation et d’héritage propices à la modularité, la réutilisation et l’extensibilité du code. Mais ce style de programmation est apparu insuffisant pour prendre en compte des préoccupations transversales aux classes. Pour pallier ce problème, la programmation dite par aspect (AOP - Aspect-Oriented Programming) a, en particulier, vu le jour permettant de gérer, de manière modulaire, ces préoccupations en les séparant du code de base (separation of concerns) ; la plus connue des implémentations étant AspectJ [2, 55] de Kiczales. Il est ainsi très facile d’étendre le code de base avec de nouvelles fonctionnalités sans le modifier directement (technique non invasive). Cette technique jeune soulève de nombreuses questions : où tisser les aspects ? Comment composer plusieurs aspects ? Quelle technique d’implémentation choisir entre la transformation de programme, la réflexivité ou la génération de code adapté ? L’approche objet a aussi une granularité très fine, peu adaptée aux systèmes complexes. Le concept de composant [63, 80] a été introduit afin d’encapsuler plusieurs objets proposant des services et de pouvoir facilement y associer du code non-fonctionnel tel que la communication entre composants, la persistance ou une politique de sécurité. Avec cette approche par composants, il est facile de déployer et même de répartir une application. Il est aussi possible de construire une application uniquement par assemblage de composants, ce qui devrait réduire les coûts et les temps de développement. Quatre principaux modèles de composants ont émergé : les EJBs (Entreprise JavaBeans) [79] de Sun, CCM (CORBA Component Model) [69] de l’OMG (Object Management Group), DCOM (Distributed Component Object Model) et .NET de Microsoft, et les Web Services du W3C (World Wide Web Consortium). Avec l’avènement des Web Services, cette possibilité de création d’applications par assemblage de composants attire de nombreux industriels. Mais il reste encore de nombreuses interrogations : comment faire communiquer des composants de modèles différents ? Comment découvrir les composants ayant les services et la qualité de service (QoS) souhaités ? Quelle sécurité adopter pour les transactions ? Avec l’effervescence liée à la naissance du Web, il y a eu une volonté de standardiser les langages et protocoles, ce qui a conduit à la création du W3C [10]. Ce consortium a proposé un nouveau format de données, XML (Extensible Markup Language), issu de SGML (Standard Generalized Markup Language) afin de simplifier et d’uniformiser les échanges d’informations entre applications, indépendamment de tout langage et plate-forme. Ce consortium a ensuite élaboré des spécifications7 de langages, de protocoles et d’APIs (Application Programming Interface) tels que le langage XSLT (Extensible Stylesheet Language Transformation) pour effectuer des transformations, le protocole SOAP (Simple Object Access Protocol) pour échanger des messages ou l’API DOM (Document Object Model) pour manipuler les documents sous forme d’arbres. Utiliser des technologies standardisées et pour lesquelles il existe de nombreux outils simplifie le développement, l’évolution et rend les applications ouvertes. 7 Les spécifications du W3C (XML et DTD, DOM, XSL et XSLT, XML Schema, BML, MathML, SVG, XPath, XHTML, SOAP, WSDL, etc.) sont accessibles sur le site http://www.w3c.org.. 2.

(20) Introduction Ces bouleversements ont aussi été pris en compte au niveau des spécifications des logiciels, avec l’apparition de nouvelles méthodes d’analyse et de conception à base de modèles et à production de code. La plus célèbre et récente de ces méthodes de modélisation de systèmes à objets est UML (Unified Modeling Language) [70] de l’OMG qui réunit et unifie les notations et les sémantiques des méthodes Booch de Grady Booch, OMT (Object Modeling Technique) de Jim Rumbaugh et OOSE (Object-Oriented Software Engineering) de Ivar Jacobson. Avec ce langage graphique, les différentes dimensions d’un logiciel complexe peuvent être spécifiées, assemblées, visualisées et documentées. Ces différentes modélisations sont ensuite utilisées pour générer automatiquement la trame du code du logiciel cible. Récemment, l’OMG a introduit une nouvelle approche d’écriture de spécifications et de développement d’applications, nommée MDA8 (Model-Driven Architecture) [28, 42, 82]. Cette approche prône l’utilisation de modèles indépendants de toute plate-forme et technologie (PIM - Plateform-Independant Model) qui sont ensuite transformés vers un ou plusieurs modèles de plate-forme spécifique (PSM - Platform-Specific Model). La partie métier (PIM) est ainsi séparée de la partie technologie cible (PSM) et le passage du PIM vers un ou plusieurs PSMs s’effectue par des règles de transformation. Cette approche par abstraction permet de mieux se concentrer sur la partie «intelligente» et la rend pérenne car utilisable avec les technologies futures.. Contribution Un changement radical des méthodologies de conception et de développement d’application est nécessaire pour aisément prendre en compte ces nouvelles approches de développement telles que la programmation par aspects, les composants et la stratégie de développement MDA. Cette thèse jette les bases d’une nouvelle manière de programmer où ces approches sont automatiquement intégrées aux spécifications (modèles abstraits) de l’application lors de phases de génération de code source [34]. Cette idée a été appliquée, à différents niveaux, lors de la réalisation d’un générateur d’outils nommé S MART T OOLS, aussi bien pour la représentation de données ou d’environnements interactifs que pour les traitements sémantiques ou l’architecture (voir figure 1). Cette thèse défend cette idée et montre, de manière pragmatique, les apports de ces différentes approches et comment les combiner. Nos objectifs avec cet outil s’inscrivent parfaitement dans cette nouvelle problématique, aussi bien pour sa réalisation que pour les environnements qu’il produit ; son but étant d’aider à la création d’outils tels que des éditeurs, des afficheurs (pretty-printers), des analyseurs syntaxiques (parsers) ou des traitements sémantiques (analyses, transformations) pour les langages de programmation ou métiers (DSL - Domain-Specific Language). Plus précisément, à partir d’une description d’un langage ou modèle de données (DTD ou XML Schema), il génère un environnement minimal doté d’un éditeur guidé par la syntaxe, d’un ensemble de fichiers Java facilitant l’écriture de traitements sémantiques, d’afficheurs génériques et d’un analyseur syntaxique XML ayant les fonctions de construction d’arbres de ce langage. Cet 8 Des informations de cette approche sont disponibles http://www.sciences.univ-nantes.fr/info/lrsg/Recherche/mda/. 3. à. http://www.omg.org/mda. ou.

(21) Introduction environnement peut, ensuite, être enrichi par d’autres outils. Modèle d'analyse sémantique. Modèle de données. Modèle de vue/GUI. Modèle de composant. PIM Générateurs de SmartTools API de manipulation d'arbres. PSM. DTD ou XML Schema. Glue des Composants. Afficheurs. Editeur structuré. Spécifications d'un parseur Visiteur par défaut + AOP. F IG . 1 – Vue fonctionnelle de S MART T OOLS : les modèles associés à un langage, les générateurs, et les outils générés à partir des modèles Du point de vue d’un utilisateur de l’outil, l’originalité et l’innovation de notre approche peuvent se synthétiser en trois points : 1. Fournir une interface utilisateur construite à partir d’un modèle. L’innovation de notre approche consiste à traiter tous les aspects d’affichage, y compris l’interface utilisateur, selon le même modèle. Il se dégage ainsi une approche homogène et uniforme, ayant un fort potentiel de réutilisation tant pour S MART T OOLS que pour les outils produits. Un autre avantage important est que les techniques utilisées permettent d’exporter (adapter) les vues graphiques vers d’autres supports dont le Web (navigateurs). 2. Accepter et utiliser des formats non propriétaires définis par le W3C et profiter ainsi des nombreux développements réalisés autour de XML. De cette manière, le coût et le temps de développement de l’outil peuvent être fortement réduits. Notre innovation consiste à proposer des traitements sémantiques sur des documents XML, en utilisant une méthodologie de programmation basée sur le patron de conception visiteur (visitor design pattern) [40, 71, 72], issu de la programmation par objets. 3. Proposer une programmation par aspects [24, 53, 55] spécialisée au-dessus de la technique des visiteurs ne requérant pas de transformation de code. Cette programmation spécialisée aux visiteurs (points de jonction fixes) et dynamique a l’intérêt d’être beaucoup plus simple dans sa mise en œuvre que les approches plus classiques et généralistes [59]. Mais surtout, elle aura certainement un grand intérêt dans le cadre d’applications Web pour traiter les problèmes de reconfiguration, d’adaptation, et de sécurité des composants. Pour assurer l’évolution de l’outil, nous avons choisi, lors de la mise en œuvre, une architecture logicielle modulaire [21] (avec des composants indépendants) et extensible. 4.

(22) Introduction Ainsi, il est facile d’ajouter de nouvelles fonctionnalités (importation de nouveaux composants) ou de partager notre savoir-faire (exportation de nos composants) avec d’autres plates-formes. De plus, pour pouvoir immédiatement tester toutes les techniques proposées, il nous est paru essentiel d’auto-utiliser l’outil pour le développer. Ainsi, tous nos langages internes ont été développés grâce à l’outil. Par ailleurs, chaque environnement produit réutilise les composants génériques existants.. Justificatifs de notre démarche Sur chaque point important énoncé ci-dessus, nous allons expliquer notre démarche et justifier en quoi elle est originale et différente par rapport aux travaux existants.. Édition structurée et environnement interactif Dans le domaine des éditeurs structurés [23, 56, 77], les langages métiers définis à l’aide des formalismes XML sont certainement de meilleurs candidats que les langages dits de programmation, où les éditeurs professionnels et spécialisés (Eclipse, Sun ONE anciennement Forte, Visual StudioTM , JBuilderTM , Visual AgeTM , etc) sont des concurrents manifestes à l’approche générique. Mais il est important, même pour ces langages métiers [87] beaucoup moins exigeants en terme d’édition libre (possibilité d’écrire du code à la volée), de proposer des outils d’affichage ouverts et extensibles à de nouvelles bibliothèques de composants graphiques telle que la bibliothèque Swing. Nous allons montrer qu’il est relativement simple de construire au-dessus de l’outil de transformation XSLT, un mécanisme d’affichage de vues avec les contraintes particulières liées à l’édition structurée. Cette approche (avec BML - Bean Markup Language) rend aussi l’exportation aisée des vues graphiques à travers le réseau. Le mélange de diverses familles technologiques – la bibliothèque Swing pour le graphisme, l’outil XSLT pour les transformations, BML pour la sérialisation et CSS (Cascading Style Sheet) pour l’application de styles – apporte une solution efficace à faible coût de développement et de maintenance. Développer nos propres algorithmes de placement d’objets graphiques, langages de transformation et moteurs nous aurait demandé beaucoup d’énergie et de temps pour un résultat qui, bien que peut-être plus efficace (car conçus pour et non adaptés), aurait été non évolutif et non ouvert. Notre solution profite ainsi des avantages de chaque technologie et surtout de leurs futures évolutions. L’utilisation des technologies XML est un atout indéniable de notre approche.. Passerelle vers les formalismes DTD et XML Schema Adopter des formats de données standardisés facilite l’échange d’informations entre logiciels. Le W3C donne la possibilité aux concepteurs de décrire les structures de données échangées en utilisant les formalismes DTD (Document Type Definition) ou XML Schema. Ainsi ils définissent des langages dits métiers (par opposition aux langages de programmation) très variés et liés à un domaine d’application : télécommunications, mais aussi finance, assurances, transports, etc. Les techniques liées aux langages de programmation peuvent 5.

(23) Introduction être employées pour les langages métiers, d’autant plus que ces derniers ont souvent une syntaxe et une sémantique plus simples. Mais les concepteurs et les utilisateurs de langages métiers n’ont pas forcément de compétences approfondies sur les techniques issues de la programmation (analyse, compilation, interprétation, etc). Il y a donc un besoin d’outils pour faciliter l’utilisation de ces techniques. De plus, de telles applications (liées à l’Internet) nécessitent un développement rapide, des possibilités d’intégration, une utilisation facile et un affichage multi-supports tel que l’écran d’un PDA (Personal Digital Assistant), d’un téléphone mobile, un éditeur de texte ou un navigateur Internet. Nos efforts pour accepter les formalismes du W3C sont certes motivés par notre souci d’élargir le champ d’applications de S MART T OOLS mais aussi par notre volonté de faciliter son utilisation. De cette manière, les utilisateurs ne sont pas contraints d’apprendre nos langages internes. L’outil accepte, en entrée, aussi bien notre propre langage de définition d’AST (Abstract Syntax Tree) qu’une DTD et bientôt un XML Schema. L’intérêt est de proposer pour ce type d’applications (langages) nos outils d’édition, d’affichage et/ou de description sémantique. Notre approche de génération automatique du couple analyseur syntaxique et afficheur semble envisageable pour des langages métiers simples. Elle serait certainement trop complexe pour des langages de programmation. Cette génération devrait rendre de grands services dans ce contexte de petits langages métiers. En suivant la même approche, établir une passerelle vers le méta-langage d’UML, le MOF (Meta Object Facility), semble aussi naturel [22].. Outils sémantiques Le succès grandissant de la notion de patrons de conception [40] montre que les concepts de programmation par objets ne sont pas suffisants et que chaque type d’application ou problématique demande des solutions appropriées [46, 67]. En particulier, le patron visiteur, base de nos outils sémantiques, a suscité un ensemble de travaux de recherche [72], qui ont tous comme objectif de trouver le meilleur compromis entre la lisibilité et l’efficacité. L’un des autres soucis de ce patron est la composition de visiteurs [57]. Certaines similitudes sur cette problématique avaient déjà été remarquées dans [29] mais pour des familles de technologies différentes (grammaires attribuées [45, 78], programmation polytypique [48], et programmation adaptative [59, 73]). La programmation adaptative suit cette même problématique de séparation des concepts (parcours et sémantique). La programmation par aspects [53] a aussi été introduite pour la séparation des parties fonctionnelle et non-fonctionnelle (applicative ou de services) d’une application. Les approches par transformation de programme utilisées pour la programmation par aspects ont montré leurs limites [24]. Il est clair qu’il existe des liens très forts avec les travaux de recherche sur la réflexivité [60, 61] pour les langages à objets, en particulier la notion de MOP (Meta-Object Protocol) [54]. Les mécanismes mis en jeu dans ces approches totalement dynamiques ne sont pas simples d’utilisation. Ils demandent de comprendre la sémantique sous-jacente des langages à objet. L’originalité de notre approche est de partir d’une spécification déclarative de la structure des objets et d’effectuer une génération de code source des visiteurs enrichie par les mécanismes de programmation par aspects ou adaptative. L’intérêt est d’une part d’éviter 6.

(24) Introduction les problèmes d’efficacité par cette génération et de cacher à l’utilisateur la complexité des mécanismes mis en jeu. De plus, notre approche de programmation par aspects, adaptée à nos besoins, a le mérite d’être d’une mise en œuvre très simple, par une extension naturelle du patron de conception visiteur. Avec tous ces mécanismes «cachés», une analyse peut, très facilement, être étendue, soit par héritage, soit par l’ajout d’aspects.. Architecture à composants Pour l’architecture de notre logiciel, nous avons préféré suivre une approche comparable à MDA en concevant notre propre modèle abstrait de composants, dédié à nos besoins (métier) et projetable vers des modèles spécifiques concrets. Les raisons d’un tel choix sont les suivantes : – la difficulté de choisir une technologie de composants pérenne et adaptée à notre métier ; – l’identification claire des besoins en définissant ce modèle indépendamment de toute technologie. Avec cette approche, les besoins spécifiques sont clairement identifiés. Alors qu’une utilisation directe d’un modèle existant, non adapté à nos besoins, aurait caché les spécificités de nos composants. Lors de la phase de projection de notre modèle vers CCM, EJB ou les Web Services, nous nous sommes aussi aperçus que certains de nos besoins, dont l’extensibilité de services des composants, auraient difficilement été exprimables. De plus, grâce à cette technique de projection, il est très facile, par définition de nouvelles règles de transformation, d’exporter nos composants vers une plate-forme ayant un nouveau modèle de composant. Une architecture par composants pour un tel outil (à génération de code) est nécessaire afin d’établir une nette séparation entre le code du noyau, des outils génériques et des langages. De cette façon, seuls les composants utiles à l’application peuvent être chargés en mémoire. Cette modularité est aussi souhaitable pour, aisément, exporter ou importer des composants.. Le lien conducteur de cette thèse est la programmation générative qui fédère toutes ces technologies hétéroclites, simplifie leur usage et facilite les évolutions. Cette génération, à partir de modèles, correspond à un sous-ensemble de l’approche MDA. Depuis trois ans, S MART T OOLS est développé de manière incrémentale et a fortement évolué passant d’une version proche de Centaur [23, 81] (version 1) avec AÏOLI [84] et FIGUE [85] (pour respectivement VTP - Virtual Tree Processor - et PPML - Pretty Printing Meta Language), à une version ouverte basée sur des techniques non-propriétaires et sur les technologies XML, et donc n’ayant plus rien de commun avec Centaur. Comme l’outil est en perpétuelle évolution (développement en cours de la version 4), certains aspects énoncés dans ce manuscrit pourraient être erronés lors de la diffusion de cette version. De plus, certaines de nos expériences (visiteurs génériques) effectuées en version 3 et certains langages n’ont pas encore été portés dans la version 4. 7.

(25) Introduction. Plan du manuscript Chapitre 1 : Présentation générale de S MART T OOLS (page 11) Ce chapitre donne une vue d’ensemble de l’outil [31, 74], cible de nos expérimentations. Cette vue permet d’appréhender les besoins et rouages de l’outil mais aussi son évolution puisque cette présentation date d’un an et demi (version 3). Elle montre comment l’approche par génération de code et l’usage de technologies standardisées avantagent le développement et l’évolution d’un tel logiciel. Chapitre 2 : Présentation des technologies XML (page 33) Ce chapitre présente diverses technologies XML telles que XML, DTD et XML Schema, XSLT et XPath, BML, et CSS. Son objectif est de fournir aux néophytes un aperçu rapide de leurs possibilités pour mieux comprendre les choix réalisés dans S MART T OOLS. Il est indépendant de tout chapitre et donc sa lecture peut être effectuée dans n’importe quel ordre ou même omise par les personnes connaissant ces technologies. Chapitre 3 : Outils syntaxiques (page 53) Ce chapitre explique pourquoi nous avons créé notre propre formalisme de définition de langage, nommé A B S YNT, et présente ses notions de base. C’est le cœur du système sur lequel reposent tous les autres outils. Comme S MART T OOLS est adapté aux langages métiers, nous établissons ou avons établi des passerelles avec leurs langages de définition, DTD et XML Schema. Ainsi l’outil est ouvert et ses utilisateurs ne sont pas contraints à apprendre notre format interne. Ce chapitre présente aussi comment spécifier des afficheurs avec notre langage de syntaxe concrète, nommé C O S YNT, ou directement avec XSLT et générer les analyseurs syntaxiques associés. Chapitre 4 : Outils sémantiques : visiteurs et aspects (page 83) Ce chapitre présente différentes manières [32] d’implémenter des analyses sémantiques lisibles et facilement extensibles, ayant comme point de départ le patron de conception visiteur. Il est ainsi possible de configurer le parcours et les signatures des méthodes visit (évitant les coercitions de type) et de les enrichir, à l’exécution, d’aspects. Une des techniques très prometteuses découple même le parcours du code de l’analyse sémantique permettant la composition d’analyses. Ce chapitre évoque également comment des visiteurs génériques, indépendants de tout langage, pourraient être réalisés. Chapitre 5 : Architecture par composants (page 107) Ce chapitre explique pourquoi nous avons préféré créer notre propre modèle de composants plutôt qu’en utiliser un existant tel que CORBA ou EJB. Ce modèle est décrit [30] ainsi que les principaux composants de l’outil et sa mise en œuvre. Les avantages principaux de nos composants sont leur adéquation aux besoins, leur extensibilité de services, et leur capacité à être exportés vers d’autres technologies [89]. Conclusion (page 137) En conclusion, nous présentons les champs possibles d’application d’un tel outil et 8.

(26) Introduction montrons comment l’approche MDA est utilisée, à différents niveaux, dans S MARTT OOLS et dans les environnements produits. Annexe A : S MART T OOLS mini-HowTo (page 147) Ce mini-tutorial présente brièvement S MART T OOLS puis explique comment l’installer et l’exécuter. Annexe B : Exemple de visiteurs (page 149) Cette annexe donne, pour comparer, les exemples d’un visiteur configuré et d’un visiteur découplé de la même analyse sémantique : la vérification de type du langage T INY.. L’outil S MART TOOLS est le fruit du travail d’une équipe soudée, composée principalement de Didier Parigot (chargé de recherche à l’INRIA Sophia-Antipolis), d’Alexandre Fau, de Pascal Degenne (ingénieurs experts à l’INRIA puis au W3C), et de moi-même. Les travaux de cette thèse ont été effectués en étroite collaboration avec ces personnes. Toutes les idées présentées dans ce manuscrit sont issues de nos séances de «tempêtes de cerveaux» stimulantes et ont été validées par leur utilisation dans l’outil.. 9.

(27) Introduction. 10.

(28) Chapitre 1. Présentation générale de S MART T OOLS 1.1 1.2 1.3 1.4 1.5. Syntaxe abstraite et outils . . Traitements sémantiques . . L’architecture de SmartTools Environnement interactif . . Applications . . . . . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. 12 17 21 24 29. Introduction Ce chapitre permet d’avoir une vue d’ensemble de S MART T OOLS. Il introduit brièvement tous les concepts utilisés pour sa construction et son utilisation. Tous ces concepts seront ensuite développés et actualisés dans les chapitres suivants. En effet, nous avons préféré baser ce chapitre, contrairement aux autres, sur la version précédente (version 3) afin de montrer l’évolution de conception de l’outil et à cause de la difficulté que nous aurions rencontrée à rédiger une présentation générale de la version en cours de développement. Ce chapitre se décompose en cinq sections. La première section introduit les formalismes de base (syntaxe abstraite), les liens avec les formalismes équivalents du W3C et les outils associés (éditeur structuré). La deuxième section présente les outils pour la programmation des traitements sémantiques comme la programmation par visiteur ou la programmation par aspects. La troisième section donne un aperçu de l’architecture du système organisée autour d’un bus logiciel (contrôleur de message). La quatrième section décrit notre approche uniforme pour la conception et la réalisation des interfaces graphiques et de l’interface utilisateur de S MART T OOLS. Enfin la cinquième présente quelques applications de notre outil. C HANGEMENTS DANS LA VERSION 4 Les principales différences entre la version 3 et la version 4 portent essentiellement sur l’architecture du système, les informations de présentation des. 11.

(29) 1.1 Syntaxe abstraite et outils vues graphiques et la définition de la structure d’un arbre de syntaxe abstraite. Les modifications suivantes ont pour but de rendre l’outil et les environnements produits plus ouverts, flexibles et proches des technologies XML : – L’architecture n’est plus centrée autour du bus logiciel (décrit dans le paragraphe 1.3 à la page 21) mais utilise une approche par communication directe entre composants facilitant l’importation et l’exportation de composants. – Les informations de préférences de style des éléments (couleur, positionnement, fonte) composant une vue ne sont plus gérées au niveau de la transformation de l’arbre de syntaxe abstraite en arbre de syntaxe concrète mais directement au niveau de l’arbre de syntaxe concrète en employant CSS (Cascading Style Sheet). Cette séparation entre le contenu et la présentation rend les vues ajustables sur mesure par l’utilisateur final de l’outil. – La définition de structure des arbres a été enrichie des notions de fils optionnels ou tableaux afin d’être en meilleure adéquation avec les documents XML traités. Des remarques en fin de paragraphe résument les éventuelles différences pour actualiser ce chapitre et les phrases inconsistantes ont été mises au passé.. 1.1 Syntaxe abstraite et outils Tous les outils de S MART T OOLS sont basés sur la notion de syntaxe abstraite étendue et fortement typée (AST - Abstract Syntax Tree) que nous allons définir dans cette section. Cette notion de syntaxe abstraite est bien connue et est couramment utilisée dans de nombreux générateurs d’environnements ou de compilateurs [23, 49, 56]. Cette section décrit le langage de définition d’AST, l’implémentation des arbres manipulés, les passerelles réalisées pour importer d’autres formats de définition d’AST et enfin les différents outils générés.. 1.1.1 Langage de définition de syntaxe abstraite Les concepts importants de la définition d’une syntaxe abstraite sont les constructeurs (opérateurs) et les types. Les constructeurs sont regroupés dans des ensembles nommés : les types. Les fils (paramètres) des constructeurs sont typés. La partie gauche de la figure1.1 montre la définition incomplète de notre langage jouet : T INY 1 . Par exemple, le constructeur assign est de type Statement et possède deux fils : le premier de type Var et le second de type Exp. Il existait trois catégories de constructeurs : – atomique sans fils ou feuille (par exemple var) ; – d’arité fixe (assign) ; – d’arité variable (liste) à type fixe (statements) . Il est aussi possible de déclarer des informations associées aux constructeurs sous forme d’annotations typées plus communément appelées attributs. Par exemple, des sucres syn1. Langage utilisé comme fil d’Ariane au cours de ce manuscrit.. 12.

(30) Chapitre 1. Présentation générale de S MART TOOLS. Formalism of tiny is Root is %Top; Top = program(Decls declarations, Statements statements); Decls = decls(Decl[] declarationList); Statements = statements(Statement[] statementList); Statement = assign(Var variable, Exp value), while(ConditionExp cond, Statements statements), if(ConditionExp cond, Statements statementsThen, Statements statementsElse); Var = var as STRING; Exp = %ArithmeticOp, var, int as STRING, true(), false(); ... End. <!ENTITY <!ENTITY <!ENTITY <!ENTITY <!ENTITY <!ENTITY. % % % % % %. Top ’program’> Decls ’decls’> Statements ’statements’> Statement ’if|while|assign’> Var ’var’> Exp ’false|int|var|true| %ArithmeticOp;’>. <!ELEMENT program <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT. <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT .... (%Decls;, %Statements;)> decls (%Decl;)*> statements (%Statement;)*> assign (%Var;, %Exp;)> while (%ConditionExp;, %Statements;)> if (%ConditionExp;, %Statements;, %Statements;)> var (#PCDATA)> int (#PCDATA)> true EMPTY> false EMPTY>. F IG . 1.1: Une partie de la définition d’AST de notre langage jouet T INY avec notre langage interne (à gauche) et son équivalence en DTD (à droite) taxiques (figure 1.2 pour le constructeur assign) pouvaient être spécifiés sous forme d’attributs pour la génération d’analyseurs syntaxiques et d’afficheurs associé. assign(Var variable, Exp value) with attributes { fixed String separator1 = "=", fixed String afterOp = ";", fixed String styleS1 = "kw" }. <!ELEMENT assign (%Var;, %Exp;)> <!ATTLIST assign separator1 CDATA #FIXED ’=’ afterOp CDATA #FIXED ’;’ styleS1 CDATA #FIXED ’kw’ >. F IG . 1.2: Définition du constructeur assign avec les sucres syntaxiques utiles à la génération d’un analyseur syntaxique et de l’afficheur associé ; à gauche avec notre langage interne et à droite en DTD C HANGEMENTS DANS LA VERSION 4 Afin d’accepter un plus large éventail de définitions de langages ou de documents, les notions de fils optionnel et de fils tableau ont été rajoutées en version 4. Ce changement était nécessaire pour être plus proche des structures des documents XML et perdre moins d’informations de typage. Ainsi, il est maintenant possible d’écrire op(A[] aList, B? bSon, C cSon, D? dSon) qui indique que le premier fils du constructeur op est un tableau de A, le deuxième optionnel de type B, le troisième obligatoire de type C et le quatrième optionnel de type D. La contrainte de cette catégorie de constructeurs est que les types des fils optionnels ou tableaux placés devant un fils requis soient disjoints entre eux et aussi disjoints avec le type du fils requis. Dans , et et il notre exemple, il est impératif d’avoir. 13.

(31) 1.1 Syntaxe abstraite et outils est possible d’avoir . Cette contrainte est nécessaire afin de savoir à quel fils affecter un nœud. Un tel constructeur, en version 3, aurait été spécifié op(T[] tList) avec T = %A, %B, %C, %D, ce qui aurait impliqué une granularité de typage de l’arbre moins fine. La catégorie des constructeurs de liste a ainsi disparu puisqu’elle se trouve incluse, par construction, dans cette nouvelle catégorie de constructeurs à arité de type (fils) fixe et de nœuds variable. Pour augmenter la lisibilité des définitions de structures, les syntaxes abstraite et concrète de ce langage (renommé A B S YNT au lieu d’AST, nom qui prêtait à confusion) ont aussi été légèrement modifiées. Une définition se décompose maintenant en trois parties : la première contenant les informations de typage, la deuxième les attributs (avec factorisation possible d’un attribut sur plusieurs constructeurs) et la troisième des informations supplémentaires utiles pour les calculs sémantiques mais non incluses dans les documents XML. Afin de ne plus «polluer» les documents XML d’attributs réservés à la génération d’afficheurs et d’analyseurs syntaxiques, un nouveau langage, nommé C O S YNT, (voir section 3.4 page 75) a été défini. Ainsi toutes les informations relatives à une syntaxe concrète d’un langage (sauf les informations de style gérées dans un fichier CSS) sont maintenant stockées dans un document C O S YNT et non dans la définition A B S YNT du langage.. 1.1.2 Implémentation au-dessus de l’API DOM Nous souhaitons utiliser le plus possible les composants logiciels existants issus des standards du W3C, comme par exemple l’API DOM (Document Object Model) de manipulation d’arbres XML. Cette API manipule des nœuds de type uniforme org.w3c.dom.Node. Mais l’utilisation du patron visiteur (cf. paragraphe 1.2.1 page 18) nécessite une structure fortement typée. Dans notre cas, cela signifie que le type de chaque nœud dépend du constructeur auquel il est associé. Nous avons étendu et complété cette API afin de travailler sur des arbres fortement typés. Par exemple, un nœud assign sera une instance de la classe tiny.ast.AssignNodeImpl qui étend la classe de base org.w3c.dom.Node comme le montre la figure 1.3. L’avantage de construire un arbre typé est que sa cohérence est garantie par le vérificateur de types de Java. Les classes (AssignNodeImpl, etc.) sont automatiquement générées par S MART T OOLS à partir de la définition d’AST (cf. figure 1.1). Par constructeur, S MART T OOLS génère une classe et une interface (la figure 1.4 montre l’interface générée pour le constructeur assign) et une interface par type ; celle-ci est implémentée par tous les constructeurs qui sont inclus dans ce type. Chaque classe Java décrivant un constructeur étend une implémentation de DOM. Ces classes contiennent les méthodes d’accès (par exemple, getVariableNode) et de modification (setVariableNode) des fils et des annotations (getSeparator1Attr). Le nommage des fils des constructeurs (statementList pour le constructeur statements) est utilisé pour la génération des noms des accesseurs (dans ce cas setStatementListNode et getStatementListNode). Dans la version 2 de l’API DOM, les attributs ne peuvent être que de type String. Comme il est parfois nécessaire lors d’un calcul de conserver des objets de type plus complexe dans les nœuds, nous avions ajouté la possibilité d’avoir des attributs de type autre 14.

(32) Chapitre 1. Présentation générale de S MART TOOLS. DOM. org.w3c.dom.Node. org.apache.xerces.dom.NodeImpl org.w3c.dom.Element org.apache.xerces.dom.ElementImpl. SmartTools. fr.smarttools.tree.UntypedNode. fr.smarttools.tree.FixedNode. fr.smarttools.tree.UntypedNodeImpl. fr.smarttools.tree.FixedNodeImpl. tiny tiny.ast.StatementType. tiny.ast.AssignNode. tiny.ast.AssignNodeImpl +getVariableNode(): tiny.ast.VarType +setVariableNode(tree:tiny.ast.VarType): void +getValueNode(): tiny.ast.ExpType +setValueNode(tree:tiny.ast.ExpType): void. F IG . 1.3: Schéma du graphe d’héritage du constructeur assign package tiny.ast; public interface AssignNode extends EVERYType, StatementType public tiny.ast.VarType getVariableNode(); public void setVariableNode(tiny.ast.VarType node); public tiny.ast.ExpType getValueNode(); public void setValueNode(exp.ast.ExpType node);. {. // Attributes for assign operator public java.lang.String getSeparator1Attr(); public java.lang.String getAfterOpAttr(); public java.lang.String getStyleS1(); }. F IG . 1.4: Interface AssignNode générée que String mais ils étaient volatiles. Ils n’apparaissaient pas dans le format XML du document (programme) et étaient perdus lors de la sauvegarde (serialisation). Donc les attributs étaient soit de type String à valeur constante, obligatoire ou optionnelle, soit de type quelconque mais volatiles (c’étaient des attributs de travail seulement utiles pour des calculs sémantiques). Cette couche au-dessus de DOM est compatible avec l’utilisation de tous les outils liés aux technologies XML comme les moteurs de transformation XSLT ou le mécanisme de références des chemins XPath (XML Path language) ; elle peut aussi utiliser les services proposés par l’API DOM dont la représentation de l’arbre au format XML. Cette couche permet d’obtenir les informations contenues dans la définition d’AST (type du constructeur attendu, arité du constructeur, etc.), d’ajouter la notion de numéro de fils, de maintenir la cohérence de l’arbre s’il est modifié et de gérer des attributs volatiles 15.

(33) 1.1 Syntaxe abstraite et outils de type complexe. Les classes des constructeurs n’héritent pas directement de DOM mais d’une des trois classes faiblement typées regroupant les informations communes à la catégorie du constructeur (feuille, liste ou variable à types différents). Avec ce typage faible, il est possible de décrire des traitements génériques (par exemple, pour construire une représentation graphique de l’arbre) qui ne reposent que sur la catégorie des constructeurs (voir paragraphe 4.4 page 104).. 1.1.3 Passerelles pour importer d’autres formalismes (DTD, XML Schema) Il est important que les concepteurs de langages puissent définir leurs langages (définition d’AST) en utilisant directement les formats proposés par le W3C (DTD, XML Schema) et pas nécessairement le format propriétaire de S MART T OOLS. Le principal problème rencontré lors de la réalisation de l’application d’importation de DTD a été d’inférer les types nécessaires aux outils sémantiques de S MART T OOLS. En effet, il n’existe pas explicitement de notion de type (ensemble d’éléments) dans une DTD. Avec la notion d’entité paramétrée, il est possible de définir un groupement d’éléments mais seulement à des fins de factorisation. Dans une première approche, on peut supposer que les parties droites des définitions d’éléments ne soient composées que par des références à des entités paramétrées. Par exemple, seule la première de ces deux définitions d’éléments est acceptée : <!ELEMENT while ((%ConditionExp;), (%Statements;))>) <!ELEMENT while ((true|false|var|equal|notEqual), (statements))>. Les éléments (<!ELEMENT while ...) sont vus comme des définitions de constructeur et leurs parties droites ne devraient être composées que de références vers des entités paramétrées (%ConditionExp;) pour indiquer le type de leurs fils. Afin de traiter le plus de DTDs possibles, il est nécessaire de définir un algorithme d’inférence de type. Par exemple pour la deuxième définition, on infère un type qui regroupe l’ensemble des éléments qui définissent une expression conditionnelle (comme l’entité %ConditionExp;). Pour les XML Schema, la notion de type est explicitement présente, mais il existe des mécanismes d’extension ou de restrictions (de type) que nous devons prendre en compte lors de la traduction des XML Schema vers notre formalisme.. 1.1.4 Outils générés Le format XML d’un langage est essentiellement un format d’échange de données entre applications, pas vraiment adapté pour l’édition et la manipulation directes. Pour contourner ce problème, le concepteur peut définir une «vraie» syntaxe concrète à son langage (voir la figure 1.5), donc écrire un analyseur syntaxique et l’afficheur associé. Mais cette tâche demande des compétences en techniques d’analyse syntaxique. Dans les cas simples (syntaxe non ambiguë, sans notion de priorité des constructeurs arithmétiques), cette tâche pouvait être automatisée. Le concepteur devait juste indiquer en supplément dans la définition d’AST les expressions régulières et les sucres syntaxiques (cf. figure 1.2 attributs afterOp et separator1) enrobant les constructeurs. Avec ces informations (ajoutées aux constructeurs), notre outil pouvait produire la spécification d’un analyseur syntaxique 16.