Now Reading: UMLユースケース関係の習得：「include」と「extend」の力と危険性

1
  • 01

    UMLユースケース関係の習得：「include」と「extend」の力と危険性

Read this post in: de_DEen_USes_ESfr_FRhi_INid_IDpl_PLpt_PTru_RUvizh_CNzh_TW

UMLユースケース関係の習得：「include」と「extend」の力と危険性

UMLYesterday

ソフトウェア要件およびシステムモデリングの世界において、UML（統合モデリング言語)は、システムの振る舞いを可視化するための基盤の一つである。その最も強力だが頻繁に誤解される機能の一つが、「include」および「extend」ユースケース間の関係である。これらのメカニズムは、重複の削減, 変異性の管理、およびモジュール性の向上ユースケースモデルにおける。しかし、それらの誤用は広範にわたる——過度に複雑な図面、ステークホルダー間の混乱、ユーザー価値への注目が失われる結果を招く。

 

 

本記事では、包括的で実践的かつ専門家による支援を受けたガイド「include」と「extend」の一般的な落とし穴を理解し、適用し、回避するためのものである。我々はそれらの真の意味を比較し、なぜそれらがDFD（機能分解）と同じ罠に陥るのかを検証し、そして現代的なベストプラクティス2025–2026年のチーム向けに提供する——特にアジャイル、リーン、またはハイブリッド環境で作業しているチームにとって。

🔹 コアの意味：「include」と「extend」の本当の意味本当に意味するもの

✅ 「include」：必須の再利用——「常に必要」とされるサブフロー

定義:
«include»関係は、必須で、常に実行される複数のユースケース間で再利用するために抽出されたサブフローである。

📌 主な特徴：

  • 常に実行される：含まれるユースケースは、ベースユースケースが呼び出されるたびに実行される。

  • ベースユースケースはこれなしでは不完全である：含まれる動作がなければ、ベースユースケースはその目的を果たせない。

  • 依存関係の方向：矢印はベース → 含まれる.

  • 独立した意味：含まれるユースケースは通常単独では意味を持たない—それは大きなプロセスの一部としてでなければ意味を持たない。

  • 類比：ある種の関数呼び出しまたはサブルーチンプログラミングにおける—メインルーチンにとって不可欠なもの。

🧠 伝統的な記憶術：

「～するにはログイン、あなたはユーザー認証.”
「～するには現金を引き出す、あなたは必ずPINを検証する.”

これらは妥協できないステップ認証がなければログインできません。PINの検証がなければ現金を引き出せません。

💡 使用するタイミング：

  • ある共通で複雑かつ再利用可能な振る舞いが現れる場合2つ以上のユースケースに現れる場合にのみ«include»を使用する。

  • 例：

    • ユーザー認証

    • 監査ログの記録

    • 通知の送信

    • 入力形式の検証

✅ 目安：再利用される振る舞いが重要である, 単純でない、かつ≥2–3ユースケースに現れる場合にのみ«include»を使用する。

✅ «extend»：オプションの変形 – 「条件付き追加機能」

定義:
「extend」関係は、オプション、条件付き、またはバリエーション動作を定義し、特定の拡張ポイントに接続する拡張ポイントベースのユースケースの

📌 主な特徴：

  • 条件付き実行：特定の状況下でのみ実行される。

  • ベースのユースケースは単独で完結する：拡張なしでも通常のフローが成立する。

  • 依存関係の方向：矢印は拡張元 → ベース（逆方向）。

  • 独立した意味合い：拡張するユースケースはほとんど単独では意味を持たない—それは文脈がある場合にのみ意味を持つ文脈内でのみ.

  • 類比：たとえばフック, プラグイン、またはAOP（アスペクト指向プログラミング）のアドバイス—特定のポイントで動作を追加します。

🧠 クラシックな記憶術：

「～しているときにフライトを予約する、あなたはおそらく希望するかもしれません希望する座席を選択する.”
「～しているときにクレジットカードで支払う、あなたはおそらく必要になるかもしれません3Dセキュアコードを入力する.”

これらはオプションの強化機能—コアフローには必須ではありません。

💡 使用するタイミング：

  • 以下をモデル化するため：代替パス, 例外、またはオプション機能.

  • ユースケースに条件に基づく異なる動作条件（例：ユーザーの役割、システム状態、設定）に基づいて異なる動作がある場合。

  • 例:

    • 割引を適用（拡張する注文を提出)

    • 返金を依頼（拡張する支払いを処理)

    • PDF領収書を生成（拡張する取引を完了)

✅ 目安：「拡張する」は慎重に使用する——意味のある変化に対してのみ意味のある変化明確な拡張ポイント.

🔍 すばやい比較：「含む」対「拡張する」

