GenAWeave: A Generic Aspect Weaver
Framework based on Model-Driven Program Transformation
Committee Members: Dr. Jeff Gray (Advisor, Chair) Dr. Purushotham Bangalore Dr. Barrett Bryant Dr. Marjan Mernik Dr. Anthony Skjellum Dr. Randy Smith May 19, 2008
Suman [email protected]
Ph.D. Dissertation Defensehttp://www.cis.uab.edu/softcom/GenAWeave/
Software Composition and Modeling Laboratory
Department of Computer and Information SciencesUniversity of Alabama at Birmingham
S o f t C o m
2
Outline of Presentation
Motivation
Approach
Research Goals
Evaluation
Lack of Modularization (Legacy software decay)
Several Billion lines of Legacy code
Program Transformation
ChallengesLack of Reusability
+Accidental Complexities
Model-Driven Engineering Generic Aspect Weaver
Framework
Aspect FORTRAN Aspect Pascal
3
Challenges with Maintaining Legacy Systems
Commercial + Scientific Applications
> 200 Billion Lines of Legacy code
Migration is not an easy task !
Huge investment in infrastructure, effort, manpower
50% of the annual $230 billion spent on all software budgets
Too much time required to make simple changes
A need for constant fixes
Limited knowledge of the entire system
4
Laws of Evolution – Lehman, 1997 Systems must be continually
adapted else they become progressively less satisfactory and are subjected to decay over a period of time.
As systems evolve, they become more complex must take some action to reduce the complexity.
Big Ball of Mud
Brian Foote and Joseph Yoder
5
Tools and Techniques to Support Evolution of Legacy Software Aspect-Oriented Programming
AOP is a programming technique that allows programmers to modularize crosscutting concerns (i.e., program features that cut across the typical divisions of modularity, such as logging). Such features often cannot be cleanly decomposed from the rest of the system in both the design and implementation, and result in either scattering or tangling of source code.
Software Refactoring
“The process of changing a software system in such a way that it does not alter the external behavior of the code, yet improves its internal structure” [Fowler et al., 1999].
6
Crosscutting Concerns
XML Parsing in Apache Tomcat Server
Profiling in Apache Tomcat Server
http://www.parc.com/research/projects/aspectj/
7
Separation of Crosscutting Concerns - AOP Module A Module B
CC1
CC2
Concern CC1
Crosscutting concernsCC1/CC2 superimposed on Module A and B
Concern CC2
8
Aspect Weaving
AspectWeaver
Aspect Program
BaseProgram
Aspect Specification
Modified Target Program
The term “Aspect Weaving” refers to combining aspects (i.e., crosscutting features) with non-crosscutting pieces of source code.
The tool that is responsible for merging the separated aspects with the
base code is called an aspect weaver.
9
Aspect Weavers: Current Limitations
However –
1. Specific to a few popular languages (e.g., Java)
2. New tools are developed from scratch without preserving knowledge of previous construction
3. No emphasis on reusability in a different language and platform context
4. Generally do not support custom aspect weaving functionality (e.g., join point for loops, with construct in Object Pascal)
Several tools and language extensions have been developed to enable aspect weaving
10
Research Questions
Is there a technique to construct aspect weavers for legacy languages without extending or inventing a new parser (or compiler) from scratch?
Can such construction be supported in a more generic or language-independent way?
Can the knowledge of building a weaver from a previous
construction be reused in a different language and platform context?
Can we add custom features to an existing weaver and the same knowledge transferred to new weavers?
11
Outline of Presentation
Motivation
Approach
Research Goals
Evaluation
Lack of Modularization (Legacy software decay)
Several Billion lines of Legacy code
Program Transformation
ChallengesLack of Reusability
+Accidental Complexities
Model-Driven Engineering Generic Aspect Weaver
Framework
Aspect FORTRAN Aspect Pascal
12
Challenges in Language-Independent Legacy AdaptationChallenge C1 – The Parser Construction Problem
Challenge C2 – The Weaver Construction Problem
Challenge C3 – Accidental Complexities of Transformation Specifications
Challenge C4 – Language-Independent Generalization of Transformation Objectives
13
Challenge C1 – The Parser Construction Problem Scalability Extensibility Reusability
C++ Object Pascal Fortan Cobol Ada Jovial VHDL
Parser
Lower-order
Transforms
Aspect Language
Transformation System
User Inputs
Legacy System
Higher-order
Transforms
14
Challenge C2 – The Weaver Construction Problem
patternpattern probe_id_pattern1() probe_id_pattern1(): : unqualified_idunqualified_id = "printf". = "printf".
rulerule insert_probe1 insert_probe1(s: (s: statement_seqstatement_seq): ): function_bodyfunction_body ->-> function_bodyfunction_body = " { \s } " = " { \s } " ->-> "{ \probe_id_pattern1\(\)"{ \probe_id_pattern1\(\) (\"Entering Method…\");(\"Entering Method…\"); { \s } { \s } }".}".
Availability of AST representation Low-level Transformation Infrastructure
Parser
Lower-order
Transforms
Aspect Language
Transformation System
User Inputs
Legacy System
Higher-order
Transforms
15
Challenge C3 – Accidental Complexities of Transformation Specifications A high-level aspect language
layered on top of the transformation system
Translates to low-level specifications
aspect insert_probe1 { before(): execution (function_declaration) { // insert print statement } }
Parser
Lower-order
Transforms
Aspect Language
Transformation System
User Inputs
Legacy System
Higher-order
Transforms
16
Challenge C4 – Language-Independent Generalization of Transformation Objectives
Parser
Lower-order
Transforms
Aspect Language
Transformation System
User Inputs
Higher-order
Transforms
rule BeforeAdvice2Pattern { from s : APascal!BeforeAdvice to t : RSL!Pattern ( phead <- ph, ptext <- spt, token <- 'statement_list', ), ph : RSL!PatternHead ( name <- 'before_ advice_stmt' ), ...}
17
Outline of Presentation
Motivation
Approach
Research Goals
Evaluation
Lack of Modularization (Legacy software decay)
Several Billion lines of Legacy code
Program Transformation
ChallengesLack of Reusability
+Accidental Complexities
Model-Driven Engineering Generic Aspect Weaver
Framework
Aspect FORTRAN Aspect Pascal
18
Research Goals
Program Transformation
Engine(C1,C2)
Aspect Weavers
Low-Level xForm constructs
High-level language constructs
Legacy Software
Increase the level of
abstraction and reuse the
core transformations
rules across language
domains
Higher-Order Transforms
Goal 1 : Raise the level of abstraction (aspect layering) for end-programmers (C3)
Goal 2 : Reuse core transformations across language domains using higher-order transforms (C2, C4)
19
Model-Driven Program Transformation based Aspect Weaving Framework
The high-level aspect language is used to raise the level of abstraction and hide the accidental complexities that are associated with program transformation rules
The program transformation rule generator produces program transformation rules using higher- order model transformation rules
The generated program transformation rules are processed along with the source program to accomplish the desired weaving
Reuses existing parsers
Reuses several artifacts while creating weavers from one language to another
20
Outline of Presentation
Motivation
Approach
Research Goals
Evaluation
Lack of Modularization (Legacy software decay)
Several Billion lines of Legacy code
Program Transformation
ChallengesLack of Reusability
+Accidental Complexities
Model-Driven Engineering Generic Aspect Weaver
Framework
Aspect FORTRAN Aspect Pascal
21
Overview of Approach
Current State-of-the-Art Techniques
Program Transformation Back-End
Model-Driven Front-End
Model Transformation
GenAWeave in Action
PT Based Back-End
SourceProgram
TransformationSystem
TransformedProgram
M3
M2
M1
AspectMetamodel
Myaspect.apAspectPascal
EBNFEBNF
Aspect.gGrammar
Myaspect Model
KM3Grammarware TS
Model-Driven Engineering (MDE)Technical Space (TS)
RSLMetamodel
MyRslModel
RSL.gGrammar
MyRsl.rslRSL program
ExtractionInjection
Grammarware TS
Aspect2RSLTransformation
SymbolTable
ATL ModelTransformation
Engine
Pretty Printer
DMS ProgramTransformation
Engine
Generic Model Transform Library
Concrete RSL Transform
Lexer/Parser
Domain Reader
AspectSourceProgram
ASTGraph
Unparserdefinitions
Parserdefinitions
C2
C1
C1
Model-Driven Front-End Program Transformation based Back-End
Generic AspectMetamodel
Aspect SourceMetamodel
Aspect SourceModel
RSLMetamodel
RSLModel
InputSourceProgram
Analyzer
TransformedTargetProgram
C4
C4
C2
C2
C3 C3
C3C3
+name : String
GAspect
Advice
1*
AroundAdviceBeforeAdvice AfterAdvice
Statement
1*
+name : String
Pointcut
1
*
Expression
ArgsExprLoopExpr
AspectPascal
LoopStatement
FuncOrProcDefExpr
CallExprWithinCodeExpr ExecExpr
1
*
WhileLoopForLoop WithExpr
FuncOrProcSignature
FuncDef ProcDef
22
Current State-of-the-Art: Transformation Techniques
Object-based transforms, such as a visitor object applied to an object model
Intermediate representations that permit primitive transformations to be applied to a set of languages (e.g., .Net CodeDOM)
XML-based transforms that use an XML DOM structure
Term rewriting, such as a transformation rule
23
Current State-of-the-Art:SourceWeave.Net
Uses Microsoft’s CodeDom Architecture as the underlying AST Representation
Uses XML descriptor to specify interaction between aspects and .Net components
http://www.dsg.cs.tcd.ie/dynamic/?category_id=438
Limited availability of CodeDOM providers
CodeDOM biased towards C#, hence lack of expressiveness for
other languages
Verbosity of XML representations a serious concern for scalability
24
Current State-of-the-Art:Weave.Net
http://www.dsg.cs.tcd.ie/dynamic/?category_id=194
Uses existing .Net Binary Component and crosscutting specifications in an xml file as input
Advice is given separately in another .Net assembly
Limited to applications hosted within .Net
Aspect specification is difficult to comprehend due to lack of expressiveness of XML constructs
Component(.NET Assembly)
Weave.NETWoven Component(.NET Assembly)
Crosscutting Statements (XML)
Behaviour (.NET Assembly)
Aspect
25
Current State-of-the-Art: Aspect Cobol
http://homepages.cwi.nl/~ralf/AspectCobol/
Parse trees are exported to XML
Weaving is achieved by XML DOM tree processing in Java
XML representation of source code (intermediate form) may not scale with code size
It has been reported that such internal representations are 50 times larger and much slower to transform
Limited only to COBOL
A more generalized approach is missing
26
Current State-of-the-Art: Aspicere + GCC 4.0
http://users.ugent.be/~badams/aspicere/
Proposes to use GCC 4.0 GENERIC trees
Weaving is done by modifying the GENERIC
AST representations
Lack of support for .Net Languages like C#, VB.Net and other languages like Object Pascal, Cobol etc, currently supports only C
Still in a proposal stage, not clear whether API support is available for modifying GENERIC trees
Very little documentation available from project site
27
Overview of Approach
Current State-of-the-Art Techniques
Program Transformation Back-End
Model-Driven Front-End
Model Transformation
GenAWeave in Action
PT Based Back-End
SourceProgram
TransformationSystem
TransformedProgram
M3
M2
M1
AspectMetamodel
Myaspect.apAspectPascal
EBNFEBNF
Aspect.gGrammar
Myaspect Model
KM3Grammarware TS
Model-Driven Engineering (MDE)Technical Space (TS)
RSLMetamodel
MyRslModel
RSL.gGrammar
MyRsl.rslRSL program
ExtractionInjection
Grammarware TS
Aspect2RSLTransformation
SymbolTable
ATL ModelTransformation
Engine
Pretty Printer
DMS ProgramTransformation
Engine
Generic Model Transform Library
Concrete RSL Transform
Lexer/Parser
Domain Reader
AspectSourceProgram
ASTGraph
Unparserdefinitions
Parserdefinitions
C2
C1
C1
Model-Driven Front-End Program Transformation based Back-End
Generic AspectMetamodel
Aspect SourceMetamodel
Aspect SourceModel
RSLMetamodel
RSLModel
InputSourceProgram
Analyzer
TransformedTargetProgram
C4
C4
C2
C2
C3 C3
C3C3
+name : String
GAspect
Advice
1*
AroundAdviceBeforeAdvice AfterAdvice
Statement
1*
+name : String
Pointcut
1
*
Expression
ArgsExprLoopExpr
AspectPascal
LoopStatement
FuncOrProcDefExpr
CallExprWithinCodeExpr ExecExpr
1
*
WhileLoopForLoop WithExpr
FuncOrProcSignature
FuncDef ProcDef
28
Program Transformation Back-End
Analyzer
unparserdefinitions
ASTGraph
Parser
SourceProgram
SymbolTable
Pretty Printer
Domain Definitions
TargetProgram
parserdefinitions
DMS Transformation
Engine
ProgramTransformation Rules
1. default base domain ObjectPascal.2. private rule insert_probe(stmt_list: statement_list): 3. function_body function_body4. = "begin \stmt_list end" 5. "begin ShowMessage(\"Entering Method\"); \stmt_list end".6. public ruleset TraceAllFunctions = {insert_probe}
29
Program Transformation based Aspect Weaving (Language-specific weavers)
Several aspects identified Processing dialog meter
Updating of progress meter Appears in 62 different places of the schema migrator
Exception handling of meter Logging of SQL query statements The methods of the logging object
are invoked in over 50 different places in the schema migrator Synchronization in database error handler The addition of this
concurrency concern resulted in a manual invasive change to over 20 classes. Dirty Bits in language internationalization utility This appears in 29
unique places in the language internationalization source code
Experiment conducted on support utilities for a commercial distributed application written in Object Pascal
30
Object Pascal Example
// The user wants to perform another search
procedure TLangMan.SearchAgainClick(Sender: TObject);
begin
// Perform an update if an edit occurred that //might change the focus of the listview
if EditMadeDirtyBit then
SaveDBControls;
…
end;
default base domain ObjectPascal.external condition func_sig_has_click(id1:IDENTIFIER,id2:IDENTIFIER)= 'func_sig_has_click'.pattern advice(slist:statement_list) : statement_list = "if EditMadeDirtyBit then SaveDBControls; \slist".pattern isClick(id:IDENTIFIER): IDENTIFIER = id if func_sig_has_click(click(), id).pattern click (): IDENTIFIER = "Click".rule probe_dirty_bit (id1:IDENTIFIER, id2:IDENTIFIER,fps:formal_parameters, slist:statement_list): implementation_decl -> implementation_decl = "procedure \id1 . \isClick\(\id2\) \fps ; begin
\slist end;" -> "procedure \id1 . \id2 \fps ;
begin\advice\(\slist\)
end;".if ~[modslist:statement_list .slist matches"\:statement_list \advice\(\modslist\)"].
public ruleset applyrules = { probe_dirty_bit }.
(define func_sig_has_click (lambda Registry:MatchingCondition (let (;;(= [const_string (reference string)] (AST:GetString arguments:1)) (= [search_string (reference string)] (AST:GetString arguments:2)) (= [scanner StringScan:Scan ] (StringScan:MakeScan search_string)) );; (value (while (== (StringScan:End? (. scanner)) ~f)
(ifthenelse (StringScan:MatchString? (. scanner) const_string) (return ~t)
(StringScan:Advance (. scanner)) )ifthenelse )while~f
)value )let )lambda)define
31
Justification of PT Back-End A mature PTE (e.g., DMS) can ease the construction effort for
weavers of legacy languages by offering a direct solution to Challenges C1 and C2.
A PT model offers complex Join Point Shadows (e.g., nested conditional statements) and a rich pointcut to join point binding.
PTEs offer powerful pattern matching and efficient tree traversal strategies (e.g., using visitors over ASTs) that can scale to several million lines of code.
PTEs offers internal APIs that enable transformation of ASTs in an arbitrary manner, thereby allowing more complex and flexible transforms required by legacy applications (e.g., aspects and loops).
In contrast to the verbose AST representation in XML-based approaches, DMS provides internal data structures (e.g., hypergraphs) to represent the underlying AST. This offers an improved level of optimization to support parsing and transforming large legacy applications.
32
Challenges using PT Engines The rewrite rules used to modify base programs are difficult to
compose, which makes it accessible to only language researchers (accidental complexities, Challenge C3)
The transformation rules are generally hard to comprehend by average software developers (need to know about the grammar and semantics of the underlying PTE, Challenge C3)
The transformation rules are tied to the grammar of the base language (Challenge C4)
Moreover….
The entire weaver is rendered unusable if the base transformation engine is replaced with another one (interoperability problem)
The PT engine may be proprietary, i.e., may not be available for use by all desired parties (e.g., DMS)
33
Overview of Approach
Current State-of-the-Art Techniques
Program Transformation Back-End
Model-Driven Front-End
Model Transformation
GenAWeave in Action
PT Based Back-End
SourceProgram
TransformationSystem
TransformedProgram
M3
M2
M1
AspectMetamodel
Myaspect.apAspectPascal
EBNFEBNF
Aspect.gGrammar
Myaspect Model
KM3Grammarware TS
Model-Driven Engineering (MDE)Technical Space (TS)
RSLMetamodel
MyRslModel
RSL.gGrammar
MyRsl.rslRSL program
ExtractionInjection
Grammarware TS
Aspect2RSLTransformation
SymbolTable
ATL ModelTransformation
Engine
Pretty Printer
DMS ProgramTransformation
Engine
Generic Model Transform Library
Concrete RSL Transform
Lexer/Parser
Domain Reader
AspectSourceProgram
ASTGraph
Unparserdefinitions
Parserdefinitions
C2
C1
C1
Model-Driven Front-End Program Transformation based Back-End
Generic AspectMetamodel
Aspect SourceMetamodel
Aspect SourceModel
RSLMetamodel
RSLModel
InputSourceProgram
Analyzer
TransformedTargetProgram
C4
C4
C2
C2
C3 C3
C3C3
+name : String
GAspect
Advice
1*
AroundAdviceBeforeAdvice AfterAdvice
Statement
1*
+name : String
Pointcut
1
*
Expression
ArgsExprLoopExpr
AspectPascal
LoopStatement
FuncOrProcDefExpr
CallExprWithinCodeExpr ExecExpr
1
*
WhileLoopForLoop WithExpr
FuncOrProcSignature
FuncDef ProcDef
34
Model-Driven Front-End - Justification Modularize the weaver construction process by decoupling the model of the high-level aspect language from the model of the target program transformation language (RSL).
The source aspect metamodel need not be altered even if one chooses to opt for a different target PTE, only a new PTE metamodel needs to be developed.
Conversely, for every new language, one needs to add the appropriate metamodel extensions to the base aspect metamodel, but no change to the target metamodel is needed.
Both the aspect language (source) and rules language (target) can evolve independent of each other. This leads to new features being added to the weaver.
35
Metamodel for Aspect Pascal+name : String
AspectPascal
Advice
+aspect1+advices*
AroundAdviceBeforeAdvice AfterAdvice
Statement
+advice
1+stmts *
+name : String
Pointcut
+aspect
1+pointcuts*
Expression
+pointcut1+expressions*
+advice +pointcut
Advice
Statement
+advice1+stmts*
ParamDef
+advice
1
+paramdefs*
LoopStatement OpaqueStatement ProceedStatement
+name : String
Pointcut
Expression
+pointcut1
+expressions*
CallExpr WithExpr ExecExpr
FunctionOrProcSignature
11
110- 0-
36
KM3 and TCS Specification
class AspectPascal extends LocatedElement { attribute name : String; reference domain container : Domain; reference pointcuts[1-*] container : Pointcut oppositeOf aspect; reference advice[1-*] container : Advice oppositeOf aspect;}class Pointcut extends Element { attribute name : String; reference aspect : AspectPascal oppositeOf pointcut; reference paramdefs[*] container : ParameterDef; reference exprs[1-*] container : Expression oppositeOf pointcut;}abstract class Advice extends LocatedElement { reference aspect : AspectPascal oppositeOf advice; reference pointcut : Pointcut; reference paramdefs[*] container : ParameterDef; reference stmts[1-*] container : Statement;}
37
KM3 and TCS Specification
template AspectPascal main: "aspect" name "{" pointcut advice "}";
template Pointcut context addToContext: "pointcut" name "(" paramdefs{separator = ","} ")" ":" exprs {separator = "&&"} ";";
template Advice abstract;
template BeforeAdvice: "before" "(" paramdefs {separator = ","} ")" ":"
... ;template AfterAdvice
: "after" "(" paramdefs {separator = ","} ")" ":" ... ;
38
Support for Generic Front-End (Aspect Pascal)
+name : String
GAspect
Advice
1*
AroundAdviceBeforeAdvice AfterAdvice
Statement
1*
+name : String
Pointcut
1
*
Expression
ArgsExprLoopExpr
AspectPascal
LoopStatement
FuncOrProcDefExpr
CallExprWithinCodeExpr ExecExpr
1
*
WhileLoopForLoop WithExpr
FuncOrProcSignature
FuncDef ProcDef
39
Support for Generic Front-End (Aspect FORTRAN)
+name : String
GAspect
Advice
1*
AroundAdviceBeforeAdvice AfterAdvice
Statement
1*
+name : String
Pointcut
1
*
Expression
ArgsExprLoopExpr
AspectFORTRAN
LoopStatement
FuncOrSubDefExpr
CallExprWithinCodeExpr ExecExpr
1
*
DoLoop
FuncOrProcSignature
FuncDef SubDef
40
41
Target Metamodel (RSL)
-dname : String
RSL
+name : String
RuleSet
+rsl
1
+ruleset
*
+dname : String+tokens : String
ExternalPattern
Rule
+dname : String+tokens : String
ExternalCondition
+name : String+type : String
Element
Condition
+rsl1
+elems*
Pattern
+rulesets1
+rules*
42
Overview of Approach
Current State-of-the-Art Techniques
Program Transformation Back-End
Model-Driven Front-End
Model Transformation
GenAWeave in Action
PT Based Back-End
SourceProgram
TransformationSystem
TransformedProgram
M3
M2
M1
AspectMetamodel
Myaspect.apAspectPascal
EBNFEBNF
Aspect.gGrammar
Myaspect Model
KM3Grammarware TS
Model-Driven Engineering (MDE)Technical Space (TS)
RSLMetamodel
MyRslModel
RSL.gGrammar
MyRsl.rslRSL program
ExtractionInjection
Grammarware TS
Aspect2RSLTransformation
SymbolTable
ATL ModelTransformation
Engine
Pretty Printer
DMS ProgramTransformation
Engine
Generic Model Transform Library
Concrete RSL Transform
Lexer/Parser
Domain Reader
AspectSourceProgram
ASTGraph
Unparserdefinitions
Parserdefinitions
C2
C1
C1
Model-Driven Front-End Program Transformation based Back-End
Generic AspectMetamodel
Aspect SourceMetamodel
Aspect SourceModel
RSLMetamodel
RSLModel
InputSourceProgram
Analyzer
TransformedTargetProgram
C4
C4
C2
C2
C3 C3
C3C3
+name : String
GAspect
Advice
1*
AroundAdviceBeforeAdvice AfterAdvice
Statement
1*
+name : String
Pointcut
1
*
Expression
ArgsExprLoopExpr
AspectPascal
LoopStatement
FuncOrProcDefExpr
CallExprWithinCodeExpr ExecExpr
1
*
WhileLoopForLoop WithExpr
FuncOrProcSignature
FuncDef ProcDef
43
Model Transformation
M1 = model level; M2 = metamodel level; M3 = meta-metamodel level
M3
M2
M1
AspectMetamodel
Myaspect.apAspectPascal
EBNFEBNF
Aspect.gGrammar
Myaspect Model
KM3
Grammarware TSModel-Driven Engineering (MDE)
Technical Space (TS)
RSLMetamodel
MyRslModel
RSL.gGrammar
MyRsl.rslRSL program
ExtractionInjection
Grammarware TS
Aspect2RSLTransformation
44
ATL Transformations rule AfterAdvice2Pattern { from s : Aspect!AfterAdvice to t : Rsl!Pattern ( ptoken <-'statement_list', ptext <- s.advStmt.stmt ...
), ... }
rule Aspect2Rsl { from
s: Aspect!Aspect to
t: Rsl!Rsl ( domain <- s.domain, pattern <- s.advice, rule <- s.pointcut,
ruleset <- rs ), rs: Rsl!RuleSet (
rsname <- s.aname,
rname <- s.pointcut-> collect(e|e).pctname), … }
The transformations generate the corresponding RSL rule for the given aspect
Core transformation library :call, exec, loop, with, withincode(i.e., one transformation for each type of pointcut)
45
Generalizing the Rule Generator Design
generic_advice_call ({ program_root_ Fortran90_program},{ method_id_ Name},{ proceed_ Name},{ before_advice_ execution_part_construct_list},{ after_advice_ execution_part_construct_list},) Fortran90_program
generic_advice_call ({ program_root_ ObjectPascal},{ method_id_ IDENTIFIER},{ proceed_ IDENTIFIER},{ before_advice_ statement_list},{ after_advice_ statement_list},) ObjectPascal
46
Support for Reusable Back-End Functions To support back-end construction, GenAWeave provides a reusable library of external functions that can be used to construct part of the low-level weaving infrastructure for a given weaver
name_ends_with - useful for matching identifiers (e.g., function name) whose name ends with a given input. This is equivalent to a wildcard search *name in an aspect program
name_begins_with - useful for matching names (e.g., function name, identifiers), which begin with the given input. This is equivalent to a wildcard search name* in an aspect program
GetChildFromParent - helper routine useful for finding a child node with a given property from the parent node
GetParentFromChild - helper routine useful for finding a parent node with a given property from the child node
47
(define name_ends_with (lambda Registry:MatchingCondition
(let (;; (= [search_string (reference string)] (Graph:HGHandling:GetString arguments:1))
[sub_string string] [search_string_size natural] [search_id_size natural] [start_index natural] );; (value
(;; (= search_string_size (size (@(AST:GetString arguments:1))))
(= search_id_size (size (@(AST:GetString arguments:2)))) (= start_index (- search_string_size search_id_size)) (= sub_string (Strings:Substring (AST:GetString arguments:1) (+ start_index 1) search_id_size))
(ifthen(== sub_string (@(AST:GetString arguments:2))) (return ~t))ifthen
(return ~f));;~f
)value )let)lambda
)define
48
Overview of Approach
Current State-of-the-Art Techniques
Program Transformation Back-End
Model-Driven Front-End
Model Transformation
GenAWeave in Action
PT Based Back-End
SourceProgram
TransformationSystem
TransformedProgram
M3
M2
M1
AspectMetamodel
Myaspect.apAspectPascal
EBNFEBNF
Aspect.gGrammar
Myaspect Model
KM3Grammarware TS
Model-Driven Engineering (MDE)Technical Space (TS)
RSLMetamodel
MyRslModel
RSL.gGrammar
MyRsl.rslRSL program
ExtractionInjection
Grammarware TS
Aspect2RSLTransformation
SymbolTable
ATL ModelTransformation
Engine
Pretty Printer
DMS ProgramTransformation
Engine
Generic Model Transform Library
Concrete RSL Transform
Lexer/Parser
Domain Reader
AspectSourceProgram
ASTGraph
Unparserdefinitions
Parserdefinitions
C2
C1
C1
Model-Driven Front-End Program Transformation based Back-End
Generic AspectMetamodel
Aspect SourceMetamodel
Aspect SourceModel
RSLMetamodel
RSLModel
InputSourceProgram
Analyzer
TransformedTargetProgram
C4
C4
C2
C2
C3 C3
C3C3
+name : String
GAspect
Advice
1*
AroundAdviceBeforeAdvice AfterAdvice
Statement
1*
+name : String
Pointcut
1
*
Expression
ArgsExprLoopExpr
AspectPascal
LoopStatement
FuncOrProcDefExpr
CallExprWithinCodeExpr ExecExpr
1
*
WhileLoopForLoop WithExpr
FuncOrProcSignature
FuncDef ProcDef
49
GenAWeave in Action
Symbol Table
ATL ModelTransformation
Engine
Pretty Printer
DMS ProgramTransformation
Engine
Generic Model Transform Library
Concrete RSL Transform
Lexer/Parser
Domain Reader
AspectSourceProgram
ASTGraph
Unparserdefinitions
Parserdefinitions
Model-Driven Front-End Program Transformation Back-End
Generic Aspect Metamodel
Aspect SourceMetamodel
Aspect Source Model
RSLMetamodel
RSL Model
InputSourceProgram
Analyzer
TransformedTargetProgram
50
GenAWeave in Action
Symbol Table
ATL ModelTransformation
Engine
Pretty Printer
DMS ProgramTransformation
Engine
Generic Model Transform Library
Concrete RSL Transform
Lexer/Parser
Domain Reader
AspectSourceProgram
ASTGraph
Unparserdefinitions
Parserdefinitions
Model-Driven Front-End Program Transformation Back-End
Generic Aspect Metamodel
Aspect SourceMetamodel
Aspect Source Model
RSLMetamodel
RSL Model
InputSourceProgram
Analyzer
TransformedTargetProgram
51
GenAWeave in Action
Symbol Table
ATL ModelTransformation
Engine
Pretty Printer
DMS ProgramTransformation
Engine
Generic Model Transform Library
Concrete RSL Transform
Lexer/Parser
Domain Reader
AspectSourceProgram
ASTGraph
Unparserdefinitions
Parserdefinitions
Model-Driven Front-End Program Transformation Back-End
Generic Aspect Metamodel
Aspect SourceMetamodel
Aspect Source Model
RSLMetamodel
RSL Model
InputSourceProgram
Analyzer
TransformedTargetProgram
52
GenAWeave in Action
Symbol Table
ATL ModelTransformation
Engine
Pretty Printer
DMS ProgramTransformation
Engine
Generic Model Transform Library
Concrete RSL Transform
Lexer/Parser
Domain Reader
AspectSourceProgram
ASTGraph
Unparserdefinitions
Parserdefinitions
Model-Driven Front-End Program Transformation Back-End
Generic Aspect Metamodel
Aspect SourceMetamodel
Aspect Source Model
RSLMetamodel
RSL Model
InputSourceProgram
Analyzer
TransformedTargetProgram
53
GenAWeave in Action
Symbol Table
ATL ModelTransformation
Engine
Pretty Printer
DMS ProgramTransformation
Engine
Generic Model Transform Library
Concrete RSL Transform
Lexer/Parser
Domain Reader
AspectSourceProgram
ASTGraph
Unparserdefinitions
Parserdefinitions
Model-Driven Front-End Program Transformation Back-End
Generic Aspect Metamodel
Aspect SourceMetamodel
Aspect Source Model
RSLMetamodel
RSL Model
InputSourceProgram
Analyzer
TransformedTargetProgram
54
GenAWeave in Action
Symbol Table
ATL ModelTransformation
Engine
Pretty Printer
DMS ProgramTransformation
Engine
Generic Model Transform Library
Concrete RSL Transform
Lexer/Parser
Domain Reader
AspectSourceProgram
ASTGraph
Unparserdefinitions
Parserdefinitions
Model-Driven Front-End Program Transformation Back-End
Generic Aspect Metamodel
Aspect SourceMetamodel
Aspect Source Model
RSLMetamodel
RSL Model
InputSourceProgram
Analyzer
TransformedTargetProgram
55
GenAWeave in Action
Symbol Table
ATL ModelTransformation
Engine
Pretty Printer
DMS ProgramTransformation
Engine
Generic Model Transform Library
Concrete RSL Transform
Lexer/Parser
Domain Reader
AspectSourceProgram
ASTGraph
Unparserdefinitions
Parserdefinitions
C2
C1
C1Generic Aspect
Metamodel
Aspect SourceMetamodel
Aspect Source Model
RSLMetamodel
RSL Model
InputSourceProgram
Analyzer
TransformedTarget Program
C4
C4
C2
C2
C3 C3
C3C3
C1
Model-Driven Front-End Program Transformation Back-End
56
Integration into Eclipse
The editor indicates the misspelling of the pointcut name timer_around_loops
Syntax highlighting
Error reporting
Outline view
57
Outline of Presentation
Motivation
Approach
Research Goals
Evaluation
Lack of Modularization (Legacy software decay)
Several Billion lines of Legacy code
Program Transformation
ChallengesLack of Reusability
+Accidental Complexities
Model-Driven Engineering Generic Aspect Weaver
Framework
Aspect FORTRAN Aspect Pascal
58
Experimental Evaluation – Case Study Two weavers were constructed; one each for Object Pascal and
FORTRAN. In addition, metamodels for aspect extensions of Java and C++ were also built.
A subset (e.g., primitive pointcuts like call, execution, loop, withincode, and args) of standard AOP features was built into both weavers in an AspectJ-like style.
// The user wants to perform another search
procedure TLangMan.SearchAgainClick(Sender: TObject);
begin
// Perform an update if an edit occurred that //might change the focus of the listview
if EditMadeDirtyBit then
SaveDBControls;
…
end;
59
Aspect Specification
domain ObjectPascal;
aspect probe_dirty_bit {
pointcut proc_click(): execution(procedure *.*Click(*:*));
before() : proc_click() {
if EditMadeDirtyBit
then SaveDBControls ;
}
}
Note the wildcard *, internally supported by reusable PARLANSE external function name_ends_with
60
Aspect Model – XMI representation (internal)
<?xml version="1.0" encoding="ISO-8859-1"?><APascal xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="APascal" xmlns:_1="GAspect" location="1:1-11:2" name="probe_dirty_bit">
<domain location="1:1-1:21" name="ObjectPascal"/> <pointcut location="5:3-5:63" name="proc_click"> <pctexpr xsi:type="ExecExpr" location="5:26-5:62"> <funcOrProcSig xsi:type="ProcedureDef" location="5:36-5:61" name="*Click" classifier="*"> <paramdefs location="5:57-5:60" name="*" type="*"/> </funcOrProcSig> </pctexpr> </pointcut> <advice xsi:type="_1:BeforeAdvice" location="7:3-10:4"
pctname="//@pointcut.0"> <advStmt xsi:type="_1:OpaqueStatement" location="8:5-9:33" stmt="if
EditMadeDirtyBit
 then SaveDBControls;"/> </advice></APascal>
61
Model Transformation Rule (method-exec join point) lazy rule PointCutToExternalPattern {
froms : APascal!Pointcut
tot : RSL!ExternalPattern (
dname <- 'ObjectPascal',eptext <- s.extPatternName,ptoken <- 'statement_list',phead <- ph
),ph : RSL!PatternHead (
name <- s.extPatternName,
slist : RSL!PatternParameter (name <- 'slist',referTo <- 'statement_list'
),proceed_bef : RSL!PatternParameter (
name <- 'proceed_bef',referTo <- 'statement_list'
),proceed_aft : RSL!PatternParameter (
name <- 'proceed_aft',referTo <- 'statement_list'
), ...
62
Generated RSL (internal)default base domain ObjectPascal.pattern find(id : IDENTIFIER) : IDENTIFIER = id if name_ends_with(id, search_id()).pattern search_id() : IDENTIFIER = " Click ".pattern before_advice_stmt() : statement_list = "if EditMadeDirtyBit then SaveDBControls;".external pattern around_advice_exec(slist : statement_list, proceed_bef : statement_list, proceed_aft :
statement_list) : statement_list ='around_advice_exec' in domain ObjectPascal.external condition name_ends_with( routine_name : IDENTIFIER, search_id : IDENTIFIER)= 'name_ends_with'.rule proc_click( id1 : IDENTIFIER, id2 : IDENTIFIER, fps : formal_parameters, slist : statement_list): implementation_declaration-> implementation_declaration= "procedure \id1 . \find\(\id2\) \fps ; begin \slist end;"-> "procedure \id1 . \id2 \fps ; begin \around_advice_exec\(\slist \, \before_advice_stmt\(\) \, \
after_advice_stmt\(\) \) end;" if slist == around_advice_exec(slist, before_advice_stmt(), after_advice_stmt()) .pattern after_advice_stmt() : statement_list = "".public ruleset probe_dirty_bit = {proc_click}.
63
Join Point for LoopsIt is often desired to monitor the performance of loops for some high-performance scientific applications. Harbulot et al. first introduced this concept in an extension to AspectJ [Harbulot and Gurd, 2005].
According to our definition, the join point for a loop has the following signature:
<loop_name>(init::<val>, exit::<val>, stride::<val>)
Init specifies the loop initialization value, exit specifies the loop termination value and stride specifies the loop increment counter.
aspect AddTimerAroundLoops { pointcut loop_timer_(): execution(do(init::1,exit::10,stride:*)); void around(): loop_timer_() { time_begin = MPI_Wtime() proceed() time_end = MPI_Wtime() } }
64
Discussion of Experimental Results
FEATURESAdvice Pointcuts
before after around call exec withincode loop args with
Aspect Pascal
AspectFORTRAN
For translating a method call join point in FORTRAN and Object Pascal, 230 lines of model transformation code (out of 280 LOC) were reused without any modification. The remaining 50 LOC were reused with minor customization.
For translating a loop execution join point in FORTRAN and Object Pascal, 265 LOC out of 305 were reused without any modification, while the remaining 40 LOC were reused with minor customization
65
Discussion of Experimental Results
Likewise, the front-end of all weavers share a generic metamodel (i.e., GAspect). Out of 550 LOC used for defining the front-end metamodel (KM3 and TCS specifications), nearly 280 LOC were shared among the two weavers.
In additions to front-end reuse, GenAWeave provides a reusable library of back-end external functions. Currently, there are 11 such functions that are shared by the Object Pascal and FORTRAN weavers.
66
FRONT-END REUSABILITYMETAMODEL KM3+TCS (LOC) Shared LOC Percentage
Aspect Pascal 565280
49.5
Aspect FORTRAN 550 50.1
MODEL TRANSFORMATION
ATL (LOC) Shared LOC Percentage
Aspect Pascal 18901290
68.2
Aspect FORTRAN 1585 81.3
BACK-END REUSABILITY
PARLANSE FUNCTIONS Total LOCShared
LOCNo. of Shared
FunctionsPercentage
Aspect Pascal 873310 11
35.5
Aspect FORTRAN 775 40
OVERALL REUSABILITYOVERALL LOC Shared LOC Percentage
Aspect Pascal 33281880
56.4
Aspect FORTRAN 2910 64.6
Reusability Summary
67
GenAWeave on the Web
http://www.cis.uab.edu/softcom/genaweave
Software and Video demos available at -
68
Future Work Improve the generality of the framework.
Metamodel inheritance
Rule inheritance Apply and evaluate the framework towards construction of other aspect
weavers for legacy and modern programming languages. Applying the approach to domain-specific aspect languages (DSALs) Applying the approach towards high-performance scientific computing applications,
especially towards specialization of scientific libraries Investigate other software engineering techniques like generalized refactoring
and generic aspect mining based on the knowledge gained in developing a generic framework for aspect weaving.
GAspect
APascal ARuby AFortran
GAspect
APascal ARuby
AFortranOO-A
69
Core Contributions
An exploration of the underlying science to support a generic source model for AOP, including higher-order transformations, and high-level aspect language as a foundation for reusable program transformation and analysis.
A generative methodology to permit construction of aspect weavers for multiple languages; provide a language experimentation environment for investigating ideas in new paradigms without constructing all of the underlying parsing and transformation mechanisms from scratch.
70
Lessons Learned Lesson 1 - Generalizing the weaver front-end
Parts of the aspect language front-end can be reused by making it generic
Lesson 2 - Improving the generic metamodel Using model and rule inheritance
Lesson 3 - Use of generic interfaces in the rule generator This helps to improve the rule generator library with
minimum customization Lesson 4 - Modeling can be suitably applied to PTEs
Higher-order transforms could be used to generate lower-order program transformation rules
71
Lessons Learned Lesson 5 - Changing the target PTE
Source aspect metamodel need not be altered even if one chooses to opt for a different target PTE, may also use a pivot metamodel for PTEs
Lesson 6 - Changing the source language Conversely, for every new aspect language, one needs
to add the appropriate metamodel extensions to the GAspect metamodel, but no change to the target metamodel is needed
Lesson 7 - Automation of rule generator It is possible to extract the join point model from
transformation rules, and model it in terms of the concrete syntax. In future, can also use a model weaver to map the differences in concrete syntax
72
PublicationsJournal Papers: 4 (2 under review), Conference and Workshop papers: 10 Suman Roychoudhury, Jeff Gray, Jing Zhang, Purushotham Bangalore, and Anthony Skjellum, “Modularizing Scientific Libraries with
Aspect-Oriented and Generative Programming Techniques,” Acta Electrotechnica et Informatica, (accepted Jan, 2008). Suman Roychoudhury, Jeff Gray, and Frederic Jouault, “Model-Driven Aspect Weaving Framework,” Transactions of Aspect-Oriented
Software Development (conditional acceptance, Mar 2008). Suman Roychoudhury, Jeff Gray, Jing Zhang, Purushotham Bangalore, and Anthony Skjellum, “A Program Transformation Technique to
Support Aspect-Oriented Programming within C++ Templates”, International Journal of Computer Science and Software Technology, (under review since Dec, 2007).
Faizan Javed, Marjan Mernik, Jeff Gray, Jing Zhang, Barrett R. Bryant, and Suman Roychoudhury, “Using a Program Transformation Engine to Infer Types in a Metamodel Recovery System,” Acta Electrotechnica et Informatica, (accepted Sep, 2007).
Jeff Gray and Suman Roychoudhury, “A Technique for Constructing Aspect Weavers Using a Program Transformation Engine,” International Conference on Aspect-Oriented Software Development, Lancaster, UK, March 22-26, 2004, pp. 36-45 Alabama IEEE “Best Paper of 2004” Award (1st place).
Suman Roychoudhury, Jeff Gray, and Frederic Jouault, “Model-based Aspect Weaver Construction,” 4th International Workshop on Software Language Engineering, Nashville, TN, Oct 1-2, 2007.
Xiaoqing Wu, Barrett Bryant, Jeff Gray, Suman Roychoudhury, and Marjan Mernik, “Separation of Concerns in Compiler Development using Aspect-Orientation,” ACM Symposium for Applied Computing – Programming for Separation of Concerns Track, Dijon, Bourgogne, France, April 2006.
Xiaoqing Wu, Suman Roychoudhury, Barrett Bryant, Jeff Gray, and Marjan Mernik, “A Two-Dimensional Separation of Concerns for Compiler Construction,” ACM Symposium for Applied Computing– Programming for Separation of Concerns Track, Santa Fe, NM, March 2005, pp. 1365-1369.
Suman Roychoudhury and Jeff Gray, “Towards Language-Independent Weaving Using Grammar Adapters,” AOSD Workshop on Linking Aspect Technology and Evolution, Chicago, IL, March 2005.
Hui Wu, Jeff Gray, Suman Roychoudhury, and Marjan Mernik, “Weaving a Debugging Aspect into Domain-Specific Language Grammars,” ACM Symposium for Applied Computing – Programming for Separation of Concerns Track, Santa Fe, NM, March 2005, pp. 1370-1374.
Suman Roychoudhury, “A Language-Independent Approach to Software Maintenance Using Grammar Adapters,” Doctoral Symposium, Object-Oriented Programming, Systems, Languages, and Applications Companion Vancouver, BC, October 2004, pp. 52-53.
Jeff Gray, Jing Zhang, Yuehua Lin, Suman Roychoudhury, Hui Wu, Rajesh Sudarsan, Aniruddha Gokhale, Sandeep Neema, Feng Shi, and Ted Bapty, “Model-Driven Program Transformation of a Large Avionics Framework,” Generative Programming and Component Engineering, Springer-Verlag LNCS 3286, Vancouver, BC, October 2004, pp. 361-378.
Shairaj Shaik, Raymond Corvin, Rajesh Sudarsan, Faizan Javed, Qasim Ijaz, Suman Roychoudhury, Jeff Gray, and Barrett Bryant, “SpeechClipse - An Eclipse Speech Plug-In,” Eclipse Technology eXchange Workshop, Anaheim, CA, October 2003.
Suman Roychoudhury, Jeff Gray, Hui Wu, Jing Zhang, and Yuehua Lin, “A Comparative Analysis of Meta-programming and Aspect-Orientation,” 41st Annual ACM SE Conference, Savannah, GA, March 7-8, 2003, pp. 196-201.
73
Conclusion The research raised several key challenges in designing a
generic framework to construct aspect weavers
The research demonstrated an approach that combines PTEs with MDE to construct aspect weavers for legacy programming languages
The combination of the two distinct technical spaces (i.e., PTEs and MDE) offered more possibilities than each considered separately
74
Back-up Slides
75
Specialization of HPL
HPL is a software package that solves a random dense linear system (LU factorization) on distributed-memory architectures
Depending on the machine architecture and the availability of the type of BLAS (either FBLAS or CBLAS) or VSIPL, the software package mostly relies on preprocessor directives to make specific calls to appropriate linear algebra subroutines.
76
HPL Specialization using DMS
HPL-ALL
1 Macro Extraction
Remove all preprocessor directives, i.e., calls toFBLAS, CBLAS and VSIPL
HPL-CBLAS
2 Specialization
Specialize to HPL-CBLAS,HPL-FBLAS, HPL-VSIPL, i.e., a software product line
HPL-FBLAS
HPL-VSIPL
HPL Core
77
1. external pattern remove_macro(tran_unit:translation_unit,id:identifier):2. translation_unit = 'remove_macro' in domain Cpp~ISO14882c1998. 3. external pattern add_macro(tran_unit:translation_unit,id:identifier):4. translation_unit = 'add_macro' in domain Cpp~ISO14882c1998. 5. pattern FBLAS(): identifier = "HPL_CALL_FBLAS". 6. pattern CBLAS(): identifier = "HPL_CALL_CBLAS". 7. pattern VSIPL(): identifier = "HPL_CALL_VSIPL". 8. rule del_cblas(t_u: translation_unit): translation_unit-> translation_unit9. = t_u -> remove_macro(t_u,CBLAS())10. if tran_unit ~= remove_macro(t_u,CBLAS()). 11. rule del_vsip(t_u: translation_unit): translation_unit-> translation_unit12. = t_u -> remove_macro(t_u,VSIPL())13. if t_u ~= remove_macro(t_u,VSIPL()). 14. rule del_fblas(t_u: translation_unit): translation_unit-> translation_unit15. = t_u -> remove_macro(t_u,FBLAS())16. if t_u ~= remove_macro(t_u,FBLAS()). 17. rule add_cblas(t_u: translation_unit): translation_unit-> translation_unit18. = t_u -> add_macro(t_u,CBLAS())19. if t_u ~= add_macro(t_u,CBLAS()). 20. rule add_vsip(t_u: translation_unit): translation_unit -> translation_unit21. = t_u -> add_macro(t_u,VSIPL())22. if t_u ~= add_macro(t_u,VSIPL()). 23. rule add_fblas(t_u: translation_unit): translation_unit-> translation_unit24. = t_u -> add_macro(t_u,FBLAS())25. if t_u ~= add_macro(t_u,FBLAS()).
DMS Macro-Extraction and Specialization Rule
78
Before and After Specialization with CBLASSize of HPL BLAS (before) Size of HPL BLAS (after)
Number of lines of code: 1719 Number of directive lines: 390 Number of empty lines: 172 Number of comment lines: 731 Number of empty comment lines: 327
Number of lines of code: 40 Number of directive lines: 50 Number of empty lines: 10 Number of comment lines: 731 Number of empty comment lines: 327
Total number of lines: 3339 Total number of lines: 1158
79
Time Analysis
HPL-ALL vs HPL-CBLAS Time Analysis (NxTime)
0
200
400
600
800
1000
Matrix Dimension NxN
Tim
e (
Se
co
nd
s)
HPL-ALL
HPL-CBLAS
HPL-ALL 14.58 41.51 177.11 877.12
HPL-CBLAS 5.5 19.01 97.01 878.57
5000 10000 20000 40000
80
Performance Analysis
HPL-ALL vs HPL-CBLAS Performance Analysis (NxGFlops)
0
10
20
30
40
50
60
Matrix Dimension NxN
GF
lop
s
HPL-ALL
HPL-CBLAS
HPL-ALL 5.719 16.11 30.02 48.54 54.91
HPL-CBLAS 15.23 34.82 54.88 48.57 56.93
5000 10000 20000 40000 60000