1. 1 Model Evolution with Aspect-oriented Mechanisms Naoyasu Ubayashi (Kyushu Institute of Technology) Tetsuo Tamai (University of Tokyo) Shinji Sano, Yusaku Maeno, Satoshi Murakami (Kyushu Institute of Technology) 6 September 2005 IWPSE 2005 International Workshop on Principles of Software Evolution

2. 2 Overview  Motivation  An extensible model compiler based on AO  Evolution based on extensible model compiler  Related work  Conclusion

3. 3 1. Motivation

4. 4 Issues to be tackled Model-based development is a software development method in which models are created before source code is written. Although the method is effective, we have to modify models when we face evolution such as change of platforms. These modifications crosscut over many places in the models, and tend to cause unexpected errors. New platforms New requirements Optimization Evolution!

5. 5 How does MDA deal with this problem ? Analysis Design Coding CIM PIM PSM Source code MDA: Model-Driven ArchitecturePIM: Platform Independent Model CIM: Computation Independent ModelPSM: Platform Specific Model OOSDMDA model compiler We can regard PIMs as new kinds of reusable software components because they can be reused even if a platform is changed.

6. 6 But, … Although MDA is effective for software development, it mainly focuses on platform-specific concerns. We have to modify models when we face evolution related to other kinds of concerns including application- specific optimization, security policies, and deployment. It is necessary to allow a modeler to customize transformation rules because model modifications for dealing with these concerns may be specific to an application. Multiple concerns Extensibility

7. 7 Motivating example -- A simple bulletin board system

8. 8 Example of model evolution OriginalFirst VersionSecond Version Variation of Second Version make a product that is executable on the Struts platform optimize memory usage loggin g add a logging function for debugging loggin g modifications crosscut over many places Platform concern Optimization concern Logging concern

9. 9 Our approach We propose a method for model evolution using an extensible model compiler based on aspect orientation, a mechanism that modularizes crosscutting concerns. Previously we proposed an AO modeling language called AspectM that supports modeling-level aspects. We demonstrate the effectiveness of AspectM in terms of model evolution. N.Ubayashi, T.Tamai: Concern Management for Constructing Model Compilers, MACS 2005 (Workshop at ICSE 2005) N.Ubayashi, T.Tamai, et al.: Model Compiler Construction Based on Aspect-oriented Mechanisms, GPCE 2005 (to appear)

10. 10 Extensible model compiler Aspect UML model weave Extensible model compiler UML model Aspect UML model AspectM Using AspectM, a modeler can extend model transformation rules by defining new aspects in the process of modeling. (ex. PIM) (ex. PSM) Modeling

11. 11 Evolution at the modeling level Base Model Model for Product 1 Model for Product 2 Model for Product n Model for Product 1 Model for Product 2 Model for Product n Ver.1 Ver.2 Version Variation model compilation using aspects model compilation using aspects

12. 12 Advantage of our approach Using our extensible model compiler, a series of models can be generated from a single abstract model that embodies only core concerns such as business logics. The model does not include such concerns as platforms and application-specific optimizations. These concerns vary according to product specifications. Model transformations enable us to shift from code- centric product-line engineering (PLE) to model- centric PLE.

13. 13 2. An extensible model compiler based on AO -- from our previous work

14. 14 Aspect orientation AOP is based on the JPM (Join Point Model). Join point Pointcut Advice program execution points including method invocations and field access points a means of extracting a set of join points related to a specific crosscutting concern from all join points a means of raising effects at the join points

15. 15 Aspect orientation at the modeling-level (example) Extension of JPMs (Join Point Models) in AOP classA attributes operations classB attributes operations classC attributes operations join point (class) classA || classB (extract join point whose name is classA or classB) pointcut classA attributes new attributes operations new operations advice add new attributes add new operations classB attributes new attributes operations new operations join point (class) join point (class)

16. 16 JPMs for model transformations JPMJoin pointPointcutAdvice PAoperation Example 1) setX || setY 2) set* 3) classA || classB 4) class* before, after, around CMclass merge-by-name NEclass-diagramadd-class delete-class OCclassadd-operation, delete-operation, add-attribute, delete-attribute RNclass, operation, attribute rename RLclassadd-inheritance, delete-inheritance, add-aggregation, delete-aggregation, add-relationship, delete-relationship PA （ pointcut & advice ）， CM （ composition ）， NE （ new element ）， OC （ open class ）， RN （ rename ）， RL （ relation ）

17. 17 AspectM AspectM is an aspect-oriented modeling language that supports six kinds of JPMs. In AspectM, an aspect can be described in either a diagram or an XML format. AspectM provides the two kinds of aspects: ordinary aspect and component aspect. A component aspect is a special aspect for composing aspects. An aspect can have parameters for supporting generic facilities. By filling parameters, an aspect for a specific purpose is generated.

