Uml 你会在用例图上展示参与者不能做的事情吗？

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

---

或者这仅仅是因为他们不会有一条线将他们连接到特定的用例吗？

不。演员会连接到他所能做的一切。如果参与者不能做到这一点，那么它就不会显示。

如果您正在绘制的用例是参与者试图做一些不允许的事情，然后被拒绝，那么是的，我会显示它

---

否则，我会坚持只包含实际属于用例一部分的内容。

您可以为能够完成任务的角色扮演者建模。然后，您可以使用另一个用例，让原始参与者尝试获取给定角色。

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

我认为这个问题和大多数答案对用例的使用方式产生了错误的印象

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

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

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

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

然而，保持与目标对应的参与者的最新名单是次要的。进行利益相关者分析，制定参与者列表是确定用户目标的一种手段。在确定了用户目标之后，严格地说，不再需要保留参与者列表

---

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

这并不完全是你想要的，而是在谷歌上查找误用案例。以下是由主持人删除的答案，因此我将其包括在这里，因为我认为它增加了一些内容。。。“如果我们对一个网站进行建模，我们只会显示不同角色的参与者有哪些访问权限，但如果我们对网站背后的权限系统进行建模，我们可以显示被拒绝的权限请求”