SES2014 Workshop#4 で紹介したものに１枚追加しました

1. モデルベース開発における
モデルとプラットフォームについて
- オープンソースでどこまでできる？ -
ビューファイブLLC
田中明
a.tanaka@view5.co.jp
2014年9月3日SES2014 Workshop #4

2. 自己紹介
 アカデミックな活動や現場での開発経験より標準化活動を長く体
験してきました
 OSI上位層通信プロトコル標準化（ISO/IEC JTC1/SC21）
 通信対応API標準化（X/Open）
 分散オブジェクト標準化（OMG）
 オープン分散処理参照モデル（ISO/IEC JTC1/SC21, 7）
 モデリング標準（UML/UML Profile/MOF …）（OMG）
 モデルベースの開発が主流になる日が来ることを期待しつつ、更
に各種モデル標準を実際に使えるようにすることを目指し（学会
の外側で）地味に活動をしています
 Xtext ユーザ会
 Eclipse Modeling Project 勉強会
 Eclipse 非会員（但しアクセス頻度高）
 OMG 会員（Influencing Member）

3. モデリング
 問題領域（対象とする現実の世界）が複雑すぎるため枝
葉を切り捨て本質をとらえようとする知的活動だと理解
しています
 モデリング言語は沢山あると認識しています
 数学・数式はモデリング言語の一つ
 UML はとても強力なモデリング言語ですが、それでも沢山
ある言語のうちの一つ
 メタモデル標準、UML Profile標準、BPMN等はUMLだけでカ
バー出来ない領域のため
 Eclipse のEcore モデルはEMOF に基づくモデル実装
 組み込み分野でステートマシンやDSL がかなり利用されシ
ミュレーション機能がほぼ必須になっている

4. Third Biannual Workshop on Eclipse Open Source Software and
OMG Open Specifications 資料よりの引用
http://www.omg.org/news/meetings/tc/dc-12/special-events/pdf/overview.pdf

5. プラットフォーム
 プラットフォームの定義（MDA Guide version 1.0 より）
 “A platform in general is a set of subsystems/technologies that
provide a coherent set of functionality through interfaces and
specified usage patterns that any subsystem that depends on the
platform can use without concern for the details of how the
functionality provided by the platform is implemented.”
 例：一般的（オブジェクト、バッチ等）、テクノロジ（CORBA/CORBA
Components/J2EE etc.）、ベンダ固有
 モデル駆動開発はプラットフォームに到達しないと完了しません
 ところがプラットフォームは日々進化するmoving target
 「プラットフォーム」の認識が異なりモデル駆動の議論が噛み合ない
ことが多々ありました
 モデル駆動開発は「モデリングとプログラミング（プラットフォー
ム）の間のギャップを埋める作業を、モデルとモデル変換を中心に行
うこと」とも言えそうです

6. UML に基づくモデル駆動開発
 多くの人にOMG のMDA はこれと思われている方式
 厳密なUMLモデルを作成する
 実際に使われるのは、クラス図、コンポーネント図、ステート
マシン図、アクティビティ図、配備図など
 MDA: CIM*<->PIM*<->PSM*<->Text (Code)
 モデル表現：UML
 モデル変換：MOF QVTなどを利用
 コード生成：MOFM2Tなどを利用
 現実的にはCIM/PIM/PSMのどれかを作成しそこからダイレクト
にコード生成する例が多く見られ、MDAのモデル（M2M）変換
がそれほど活用されているようには思えない
 構造を表現するモデルは扱い易いが、振る舞いを表現するモデ
ルの作成とその変換は難易度が高い

7. Eclipse でのモデル駆動開発
 Eclipseは最初からEMF(Eclipse Modeling Framework)を含んだ
オープンソースプロジェクト（www.eclipse.org）
 EMFのEcore はOMG のMOF仕様に含まれるサブセット仕様で
あるEssential MOF に基づく標準形式（と実装）
 Eclipse Modeling Project でのEcore モデル
 作成：専用ダイアグラムエディタ（Ecore Tools）、専用テキスト型エ
ディタ（Xtext, Xcore, etc.）、専用木構造エディタ等を利用
 利用：EMF コード生成機能利用コンポーネンツ、UML エディタ
（Papyrus etc.）、DSL エディタ（GMF, Sirius, Xtext, EuGENia etc.）
 特徴：Ecoreモデル図はUML クラス図のサブセット相当であり、クラ
ス図との比較で出来ること出来ないことを理解しておく必要がありま
す（例：関連クラス、多項関係、ステレオタイプなど記述出来ない）

8. モデル駆動について
 必要最低限の仕様をモデルとして記述すれば、モデル変換の
ツールチェーンを利用しプラットフォームに到達できる（は
ず）：「言うは易し行うは難し」の典型
 UML で書いてもEcore で書いても、モデルはXMI 文書となり、それがモデ
ル変換の入力になるため、それ程大きな違いはない
 気になる点
 十分に厳密なモデルをある抽象化レベルで記述する必要がありますが、こ
れが容易なことではありません
 CIM->CIM/PIM, PIM->PIM/PSM, PSM->PSMといったM2M変換：コードと距離
のあるこれら中間生成物の生成作業に理解を得ることは時として困難です
 進化し続けるプラットフォームは、M2T変換にインパクトを与えます（好
