九州工業大学 情報工学部 知能情報工学科 鵜林尚靖 ２００４年１０月１５日

Presentation on theme: "九州工業大学 情報工学部 知能情報工学科 鵜林尚靖 ２００４年１０月１５日"— Presentation transcript:

1 九州工業大学 情報工学部 知能情報工学科 鵜林尚靖 ２００４年１０月１５日
組込みソフトウェアシンポジウム ESS 2004 アスペクト指向 ソフトウェア開発 九州工業大学 情報工学部 知能情報工学科 鵜林尚靖 ２００４年１０月１５日

2 内容 アスペクト指向が生まれた背景 アスペクト指向の考え方 様々なアスペクト指向メカニズム アスペクト指向の適用事例 アスペクト指向とＭＤＡ
アスペクト指向の今後

3 １．アスペクト指向が 　　生まれた背景

4 ソフトウェア開発手法の変遷 構造化手法 オブジェクト指向手法 アスペクト指向 60 年代 70 年代 80 年代 90 年代 2000 年代
構造化プログラミング 構造化分析 構造化設計 ＯＯＰ ＯＯＡ ＯＯＤ パターン フレームワーク コンポーネント ＥＡ プロダクトライン アジャイル, ＸＰ ＭＤＡ アスペクト指向

5 アスペクト指向とは何？ 一言でいうと 「モジュール化メカニズム」の一つ

6 モジュール化メカニズムの歴史 構造化 機能中心のため、データの変更に対して脆い データ抽象 データとそれに関連する操作をまとめてしまおう
抽象データ型 データとそれに関連する操作をまとめて型にしよう オブジェクト指向 継承機構も入れて、再利用性を高めよう

7 モジュール化メカニズムの発展 ～ 構造化 から オブジェクト指向 へ ～
モジュール化メカニズムの発展 　～ 構造化 から オブジェクト指向 へ ～ 操 作 操 作 オブジェクト 操 作 操 作 データ データ 操 作 データ データ データ 操 作 オブジェクト 操 作 操 作 操 作 オブジェクト 操 作 データ 操 作 データ データ オブジェクト指向 構造化 変更の影響範囲が オブジェクト内に カプセル化される データを変更すると周りの 操作に影響が波及する

8 モジュール化の理想像 問題領域の構造がソフトウェア構造に対応する ソフトウェア構造を構成する関心事を自然にモジュール化できる
要求分析 設計 実装 問題 領域 分析時の 関心事 設計時の 関心事 モジュールの 構成 問題領域の構造がソフトウェア構造に対応する ソフトウェア構造を構成する関心事を自然にモジュール化できる 　（関心事の分離 “Separation of Concerns” Edsger Wybe Dijkstra ）

9 良いモジュール化 １箇所にモジュール化されている org.apache.tomcat におけるXML parsing
機能要件を きれいにモジュール化 org.apache.tomcat におけるXML parsing 赤い線はXML parsingを行うコード行を示す １箇所にモジュール化されている AspectJ.

10 （Crosscutting Concerns）
しかし、ログ処理の場合は．．． 複数のオブジェクトにまたがる （Crosscutting Concerns） org.apache.tomcat におけるログ処理 赤い線はログ処理を行うコード行を示す １箇所ではない しかも、数多くの場所に分散している（tangling and scattering） AspectJ.

11 現実のモジュール化は．．． ソフトウェア構造 要求分析 設計 実装 問題 領域 （問題意識）
分析時の 関心事 設計時の 関心事 モジュールの 構成 （問題意識） 　上流の関心事が、下流に行くにしたがって構造的に分散してしまう 　（オブジェクト指向でも解決できない問題がある）

