GenAWeave: A Generic Aspect Weaver Framework based on Model-Driven Program Transformation - PowerPoint PPT Presentation

About This Presentation
Title:

GenAWeave: A Generic Aspect Weaver Framework based on Model-Driven Program Transformation

Description:

GenAWeave: A Generic Aspect Weaver Framework based on Model-Driven Program Transformation Suman Roychoudhury roychous_at_cis.uab.edu Ph.D. Dissertation Defense – PowerPoint PPT presentation

Number of Views:168
Avg rating:3.0/5.0
Slides: 81
Provided by: Suman5
Learn more at: https://gray.cs.ua.edu
Category:

less

Transcript and Presenter's Notes

Title: GenAWeave: A Generic Aspect Weaver Framework based on Model-Driven Program Transformation


1
GenAWeave 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
2
Outline 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
3
Challenges 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
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
Crosscutting concerns CC1/CC2 superimposed on
Module A and B
CC1
CC2
Concern CC2
Concern CC1
8
Aspect 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.

9
Aspect 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)

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
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
12
Challenges 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
13
Challenge C1 The Parser Construction
Problem
  • Scalability
  • Extensibility
  • Reusability
  • C
  • Object Pascal
  • Fortan
  • Cobol
  • Ada
  • Jovial
  • VHDL

14
Challenge 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
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
16
Challenge 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
17
Outline 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
18
Research 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
19
Model-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
20
Outline 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
21
Overview of Approach
Current State-of-the-Art Techniques
Program Transformation Back-End
Model-Driven Front-End
Model Transformation
GenAWeave in Action
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-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
24
Current 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
25
Current 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/
26
Current 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/
27
Overview of Approach
Current State-of-the-Art Techniques
Program Transformation Back-End
Model-Driven Front-End
Model Transformation
GenAWeave in Action
28
Program 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
29
Program 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

30
Object 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
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
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
36
KM3 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
37
KM3 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 "," ")" "" ...
38
Support for Generic Front-End (Aspect Pascal)
39
Support for Generic Front-End (Aspect FORTRAN)
40
(No Transcript)
41
Target Metamodel (RSL)
42
Overview of Approach
Current State-of-the-Art Techniques
Program Transformation Back-End
Model-Driven Front-End
Model Transformation
GenAWeave in Action
43
Model 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
44
ATL 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

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 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
48
Overview of Approach
Current State-of-the-Art Techniques
Program Transformation Back-End
Model-Driven Front-End
Model Transformation
GenAWeave in Action
49
GenAWeave 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
50
GenAWeave 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
51
GenAWeave 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
52
GenAWeave 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
53
GenAWeave 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
54
GenAWeave 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
55
GenAWeave 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
56
Integration into Eclipse
Outline view
Syntax highlighting
Error reporting
The editor indicates the misspelling of the
pointcut name timer_around_loops
57
Outline 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
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)
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
61
Model 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' ), ...
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". 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.
63
Join 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()
64
Discussion 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

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
Reusability 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
67
GenAWeave on the Web
  • Software and Video demos available at -

http//www.cis.uab.edu/softcom/genaweave
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.

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

Thank you
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-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
77
DMS 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()).
78
Before 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
79
Time Analysis
80
Performance Analysis
Write a Comment
User Comments (0)
About PowerShow.com