MDA (Model Driven Architecture) モデル駆動型開発手法

MDA
(Model Driven Architecture)
モデル駆動型開発手法
2005年12月10日
佐藤 治夫
copyright , 2007 Be PROUD
1
アウトライン
1. はじめに∼MDAとは
2. システム開発プロジェクトの現状
3. Model Driven Architecture
4. MDAのインパクト
copyright , 2007 Be PROUD
2
アウトライン
1. はじめに∼MDAとは
2. システム開発プロジェクトの現状
3. Model Driven Architecture
4. MDAのインパクト
copyright , 2007 Be PROUD
3
1. はじめに∼MDAとは
MDAとは
(Model Driven Architecture)
モデルを中心として駆動する
自動化技術を活用した開発手法のこと
①開発するシステムを
ツールを使用してモデルで表現
（モデリング）
開発者
②モデルをもとに
ソースコード等を自動生成
モデル
主にUMLで作成 etc…
copyright , 2007 Be PROUD
ソースコード
実行コード
4
アウトライン
¾ はじめに∼MDAとは
¾ システム開発プロジェクトの現状
¾ Model Driven Architecture
¾ MDAのインパクト
copyright , 2007 Be PROUD
5
2. システム開発プロジェクトの現状
ビジネスの成功と
ITシステムの深い関わり
→ITシステムに対して期待・要求が高まっている
1.
2.
3.
4.
5.
多種多様・複雑な機能の実現
短納期かつ高品質
高い稼働率
セキュリティの確保
変更への柔軟・迅速な対応
copyright , 2007 Be PROUD
6
2. システム開発プロジェクトの現状
要求の高まりの結果
何が起こっているか
1. 低いプロジェクトの成功率
（Quality：品質、Cost：予算、Delivery：納期）が達成されていない
2. 要求実現のためSEは過酷な労働
残業、土日出勤は日常茶飯事
3. QCD未達成のためユーザーからの
評価が低くなりがち
copyright , 2007 Be PROUD
7
2. システム開発プロジェクトの現状
理由
1. 開発プロセスが乱立し、模索状態
RUP、アジャイル、ウォーターフォール etc…
2. 次々と出現する実装技術
Java, C#, Struts , JSF, Spring , Seasar2 , Hibernate , i-Batis , Ajax etc…
3. 依然として手動・目視が中心のテスト
copyright , 2007 Be PROUD
8
2. システム開発プロジェクトの現状
この幸せとはいえない
現状を打開するには？
一つの解
自動化技術を活用した
開発プロセスの確立が鍵
→MDAの導入
copyright , 2007 Be PROUD
9
アウトライン
1. はじめに∼MDAとは
2. システム開発プロジェクトの現状
3. Model Driven Architecture
4. MDAのインパクト
copyright , 2007 Be PROUD
10
3. Model Driven Archtecture
MDAの基本概念
≪MDA≫
≪開発プロセス≫
※実装技術、プラットフォームとは
プログラミング言語・DBなどのこと
要求分析
〔成果物〕
（注）仕様書=PIMではない
仕様分析
仕様書
PIM (Platform Independent Model)
ユーザーの視点からシステムを表現
＝実装技術に依存しない
設計
設計書
変換ルール
PSM (Platform Specific Model)
作り手の視点からシステムを表現
＝実装技術 依存
実装／テスト
自動変換
自動変換
変換ルール
ソースコード等
copyright , 2007 Be PROUD
11
3. Model Driven Archtecture
モデル変換の具体例
≪成果物の例≫
分析レベルのモデル
(実装技術非依存）
PHP
PSM
ソース
・ユースケース図
・ドメインモデル（クラス図)
・画面遷移図（アクティビティ図）
PIM
C#
Java
PSM
ソース
PSM
ソース
copyright , 2007 Be PROUD
・Struts+Spring+Hibernate
のクラス図
・ER図
・Javaソースコード
・JSPファイル
・設定ファイル
・SQLファイル
・ビルドファイル
12
3. Model Driven Archtecture
仕様→設計の手法の特徴
要求分析
仕様分析
設計
1.
実装技術ごとに一定の設計パターンが存在する
（プログラミング言語・フレームワークごと）
2. 設計技術はパターン化することができる。
※ パターン化した例
・ ｴﾝﾀｰﾌﾟﾗｲｽﾞ・ｱﾌﾟﾘｹｰｼｮﾝ・ｱｰｷﾃｸﾁｬ・ﾊﾟﾀｰﾝ
・ デザインパターン
・ J2EEパターン
実装／テスト
copyright , 2007 Be PROUD
13
3. Model Driven Archtecture
設計→実装の手法の特徴
要求分析
仕様分析
設計
設計書の内容をソースとして実装する。
→パターン化できる。
①クラス図→クラスのソースコード
②ER図→SQL DDL文
③アクティビティ図→画面遷移設定ファイル
(struts-config.xml、faces-config.xml)
実装／テスト
copyright , 2007 Be PROUD
14
3. Model Driven Archtecture
パターン化から自動化へ
１．分析→設計
２．設計→実装
パターン化することが可能
その作業は自動化できる
copyright , 2007 Be PROUD
15
3. Model Driven Archtecture
分析（PIM)→設計（PSM) 変換例
１．連番フィールドの付与
２．多対多モデル
３．フレームワークへのマッピング
copyright , 2007 Be PROUD
16
3. Model Driven Archtecture
例１ 連番フィールドの付与
≪PIM≫
商品を一意に
識別できる
商品コード
変換
≪PSM≫
レコードを一意に
識別できる
連番IDを付与
copyright , 2007 Be PROUD
17
3. Model Driven Archtecture
例２ 多対多モデル
関係テーブルを用いて多対多のデータを格納
≪PIM≫
変換
≪PSM≫
１対多
関係テーブル
copyright , 2007 Be PROUD
多対１
18
3. Model Driven Archtecture
例３ フレームワークへのマッピング
≪PIM≫
変換
≪PSM≫
≪プレゼンテーション層≫
Struts
≪サービス層≫ ≪DAO層≫
Spring
copyright , 2007 Be PROUD
Hibernate
19
3. Model Driven Archtecture
MDAの効果
1.
2.
モデルを中心として、分析・設計・実装がマッピングしているので、開発サ
イクルを統一した手法で進めることができる。
パターン化できる作業の自動化により品質・生産性の向上が期待できる。
分析
PIM (Platform Independent Model)
自動変換
設計
PSM (Platform Specific Model)
自動変換
実装
変換ルール
変換ルール
ソースコード等
copyright , 2007 Be PROUD
20
3. Model Driven Archtecture
MDAに関連するOMG標準
OMG（Object Management Group)が
モデリングのための標準を策定
1. UML2.0
→MDA対応のため仕様を厳密に定義しなおした。
2. MOF(Meta Object Facility)
→モデリング言語を定義するためのメタモデルを定義した仕様
3. XMI(XML Metadata Interchange)
→メタモデルをXMLで表現するための仕様
4. QVT(Query View Transformations)
→モデル変換定義の標準仕様
copyright , 2007 Be PROUD
21
3. Model Driven Archtecture
MDAにおける
OMG標準の位置づけ
モデリング言語
（UML2.0など）
on MOF
PIM (Platform Independent Model)
XMI
自動変換
変換ルール
QVT
モデリング言語
（UML2.0など）
on MOF
PSM (Platform Specific Model)
XMI
自動変換
変換ルール
QVT
ソースコード等
copyright , 2007 Be PROUD
22
3. Model Driven Archtecture
MDA対応ツール
1. Borland Toghether（Borland社）
2. Rational Rose（IBM社）
3. AndroMDA(オープンソース)
http://www.andromda.org/
4. Optimal J（コンピュウェア社)
5. Eclipse
EMF（Eclipse Modeling Framework) , UML2 ,
GMT（Generative Model Transformer)
etc….
copyright , 2007 Be PROUD
23
(参考)AndroMDAの記事
1. Java World 『実践！モデルドリブン開発
∼AndroMDAで試す近未来のJava開発』
2005年5月∼12月連載
2. CodeZine『AndroMDAでMDAの世界を
体験する（コード生成編・コード分析編）』
http://codezine.jp/a/article.aspx?aid=132
http://codezine.jp/a/article.aspx?aid=133 copyright , 2007 Be PROUD
24
3. Model Driven Archtecture
２つの自動化による高品質開発
∼MDA活用の展望
変換ﾙｰﾙ定義者
＜開発発注側＞
＜外部開発組織＞
変換ﾙｰﾙ
PIM
変換ﾙｰﾙ
PSM
ソース
拡張ソースコード
ソース・テストコード自動生成
（トップダウンの自動化）
テストコード
仕様検討者・モデラー
＜受け入れテスト＞
テスト担当者
入力／出力ｲﾝﾀｰﾌｪｰｽが
決まっているので、
ﾃｽﾄｺｰﾄﾞも自動生成できる
テストコードの実装
プログラマ
自動ﾃｽﾄ
自動生成できない部分を
（ボトムアップの自動化）
コーディング
（拡張ポイントに対して）
拡張テストコード
copyright , 2007 Be PROUD
25
3. Model Driven Archtecture
MDAのこれから課題
1. なにをもってPIMとするか
モデリング手法・方法論の確立
2. MDAツールの充実
3. 開発プロセスとの統合
4. いかに計測し効果を高めていくか
copyright , 2007 Be PROUD
26
アウトライン
1. はじめに∼MDAとは
2. システム開発プロジェクトの現状
3. Model Driven Architecture
4. MDAのインパクト
copyright , 2007 Be PROUD
27
4. MDAのインパクト
開発プロジェクトへのインパクト
1.
2.
仕様・設計・実装がマッピングしているので、開発サイクル全体
を統一した手法で進めることができる。
高品質の成果物・生産性向上
→自動化技術のメリットを享受
3.
保守性の向上
仕様→設計→実装のトレーサビリティー
→モデルは、コードと乖離していない生きたドキュメントとなる
4.
モデルによるシステムの「見える化」
図表現による直感的な認識共有
→関係者間の認識のずれが早期に解消
→プロジェクトリスクが低減
copyright , 2007 Be PROUD
28
4. MDAのインパクト
経営層へのインパクト
1. 株主への説明責任
ソフトウェアのリスクをいかに管理しているかが問われる
2. コーポレートガバナンス（企業統治）への活用
コーポレートガバナンス＝企業の経営を監視する仕組み
→ソフトウェアライフサイクルを企業として監視する仕組みが必要となる。
（開発・運用・技術・セキュリティ）
3. モデルの資産化
copyright , 2007 Be PROUD
29
4. MDAのインパクト
モデルの資産化
PIMを保守していけば再構築プロジェクトの際も
モデルを再利用できる。（資産としてのモデル）
PIM
実装技術に比べて変化が少ない
PSM
PSM
PSM
Java1.4
Java5
新しい言語
（時間軸）
・実装技術は移り変わりが早い。
・ベンダーのサポート切れ
copyright , 2007 Be PROUD
30
4. MDAのインパクト
エンジニアへのインパクト
1. 自動化技術のメリットを享受
→生産性・品質の向上
→バグ・トラブルの減少
→残業・土日勤務の減少
2. 仕様→設計のマッピングを意識すること
によるエンジニア力の向上
3. 開発プロセス全体を意識した開発
copyright , 2007 Be PROUD
31
MDA
(Model Driven Architecture)
自動化技術を活用した
開発プロセスの確立が鍵
END
copyright , 2007 Be PROUD
32