インクルードと拡張のユースケース図の違いは何ですか？

違いは何であるincludeとextendにおけるユースケース図は？

Extendは、ユースケースが別のファーストクラスのユースケースにステップを追加するときに使用されます。

たとえば、「現金を引き出す」が現金自動預け払い機（ATM）の使用例だとします。「査定手数料」は、ウィズドローキャッシュを拡張し、ATMユーザーがATMの所有機関で銀行に預金しない場合にインスタンス化される条件付きの「拡張ポイント」を記述します。基本的な「Withdraw Cash」ユースケースは、拡張なしで、それ自体で成り立っていることに注意してください。

Includeは、複数のユースケースで重複するユースケースフラグメントを抽出するために使用されます。含まれているユースケースは単独では使用できず、元のユースケースは含まれているものなしでは完全ではありません。これは控えめに使用し、重複が重要であり、偶然ではなく設計によって存在する場合にのみ使用してください。

たとえば、すべてのATMユースケースの開始時に発生するイベントのフロー（ユーザーがATMカードを挿入し、PINを入力し、メインメニューが表示された場合）は、インクルードの良い候補になります。

これは議論の余地があるかもしれませんが、「インクルードは常にあり、エクステンドは時々ある」というのは、事実上の意味として今ほとんど引き継がれている非常に一般的な誤解です。ここに正しいアプローチがあります（私の見解では、Jacobson、Fowler、Larmen、および他の10の参照に対してチェックされています）。

関係は依存関係です

ユースケースの関係を含めて拡張するための鍵は、他のUMLと同様に、ユースケース間の点線の矢印が依存関係であることを認識することです。「ベース」、「インクルード」、「拡張」という用語を使用して、ユースケースの役割を示します。

含める

基本ユースケースは、含まれているユースケースに依存しています。含まれていない場合/含まれていない場合は、常に発生する可能性があるインタラクションのサブシーケンスを表すため、基本的なユースケースは不完全です。（これはこれについての一般的な誤解に反します。ユースケースが常にメインシナリオで発生し、代替フローで発生することが示唆するものは、単にメインシナリオとして選択したものに依存します。ユースケースは、別のフローを表すように簡単に再構築できます。メインシナリオとして、これは重要ではありません）。

一方向依存のベストプラクティスでは、ベースユースケースは含まれているユースケースを認識（および参照）しますが、含まれているユースケースはベースユースケースを「認識」してはなりません。これが、含まれているユースケースが次の理由になる場合がある理由です。

伸ばす

拡張ユースケースは、ベースユースケースに依存しています。基本的なユースケースで説明されている動作を文字通り拡張します。基本ユースケースは、拡張ユースケースの追加機能を使用せずに、それ自体が完全に機能するユースケース（「インクルード」はもちろん含まれています）でなければなりません。

拡張ユースケースは、いくつかの状況で使用できます。

1. 基本ユースケースはプロジェクトの「必須」機能を表し、拡張ユースケースはオプションの（推奨/推奨/推奨）動作を表します。これは、オプションという用語が関連する場所です。ベースユースケースシーケンスの一部として実行されるかどうかはオプションではなく、ビルド/配信するかどうかのオプションです。
2. フェーズ1では、その時点での要件を満たす基本ユースケースを提供できます。フェーズ2では、拡張ユースケースで説明されている機能を追加します。これには、フェーズ2が配信された後に常にまたは時々実行されるシーケンスが含まれている可能性があります（これも一般的な誤解に反しています）。
3. これは、特にそれらが独自の代替フローで「例外的な」複雑な動作を表す場合に、ベースユースケースのサブシーケンスを抽出するために使用できます。

考慮すべき重要な側面の1つは、拡張ユースケースが、組み込みユースケースのように1つの場所だけでなく、基本ユースケースのフローの複数の場所に動作を「挿入」できることです。このため、拡張ユースケースが複数の基本ユースケースを拡張するのに適している可能性はほとんどありません。

