ソフトウェア開発手法の最前線 ～ アスペクト指向、MDA、MIC ～

Download Report

Transcript ソフトウェア開発手法の最前線 ～ アスペクト指向、MDA、MIC ～ 

東芝情報システム（株）殿向け
チュートリアル
ソフトウェア開発手法の最前線
～ アスペクト指向、ＭＤＡ、ＭＩＣ ～
九州工業大学
情報工学部 知能情報工学科
鵜林尚靖
２００５年９月１２日
1
内容





アスペクト指向の背景
アスペクト指向の概要
アスペクト指向、ＭＤＡ、そしてＭＩＣ
アスペクト指向の今後
研究室の紹介
2
ソフトウェア開発手法の変遷
60 年代
70 年代
80 年代
90 年代
2000 年代
構造化手法
構造化プログラミング
構造化分析
構造化設計
オブジェクト指向手法
ＯＯＰ
ＯＯＡ
ＯＯＤ
パターン
フレームワーク
コンポーネント
ＥＡ
プロダクトライン
アジャイル, ＸＰ
ＭＤＡ
アスペクト指向
3
１．アスペクト指向の背景
4
アスペクト指向とは何？
一言でいうと
「モジュール化メカニズム」の一つ
5
モジュール化メカニズムの歴史
構造化
機能中心のため、データの変更に対して脆い
データ抽象
データとそれに関連する操作をまとめてしまおう
抽象データ型
データとそれに関連する操作をまとめて型にしよう
オブジェクト指向
継承機構も入れて、再利用性を高めよう
6
モジュール化の理想像
ソフトウェア構造
要求分析
設計
実装
問題
領域
分析時の
関心事
設計時の
関心事
モジュールの
構成
問題領域の構造がソフトウェア構造に対応する
ソフトウェア構造を構成する関心事を自然にモジュール化できる
（関心事の分離 “Separation of Concerns” Edsger Wybe Dijkstra ）
7
良いモジュール化
org.apache.tomcat におけるXML parsing
– 赤い線はXML parsingを行うコード行を示す
機能要件を
きれいにモジュール化
– １箇所にモジュール化されている
AspectJ. http://eclipse.org/aspectj/より抜粋
8
しかし、ログ処理の場合は．．．
複数のオブジェクトにまたがる
（Crosscutting Concerns）
org.apache.tomcat におけるログ処理
– 赤い線はログ処理を行うコード行を示す
– １箇所ではない
– しかも、数多くの場所に分散している（tangling and scattering）
AspectJ. http://eclipse.org/aspectj/より抜粋
9
現実のモジュール化は．．．
ソフトウェア構造
要求分析
設計
実装
問題
領域
分析時の
関心事
設計時の
関心事
モジュールの
構成
（問題意識）
上流の関心事が、下流に行くにしたがって構造的に分散してしまう
（オブジェクト指向でも解決できない問題がある）
10
従来手法の問題
オブジェクト指向プログラミングは、機能要件のカプセル化には優れているが、
横断的関心事（ Crosscutting Concerns ）の表現には必ずしも向いていない。
＜横断的関心事の例＞
・エラーチェック戦略
・セキュリティ
・デザインパターン
・同期制御
・資源共有
・分散にかかわる関心事
・性能最適化
・プラットフォーム
性能最適化のためのコードを追加しようとする
と、コードが複数のオブジェクトに分散してしま
い、見通しの悪いプログラムになってしまう。
「分かりやすく性能も良い」プログラムを作る
のが難しい。
11
ソフトウェアの構造
最適化
メモリ容量
ＨＷ特性
応答性
プラットフォーム
きれいなプログラムを作成したい！
でも、プラットフォーム適合、ＨＷ特性、性能向上、例外
のためのコードを追加すると
どんどんプログラムが汚くなってしまう。。。
12
解決方法




MIC (Model-Integrated Computing)
AOP (Aspect-Oriented Programming)
IP (Itentional Programming)
GenVoca
今日はアスペクト指向について紹介
アスペクト指向と絡めて、ＭＤＡ、ＭＩＣについて紹介
13
２．アスペクト指向の概
要
14
アスペクト指向を実現する
言語処理系、システム







