用例可以没有参与者吗？

Question

我正在研究一个全自动系统的用例图。外部系统只会触发该系统的一个用例。大多数其他用例都是调度的任务，并由计时器调用。我有一个由计时器调用的用例，它包括并扩展了另外两个用例。

​

​

当我写用例描述时，谁将是UC-2和UC-3的主角。在没有参与者的情况下，用例是否存在？我见过很多用例图，它们包括或扩展了用例，而没有直接连接到参与者。请澄清这一点。提前谢谢。

编辑:我的系统与DBMS连接。我的系统将不时地分析数据库工作负载，并检查是否可以进行任何调优。这都是关于我的系统。UC-1是分析DBMS，UC-2是检查性能统计，UC-3是调优数据库.因此，timer是调用用例的那个。数据库管理系统在另一个用例中重复benefit.Steps的检查性能(UC-2)。这就是为什么我把它作为一个单独的用例。另一方面，只有在分析数据库后需要进行调优时，才会执行调优数据库(UC-3)。

Answer 1

这在官方上是正确的。包含的用例是包含用例的强制部分，扩展用例将可选择地扩展某些用例。正如@Ister在注释中指出的那样，包含/扩展用例的参与者将是主用例的参与者。

但是，根据我的经验，您最好避免使用那些包括/扩展关系。在大多数情况下，人们倾向于将它们用于功能分解，这显然是错误的。用例应该显示其参与者的附加价值，而不是如何在某个地方使用某项功能。在大多数情况下，不存在附加价值的结构，您可以将每个气泡显示为独立的用例，或者将其集成到主用例中。我建议阅读Bittner/Spence来了解问题。

Edit1：我刚意识到这个句子

只触发该系统的一个用例

这听起来更像是将用例与活动混合在一起。这不是一种功能。用例是附加价值。对于具有触发器的用例，有一个场景(集合)。但是说“用例被触发”听起来是错误的。触发用例的活动(在用例中它开始获得技术)。大多数技术人员很难对用例进行裁剪和抽象。还有一个阅读Bittner/Spence的理由。

Edit2：在您的评论中，您讨论的是技术用例。我承认，我过去曾就此事进行过密集的讨论。但是你需要区分技术和商业。您的业务用例是Analyse DBMS、Check Performance和Tune database。因此，它们不是Timer的UCs，而是一些关心性能的机构。Timer的惟一UC是Trigger task (或者类似的东西)。有个伤口。Timer不关心生意。它将愉快地以同样的方式触发系统的关闭。它并不仅仅是因为它在技术上被用来启动一些与业务相关的过程而成为业务参与者。

不要忘记:阅读Bittner/Spence。对我来说，这本书让我大开眼界，因为我也不知道用例的意图。

Answer 2

UC2和UC3很可能不是真正的用例，实际上是UC1中的步骤/操作。检查是否有真实用例的一个好方法是问自己是否有任何参与者(人、系统或时间等)。这将使用例成为一个完整的目标。换句话说，任何参与者都会启动这个用例。除此之外，偶尔也会有一个没有参与者启动的用例。只有在有多个包含或扩展该用例的其他用例(即至少2个)的情况下，才会发生这种情况。在这种情况下，用例的存在是为了促进模型中的重用和简化模型--特别是在编写用例描述时。不要想方设法创建包含和扩展关系，始终要进行双重检查--如果没有任何参与者使用您正在包含或扩展的用例，并且没有其他用例正在使用，那么您绝对不需要它。

Answer 3

用例总是由参与者执行的场景。在您的情况下，主要参与者是正在讨论的系统。

从技术上讲，你可以引入一个计时器作为一个演员谁执行第一UC-1步，但更好的吻。只需在UC-1步骤之前添加一行，通过常见约定：

Trigger: timer according to [Link to requirements about timer schedule].

如果您必须编写超出这一行的内容(例如，在触发UC-1之前，定时器检查条件)，则定时器必须成为参与者。

总的来说，您的用例结构对我来说非常有效，只是不要忘记将UC-1连接到更高的目标。并请删除扩展/包括，如前所述。