MindmapModeling 2015

MindmapModelingの最新状況についてのご紹介です。

MindmapModelingはマインドマップを使ってモデリングを行う手法です。マインドマップを使って自由にモデルを書くというのではなく、UMLメタモデルによるモデルの表記方法としてマインドマップを用いるというアプローチです。

wakhok時代(2007年ごろ)に教育用として考案してモデリングの授業で使用していました。雑誌連載したものを書籍としてもまとめました。

• マインドマップではじめるモデリング講座

MingmapModelingの比較的最近の記事としては2012年のものがあります。

• MindmapModelingと集合知

その後、活動の中心がクラウドサービスプラットフォームの開発になったため情報発信は減りましたが、モデルコンパイラSimpleModelerなど他のモデリング技術と同時に開発技術として内部利用してきました。

クラウドアプリケーションとMindmapModeling

前述した通りMindmapModelingは元々教育用に開発したものですが、クラウドアプリケーション開発では実用技術として使えるのではないかと考えています。

モデリング技術全体に対するアプローチは以下で取り上げました。

• クラウドアプリケーション・モデリング考

クラウドサービスプラットフォームとScalaによるDSL指向Object-Functional Programming(OFP)のコンボによってアプリケーション開発におけるアプリケーションロジックのプログラミング量は劇的に減らすことができると考えています。

そうなると開発技術の焦点は以下の2つになります。

1. UIやその他の体験(リコメンドの精度など)を統合したUX(User eXperience)
2. ビジネスとのつなぎ込み

その中で(2)ビジネスとのつなぎ込みはまさにモデリング技術によって解決する分野ですが、ここにMindmapModelingがぴったりはまるのではないかと考えています。(1)のUXもUI的なチューニングではない、上記では「その他の体験」としている部分はアプリケーションが提供するフィーチャーそのものなので、機能要件あるいは非機能要件としてモデル化する必要があります。この目的でもMindmapModelingを使用することができます。

ビジネスとのつなぎ込み

MindmapModelingはビジネスとのつなぎ込みのモデルとして使用するため以下の2つの要件を満たすことを指向しています。

• ビジネスサイドのサービス企画担当者と開発担当者が共有して議論のベースとして使用できるモデル
• システム開発のオブジェクト(+関数)モデルにシームレスに連携できるモデル

MindmapModelingでは記述方式にマインドマップを使うことと、メタモデルを絞り込むことでこの要件を満たすこと意図しています。

従来的なシステム開発プロセスは以下のようなモデルの連携になります。

• ビジネス設計-システム要求-分析-設計-実装

MindmapModelingはこの中のビジネス設計の後半、システム要求、分析の前半ぐらいまでをざっくり(教育向けに)カバーすることを目的にしていました。

そして、クラウド時代になるわけですが、ここではクラウドサービスプラットフォーム＆Scalaの組合せにより、以下の形に持ち込めるのではないかという仮説を立てています。

• ビジネス設計-システム要求-実装

この中のビジネス設計の後半とシステム要求をMindmapModelingで行い、そのまま直接Scalaプログラミングにつなげてしまうというのが新しい方程式です。ベースとなるクラウドサービスプラットフォームが固定化されていることとScalaのDSL機能、この2つの技術を組み合わせることで分析と設計のアクティビティを省いてしまう(i.e. プログラマが暗算で行う)ことが可能ではないかというのが仮説の眼目です。実際にApparelCloudの開発はこの方針にそって行っています。

ビジネス設計

ビジネス設計の後半からシステム要求はMindmapModelingで行うとして、次に必要になるのは、一つ上流にあるビジネス設計(の前半)です。

ここでいうビジネス設計はビジネスの意図、ゴール、メカニズムをオブジェクト・モデル化したものを意図しています。(具体的にはEriksson-Penkerをベースにしたメタモデルをイメージしています。)

EverforthではApparelCloudのビジネス領域とプラットフォーム向けのメタモデルを開発中です。(来年中にはご紹介できると思います。)

また、より汎用的な用途のメタモデルとしては匠Methodも選択肢になります。

ビジネス設計の技法としてEverforth方式、匠Method、あるいはその他のメソッドを目的に合わせて選んでも、ビジネスサイドとエンジニアとの情報共有にはMindmapModelingを使用することで、開発側へのインパクトを最小限に抑えることができます。

MindmapModeling 2015

MaindmapModeling 2015年版です。

雛形

雛形の図は以下になります。

例

MaindmapModeling 2015年半の例としてECサイトをモデリングしてみました。

ざっくりとイメージはつかんでいただけると思います。

改良点

マインドマップはオリジナルから以下の点を改良しています。

• 設計向けにチューニング
• クラウド向けのモデル

設計向けにチューニング

wakhok時代(2008年ごろ)に考案したMindmapModelingはモデリングへの導入を意図していたので「登場人物」や「道具」といったメタファを使っていましたが実務で使う上では逆にオブジェクト・モデリングとの連続性が分かりづらいという問題がありました。

この問題に対応するために、枝の名前を「登場人物→Actor」というように英語の正式用語化しました。

また、要求、分析レイヤーのモデルを指向していたので設計時に必要なモデル要素は意図的に省いていました。用途に応じて設計向けのモデルも記述できるようにTraitやPowertypeといった枝を追加しています。

クラウド向けのモデル

MindmapModelingのメタモデルに以下のモデル要素を追加しました。

Dataflow

データフロー。

Summary

サマリーエンティティ。

Document

データ表現/転送用途の不変オブジェクト。

SummaryとDocumentは元々SimpleModelingにはメタモデルとして組み込んでいましたが、分析目的、教育目的にはモデルが複雑になりすぎるのでMindmapModelingには導入していなかったモデル要素です。

Dataflow

クラウドアプリケーションでは、CQRSアーキテクチャに見られる通り、バックエンドでの非同期大規模計算がシステムの基本機能になってきます。

この処理を記述するためのモデルとしてデータフローを用意しました。

MindmapModelingでは、厳密なデータフロー・モデルを記述することは目的としていません。

Summary

クラウドアプリケーションでは、問い合わせに必要なデータ集計等を事前計算しておいて専用のテーブルなどに格納しておくことが重要な処理になります。

ざっくりとは業務システムで使われているバッチ処理と考えてよいと思います。

この目的で使用するテーブルなどのデータストアを表現するためのエンティティとしてSummaryを導入しました。

前述のDataflowで作成した事前計算結果をSummaryに格納するという位置付けになります。

Document

Documentは伝票を記述するモデルです。以下の利用方法を想定しています。

• データをプログラム内で持ちまわる容れ物
• XML, JSONの形式で転送可能になっている
• 代数的データ型

Scalaではplay-jsonなどでJSONとの相互変換を担保したcase classで実装することを想定しています。

このレイヤーのモデルを分析段階でどこまで記述するのかは判断の別れるところですが、MidnmapModelingの方針として設計指向に寄せたので、その一環でメタモデルとして取り入れました。

このため、必要に応じて使用するという温度感のモデルになります。

設計への流れ

通常のモデルはMindmapModelingから直接Scalaプログラミングしても問題ありませんが、ある程度複雑なモデルの場合や新しく取り組む業務分野などの場合はメモ的に設計モデルをつくるのが効率的です。また外部連携が必要な処理では、きっちりとした仕様書が必要になります。

逆にいうとモデリング作業のすべてをMindmapModeling上で完結させることは目的としていません。基本はMindmapModeling上で行い、必要に応じてオブジェクト・モデリングやDOAなどの技法を適材適所で使う形を想定しています。

ロバストネス図

