より具体的な関係を表すユースケース図

必要であればユースケース図で、さらに追加の情報を図示することができます。図2のユースケース図は、先ほどのユースケース図のアクターとユースケースの構造を、より具体的な関係によって整理したものです。新たに登場した要素間の関係は、「汎化」「包含」「拡張」です。

汎化とは、アクターとアクターの間、またはユースケースとユースケースの間の関係のひとつです。具体的な要素とより抽象的な要素の関係であることを表しています。ある抽象的なユースケースの目的を達成することができる具体的なユースケースが、いくつか思いつく場合などに使用します。他にも、アクターとの関連やユースケース間の関係をひとまとめにする方法としても使用できます。また、白抜きの矢印で表記します。

包含とは、ユースケース間の依存関係の1つです。アクターが包含元のユースケースの目的を達成するために、（同じくアクターが）必ず包含先のユースケースも利用する必要があることを示しています。点線の開かれた矢印で表記し、「≪include≫」を記述します。

拡張とは、包含と同様にユースケース間の依存関係の1つです。拡張はアクターが拡張先のユースケースを使用している最中に、（同じくアクターが）拡張元のユースケースを利用する場合があることを示すものです。点線の開かれた矢印で表記し、「≪extend≫」を記述します。

本記事の例では最初に、「承認者」アクターと「経理担当者」アクターとで共通する、より抽象的なアクターとして「確認者」アクターを追加しています。もともと「出張申請を確認する」ユースケースに対して「承認者」アクターと「経理担当者」アクターの両方から関連線が引かれていましたが、「確認者」アクターを追加することによって、1本の関連線で表現することができます。

次に、「出張申請を登録する」ユースケースを使用するアクターである「申請者」アクターが、途中で必ず使用する（包含）ユースケースとして「出張旅費を比較する」を追加しています。交通費精算システムと連携し、出張の出発地点から目的地点までのいくつかの経路や交通費を比較するためのユースケースです。また、「出張申請を確認する」ユースケースを使用する「確認者」アクターが、途中でこの「出張旅費を比較する」を使用する場合もあります。

このように、「包含」はいくつかのユースケースの共通する部分を抜き出して、共通ユースケースを抽出する場合に使用されることが多い関係です。「出張申請の承認行為を行う」というユースケースは、具体的には「出張申請を承認する」「出張申請を差し戻す」「出張申請を却下する」の3つを表していることがわかります。アクターとの線を1本にまとめられることは、汎化関係を採用するメリットの1つです。

ユースケース図を記述する際の注意点

今回解説した「包含」「拡張」「汎化」の関係は、理解してしまえば便利な道具です。しかし、図が複雑になりすぎるというデメリットもあります。ユースケース図を利用する場面を思い出してください。

ユースケース図はユーザに機能的な要求を確認するために記述することが多いため、UMLに関する高度な知識を必要としない方が良いことがあります。3つの関係をすべて使うのではなく、「拡張」や「汎化」を「包含」のみで表現するなど、モデルの読み手に応じた記述方法を採用することも、モデリングのテクニックの1つと言えます。 次のページ