我对用例图中扩展用例和父用例的区别感到困惑。
我想知道何时可以使用extend，何时可以使用父用例？
例如：
例如：
- 打印收据 extend 确认
- 通过PayPal支付 inherits 付款。
- 通过信用卡支付 inherits 付款。
扩展用例与父用例有什么区别？
3
- abdou_dev
1
UC图基本上是一种功能分解。只是一个糟糕的（如果不说是）错误的例子。 - qwerty_so
2个回答
2
保持所有比例的情况下，将扩展和包含+概括进行比较就像比较聚合体a和b+概括一样。
一般化关系与UML中的其他地方一样，“通过PayPal支付”是“支付”，“通过信用卡支付”也是“支付”。该图表指示UC“确认订单”包括UC“支付”或两个继承UC之一。因此，UC“确认订单”的行为无条件地包含UC“支付”的行为，或UC“通过PayPal支付”的行为，或UC“通过信用卡支付”的行为。
标准中有UC之间的继承示例，请参见第18.1.5章的第646页上的图18.11，网址为formal/2017-12-05。
一般化关系与UML中的其他地方一样，“通过PayPal支付”是“支付”，“通过信用卡支付”也是“支付”。该图表指示UC“确认订单”包括UC“支付”或两个继承UC之一。因此，UC“确认订单”的行为无条件地包含UC“支付”的行为，或UC“通过PayPal支付”的行为，或UC“通过信用卡支付”的行为。
标准中有UC之间的继承示例，请参见第18.1.5章的第646页上的图18.11，网址为formal/2017-12-05。
- bruno
1
两个蓝色的气泡位于右下角，通过泛化关系继承自
用例非常接近散文和非正式语言。它（可能）意味着您采用父UC的描述，并用继承UC中定义的文本替换其中的部分内容（重写）。从某些情况来看，这样做有时部分有效。然而，通过信用卡和Paypal支付是非常不同的（您知道的），并且没有太多共同之处。因此，更好的方法是使用各种支付方式“扩展”
注意：上面的示例只是一个糟糕的例子。它开始了功能分解。用例应该展示系统为其参与者带来的单一独特的增值。打印收据绝对是一个纯粹的函数，没有实际的增值（现在谁还需要纸质收据？）。选择产品也一样：这里的增值是什么？计算...只是说明它是一个函数。基本上你有两个用例：确认订单和付款（请注意，在标题中描述用例时使用动词+名词是强制性的）。
像往常一样，我会推荐Bittner/Spence作为关于用例的优秀读物。
Payment。虽然看起来方便，但这并不可取。与明确定义的类继承不同，UC继承是一个开放的领域。UML规范仅在一个图中使用泛化，并没有对UC的泛化做出任何定义！用例非常接近散文和非正式语言。它（可能）意味着您采用父UC的描述，并用继承UC中定义的文本替换其中的部分内容（重写）。从某些情况来看，这样做有时部分有效。然而，通过信用卡和Paypal支付是非常不同的（您知道的），并且没有太多共同之处。因此，更好的方法是使用各种支付方式“扩展”
Payment。这样，您就有了一个固定的付款流程，可以选择信用卡或Paypal方式（如果设计成这样甚至可以混合使用）。
注意：上面的示例只是一个糟糕的例子。它开始了功能分解。用例应该展示系统为其参与者带来的单一独特的增值。打印收据绝对是一个纯粹的函数，没有实际的增值（现在谁还需要纸质收据？）。选择产品也一样：这里的增值是什么？计算...只是说明它是一个函数。基本上你有两个用例：确认订单和付款（请注意，在标题中描述用例时使用动词+名词是强制性的）。
像往常一样，我会推荐Bittner/Spence作为关于用例的优秀读物。
- qwerty_so
3
我认为这张图片展示的用例图并没有错误，因为我是从教程中获取的。我现在认为，泛化关系可以在我们有两个选项并且只能选择其中一个时使用，但是对于扩展关系，我认为它描述了来自用例主要部分的子任务和子用例。 - abdou_dev
我没有说这是错误的。只是因为UC继承它是虚无缥缈的坏主意。没有清晰的定义，在上述情况下，我认为这是一个设计错误。使用Paypal和信用卡支付几乎没有什么共同之处，除了最后完成一笔资金转移。所以如果你不继承任何东西，概括有什么意义呢？此外，UC应该描述独特的附加值，而概括则与“独特性”相矛盾。 - qwerty_so
1啊，不要告诉我这个教程一定是正确的。我在这里看到过很多明显错误的教程。 - qwerty_so
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接