AspectJ （Gregor Kiczales, et al.）
Hyper/J, CME （Harold Ossher, et al.）
DemeterJ （Karl J. Lieberherr, et al.）
Composition filters （Mehmet Aksit, et al.）
Caesar （Mira Mezini, et al.）
JBoss-AOP
AspectWerkz
Ｊ２ＥＥ環境への適用が増えている！
ＰＯＪＯ（Plain Old Java Object）
今日はＡｓｐｅｃｔＪベースで紹介
15
AOP（Aspect-Oriented Programming）
AOPとは、同期制御、資源共有、性能最適化など複数のオブ
ジェクトにまたがる関心事をアスペクトというモジュール概念を
用いて記述するプログラミング方式
オブジェクト
（通常の機能）
weaver
プログラム
アスペクト
（オブジェクトに
またがる関心事）
・複数のオブジェクトにまたがる関心事を見通しよく記述できる！
・「分かりやすく性能も良い」プログラムが作れる！
16
ＡＯＰのメカニズム ＪＰＭ（Join Point
Model）
aspect PublicErrorLogging {
static Log log = new Log();
pointcut publicInterface ():
target (mypackage..*) && call (public * *(..));
after() returning (Object o): publicInterface() {
System.out.println(thisJoinPoint);
}
after() throwing (Error e): publicInterface() {
log.write(e);
}
メソッド呼び出し、
変数参照／更新など
の実行点を捕まえる
weaving
}
ログ処理コード
の埋め込み
（advice）
プログラム上
の様々な実行
点
（join point）
実行点の取り出し
（pointcut）
実行点の中から
ログ処理に関わ
る部分を抽出
17
ＡｓｐｅｃｔＪの主要概念
振る舞いへの作用
ジョインポイント（ｊｏｉｎ ｐｏｉｎｔ）
ポイントカット（ｐｏｉｎｔｃｕｔ）
アドバイス（ａｄｖｉｃｅ）
構造への作用
インタータイプ定義
ｄｅｃｌａｒｅ句による宣言
18
簡単なＡｓｐｅｃｔＪプログラム
アスペクト
HelloWorld.java
public class HelloWorld {
public static void main ( String [], args) {
HelloWorld app = new HelloWorld ();
app.hello();
}
Trace.java
インタータイプ
定義
public aspect Trace {
private String HelloWorld.mes = “トレース”;
ポイントカット
public pointcut atHello() :
call (void HelloWorld.hello());
void hello() {
System.out.println(“こんにちは！”);
}
before(HelloWorld h) : atHello() && target(h) {
System.out.println(h.mes + “呼び出し前”);
}
}
after(HelloWorld h) : atHello() && target(h) {
System.out.println(h.mes + “呼び出し後”);
}
}
アドバイス
「AspectJによるアスペクト指向プログラミング入門」
長瀬、天野、鷲崎、立堀(著) より
19
例題：
簡易図形エディタ
Display
* FigureElement
Figure
makePoint(..)
makeLine(..)
Point
getX()
getY()
setX(int)
setY(int)
moveBy(int, int)
moveBy(int, int)
2
Line
getP1()
getP2()
setP1(Point)
setP2(Point)
moveBy(int, int)
operations that
move elements
AspectJ. http://eclipse.org/aspectj/より抜粋
20
通常の保守、改良
class Line {
class Line {
private Point p1, p2;
private Point p1, p2;
Point getP1() { return p1; }
Point getP2() { return p2; }
Point getP1() { return p1; }
Point getP2() { return p2; }
void setP1(Point p1) {
this.p1 = p1;
void setP1(Point p1) {
this.p1 = p1;
Display.update(this);
}
void setP2(Point p2) {
this.p2 = p2;
Display.update(this);
}
}
void setP2(Point p2) {
this.p2 = p2;
}
}
}
class Point
{
class Point
private int x = 0, y = 0;
private int x = 0, y = 0;
int getX() { return x; }
int getY() { return y; }
int getX() { return x; }
int getY() { return y; }
void setX(int x) {
this.x = x;
void setX(int x) {
this.x = x;
Display.update(this);
}
void setY(int y) {
this.y = y;
Display.update(this);
}
}
void setY(int y) {
this.y = y;
}
}
{
変更が複数の
クラスに散らば
ってしまう！
}
AspectJ. http://eclipse.org/aspectj/より抜粋
21
AspectJによる保守、改良
class Line {
aspect DisplayUpdating {
private Point p1, p2;
pointcut move(FigureElement figElt):
target(figElt) &&
(call(void FigureElement.moveBy(int, int) ||
call(void Line.setP1(Point))
||
call(void Line.setP2(Point))
||
call(void Point.setX(int))
||
call(void Point.setY(int)));
Point getP1() { return p1; }
Point getP2() { return p2; }
void setP1(Point p1) {
this.p1 = p1;
}
void setP2(Point p2) {
this.p2 = p2;
}
after(FigureElement fe) returning: move(fe) {
Display.update(fe);
}
}
class Point
{
}
private int x = 0, y = 0;
int getX() { return x; }
int getY() { return y; }
void setX(int x) {
this.x = x;
}
void setY(int y) {
this.y = y;
}
変更が１つのアスペクトに局所化される！
}
AspectJ. http://eclipse.org/aspectj/より抜粋
22
クラスを横断するアスペクト
Display
* FigureElement
Figure
makePoint(..)
makeLine(..)
Point
getX()
getY()
setX(int)
setY(int)
moveBy(int, int)
moveBy(int, int)
2
Line
getP1()
getP2()
setP1(Point)
setP2(Point)
moveBy(int, int)
DisplayUpdating
AspectJ. http://eclipse.org/aspectj/より抜粋
23
３．アスペクト指向、Ｍ
ＤＡ、
そしてＭＩＣ
24
（１） ＭＤＡ
25
現状の課題（オブジェクト指向分析、
設計）

モデルの再利用は限定的： 分析や設計時のモデル
資産を蓄積することにより、ある程度の再利用部品
化が可能。しかし、オブジェクト指向による設計モ
デルの多くは実装に依存する部分と依存しない部分
が明確に切り分けられていない場合が多く、再利用
の範囲は限定的。

人手によるモデル間の変換： 分析モデルから設計
モデルへの変換、設計モデルからプログラムコード
への変換は多くの場合人手で行われている。せっか
くモデルを作成しても、直接プログラムコードには
つながらない。
26
MDA（Model-Driven Architecture）とは
実装技術（Ｊ２ＥＥや．ＮＥＴなど）から分析/設計を
独立させ、設計情報が実装技術に左右されないよ
うにする技術
分析/設計部分はプラットフォームに
依存しない為、再利用可能
UML２の目玉
27
ＭＤＡと従来プロセスの違い
従来の開発
ＭＤＡによる開発
分析
CIM
PIM
設計
PSM
コーディング
設計フェーズが
大きく変化！
モデルコンパイラ
による自動変換
ソース・コード
CIM: Computation Independent Model
PIM: Platform Independent Model
PSM: Platform Specific Model
28
モデル変換の例（Ｓｔｒｕｔｓの場
合）
ステップ１： 複数ＰＩＭの合成
①PIMクラスのマージ
ステップ２： アクションフォーム
Ｂｅａｎへの変換
②Bean規約名に変更
③ActionFormを継承
④setter/getterを追加
ステップ３： アクションクラス
の新規作成
⑤アクションクラスを生成
⑥Actionを継承
⑦executeメソッドを追加
⑧メソッド本体を追加
ＰＩＭ
ＰＳＭ
29
ＭＤＡのメリット

コード中心開発からモデル中心開発へパラダイムシ
フト： 開発者は特定のプラットフォームやプログ
ラミング技術にとらわれることなく、PIMの開発に
全力を注ぐことができる。

新しいタイプのコンポーネント化： PIMモデル部
品とモデル変換規則をライブラリ化することにより、
様々な機能やプラットフォームに対応したプロダク
ト群を生成することが可能になり、プロダクトライ
ン型開発の実現につながる。
30
ＭＤＡ実現のための鍵


厳密なモデル表記 （ＭＯＦ、ＯＣＬ）
厳密なモデル変換定義 （ＱＶＴ）
QVTの例
mapping Simple_Class_To_Java_Class
refine Simple_Class_And_Java_Class {
domain {(SM.Class)[name = n, attributes = A] }
body {
(JM.Class)[
name = n,
attributes = A->iterate(a as ={} |
as + Simple_Attribute_To_Java_Attribute(a))
]
}
}
MOF: Meta Object Facility
OCL: Object Constraint Language
QVT: Queries, Views, and Transformations
31
（２）アスペクト指向と
の接点
32
何故、アスペクト指向なのか？

プラットフォームに関わる部分は横断的関心事。
→ アスペクトが得意とするところ

モデル変換の対象はプラットフォームのみに留ま
らない。最適化、等々。
→ 現状のＭＤＡはモデル変換の一部しか
捉えていない

上流段階（ユースケースや設計レベル）でのアス
ペクト指向サポートが必要。セキュリティなどの
横断的関心事はモデリング段階で考える必要があ
る。
→ Early Aspect
33
ＭＤＡとアスペクト指向
ＰＩＭモデル（ＵＭＬ）
アプリケーション
ｗｅａｖｉｎｇ
実装環境対応コード
アプリケーション
実装環境対応コード
マッピングルール（ＭＯＦ ＱＶＴ）
アスペクト記述言語
「AspectJによるアスペクト指向プログラミング入門」
長瀬、天野、鷲崎、立堀(著) より
34
我々の研究室での研究事例
アスペクト指向に基づく拡張可能なモデルコンパイラ
Naoyasu Ubayashi, Tetsuo Tamai, Shinji Sano, Yusaku Maeno, Satoshi Murakami:
Model Compiler Construction Based on Aspect-Oriented Mechanisms,
4th ACM SIGPLAN International Conference on Generative Programming
and Component Engineering (GPCE 2005), to appear
35
当研究室のＡｓｐｅｃｔＭモデルコン
パイラ
アスペクト
アスペクト
アスペクト図
(モデル変換モジュール
(モデル変換モジュール
(モデル変換モジュール
としてのアスペクト)
としてのアスペクト)
としてのアスペクト)
ＸＭＬ
アスペクトを追加する
ことにより様々な変換
を可能にする
UMLモデル
(クラス図)
ＸＭＬ
weave
UMLモデル
(クラス図)
モデルコンパイラ
ＸＭＬ
アスペクト図
(システム構成モジュール
としてのアスペクト)
ＸＭＬ
アスペクト指向メカニズムにより
モデルコンパイラを実現！
36
モデルレベルのアスペクト指向
join point
(class)
classA
pointcut
classA || classB)
advice
add new attributes
add new operations
attributes
classA
attributes
new attributes
operations
new operations
operations
classB
join point
(class)
classC
attributes
classB
attributes
attributes
operations
join point
(class)
横断的関心事（プラット
フォームなど）をモデル
に挿入
new attributes
operations
new operations
operations
ＪＰＭの概念を拡張（通常のＡｓｐｅｃｔＪにおけるＪＰＭとは異なる）
37
モデル変換のためのＪＰＭ
モデル変換機能
操作本体の変更
クラスのマージ
クラスの追加/削除
PA
CM
NE
OC
RN
RL
○
○
○
操作の追加/削除
○
属性の追加/削除
○
クラス名の変更
○
操作名の変更
○
属性名の変更
○
継承の追加/削除
○
集約の追加/削除
○
関連の追加/削除
○
PA（pointcut & advice），CM（composition），NE（new element），
OC（open class），RN（rename），RL（relation）
38
モデル変換のためのＪＰＭ（つづき）
JPM
Join point
Pointcut
PA
operation
before,
after,
around
CM
class
merge-by-name
NE
class-diagram
OC
class
RN
class, operation, attribute
rename
RL
class
add-inheritance,
delete-inheritance,
add-aggregation,
delete-aggregation,
add-relationship,
delete-relationship39
記述例
① setX || setY
② set*
③ classA || classB
④ class*
Advice
add-class
delete-class
add-operation,
delete-operation,
add-attribute,
delete-attribute
ＡｓｐｅｃｔＭによるモデル記述
６つのＪＰＭをサポート（新たなＪＰＭを追加可能）
３種類のアスペクトをサポート（通常アスペクト、コンポーネント
アスペクト、テンプレートアスペクト）
ＵＭＬを対象としたＸＭＬベースのＡＯＰ言語
ダイアグラム表記
aspect
<< jpm-type >>
aspect-name
pointcut-name : joinpoint-type
{ pointcut-body }
：
：
advice-name [pointcut-name]: advice-type
{ advice-body }
：
：
ダイアグラム保存形式（XMLベース）
<aspect name=aspect-name type=jpm-type >
{ <pointcut name=pointcut-name
type=joinpoint-type>
pointcut-body
</pointcut> } +
{ <advice name=advice-name
type=advice-type
ref-pointcut=pointcut-name </advice>
<advice-body>advice-body </advice-body>
</advice> } +
</aspect>
40
AspectM 支援ツール
Model Editor (Eclipse UML)
Model Compiler
UML diagrams
XMI (PIM)
Aspect diagrams
XMI
XSLT style sheet
AspectM
metamodel
(EMF)
XMI (PSM)
XSLT style sheet
Java code
41
アスペクト導入のためのメタモデル
Class
ＵＭＬメタモデル
を拡張
Aspect
42
（３）ＭＤＡからＭＩ
Ｃへ
43
ＭＤＡの先にあるもの
ＭＤＡ： プラットフォームに関する関心事を分離
アスペクト指向： プラットフォームのみならず、モデリング段階
の横断的関心事を分離
ドメイン指向モデリング
ドメイン専用モデリング言語
（DSL: Domain-Specific Modeling Language）
44
Model-Integrating Computing (MIC)



