ATLAS Data Dictionary L’ environnement L’ équipe • Partie du « Control Framework » de ATLAS Intégrer dans ATHENA • L ’ équipe : LAPP : A. Bazan , P.Ghez, T. Le Flour, S. Lieunard LBNL : C. Tull (responsable du projet) T. Le Flour L.A.P.P 2 Pourquoi un « Data Dictionnary » ? • Afin d ’ éviter l ’ intégration fastidieuse d ’un ou plusieurs objets dans le « Framework » • Réutilisation d ’objets déjà présents dans le dictionnaire • Afin de concentrer le développement d ’un objet uniquement au niveau de son comportement T. Le Flour L.A.P.P 3 Pourquoi un « Data Dictionnary » ? • Accès ultérieur aux objets • debugging, visualisation, ... • Intégrer l ’accès aux objets depuis des services de « scripting » • Identifier aisément l ’existence d ’objet a travers leur présence dans le dictionnaire T. Le Flour L.A.P.P 4 Pourquoi un « Data Dictionnary » ? • Pouvoir décrire simplement un objet pour : sa partie publique • Visibilité de l ’objet : – accès extérieur depuis du code – accès extérieur depuis un langage « script »(PYTHON) sa partie persistante • sauvegarde de l ’objet dans un système de stockage ses relations avec d ’autres objets • relation avec des objets décrits également • relation avec des objets extérieurs T. Le Flour L.A.P.P 5 La description • Plusieurs possibilités : utilisation d ’un langage de programmation courant et utilisé dans le l ’environnement ATLAS : le C++ • Avantages : langage connu, grammaire définie, pas de nouveau langage a apprendre, … • Inconvénients : trop proche de l ’implémentation, pas de moyen de décrire la persistance, ... utilisation du langage de description des documents WEB : XML • Avantages : langage connu, langage de description, outils existent, permet de définir ce que l ’on souhaite, ... • Inconvénients : pas de grammaire définie, fastidieux a écrire ? , … utilisation du langage de description associé a CORBA : IDL • Avantages : langage connu, langage de description d ’interface, grammaire définie • Inconvénients : besoins d ’extensions de la grammaire, ... T. Le Flour L.A.P.P 6 Le choix • Grammaire de base : IDL + ? = ? Relation inter-objet : • adjonction d ’éléments de syntaxe ODL • mot-clé RELATIONSHIP Visibilité • ajout du mot-clé : private Accès a des objets externes non décrits • ajout du mot-cle : extern ADL = Athena Description Language T. Le Flour L.A.P.P 7 Une vue générale Compiler Back End Source ADL Compiler Front End C++,Java,... Compiler Back End C++,Java,... Compiler Back End C++,Java,... T. Le Flour L.A.P.P 8 Les « Uses Cases » L ’accès aux descriptions Éditer une description Créer une description Détruire une description Naviguer les descriptions Reverse Engineering « Parser » une description Publier une description T. Le Flour L.A.P.P 9 Les « Uses cases » (suite) La génération de code Choisir Back-End Configurer Back-End Générer Code Chaque back-end est sélectionnable individuellement et dynamiquement accessible Certains back-end peuvent être configurables Ex: La persistance peut etre configurée de plusieurs facons : Blob DDL adéquat utilisation d ’un DDL existant Démarrage de la génération de code et de la représentation interne d ’une description : Meta-Object Representation T. Le Flour L.A.P.P 10 Les « Uses Cases » (suite) L ’accès aux objets décrits(Run-Time) Lister les objets décrits Accéder a tous les objets crées et associés a une description ADL Retrouver un objet décrit Créer un objet décrit Détruire un objet décrit Accès aux données membres Invoquer une méthode Accéder a la description d ’un objet Accéder a un objet associé a une description ADL sur selection (Critères,….) Créer ou détruire un objet associé a une description ADL dans l ’espace « transient » (TES) Connaissant une reference, dans le « TES », d ’un objet décrit, retrouver et afficher sa description d ’origine Consulter, Modifier le contenu d ’un objet par connaissance d ’une réf. et d ’une description ADL ==> Mécanismes d ’introspection 11 Les outils • JavaCC The Java Parser Generator (http://www.webgain.com/products/metamata/java_doc.html) But : • génération d ’un code JAVA d ’analyse syntaxique a partir d ’une description de grammaire Avantages • beaucoup de grammaire disponible(IDL, ODL, HTML, XML, PERL, …) • Adaptable a des besoins spécifiques T. Le Flour L.A.P.P 12 Les outils • JavaCC(suite) Principe • JJTREE – analyse syntaxique de la grammaire – génération des sources JAVA (Abstract Syntax Tree : AST) : chaque nœud de l ’arbre de syntaxe correspond a une classe • JAVACC – génération du code (JAVA) du « Parser » – génération du code permettant le parcours de l ’arbre basé sur le « Visitor Pattern » Utilisation • Analyse syntaxique du fichier d ’entrée(format ADL) • Interrogation du contenu (parcours de l ’arbre) T. Le Flour L.A.P.P 13 JavaCC : Les Grammaires • Grammaire ADL void interface_dcl() : {} { interface_header() "{" interface_body() "}" } void interface_header() : {} { "interface" identifier() [ inheritance_spec() ] } T. Le Flour L.A.P.P ASTinterface_dcl JAVA File ASTheader_dcl JAVA File 14 JavaCC : Le principe ADLParser Visitor (interface) SimpleNode <<implements>> AST specification AST Interface_dcl AST interface_header AST xxxxx Accepte le visiteur Méthode : accept(…) Génération JJTREE Nœud principal 1. Accept(…) T. Le Flour L.A.P.P ADLParser (Visitor) Génération JavaCC 2. Visit(…) a. traitement du nœud courant b. accept sur tous les enfants du noeud 15 De la description a l ’utilisation Back End Code Cxx,Java,... Source ADL ADL Parser JavaCC ADL Analyzer Meta Objet Representation Back End Code Cxx,Java,... Compiler Front End Back End Code Cxx,Java,... T. Le Flour L.A.P.P 16 La structure interne • similitude avec la structure utilisée par JAVA pour les mécanismes de réflexion GenObject InterfaceDefinition 0..* 1 RelationDefinition ElementaryDefinition 0..* 0..* 0..* 0..* 1 0..* StructureDefinition 0..* AttributeDefinition1 0..* 0..* 0..1 TypeDefinition 0..* 1 OperationDefinition 1 0..* T. Le Flour L.A.P.P ParameterDefinition 17 ATHENA : La structure • Basé sur GAUDI (Framework de LHCb) T. Le Flour L.A.P.P 18 Intégration dans ATHENA • Fournir la « machinerie » pour intégration dans ATHENA Generation des squelettes d ’implementation (Code Generation) • Enregistrement dans le « Transient Event Store » • génération automatiques des méthodes d ’ accès au données-membres Génération des « converteurs » pour la persistance • Generation de fichiers DDL pour la persistence(Objectivity) • Generation du code des converteurs Generation des acces via le scripting • SWIG(Simple Wrapper and Interface Generator) actuellement , BOOST, Introspection • «Adapter Pattern » pour l ’accès aux objets existants T. Le Flour L.A.P.P 19 Diagramme de classe : Vue Utilisateur LArRawChannel LArCell LArDigit LArRawChannel.adl LArCell.adl LArDigit.adl Data Dictionnary : Description Code Generator Backend Activation Scripting BackEnd Activation DataObject LArCellBase Converter d_object LArCellAdapter Wrapper LArCell LArCellAdapter Code Generator Back End Scripting Back End Non generated class Converter BackEnd Activation LArCell NaiveObjyCnv T. Le Flour L.A.P.P LArCell NaiveObjy LArDigit VectorObjy DDL Schéma Converter Back End 20 Intégration dans ATHENA L ’introspection • Data Dictionary Service Interface d ’accès Création Enregistrement Objet ADL Algorithm Enregistrement SERVICES Liste des objets enregistres Description d ’un objet invocation de méthode consultation « data member » Accès Description Scripting Browser Transient Event Store Objets ADL Repository T. Le Flour L.A.P.P Accès Module Instrospection 21 Situation actuelle • Un prototype existe depuis fin Avril et intègre : Génération des squelettes de code Génération des « converteurs » Génération des accès a travers le langage de « scripting » • Ce qu ’il reste a faire : Analyse et implémentation du mécanisme d ’introspection Etude des évolutions d ’une description • conséquences sur la génération de code • conséquences sur l’ accès aux données Plus tard(peut-être) • Outils de gestion – « Browser » de description, Environnement graphique plus évolué ? T. Le Flour L.A.P.P 22