关于UML的问题用例图

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

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

Use Case Choices

因此，对于这样的应用程序将所有由应用用户的可能用途被封装成一个单一的用例图（A）？还是应该将它分解为每个场景（B）的多个用例图？还是我一起错过了大局？用例图假设是隐藏实现细节还是应该进一步阐述？我没有使用任何< <扩展>>或< <这里包括>>关系，因为我不确定是否应该进入更深入的实现细节。

想法？

来源

2014-04-02 asdf

选择A是首选，因为它让读者一眼就能看到更广泛的用例。随着您拥有更多参与者，这变得更加重要：应用程序用户，技术支持，系统管理员等。一些用例被多个参与者使用，并且通过在单个关系图上包含多个参与者和多个用例而变得清晰。

来源

2014-04-02 15:07:46 Bruce

现在将A作为整个系统的用例图，然后针对每个个案更详细地分析实施细节的用例图。感谢您的回复 – asdf

嵌套用例图没有太多价值。它们应该用来显示系统的范围和行为的背景，所以它们应该处于高水平。深入探索用例往往最终会出现在捕获特定场景的活动图和序列图中。 – Bruce

A是definitelly更好。

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

这方面可以有很多的东西，比如： - 一个功能模件 - 单个演员使用情况 - 所有的用例（如果问题是小 - 使用情况下可从同一页面访问，像你的）。 - 不管你觉得有用

有一个图上单一的UC只有缺点： - 更多的图表绘制（少生产力/效率） - 用例之间的关系丢失（少清晰度） - 模型较大并且难以搜索，导航，维护

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

来源

2014-04-09 10:09:34 Aleks

关于UML的问题用例图

回答

相关问题