mindmapmodelingチュートリアル

MindmapModeling チュートリアル 2011-‐10-‐29 浅海智晴 (@asami224)

目次

•  MindmapModelingとは •  MindmapModeling概説 •  ドメイン・モデルの作り方 •  トピックス

MindmapModelingとは

MindmapModeling •  MindmapModelingはマインドマップを使ってモデルを作成する手法。

•  稚内北星学園大学東京サテライト校で実務者をターゲットとしたモデリング教育向けに開発

•  問題空間側のモデルをマインドマップで記述することができる。

•  業務モデル : 業務ユースケース •  ドメイン・モデル : 静的構造モデル

•  MindmapModelingと一般的なマインドマップの違い。 •  MindmapModelingモデルは、マインドマップの上に独自構造を拡張しており、オブジェクト・モデルに落とし込む手順が確立

している。

なぜMindmapModelingなのか

•  自然言語(日本語)による文章情報からいかにオブジェクト・モデルを作成するのか？ •  自然言語(日本語)→UMLを直接作成するのは難しい。 •  自然言語(日本語)ベースの中間的な構造モデルがあるとよい。 •  この目的にはマインドマップが最適。

•  単なるマインドマップでは不十分 •  オブジェクト・モデルへの変換を前提にしたマインドマップベースのフォーマットが有効。

•  このためには目的にかなったメタ・モデルをバックグラウンドにしたマインドマップのフォーマットでなければならない。

•  このフォーマットがMindmapModeling。 •  オブジェクト・モデルをメタファで理解できる。 •  オブジェクト・モデリングの”コツ”を習得

MindmapModeling関連本

自然言語モデルとオブジェクト・モデル

作業分野� モデル対象� メタファ � モデル種別� 自然言語�

モデル�

オブジェクト・モデル�

ドメイン分析� 現実世界� 舞台� 構造� 用語集� クラス図�

要求分析� やりたいこと � 物語� 挙動� ユースケース � ユースケース �

メタモデル

Mindmapモデリングのプロファイル

ドメイン

イベント

アクター

リソース

業務ユースケース

システム・ユースケース

状態機械

業務タスク

システム・タスク

業務タスクをアクターとサービス・システムの対話として具体化

業務タスクの実行によってイベントが発生する

サービス・システム外にあるオブジェクト

サービス・システム上で発生するイベント

サービス・システムが管理しているオブジェクト

アクターと業務システムの物語

アクターとサービス・システムの物語

業務ユースケースのフローの中でサービス・システムと対話するステップ

脚本

物語

登場人物

出来事

道具

イベントに参加するアクター

イベントによって更新(+参照)されるリソース

イベントによって状態が遷移する

MindmapModeling概説

MindmapModelingの構成 •  演劇のメタファ •  演劇の構造、用語を使ってモデルを表現 •  分かりやすく、かつ、オブジェクト・モデルと親和性が高い

•  構造の導入 •  BOI構造枝

•  ルート直下の構造枝 •  マインドマップではルート直下の枝をBOI(basic ordering idea)と呼ぶ

•  用途別の用語の定義を行う •  構造枝

•  用語の構造を定義するために使用する枝 •  参照枝

•  BOI構造枝または構造枝配下にある用語に対する参照 •  普通枝

•  通常のマインドマップの枝

雛形

テーマ

メモ

パレット

物語

役割

規則

出来事

道具

登場人物

MindmapModelingの例

yorozuSample4Slide

物語

道具

役割

パレット

規則

メモ

出来事

登場人物

支払い

出品

購入

販売

出品券

現金

商品

従業員

出品者

販売者

購入者

よろず商会が管理している現金

出品者に対して商品の出品の証明書として発行するチケット

よろず商会が販売する商品

販売者

出品者

現金

出品券

販売員

購入員

出品者

販売員

購入者

商品

出品券

購入員

商品

現金

現金

商品

種類

部品

部品

種類

よろず商会に商品を出品する人

よろず商会に商品を売る人

よろず商会から商品を買う人

出来事

出来事

出来事

販売価格

購入価格

商品

委託商品

商品名

在庫商品

出品者

購入員

出品

販売

購入

販売員

よろず商会が出品者から委託されて販売する商品

よろず商会が仕入れて販売する商品

部品

よろず商会で商品を仕入れる人

よろず商品で商品を販売する人

出来事

出品券

支払い

BOI構造枝(1) • 登場人物 • 問題空間に登場するアクティブな人や物 • オブジェクト・モデルではアクター(actor)に対応

