uml - 用例可以没有 Actor 吗？

Question

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



当我编写用例描述时，谁将成为 UC-2 和 UC-3 的参与者。没有参与者的用例可以存在吗？我见过很多用例图，其中包含或扩展了用例，而没有直接连接到参与者。请澄清这一点。提前致谢。

编辑:
我的系统与 DBMS 连接。我的系统会不时分析数据库工作负载并检查是否可以进行任何调整。这就是我的系统。 UC-1 是分析 DBMS，UC-2 是检查性能统计，UC-3 是调优数据库。所以计时器是调用用例的那个。 DBMS 从中受益。检查性能 (UC-2) 中的步骤在另一个用例中重复。这就是为什么我把它作为一个单独的用例。另一方面，只有在分析数据库后需要调优时才会执行调优数据库(UC-3)。

Answer 1

官方这是正确的。包含用例是包含用例的强制性部分，扩展用例将可选地扩展一些用例。正如@Ister 在评论中指出的那样，包含/扩展用例的参与者将是主要用例的参与者。

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

编辑 1 : 我才明白这句话

trigger just one use case of this system

这听起来像是将用例与事件混合在一起。这不是一个功能。用例是附加值。有一个具有触发器的用例的场景(集)。但是说“一个用例被触发”听起来是错误的。您触发用例的事件(它开始变得技术化)。大多数技术人员都难以对用例进行剪裁和抽象。阅读 Bittner/Spence 的另一个理由。

编辑 2 :在您的评论中，您谈论的是技术用例。我承认我过去曾就此进行过深入的讨论。但是您需要区分技术和业务。您的业​​务用例是 Analyse DBMS , Check Performance , 和 Tune database .因此，它们不是 Timer 的 UC。但对于一些关心绩效的机构。 Timer唯一的UC是 Trigger task (或类似的东西)。有一个切口。 Timer不关心生意。它会以同样的方式愉快地触发系统关闭。它不会仅仅因为它在技术上用于启动某些业务相关流程这一事实而成为业务参与者。

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