Upload
ann-goodwin
View
219
Download
0
Tags:
Embed Size (px)
Citation preview
Model-Driven Aspect Adaptation
To Support Modular Software EvolutionPh.D. Defense
Jing [email protected]
http://www.cis.uab.edu/zhangj
Committee Members: Dr. Jeff Gray (Academic Advisor) Dr. Barrett Bryant Dr. Aniruddha Gokhale Dr. Marjan Mernik Dr. Chengcui Zhang
March 30th, 2009
2
Overview of Presentation
Research GoalsResearch Goals
MotivationMotivation
ChallengesChallenges
ApproachesApproaches
EvaluationEvaluation
Model-Driven Aspect AdaptationAspect-Oriented
Activity ModelingBold Stroke
Model Evolution
Legacy Evolution
Co-Evolution
Inevitable Software Evolution
ModularEvolution
ModularEvolution
Changeability ComprehensibilityIndependentDevelopment
INFM
Main Menu
Processed alarm typesSeverity level selection
Alarm Monitor Window
Rule Application Notification
Main Menu
Processed alarm typesSeverity level selection
Alarm Monitor Window
Rule Application Notification
3
First Law of Software Evolution
“Software that is being used must be continually adapted or it becomes progressively less satisfactory.”
-- Manny M. Lehman
Manny M. Lehman, “Laws of Software Evolution Revisited,” In Proceedings of the 5th European Workshop on Software Process Technology (EWSPT), Nancy, France, October 1996, pages 108–124.
4
Challenges in Software Evolution:1. Model Evolution
∆M: The changes made to the models
M∆
Models Models’
As the size of system models grows, techniques and tools are needed to automate complex change evolution
5
Challenges in Software Evolution:2. Legacy Evolution
∆S: The changes made to the legacy source
A small modification in the high-level requirements may trigger drastic manual changes in large portions of the low-level legacy source code
6
Challenges in Software Evolution:3. Model/Code Co-Evolution
∆M: The changes made to the models∆S: The changes reflected in the source code
Conformity between the models and underlying source code needs to be established in order to maintain the fidelity of the whole system
7
Criteria for Software Evolution Modularization
Dividing a complex system into a set of manageable building blocks, or modules
Modular software evolution Changeability
Individual modules should be able to change without radical impact to the rest of the system
Comprehensibility High-level evolutionary requirements need to be well-understood
and thus systematically translated into the low-level change adaptation
Independent Development Evolution tasks need to be divided into individual modules that can
be implemented and maintained by different groups
8
Research Objectives
Model Evolution
Model Evolution
Model/CodeCo-Evolution
Model/CodeCo-Evolution
LegacyEvolution
LegacyEvolution
Changeability ComprehensibilityIndependentDevelopment
Aspect-Orientation
Model-DrivenAspect Adaptation
9
Thesis Statement
This dissertation research is devoted to approaches uniting Model-Driven Engineering (MDE) with Aspect-Oriented Software Development (AOSD) techniques to support modular software evolution. The ultimate goal is to improve changeability, comprehensibility and independent development of the evolutionary task implementation.
First, the Aspect-Oriented Activity Modeling (AOAM) approach is investigated to support evolution of UML activity models.
Second, the Model-Driven Aspect Adaptation (MDAA) approach is investigated to facilitate model/code co-evolution and legacy evolution.
10
Outline
Motivation and Challenges Research Objectives Background Aspect-Oriented Activity Modeling Model-Driven Aspect Adaptation
DSM-Based MDAA UML Activity-Based MDAA
Future Work and Conclusion
11
Two Types of Software Restructuring
Horizontal transformation Transformation within the same level
of abstraction Model Transformation,
Aspect-Oriented Modeling (AOM), Program Transformation, Aspect-Oriented Programming (AOP)
Vertical translation Translation, or synthesis, between
layers of abstraction Reverse Engineering,
Model-Driven Engineering (MDE)
ComputePositionC++
ComputePositionwith Locking
C++
NavDisplayC++
12
Model-Driven Engineering
Metamodel
System
M3
M2
M1
M0
ConformsTo
Meta-metamodel
ConformsTo
ConformsTo
Model
Describes
OMG UML-based generic modeling Rational Rose Telelogic TAU …
Domain-specific modeling (DSM) GME Microsoft software factories …
13
Unified Modeling Language (UML)
Class
ClassOperation Attribute Instance
<<instanceOf>> <<instanceOf>> <<instanceOf>> <<instanceOf>>
classifier
Person
name: String
setName(n: String)
<<instanceOf>><<instanceOf>><<instanceOf>>
: Person
name = “Mike”
<<snapshot>>
<<instanceOf>> <<instanceOf>>
<<instanceOf>>
M3 (MOF)
M2 (UML)
M1 (User model)
M0 (Run-time instance)aPerson : Person
name = “Mike”
Structural modeling Class diagram Component diagram Deployment diagram
Behavioral modeling State machine diagram Activity diagram Use case diagram Interaction diagram
14
Telelogic TAU: A UML-based MDE Tool
Design
Code Generation
Testing
Simulation
15
ModelInterpretation
Model Interpreters
Models
Modeling Environment
ApplicationDomain
App1
App2
App3
Application Evolution
Environment Evolution
MetaprogrammingInterface
Formal Specifications
Meta-LevelTranslation
Model Builder
Domain-Specific Modeling (DSM) in Generic Modeling Environment (GME)
Metamodel
Model
Interpreter
void CComponent::InvokeEx(CBuilder &builder,CBuilderObject *focus, CBuilderObjectList &selected, long param) {CString DMSRoot = "";DMSRoot = SelectFolder("Please Select DMSRoot Folder:");if (DMSRoot != "") {DMSRulePath = DMSRoot + RULESPATH + "Rules\\";MSRuleApplierPath = DMSRoot + RULESPATH + "RuleApplier\\";AfxMessageBox("DMSRulePath = " + DMSRulePath , MB_OK);CString OEPRoot = "";OEPRoot = SelectFolder("Please Selec
DEFINE
INTERPRET
16
Crosscutting Concerns
Problems Reusability Maintainability Evolvability
Profiling in Apache Tomcat Serverhttp://www.parc.com/research/projects/aspectj/
17
Aspect-Oriented Software Development (AOSD)
Advanced separation of concerns Modularize crosscutting
concerns Aspect
Encapsulates each crosscutting concern in an individual module
Aspect weaver Composes aspects with
the base modules
18
AOSD Terminology Join Point
A point of interest through which two or more concerns may be composed
Pointcut A collection of join points
Advice The adaptation to be
applied at each join point specified in a pointcut
Aspect applicabilityAspect applicability
Aspect functionalityAspect functionality
Where
What
Aspect
Pointcut
Advice
19
AOSD Technologies
Aspect-Oriented Programming (AOP) AspectJ
The most widely used AOP language Tailored for Java
Aspect-Oriented Modeling (AOM) Constraint-Specification Aspect Weaver (C-SAW)
Aspect model weaver for domain-specific models Embedded Constraint Language (ECL) to support model weaving A plug-in for GME
Motorola WEAVR Aspect model weaver for UML state machines A plug-in for Telelogic TAU
20
Outline
Motivation and Challenges Research Objectives Background Aspect-Oriented Activity Modeling Model-Driven Aspect Adaptation
DSM-Based MDAA UML Activity-Based MDAA
Future Work and Conclusion
21
Aspect-Oriented Activity Modeling MOF
Activity Metamodel
Aspect-Activity Metamodel
Activity ModelAspect-Activity
Model
Aspect Weaver
Defined By Defined By
Def
ined
By
Def
ined
By
Composed Activity Model
22
Order Processing Activity Model Operation Action
Send Signal Action
Receive Event Action
Fork
Receive_Order
order: Orderorder: Order
Op_Process_Order
order: Orderorder: Order
Cancel_Order_Request
Cancel_Order
Request_Payment()
Payment_Confirmed
Ship_Order
23
Aspect-Activity Metamodel (Profile)
24
Tracing Aspect, Pointcuts and Advice
Base_Activity TracingAspect<< crosscuts >>
<< Activity >> << Aspect >>
activity Trace
LogThisJoinPoint
proceed
<<Advice>>
Cancel_*
Trace<< Advice >>
int flag;
Op_Process_Order
order: Order
Cancel_Order_Request
Request_Payment
<< Pointcut >>
<< Pointcut >>
<< Pointcut >>
<< Pointcut >>
activity << Aspect >>
<< binds>>
<< binds>>
<< binds>>
<< binds>>
tjp : thisJoinPointtjp :
TracingAspect
25
Order Processing Model with Tracing Aspect
Receive_Order
order: Orderorder: Order
Op_Process_Order
order: Orderorder: Order
Cancel_Order_Request
Request_Payment ()
Payment_Confirmed
Ship_Order
Cancel_Order
LogThisJoinPoint
LogThisJoinPoint
LogThisJoinPoint
LogThisJoinPoint
26
Pointcut Composition in AOAM Operators
and (&&) or (||) not (!) cflow cflowbelow within
activity CompositePointcut Activity diagram1 {1/1}
( * _Order && ! cflow ( Cancel_* ) )
<<Pointcut>>
<< Pointcut >> << Pointcut >>
Cancel_** _Order
27
Advice Composition in AOAM Operators
binds follows
Advice are ordered based on the precedence relationships (e.g., <<follows>>) Advice1 has precedence
over Advice2 at the shared join point
Interference between the advice is reduced by declaring the advice precedence explicitly
Advice1Advice1
Advice2Advice2Shared Join Point
activity << Aspect >>
<< binds>>
AdviceCompositionAspect
Pointcut1
<< Pointcut >>
Pointcut2
<< Pointcut >>
Advice1<< Advice >>
Advice2<< Advice >><< binds>>
<< binds>>
<< binds>><< follows>>
28
Aspect Composition in AOAMDeployment class Deployment {1/1}
:: Base_Activity :: Aspects:: ExceptionAspect
:: Aspects:: TracingAspect:: Aspects:: LoggingAspect
:: Aspects:: EncryptionAspect
<< crosscuts>>
<< follows>><< crosscuts>>
<<hidden_by >>
<< follows>> << dependent_on >>
<< Aspect >>
<< Aspect >>
<< Aspect >>
<< Aspect >>
<< Activity >>
Operators crosscuts follows hidden_by dependent_on
Interference between the aspects is reduced by declaring the aspect precedence explicitly
TracingAspect follows ExceptionAspect ExceptionAspect has higher precedence than TracingAspect
LoggingAspect is hidden by TracingAspect The presence of TracingAspect inactivates LoggingAspect
LoggingAspect is dependent on EncryptionAspect LoggingAspect can only be applied in the presence of the
EncryptionAspect
ExceptionAspect
ExceptionAspect
TracingAspectTracingAspect
LoggingAspect
LoggingAspect
EncryptionAspect
EncryptionAspect
29
Summary of AOAM
Contributions AOAM supports modular evolution in activity modeling
Evolutionary requirements are encapsulated in aspect models Aspect models allow specific concerns to be maintained,
comprehended and developed independently Aspect models are woven into the base model via the AOAM
weaver AOAM allows precedence relationships to be specified at
the modeling level to prevent undesirable interferences between aspects
AOAM weaver is implemented in Telelogic TAU, as an extension of the Motorola state machine weaver
30
Outline
Motivation and Challenges Research Objectives Background Aspect-Oriented Activity Modeling Model-Driven Aspect Adaptation
DSM-Based MDAA UML Activity-Based MDAA
Future Work and Conclusion
31
Model-Driven Aspect Adaptation Framework Meta-
metamodelMeta-
metamodel
MetamodelMetamodel
Source CodeSource Code
Conforms To
Model ExtractorModel Extractor ModelModel ModelComposer
ModelComposer
EnhancedModel
EnhancedModel
EnhancedCode
EnhancedCode
ProgramComposerProgram
Composer
Aspect CodeGenerator
Aspect CodeGenerator
AspectCode
AspectCode
AspectModel
AspectModel
AspectMetamodel
AspectMetamodel
Conforms To
Conforms ToConforms To
Simulation/Testing
32
Roles in MDAA Process
CreateAspect Metamodel
Construct AspectCode Generator
Specify AspectModel
AspectDeveloper
DomainExpert
IdentifyBase Metamodel
ExtractBase Model
Model Extraction Engineer
Invoke AspectCode Generator
33
MDAA Component: Model Extractor DSM Metamodel
UML Metamodel
34
MDAA Component: Model Composer
Model Composer
…...
Composition Relations
Model 1 Model 2 Model 3
ComposedModel
AOM Weaver C-SAW AOAM Weaver
35
MDAA Component: Aspect Code Generator
Logging AspectCode
1 1
Modeling Space Source Code Space
ConcurrencyAspect Code
1 1
Logging AspectModel
ConcurrencyAspect Model
36
MDAA Component: Program Composer
Program transformation engine Design Maintenance
System (DMS) ASF + SDF …
AOP weaver AspectJ AspectC++ …
Program Composer
Composition Relations
ComposedProgram Source
Program 2Program 1
void BM__PushPullComponentImpl::Update (const UUEventSet& events){ BM__ComponentInstrumentation::EventConsumer(GetId(), "Update", events); unsigned int tempData1 = GetId().GetGroupId(); unsigned int tempData2 = GetId().GetItemId(); std::vector<BM__ClosedComponent*>::iterator devIter = devices_.begin(); std::vector<BM__ClosedComponent*>::iterator endIter = devices_.end(); for (; devIter != endIter; ++devIter) { BM__ClosedComponent* component = *devIter; const UUIdentifier& id = component->GetId(); }
Program 3
…...
void BM__PushPullComponentImpl::Update (const UUEventSet& events){
UM__GUARD_EXTERNAL_REGION(GetExternalPushLock())
BM__ComponentInstrumentation::EventConsumer(GetId(), "Update", events); unsigned int tempData1 = GetId().GetGroupId(); unsigned int tempData2 = GetId().GetItemId(); std::vector<BM__ClosedComponent*>::iterator devIter = devices_.begin(); std::vector<BM__ClosedComponent*>::iterator endIter = devices_.end(); for (; devIter != endIter; ++devIter) { BM__ClosedComponent* component = *devIter; const UUIdentifier& id = component->GetId();
UM__GUARD_INTERNAL_REGION; log.add(“data1_=”+data1_); data1_ = tempData1; data2_ = tempData2; log.add(“data2_=”+data2_); }
void BM__PushPullComponentImpl::Update (const UUEventSet& events){
UM__GUARD_EXTERNAL_REGION(GetExternalPushLock()); BM__ClosedComponent* component = *devIter; const UUIdentifier& id = component->GetId();
UM__GUARD_INTERNAL_REGION; log.add(“data1_=”+data1_); data1_ = tempData1; data2_ = tempData2;
log.add(“data2_=”+data2_); }
37
Outline
Motivation and Challenges Research Objectives Background Aspect-Oriented Activity Modeling Model-Driven Aspect Adaptation
DSM-Based MDAA UML Activity-Based MDAA
Future Work and Conclusion
38
DSM-Based MDAA Instantiation
Base Metamodel
void BM__PushPullComponentImpl::Update (const UUEventSet& events){ BM__ComponentInstrumentation::EventConsumer(GetId (), "Update", events);
unsigned int tempData1 = GetId().GetGroupId();unsigned int tempData2 = GetId().GetItemId();std::vector<BM__ClosedComponent*>::iterator devIter = devices_.begin();std::vector<BM__ClosedComponent*>::iterator endIter = devices_.end();for (; devIter != endIter; ++devIter) {
BM__ClosedComponent* component = *devIter;const UUIdentifier& id = component->GetId();
if (idInEventSet(id, events))
{ const BM__ClosedFunctionalFacet& facet = component->ProvideClosedFunctionalFacet();
BM__ComponentInstrumentation::SendDirectCall(GetId (), "Update", component->GetId(), "GetData1");
tempData1 += facet.GetData1();
BM__ComponentInstrumentation::SendDirectCall(GetId (), "Update", component->GetId(), "GetData2");
tempData2 += facet.GetData2();
} } data1_ = tempData1; data2_ = tempData2;
}
void BM__PushPullComponentImpl::Update (const UUEventSet& events){ BM__ComponentInstrumentation::EventConsumer(GetId (), "Update", events);
unsigned int tempData1 = GetId().GetGroupId();unsigned int tempData2 = GetId().GetItemId();std::vector<BM__ClosedComponent*>::iterator devIter = devices_.begin();std::vector<BM__ClosedComponent*>::iterator endIter = devices_.end();for (; devIter != endIter; ++devIter) {
BM__ClosedComponent* component = *devIter;const UUIdentifier& id = component->GetId();
if (idInEventSet(id, events))
{ const BM__ClosedFunctionalFacet& facet = component->ProvideClosedFunctionalFacet();
BM__ComponentInstrumentation::SendDirectCall(GetId (), "Update", component->GetId(), "GetData1");
tempData1 += facet.GetData1();
BM__ComponentInstrumentation::SendDirectCall(GetId (), "Update", component->GetId(), "GetData2");
tempData2 += facet.GetData2();
} } data1_ = tempData1; data2_ = tempData2;
}
Legacy Source Code
Base Model
Design Maintenance
System (DMS)
void BM__PushPullComponentImpl::Update (const UUEventSet& events)
{ UM__GUARD_EXTERNAL_REGION(GetExternalPushLock());BM__ComponentInstrumentation::EventConsumer(GetId(), "Update", events);
unsigned int tempData1 = GetId().GetGroupId(); unsigned int tempData2 = GetId().GetItemId();
std::vector<BM__ClosedComponent*>::iterator devIter = devices_.begin();
std::vector<BM__ClosedComponent*>::iterator endIter = devices_.end();
for (; devIter != endIter; ++devIter) {
BM__ClosedComponent* component = *devIter; const UUIdentifier& id = component->GetId();
if (idInEventSet(id, events))
{ const BM__ClosedFunctionalFacet& facet = component->ProvideClosedFunctionalFacet();
BM__ComponentInstrumentation::SendDirectCall(GetId(), "Update", component->GetId(), "GetData1");
tempData1 += facet.GetData1();
BM__ComponentInstrumentation::SendDirectCall(GetId(), "Update", component->GetId(), "GetData2");
tempData2 += facet.GetData2();
} } UM__GUARD_INTERNAL_REGION; log.add(“data1_=”+data1_);
data1_ = tempData1; data2_ = tempData2; log.add(“data2_=”+data2_); }
void BM__PushPullComponentImpl::Update (const UUEventSet& events)
{ UM__GUARD_EXTERNAL_REGION(GetExternalPushLock());BM__ComponentInstrumentation::EventConsumer(GetId(), "Update", events);
unsigned int tempData1 = GetId().GetGroupId(); unsigned int tempData2 = GetId().GetItemId();
std::vector<BM__ClosedComponent*>::iterator devIter = devices_.begin();
std::vector<BM__ClosedComponent*>::iterator endIter = devices_.end();
for (; devIter != endIter; ++devIter) {
BM__ClosedComponent* component = *devIter; const UUIdentifier& id = component->GetId();
if (idInEventSet(id, events))
{ const BM__ClosedFunctionalFacet& facet = component->ProvideClosedFunctionalFacet();
BM__ComponentInstrumentation::SendDirectCall(GetId(), "Update", component->GetId(), "GetData1");
tempData1 += facet.GetData1();
BM__ComponentInstrumentation::SendDirectCall(GetId(), "Update", component->GetId(), "GetData2");
tempData2 += facet.GetData2();
} } UM__GUARD_INTERNAL_REGION; log.add(“data1_=”+data1_);
data1_ = tempData1; data2_ = tempData2; log.add(“data2_=”+data2_); }
Enhanced Code with Aspect(s)
Enhanced Model with Aspect(s)
ModelExtraction Engineer
Interpreter(s)
Enhanced Metamodel(s)
Program Transformation
Rules in RSL
Conforms ToConforms To
Conforms To
C-SAW
AspectMetamodel(s)
Aspect Model(s) in ECL
Conforms To
Metamodel Composer
Evolutionary requirements are captured as higher level policy strategies and weaved into models
Ensures causal connection between model changes and the underlying source code of the legacy system
Large-scale adaptation across multiple source files that are driven by minimal changes to the model properties
Domain experts are shielded from lower-level transformation rules
39
Metamodel Composer
Why metamodel composer? C-SAW provides no support for transformation BETWEEN two
different metamodels Need a means to compose base metamodel and aspect metamodel
MetamodelComposerMetamodelComposer
40
Experimental Case Study:Bold Stroke Product Line
Background context Mission-control software for Boeing military aircraft
under development since 1995 CORBA event-based systems Thousands of components implemented in over three
million lines of C++ code Embedded System Modeling Language (ESML)
Key challenges Difficult to evolve the underlying source representation
to address new requirements Impossible to determine, a priori, all of the future
adaptation requests
41
ESML Base Metamodel
42
Case Study: A Black Box Data Recorder
Requirement: Record the state information of the aircraft according to polices defined in a model
Under different stages of development, a concern may need to be adjusted based on different contexts, e.g., testing on the ground vs. in-flight recording
Ability to rapidly explore design alternatives that represent different policies
43
Composed ESML Metamodel with Logging Aspect
44
Apply C-SAW to Insert Logging Aspect to ESML Base Modeldefines Start, logDataAtoms, AddLog;
strategy logDataAtoms() { atoms()->select(a | a.kindOf() == "Data")->AddLog(); }
strategy AddLog() {declare parentModel : model;declare dataAtom, logAtom : atom;
dataAtom := self;parentModel := parent();logAtom := parentModel.addAtom("Log", "LogOnMethodExit");logAtom.setAttribute("Kind", "On Method Exit");logAtom.setAttribute("MethodList", "Update");parentModel.addConnection("AddLog", logAtom, dataAtom);
}
aspect Start() {rootFolder().findFolder("ComponentTypes").models().
select(m|m.name().endWith("Impl"))->logDataAtoms();}
45
ESML Component with Logging Aspect
46
Generated DMS Transformation Rules to Insert “LogOnMethodExit” Aspectdefault base domain Cpp~VisualCpp6.
pattern LogStmt(): statement = "log.add(\"data1_=\" + data1_);".
pattern LogOnMethodExitAspect(s: statement_seq): statement_seq = "\s \LogStmt\(\)".
pattern JoinPoint(id:identifier): qualified_id = "\id :: Update".
rule insert_log_on_method_exit(id:identifier, s:statement_seq, p:parameter_declaration_clause):
function_definition -> function_definition = "void \JoinPoint\(\id\)(\p) {\s} " -> "void \JoinPoint\(\id\)(\p) {\LogOnMethodExitAspect\(\s\)}" if ~[modsList:statement_seq. s matches "\:statement_seq \LogOnMethodExitAspect\(\modsList\)"].
public ruleset applyrules={insert_log_on_method_exit}.
47
Transformed C++ Source Code
1 unsigned int BM__ClosedEDComponentImpl::getData1_ () const2 {3 4 5 UM__GUARD_INTERNAL_REGION;6 BM__ComponentInstrumentation::ReceiveDirectCall(GetId(), "GetData1"); 7 8 9 return data1_;10 } 11 12 void BM__ClosedEDComponentImpl::Update (const UUEventSet& events)13 { 14 15 16 UM__GUARD_EXTERNAL_REGION(GetExternalPushLock()); 17 BM__ComponentInstrumentation::EventConsumer(GetId(), "Update", events);18 unsigned int tempData1 = GetId().GetGroupId();19 unsigned int tempData2 = GetId().GetItemId();20 21 //*** REMOVED: code for implementing Real-time Event Channel22 23 24 data1_ = tempData1; //*** REMOVED: actual variable names (proprietary)25 data2_ = tempData2;26 27 28 }
log.add("data1_=" + data1_);
log.add("data1_=" + data1_);
log.add("data1_=" + data1_);
log.add("data1_=" + data1_);
log.add("data1_=" + data1_);
Log on getData1_() method entry
Log on reading data1_
Log on Update() method entry
Log on writing data1_
Log on Update() method exit
48
Experimental Results
Manual Changes
(No. Of Places)
Aspect Model Interpreter
(LOC)
ECL
(LOC)
Generated RSL
(LOC)
Concurrency 50 (in 25 different cpp files)
257 25 1250
Logging 200 (in 25 different cpp files)
305 37 3750
Assertion 100 (in 25 different cpp files)
270 33 2500
49
MDAA Interpreters for Different Aspect Models
Concurrency Aspect Metamodel
Conforms To
Interpreter for Concurrency Aspect
Logging Aspect Metamodel
Conforms To
Interpreter for Logging Aspect
50
Outline
Motivation and Challenges Research Objectives Background Aspect-Oriented Activity Modeling Model-Driven Aspect Adaptation
DSM-Based MDAA UML Activity-Based MDAA
Future Work and Conclusion
51
Activity-Based MDAA Instantiation
AspectJ Weaver
Aspect Code Generator
AutonomicCapabilities
IdentifyAlgoFailure
hasFailure
AnalyzeAlgoFailure
deltaParam : Param
T
[ true ]
AnalyzeTimeoutFailure
deltaParam : Param
Reconfiguration
deltaParam : Param
Aspect-Activity Model
AutonomicCapabilities
INFM
ConnectDB
ProcessPatterns
ExecuteAlgo
IdentifyAlgoFailure
hasFailure
AnalyzeAlgoFailure
deltaParam : Param
SetParam
T
[false]
[true]
AnalyzeTimeoutFailure
deltaParam : Param
Reconfiguration
deltaParam : Param
Enhanced Model
Aspect-Activity Weaver
Base Activity Model
Aspect-Activity Profile
Conforms To
Base Code(In Java)
Model Extraction
AspectJ Code
Enhanced Code
52
Experimental Case Study:Intelligence Network Fault Management (INFM) Background context A fault management software
developed by Motorola Labs for CDMA cellular network
Alarm correlation by patterndiscovery algorithms
Implemented in over 50K lines of Java code
Main Menu
Processed alarm typesSeverity level selection
Alarm Monitor Window
Rule Application Notification
Main Menu
Processed alarm typesSeverity level selection
Alarm Monitor Window
Rule Application Notification
Key challenges Increasing computational complexity would cause various
software failures (e.g., timeout failure and pattern failure) Different strategies are needed to resolve software failures Failure management strategies are subject to change with
evolving system requirements
53
INFM Alarm Correlation Activity Base Model
INFM
ConnectDB
SetParam
ExecuteAlgo
ProcessPatterns
ConfigureConnection
ConnectFTP
[ config == DB]
[ config == DB]
[ config == FTP]
[ config == FTP]
54
Case Study: A Pattern Failure Handler Aspect
ReportFailure counter < N[false]
proceed
IdentifyPatternFailure
hasFailure
RecheckPatterns
hasFailure
[true]
[true]
ReconfigureAlgo
deltaParam : Param
counter ++
AnalyzePatternFailure
deltaParam : Param
[false]
[true]
[false]
hasFailure : bool
hasFailure : bool
ExecuteAlgo
<< Pointcut >>
activity << Aspect >>
PatternFailureHandlerAdvice
<< Advice >>
<< binds>>
activity PatternFailureHandlerAdvice << Advice >>PatternFailureHandlerAspect
InitializeCounter
55
Composed INFM Model by AOAM Weaver
INFM
ConnectDB
SetParam
ExecuteAlgo
ProcessPatterns
ConnectFTP
ConfigureConenction
[ config == DB]
[ config == DB] [ config == FTP]
[ config == FTP]
ReportFailure counter < N[false]
IdentifyPatternFailure
hasFailure
RecheckPatterns
hasFailure
[true]
[true]
ReconfigureAlgo
deltaParam : Param
counter ++
AnalyzePatternFailure
deltaParam : Param
[true]
[false]
hasFailure : bool
hasFailure : bool
InitializeCounter
[false]
PatternFailureHandlerAspect
56
Generated AspectJ Code for the Pattern Failure Handler Aspect
aspect PatternFailureHandlerAspect { int N = 10; int counter = 0; boolean hasFailure; Param deltaParam;
pointcut pct() : call(ExecuteAlgo(...));
around() : pct() { while (counter < N) { proceed(); hasFailure = IdentifyPatternFailure(); if (hasFailure) { hasFailure = RecheckPatterns(); if (hasFailure) { deltaParam = AnalyzePatternFailure(); ReconfigureAlgo(deltaParam); counter ++; } else { break; } } else { break; } } }}
57
Summary of MDAA
MDAA provides modular evolution for legacy systems by uniting MDE and AOSD technologies Evolutionary changes are encapsulated in high-level
abstract aspect models Aspect models allow specific evolutionary
requirements to be maintained, comprehended and developed independently
Aspect models are translated into the low-level aspect code by aspect code generators
The legacy system is transformed by weaving the generated aspect code into the base source code
58
Comparison of DSM-based and UML-based MDAA Instantiation
DSM-based MDAA UML-based MDAA
Base Metamodel Domain-specific Domain-generic
Model Close to the domain concepts
Close to the implementation concepts
Aspect Metamodel Multiple for one base
metamodel
Only one for one base
metamodel
Aspect Code Generator
Multiple for one base
metamodel
Only one for one base
metamodel
59
Outline
Motivation and Challenges Research Objectives Background Aspect-Oriented Activity Modeling Model-Driven Aspect Adaptation
DSM-Based MDAA UML Activity-Based MDAA
Future Work and Conclusion
60
Future Work
AOM More types of join points support in AOAM Aspect mining and refactoring at the model level
Extend initial experimental work on aspect identification to support aspect extraction and refactoring
Aspect interference analysis Extend preference-based approach for reducing aspect interference Perform formal evaluation and analysis for detecting aspect
interference MDAA
System validation through model simulation Version control support MDA (Model-Driven Architecture) and ADM (Architecture-Driven
Modernization) alignment
61
Conclusion Software evolution challenges
Activity model evolutionSolution: AOAM weaver
Model/Code co-evolution, legacy evolutionSolution: MDAA framework
Contribution Modular software evolution by combining MDE and AOSD
Changeability – aspect models are able to change without radical impact to the rest of the system
Comprehensibility – evolutionary requirements are captured in high-level aspect models and systematically translated into the low-level change adaptation
Independent Development – evolution tasks are divided into individual aspect modules that can be developed and maintained by different groups
62
Representative Publications Book chapters (3):
Jeff Gray, Sandeep Neema, Jing Zhang, Yuehua Lin, Ted Bapty, Aniruddha Gokhale, and Douglas C. Schmidt, “Concern Separation for Adaptive QoS Modeling in Distributed Real-Time Embedded Systems,” in Behavioral Modeling for Embedded Systems and Technologies: Applications for Design and Implementation, Idea Group, 2009.
Jing Zhang, Yuehua Lin, and Jeff Gray, "Generic and Domain-Specific Model Refactoring using a Model Transformation Engine," Model-driven Software Development - Research and Practice in Software Engineering, Springer, ISBN: 3-540-25613-X, 2005, Chapter 9, pp. 199-218.
Yuehua Lin, Jing Zhang, and Jeff Gray, "A Framework for Testing Model Transformations," Model-driven Software Development - Research and Practice in Software Engineering, Springer, ISBN: 3-540-25613-X, 2005, Chapter 10, pp. 219-236.
63
Representative Publications (Cont’) Journal papers (7):
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 Journal, 2009.
Yuehua Lin, Jeff Gray, Jing Zhang, Steve Nordstrom, Aniruddha Gokhale, and Sandeep Neema, “Replicators: Transformations to Address Model Scalability,” Software: Practice and Experience, vol. 38, no. 14, November 2008, pp. 1475-1497.
Jing Zhang, Jeff Gray, Yuehua Lin, and Robert Tairas, “Aspect Mining from a Modeling Perspective,” International Journal of Computer Applications in Technology, Volume 31, Number 1-2, March 2008, pp. 74-82.
Faizan Javed, Marjan Mernik, Jeff Gray, Jing Zhang, Barrett Bryant, and Suman Roychoudhury, “Using A Program Transformation Engine to Infer Types in A Metamodel Recovery System,” Acta Electrotechnica et Informatica, vol. 8, no. 1, January-March 2008, pp. 3-10.
Jing Zhang, Thomas Cottenier, Aswin van den Berg, and Jeff Gray, “Aspect Composition in the Motorola Aspect-Oriented Modeling Weaver,” JOT special issue on AOM, August 2007, pp. 89-108.
Krishnakumar Balasubramanian, Aniruddha Gokhale, Yuehua Lin, Jing Zhang, and Jeff Gray, “Weaving Deployment Aspects into Domain-Specific Models,” International Journal on Software Engineering and Knowledge Engineering, vol. 16, no. 3, June 2006, pp. 403-424.
Jeff Gray, Yuehua Lin and Jing Zhang, “Automating Change Evolution in Model-Driven Engineering,” IEEE Computer (Special Issue on Model-Driven Engineering), vol. 39, no. 2, February 2006, pp. 51-58.
64
Representative Publications (Cont’) Conference papers (11):
Michael Jiang, Jing Zhang, Hong Zhao, and Yuanyuan Zhou, “Enhancing Software Product Line Maintenance with Source Code Mining,” International Conference on Wireless Algorithms, Systems and Applications (WASA), Dallas, TX, October 2008, pp. 538-547.
Yan Liu, Jing Zhang, Xin Meng, and John Strassner, “Sequential Proximity-based Clustering for Telecommunication Network Alarm Correlation,” The Fifth International Symposium on Neural Networks (ISNN), Beijing, China, September 2008, pp. 30-39.
Michael Jiang, Jing Zhang, Hong Zhao, and Yuanyuan Zhou, “Maintaining Software Product Lines – an Industrial Practice,” International Conference on Software Maintenance (ICSM), Beijing, China, September 2008, pp. 444-447.
John Strassner, Srini Samudrala, Greg Cox, Yan Liu, Michael Jiang, Jing Zhang, Sven van der Meer, Micheal Ó Foghlu and Willie Donnellu, “The Design of a New Context-Aware Policy Model for Autonomic Networking,” The 5th IEEE International Conference on Autonomic Computing (ICAC), Chicago, IL, June 2008, pp. 119-128.
Yan Liu, Jing Zhang, Michael Jiang, Dave Raymer, and John Strassner, “A Model-based Approach to Adding Autonomic Capabilities to Network Fault Management System,” IEEE/IFIP Network Operations and Management Symposium (NOMS 2008), Salvador, Brazil, April 2008, pp. 859-862.
Yan Liu, Jing Zhang, Michael Jiang, Dave Raymer, and John Strassner, “A Case Study: A Model-Based Approach to Retrofit a Network Fault Management System with Self-Healing Functionality,” 5th IEEE International Conference on Engineering of Autonomic and Autonomous Systems (EASe), Belfast, Northern Ireland, March/April 2008, pp. 9-18.
Jing Zhang, Yan Liu, Michael Jiang and John Strassner, “An Aspect-Oriented Approach to Handling Crosscutting Concerns in Activity Modeling,” IAENG International Conference on Software Engineering, Hong Kong, March 2008, pp. 885-890.
Best Paper Award: Jeff Gray, Yuehua Lin, Jing Zhang, Steve Nordstrom, Aniruddha Gokhale, Sandeep Neema, and Swapna Gokhale, “Replicators: Transformations to Address Model Scalability,” Model Driven Engineering Languages and Systems (MoDELS) (formerly the UML series of conferences), Springer-Verlag LNCS 3713, Montego Bay, Jamaica, October 2005, pp. 295-308.
Jeff Gray, Jing Zhang, Yuehua Lin, Hui Wu, Suman Roychoudhury, Rajesh Sudarsan, Sandeep Neema, Feng Shi, and Ted Bapty, “Model-Driven Program Transformation of a Large Avionics Application,” Generative Programming and Component Engineering (GPCE 2004), Springer-Verlag LNCS, Vancouver, BC, October 2004, pp. 361-378.
Song Zhou, Chuanxi Xu, Hui Wu, Jing Zhang, Yuehua Lin, Juanqin Wang, Jeff Gray, and Barrett Bryant, “E-R Modeler: A Database Modeling Toolkit for Eclipse,” 42nd Annual ACM SE Conference, Huntsville, AL, April 2004,pp. 160-165.
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.
65
Representative Publications (Cont’) Workshop papers (10):
Yan Liu, Jing Zhang, and John Strassner, “Model-Driven Adaptive Self-Healing for Autonomic Computing,” The 3rd IEEE International Workshop on Modeling Autonomic Communication Environments (MACE 2008), Samos Island, Greece, September 22-26, 2008.
John Strassner, Yan Liu and Jing Zhang, “A Context-Aware Policy Model to Support Autonomic Networking,” The First IEEE International Workshop on Model-Driven Development of Autonomic Systems (MDDAS) - A Workshop held at COMPSAC, Turku, Finland, July-August 2008.
Michael Jiang, Jing Zhang, David Raymer and John Strassner, “A Modeling Framework for Self-Healing Software Systems,” [email protected] - A Workshop held at MoDELS Conference, Nashville, TN, October 2007.
Jing Zhang, Thomas Cottenier, Aswin van den Berg, and Jeff Gray, “Aspect Interference and Composition in the Motorola Aspect-Oriented Modeling Weaver,” MoDELS Workshop on Aspect-Oriented Modeling, Genova, Italy, October 2006.
Arundhati Kogekar, Dimple Kaul, Aniruddha Gokhale, Paul Vandal, Upsorn Praphamontripong, Swapna Gokhale, Jing Zhang, Yuehua Lin, Jeff Gray, “Model-driven Generative Techniques for Scalable Performabality Analysis of Distributed Systems,” IPDPS Workshop on Next Generation Systems, Rhodes Island, Greece, April 2006.
Jing Zhang, Jeff Gray, and Yuehua Lin, “A Model-Driven Approach to Enforce Crosscutting Assertion Checking,” 27th ICSE Workshop on the Modeling and Analysis of Concerns in Software (MACS), St. Louis, MO, May 2005.
Jing Zhang, Jeff Gray, and Yuehua Lin, “A Generative Approach to Model Interpreter Evolution,” 4th OOPSLA Workshop on Domain-Specific Modeling, Vancouver, BC, Canada, October 2004, pp. 121-129.
Yuehua Lin, Jing Zhang, and Jeff Gray, “Model Comparison: A Key Challenge for Transformation Testing and Version Control in Model Driven Software Development,” OOPSLA Workshop on Best Practices for Model-Driven Software Development, Vancouver, BC, Canada, October 2004.
Jing Zhang and Jeff Gray, “Legacy System Evolution through Model-Driven Program Transformation,” 8th IEEE International Enterprise Distributed Object Computing Conference (EDOC 2004) Workshop on Model-Driven Evolution of Legacy Systems (MELS), Monterey, CA, September 2004.
Jeff Gray, Yuehua Lin, and Jing Zhang, “Aspect Model Weavers: Levels of Supported Independence,” Middleware 2003: Workshop on Model-driven Approaches to Middleware Applications Development, Rio de Janeiro, Brazil, June 2003.
66
Publication, Software and Video demos available at:http://www.cis.uab.edu/gray/Research/C-SAW/
67
Backup
68
Application Evolution
Evolution Scenario 1: Application Evolution
ModelInterpretatio
n
Model Interpreters
Models
Modeling Environment
ApplicationDomain
App1
App2
App3
Environment Evolution
MetaprogrammingInterface
Formal Specifications
Meta-LevelTranslation
Model Builder
Changes are made to the domain models Model interpretation re-synthesizes the whole application system
Application Evolution
Complete regeneration is not always a plausible solution when applied to existing large legacy systems
69
Environment Evolution
Evolution Scenario 2: Environment Evolution
Environment Evolution
Changes are made to the metamodel Model migration to support domain model evolution
ModelInterpretatio
n
Model Interpreters
Models
Modeling Environment
ApplicationDomain
App1
App2
App3
MetaprogrammingInterface
Formal Specifications
Meta-LevelTranslation
Model Builder
Application Evolution
Advanced mechanism is needed to support crosscutting evolutionary concerns
70
Comparison of DSM to Programming Language and Database Definition
Domain-SpecificModeling
ProgrammingLanguage Definition
Database SchemaDefinition
Schema definitionMetamodel for aspecific domain(e.g., Petri Net)
Grammar for a specificlanguage (e.g., Java)
Table, constraint, and storedprocedure definitions for a
specific domain (e.g., payroll database)
Schema instance
Domain model (e.g., Petri Net model of a teller
machine)
A program written in aspecific language
Intension of a database at aspecific instance in time
(e.g., the June 2008 payrollinstance)
Schema execution Model interpreterLanguage
compiler/interpreter
Transactions and behavior ofstored procedures
in an executing application