Contribution to Generative Programming

Contribution to Generative Programming Application into the SmartTools generator: XML technologies, aspect-oriented programming and components Carine Courbis INRIA Sophia-Antipolis UCL - Software Systems Engineering Group (London) BTexact Technologies (Adastral Park, Ipswich) 31st March/1st April 2003

Context of this Work INRIA Sophia-Antipolis, OASIS team SmartTools Project (http://www-sop.inria.fr/oasis/SmartTools) Contracts: Bull Cp8, Microsoft and W3C Pragmatic developments 5 Members: • 1 Research Scientist: Dr.Didier Parigot[INRIA Sophia-Antipolis] • 3 Research Engineers: Pascal Degenne [now CIRAD], Alexandre Fau [now Ilog R&D], Dr. Claude Pasquier [now CNRS] • 1 PhD Candidate: myself This talk = my PhD defence talk Questions, at anytime, welcomed

Context: Upheaval Factors [1/3] Changes in Computer Science due to: • The Internet From PC-enclosed applications to Distributed ones Communication between applications and users • data exchange format ? XML Standard from W3C • Proliferation of new Technologies Many solutions to a problem (e.g. component) Which one to choose ? The more Perennial ?

Context: Upheaval Factors [2/3] • Democratisation of Computers Spread on none-technical domains Different knowledge, needs, supports, activity domains • Pressure of the market, Competition Developments: quicker, cheaper, adaptable • New Methods to Develop Applications Evolutionary Software, Adaptable to Needs

Context: Development Techniques [3/3] Programming Level OOP: encapsulation, inheritance  code extensible, reusable, modular, but … Cross-cutting Concerns, Mixing of Functional/None-Functional code  AOP, SOP, Intentional Programming  Component Programming, etc. Specification Level Document format Standardisation (W3C) UML, MDA of OMG

Model Code Generation / Transformations Objective and Approach To propose a new way of programming using code generation [Czarnacki, Eisenecker] from Models To integrate Technologies/Needs at generation  MDA Benefits: adaptable code to Technologies and Needs, to focus only on the "intelligent" part (ease programming) Additionally: Use of Standards from W3C and OMG (Tools and Evolutions)

MDA Approach MDA: Model-Driven Architecture of the OMG [Bézivin] PSM PIM PSM Generation / Transformations PSM Platform (Technology) Independent Model Platform (Technology) Specific Model Example: Web-Services CCM Component Model EJB To have a UML Domain-specific Model and to Specialise it by Transformation Our Approach: MDA but at Different Levels and with Languages

Data Manipulation API Data Model DTD or XML Schema Structured Editor Semantic Analyses Model Default Visitor + AOP PIM PSM View/GUI Model Pretty-printer Parser Specification Component Model Components Instantiation, at different levels, in SmartTools SmartTools = Software Framework To help developing DSLs/Tools SmartToolsGenerators For a Language L

Plan Subject Syntactic Tools Semantic Tools Architecture Conclusion AbSynt Bridge DTD AOP Context Approach Visitor CoSynt Configurable Visitors Projection Decoupled Visitors

DTD or XML Schema convert translate is instance of is conform to is represented by XML Document Objects/Nodes can be serialised in Open to Document world: Bridge Possible Semantic Analyses XML Document  Java Objects Our Data Model / Algebra Java Classes above DOM generate

 Textual form ast sugars, ast styles, boxes, ast, sugars Views/GUI Model: CoSynt Goal: To Transform an AST into a graphical/text view High Level Language, Separation of Concerns Generation : Pretty-printer and the associated Parser • Concrete Syntax • Display (sequences of transformations)  AST Concrete Syntax Tree  boxes, ast, sugars  Specialisation/Refinement by successive Transformations Tree of graphical objects Tree of objects with styles

AbSynt assign(Var var, Exp e) ANTLR Specification LL(k) Parser in Java CoSynt Concrete Syntax { assign(v,e) : v "=" e ";" } Layout { assign : line:(1 2 3 4) BML Nlabel : var, int Text newline : assign } XSLT stylesheet (text) Text + AST XSLT stylesheet (view) BML File Benefit from Standard Tools Swing Objects Swing Objets with styles (view isomorphic to the AST) + CSS CoSynt  Parser, Pretty-printer (using Standards) +

Plan Subject Syntactic Tools Semantics Tools Architecture Conclusion AbSynt Bridge DTD AOP Context Approach Visitor CoSynt Configurable Visitors Projection Decoupled Visitors

Aspect-Oriented Programming Separation of concerns[Kiczales] To Modular concerns and to interleave (weave) them , when requested, into the class code Where to weave? How to compose many aspects? Which implementation technique to choose? Classes Aspects Code Weaver

static type  dynamic type class T2 implements I2 { void accept(Visitor v) { v.visit(this); }... class T1 … class T3… Design Pattern Visitor in Java To define Operations on Objects Structure (tree) • Without Modifying the Objects • Code (extensible module) and Structure Separation class Visitor1 implements Visitor { void visit(T1 node) { ... node.getSon().accept(this); } void visit(T2 node) {…} void visit(T3 node) {…} } class Visitor2 extends Visitor1 {…}

1st Solution: Configurable Visitors Goal: ”To hide" the Visitor design pattern (in Java) Natural and Extensible Code Drawbacks:accept, fixed parameters and return type of methods  castsor global variables Solution: From model, Visitor Generation • Pre-computation to statically look for methods • Visit methods with configurable signatures and traversal • Aspects dedicated to our Visitors (more extensible analyses), statically or dynamically plugged in

2nd solution : Decoupled Visitors Goal: Reuse the Analyses  Composition, Enrichment Separation: Structure, Traversal, Semantic Actions  a Visit = n pieces of code  Aspects before, after, and between the sons Visitor = Code Weaver (~ Attribute Grammar evaluator) visit(){ before visit() between visit() after } public Object beforeOp(AffectNode n, Object p) {…} public Object betweenElem1and2(AffectNode n, Object p) {…} public Object afterOp(AffectNode n, Object p) {…}

Component specification Launching specification Architecture : Context SmartTools : To Generate autonomous Tools (Services) for DSLs + Meta-tool (generic tool) Goals : Tools Exportation and Importation + Architecture Configuration depending Application Objects are too fine-grain  Components • Specification of RequiredInterfaces (dependence) • Deployment Façade Container Functional Component

Architecture : Our Approach Which component technology to choose? Solution: MDA approach  PIM: own abstract component model  PSMs: SmartTools, EJB, CCM, Web-Services

Web- Services CCM EJB SmartTools Eclipse Container class + Extension façade class WSDL file + SOAP corresponding class IDL File + CORBA server class Remote and Home Interfaces ? Architecture : Projections Component specification <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>

Results : Utilisation examples SmartTools Internal Languages (bootstraps) AbSynt, CoSynt, ViProfile, CDML (component) W3C Languages XSLT, SVG, DTD, XML Schema, CSS, XML Programming Languages or DSL java, ant, etc. (because of XML bridge)

Conclusion Technology/Language Independent Model Generation / Transformations Code enriched with Technologies Approach  MDA Generative programming: evolutionary software, applicable to  levels Domain-specific part (PIM) Generated Targets (PSM) Java classes above DOM, DTD/XML Schema Data AbSynt View/GUI AbSynt + CoSynt Pretty-printer, Parser Sémantics AbSynt + ViProfile Visitors in Java Components for SmartTools, EJB, CCM or Web-Services CDML Components

Research Perspectives [1/2] Semantic analyses: • Composition rules of Semantic Actions • To make language components ~ GenVoca [Batory] • Pattern-matching: JDOM [Moreau, Kirchner], Pizza [Odersky], Java 1.5?

Research Perspectives [2/2] Components: • To Add the possibility of Aspects inside Objects + Aspects = Components • To Model the projection mechanisms Abstract PIM  Application PIM  PSMs SmartTools: Experimentation platform Bridges toward other Worlds: • Semantic-Web: Abstract Syntax  RDFS • UML: Abstract Syntax  MOF

Quick Demo

Contribution to Generative Programming Application into the SmartTools generator: XML technologies, aspect-oriented programming and components Questions ... http://www-sop.inria.fr/oasis/SmartTools

<assign> <var>a</var> <int>2</int> </assign> assign var int a=2; or "a" "2" Data Model (Algebra): AbSynt Program  AST (Abstract Syntax Tree) Why a new Formalism ? • To have a High Level Structuring Description format, independent technology/language • To accept DTD/XML Schema  Optional/List Son • To have an Abstraction towards the Implementation  layer to manipulate nodes

Written Code Transformation (SmartTools) Type  Interface, Constructor  Interface + Class Attribute  Variable Generated Code AbSynt  Java Classes above DOM PIM:Constructors (Operators), Types, Attributes, and Semantic Data PSM:JavaClasses aboveDOMto obtain Strictly Typed Trees DOM Services: serialisation, XPath, XSL, etc. Statement = assign(Var variable, Exp value); Required env as java.lang.String in affect; vector as java.util.HashMap in affect; package tiny.ast public interface AssignNode extends StatementType { public tiny.ast.VarType getVariableNode(); public void setVariableNode(tiny.ast.VarType node); ...

<!ELEMENT el (op1, (op2|(op3, op4)|(op5, op6*)))> el(T1 f1, T2[] f2); with T1=op1; et T2= op2, op3, op4, op5, op6; Example Abstract Syntax versus DTD, XML Schema Analogies • Constructors = Elements, Attributes = Attributes • Types  some of the parameter Entities, choices, substitutable elements ( type notion of XML Schema, corresponding to content model) Differences/Difficulties • Optional/List son notion • EBNF description: content model sometimes too complex  Loss of structure information

AbSynt assign(Var var, Exp e) ViProfile Integer visitSt(%Statement, Type t); String visit(%Var, Type t); abstract class AbstractVisitor extends ClassicVisitorImpl { void pre-computation() {...} ... class TraversalVisitor extends AbstractVisitor {…} ViProfile  Configurable Visitor (Java) + class Visitor extends TraversalVisitor { Integer visitSt(AssignNode node, Type t) { String s = visit(node.getVar(), t);... class TraceAspect implements Aspect { public void before(Type t, Object[] p) { System.out.println(”before " + p[0]); } public void after(Type t, Object[] p) {} }

3] beforeOp(AssignNode, Object) S1 Action 1] traverse() S2 Action 4] 2] beforeOp( UntypedNode) S3 Action 5] S4 Action 6] Running Example of a Decoupled Visitor Dynamic Traversal Decoupled Visitor ~ Code Weaver

Comparison between the two Solutions Same expression power • 1st: natural (thank to code generation) and extensible code but no reusable • 2nd: reusable code but less readable Example: a typechecking analysis was enriched with an initialisation variable check

assign assign  a=2; Textual form var int var int  "=" ";" assign Nbox "a" "2" "a" "2" Tree of graphical objects Tree of objects with styles   line Concrete Syntax Tree Sbox AST var keyword int keyword Nlabel Slabel Nlabel Sbox Specialisation/Refinement by successive Transformations "a" "=" "2" ";" Views/GUI Model: CoSynt Goal: To Transform an AST into a graphical/text view High Level Language, Separation of Concerns Generation : Pretty-printer and the associated Parser • Concrete Syntax • Display (sequences of transformations)

Contribution to Generative Programming