概要
オブジェクト指向開発では、開発の最初に問題空間(業務)の構造をUMLのクラス図で記述します。このクラス図を作成する過程で、日本語で記述された文章から、問題空間の構造を抽出します。
慣れれば文章から直接クラス図を起こすことができますが、初学者にはなかなか難しいのも事実です。また、大規模な問題空間の場合には、文章の量も膨大になるので、内容を整理するための中間的なモデルがあると有用です。
このような目的にマインド・マップを用いることが有力です。
単に、マインド・マップを使って臨機応変に言葉を整理していくのも十分に効果的ですが、クラス図に変換することを想定したフォームをあらかじめ定めておくとより効率的な作業を行うことが出来ます。
この目的で開発した方式が、マインド・マップ・モデリングです。
マインド・マップ・モデリングは、定型的に記述できる部分は定型的に、それ以外の部分は通常のマインド・マップの通り臨機応変に記述します。このため、必要最低限の手法をマスターすれば、すぐにでも利用を開始することができます。利用を進めながら、必要に応じて定型的に記述できる範囲を増やしていけばよいでしょう。
目的*
マインド・マップ・モデリングとは、マインド・マップを用いて問題空間のモデリングを行う手法です。
本テキストが想定しているオブジェクト指向モデリングの全体像は図オブジェクト指向モデリングの全体像です。
自然言語モデルとオブジェクト・モデルが相互に連携しながら存在しています。
プログラムの設計と実装の段階では、オブジェクト・モデルのみを使用しますが、問題空間のモデル化には自然言語モデルとオブジェクト・モデルを併用します。
特にドメイン・モデルを構成する自然言語とオブジェクトを同期させておくことが重要です。
マインド・マップ・モデリングのアプローチ
マインド・マップ・モデリングのアプローチを図マインド・マップ・モデルと自然言語モデル、オブジェクト・モデルの関係に示します。
予備モデルとしてマインド・マップ・モデルを作成します。このマインド・マップ・モデルを自然言語モデルである用語集とオブジェクト・モデルであるクラス図に変換します。
マインド・マップ・モデルからの変換は、マインド・マップ・エディタの機能を使って半自動的な処理が可能です。
問題空間の構造*
マインド・マップ・モデリングが想定している、モデリング対象の構造を図問題空間に示します。図では、問題空間の中にビジネス・システムが、ビジネスシステムの中にITシステムが入れ子になって入っています。マインド・マップ・モデリングでは、このように「問題空間」、「ビジネス・システム」、「ITシステム」の3層で構成される問題空間を使用します。
最も重要なことは、問題空間の外側と内側を明確に峻別することです。問題空間の外側と内側の境界が曖昧になると、正しいモデリングができません。また、作業効率を上げるためには問題空間の範囲を目的に応じてできるだけ絞ることが重要です。
ビジネス・システム
問題空間の中では、ビジネス・システムの外側と内側を分別します。
ビジネス・システムの外側にあるオブジェクトは、ビジネス・システム内に写像することでビジネス・システムで利用することができるようになります。
ビジネス・システム内(かつITシステムの外側)には、次の2種類のオブジェクトが存在します。
- ビジネス・システム外に存在するオブジェクトをビジネス・システム内に写像したオブジェクト
- ビジネス・システム内に存在するオブジェクト
ITシステム
ビジネス・システムの中では、ITシステムの外側と内側を分別します。ITシステムの外側にあるオブジェクトは、ITシステム内に写像することでITシステムで利用することができるようになります。
ITシステム内には次の2種類のオブジェクトが存在します。
- ビジネス・システム内に存在するオブジェクトをITシステム内に写像したオブジェクト
- ITシステム内に存在するオブジェクト
このうち前者の「ビジネス・システム内に存在するオブジェクトをITシステム内に写像したオブジェクト」がドメイン・モデルとしてモデル化する対象となるオブジェクトです。
ITシステムの内側のみに存在するオブジェクトは、実装依存のオブジェクトなのでモデリングの対象外になります。
アナロジ*
演劇のアナロジが分かりやすい
- モデリングしやすい
- 習得しやすい
- 顧客に説明しやすい
マインド・マップ・モデリングのコツ
- 非定型の情報を積極的に記述する。
- モデルを整理する際にも、非定型の情報を残す。
- ラフなモデルであることを積極的に活用する。
- 過度なモデリングはしない。
非定型の情報はUMLなどの*なモデルに変換すると失われてしまいます。マインド・マップ上では、このような非定型の情報も積極的に残しておくのがよいでしょう。
モデル体系
ソフトウェア開発におけるモデルの体系には色々な考え方がありますが、ここでは以下の図に示すモデル体系をリファレンス・モデルとして使用します。
このリファレンス・モデルでは、モデルを問題空間と解決空間の2種類に大別しています。問題空間にあるモデルは開発対象のソフトウェアが解決しようとしている問題をモデル化したモデルでありwhatのモデルといえます。一方、解決空間にあるモデルは開発対象のソフトウェアがどのようにして問題を解決するのかというやり方をモデル化したhowのモデルといえます。
問題空間モデルと解決空間モデルは、目的に応じてさらに以下のとおりに細分化されます。
- ドメイン分析モデル
- 要求分析モデル
- システム分析モデル
- 設計モデル
- 実装モデル
顧客がITシステムに期待することは、顧客が認識する「現実世界」の特定と、この現実世界の上で顧客が「やりたいこと」によって記述することができます。このうち、「現実世界」をモデル化したものが「ドメイン分析モデル」、「やりたいこと」をモデル化したものが「要求分析モデル」です。
解決空間モデルは、「やり方のモデル」のことで、システムが「どうやって(how)」顧客がやりたいことをITシステムで実現するのかをモデル化したものです。解決空間モデルは、システム分析モデル、設計モデル、実装モデルから構成されています。
システム分析モデルは、プログラミング言語や実行プラットフォームといった実現方法に依存しない、ITシステムとして本質的なレベルでの解決方法をモデル化したモデルです。それに対して、設計モデルと実装モデルはプログラミング言語や実行プラットフォームを前提に具体的な実現方法をモデル化したモデルです。設計モデルは、プログラミングによる実装を前提にしたモデルです。一方、実装モデルは、プログラミング言語などによる実装を指します。
詳細モデル体系
SimpleModelingモデルをさらに詳細に記述したものが以下の図です。
SimpleModelingモデルは以下の4つの軸で分類することができます。
- 段階
- ドメイン分析、要求分析、システム分析、設計
- 言語
- 自然言語、オブジェクト
- モデルの種別
- 静的モデル、動的モデル、機能モデル
- モデル化対象
- アプリケーション・モデル、ドメイン・モデル
以下で、これらの分類を用いてモデル体系について説明します。
作業段階
モデルの段階として、ドメイン分析、要求分析、システム分析、設計の段階を使用します。
ドメイン分析は、問題空間の構造を記述したモデルです。
要求分析は、問題空間の構造の上で情報システムの利用者が"やりたいこと"を記述したモデルです。
システム分析は、問題空間の中で情報システムの利用者が"やりたいこと"を達成するための、解決空間のモデルです。情報システムの抽象モデルとして記述します。
言語
モデルを記述する言語として、自然言語とオブジェクトがあります。
モデルの種別
モデルの種別として静的モデル、動的モデル、機能モデルの3種類があります。
静的モデルは、静的な構造を記述するモデルです。UMLではクラス図やコンポーネント図が静的モデルを記述する図として用意されています。
動的モデルは、動的な挙動を記述するモデルです。UMLではステートマシーン図、シーケンス図、コミュニケーション図などが動的モデルを記述する図として用意されています。
機能モデルは、モデル化対象のモデルの機能を記述するモデルです。
モデル化対象
モデル化対象としてドメイン・モデルとアプリケーション・モデルの2種類があります。
ドメイン・モデルは、問題空間の静的な構造を記述したモデルです。ドメイン分析作業で作成し、各作業段階に対応して具体化します。
アプリケーション・モデルは、情報システムが提供する機能の定義とその実現を記述したモデルです。主に要求分析作業で作成した要求モデルから派生してきます。
???
XXXX
SimpleModelingが想定しているビジネス・システム開発の全体像は図businessItOverviewです。
左上の経営戦略では、経営戦略を策定します。この経営戦略に則ってビジネス・プロセス・リエンジニアリング(以下BPR)が開始されます。
BPRではさまざまな作業を行われますが、そのひとつにビジネス・システム開発があります。ビジネス・システム開発の構成要素としてITシステム開発が行われます。
XXX
図userVenderItDevelopmentはITシステム開発の立場から、BPRの全体像を整理したものです。ITシステム開発に直接関係しない作業は省略しています。
業務TO-BE設計のドメイン・モデルは、ドメイン分析モデルと共通に用いることができるモデルです。業務TO-BE設計で作成した情報モデルをそのままドメイン分析モデルの成果物として使用するのが理想です。
XXX
モデルと作業分野の対応関係を図modelAnalysisDeciplineMatrixに示します。
コンテキスト・モデル、バリュー・チェーン・モデル、ビジネス・プロセス・モデル、ビジネス・ユースケース・モデル、ビジネス・フロー・モデルは業務AS-IS分析と業務TO-BE設計で作成します。
情報モデルは、業務AS-IS分析、業務TO-BE設計、ドメイン分析、要求分析で作成します。
ビジネス・ルール・モデルは、業務AS-IS分析、業務TO-BE設計、ドメイン分析、要求分析で作成します。
システム・ユースケースは、要求分析で作成します。
機能モデルは、要求分析で作成します。
ドメイン・モデルを中心としたモデル連携
ドメイン・モデルは非常に重要な位置付けのモデルです。
図domainModelRelationshipにドメイン・モデルをハブとした各モデルの関係を示します。
ドメイン・モデルは、ビジネス・システム・モデルとITシステム・モデルで共用します。つまり、ドメイン・モデルをハブとして、ビジネス・システムとITシステム・モデルが連携を行うわけです。
また、ドメイン・モデルはITシステム・モデル内でも、要求分析モデルとシステム分析モデルからも共用します。
ドメイン・モデルから設計モデルのドメイン・モデルに変換します。
問題空間、解決空間の観点からのドメイン・モデルをハブとした連携についても触れる。