Vanderbilt Univ. のISIS（Institute for Software
Integrated Systems）で研究開発。
ドメイン専用モデリング環境を提供。
アスペクト指向への応用は、J.Gray (現在、
Univ. of Alabama )が研究。ＡＯＤＭ（AspectOriented Domain Modeling）を提案。
45
Model-integrated approach to
software composition
［出典］
Janos Sztipanovits and Gabor Karsai:
Generative Programming for Embedded Systems,
GPCE2002, LNCS2487, pp.32--49, 2002
46
Meta-modeling language architecture
適用例
［出典］
Janos Sztipanovits and Gabor Karsai:
Generative Programming for Embedded Systems,
GPCE2002, LNCS2487, pp.32--49, 2002
47
４．アスペクト指向の
今後
48
アスペクト指向の今後


現在、プログラミング周りで研究が活発（８
０年代のＯＯＰ研究を彷彿させる）
今後は、適用事例の拡大、開発方法論の整備、
アスペクトコンポーネント・フレームワーク
の整備に向かって行くと思われる（９０年代
のＯＯソフトウェアエンジアリングの発展に
類似）
歴史は繰り返す．．．
49
AOSD ソフト開発工程全体への波及
AOP（Aspect-Oriented Programming）
から
AOSD（Aspect-Oriented Software Development）
へ
AO: Aspect-Oriented
要求分析
Early Aspect
設計
AO
Design Pattern
AO
Modeling
Aspect
Mining
AO
Framework
実装
AO
Language
AO
Component
AO
Database
50
上流段階のアスペクト研究例
Ｓｔｅｉｎ他［ＡＯＳＤ２００２］
アスペクトをＵＭＬ図として表現する方法を提案
モデリング段階のアスペクトはＡｓｐｅｃｔＪなどのＡＯＰ言語に変換
するもので、この方法ではＭＤＡは実現できない
ＡｓｐｅｃｔＭのアスペクトはＵＭＬ図自身を操作するもの
Ｇｒａｙ他［ＧＰＣＥ２００３］
ＡＯＤＭ（Aspect-Oriented Domain Modeling）を提案
属性や関連などのモデル要素を追加する機能をもつ
ＭＤＡなどの一般的なモデル変換を対象にしたものではない
Ｓｉｌｌｉｔｏ他［ＥＣＯＯＰ２００４］
ユースケースレベルのポイントカットを提案
上流のモデリング段階においてもＪＰＭの考え方が有効であるこ
とを示した
51
アスペクト指向言語の変遷
ドメイン専用ＡＯＰ言語を個々に開発するアプローチ
（１９９７年頃まで）
Weaverを開発するのが大変
汎用ＡＯＰ言語（AspectJ等： 「Pointcut＋Advice」メカニズ
ム）のアプローチ
（現在）
適用範囲が限定される
拡張可能ドメイン専用ＡＯＰ言語の（Xaspect等）アプローチ
（これから）
52
アスペクト指向に関する情報源
ポータルサイト
http://aosd.net
国際会議
Aspect-Oriented Software Development (AOSD)
OOPSLA, ECOOP, GPCE, ICSE, FSE, ICFP など
53
５．研究室の紹介
54
最近の主な研究
Naoyasu Ubayashi and Tetsuo Tamai:
Aspect-Oriented Programming with Model Checking,
1st International Conference on Aspect-Oriented Software Development (AOSD 2002)
Kouhei Sakurai, Hidehiko Masuhara, Naoyasu Ubayashi, Saeko Matsuura, and Seiichi Komiya:
Association aspects,
3rd International Conference on Aspect-Oriented Software Development (AOSD 2004)
Tetsuo Tamai, Naoyasu Ubayashi, and Ryoichi Ichiyama:
An Adaptive Object Model with Dynamic Role Binding,
27th IEEE/ACM International Conference on Software Engineering (ICSE 2005)
Naoyasu Ubayashi, Tetsuo Tamai, Shinji Sano, Yusaku Maeno, Satoshi Murakami:
Model Compiler Construction Based on Aspect-Oriented Mechanisms,
4th ACM SIGPLAN International Conference on Generative Programming
and Component Engineering (GPCE 2005), to appear
Naoyasu Ubayashi, Genki Moriyama, Hidehiko Masuhara, and Tetsuo Tamai:
A Parameterized Interpreter for Modeling Different AOP Mechanisms,
20th IEEE/ACM International Conference on Automated Software Engineering (ASE 2005),
to appear
55
現在進行形の研究




Weaving by Contract
Contract Generator for AO Refactorings
Class-based AOP Language
Reflective AOP Language
56
おわり
57