logo标签列表

除了"<<extend>>"和"<<include>>"之外，UML用例图中还有哪些显示依赖关系的方式？

umluse-case
3

除了“扩展”或“包含”之外，我们如何显示用例之间的简单依赖关系。例如，我们想说use case1依赖于由user1完成的use case2。可以使用简单的箭头吗？箭头应该指向哪个方向？

3个回答
3

是的，还有其他依赖关系。

直接连接到用例的完整类列表如下（UML 2.5标准图18.1）:

  • 用例
  • 约束
  • 参与者
  • 包含
  • 扩展
  • 扩展点

但这并不意味着您不能在用例图中使用其他UML元素。UML标准未将任何元素限制在图表中。您甚至可以在一个图表中使用所有UML元素。当然，那样是没有意义的。

例如，实际可用的工具集可以查看VP UML的用例调色板上的元素。除了已经提到的之外，还有：

  • 系统
  • 依赖
  • 一般化
  • 实现
  • 协作
  • 注释
  • 锚点
  • 包容

此处你可以看到一个简短的带解释的列表。

正如您所见，依赖关系不仅被标准允许，而且被广泛使用。

1
您有多种可能展示用例之间的依赖关系。除了使用 << extend >> 和 << includes >> 之外，还有更多可用的关键词。
  1. << requires >> - 表示 UC2 需要先执行 UC1。
  2. << follows >> - 表示该用例紧随另一个用例执行。
  3. << resembles >> - 表示该用例与另一个用例在结果和前置条件上相似，但活动不同。
  4. << equivalent >> - 相同的用例但名称不同。

在您的情况下，我会从演员 (user1) 指向 case1，然后 case1 << includes >> case2。您需要时刻记住图表的目的。如果您将 UML 用作草图，则仅需确保图表可理解且在范围内即可。过度规范化并不能支持此目的。

1
你能提供“更多关键字”的来源链接吗？它们是由哪个 UML 剖面定义的？ - xmojmr
1
你说：“用例1依赖于由用户1完成的用例2”。
请你澄清一下，UC1如何依赖于UC2？
UC建模可能非常棘手。对于建模者来说，很容易忘记UC实际上是什么，并将一些其他系统问题混合到模型中。
UC模型不应表达从底层系统结构导出的依赖关系。例如，如果UC1是由实现UC2的组件实现的，则在UC模型本身中不显示此情况。你所谈论的依赖关系是否属于这种情况？
两个UC之间的执行顺序通常也隐藏在图表中（可以通过前置条件和后置条件间接显示，但不使用关系）。
我的建议是尽可能保持UC模型简单，并限制适度使用“包含”和“扩展”的关系。UC可以被看作是与演员和系统之间的互动，对话的抽象。一个对话怎么能取决于其他对话呢？
网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接