时间在用例中是一个参与者吗?

12

好的,对于一个关于真假的问题:

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

我回答TRUE,但老师将其标记为错误,不是因为他认为我漏掉了硬件组件(我想我可能部分地认同),而是因为他说:

“时间也是一个参与者。”

用例图如何将时间视为参与者?

请参考任何将时间视为参与者的参考文献。我没有找到任何一本书,而且实话说我认为这毫无意义。时间本身不会行动,它要么是系统,要么是按计划工作的人。


4
请务必画上一张带有飘逸白色胡须和沙漏的图案... - Shog9
是的,我想这就是这个人想要的。 - andandandand
10个回答

9

你的链接说:Actor 是一个在与你的系统进行一次或多次交互中扮演角色的人员、组织或外部系统(通常在 UML Use Case diagrams 中被画成小人形)。 - andandandand
然后,使用名称“Time”将或“系统”标记为按计划工作的人,而不是自行运作的神秘实体。 - andandandand
时间是一个“外部系统”。请查看定义演员下面的第8点。它说明了时间被添加为演员。 - Martin Peck
是的,我已经参考过它了,但我觉得它很愚蠢,因为它不是自己行动的东西,而是由系统本身安排的条件,真正“行动”的是系统。无论如何,感谢你提供这个晦涩的、毫无意义的参考。你的答案已被标记为接受。 - andandandand
我想我的主要答案是“让你的老师说服你”,然后“理解你的老师的想法,即使你不同意,因为知道他们的信仰可以让你得高分”。我完全理解你的观点 - 这只是我对UML的许多问题之一。 - Martin Peck
+1:很好的答案,我整晚都在寻找它。你救了我的一天 :) - Luiggi Mendoza

6
我不同意时间是一个行动者。你必须真正考虑的是谁将从行动中受益,并在功能描述中设置时间表的创建和执行。请看这篇文章:用例博士

1
这是一篇很棒的文章,感谢提供链接。我告诉我的学生之一就是,它部分取决于你想要传达什么信息。用例建模旨在以清晰、一致的方式向多个受众传达有关系统设计的信息。如果它所建模的实现了这一目标(无论我们选择是否将时间作为参与者),那么我们就成功了。因此,尽管我在整篇文章中都点头表示认同,因为使用时间作为参与者可以传达系统中的重要触发器,我建议使用它。 - alttag

3

演员可以被视为启动用例的某人或某物。定时任务由“时间”启动。从这个意义上说,“时间”是一个演员,因为它启动了用例。

例如:

必须每6小时生成一次报告。因此,“6小时”这段时间必须是一个演员,因为生成任务将每隔6小时启动一次。


1
请举一个例子,其中演员“时间”与系统进行交互。我相信时间本身不会行动,它要么是一个使用计时器的系统,要么是按照时间表行动的人。 - andandandand
1
在阅读这个问题之前,你是否曾考虑过时间作为一个角色?我一直认为你提供的那个案例是软件组件开始使用用例的一个例子,即调度程序。 - Simonw
是的,这是UML使用的约定。 - Fabio Vinicius Binder
一个用例无法启动。用例描述的交互可以由某人发起。想象一下这样的情况,出于性能原因,系统响应用户与系统交互以达到用户目标的部分被推迟并安排在以后处理。这是一个设计/实现决策。它不会改变功能要求(在用例中)。现在时间成为了演员?我宁愿保持用例不变,但我会考虑将时间添加为“次要”演员。所以时间帮助主要演员达到用户目标。时间没有针对系统的用户目标(用例)。 - onknows

1

是的,时间可以在用例中扮演角色。但不应该是主要角色。因为这实际上违反了用例中角色的定义。

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

时间有什么样的目标?

Time ------> RunPayroll

谁从运行工资单中受益?也许时间演员掩盖了真正的演员。

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

但这是否给人留下了手动调用Payroll管理员的印象呢?毕竟我们正在开发自动化系统?

但请记住,如果我们将Payroll管理员作为主要参与者,那么我们可以捕获所有围绕工资单运行的系统功能。这包括允许Payroll管理员设置工资单运行的时间表以及处理差异、手动干预和假期等功能。 [亲爱的Use Case博士:时钟是参与者吗]

您可以从Dear Dr. Use Case: Is the Clock an Actor?中获取IBM漂亮的文章。


1
在我对类似问题回答中,我说要建立一个名为“Scheduler”的演员来模拟应在特定时间执行的活动。这更像是一个占位符,不涉及技术。这个想法是必须有某个人或组件负责监控时间并启动特定的用例。根据用例的需求,该用例会说“此用例从X时间开始”。是的,时间是可以被建模的因素,但是教练所采取的方式似乎对我来说有些牵强,因为时间本身并不关心什么时候发生什么事情,它只是存在。他试图过于概括,以适应他对建模概念的所有类型用例的理解。
在与教练的讨论中,我会问:“时间本身-没有其他机制、人员或软件-是对系统产生影响的实体吗?”显然答案是否定的,但是这个想法是可以有一个任意的演员,a) 可以测量时间,b) 知道某些用例对时间敏感。
我很喜欢 @Igor答案中的文章,因为它确实涵盖了将时间作为主要参与者的问题。通常情况下,参与者由某种名词表示,因此也许可以妥协,使用时钟作为参与者,而不是大写字母'Time'。像其他帖子一样,我同意你不太可能说服老师,但进行讨论是值得的,因为它有助于理解他对建模的看法。虽然我意识到这个问题所在的课程已经晚了,但我发表这个答案,希望能帮助那些遇到用例建模时间问题或遇到教授有自己关于如何使用UML用例建模的观点的人们。

1
我也同意,时间在这种情境中并不是一个主要的参与者。我希望补充一些解释来支持这个想法:“将时间作为一个参与者”往往并不是一个好主意。
(1)让我们给这个事物另一个名称和可行的定义。时间可以被测量。但是确切地定义这个概念是一个非常复杂的科学问题。因此,对于日常使用来说,描述与之交互的意义不大。适合我的角色的描述和名称是一些能够测量时间并能够通知相关信息的东西,例如TimeService。
(2) 我们可以在任何地方测量时间。时间不仅存在于环境外部。只有当用户要求我们的时间提供者不能成为构建系统的一部分时,我们才应该描述与第二参与者TimeService的交互以及与之对应的接口。但是,在用例图中,TimeService通常会作为实现用例的类或组件之一而不存在作为参与者。
更多细节请查看我写的这篇简短文章。

1

我同意将时间作为一个角色。如果系统中的用例在某个特定的时间点被触发,我会将时间建模为一个角色,并将其与该用例相关联。在这些情况下,时间可以被视为外部实体(因此是一个角色)。


0
时间与系统进行交互。例如,时间流逝,系统必须根据那个“动作”做某些事情。

0

在我更了解之前,我觉得作为演员的时间有点令人困惑,特别是因为演员表演,而时间是由于事物的变化而产生的:地球绕着太阳转,晶体脉动。我们使用变换到时间转换器工具(即时钟!)来转换这些变化的聚合副作用成为我们所称的人造尺度:时间。


将演员命名为“调度器”会有什么不同吗? - Kelly S. French

0

我同意@Novalis的观点,时间可以是一个行动者,但不是主要的行动者,因为每个利益相关者都是行动者,时间可以对任何利益相关者的利益或损失负责,因此它可以被视为次要的行动者或者你想给它的任何名称。


网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接