TIME是用例中的演员吗？

Question

好吧，关于一个真正的错误问题：

a）系统的参与者仅由人或其他软件组件代表。

我说真的，并且老师将其标记为错误，并不是因为他认为我错过了硬件组件（我想我会部分承认），而是因为他的话：

“时间也是演员。”

用例图如何将TIME视为演员？

请参阅任何将时间视为演员的参考书目。我没有发现任何事实，我认为这没有任何意义。时间不是单独行动，而是一个系统或按时间表工作的人。

Answer 1

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

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

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

我怀疑你应该让你的老师解释时间是一个演员以及它如何在用例图上表示，因为毕竟他们将标记你的下一个任务，所以他们的解释胜过其他所有人： ）

哦，维基百科说Time是演员，所以一定是真的：

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

Answer 2

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

Dr. Use Case

Answer 3

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

示例：

必须每6小时生成一份报告。因此，时间“6小时”必须是演员，因为生成任务将每6小时启动一次。

Answer 4

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

Answer 5

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

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

时间有什么样的目标？

Time ------> RunPayroll

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

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

但这确实会让工资单管理员手动调用运行工资单用例？毕竟我们正在开发自动化系统？

  

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

你可以从中获得很好的Ibm文章 Dear Dr. Use Case: Is the Clock an Actor?

Answer 6

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

Answer 7

在my answer到similar question，我说他们建模应该在给定时间执行的活动的方法是创建一个名为'Scheduler'的actor，它更像是一个占位符，并且没提一项技术。这个想法是必须有一些人或组件，其职责是监控时间，然后启动特定的用例。用例说“这个用例从时间X开始”，具体取决于用例的需要。是的时间是一个可以建模的因素，但是教师的方式对我来说似乎是一个延伸，因为时间本身并不关心当它发生时会发生什么。他过度概括，试图将所有类型的用例都纳入他的建模概念中。

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

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

演员通常用某种名词来表示，所以也许妥协是使用时钟作为演员而不是资本-T'时间'。像其他海报一样，我同意你不太可能说服老师，但是值得讨论，因为它有助于理解他对一般建模的看法。

虽然我发现生成这个问题的课程为时已晚，但是我发布这个答案是为了帮助那些在用例中遇到建模时间问题的人，或者遇到一个有自己的用例的教授。关于如何使用UML用例建模的看法。

Answer 8

时间与系统交互。例如。时间过去了，系统必须根据“行动”做点什么。

Answer 9

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

Answer 10

直到我知道得更清楚我觉得时间成为一个有点令人困惑的演员，特别是因为演员行为，而时间是由于事情发生了变化：地球围绕太阳旋转，晶体脉动。我们使用更改时间转换器工具（即时钟！）将这些更改的聚合副作用转换为我们称之为<时间的人造规模。