ソフトウェア開発手法の最前線 ~ アスペクト指向、MDA、MIC ~
DESCRIPTION
東芝情報システム(株)殿向け チュートリアル. ソフトウェア開発手法の最前線 ~ アスペクト指向、MDA、MIC ~. 九州工業大学 情報工学部 知能情報工学科 鵜林尚靖 2005年9月12日. 内容. アスペクト指向の背景 アスペクト指向の概要 アスペクト指向、MDA、そしてMIC アスペクト指向の今後 研究室の紹介. ソフトウェア開発手法の変遷. 60. 70. 80. 90. 2000. 年代. 年代. 年代. 年代. 年代. 構造化手法. オブジェクト指向手法. 構造化プログラミング 構造化分析 構造化設計. OOP. - PowerPoint PPT PresentationTRANSCRIPT
1
ソフトウェア開発手法の最前線~ アスペクト指向、MDA、MIC ~
九州工業大学情報工学部 知能情報工学科鵜林尚靖2005年9月12日
東芝情報システム(株)殿向けチュートリアル
2
内容
アスペクト指向の背景 アスペクト指向の概要 アスペクト指向、MDA、そしてMIC アスペクト指向の今後 研究室の紹介
3
ソフトウェア開発手法の変遷60年代 70年代 80年代 90年代 2000年代
構造化手法
オブジェクト指向手法
OOAOODパターンフレームワークコンポーネント
MDA
アスペクト指向
構造化プログラミング構造化分析構造化設計 OOP EA
プロダクトラインアジャイル , XP
4
1.アスペクト指向の背景
5
アスペクト指向とは何?
一言でいうと
「モジュール化メカニズム」の一つ
6
モジュール化メカニズムの歴史
構造化機能中心のため、データの変更に対して脆い
データ抽象データとそれに関連する操作をまとめてしまおう
抽象データ型データとそれに関連する操作をまとめて型にしよう
オブジェクト指向継承機構も入れて、再利用性を高めよう
7
モジュール化の理想像
問題領域
要求分析 設計 実装
ソフトウェア構造
問題領域の構造がソフトウェア構造に対応するソフトウェア構造を構成する関心事を自然にモジュール化できる (関心事の分離 “ Separation of Concerns” Edsger Wybe Dijkstra )
分析時の関心事
設計時の関心事
モジュールの構成
8
良いモジュール化
org.apache.tomcat における XML parsing– 赤い線は XML parsing を行うコード行を示す– 1箇所にモジュール化されている
AspectJ. http://eclipse.org/aspectj/ より抜粋
機能要件をきれいにモジュール化
9
しかし、ログ処理の場合は...
org.apache.tomcat におけるログ処理– 赤い線はログ処理を行うコード行を示す – 1箇所ではない– しかも、数多くの場所に分散している( tangling and
scattering )
複数のオブジェクトにまたがる( Crosscutting Concerns )
AspectJ. http://eclipse.org/aspectj/ より抜粋
10
現実のモジュール化は...
(問題意識) 上流の関心事が、下流に行くにしたがって構造的に分散してしまう (オブジェクト指向でも解決できない問題がある)
問題領域
要求分析 設計 実装
ソフトウェア構造
分析時の関心事
設計時の関心事
モジュールの構成
11
従来手法の問題
<横断的関心事の例>
・エラーチェック戦略・セキュリティ・デザインパターン・同期制御・資源共有・分散にかかわる関心事・性能最適化・プラットフォーム
オブジェクト指向プログラミングは、機能要件のカプセル化には優れているが、横断的関心事( Crosscutting Concerns )の表現には必ずしも向いていない。
性能最適化のためのコードを追加しようとすると、コードが複数のオブジェクトに分散してしまい、見通しの悪いプログラムになってしまう。「分かりやすく性能も良い」プログラムを作るのが難しい。
12
ソフトウェアの構造
HW特性
応答性
最適化メモリ容量
きれいなプログラムを作成したい!でも、プラットフォーム適合、HW特性、性能向上、例外のためのコードを追加するとどんどんプログラムが汚くなってしまう。。。
プラットフォーム
13
解決方法
MIC (Model-Integrated Computing) AOP (Aspect-Oriented Programming) IP (Itentional Programming) GenVoca
今日はアスペクト指向について紹介アスペクト指向と絡めて、MDA、MICについて紹介
14
2.アスペクト指向の概要
15
アスペクト指向を実現する言語処理系、システム 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
J2EE環境への適用が増えている!POJO( Plain Old Java Object )
今日はAspectJベースで紹介
16
AOP ( Aspect-Oriented Programming )AOP とは、同期制御、資源共有、性能最適化など複数のオブジェクトにまたがる関心事をアスペクトというモジュール概念を用いて記述するプログラミング方式
weaver
オブジェクト(通常の機能)
アスペクト(オブジェクトにまたがる関心事)
プログラム
・複数のオブジェクトにまたがる関心事を見通しよく記述できる!・「分かりやすく性能も良い」プログラムが作れる!
17
AOPのメカニズム JPM( Join Point Model )
プログラム上の様々な実行
点
( join point )
実行点の取り出し
( pointcut )
実行点の中からログ処理に関わる部分を抽出
ログ処理コードの埋め込み
( advice )
メソッド呼び出し、変数参照/更新などの実行点を捕まえる
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
18
AspectJの主要概念
振る舞いへの作用
ジョインポイント(join point)ポイントカット(pointcut)アドバイス(advice)
構造への作用
インタータイプ定義declare句による宣言
19
簡単なAspectJプログラム
「 AspectJ によるアスペクト指向プログラミング入門」 長瀬、天野、鷲崎、立堀 ( 著 ) より
public class HelloWorld { public static void main ( String [], args) { HelloWorld app = new HelloWorld (); app.hello(); }
void hello() { System.out.println(“こんにちは!” ); }}
HelloWorld.javapublic 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アスペクト
ポイントカット
アドバイス
インタータイプ定義
20
例題: 簡易図形エディタ
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/ より抜粋
21
通常の保守、改良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/ より抜粋
22
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つのアスペクトに局所化される!
AspectJ. http://eclipse.org/aspectj/ より抜粋
23
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/ より抜粋
24
3.アスペクト指向、MDA、 そしてMIC
25
(1) MDA
26
現状の課題(オブジェクト指向分析、設計)
モデルの再利用は限定的: 分析や設計時のモデル資産を蓄積することにより、ある程度の再利用部品化が可能。しかし、オブジェクト指向による設計モデルの多くは実装に依存する部分と依存しない部分が明確に切り分けられていない場合が多く、再利用の範囲は限定的。
人手によるモデル間の変換: 分析モデルから設計モデルへの変換、設計モデルからプログラムコードへの変換は多くの場合人手で行われている。せっかくモデルを作成しても、直接プログラムコードにはつながらない。
27
MDA ( Model-Driven Architecture )とは
実装技術(J2EEや.NETなど)から分析 / 設計を独立させ、設計情報が実装技術に左右されないようにする技術
分析 /設計部分はプラットフォームに依存しない為、再利用可能
UML 2の目玉
28
MDAと従来プロセスの違い
分析
設計
コーディング
CIM
PIM
PSM
ソース・コード
CIM: Computation Independent ModelPIM: Platform Independent ModelPSM: Platform Specific Model
従来の開発 MDAによる開発
設計フェーズが大きく変化!
モデルコンパイラによる自動変換
29PIM PSM
ステップ1: 複数PIMの合成
ステップ2: アクションフォーム Beanへの変換
ステップ3: アクションクラス の新規作成
モデル変換の例(Strutsの場合)
①PIM クラスのマージ
②Bean規約名に変更③ActionForm を継承④setter/getter を追加
⑤アクションクラスを生成⑥Action を継承⑦execute メソッドを追加⑧メソッド本体を追加
30
MDAのメリット
コード中心開発からモデル中心開発へパラダイムシフト: 開発者は特定のプラットフォームやプログラミング技術にとらわれることなく、 PIM の開発に全力を注ぐことができる。
新しいタイプのコンポーネント化: PIM モデル部品とモデル変換規則をライブラリ化することにより、様々な機能やプラットフォームに対応したプロダクト群を生成することが可能になり、プロダクトライン型開発の実現につながる。
31
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 の例
32
(2)アスペクト指向との接点
33
何故、アスペクト指向なのか?
プラットフォームに関わる部分は横断的関心事。 → アスペクトが得意とするところ
モデル変換の対象はプラットフォームのみに留まらない。最適化、等々。
→ 現状のMDAはモデル変換の一部しか 捉えていない
上流段階(ユースケースや設計レベル)でのアスペクト指向サポートが必要。セキュリティなどの横断的関心事はモデリング段階で考える必要がある。
→ Early Aspect
34
MDAとアスペクト指向
「 AspectJ によるアスペクト指向プログラミング入門」 長瀬、天野、鷲崎、立堀 ( 著 ) より
PIMモデル(UML)
マッピングルール(MOF QVT)
アプリケーション
実装環境対応コード
アプリケーション
実装環境対応コード
アスペクト記述言語
weaving
35
我々の研究室での研究事例
アスペクト指向に基づく拡張可能なモデルコンパイラ
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
36
当研究室のAspectMモデルコンパイラ
アスペクト( モデル変換モジュールとしてのアスペクト )
アスペクト( モデル変換モジュールとしてのアスペクト )
アスペクト図( モデル変換モジュールとしてのアスペクト )
UML モデル( クラス図 )
UML モデル( クラス図 )weave
アスペクトを追加することにより様々な変換を可能にする
アスペクト図( システム構成モジュール
としてのアスペクト )
モデルコンパイラXML
XML
XML
XML
アスペクト指向メカニズムによりモデルコンパイラを実現!
37
モデルレベルのアスペクト指向
classAattributes
operationsclassB
attributes
operationsclassC
attributes
operations
join point
(class) classA || classB)pointcut classA
attributesnew attributes
operationsnew
operations
adviceadd new attributesadd new operations
JPMの概念を拡張(通常のAspectJにおけるJPMとは異なる)
classBattributes
new attributesoperations
new operations
join point
(class) join point
(class)
横断的関心事(プラットフォームなど)をモデルに挿入
38
モデル変換のためのJPM
モデル変換機能 PA CM NE OC RN RL操作本体の変更 ○クラスのマージ ○クラスの追加 /削除 ○操作の追加 /削除 ○属性の追加 /削除 ○クラス名の変更 ○操作名の変更 ○属性名の変更 ○継承の追加 /削除 ○集約の追加 /削除 ○関連の追加 /削除 ○PA ( pointcut & advice ), CM ( composition ), NE ( new element ), OC ( open class ), RN ( rename ),RL ( relation )
39
モデル変換のためのJPM(つづき)JPM Join point Pointcut AdvicePA operation
記述例 ① setX || setY ② set* ③ classA ||
classB ④ class*
before,after,around
CM class merge-by-nameNE class-diagram add-class
delete-classOC class add-operation,
delete-operation,add-attribute,delete-attribute
RN class, operation, attribute
rename
RL class add-inheritance,delete-inheritance,add-aggregation,delete-
aggregation,add-relationship,delete-relationship
40
<< jpm-type >>aspect-name
pointcut-name : joinpoint-type { pointcut-body } : :
advice-name [pointcut-name]: advice-type { advice-body } : :
aspect <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>
AspectMによるモデル記述
ダイアグラム表記 ダイアグラム保存形式( XMLベース)
6つのJPMをサポート(新たなJPMを追加可能)3種類のアスペクトをサポート(通常アスペクト、コンポーネントアスペクト、テンプレートアスペクト)
UMLを対象としたXMLベースのAOP言語
41
AspectM 支援ツール
UML diagramsAspect diagrams
Model Editor (Eclipse UML)
AspectMmetamodel
(EMF)
XMI (PIM)XMI
XSLT style sheet
XMI (PSM)
XSLT style sheet
Java code
Model Compiler
42
アスペクト導入のためのメタモデル
Aspect
Class
UMLメタモデルを拡張
43
(3)MDAからMICへ
44
MDAの先にあるもの
MDA: プラットフォームに関する関心事を分離
アスペクト指向: プラットフォームのみならず、モデリング段階 の横断的関心事を分離
ドメイン指向モデリングドメイン専用モデリング言語
( DSL: Domain-Specific Modeling Language )
45
Model-Integrating Computing (MIC) Vanderbilt Univ. の ISIS ( Institute for
Software Integrated Systems )で研究開発。
ドメイン専用モデリング環境を提供。 アスペクト指向への応用は、 J.Gray ( 現在、 Univ. of Alabama ) が研究。AODM( Aspect-Oriented Domain Modeling )を提案。
46
Model-integrated approach to software composition
Janos Sztipanovits and Gabor Karsai:Generative Programming for Embedded Systems,GPCE2002, LNCS2487, pp.32--49, 2002
[出典]
47
Meta-modeling language architecture
適用例
Janos Sztipanovits and Gabor Karsai:Generative Programming for Embedded Systems,GPCE2002, LNCS2487, pp.32--49, 2002
[出典]
48
4.アスペクト指向の今後
49
アスペクト指向の今後
現在、プログラミング周りで研究が活発(80年代のOOP研究を彷彿させる)
今後は、適用事例の拡大、開発方法論の整備、アスペクトコンポーネント・フレームワークの整備に向かって行くと思われる(90年代のOOソフトウェアエンジアリングの発展に類似)
歴史は繰り返す...
50
AOSD ソフト開発工程全体への波及
AOP ( Aspect-Oriented Programming )から
AOSD ( Aspect-Oriented Software Development )へ
要求分析 設計 実装
Early Aspect AODesign Pattern
AO: Aspect-Oriented
AOFramework
AspectMining
AOLanguage
AOComponent
AOModeling
AODatabase
51
上流段階のアスペクト研究例Stein他[AOSD2002]
アスペクトをUML図として表現する方法を提案モデリング段階のアスペクトはAspectJなどのAO
P言語に変換するもので、この方法ではMDAは実現できない
AspectMのアスペクトはUML図自身を操作するものGray他[GPCE2003]
AODM( Aspect-Oriented Domain Modeling )を提案属性や関連などのモデル要素を追加する機能をもつMDAなどの一般的なモデル変換を対象にしたものではな
いSillito他[ECOOP2004]
ユースケースレベルのポイントカットを提案上流のモデリング段階においてもJPMの考え方が有効で
あることを示した
52
アスペクト指向言語の変遷
ドメイン専用AOP言語を個々に開発するアプローチ(1997年頃まで)
Weaver を開発するのが大変
汎用AOP言語( AspectJ等: 「 Pointcut+ Advice 」メカニズム)のアプローチ(現在)
拡張可能ドメイン専用AOP言語の( Xaspect等)アプローチ(これから)
適用範囲が限定される
53
アスペクト指向に関する情報源
国際会議
Aspect-Oriented Software Development (AOSD)OOPSLA, ECOOP, GPCE, ICSE, FSE, ICFP など
ポータルサイト
http://aosd.net
54
5.研究室の紹介
55
最近の主な研究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
56
現在進行形の研究
Weaving by Contract Contract Generator for AO Refactorings Class-based AOP Language Reflective AOP Language
57
おわり