MindmapModelingで作成したモデルを実装に落とし込むための中間モデルとしてはロバストネス図が有力です。

前述のECサイトのモデル向けのロバストネス図の例を以下になります。

このロバストネス図をベースに、必要に応じてコンポーネント図やコミュニケーション図(コラボレーション図)を作成するとよいでしょう。

まとめ

MaindmapModelingの最新状況についてご紹介しました。

2008年ごろからクラウドアプリケーションの開発技法について考えてきましたが商用システムの開発を通して色々と部品建てが揃ってきたので、2016年は具体的な開発方法論として整備していければと思っています。

MindmapModeling「チャネルの多様化で難題と化す予算の最適配分」

12月15日(土)に横浜モデリング勉強会(facebook group)を行いました。また、会場には(株)アットウェア様の会議室をお借りしました。参加された皆さん、アットウェア様、どうもありがとうございました。

この勉強会で、浅海が作成したモデルを紹介します。モデルはMindmapModelingの手法で作成しました。(勉強会で使用したチュートリアル)

ワークショップの流れ

モデリング勉強会はワークショップ形式で以下の作業を行います。

• 雑誌記事から情報システムの企画書、提案書、RFPの元ネタとなるモデルを作成する。

その上で、「要求仕様確認、実装可能性確認、開発のベースとなるプログラムを自動生成するモデルを目指」します。詳細は「ワークショップの進め方 第2版」になります。

テーマ

モデリングの対象は、日経ビジネス誌の記事「チャネルの多様化で難題と化す予算の最適配分」です。

用語の収集と整理

まず用語の収集と整理します。

MindmapModelingに慣れてくると、用語がだいたいどこの枝に収まるのかわかるようになるので、用語を拾いながらラフなモデルを作っていきます。

今回の記事は、広告の効果を計測するメカニズム的なことが多く書かれていたので、このあたりを規則と登場人物を中心に分類しました。

クラス図

この段階でのマインドマップをSimpleModelerでクラス図化したものが以下になります。

いくつかモデルの島ができていますが、全体としてはまだばらばらです。

物語

次の作業は「物語」です。

モデルは中心軸がないと単なる「用語」の集りなのでまとまりがでてきません。何らかの目的を実現するための構造を抽出したいわけですが、この「目的」と「目的を実現するための構造」を掬いとるためのツールとして有効なのが「物語」です。オブジェクト・モデリングの概念ではビジネス・ユースケースということになります。

「物語」を中心軸と定め、「物語」のスコープで用語を取捨選択、組織化し、足りない用語を補っていきます。

その手順は:

1. 物語の名前をつける。目的(goal)が明確になる名前がよい。
2. 物語の主人公、相手役、脇役などの登場人物を定める。
3. 物語で使用する道具を定める。
4. 出来事または脚本の列として脚本を記述する。

となります。2の登場人物と3の道具は最初から完全なものはできないので暫定的なものを定め、4の脚本の作業を通して洗練させていきます。

「物語」として、「広告予算編成を最適化する」を設定し、この「物語」の作成を軸に、「出来事」の整理、「道具」の整理を進めました。

物語「広告予算編成を最適化する」は以下の出来事による脚本から構成されます。

• マーケッティング施策を実行する
• マーケッティング施策の結果を計測する
• マーケッティング施策の結果を分析する
• 予算配分する

さらに、各出来事を詳細化して、規則や道具を結びつけていきます。

今回の記事は内容がかなり絞りこまれていたので、モデリングの方向を問題領域の世界を記述するというよりシステム化を指向した詳細なモデルを記述するようにしてみました。

クラス図

この段階でのマインドマップをSimpleModelerでクラス図化したものが以下になります。

かなりクラス図らしくなってきました。ビジネス・ユースケース→イベント→アクター＋リソースの流れが分かりやすく可視化されています。

ここまでの作業で時間切れとなりました。

ちょっと洗練

時間内に作ったマインドマップモデル＋クラス図はSimpleModelerの機能不足もあって、出来事から規則に続く流れがクラス図上に表示できませんでした。

そこで、SimpleModelerに機能追加を行いながら、この点の記述の精度を上げたモデルが以下のものです。

クラス図

クラス図は以下になります。

SimpleModelingではアルゴリズムを記述するためのモデルとして、規則に加えてサービスを持っていますが、今回このサービスをマインドマップモデルでも使ってみました。

SimpleModelerで出来事から規則およびサービスへの関係は依存性(dependency)として記述しています。

ノート

オブジェクト・モデリングの鍵の一つは、静的構造を記述するドメイン・モデル(クラス図)と動的モデルをどのように関連付けていくのかという点です。

SimpleModelingでは、イベント(出来事)を起点にルールやサービスを呼び出すという点を軸の一つにしています。今回はよい機会なのでSimpleModelerにこのあたりの機能を追加してMindmapModelingからクラス図の生成の処理に盛りこんでみました。

具体的な記述方法、使い方は追々ブログで紹介していきたいと思います。

次回

次回はまだ確定していませんが1月19日(土)を予定しています。

詳細情報はfacebookグループ「横浜モデリング勉強会」を参照してください。

今回と同じく「ワークショップの進め方 第2版」の手順で、「雑誌記事から情報システムの企画書、提案書、RFPの元ネタとなるモデルを作成する」を行う予定です。

MindmapModeling/SimpleModeler - 状態機械

オブジェクト指向モデリングでは、状態機械(state machine)が動的モデルの核となるモデル要素です。

状態機械はネスト状態をサポートした本格的なものをScala DSLとして組み込み済みです。しかし、Mindmap DSLとSmartDox DSLで定義できるようにはなっていないので、文法の拡張を行ない定義可能にする予定です。

まず、最初のターゲットとしてScala DSLのフルスペックの状態機械ではなく、Javaの属性として変数領域を確保するための情報を定義する範囲でのDSL化を行なっています。

MindmapModeling

状態機械のために、MindmapModelingのトップクラスの枝であるBOI構造枝に「状態機械」を追加しました。各状態機械はこの枝の下に配置します。

以下のようにしてクラス図を生成することができます。

$ sm -diagram statemachine.xmind

このマインドマップから生成されるクラス図です。3つの状態「開始」、「実行中」、「終了」を持つ状態機械「進行」が定義されています。

SmartDox DSL

上のMindmapModeling文法に対応するSmartDox DSLは以下になります。

#+title: 状態機械/StateMachine

* StateMachine

** 進行

#+caption: 状態
| name   |
|--------|
| 開始   |
| 実行中 |
| 終了   |

このDSLから以下のようにしてクラス図を生成することができます。

$ sm -diagram statemachine.org

生成されるクラス図は以下になります。

ノート

状態機械内の状態遷移を記述するSmartDox DSLおよびMindmapModelingの文法は現在検討中です。

最終的には、この状態機械モデルからJavaやScalaプログラムの生成まで行う予定です。

諸元

SimpleModeler Version 0.4.0-RC5-SNAPSHOT (20121126)

SimpleModeler 0.4.0-RC4から少し手を入れたバージョンなので、0.4.0-RC4とは出力されるクラス図が若干異なります。

MindmapModeling/SimpleModeler - 関連クラス

SimpleModelerで扱うメタモデルを設計する上での懸案事項の一つが多対多の関連と関連クラス(association class)の扱いです。

SimpleModeling/MindmapModelingのオブジェクト・モデルの中で多対多の関連や関連クラスをどう扱い、JavaやRDBMSにどうマッピングしていくのかという点は、テキストDSLでの効率的な記述方法の問題と相まって、あまり良い解を思いつきませんでした。

