标识用例模型中的参与者

Comments

参与者可以表示与您系统接口的任何事物和任何人。这可以包括人(不仅仅是最终用户)、外部系统和其它组织。参与者总在正在建模的系统的外部。它们从来不是系统的一部分。为了帮助发现系统中的参与者,您可以问自己以下问题:

  • 谁是系统的主要客户?
  • 谁从该系统获得信息?
  • 谁向系统提供信息?
  • 谁安装系统?
  • 谁操作系统?
  • 谁关闭系统?
  • 其它系统与该系统交互什么?
  • 在预设的时间,有事情自动发生吗?
  • 谁将提供、使用或从系统删除信息?
  • 系统从哪里获得信息?

参与者表示角色
当进行用例建模时,您的目的是使用参与者来对角色建模,而不是对物理的、现实世界的人、组织或系统本身。例如,在用例“参加研习班”中涉及到 StudentRegistrar参与者。是的,学生很可能是人。然而,考虑到 Registrar。现在,在大多数大学中,有一些人担当注册员的角色。但是,真的象这样吗?考虑一下注册员所做的。他们:

  • 协调学校和学生之间的文书工作
  • 验证学生提交的信息
  • 为学生提供关于参加研习班的意见

前两项任务(协调文书工作和验证信息)很明显可以自动进行。第 3项任务(为学生提供意见),极有可能可以使用人工智能(AI)专家系统来自动进行。这一点表明 Registrar参与者可以由人或系统来实现。它甚至可以外包给专门从事注册活动方面的其它组织。如果您假定 Registrar参与者表示人,那么您已经限制了系统设计可能发展的契机,这违背了基本建模的本性。相反,您希望描述作为一个注册员意味什么样的角色,而将设计问题留给您的设计活动。同样,这允许一个人担当多个角色的可能性。例如,如果学校的注册员也可以参加课程,他或她同时可以担当学生 注册员。从用例的观点来看,这非常有效。

参与者不进行职位建模
理解参与者不进行职位建模,这一点也是很重要的。他们,例如,在大学中,系主任、终身教授、副教授和助教都能够输入分数和调整分数(可能大多数情况下就是如此)。虽然,的确是这些人做这些事情,但您不想在用例模型中描述这些。相反,您想问自己,在这个用例中,这些类型的人担当什么角色。在该示例中,这些用户看起来是担当年级管理员的角色。这种方法简化了序列图,并且没有使您考虑组织内的当前职位的层次结构。明年,当“终身教授”和“助教”的职位合并为“教师”时,您无须重新修改用例图。

编写参与者文档
为了描述一个参与者,您可能想给它一个名称来精确地反映其在模型中的角色。参与者名称通常是单数名词,譬如, 年级管理员客户以及 支付出纳员。您还应该提供一个参与者的描述,通常几个句子就可以做到,并且,如果需要,可以提供参与者的现实世界示例。图1显示了您可能如何描述 年级管理员参与者。请注意,该描述是如何引用相关商业规则。(我总是在它们自己的构件中编写商业规则文档,这样我可以在用例、参与者定义或从任何其它相应开发构件中引用它们。)请注意,该示例是用来清楚地说明谁可能是年级管理员。

图 1. 年级管理员参与者的描述

名称:年级管理员

描述:年级管理员将输入、更新和最终决定系统中学生的作业、测验和考试的分数。请参阅可应用的商业规则BR123 和 BR124。

示例:

  • 主任
  • 终身教授
  • 副教授
  • 助教,由研习班教师授权访问



相关主题


评论

添加或订阅评论,请先登录注册

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=Rational
ArticleID=53556
ArticleTitle=标识用例模型中的参与者
publish-date=07072000