Model-Driven Aspect Adaptation To Support Modular Software Evolution

1. March 30th, 2009 Model-Driven Aspect AdaptationTo Support Modular Software Evolution Ph.D. Defense Jing Zhang zhangj@cis.uab.edu 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

2. Model Evolution Inevitable Software Evolution Modular Evolution Legacy Evolution Changeability Comprehensibility Independent Development Co-Evolution Model-Driven Aspect Adaptation Aspect-OrientedActivity Modeling INFM Bold Stroke Overview of Presentation Motivation Challenges Research Goals Approaches Evaluation

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. As the size of system models grows, techniques and tools are needed to automate complex change evolution ∆M: The changes made to the models Challenges in Software Evolution:1. Model Evolution

5. A small modification in the high-level requirements may trigger drastic manual changes in large portions of the low-level legacy source code ∆S: The changes made to the legacy source Challenges in Software Evolution:2. Legacy Evolution

6. Conformity between the models and underlying source code needs to be established in order to maintain the fidelity of the whole system ∆M: The changes made to the models ∆S: The changes reflected in the source code Challenges in Software Evolution:3. Model/Code Co-Evolution

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-understoodand 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 Aspect- Orientation Model-Driven Aspect Adaptation Model/Code Co-Evolution Legacy Evolution Changeability Comprehensibility Independent Development

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. 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) Two Types of Software Restructuring ComputePositionC++ ComputePositionwith LockingC++ NavDisplayC++

12. Model-Driven Engineering • OMG UML-based generic modeling • Rational Rose • Telelogic TAU • … • Domain-specific modeling (DSM) • GME • Microsoft software factories • …

13. Unified Modeling Language (UML) • Structural modeling • Class diagram • Component diagram • Deployment diagram • Behavioral modeling • State machine diagram • Activity diagram • Use case diagram • Interaction diagram

14. Testing Design Simulation Code Generation Telelogic TAU: A UML-based MDE Tool

15. Metamodel DEFINE Model Meta-Level Translation INTERPRET Interpreter void CComponent::InvokeEx(CBuilder &buil der,CBuilderObject *focus, CBui lderObjectList &selected, long param) { CString DMSRoot = ""; DMSRoot = SelectFolder("Please Select DMS Root Folder:"); if (DMSRoot != "") { DMSRulePath = DMSRoot + RULESPATH + "Rules\\"; MSRuleApplierPath = DMSRoot + RULESPATH + "RuleApplier\\"; AfxMessageBox("DMSRulePath = " + DMSRulePath , MB_OK); CString OEPRoot = ""; OEPRoot = SelectFolder("Please Selec Model Interpreters Models Formal Specifications Model Interpretation Domain-Specific Modeling (DSM) in Generic Modeling Environment (GME) Metaprogramming Interface Application Domain Application Evolution Environment Evolution App 1 App 2 App 3 Modeling Environment Model Builder

16. Profiling in Apache Tomcat Server http://www.parc.com/research/projects/aspectj/ Crosscutting Concerns Problems • Reusability • Maintainability • Evolvability

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. Where What 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 Aspect applicability Pointcut Aspect functionality 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

22. Order Processing Activity Model Operation Action Send Signal Action Receive Event Action Fork

23. Aspect-Activity Metamodel (Profile)

24. Tracing Aspect, Pointcuts and Advice

25. Order Processing Model with Tracing Aspect

26. Pointcut Composition in AOAM • Operators • and (&&) • or (||) • not (!) • cflow • cflowbelow • within

27. Advice1 Advice2 Shared Join Point 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

28. Exception Aspect Tracing Aspect Logging Aspect Encryption Aspect Aspect Composition in AOAM • 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

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. Conforms To Conforms To Conforms To Model-Driven Aspect Adaptation Framework Meta- metamodel Conforms To Aspect Metamodel Metamodel Model Extractor Model Model Composer Aspect Model Enhanced Model Aspect Code Generator Simulation/Testing Source Code Enhanced Code Aspect Code Program Composer

32. Roles in MDAA Process

33. DSM Metamodel UML Metamodel MDAA Component: Model Extractor

34. MDAA Component: Model Composer AOM Weaver • C-SAW • AOAM Weaver

35. MDAA Component: Aspect Code Generator

36. MDAA Component: Program Composer • Program transformation engine • Design Maintenance System (DMS) • ASF + SDF • … • AOP weaver • AspectJ • AspectC++ • …

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 • 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 Metamodel Composer

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 Model

45. ESML Component with Logging Aspect

46. Generated DMS Transformation Rules to Insert “LogOnMethodExit” Aspect

47. Log on getData1_() method entry Log on reading data1_ Log on Update() method entry Log on writing data1_ Log on Update() method exit Transformed C++ Source Code log.add("data1_=" + data1_); log.add("data1_=" + data1_); log.add("data1_=" + data1_); log.add("data1_=" + data1_); log.add("data1_=" + data1_);

48. Experimental Results

49. MDAA Interpreters for Different Aspect Models

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