アスペクト指向に基づく 拡張可能な MDAモデルコンパイラ

組込みソフトウェアシンポジウム ESS 2004
アスペクト指向に基づく
拡張可能な
MDAモデルコンパイラ
鵜林 尚靖,佐野 慎治,前野 雄作,村上 聡,
片峯 恵一,橋本 正明(九州工業大学)
玉井 哲雄(東京大学)
2004年10月15日
1
MDAとは
従来の開発
MDAによる開発
分析
CIM
PIM
設計
PSM
コーディング
設計フェーズが
大きく変化!
モデルコンパイラ
による自動変換
ソース・コード
MDA: Model-Driven Architecture
PIM: Platform Independent Model
CIM: Computation Independent Model PSM: Platform Specific Model
2
モデル変換の例(Strutsの場
合)
ステップ1: 複数PIMの合成
①PIMクラスのマージ
ステップ2: アクションフォーム
Beanへの変換
②Bean規約名に変更
③ActionFormを継承
④setter/getterを追加
ステップ3: アクションクラス
の新規作成
⑤アクションクラスを生成
⑥Actionを継承
⑦executeメソッドを追加
⑧メソッド本体を追加
PIM
PSM
3
研究のアプローチ
MDAの課題
モデル作成者自身がアプリケーションの特性や目的に応
じてモデル変換規則を定義するのが難しい eg. QVT
アスペクト指向に基づいたモデルコンパイラ
モデリング言語AspectM
ゴール
 モデル作成者はモデリングの一環としてアスペクトを定
義することにより、モデルコンパイラの機能を拡張できる
 モデル変換記述も通常のモデリングも同じ土俵で考える
ことができる(モデリングレベルのメタプログラミング)
4
組込みソフトウェア開発への応用
PSMの作り方
リソースの観点でクラスを再編成
例:利用されていないクラスやメソッドを削除(NE型)
同じノードに割り当てられるクラスを1つにマージ(CM型)
開発プロセス(利用局面)
少しずつ仕様が異なる組込みプロダクト毎にモデル変換
を最適化,変更する
モデル作成者自身がアプリケーションの特性に応
じてモデルコンパイラを構築することが可能
5
拡張可能モデルコンパイラの考え方
アスペクト
アスペクト
アスペクト図
(モデル変換モジュール
(モデル変換モジュール
(モデル変換モジュール
としてのアスペクト)
としてのアスペクト)
としてのアスペクト)
XML
アスペクトを追加する
ことにより様々な変換
を可能にする
UMLモデル
(クラス図)
XML
weave
UMLモデル
(クラス図)
モデルコンパイラ
XML
アスペクト図
(システム構成モジュール
としてのアスペクト)
XML
アスペクト指向メカニズムにより
モデルコンパイラを実現!
6
AOPのメカニズム
JPM
Join Point
メソッド呼び出し
メソッド実行
・
・
元ソース
Advice
実行コード
・・・・・・
---
・・・・・・
・・・・・・
・・・・・・
・・・・・・
・・・・・・
・・・・・・
・・・・・・
---
・・・・・・
---
PointCut
AOP: Aspect-Oriented Programming
JPM: Join Point Model
7
AOPとMDA


JPM においてのadviceはプログラム変換と呼
ぶことができる
JPMでモデル変換を記述することが可能にな
るのでは
Join Point
クラス名
Advice
クラス名
属性
・・・
属性①
属性②
操作
・・・
操作
・・・
クラス図
PointCut
8
モデル変換のためのJPM
モデル変換機能
操作本体の変更
クラスのマージ
クラスの追加/削除
PA
CM
NE
OC
RN
RL
○
①PIMクラスのマージ
CM
②Bean規約名に変更
○
RN
○
③ActionFormを継承
操作の追加/削除
○
属性の追加/削除
○
RL
④setter/getterを追加
クラス名の変更
○
操作名の変更
○
属性名の変更
○
OC
⑤アクションクラスを生成
NE
⑥Actionを継承
継承の追加/削除
○
集約の追加/削除
○
関連の追加/削除
○
PA(pointcut & advice),CM(composition),NE(new element),
OC(open class),RN(rename),RL(relation)
RL
⑦executeメソッドを追加
OC
⑧メソッド本体を追加
PA
9
モデル変換のためのJPM(つづき)
JPM
Join point
PA
operation
CM
class
NE
class-diagram
OC
class
RN
class, operation, attribute
RL
class
Pointcut
Advice
before,
after,
around
merge-by-name
記述例
① setX || setY
② set*
③ classA || classB
④ class*
add-class
delete-class
add-operation,
delete-operation,
add-attribute,
delete-attribute
rename
add-inheritance,
delete-inheritance,
add-aggregation,
delete-aggregation,
add-relationship,
delete-relationship10
MessageクラスとMessageProfileクラスを
AspectMの記述例
マージしてPostMessageクラスに変換
aspect
<< CM >>
merge-message-classes
message-classes : class
{ Message || MessageProfile }
merge-message-classes [message-classes]
: merge-by-name
{ PostMessage }
<aspect name="merge-message-classes" type="CM" >
<pointcut name="message-classes" type="class"> Message || MessageProfile </pointcut>
<advice name="merge-message-classes" type="merge-by-name">
<ref-pointcut> message-classes </ref-pointcut>
<advice-body>
<element> PostMessage</element>
</advice-body>
</advice>
</aspect>
11
モデルコンパイラの実装(プロトタイ
プ)
アスペクト図
「アスペクト図→XMI形式」変換
XMI形式アスペクト
「XMI形式アスペクト→XSLT変換
ルール」変換
XSLT変換ルール
クラス図
(PIM)
XSLT処理系
クラス図
(PSM)
12
何故、アスペクト指向なのか?
(研究のモチベーション)



実装に関わる部分は横断的関心事。
MDAにおけるモデル変換は実装に関わる部
分の変換であるが、モデル変換の対象はこれ
に留まらない。最適化、等々。Active Library
の考え方をモデルコンパイラに導入する必要
はないか?
上流段階(ユースケースや設計レベル)での
アスペクト指向サポートとMDAサポートを
同じメカニズムで実現できる。
13
関連研究
Stein他[AOSD2002]
アスペクトをUML図として表現する方法を提案
モデリング段階のアスペクトはAspectJなどのAOP言語に変換
するもので、この方法ではMDAは実現できない
AspectMのアスペクトはUML図自身を操作するもの
Gray他[GPCE2003]
AODM(Aspect-Oriented Domain Modeling)を提案
属性や関連などのモデル要素を追加する機能をもつ
MDAなどの一般的なモデル変換を対象にしたものではない
Sillito他[ECOOP2004]
ユースケースレベルのポイントカットを提案
上流のモデリング段階においてもJPMの考え方が有効であるこ
とを示した
14
まとめ


MDAのモデルコンパイラをアスペクトを組
み合わせることにより実現する方式を提案
従来別々の概念と考えられていたアスペクト
指向とMDAを同じ枠組みで捉えることが可
能になった
15