2013年2月28日木曜日

MindmapModeling「日本は「シェールガス革命」の恩恵を受けることができない?」

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

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

ワークショップの流れ

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

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

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

テーマ

モデリングの対象は、日経ビジネス誌の記事「日本は「シェールガス革命」の恩恵を受けることができない?」です。

用語の収集と整理

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

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




今回の記事は、エネルギーの特性に大きな比重がありそうなので、この点を中心に分類しました。

クラス図

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




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

出来事

「道具」としてシェールガスの文脈でエネルギーの特性をモデリングして来ました。次は、モデルの焦点を絞るため「物語」に進みたいところですが、その前準備として「出来事」をモデリングしました。




クラス図

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



物語

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

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

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

その手順は:

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

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




クラス図

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




「物語」から「出来事」を介して、各種「道具」がうまく組織化できました。

今回のモデルは「エネルギー」という抽象概念を、産業用エネルギーという軸からモデル化しました。モデルの趣旨からは「物語」や「出来事」がなくてもある程度定性的にモデリングできる素材でしたが、「物語」を使うことでより的確にモデリングできたと思います。

次回

次回はまだ確定していません。分かり次第お知らせします。

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

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

2013年1月7日月曜日

メッセージ・フロー図

システム・アーキテクチャなどを記述するモデル図を作成する際に困るのが、データ・フローとコントロール・フローの使い分けです。同期処理のみで構成される処理の場合は、データ・フローとコントロール・フローが一致するケースが多くなります。この場合、データ・フローまたはコントロール・フローのどちらか一方を書いておけば十分です。

しかしクラウド・アプリケーションのようにいたるところで非同期処理やバックグラウンド処理があるような場合、データ・フローとコントロール・フローが複雑に交錯することになりますが、両方のフローを線で記述していくと非常に煩雑な図になってしまいます。

この問題に対応するために考案したのがメッセージ・フロー図です。

SimpleModelingのメタモデルの最近の全体像は「MindmapModelingと集合知(7) - クラウド拡張」にありますが、メッセージ・フロー図は図の左側にあります。

2009年ごろから使っていますが、初期のものは「(仮称)クラウド研究会@札幌」にあるような形でした。

気づいたら文法を資料化しないまま随分経ってしまいましたが、2013年のはじめにひと通りまとめておきたいと思います。

文法

メッセージ・フロー図で使用するフロー線の文法です。



フロー線の先端部でプッシュ、プルの違いを表現します。また、白抜きの先端はデータフローとコントロールフローの向きが異なることを示します。

個々の詳細説明は後日。

使用例

前出の矢印を使ったロバストネス図は以下になります。



通常のロバストネス図はアクター、バウンダリ、コントロール、エンティティの各オブジェクト間の通信経路のみが分かりますが、メッセージフロー図の矢印記号を使うことで、(慣れれば)データ・フローとコントロール・フローをひと目で把握することができます。