• 道具 • 登場人物が操作する道具 • オブジェクト・モデルではリソース・エンティティ(resource enCty)に対応

• 出来事 • アクターの活動に伴って発生する出来事 • オブジェクト・モデルではイベント・エンティティ(event enCty)に対応

BOI構造枝(2) •  規則 •  構造に対する制約 •  オブジェクト・モデルではドメイン・ルールに対応

•  役割 •  物語や出来事に対する役割 •  オブジェクト・モデルではコラボレーションやイベントにおけるロール

(role)に対応 •  コラボレーション、イベントと登場人物、道具を間接的に繋げる

•  物語 •  問題空間で発生する物語 •  登場人物の目的を達成するための出来事の系列 •  オブジェクト・モデルではユースケースに対応

•  パレット •  構造枝の雛形を置いてある枝

•  メモ •  未分類の用語を置いておくための枝

構造枝(1) •  配役

•  用語の具体例 •  オブジェクト・モデルではインスタンス(instance)

•  種類 •  用語の種類 •  オブジェクト・モデルでは汎化(generalizaCon)

•  区分 •  用語の区分 •  オブジェクト・モデルではパワータイプ(powertype)

•  部品 •  用語を構成する部品 •  オブジェクト・モデルでは集約(aggregaCon)または合成(composiCon)

•  属性 •  用語の属性 •  オブジェクト・モデルでは属性(aHribute)

•  出来事 •  用語が発生させるイベント •  オブジェクト・モデルではイベント・エンティティ(event enCty)

•  役割 •  用語が担う役割 •  オブジェクト・モデルではロール(role)

構造枝(2) •  主役

•  出来事や物語を発生させる登場人物 •  オブジェクト・モデルではユースケースのプライマリ・アクター(primary actor)

•  相手役 •  出来事や物語に対応する登場人物 •  オブジェクト・モデルではユースケースのセカンダリ・アクター(secondary

actor) •  脇役

•  出来事や物語に参加する主役と相手役以外の登場人物 •  オブジェクト・モデルではユースケースのセカンダリ・アクター(secondary

actor) •  目標

•  主役が物語で達成したいこと •  オブジェクト・モデルではユースケースの目標(goal)

•  状況の変化 •  出来事や物語によって起きる道具の変化 •  オブジェクト・モデルではリソース・エンティティ(resource enCty)の状態遷移

(state transiCon) •  脚本

•  物語を構成する出来事の系列 •  オブジェクト・モデルではユースケースのフロー(flow)

参照枝

•  登場人物 •  道具 •  出来事 •  規則 •  役割 •  物語

ドメインモデルの作り方

自然言語モデル→ドメイン情報モデル作業手順

1.  文章の中から名詞を抽出する •  名詞を登場人物(アクター)と道具(リソース)に仕分け

2.  文章の中から動詞を抽出する •  動詞を出来事(イベント)に仕分け

3.  名詞の構造を定める •  is-‐a関係(SはOの一種である)

•  種類

•  has-‐a関係(SはOから構成されている) •  部品

4.  SVO(名詞、動詞、名詞)で考える •  登場人物(アクター)、出来事(イベント)、道具(リソース)

5.  クラス図に変換 ¡  以下の手順はオブジェクト・モデリングに合流

例題：よろず商会

•  顧客は商品を購入する。 •  従業員は商品を仕入れる。 •  顧客には個人顧客と法人顧客がある。 •  商品は製品と保守契約から構成されている。 •  顧客は顧客番号と氏名を持っている。 •  従業員は従業員番号と氏名を持っている。

手順１：文章の中から名詞を抽出する

•  文章では、主語や目的語が抜けている場合があるので、適宜補う

•  登場人物(アクター)、道具(リソース)、部品(属性)に分類 •  登場人物：システム外にあり、イベントを発生させる人や物

•  道具：システム内にあり、イベントの発生によって状態が変化する物

•  部品：アクターやリソースの特性を表現する値

例題：よろず商会名詞の抽出

よろず商会

メモ

パレット

物語

役割

規則

出来事

道具

登場人物

氏名

従業員番号

顧客番号保守契約

製品

商品

法人顧客

個人顧客

従業員

顧客

顧客は商品を購入する。従業員は商品を仕入れる。顧客には個人顧客と法人顧客がある。商品は製品と保守契約から構成されている。顧客は顧客番号と氏名を持っている。

従業員は従業員番号と氏名を持っている。

例題：よろず商会名詞の抽出/属性