12 オブジェクト指向の限界 オブジェクト指向プログラミングは、機能要件のカプセル化には優れているが、横断的関心事（ Crosscutting Concerns ）の表現には必ずしも向いていない。 ＜横断的関心事の例＞ ・エラーチェック戦略 ・セキュリティ ・デザインパターン ・同期制御 ・資源共有 ・分散にかかわる関心事 ・性能最適化 性能最適化のためのコードを追加しようとすると、コードが複数のオブジェクトに分散してしまい、見通しの悪いプログラムになってしまう。「分かりやすく性能も良い」プログラムを作るのが難しい。 ＡＯＰ

13 組込みソフトウェア設計の難しさ 現在のソフトウェア技術では、機能的合成可能性が物理的合成可能性を意味するものではない。
実際、物理特性は合成可能ではない。むしろ、開発プロセスにおいて、横断的制約（cross-cutting constraints）として現れる。 このような横断的制約は設計をやり難くしてしまう可能性がある。 Janos Sztipanovits and Gabor Karsai: Generative Programming for Embedded Systems, GPCE2002, LNCS2487, pp , 2002

14 組込みソフトウェアの構造 最適化 メモリ容量 ＨＷ特性 応答性 きれいなプログラムを作成したい！
でも、ＨＷ特性、性能向上、例外のためのコードを追加すると どんどんプログラムが汚くなってしまう。。。 アスペクト指向

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 ２．アスペクト指向の 　　考え方 ～ ＡｓｐｅｃｔＪ を中心に ～

17 ＡｓｐｅｃｔＪ 最も代表的なＡＯＰ言語 ＡＯＰの基本的な考え方をＪａｖａ上に実現した言語
元々はＰＡＲＣで開発。現在はＥｃｌｉｐｓｅプロジェクトに移管。 AspectJ:

18 開発環境： AJDT Eclipse Tools Projectの１つ。
AJDT（AspectJ Development Tools）は、AspectJを用いたアスペクト指向開発を支援するためのツールをEclipse上に提供する。 AJDTを用いることにより、JDT（Java Development Tools）上でAspectJの機能が使用できるようになる。 AJDT:

19 ＡｓｐｅｃｔＪによるプログラミング方式 同期制御、資源共有、性能最適化など複数のオブジェクトにまたがる関心事をアスペクトというモジュール概念を用いて記述 オブジェクト （通常の機能） weaver プログラム アスペクト （オブジェクトに またがる関心事） ・複数のオブジェクトにまたがる関心事を見通しよく記述できる！ ・「分かりやすく性能も良い」プログラムが作れる！

20 ＡｓｐｅｃｔＪの主要概念 振る舞いへの作用 ジョインポイント（ｊｏｉｎ ｐｏｉｎｔ） ポイントカット（ｐｏｉｎｔｃｕｔ）
アドバイス（ａｄｖｉｃｅ） 構造への作用 インタータイプ定義 ｄｅｃｌａｒｅ句による宣言

21 簡単なＡｓｐｅｃｔＪプログラム HelloWorld.java Trace.java
アスペクト インタータイプ 定義 HelloWorld.java Trace.java public class HelloWorld { public static void main ( String [], args) { HelloWorld app = new HelloWorld (); app.hello(); } void hello() { System.out.println(“こんにちは！”); 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 + “呼び出し後”); ポイントカット アドバイス 「AspectJによるアスペクト指向プログラミング入門」 長瀬、天野、鷲崎、立堀(著)　より

22 実行点の中からトレース処理に関わる部分を抽出
ＪＰＭ（Join Point Model） 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 + “呼び出し後”); メソッド呼び出し、 変数参照／更新など の実行点を捕まえる weaving トレースコードの埋め込み （advice） プログラム上の様々な実行点 （join point） 実行点の取り出し （pointcut） 実行点の中からトレース処理に関わる部分を抽出

23 実用的な例： 簡易図形エディタ * operations that move elements Display Figure
実用的な例：　簡易図形エディタ Display * Figure makePoint(..) makeLine(..) FigureElement moveBy(int, int) operations that move elements Point getX() getY() setX(int) setY(int) moveBy(int, int) Line getP1() getP2() setP1(Point) setP2(Point) moveBy(int, int) 2 AspectJ.