側面 「含む」 「拡張する」
実行 常に 時々／条件付きで
基本のUCは単独で完了するか？ ❌ いいえ——含むものに依存する ✅ はい——拡張なしで完了可能
依存関係の方向 基本 → 含む 拡張 → 基本
矢印の方向 含むユースケースを指す 基本ユースケースを指す
主な目的 必須で共有される手順の再利用 オプション/変異フローの処理
類推 関数呼び出し / サブルーチン フック / プラグイン / AOPアドバイス
独立した意味を持ちますか？ めったにない ほとんどない
最適な用途 再利用可能で複雑なクロスカッティングな関心事 条件付き、オプション、または代替的な振る舞い

⚠️ 「分解の罠」：ユースケース図が軌道から外れる理由

ちょうどDFD（データフロー図）の問題を抱えている機能的分解の罠、ユースケース図も同じ致命的な病気にかかりやすい: 過剰な分解.

📉 DFDの機能的分解の罠（要約）：

  • チームはプロセスをさらに小さくするバブルに分割し続けている。

  • 図表は数十もの小さな低レベルの関数に膨張する。

  • その 元の目的—ユーザーに価値を提供すること—が失われる。

  • 結局は のように見える疑似コード または 内部アルゴリズム設計、ユーザーの行動ではない。

🧨 ユースケース「機能分解病」：

  • すべての小さなステップが独自のユースケースになる：

    • ユーザー名を入力

    • パスワードを入力

    • ログインボタンをクリック

    • フォーマットを検証

    • エラーメッセージを表示

  • «include» が 広くすべてのアクションを分解するために適用される。

  • 結果：A 深い階層 のユースケース（A → B → C → D…）で、明確なアクターの目的がない。

  • 図表は 保守不能, 混乱、そして 無意味 ステークホルダーにとって。

❌ 赤旗：あなたのユースケース図に 15～20個以上のユースケースがある、または ほとんどの基本ユースケースが2～4ステップの長さであるその場合、あなたはおそらく罠にはまっているでしょう。

🛠️ なぜこれが起こるのか：よくある落とし穴と誤解

落とし穴 説明 回避方法
«include»の過剰使用 すべてのサブステップを再利用可能なユースケースとして扱う。 «include»は 重要な, 再利用可能な, クロスカットする 振る舞い（例：認証、ログ記録）にのみ使用する。
矢印の方向の混乱 «include»の矢印を逆方向に描く（ベース ← インクルード）または«extend»の矢印を前向きに描く。 思い出してください： include = ベース → インクルード; extend = 拡張する → ベース.
代替フローに«extend»を使用する 代替フローをモデル化する 内部に 一つのユースケースを«extend»として扱うのではなく、テキストによる代替を用いる。 使用するテキストベースの代替フローほとんどの変化に対して使用する。『extend』は、本物のオプション拡張.
includeチェーンの作成 A → B → C → D → E… 深いチェーンを避ける。複数のincludeが必要な場合は、単一の再利用可能なユースケースに再構成する.
曖昧な拡張ポイント 明確で名前が付けられた挿入ポイントのない状態で『extend』関係を追加する。 定義する明示的な拡張ポイント（例：「支払い確認後」）を基本ユースケース内で。
図の混雑 ユースケースと関係が多すぎると → 視覚的なノイズになる。 図を小さく、焦点を絞り、アクター中心に。各サブシステムごとに複数の図を使用する。
ステークホルダーの混乱 技術的でないステークホルダーは『include/extend』を理解しにくいと感じる。 使用するテキストベースのシナリオまたはユーザーストーリーマップ明確さのために。
設計レベルのモデリング ユーザーの目的ではなく、内部アーキテクチャ（例：「データベースを呼び出す」）をモデリングする。 焦点を当てるアクター価値—実装ではない。
果てしない議論 シナリオの作成よりも「include か extend か」について議論するチーム。 使用する実用的なヒューリスティクスそして形式よりも明確さを優先する.

✅ 2025–2026年のベストプラクティス：現代的でアジャイルなアプローチ

要件工学のあり方には変化が生じた。アジャイル、リーン、製品志向のチームはますます重いUML図から離れ、代わりに軽量で価値志向の手法へと移行している。

🎯 コア原則：内部構造ではなく、アクター価値に注目する

❗ «include» または «extend» を追加する前に、以下の問いを投げかける:
「この関係性はユーザーが目的を理解するのを助けるのか、それとも単にシステムを分解しているだけなのか？」

✅ 推奨される現代的実践：

1. «include» を慎重に使用する — 主な再利用可能な振る舞いのみに限定する

  • 以下のものにのみ使用するクロスカッティングな関心事が複数の複数のユースケースに現れるもの。

  • 例：

    • ユーザー認証

    • メール通知を送信

    • セキュリティイベントをログ記録

    • ビジネスルールを適用

❌ 避けるべき：ユーザー名を入力, 送信をクリック, メール形式を検証

