用例可以没有演员吗?

Dee*_*ool 6 uml use-case

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

在此输入图像描述

当我写用例说明时,谁将成为UC-2和UC-3的演员.没有演员可以存在一个用例吗?我已经看到很多用例图包含或扩展了用例而没有直接连接到一个actor.请澄清一下.提前致谢.

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

qwe*_*_so 5

这是正确的.包含的用例是包含用例的必需部分,扩展用例可以选择扩展一些用例.正如@Ister在注释中注释的那样,包含/扩展用例的actor将是主要用例的actor.

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

编辑1:我才意识到这句话

触发这个系统的一个用例

这听起来像是将用例与活动混合在一起.这不是一个功能.用例是附加值.有一个具有触发器的用例的场景(集).但是说"用例被触发"听起来错了.您触发用例的活动(它开始获得技术).大多数技术人员都难以完成切割和抽象用例.阅读Bittner/Spence的另一个原因.

编辑2:在您的评论中,您正在谈论技术用例.我承认我过去曾对此进行过深入的讨论.但您需要区分技术和业务.你的商业用例Analyse DBMS,Check PerformanceTune database.因此,Timer对于一些关心绩效的机构来说,它们不是一个联合公司.唯一的UC TimerTrigger task(或类似的东西).有一个削减.该Timer不关心生意.它将以同样的方式愉快地触发系统的关闭.它不会成为商业行为者,因为它在技术上用于启动一些业务相关流程.

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