1
Model-based Aspect Weaver ConstructionSuman Roychoudhury
Frédéric Jouault
Jeff Gray
{roychous, jouault, gray} @ cis.uab.edu
This project is supported byNSF CAREER award (CCF-0643725) and the OpenEmbeDD project
2
Background - PT based Aspect Weaver Modified Source Program = fweave (Source Program, Aspect Program)
Using a Program Transformation Engine, one can write an Aspect Program in terms of rewrite rules
rulerule insert_trace_probe(stmts: insert_trace_probe(stmts:statement_seqstatement_seq): ): function_bodyfunction_body -> -> function_bodyfunction_body= " { \stmts } " -> = " { \stmts } " -> " { printf("Entering Method…");\stmts }"." { printf("Entering Method…");\stmts }".
RuleSpecifications
SourceProgram
TransformationEngine
TransformedProgram
Example RSL rule:
3
Motivation Case Study: A Delphi Weaver *
As several evolution tasks (e.g., deleting database triggers, compiling new stored procedures) were executed in the DB Schema manager utility, the processing dialog meter was required to be updated accordingly (appeared in 62 different places in Schema manager utility)
2. if not 3. ProcDlg1.Process(TotalInserts) then4. begin5. ProcDlg1.Canceled := True;6. Result := True;7. exit;8. end; // if not Process
* Gray J, and Roychoudhury S, “A Technique for Constructing Aspect Weavers using a Program Transformation Engine,” AOSD ’04, International Conference on Aspect-Oriented Software Development, Lancaster, UK, March 2004, pp. 36-45.
1. Inc(TotalInserts);Progress Meter Updating
4
RSL Implementation of the Case Study(Rule based aspect weaving)default base domain ObjectPascal.pattern after_advice() : statement_list = "if not ProcDlg1.Process(TotalInserts) then begin ProcDlg1.Canceled := True; Result := True; exit; end".rule IncCall() : statement_list -> statement_list = $Inc(TotalInserts)-> $Inc(TotalInserts) after_advice().public ruleset progress_meter = {IncCall}.
The above rule is written in RSL which is the rewrite language in the DMS program transformation engine
5
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)
The transformation rules are generally hard to comprehend by average software developers (need to know about the grammar)
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)
6
An Aspect Specification Front-enddecoupled from PT enginedomain ObjectPascal;aspect progress_meter { pointcut()IncCall : call(Inc(TotalInserts)); after() : IncCall { if not ProcDlg1.Process(TotalInserts) then
begin ProcDlg1.Canceled := True; Result := True;exit;
end; }}
Source Aspect Specification for Progress Meter Dialog
7
Model-based Front-end Construction
PT Based Back-End
Model Based Front-End
AspectSpecification
RuleSpecifications
SourceProgram
TransformationSystem
TransformedProgram
ATLTransformations
Aspect Specification conforming to an Aspect Metamodel
Aspect Metamodel
RSLMetamodel
Rules Specification conforming to a Rules Metamodel
Translation between aspect specification to rules specification is realized using ATL transformations (model transformation language)
8
Source Aspect Metamodel
KM3 specification (in AMMA)
Ecore metamodel as rendered in Eclipse Modeling Editor
9
Target RSL Metamodel
KM3 specification (in AMMA)
Ecore metamodel as rendered in Eclipse Modeling Editor
10
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, set, get, cflow, etc.(i.e., one transformation for each type of pointcut)
11
Transformation Overview
• The megamodel showing the complete scenario how source aspect specification gets translated to target RSL specification using ATL transformation
(demo: http://localhost:6885/gaspect )
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
M1 = terminal model level; M2 = metamodel level; M3 = meta-metamodel level
Grammarware TS
Aspect2RSLTransformation
12
Primary Benefits Since the rewrite rules are automatically generated (instead of
manual coding) from the aspect specification, one need not be aware of the accidental complexities associated with them
Also by decoupling the source aspect model from the target RSL model : The source aspect model need not be altered even if the target is
replaced with a different PT engine (e.g., the rewrite engine used by ASF+SDF)
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
Another advantage is that both the aspect language (source) and rules language (target) can evolve independent of each other which leads to new features being added to the weaver
13
Future directions:
Towards Generic Aspect Weaver Construction:
Extending the Aspect Metamodel (via Metamodel Extension) to support multiple languages
Extending ATL Transformations (e.g., using rule inheritance, module superimposition)
By adapting this technique we may also construct aspect weavers for domain-specific languages
Core Aspect Metamodel for OOL
Delphi Java Fortran 2003
Java 1.4 Java 1.5
Aspect Metamodel for Fortran
Fortran 77 Fortran 90
14
Concluding Remarks - Summary The majority of research in this area mainly focuses on how aspects can be applied to MDE. This research illustrates how MDE can also assist in building aspect weavers
The main advantage of this approach is the ability to modularize the weaver construction process by decoupling the source aspect language metamodel from the target PTE metamodel
The source aspect metamodel need not be altered even if the target is replaced with a different PT engine
Conversely, for every new language, we need to add the appropriate metamodel extensions to the base aspect metamodel, but no change to the target metamodel is needed (as part of future work)
Nevertheless, one can still leverage the power of program transformation engines (avoid the associated accidental complexities ) to build weavers that are easy to modularize, evolve and maintain