24

UML ユース ケース図では、特定のユース ケースがいくつかの異なる方法、つまりユースケースの拡張ではなく、ユース ケースの一般化で実現される可能性があることを示す、一見同等に見える 2 つの方法を使用できます。次の基本的な例は、同じ頻度で、場合によっては単一のソース内でいずれかのアプローチを使用してモデル化されたものを見てきました。

ユースケースの一般化イメージ

ユースケース拡張イメージ

私の考えでは、拡張は一般化よりも弱い関係です。基本ケースの特殊なユースケースの直接置換は、一般化では可能である必要がありますが、拡張では必ずしも可能ではないからです。

一般化はポリモーフィックな実装が望まれることを意味し、拡張は何らかの分岐構造が使用されることを意味するように私には思えます。

void makePayment(const PaymentDetails* pd)
{
   pd->pay();
}

とは対照的に

void makePayment(const PaymentDetails* pd)
{
   switch(pd->type)
   {
       case EFT:
                payViaEFT(pd); 
                break;
       case PAYPAL:
                payViaPayPal(pd); 
                break;
       case CREDITCARD:
                payViaCreditCard(pd); 
                break;
   }
}

このような実装固有の問題をモデル化するには、ユースケースの段階が早すぎませんか? そのためのより適切な UML ダイアグラムがあります。2 つのうちどちらを使用するかについて厳格なルールはありますか? もしそうなら、それは何ですか?

4

3 に答える 3

16

私の考えでは、拡張は一般化よりも弱い関係です。基本ケースを特殊なユースケースに直接置き換えることは、一般化では可能でなければなりませんが、必ずしも拡張では可能ではないからです。

それは本当です。

一般化は多態的な実装が望まれることを意味し、拡張はいくつかの分岐構造が使用されることを意味するように私には思えます。

この図は、実装を示していません。ただし、図からヒントを自分で解釈することはできます。UMLは、言語やソリューションに依存しません。

ユースケースの段階は、そのような実装固有の懸念をモデル化するには時期尚早ではありませんか？

さて、上に示したように、UMLは特定の種類の実装を強制しません。ただし、ここでは、タイムスケジュールとワークロードに大きな影響を与える可能性のあるいくつかの重要な機能要件を収集しています。（「クレジットカードで支払う」は、「銀行振込で前払いする」よりも処理がはるかに複雑です）。したがって、それを把握するよう努めますが、さまざまなソリューションアプローチを受け入れる必要があります。

そのためのより適切なUML図があります。

それらは同じ主題に関する異なる見解であるため、実際に並行して使用できます:)。

どちらを使用するかについての厳格なルールはありますか？もしそうなら、それは何ですか？

実際、拡張機能は、3つの名前付きオプションのいずれも使用せずに支払う方法がある可能性があることを誤って示唆しているため、この場合の一般化を好みます。あなたがあなた自身を示したように。

于 2013-02-28T12:43:02.963 に答える
10

拡張関係を使用してモデル化する場合、拡張使用事例 (xxx 経由で支払う) が実行されるのは、拡張使用事例 (支払いを行う) が正確な場所 (拡張ポイント、支払タイプによって指定される) にある場合で、そのような拡張関係の条件が満たされている場合です。 (たとえば、「Paypal 経由で支払う」の場合、条件は payment_type=PAYPAL になります)。このモデルでは、「Pay via Paypal」は Paypal での支払いトランザクションの完了の詳細のみを処理し、「Make Payment」は支払い方法に依存しないすべての動作 (合計金額の計算や保存など) を指定します。実行されたトランザクションの結果)。

一方、一般化 (ユースケースだけでなく、あらゆる分類子に対しても定義される) は、より広い概念です。これは、特殊な動作がいつどのように実行されるかの詳細を (図レベルで) 詳細に説明しないためです。「ペイパル経由の支払い」が「支払いの実行」の特殊化である場合、「支払いの実行」の動作が再定義され、「クレジット カードによる支払い」の動作とは大幅に異なる可能性があります。

拡張ユースケースであることは、代替案をハードコーディングする必要があるという意味ではありません。実際、pd->pay(pd)選択した支払いタイプに応じて異なる動作を呼び出すため、最初の例は拡張関係の有効な実装でもあります。実際には、ユースケース図はシステムが行うべきことをモデル化しますが、低レベルの実装の詳細はアクティビティ図でより適切に指定されます。

于 2013-02-28T14:59:20.447 に答える
6

拡張機能の例としては、「割引コードの入力」のユース ケースがあります。割引コードの入力は支払いに関係しますが、支払いを行うために入力する必要はありません。

どちらを使用するかを決定するために、"is a" 関係を調べることができます。Pay by PayPal は、支払いを行う特定の方法です。割引コードを入力してください。これは、支払いの際にできる追加の操作です。

于 2014-12-10T00:15:41.137 に答える