slide1
Download
Skip this Video
Download Presentation
ソフトウェア開発手法の最前線 ~ アスペクト指向、MDA、MIC ~

Loading in 2 Seconds...

play fullscreen
1 / 57

MDAMIC - PowerPoint PPT Presentation


  • 46 Views
  • Uploaded on

東芝情報システム(株)殿向け チュートリアル. ソフトウェア開発手法の最前線 ~ アスペクト指向、MDA、MIC ~. 九州工業大学 情報工学部 知能情報工学科 鵜林尚靖 2005年9月12日. 内容. アスペクト指向の背景 アスペクト指向の概要 アスペクト指向、MDA、そしてMIC アスペクト指向の今後 研究室の紹介. ソフトウェア開発手法の変遷. 60. 70. 80. 90. 2000. 年代. 年代. 年代. 年代. 年代. 構造化手法. オブジェクト指向手法. 構造化プログラミング 構造化分析 構造化設計. OOP.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about ' MDAMIC ' - nitsa


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
slide1

東芝情報システム(株)殿向け

チュートリアル

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

九州工業大学

情報工学部 知能情報工学科

鵜林尚靖

2005年9月12日

slide2
内容
  • アスペクト指向の背景
  • アスペクト指向の概要
  • アスペクト指向、MDA、そしてMIC
  • アスペクト指向の今後
  • 研究室の紹介
slide3
ソフトウェア開発手法の変遷

60

70

80

90

2000

年代

年代

年代

年代

年代

構造化手法

オブジェクト指向手法

構造化プログラミング

構造化分析

構造化設計

OOP

OOA

OOD

パターン

フレームワーク

コンポーネント

EA

プロダクトライン

アジャイル, XP

MDA

アスペクト指向

slide5
アスペクト指向とは何?

一言でいうと

「モジュール化メカニズム」の一つ

slide6
モジュール化メカニズムの歴史

構造化

機能中心のため、データの変更に対して脆い

データ抽象

データとそれに関連する操作をまとめてしまおう

抽象データ型

データとそれに関連する操作をまとめて型にしよう

オブジェクト指向

継承機構も入れて、再利用性を高めよう

slide7
モジュール化の理想像

ソフトウェア構造

要求分析

設計

実装

問題

領域

分析時の

関心事

設計時の

関心事

モジュールの

構成

  • 問題領域の構造がソフトウェア構造に対応する
  • ソフトウェア構造を構成する関心事を自然にモジュール化できる

 (関心事の分離 “Separation of Concerns” Edsger Wybe Dijkstra )

slide8
良いモジュール化

機能要件を

きれいにモジュール化

  • org.apache.tomcat におけるXML parsing
    • 赤い線はXML parsingを行うコード行を示す
    • 1箇所にモジュール化されている

AspectJ. http://eclipse.org/aspectj/より抜粋

slide9
しかし、ログ処理の場合は...

複数のオブジェクトにまたがる

(Crosscutting Concerns)

  • org.apache.tomcat におけるログ処理
    • 赤い線はログ処理を行うコード行を示す
    • 1箇所ではない
    • しかも、数多くの場所に分散している(tangling and scattering)

AspectJ. http://eclipse.org/aspectj/より抜粋

slide10
現実のモジュール化は...

ソフトウェア構造

要求分析

設計

実装

問題

領域

分析時の

関心事

設計時の

関心事

モジュールの

構成

(問題意識)

 上流の関心事が、下流に行くにしたがって構造的に分散してしまう

 (オブジェクト指向でも解決できない問題がある)

slide11
従来手法の問題

オブジェクト指向プログラミングは、機能要件のカプセル化には優れているが、横断的関心事( Crosscutting Concerns )の表現には必ずしも向いていない。

<横断的関心事の例>

・エラーチェック戦略

・セキュリティ

・デザインパターン

・同期制御

・資源共有

・分散にかかわる関心事

・性能最適化

・プラットフォーム

性能最適化のためのコードを追加しようとすると、コードが複数のオブジェクトに分散してしまい、見通しの悪いプログラムになってしまう。「分かりやすく性能も良い」プログラムを作るのが難しい。

slide12
ソフトウェアの構造

最適化

メモリ容量

HW特性

プラットフォーム

応答性

きれいなプログラムを作成したい!

でも、プラットフォーム適合、HW特性、性能向上、例外

のためのコードを追加すると

どんどんプログラムが汚くなってしまう。。。

slide13
解決方法
  • MIC (Model-Integrated Computing)
  • AOP (Aspect-Oriented Programming)
  • IP (Itentional Programming)
  • GenVoca

今日はアスペクト指向について紹介

アスペクト指向と絡めて、MDA、MICについて紹介

slide15
アスペクト指向を実現する言語処理系、システムアスペクト指向を実現する言語処理系、システム
  • 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ベースで紹介

aop aspect oriented programming
AOP(Aspect-Oriented Programming)

AOPとは、同期制御、資源共有、性能最適化など複数のオブジェクトにまたがる関心事をアスペクトというモジュール概念を用いて記述するプログラミング方式

オブジェクト

(通常の機能)

weaver

