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