24 通常の保守、改良 class Line { class Point { class Line { class Point { 変更が複数の
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; 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.

25 AspectJによる保守、改良 （set* のような記述も可能） 変更が１つのアスペクトに局所化される！ 予期しないソフトウェア発展に有効！
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; 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); } （set* のような記述も可能） 変更が１つのアスペクトに局所化される！ 予期しないソフトウェア発展に有効！ 　（unanticipated software evolution） AspectJ.

26 クラスを横断するアスペクト * Display Figure makePoint(..) makeLine(..)
FigureElement moveBy(int, int) Point getX() getY() setX(int) setY(int) moveBy(int, int) Line getP1() getP2() setP1(Point) setP2(Point) moveBy(int, int) 2 DisplayUpdating AspectJ.

27 ３．様々なアスペクト指向 　　メカニズム

28 様々なアスペクト指向メカニズム アスペクト指向 ＝ ＡｓｐｅｃｔＪ ではない！ たとえば、
PA （ＡｓｐｅｃｔＪ流 pointcut ＆ advice） TRAV （DemeterＪ流 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 ＡＳＢ ＡＳＢ（Aspect Sand Box） ４つのアスペクト指向メカニズムをモデル化 ４つのインタプリタを提供
ＡＳＢ（Aspect Sand Box） ４つのアスペクト指向メカニズムをモデル化 ４つのインタプリタを提供 ここでは、ＡＳＢのサンプルプログラム（※）を提示しながら ４つのアスペクト指向メカニズムを紹介する ※ 元々のプログラムはＳｃｈｅｍｅライクな言語であるが、ここでは、 　　分かりやすさを考慮してＪａｖａライクな 言語で説明する ※ 以下の論文からの引用 　　　Hidehiko Masuhara and Gregor Kiczales: 　　　Modeling Crosscutting in Aspect-Oriented Mechanisms, ECOOP 2003

30 基盤となる例題プログラム 簡易図形エディタ

31 ＰＡ （ＡｓｐｅｃｔＪ流 Ｐｏｉｎｔｃｕｔ ＆ Ａｄｖｉｃｅ）
ＰＡ　（ＡｓｐｅｃｔＪ流 Ｐｏｉｎｔｃｕｔ ＆ Ａｄｖｉｃｅ） ＡＳＢサンプルプログラム 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);

32 ＴＲＡＶ （ＤｅｍｅｔｅｒＪ流） ｔｒａｖｅｒｓｅ 仕様に則り、 オブジェクト木を訪問し、 Ｖｉｓｉｔｏｒ メソッドを実行
ＴＲＡＶ　（ＤｅｍｅｔｅｒＪ流） Northeastern大学で開発されたツール／ライブラリで、Javaに よるAdaptive Programmingを支援する ＡＳＢサンプルプログラム Visitor counter = new CountElementsVisitor(); traverse("from Figure to FigureElement", fig, counter); ［Ｖｉｓｉｔｏｒ］ Ｃｏｕｎｔｅｒ fig ｔｒａｖｅｒｓｅ 仕様に則り、 オブジェクト木を訪問し、 Ｖｉｓｉｔｏｒ メソッドを実行 Ｐｏｉｎｔ

33 ＣＯＭＰＯＳＩＴＯＲ （ＨｙｐｅｒＪ流） Ｈｙｐｅｒ／Ｊとは
ＣＯＭＰＯＳＩＴＯＲ　（ＨｙｐｅｒＪ流） Ｈｙｐｅｒ／Ｊとは IBM T.J Watson Research Centerで開発されたJavaベースの言語。 SOP（Subject-oriented programming）およびその後継の MDSOC（Multi-Dimensional Separation Of Concerns）という考え方に基づいている。 すべてを関心事（クラスで表現）としてプログラミングする方式。AspectJのようにアスペクトとクラスといった区分がない。 ソフトウェアのevolutionへの柔軟な対応を重視。

34 つづき ＡＳＢサンプルプログラム class Observable { Display display; void moved() {
display.update(this); } ; relationship between Point/Line and Observable match Point.setX with Observable.moved match Point.setY with Observable.moved match Line.setP1 with Observable.moved match Line.setP2 with Observable.moved

35 ＯＣ （ＡｓｐｅｃｔＪ流 Ｏｐｅｎ Ｃｌａｓｓ）
ＯＣ　（ＡｓｐｅｃｔＪ流 Ｏｐｅｎ Ｃｌａｓｓ） ＡｓｐｅｃｔＪ の インタータイプ定義 ＡＳＢサンプルプログラム class DisplayMethods { void Point.draw() { Graphics.drawOval(...); } void Line.draw() { Graphics.drawLine(...); } }

36 疑問．．． ＰＡ ＴＲＡＶ ＣＯＭＰＯＳＩＴＯＲ ＯＣ 同じアスペクト指向と言っても 全然違うではないか？ これらに共通するものは
あるのか？

37 Ｔｈｒｅｅ-Ｐａｒｔ Ｍｏｄｅｌ EFFB - means of effecting A - program B - program
EFFA IDA- means of identifying IDB META - weaving parameter X - computation or program XJP- join point Hidehiko Masuhara and Gregor Kiczales: 　　　Modeling Crosscutting in Aspect-Oriented Mechanisms, ECOOP 2003

38 Ｔｈｒｅｅ-Ｐａｒｔ Ｍｏｄｅｌ （つづき）
c, m, f: class, method, field の略

39 ４．アスペクト指向の 　　適用事例

40 アスペクト指向の適用事例 デバッグやロギングについてはメリットは分かるが、 それ以外の応用はどうなのか？ デザインパターンへの応用
　　　　　　　　　　　　　　　　　　［Hannemann他０２］ データベースへの応用 ［Rashid他０３］ ＦｒｅｅＢＳＤカーネルの最適化コードをＡＯＰで分離 　　　　　　　　　　　　　　　　　　［Ｃｏａｄｙ他０２，０３］ ＷｅｂＳｐｈｅｒｅのコードをＡＯＰで分離 　　　　　　　　　　　　　　　　　　［Ｃｏｙｌｅｒ０４］

41 事例１： デザインパターンへの応用 Jan Hannemann and Gregor Kiczales:
事例１：　デザインパターンへの応用 Jan Hannemann and Gregor Kiczales: Design Pattern Implementation in Java and AspectJ, OOPSLA2002 (2002) ＡｓｐｅｃｔＪを持いて、ＧｏＦデザインパターンの記述を改良

42 Ｏｂｓｅｒｖｅｒ パターン ＊ １ Subject Observer o Update() Attach(Observer)
Detach(Observer) Notify() for(;全てのObserver;) {o->Update();} １ １ ConcreteObserver ConcreteSubject subject observerState:State* subjectState:State* GetState() Update() observerState = Subject->GetState(); return subjectState;

43 Ｏｂｓｅｒｖｅｒ パターンの適用例 Jan Hannemann and Gregor Kiczales:
Design Pattern Implementation in Java and AspectJ, OOPSLA2002 (2002) より引用

44 Ｏｂｓｅｒｖｅｒパターンの汎用アスペクト
抽象ポイントカット 抽象アスペクト インタフェース アドバイス 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 事例２： データベースへの応用 永続性（Persistence）は横断的関心事の１つ Aspect-Oriented Database
事例２：　データベースへの応用 永続性（Persistence）は横断的関心事の１つ アスペクト指向により、永続性をモジュール化したい 永続アスペクトを再利用したい 永続性のことを気にせずにアプリケーションを開発したい Aspect-Oriented Database Awais Rashid and Ruzanna Chitchyan: "Persistence as an aspect", AOSD2003

47 アスペクト化された永続性（１） 例： 文献管理アプリケーション データアクセスに関わる join pointを抽出し、そこに
例：　文献管理アプリケーション データアクセスに関わる join pointを抽出し、そこに DB処理のためのコードを weavingする

48 アスペクト化された永続性（２） AspectJ による記述 Connection Storage & Update Retrieval
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 } 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 Connection Storage & Update Retrieval

49 アスペクトベースの永続化フレームワーク Weaving 永続化フレームワーク アプリケーション
永続性の部分をアスペクト化することにより、アプリケーションは永続性のことを気にせずに開発できる（一部例外あり）。

50 ５．アスペクト指向とＭＤＡ

51 MDA（Model-Driven Architecture）とは
実装技術（Ｊ２ＥＥや．ＮＥＴなど）から分析/設計を独立させ、設計情報が実装技術に左右されないようにする技術 分析/設計部分はプラットフォームに 依存しない為、再利用可能 UML２の目玉

52 ＭＤＡと従来プロセスの違い 従来の開発 ＭＤＡによる開発 設計フェーズが 大きく変化！ CIM 分析 PIM 設計 PSM コーディング
モデルコンパイラ による自動変換 PSM コーディング ソース・コード CIM: Computation Independent Model PIM: Platform Independent Model PSM: Platform Specific Model

53 モデル変換の例（Ｓｔｒｕｔｓの場合） ステップ１： 複数ＰＩＭの合成 ①PIMクラスのマージ ステップ２： アクションフォーム
ステップ１：　複数ＰＩＭの合成 ①PIMクラスのマージ ステップ２：　アクションフォーム 　　　　　　　　Ｂｅａｎへの変換 ②Bean規約名に変更 ③ActionFormを継承 ④setter/getterを追加 ステップ３：　アクションクラス 　　　　　　　　の新規作成 ⑤アクションクラスを生成 ⑥Actionを継承 ⑦executeメソッドを追加 ⑧メソッド本体を追加 ＰＩＭ ＰＳＭ

54 ＭＤＡのメリット コード中心開発からモデル中心開発へパラダイムシフト：　開発者は特定のプラットフォームやプログラミング技術にとらわれることなく、PIMの開発に全力を注ぐことができる。 新しいタイプのコンポーネント化：　PIMモデル部品とモデル変換規則をライブラリ化することにより、様々な機能やプラットフォームに対応したプロダクト群を生成することが可能になり、プロダクトライン型開発の実現につながる。

55 ＭＤＡ実現のための鍵 厳密なモデル表記 （ＭＯＦ、ＯＣＬ） 厳密なモデル変換定義 （ＱＶＴ） QVTの例
厳密なモデル表記　（ＭＯＦ、ＯＣＬ） 厳密なモデル変換定義　（ＱＶＴ） 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

56 ＭＤＡとアスペクト指向 ＰＩＭモデル（ＵＭＬ） アプリケーション 実装環境対応コード ｗｅａｖｉｎｇ アプリケーション 実装環境対応コード
マッピングルール（ＭＯＦ ＱＶＴ） アスペクト記述言語 「AspectJによるアスペクト指向プログラミング入門」 長瀬、天野、鷲崎、立堀(著)　より

57 当研究室の研究紹介： ＡｓｐｅｃｔＭモデルコンパイラ
アスペクト (モデル変換モジュール としてのアスペクト) アスペクト図 ＸＭＬ アスペクトを追加することにより様々な変換を可能にする weave UMLモデル (クラス図) UMLモデル (クラス図) ＸＭＬ ＸＭＬ モデルコンパイラ アスペクト図 (システム構成モジュール としてのアスペクト) アスペクト指向メカニズムにより モデルコンパイラを実現！ ＸＭＬ

58 ＡｓｐｅｃｔＭにおけるＪＰＭ JPMでモデル変換を記述 Join Point クラス名 Advice クラス名 Point Cut クラス図
属性 ・・・ 属性① 属性② 操作 ・・・ 操作 ・・・ Point Cut クラス図

59 モデル変換のためのＪＰＭ ①PIMクラスのマージ ＣＭ ②Bean規約名に変更 ＲＮ ③ActionFormを継承 ＲＬ
　　ＣＭ ②Bean規約名に変更 　　ＲＮ ③ActionFormを継承 　　ＲＬ ④setter/getterを追加 　　ＯＣ ⑤アクションクラスを生成 　　ＮＥ ⑥Actionを継承 ⑦executeメソッドを追加 ⑧メソッド本体を追加 　　ＰＡ モデル変換機能 PA CM NE OC RN RL 操作本体の変更 ○ クラスのマージ クラスの追加/削除 操作の追加/削除 属性の追加/削除 クラス名の変更 操作名の変更 属性名の変更 継承の追加/削除 集約の追加/削除 関連の追加/削除 PA（pointcut & advice），CM（composition），NE（new element），OC（open class），RN（rename），RL（relation）

60 merge-message-classes
ＡｓｐｅｃｔＭの記述例 MessageクラスとMessageProfileクラスを マージしてPostMessageクラスに変換 << 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>

61 ６．アスペクト指向の今後

62 アスペクト指向の今後 歴史は繰り返す．．． 現在、プログラミング周りで研究が活発（８０年代のＯＯＰ研究を彷彿させる）
今後は、適用事例の拡大、開発方法論の整備、アスペクトコンポーネント・フレームワークの整備に向かって行くと思われる（９０年代のＯＯソフトウェアエンジアリングの発展に類似） 歴史は繰り返す．．．

63 AOSD ソフト開発工程全体への波及 AOP（Aspect-Oriented Programming） から
AOSD（Aspect-Oriented Software Development） へ AO: Aspect-Oriented 要求分析 設計 実装 Early Aspect AO Design Pattern AO Language AO Modeling AO Framework AO Component Aspect Mining AO Database

64 上流段階のアスペクト研究例 Ｓｔｅｉｎ他［ＡＯＳＤ２００２］ Ｇｒａｙ他［ＧＰＣＥ２００３］ Ｓｉｌｌｉｔｏ他［ＥＣＯＯＰ２００４］
アスペクトをＵＭＬ図として表現する方法を提案 モデリング段階のアスペクトはＡｓｐｅｃｔＪなどのＡＯＰ言語に変換するもので、この方法ではＭＤＡは実現できない ＡｓｐｅｃｔＭのアスペクトはＵＭＬ図自身を操作するもの Ｇｒａｙ他［ＧＰＣＥ２００３］ ＡＯＤＭ（Aspect-Oriented Domain Modeling）を提案 属性や関連などのモデル要素を追加する機能をもつ ＭＤＡなどの一般的なモデル変換を対象にしたものではない Ｓｉｌｌｉｔｏ他［ＥＣＯＯＰ２００４］ ユースケースレベルのポイントカットを提案 上流のモデリング段階においてもＪＰＭの考え方が有効であることを示した

65 アスペクト指向言語の変遷 ドメイン専用ＡＯＰ言語を個々に開発するアプローチ （１９９７年頃まで） Weaverを開発するのが大変
汎用ＡＯＰ言語（AspectJ等： 「Pointcut＋Advice」メカニズム）のアプローチ （現在） 適用範囲が限定される 拡張可能ドメイン専用ＡＯＰ言語の（Xaspect等）アプローチ （これから）

66 アスペクト指向に関する情報源 ポータルサイト http://aosd.net 国際会議
Aspect-Oriented Software Development (AOSD) OOPSLA, ECOOP, GPCE, ICSE, FSE, ICFP など

67 おわり