依存関係に関しては、拡張ユースケースは基本ユースケースに依存し、これも一方向の依存関係です。つまり、基本ユースケースは、シーケンス内の拡張ユースケースへの参照を必要としません。これは、拡張ポイントを示したり、テンプレートの他の場所で拡張ユースケースにx-refを追加したりできないことを意味するわけではありませんが、基本ユースケースは、拡張ユースケースがなくても機能する必要があります。

概要

「インクルードは常にあり、エクステンドは時々ある」という一般的な誤解が間違っているか、せいぜい単純化していることを示したことを願っています。このバージョンは、誤解がもたらす矢印の方向性に関するすべての問題を考慮すると、より意味があります。正しいモデルでは、依存関係のみであり、ユースケースの内容をリファクタリングしても変更されない可能性があります。

私はよくこれを使用して2つを覚えています：

私の使用例：私は都市に行きます。

含まれている->車を運転する

延長->ガソリンを充填

「ガソリンを補充する」は常に必要なわけではありませんが、車内に残っているガソリンの量に基づいて必要に応じて必要になる場合があります。「車を運転する」は前提条件なので、ここに含めます。

ユースケースは、この質問に答えるなど、行動を文書化するために使用されます。

行動は、行動の一部であるが必ずしもその一部ではない場合、別のものを拡張します。たとえば、回答を調査します。

また、質問に答えようとしない限り、答えを調査しても意味がありません。

スタック交換へのログインなど、動作が包含動作の一部である場合、その動作は別の動作に含まれます。

明確にするために、この図は、ここでスタックオーバーフローで答えたい場合にのみ当てはまります:)。

これらは、UML 2.5ページ671〜672 の技術定義です。

私が重要だと思うことを強調しました。

伸びる

Extendは、拡張UseCase（拡張）から拡張UseCase（extendedCase）への関係であり、拡張UseCaseで定義された動作を拡張UseCaseで定義された動作に挿入する方法とタイミングを指定します。拡張は、拡張UseCaseで定義された1つ以上の特定の拡張ポイントで行われます。

Extendは、1つ以上のUseCaseで定義された動作に、おそらく条件付きで追加する必要があるいくつかの追加動作がある場合に使用することを目的としています。

拡張ユースケースは、独立に延びるユースケースの定義され、独立して延びるユースケースの意味があります。一方、拡張UseCaseは通常、それ自体では必ずしも意味がない動作を定義します。代わりに、拡張UseCaseは、特定の条件下での拡張UseCaseの実行を強化する一連のモジュール動作インクリメントを定義します。

...

含む

Includeは、2つのUseCase間のDirectedRelationshipであり、インクルードされたUseCase（追加）の動作が、インクルードするUseCase（includeingCase）の動作に挿入されることを示します。これはNamedElementの一種でもあるため、所有するUseCase（includeingCase）のコンテキストで名前を持つことができます。インクルードするUseCaseは、インクルードされたUseCaseを実行することによって生成される変更に依存する場合があります。含まれているUseCaseの動作を完全に説明するには、含まれているUseCaseが利用可能である必要があります。

Include関係は、2つ以上のUseCaseの動作に共通の部分がある場合に使用することを目的としています。この 共通部分は、別のUseCaseに抽出され、この部分が共通するすべての基本UseCaseに含まれます。Include関係の主な用途は一般的なパーツの再利用であるため、ベースのUseCaseに残されるものは通常それ自体では完全ではなく、含まれるパーツに依存して意味があります。これは関係の方向に反映され、基本のUseCaseは追加に依存しますが、その逆はありません。

...

includeとextendsの意図を理解することが重要だと思います：

「関係が意図される含む再利用することによってモデル化された行動別のユースケースを延ばす関係が意図されているのに対し、 追加既存のユースケースに部品を同様のようにモデル化するためのオプション（オーバーガードとPalmkvist、ユースケースシステムサービス」：パターンと青写真をアディソン-ウェズリー、2004年）。

これは私に次のように読みます：

