Uml 用例可以分解成多个图表吗？

我对UML相当陌生，尤其是用例。我的问题是，我们应该划分用例来表示我们系统的流程吗

例如，团队管理系统具有团队控制、任务控制和参与者控制等功能。一个参与者可以加入多个政党，政党可以有多个参与者

登录后的用户可以通过“显示参与方”按钮选择当前注册的所有参与方。参与者可以由用户创建，因此他们将成为主持人，这样他们就可以邀请参与者加入并给他们任务。 选择一个参与方将引导用户进入参与方名称页面。从那里，主持人可以通过参与者控制选项卡邀请参与者，将他们的角色更改为主持人或参与者处理任务，并将任务控制选项卡包含在特定的团队中。 主持人可以将派对类型更改为仅在派对控制选项卡中打开/邀请，或者更改姓名和日期。 只有主机可以修改团队详细信息和分配任务，参与者可以查看分配给他们的任务，但不能修改任何内容。所有选项卡都放置在左侧菜单栏上

我们有两个主要参与者，主持人和参与者。所以我的问题从这里开始：

1。我是否应该将用例分为4个用例：各方（将有展示方流程），方控制，任务控制，参与者控制，就像系统的基本流程一样（登录后，用户进入仪表板。从仪表板中选择显示参与方->参与方控制，任务控制，参与者控制）

2.对于每个用例图，我将添加一个流程图来进一步说明用户如何与系统交互，如果在这种情况下只需要一个用例图，我是否应该将这些功能分解为多个流程图

---

感谢您阅读我的问题！

是的，用例可以分解为几个不同的图表，每个图表都显示了较大模型的一部分

但是不，不是按流分类的：用例不用于建模流。用例应与用户目标相对应，而不应显示如何实现这些目标：

• 有关用户界面的详细信息（例如，按钮，它指向一个功能，然后是下一个…），您可以使用

对于更广泛的用户体验设计，您可以考虑或。 对于一个详细的控件或对象流，您可以考虑活动图而不是流程图。实际上，活动图可以指定允许实现复杂用例的行为。然而，要经受“可视化编程”的诱惑。

---

但是用例本身应该独立于它是如何实现的，并为以用户为中心的UI设计留下自由。这个系统能为其用户做些什么是图表应该回答的主要问题。

不！你说的是功能分解，而不是用例（图表）的一部分。用例“只是”显示它给所考虑系统的参与者带来的附加值

当涉及到实现细节或“用户故事”时您可以使用类似Cockburn的文本描述，也可以选择活动图。如果您有复杂的场景，也可以混合使用。但是，不应该有重叠，因为您有一个问题：哪一个说的是实话。随着时间的推移，编辑可能会出现分歧，留下一些混乱

和往常一样，我建议阅读关于用例的Bittner/Spence

---

p.S.基本上和我的答案是相似的，或者至少他们没有矛盾。我只是强调了一点，功能分解是一个不可继续的用例级别。

实际上，我要说它必须是独立的，而不仅仅是应该的，因为如果不是这样，它就是功能分解的开始。那就错了。@qwerty_所以我同意，但我不同意仍然在寻找一种更强烈地宣称加州大学独立性的措辞，同时也没有完全阻止表达某种依赖性的扩展和包含。有什么建议吗？嗯。我知道你的问题是什么。我只能说我在很多方面都很严严严（这当然给了我矛盾的陈述/回答）。看看我的答案；-）UC当然可以分解，但只能以非常有限的方式分解。如果你进行这种分解，你已经开始了功能分解。包括/扩展实际上是不好的概念，因为它们经常被错误地使用。哦，我没有看到你的编辑。我想这是一个完美的陈述。尽管如此，我认为OP实际上是ta目标函数分解，这就是为什么我开始回答“否”；-）