Posted inUnified Modeling Language Use Case Modeling Visual Paradigm

UMLのユースケース図におけるIncludeおよびExtend関係の包括的なガイド

統一モデリング言語（UML）ユースケース図は、システムの機能要件をモデル化するための強力なツールです。アクター（ユーザーまたは外部システム）がユースケースを通じてシステムとどのように相互作用するかを示します。ユースケース図における2つの重要な関係—Include および Extend—は振る舞いを構造化およびモジュール化することで複雑さを管理するのに役立ちます。このチュートリアルでは、これらの関係の目的、特徴、実用的応用について詳細に説明し、例を交えて明確さを確保します。

Include関係とExtend関係とは何か？

においてUMLのユースケース図, Include および Extend関係により、複雑なユースケースをより小さな再利用可能またはオプションのコンポーネントに分解できます。これらの関係はモジュール性を高め、重複を減らし、図の明確性を向上させます。

Include” and “Extend” Use Cases - Visual Paradigm Blog

  • Include関係（<<include>>)：基本のユースケースの一部として常に実行される必須の振る舞いを表します。複数のユースケースに共通する機能を再利用可能なコンポーネントとして抽出します。

  • Extend関係（<<extend>>)：特定の条件下で基本のユースケースを拡張するオプションまたは条件付きの振る舞いを表します。これにより、基本のユースケースはそのコア機能に集中したままになります。

両方の関係は、ダッシュ線の矢印を使用してユースケースを接続し、ラベルで<<include>> または <<extend>>を示します。矢印の方向は重要で、ユースケース間の依存関係を反映しています。

Include関係（<<include>>)

目的

The 包含包含関係は、複数のユースケースから共通で必須の振る舞いを抽出し、単一で再利用可能なユースケースにすることで、再利用性を高め、重複した機能を回避することで基本ユースケースを簡素化する。

特徴

  • 必須：基本ユースケースが実行されるたびに、含まれるユースケースは常に実行される。

  • 再利用可能：含まれるユースケースは、独立して機能する一貫した機能であり、複数の基本ユースケースで使用可能である。

  • 図の簡素化：共通の手順を抽出することで、基本ユースケースは簡潔で焦点を絞ったままになる。

  • 方向：矢印は基本ユースケースから含まれるユースケースへ向かっており、基本ユースケースが含まれるユースケースに依存していることを示している。

表記法

  • 破線の矢印でラベル付けされた<<include>>は基本ユースケースと含まれるユースケースを接続する。

例1：オンラインショッピングシステム

顧客が注文するまたは注文をキャンセルするという2つのユースケースがある。どちらも顧客がログインするシステムにログインする必要がある。

  • 基本ユースケース: 注文する, 注文をキャンセル

  • 含まれるユースケース: ログイン

  • 説明: ログインは注文の作成および注文のキャンセルの両方において必須のステップです。両方のユースケースにログイン機能を重複して実装する代わりに、それを別個のユースケースとして抽出しています。ログインこのユースケースは両方のユースケースによって含まれます。

図示表現:

[注文を確定] ----<<include>>----> [ログイン]
[注文をキャンセル] ----<<include>>----> [ログイン]

例2：図書館管理システム

図書館システムでは、ユーザーは本を借りるまたは本を返却する。両方のプロセスにおいて、ユーザーの確認.

  • 基本ユースケース: 本を借りる, 本を返却する

  • 含まれるユースケース: ユーザーの確認

  • 説明: ユーザーの身元を確認する（例：図書カードの確認）ことは、本を借りるときも返却するときも必須のステップです。ユーザーの確認 ユースケースは重複を避けるために含まれています。

図表表現:

[本を借りる] ----<<include>>----> [ユーザーを確認する]
[本を返す] ----<<include>>----> [ユーザーを確認する]

使用するタイミング

  • 複数のユースケースが共通の必須手順を共有する場合。

  • 再利用可能な機能を抽出することで、ユースケースの記述を簡素化したい場合。

  • 含まれるユースケースが独立して意味を持つ場合（例：ログイン または ユーザーを確認する は独立した関数として理解できる）。

