包括/扩展的用例能否由另一个参与者发起？

Question

嗨，我想让接待员和经理能够查看工作类型和费率并随后进行更新。但是，技术人员只能查看而不能更新。这个用例图有效吗？

我了解到，扩展用例是由启动基本用例的参与者发起的。如何区分技术人员只能启动基本用例而不能启动扩展用例？我应该不放置扩展关联吗？包含用例怎么办？

很抱歉如果这个问题以前已经被问过。

- Soggeh

Answer 1

你既不应该“包含”也不应该“扩展”。

“查看工作类型和费率”以及“编辑工作类型和费率”是完全有效的独立用例。

通常，仅因为您通常在一个用例之后执行另一个用例而将用例链接在一起是一个坏主意。您不应该尝试使用用例来建模活动序列。使用业务流程分析进行建模。

您可以使用前置条件和后置条件来限制用例的执行。实际上，您的“编辑”用例并不真正需要特定地执行“查看”用例，对吗？它可能只需要选择一个工作类型。因此，它可以在具有后置条件声明已选择工作类型的任何用例之后立即执行。

哪个用例执行此操作与编辑用例无关，只要在用例开始之前选择了工作类型即可。可能有10个不同的用例会导致选择工作类型。

我认为“扩展”是不正确的。扩展用例通常是不完整的用例，它们将其行为插入到完整的用例中，并且是在扩展用例中定义的特定扩展点。扩展用例不知道扩展用例的任何信息，也不需要或使用此行为的结果。

我发现适用“扩展”用例的少数情况是监视用例之类的事情。例如，监视系统中打开的票数并在超过某个阈值时向管理员发送警报的用例。

如果您仍然坚持将用例链接在一起，例如，如果您真正意味着只有在执行“查看工作类型和费率”用例之后才能编辑费率，那么我会反其道而行之。从“编辑工作类型和费率”用例包含“查看工作类型和费率”用例，可能是第一步。

这两种解决方案（独立用例或从编辑到查看的包含）都解决了您关于不同用户权限的问题，因为现在清楚无误地知道谁可以做什么。

- Geert Bellekens

---

是的，incl/excl被误认为是链式调用，这不是它们的本意。因此，如果一个人对它的使用不是绝对确定，最好不要使用它。我可能会在我的答案中添加评论来澄清这一点。 - qwerty_so

@ThomasKilian 我已经查看了，它说：“扩展的用例通常定义的行为本身可能并不一定有意义”，我将其翻译为“不完整”。被扩展的用例必须在自身上是“完整”的，因为它们对扩展用例没有任何了解。 - Geert Bellekens

特别是关于Include：由于Include关系的主要用途是重用公共部分，因此在基本用例中剩下的内容通常本身并不完整，而是依赖于包含的部分才能具有意义。这与您所说的相反。所以include会使主要的用例不完整！ - qwerty_so

@ThomasKilian 我认为你的引用并没有与我的陈述相矛盾。它说包含其他用例的用例通常是不完整的。被扩展的用例总是完整的。扩展用例通常是不完整的。我会编辑我的回复以反映“可能性”。 - Geert Bellekens

再思考一下，我有一个问题：什么是不完整的用例？鱼没有自行车吗？我觉得规范中的整个部分都是垃圾。用例应该只显示单个的增加值。没有扩展/包含等。 （好吧，我们可以进行漫长的讨论，但我们不应该这样做...） - qwerty_so

Answer 2

我会这样建模：

在这种情况下，经理和接待员在角色上是相同的，这就是为什么我使用了一般化。如果不知道领域，这似乎是可以的，但这只是一个提议。 <<extend>>受到{不允许演员Tech}的限制，这清楚地排除了该演员进入此（可选）用例。

没有必要将Receptionist与Update...相关联，因为它是View...的扩展，除非你想先View而不Update。

关于<<include>>/<<extend>>的注意事项：它们不是用例链接。UML规范说明（第638页）：

当有一些额外的行为应该被添加到一个或多个用例中定义的行为中时，应使用Extend。

Include关系旨在用于两个或多个UseCase的行为存在共同部分的情况。然后将这个共同部分提取到一个单独的UseCase中，由所有具有这个共同部分的基础UseCases进行包含。

现在，"<>"看起来像个混蛋。用例是关于独特的增值的。如果有多个用例中存在行为重复，这种独特性就会受到质疑。无论如何，这些关系通常只被视为功能分解。这是完全错误的。从我的角度来看，没有这些关系的UML规范会更好。

在上图的上下文中，它代表一种模式，您可以在查看某物之后才能对其进行编辑。最好有两个没有"<>"的单独泡泡，在Update中放置一个约束，告诉{仅在查看后才能访问...}。

- qwerty_so

---

但是，如果您设置了一个包含并关联接待员来查看和更新，则不需要约束条件... - granier

@granier <<include>> 是必须执行的，在这种情况下似乎没有意义 - 它是可选的。 - qwerty_so

@granier 简单来说，查看表单和编辑表单是不同的。虽然编辑表单显示值，但它们是可编辑的。查看表单不允许编辑。它们显然是不同的用例。 - qwerty_so

是的，先决条件就足够了。我的人类逻辑告诉我这并没有语义上的区别 :-) - qwerty_so

@GeertBellekens 你试图给圣人洗礼;-) 我知道这个并且几乎从不厌倦宣讲。然而，在这个情境下，我认为这是 <<extend>> 的一个有效应用（为数不多的应用之一）。虽然它不是直接涉及UCs的顺序，但这意味着“您需要查看才能更新”，这是一种常见的模式。如果有直接编辑的要求，我会把 <<extend>> 放在一边。请查阅第 638 页：Extend 旨在用于存在某些附加行为的情况... 那么可以采用以下模式：查看已锁定的字段，然后可选地解锁以进行编辑。 - qwerty_so

Answer 3

我会将"extend"改为"include"。要更新工作，你必须查看它。查看是强制性的。

在你的图表中，经理和接待员是等价的，仅使用这个模式，你只能定义一个参与者。或者模型中经理继承自接待员。

为了避免错误，如果你这样做，你必须确保接待员和经理也可以激活查看用例而不更新。否则，有些关联必须被移除。

- granier

---

如果你把"extend"改成"include"，那就是对的。 - granier

哈哈，图表只是实际模式的快照，以便说明我的问题。前台接待员和经理在其他用例中扮演不同的角色。但是，这个图是否足够合法地说明只有经理和前台接待员可以更新？（尽管他们也必须先查看）。 是的，他们可以在不更新的情况下进行查看。 - Soggeh

不过，如果我只是删除两个用例之间的关联，会更好吗？ - Soggeh

你可以这样做，但是如果你移除了 include（假设你将 extend 改为 include），更新就不再是必须的了。如果你想要进行更新，你必须执行与查看相同的操作，也就是保留 include。另外，由于经理和接待员之间存在继承关系，因此你的架构将更易于阅读。 - granier

@granier 也许你应该澄清一下你是指从编辑用例到查看用例的包含还是反过来。 - Geert Bellekens

其实，我们可以讨论很多关于这个主题的问题以及如何逻辑地建模视图/更新。我觉得@killian的建议与问题相似，但是可以对其背后的逻辑进行争论。但我不确定那是否会是一次积极的辩论… - granier