您好，我希望接待员和经理能够查看工作类型和费率并随后对其进行更新。但是，技术人员只能查看，不能更新。图表有效吗？
我读到扩展用例是由发起基本案例的参与者发起的。我应该如何区分技术人员只能启动基本案例而不是扩展案例？我不应该放置扩展关联吗？包含的用例呢？
对不起，如果这个问题以前被问过。
问问题
2572 次
3 回答
3
你既不应该“包含”也不应该“扩展”
查看工作类型和费率以及编辑工作类型和费率是完全有效的独立用例。
一般来说，将用例链接在一起是一个坏主意，因为您通常一个接一个地做。您不应该尝试使用用例对活动序列进行建模。为此使用您的业务流程分析。
您可以使用后置条件和前置条件来约束用例的执行。实际上，您的Edit用例实际上并不需要特别执行View用例，对吗？它可能只需要选择一个工作类型。因此，它可以在任何具有表明选择工作类型的后置条件的用例之后立即执行。
哪个用例执行此操作与编辑用例无关，只要在用例开始之前选择了工作类型即可。可能有 10 个不同的用例会导致选择一种工作类型。
我认为“扩展”是完全错误的。扩展用例通常是不完整的用例，将它们的行为插入完整的用例是扩展用例中定义的特定扩展点。中的扩展用例对扩展用例没有任何了解，并且不需要或使用此行为的结果。
我发现“扩展”用例适用的少数情况是监控用例。例如，监控系统中打开的工单数量并在超过某个阈值时向管理员发送警报的用例。
如果您仍然坚持将用例链接在一起，例如，如果您的意思是您只能在执行用例查看工作类型和费率后编辑费率，我会反其道而行之。包括用例从用例中查看工作类型和费率编辑工作类型和费率，这可能是第一步。
两种解决方案（单独的用例，或包括从编辑到视图）都解决了您关于不同用户权利的问题，因为现在已经很清楚谁可以做什么了。
于 2017-11-10T07:05:41.160 回答
2
我会这样建模：
Manager并且Receptionist在这种情况下具有相同的角色，这就是我使用概括的原因。在不知道域的情况下，这似乎还可以，但这只是一个建议。
受其<<extend>>约束{not allowed for actor Tech}，明确排除了该参与者进入此（可选）用例。
没有必要也关联Receptionist，Update...因为它是 的扩展View...，除非您希望能够在Update没有Viewing 的情况下先进行。
注意<<include>>/<<extend>>：它们并不意味着链接用例。UML 规范声明（第 638 页）：
当有一些额外的行为可能有条件地添加到一个或多个 UseCases 中定义的行为时，应使用 Extend。
和
当两个或多个 UseCases 的行为有共同部分时，应使用 Include 关系。然后将此公共部分提取到一个单独的用例中，以包含在所有具有该部分共同的基本用例中。
现在<<include>>看起来就像个混蛋。用例是关于一个独特的附加值。如果在多个用例中存在行为重复，这种独特性可能会受到质疑。在任何情况下，这些关系通常只被视为功能分解。那将是完全错误的。从我的 POV 来看，如果没有这些关系，UML 规范会更好。
在上图的上下文中，它代表了一种模式，您可以在其中查看某些内容，然后才能使其可编辑。最好有两个单独的气泡，而不用<<extend>>在哪里设置Update限制{ can only be reached after View... }。
于 2017-11-09T14:42:44.963 回答
0
我会通过包含更改扩展。要更新作品，您必须查看它。必须查看它。
在您的图表中，Manager 和 Receptionnist 是等效的，仅使用此模式，您只能定义一个参与者。或者 Manager 从 Receptionnist 继承的模型。
并且为避免错误，如果您这样做，您必须确保接待员和经理也可以在没有更新的情况下激活视图用例。否则必须删除一些关联。
于 2017-11-09T13:45:00.867 回答