用例泛化與擴展

Question

UML用例圖允許兩種看似等價的方式來表明給定的用例可能以幾種不同的方式實現，即use case generalizations而不是use case extensions。我已經看到了以下基本示例，使用任一種方法以相同頻率進行建模，有時在單一來源內。

在我看來，一個擴展比概括爲一體的專業化使用情況基本情況的直接替代必須是泛化可能更弱的關係，但不一定在擴展。

在我看來，泛化意味着多態實現是期望的，而擴展意味着要使用一些分支結構。

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圖。是否有一個硬性和快速的規則，關於哪兩個使用，如果是的話是什麼？

Answer 1

在我看來，一個擴展比泛化 爲一體的專業化使用情況基本情況 的直接替代必須是在泛化可能但不一定在擴展較弱的關係。

的確如此。

在我看來，這意味着推廣而推廣隱含着一些分支 結構中使用的多態 實現期望的。

該圖不指定任何實現。 雖然你可以從圖表中爲自己解釋提示。 UML仍然獨立於語言和解決方案。

是不是用例階段爲這樣的實現太早了 要模擬的具體問題？

那麼，如上所述，UML沒有強制執行任何特定類型的實現。 但是，您正在收集一些重要的功能要求，這可能會極大地影響您的時間表和工作量。 （「使用信用卡支付」的處理方式比「通過銀行轉賬預先付款」要複雜得多）。所以你會努力捕捉，但仍然對不同的解決方案持開放態度。

這裏有更合適的UML 圖。

你真的可以並行使用它們:)因爲它們是同一主題上的不同視圖。

是否有一個硬性規定，關於哪兩個使用 ？如果是的話是什麼？

在這種情況下，我更喜歡泛化，因爲事實上擴展錯誤地暗示可能有付款的方式而不使用任何三個命名選項。正如你所表明的那樣。

Answer 2

當使用擴展關係進行建模時，擴展用例（支付通過xxx）在擴展用例（付款）位於精確位置（由擴展點，付款類型給出）這種擴展關係成立（例如，「通過Paypal支付」，條件將爲payment_type = PAYPAL）。在這種模式中，「通過PayPal支付」僅處理使用PayPal完成支付交易的細節，而「支付」指定了與支付方法無關的所有行爲（例如計算總金額並保存交易結果一旦執行）。另一方面，泛化（其不僅限於用例，而且也適用於任何分類器）是一個更廣泛的概念，因爲它沒有詳細說明（在圖級）何時以及如何專門化行爲被執行。如果「通過Paypal支付」是「付款」的專業化，它將重新定義「付款」的行爲，這可能與「通過信用卡支付」的行爲有很大不同。

作爲擴展用例並不意味着替代品必須進行硬編碼。事實上，您的第一個示例也是擴展關係的有效實施，因爲pd->pay(pd)將根據所選付款類型調用不同的行爲。實際上，用例圖模型系統應該做什麼，而在活動圖中更好地指定低級實施細節。

Answer 3

擴展的例子是「輸入折扣代碼」用例。輸入折扣代碼與付款有關，但您無需輸入折扣代碼即可進行付款。

你可以看看「是」的關係，以決定使用哪一個。 PayPal付款「是」付款，付款的具體方式「。輸入優惠碼不是。這是您付款時可以做的其他事情。