プログラム

アスペクト

(オブジェクトに

またがる関心事)

・複数のオブジェクトにまたがる関心事を見通しよく記述できる!

・「分かりやすく性能も良い」プログラムが作れる!

join point model
AOPのメカニズム JPM(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)

slide18
AspectJの主要概念

振る舞いへの作用

  • ジョインポイント(join point)
  • ポイントカット(pointcut)
  • アドバイス(advice)

構造への作用

  • インタータイプ定義
  • declare句による宣言
slide19
簡単なAspectJプログラム

アスペクト

インタータイプ

定義

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によるアスペクト指向プログラミング入門」

長瀬、天野、鷲崎、立堀(著) より

slide20

Figure

FigureElement

moveBy(int, int)

makePoint(..)makeLine(..)

Point

Line

getX()getY()setX(int)setY(int)moveBy(int, int)

getP1()getP2()setP1(Point)setP2(Point)moveBy(int, int)

operations that move elements

例題: 簡易図形エディタ

Display

*

2

AspectJ. http://eclipse.org/aspectj/より抜粋

slide21
通常の保守、改良

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 {

privateint 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 {

privateint 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/より抜粋

aspectj
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 {

privateint 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);

}

}

変更が1つのアスペクトに局所化される!

AspectJ. http://eclipse.org/aspectj/より抜粋

slide23

Figure

FigureElement

moveBy(int, int)

makePoint(..)makeLine(..)

Point

Line

getX()getY()setX(int)setY(int)moveBy(int, int)

getP1()getP2()setP1(Point)setP2(Point)moveBy(int, int)

クラスを横断するアスペクト

Display

*

2

DisplayUpdating

AspectJ. http://eclipse.org/aspectj/より抜粋

slide24

3.アスペクト指向、MDA、  そしてMIC3.アスペクト指向、MDA、  そしてMIC

slide26
現状の課題(オブジェクト指向分析、設計)
  • モデルの再利用は限定的: 分析や設計時のモデル資産を蓄積することにより、ある程度の再利用部品化が可能。しかし、オブジェクト指向による設計モデルの多くは実装に依存する部分と依存しない部分が明確に切り分けられていない場合が多く、再利用の範囲は限定的。
  • 人手によるモデル間の変換: 分析モデルから設計モデルへの変換、設計モデルからプログラムコードへの変換は多くの場合人手で行われている。せっかくモデルを作成しても、直接プログラムコードにはつながらない。
mda model driven architecture
MDA(Model-Driven Architecture)とは

実装技術(J2EEや.NETなど)から分析/設計を独立させ、設計情報が実装技術に左右されないようにする技術

分析/設計部分はプラットフォームに

依存しない為、再利用可能

UML2の目玉

slide28
MDAと従来プロセスの違い

従来の開発

MDAによる開発

設計フェーズが

大きく変化!

CIM

分析

PIM

設計

モデルコンパイラ

による自動変換

PSM

コーディング

ソース・コード

CIM: Computation Independent Model

PIM: Platform Independent Model

PSM: Platform Specific Model

slide29
モデル変換の例(Strutsの場合)

ステップ1: 複数PIMの合成

①PIMクラスのマージ

ステップ2: アクションフォーム

        Beanへの変換

②Bean規約名に変更

③ActionFormを継承

④setter/getterを追加

ステップ3: アクションクラス

        の新規作成

⑤アクションクラスを生成

⑥Actionを継承

⑦executeメソッドを追加

⑧メソッド本体を追加

PIM

PSM

slide30
MDAのメリット
  • コード中心開発からモデル中心開発へパラダイムシフト: 開発者は特定のプラットフォームやプログラミング技術にとらわれることなく、PIMの開発に全力を注ぐことができる。
  • 新しいタイプのコンポーネント化:PIMモデル部品とモデル変換規則をライブラリ化することにより、様々な機能やプラットフォームに対応したプロダクト群を生成することが可能になり、プロダクトライン型開発の実現につながる。
slide31
MDA実現のための鍵
  • 厳密なモデル表記 (MOF、OCL)
  • 厳密なモデル変換定義 (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

slide33
何故、アスペクト指向なのか?
  • プラットフォームに関わる部分は横断的関心事。

→ アスペクトが得意とするところ

  • モデル変換の対象はプラットフォームのみに留まらない。最適化、等々。

→現状のMDAはモデル変換の一部しか

        捉えていない

  • 上流段階(ユースケースや設計レベル)でのアスペクト指向サポートが必要。セキュリティなどの横断的関心事はモデリング段階で考える必要がある。 

→ Early Aspect

slide34
MDAとアスペクト指向

PIMモデル(UML)

アプリケーション

実装環境対応コード

weaving

アプリケーション

実装環境対応コード

マッピングルール(MOF QVT)

アスペクト記述言語

「AspectJによるアスペクト指向プログラミング入門」

長瀬、天野、鷲崎、立堀(著) より

slide35

我々の研究室での研究事例

アスペクト指向に基づく拡張可能なモデルコンパイラ

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

slide36

アスペクト

(モデル変換モジュール

としてのアスペクト)

アスペクト

(モデル変換モジュール

としてのアスペクト)

アスペクト図

(モデル変換モジュール

としてのアスペクト)

当研究室のAspectMモデルコンパイラ

XML

アスペクトを追加することにより様々な変換を可能にする

weave

UMLモデル

(クラス図)

UMLモデル

(クラス図)

XML

XML

モデルコンパイラ

アスペクト図

(システム構成モジュール

としてのアスペクト)

アスペクト指向メカニズムにより

モデルコンパイラを実現!

XML

slide37
モデルレベルのアスペクト指向

join point

(class)

pointcut

advice

classA

classA || classB)

