TIME 是用例中的参与者吗？答案

【问题标题】：Is TIME an actor in a use case?TIME 是用例中的参与者吗？
【发布时间】：2009-05-12 23:14:34
【问题描述】：

好吧，关于一个真假问题：

a) 系统的参与者仅由人类或其他软件组件表示。

我说的是真的，老师把它标记为错误，不是因为他认为我错过了硬件组件（我想我会部分让步），而是因为，用他的话来说：

“TIME也是演员。”

用例图如何将 TIME 视为参与者？

请参阅任何将时间视为演员的参考书目。我没有找到任何东西，说实话，我认为这没有任何意义。时间不会自己行动，它要么是一个系统，要么是一个按计划工作的人。

【问题讨论】：

一定要用飘逸的白胡子和沙漏来画...
是的，我想这就是这家伙想要的。

标签： uml use-case

【解决方案1】：

这里是 UML 2 用例图表指南...

http://www.agilemodeling.com/style/useCaseDiagram.htm

...展示如何表示时间。

我怀疑你应该请你的老师解释时间是一个演员，以及它是如何在用例图中表示的，因为毕竟，他们将标记你的下一个作业，因此他们的解释胜过所有其他人：- )

哦，维基百科说时间是一个演员，所以它一定是真的：

http://en.wikipedia.org/wiki/Use_case

【讨论】：

您的链接显示：参与者是在与您的系统的一个或多个交互中扮演角色的个人、组织或外部系统（参与者通常在 UML 用例图上绘制为简笔画）。
然后将一个名为 Time 的 person 或“system*”标记为按计划工作的人，而不是一个单独工作的神奇神秘实体。
时间是一个“外部系统”。查看 Actor 定义下方的第 8 点。它说明了作为演员添加的时间。
是的，我已经引用了它，我觉得它很愚蠢，因为它不是自己行动的东西，而是系统本身安排的条件，谁才是真正“行动”的人.无论哪种方式，感谢您对荒谬经典的晦涩参考。您的答案被标记为已接受。
我想我的主要答案是“让你的老师说服你”然后“理解你的老师的想法，即使你不同意，因为知道他们相信什么可以让你获得高分”。我完全赞同你的观点——这只是我在使用 UML 时遇到的众多问题之一。

【解决方案2】：

我不同意时间是演员。您真正需要考虑的是谁将从行动中受益，并在功能描述中设置时间表的创建和执行。看看这篇文章：

Dr. Use Case

【讨论】：

这是一篇很棒的文章，感谢您的链接。我告诉我的学生的一件事是，这部分是关于你试图传达的内容。用例建模旨在以清晰、一致的方式向多个受众传达有关系统设计的信息。如果他们的建模实现了这个目标（无论我们选择使用时间作为演员还是不使用），我们就成功了。出于这个原因，虽然我在文章中一直点头，但因为使用 Time 作为演员传达了系统中的一个重要触发器，我建议使用它。

【解决方案3】：

可以将参与者视为启动用例的某人或某事。计划任务按“时间”启动。从这个意义上说，“时间”是一个参与者，因为它启动了一个用例。

例子：

必须每 6 小时生成一份报告。所以，时间“6 hours”一定是actor，因为generate task会每6小时启动一次。

【讨论】：

请展示演员“时间”与系统交互的示例。我相信时间不会自己行动，它要么是一个与计时器一起工作的系统，要么是一个按时间表行动的人。
在阅读这个问题之前，您是否考虑过作为演员的时间？我一直认为您提供的案例是启动用例的软件组件的示例，即调度程序
没错，就是UML使用的约定。
无法启动用例。用例描述的交互可以由某人发起。想象一下这样的情况，由于性能原因，系统响应用户与系统交互以达到用户目标的一些操作被推迟并安排在后面的处理中。这是一个设计/实施决策。它不会改变功能要求（在用例中）。现在TIME变成了演员？我宁愿保持用例不变，但我会考虑将 TIME 添加为“次要”角色。所以 TIME 帮助主要参与者达到用户目标。 TIME 对系统没有用户目标（用例）。

【解决方案4】：

