用例泛化与扩展

UML用例图允许两种看似等价的方式来表明给定的用例可能以几种不同的方式实现，即use case generalizations而不是use case extensions。我已经看到了以下基本示例，使用任一种方法以相同频率进行建模，有时在单一来源内。用例泛化与扩展

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图。是否有一个硬性和快速的规则，关于哪两个使用，如果是的话是什么？

来源

2013-02-28 DuncanACoulter

这两个实现都模拟相同的问题。它们不与一个UC图或另一个关联。多态性更合乎需要，因为它更简单，更容易扩展并且不易受人为错误的影响。 – 2015-05-04 18:55:45

在我看来，一个扩展比泛化为一体的专业化使用情况基本情况的直接替代必须是在泛化可能但不一定在扩展较弱的关系。

的确如此。

在我看来，这意味着推广而推广隐含着一些分支结构中使用的多态实现期望的。

该图不指定任何实现。虽然你可以从图表中为自己解释提示。 UML仍然独立于语言和解决方案。

是不是用例阶段为这样的实现太早了要模拟的具体问题？

那么，如上所述，UML没有强制执行任何特定类型的实现。但是，您正在收集一些重要的功能要求，这可能会极大地影响您的时间表和工作量。（“使用信用卡支付”的处理方式比“通过银行转账预先付款”要复杂得多）。所以你会努力捕捉，但仍然对不同的解决方案持开放态度。

这里有更合适的UML 图。

你真的可以并行使用它们:)因为它们是同一主题上的不同视图。

是否有一个硬性规定，关于哪两个使用？如果是的话是什么？

在这种情况下，我更喜欢泛化，因为事实上扩展错误地暗示可能有付款的方式而不使用任何三个命名选项。正如你所表明的那样。

来源

2013-02-28 12:43:02 observer

当使用扩展关系进行建模时，扩展用例（支付通过xxx）在扩展用例（付款）位于精确位置（由扩展点，付款类型给出）这种扩展关系成立（例如，“通过Paypal支付”，条件将为payment_type = PAYPAL）。在这种模式中，“通过PayPal支付”仅处理使用PayPal完成支付交易的细节，而“支付”指定了与支付方法无关的所有行为（例如计算总金额并保存交易结果一旦执行）。另一方面，泛化（其不仅限于用例，而且也适用于任何分类器）是一个更广泛的概念，因为它没有详细说明（在图级）何时以及如何专门化行为被执行。如果“通过Paypal支付”是“付款”的专业化，它将重新定义“付款”的行为，这可能与“通过信用卡支付”的行为有很大不同。

作为扩展用例并不意味着替代品必须进行硬编码。事实上，您的第一个示例也是扩展关系的有效实施，因为pd->pay(pd)将根据所选付款类型调用不同的行为。实际上，用例图模型系统应该做什么，而在活动图中更好地指定低级实施细节。

来源

2013-02-28 14:59:20 Javier

扩展的例子是“输入折扣代码”用例。输入折扣代码与付款有关，但您无需输入折扣代码即可进行付款。

你可以看看“是”的关系，以决定使用哪一个。 PayPal付款“是”付款，付款的具体方式“。输入优惠码不是。这是您付款时可以做的其他事情。

来源

2014-12-10 00:15:41 BobRodes

我明白你在说什么了。付款并不是完整的，所以使用最自然的关系就是泛化（无论如何我都支持这一点）。然而，使用泛化似乎意味着在同一时间不可能使用多种付款方式。 [某些人]（http://www.uml-diagrams.org/use-case-include.html）表示，添加包含关系条件的能力将有助于避免这些问题。你的想法？ – DuncanACoulter 2014-12-22 11:33:11

我查看了作者在您的链接中指出的问题。有一个简单的解决方案。如果你仔细想想，用两种方法支付的“一”实际上是两笔支付。作者越来越意识到多种付款方式必须通过付款使用案例一次通过。您可以为每种付款方式一次通过。如果您希望将多个付款交易链接到一个逻辑付款，那么扩展付款用例，添加一个“流程多付款方式”用例或其他一些链接多次通过付款的链接。 – BobRodes 2014-12-22 14:58:58

另外，虽然我现在看到关于可能使用扩展来处理多个付款的观点，但我仍然认为使用泛化模型更加准确。清楚地使用扩展并不区分单一支付方式和多种支付方式。 – BobRodes 2014-12-22 15:05:30

用例泛化与扩展

回答

相关问题