问题描述
我对 UML 相当陌生，尤其是用例。我的问题是我们是否应该划分用例来表示我们系统的流程？
例如，派对管理系统具有派对控制、任务控制和参与者等功能控制。一个参与者可以加入多方，方可以有多个参与者。
用户登录后可以通过显示派对按钮选择他们当前注册的所有派对。用户可以创建派对，因此他们将成为主持人，以便他们可以邀请参与者加入并给他们任务。 选择一方会将用户引导至聚会名称页面。从那里，主持人可以通过参与者控制标签邀请参与者，将他们的角色更改为主持人或参与者在包含在特定派对中的任务控制标签中为他们处理任务。 主持人可以在派对控制标签中将派对类型更改为开放/邀请或更改名称和日期。 只有主持人可以修改派对详情和分配任务，参与者可以查看分配给他们的任务但不能修改任何内容。所有选项卡都放置在左侧菜单栏中。
我们有 2 个主要参与者，主持人和参与者。所以我的问题从这里开始：
1。我是否应该将用例划分为 4 个用例：所有当事人（将有显示当事人流程）、当事人控制、任务控制、参与者控制就像系统的基本流程一样（登录后，用户在仪表板中。从仪表板中，选择显示派对—> 派对控制、任务控制、参与者控制）？
2. 对于每个用例图，如果只需要一个用例图，我将添加一个流程图来进一步说明用户如何与系统交互在这种情况下，我应该将这些功能分解成许多流程图吗？
感谢您阅读我的问题！
解决方法
是的，用例可以分解成几个不同的图表，每个图表显示更大模型的一部分。
但不，不是按流程细分：用例不适用于对流程进行建模。用例应与用户目标相对应，不应展示如何实现这些目标：
-
对于用户界面详细信息（例如，指向某个功能的按钮，然后是下一个...），您可以使用 wireframes
-
为了更全面地设计用户体验，您可以考虑使用 story boards 或 user journey maps。
-
对于详细的控制或对象流，您可以考虑使用活动图而不是流程图。事实上，活动图可以指定允许实现复杂用例的行为。但是，要抵挡住“可视化编程”的诱惑。
但是用例本身应该独立于它的实现方式，并为以用户为中心的 UI 设计留下自由。该系统能为用户做什么是图表应该回答的主要问题。
,不！您所说的是功能分解，而不是用例（图表）的一部分。用例“只是”显示了它为所考虑系统的参与者提供的附加价值。
当涉及到实施细节或“用户故事”时，您可以使用类似 Cockburn 的文本描述或选择活动图。如果您有复杂的场景，也可以混合使用。但是，从那时起您就不应该有重叠了：哪个说的是实话。随着时间的推移，编辑可能会出现分歧并留下一些混乱。
一如既往，我建议阅读 Bittner/Spence 关于用例！
附言基本上 @Christophe's 和我的答案是相似的，或者至少它们不矛盾。我只是强调一点，功能分解在用例级别是行不通的。