Contribution à la Programmation Générative Application dans le générateur SmartTools : technologies XML, programmation par aspects et composants Je vais vous présenter les travaux effectués dans le cadre de ma thèse qui s'intitule Contribution à la programmation générative - Application dans le générateur SmartTools : technologies XML, programmation par aspects et composants. Je vais, tout d'abord, introduire le contexte de cette thèse. Carine Courbis Thèse dirigée par Didier Parigot et Isabelle Attali INRIA Sophia-Antipolis Soutenance de thèse, le 10 décembre 2002

Contexte : Facteurs de Bouleversements [1/3] Bouleversements de l'Informatique dus à : Internet Du PC, monde clos, au Distribué Communication entre applications et utilisateurs Format d'échange ? Standard XML du W3C Prolifération de Nouvelles Technologies Plusieurs solutions à un problème (ex : composant) Laquelle choisir ? la plus Pérenne ? Evolutive ? Former les programmeurs Depuis ces dernières années, il y a eu de formidables bouleversements dans le monde de l'informatique. Ces évolutions sont majoritairement dues à 4 phénomènes: l'émergence d'Internet, la prolifération de nouvelles technologies, la démocratisation de l'Informatique et la pression du marché économique. Je vais expliquer en quoi ces évolutions influent sur le développement d'applications, point qui nous a intéressés durant cette thèse. En effet, avec l'émergence d'Internet, la conception des applications doit être modifiée afin de prendre en compte la notion de répartition/distribution de code. On est passé de la conception d'applications confinées à un ordinateur, sans lien avec l'extérieur à des applications réparties, communiquant entre elles des données hétéroclites. Le problème était quel format de données utiliser pour échanger les informations (XML). Dans le même temps, il y a l'apparition d'une multitude de technologies. Avec cette prolifération, il est très probable d'avoir plusieurs solutions technologiques à un même problème. Le problème est de choisir la technologie la plus adaptée, pérenne et ayant des capacités à évoluer. Il est difficile de prévoir laquelle va émerger entre des solutions concurrentes. Choisir une nouvelle technologie implique aussi, pour l'entreprise, de former ses programmeurs. Cela peut coûter cher.

Contexte : Facteurs de Bouleversements [2/3] Démocratisation de l'Informatique Extension aux domaines non techniques Connaissances, besoins, supports, domaines d'activités différents Pression du marché, Concurrence Développements : + courts, - chers, adaptables Bouleversements des Méthodes de Développement d'Applications Logiciels évolutifs, adaptables aux Besoins Depuis quelques années, l'Informatique conviviaux -> GUI faciles utiliser -> peu compétence info, basés sur techniques connues ouverts -> format de données standard implémentation modulaire, flexible, à composants réutilisables et génériques

Contexte : Techniques de Développement [3/3] Niveau Programmation OO : encapsulation, héritage  code extensible, réutilisable, modulaire, mais … Préoccupations transversales aux classes, Mélange de code fonctionnel/non-fonctionnel  AOP, Programmation par Composants, etc Niveau Spécification Standardisation des formats de document (W3C) UML, MDA de l'OMG

Objectif et Approche Aider au Développement d'Applications Idée : Simplifier la programmation en Générant du code, à partir des Modèles (parties métiers) Solution : Phase de Génération : intègre les Technologies  MDA Gains : code adaptable selon technologies et besoins, concentration seulement sur partie "intelligente" En plus: Utilisation de Standards du W3C et de l'OMG (Outils et Evolutions) Génération / Transformations Code Modèle

Approche MDA MDA : Model-Driven Architecture PSM PIM Génération / Transformations PSM PSM Modèle Indépendant de la Plate-forme/Techno Modèle Spécifique à la Plate-forme/Techno Exemple: Web-Services CCM Modèle de composants EJB Avoir un Modèle Métier UML et le Spécialiser par Transformation Notre Approche : MDA à Différents Niveaux et avec des Langages

Instanciation, à différents niveaux, dans SmartTools SmartTools = Atelier Logiciel Aide au Développement Langages métiers/Outils Modèle de Données PIM API manipulation données DTD ou XML Schema Editeur guidé par la Syntaxe PSM Générateurs SmartTools Modèle d'Analyses Sémantiques Visiteurs par défaut + AOP Modèle de Vues/GUI Afficheur Spécification Parseur Composants Modèle de Composants Pour un Langage L

Plan Sujet Outils Syntaxiques Outils Sémantiques Architecture Conclusion AbSynt AOP Contexte Passerelles DTD XML Schema Visiteur Approche CoSynt Visiteurs configurables Projection Visiteurs découplés

