我以前从未制作过用例图，所以我想知道我的是否正确。
2932 次
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 回答