关于 UML 用例图的问题

Question

我正在为我正在创建的示例应用程序中的各种场景创建用例图。这是为了纯粹的学习，实际上并没有在 UML 图规划阶段之外实施。

这个移动应用程序的广义概念是健身计划。用户可以输入他在健身房所做的事情，可以看到他的活动结果等。一次只有一个用户，想想一个 iPhone 应用程序。

那么我假设这样的事情唯一涉及的参与者是应用程序用户本身是正确的吗？其他一切都将由系统处理。

因此，出于我的问题的目的，我只想列出应用程序用户在使用此应用程序时可能遇到的 5 个假设场景。

 1. User creates an account in the application
 2. User creates his own custom exercise he can perform
 3. User checks his fitness stats/activity/data (whatever you wanna call it)
 4. User exercises! (Records new data into the application)

所以我的问题是，这一切会被编译成 1 个单一的 UML 用例图吗？那么它看起来像 A 还是 B？

那么对于这样的应用程序，应用程序用户的所有可能用途是否会被封装到一个单独的用例图 (A) 中？还是应该为每个场景（B）分成多个用例图？还是我一起错过了大局？用例图是否应该隐藏实现细节或者我应该进一步阐述？我在这里没有使用任何 > 或 > 关系，因为我不确定是否应该深入研究实现细节。

想法？

Answer 1

A 肯定更好。

始终将相关用例（或其他元素）组合在一张图表上，以帮助读者理解上下文。

这个上下文可以是很多东西，比如： - 一个功能模块 - 单个参与者的用例 - 可从同一页面访问的用例 - 所有用例（如果问题很小，比如你的）。 - 任何你觉得有用的东西

在图表上使用单个 UC 只有缺点： - 绘制更多图表（降低生产力/效率） - 用例之间的关系丢失（不太清晰） - 模型更大，更难搜索、导航和维护

还要记住，UC 是一组场景，而不是单个场景！

Answer 2

选择 A 是首选，因为它让读者一眼就能对用例有更广泛的了解。当您有更多参与者时，这一点变得更加重要：应用程序用户、技术支持、系统管理员等。一些用例被多个参与者使用，并且通过在单个图表上拥有多个参与者和多个用例来明确这一点。