我正在研究全自动系统的用例图。外部系统只会触发该系统的一个用例。大多数其他用例是计划任务并由计时器调用。我有一个由计时器调用的用例,它包括并扩展了另外两个用例。
当我写用例说明时,谁将成为UC-2和UC-3的演员。没有演员可以存在一个用例吗?我已经看到很多用例图包含或扩展了用例而没有直接连接到一个actor。请澄清一下。提前谢谢。
编辑: 我的系统与DBMS连接。我的系统会不时地分析数据库工作负载并检查是否可以进行任何调整。这就是我的系统。 UC-1是分析DBMS,UC-2是检查性能统计,UC-3是调整数据库。因此,计时器是调用用例的计时器。 DBMS获益。在另一个用例中重复检查性能(UC-2)中的步骤。这就是为什么我把它作为一个单独的用例。另一方面,只有在分析数据库后需要进行调整时才会执行Tune数据库(UC-3)。
答案 0 :(得分:5)
官方说这是正确的。包含的用例是包含用例的必需部分,扩展用例可以选择扩展一些用例。正如@Ister在注释中注释的那样,包含/扩展用例的actor将是主要用例的actor。
但是,根据我的经验,你最好避免使用那些包含/扩展关系。在大多数情况下,人们倾向于使用它们进行功能分解,这是完全错误的。用例应显示其actor的附加值,而不是某个功能如何在某处使用。在大多数情况下,不存在附加值的结构,您可以将每个气泡显示为独立用例或将其集成到主要用例中。我建议阅读Bittner / Spence来解决问题。
Edit1 :我刚刚意识到这句话
只触发此系统的一个用例
这听起来像是将用例与活动混合在一起。这不是一个功能。用例是附加值。有一个具有触发器的用例的场景(集)。但是说“用例被触发”听起来错了。您触发用例的活动(它开始获得技术)。大多数技术人员都难以完成切割和抽象用例。阅读Bittner / Spence的另一个原因。
Edit2 :在您的评论中,您谈论的是技术用例。我承认我过去曾对此进行过深入的讨论。但您需要区分技术和业务。您的业务用例包括Analyse DBMS
,Check Performance
和Tune database
。因此,它们不是Timer
的UC,而是一些关心性能的机构。 Timer
的唯一UC是Trigger task
(或类似的东西)。有一个削减。 Timer
并不关心业务。它将以同样的方式愉快地触发系统的关闭。它不会成为商业行为者,因为它在技术上用于启动一些与业务相关的过程。
不要忘记:阅读Bittner / Spence。对我来说,这本书令人大开眼界,因为我也不知道用例的意图。
答案 1 :(得分:0)
用例始终是由actor执行的场景。在您的情况下,主要参与者是正在讨论的系统。
从技术上讲,你可以引入一个计时器作为执行第一步UC-1步骤的演员,但更好的KISS。只需通过常规惯例在UC-1步骤之前添加一行:
Trigger: timer according to [Link to requirements about timer schedule].
如果你必须写出超出这一行的东西(例如在触发UC-1之前计时器检查条件),那么计时器必须成为一个演员。
总体而言,您的用例结构对我来说看起来非常有效,但是不要忘记将UC-1连接到更高的目标。请删除已提及的extends / includes。
答案 2 :(得分:0)
UC2和UC3很可能不是真正的用例,而是UC1中的步骤/动作。检查您是否有真实用例的一个好方法是询问您自己是否有任何将该用例作为完整目标的演员(人,系统或时间等)。换句话说,任何演员都会发起这个用例。除此之外 - 偶尔你可能有一个没有演员发起的用例。这应仅在存在多个其他用例(即至少2个)的情况下发生,这些用例将包括或扩展该用例。在这种情况下,用例是为了便于在模型中重用并简化模型 - 特别是在编写用例叙述时。不要忘记创建包含和扩展关系总是仔细检查 - 如果没有演员正在使用您包含或扩展的用例,并且没有其他用例正在使用它,那么您绝对不需要它