web-dev-qa-db-ja.com

ユースケースの一般化と拡張

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

Use case generalisation image

Use case extension image

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

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

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つのうちどちらを使用するかについて、厳格な規則はありますか。

umluse-case
22
DuncanACoulter

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

それは本当です。

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

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

このような実装固有の懸念をモデル化するには、ユースケースステージが早すぎませんか？

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

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

同じ主題について異なるビューなので、実際にそれらを並行して使用できます:).

2つのうちどちらを使用するかについて、厳格な規則はありますか。

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

15
observer

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

一方、一般化（ユースケースだけでなく、任意の分類子に対しても定義されます）は、特殊な動作がいつどのように実行されるかについての詳細を（図レベルで）詳細に説明しないため、より広い概念です。 「PayviaPaypal」が「MakePayment」の専門分野である場合、「Make Payment」の動作が再定義され、「Payviacreditcard」の動作とは大幅に異なる可能性があります。

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

9
Javier

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

「isa」の関係を見て、どちらを使用するかを決定できます。 Paypalによる支払いは「支払いを行う」、支払いを行う特定の方法です。割引コードの入力は違います。それはあなたが支払いをしている間にあなたがすることができる追加の何かです。

5
BobRodes