你会展示一个Actor在用例图上不能做的事吗?

时间:2008-10-10 15:48:05

标签: uml use-case

在用例图上,您可以显示演员不能做的事情,例如因为他们没有权限这样做吗?

或者它是否仅仅是隐含的,因为它们不会将它们连接到特定的用例?

5 个答案:

答案 0 :(得分:5)

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

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

答案 1 :(得分:1)

没有。一个演员将与他能做的一切联系起来。如果演员不能这样做,那么就不会显示。

答案 2 :(得分:1)

这是备用路径的用途。基本路径(a.k.a. happy path)将显示正确的Actor启动用例时会发生什么。在备用路径中,您可以显示如果错误的Actor尝试启动它会发生什么。

答案 3 :(得分:0)

您可以为可以执行任务的角色扮演者建模。然后,您可以使用另一个用例,原始actor将尝试获取给定的角色。

答案 4 :(得分:0)

恕我直言,这个问题和大多数答案给出了用例使用方式的错误印象。

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

当它与过多的UML /建模相结合时,它可能是一种彻底的破坏性技术。用例文本的结构化建模,例如通过使用UML活动图对主流和备用流建模,是一种经过试验的方法,例如创建Use Cases of Mass Destruction

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

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

保持最新的演员列表映射到目标是次要的。进行利益相关者分析,制定参与者列表是识别用户目标的一种手段。在确定了用户目标之后,严格来说,不再需要保留演员列表。

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