Description

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