Contribution to Generative Programming
Application into the SmartTools generator: XML technologies, aspect-oriented
programming and components
Carine CourbisINRIA Sophia-Antipolis
UCL - Software Systems Engineering Group (London)BTexact Technologies (Adastral Park, Ipswich)
31st March/1st April 2003
2
Context of this WorkINRIA 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
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 TechnologiesMany solutions to a problem (e.g. component)
Which one to choose ? The more Perennial ?
4
Context: Upheaval Factors [2/3]
– Democratisation of Computers Spread on none-technical domains
Different knowledge, needs, supports, activity domains
– Pressure of the market, CompetitionDevelopments: quicker, cheaper, adaptable
New Methods to Develop Applications Evolutionary Software, Adaptable to Needs
5
Context: Development Techniques [3/3]
Programming LevelOOP: encapsulation, inheritance code
extensible, reusable, modular, but … Cross-cutting Concerns, Mixing of Functional/None-
Functional code
AOP, SOP, Intentional Programming
Component Programming, etc.
Specification LevelDocument format Standardisation (W3C)
UML, MDA of OMG
6
Objective and ApproachTo 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
7
MDA ApproachMDA: 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
ComponentModel
CCMWeb-Services
Generation /Transformations
PIM
Example:
PSMPSMPSM
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-printerParser
Specification
Components
SmartToolsGenerato
rs
Data Manipulation
API DTD or XMLSchema
StructuredEditor
PSM
Data Model
PIM
SemanticAnalysesModel
View/GUI Model
9
Plan
Subject SyntacticTools
SemanticTools
Architecture Conclusion
AbSyntBridge DTD
CoSynt
AOP
Visitor
ConfigurableVisitors
DecoupledVisitors
Context
Projection
Approach
10
XML Document Java Objects
Our DataModel /Algebra
Java Classesabove DOMgenerate
convertDTD
orXML Schema translate
Open to Document world: Bridge
can be serialised inXML Document
is conform to
is represented byObjects/Nodes
is instance of
Possible Semantic Analyses
11
Views/GUI Model: CoSynt
Goal: To Transform an AST into a graphical/text viewHigh 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 objectswith styles
Concrete Syntax Tree
Specialisation/Refinement by successive Transformations
ast sugars, ast
boxes,ast, sugars
styles, boxes,
ast, sugars
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, intText newline : assign}
CoSynt
ANTLR Specification
XSLT stylesheet (text)
XSLT stylesheet (view)
Text
BML File
Swing Objects
+ CSSSwing Objets
with styles(view isomorphic to the AST)
AST+
LL(k) Parser in Java
Benefit from Standard Tools
13
Plan
Subject Syntactic Tools
SemanticsTools
Architecture Conclusion
AbSyntBridge DTD
CoSynt
AOP
Visitor
Configurable Visitors
DecoupledVisitors
Context
Projection
Approach
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
CodeWeaver
Classes
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…
16
1st Solution: Configurable Visitors
Goal: ”To hide" the Visitor design pattern (in Java) Natural and Extensible CodeDrawbacks: 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
17
2nd solution : Decoupled Visitors
Goal: Reuse the Analyses Composition, EnrichmentSeparation: 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}
18
Subject SyntacticTools
SemanticTools
Architecture Conclusion
AbSyntBridge DTD
CoSynt
AOP
Visitor
ConfigurableVisitors
DecoupledVisitors
Context
Projection
Approach
Plan
19
Architecture : Context
SmartTools : To Generate autonomous Tools (Services) for DSLs + Meta-tool (generic tool)
Goals : Tools Exportation and Importation + Architecture Configuration depending ApplicationObjects are too fine-grain Components
• Specification of Required Interfaces (dependence)• Deployment
Componentspecification
LaunchingspecificationContainer
Component
Functional
Façade
20
Architecture : Our Approach
Which component technology to choose? Solution: MDA approach
PIM: own abstract component model
PSMs: SmartTools, EJB, CCM, Web-Services
21
Architecture : Projections<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>
Container class+
Extension façadeclass
SmartTools
WSDL file+
SOAP corresponding
class
Web-Services
IDL File+
CORBAserverclass
CCM
Remote andHome
Interfaces
EJB
Component specification
?
Eclipse
22
Subject SyntacticTools
SemanticTools
Architecture Conclusion
AbSyntBridge DTD
CoSynt
AOP
Visitor
ConfigurableVisitors
DecoupledVisitors
Context
Projection
Approach
Plan
23
Results : Utilisation examples
SmartTools Internal Languages (bootstraps)AbSynt, CoSynt, ViProfile, CDML (component)
W3C LanguagesXSLT, SVG, DTD, XML Schema, CSS, XML
Programming Languages or DSLjava, ant, etc. (because of XML bridge)
24
Conclusion
Data AbSynt
Domain-specific part (PIM)
Generated Targets(PSM)
Java classes above DOM,DTD/XML Schema
View/GUI AbSynt + CoSynt Pretty-printer, Parser
Sémantics AbSynt + ViProfile Visitors in Java
Components CDMLComponents for SmartTools,EJB, CCM or Web-Services
Technology/LanguageIndependent
Model
Generation /Transformations
Code enriched withTechnologies
Approach MDA
Generative programming: evolutionary software, applicable to levels
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?
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 PSMsSmartTools: Experimentation platform
Bridges toward other Worlds:– Semantic-Web: Abstract Syntax RDFS– UML: Abstract Syntax MOF
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
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
<assign> <var>a</var> <int>2</int></assign>
a=2;
assignvar int
"a" "2"or
31
PIM: Constructors (Operators), Types, Attributes, and Semantic DataPSM: Java Classes above DOM to obtain Strictly Typed Trees DOM Services: serialisation, XPath, XSL, etc.
AbSynt Java Classes above DOM
package tiny.astpublic 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 + ClassAttribute Variable
Generated Code
Written Code Transformation(SmartTools)
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
<!ELEMENT el (op1, (op2|(op3, op4)|(op5, op6*)))> el(T1 f1, T2[] f2); with T1=op1; et T2= op2, op3, op4, op5, op6;
Example
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) {}
}
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)
35
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 readableExample: a typechecking analysis was enriched
with an initialisation variable check
36
Views/GUI Model: CoSynt
Goal: To Transform an AST into a graphical/text viewHigh Level Language, Separation of Concerns
Generation : Pretty-printer and the associated Parser• Concrete Syntax • Display (sequences of transformations)
assignvar int
"a" "2"
AST
Nboxassign
Sboxline
Nlabelvar
"a"Slabel
keyword
"="Nlabel
int
"2"Sbox
keyword
";"
Tree of graphicalobjects
a=2; Textual form
Tree of objectswith styles
assign
var int
"a" "2"
"=" ";"
Concrete Syntax Tree
Specialisation/Refinement by successive Transformations