调度程序是否应该是用例图中的参与者答案

【问题标题】：Should a Scheduler be an actor in a use case diagram调度程序是否应该是用例图中的参与者
【发布时间】：2010-02-11 15:39:48
【问题描述】：

假设作为系统一部分的调度程序负责每周向用户发送电子邮件。应该将“调度程序”视为参与者还是应将其建模为用例？

选择演员的准则说：如果：它是与您的系统交互的真实人。如果“是”它是一个演员其他：是否可以在系统内更改。如果“否”它是一个演员

调度员不是人。你可以改变它的运作方式。但我的直觉告诉我，这可以是一个演员。一点帮助会很棒。

【问题讨论】：

标签： uml modeling use-case

【解决方案1】：

更高级的指南说：如果它可以帮助您理解设计，请将其包含在图表中。如果它只会引入不必要的噪音，请忽略它。

此外，还有一个更高级别的准则：使用常识。

【讨论】：

【解决方案2】：

我经常将调度程序和其他与时间相关的外部代理建模为参与者。它是有道理的，可以理解的，不与 UML 中的任何内容或 OO 建模的常见做法相矛盾，并且非常适合大多数实现策略。

【讨论】：

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

【解决方案3】：

@CesarGon 一个风险可能是您使用用例（图表）作为设计技术而不是需求技术。由于需求技术的重点是针对系统的用户目标和与系统交互的参与者。 TIME 演员没有针对系统的用户目标，所以我尝试找到对系统有目标或兴趣的演员。谁在乎每周的电子邮件不发送？我添加为次要演员的 TIME 演员。 TIME 演员帮助“真正的”演员达到用户目标。

【讨论】：