扩展用例和父用例有什么区别？

如何解决扩展用例和父用例有什么区别？

我对用例图中的扩展用例和父用例之间的区别感到困惑。我想知道何时可以使用 extend ，何时可以使用父用例？

例如：

打印单扩展确认
通过PayPal 继承付款。
通过信用卡继承付款。

继承和扩展有什么区别？

图片来源：https://t4tutorials.com/use-case-diagrams/

解决方法

保留所有用于比较扩展和include +概括的比例就像比较聚合 a 和 b +概括中的聚合：

在图中，由于扩展，可以将UC 打印单 中定义的行为插入到UC 确认订单中定义的行为中>

这些概括就像在UML中的其他地方一样，通过Paypal付款是 Payment ，而通过信用卡付款是付款。该图表明UC 确认订单包括UC 付款或两个继承UC之一。因此，UC 确认订单的行为包含无条件 UC Payment 的行为或UC paypal通过Paypal 或UC 通过信用卡付款的行为。

规范中有一个UC之间的继承示例，请参见formal/2017-12-05的第18.1.5章646图18.11

右下角的两个蓝色气泡通过泛化关系从Payment继承。尽管看起来很方便，但这并不可取。与明确定义的类继承不同，UC继承是一个开放字段。 UML规范仅在一个图中使用了一个概括，而对UC的概括实际上意味着什么绝对没有定义！

在散文和非正式语言的世界中，用例非常多。它（可能因为没有定义）可能意味着您需要使用父UC的描述，并将其部分替换（覆盖）为继承UC中定义的文本。从有时部分起作用的上下文中。但是，通过信用卡和Paypal进行支付有很大不同（您知道），并且没有太多共同点。因此，更好的方法是使用各种付款方式来“扩展” Payment。这样，您就可以采用固定的付款程序，可以选择采用信用卡或Paypal方式（甚至是混合付款方式）。

N.B .：上面的例子只是一个糟糕的例子。它开始功能分解。用例应显示正在考虑的系统应带给其参与者的单个唯一增值。 Print slip绝对是纯函数，没有真正的附加值（这些天谁需要纸条？）。 Selection of product一样：这里的附加值是什么？ Calculate...只是在说这是一个函数。基本上，您有两个用例：Confirm order和Make payment（请注意，在标题中描述用例时必须使用动词+实体）。

一如既往，我将推荐Bittner / Spence作为有关用例的优秀读物。