在用例图中扩展

Question

在书籍《UML @ Classroom 面向对象建模入门》中写道：“用例——即使是包含或扩展用例——总是可以独立执行的。如果它们只能在另一个用例的范围内执行，而不能独立执行，那么它们就不是用例，也不应该被描绘为用例。它们的功能必须在使用它们的用例描述中进行覆盖。”然而，我教授给我的所有扩展关系的示例以及我在互联网上找到的扩展用例都只能在基本用例的范围内触发。 我很困惑，哪个是正确的？

我有一个小项目，我忽略了那些不能由任何参与者触发的扩展用例，我应该画出这些扩展用例吗？

- Ahmed

---

@GeertBellekens 你链接的答案中包含了很多错误/不准确的解释。如果可能的话，我会全部删除它。 - qwerty_so

你最好展示自己的上下文，而不是链接一个旧问题。 - qwerty_so

最好展示你自己的上下文，而不是链接到一个旧问题。 - qwerty_so

@qwerty_so 我知道，但基本上是同一个问题，所以重复了。一些答案还可以。 - Geert Bellekens

@GeertBellekens 对于无知者来说，问题是哪个答案好，哪个答案不好？“糟糕的用户中心综合征”无处不在，而且SO的投票并不能解决它 :-( - qwerty_so

Answer 1

规范中说：

扩展用例通常定义的行为本身可能并不一定有意义。

以及

扩展发生在扩展用例中定义的一个或多个特定扩展点上。

所以，uml@classroom是错误的，你的教授是正确的。扩展用例本身没有意义，并且在扩展用例中必须存在一个扩展点。

然而，避免使用扩展关系有很好的理由。

首先，规范自相矛盾：

用例指定了由其主体执行的一组动作，产生对每个主体的一个或多个参与者或其他利益相关者来说是有价值的可观察结果。

一个可能没有意义的行为怎么能是“有价值”的呢？

所以，也许UML应该引入“次要”用例来实现这个目的。实际上，在我们公司就是这样做的。也就是说，如果客户坚持使用“扩展”或“包含”。

在我看来，只有在它们是描述常见或扩展行为的唯一手段时，才需要次要的"use cases"。然而，通常情况下，您会使用其他元素来描述用例，比如活动图或交互概述图。它们可以轻松准确地描述这种行为。扩展用例只会重复努力，没有任何好处。

因此，即使 uml@classroom 在形式上是不正确的，建议仍然是正确的！一个值得努力的用例是独立的！

附注：很多混淆都源于对语言的草率使用：一个用例并不“执行”。使用用例是当我通过调用一些函数来使用系统时，它才发生。规范从未使用过这种措辞。相反，它谈论的是启动用例。

- Axel Scheithauer

---

看来我可以在这里重复一下对Christope的回答。老实说，我是通过学习Bittner/Spence的UC而不是通过消化规范来学习的。Max Liebermann说过：“人不能吃得比想吐的还多。” - qwerty_so

看来我可以在这里重复一下对Christope的回答。老实说，我是通过Bittner/Spence学习UC的，而不是通过消化规格说明书。Max Liebermann曾说过：“人无法吃得比想吐的更多。” - qwerty_so

@querty_so 我同意，规范并非旨在提供方法论建议。对此，您应该阅读其他书籍。您必须承认规范的这一点：它允许根据Bittner/Spence的用例进行良好的建模。 - Axel Scheithauer

@querty_so 我同意，规范并不旨在提供方法论建议。对此，你应该阅读其他书籍。你必须承认规范的优点：它允许根据Bittner/Spence的要求进行良好的用例建模。 - Axel Scheithauer

@querty_so 我同意，规范并不旨在提供方法论建议。对此，你应该阅读其他书籍。你必须承认规范的优点：它允许根据Bittner/Spence的方法对用例进行良好的建模。 - undefined

Answer 2

独立性是避免功能分解的实用方法。考虑到功能分解并不是一个坏的用例实践（即使 UML 规范明确允许它），寻找独立的用例是一个好主意。

扩展也应该遵循这个规则，但原因并不是你所想的那样。根据定义，扩展是一种附加行为，只在扩展用例的上下文中有意义：

UML 2.5.1 - 第18.1.3.2节：Extend 是从扩展用例（extension）到被扩展用例（extendedCase）的关系，指定了如何以及何时将扩展用例中定义的行为插入到被扩展用例中定义的行为中。扩展发生在被扩展用例中定义的一个或多个特定扩展点上。 当需要添加一些额外的行为，可能是有条件地，到一个或多个用例中定义的行为时，应使用 Extend。

因此，拥有一个独立的扩展非常困难。尽管如此，你仍然应该遵循你的书中的规则：避免依赖使用案例。因此，要尽量避免使用扩展。这是好的，因为大多数情况下，扩展呈现了一些非常详细的内容，这些内容同样可以在扩展使用案例的叙述中解释清楚 ;-)

- Christophe

---

我仍然认为邪恶来自元模型作者是技术人员，并认为自己处于功能分解路径中。既不包括也不扩展应该不存在，因为它只会导致功能分解。只需阅读定义即可验证。好吧，这是一厢情愿的想法。直到 UML 5.0，我们可能不得不左右逢源。肯定会失败。 - qwerty_so

我仍然认为邪恶来自元模型的作者是技术人员，并且将自己置于功能分解路径中。既不包含也不扩展应该不存在，因为它只会导致功能分解。仅仅阅读定义就可以验证这一点。唉，如此一厢情愿的想法。直到UML 5.0出现，我们可能不得不摇摆不定。肯定会失败。 - qwerty_so

我仍然认为邪恶来自元模型的作者是技术人员，并且将自己置于功能分解路径中的思维方式。既不包含也不扩展应该不存在，因为它只会导致功能分解。仅仅阅读定义就可以验证这一点。唉，这只是一厢情愿的想法。直到 UML 5.0，我们可能不得不摇摆不定。肯定会失败。 - undefined