包含/扩展的用例可以由另一个参与者启动吗？

Question

您好，我希望接待员和经理能够查看工作类型和费率并随后对其进行更新。但是，技术人员只能查看，不能更新。图表有效吗？

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

对不起，如果之前有人问过这个问题。

Answer 1

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

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

一般来说，将用例链接在一起是一个坏主意，因为您通常一个接一个地执行。 您不应该尝试使用用例对活动序列进行建模。为此使用您的业务流程分析。

您可以使用后置条件和前置条件来约束用例的执行。实际上，您的 Edit 用例实际上并不需要特别执行 View 用例，对吗？它可能只需要选择一个工作类型。因此，它可以在任何具有表明选择工作类型的后置条件的用例之后立即执行。

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

我认为“扩展”是完全错误的。扩展用例通常是不完整用例，将它们的行为插入到完整用例中是扩展用例中定义的特定扩展点。中的扩展用例对扩展用例没有任何了解，不需要也不使用这种行为的结果。

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

如果您仍然坚持将用例链接在一起，例如，如果您真的表示您只能在执行用例后编辑费率查看工作类型和费率 我会反其道而行之。包括用例查看工作类型和费率从用例编辑工作类型和费率，可能是第一步。

这两种解决方案（单独的用例，或包括从编辑到查看）都​​解决了您关于不同用户权利的问题，因为现在很清楚谁可以做什么。

Answer 2

我会这样建模：

Manager 和 Receptionist 在这种情况下具有相同的作用，这就是我使用概括的原因。在不知道域的情况下，这似乎还可以，但这只是一个建议。

<<extend>> 受{not allowed for actor Tech} 的约束，这明确排除了此参与者进入此（可选）用例。

没有必要同时将Receptionist 与Update... 关联起来，因为它是View... 的扩展，除非您希望能够在没有View 的情况下先使用Update。

注意关于<<include>>/<<extend>>：它们并不意味着链接用例。 UML 规范声明（第 638 页）：

当有一些额外的行为可能有条件地添加到一个或多个用例中定义的行为时，可以使用扩展。

和

包含关系旨在用于两个或多个 UseCases 行为的共同部分。然后将此公共部分提取到一个单独的 UseCase 中，以包含在所有具有该部分公共的基本 UseCases 中。

现在<<include>> 看起来就像个混蛋。用例是关于一个独特的附加值。如果在多个用例中存在行为重复，这种独特性可能会受到质疑。在任何情况下，这些关系通常只被视为功能分解。那将是完全错误的。从我的观点来看，如果没有这些关系，UML 规范会更好。

在上图的上下文中，它代表了一种模式，您可以在其中查看某些内容，然后才能使其可编辑。如果没有 <<extend>> 在 Update 中设置约束，告诉 { can only be reached after View... }，则最好有两个单独的气泡。

Answer 3

我会通过包含更改扩展。要更新作品，您必须查看它。必须查看。

在您的图表中，Manager 和 Receptionnist 是等价的，仅使用此模式，您只能定义一个参与者。或者 Manager 从 Receptionnist 继承的模型。

为避免错误，如果您这样做，您必须确保接待员和经理也可以在不更新的情况下激活视图用例。否则必须删除一些关联。