Modèle de Données : AbSynt Programme AST (arbre de syntaxe abstraite) Pourquoi un nouveau Formalisme ? Avoir un format de Description de Structure de Haut Niveau, indépendant techno/langage Accepter DTD/XML Schema  Fils Optionnels/Tableaux Avoir une Abstraction vis-à-vis de l'Implémentation  sur-couche de manipulation des nœuds <affect> <var>a</var> <int>2</int> </affect> a=2; affect var int "a" "2" ou

AbSynt  Classes Java sur DOM PIM : Constructeurs (Opérateurs), Types, Attributs, et et Données sémantiques PSM : Classes Java sur DOM pour Arbres Strictement Typés Services DOM : serialisation, XPath, XSL, etc. Code généré Code écrit Transformation (SmartTools) Statement = affect(Var variable, Exp value); Required env as java.lang.String in affect; vector as java.util.HashMap in affect; Type  Interface, Constructeur  Interface + Classe Attribut  Variable package tiny.ast public interface AffectNode extends StatementType { public tiny.ast.VarType getVariableNode(); public void setVariableNode(tiny.ast.VarType node); ...

Document XML  Objets Java DTD ou XML Schema traduit Ouverture vers le monde Document, Passerelle Notre Modèle AbSynt Classes Java sur DOM convertit génère se serialise en Document XML est conforme à est représenté par Objets/Nœuds est instance de Analyses Sémantiques possibles

Syntaxe abstraite versus DTD, XML Schema Analogies Constructeurs = Eléments, Attributs = Attributs Types  certaines Entités paramètres, choix, éléments substituables ( notion type de XML Schema car modèle de contenu) Différences/Difficultés Notions de fils optionnels/tableaux Descriptions EBNF : modèle de contenu parfois trop complexe  Perte d'informations de structure <!ELEMENT el (op1, (op2|(op3, op4)|(op5, op6*)))> el(T1 f1, T2[] f2); avec T1=op1; et T2= op2, op3, op4, op5, op6; Exemple

Modèle des Vues/GUI : CoSynt But: Transformer un AST en vue graphique/texte Langage Haut niveau, Séparation des Préoccupations Génération : Afficheur et Analyseur Syntaxique associé Syntaxe concrète Affichage (suite de transformations)  affect var int "a" "2" "=" ";" Arbre de syntaxe concrète Spécialisation/Raffinement par Transformations successives affect var int "a" "2" AST a=2; Forme textuelle  Nbox affect Sbox line Nlabel var "a" Slabel keyword "=" int "2" ";"  Arbre d'objets graphiques  Arbre d'objets avec styles

CoSynt  Analyseur Syntaxique, Afficheur (avec des Standards) affect(Var var, Exp e) AbSynt Spécification ANTLR Analyseur syntaxique LL(k) en Java Bénéficie d'Outils Standard Concrete Syntax { affect(v,e) : v "=" e ";" } Layout { affect : line:(1 2 3 4) BML Nlabel : var, int Text newline : affect CoSynt + AST + Feuille XSLT (texte) Feuille XSLT (vue) Texte Fichier BML Objets graphiques Swing Objets graphiques Swing avec style (vue isomorphe AST) + CSS

Plan Sujet Outils Syntaxiques Outils Sémantiques Architecture Conclusion AbSynt AOP Contexte Passerelles DTD XML Schema Visiteur Approche CoSynt Visiteurs configurables Projection Visiteurs découplés

Programmation par Aspects Separation of concerns Classes Aspects Tisseur de Code Rendre Modulaire les Préoccupations et les ajouter (Tisser), à la demande, au code de base Où tisser? Comment composer plusieurs aspects? Quelle technique d'implémentation ?

Patron de conception Visiteur Définir des Opérations sur la structure d'Objets (arbre) Sans Modifier les objets Séparation Code (module extensible) et Structure type statique  type dynamique class Visitor1 implements Visitor { void visit(T1 node) { ... node.getSon().accept(this); } void visit(T2 node) {…} void visit(T3 node) {…} class T2 implements I2 { void accept(Visitor v) { v.visit(this); }... class T1 … class T3… class Visitor2 extends Visitor1 {…}

1re Solution : Visiteurs Configurables But : "Cacher" le patron Visiteur (en Java)  Code Naturel et Extensible Inconvénients : accept, paramètres et type de retour figés des méthodes d'où casts ou variables globales Solution : Générer, à partir d'un modèle (ViProfile), Méthodes visit à signature et parcours configurables Pré-calcul de recherche statique de méthodes En Plus : Aspects dédiés aux visiteurs (analyses plus extensibles), à branchement dynamique ou statique

ViProfile  Visiteur Configuré (Java) affect(Var var, Exp e) AbSynt Integer visitSt(%Statement, Type t); String visit(%Var, Type t); ViProfile + abstract class AbstractVisitor extends ClassicVisitorImpl { void pré-calcul() {...} ... class TraversalVisitor extends AbstractVisitor {…} class Visitor extends TraversalVisitor { Integer visitSt(AffectNode node, Type t) { String s = visit(node.getVar(), t);... class TraceAspect implements Aspect { public void before(Type t, Object[] p) { System.out.println("avant " + p[0]); } public void after(Type t, Object[] p) {}

2e solution : Visiteurs Découplés But : Réutilisation d'Analyses  Composition, Enrichissement Séparation : Structure, Parcours, Actions Sémantiques  une Visite = n morceaux de code  Aspects avant, après, et entre les fils Visiteur = Tisseur de code public Object beforeOp(AffectNode n, Object p) {…} public Object betweenElem1and2(AffectNode n, Object p) {…} public Object afterOp(AffectNode n, Object p) {…}

Exemple d'exécution d'un Visiteur Découplé Parcours Dynamique 1] traverse() 2] beforeOp( UntypedNode) 3] beforeOp(AffectNode, Object) Action S1 Action S2 Action S3 Action S4 4] 5] 6] Visiteur Découplé ~ Tisseur de Code

