Upload
zaina
View
55
Download
0
Embed Size (px)
DESCRIPTION
組込みソフトウェアシンポジウム ESS 2004. アスペクト指向 ソフトウェア開発. 九州工業大学 情報工学部 知能情報工学科 鵜林尚靖 2004年10月15日. 内容. アスペクト指向が生まれた背景 アスペクト指向の考え方 様々なアスペクト指向メカニズム アスペクト指向の適用事例 アスペクト指向とMDA アスペクト指向の今後. 1.アスペクト指向が 生まれた背景. ソフトウェア開発手法の変遷. 60. 70. 80. 90. 2000. 年代. 年代. 年代. 年代. 年代. 構造化手法. オブジェクト指向手法. - PowerPoint PPT Presentation
Citation preview
1
アスペクト指向ソフトウェア開発
九州工業大学情報工学部 知能情報工学科鵜林尚靖2004年10月15日
組込みソフトウェアシンポジウム ESS 2004
2
内容
アスペクト指向が生まれた背景 アスペクト指向の考え方 様々なアスペクト指向メカニズム アスペクト指向の適用事例 アスペクト指向とMDA アスペクト指向の今後
3
1.アスペクト指向が 生まれた背景
4
ソフトウェア開発手法の変遷60年代 70年代 80年代 90年代 2000年代
構造化手法
オブジェクト指向手法
OOAOODパターンフレームワークコンポーネント アスペクト指向
構造化プログラミング構造化分析構造化設計 OOP EA
プロダクトラインアジャイル , XPMDA
5
アスペクト指向とは何?
一言でいうと
「モジュール化メカニズム」の一つ
6
モジュール化メカニズムの歴史
構造化機能中心のため、データの変更に対して脆い
データ抽象データとそれに関連する操作をまとめてしまおう
抽象データ型データとそれに関連する操作をまとめて型にしよう
オブジェクト指向継承機構も入れて、再利用性を高めよう
7
モジュール化メカニズムの発展 ~ 構造化 から オブジェクト指向 へ ~
構造化
操 作
データ
データ
データ
データ
操 作
操 作 操 作
操 作
オブジェクト指向
操 作データ
オブジェクト操 作
データ
オブジェクト
操 作
操 作
操 作
データ
オブジェクト
操 作
データ
データを変更すると周りの操作に影響が波及する
変更の影響範囲がオブジェクト内にカプセル化される
8
モジュール化の理想像
問題領域
要求分析要求分析 設計設計 実装実装
ソフトウェア構造
問題領域の構造がソフトウェア構造に対応するソフトウェア構造を構成する関心事を自然にモジュール化できる (関心事の分離 “ Separation of Concerns” Edsger Wybe Dijkstra )
分析時の関心事
設計時の関心事
モジュールの構成
9
良いモジュール化
org.apache.tomcat における XML parsing– 赤い線は XML parsing を行うコード行を示す– 1箇所にモジュール化されている
AspectJ. http://eclipse.org/aspectj/ より抜粋
機能要件をきれいにモジュール化
10
しかし、ログ処理の場合は...
org.apache.tomcat におけるログ処理– 赤い線はログ処理を行うコード行を示す – 1箇所ではない– しかも、数多くの場所に分散している( tangling and
scattering )
複数のオブジェクトにまたがる( Crosscutting Concerns )
AspectJ. http://eclipse.org/aspectj/ より抜粋
11
現実のモジュール化は...
(問題意識) 上流の関心事が、下流に行くにしたがって構造的に分散してしまう (オブジェクト指向でも解決できない問題がある)
問題領域
要求分析要求分析 設計設計 実装実装
ソフトウェア構造
分析時の関心事
設計時の関心事
モジュールの構成
12
オブジェクト指向の限界
<横断的関心事の例>
・エラーチェック戦略・セキュリティ・デザインパターン・同期制御・資源共有・分散にかかわる関心事・性能最適化
オブジェクト指向プログラミングは、機能要件のカプセル化には優れているが、横断的関心事( Crosscutting Concerns )の表現には必ずしも向いていない。
オブジェクト指向プログラミングは、機能要件のカプセル化には優れているが、横断的関心事( Crosscutting Concerns )の表現には必ずしも向いていない。
性能最適化のためのコードを追加しようとすると、コードが複数のオブジェクトに分散してしまい、見通しの悪いプログラムになってしまう。「分かりやすく性能も良い」プログラムを作るのが難しい。
AOP
13
組込みソフトウェア設計の難しさ
現在のソフトウェア技術では、機能的合成可能性が物理的合成可能性を意味するものではない。
実際、物理特性は合成可能ではない。むしろ、開発プロセスにおいて、横断的制約( cross-cutting constraints )として現れる。
このような横断的制約は設計をやり難くしてしまう可能性がある。
Janos Sztipanovits and Gabor Karsai:Generative Programming for Embedded Systems,GPCE2002, LNCS2487, pp.32--49, 2002
14
組込みソフトウェアの構造
HW特性
応答性
最適化メモリ容量
きれいなプログラムを作成したい!でも、HW特性、性能向上、例外のためのコードを追加するとどんどんプログラムが汚くなってしまう。。。
アスペクト指向
15
アスペクト指向を実現する言語処理系、システム
AspectJ ( Gregor Kiczales, et.al. ) Hyper/J ( Harold Ossher, et.al. ) DemeterJ ( Karl J. Lieberherr, et.al. ) Composition filters ( Mehmet Aksit,
et.al. ) JBoss-AOP AspectWerkz など多数
16
2.アスペクト指向の 考え方
~ AspectJ を中心に ~
17
AspectJ
最も代表的なAOP言語 AOPの基本的な考え方をJava上に実
現した言語 元々はPARCで開発。現在はEclipseプロジェクトに移管。
AspectJ: http://eclipse.org/aspectj/
18
開発環境: AJDT
Eclipse Tools Project の1つ。
AJDT ( AspectJ Development Tools )は、 AspectJ を用いたアスペクト指向開発を支援するためのツールを Eclipse 上に提供する。
AJDT を用いることにより、 JDT ( Java Development Tools )上で AspectJ の機能が使用できるようになる。
AJDT: http://eclipse.org/ajdt/
19
AspectJによるプログラミング方式同期制御、資源共有、性能最適化など複数のオブジェクトにまたがる関心事をアスペクトというモジュール概念を用いて記述
weaverweaver
オブジェクト(通常の機能)
オブジェクト(通常の機能)
アスペクト(オブジェクトにまたがる関心事)
アスペクト(オブジェクトにまたがる関心事)
プログラムプログラム
・複数のオブジェクトにまたがる関心事を見通しよく記述できる!・「分かりやすく性能も良い」プログラムが作れる!
20
AspectJの主要概念
振る舞いへの作用
ジョインポイント(join point)ポイントカット(pointcut)アドバイス(advice)
構造への作用
インタータイプ定義declare句による宣言
21
簡単なAspectJプログラム
「 AspectJ によるアスペクト指向プログラミング入門」 長瀬、天野、鷲崎、立堀 ( 著 ) より
public class HelloWorld { public static void main ( String [], args) { HelloWorld app = new HelloWorld (); app.hello(); }
void hello() { System.out.println(“こんにちは!” ); }}
HelloWorld.java
public aspect Trace { private String HelloWorld.mes = “ トレース” ;
public pointcut atHello() : call (void HelloWorld.hello());
before(HelloWorld h) : atHello() && target(h) { System.out.println(h.mes + “呼び出し前” ); }
after(HelloWorld h) : atHello() && target(h) { System.out.println(h.mes + “呼び出し後” ); }}
Trace.java
アスペクト
ポイントカット
アドバイス
インタータイプ定義
22
JPM( Join Point Model )
プログラム上の様々な実行
点
( join point )
実行点の取り出し
( pointcut )
実行点の中からトレース処理に関わる部分を抽
出
トレースコードの埋め込み
( advice )
メソッド呼び出し、変数参照/更新などの実行点を捕まえる
weaving
public aspect Trace { private String HelloWorld.mes = “ トレース” ;
public pointcut atHello() : call (void HelloWorld.hello());
before(HelloWorld h) : atHello() && target(h) { System.out.println(h.mes + “呼び出し前” ); }
after(HelloWorld h) : atHello() && target(h) { System.out.println(h.mes + “呼び出し後” ); }}
23
実用的な例: 簡易図形エディタ
operations that move elements
Display
*
2Point
getX()getY()setX(int)setY(int)moveBy(int, int)
Line
getP1()getP2()setP1(Point)setP2(Point)moveBy(int, int)
Figure
makePoint(..)makeLine(..)
FigureElement
moveBy(int, int)
AspectJ. http://eclipse.org/aspectj/ より抜粋
24
通常の保守、改良class Line { private Point p1, p2;
Point getP1() { return p1; } Point getP2() { return p2; }
void setP1(Point p1) { this.p1 = p1;
} void setP2(Point p2) { this.p2 = p2;
}}
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;
}}
class Line { private Point p1, p2;
Point getP1() { return p1; } Point getP2() { return p2; }
void setP1(Point p1) { this.p1 = p1; Display.update(this); } void setP2(Point p2) { this.p2 = p2; Display.update(this); }}
class Point {
private int x = 0, y = 0;
int getX() { return x; } int getY() { return y; }
void setX(int x) { this.x = x; Display.update(this); } void setY(int y) { this.y = y; Display.update(this); }}
変更が複数のクラスに散らばってしまう!
AspectJ. http://eclipse.org/aspectj/ より抜粋
25
aspect DisplayUpdating {
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)));
after(FigureElement fe) returning: move(fe) { Display.update(fe); }}
AspectJ による保守、改良
class Line { private Point p1, p2;
Point getP1() { return p1; } Point getP2() { return p2; }
void setP1(Point p1) { this.p1 = p1; } void setP2(Point p2) { this.p2 = p2; }}
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; }}
変更が1つのアスペクトに局所化される!予期しないソフトウェア発展に有効! ( unanticipated software evolution )
AspectJ. http://eclipse.org/aspectj/ より抜粋
( set* のような記述も可能)
26
DisplayUpdating
Display
*
2Point
getX()getY()setX(int)setY(int)moveBy(int, int)
Line
getP1()getP2()setP1(Point)setP2(Point)moveBy(int, int)
Figure
makePoint(..)makeLine(..)
FigureElement
moveBy(int, int)
クラスを横断するアスペクト
AspectJ. http://eclipse.org/aspectj/ より抜粋
27
3.様々なアスペクト指向 メカニズム
28
様々なアスペクト指向メカニズム
アスペクト指向 = AspectJ ではない!
たとえば、
PA (AspectJ流 pointcut & advice )TRAV ( DemeterJ流 traversal specifications)COMPOSITOR ( Hyper/J 流 class hierarchy composition )OC ( AspectJ 流 open classes )※用語は以下のものに準拠
Hidehiko Masuhara and Gregor Kiczales:Modeling Crosscutting in Aspect-Oriented Mechanisms, ECOOP 2003
29
ASB
ASB( Aspect Sand Box )
4つのアスペクト指向メカニズムをモデル化4つのインタプリタを提供
ここでは、ASBのサンプルプログラム(※)を提示しながら4つのアスペクト指向メカニズムを紹介する
※ 元々のプログラムはSchemeライクな言語であるが、ここでは、 分かりやすさを考慮してJavaライクな 言語で説明する※ 以下の論文からの引用 Hidehiko Masuhara and Gregor Kiczales: Modeling Crosscutting in Aspect-Oriented Mechanisms, ECOOP 2003
http://www.cs.ubc.ca/labs/spl/projects/asb.html
30
基盤となる例題プログラム
簡易図形エディタ
31
PA (AspectJ流 Pointcut & Advice)
after (FigureElement fe): ( call(void Point.setX(int)) || call(void Point.setY(int)) || call(void Line.setP1(Point)) || call(void Line.setP2(Point))) && target(fe){ fe.display.update(fe);
ASBサンプルプログラム
32
TRAV (DemeterJ流)
Visitor counter = new CountElementsVisitor();traverse("from Figure to FigureElement", fig, counter);
fig
Point
[Visitor]Counter
traverse 仕様に則り、オブジェクト木を訪問し、Visitor メソッドを実行
Northeastern 大学で開発されたツール/ライブラリで、 Javaによる Adaptive Programming を支援する
ASBサンプルプログラム
33
COMPOSITOR (HyperJ流)
IBM T.J Watson Research Center で開発された Javaベースの言語。
SOP ( Subject-oriented programming )およびその後継の MDSOC ( Multi-Dimensional Separation Of Concerns )という考え方に基づいている。
すべてを関心事(クラスで表現)としてプログラミングする方式。AspectJ のようにアスペクトとクラスといった区分がない。
ソフトウェアの evolutionへの柔軟な対応を重視。
Hyper/Jとは
34
つづき
ASBサンプルプログラム
class Observable { Display display; void moved() { display.update(this); }}
; relationship between Point/Line and Observablematch Point.setX with Observable.movedmatch Point.setY with Observable.movedmatch Line.setP1 with Observable.movedmatch Line.setP2 with Observable.moved
35
OC (AspectJ流 Open Class)
AspectJ の インタータイプ定義
class DisplayMethods { void Point.draw() { Graphics.drawOval(...); } void Line.draw() { Graphics.drawLine(...); }}
ASBサンプルプログラム
36
疑問...
PATRAVCOMPOSITOROC
同じアスペクト指向と言っても全然違うではないか?
これらに共通するものはあるのか?
37
Three - Part Model
A - program
B - program
X - computationor programXJP-
join point
IDA -
means of
identifying
IDBIDB
EFFA
EFFA
EFF B -
mea
ns o
f
effe
ctingEFF B -
mea
ns o
f
effe
cting
META -weaving
parameter
Hidehiko Masuhara and Gregor Kiczales: Modeling Crosscutting in Aspect-Oriented Mechanisms, ECOOP 2003
38
Three - Part Model (つづき)
c, m, f: class, method, field の略
39
4.アスペクト指向の 適用事例
40
アスペクト指向の適用事例
デバッグやロギングについてはメリットは分かるが、それ以外の応用はどうなのか?
デザインパターンへの応用 [ Hannemann他02]データベースへの応用
[ Rashid他03] FreeBSDカーネルの最適化コードをAOPで分離 [Coady他02,03]WebSphereのコードをAOPで分離 [Coyler04]
41
事例1: デザインパターンへの応用
Jan Hannemann and Gregor Kiczales:Design Pattern Implementation in Java and AspectJ, OOPSLA2002 (2002)
AspectJを持いて、GoFデザインパターンの記述を改良
42
Observer パターンSubject
Attach(Observer)Detach(Observer)Notify()
1 *Observer
Update()
ConcreteSubject
subjectState:State*
GetState()
1 1
subject
return subjectState;
ConcreteObserver
observerState:State*
Update()
observerState= Subject->GetState();
o
for(;全ての Observer;){o->Update();}
43
Observer パターンの適用例
Jan Hannemann and Gregor Kiczales:Design Pattern Implementation in Java and AspectJ, OOPSLA2002 (2002) より引用
44
Observerパターンの汎用アスペクト
Jan Hannemann and Gregor Kiczales:Design Pattern Implementation in Java and AspectJ, OOPSLA2002 (2002) より引用
抽象アスペクト
インタフェース
抽象ポイントカット
アドバイス
45
実際のプログラムへの適用
Jan Hannemann and Gregor Kiczales:Design Pattern Implementation in Java and AspectJ, OOPSLA2002 (2002) より引用
具象ポイントカット
46
事例2: データベースへの応用
永続性( Persistence )は横断的関心事の1つ
アスペクト指向により、永続性をモジュール化したい永続アスペクトを再利用したい永続性のことを気にせずにアプリケーションを開発したい
Aspect-Oriented Database
Awais Rashid and Ruzanna Chitchyan:"Persistence as an aspect", AOSD2003
47
アスペクト化された永続性(1)
J ournalvol umenumber
Seri essubj ectcontentsvol ume
Book
Publ i shernameemai l
Publ i sher Locati ontowncountry
1. . n
1
+I s_Located_at
+I s_for_publ i sher
1. . n
1
AutherEdi tor
fi rstNamesurnameemai laddress
Bi bl i ography I tem
ti t l epubl i cati onDateurl
1. . n
1
+Has_Publ i shed1. . n
+Publ i shed_By
1
1. . n
1. . n
+HasAuthored/ Edi ted
+Authored/Edi ted_By
1. . n
1. . n
Archi veI SBNpages
Art i cl estartPageendPage
ConferenceconferenceNamecontents
データアクセスに関わるjoin point を抽出し、そこにDB 処理のためのコードをweaving する
例: 文献管理アプリケーション
48
アスペクト化された永続性(2)
public class PersistentRoot { protected boolean isDeleted = false; public void delete() { this.isDeleted = true; } public boolean isDeleted() { return this.isDeleted; }}
public aspect ApplicationDatabaseAccess {
declare patents: (BibliographyItem || AuthorEditor || Publisher || PublisherLocation) extends PersistentRoot;
// other code}
public abstract aspect DatabaseAccess {
private static Connection dbConnection; private static String dbURL; abstract pointcut establishConnection(); abstract pointcut closeConnection(); public abstract String getDatabaseURL(); public abstract String getDriverName();
pointcut trapInstantiation() : call(PersistentRoot+.new(..)); pointcut trapUpdates(PersistentRoot obj) : !cflow(call(public static Vector SQLTranslation.getObjects(ResultSet, String))) && (this(obj) && execution(public void PersistentRoot+.set*(..)));
pointcut trapRetrievals() : call(Vector PersistentData.get*(..)); public static PersistentData getPersistentData() { … }
: :
// advice code}
AspectJ による記述
Connection
Storage & Update
Retrieval
49
アスペクトベースの永続化フレームワーク
永続性の部分をアスペクト化することにより、アプリケーションは永続性のことを気にせずに開発できる(一部例外あり)。
永続化フレームワークMetaData Access
<<aspect>>
Persi stent Data
Persi stent Data I mpl i mentat i on
Appl i cat i on speci fi c customi sat i on
Appl i cat i on Database Access
<<aspect>>Establ i sh Mappi ng
<<aspect>>
Lookup Tabl e
SQLTraj nsl at i on<<aspect>>
Data Access<<aspect>> <<use>>
<<use>><<use>>
<<use>>
J ournalvol umenumber
Seri essubj ectcontentsvol ume
Book
Publ i shernameemai l
Publ i sher Locati ontowncountry
1. . n
1
+I s_Located_at
+I s_for_publ i sher
1. . n
1
AutherEdi tor
fi rstNamesurnameemai laddress
Bi bl i ography I tem
ti t l epubl i cat i onDateurl
1. . n
1
+Has_Publ i shed1. . n
+Publ i shed_By
1
1. . n
1. . n
+HasAuthored/ Edi ted
+Authored/Edi ted_By
1. . n
1. . n
Archi veI SBNpages
Art i cl estartPageendPage
ConferenceconferenceNamecontents
アプリケーション
Weaving
50
5.アスペクト指向とMDA
51
MDA ( Model-Driven Architecture )とは
実装技術(J2EEや.NETなど)から分析 / 設計を独立させ、設計情報が実装技術に左右されないようにする技術
分析 /設計部分はプラットフォームに依存しない為、再利用可能
UML 2の目玉
52
MDAと従来プロセスの違い
分析
設計
コーディング
CIM
PIM
PSM
ソース・コード
CIM: Computation Independent ModelPIM: Platform Independent ModelPSM: Platform Specific Model
従来の開発 MDAによる開発
設計フェーズが大きく変化!
モデルコンパイラによる自動変換
53PIM PSM
ステップ1: 複数PIMの合成
ステップ1: 複数PIMの合成
ステップ2: アクションフォーム Beanへの変換
ステップ2: アクションフォーム Beanへの変換
ステップ3: アクションクラス の新規作成
ステップ3: アクションクラス の新規作成
モデル変換の例(Strutsの場合)
①PIM クラスのマージ
②Bean規約名に変更③ActionForm を継承④setter/getter を追加
⑤アクションクラスを生成⑥Action を継承⑦execute メソッドを追加⑧メソッド本体を追加
54
MDAのメリット
コード中心開発からモデル中心開発へパラダイムシフト: 開発者は特定のプラットフォームやプログラミング技術にとらわれることなく、 PIM の開発に全力を注ぐことができる。
新しいタイプのコンポーネント化: PIM モデル部品とモデル変換規則をライブラリ化することにより、様々な機能やプラットフォームに対応したプロダクト群を生成することが可能になり、プロダクトライン型開発の実現につながる。
55
MDA実現のための鍵
厳密なモデル表記 (MOF、OCL) 厳密なモデル変換定義 (QVT)
MOF: Meta Object FacilityOCL: Object Constraint LanguageQVT: Queries, Views, and Transformations
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)) ] }}
QVT の例
56
MDAとアスペクト指向
「 AspectJ によるアスペクト指向プログラミング入門」 長瀬、天野、鷲崎、立堀 ( 著 ) より
PIMモデル(UML)
マッピングルール(MOF QVT)
アプリケーション
実装環境対応コード
アプリケーション
実装環境対応コード
アスペクト記述言語
weaving
57
当研究室の研究紹介:AspectMモデルコンパイラ
アスペクト( モデル変換モジュールとしてのアスペクト )
アスペクト( モデル変換モジュールとしてのアスペクト )
アスペクト( モデル変換モジュールとしてのアスペクト )
アスペクト( モデル変換モジュールとしてのアスペクト )
アスペクト図( モデル変換モジュールとしてのアスペクト )
アスペクト図( モデル変換モジュールとしてのアスペクト )
UML モデル( クラス図 )
UML モデル( クラス図 )
UML モデル( クラス図 )
UML モデル( クラス図 )weaveweave
アスペクトを追加することにより様々な変換を可能にする
アスペクト図( システム構成モジュール
としてのアスペクト )
アスペクト図( システム構成モジュール
としてのアスペクト )
モデルコンパイラモデルコンパイラXML
XML
XML
XML
アスペクト指向メカニズムによりモデルコンパイラを実現!
58
AspectMにおけるJPM
JPM でモデル変換を記述
クラス図
クラス名属性
・・・
操作・・・
Join PointJoin Point
Point CutPoint Cut
クラス名属性①属性②
操作・・・
AdviceAdvice
59
モデル変換のためのJPM
モデル変換機能 PA CM NE OC RN RL
操作本体の変更 ○
クラスのマージ ○
クラスの追加 /削除 ○
操作の追加 /削除 ○
属性の追加 /削除 ○
クラス名の変更 ○
操作名の変更 ○
属性名の変更 ○
継承の追加 /削除 ○
集約の追加 /削除 ○
関連の追加 /削除 ○
①PIM クラスのマージ CM②Bean規約名に変更 RN③ActionForm を継承 RL④setter/getter を追加 OC⑤アクションクラスを生成 NE⑥Action を継承 RL⑦execute メソッドを追加 OC⑧メソッド本体を追加 PA
PA ( pointcut & advice ), CM ( composition ), NE ( new element ), OC ( open class ), RN ( rename ),RL ( relation )
60
AspectMの記述例
<< CM >>merge-message-classes
message-classes : class { Message || MessageProfile }
merge-message-classes [message-classes] : merge-by-name { PostMessage }
aspect
<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>
Message クラスと MessageProfile クラスをマージして PostMessage クラスに変換
61
6.アスペクト指向の今後
62
アスペクト指向の今後
現在、プログラミング周りで研究が活発(80年代のOOP研究を彷彿させる)
今後は、適用事例の拡大、開発方法論の整備、アスペクトコンポーネント・フレームワークの整備に向かって行くと思われる(90年代のOOソフトウェアエンジアリングの発展に類似)
歴史は繰り返す...
63
AOSD ソフト開発工程全体への波及
AOP ( Aspect-Oriented Programming )から
AOSD ( Aspect-Oriented Software Development )へ
要求分析要求分析 設計設計 実装実装
Early Aspect AODesign Pattern
AO: Aspect-Oriented
AOFramework
AspectMining
AOLanguage
AOComponent
AOModeling
AODatabase
64
上流段階のアスペクト研究例Stein他[AOSD2002]
アスペクトをUML図として表現する方法を提案モデリング段階のアスペクトはAspectJなどのAO
P言語に変換するもので、この方法ではMDAは実現できない
AspectMのアスペクトはUML図自身を操作するものGray他[GPCE2003]
AODM( Aspect-Oriented Domain Modeling )を提案属性や関連などのモデル要素を追加する機能をもつMDAなどの一般的なモデル変換を対象にしたものではな
いSillito他[ECOOP2004]
ユースケースレベルのポイントカットを提案上流のモデリング段階においてもJPMの考え方が有効で
あることを示した
65
アスペクト指向言語の変遷
ドメイン専用AOP言語を個々に開発するアプローチ(1997年頃まで)
Weaver を開発するのが大変
汎用AOP言語( AspectJ 等: 「 Pointcut + Advice 」メカニズム)のアプローチ(現在)
拡張可能ドメイン専用AOP言語の( Xaspect 等)アプローチ(これから)
適用範囲が限定される
66
アスペクト指向に関する情報源
国際会議
Aspect-Oriented Software Development (AOSD)OOPSLA, ECOOP, GPCE, ICSE, FSE, ICFP など
ポータルサイト
http://aosd.net
67
おわり