システム開発プロジェクトにおいて、UMLを用いたモデリングは、要件定義から設計、実装に至る各フェーズで極めて重要な役割を担います。
特に、ステークホルダー間の共通理解形成や機能要件の明確化において、UseCaseを用いるのは非常に効果的です。

しかし、UMLの記法や利用例は広く知られている一方で、「なぜそのように記述するのか」「その記法がどのような意味論に基づいているのか」といった、UMLの概念的な側面や抽象構文への理解は、自分含め、意外にも十分に浸透していないと思っています。
この概念的な理解の不足は、モデリング成果物の品質低下、認識齟齬の発生、ひいては手戻りの増加といったプロジェクトリスクに直結します。

本稿では、UMLの仕様であるUMLspecification (version 2.5.1)に依拠し、UseCaseの中核をなす概念を深掘りします。
これにより、単なる記法の習得に留まらない、本質的なUMLモデリング能力の向上を目指します。
読者の皆様が、要件定義フェーズにおけるモデリング活動において、より高品質で整合性の取れた成果物を生み出す一助となれば幸いです。

出典：
OMG

UMLは「Unified Modeling Language（統一モデリング言語）」の略であり、その目的は、システムアーキテクト、ソフトウェアエンジニア、ソフトウェア開発者に対し、ソフトウェアベースのシステムの分析、設計、実装のための標準的なツールを提供し、ビジネスプロセスなどのモデリングを支援することにあります。

UMLsは、UMLをモデリング言語として利用するための意味論および構文を厳密に定義し、異なるモデリングツール間でのモデル情報の一貫性を確保するために、以下の要件を掲げています。

1. UMLの抽象構文（Abstract Syntax）の正式な定義：完全なUMLモデルを構築するための基盤となるルール。
2. 各UMLモデリング概念の意味論（Semantics）の詳細な説明：各要素が持つ意味と振る舞い。
3. 個々のUMLモデリング概念を表現するための具象構文（Concrete Syntax）、すなわちエンジニアが読める表記要素の仕様、およびそれらを様々なタイプのダイアグラムに組み合わせるためのルール。

本稿では、特に上記1と2の抽象構文と意味論に焦点を当て、ユースケース図の深掘りを行います。

UMLにおける「UseCase」は概念としての要素、「ユースケース」（例：「顧客が商品を検索する」）は具体的な機能を示すものとして、文脈によって区別して言及します。

UMLsによれば、UseCaseは以下の特徴を持ちます。

• UseCaseは、あるシステムが何をすべきかを明確にする手段である。
• UseCaseの定義に不可欠な概念は、Actor（アクター）、ユースケース（具体的な機能）、そしてSubject（分析対象のシステム）である。
• Subjectは、ユースケースが適用される、あるいはユースケースを用いて検討が行われる対象システムや対象範囲を指す。
• 対象となるシステムのユーザー、あるいはSubjectと対話する可能性のある「他のシステム」をActorとして記述する（Actorは人間だけでなく、他のシステムやデバイス、または特定の役割を担うステークホルダーも含む）。

この概念を図解すると、以下のようになります。

図1: ユースケース図の基本要素と関係性

ユースケースは、任意の数のSubjectに適用可能であり、ユースケースが適用されることで、そのSubjectが実行する一連の動作が言語化され、Actorとの間に起こる相互作用と動作結果が明確になります。

UMLsから抜粋したユースケースの重要特性は以下の通りです。

• ユースケースはBehaviorClassifier（振る舞い分類子）の一種である。これは、ユースケースが特定の振る舞いを定義する分類子であり、その振る舞いを具体的な行動モデル（例：アクティビティ図、シーケンス図、ステートマシン図）で詳細化できることを意味する。
• 各ユースケースは、SubjectがActorに提供する価値ある機能の単位であり、SubjectとActorの主要な対話手段である。
• 各ユースケースは、Subjectが1つ以上のActorと協力して実行できる動作を指定する。
• ユースケースには、正常系の振る舞いだけでなく、例外動作やエラー処理を含むことが可能である。
• ユースケースを「完了」させるためには、そのユースケースに定義されたすべてのステップを完了する必要がある。完了条件は、実行後、①ユースケースを再度実行可能になるか、②エラー状態になる、のいずれかである。

ユースケースは、アクティビティ図やステートマシン図といった他のUMLダイアグラムを用いて、その一連の動作を詳細に記述することが可能です。
必要に応じて、事前条件、事後条件、および自然言語テキストによって記述され、他のダイアグラムと組み合わせることで、より包括的な機能要件の定義に貢献します。

図2: ユースケース「電話をかける」とそれに関係づけられたステートマシン図

Actorは、Subjectが提供する便利な機能であるユースケースを外部から利用するエンティティを指します。

UMLsにおけるActorの重要特性と、ユースケースとの関連付けに関する特徴は以下の通りです。