2. 「extend」よりもテキスト形式の代替フローを優先

  • 代わりに：

    「extend」：希望席を選択 → フライトを予約

  • 使用する：

    ユースケース：フライトを予約
...
代替フロー：
  1. ユーザーが「希望席」オプションを選択。
  2. システムが座席図を表示。
  3. ユーザーが座席を選択。
  4. システムが座席の好みを適用。

✅ なぜですか？テキスト形式のフローは読みやすい, より柔軟、そして誤用されにくい.

3. 保持するユースケース図小さく、焦点を絞る

  • 1つの図ごとにアクターまたはサブシステム.

  • 制限：5～10のユースケース図あたり

  • 使用する：パッケージ図またはコンテキスト図上位構造を示すために

4. 尋ねる：「ユーザーストーリーマップのほうがこの情報をより良く伝えるだろうか？」

  • 10個以上の «include»/«extend» 関係を使用している場合、図を次のように置き換えることを検討してください：

    • Aユーザーストーリーマップ

    • Aシナリオベースの表

    • Aシンプルなフローチャート主要な経路を含む

🔄 現代のトレンド：多くのアジャイルチームがユースケース図を完全に避けるまたは、それらを使用する上位レベルの発見のためだけに.

5. 「extend」は意味のあるバリエーションにのみ使用する

  • 「extend」は以下のものに限定するオプション、コアでない機能：

    • はまれに使用される

    • は文脈依存

    • は独立しているコア目標から独立している

✅ 例：
支払い処理（基本）
3Dセキュア認証を適用する（拡張）— 銀行によって要求された場合にのみ

❌ 避けるべき：
カード番号を入力する → カードを検証する → 支払い処理（すべては同じユースケースのステップでなければならない）

📊 概要：「include」と「extend」の黄金ルール

ルール ガイドライン
1. 「include」＝必須 以下のものにのみ使用する必須で再利用可能な2つ以上のユースケースに出現するステップ
2. «extend» = オプション 以下の状況でのみ使用する：条件付き、バリエーション、または稀な行動。
3. 基本のユースケースは完全でなければならない «extend»：基本は単独で動作する。«include»：基本はそれなしでは不完全である。
4. 簡単に保つ «include»/«extend»の後に4～6ステップ以内のユースケースである場合、過剰に分解している。
5. 読みやすさを最優先する 文章によるシナリオ > 複雑な図表。
6. チェーンを避ける A → B → C → D といった連鎖は禁止。1つの再利用可能なユースケースに再構成する。
7. ターゲットを理解する ステークホルダーは«include»の矢印には関心がない—彼らが关心するのは価値である.
8. 質問する：「これはユーザーの目標か、内部ステップか？」 アクターにとって目標でない場合は、ユースケースに含まれるべきでない可能性が高い。

🎯 最終的な考え：道具であり、罠ではない

«include»と«extend»は強力なツール—厳格なルールではない。設計意図は以下の通りである：

  • 重複の削減

  • 変異の管理

  • 保守性の向上

しかし、DFDにおける機能的分解のように、それらは危険な武器過剰に使用されると。本当の危険は関係そのものではなく、ユーザーの目的を見失う.

🔥 思い出してください:
ユースケースは技術的なプロセスではありません。
それはユーザーが達成したいことに関する物語—そしてシステムがどのように支援するか。

迷ったときは、自分に尋ねてください:

「UMLを知らなくてもユーザーはこれを理解できるだろうか？」
もしそうでないなら、簡潔にしましょう。
もしそうなら、正しい方向性に進んでいます。

📚 詳細な読書と参考文献

  • UML仕様書（OMG）: www.omg.org/spec/UML

  • マーティン・ファウラー – ユースケースモデリング: 分析パターン & UMLの要点

  • イヴァル・ヤコブソン – オブジェクトの利点：ユースケースに関する基盤的な研究

  • アジャイルモデリング（AM）スコット・W・アンブラー著

  • ユーザーストーリーマッピングジェフ・パタン著 – 複雑な図の現代的な代替手段

✅ 一文のルール

必須の再利用には「include」を使用し、オプションの変更には「extend」を使用するが、本当に価値をもたらす場合に限る。それ以外はシンプルに保つこと。

なぜなら最終的には、目的は完璧なものを描くことではなく、UML図—実際の人に実際の価値を提供するシステムを構築することである。

📌 著者による補足（2025–2026）:
チームが～へと移行する中で製品中心の, 価値志向の、そして協働型の開発へと移行する中で、従来のUML図の役割は進化している。「include」と「extend」は依然として有用だが、自制心、明確さ、目的を持って使用する場合に限る図ではなく、ユーザーに貢献させるようにしよう。

Related Posts

Recent Comments

表示できるコメントはありません。
Sidebar Search
Loading

Signing-in 3 seconds...

Signing-up 3 seconds...