モデル駆動開発勉強会#2 SimpleModler 浅海智晴さん

遅くなりましたが、１１月３０日（日）に開催されたモデル駆動開発勉強会#2のまとめ第２弾です。

第２部は、浅海智晴さんがご自身で開発されている「Simple Modeler」について発表してくださいました。

資料はこちら↓↓↓

http://www.beproud.jp/doc/simplemodeler_asami.pdf

システムのライフサイクルを長くするには、要件定義から実装まで、一貫した思想で見通し、バランスの良いアーキテクチャで開発することが求められます。バランスの悪いアーキテクチャで開発してしまうと、リリース後は、バランスの悪い部分を補うことに力を多くそそぐはめになります。

浅海さんの話を聞いていて、システムを構築するエンジニアは、Simple Modelingのような開発プロセス全体にまたがった体系だった開発理論を学び、各フェーズ間のマッピング感覚・センスを身につける必要があると実感しました。SimpleModelerは、そのSimpleModelingをモデル駆動開発で実践するために実装されたものです。浅海さんの考え抜かれた理論が凝縮された実装なので、これからも要注目です。

以下がまとめです。

■SimpleModeler
　〜Scala DSLによるモデルコンパイラ
　シンプルモデリングを実装(Scala DSL)
　
■テーマ
　・プログラマのためのモデリング
　→モデリング手法とモデル駆動開発
　・モデリング手法
　→SimpleModeling
　・モデル駆動開発
　→SimpleModeler

日本語自然言語→マインドマップモデル（準備モデル）→ドメインモデル

