用例可以没有演员吗？
Can a use case be without an actor?
我正在绘制全自动系统的用例图。外部系统只会触发该系统的一个用例。大多数其他用例都是计划任务并由计时器调用。我有一个由计时器调用的用例，它包括并扩展了另外两个用例。
当我写用例描述时，UC-2 和 UC-3 的演员是谁。一个用例可以没有参与者而存在吗？我见过很多用例图，其中包含或扩展了用例，但没有直接连接到参与者。请澄清这一点。提前致谢。
编辑：
我的系统与 DBMS 相连。我的系统会时不时地分析数据库的工作负载，检查是否可以做任何调整。这就是我的系统。 UC-1 是分析 DBMS，UC-2 是检查性能统计数据，UC-3 是调整数据库。所以定时器是调用用例的定时器。 DBMS 在另一个用例中重复检查性能 (UC-2) 中的 benefit.Steps。这就是为什么我把它作为一个单独的用例。另一方面，Tune database(UC-3)只有在分析数据库后需要调优时才会执行。
官方说法是正确的。包含用例是包含用例的强制性部分，扩展用例将选择性地扩展某些用例。正如@Ister 在评论中指出的那样，included/extending 用例的参与者将是主要用例的参与者。
但是，根据我的经验，您最好避免使用那些 include/extend 关系。在大多数情况下，人们倾向于将它们用于功能分解，这是完全错误的。用例应显示其参与者的附加值，而不是某个功能在某处的使用方式。在大多数情况下，附加值的结构不存在，您可以很好地将每个气泡显示为一个独立的用例或将其集成到主要用例中。我建议阅读 Bittner/Spence 以进入正题。
Edit1: 我刚刚意识到了这句话
trigger just one use case of this system
这听起来像是将用例与活动混合在一起。这不是一个功能。用例是附加值。有一个具有触发器的用例场景（集）。但是说 "a use case is triggered" 听起来是错误的。您触发用例的活动（它开始变得技术性）。大多数技术人员都难以对用例进行切割和抽象。阅读 Bittner/Spence.
的又一个理由
Edit2：在您的评论中，您谈论的是技术用例。我承认我过去曾就此进行过深入的讨论。但是您需要区分技术和业务。您的业务用例是 Analyse DBMS、Check Performance 和 Tune database。因此，它们不是 Timer 的 UC，而是某些关心性能的机构的 UC。 Timer 的唯一 UC 是 Trigger task（或类似的东西）。有一个切口。 Timer 不关心业务。它会以同样的方式愉快地触发系统关闭。它并不仅仅因为它在技术上用于启动一些与业务相关的流程这一事实而成为业务参与者。
不要忘记：阅读 Bittner/Spence。对我来说，这本书让我大开眼界，因为我也不知道用例的意图。
用例总是由参与者执行的场景。在您的情况下，主要参与者是正在讨论的系统。
从技术上讲，您可以引入一个计时器作为执行第一个 UC-1 步骤的演员，但更好的是 KISS。只需通过通用约定在 UC-1 步骤之前添加一行：
Trigger: timer according to [Link to requirements about timer schedule].
如果你必须在这一行之外写一些东西（例如定时器在触发 UC-1 之前检查条件）那么定时器必须成为一个演员。
总的来说，你的用例结构对我来说非常有效，只是不要忘记将 UC-1 连接到更高的目标。请删除 extends/includes 如前所述。
UC2 和 UC3 可能不是真正的用例，但实际上 steps/actions 在 UC1 中。检查您是否有真实用例的一个好方法是问问自己是否有任何参与者（人、系统或时间等）会将该用例作为一个完整的目标。换句话说，任何参与者都会启动这个用例。除此之外——有时您可能有一个没有参与者发起的用例。只有在有多个其他用例（即至少 2 个）将包含或扩展该用例的情况下才会发生这种情况。在这种情况下，用例的目的是促进模型中的重用和简化模型——尤其是在编写用例叙述时。不要特意创建包含和扩展关系，始终仔细检查 - 如果没有参与者使用您正在包含或扩展的用例，并且没有其他用例正在使用它，那么您绝对不需要它。
我正在绘制全自动系统的用例图。外部系统只会触发该系统的一个用例。大多数其他用例都是计划任务并由计时器调用。我有一个由计时器调用的用例，它包括并扩展了另外两个用例。
当我写用例描述时，UC-2 和 UC-3 的演员是谁。一个用例可以没有参与者而存在吗？我见过很多用例图，其中包含或扩展了用例，但没有直接连接到参与者。请澄清这一点。提前致谢。
编辑： 我的系统与 DBMS 相连。我的系统会时不时地分析数据库的工作负载，检查是否可以做任何调整。这就是我的系统。 UC-1 是分析 DBMS，UC-2 是检查性能统计数据，UC-3 是调整数据库。所以定时器是调用用例的定时器。 DBMS 在另一个用例中重复检查性能 (UC-2) 中的 benefit.Steps。这就是为什么我把它作为一个单独的用例。另一方面，Tune database(UC-3)只有在分析数据库后需要调优时才会执行。
官方说法是正确的。包含用例是包含用例的强制性部分，扩展用例将选择性地扩展某些用例。正如@Ister 在评论中指出的那样，included/extending 用例的参与者将是主要用例的参与者。
但是，根据我的经验，您最好避免使用那些 include/extend 关系。在大多数情况下，人们倾向于将它们用于功能分解，这是完全错误的。用例应显示其参与者的附加值，而不是某个功能在某处的使用方式。在大多数情况下，附加值的结构不存在，您可以很好地将每个气泡显示为一个独立的用例或将其集成到主要用例中。我建议阅读 Bittner/Spence 以进入正题。
Edit1: 我刚刚意识到了这句话
trigger just one use case of this system
这听起来像是将用例与活动混合在一起。这不是一个功能。用例是附加值。有一个具有触发器的用例场景（集）。但是说 "a use case is triggered" 听起来是错误的。您触发用例的活动（它开始变得技术性）。大多数技术人员都难以对用例进行切割和抽象。阅读 Bittner/Spence.
的又一个理由Edit2：在您的评论中，您谈论的是技术用例。我承认我过去曾就此进行过深入的讨论。但是您需要区分技术和业务。您的业务用例是 Analyse DBMS、Check Performance 和 Tune database。因此，它们不是 Timer 的 UC，而是某些关心性能的机构的 UC。 Timer 的唯一 UC 是 Trigger task（或类似的东西）。有一个切口。 Timer 不关心业务。它会以同样的方式愉快地触发系统关闭。它并不仅仅因为它在技术上用于启动一些与业务相关的流程这一事实而成为业务参与者。
不要忘记：阅读 Bittner/Spence。对我来说，这本书让我大开眼界，因为我也不知道用例的意图。
用例总是由参与者执行的场景。在您的情况下，主要参与者是正在讨论的系统。
从技术上讲，您可以引入一个计时器作为执行第一个 UC-1 步骤的演员，但更好的是 KISS。只需通过通用约定在 UC-1 步骤之前添加一行：
Trigger: timer according to [Link to requirements about timer schedule].
如果你必须在这一行之外写一些东西（例如定时器在触发 UC-1 之前检查条件）那么定时器必须成为一个演员。
总的来说，你的用例结构对我来说非常有效，只是不要忘记将 UC-1 连接到更高的目标。请删除 extends/includes 如前所述。
UC2 和 UC3 可能不是真正的用例，但实际上 steps/actions 在 UC1 中。检查您是否有真实用例的一个好方法是问问自己是否有任何参与者（人、系统或时间等）会将该用例作为一个完整的目标。换句话说，任何参与者都会启动这个用例。除此之外——有时您可能有一个没有参与者发起的用例。只有在有多个其他用例（即至少 2 个）将包含或扩展该用例的情况下才会发生这种情况。在这种情况下，用例的目的是促进模型中的重用和简化模型——尤其是在编写用例叙述时。不要特意创建包含和扩展关系，始终仔细检查 - 如果没有参与者使用您正在包含或扩展的用例，并且没有其他用例正在使用它，那么您绝对不需要它。