我正在研究全自动系统的用例图。外部系统只会触发该系统的一个用例。大多数其他用例都是计划任务并由计时器调用。我有一个由计时器调用的用例,它包含并扩展了其他两个用例。
当我编写用例描述时,谁将成为 UC-2 和 UC-3 的参与者。用例可以在没有参与者的情况下存在吗?我见过很多用例图,其中包含或扩展了用例,但没有直接连接到参与者。请澄清这一点。提前致谢。
编辑:
我的系统与 DBMS 连接。我的系统会不时分析数据库工作负载并检查是否可以进行任何调整。这就是我的系统的全部内容。 UC-1 是分析 DBMS,UC-2 是检查性能统计数据,UC-3 是调整数据库。因此计时器是调用用例的计时器。 DBMS 从中受益。在另一个用例中重复检查性能 (UC-2) 的步骤。这就是为什么我将其作为一个单独的用例。另一方面,只有在分析数据库后需要调整时才会执行数据库调整(UC-3)。
官方认为这是正确的。包含用例是包含用例的强制部分,扩展用例将选择性地扩展某些用例。正如 @Ister 在评论中指出的那样,包含/扩展用例的参与者将是主要用例的参与者。
但是,根据我的经验,您最好避免使用这些包含/扩展关系。在大多数情况下,人们倾向于使用它们进行功能分解,这是完全错误的。用例应显示其参与者的附加值,而不是某个功能如何在某处使用。在大多数情况下,不存在附加值的结构,您可以很好地将每个气泡显示为独立用例或将其集成到主要用例中。我建议阅读 Bittner/Spence 来深入了解问题。
Edit1: 我才明白这句话
仅触发该系统的一个用例
这听起来像是您将用例与活动混合在一起。这不是一个功能。用例是附加值。对于具有触发器的用例,存在一个场景(集)。但说“用例被触发”听起来是错误的。您触发用例的活动(它开始变得技术性)。大多数技术人员都很难对用例进行切割和抽象。阅读比特纳/斯宾塞的又一个理由。
Edit2:在您的评论中您谈论的是技术用例。我承认我过去曾对此进行过深入的讨论。但您需要区分技术和业务。您的业务用例是Analyse DBMS
, Check Performance
, and Tune database
。因此,它们不是 UCTimer
但对于一些关心绩效的机构来说。唯一的 UCTimer
is Trigger task
(或类似的东西)。有一个切口。这Timer
不关心生意。它会以同样的方式愉快地触发系统关闭。它并不仅仅因为它在技术上用于启动某些业务相关流程而成为业务参与者。
不要忘记:阅读 Bittner/Spence。对我来说,这本书让我大开眼界,因为我也不知道用例的意图。
本文内容由网友自发贡献,版权归原作者所有,本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容,请联系:hwhale#tublm.com(使用前将#替换为@)