インクルード= 機能の再利用（つまり、インクルードされた機能が使用されている、またはシステムの他の場所で使用できる）。したがって、インクルードは別のユースケースへの依存関係を示します。

=延び追加機能と（再利用しない）、また、任意のオプション機能を。したがって、Extendsは次の2つのいずれかを示し
ます。1。ユースケースへの新しい機能/機能の追加（オプションかどうか）
2. オプションのユースケース（既存かどうか）。

要約：
インクルード=機能の再利用
Extends =新規および/またはオプションの機能

ほとんどの場合、拡張の2番目の使用法（つまり、オプション機能）が見つかります。これは、機能がオプションではない場合、ほとんどの場合、拡張ではなくユースケース自体に組み込まれているためです。少なくともそれは私の経験でした。（Julian Cは、プロジェクトが2番目のフェーズに入ったときに、extendsの最初の使用法（つまり、新しい機能の追加）が見られることを指摘しています）。

簡単にするために、

ために include

1. 基本ユースケースが実行されると、含まれているユースケースがEVERYTIMEで実行されます。
2. 基本ユースケースを完了するには、含まれているユースケースを完了する必要がありました。

典型的な例：ログインとパスワードの確認の間

（ログイン）--- <<含める>> --- >（パスワードの確認）

ログインプロセスを成功させるには、「パスワードの確認」も成功する必要があります。

ために extend

1. 基本ユースケースが実行されると、拡張ユースケースはSOMETIMESだけ実行されます
2. 拡張ユースケースは、特定の基準が満たされた場合にのみ発生します。

典型的な例：ログインとエラーメッセージの表示の間（ときどき発生するだけ）

（ログイン）< --- <<拡張>> ---（エラーメッセージを表示）

「エラーメッセージを表示」は、ログインプロセスが失敗した場合にのみ発生します。

ここで msdnが説明したことは非常に理解しやすいと思います。

含める [5]

組み込みユースケースは、組み込みユースケースを呼び出すか、呼び出します。インクルージョンは、ユースケースがどのように小さなステップに分割されるかを示すために使用されます。含まれている使用例は、矢先にあります。

延長 [6]

一方、拡張ユースケースは、拡張ユースケースに目標とステップを追加します。拡張機能は特定の条件下でのみ動作します。拡張されたユースケースは矢じりの端にあります。

これをより明確にしましょう。私たちはinclude、あるケースの存在が別のケースの存在に依存するという事実を表現したいときはいつでも使用します。

例：

ユーザーは、自分のアカウントにログインした後にのみオンラインショッピングを行うことができます。言い換えると、彼は自分のアカウントにログインするまで買い物をすることができません。

素材がアップロードされるまで、ユーザーはサイトからダウンロードできません。そのため、何もアップロードされていないとダウンロードできません。

わかりますか？

それは条件付きの結果についてです。以前にそれをしなかった場合、私はこれを行うことができません。

少なくとも、これは私たちが使用する正しい方法だと思いますInclude。私はラップトップの例と真上からの保証が最も説得力があると思う傾向があります！

ユースケースに前提条件がある場合はいつでも、インクルードに進んでください。

認証があるユースケースの場合、最悪のシナリオ、またはオプションの場合は、延長に進みます。

例：入場、予約、チケット予約を求める使用例の場合、フォーム（登録またはフィードバックフォーム）に記入する必要があります。

例：ログインまたはアカウントへのサインインを確認するユースケースの場合、認証は必須です。最悪の場合のシナリオも考えてください。本を返却して罰金を科せます。予約を取得できません。延長がどこに来るか...

図に含めたり拡張したりして使いすぎないでください。

シンプルなシリーを保つ!!!

また、UMLバージョンにも注意してください。長い間、<<使用>>と<<インクルード>>が<<インクルード>>に、<<拡張>>と<<拡張>> AND汎化に置き換えられています。
私にとってそれはしばしば誤解を招くポイントです：例として、ステファニーの投稿とリンクは古いバージョンについてです：

