Uml 设计用例图的正确方法

[原始标题]：参与者需要在用例图中直接指出吗？

---

或者我可以这样做吗

在这个用例图中，我想说actor可以使用指向的用例组中的任何用例

这种事情允许吗

编辑#1

我问这个问题的原因是，当我创建这个用例时，有很多线相互交叉，这让我感到困惑

还有一条评论：

最好将其拆分为更小的图表

是这样的意思吗

编辑#2

阅读评论后：

用例指定了一组由其主题执行的动作，这会产生一个可观察的结果，该结果对每个主题的一个或多个参与者或其他利益相关者都有价值

因此，我决定改为：

用例图应该是这样的吗

编辑#3

结论

• 参与者应该直接指向用例
• 阅读更多关于用例图应该如何在这个问题上发表评论的细节

---

要符合UML，您不能这样做。但我想人们可以理解你想表达的意思
作为旁注：

Login

不是业务用例。这是一种限制。同样对于CRUD用例，我不会将它们分开，而是使用一个

mainter

（这本身就是一个边界用例，因为维护某些东西与业务无关）。您可以分别将维护操作约束到某些参与者
编辑关于

登录

（我的最爱之一）：用例最常用于描述业务上下文（与您所做的完全相同）。因此，从业务的角度来看，

登录

不是一个用例，而是一个简单的约束（只有在登录时才能执行与业务相关的操作）

---

现在来看

管理/维护

用例。他们处于相似的水平。通常，“管理”本身与业务没有直接关系。在许多情况下，人们不再关注真正的业务。因此，您管理某些东西的原因是真实的用例（例如，正确的用户数据、收集用户数据）。这是相当具有挑战性的，我承认有时我也会回到

管理

。大多数人不会为此烦恼，但做好工作需要考虑基本问题，而不是养成坏习惯。
虽然没有人会因为你这样做而惩罚你，但我认为这是好的。但有一件事是，颜色方案令人困惑，使用venn图进行分组可能会更好。我认为在图上多次显示同一参与者是相当令人困惑的，而且它肯定不是UML。此外，我不会在图表上添加这么多东西。最好将其拆分为更小的图表。不，官方定义是：

UseCase指定由其主题执行的一组操作，这会产生一个可观察的结果，对一个或多个参与者或每个主题的其他利益相关者都有价值。

在这种情况下，我认为

查看主页

对参与者几乎没有价值，我可以想象这也不是一组复杂的操作。因此，您可能可以安全地忽略这一点，并在关于主页的其他用例中添加一个步骤或前提条件。UML标准由对象管理组（OMG）管理。请参阅官方规范。是的，这就是用例的意义所在！干得好。是否需要解释有关

维护的更多信息？另外，用例不应该是
参与者可以用系统做什么
？请检查我编辑的问题。这是一个合适的用例吗？我在回答中添加了一些信息。