假设作为系统一部分的调度程序负责每周向用户发送电子邮件。应该将“调度程序”视为参与者还是应该将其建模为用例？
选择演员的指南说：如果：它是与您的系统交互的真实人。如果“是”它是一个演员 Else：它是你可以在系统内改变的东西吗？如果“不”是演员
调度员不是人。你可以改变它的运作方式。但我的直觉告诉我，这可以是一个演员。一点帮助会很棒。
问问题
1426 次
3 回答
1
我经常将调度程序和其他与时间相关的外部代理建模为参与者。它是有道理的，可以理解的，与 UML 中的任何内容或 OO 建模的常见实践没有任何矛盾，并且它非常适合大多数实现策略。
于 2010-03-05T00:54:46.543 回答
1
更高级的指南说：如果它可以帮助您理解设计，请将其包含在图表中。如果它只会引入不必要的噪音，请将其排除在外。
此外，还有一个更高级别的准则：使用常识。
于 2010-02-11T15:45:08.130 回答
1
@CesarGon 风险可能是您使用用例（图表）作为设计技术而不是需求技术。由于需求技术的重点将放在针对系统的用户目标和与系统交互的参与者上。TIME 演员没有针对系统的用户目标，所以我尝试找到对系统有目标或兴趣的演员。谁在乎每周的电子邮件不发送？我添加为次要演员的 TIME 演员。TIME 演员帮助“真正的”演员达到用户目标。
于 2012-06-21T07:42:20.597 回答