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

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

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

ワークショップの流れ

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

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

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

テーマ

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

用語の収集と整理

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

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

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

クラス図

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

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

出来事

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

クラス図

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

物語

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

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

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

その手順は:

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

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

クラス図

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

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

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

次回

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

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

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

MindmapModelingと集合知(7) - クラウド拡張

前回は、マインドマップモデリングの土台となるSimpleModelingのメタモデルを紹介しました。

このSimpleModelingメタモデルは、wakhok時代から積み上げてきたものでwakhok時代の成果物は『上流工程UMLモデリング 業務・要求分析からプログラミングへのモデル化技法』になります。

wakhokの段階では、伝統的な業務アプリをターゲットにしていましたが、2008年以降は、新しく勃興してくる「クラウド・アプリケーション」を新しいターゲットに設定して、メタ・モデルの拡張を進めています。

「クラウド・アプリケーション＝クラウド・サービス＋スマート・デバイス」とした上でキーポイントは以下になります。

• ビジネス・モデリングとの連続性を確保
• クラウド・サービスによる大規模データ/大規模演算
• スマート・デバイスを用いたUX/UI
• モデルからプログラムの自動生成

そこで昨日のメタモデルの図になるわけですが、このブログを書きながら少し情報を追加したので、その改版版を以下に示します。

最近UXの取り込みのイメージができてきたので、その情報を追加しました。また、ビジネス・プロセスのところで省略していたビジネス・フローを念の為に入れています。

以下ではこのメタモデルのインスタンスとして構築したモデルをSimpleModelingモデル、略してSMモデルと呼ぶことにします。

ビジネス・モデリング

SMモデルでは、プログラムに直接落とし込める部分を「固いモデル」、落とし込めない部分を「柔らかいモデル」と呼んでいます。基本的に要求仕様に近くなるほど「柔らかいモデル」、ドメインモデルに近くなるほど「固いモデル」になります。

ポイントとなるのは、固いモデルが、柔らかいモデルで記述したモデルを効率的に実現するための土台になっているのかという点を検証可能にしたいということです。このために、ビジネス・プロセスやユースケースといった柔らかいモデルを記述し、ドメインモデルとの関係をモデル上で維持し、可視化やモデルの検証などを行う基盤としていく予定です。

SMモデルでは、ビジネス・ユースケース(マインドマップモデリングの「物語」)をビジネス・モデリングの軸としています。ビジネス・プロセスはビジネス・ユースケースの集まりとしてモデル化していきます。ビジネス・ユースケースの具体的なステップはビジネス・タスクとして抽出し、ユースケースと紐付けます。

またビジネス・プロセスやビジネス・ユースケースは、イベント、アクター、イベントといったエンティティを使用します。この部分で直接プログラムとの関係が出てきます。

ビジネス・プロセスやその実行過程としてのビジネス・ユースケースにおいて、どのようなエンティティがどのように使われるのかという点を可視化し、検証可能にしていくのがSMモデルのおけるビジネス・モデリングの目標です。

クラウド・サービス

クラウド・サービスでは、大規模データ、大規模演算をどのようにモデル化して全体アーキテクチャに位置付けていくのかについて検討を重ねてきました。

「MindmapModelingと集合知」でも少し触れましたが、「データフローの導入」、「メッセージフローの導入」がクラウド・サービス向けの拡張点です。

大規模データ、大規模演算への対応が「データフローの導入」、非同期事象・遅延への対応が「メッセージフローの導入」です。プログラミングモデルに例えると前者が並列プログラミング、後者が並行プログラミング的なアプローチになります。

少し情報が古いですが想定しているアーキテクチャは以下のものです。

• クラウドアプリケーションのアーキテクチャ素案
• Hadoopの置き場所
• データベースの選択
• アプリケーションアーキテクチャとデータベース

このようなアーキテクチャに対して「Object-Functional Analysis and Design: 次世代モデリングパラダイムへの道標」で取り組んだObject-Functionalの切り口で分析、設計、プログラミングを行うためのメタモデルとDSLの実現を目指しています。

スマート・デバイス＆UX/UI

スマート・デバイスを用いたUX/UIもクラウド・アプリケーションの重要なテーマです。

Android

スマートデバイスについてはAndoirdを素材に検討を重ねてきました。成果物は以下のとおりです。

• Androidのアーキテクチャ
• g4 (クラウド温泉＠小樽)
• SimpldeModelerが生成するAndroidコード

スマートデバイスとスマートサービスの組合せによるアーキテクチャの動作イメージやモデリングとの接点は大体つかめたと思います。基本的にはiOSへの技術転用は可能だと考えているので、いずれそちらの方面にも展開できればと思います。

UX/UI

UXについては、色々と調査を進めていたのですが、最近イメージが明確になってきたのでSMモデルの枠組みの中に取り込んでいきたいと考えているところです。

上の図で示した通りユースケース→タスクのラインからサービスを、UXのラインからUIを構築するような形を考えています。

プログラムの自動生成

以上に示した各種モデルをDSLで記述し、プログラムの自動生成を行うためのツールとしてSimpleModelerを開発中です。

セッションではマインドマップモデリングとSimpleModelerでプログラムの自動生成のデモも行う予定です。