1 / 26

Composant logiciel

Composant logiciel. M O Ï R A. Une méthode et un outil destinés à simplifier le traitement des langages. Le traitement du langage. Présent dans 90% des développements logiciels scientifiques et techniques : configuration d’un logiciel (phrases cle=valeur),

kina
Download Presentation

Composant logiciel

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Composant logiciel M O Ï R A Une méthode et un outil destinés à simplifier le traitement des langages

  2. Le traitement du langage Présent dans 90% des développements logiciels scientifiques et techniques : • configuration d’un logiciel (phrases cle=valeur), • interprétation d’une commande, • calcul d’une expression, • génération de code, dérivation formelle, • contrôle sémantique, preuve de programmes, • etc ... Remarque : On ne traite pas les langues naturelles

  3. Etat de l’art • Des algorithmes d’analyse syntaxique sont au point depuis les années 70, des outils de base standard sont disponibles (Yacc, Bison). • Démarche classique : • 1) Ecriture de la grammaire du langage à traiter, (formalisme BNF) décorée par des actions sémantiques. • 2) un constructeur syntaxique génère automatiquement le programme de reconnaissance de ce langage : un analyseur syntaxique.

  4. Illustration (1) • Grammaire BNF (Backus Naur Form) : <phrase type> ::= <sujet> <verbe> <complément> . <affectation ::= <identifieur> = <expression> <addition> ::= <operande> + <operande> • Phrase syntaxiquement correcte : y = x + 1 • Erreur syntaxique : y = = x + 1 • Contrôle sémantique : x et y sont-ils déclarés ? du bon type ? • Action sémantique : Faut-il calculer y, traduire l‘instruction ?

  5. Illustration (2) • La démarche classique : Constructeur Syntaxique Grammaire Analyseur Syntaxique Application Fichier de données

  6. Exemple de code YACC %token UL_REEL UL_IDENT SP_PTV SP_EGAL SP_PLUS SP_MOINS ... %{ %} %start les_donnees %% les_donnees : {debut_liste_aff ();} des_affectations {fin_liste_aff ();}; affectation : identifieur SP_EGAL expression { creer_affectation ();} ; expression : addition | soustraction | terme; addition : expression SP_PLUS terme { creer_addition ();} ; soustraction : expression SP_MOINS terme { creer_soustraction ();} ; terme : multiplication | division; . . ................. reel : UL_REEL { creer_reel ();} ; identifieur : UL_IDENT { creer_identifieur ();} ; des_affectations : affectation { ajouter_affectation ();} | affectation SP_PTV { ajouter_affectation ();} des_affectations | SP_PTV ;

  7. Problèmes liés au traitement du langage • De trop nombreux développeurs préfèrent un codage manuel. • Si l’analyse syntaxique est bien formalisée, la sémantique l’est beaucoup moins. • Yacc : Cohabitation de deux types de code dans un même fichier (grammaire formelle + code C) : lisibilité restreinte. • Séquencement des actions sémantiques : nécessité de comprendre le fonctionnement de l’analyseur pour savoir à quel moment les actions sont déclenchées, et sur quelles variables elles agissent. • Obligation d’écrire des grammaires régulières.

  8. Spécificité de Moïra • La sémantique est implicite : aucune instruction n’apparaît dans la grammaire. • Utilisation d’une sémantique par arbre abstrait : le texte à analyser est transformé en une structure arborescente • qui coïncide à sa description formelle, • et qui est plus adaptée aux traitements applicatifs.

  9. Exemple de grammaire MOïRA LesDonnees::= { Affectation }*; Affectation ::= identifieur "=" expression expression ::= Addition | Soustraction | terme Addition ::= expression "+" terme Soustraction ::= expression "-" terme terme ::= Multiplication | Division | facteur Multiplication ::= terme "*" facteur Division ::= terme "/" facteur facteur ::= Parentheses | Identifieur | Reel Parentheses ::= "(" expression ")" Identifieur ::= %IDENT Reel ::= %REEL

  10. affectation expression addition expression terme multiplication terme terme facteur facteur facteur identifieur identifieur identifieur identifieur Y = A * X + B Arbre syntaxique • Texte analysé : Y = A*X + B • La conformité d'un texte est prouvée si l'on peut énumérer les règles grammaticales qui ont permis de structurer ce texte • On peut faire apparaître ces règles sous forme arborescente

  11. affectation expression addition expression terme multiplication terme terme facteur facteur facteur identifieur identifieur identifieur identifieur Y = A * X + B Arbre abstrait (1) L'arbre abstrait est une simplification de l'arbre syntaxique. On élimine : • Les règles intermédiaires non significatives (expression, terme, facteur) • Les mot-clés et séparateurs qui sont des symboles de ponctuation devenus inutiles

  12. affectation expression addition expression terme multiplication terme terme facteur facteur facteur identifieur identifieur identifieur identifieur Y = A * X + B Arbre abstrait : élimination des nœuds inutiles

  13. Arbre généré Vue d’ensemble Constructeur syntaxique 1) Écriture d ’une grammaire Grammaire MOÏRA 2) Génération de l’automate de reconnaissance x = 5 y = 3*x+1 y = ? y=16 Calcul Texte en entrée Application Résultat

  14. Exemple : un programme de calcul double calcul (arbre racine) { arbre ndgauche, nddroite; int rule; aa_interroger_noeud (racine, &rule, &ndgauche, &nddroite); switch (rule) { caseCD_Affectation : ident = aa_ident(ndgauche); result = calcul (nddroite); set_value(ident, result); break; caseCD_Addition : result = calcul(ndgauche) + calcul(nddroite); break; caseCD_Multiplication : result = calcul(ndgauche) * calcul(nddroite); break; caseCD_Parentheses : result = calcul(ndgauche); break; ......... caseCD_Reel : result = aa_reel (racine); break; caseCD_Identifieur: ident = aa_ident(racine); result = get_value (ident); break; } return result;

  15. Conséquences de la méthode • Séparation nette de 2 classes d’algorithmes correspondant chacune à un métier différent. • On fait abstraction de l’analyse syntaxique et des fonctions de bas niveau (analyse lexicale, saisie du texte, …). • On se consacre aux tâches à réelle valeur ajoutée de l’application : développement plus rapide (et plus intéressant).

  16. Mise en œuvre de Moïra • Lancer la commande : $ moira MyData Effet : • analyse le fichier MyData.bnf • génère l’include MyDataRules.h qui contient les codes associés aux règles, • ainsi que le module C++ MyDataLoad.cc … • qui contient la fonction MyDataLoad() … • laquelle fournit l’objet de classe MoiraLang configuré selon le langage MyData.

  17. Fourniture Moïra • Le générateur (C Ansi). • La bibliothèque de support à l’exploitation (C/C++). • Manuel de référence (WORD). • Guide HTML. • Quelques exemples d’algorithmes : traduction, calcul arithmétique, dérivation formelle, résolution formelle, …

  18. MOÏRA Quelques références

  19. Historique • 1980 Mise en œuvre de cette technique de sémantique par arbre abstrait par Jacques Raguideau pour le compilateur Quatrix (Cisi Saclay). • 1989 redécouverte pour ALLAN/Simulation (version FORTRAN de l’analyseur). • 1991 Création de Moïra (C Ansi, s’appuyant sur YACC, puis autonome) • 2004 : version C++ de MOïRA 4.

  20. Références en modélisation et simulation (1) Objet : Modélisation de systèmes physiques par équations différentielles et/ou schémas-blocs. Génération de simulateur, directe ou via un solveur. Techniques : Contrôle sémantique du texte, assemblage de modèles, traduction, génération de code, dérivation formelle. • ALLAN.™Simulation, (Gaz de France, 1987-94) : pré/post processeur de Neptunix.(ancêtre écrit en FORTRAN). • SCRIBT (CEA,GDF, 1993) : Modélisation au moyen de Bondgraphs. • ARCJET : (Dassault, 1993) Génération de langage NEPTUNIX à partir d'une forme itérée d’équations.

  21. Références en modélisation et simulation (2) • ULM (GDF, 1993) : Un Langage de Modélisation destiné à l'échange de modèles physiques. • VENUS (Cisi, 1995) : Maquettage d'un générateur de simulateurs. • ADASSL (DDS, 1995) : Interface ALLAN/DASSL. • NEPTUNIX+ (Cisi+GIAT,1998) : Nouvelle génération du langage de description des équations.

  22. Références en programmation Objet : Compilation, contrôle sémantique, traduction. • QUATRIX (Cisi, 1980) : langage dédié aux applications scientifiques. (Ancêtre Pascalien de Moïra). • ATES (Projet Esprit, 1986) : Mise en oeuvre de techniques de preuve de programme. • PEGASE (CEA/IPSN, 1993) : Génération de jeux de données décrits formellement à partir des chemins sémantiques des programmes. • MOïRA (Cisi,1994) Traduction du générateur PL1 en C. • HORUS (2003 CEA/DAM) : Traduction de fonctions FORTRAN en C.

  23. Références bases de données • LMD2 (EDF, 1991) : (1ère maquette YACC de Moïra) Journalisation et réinterprétation des requêtes. • LDV (1993, EDF) : Traduction et optimisation des requêtes du Modèle Conceptuel des données en SQL. • OTARIE (1994 CNET) : Interprétation du langage de commande destiné à gérer les réseaux de télécommunication. • SACBASE (1996 EDF) : Acquisition d'une base de connaissances pour une centrale thermique.

  24. Analyse des données en calcul scientifique • NEPTUNIX 3 (1994, Cisi) : Langage d’exploitation des simulateurs. • CEDRES (1998 CEA) : Code de calcul d'équilibre d'un plasma dans un Tokamak. Analyse des données et étude des scénarios. • LINDEP (1999 GIAT) : Interpréteur de spécifications de plans d’expériences . • HERA (2004 CEA/DAM) : Lecture d’un fichier de données structurées. Version C++ de l’analyseur.

  25. Références diverses • ALLAN2 et ALLAN3 (GDF 1989 et 1995) , ODESSA (2000 CEA Saclay) : Calculettes utilisées en post-traitements sur des variables affichées • ISEPUMS (1999 ESI Project 2792) : Respécification en VDM-SL d’un module du segment sol de SPOT4. • HERA (2003 CEA/DAM) : Mise en place d’un mécanisme de contrôle d’assertions post-simulation.

  26. FIN Merci de votre attention. Avez vous des Questions ???

More Related