1

用例图

我以前从未制作过用例图，所以我想知道我的是否正确。

4

1 回答 1

4

简而言之

这是一个（几乎）有效的用例图。但这并不能使它们成为好的用例。但最终重要的是它是否对您有用。

更多细节

根据 UML，它在形式上是正确的吗？

UML 与价值无关，并在规范的第 637 页定义了 UC（由我强调）：

UseCase 是一种 BehavioredClassifier，它表示一组提供的行为的声明。每个 UseCase 指定 主体可以与一个或多个 Actor 协作执行的一些行为。用例定义主题的提供行为，而不参考其内部结构。这些行为，涉及 演员和主体之间的交互，可能会导致主体状态的变化以及与其环境的通信。

让我们根据这个定义检查你的 UC 的有效性：

  • Start game、move paddle、restart game和exit game是游戏（主体）与玩家（演员）合作提供的行为。根据 UML，这些是有效的 UC。
  • Ball falls、hit all bricks、hit brick和display score是更值得怀疑的行为：它们不需要与玩家合作或互动。尽管如此，您仍可以争辩说，只有当用户观察到这些行为时，这些才有意义，因此与玩家进行了交互。所以可以说这些也是关于 UML 定义的有效 UC。
  • Add score似乎是一种纯粹的内部行为，在没有用户的情况下完成，甚至没有被用户观察到。这将不是一个有效的 UC。然而，标签可能会产生误导：如果它Display score意味着最终的游戏结束分数并且Add score意味着屏幕上分数的更新，那么它可能再次被认为是一个有效的 UC。

扩展（可选）和包含（系统）的使用似乎也是正确的。

这是一个好的UC吗？

虽然 UML 与价值无关，但许多作者以更模糊的方式定义用例。特别是Ivar Jacobson，用例的发明者将其定义为：

用例是使用系统为特定用户实现特定目标的所有方式。所有用例集合在一起，为您提供了使用系统的所有有用方法，并说明了它将提供的价值。

根据这个定义，这里只有一个用例：

  • Play a game：这是用户为他/她带来价值的目标。

所有其他元素只是使用系统实现这一目标的方法。所以它们属于单一用例。一种方法是将它们表示为用例描述的细节：

  • 一种合适的方法是在基本用例中根据意图来显示这些。这种方法是康斯坦丁和洛克伍德在 1999 年发明的。它被居中使用，并且在用户界面中的操作顺序方面具有完全的灵活性。

  • 另一种现代方式是 Ivar Jacobson 在 2011 年发明的Use-Case 2.0。这些细节将显示为用例切片，其方式与用户故事非常相似。

于 2020-05-08T16:26:32.817 回答