MindmapModeling「LCCがもたらしたのは、価格破壊だけではない」

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

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

ワークショップの流れ

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

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

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

テーマ

モデリングの対象は、日経ビジネス誌の記事「LCCがもたらしたのは、価格破壊だけではない」です。

用語の収集と整理

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

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

今回の記事は、チケットに関しては常識の範囲の普通の記述なので焦点が絞りにくい感じでした。逆に規則(business rule)についての記述は多いのですが、これも制約事項的なものなので直接オブジェクト・モデルに活かせる感じではありません。

クラス図

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

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

物語

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

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

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

その手順は:

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

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

モデルの焦点を絞るために物語として利用者がチケットを購入する物語とキャリアが価格設定をする物語を、物語の枝に上げました。

物語を作ることで頭の中が整理されたこともあり、モデリングの焦点の絞り方として以下の2つのアプローチがあることが見えてきました。

• 利用者がキャリアをまたがって最適なチケットを購入するためのシステム
• キャリアが利用者からより高額な購入価格を設定するためのシステム

いずれの場合も、OR的な最適解を求めるアルゴリズムは記事のスコープ外ですが、そういったアルゴリズムを機能させるためのドメイン・モデルを分析するのがマインドマップ・モデルのターゲットになります。

今回は「利用者がキャリアをまたがって最適なチケットを購入するためのシステム」のアプローチを取ることにしました。　

クラス図

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

ビジネスユースケースを追加した他は、モデルに手を入れていないのでまだ一人っ子クラスが沢山あります。

最終型

前述の方針でさらに洗練を進めたモデルが以下になります。

「利用者がキャリアをまたがって最適なチケットを購入するためのシステム」の観点からチケット周りのモデルを精密化しました。

ポイントとなるのは、チケットとチケット仕様を分けた点です。チケットは利用者が購入したチケットのインスタンスに対応するクラスで、チケット仕様はチケットの料金設定などのメタ情報です。データベース的には前者がトランザクションデータ、後者がマスターデータということになるでしょう。

システム的には、チケット仕様に対してチケットがどのように売れたのかという点を記録しておき、後付けで分析して次回の価格設定に活かしたり、リアルタイムで分析して価格設定にフィードバックをかけたりするようなシステムを想定しています。

まだ、物語(ビジネスユースケース)まで手が回っていませんが、時間があれば物語に情報をフィードバックして、物語側の精度を上げていきたいところです。

クラス図

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

ビジネスユースケースとクラス間の関係がかなり整理されてきました。

経験則的には区分(powertype)の抽出数がモデルの充実度の指標になりますが、その点でも良い感じになっていることが確認できます。

ノート

ファウラーのアナリシスパターンに情報をoperationとknowledgeの二層に分けるパターンが出てきますが、knowledge的なメタ情報は普通のシステムでも普通に出てきます。マスターデータとして管理している情報の多くは、このknowledgeとしてモデル化できると思いますし、意識的にそうしていくことでより汎用性の高いモデルに洗練させていくことができると思います。

そういう意味で、SimpleModelingやMindmapModelingのメタモデル(=プロファイル)を考える上で、knowledge的なメタ情報を入れるのかどうかが常に悩みどころになっていました。何でもかんでも入れてしまうとメタモデルが複雑になってしまうので、最小限に絞る方向でモデル要素の取捨選択を行なっています。

クラウドアプリケーションの場合、単一ノードRDBMSの一本足打法でなくなるため、データごとのデータストアの選択やデータの配備方法が非常に重要になってきます。このためknowledge情報をメタモデル上も一級市民にして、方法論全体の枠組みの中できちんと扱って行かないといけないかな、と今回モデリングしながら感じました。

現在のところ、SimpleModelingには入れて、MindmapModelingには入れない、というのが落とし所かなぁと考えたりしています。

次回

次回は10月20日(土)です。

• facebook, atnd

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