用例中的扩展与一般化

Question

我已经阅读了这篇文章: 用例泛化与扩展。以下是2个案例。

案例1：

案例2：

更新影片 只有在至少三个用例中的一个发生时才会发生。在泛化关系中，只有一个用例发生。在扩展关系中，更新影片可以在没有任何用例的情况下发生。那么我应该使用哪个？

- Haru

---

你的第一个案例中，扩展方向是错误的。像您所想的那样（仅在执行主要用例之一时更新电影），扩展应该在另一个方向上。这将是包含正确方向的方式。但我同意其他答案，您可能甚至不需要在您的情况下使用包括、扩展或概括（甚至大多数情况下都不需要）。 - Geert Bellekens

Answer 1

简而言之

如果只保留左侧用例不是一个选项，那么基于一般化的第二个版本更好，因为它更好地传达了面向目标的用例。但是，请考虑重新命名一般用例。

更多论点

该特定图中的用例存在歧义:

• 用例原则上是针对演员目标的。左侧用例看起来像一个目标。右侧可能是对用户重要的子目标（适用于用例），也可能是实现目标的功能分解（不适用于用例）。
• 从通常对CRUD的理解来看，不清楚“更新电影”与“修改电影”有什么区别。因此，需要重新命名以避免歧义。那么“管理电影”怎么样？
• 从左侧看，与右侧用例的关系，使用«extends»暗示您实际上正在建模用户界面或功能，例如窗口更新电影可以导致其他不同的函数或功能，每个在右侧都是可选的。这只有在左侧更新电影对演员有意义而不考虑其任何扩展时才有意义。但是这不是事实，因为您声称“[右侧的三个用例中]至少发生一个”。让我们避免这种功能分解。

基于一般化的版本，可以完全对应于合适的用例，具有通用目标，并在更具体的目标中进行了说明，每个目标本身都有意义。

作者们怎么说？

Alistair Cockburn在他的优秀书籍编写有效用例中，专门写了一章关于CRUD用例：

问题是，它们是否都是一个更大的用例管理xxx的一部分，还是独立的？
原则上，它们是独立的，因为每个是由不同的人以不同的安全级别执行的不同目标。但是它们会混淆用例集并且可能使要跟踪的项目数量增加三倍。

由于Cockburn专注于描述用例而不是UML模型，因此他接下来描述了他所谓的“参数化用例”，其中包含有些情节操作对于特定的用例更加具体的通用用例。这种技术非常符合一般化/特殊化，他在关于UML符号的附录中也提到了它。

Kurt Bitter和Ian Spence在他们出色的书籍用例建模中不赞成使用CRUD用例。他们的主要论点不是CRUD用例有问题，而是它们耗时且对建模提供的价值很少：

尽管使用用例来描述CRUD这种行为在技术上是适当的，但将此行为描述为用例可能不值得花费这么多时间。我们将这个准则总结为“用例应该不仅包含CRUD”。

他们阐明了为什么不值得这样做：

对于简单的CRUD行为，使用用例无法为确保系统正在执行正确的事情增加太多价值。(…)很少会出现误解需求的情况。

- Christophe

---

我同意将“更新电影”更改为“管理电影”。管理包括的内容不仅限于CRUD，但在这种情况下，让我们只谈论CRUD。包容性意味着CRUD可以在同一个电影对象上进行。我可以创建、读取、修改电影，然后从网站中删除它。一个泛化的例子是“付款”用例。它可以分为“通过PayPal支付”和“通过信用卡支付”。当任一用例发生时，都会创建一个交易。我的意思是，两个用例使用不同的对象。这让我感到困惑。 - Haru

@Haru 处理CRUD引发了很多争议，让一些顾问赚得盆满钵满；-) 我更喜欢在图表中不显示详细的CRUD，因为图表是用来提供大局观的。但如果没有用例，这个话题仍然需要以某种方式进行处理、描述、实现和测试。所以最终，不管选择哪种方法，都没有太大区别，除了图表的简单性。另一个普遍化问题是要找出“创建电影”与“更新电影”还是与“创建作者”有更多的共同点。 - Christophe

“Make payment” 是另一个常见的例子。对于用户来说，目标是支付。支付媒介只是一个细节。您可以选择目标导向的用例，并留出一些空间进行支付媒介相关的交互。更新由您描述这些内容：您可以在“支付”叙述后面添加两个段落。但是，如果您认为区分用例很重要，例如因为次要参与者（银行操作员与PayPal）不同，那么就可以使用专业化。专业化的优点是您以后可以添加“现金支付”，“Apple Pay”等。 - Christophe

我的意思是，总体原则已经足够了。顺便说一下，专业化不需要在主要图表中混杂，而可以在单独的图表中显示（在UML中，保持图表简单和聚焦）。因此，它还具有通过关注点分离来促进图表维护的优点。最后但并非最不重要的是，如果您使用实体-边界-控制将您的类与用例相关联，那么将Control Paying作为Control Paying with PayPal的概括似乎很容易，这将共享大部分行为。 - Christophe

...但要覆盖那些特定于PayPal的部分。我希望这些冗长的解释不会让您感到困惑@Haru - 我的意思是，最终，这些图表只是一种工具，用于促进软件的交付，而由您来决定哪种方式最有助于最终交付软件;-) - Christophe

Answer 2

以上内容都不是用例。它们是纯函数，作为某些用例描述中的活动中的操作。用例为其参与者带来附加价值。这是您开始构建的升华点。从来不是功能！因此，您正在进行功能分解。您走错了轨道。

像往常一样，我推荐Bittner/Spence关于用例建模的阅读。这是您可以找到的最好的读物。

- qwerty_so

---

我明白了。那么我怎样才能知道“更新电影”有以上功能呢？我有用例描述。 - Haru

正如我所说：“更新电影”不是一个用例。 - qwerty_so