また、多対多の関連や関連クラスはリソースエンティティや普通のエンティティで代替するのが可能なことと、多対多の関連が出てくるところはモデリングを進めると属性を持った普通のクラスに伸びていくことが多いので、それほど強いニーズを感じていなかったということもあります。

ただ、以下の2つのニーズがあることがわかったので関連クラスをサポートすることにしました。

• 既存のRDBMSのテーブルを扱う場合に、関連クラスを使えると便利
• オブジェクト側に変更を加えず、ユースケースのニーズに応じて関連を追加できる方法があると便利

多対多の関連は、今のところ直接DSLで記述できるようにする予定はありませんが、関連クラスを使って実現することが可能です。

MindmapModeling

関連クラスは、MindmapModelingのトップクラスの枝であるBOI構造枝に「関連」を追加し、この下に配置します。

以下のようにしてクラス図を生成することができます。

$ sm -diagram associationClass.xmind

このマインドマップから生成されるクラス図です。トレイト・クラスが一つ定義されています。

SmartDox DSL

上のMindmapModeling文法に対応するSmartDox DSLは以下になります。

#+title: 関連クラス/Association Class

* 道具

** ブログ

** タグ

* 関連

** ブログタグ対応

#+caption: 関連
| 名前   | 型     | 多重度 |
|--------+--------+--------|
| ブログ | ブログ | *      |
| タグ   | タグ   | *      |

一点だけ、データ型を指定しているところが異なります。

このDSLから以下のようにしてクラス図を生成することができます。

$ sm -diagram associationClass.org

このマインドマップから生成されるクラス図です。トレイト・クラスが一つ定義されています。

この場合はデータ型をDSLで指定しているので、その指定もクラス図に反映されています。

諸元

SimpleModeler Version 0.4.0-RC5-SNAPSHOT (20121129)

SimpleModeler 0.4.0-RC4から少し手を入れたバージョンなので、0.4.0-RC4とは出力されるクラス図が若干異なります。

MindmapModeling/SimpleModeler - トレイトの使用方法

昨日「MindmapModeling/SimpleModeler - トレイト」のトレイトを実際に使う場合の文法について説明します。

MindmapModelingの使い方は以下になります。

このモデルでは「特色」(トレイト)として以下のものを定義しています。

• タグ付け可能
• 画像貼付け可能

そして、この2つのトレイトをミックスインした道具(resouce entity)「ブログ記事」を定義しています。「ブログ記事」の構造枝「特色」の下に2つの特色「タグ付け可能」と「画像貼付け可能」を配置しています。このことによって「ブログ記事」に「タグ付け可能」と「画像貼付け可能」がミックスインされます。

このマインドマップモデルから以下のようにしてクラス図を生成することができます。

$ sm -diagram trait.xmind

生成されたクラス図は以下になります。2つのトレイト「タグ付け可能」と「画像貼付け可能」が定義されており、リソース「ブログ記事」がこの2つのトレイトをミックスインしています。

Java

SimpleModelerでは「トレイト・モデリング」で説明したモデリングのトレイトのJavaマッピングをサポートしています。

先ほどのMindmapModelingのモデルから以下のようにしてJavaプログラムを生成します。

$ sm -java trait.xmind

Javaにはトレイトがないので、インタフェースとして生成されます。トレイト「タグ付け可能」に対応するインタフェース(の先頭部分)は以下のものになります。

public interface タグ付け可能 {
    public static final String PROPERTY_タグ = "タグ";
    public String getタグ();
    public void setタグ(String タグ);
}

リソース「ブログ記事」に対応するJavaクラス「ブログ記事」(の先頭部分)は以下のものになります。