アイテムの支払い時には、代金引換、paypalを使用した支払い、またはカードによる支払いを選択できます。これらはすべて「アイテムの支払い」ユースケースの代替手段です。私の好みに応じて、これらのオプションのいずれかを選択できます。

実際、「アイテムの支払い」に代わる方法はありません。最近のUMLでは、「代金引換」は延長であり、「paypalを使用した支払い」/「カードによる支払い」は専門分野です。

「インクルード」は、ベースユースケースを拡張するために使用され、必須条件です。つまり、インクルードユースケースの実行は、ベースユースを完了するために正常に実行される必要があります。

たとえば、メールサービスのケースを考えてみましょう。ここでの「ログイン」は、メールを送信するために実行する必要がある、含まれているユースケースです（基本ユースケース）。

一方、「除外」は、基本ユースケースを拡張するオプションのユースケースです。基本ユースケースは、拡張ユースケースを呼び出したり呼び出したりしなくても正常に実行できます。

たとえば、「ラップトップ購入」を基本ユースケースとして検討し、「追加保証」を拡張ユースケースとして検討します。ここでは、追加の保証を受けることなく、基本ユースケース「ラップトップ購入」を実行できます。

これは優れたリソースであり、優れた説明 があります。ユースケースに含まれるものは何ですか？ ユースケースでの拡張とは何ですか？

ユースケースの拡張は、通常、オプションの動作を定義します。それは拡張ユースケースから独立しています

2つ以上のユースケースの動作の共通部分を抽出するために使用されるインクルード

図の要素

• アクター：ロールとも呼ばれます。アクターの名前とステレオタイプは、その[プロパティ]タブで変更できます。

• 継承：アクター間のリファインメント関係。この関係には、名前とステレオタイプを含めることができます。

• ユースケース：これらは拡張ポイントを持つことができます。

• 拡張ポイント：これは、拡張機能を追加できる場所を定義します。

• 関連付け：役割とユースケースの間。関連を話す名前を付けると便利です。

• 依存関係：ユースケース間。多くの場合、依存関係には、依存関係の役割をより適切に定義するためのステレオタイプがあります。ステレオタイプを選択するには、図またはナビゲーションペインから依存関係を選択し、[プロパティ]タブでステレオタイプを変更します。依存関係には2つの特別な種類があります。<<extend>>および<<include>>には、Poseidonが独自のボタンを提供します（以下を参照）。

• 関係の拡張：2つのユースケース間の単方向の関係。ユースケースBとユースケースAの拡張関係は、Bの動作をAに含めることができることを意味します。

• 包含関係：2つのユースケース間の単方向の関係。このようなユースケースAとBの関係は、Bの動作が常にAに含まれることを意味します。

• システム境界：システム境界は、実際にはPoseidon for UMLのモデル要素として実装されていません。長方形を描き、それを背景に送信して、対応するすべてのユースケースを長方形の中に配置することで、システムの境界線として使用できます。

<include>と<extend>はどちらも基本クラスに依存しています<extend>が、オプションです。つまり、基本クラスから派生していますが、ユーザーの観点からは、使用することも使用しないこともあります。

<include>つまり、基本クラスに組み込まれています。つまり、<include>ユースケースでの使用は必須であり、そうでない場合は不完全と見なされます。

例えば：

ATMの機械構造では（ユーザーの観点から）：

１：出金・預金・小切手<extend>は利用者に依存するため、出金・現金の預金・口座確認が対象となります。これらは、ユーザーが行うオプションの処理です。

2：「ピンの入力、カードの配置、カードの取り外し」は<include>、ユーザーがカードを配置し、検証のために有効なピンを入力する必要があるため、これが原因です。

この2つを覚えておくことはお勧めしません。

私の使用例：私は都市に行きます。

含まれている->車を運転する

延長->ガソリンを充填

私はむしろあなたが使いたいです：私のユースケース：私は都市に行きます。

延長->車の運転

含まれている->ガソリンを満たす

