MindmapModelingの最新状況についてのご紹介です。
MindmapModelingはマインドマップを使ってモデリングを行う手法です。マインドマップを使って自由にモデルを書くというのではなく、UMLメタモデルによるモデルの表記方法としてマインドマップを用いるというアプローチです。
wakhok時代(2007年ごろ)に教育用として考案してモデリングの授業で使用していました。雑誌連載したものを書籍としてもまとめました。
MingmapModelingの比較的最近の記事としては2012年のものがあります。
その後、活動の中心がクラウドサービスプラットフォームの開発になったため情報発信は減りましたが、モデルコンパイラSimpleModelerなど他のモデリング技術と同時に開発技術として内部利用してきました。
クラウドアプリケーションとMindmapModeling
前述した通りMindmapModelingは元々教育用に開発したものですが、クラウドアプリケーション開発では実用技術として使えるのではないかと考えています。
モデリング技術全体に対するアプローチは以下で取り上げました。
クラウドサービスプラットフォームとScalaによるDSL指向Object-Functional Programming(OFP)のコンボによってアプリケーション開発におけるアプリケーションロジックのプログラミング量は劇的に減らすことができると考えています。
そうなると開発技術の焦点は以下の2つになります。
- UIやその他の体験(リコメンドの精度など)を統合したUX(User eXperience)
- ビジネスとのつなぎ込み
その中で(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年は具体的な開発方法論として整備していければと思っています。
投稿
