Extend は、ユースケースが別のファーストクラスのユースケースにステップを追加するときに使用されます。
たとえば、「現金の引き出し」が現金自動預け払い機（ATM）のユースケースであるとします。 "Assess Fee"はWithdraw Cashを拡張し、ATMユーザーがATMの所有機関に入金しない場合にインスタンス化される 条件付き "extension point"を記述します。基本的な "Withdraw Cash"ユースケースは拡張なしでそれ自身で成り立つことに注意してください。
Include は、複数のユースケースで 複製 であるユースケースフラグメントを抽出するために使用されます。含まれているユースケースは単独では成り立たず、最初のユースケースは含まれていない限り完全ではありません。これは控えめに、そして重複が重要であり、（偶然ではなく）設計によって存在する場合にのみ使用されるべきです。
たとえば、すべてのATMユースケースの開始時（ユーザーが自分のATMカードに入れてPINを入力してメインメニューが表示されているとき）に発生するイベントのフローは、インクルードに適した候補です。
これは議論の余地があるかもしれませんが、「含むことが常にあり、拡張があることもあります」は非常に一般的な誤解であり、事実上の意味として現在ほとんど受け継がれています。これが正しいアプローチです（私の見解では、Jacobson、Fowler、Larmen、その他10の参考文献と照らし合わせてチェックしています）。
関係は依存関係です
ユースケースの関係を含めて拡張するための鍵は、他のUMLと同様に、ユースケース間の点線の矢印が依存関係であることを認識することです。ユースケースの役割を表すために、「基本」、「含まれる」、「拡張」という用語を使用します。
含める
基本ユースケースは、含まれているユースケースに依存します。それがなければ、含まれるユースケースは常にORに起こる可能性のある対話のサブシーケンスを表すため、基本的なユースケースは不完全です。 （これはよくある誤解とは反対です。ユースケースが示唆するものは常にメインシナリオで発生し、代替フローで発生することもあります。単にメインシナリオとして選択したものによって異なります。ユースケースは別のフローを表すように簡単に再構築できます。主なシナリオとして、これは重要ではないはずです。
一方向の依存関係のベストプラクティスでは、基本ユースケースは包含ユースケースを認識していますが、包含ユースケースは基本ユースケースを「知っている」べきではありません。これが、含まれるユースケースが以下のようになる理由です。a）独自の基本ユースケース、およびb）多数の基本ユースケースによって共有される。
伸びる
拡張ユースケースは基本ユースケースに依存します。基本的なユースケースで説明されている動作を文字通り拡張します。基本ユースケースは、拡張ユースケースの追加機能なしで、それ自体が完全に機能的なユースケースである必要があります（「含める」ことはもちろん含まれます）。
拡張ユースケースは、いくつかの状況で使用できます。
- 基本ユースケースはプロジェクトの「必須」機能を表し、拡張ユースケースはオプションの（するべきであるかどうかにかかわらず）振る舞いを表します。これはオプションという用語が関連するところです - それが時々基本的なユースケースシーケンスの一部として実行されるかどうかオプションではなく構築/提供するかどうかオプション。
- フェーズ1では、その時点での要件を満たす基本ユースケースを提供できます。フェーズ2では、拡張ユースケースで説明されている追加機能を追加します。これには、フェーズ2が配信された後に常にまたは時々実行されるシーケンスを含めることができます（これもまた一般的な誤解に反して）。
- 基本的なユースケースのサブシーケンスを抽出するために使用することができます。特に、それらが独自の代替フローを伴う「例外的な」複雑な動作を表す場合には可能です。
考慮すべき重要な側面の1つは、拡張されたユースケースでは、含まれるユースケースのように1箇所だけではなく、基本ユースケースのフロー内の複数の場所に動作を「挿入」できることです。このため、拡張ユースケースが複数の基本ユースケースを拡張するのに適しているとは考えにくいです。
依存性に関しては、拡張ユースケースは基本ユースケースに依存しており、また一方向の依存関係です。つまり、基本ユースケースはシーケンス内で拡張ユースケースへの参照を必要としません。つまり、テンプレート内の他の場所で拡張ポイントを説明したり拡張ユースケースにx-refを追加したりできないという意味ではありませんが、基本ユースケースでは拡張ユースケースがなくても機能する必要があります。
概要
「常に含む、時には拡張する」という一般的な誤解が間違っているか、せいぜい単純化されていることを示したことを願っています。誤解が示す矢印の方向性に関するすべての問題を考慮すると、このバージョンは実際にはもっと意味があります。正しいモデルではそれは単なる依存関係であり、ユースケースの内容をリファクタリングしても変わることはありません。
私はこれをよく2つのことを思い出すために使用します。
私のユースケース：私は街に行きます。
含む - >車を運転する
拡張 - >ガソリンを埋める
「ガソリンをいっぱいにする」は常に必要というわけではありませんが、車内に残っているガソリンの量に基づいて必要に応じて必要な場合があります。 「車を運転する」ことが前提条件です。
ユースケースは、動作を文書化するために使用されます。この質問に答えてください。
ビヘイビアは、ビヘイビアの一部であるが必ずしもそうではない場合、他のビヘイビアを拡張します。答えを調べてください。
また、質問に答えようとしないのであれば、答えを調査しても意味がありません。
ビヘイビアは、インクルードビヘイビアの一部である場合、別のビヘイビアに含まれます。スタック交換にログインします。
明確にするために、この図はスタックオーバーフローでここで答えたい場合にのみ当てはまります：）。
これらは ML 2.5 ページ671-672の技術的定義です。
重要だと思うことを強調しました。
拡張
Extendは関係です拡張UseCaseから（拡張）拡張UseCaseに（extendedCase）動作の定義方法とタイミングを指定します拡張ユースケースでは、拡張ユースケースで定義された動作に挿入できます。拡張は、拡張UseCaseで定義された1つ以上の特定の拡張ポイントで行われます。
Extendは、1つ以上のUseCasesで定義された動作に場合によってはを追加する必要がある追加の動作がある場合に使用することを目的としています。
extended UseCaseは、拡張UseCaseとは独立して定義され、拡張UseCaseとは独立して意味があります。一方、拡張UseCaseは通常、必ずしもそれ自体で意味があるとは限らないという動作を定義します。代わりに、拡張UseCaseは、特定の条件下で拡張UseCaseの実行を強化する一連のモジュラー動作増分を定義します。
...
含む
Includeは、2つのUseCase間のDirectedRelationshipであり、含まれるUseCase（追加）含まれるUseCaseの動作に挿入されるの動作を示します。 （含むケース）。また、NamedElementの一種であるため、所有するUseCase（includeCase）のコンテキストで名前を持つことができます。含まれるUseCaseは、含まれているUseCaseを実行することによって生じる変更に依存する場合があります。含まれているUseCaseの動作を完全に説明するには、含まれているUseCaseが使用可能でなければなりません。
Include関係は、2つ以上のUseCaseの動作に共通部分がある場合に使用することを目的としています。この共通部分は別のUseCaseに抽出され、この部分を共有するすべてのベースUseCaseに含まれます。 Include関係の主な用途は一般的なパーツの再利用であるため、ベースUseCaseは通常それ自体では完全ではありませんに残されていますが、意味のある含まれるパーツに依存しています。これは関係の方向に反映され、ベースUseCaseは追加に依存するが、その逆には依存しないことを示します。
...
インクルードと拡張の意図を理解することは重要だと思います。
「包含関係は再利用別のユースケースによってモデル化された動作を対象としていますが、拡張関係は追加既存のユースケースへのパーツを対象としています- 同様モデリング用オプションシステムサービス」（Overgaard and Palmkvist、ユースケース：パターンと設計図、Addison-Wesley、2004年）。
これは次のように読みます。
インクルード= 再利用機能性（つまり、インクルードされた機能が使用されるか、システムの他の場所で使用される可能性があります）。したがって、インクルードは別のユースケースへの依存関係を示します。
Extends = 追加（再利用しない）機能および（） any optional機能。したがって、Extendsは次の2つのいずれかを示すことができます。
1。 new機能/機能をユースケースに追加（オプションかどうか）
2。 any オプションユースケース（存在するかどうか）。
概要：
含める=機能の再利用
Extends =新機能および/またはオプション機能
機能がオプションではない場合、ほとんどの場合、拡張機能ではなくユースケース自体に組み込まれているため、extendsの2番目の使用法（つまり、オプション機能）が見つかります。少なくともそれは私の経験でした。 （Julian Cは、プロジェクトが第2フェーズに入ったときに、extendsの最初の使用法（つまり、新しい機能の追加）が表示されることがあると指摘しています）。
これをより明確にしましょう。あるケースの存在が別のケースの存在に依存するという事実を表現したいときはいつもincludeを使います。
例：
ユーザーは自分のアカウントにログインした後にのみオンラインショッピングを行うことができます。言い換えれば、彼は自分のアカウントにログインするまで買い物をすることができません。
ユーザは、資料がアップロードされる前にサイトからダウンロードすることはできません。そのため、何もアップロードされていないとダウンロードできません。
あなたはそれを手に入れますか？
それは条件付きの結果についてです。 以前にやっていなかったらこれができない 。
少なくとも、これがIncludeの正しい使い方だと私は思います。私はラップトップと真上からの保証の例が最も説得力があると思う傾向があります！
私はmsdnが説明したこと ここ を理解するのはとても簡単だと思います。
含める [5]
包含ユースケースは、包含ユースケースを呼び出すか呼び出す。包含は、ユースケースがどのように小さなステップに分割されるかを示すために使用されます。同梱のユースケースは矢尻にあります。
延長 [6]
一方、拡張ユースケースは拡張ユースケースに目標とステップを追加します。拡張機能は特定の条件下でのみ機能します。拡張ユースケースは矢じりの端にあります。
簡単にすると
includeの場合
- 基本ユースケースが実行されると、含まれるユースケースは _ everytime _ が実行されます。
- 基本ユースケースが完了するためには、含まれているユースケースの完成が必要でした。
典型的な例：ログインとパスワードの確認の間
（login）--- << include >> --- > （パスワードを確認）
ログインプロセスが成功するには、「パスワードの確認」も成功する必要があります。
extendの場合
- 基本ユースケースが実行されると、拡張ユースケースのみが実行されます _ときには_
- 拡張ユースケースは、特定の基準が満たされた場合にのみ発生します。
典型的な例：ログインとエラーメッセージの表示の間（時々起こる）
（login） < --- << extend >> ---（エラーメッセージを表示する）
「show error message」はログインプロセスが失敗した場合にのみ発生します。
ユースケースに必要条件があるときはいつでも、インクルードに行きます。
認証を持つユースケース、最悪の場合のシナリオ、またはオプションの場合は、次に進みます。
例：入場、予約、チケット予約を求めるユースケースの場合は、フォーム（登録またはフィードバックフォーム）に記入する必要があります。
例：ログインを確認するユースケース、またはアカウントにサインインするには、あなたの認証は必須です。 extendが効くところは….
ダイアグラムにインクルードしたり、拡張したりしないでください。
それを単純に守ってください!!!
「インクルード」は基本ユースケースを拡張するために使用され、これは必須条件です。つまり、組み込みユースケースの実行は、基本ユースケースを完了するために正常に実行される必要があります。
例えばEメールサービスのケースを考えてみてください。ここで「ログイン」はEメールを送信するために実行されなければならない含まれたユースケースです（基本ユースケース）
一方、 "Exclude"は基本ユースケースを拡張するオプションのユースケースです。拡張ユースケースを呼び出したり呼び出したりしなくても、基本ユースケースは正常に実行できます。
例えば基本ユースケースとして「ノートパソコン購入」を、拡張ユースケースとして「追加保証」を検討してください。ここでは、追加保証を受けなくても基本ユースケース「ノートパソコン購入」を実行できます。
また、UMLバージョンにも注意してください。<< uses >>および<< includes >>が<< include >>に置き換えられ、<< extends >>が << extend >> ANDに置き換えられたのは昔からあります一般化 。
私にとっては、それが誤解を招く点です。たとえば、ステファニーの投稿とリンクは古いバージョンに関するものです。
アイテムの支払いをするとき、あなたは配達で支払う、Paypalを使って支払う、またはカードで支払うことを選ぶかもしれません。これらはすべて「商品の支払い」ユースケースの代替手段です。私は私の好みに応じてこれらのオプションのどれでも選ぶことができます。
実際には「商品の代金を払う」に代わるものは本当にありません！今日のUMLでは、「代金引換」は拡張であり、「ペイパルを使用した支払」/「カードによる支払」は特殊化です。
これは素晴らしい説明がある素晴らしいリソースです： ユースケースに含まれるものは何ですか？ユースケースでのExtendとは何ですか？
拡張ユースケースは通常、オプションの動作を定義します。拡張ユースケースの 独立
2つ以上のユースケースの動作の共通部分を抽出するために使用される
Extends は、ユースケースが複雑すぎることを理解している場合に使用されます。そこで、複雑なステップをそれぞれ独自の「拡張」ユースケースに展開します。
含む 2つのユースケースで共通の動作が見られる場合に使用します。それで、あなたは共通の振る舞いを別の「抽象的な」ユースケースに要約します。
（ref：Jeffrey L. Whitten、Lonnie D. Bentley、システム分析と設計法、McGraw-Hill/Irwin、2007）
<include>と<extend>は両方とも基本クラスに依存していますが、<extend>はオプションです。つまり、基本クラスから派生していますが、ユーザーから見ると使用される場合と使用されない場合があります。
<include>は基本クラスに組み込まれています。つまり、ユースケースで<include>を使用することは必須です。そうしないと、不完全と見なされます。
例：
ATM機の製造において（ユーザーの視点によると）：
1：引き出し、預け入れ、または小切手かどうかはユーザーによって異なるため、引き出し、現金の預け入れ、および口座のチェックは<extend>の下に行われます。これらはユーザーが行うオプションのことです。
2：「ピンの入力、カードの配置、カードの取り外し」これらは<include>の下にくるものです。これは、ユーザーがカードを配置し、確認のために有効なピンを入力する必要があるためです。
include の関係により、あるユースケースに別のユースケースのステップを含めることができます。
たとえば、Amazonアカウントを持っていて、注文を確認したいとします。最初に自分のアカウントにログインせずに注文を確認することは不可能です。それで、イベントの流れはそうしたいです...
extend の関係は、ユースケースのフローに追加のステップを追加するために使用されます。これは通常、オプションのステップです...
我々はまだあなたのAmazonアカウントについて話していると想像してください。基本ケースをOrder、拡張機能の使用ケースをAmazon Primeとします。ユーザーは定期的に商品を注文するか、Amazon Primeを選択するかを選択できます。これにより、注文がより高いコストでより早く届くようになります。
ただし、ユーザーがAmazon Primeを選択する必要はなく、これは単なるオプションであり、このユースケースを無視することを選択できます。
この2つを覚えておくためにこれを使用することはお勧めしません。
私のユースケース：私は街に行きます。
含む - >車を運転する
拡張 - >ガソリンを埋める
私はあなたが使用したいと思います：私のユースケース：私は街に行きます。
拡張 - >車を運転する
含む - >ガソリンを埋める
拡張関係は基本クラスの振る舞いを継続すると教えられています。基本クラスの機能はそこになければなりません。一方、包含関係は、呼び出される可能性がある関数に似ています。 5月は大胆です。
ダイアグラム要素
アクター：ロールとも呼ばれます。アクターの名前とステレオタイプは、その[プロパティ]タブで変更できます。
継承：アクター間のリファインメント関係。この関係は名前とステレオタイプを運ぶことができます。
ユースケース：これらは拡張ポイントを持つことができます。
拡張ポイント：これは拡張が追加されることができる位置を定義します。
関連付け：役割とユースケースの間。名前を話す関連付けを付けると便利です。
依存関係：ユースケース間。依存関係には、依存関係の役割をより明確に定義するための固定観念があります。ステレオタイプを選択するには、ダイアグラムまたはナビゲーション区画から依存関係を選択してから、「プロパティー」タブでステレオタイプを変更します。依存関係には2つの特別な種類があります：
<<extend>>と<<include>>、それに対してPoseidonは独自のボタンを提供します（下記参照）。関係の拡張：2つのユースケース間の一方向の関係。ユースケースBとユースケースAの間の拡張関係は、Bの動作をAに含めることができることを意味します。
関係を含める：2つのユースケース間の一方向の関係。ユースケースAとBのこのような関係は、Bの動作が常にAに含まれることを意味します。
システム境界：システム境界は、実際にはPoseidon for UMLのモデル要素としては実装されていません。対応するすべてのユースケースを矩形の内側に配置することで、矩形を描画し、それを背景に送信してシステム境界として使用することができます。
両者の違いはここで説明されています。しかし、説明されていないのは、<<include>>と<<extend>>は、まったく使われるべきではないという事実です。
Bittner/Spenceを読むと、ユースケースは合成ではなく分析であることがわかります。ユースケースの再利用は意味がありません。それは明らかにあなたがあなたのドメインを誤って切断したことを示しています。付加価値はそれ自体がユニークでなければなりません。私が知っている付加価値の唯一の再利用はフランチャイズです。だからあなたがハンバーガービジネスをしているのなら、ニース。しかし他の至る所であなたの学士号としての任務はUSPを見つけることを試みることです。そしてそれは良いユースケースで提示されなければなりません。
私が人々がそれらの関係の1つを使っているのを見る時はいつでも、彼らは機能的分解をやろうとしている時です。そしてそれは明らかに間違っています。
簡単に言うと、「私はやりました...」と躊躇せずに上司に答えることができれば、「...」はあなたがそれをするためのお金を得ているのであなたのユースケースです。 （それはまた、 "login"がまったくユースケースではないことを明らかにします。）
その点で、他のユースケースに含まれているか拡張している自立型のユースケースを見つけることはほとんどありません。やがて<<extend>>を使ってあなたのシステムの選択性を示すことができます。つまり、いくつかのライセンスのユースケースを含めることやそれらを省略することを可能にする何らかのライセンススキーマです。しかしそれ以外は避けてください。
私は「含む」を基本的なユースケースの必要な前提条件/伴奏として考えるのが好きです。つまり、基本ユースケースに含まれるユースケースがないと、その基本ユースケースを完全と見なすことはできません。商品を顧客に販売するeコマースWebサイトの例を挙げます。最初に商品を選択してカートに入れることなしに商品の代金を支払うことはできません。これは、ユースケース「アイテムの支払い」に「アイテムの選択」が含まれることを意味します。
Extendの使い方はいろいろありますが、私はそれを代わりに使っても使わなくてもよいと考えるのが好きです。たとえば - まだeコマースサイトにあります。アイテムの支払いをするとき、あなたは配達で支払う、Paypalを使って支払う、またはカードで支払うことを選ぶかもしれません。これらはすべて「商品の支払い」ユースケースの代替手段です。私は私の好みに応じてこれらのオプションのどれでも選ぶことができます。
より明確にし、ユースケースを取り巻く規則については、私の記事をここで読んでください。
http://businessanalystlearnings.com/ba-techniques/2013/2/20/use-case-diagram-the-basics