包含/扩展用例是否可以由另一个actor发起？

Question

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

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

很抱歉，如果之前有人问过这个问题。

Answer 1

你既不应该“包括”也不应该“延伸”

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

一般来说，将用例链接在一起是一个坏主意，因为你通常一个接一个地做。 您不应该尝试使用用例来模拟活动的顺序。使用您的业务流程分析。

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

只要在用例开始之前选择了工作类型，哪个用例与Edit用例无关。可能有10个不同的用例导致选择工作类型。

«延伸»我认为是完全错误的。扩展用例通常是不完整用例，将其行为插入完整用例是扩展用例中定义的特定扩展点。扩展用例对扩展用例没有任何了解，也不需要或使用此行为的结果。

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

如果您仍然坚持将用例链接在一起，例如，如果您真的意味着您只能在执行用例后编辑费率查看工作类型和费率我会反过来做。在用例编辑工作类型和费率中包含用例查看工作类型和费率，可能是第一步。

这两个解决方案（单独的用例，或包括从编辑到视图）解决了有关不同用户权利的问题，因为现在可以清楚地知道谁可以做什么。

Answer 2

我会这样建模：

Manager和Receptionist在此上下文中具有相同的角色，这就是我使用泛化的原因。不知道域名这似乎没问题，但这只是一个提案。

<<extend>>受{not allowed for actor Tech}约束，明确排除此演员进入此（可选）用例。

除了您希望能够Receptionist没有Update...之外，您无需将View...与Update相关联，因为它是View的扩展名。第一个。

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

  

当有一些额外行为（可能是有条件地）添加到一个或多个UseCases中定义的行为时，可以使用

。

和

  

当包含两个或多个UseCases行为的公共部分时，将使用Include关系。然后将这个公共部分提取到一个单独的UseCase，由所有具有此部分的基本UseCases包含。

现在<<include>>看起来像个混蛋。用例是一个独特的附加值。如果在多个用例中出现行为复发，则可以质疑这种独特性。在任何情况下，这些关系通常仅被视为功能分解。这是完全错误的。从我的POV来看，没有这些关系，UML规范会更好。

在上图的上下文中，它表示一种模式，您可以在其中查看某些内容，然后才能使其可编辑。如果在<<extend>>告诉Update {}}}中放置约束，那么在没有{ can only be reached after View... }的情况下拥有两个单独的气泡将是完美的。

Answer 3

我会通过include更改extend。要更新工作，您必须查看它。必须查看它。

在您的图表中，Manager和Receptionnist是等效的，仅使用此架构，您只能定义一个actor。或者Manager从Receptionnist继承的模型。

为了避免错误，如果你这样做，你必须确保Receptionist和Manager也可以在没有更新的情况下激活视图用例。否则必须删除一些协会。