@Entity
public class ブログ記事 implements タグ付け可能, 画像貼付け可能 {
    public static final String PROPERTY_ID = "id";
    @Id
    @GeneratedValue(strategy=GenerationType.AUTO)
    private Long id;
    @Basic(fetch=FetchType.EAGER)
    @Column(nullable=false)
    protected String タグ;
    @Basic(fetch=FetchType.EAGER)
    @Column(nullable=false)
    protected String リンク;

トレイトの実装部がクラスの中に埋め込まれるのと同時に、インタフェース「タグ付け可能」と「画像貼付け可能」がインプリメントされています。このことによって、事実上トレイトをミックスインしたクラスとして使用することができるわけです。

SmartDox DSL

上のMindmapModeling文法に対応するSmartDox DSLは以下になります。一点だけ、データ型を指定しているところが異なります。

#+title: 特色/Trait

* 特色

** タグ付け可能

#+caption: 属性
| name | type  |
|------+-------|
| タグ | token |

** 画像貼付け可能

#+caption: 属性
| name   | type |
|--------+------|
| リンク | link |

* 道具

** ブログ記事

#+caption: 性質一覧
| 項目 | 値                          |
|------+-----------------------------|
| 特色 | タグ付け可能,画像貼付け可能 |

#+caption: 属性
| name     | type   |
|----------+--------|
| タイトル | string |
| 内容     | text   |

このDSLから以下のようにしてクラス図を生成することができます。

$ sm -diagram trait.org

このSmartDox DSLから生成されるクラス図は以下になります。

諸元

• SimpleModeler Version 0.4.0-RC5-SNAPSHOT (20121127)

SimpleModeler 0.4.0-RC4から少し手を入れたバージョンなので、0.4.0-RC4とは出力されるクラス図が若干異なります。

MindmapModeling/SimpleModeler - トレイト

「トレイト・モデリング」でも取り上げたトレイトは、プログラミングのみならずモデリングでも非常に有効です。
このトレイトをSimpleModelerに組み込んでみました。
これに関連して、MindmapModelingではあまり使う機会はありませんが一応文法としても定義しています。トレイト(trait)はマインドマップ的には「特色」という用語を当てています。

以下のようにしてクラス図を生成することができます。

$ sm -diagram trait.xmind

このマインドマップから生成されるクラス図です。トレイト・クラスが一つ定義されています。

SmartDox DSL

上のMindmapModeling文法に対応するSmartDox DSLは以下になります。

#+title: 特色/Trait

* Trait

** タグ付け可能

#+caption: 属性
| name | type  |
|------+-------|
| タグ | token |

一点だけ、データ型を指定しているところが異なります。
このDSLから以下のようにしてクラス図を生成することができます。

$ sm -diagram trait.org

このマインドマップから生成されるクラス図です。トレイト・クラスが一つ定義されています。

この場合はデータ型をDSLで指定しているので、その指定もクラス図に反映されています。

諸元

SimpleModeler Version 0.4.0-RC5-SNAPSHOT (20121126)
SimpleModeler 0.4.0-RC4から少し手を入れたバージョンなので、0.4.0-RC4とは出力されるクラス図が若干異なります。

MindmapModeling/SimpleModeler - 要約の文法

「MindmapModeling/SimpleModeler - 要約」で導入した「要約(summary)」のMindmapModelingの文法は以下になります。

以下のようにしてクラス図を生成することができます。

$ sm -diagram summary.xmind

このマインドマップから生成されるクラス図です。要約クラスが一つ定義されています。

SmartDox DSL

上のMindmapModeling文法に対応するSmartDox DSLは以下になります。

#+title: 要約/Summary

* Summary

** ランキング

#+caption: 属性
| name | type  |
|------+-------|
| 名前 | token |
| 得点 | int   |

一点だけ、データ型をしているところが異なります。
このDSLから以下のようにしてクラス図を生成することができます。

$ sm -diagram summary.org

このマインドマップから生成されるクラス図です。要約クラスが一つ定義されています。

この場合はデータ型をDSLで指定しているので、その指定もクラス図に反映されています。

諸元

SimpleModeler Version 0.4.0-RC5-SNAPSHOT (20121126)
SimpleModeler 0.4.0-RC4から少し手を入れたバージョンなので、0.4.0-RC4とは出力されるクラス図が若干異なります。

MindmapModeling/SimpleModeler - 要約

「MindmapModeling「1回のメール配信で売り上げ数千万アップの驚異」」で、MindmapModelingの文法を拡張中であることを説明しました。正確にはSimpleModelingのメタモデルの拡張を行い、MindmapModelingの文法への反映と、SimpleModelerでの実装を行いました。

その文法拡張の一つが「要約(summary)」です。

summaryテーブルという考え方自体は昔からデータモデリングで使われていますし、「上流工程UMLモデリング」でもモデル要素としてはあげていました。これを第一級のモデル要素としてMindmapModelingやSimpleModelerで意識して扱うのが妥当かどうかという点が長年の懸案事項でした。

「要約」はクラウド・アプリで必須、という結論を出したのが昨年末になりますが、やっと実装することができました。

関連する記事:

• 要約エンティティ
• メタモデル

とはいえ、今回はMindmapModelingに「要約」のBOI構造枝を追加したのと、SimpleModelerで扱えるようにするところまでです。

「要約」のあるところデータフローあり。「要約」データは、オンラインからのSQLの問合せでは実用的な応答速度を出せないような大規模演算が後ろに控えているのが普通です。この実装はバッチ処理になります。このバッチ処理の設計と実装にはデータフローが有効です。

データフローの記述方法をどうするのかというのが、これまた懸案事項だったのですが、この基本的なアイデアを思いついたのが、今回MindmapModeling/SimpleModelerに「要約」を入れることにした直接の動機になっています。

こちらは実装にもう少し時間がかかりそうですが、ある程度形が見えてきたらブログで紹介したいと思います。

MindmapModeling「1回のメール配信で売り上げ数千万アップの驚異」

11月17日(土)に横浜モデリング勉強会(facebook group)を行いました。また、会場には(株)アットウェア様の会議室をお借りしました。参加された皆さん、アットウェア様、どうもありがとうございました。

この勉強会で、浅海が作成したモデルを紹介します。モデルはMindmapModelingの手法で作成しました。(勉強会で使用したチュートリアル)

ワークショップの流れ

モデリング勉強会はワークショップ形式で以下の作業を行います。

• 雑誌記事から情報システムの企画書、提案書、RFPの元ネタとなるモデルを作成する。

その上で、「要求仕様確認、実装可能性確認、開発のベースとなるプログラムを自動生成するモデルを目指」します。詳細は「ワークショップの進め方 第2版」になります。

テーマ

モデリングの対象は、日経ビジネス誌の記事「1回のメール配信で売り上げ数千万アップの驚異 - 良品計画のWebサイト『MUJI.net』の秘密を聞く（前編）」です。タイトルがキャッチーでよいですね。メールによるO2Oも旬のネタといえます。

用語の収集と整理

まず用語の収集と整理します。

MindmapModelingに慣れてくると、用語がだいたいどこの枝に収まるのかわかるようになるので、用語を拾いながらラフなモデルを作っていきます。

今回の記事は、色々な規則的やノウハウ的なことが多く書かれていたので、これらの記述は「規則」に分類しました。

登場人物の「顧客」は常識的な線でモデル化します。

ポイントとなりそうなのが出来事です。メールを使ったクーポンの発行がこのモデルの軸になりそうです。

クラス図

この段階でのマインドマップをSimpleModelerでクラス図化したものが以下になります。

顧客の島とイベントの島ができていますが、全体としてはまだばらばらです。

物語

次の作業は「物語」です。

モデルは中心軸がないと単なる「用語」の集りなのでまとまりがでてきません。何らかの目的を実現するための構造を抽出したいわけですが、この「目的」と「目的を実現するための構造」を掬いとるためのツールとして有効なのが「物語」です。オブジェクト・モデリングの概念ではビジネス・ユースケースということになります。

「物語」を中心軸と定め、「物語」のスコープで用語を取捨選択、組織化し、足りない用語を補っていきます。

その手順は:

1. 物語の名前をつける。目的(goal)が明確になる名前がよい。
2. 物語の主人公、相手役、脇役などの登場人物を定める。
3. 物語で使用する道具を定める。
4. 出来事または脚本の列として脚本を記述する。

となります。2の登場人物と3の道具は最初から完全なものはできないので暫定的なものを定め、4の脚本の作業を通して洗練させていきます。

「物語」として、「メールの店舗売上効果を測定する」を設定し、この「物語」の作成を軸に、「出来事」の整理、「道具」の整理を進めました。

出来事はあくまでもイベントの記述に特化して、クーポンは道具の方に分離しました。

また、今回新しいBOI構造枝として「要約」を追加しました。これは、「MindmapModelingと集合知(7) - クラウド拡張」などでクラウド・アプリ向けのメタモデルの拡張を説明してきましたが、この中の「サマリー」に相当するものです。

出来事の発生によって道具の状態が遷移していくのが、モデルの基本的な振舞いですが、「メールの店舗売上効果を測定する」という形で測定を行う必要があるので、測定対象のエンティティが必要になります。この測定対処のエンティティとして「要約」を用意しました。要約はバッチ処理で一定期間内のイベントの発生結果を集約する処理に用います。

クラス図

この段階でのマインドマップをSimpleModelerでクラス図化したものが以下になります。

だいぶまとまってきた感じです。クラス図を見ると、ユースケースから各種イベントをへて顧客に至る関係は確保できたことが分かります。その一方で、クーポンとイベントの関係がまだ設定できていません。

このあたりの関係はクラス図にしてみるとよく分かりますね。

一点、ビジネス・ユースケース「メールの店舗売上効果を計測する」からビジネス・タスク「BTメールの店舗売上効果を計測する」への呼出しをinclude依存性で記述する図になっています。ビジネス・タスク「BTメールの店舗売上効果を計測する」は内部的に自動生成したものですが、こういった図の場合は冗長なので自動生成させないようにしたいと思います。

ちょっと洗練

上の「物語」の作業からあまり時間が取れなかったので、道具にあるクーポン周りをブラッシュアップしました。

クラス図

クラス図は以下になります。

ここまでの作業で時間切れとなりました。

上のモデルから引き続いて出来事と道具の間の関係が設定できていない状態です。また、「メールの店舗売上効果を計測する」の要となる、RFM(Recerency, Frequency, Monetary)を計測対象とした計測の振舞いをクラス図の上で表現するところまで持っていけませんでした。

やるべき事はだいたい見えてきた感じです。作業を続けるとすると、まずは上記2つのポイントを埋めていくことになります。

ノート

今回のモデリングでは「要約」の他にいくつか機能拡張を行いました。機能拡張についてはSimpleModelerでの使い方を含めて別途説明したいと思います。

次回

次回は12月15日(土)です。

詳細情報はfacebookグループ「横浜モデリング勉強会」を参照してください。

今回と同じく「ワークショップの進め方 第2版」の手順で、「雑誌記事から情報システムの企画書、提案書、RFPの元ネタとなるモデルを作成する」を行う予定です。

「MindmapModelingと集合知」まとめ

ちょっと間があいてしまいましたが、10月22日に名古屋で行われたクローズな集まりでのセッションのまとめです。

• MindmapModelingと集合知
• MindmapModelingと集合知(2) - ユビキタス言語
• MindmapModelingと集合知(3) - 日本語とモデルとプログラム
• MindmapModelingと集合知(4) - 関係
• MindmapModelingと集合知(5) - SVOで考える
• MindmapModelingと集合知(6) - メタモデル
• MindmapModelingと集合知(7) - クラウド拡張
• MindmapModelingと集合知(8) - マインドマップモデリングの例
• MindmapModelingと集合知(9) - SmartDox DSL
• MindmapModelingと集合知(10) - トレイト
• MindmapModelingと集合知(11) - SmartDox DSLによるユビキタス言語
• MindmapModelingと集合知(12) - オントロジー
• Literate modeling

「MindmapModelingと集合知」から「MindmapModelingと集合知(12) ー オントロジー」までがネタ整理、「Literate modeling」は「MindmapModelingと集合知」のまとめ的な記事になっています。

今回はちょうど開発中だったSimpleModelerのSmartDox DSLの位置付け、意味などを整理して考えるよい機会になりました。キーワードとして抽出できたのが「ユビキタス言語」と「Literate modeling」です。

プログラムを作りながら考えていることは漠然としているので、そのままではすぐには言語化できません。今回のような機会があると、言語化のよいきっかけになりますね。関係者の皆さん、どうもありがとうございました。

Scala基礎勉強会

「MindmapModelingと集合知」とは直接関係はありませんが、前日に開催されたScala基礎勉強会に触発されて、以下のブログも書きました。

• トレイト・モデリング

Scalaはなんといってもトレイトですね。

Literate modeling

10月23日の昼にとあるプライベートな集まりで、夜に名古屋Geek BarでSimpleModelerを紹介する機会がありました。参加された皆さん、どうもありがとうございました。

今回は新機能であるSmartDox DSLを中心に紹介しました。

ユビキタス言語

SimpleModelerの主張点の一つは、ユビキタス言語を軸にビジネス・モデリングから分析、設計、そしてコード自動生成を束ねていく点にあります。

この目的に、より近づくために開発したのがSmartDox DSLです。

SmartDoxは、Emacs org-modeをベースにした文書処理システムです。これをオブジェクト指向モデルの記述言語に採用したものがSmartDox DSLです。

SmartDoxは普通の文章を記述するためのフォーマットですが、この中に、一定のコンベンションに沿った文章を書くことで、この文章の中からオブジェクト・モデルを抽出し、モデルの可視化やコード生成を行うものです。このようにして抽出されたオブジェクト・モデルは、自然言語によって記述された文書との整合性を持つはずです。この部分が日本語、モデル、プログラムの共通部分、すなわちユビキタス言語となります。

Literate modeling

ユビキタス言語を軸に説明する方針をとっていたのですが、説明をしながら思いついたのはLiterate modelingの観点をもう少し強調した方がよいかもという点です。

Literate modelingはLiterate programmingのモデリング版で『Enterprise Patterns and MDA』で提案されているものです。

UMLによるビジュアル・プログラミングだけでは情報不足という認識から、UMLと同時にビジネス文脈文書(Business context document)を作成し、この2つをあわせてモデリングの成果物とします。

『Enterprise Patterns and MDA』版Literate modelingでは、UMLが主でこれを自然言語文書で補完しますが、SmartDox DSLのLiterate modelingではこれを一歩進めて自然言語文書＋コンベンションで実現します。

スライドにも柔らかいモデル、固いモデルという表現が出てきますが、これをもう少し精密化して、Literate modelingの文脈で説明していくのがよいのではないかと考えたわけです。

SmartDox DSLで書かれた自然言語文書(＋コンベンション)の文書から抽出されるものは以下の3つに分類できます。

非モデル

モデル化できないマテリアル。自然言語、図など。

柔らかいモデル

プログラムに落とすことはできないが、モデルとしてデータ化することができる。

固いモデル

プログラムを自動生成できる。

SmartDox DSLでは非モデル、柔らかいモデル、固いモデルを一つの文書に束ねて記述します。このため、プログラムと直接対応を持たない非モデル、柔らかいモデルがプログラムと生き別れになってしまい散逸してしまうことを防ぐことができます。

柔らかいモデルは、要求仕様といったビジネス側の要件をオブジェクト指向モデルの枠組みにそって記述したものです。この柔らかいモデルが固いモデルを束ねる形になりますが、このメカニズムにより固いモデル経由で、仕様記述、ビジネス・モデリング記述とプログラムの関係を明示することができます。

また、非モデルも柔らかいモデルや固いモデルの説明として紐付けられ、モデルの中に束ねられます。

説明中に思いついたアイデアをより具体化してみました。Literate modelingはSimpleModelerの特徴をわかりやすく表現できるようです。SimpleModelerのモデル記述方法に関する説明は「ユビキタス言語」と「Literate modeling」の2つを軸に洗練させていきたいと思います。

MindmapModeling「オンライン・ツー・オフライン（O2O）は、これからどう近づくか？」

10月20日(土)に横浜モデリング勉強会(facebook group)を行いました。また、会場には(株)アットウェア様の会議室をお借りしました。参加された皆さん、アットウェア様、どうもありがとうございました。

この勉強会で、浅海が作成したモデルを紹介します。モデルはMindmapModelingの手法で作成しました。(勉強会で使用したチュートリアル)

ワークショップの流れ

モデリング勉強会はワークショップ形式で以下の作業を行います。

• 雑誌記事から情報システムの企画書、提案書、RFPの元ネタとなるモデルを作成する。

その上で、「要求仕様確認、実装可能性確認、開発のベースとなるプログラムを自動生成するモデルを目指」します。詳細は「ワークショップの進め方 第2版」になります。

テーマ

モデリングの対象は、アドタイ誌の記事「オンライン・ツー・オフライン（O2O）は、これからどう近づくか？」です。

この記事を中心に記事に登場するO2Oを活用している2つの会社「ニーマン・マーカス」、「ホールフーズマーケット」のO2Oのモデルを作成します。記事は短いので必要に応じて他のサイトの情報を参照します。

用語の収集と整理

まず用語の収集と整理します。

MindmapModelingに慣れてくると、用語がだいたいどこの枝に収まるのかわかるようになるので、用語を拾いながらラフなモデルを作っていきます。

今回の記事は、高級でデパート「ニーマン・マーカス」とスーパーマーケット「ホールフーズ・マーケット」のどちらかを選択するという趣旨だったのですが、「コミュニティを作る」という意味では共通部分が多いと感じたので、「ニーマン・マーカス」と「ホールフーズ・マーケット」を合体させたモデルを作成することにしました。

クラス図

この段階でのマインドマップをSimpleModelerでクラス図化したものが以下になります。

まだ、個々のクラスはばらばらで組織化されていません。

物語

次の作業は「物語」です。

モデルは中心軸がないと単なる「用語」の集りなのでまとまりがでてきません。何らかの目的を実現するための構造を抽出したいわけですが、この「目的」と「目的を実現するための構造」を掬いとるためのツールとして有効なのが「物語」です。オブジェクト・モデリングの概念ではビジネス・ユースケースということになります。

「物語」を中心軸と定め、「物語」のスコープで用語を取捨選択、組織化し、足りない用語を補っていきます。

その手順は:

1. 物語の名前をつける。目的(goal)が明確になる名前がよい。
2. 物語の主人公、相手役、脇役などの登場人物を定める。
3. 物語で使用する道具を定める。
4. 出来事または脚本の列として脚本を記述する。

となります。2の登場人物と3の道具は最初から完全なものはできないので暫定的なものを定め、4の脚本の作業を通して洗練させていきます。

「物語」の作成を軸に、「出来事」の整理、「道具」の整理を進めました。

物語としては、ニーマン・マーカス由来の「顧客と専任スタッフの信頼関係を作る」、ホールフーズマーケット由来の「顧客とスタッフでコミュニティを作る」の2つの物語を軸にしています。どちらも、顧客と会社の間のコミュニティを醸成するという意味では共通しているのでこの観点でリソース(道具)の抽出、リソース間関係の整備などを行なっています。

今回はこの段階で時間切れになりました。

クラス図

この段階でのマインドマップをSimpleModelerでクラス図化したものが以下になります。

まだ、ビジネス・ユースケース→イベント→リソースの関係が作りこまれていないので、横に平べったくなっています。

モデリングを続けるとすると、そのあたりを伸ばしていく感じですね。

ノート

今回のモデリングでは以下の2つの機能拡張を試してみました。

• トレイト
• 物語の集約関係

トレイト

最近、モデル駆動を前提とした概念モデリングでもトレイトというモデル要素を導入するのが有効ではないかと考えています。

この目的でSimpleModelerにもトレイトを導入しました。

今回のモデルでは「共有したい物語」トレイトとして使用しています。

物語の集約関係

物語(business use case)は主役(primary actor)の視点で進めることが基本ですが、ある大きな物語とその内部のエピソードとなる物語で視点が異なることがあります。

今回のモデルでは「顧客と専任スタッフの信頼関係を作る」という物語は小売業企業の視点ですが、そのエピソードとなる「店舗で商品選択のアドバイスをもらう」は顧客(買物客)の視点になります。

この支店の異なる物語の入れ子関係を物語間に集約関係を導入するとモデルを的確に記述できそうということが分かってきました。この目的で勉強会の後にSimpleModelerを拡張しました。

前述の図は、改造後のSimpleModelerで生成したものです。

次回

次回は11月17日(土)です。

詳細情報はfacebookグループ「横浜モデリング勉強会」を参照してください。

今回と同じく「ワークショップの進め方 第2版」の手順で、「雑誌記事から情報システムの企画書、提案書、RFPの元ネタとなるモデルを作成する」を行う予定です。

MindmapModelingと集合知(12) - オントロジー

今回のセッションは、社会科学を中心に、工学、理学の知見を集約してクラウド時代の「集合知」に対してアプローチしている集まり、でのものになります。

ソフトウェア開発でのモデリングは、日本語(自然言語)の情報から必要な情報を抽出、再構成してプログラムに落とし込むためのモデルを構築するものですから、この文脈の中で日本語(自然言語)をどう扱っていくのかという点は常に関心を持っていました。

その成果物として、ユビキタス言語をハブに「固いモデル」と「柔らかいモデル」を統合したSmartDox DSLをつくってみたわけです。

最近、読み返してみた『Enterprise Patterns and MDA』に「literate modeling」というコンセプトが載っていましたが、SmartDox DSLの目指すところはまさにこのliterate modelingということになると思います。

ボク自身は「集合知」といったものは全くの門外漢なので、直接その話題を取り上げることはありませんが、日本語とモデルとプログラムを結びつけるユビキタス言語としてのSmartDox DSLが何かのヒントにしていただけるかもしれないということで、この点を中心の話題にする予定です。

オントロジー

マインドマップモデリングは、wakhokでの教育用に考案したものですが、このメタモデルの設計にあたっては、日本語を扱う技術ということもあり、参考のためにオントロジーの文献もあたってみました。オントロジーの分野も門外漢なので、どの本が定番かよく分からないのですが、MDAや企業システムのモデル化という観点で以下の本を入手しました。

• Model Driven Architecture and Ontology Development
• Enterprise Ontology

マインドマップモデリングは、最終的にOOPに落とし込むのが目的なので、できるだけOOPのセマンティクスの範囲でメタモデルを設計しています。そういう意味で、上記の本によるオントロジーは汎用的すぎて、目的には合わないと判断して初期の段階で参考資料からは落としました。

ただ、Mindmap DSLやSmartDox DSLといった形で、ユビキタス言語ベースのモデル記述DSLとそのメタモデルが形になってくると、このメタモデルのインスタンスであるモデル、このモデルのインスタンスであるデータは、ある意味ソフトウェア開発という文脈での意味のグラフと考えることができるかもしれないと感じています。そういう観点から、オントロジーの技術を導入して、なにか面白いことができるかもという期待もあります。

たとえば、「柔らかいモデル」の部分になる自然言語による記述に対してオントロジーな処理を施して意味を抽出し、「固いモデル」との整合性をチェック、は難しいかもしれませんが、レビューの元ネタぐらいはつくれないかな、とかそういう方向での応用です。

クラウド・プラットフォーム上での「集合知」の扱いがオントロジーと関係が出てくるのかそうでないのかも当日にならないと分かりませんが、そういった点も含めてこのあたりの技術動向についての知見を得ることができればと期待しています。

MindmapModelingと集合知(11) - SmartDox DSLによるユビキタス言語

ユビキタス言語で説明した通り、ユビキタス言語をハブにして日本語、モデル、プログラムを連携します。

元々、マインドマップモデリングをユビキタス言語として使用していましたが、マインドマップの記述力では本格的なシステム開発に耐えるモデルを記述するには無理があります。あくまでも、ブレインストーミングや教育の用途向けになります。

また本格的なシステム開発に耐えるモデルとしてはScalaをホスト言語とした内部DSLを使用していましたが、プログラミング寄りの記述方法なのでユビキタス言語としては難がありました。

この問題を解決するために開発したのがSmartDox DSLです。

SmartDox DSLは基本的にマインドマップと同じ文書構造になっており、システム側の語彙も共通しています。ただし、表組みなどを使ってより精密なモデルを記述できるようになっています。

SmartDox DSLでは、以下の2種類の語彙があります。

• システム語彙
• アプリケーション語彙

システム語彙

以下の用語にユビキタス言語の構造上の意味を持たせています。

語彙	OO用語	OO用語(英語)
登場人物	アクター	actor
道具	リソース	resource
出来事	イベント	event
要約	サマリ	summary
役割	ロール	role
物語	ビジネス・ユースケース	business use case
規則	ビジネス・ルール	business rule
特色	トレイト	trait
区分	パワータイプ	powertype
種類	汎化	generalization
参照, 関連	関連	association
部品, 集約	集約	aggregation
部品, 合成	合成	composition
属性	属性	attribute
脚本	(ユースケースの)フロー	(use case) flow
主役	プライマリ・アクター	primary actor
相手役	セカンダリ・アクター	secondary actor
脇役	サポーティング・アクター	supporting actor
状況の変化	状態遷移	state transition
状態	状態	state
状態機械	状態機械	state machine
サービス	サービス	service
基底	基底クラス	base class
多重度	多重度	multiplicity
目的	目的	goal
注記	アノテーション	annotation
性質	プロパティ	property

アプリケーション語彙

システム言語の語彙と文章の構造を用いて、アプリケーション言語の語彙を定義します。

前回の例では以下のクラス図が示すモデルをSmartDox DSLで記述しました。

このモデルでは以下のアプリケーション語彙が定義されています。

種別	アプリケーション語彙
アクター	顧客
リソース	商品
イベント	購入
トレイト	Master, Transaction, LogicalDeletable, Tagable, ImageHolder

「固いモデル」と「柔らかいモデル」の整合性

アウトラインや表組みの中の所定の場所にシステム語彙やアプリケーション語彙を記述することで、プログラム生成に必要な精度のモデルを記述します。この部分はツールと人間が共通に認識します。ここの部分を「固いモデル」と呼んでいます。

それと同時に、日本語の文章で各モデル要素の仕様を記述します。この部分はツールはモデルとしては扱わず、人間が仕様を理解するための情報になります。ここの部分を「柔らかいモデル」と呼んでいます。

柔らかいモデルの意図は、要求仕様といった人間側の情報をまとめ固いモデルへ紐付ける点にあります。要求仕様と固いモデルの整合性は、人間が「柔らかいモデルの文章」を読んでアナログに判断していきます。

従来のプログラミング言語よりの固いモデルと人間よりの柔らかいモデルが別々に存在しており、2つのモデル間の連携が不十分でした。

固いモデルと柔らかいモデルを統合したユビキタス言語を用いることで、アプリケーション開発のライフサイクルを通して持続的にこの2つのモデルの整合性を保っていく事が可能になるのではないかと考えています。

MindmapModelingと集合知(9) - SmartDox DSL

今月の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を使って以下のクラス図を生成することができます。

開発中なのでまだ試せていませんが、各種プログラムの自動生成もできる予定です。

MindmapModelingと集合知(8) - マインドマップモデリングの例

ここまで以下の順にマインドマップモデリングの基盤技術について説明してきました。

• MindmapModelingと集合知 :: セッションについて
• ユビキタス言語 :: オブジェクト指向モデルとユビキタス言語
• 日本語とモデルとプログラム :: ユビキタス言語で日本語とモデルとプログラムをつなぐ
• 関係 :: マインドマップモデリングで使用する「関係(relationship)」
• SVOで考える :: SVOとイベントの導入
• メタモデル :: マインドマップモデリングの土台となるメタモデル
• クラウド拡張 :: メタモデルのクラウド・アプリケーション向け拡張

ユビキタス言語をハブとして、日本語とモデルとプログラムをつなぐわけですが、その実現技術としてマインドマップを用いるのがマインドマップモデリングというわけです。

マインドマップモデリングのメリット

通常、マインドマップは非定形の情報を記述しますが、ここまで説明してきたようにマインドマップモデリングではオブジェクト指向技術と連携できるメタモデルを持っており、このメタモデルの枠組みの上でモデルを構築していきます。

一見、同様のことはUMLでもできそうですが、以下の理由によりマインドマップを用いたほうがはるかに便利というのが経験則です。

• UMLの文法を覚えるのが大変。UMLは文法を覚えないと何も描けない。さらにUMLのモデルとして基本文法に加えてアプリケーション用のプロファイルも覚える必要がある。マインドマップモデリングでは、文法をうろ覚えでもとりあえずそれなりのものを描くことができる。
• マインドマップモデリングではモデル全体の一覧性が高い。
• エディタ(XMind)がUMLエディタよりも簡単に使える。UMLエディタではプロパティシートの呼出しなど煩雑な処理が必要になる。

以上のメリットがあるので、モデリング初学者向けの教育や、顧客との文脈共有のためのブレインストーミングに有効です。

マインドマップモデリングの例

マインドマップモデリングの例として横浜モデリング勉強会で行ったMindmapModeling「LCCがもたらしたのは、価格破壊だけではない」のマインドマップモデルが以下です。横浜モデリング勉強会では、「雑誌記事から情報システムの企画書、提案書、RFPの元ネタとなるモデルを作成する」という趣旨で雑誌記事からマインドマップを作成するワークショップ形式の勉強会です。(ワークショップの進め方 (2012-06-16版))

このモデルは、日本語の情報としても本文の内容をうまく整理できていると思いますが、ユビキタス言語としてオブジェクト指向モデルと連続性がある点がさらに重要です。

これは、SimpleModelerを用いてクラス図を生成することで確認することができます。

上記のマインドマップモデルから生成したクラス図は以下になります。

SimpleModelerでは、クラス図だけでなくJavaクラスやAndroidアプリケーション、Ext-JS&Playアプリケーションの生成も行うことができます。つまり、ユビキタス言語からプログラムの自動生成する、モデル駆動開発を行うことができるわけです。

MindmapModelingと集合知(6) - メタモデル

前々回、前回でマインドマップモデリングでのモデリング方法についてざっくりと説明しました。業務アプリケーションを記述する場合、どのような枠組みを補助線にしていけばよいのかというプラクティスを、オブジェクト・モデルのプロファイルとして形式知化したものと考えるとよいでしょう。

こういったモデリングのプロファイルを考えるためには、モデルのメタモデルを構築する必要があります。

マインドマップモデリングでは、ボクが整備しているSimpleModelingというモデリング手法のメタモデルをベースにしています。SimpleModelingのメタモデルの中で、概要をざっくりつかむのに必要なモデル要素を厳選して、この範囲でモデルを記述します。

SimpleModelingのメタモデルの最新状況は以下のようになっています。

このメタモデルの中で、マインドマップモデリングでは以下のものを使用しています。

MindmapModeling	SimpleModeling
登場人物	アクター
道具	リソース
出来事	イベント
役割	ロール(図では省略)
規則	ルール
物語	ビジネス・ユースケース

エンティティを中心にメタモデルの一部を切り取っています。

マインドマップモデリングの範囲では、イベント(出来事)を中心に、エンティティとビジネス・ユースケースを結びつけるのが眼目になります。モデリングの中で、ビジネスの目標に沿った形で、エンティティとイベントを抽出し、お互いの関係を整理します。

MindmapModelingと集合知(5) - SVOで考える

今月の22日にとある名古屋の学際的な集まりで、マインドマップモデリングやモデル駆動開発についてお話させていただくことになりました。タイトルは「文書をプログラムにする技術」となりました。このセッションのネタ整理を「Object-Functional Analysis and Design: 次世代モデリングパラダイムへの道標」や「クラウド温泉3.0@小樽」といった感じで、ブログの上で行なっていっています。

前回はオブジェクト・モデルにおける関係(relationship)がマインドマップモデリングでどのように扱われているのかについて説明しました。

関係(relationship)の中で汎化(generalization)と集約(aggregation)を特別扱いするのがオブジェクト指向の基本的な考え方です。

関係(relationship)の一種に関連(association)があり、関連(association)の一種に集約(aggregation)、集約(aggregation)の一種に合成(composition)があるという関係になっています。

マインドマップモデリングでは、汎化を種類枝、集約を部品枝で記述していきます。

さて、伝統的なオブジェクト指向モデルでは、基本的にはこの部品建てなのですが、実際に業務アプリケーションをモデリングするとなるとこれだけでは道具不足です。UMLの基本部品をベースに、用途向けのプロファイルを整備していく必要があります。

動詞

業務アプリケーション向けのプロファイルは色々な論点がありますが、その一つとしてシステムの振舞いとの接点をどのように持たせるのかという点があります。

マインドマップモデリングで重要視している概念がSVOです。英文法に出てくるSubject-Verb-Objectですね。

日本語の文書にある「動詞」からシステムの振舞いを抽出するのが第一ステップです。

MindmapModelingチュートリアル from Tomoharu ASAMI

SVO

抽出した「動詞」を静的構造の中に位置付けるための手法としてSVOを使用します。

MindmapModelingチュートリアル from Tomoharu ASAMI

SVOを用いて、振舞いをモデル化した「動詞」と振舞いの起点となる「名詞」、振舞いの対象となる「名詞」を結びつけます。さらに、振舞いの結果発生する「名詞」の状態遷移を記述するための土台ともなります。

出来事

オブジェクト指向モデルの基本的な考え方では、動的モデルの振舞いは静的構造モデルの関連(association)に結びつきますが、関連そのものは揮発的な情報になってしまうので、動的モデルとの連携のヒントといったレベルのものになってしまいます。

また、業務アプリケーションのおけるイベントは、「伝票の発行」など記録を残していくことが基本なので、動的モデルといえども静的構造モデルとしての側面を持っています。

その上、アプリケーション上の最重要情報でもあるので、"連携のヒント"レベルの扱いではもったいなさすぎます。

以上の点からマインドマップモデリングではビジネス・イベントをエンティティとして扱い「動詞」やSVOのVと結びつけています。

具体的なモデリングの手法としてはスライドにもあるように、SVOを用いて動詞を「出来事」の枝に追加していきます。

MindmapModelingチュートリアル from Tomoharu ASAMI

SVOでモデリングした「動詞」を「出来事」として可視化し、「名詞」から抽出した「登場人物」や「道具」と結びつけていくのがマインドマップモデリングの重要な作業になるわけです。

MindmapModelingと集合知(4) - 関係

ここまでの議論では日本語、モデル、プログラムの共通部分をユビキタス言語で記述し、このユビキタス言語をハブにして、日本語、モデル、プログラムの独自部分をンクしていくというアプローチを紹介しました。

その実現手法の一つがマインドマップモデリングです。マインドマップモデリングに則ったマインドマップが日本語とモデルをつなぐユビキタス言語というわけです。

マインドマップモデリングの手法は「マインドマップではじめるモデリング講座」という書籍にまとめましたが、横浜モデリング勉強会で本書の購入を前提にしたくなかったのと、リファレンス的な資料も必要だったので、簡単なチュートリアルを作りました。

それが「MindmapModelingチュートリアル」です。

MindmapModelingチュートリアル from Tomoharu ASAMI

マインドマップモデリングの概要はこのチュートリアルをみていただければ簡単に把握することができると思います。

名詞の構造を考える

日本語をユビキタス言語化する際にまず考えないといけないのは文書中の名詞をオブジェクトのクラス化することです。

チュートリアルでは以下の節がこの作業に相当します。

MindmapModelingチュートリアル from Tomoharu ASAMI

このようにして抽出した名詞から構成される構造を記述するのがオブジェクト指向モデルのハイライトです。名詞間の関係をオブジェクト指向モデルの文脈で抽出するという点が重要になります。

チュートリアルでは以下の節がこの作業に相当します。

MindmapModelingチュートリアル from Tomoharu ASAMI

オブジェクト指向モデルの静的構造モデルは基本的にクラスとクラス間の関係(relationship)で構成されます。関係(relationship)の一種に関連(association)があり、関連のインスタンスがリンク(link)で、クラスのインスタンスであるオブジェクトは関連のインスタンスであるリンクで接続されます。関連はクラスの結合の強度によって集約(aggregation)、合成(composition)となっていきます。

オブジェクト指向モデルでは、関係(relationship)が基本モデル要素ですが、各種の関係の中でis-a(is-kind-of)関係、has-a(is-composed-of)関係を特別扱いしている点がポイントで、この2つの関係を軸に構造を記述していきます。

is-a関係は、UMLでは汎化(generalization)になります。通称的には継承(inheritance)でもよいでしょう。

has-a関係は、UMLでは集約(aggregation)、合成(composition)になります。

データベースに格納するデータ構造としての静的構造を構築するだけであれば、UMLが定めるオブジェクト指向モデルの基本モデル要素のみでも十分にモデルを記述することができます。

MindmapModelingと集合知(3) - 日本語とモデルとプログラム

「MindmapModelingと集合知」では、日本語(自然言語)、モデル、プログラムの関係として以下の図を導入しました。

理想的には、日本語の世界とモデルとプログラムが完全に一致することで、日本語の仕様書を書けばそのままプログラムとして動作するというものです。もちろん、これはSFの世界になってしまい現実的ではありません。そこで、日本語、モデル、プログラムのそれぞれが部分的に重なり図のようになるわけです。

これらの重なりに対してマインドマップモデリングやSimpleModelingで、それぞれの重なりに対してどのように対処しようとしているのか説明します。

日本語の世界とモデル

日本語の世界とモデルとの共通部をつくり、これを大きくしていくことが最初の段階になります。

もちろん、自由奔放に書いた日本語の文章がモデルに変換できるわけではありません。モデルを一定の規則に則って日本語で記述するアプローチを取ります。

このために導入したのが、「MindmapModelingと集合知(2) - ユビキタス言語」で説明したマインドマップモデリングの「登場人物 (actor)」、「道具 (resource)」、「出来事 (event)」といったモデル上の役割です。マインドマップモデリングでは演劇のメタファで、こういったモデル上の役割を規定しており、これらのメタファ上でマインドマップを記述していくことで、自然にオブジェクト・モデルと相互運用できるモデルを記述できるようにしています。

マインドマップモデリングは、文書とモデルの折衷案という切り口でもありますが、この手法を洗練させ文書よりに持ってくることで、日本語の世界とモデルの共通部分をより大きくすることができるかもしれません。

モデルとプログラム

プログラムとモデルを一致させることができれば、プログラムを書くこととモデルを作ることはイコールになります。

もちろん、現時点で完全にプログラムとクラスをマッピングさせることはできませんが、静的構造に関してはほぼ100%マッピングすることが可能なので、静的構造を軸にモデルとプログラムの一元化を考えていくことになります。

モデルとして静的構造のみを扱うのであれば、Javaクラスにアノテーションやコメントでモデル上の情報や日本語による仕様を記述していくというアプローチでも十分に機能するでしょう。

しかし、振舞いをスコープに入れるとこの前提が崩れてきます。

「オブジェクト・モデリングのボトルネック」で取り上げた通り、オブジェクトモデリングでは静的構造モデルと状態機械モデルの実装技術は確立していますが、協調モデルの実装技術が未完成のため、ここは手作業でやらざるを得なくなっているからです。

関数型言語、論理型言語の導入でこの垣根は徐々に下がっていく事になるでしょうが、現時点ではうまく連携できないという前提で考えておくのが無難です。

しかし、協調モデルはユースケース技術による「物語」を使ったシナリオ分析によって、要求モデル、振舞いの外部仕様、静的構造モデルを結びつける技術が確立してます。この「物語」の部分はまさに「日本語」を使ったモデルなので、日本語による記述との親和性が高くなっています。

以上の点を踏まえて、マインドマップモデリングでは「物語」を「脚本」を通して「登場人物」や「道具」といった静的構造に結びつけるメカニズムを提供しています。モデルとプログラムの重なりで欠落する振舞いの部分、つまり協調モデルは「日本語の世界とモデル」の技術を適用することで、緩和できるわけです。

そういう意味でも、日本語の世界、モデル、プログラムを統合的に扱うアプローチは有効ではないかと考えています。

日本語の世界とモデルとプログラム

ソフトウェア開発での論点の一つは、プログラムに落とし込めない日本語で書いた仕様をいかにプログラムとリンクした形で維持していくのかという点にあります。

その解決策としてオブジェクトモデリングの王道であるユビキタス言語をハブとして、モデル化できないゆるい日本語の情報をモデルに結びつけるという手法が考えられます。さらに、ユビキタス言語からモデルやプログラムの重ならない部分もリンクしていくということもできるでしょう。

ユビキタス言語は、日本語の文書かつモデルでプログラムの自動生成付き、という形になるでしょう。マインドマップモデリングを入り口に、こういった技術へのアプローチを考えています。