• Actorは、システムと相互作用する外部のエンティティを表し、システムに対してサービスを要求したり、システムからのサービスを受け取ったりする役割を持つ。
• 多重度を持つ関連付け:
  • ユースケースとActorが関連付けられていて、Actor側で多重度が1より大きい場合、複数のActorインスタンスがそのユースケースに関連していることを意味する。（例: 「ミサイルの発射」ユースケースには、2名の軍事責任者による同時キー操作が必要な場合など）。
  • ユースケースとActorが関連付けられていて、ユースケース側の多重度が1より大きい場合、特定のアクターがそのタイプの複数のユースケースに参加できることを意味する。
  • Actorは、複数のユースケースを並行して同時に開始することも、異なる時点で開始することも可能。

UMLsは、UMLをそのメタモデルにおける抽象構文の視点で記述しており、特にユースケースとActorはUseCaseモデリングの根幹をなす要素です。UMLsの記述を基に、これらの概念を改めて整理します。

• 定義: Actorから見たSubjectが提供する機能の単位を表します。SubjectがActorに提供する一連の相互作用を記述します。
• 性質:
  • Classifierの一種: 特定の振る舞い（機能）の型を定義する分類子です。
  • BehaviorClassifierの一種: 特に「振る舞い」を定義する分類子であり、ユースケースが具体的な振る舞いの記述（例：アクティビティ図やシーケンス図による詳細化）と関連付けられることを意味します。
  • Name: ユースケースは一意の名前を持ち、通常は「動詞＋名詞」の形式で具体的な機能を表現します（例：「商品をかごに入れる」、「預り金を計算する」）。
  • Subject: ユースケースが属するシステムまたはコンポーネントを示します。ユースケースは必ず何らかのSubjectの機能として存在します。
  • OwnedBehavior: ユースケースはその振る舞いを詳細に記述するモデル要素（例：アクティビティ、シーケンスなど）を所有することができます。これは、ユースケース記述（UCシナリオ）の具体化に利用されます。

• 定義: Subjectと相互作用する外部のエンティティを指します。Subjectに対してサービスを要求したり、逆にそのサービスを受け取ったりする役割を担います。
• 性質:
  • Classifierの一種: 共通の特性を持つオブジェクトの集合を定義する概念です。この場合は特定の役割を果たすエンティティを指します。
  • Name: 固有の名詞の形で名前を持ちます（例：「空調システム」、「顧客」）。
• 役割: システム(Subject)の外部との境界を明確にし、誰（または何）がシステムとどのように関わるのかを明確化します。

• Association (関連):
  • 関連: Actorとユースケース間の最も基本的な関係性です。Actorがユースケースを開始したり、ユースケースの結果を受け取ったりする意味合いを持ちます。
  • 方向性: 情報フローの方向を示すために、関連端に矢印を追加することがあります。これは、関連が単なるつながりだけでなく、相互作用の向きを示す場合に有効です。
  • 多重度: 多重度を定義することが可能で、それによって関係性に多重度（例: 複数のActorインスタンスが関与）を持たせることができます。

ユースケース図では、ユースケース同士が複雑な関係を持つことがあります。
UMLsでは、特に「Extend」と「Include」の2つの関係性が定義されています。

Extend関係は、拡張されるユースケース（拡張先）に対して、拡張するユースケース（拡張元）からの関係を示します。

• Extendは、拡張されるユースケースの振る舞いに対して、特定の条件が満たされた場合に追加の振る舞いを挿入することを指定します。
• この関係は、1つ以上のユースケースで定義された振る舞いに対して、場合によっては条件付きで振る舞いを追加する必要があるときに使用されます。
• 拡張元のユースケースは、拡張先のユースケースとは独立して定義され、単独でも意味を持つことができます。
• 拡張元のユースケースは、必ずしも単独で完全に意味を持つ振る舞いを定義するわけではありません。むしろ、特定の条件下で拡張されるユースケースの実行を増強する、モジュール化された振る舞いの集合を定義します。

UMLsでは、Extend関係に関連する二つの概念としてExtensionLocationとExtensionPointが言及されています。

図3: ExtensionLocationとExtensionPointの違い

5.1.1. ExtensionLocation (拡張位置)

ユースケースの基本フロー（Main Flow）の中で特定の条件が満たされた場合に、拡張フロー(Extension Flow)が挿入される具体的な場所を示します。

ExtensionLocationの具体例 (ユースケース：オンラインショッピングの場合)

基本フロー:

1. 顧客がカートに商品を入れる。
2. 顧客がチェックアウトを開始する。
3. 顧客が配送先情報を入力する。
4. 顧客が支払い方法を選択する。
5. 顧客が注文内容を確認する。
6. 顧客が注文を確定する。

ここで、以下のような拡張フローを考えます。

