uml - 你会在用例图上展示演员不能做的事情吗？

Question

在用例图上，您能否展示参与者不能做的事情，例如因为他们没有权限去做？

还是因为它们没有将它们与特定用例连接起来的事实而只是暗示？

score 5 · Accepted Answer

如果您正在绘制的用例是演员试图做一些不允许的事情然后被拒绝的情况，那么是的，我会展示它。

否则，我会坚持只包括实际上是用例一部分的东西。

score 1 · Accepted Answer

1

不会。Actor 会与他能做的所有事情相关联。如果 Actor 做不到，则不会显示。

于 2008-10-10T15:55:32.160 回答

score 1 · Accepted Answer

这就是替代路径的用途。基本路径（又名快乐路径）将显示正确的 Actor 启动用例时会发生什么。在备用路径中，您可以显示如果错误的 Actor 尝试启动它会发生什么。

score 0 · Accepted Answer

您可以为可以完成任务的角色角色建模。然后，您可能会有另一个用例，其中原始参与者尝试获取给定角色。

score 0 · Accepted Answer

恕我直言，这个问题和大多数答案对用例的使用方式产生了错误的印象。

用例旨在作为一种使用自然语言的需求技术。这种方式是最有效的。

当它与过多的 UML/建模相结合时，它可能是一种彻底的破坏性技术。用例文本的结构化建模（例如，通过使用 UML 活动图对主要流和替代流进行建模）是一种久经考验的方法，例如创建大规模破坏用例。

用例图可能很有用，但我们应该记住用例的目的是一种技术，它首先是识别系统应该支持的用户目标。随后，我们可以使用自然语言在使用主流、替代流等的用例文本中捕获更多细节。

使用图表工具，我们可以可视化一些简单的信息： - 对于每个用户目标，我们可以创建模型元素类型用例。- 使用带有用例元素的系统框显示系统边界。- 在参与者和用例之间建立关系，以表明参与者对系统有特定的目标。

然而，保持映射到目标的最新参与者列表是次要的。进行利益相关者分析，制定参与者列表是确定用户目标的一种方法。在确定了用户目标之后，严格来说不再需要保留参与者列表。

如果我们询问有关如何将用户权限放入用例模型的问题，我们很可能试图捕获太多信息。我们应该将模型元素抽象出来，这样模型就不会试图回答/捕获这些类型的详细设计问题。

5 回答 5