关于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）的多个用例图？还是我一起错过了大局？用例图是否隐藏了实现细节，还是应该进一步详细说明？我没有使用任何＆lt;＆lt;延伸＆gt;＆gt;或＆lt;＆lt;包括＆gt;＆gt;这里的关系，因为我不确定我是否应该深入了解实施细节。

想法？

Answer 1

选择A是首选，因为它一目了然地为读者提供了更广泛的用例概述。这变得更加重要，因为你有更多的演员：应用程序用户，技术支持，系统管理员等。一些用例由多个演员使用，并通过在一个图表上拥有多个演员和多个用例来明确。 / p>

Answer 2

A确定更好。

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

这个上下文可以是很多东西，比如： - 功能模块 - 单个演员的使用​​案例 - 可从同一页面访问的用例 - 所有用例（如果问题很小，就像你的一样）。 - 无论你发现什么有用

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

另请注意，UC是一组场景，而不是单一场景！