我同意让 Time 作为演员。如果系统中的用例在某个时刻被触发，我会将 Time 建模为参与者并将其与该用例相关联。在这些场景中，时间可以被认为是一个外部实体（因此也是一个参与者）

【讨论】：

【解决方案5】：

是的，TIME 可以在用例中扮演角色。但不应该是主要参与者。因为它确实违反了用例中参与者的定义。

Primary actor is someone/thing which has a goal for interacting with the system.

Time有什么样的目标？

Time ------> RunPayroll

谁从运行工资单中受益？也许时间演员隐藏了一个真正的演员。

Payroll Administrator (primary actor) ---> RunPayroll  --> Time (Supporting actor)

但这确实给人以工资单管理员手动调用的“运行工资单用例”的印象？毕竟我们是在开发自动化系统？

但请记住，如果我们使用工资单管理员作为主要 Actor，那么我们就可以捕获所有的系统功能，围绕工资单的运行。这包括允许工资单的功能管理员设置时间表用于运行工资单和处理差异，人工干预，和假期。 [亲爱的博士用例：时钟是演员吗]

您可以从 Dear Dr. Use Case: Is the Clock an Actor?

【讨论】：

【解决方案6】：

我也同意在这种情况下时间不是主要参与者。我想添加一些解释来支持“作为演员的时间”通常根本不是一个好主意的想法。
(1) 让我们给这个东西另一个名字和一个可行的定义。时间是可以测量的。但是，准确地定义这个概念是一个非常复杂的科学问题。因此，对于日常使用而言，描述与它的交互几乎没有意义。更适合我的角色的描述和名称是衡量时间并能够通知它的东西，例如时间服务。
(2) 我们可以在任何地方测量时间。 时间不仅在环境之外。只有当用户要求我们的时间提供者不能成为构建系统的一部分时，我们才应该描述与辅助参与者 TimeService 的交互及其接口。但大多数情况下，TimeService 将是实现/实现用例的类或组件之一，并且在 UC 图中不作为参与者。
For more details: this is a short text I wrote about it.

【讨论】：

【解决方案7】：

在my answer 到similar question 中，我说他们对应该在给定时间执行的活动进行建模的方法是创建一个名为“Scheduler”的参与者，它更像是一个占位符，没有提及技术.这个想法是必须有一些人或组件负责监控时间，然后启动特定的用例。用例根据用例的需要说“这个用例在时间 X 开始”。是的，时间是一个可以建模的因素，但教练的方式对我来说似乎有点牵强，因为时间本身并不关心什么时候会发生什么，它就是这样。他过度概括，试图将所有类型的用例融入他的建模概念。

在与讲师的假设讨论中，我会问：“时间本身——没有其他机制、人或软件——是作用于系统的实体吗？”显而易见的答案是“不”，但想法是可以有一个任意的参与者 a) 可以测量时间，并且 b) 知道某些用例对时间敏感。

我确实喜欢article in @Igor's answer，因为它确实涵盖了让 Time 成为主要演员的大部分问题。

演员通常用某种名词来表示，所以也许折衷的办法是使用时钟作为演员，而不是大写的-T“时间”。像其他海报一样，我同意您不太可能说服老师，但值得讨论，因为这有助于了解他对建模的总体看法。

虽然我意识到对于产生这个问题的课程来说为时已晚，但我发布这个答案是为了帮助其他在用例中遇到建模时间问题的人，或者遇到一位教授对如何使用 UML 用例进行建模有自己的看法。

【讨论】：

【解决方案8】：

时间与系统相互作用。例如。时间过去了，系统必须根据那个“动作”做一些事情。

【讨论】：

【解决方案9】：

我同意 @Novalis 时间可以是参与者但不是主要参与者，因为每个利益相关者都是参与者，时间可以对任何利益相关者的利益或损失负责，因此它可以被视为次要参与者或任何你想给的名字。

【讨论】：

【解决方案10】：

直到我更清楚地知道，我发现当演员的时间有点令人困惑，尤其是因为演员行动，而时间是由于事情在变化：地球绕着太阳转，水晶在跳动。我们使用 change-to-time 转换器 工具（即时钟！）将这些变化的聚合副作用转换为我们称之为 人造尺度：时间。

【讨论】：

将演员命名为“调度员”会有什么不同吗？