よろず商会

役割

物語

パレット

規則

メモ

出来事

道具

登場人物

保守契約

製品

商品

法人顧客

個人顧客

従業員

顧客

部品

部品

氏名

氏名

従業員番号

顧客番号

顧客は商品を購入する。従業員は商品を仕入れる。顧客には個人顧客と法人顧客がある。商品は製品と保守契約から構成されている。顧客は顧客番号と氏名を持っている。従業員は従業員番号と氏名を持っている。

手順2：文章の中から動詞を抽出する

• 文章の動詞から、「出来事」を抽出する • 構造を示す動詞は次の「名詞の構造を定める」で扱う • 構造を示す動詞：持っている、構成されている、など

• 残るのは、挙動を示す動詞 • 動詞を出来事(イベント)と関連に分類 • 記録に残す必要がある「動詞」(挙動)は出来事(イベント) • 記録に残す必要がない「動詞」は関連(associaCon) •  マインドマップ・モデリングでは直接は扱わない

例題：よろず商会動詞の抽出

よろず商会

役割

物語

パレット

規則

メモ

出来事

道具

登場人物

購入

仕入れ

保守契約

製品

商品

法人顧客

個人顧客

従業員

顧客

部品

部品

氏名

氏名

従業員番号

顧客番号


手順3：名詞の構造を定める •  is-‐a(is-‐kind-‐of)関係 •  汎化(generalizaCon) •  SはOの一種である。 •  構造枝「種類」

•  has-‐a(is-‐composed-‐of)関係 •  集約(aggregaCon) •  SはOから構成されている。 •  構造枝「部品」

is-‐a(is-‐kind-‐of)関係

よろず商会

役割

物語

パレット

規則

メモ

出来事

道具

登場人物

購入

仕入れ

保守契約

製品

商品

従業員

顧客

種類

部品

部品

氏名

氏名

従業員番号

顧客番号

法人顧客

個人顧客

法人顧客は顧客の一種である。

個人顧客は顧客の一種である。顧客は商品を購入する。従業員は商品を仕入れる。顧客には個人顧客と法人顧客がある。商品は製品と保守契約から構成されている。顧客は顧客番号と氏名を持っている。従業員は従業員番号と氏名を持っている。

has-‐a(is-‐composed-‐of)関係

よろず商会

役割

物語

パレット

規則

メモ

出来事

道具

登場人物

購入

仕入れ

保守契約

製品

商品

従業員

顧客

部品

種類

部品

部品

保守契約

製品

氏名

氏名

従業員番号

顧客番号

法人顧客

個人顧客

商品は製品から構成されている。

商品は保守契約から構成されている。



手順4：SVOで考える •  SVO •  主語(Subject) ...は •  動詞(Verb) ...する •  目的語(Object) ...に、...を

•  SVOO •  間接目的語(Indirect Object) ...に •  直接目的語(Direct Object) ...を

SVOで考えるイベント

よろず商会

役割

物語

パレット

規則

メモ

出来事

道具

登場人物

購入

仕入れ

保守契約

製品

商品

従業員

顧客

主役

主役

状況の変化

状況の変化

部品

種類

部品

部品

顧客

従業員

商品

製品

保守契約

製品

氏名

氏名

従業員番号

顧客番号

法人顧客

個人顧客

顧客(Subject)は商品(Object)を購入する(Verb)



手順５：クラス図に変換

1.  登場人物はアクターに変換 2.  道具はリソース・エンティティに変換 3.  出来事はイベント・エンティティに変換 4.  種類はisa関係に変換 5.  部品は：

1.  属性に変換、または 2.  hasa関係に変換

クラス図に変換

<<actor>>従業員

<<actor>>顧客

<<resource>>商品

<<event>>購⼊入

<<event>>仕⼊入れ

<<actor>>法⼈人顧客

<<actor>>個⼈人顧客

<<resource>>製品

<<resource>>保守契約


名詞の属性を追加

<<resource>>商品

<<event>>購⼊入



<<resource>>製品


+ 氏名 : 氏名+ 顧客番号 : 顧客番号

<<actor>>顧客

+ 氏名 : 氏名+ 従業員番号 : 従業員番号

従業員<<actor>>



オブジェクト・モデリングに合流

•  ここまでの作業で、マインドマップからクラス図への変換は完了

•  これ以降の作業は通常のUMLベースのオブジェクト・モデリングとなる

定型的な属性を追加

+ 商品名 : 商品名+ 商品番号 : 商品番号

<<resource>>商品

