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

組込みソフトウェアシンポジウム ESS 2004
アスペクト指向に基づく
拡張可能な
MDAモデルコンパイラ
鵜林 尚靖，佐野 慎治，前野 雄作，村上 聡，
片峯 恵一，橋本 正明（九州工業大学）
玉井 哲雄（東京大学）
２００４年１０月１５日
1
ＭＤＡとは
従来の開発
ＭＤＡによる開発
分析
CIM
PIM
設計
PSM
コーディング
設計フェーズが
大きく変化！
モデルコンパイラ
による自動変換
ソース・コード
MDA: Model-Driven Architecture
PIM: Platform Independent Model
CIM: Computation Independent Model PSM: Platform Specific Model
2
モデル変換の例（Ｓｔｒｕｔｓの場
合）
ステップ１： 複数ＰＩＭの合成
①PIMクラスのマージ
ステップ２： アクションフォーム
Ｂｅａｎへの変換
②Bean規約名に変更
③ActionFormを継承
④setter/getterを追加
ステップ３： アクションクラス
の新規作成
⑤アクションクラスを生成
⑥Actionを継承
⑦executeメソッドを追加
⑧メソッド本体を追加
ＰＩＭ
ＰＳＭ
3
研究のアプローチ
ＭＤＡの課題
モデル作成者自身がアプリケーションの特性や目的に応
じてモデル変換規則を定義するのが難しい eg. ＱＶＴ
アスペクト指向に基づいたモデルコンパイラ
モデリング言語ＡｓｐｅｃｔＭ
ゴール
 モデル作成者はモデリングの一環としてアスペクトを定
義することにより、モデルコンパイラの機能を拡張できる
 モデル変換記述も通常のモデリングも同じ土俵で考える
ことができる（モデリングレベルのメタプログラミング）
4
組込みソフトウェア開発への応用
ＰＳＭの作り方
リソースの観点でクラスを再編成
例：利用されていないクラスやメソッドを削除（ＮＥ型）
同じノードに割り当てられるクラスを１つにマージ（ＣＭ型）
開発プロセス（利用局面）
少しずつ仕様が異なる組込みプロダクト毎にモデル変換
を最適化，変更する
モデル作成者自身がアプリケーションの特性に応
じてモデルコンパイラを構築することが可能
5
拡張可能モデルコンパイラの考え方
アスペクト
アスペクト
アスペクト図
(モデル変換モジュール
(モデル変換モジュール
(モデル変換モジュール
としてのアスペクト)
としてのアスペクト)
としてのアスペクト)
ＸＭＬ
アスペクトを追加する
ことにより様々な変換
を可能にする
UMLモデル
(クラス図)
ＸＭＬ
weave
UMLモデル
(クラス図)
モデルコンパイラ
ＸＭＬ
アスペクト図
(システム構成モジュール
としてのアスペクト)
ＸＭＬ
アスペクト指向メカニズムにより
モデルコンパイラを実現！
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
モデル変換のためのＪＰＭ
モデル変換機能
操作本体の変更
クラスのマージ
クラスの追加/削除
PA
CM
NE
OC
RN
RL
○
①PIMクラスのマージ
ＣＭ
②Bean規約名に変更
○
ＲＮ
○
③ActionFormを継承
操作の追加/削除
○
属性の追加/削除
○
ＲＬ
④setter/getterを追加
クラス名の変更
○
操作名の変更
○
属性名の変更
○
ＯＣ
⑤アクションクラスを生成
ＮＥ
⑥Actionを継承
継承の追加/削除
○
集約の追加/削除
○
関連の追加/削除
○
PA（pointcut & advice），CM（composition），NE（new element），
OC（open class），RN（rename），RL（relation）
ＲＬ
⑦executeメソッドを追加
ＯＣ
⑧メソッド本体を追加
ＰＡ
9
モデル変換のためのＪＰＭ（つづき）
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クラスを
ＡｓｐｅｃｔＭの記述例
マージして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変換ルール
クラス図
（ＰＩＭ）
XSLT処理系
クラス図
（ＰＳＭ）
12
何故、アスペクト指向なのか？
（研究のモチベーション）



実装に関わる部分は横断的関心事。
ＭＤＡにおけるモデル変換は実装に関わる部
分の変換であるが、モデル変換の対象はこれ
に留まらない。最適化、等々。Active Library
の考え方をモデルコンパイラに導入する必要
はないか？
上流段階（ユースケースや設計レベル）での
アスペクト指向サポートとＭＤＡサポートを
同じメカニズムで実現できる。
13
関連研究
Ｓｔｅｉｎ他［ＡＯＳＤ２００２］
アスペクトをＵＭＬ図として表現する方法を提案
モデリング段階のアスペクトはＡｓｐｅｃｔＪなどのＡＯＰ言語に変換
するもので、この方法ではＭＤＡは実現できない
ＡｓｐｅｃｔＭのアスペクトはＵＭＬ図自身を操作するもの
Ｇｒａｙ他［ＧＰＣＥ２００３］
ＡＯＤＭ（Aspect-Oriented Domain Modeling）を提案
属性や関連などのモデル要素を追加する機能をもつ
ＭＤＡなどの一般的なモデル変換を対象にしたものではない
Ｓｉｌｌｉｔｏ他［ＥＣＯＯＰ２００４］
ユースケースレベルのポイントカットを提案
上流のモデリング段階においてもＪＰＭの考え方が有効であるこ
とを示した
14
まとめ


ＭＤＡのモデルコンパイラをアスペクトを組
み合わせることにより実現する方式を提案
従来別々の概念と考えられていたアスペクト
指向とＭＤＡを同じ枠組みで捉えることが可
能になった
15