18. 18 Example of AspectM descriptions > addAttributeX classeAandB : class { pointcut-body=“cname(classA) || cname(classB)” } merge [classAandB] : add-attribute { advice-body=“attributeX” } aspect cname(classA) || cname(classB) attributeX classA classB classC classA new attributes advice add new attributes pointcut classA || classB classB new attributes

19. 19 Implementation of model compiler Aspect diagram (XML) XSLT processor XSLT style sheet for converting aspect (XML) to XSLT style sheet XSLT style sheet for converting UML (XML) to UML (XML) UML diagram (XML) XSLT processor UML diagram (XML) The first transformation phase The second transformation phase Model Compiler

20. 20 3. Evolution using extensible model compiler

21. 21 Example of model evolution OriginalFirst VersionSecond Version Variation of Second Version make a product that is executable on the Struts platform optimize memory usage loggin g add a logging function for debugging loggin g modifications crosscut over many places Platform concern Optimization concern Logging concern

22. 22 ＰＩＭ ＰＳＭ Step1: merge PIMs Step 2: transform the merged class to an action form bean class Step 2: transform the merged class to an action form bean class Step 3: create an action class Model transformation for first version 1) merge PIM classes 2) change the name of merged class 3) inherit ActionForm 4) add setter/getter 5) create an action class 6) inherit Action 7) add execute method 8) add a method body Platform: Struts platform concerns crosscut over model elements

23. 23 Aspect for the first version > MergeClasses inputClasses : class { pointcut-body=“cname(Message) || cname(MessageProfile)” } merge [inputClasses] : merge-by-name { advice-body=“PostMessage” } aspect Step1: merge PIMs Step 2: transform the merged class to an action form bean class Step 2: transform the merged class to an action form bean class Step 3: create an action class 1) merge PIM classes 2) change the name of merged class 3) inherit ActionForm 4) add setter/getter 5) create an action class 6) inherit Action 7) add execute method 8) add a method body Platform: Struts

24. 24 Component, Generics @input-classes@ @merged-class@ @input-classes@ @merged-class@ @merged-class@ concat( @merged-class@,"Form") concat( @merged-class@,"Form") Step1 Step2 component generics

25. 25 Aspect for the second version <aspect name="DeleteAttribute" type="ordinary" jpm="OC"> <pointcut name="postMessageClass" type="class"> cname(PostMessage) <advice name="deleteDate" adviceType="delete-attribute" ref-pointcut="postMessageClass"> date > DeleteAttribute postMessageClasse : class { pointcut-body=“cname(PostMessage)” } merge [postMessageClasse] :delete-attribute { advice-body=“date” } aspect

26. 26 Aspect for a variation <aspect name="LoggingSetter" type="ordinary" jpm="PA"> <pointcut name="allSetter" type="method"> oname(set*) <advice name="logSetter" adviceType="before" ref-pointcut="allSetter"> Log.write() > LoggingSetter allSetter : method { pointcut-body=“oname(set*)” } merge [allSetter] : before { advice-body=“Log.write()” } aspect

27. 27 Model evolution (example) Original Model Optimized Model for Struts Platform + Logging Model for Struts Platform Ver.1 Ver.2 Version Aspect Generic-Classes2ActionFormBean Aspect DeleteAttribute Variation Version Aspect LoggingSetter

28. 28 Towards product-line engineering Aspects are useful for product-line engineering in which a variety of PSMs are generated from a single set of PIMs. Aspect library for.NET Aspect library for J2EE Aspect library for other platforms : Aspect library for product-line B Aspect library for product-line A Aspect library for other product-lines : Application-specific aspects UML diagrams defined by modelers Application-specific aspects UML diagrams Product X Product Y weave

29. 29 4. Related work

30. 30 Related work Aspect-oriented domain modeling (AODM) [J. Ｇｒａｙ et. al. 2003] AODM introduced a language called ECL that provides facilities for adding model elements such as attributes and relations. In Draco, software development processes were considered as a series of transformations. Draco [J. Neighbors 1984] Persistence as an Aspect [A.Rashid and R.Chitchyan 2003] Aspect-oriented mechanisms (+ reflection) for describing database concerns are proposed. QVT [OMG] QVT (Queries, Views, and Transformations) is a model transformation language.

31. 31 5. Conclusion

32. 32 Conclusion We propose a method for model evolution using an extensible model compiler based on aspect orientation. A modeler can extend model transformation rules by defining new aspects in the process of modeling.

33. 33 Appendix

34. 34 Discussion -- Aspect-orientation vs. meta programming Someone might claim that AspectM is not an aspect- oriented language but a meta language for model transformations. AspectM can describe not only model transformation concerns but also ordinary crosscutting concerns such as logging. AspectM unifies (lightweight) meta-programming with ordinary aspect-orientation by extending the idea of JPMs. aspect-orientation lightweight meta-programming JPMs