MOïRA est une méthode implémentée dans un outil. Son but est d'intégrer de façon optimale le traitement des données textuelles dans une application. Ses points forts  sont les suivants :

•  prise en charge de l'analyse syntaxique par un outil extrêmement performant,
• transformation du texte en une structure de données adaptée aux traitements du langage,
• le développeur ainsi dégagé du travail d'intendance peut se consacrer à la tâche à réelle valeur ajoutée qu'est l'interprétation du texte.

Contenu de cette page :
 

Introduction : les langages aujourd'hui
La démarche MOïRA
De la grammaire à l'arbre abstrait
Petite histoire et références

Voir aussi un diaporama Power Point.

Retour à MOïRA

L'écriture d'une grammaire MOïRA
Questions fréquentes
A propos de YACC

Les langages aujourd'hui

95 % des logiciels scientifiques utilisent des données sous forme d'un texte plus ou moins structuré. Les besoins sont multiples, des plus simples aux plus complexes : configuration d'un logiciel au moyen de phrases du type "clé = valeur", traduction de textes, générateurs de code, calcul formel, analyseur sémantiques de programmes, etc ...

La mise en oeuvre des concepts élaborés durant les années 60-70 en théorie des langages et des automates a donné naissance à la technologie actuelle : spécification du texte au moyen d'une représentation abstraite (la grammaire), à partir de laquelle le programme de reconnaissance (l'analyseur syntaxique) est généré automatiquement au moyen d'un outil (constructeur syntaxique). Les algorithmes utilisés sont depuis longtemps puissants et efficaces.

Cependant, analyser la forme d'un texte ne suffit pas. Cet effort ne se justifie qu'à cause du travail applicatif, ou sémantiqueà mener. Et si  l'analyse syntaxique est un domaine parfaitement formalisé, l'impléméntation de la sémantique est plus disparate.

Dans la pratique la démarche la plus fréquente est d’associer à chaque règle grammaticale des instructions (actions sémantiques) qui seront activées lorsque la règle est reconnue. On parle de "décorer" la grammaire. Voir l'exemple de YACC  fourni en annexe. Pour s'y retrouver, il faut posséder une certaine maîtrise de l'analyse syntaxique, ne serait-ce que pour savoir dans quel ordre les règles grammaticales voire les portions de règles, seront activées. Il faut aussi faire preuve de suffisamment d'adresse pour structurer et séquencer ces instructions en fonction du fonctionnement de l'accessoire un peu mystérieux qu'est l'analyseur syntaxique.

L'originalité de Moïra est de faire totalement abstraction du déroulement de l'analyse syntaxique pour ne fournir au programme applicatif que son résultat : une structure de données reflétant fidèlement la structure du texte, et cependant exploitable par un programme.

L'automate utilisé dans MOïRA est écrit d'après l'algorithme de FLOYD-EVANS. Le langage décrit doit être de classe LALR(1). Cet algorithme constitue le compromis le plus communément admis entre les contraintes de forme d'un langage et la rapidité du traitement.

Pour interpréter un texte, on commence par spécifier sa syntaxe au moyen d'une grammaire écrite au moyen du formalisme B.N.F.  Comme exemple, nous allons écrire un programme capable de calculer des  expressions arithmétiques.

• On écrit sa grammaire :  Calcul.bnf.  Notons que l'on retrouvera le radical de ce fichier (Calcul) dans les éléments générés.
• Puis on lance la commande :

Deux fichiers sont générés :

• Le module C++  CalculLoad.cc qui contient l'analyseur syntaxique. C'est un objet de la classe MoiraLang, objet dédié au langage étudié. La fonction CalculLoad crée l'objet, le configure selon le langage décrit dans la grammaire et fournit son pointeur au programme appelant.
• CalculRules.h qui contient les codes de noeuds associés à chaque règle syntaxique.

Dans ce fichier, exemple d'application on trouve les instructions suivantes  :
 

