2. 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) 31 st March/1 st April 2003

3. 2 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

4. 3 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 ?

5. 4 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

6. 5 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

7. 6 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) Generation / Transformations CodeModel

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

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

10. 9 Plan SubjectSyntactic Tools Semantic Tools ArchitectureConclusion AbSynt Bridge DTD CoSynt AOP Visitor Configurable Visitors Decoupled Visitors Context Projection Approach

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

12. 11 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  Tree of graphical objects Textual form   Tree of objects with styles  Concrete Syntax Tree Specialisation/Refinement by successive Transformations ast sugars, ast boxes, ast, sugars styles, boxes, ast, sugars

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

14. 13 Plan SubjectSyntactic Tools Semantics Tools ArchitectureConclusion AbSynt Bridge DTD CoSynt AOP Visitor Configurable Visitors Decoupled Visitors Context Projection Approach

15. 14 Aspect-Oriented Programming 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? Separation of concerns [Kiczales] Aspects Code Weaver Classes

16. 15 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) {…} } static type  dynamic type class Visitor2 extends Visitor1 {…} class T2 implements I2 { void accept(Visitor v) { v.visit(this); }... class T1 … class T3…

17. 16 1 st 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  casts or 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

18. 17 2 nd 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) public Object beforeOp(AffectNode n, Object p) {…} public Object betweenElem1and2(AffectNode n, Object p) {…} public Object afterOp(AffectNode n, Object p) {…} visit(){ before visit() between visit() after }

19. 18 SubjectSyntactic Tools Semantic Tools ArchitectureConclusion AbSynt Bridge DTD CoSynt AOP Visitor Configurable Visitors Decoupled Visitors Context Projection Approach Plan

20. 19 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 Required Interfaces (dependence) Deployment Component specification Launching specification Container Component Functional Façade

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

22. 21 Architecture : Projections... Container class + Extension façade class SmartTools WSDL file + SOAP corresponding class Web- Services IDL File + CORBA server class CCM Remote and Home Interfaces EJB Component specification ? Eclipse

23. 22 SubjectSyntactic Tools Semantic Tools ArchitectureConclusion AbSynt Bridge DTD CoSynt AOP Visitor Configurable Visitors Decoupled Visitors Context Projection Approach Plan

24. 23 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)

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

26. 25 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?

27. 26 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

28. Quick Demo

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

30. 29

31. 30 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 a 2 a=2; assign varint "a""2" or

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

33. 32 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 el(T1 f1, T2[] f2); with T1=op1; et T2= op2, op3, op4, op5, op6; Example

34. 33 ViProfile  Configurable Visitor (Java) + assign(Var var, Exp e) AbSynt Integer visitSt(%Statement, Type t); String visit(%Var, Type t); ViProfile abstract class AbstractVisitor extends ClassicVisitorImpl { void pre-computation() {...}... class TraversalVisitor extends AbstractVisitor {…} 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) {} }

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

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

37. 36 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) assign varint "a""2" AST Nbox assign Sbox line Nlabel var "a" Slabel keyword "=" Nlabel int "2" Sbox keyword ";"  Tree of graphical objects a=2; Textual form   Tree of objects with styles  assign varint "a""2" "="";" Concrete Syntax Tree Specialisation/Refinement by successive Transformations