好的,对于一个关于真假的问题:
a) 系统的参与者仅由人类或其他软件组件代表。
我回答TRUE,但老师将其标记为错误,不是因为他认为我漏掉了硬件组件(我想我可能部分地认同),而是因为他说:
“时间也是一个参与者。”
用例图如何将时间视为参与者?
请参考任何将时间视为参与者的参考文献。我没有找到任何一本书,而且实话说我认为这毫无意义。时间本身不会行动,它要么是系统,要么是按计划工作的人。
这里是UML 2用例图编制指南...
http://www.agilemodeling.com/style/useCaseDiagram.htm
我猜你应该询问你的老师,让他解释时间如何成为一个角色,并在用例图中表示出来,因为毕竟他们将评分你的下一个作业,所以他们的解释比其他人更重要:-)
哦,维基百科说时间是一个角色,所以这一定是真的:
演员可以被视为启动用例的某人或某物。定时任务由“时间”启动。从这个意义上说,“时间”是一个演员,因为它启动了用例。
例如:
必须每6小时生成一次报告。因此,“6小时”这段时间必须是一个演员,因为生成任务将每隔6小时启动一次。
是的,时间可以在用例中扮演角色。但不应该是主要角色。因为这实际上违反了用例中角色的定义。
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漂亮的文章。
我同意将时间作为一个角色。如果系统中的用例在某个特定的时间点被触发,我会将时间建模为一个角色,并将其与该用例相关联。在这些情况下,时间可以被视为外部实体(因此是一个角色)。
在我更了解之前,我觉得作为演员的时间有点令人困惑,特别是因为演员表演,而时间是由于事物的变化而产生的:地球绕着太阳转,晶体脉动。我们使用变换到时间转换器工具(即时钟!)来转换这些变化的聚合副作用成为我们所称的人造尺度:时间。
我同意@Novalis的观点,时间可以是一个行动者,但不是主要的行动者,因为每个利益相关者都是行动者,时间可以对任何利益相关者的利益或损失负责,因此它可以被视为次要的行动者或者你想给它的任何名称。