#include "MoiraLang.h" MoiraLang*  CalculLoad();	Partie déclarative : Include de la classe Moira d'analyse syntaxique Prototype de la fonction de chargement
MoiraLang* ml = CalculLoad();	1er temps : Création du pointeur d'objet ml, à partir de la fonction générée par le constructeur
arbre root = ml->Analyze (ligne);	2éme temps :Analyse syntaxique d'une chaîne de caractères.
double val = calcul_reel(root);	3éme temps : Appel d'une fonction utilisateur d'interprétation. Ici il s'agit de calculer une expression.

En résumé,  la démarche suit le schéma suivant.

Retour au début

MOïRA utilise un mode de description proche du modèle grammatical traditionnel BNF (Backus-Naur Form).
Pour plus de détails consulter le document joint sur l'écriture d'une grammaire.

En résumé les éléments apparaissant dans une grammaire sont  :
 

Prenons comme exemple la grammaire décrivant les expressions algébriques :
 

Pour intégrer la sémantique, la solution MOïRA consiste à générer durant l'analyse syntaxique un arbre abstrait, qui est la représentation formelle du texte analysé, définie selon la grammaire.

Soit le texte suivant :

La conformité du texte à la grammaire précédente est prouvée s'il est possible de retrouver les règles grammaticales qui ont permis de constituer ce texte. Ces règles peuvent être ordonnées de façon arborescente et généralement unique. Si la disposition n'est pas unique, la grammaire est dite ambiguë.

Les règles apparaissent sur l'arbre syntaxique appelé aussi arbre de dérivation associé au texte :
 

Arbre de dérivation de l'expression  "Y=A*X+B"

MOïRA utilise une représentation arborescente simplifiée déduite de l'arbre de dérivation. Dans cette représentation plus compacte, on ne fait pas apparaître les symboles de ponctuation du langage (séparateurs ou mots-clés) devenus inutiles. Quelques règles intermédiaires comme <expression>, <facteur> ou <terme>  sont aussi ignorées, pour ne garder que ce qui sera appelé arbre abstrait. Chaque noeud est caractérisé par un code spécifique à la règle grammaticale dont il est issu.
 

Arbre abstrait de l'expression "Y=A*X+B"

On convient de marquer les régles de la grammaire ayant une portée sémantique pour le langage étudié. La convention retenue est de faire commencer les régles "utiles" par une majuscule :
 

Retour au début

Aspect historique
Références en modélisation et simulation
Références en programmation
Références en base de données
Références diverses
Analyse des données en calcul scientifique

Aspect historique

A cette époque en apparence obscure, mais en réalité pleine d'idées, naissait le langage avant-gardiste QUATRIX. Le compilateur traduisait un langage de haut niveau en FORTRAN. L'analyseur est écrit en PASCAL, et utilise le constructeur syntaxique SYNTAX de l'INRIA. La sémantique par arbre abstrait, caractéristique de ce qui va devenir MOïRA est mise en place par Jacques Raguideau.

Pour le projetALLAN, nous avions besoin d'un analyseur d'équations différentielles. Après une tentative malheureuse d'écriture manuelle d'un analyseur syntaxique pour la maquette ALLAN, il fallait se rendre à l'évidence et utiliser un outil. On choisit de réutiliser l'analyseur syntaxique de QUATRIX qui  fut réécrit en FORTRAN (eh oui !) et isolé dans un composant logiciel. On utilisait encore le constructeur syntaxique SYNTAX écrit en PL1 (Prehistoric Language One)

Nous disposions d'un savoir-faire en matière de traitement du langage et nus étions amenés à le mettre en oeuvre sur différents projets. Nous avons décidé de pérenniser ce savoir-faire au moyen d'un outil autonome, écrit dans un langage courant. (C ANSI).

Après une vingtaine d'utilisations de MOïRA, il nous a semblé utile d'introduire deux évolutions majeures. D'une part l'écriture de la grammaire se trouve simplifiée et se rapproche ainsi de la syntaxe BNF standard. D'autre part, l'analyseur est généré sous forme d'un objet C++. L'avantage est de pouvoir faire cohabiter plusieurs langages dans une seule application et de pouvoir travailler en mode parallèle.