add new attributes

add new operations

attributes

new attributes

classA

attributes

operations

new operations

operations

classB

classB

attributes

join point

(class)

attributes

new attributes

operations

横断的関心事(プラットフォームなど)をモデルに挿入

operations

new operations

classC

join point

(class)

attributes

operations

JPMの概念を拡張(通常のAspectJにおけるJPMとは異なる)

slide38
モデル変換のためのJPM

PA(pointcut & advice),CM(composition),NE(new element),OC(open class),RN(rename),RL(relation)

slide40
AspectMによるモデル記述
  • 6つのJPMをサポート(新たなJPMを追加可能)
  • 3種類のアスペクトをサポート(通常アスペクト、コンポーネントアスペクト、テンプレートアスペクト)
  • UMLを対象としたXMLベースのAOP言語

ダイアグラム表記

ダイアグラム保存形式(XMLベース)

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>

<< jpm-type >>

aspect-name

pointcut-name : joinpoint-type

{ pointcut-body }

advice-name [pointcut-name]: advice-type

{ advice-body }

aspectm
AspectM 支援ツール

Model Editor (Eclipse UML)

Model Compiler

UML diagrams

XMI (PIM)

Aspect diagrams

XMI

XSLT style sheet

XMI (PSM)

AspectM

metamodel

XSLT style sheet

(EMF)

Java code

slide42

Class

アスペクト導入のためのメタモデル

UMLメタモデル

を拡張

Aspect

slide44
MDAの先にあるもの

MDA: プラットフォームに関する関心事を分離

アスペクト指向: プラットフォームのみならず、モデリング段階

          の横断的関心事を分離

ドメイン指向モデリング

ドメイン専用モデリング言語

(DSL: Domain-Specific Modeling Language)

model integrating computing mic
Model-Integrating Computing (MIC)
  • Vanderbilt Univ.のISIS(Institute for Software Integrated Systems)で研究開発。
  • ドメイン専用モデリング環境を提供。
  • アスペクト指向への応用は、J.Gray (現在、Univ. of Alabama )が研究。AODM(Aspect-Oriented Domain Modeling)を提案。
model integrated approach to software composition
Model-integrated approach to software composition

[出典]

Janos Sztipanovits and Gabor Karsai:

Generative Programming for Embedded Systems,

GPCE2002, LNCS2487, pp.32--49, 2002

meta modeling language architecture
Meta-modeling language architecture

適用例

[出典]

Janos Sztipanovits and Gabor Karsai:

Generative Programming for Embedded Systems,

GPCE2002, LNCS2487, pp.32--49, 2002

slide49
アスペクト指向の今後
  • 現在、プログラミング周りで研究が活発(80年代のOOP研究を彷彿させる)
  • 今後は、適用事例の拡大、開発方法論の整備、アスペクトコンポーネント・フレームワークの整備に向かって行くと思われる(90年代のOOソフトウェアエンジアリングの発展に類似)

歴史は繰り返す...

slide50
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

slide51
上流段階のアスペクト研究例

Stein他[AOSD2002]

  • アスペクトをUML図として表現する方法を提案
  • モデリング段階のアスペクトはAspectJなどのAOP言語に変換するもので、この方法ではMDAは実現できない
  • AspectMのアスペクトはUML図自身を操作するもの

Gray他[GPCE2003]

  • AODM(Aspect-Oriented Domain Modeling)を提案
  • 属性や関連などのモデル要素を追加する機能をもつ
  • MDAなどの一般的なモデル変換を対象にしたものではない

Sillito他[ECOOP2004]

  • ユースケースレベルのポイントカットを提案
  • 上流のモデリング段階においてもJPMの考え方が有効であることを示した
slide52
アスペクト指向言語の変遷

ドメイン専用AOP言語を個々に開発するアプローチ

(1997年頃まで)

Weaverを開発するのが大変

汎用AOP言語(AspectJ等: 「Pointcut+Advice」メカニズム)のアプローチ

(現在)

適用範囲が限定される

拡張可能ドメイン専用AOP言語の(Xaspect等)アプローチ

(これから)

slide53
アスペクト指向に関する情報源

ポータルサイト

http://aosd.net

国際会議

Aspect-Oriented Software Development (AOSD)OOPSLA, ECOOP, GPCE, ICSE, FSE, ICFP など

slide55
最近の主な研究

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

slide56
現在進行形の研究
  • Weaving by Contract
  • Contract Generator for AO Refactorings
  • Class-based AOP Language
  • Reflective AOP Language
ad