今月の22日にとある名古屋の学際的な集まりで、マインドマップモデリングやモデル駆動開発についてお話させていただくことになりました。タイトルは「文書をプログラムにする技術」となりました。このセッションのネタ整理を「Object-Functional Analysis and Design: 次世代モデリングパラダイムへの道標」や「クラウド温泉3.0@小樽」といった感じで、ブログの上で行なっていっています。
ここまで以下の順にマインドマップモデリングの基盤技術について説明してきました。
- MindmapModelingと集合知 :: セッションについて
- ユビキタス言語 :: オブジェクト指向モデルとユビキタス言語
- 日本語とモデルとプログラム :: ユビキタス言語で日本語とモデルとプログラムをつなぐ
- 関係 :: マインドマップモデリングで使用する「関係(relationship)」
- SVOで考える :: SVOとイベントの導入
- メタモデル :: マインドマップモデリングの土台となるメタモデル
- クラウド拡張 :: メタモデルのクラウド・アプリケーション向け拡張
- マインドマップモデリングの例 :: マインドマップを使ったユビキタス言語の実例
日本語とモデルとプログラムをつなぐハブとしてユビキタス言語が極めて重要になります。
ここで問題となるのはマインドマップを使ったモデルの表現力、記述力です。マインドマップはブレインストーミングや教育目的では極めて有効なのですが、ある程度の大きさと精密さを持ったモデルの記述力には難があります。
当初は精密なモデルの記述には(SimpleModeler専用の)Scala DSLを用いていたのですが、こちらは日本語情報による「柔らかいモデル」の記述に難があることが分かってきました。
そこで新たなDSLとして開発中なのが、浅海が開発している文書処理システムSmartDoxを使用したSmartDox DSLです。
SmartDox DSL
SmartDoxはEmacsのorg-modeをベースにした文書処理システムです。(1月10日の記事参照)
本ブログも今年に入ってからSmartDoxを使って書いていますが、非常に便利に使えています。
SmartDoxの美点の一つはorg-modeをベースにしているので、Emacsのorg-modeで編集できることです。org-modeはアウトラインプロセッサであると同時に、極めて強力な表組み記述機能を持っています。
ここで、ユビキタス言語を記述するための言語について改めて考えてみると:
- 日本語を自然に記述することができる
- アウトラインで全体構造を表現できる
- 表で詳細情報を表現できる
という要因が重要になりますが、SmartDox(org-mode)は以上のすべての要因を満たしています。
そこで、このSmartDoxを使ったSimpleModeler用のDSLを開発してみたものがSmartDox DSLです。
SmartDox DSLの例
SmartDox DSLの例を以下に示します。
- #+title: Table
- SmartDox DSLを使って記述したモデルの
- サンプル文書です。
- 文書でサンプルモデルの定義をします。
- 本来は文書中の仕様記述の文書は
- 定義するモデルに対するものになります。
- しかし、この文書ではSmartDox DSLの記述例として
- SmartDox DSL文法の説明を記述することにします。
- * サンプル文書の目的
- このサンプル文書は表を中心にしてクラス定義するサンプルです。
- 登場人物、道具、出来事の各エンティティの種別の下に
- 顧客、商品、購入といった具象エンティティを節として
- 定義します。
- そして、それらの節の下に属性一覧または特性一覧として
- エンティティの属性や関連を記述していきます。
- * 登場人物
- ** 顧客
- IDの指定はありませんが、以下のルールで推測しています。
- - 陽にID指定がない場合、先頭の属性の属性名が「id」(大文字可)で終わる場合はIDとみなす。
- #+caption: 属性一覧
- | 名前 | 型 | カラム | SQL型 |
- |--------+--------+---------+--------------|
- | 顧客ID | token | ID | CHAR(16) |
- | 名前 | token | NAME | VARCHAR(64) |
- | 住所 | string | ADDRESS | VARCHAR(256) |
- * 道具
- ** 商品
- IDは、ID欄で指定しています。
- #+caption: 属性一覧
- | 名前 | 型 | ID | カラム | SQL型 |
- |--------+-------+----+--------+-------------|
- | 商品ID | token | ○ | ID | CHAR(16) |
- | 名前 | token | | NAME | VARCHAR(32) |
- | 定価 | money | | PRICE | LONG |
- * 出来事
- ** 購入
- IDは、特性欄で指定しています。
- #+caption: 特性一覧
- | 特性 | 名前 | 型 | 多重度 | 派生 | カラム | SQL型 |
- |------+--------+-------+--------+-------------+-------------+----------|
- | ID | 購入ID | token | | | ID | CHAR(16) |
- | 属性 | 日付 | date | | | DATE | DATE |
- | 関連 | 顧客 | 顧客 | 1 | | CUSTOMER_ID | CHAR(16) |
- | 属性 | 顧客名 | token | | 顧客.名前 | | |
- | 関連 | 商品 | 商品 | 1 | | GOOD_ID | CHAR(16) |
- | 属性 | 数量 | int | | | AMOUNT | INT |
- | 属性 | 商品名 | token | | 商品.名前 | | |
- | 属性 | 単価 | money | | 商品.定価 | | |
- | 属性 | 総額 | money | | 数量 * 単価 | | |
ポイントとなるのは、仕様書のアウトラインや文章、表の中からモデルとして記述された部分を抽出し、このモデルから各種成果物を生成する点です。
マインドマップモデルよりモデルの記述力ははるかに高くなります。
また、Scala DSLと比較しても、モデルの記述力は同等ととしても、日本語の文章の記述力はるかに高くになります。
特に日本語による文章については、リストや表、プログラム例、画像といったものを自由に記述することができるので、汎用の仕様書としての役割を十分に果たすことができます。
クラス図
上記のDSLからSimpleModelerを使って以下のクラス図を生成することができます。
開発中なのでまだ試せていませんが、各種プログラムの自動生成もできる予定です。
投稿
0 件のコメント:
コメントを投稿