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>>)

目的

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

特徴

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

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

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

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

表記法

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

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

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

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

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

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

図示表現:

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

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

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

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

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

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

図表表現:

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

使用するタイミング

  • 複数の use case が共通の必須手順を共有する場合。

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

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

拡張関係（<<extend>>)

目的

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

特徴

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

  • 依存：拡張 use case は自立して意味を持たず、基本 use case に依存しています。

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

  • 方向：矢印は拡張 use case から基本 use case へ向かっており、拡張 use case が基本 use case に振る舞いを追加することを示しています。

表記法

  • ラベル付きの破線矢印<<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つの基本ユースケースにのみ使用される含むユースケースを作成すること。

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

結論

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

参照