Title: GenAWeave: A Generic Aspect Weaver Framework based on Model-Driven Program Transformation
1GenAWeave A Generic Aspect Weaver Framework
based on Model-Driven Program Transformation
Suman Roychoudhury roychous_at_cis.uab.edu
Ph.D. Dissertation Defense http//www.cis.uab.edu/
softcom/GenAWeave/
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
2Outline of Presentation
Lack of Modularization (Legacy software decay)
Several Billion lines of Legacy code
Motivation
Challenges
Lack of Reusability Accidental Complexities
Program Transformation
Research Goals
Approach
Model-Driven Engineering
Generic Aspect Weaver Framework
Evaluation
Aspect FORTRAN
Aspect Pascal
3Challenges with Maintaining Legacy Systems
50 of the annual 230 billion spent on all
software budgets
Commercial Scientific Applications
gt 200 Billion Lines of Legacy code
A need for constant fixes
Migration is not an easy task !
Huge investment in infrastructure, effort,
manpower
Limited knowledge of the entire system
Too much time required to make simple changes
4Laws 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
5Tools 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.
6Crosscutting Concerns
XML Parsing in Apache Tomcat Server
Profiling in Apache Tomcat Server
http//www.parc.com/research/projects/aspectj/
7Separation of Crosscutting Concerns - AOP
Module A
Module B
Crosscutting concerns CC1/CC2 superimposed on
Module A and B
CC1
CC2
Concern CC2
Concern CC1
8Aspect Weaving
Aspect Specification
Aspect Program
Aspect Weaver
Base Program
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.
9Aspect Weavers Current Limitations
Several tools and language extensions have been
developed to enable aspect weaving
- However
- Specific to a few popular languages (e.g., Java)
- New tools are developed from scratch without
preserving knowledge of previous construction - No emphasis on reusability in a different
language and platform context - Generally do not support custom aspect weaving
functionality (e.g., join point for loops, with
construct in Object Pascal)
10Research 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?
11Outline of Presentation
Lack of Modularization (Legacy software decay)
Several Billion lines of Legacy code
Motivation
Challenges
Lack of Reusability Accidental Complexities
Program Transformation
Research Goals
Approach
Model-Driven Engineering
Generic Aspect Weaver Framework
Evaluation
Aspect FORTRAN
Aspect Pascal
12Challenges in Language-Independent Legacy
Adaptation
Challenge C1 The Parser Construction
Problem Challenge C2 The Weaver Construction
Problem Challenge C3 Accidental Complexities
of Transformation
Specifications Challenge C4 Language-Independen
t Generalization of
Transformation Objectives
13Challenge C1 The Parser Construction
Problem
- Scalability
- Extensibility
- Reusability
- C
- Object Pascal
- Fortan
- Cobol
- Ada
- Jovial
- VHDL
14Challenge C2 The Weaver Construction
Problem
Transformation System
- Availability of AST representation
- Low-level Transformation Infrastructure
pattern probe_id_pattern1() unqualified_id
"printf". rule insert_probe1 (s statement_seq)
function_body -gt function_body " \s
" -gt " \probe_id_pattern1\(\)
(\"Entering Method\") \s ".
Higher- order Transforms
Lower- order Transforms
Parser
Legacy System
Aspect Language
User Inputs
15Challenge 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
16Challenge C4 Language-Independent
Generalization of Transformation Objectives
Transformation System
rule BeforeAdvice2Pattern from s
APascal!BeforeAdvice to t RSL!Pattern (
phead lt- ph, ptext lt- spt,
token lt- 'statement_list', ), ph
RSL!PatternHead ( name lt- 'before_
advice_stmt' ), ...
Higher- order Transforms
Lower- order Transforms
Parser
Aspect Language
User Inputs
17Outline of Presentation
Lack of Modularization (Legacy software decay)
Several Billion lines of Legacy code
Motivation
Challenges
Lack of Reusability Accidental Complexities
Program Transformation
Research Goals
Approach
Model-Driven Engineering
Generic Aspect Weaver Framework
Evaluation
Aspect FORTRAN
Aspect Pascal
18Research Goals
Goal 2 Reuse core transformations across
language domains using higher-order
transforms (C2, C4)
Goal 1 Raise the level of abstraction (aspect
layering) for end-programmers (C3)
Program Transformation Engine (C1,C2)
Higher-Order Transforms
Low-Level xForm constructs
High-level language constructs
- Increase the level of abstraction and reuse the
core transformations rules across language
domains
Aspect Weavers
19Model-Driven Program Transformation based Aspect
Weaving Framework
- Reuses existing parsers
- Reuses several artifacts while creating weavers
from one language to another
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
20Outline of Presentation
Lack of Modularization (Legacy software decay)
Several Billion lines of Legacy code
Motivation
Challenges
Lack of Reusability Accidental Complexities
Program Transformation
Research Goals
Approach
Model-Driven Engineering
Generic Aspect Weaver Framework
Evaluation
Aspect FORTRAN
Aspect Pascal
21Overview of Approach
Current State-of-the-Art Techniques
Program Transformation Back-End
Model-Driven Front-End
Model Transformation
GenAWeave in Action
22Current 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
23Current State-of-the-ArtSourceWeave.Net
- Uses Microsofts CodeDom Architecture as the
underlying AST Representation - Uses XML descriptor to specify interaction
between aspects and .Net components
- 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
http//www.dsg.cs.tcd.ie/dynamic/?category_id438
24Current State-of-the-ArtWeave.Net
- 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
http//www.dsg.cs.tcd.ie/dynamic/?category_id194
25Current State-of-the-Art Aspect Cobol
- 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
http//homepages.cwi.nl/ralf/AspectCobol/
26Current State-of-the-Art Aspicere GCC 4.0
- 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
http//users.ugent.be/badams/aspicere/
27Overview of Approach
Current State-of-the-Art Techniques
Program Transformation Back-End
Model-Driven Front-End
Model Transformation
GenAWeave in Action
28Program Transformation Back-End
Source Program
parser definitions
Parser
AST Graph
Symbol Table
Analyzer
Domain Definitions
unparser definitions
Program Transformation Rules
Target Program
Pretty Printer
DMS Transformation Engine
1. default base domain ObjectPascal. 2. private rule insert_probe(stmt_list statement_list) 3. function_body ? function_body 4. "begin \stmt_list end" ? 5. "begin ShowMessage(\"Entering Method\") \stmt_list end". 6. public ruleset TraceAllFunctions insert_probe
29Program Transformation based Aspect Weaving
(Language-specific weavers)
Experiment conducted on support utilities for a
commercial distributed application written in
Object Pascal
- 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
30Object Pascal Example
default base domain ObjectPascal. external
condition func_sig_has_click(id1IDENTIFIER,id2ID
ENTIFIER) 'func_sig_has_click'. pattern
advice(sliststatement_list) statement_list
"if EditMadeDirtyBit then
SaveDBControls
\slist". pattern isClick(idIDENTIFIER)
IDENTIFIER id if func_sig_has_click(click(),
id). pattern click () IDENTIFIER "Click". rule
probe_dirty_bit (id1IDENTIFIER,
id2IDENTIFIER,fpsformal_parameters,
sliststatement_list) implementation_decl -gt
implementation_decl "procedure \id1 .
\isClick\(\id2\) \fps begin \slist
end" -gt "procedure \id1 . \id2 \fps
begin \advice\(\slist\) end". if
modsliststatement_list .slist
matches "\statement_list \advice\(\modslist\)".
public ruleset applyrules probe_dirty_bit .
(define func_sig_has_click (lambda
RegistryMatchingCondition (let ((
const_string (reference string)
(ASTGetString arguments1))
( search_string (reference string)
(ASTGetString arguments2))
( scanner StringScanScan
(StringScanMakeScan search_string))
) (value (while (
(StringScanEnd? (. scanner)) f)
(ifthenelse (StringScanMatchStr
ing? (. scanner) const_string)
(return t)
(StringScanAdvance (. scanner))
)ifthenelse )while f )value )let
)lambda )define
// 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
31Justification 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.
32Challenges 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)
33Overview of Approach
Current State-of-the-Art Techniques
Program Transformation Back-End
Model-Driven Front-End
Model Transformation
GenAWeave in Action
34Model-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.
35Metamodel for Aspect Pascal
36KM3 and TCS Specification
class AspectPascal extends LocatedElement attribute name String reference domain container Domain reference pointcuts1- container Pointcut oppositeOf aspect reference advice1- container Advice oppositeOf aspect class Pointcut extends Element attribute name String reference aspect AspectPascal oppositeOf pointcut reference paramdefs container ParameterDef reference exprs1- container Expression oppositeOf pointcut abstract class Advice extends LocatedElement reference aspect AspectPascal oppositeOf advice reference pointcut Pointcut reference paramdefs container ParameterDef reference stmts1- container Statement
37KM3 and TCS Specification
template AspectPascal main "aspect" name "" pointcut advice "" template Pointcut context addToContext "pointcut" name "(" paramdefsseparator "," ")" "" exprs separator "" "" template Advice abstract template BeforeAdvice "before" "(" paramdefs separator "," ")" "" ... template AfterAdvice "after" "(" paramdefs separator "," ")" "" ...
38Support for Generic Front-End (Aspect Pascal)
39Support for Generic Front-End (Aspect FORTRAN)
40(No Transcript)
41Target Metamodel (RSL)
42Overview of Approach
Current State-of-the-Art Techniques
Program Transformation Back-End
Model-Driven Front-End
Model Transformation
GenAWeave in Action
43Model Transformation
Model-Driven Engineering (MDE) Technical Space
(TS)
Grammarware TS
Grammarware TS
M3
EBNF
EBNF
KM3
Aspect.gGrammar
Aspect Metamodel
RSL Metamodel
RSL.g Grammar
M2
Myaspect.ap AspectPascal
Myaspect Model
MyRsl Model
MyRsl.rsl RSL program
M1
Extraction
Injection
Aspect2RSL Transformation
M1 model level M2 metamodel level M3
meta-metamodel level
44ATL Transformations
rule AfterAdvice2Pattern from s
Aspect!AfterAdvice to t Rsl!Pattern
( ptoken lt-'statement_list', ptext
lt- s.advStmt.stmt ... ),
...
rule Aspect2Rsl from s
Aspect!Aspect to t Rsl!Rsl (
domain lt- s.domain, pattern lt-
s.advice, rule lt- s.pointcut,
ruleset lt- rs ), rs Rsl!RuleSet (
rsname lt- s.aname, rname lt-
s.pointcut-gt collect(ee).pctname),
Core transformation library call, exec, loop,
with, withincode (i.e., one transformation for
each type of pointcut)
- The transformations generate the corresponding
RSL rule - for the given aspect
45Generalizing 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
46Support 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 RegistryMatchingCondition (let ( ( search_string (reference string) (GraphHGHandlingGetString arguments1)) sub_string string search_string_size natural search_id_size natural start_index natural ) (value ( ( search_string_size (size (_at_(ASTGetString arguments1)))) ( search_id_size (size (_at_(ASTGetString arguments2)))) ( start_index (- search_string_size search_id_size)) ( sub_string (StringsSubstring (ASTGetString arguments1) ( start_index 1) search_id_size)) (ifthen( sub_string (_at_(ASTGetString arguments2))) (return t) )ifthen (return f) ) f )value )let )lambda )define
48Overview of Approach
Current State-of-the-Art Techniques
Program Transformation Back-End
Model-Driven Front-End
Model Transformation
GenAWeave in Action
49GenAWeave in Action
Input Source Program
Generic Aspect Metamodel
Parser definitions
Lexer/ Parser
Symbol Table
AST Graph
Generic Model Transform Library
Aspect Source Metamodel
RSL Metamodel
Domain Reader
Analyzer
Unparser definitions
Transformed Target Program
Pretty Printer
Aspect Source Model
RSL Model
Aspect Source Program
Concrete RSL Transform
DMS Program Transformation Engine
ATL Model Transformation Engine
Program Transformation Back-End
Model-Driven Front-End
50GenAWeave in Action
Input Source Program
Generic Aspect Metamodel
Parser definitions
Lexer/ Parser
Symbol Table
AST Graph
Generic Model Transform Library
Aspect Source Metamodel
RSL Metamodel
Domain Reader
Analyzer
Unparser definitions
Transformed Target Program
Pretty Printer
Aspect Source Model
RSL Model
Aspect Source Program
Concrete RSL Transform
DMS Program Transformation Engine
ATL Model Transformation Engine
Program Transformation Back-End
Model-Driven Front-End
51GenAWeave in Action
Input Source Program
Generic Aspect Metamodel
Parser definitions
Lexer/ Parser
Symbol Table
AST Graph
Generic Model Transform Library
Aspect Source Metamodel
RSL Metamodel
Domain Reader
Analyzer
Unparser definitions
Transformed Target Program
Pretty Printer
Aspect Source Model
RSL Model
Aspect Source Program
Concrete RSL Transform
DMS Program Transformation Engine
ATL Model Transformation Engine
Program Transformation Back-End
Model-Driven Front-End
52GenAWeave in Action
Input Source Program
Generic Aspect Metamodel
Parser definitions
Lexer/ Parser
Symbol Table
AST Graph
Generic Model Transform Library
Aspect Source Metamodel
RSL Metamodel
Domain Reader
Analyzer
Unparser definitions
Transformed Target Program
Pretty Printer
Aspect Source Model
RSL Model
Aspect Source Program
Concrete RSL Transform
DMS Program Transformation Engine
ATL Model Transformation Engine
Program Transformation Back-End
Model-Driven Front-End
53GenAWeave in Action
Input Source Program
Generic Aspect Metamodel
Parser definitions
Lexer/ Parser
Symbol Table
AST Graph
Generic Model Transform Library
Aspect Source Metamodel
RSL Metamodel
Domain Reader
Analyzer
Unparser definitions
Transformed Target Program
Pretty Printer
Aspect Source Model
RSL Model
Aspect Source Program
Concrete RSL Transform
DMS Program Transformation Engine
ATL Model Transformation Engine
Program Transformation Back-End
Model-Driven Front-End
54GenAWeave in Action
Input Source Program
Generic Aspect Metamodel
Parser definitions
Lexer/ Parser
Symbol Table
AST Graph
Generic Model Transform Library
Aspect Source Metamodel
RSL Metamodel
Domain Reader
Analyzer
Unparser definitions
Transformed Target Program
Pretty Printer
Aspect Source Model
RSL Model
Aspect Source Program
Concrete RSL Transform
DMS Program Transformation Engine
ATL Model Transformation Engine
Program Transformation Back-End
Model-Driven Front-End
55GenAWeave in Action
Input Source Program
C4
C1
Generic Aspect Metamodel
Parser definitions
Lexer/ Parser
C2
Symbol Table
C4
C3
C3
AST Graph
C2
Generic Model Transform Library
Aspect Source Metamodel
RSL Metamodel
Domain Reader
Analyzer
C1
Unparser definitions
Transformed Target Program
Pretty Printer
Aspect Source Model
RSL Model
Aspect Source Program
Concrete RSL Transform
C3
C3
DMS Program Transformation Engine
ATL Model Transformation Engine
C1
C2
Program Transformation Back-End
Model-Driven Front-End
56Integration into Eclipse
Outline view
Syntax highlighting
Error reporting
The editor indicates the misspelling of the
pointcut name timer_around_loops
57Outline of Presentation
Lack of Modularization (Legacy software decay)
Several Billion lines of Legacy code
Motivation
Challenges
Lack of Reusability Accidental Complexities
Program Transformation
Research Goals
Approach
Model-Driven Engineering
Generic Aspect Weaver Framework
Evaluation
Aspect FORTRAN
Aspect Pascal
58Experimental 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
59Aspect 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
60Aspect Model XMI representation (internal)
lt?xml version"1.0" encoding"ISO-8859-1"?gt ltAPasc
al xmiversion"2.0" xmlnsxmi"http//www.omg.org
/XMI" xmlnsxsi"http//www.w3.org/2001/XMLSchema-
instance" xmlns"APascal" xmlns_1"GAspect"
location"11-112" name"probe_dirty_bit"gt
ltdomain location"11-121" name"ObjectPascal"/gt
ltpointcut location"53-563"
name"proc_click"gt ltpctexpr
xsitype"ExecExpr" location"526-562"gt
ltfuncOrProcSig xsitype"ProcedureDef"
location"536-561" name"Click"
classifier""gt ltparamdefs
location"557-560" name"" type""/gt
lt/funcOrProcSiggt lt/pctexprgt lt/pointcutgt
ltadvice xsitype"_1BeforeAdvice"
location"73-104" pctname"//_at_pointcut.0"gt
ltadvStmt xsitype"_1OpaqueStatement"
location"85-933" stmt"if EditMadeDirtyBitxD
xA then SaveDBControls"/gt
lt/advicegt lt/APascalgt
61Model Transformation Rule (method-exec join point)
lazy rule PointCutToExternalPattern from s
APascal!Pointcut to t RSL!ExternalPattern
( dname lt- 'ObjectPascal', eptext lt-
s.extPatternName, ptoken lt- 'statement_list',
phead lt- ph ), ph RSL!PatternHead
( name lt- s.extPatternName, slist
RSL!PatternParameter ( name lt-
'slist', referTo lt- 'statement_list' ), pro
ceed_bef RSL!PatternParameter ( name lt-
'proceed_bef', referTo lt- 'statement_list' ),
proceed_aft RSL!PatternParameter ( name
lt- 'proceed_aft', referTo lt-
'statement_list' ), ...
62Generated 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". e
xternal 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-gt implementation_decl
aration "procedure \id1 . \find\(\id2\) \fps
begin \slist end" -gt "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.
63Join Point for Loops
It 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
ltloop_namegt(initltvalgt, exitltvalgt, strideltvalgt)
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(init1,exit10,stride)) void around() loop_timer_() time_begin MPI_Wtime() proceed() time_end MPI_Wtime()
64Discussion of Experimental Results
FEATURES Advice Advice Advice Pointcuts Pointcuts Pointcuts Pointcuts Pointcuts Pointcuts
FEATURES before after around call exec withincode loop args with
Aspect Pascal ? ? ? ? ? ? ? ? ?
Aspect FORTRAN ? ? ? ? ? ? ? ? ?
- 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
65Discussion 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.
66Reusability Summary
FRONT-END REUSABILITY FRONT-END REUSABILITY FRONT-END REUSABILITY FRONT-END REUSABILITY FRONT-END REUSABILITY
METAMODEL KM3TCS (LOC) Shared LOC Shared LOC Percentage
Aspect Pascal 565 280 280 49.5
Aspect FORTRAN 550 280 280 50.1
MODEL TRANSFORMATION ATL (LOC) Shared LOC Shared LOC Percentage
Aspect Pascal 1890 1290 1290 68.2
Aspect FORTRAN 1585 1290 1290 81.3
BACK-END REUSABILITY BACK-END REUSABILITY BACK-END REUSABILITY BACK-END REUSABILITY BACK-END REUSABILITY
PARLANSE FUNCTIONS Total LOC Shared LOC No. of Shared Functions Percentage
Aspect Pascal 873 310 11 35.5
Aspect FORTRAN 775 310 11 40
OVERALL REUSABILITY OVERALL REUSABILITY OVERALL REUSABILITY OVERALL REUSABILITY OVERALL REUSABILITY
OVERALL LOC Shared LOC Shared LOC Percentage
Aspect Pascal 3328 1880 1880 56.4
Aspect FORTRAN 2910 1880 1880 64.6
67GenAWeave on the Web
- Software and Video demos available at -
http//www.cis.uab.edu/softcom/genaweave
68Future 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.
69Core 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.
70Lessons 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
71Lessons 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
72PublicationsJournal 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.
73Conclusion
- 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
Thank you
74 75Specialization 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.
76HPL Specialization using DMS
HPL-CBLAS
2 Specialization
1 Macro Extraction
HPL-ALL
HPL-FBLAS
HPL Core
Remove all preprocessor directives, i.e., calls
to FBLAS, CBLAS and VSIPL
HPL-VSIPL
Specialize to HPL-CBLAS, HPL-FBLAS, HPL-VSIPL,
i.e., a software product line
77DMS Macro-Extraction and Specialization Rule
1. external pattern remove_macro(tran_unittranslation_unit,ididentifier) 2. translation_unit 'remove_macro' in domain CppISO14882c1998. 3. external pattern add_macro(tran_unittranslation_unit,ididentifier) 4. translation_unit 'add_macro' in domain CppISO14882c1998. 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-gt translation_unit 9. t_u -gt remove_macro(t_u,CBLAS()) 10. if tran_unit remove_macro(t_u,CBLAS()). 11. rule del_vsip(t_u translation_unit) translation_unit-gt translation_unit 12. t_u -gt remove_macro(t_u,VSIPL()) 13. if t_u remove_macro(t_u,VSIPL()). 14. rule del_fblas(t_u translation_unit) translation_unit-gt translation_unit 15. t_u -gt remove_macro(t_u,FBLAS()) 16. if t_u remove_macro(t_u,FBLAS()). 17. rule add_cblas(t_u translation_unit) translation_unit-gt translation_unit 18. t_u -gt add_macro(t_u,CBLAS()) 19. if t_u add_macro(t_u,CBLAS()). 20. rule add_vsip(t_u translation_unit) translation_unit -gt translation_unit 21. t_u -gt add_macro(t_u,VSIPL()) 22. if t_u add_macro(t_u,VSIPL()). 23. rule add_fblas(t_u translation_unit) translation_unit-gt translation_unit 24. t_u -gt add_macro(t_u,FBLAS()) 25. if t_u add_macro(t_u,FBLAS()).
78Before and After Specialization with CBLAS
Size 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
79Time Analysis
80Performance Analysis