Comparaison des deux Solutions Même pouvoir d'Expression 1re : code naturel (grâce à la génération) et extensible mais pas réutilisable 2e : code réutilisable mais moins lisible Exemple : analyse de vérification de type enrichie avec vérification d'initialisation de variables

Plan Sujet Outils Syntaxiques Outils Sémantiques Architecture Conclusion AbSynt AOP Contexte Passerelles DTD XML Schema Visiteur Approche CoSynt Visiteurs configurables Projection Visiteurs découplés

Architecture : Contexte SmartTools : Générer des Outils autonomes (Services) pour des Langages Métiers + Méta-outil Buts : Exportation et Importation d'Outils + Configuration Architecture selon Application Approche objet à granularité trop Fine  Composants Spécification des Interfaces Requises (dépendances) Déploiement Descriptif composant Descriptif lancement Façade Conteneur Fonctionnel Composant

Architecture : Notre Approche Quelle Technologie de composant adopter? Adéquation aux besoins Technologie : handicap à l'évolution de l'outil Implémentation "légère" et simple  Création d'un Modèle de composant abstrait Projetable vers les Technologies EJB, CCM et Web-Services

Architecture : Projections Descriptif de Composant <component name="graph" extends="abstractContainer"> <containerclass name="GraphContainer"/> <facadeclass name="GraphFacade"/> <input name="addNode" method="addNode"> <parameter name="nodeName" javatype="java.lang.String">... </input> </component> Classe container + Classe extension façade SmartTools Fichier WSDL + Classe correspondance SOAP Web-Services Fichier IDL + Classe serveur CORBA CCM Interfaces remote et home EJB

Plan Sujet Outils Syntaxiques Outils Sémantiques Architecture Conclusion AbSynt AOP Contexte Passerelles DTD XML Schema Visiteur Approche CoSynt Visiteurs configurables Projection Visiteurs découplés

Résultats : Exemples d'Utilisation Langages internes de SmartTools AbSynt, CoSynt, ViProfile, CDML (composant) Langages du W3C XSLT, SVG, DTD, XML Schema, CSS, XML Langages de Programmation ou Métiers java, ant, etc (car passerelles XML)

Conclusion Modèle Indépendant Techno/Langage Génération / Transformations Code enrichi de Technologies Approche  MDA Programmation Générative : évolution logiciels, applicable  niveaux Logiques métiers (PIM) Cibles générées (PSM) Classes Java au-dessus de DOM, DTD/XML Schema Partie Données AbSynt Partie Vues/GUI AbSynt + CoSynt Afficheur, Analyseur Syntaxique Partie Sémantique AbSynt + ViProfile Visiteurs en Java Composants pour SmartTools, EJB, CCM ou Web-Services Partie Composants CDML

Perspectives de Recherche Analyses Sémantiques : Règles de composition d'Actions Sémantiques Composants : Modéliser les mécanismes de projection Ajouter la possibilité d'Aspects à l'intérieur SmartTools : plate-forme d'expérimentation Passerelles vers d'autres mondes : Web-sémantique : Syntaxe Abstraite  RDFS UML : Syntaxe Abstraite  MOF

Contribution à la Programmation Générative Application dans le générateur SmartTools : technologies XML, programmation par aspects et composants Je vais vous présenter les travaux effectués dans le cadre de ma thèse qui s'intitule Contribution à la programmation générative - Application dans le générateur SmartTools : technologies XML, programmation par aspects et composants. Je vais, tout d'abord, introduire le contexte de cette thèse. Questions ...