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

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

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

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

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

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

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

8. 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）

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

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

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

12. 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)

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

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

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

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

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