UMLのポテンシャルを探る：FTP Online（2/5 ページ）

[Craig Larman，FTPOnline]

ユースケースモデル

　ここで取り上げる最初のユニファイドプロセスモデルは、ユースケースモデルである。それは、システムにおける機能主体な要件を記述する（Alistair Cockburnの『Writing Effective Use Cases』は、ユースケース分析の推奨書籍――関連リンク参照）。ユースケースは、テキストドキュメントでありダイアグラムではない。また、ユースケースモデリングにおいて最も多い共通の間違いは、現実のユースケース分析であるワープロによるテキスト記述よりも、ユースケースダイアグラムを考え議論することに時間を費やしてしまうことである。それにも関わらず、ユースケースと外部アクター名を概説するビジュアライゼーションとして、短時間でUMLユースケースダイアグラムをスケッチすることは有益である。

　このようなダイアグラムは、システムに関するコンテキストダイアグラムの一種として機能する。数分間のダイアグラムスケッチの後には、現実のユースケースモデリングに長い時間を費やすべきだが、それはテキストの記述である。ユースケーステキストは、オブジェクト指向アーキテクチャではないが、機能主体の要件に関する単なる記述なので、後に調査する成果物とモデルにおける、その存在と影響だけに注意することにする。POS（point-of-sales）アプリケーションにおけるドメインに関し、サンプルのユースケースダイアグラムに注目してほしい。それは幾つかのダイアグラムのチップスを使ったUML表現を応用する（図1）。

図1：POSアプリケーションのモデリング　このユースケースダイアグラムは、いくつかのダイアグラムチップによるUML表現を応用したPOS（point-of-sales）アプリケーションのドメインに関する例である（クリックで拡大します）

　このユースケースモデルは機能本位の要件を取得するための一般的なアプローチであり、ユニファイドプロセスにおける要件分野の一部である。各種の成果物から構成されており、最も重要なユースケーステキストと、オプションとしてのユースケースダイアグラム、シーケンス図、システムオペレーションコントラクトを含んでいる。

　UMLシーケンスダイアグラム表現の中で図示されるシーケンス図は、あるユースケースにおけるひとつのシナリオであり、ブラックボックスとして扱われるシステム上の入力システムオペレーションと、システムからの出力を示す（図2）。それは、システムI/Oをビジュアルに概説し、システム操作（システム上のイベント入力）の識別を支援する。図3として図示するのは、関係における影響と、ユースケースモデル加工物の関係により起り得る作成の順序である。（同様にUPは、機能本位ではない要件に関する補足の仕様など、他の重要な要件成果物を定義する）。

図2：Process Sale Scenario　UMLシーケンスダイアグラム表現で図示されるプロセス販売SSDは、システムのアウトプットと同様に、ブラックボックスとして扱われるシステム上でのインプットシステム操作の、ひとつのユースケースに対するひとつのシナリオに関して表現する。それはシステムI/Oを概説し、システム操作の識別を支援する（クリックで拡大します）

図3：Influential Relationships　この図は影響の関連性と、加工物の関連性におけるユースケースモデルで起こる作成順序を示す。ユニファイドプロセスは、ほかの重要な要件の加工物を定義するが、それはOOA/Dモデルに注目しているわれわれのスコープ外にある（クリックで拡大します）

ドメインモデル

　典型的なオブジェクト指向アーキテクチャモデルがドメインモデルである。UMLクラスダイアグラムのセットの中で図示され、問題のドメインとその関連性における、(投資者にとって）注目に値する概念と用語を表現する。例えばJavaのようなソフトウェアクラス図ではなく、問題のドメインで注目される事柄に関する、現実世界でのドメインの概念、もしくは抽象概念を図示するための概念的なクラスの概念的なビューである。そのため、尊重するかどうかについては評価が別れるところである。ユーザーは、ドメインモデルをドメインの用語に関する「ビジュアルな辞書」として捉えることができる。

　なぜ、わざわざ作成するのだろうか？　第一に、分析結果の常において真実であるように、些細な問題に慣れている開発者は、ドメインおよびその要件と共にあり、そこでのニーズに充たない小さなニーズは成果物の作成に対するものとなるだろう。しかし、もしドメインが大きく、新しく、また開発者にとって慣れたものでなければ、少なくともドメインモデルはそれらの方式での支援が可能である。ドメインでの用語および顕著なコンセプト間での重要な関連性をビジュアライズすることで、問題のドメインに対する理解を促進することが可能となる。それは、問題に関連する重要な情報を明確にすることであり、デザインと開発の期間において（アーキテクチャにおけるドメイン層の中で）ソフトウェアクラスのスターティングセットを触発することである。このクラスの名前と属性はドメインの語彙により表現される。したがって、ドメインにおける心理的な構成物と、ソフトウェアにおける表記間の、低位な表現ギャップがサポートされる。

　POSドメインに対するサンプルドメインモデルに関しては、図4を参照してほしい。このUMLクラスダイアグラムが示すのは、それぞれのクラスがひとつの名称と複数の属性、およびほかのクラスとの関連性を持つ状況である。これらの概念的なクラスは、現実世界の概念を描いており、またソフトウェアクラスではないため、メソッド表示されない。メソッドはオブジェクト指向デザインもしくはプログラミングの概念であり、現実世界のドメインにおける一部分ではない。

図4：Partial Domain　このPOSドメインに関するサンプルドメインモデルにおいて、UMLクラスダイアグラム表現は複数のクラスを示す。それらは、名前と複数の属性、ほかのクラスとの関連性を表している。これらの概念的なクラスは、ソフトウェアクラスではなく現実世界の概念を描くため、メソッドは表示されていない（クリックで拡大します）

　このドメインモデルはビジネスモデリング分野の一部である。ドメインの語彙と概念により、リッチなソースとなったユースケース本文は、ドメインモデルの作成時のインスピレーションにおける重要なソースである。