Part10は，システムの「利用方法」と入出力データの構造を明確にしました。Part11では，利用方法とデータを対応付けて，それらの関係を明らかにします。そして，システムのアプリケーション構成を明確にしてコンポーネントに分割します。
Part11は，システムレベルのモデリングの3回目です。Part9は，システムの利用方法であるユースケースを明確にしました。そして前回は，ユースケースを定義して，入出力データの構造を明確にしました。
Part11の演習の目的は，ユースケースとデータの関係を明確にすることと，システムのアプリケーション構成を明確にすることです。具体的な作業として，演習では「ユースケースデータ図」と「コンポーネント図」を作成します（図1）。
ユースケースとデータの関係を明確にすることで，ユースケースやデータの漏れに気付くことがあります。そして，システムのアプリケーション構成を明確にすることで，システムを管理しやすい単位に分割して，システムの生産性や保守性を向上させます。
本講座では，サンプルとして，中古車受注システムを取り上げています。Part10で解説したユースケース定義のサンプルを図2に再掲します。
ユースケース定義の基本フローは，特に，ユースケースの入力と出力に着目しています。入出力に着目することで，ユースケースの範囲が明確になるためです。
ユースケース定義を可視化
Part11の1つ目の演習は，Part10の前半で解説したユースケース定義をベースにして，ユースケースとデータの関係をユースケースデータ図で可視化することです。
表記法は，UMLをベースにした独自表記です。サンプルを図3に示します。UMLでは，楕円（ユースケース）と長方形（クラス）を両方含むような図は定義されていません。
ユースケースとデータの関係は，破線の矢印（依存線）で表記します。ユースケースがどのデータに依存するのかを表現します。矢印は常にユースケースからデータへ向かいます。ユースケースがデータに依存する一方で，データはユースケースに依存しないためです。矢印の向きはデータの流れを表現しているわけではないので，注意してください。
例えば「顧客を登録する」ユースケースでは「お客様情報」が入力です。具体的には，システム利用者が顧客登録画面で必要な項目を入力して登録ボタンをクリックします。従って「顧客を登録する」ユースケースから「お客様情報」へ向けて依存線を引きます。
また，登録ボタンをクリックすると，システムは「顧客データ」を生成して画面に表示するので，「顧客を登録する」ユースケースから「顧客データ」へ向けて依存線を引きます。
ユースケースがデータにどのように依存するのかは，二重山括弧（ステレオタイプ）で表記します。上記で説明した「顧客を登録する」ユースケースでは「お客様情報」を入力するので，その依存線のそばに＜＜入力＞＞を記載します。そして「顧客データ」を生成するので，その依存線のそばに＜＜生成＞＞を記載します。
依存関係の種類として，今回は「入力」と「生成」に加えて「検索」，「更新」，「削除」を想定しています。少なくとも，更新権を持つのか，単に使用しているだけなのかは区別すると良いでしょう。
異なる視点のモデルを統合
ユースケースデータ図には，Part10で解説したデータ図が含まれます。データ図は，ユースケース定義に登場するエンティティの静的な構造を表現します。Part10の後半で，ユースケース定義を参考にして，データ図を解説したので参照してください。
データに加えて，ユースケースもそのままユースケースデータ図に含まれます。ユースケースは，Part10の最初の方で示したユースケース図を参照してください。ユースケース図のユースケースは，そもそもシステム化業務フロー図において明確にしました。
従って，ユースケースデータ図を作成することは，システム化業務フロー図とデータ図を対応付けて，整合性を検証していることになるわけです。こうすることで，ユースケースやデータの漏れに気付くことができます。
例えば図3のユースケースデータ図において，受注データは，生成されているのみで，どのユースケースでも使用されていません。すなわち，受注データを利用するユースケースが漏れているのです。今回の場合，受注データは，代金請求プロセスや納車プロセスで利用する想定です。
その一方で，中古車データは，どのユースケースでも生成されていません。すなわち，中古車データを登録するユースケースが漏れているのです。中古車データは，中古車買取業務で登録される想定です。
システム化業務フロー図とデータ図を対応付けて整合性を検証することは，業務レベルにおいて，業務フロー図と業務概念図をぶつけて整合性を検証したことに相当します。
このように，異なる視点で作成したモデルを統合することは重要です。それぞれのモデルは視点が異なるだけで，そもそもの対象はある1つの業務システムですから，整合性が取れていなければならないのです。
モデリングツールを利用する
モデルを統合するような場合は特に，モデリングツールを利用すると便利です。ユースケースやクラスなどのモデル要素を一元管理できるからです。ユースケースデータ図において，ユースケースはユースケース図の要素と共通で，データはデータ図の要素と共通ですので，一元管理できます。
本講座において利用しているモデリングツールでは，ユースケースデータ図を作成すると，ユースケースとデータの関係マトリックスを自動的に表示することができます。
ユースケースデータ図の視点は，ユースケースとデータの関係を明確にすることですから，通常は，縦軸にデータ，横軸にユースケースを並べた表形式（マトリックス）で，それらの関係を表現します。
本講座では，モデリングツールの利用を前提として，視覚的にユースケースとデータを関係付けています。ユースケースデータ図は，UMLで標準に定義されている図ではないことに注意してください。
