好吧，关于一个真正的错误问题：
a) 系统的参与者仅由人类或其他软件组件代表。
我说是，老师把它标记为错误，不是因为他认为我错过了硬件组件（我想我会部分承认），而是因为，用他的话来说：
“TIME也是演员。”
用例图如何将 TIME 视为参与者？
请参阅任何将时间视为演员的参考书目。我没有找到任何东西，说实话，我认为这没有任何意义。时间不会自己行动，它要么是一个系统，要么是一个按计划工作的人。
问问题
19241 次
10 回答
9
UML 2 用例图表指南在这里...
http://www.agilemodeling.com/style/useCaseDiagram.htm
...展示如何表示时间。
我怀疑你应该请你的老师解释时间是一个演员，以及它是如何在用例图上表示的，因为毕竟他们会标记你的下一个作业，所以他们的解释胜过所有其他人:-)
哦，维基百科说时间是一个演员，所以它一定是真的：
于 2009-05-12T23:22:34.700 回答
5
我不同意时间是演员。您真正需要考虑的是谁将从行动中受益，并在功能描述中设置时间表的创建和执行。看看这篇文章：
于 2011-03-22T21:49:47.923 回答
3
参与者可以被视为启动用例的某人或某事。计划任务按“时间”启动。从这个意义上说，“时间”是一个参与者，因为它启动了一个用例。
例子：
必须每 6 小时生成一份报告。因此，时间“6 小时”必须是演员，因为生成任务将每 6 小时启动一次。
于 2009-05-12T23:17:54.507 回答
1
我同意让时间成为演员。如果系统中的用例在某个时刻被触发，我会将 Time 建模为参与者并将其与该用例相关联。在这些场景中，时间可以被认为是一个外部实体（因此也是一个参与者）
于 2009-05-13T10:22:24.547 回答
1
是的 TIME 可以成为用例中的参与者。但不应该是主要参与者。因为它确实违反了用例中参与者的定义。
Primary actor is someone/thing which has a goal for interacting with the system.
时代有什么样的目标？
Time ------> RunPayroll
谁从运行工资单中受益？也许时间演员隐藏了一个真正的演员。
Payroll Administrator (primary actor) ---> RunPayroll --> Time (Supporting actor)
但这确实给人以工资管理员手动调用的运行工资用例的印象？毕竟我们正在开发一个自动化系统？
但请记住，如果我们将工资单管理员用作主要参与者，那么我们可以捕获围绕工资单运行的所有系统功能。这包括允许工资单管理员设置运行工资单的时间表以及处理差异、人工干预和假期的功能。[亲爱的博士用例：时钟是演员吗]
你可以从Dear Dr. Use Case: Is the Clock an Actor那里得到那篇精彩的 Ibm 文章 。
于 2011-06-10T13:37:23.030 回答
1
我也同意时间不是这种情况下的主要参与者。我想添加一些解释来支持“作为演员的时间”通常根本不是一个好主意的想法。
(1)让我们给这个东西另一个名字和一个可行的定义。时间是可以测量的。但是，准确地定义这个概念是一个非常复杂的科学问题。因此，对于日常使用而言，描述与它的交互几乎没有意义。更适合我的角色的描述和名称是衡量时间并能够通知它的东西，例如 TimeService。
(2) 我们可以在任何地方测量时间。时间不仅在环境之外. 只有当用户要求我们的时间提供者不能成为构建系统的一部分时，我们才应该描述与辅助参与者 TimeService 的交互及其接口。但大多数时间服务将是实现/实现用例的类或组件之一，并且在 UC 图中不作为参与者。
有关更多详细信息：这是我写的关于它的简短文本。
于 2014-06-04T19:01:57.683 回答
1
在我对类似问题的回答中，我说他们对应该在给定时间执行的活动进行建模的方法是创建一个名为“Scheduler”的参与者，它更像是一个占位符并且没有提及技术。这个想法是必须有一些人或组件负责监控时间，然后启动特定的用例。用例根据用例的需要说“这个用例在时间 X 开始”。是的，时间是一个可以建模的因素，但教练的方式对我来说似乎有点牵强，因为时间本身并不关心什么时候会发生什么，它就是这样。他过度概括，试图将所有类型的用例融入他的建模概念。
在与讲师的假设讨论中，我会问：“时间本身——没有其他机制、人或软件——是作用于系统的实体吗？” 显而易见的答案是“不”，但想法是可以有一个任意的参与者 a) 可以测量时间，并且 b) 知道某些用例对时间敏感。
我确实喜欢@Igor 回答中的文章，因为它确实涵盖了让 Time 成为主要演员的大部分问题。
演员通常由某种名词表示，所以也许折衷方案是使用时钟作为演员，而不是大写的-T“时间”。像其他海报一样，我同意您不太可能说服老师，但值得讨论，因为这有助于了解他对建模的总体看法。
虽然我意识到对于产生这个问题的课程来说为时已晚，但我发布这个答案是为了帮助那些在用例中遇到建模时间问题的其他人，或者遇到一位有自己看法的教授如何使用 UML 用例建模。
于 2016-01-26T15:05:00.637 回答
0
时间与系统相互作用。例如，时间过去了，系统必须根据那个“动作”做一些事情。
于 2009-05-12T23:20:08.323 回答
0
我同意@Novalis时间可以是参与者但不是主要参与者，因为每个利益相关者都是参与者，时间可以对任何利益相关者的利益或损失负责，因此它可以被视为次要参与者或您想要给出的任何名称。
于 2012-10-16T14:15:47.560 回答
0
直到我更清楚地知道，我发现当演员的时间有点令人困惑，特别是因为演员在表演，而时间是由于事物在变化的事实：地球围绕太阳旋转，水晶在脉动。我们使用更改时间转换器工具（即时钟！）将这些更改的汇总副作用转换为我们称之为的人造尺度：时间。
于 2013-10-30T22:18:02.303 回答