ましい進化もありますが）
 完成後の維持管理フェーズでのモデル駆動の役割が明確になっていません
 非機能要件の取り扱い：必ず非機能要件のモデルを用意する必要があるの
でしょうか？

9. モデル駆動開発の具体例
 具体例に基づき検討することにします（まだ開発途中の
もので現状ベースの報告です）
 モデル：Xtextのサンプルの一つであるXbase 版
DomainModel（UML Class 図のサブセット相当）を使います
 モデル変換：プラットフォーム対応に直接コード変換する
ことにします
 プラットフォーム：Spring Bootを使います（実体はSpring
MVC）つまりWeb アプリケーションを目指します
 開発作業
 ツール開発者の作業はXtext 環境でのモデル変換ロジック実装
で、これがどんな内容を含むのかを例示します

10. www.eclipse.org/Xtext sample code より
Domainmodel 定義

11. Domainmodel の具体例
Company
Person
Manager
*

12. モデル駆動開発の具体例
 モデル変換実装として最低でも次のようなものがあります
 Entity に対応するデフォルトJavaコードを生成します
 DomainClass（属性、関連、操作（Xtend言語））
 DomainClassRepository（CRUD 操作）
 DomainController（画面制御）
 各種import文やアノテーションも生成します
 生成物をSpring のProject 構造に合わせ配置する仕組みを用意します
 その他：データベース関連
 通常は生成が必要なものですが、今回はプラットフォーム側に任せます
 Entity に対応するデフォルトGUI 定義（html 等）を生成します
 インデックス、一覧、新規、編集、削除、検索
 その他
 Eclipse/Xtext の提供する枠組みを基盤として利用します
 それ以外はSTSを使ったSpring Bootプロジェクト生成を利用します

13. モデル駆動開発の具体例
 実行時
 EclipseベースのSTS (Spring Tool Suite) に作成したプラグイ
ンを導入します（dropins フォルダに入れます）
 Spring Starter プロジェクトを作成します
 Web + JPA とします
 application.properties はテスト用設定をコピーします
 プロジェクト直下にmodel フォルダを作成しそこにドメイ
ンモデルを作成します
 利用者の作業は、テキスト型モデルエディタでモデル記述を行
い“save” します：この“save” がトリガーとなりコード生成が
行われます
 Boot アプリケーションとして実行します（基本的な動作が
出来れば良しとします）

14. こんな感じになります
入力モデル
GUI 系生成物
ドメインクラス
CRUD
プラットフォーム（Spring）のプロジェクト構造念のため：まだ作業途中のものです
にあわせた生成物の配置

15. トライアルから言えること
 文法が汎用的（クラス図メタモデル相当）であるため
 このようなトライアル実装は利用範囲が広い
 ただプラットフォーム対応はその都度実施する必要がある
 今回はXtend がターゲットとするJava プラットフォームであった
ため比較的少ない開発数で済んだが、、、
 モデル変換に書くコード量（想定< 500 lines）
 文法（メタモデル）の複雑さに依存
 プラットフォーム（マッピング）の複雑さに依存
 今回作業しなかった箇所
 データベース関連コード
 共通要素であり一度作成すれば再利用は可能？
 ビジネスロジック
 Xtend 言語で記述する操作を除く

16. トライアルから見える課題
 モデリング
 現在の文法で表現していないcontainment 関係を表現できるよう改訂が必要
 画面フローは単純なパターンを想定したが、複雑なケースに対応するにはステートマシンの文
法と組み合わせる改訂が必要（モデルの統合）更にGUI モデリングの検討も必要
 現在はローカル環境での作業となるが、チーム環境での作業を可能とする仕組みも必要
 ビジネスモデリング（プロセス、ルール等）との連携方法について検討が必要
 プラットフォーム及びモデル変換
 再利用できるデータベース関連変換コードの整備
 現在はJavaプラットフォームを想定しているが、JavaScript やWeb API を検討する時期にあ
る
 コード生成というアプローチ
 コード生成ロジックが複雑になるとそれが開発時のネックとなる可能性があり、出来るだけ
「手書きコード」を減らす仕組み（例：モデル変換コードライブラリなど）やコラボレーショ
ン環境との連携について検討が必要
 プラットフォーム機能をモデル変換の中で記述するという方式で、プラットフォームの進化に
十分追随出来るか、他に方法はないか、検討が必要

17. GUI モデリング
 Interactive Flow Modeling Language (OMG specification)
 http://modeling-languages.com/open-source-ifml-editor-eclipse-
github/

18. 最後に
 オープンソースの世界でも、ちょっとしたモデル駆動開発の仕
組みが出来るのではないかと考え、ここ２〜３週間トライして
いるプロジェクトであり、深さに欠ける点お詫びします
 トライアルではWeb アプリケーションを対象としましたが、
特性の異なるプラットフォームを使う別の領域では、モデリン
グとモデル変換の両方で個別の仕組みが必要になると思います
（例：フィードバック機構が入るようなプラットフォーム）
 東京近辺におられる皆様へ
 非定期ですが、東京でEclipse Modeling Project の勉強会など
を開催しています。もし宜しければご参加ください。
 https://sites.google.com/site/eclipsemodelingsigjapan/
 これまで扱った話題；MDA, EMF, Acceleo, GMF, EuGENia, Xtext,
QVTo, QVTd, ATL, BonitaBPM, Xcore, OCL(in Ecore/Papyrus)

19. ご清聴どうも有り難うございました