■開発プログラム
　・SmartDoc
　・Relaxer
　・SmartCase(試作）
　・JavaDSL(試作）

■時代の空気-プログラマの実感
　開発はアジャイル開発に向かっていく
・アジャイル
→プログラム駆動、テスト駆動、振舞駆動、不必要な仕様書は作りたくない
・軽量言語
→スクリプト言語、動的言語、テキスト指向、Web指向

■プログラミング言語
・サービスのマッシュアップ
→軽量、テキスト指向、Web指向
・フレームワーク、サービス、コンポーネントの開発
　→静的型付け、クラスライブラリ、標準API、ミドルウェア、分散、並行／並列、非同期、Java,C#、Scala
　　
■クラウド時代のソフトウェア開発
　システムの運用・保守がクラウドに飲み込まれる
　　特殊なものがだけが残る
　コンポーネント開発が本格化
　プログラムの実力で差がでることはなく、モデリングで差が出るのが大きな流れではないか
　→プロセスを再構築して体系化する必要がある
　
■モデル駆動開発＆コンポーネント
　DSL→自動生成→軽量言語でコンポーネントを組み上げる（マッシュアップ）
　UI系も軽量言語
　
■開発の流れ
　アーキテクチャベースラインをつくる仕事が日本に残る
　プログラマでありモデラーである人が仕事をする
　
■モデグラム
　モデル＆プログラム（浅海さんの造語）
　　→アジャイル開発
　・UMLでプログラミングするのは実用的ではない
　・オブジェクトモデルをテキストベースのDSLで記述する
　・キーボードから手を離した瞬間に効率が落ちる　
・設計図テキストベースのDSL
・施工図（最後につくる）→UML　
　　　レビュー用など
　
Simple Modeling
http://simplemodeling.jp
SimpleModeler
http://code.google.com/p/simplemodeler/

■SimpleModelingのテーマ
・クラウド時代のモデリング手法
　問題空間重視
　コラボレーション重視
　CBD
・モデル駆動開発
　　具体的なプロファイル
　　DSL
　　業務に近いところのモデルが重要

○ビジネスモデリング
企業システムモデリングの３階層構造
1. ビジネス戦略（問題空間、解決空間）
2. ビジネスシステム（問題空間、解決空間）
3. サービスシステム（問題空間、解決空間）

SimpleModelの対象
2.ビジネスシステムと3.サービスシステム

■SimpleModelerとは
　SimpleModelのモデル・コンパイラ
　 Scalaをメタ言語としたDSL
　
■構成
　・Golenport（アプリケーション・フレームワーク）
　Java 生成器　Relaxer Framework
　scala は皆が使いこなすには難しい
　アーキテクチャベースラインをつくる人など一部の人向け

■Goldenport
　文書記述機能としてSmartDocを基本機能として提供
　・各種コンポーネントを組み立ててアプリケーションを構築する
　　・Service　利用者に価値をもたらす機能
　　・Entity　操作対象のオブジェクト
　　・Importer　外部世界の移入
　　・Exporter 外部世界の移出

■SimpleModelerDescriptor
Scalaのプログラムで定義。IDEがコンパイラでエラーをはじいてくれる
XMLはエラーがわからない

■SimpleModlerで実現したいこと
・SimpleModelingの運用基盤として
・テキストによるモデル記述
・プログラム自動生成
・ドメイン・モデルを中心として
・テキスト・エディタ＋オープンソースで手軽に
・納品物にできるソースコード品質
・仕様書の自動生成
・モデル検証
　→これも大事。用語集と整合性があるか。

■メタ・モデル
・業務モデル
　業務ビジョンモデル、業務プロセスモデル、業務ユースケースモデル、業務タスクモデル
・ドメインモデル
　エンティティモデル、サービスモデル、ルールモデル
・要求モデル
　ビジョンモデル、ユースケースモデル

■ドメインモデルでやりたいこと
・ドメイン・モデルのScala DSL表現
・プログラムの自動生成
・９９％自動生成できると思う
・自動生成後の拡張手法
　　GenerationGapパターンなど
　　Relaxerの実装経験
　　
■ユースケースでやりたいこと
・ユースケースフローのScal DSL表現方法
・業務モデル、ドメインモデル、要求モデル、システムモデルの連携
　　ドメインモデルとユースケースモデルの整合性があるか大事→UMLだと整合性がわからない
・フローのステップやパスの自動採番
・ビューの変更
・モデル検証

■DSL駆動開発の論点
・自動生成できる範囲を明確にする
・適用対象を絞り込む
・開発プロセスを定義する
・主力の記述言語にUMLを使用しない
・主力の記述言語にグラフィカル言語を使用しない
・メタモデルの定義にMOFを使用しない
・記述言語はツールからの操作性を重視する
　用語集をツールで同期をとれるようにしておく
・自然言語情報を定型的に取り扱える

■DSL実現の選択肢
　・UML
　グラフィカル言語は編集が頻雑
　帳票形式の情報をうまく扱えない
　生産性が悪い（キーボードから手を離した瞬間に生産性は落ちる）
　・Excel
　　→ゼミでやったが挫折した
　・マインドマップ
　・動的型付け言語
　　コンパイルエラーによるエラー検出の範囲が小さい
　　IDEによる入力補完の制度が低い
　・Java
　・Scala

アクター、イベント、リソースなどをベースにしてる理論
　→DOAや、REA

■SimpleModelerのメタモデル
○ドメインオブジェクト
・エンティティ
アクター、リソース、イベント、ロール、サマリ
・バリュー
・データタイプ
・パワータイプ
・ドキュメント
・サービス
・ルール

○リソースの種別
・種別
　在庫、講座、契約、チケット、カレンダー
・単位区分
単品、個数、量、範囲、通貨、日付、日時、日時コマ
・種別と単位区分の組み合わせで生成するプログラムを最適化する予定

○関係(relationship)
・属性
　　データ型、バリュー、ドキュメント
・関連(association)
SimpleModelingの関連は、クラスに従属させている
　・プログラミング言語との親和性
　・DSLでの記述性

・使用
SimpleModelerでは、メソッドやユースケースが使用しているオブジェクトを抽出して仕様として表示する

・参加（UMLでは非公式の概念）
　→影響範囲を調査するときに役に立つ

■データ型
・XML Datatypeをベースにした物をSimpleModelingで定義
・ユーザ拡張はせず、バリューで対応する

■まとめ
　SimpleModel→SimpleModeling→SimpleModeler
　
■その他
Q.自動生成したものはメンテナンスしにくいのでは
A.自動生成したものはメンテナンスしない

浅海さん、ありがとうございました！