Model 关于UML用例图的问题

我正在为我正在创建的示例应用程序中的各种场景创建用例图。这是为了纯粹的学习，实际上在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)

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

那么对于这样的应用程序，应用程序用户的所有可能用途是否都封装在一个单一用例图（A）中？或者应该为每个场景（B）将其拆分为多个用例图？还是我都错过了大局？用例图是否应该隐藏实现细节，还是应该进一步详细说明？我在这里没有使用任何>或>关系，因为我不确定是否应该深入了解实现细节

---

想法？

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

a确实更好

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

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

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

---

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

现在是整个系统的用例图，然后将每个用例图分开，深入到实现细节中？感谢您的响应。从嵌套的用例图中获得的价值不大。它们应该用于显示系统的范围和行为的上下文，因此它们应该处于较高的级别。深入研究用例通常会在捕捉特定场景的活动图和序列图中结束。