Model-Driven Aspect Adaptation To Support Modular Software Evolution Ph.D. Defense Jing Zhang [email protected] Committee

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




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




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


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


Request_Payment

<< Pointcut >>

<< Pointcut >>

<< Pointcut >>

<< Pointcut >>

activity << Aspect >>

<< binds>>

<< binds>>

<< binds>>

<< binds>>

tjp : thisJoinPointtjp :

TracingAspect

25

Order Processing Model with Tracing Aspect

Receive_Order


Op_Process_Order



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


<< 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




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




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();



} } 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();







} } 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();



BM__ComponentInstrumentation::SendDirectCall(GetId(), "Update", component->GetId(), "GetData1");




} } 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();







} } 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 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




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




Main Menu




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 >>


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




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


Evolution Scenario 1: Application Evolution

ModelInterpretatio

n

Model Interpreters

Models


ApplicationDomain

App1

App2

App3





Model Builder

Changes are made to the domain models Model interpretation re-synthesizes the whole application system


Complete regeneration is not always a plausible solution when applied to existing large legacy systems

69


Evolution Scenario 2: Environment Evolution


Changes are made to the metamodel Model migration to support domain model evolution

ModelInterpretatio

n

Model Interpreters

Models


ApplicationDomain

App1

App2

App3




Model Builder


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

Documents

Model-Driven Aspect Adaptation To Support Modular Software Evolution Ph.D. Defense Jing Zhang [email protected] Committee