拡張関係が基本クラスの動作を継続することを教えられています。基本クラスの機能が必要です。一方、include関係は、呼び出される可能性のある関数に似ています。5月は太字です。

これは、ユースケースモデルでのアジャイルモデリングの再利用から確認できます。

ここでは、両者の違いについて説明しました。しかし、どのような説明されていないことは事実である<<include>>と<<extend>>単純にすべてで使用すべきではありません。

Bittner / Spenceを読むと、ユースケースは分析ではなく合成に関するものであることがわかります。ユースケースの再利用はナンセンスです。ドメインを誤って削除したことを明確に示しています。付加価値はそれ自体がユニークでなければなりません。私が知っている付加価値の唯一の再利用は、フランチャイズです。だから、あなたがハンバーガービジネスをしているなら、いいです。しかし、他のあらゆる場所でBAとしてのあなたの仕事は、USPを見つけることです。そして、それは良いユースケースで提示されなければなりません。

私が人々がそれらの関係の1つを使用しているのを見たときはいつでも、彼らは機能分解をしようとするときです。そして、それは明らかに間違っています。

簡単に言うと、上司に迷わずに「私はやった...」と答えることができれば、「...」はあなたがそれを行うためのお金を得たので、あなたのユースケースです。（これにより、「ログイン」はユースケースではないことが明らかになります。）

その点で、他のユースケースに含まれている、または拡張されている自立型のユースケースを見つけることはほとんどありません。最終的に<<extend>>は、システムのオプション性を示すために使用できます。つまり、一部のライセンスの使用例を含めたり、省略したりできる一部のライセンススキーマです。しかし、それ以外の場合は、それらを避けてください。

伸びるは、ユースケースが非常に複雑であることを理解したときに使用されます。したがって、複雑なステップを独自の「拡張」ユースケースに抽出します。

インクルードは、2つの使用例で一般的な動作が見られる場合に使用されます。したがって、一般的な動作を別の「抽象的な」ユースケースに抽象化します。

（参照：Jeffrey L. Whitten、Lonnie D. Bentley、システム分析および設計方法、McGraw-Hill / Irwin、2007年）

含む関係が一度使う場合は、別の使用ケースのステップを含めることができます。

たとえば、Amazonアカウントがあり、注文を確認したい場合、最初にアカウントにログインしないと注文を確認することはできません。だからイベントの流れはそうしたい...

延長の関係は、通常はオプションのステップであるユースケースの流れに余分なステップを、追加するために使用されています...

まだあなたのAmazonアカウントについて話していると想像してください。基本ケースがOrderで、拡張ユースケースがAmazon Primeであるとしましょう。ユーザーは、定期的にアイテムを注文するか、Amazon Primeを選択するオプションを選択できます。これにより、注文がより高いコストでより早く届くようになります。

ただし、ユーザーはAmazon Primeを選択する必要はありません。これは単なるオプションであり、この使用例を無視することを選択できます。

「インクルード」は、基本ユースケースの必要な前提条件/付随物として考えるのが好きです。つまり、ベースユースケースは、それに含まれるユースケースなしでは完全なものとは見なされません。顧客にアイテムを販売するeコマースWebサイトの例を示します。最初にそのアイテムを選択してカートに入れることなしにアイテムを支払うことができる方法はありません。これは、ユースケース「アイテムの支払い」に「アイテムの選択」が含まれることを意味します。

extendsの使用法はさまざまですが、使用する場合と使用しない場合がある代替として考えたいと思います。たとえば、まだeコマースサイトです。アイテムの支払い時には、代金引換、paypalを使用した支払い、またはカードによる支払いを選択できます。これらはすべて「アイテムの支払い」ユースケースの代替手段です。私の好みに応じて、これらのオプションのいずれかを選択できます。

より明確にして、ユースケースを取り巻くルールについては、私の記事をここで読んでください：

http://businessanalystlearnings.com/ba-techniques/2013/2/20/use-case-diagram-the-basics