+ 購入日時 : 日時+ 購入番号 : 購入番号

<<event>>購⼊入



+ 製品名 : 製品名+ 製品番号 : 製品番号

<<resource>>製品

+ 保守契約名 : 保守契約名+ 保守契約番号 : 保守契約番号


+ 氏名 : 氏名+ 顧客番号 : 顧客番号

<<actor>>顧客


従業員<<actor>>

+ 仕入れ日時 : 日時+ 仕入れ番号 : 仕入れ番号




データ型データ型� 種別�

従業員番号� 識別子�

顧客番号� 識別子�

商品番号� 識別子�

製品番号� 識別子�

保守契約番号� 識別子�

仕入れ番号� 識別子�

購入番号� 識別子�

氏名� 名称�

商品名� 名称�

製品名� 名称�

保守契約名� 名称�

日時� 時間�

トピックス

汎化、インスタンス、パワータイプ

•  汎化、インスタンス、パワータイプを適切に使い分ける •  SはOの一種である。

•  汎化 (generalizaCon) •  SはOの具体例である。

•  インスタンス (instance) •  汎化と思ってもインスタンスである事が多い。インスタンスを汎化と誤認しないことが大事。

•  SはOの一種である。 •  パワータイプ (powertype) •  汎化との使い分けは?

パワータイプ(powertype)とは •  “区分”を表現するモデリング手法 •  冪(べき)集合(power set)に由来

•  オブジェクト・モデルでは汎化はできるだけ使わないことが望ましい •  多重継承はモデルが複雑になり、また実装が難しくなるという問題がある。

•  単一の継承であってもRDBMSでの実装が複雑になる問題がある。

•  できるだけパワータイプを用いることでこの問題を回避できる。

•  オブジェクトの種別をデータとしてオブジェクト内に保持する実装を行う •  データベース: 区分コード •  Java: enum

例題：会議室予約

•  従業員は会議室を予約することができる。 •  従業員は会議室の予約と同時に会議用の備品を予約することができる。

•  会議室備品にはプロジェクタ、電話会議用電話がある。

使用例：会議室予約汎化

会議室

メモ

パレット

物語

役割

規則

出来事

道具

登場人物

予約

備品

会議室

従業員

主役

種類

状況の変化

従業員

電話会議用電話

プロジェクタ

会議室

クラス図：会議室予約汎化


<<actor>>従業員

+ 使用終了時間 : 日時+ 使用開始時間 : 日時+ 予約発行日時 : 日時+ 予約番号 : 予約番号

<<event>>予約

+ 会議室番号 : 会議室番号

<<resource>>会議室

+ 備品番号 : 備品番号

<<resource>>備品

<<resource>>プロジェクタ

<<resource>>電話会議⽤用電話

「備品」の”種類”の配下にある「プロジェクタ」、「電話会議用電話」は「備品」を親とする汎化としてモデル化

使用例：会議室予約インスタンス・オブジェクト

会議室

メモ

パレット

物語

役割

規則

出来事

道具

登場人物

予約

備品

会議室

従業員

主役

配役

状況の変化

従業員


プロジェクタ

会議室

クラス図：会議室予約インスタンス・オブジェクト


<<actor>>従業員


<<event>>予約



+ 備品名 : 備品名+ 備品番号 : 備品番号

<<resource>>備品

<<resource>>

備品名 = プロジェクタ備品番号 = P0001

プロジェクタ : 備品

<<resource>>

備品名 = 電話会議用電話備品番号 = T0001

電話会議用電話 : 備品

<<instanceOf>>

<<instanceOf>>

「備品」の”配役”の配下にある「プロジェクタ」、「電話会議用電話」は「備品」のインスタンスとしてモデル化

使用例：会議室予約パワータイプ

会議室

メモ

パレット

物語

役割

規則

出来事

道具

登場人物

予約

備品

会議室

従業員

主役

種別

状況の変化

従業員

備品種別

会議室


プロジェクタ

「種別」になっていますが「区分」です。

参考：会議室予約パワータイプ


<<actor>>従業員


<<event>>予約



+ 備品番号 : 備品番号

<<resource>>備品

プロジェクタ電話会議⽤用電話

<<powertype>>備品種別

「備品」の”種別”の配下にある「プロジェクタ」、「電話会議用電話」はパワータイプ「備品種別」のサブタイプとしてモデル化

UMLの本来の書き方とは異なりますが、書きやすい独自の表記法を用いています。

mindmapmodelingチュートリアル

Technology