拡張関係（<<extend>>)

目的

この拡張拡張関係は、特定の状況下でのみ実行されるオプションまたは条件付きの振る舞いをモデル化するために使用されます。これにより、基本となるユースケースはそのコア機能に集中しつつ、オプションの振る舞いをモジュール化して追加できます。

特徴

  • オプション／条件付き：拡張されるユースケースは、特定の条件が満たされた場合にのみ実行されます。

  • 依存：拡張されるユースケースは自立して意味を持たず、基本となるユースケースに依存しています。

  • 拡張ポイント：基本となるユースケースは、拡張される振る舞いを挿入できる特定のポイントを定義する可能性があります。

  • 方向：矢印は拡張されるユースケースから基本となるユースケースへ向かっており、拡張されるユースケースが基本となるユースケースに振る舞いを追加することを示しています。

表記法

  • ラベル付きの破線矢印<<extend>> は拡張されるユースケースをベースとなるユースケースに接続し、しばしば条件または拡張ポイントを指定する注記を伴う。

例1：ATMシステム

ATMシステムでは、ベースとなるユースケースは現金の引き出し。オプションの動作として、領収書の印刷が行われる可能性がある。これはユーザーが領収書の発行を要求した場合に限る。

  • ベースとなるユースケース: 現金の引き出し

  • 拡張されるユースケース: 領収書の印刷

  • 条件：ユーザーが現金を引き出した後に領収書の印刷を選択した場合。

  • 説明：領収書の印刷は必須ではなく、ユーザーが明確に要求した場合にのみ行われる。領収書の印刷 ユースケースは現金の引き出し を拡張ポイント「ユーザーが領収書の発行を要求する」で拡張する。

図示表現:

[領収書の印刷] ----<<extend>>----> [現金の引き出し]rn（注：条件＝ユーザーが領収書の発行を要求する）

例2：オンラインコースプラットフォーム

オンラインコースプラットフォームでは、ユーザーはクイズを受ける。オプションの動作として、ヒントを要求するユーザーが質問に苦労している場合に発生する。

  • 基本ユースケース: クイズを実施する

  • 拡張ユースケース: ヒントをリクエストする

  • 条件：ユーザーがクイズ中にヒントをリクエストする。

  • 説明：ヒントをリクエストすることは任意であり、ユーザーのニーズに依存する。このヒントをリクエストする ユースケースはクイズを実施する「ユーザーが支援を必要とする」という拡張ポイントで拡張される。

図示表現:

[ヒントをリクエストする] ----<<拡張>>----> [クイズを実施する]
（注：条件 = ユーザーが支援を必要とする）

使用するタイミング

  • 動作が任意である、または特定の条件に依存する場合。

  • 基本ユースケースをその主な機能に集中させたい場合。

  • 拡張ユースケースが基本ユースケースなしでは意味を持たない場合（例：領収書を印刷する がなければ無意味である現金を引き出す).

IncludeとExtendの主な違い

以下の表は、Include と拡張関係性を用いてその使用方法をガイドする：

基準

含む（<<含む>>)

拡張（<<拡張>>)

この振る舞いは必須ですか？

はい、基本ユースケースの一部として常に実行される

いいえ、特定の条件下でのみ実行される

この振る舞いは独立して成立しますか？

はい、整合性があり再利用可能な機能である

いいえ、基本ユースケースに依存する

複数のユースケースで発生しますか？

はい、複数のユースケースで共有される

通常、1つのユースケースに特化している

目的

再利用を促進し、基本ユースケースを簡素化する

オプションまたは例外的な振る舞いをモジュール化して追加する

矢印の方向

基本 → 含むユースケース

拡張 → 基本ユースケース

実践例：レストラン管理システム

実際のシナリオにおける使用法を説明するために、レストラン管理システムで両方の関係性を適用してみましょう。

シナリオ

レストランシステムは顧客が料理を注文するそして予約テーブル。システムは以下の追加動作も処理します。支払い および テイクアウト依頼.

