Remerciez-le!

Remerciez @Admin pour avoir partagé cet document gratuitement, de la manière la plus simple, en partageant sur les réseaux sociaux.

M.C.S.E 133 5 Le Méta-Générateur MetaGen Après avoir défini les règles de trans

M.C.S.E 133 5 Le Méta-Générateur MetaGen Après avoir défini les règles de transcription, il s’agit de les implanter dans un générateur de code. Le rôle de ce générateur de code est de transcrire la description textuelle du modèle de performance d’un système en un programme VHDL conformément aux règles de transcription décrites dans le chapitre 4. La description textuelle d’entrée et celle de sortie du générateur à développer sont conformes à une grammaire. Elles respectent une syntaxe et une sémantique données. Développer un outil pour effectuer cette transformation n’est pas une tâche facile. L’effort est encore plus important quand la génération de code inclut également une phase de synthèse logicielle ou matérielle. On se limitera dans ce document uniquement à la génération de code, ce qui signifie que l’outil de génération à développer n’est pas capable de choisir une solution d’implantation de lui-même. Si plusieurs alternatives possibles existent, la solution retenue sera spécifiée dans le modèle source ou via l’interface utilisateur de l’outil. Pour cet objectif, l’effort de développement est fortement dépendant de la syntaxe et la sémantique des langages source et cible et de la complexité des règles de transformation. Dans le passé, l’équipe MCSE a déjà développé trois types de générateurs de code pour le modèle fonctionnel de MCSE: un générateur de C [CALVEZ-93c], un générateur d’OCCAM [PASQUIER-93], un générateur de VHDL simulable [BAKOWSKI-92] et synthétisable [HELLER-92] [CALVEZ-93d]. Ces générateurs de code écrits en C utilisaient des structures internes spécifiques. Cette solution d’implantation qui dépendait également de l’environnement graphique SunView ou XMOTIF pour l’interface utilisateur s’est vite révélée pénalisante. Elle n’était pas portable. Elle ne facilitait pas la maintenance et la mise à jour des générateurs en fonction des modifications de la grammaire de la spécification d’entrée ou de celles des règles de transcription. Afin d’obtenir des outils multi plate-formes et plus faciles à développer, maintenir et enrichir, l’équipe MCSE s’est alors intéressée à la technologie méta-case et en particulier à l’outil GraphTalk pour l’édition de graphes et l’outil LEdit pour la génération de code. Cette Chapitre 5 134 M.C.S.E approche a également été abandonnée. L’explication de cette abandon est donnée en début de chapitre. Mais cette expérience et en particulier le travail effectué sur la génération de code avec LEdit a amené l’équipe MCSE à revoir entièrement sa stratégie de développement des outils dont les générateurs de code comme support pour la méthodologie MCSE. La présentation de la nouvelle philosophie de développement de la plate-forme MCSE montre qu’elle repose sur les concepts d’analyseurs syntaxiques et de méta-structure. Ces deux concepts nous ont permis de développer un principe générique de génération de code présenté dans ce chapitre et exploité pour implanter de nouveaux générateurs de code ayant comme spécification d’entrée le modèle de performance de MCSE décrit dans le chapitre 3. Un analyseur syntaxique est obtenu à partir de la spécification de la grammaire du langage concerné. Si la spécification de la grammaire est enrichie de règles de production, alors elle peut engendrer la structure de données interne image du texte analysé. La structure interne obtenue à partir d’un fichier texte est le coeur des générateurs. Pour que ceux-ci aient une architecture commune, nous avons défini un modèle générique de modèle de structure de données. Après avoir analysé la spécification d’une grammaire, nous présentons dans ce chapitre ce modèle générique appelé par la suite méta-structure ainsi que l’architecture commune des générateurs. Le principe de génération de code qui est ensuite décrit repose également sur le concept de template qui est un fichier contenant toutes les constructions en langage cible nécessaires à la transcription. Pour un générateur donné, le fichier source et un fichier template sont analysés, puis les opérations de manipulation des structures de données résultantes sont exécutées pour réaliser la transcription. Pour avoir un générateur facilement reconfigurable, nous avons décidé de décrire les opérations de manipulation de structures de données dans un langage interprété nommé Script. La syntaxe et les constructions de ce langage dédié à la manipulation de structure de données sont définies. Cette définition sert par la suite à l’interprétation de l’implantation du générateur de code VHDL qui fait l’objet du chapitre 6. Une fois saisi, le Script est interprété ou transcrit en code JAVA par un programme dont l’implantation en Java est décrite à l’aide du modèle statique de la méthode OMT-UML. Ce programme nommé MetaGen est donc un générateur de générateurs de code ou méta- générateur. 5.1 LA TECHNOLOGIE META-CASE De 1993 à 1996, le développement de la plate-forme MCSE a reposé sur l’utilisation d’un méta-outil orienté éditeur de graphes (GRAPHTALK) et d’un méta-outil orienté éditeur syntaxique (LEdit). La mise en oeuvre d’un outil CASHE (Computer Aided Software Hardware Engineering) pour une méthodologie à l’aide de la technologie méta-Case est normalement réduite à la déclaration du formalisme de ses modèles. Les méta-outils permettent, en effet, de se focaliser sur la méthode et la sémantique des modèles plutôt que sur des aspects bas niveau tels que l’intégration d’outils, la gestion d’une base de données et l’environnement graphique. L’outil GraphTalk était séduisant pour au moins 4 raisons. Il est multi plate-formes (PC, UNIX). Il est construit autour d’une base de données orientée objet. Les spécifications des modèles sont saisies graphiquement et l’outil permet d’adopter une démarche incrémentale facilitant le prototypage. La spécification graphique du méta-modèle fournit un bon support pour la documentation et le suivi du développement de l’outil. Le Méta-Générateur MetaGen M.C.S.E 135 Malheureusement, l’utilisation de GraphTalk a révélé progressivement un certain nombre de limitations: - les concepts de méta-modélisation sont trop limités pour décrire complètement le modèle MCSE et il fallait écrire de plus en plus de code C (API C) pour définir des démons et actions sur les objets du méta-modèle. Au fur à mesure de l’implantation, on perdait en efficacité (interprétation des démons) et en facilités de prototypage. - la personnalisation de l’interface utilisateur est très limitée. - il n’y a quasiment plus de maintenance et d’évolubilité des outils GraphTalk et LEdit alors que ceux-ci sont pourtant fortement "buggés". - l’utilisation nécessite de payer un "runtime" par machine. L’utilisation des méta-outils GraphTalk/LEdit a conduit à une impasse. Pour compenser leurs limites, l’équipe devait dépenser de plus en plus d’efforts alors que les résultats ne pouvaient être que médiocres, non propriétaires et sans perspective d’évolution. Cependant, l’expérience de génération de code avec LEdit qui est une encapsulation de Lex&Yacc a permis d’appréhender les concepts des générateurs d’analyseurs syntaxiques et de méta-structure sur lesquels repose entièrement la nouvelle "philosophie" de développement des outils MCSE. Avec l’expérience de la technologie méta-Case, l’équipe a également pris conscience que le succès du développement d’un outil CASHE repose essentiellement sur la généricité et l’évolubilité de la structure des données internes aux outils. Début 1997, l’équipe a donc réfléchi à une autre orientation. 5.2 NOUVELLE STRATEGIE DE DEVELOPPEMENT DES OUTILS Il est usuel de constater que dans la plupart des outils CASHE actuels le couplage de données entre outils est basé sur un échange par fichiers et non sur l’utilisation d’une base de données pour des raisons d’efficacité et d’indépendance. Sur la base de ce constat, l’équipe a donc décidé de développer une nouvelle plate-forme d’outils basée sur un couplage possible entre outils par fichiers. Dans ce contexte, comme le montre la figure 5.1, chaque outil de la plate-forme peut être implanté sous la forme d’une architecture générique basée sur trois fonctions principales: - la fonction Load qui permet de créer la structure de données à partir du fichier texte, - la fonction Save qui est la réciproque de la fonction Load et qui consiste à parcourir la structure de données et à exploiter la grammaire correspondante pour générer un fichier texte, - la fonction Transformations qui est spécifique à l’outil et qui définit les manipulations effectuées sur la structure de donnée chargée. -Figure 5.1- Architecture générique des outils de la plate-forme. Texte en entrée Outil Texte résultat Grammaire définissant la syntaxe du texte en entrée Grammaire du langage cible Structure de données interne Transformations Sauvegarde/ Restitution sur disque Load Save Chapitre 5 136 M.C.S.E Cette approche nécessite de résoudre deux problèmes: - La lecture d’un texte et sa conversion en une structure de données (Load) et l’opération inverse (Save). Pour résoudre ce problème, nous sommes partis du principe que toute structure de données peut être engendrée d’une manière automatique par un analyseur syntaxique enrichi des règles de production de la structure de données. Cet analyseur syntaxique est obtenu par un générateur d’analyseur syntaxique à partir de la spécification de la grammaire (syntaxe d’entrée du texte source) et des règles de production. Pour avoir un principe de création de la structure de données indépendant de la grammaire, nous avons défini pour la spécification des règles de production un modèle de modèle de structure de données ou méta-structure basé sur la composition de trois constructions de noeuds: le record ou ensemble fini d’éléments, l’alternative et la liste. Ce principe est présenté en détail dans le paragraphe 5.4. L’utilisation de cette technique permet de répondre aux critères de généricité et uploads/Ingenierie_Lourd/ chap-5-graph-talk.pdf