• 在庫切れの場合:
  • ExtensionLocation: 基本フロー1「顧客がカートに商品を入れる」の後
  • 拡張フロー:
    • 1: システムが在庫切れであることを顧客に通知する。
    • 2: 顧客は商品をカートから削除するか、入荷待ちを選択する。
• クーポンが適用された場合:
  • ExtensionLocation: 基本フロー4 「顧客が支払い方法を選択する」の後
  • 拡張フロー:
    • 1: 顧客がクーポンコードを入力する。
    • 2: システムがクーポンコードを確認する。
    • 3: システムが割引を適用する。

5.1.2. ExtensionPoint (拡張点)

ExtensionPointは、ユースケース内で一意の名前を持つ場所であり、ユースケースの振る舞いを拡張できる可能性のある特定の場所を指します（「もし拡張があれば、この場所で処理が分岐する可能性がある」というイメージです）。

ExtensionPointの具体例 (ユースケース：オンラインショッピングの場合)

ExtensionPoints:

• 在庫確認前処理
• クーポン適用処理
• 注文確定前処理

基本フロー:

1. 顧客がカートに商品を入れる。
2. 在庫確認前処理
3. システムが在庫を確認する。
4. 顧客がチェックアウトを開始する。
5. 顧客が配送先情報を入力する。
6. 顧客が支払い方法を選択する。
7. クーポン適用処理
8. 顧客が注文内容を確認する。
9. 注文確定前処理
10. 顧客が注文を確定する。
11. システムが注文を受け付ける。

※この例では、「在庫確認前処理」「クーポン適用処理」「注文確定前処理」がExtensionPointとして定義されます。

Include関係は、ユースケースAの振る舞いに、ユースケースBの振る舞いを挿入することを示す関係です（Aは基本ユースケース、Bは追加ユースケース）。

5.2.1. Include関係の基本原則

Include関係は、基本ユースケースが、追加ユースケースの振る舞いを必ず実行する必要があることを示します。

• 共通機能の再利用: 複数のユースケースで共通して実行される振る舞いを別ユースケースとして定義し、Include関係で参照することで、ユースケース内容の重複を回避し、モデリングの効率性と保守性を向上させます。
• 基本ユースケースの明確化: 基本ユースケースの振る舞いをより小さく分割することで、ユースケースの記述が明確になり、理解度が向上します。

5.2.2. Include関係の特性

• 依存方向: 基本ユースケースは追加ユースケースに依存しますが、基本ユースケースは追加ユースケースの実行なしには完了しません。
• 実行タイミング: 基本ユースケースの実行中に追加ユースケースの振る舞いが任意の箇所で発生します。
• 包含関係: 基本ユースケースは追加ユースケースの振る舞いを「内包」します。つまり、基本ユースケースの実行は追加ユースケースの振る舞いを含めて1つのまとまった処理として完了します。

UMLsでは、ユースケース図を記述する上での具体的な表記法（具象構文）も定義されています。

1. UseCaseの表記
   1. ユースケースは楕円で表現します。
   2. 楕円の中にユースケースの名前を記述するか、楕円の下に記述します。
   3. 必要に応じて、ステレオタイプキーワード（例: <<primary>>）を名前の上に記述します。
2. Actorの表記
   1. Actorは棒人間アイコンで表現します。
   2. Actorの名前は通常、アイコンの上または下に記述します。
   3. ActorはClass表記の矩形でも表現できます（図4参照）。
3. Subject (システム境界) の表記
   1. Subjectは長方形で表現し、その左上に名前を記述します。
   2. ユースケースの楕円は、この長方形の中に配置します。
   3. Subjectが特定のステレオタイプを持つClassの場合、そのステレオタイプキーワードを名前の上に記述します（図4参照）。
4. 関係の表記
   1. ユースケース間の関係は、破線の矢印で表現します。
   2. Extend関係の場合、矢印は拡張するユースケースから拡張されるユースケースを指し、<<extend>>ステレオタイプを矢印に記述します。
   3. Include関係の場合、矢印は基本ユースケースから追加ユースケースを指し、<<include>>ステレオタイプを矢印に記述します。
   4. Extend関係の条件やExtensionPointは、ノート要素で記述し、点線で関連づけます（図4参照）。

図4: ユースケース図の表記例

本稿では、UMLsのユースケースに関する記述を基に、その抽象構文、意味論、および主要な関係性について解説しました。
単にUMLの記法を知るだけでなく、「なぜそのように表現するのか」という概念的な背景を理解することは、UMLを用いたモデリングの品質を飛躍的に向上させます。

ステークホルダーとシステム要件を正確に把握し、設計に落とし込む上で、このようなUMLの深層理解は不可欠です。
本記事が、皆様のUMLモデリングスキル向上の一助となり、ひいてはプロジェクト成功に貢献できれば幸いです。

今後も、UMLsの他の章（例：Activity図、StateMachine図）についても、同様の視点から解説する記事を公開していく予定です。