MACS 2005 First International Workshop on the Modeling and Analysis of Concerns in Software Concern Management for Constructing Model Compilers -- Towards effective MDA Naoyasu Ubayashi (Kyushu Institute of Technology) Tetsuo Tamai (University of Tokyo) Shinji Sano, Yusaku Maeno, Satoshi Murakami (Kyushu Institute of Technology) 16 May 2005

Overview MDA and model compiler Motivation AspectM : Aspect-oriented modeling language Constructing a model compiler using AspectM Discussion Related work Conclusion

MDA and model compiler OOSD MDA model compiler CIM Analysis PIM Design PSM We can regard PIMs as new kinds of reusable software components because they can be reused even if a platform is changed. Coding Source code MDA: Model-Driven Architecture PIM: Platform Independent Model CIM: Computation Independent Model PSM: Platform Specific Model

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

Motivation -- for constructing an effective model compiler Multiple concerns We need to take account of not only platform concerns but also other kinds of model transformation concerns including optimization, real-time constraints, 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. Extensibility

2. Motivation Our Approach We propose a method for constructing an extensible model compiler based on aspect-orientation. Aspect-orientation is useful for platform descriptions because they crosscut over many model elements. A modeler can extend model transformation rules by defining new aspects in the process of modeling. Aspect Aspect UML model weave UML model UML model UML model PIM PSM Extensible model compiler

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

JPMs for model transformations 3. AspectM JPMs for model transformations transformation type PA CM NE OC RN RL change a method body ○ merge classes add/delete classes add/delete operations add/delete attributes rename classes rename operations rename attributes add/delete inheritances add/delete aggregations add/delete relationships 1)merge PIM classes 　　ＣＭ 2) change the name ofmerged 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 　　ＰＡ PA（pointcut & advice），CM（composition），NE（new element），OC（open class），RN（rename），RL（relation）

JPMs for dealing with multiple model transformation concerns 3. AspectM JPMs for dealing with multiple model transformation concerns JPM Join point Pointcut Advice PA operation Example 1) setX || setY 2) set* 3) classA　|| classB　 4) class* before, after, around CM class merge-by-name NE class-diagram add-class delete-class OC add-operation, delete-operation, add-attribute, delete-attribute RN class, operation, attribute rename RL add-inheritance, delete-inheritance, add-aggregation, delete-aggregation, add-relationship, delete-relationship

3. AspectM 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.

Example of AspectM descriptions << CM >> mergeClasses Step1: merge PIMs inputClasses : class { pointcut-body=“cname(Message) || cname(MessageProfile)” } Step 2: transform the merged class to an action form bean class merge [inputClasses] : merge-by-name { advice-body=“PostMessage” } Step 3: create an action class <aspect name=“mergeClasses” type=“ordinary” jpm=“CM" > <pointcut name=“inputClasses” type=“class”> <pointcut-body> cname(Message) || cname(MessageProfile) </pointcut-body> </pointcut> <advice name=“merge” type=“merge-by-name” ref-pointcut=“inputClasses”> <ref-pointcut> message-classes </ref-pointcut> <advice-body> PostMessage </advice-body> </advice> </aspect>

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

Dealing with multiple concerns 4. Constructing a model compiler Dealing with multiple concerns <aspect name=“mergeClasses” type=“ordinary” jpm=“CM" > <pointcut name=“inputClasses” type=“class”> <pointcut-body> cname(Message) || cname(MessageProfile) </pointcut-body> </pointcut> <advice name=“merge” type=“merge-by-name” ref-pointcut=“inputClasses”> <ref-pointcut> message-classes </ref-pointcut> <advice-body> PostMessage </advice-body> </advice> </aspect> concern for merging models <aspect name=“deleteAttribute“ type="ordinary" jpm="OC"> <pointcut name="postMessageClass" type="class"> <pointcut-body>cname(PostMessage)</pointcut-body> </pointcut> <advice name="deleteDate" adviceType="delete-attribute“ ref-pointcut="postMessageClass"> <advice-body>date</advice-body> </advice> </aspect> concern for optimizing memory usage <aspect name="loggingSetter" type="ordinary" jpm="PA"> <pointcut name="allSetter" type="method"> <pointcut-body>oname(set*)</pointcut-body> </pointcut> <advice name="logSetter" adviceType="before“ ref-pointcut="allSetter"> <advice-body>Log.write()</advice-body> </advice> </aspect> concern for logging A modeler can extend model transformation rules by defining new aspects in the process of modeling.

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

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. lightweight meta-programming aspect-orientation JPMs

6. Related work 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. 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. Draco [J. Neighbors 1984] In Draco, software development processes were considered as a series of transformations.

7. Conclusion Conclusion We proposed a method for constructing an extensible model compiler that can deal with multiple model transformation concerns. A modeler can extend model transformation rules by defining new aspects in the process of modeling.