426

ユースケース図におけるincludeとの違いは何ですか?extend

4

19 に答える 19

131

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

関係は依存関係です

ユース ケースの関係を含めて拡張するための鍵は、UML の他の部分と同様に、ユース ケース間の点線の矢印が依存関係であることを理解することです。ユース ケースの役割を表すために、「ベース」、「含まれる」、「拡張する」という用語を使用します。

含む

ベース ユース ケースは、含まれるユース ケースに依存します。含まれているユースケースは、常にまたは時々発生する可能性のある相互作用のサブシーケンスを表すため、それ/それらがなければ、基本的なユースケースは不完全です。(これは、これに関する一般的な誤解とは対照的です。ユース ケースが示唆することは、常にメイン シナリオで発生し、代替フローで時々発生することは、単にメイン シナリオとして選択したものに依存します。ユース ケースは、別のフローを表すように簡単に再構築できます。主なシナリオとして、これは重要ではありません)。

一方向の依存関係のベスト プラクティスでは、ベース ユース ケースは含まれるユース ケースを認識 (および参照) しますが、含まれるユース ケースはベース ユース ケースを「認識」してはなりません。これが、含まれるユース ケースが、a) 独自のベース ユース ケース、および b) 多数のベース ユース ケースで共有される場合がある理由です。

拡張する

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

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

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

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

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

まとめ

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

于 2010-12-17T16:46:00.430 に答える
101

私はよくこれを使って 2 つのことを覚えています。

私のユースケース: 私は街に行きます。

含む -> 車を運転する

伸びる -> ガソリンを入れる

「ガソリンを入れる」は常に必要なわけではありませんが、車に残っているガソリンの量に基づいてオプションで必要になる場合があります。「車を運転する」ことが前提条件なので含めています。

于 2013-07-03T13:01:29.253 に答える
30

インクルードとエクステンドの意図を理解することが重要だと思います:

「include リレーションシップは、別のユース ケースによってモデル化された動作を再利用することを目的としています。一方、extend リレーションシップは、 既存のユース ケースにパーツを追加すること、およびオプションのシステム サービスをモデル化することを目的としています」(Overgaard and Palmkvist、Use Cases: Patterns and Blueprints. Addison -ウェズリー、2004年)。


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

含める =機能の再利用(つまり、含まれている機能がシステムの他の場所で使用されるか、使用される可能性がある)。したがって、インクルードは別のユースケースへの依存を示します。

拡張 =機能の追加(再利用ではない) と、任意のオプション機能。したがって、拡張は次の 2 つのことのいずれかを表す ことが
できます。

要約:
含める = 機能の再利用
拡張 = 新しい機能および/またはオプションの機能

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

于 2012-04-14T08:25:59.990 に答える
15

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

例:

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

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

分かりますか？

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

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

于 2012-11-27T13:36:26.797 に答える
9

ユースケースに前提条件がある場合はいつでも、含めるようにします。

認証を使用するユースケース、最悪のシナリオ、またはオプションの場合は、拡張に進みます..

例: 入場、予約、チケット予約を求めるユース ケースの場合、フォーム (登録またはフィードバック フォーム) に記入する必要があります。

例: アカウントへのログインまたはサインインを確認するユースケースでは、認証が必須です。また、最悪のシナリオも考えてください。罰金を払って本を返却する、予約が取れない、期日を過ぎて請求書を支払う、などです。エクステンドが登場する場所...

ダイアグラムでインクルードとエクステンドを使いすぎないでください。

シンプルに保ちましょう!!!

于 2011-05-01T19:53:46.793 に答える
8

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

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

例えば：

ATM マシンの構成 (ユーザーの視点によると):

<extend>1: 引き出しか入金かチェックかは利用者次第なので、現金の引き出しと預け入れと口座のチェックが該当します。これらは、ユーザーが行うオプションのことです。

2: 「ピンの入力、カードの配置、カードの取り外し」は<include>、ユーザーがカードを配置し、確認のために有効なピンを入力する必要があるため、これらが該当します。

于 2013-05-05T02:31:20.460 に答える
7

UML バージョンにも注意してください。 << uses >> と << includes >> が << include >> に、 << extends >> が<< extends >> AND generalizationに置き換えられて久しいです。
私にとって、それはしばしば誤解を招くポイントです: 例として、ステファニーの投稿とリンクは古いバージョンに関するものです:

商品代金のお支払いは、代金引換、ペイパル、カード決済からお選びいただけます。これらはすべて、「アイテムの支払い」ユース ケースの代替手段です。好みに応じて、これらのオプションのいずれかを選択できます。

実際、「アイテムの支払い」に代わるものはありません。現在の UML では、「代金引換」がエクステンドであり、「paypal を使用した支払い」/「カードによる支払い」が専門分野です。

于 2013-03-21T14:02:14.363 に答える
7

「含める」は、基本ユース ケースを拡張するために使用されます。これは必須条件です。つまり、基本使用を完了するには、含まれるユース ケースの実行が正常に実行される必要があります。

たとえば、E メール サービスのケースを考えてみましょう。ここでは、「ログイン」は、E メールを送信するために実行する必要がある組み込みユース ケースです (ベース ユース ケース)。

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

たとえば、「ノートパソコンの購入」をベース ユース ケース、「追加保証」を延長ユース ケースと考えてください。ここでは、追加保証を受けなくても、ベース ユース ケース「ラップトップの購入」を実行できます。

于 2012-10-24T10:29:17.433 に答える
4

図の要素

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

  • 継承: アクター間の洗練された関係。この関係は、名前とステレオタイプを持つことができます。

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

  • 拡張ポイント: 拡張を追加できる場所を定義します。

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

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

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

  • インクルード関係: 2 つのユース ケース間の一方向の関係。ユース ケース A と B の間のこのような関係は、B の動作が常に A に含まれることを意味します。

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

于 2012-01-19T06:19:06.450 に答える
3

拡張は、ユース ケースが複雑すぎることがわかっている場合に使用されます。したがって、複雑な手順を独自の「拡張」ユース ケースに抽出します。

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

(参照: Jeffrey L. Whitten、Lonnie D. Bentley、Systems analysis & design Methods、McGraw-Hill/Irwin、2007)

于 2015-12-11T15:39:08.063 に答える
0

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

extends にはさまざまな用途がありますが、私はそれを、使用してもしなくてもよい代替手段と考えるのが好きです。たとえば、まだ e コマース サイトにいます。商品代金のお支払いは、代金引換、ペイパル、カード決済からお選びいただけます。これらはすべて、「アイテムの支払い」ユース ケースの代替手段です。好みに応じて、これらのオプションのいずれかを選択できます。

ユースケースに関するより明確なルールとルールについては、こちらの私の記事をお読みください。

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

于 2013-02-23T09:42:07.237 に答える