Références en modélisation et simulation

C'est l'activité qui a a le plus bénéficiié de MOïRA. Il s'agit de modéliser des systèmes physiques au moyen d'équations différentielles et de schémas-blocs, puis de générer le simulateur : programme qui simule le fonctionnement du systéme décrit.

Les techniques mises en oeuvre sont le contrôle sémantique des équations, l'assemblage des modèles, la traduction en un autre langage de modélisation (essentiellement NEPTUNIX), ou la génération directe de programmes, ce qui implique la maîtrise de la dérivation formelle.

ALLAN.™Simulation, (Gaz de France, 1988) : Modélisation et simulation de systèmes physiques décrits par des équations différentielles et/ou des schémas-blocs.Traduction en code NEPTUNIX ou ASTEC

SCRIBT (CEA,GDF, 1992) : Logiciel de modélisation de systèmes physiques au moyen de Bondgraphs.

ARCJET (1992): Traduction d'équations aux dérivées partielles en équations différentielles du langage NEPTUNIX. Linéarisation d'une forme itérée d'équations définies sur des cellules.

ULM (GDF, 1993) : Un Langage de Modélisation destiné à l'échange de modèles physiques. Analyse contextuelle et traduction en ALLAN.

SIMAP (DCN/INDRET, 1994) : Réécriture de ALLAN. en C.

VENUS (Projet interne Cisi 1996) : Maquettage d'un générateur de simulateurs. Contrôle de cohérence, dérivation formelle, génération de code.

ADASSL (DDS pour GDF) : Traducteur ALLAN/DASSL : dérivation formelle, génération de code.

Si même DDS a su s'en servir, c'est que c'est facile ...

Références en programmation

Cette activité regroupe les diverses traductions d'un langage à l'autre, les contrôles sémantiques ou optimisationsapplicables à un programme.

QUATRIX (Cisi Saclay, 1980) : Langage dédié aux programmes scientifiques.

ATES (Projet Esprit) : Adanced Techniques, integration into Efficient Software (1986-89). Dans ce logiciel, la sémantique par arbre abstrait est utilisée pour mettre en œuvre les techniques de preuve de programme.

PEGASE (CEA, 1993) : Génération de jeux de données décrits formellement à partir des chemins sémantiques des programmes. Constitution des domaines de validité de variables à partir d'un système d'inéquations, puis tirage des solutions dans les intervalles.

MOIRA (1995): Traduction du générateur SYNTAX de PL1 en C Ansi..

HORUS (2003 CEA DAM) : Traduction de modules FORTRAN en C Ansi.

Retour ou début des références

Références en base de données

LDV (EDF, 1993) : Langage d'accès à une base de données relationnelle, faisant référence aux objets du Modèle Conceptuel des données. Les requêtes sont optimisées (forme normale disjonctive) et traduites en SQL.

OTARIE (CNET, 1995) : Interprétation d'un langage de commande destiné à gérer des réseaux de télécommunication.

SACBASE (EDF, 1996) Acquisition d'une base de connaissances pour une centrale thermique.

Pour SACBASE etOTARIE, Pierre et Yannick ont cédé au prosélytisme forcené de l'auteur.

Références diverses

ALLAN2, ALLAN3, (GDF, 1989 et 1995) ODESSA (2000 CEA Saclay) : Calculette utilisée en post-traitements sur des variables affichées.

HERA    (2003 CEA DAM) : Mise en place d'un mécanisme de contrôle d'assertions post-simulation.

Retour ou début des références
 

Analyse des données en calcul scientifique

CEDRES (CEA Cadarache) : Code de calcul d'équilibre d'un plasma dans un Tokamak. Analyse des scénarios de données.

LINDEP (GIAT, 1999) : Interpreteur de spécifications de plans d’expériences .

HERA    (2004 CEA DAM) : Lecture d'un fichier de données structurées.
 

Retour ou début des références

Retour au début