ユースケース

  • 注文：顧客がメニューから食事を注文する。

  • 予約テーブル：顧客が食事用にテーブルを予約する。

  • 顧客認証：顧客の身分を確認する（例：ロイヤルティアカウント経由）。

  • 支払い：顧客が注文代金を支払う（必須：注文).

  • テイクアウト依頼：テイクアウト用に注文を包装するためのオプション依頼。

関係

  • 含む：両方の注文 および 予約テーブル は 顧客認証 を通じて顧客の身分を確認する。注文 また、以下を含む支払い注文後に支払いは必須であるため。

  • 拡張: 食事を注文は以下によって拡張可能である：テイクアウトを依頼顧客が持ち帰りを希望した場合。

図示表現

[食事を注文] ----<<包含>>----> [顧客認証]
[食事を注文] ----<<包含>>----> [支払い]
[テーブル予約] ----<<包含>>----> [顧客認証]
[テイクアウトを依頼] ----<<拡張>>----> [食事を注文]
(注：条件 = 顧客がテイクアウトを依頼する)

説明

  • 顧客認証は以下の両方で含まれる：食事を注文およびテーブル予約システムにアクセスするための必須ステップであるため。

  • 支払いは以下のものに含まれる：食事を注文注文を完了するには支払いが必要であるため。

  • テイクアウトを依頼は以下のものを拡張する：食事を注文顧客がテイクアウトを依頼した場合にのみ発生するオプションの動作であるため。

包含と拡張の使用におけるベストプラクティス

  1. 包含は慎重に使用する複数のユースケースで共有される、またはベースとなるユースケースを大幅に簡略化できる場合にのみ、動作を包含するユースケースとして抽出する。包含の過剰使用は図を複雑にする。

  2. 拡張の明確な拡張ポイントを定義する拡張動作が適用されるベースとなるユースケース内の条件やポイントを明確に指定し、曖昧さを避ける。

  3. ユースケースを焦点を絞って設計する: 基本のユースケースが単純で、主な目的に集中していることを確認し、Include必須の手順に使用し、Extendオプションの手順に使用する。

  4. Includeの再利用可能性を検証する: 含まれるユースケースは意味があり、異なる文脈で再利用可能でなければならない。

  5. 図の複雑化を避ける: Include および Extend明確性を高める場合にのみ使用する。複雑な関係はステークホルダーを混乱させる可能性がある。

よくある誤りとその回避方法

  1. IncludeとExtendの混同:

    • 誤り: Includeオプションの動作に使用したり、Extend必須の動作に使用したりする。

    • 解決策: 必ず動作が必須かどうかを確認する（必須の場合はIncludeを使用）、条件付きの場合は（Extend).

  2. 関係の過剰使用:

    • 落とし穴：あまりにも多くのものを生成すること含むまたは拡張関係性を生成することで、図を読みにくくする。

    • 解決策：重複を減らすか、明確性を高める場合にのみこれらの関係性を使用する。

  3. 曖昧な拡張条件:

    • 落とし穴：拡張の条件を明確にしない拡張関係性により、混乱を招く。

    • 解決策：常に条件または拡張ポイントのメモや説明を含める。

  4. 再利用不可能な振る舞いを含む:

    • 落とし穴：1つの基本ユースケースのみで使用される含むユースケースを作成すること。

    • 解決策：含むユースケースが再利用可能であるか、基本ユースケースを大幅に簡略化することを確認する。

結論

UMLユースケース図における含むおよび拡張関係性は、複雑さを管理し、モジュール性を確保するために不可欠である。含む 関係は必須で共有される振る舞いを抽出することで再利用性を促進しますが、拡張 関係は、オプションまたは条件付きの振る舞いをモデル化することで、基本的なユースケースを焦点を絞って保持します。目的、特徴、ベストプラクティスを理解することで、システムの機能をステークホルダーに明確に伝えることができる、明確で保守性が高く効果的なユースケース図を作成できます。

参照