在用例图中，调度器应该是一个参与者吗？

Question

在用例图中，调度器应该是一个参与者吗？

umlmodelinguse-case

3

假设系统中的调度程序负责向用户发送每周电子邮件。 "调度程序" 应该被视为一个参与者还是应该建模为用例？

选择参与者的准则如下：如果：它是与您的系统交互的实际人员。如果是，则为参与者否则：它是否可以在系统内更改。如果不是，则为参与者

调度程序不是人。而且您可以更改其功能。但是我认为它可以是一个参与者。需要一点帮助。

- djmlog103

3个回答

1

我经常将调度器和其他时间相关的外部代理建模为对象。这是有意义的，易于理解的，在UML或面向对象建模的常见实践中不会产生矛盾，并且与大多数实现策略非常契合。

- CesarGon

一个风险可能是您将用例（图表）作为设计技术而不是需求技术。我更喜欢使用用例来捕获需求。 - onknows

1

@CesarGon 一个风险可能是您将用例（图表）作为设计技术而不是要求技术。作为要求技术，重点应放在用户目标与系统以及与系统交互的参与者之间。时间参与者没有针对系统的用户目标，因此我尝试找到具有针对系统的目标或利益的参与者。当每周电子邮件未发送时，谁会关心？我将TIME参与者添加为辅助参与者。 TIME参与者帮助“真正”的参与者实现用户目标。

- onknows

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- shoosh · Accepted Answer

更高级别的指导原则是：如果它有助于您理解设计，请在图表中包含它。如果它只会引入不必要的噪音，则不要包含它。

另外，更高层次的指导原则是：运用常识。