|
Scott W. Ambler
总裁，Ronin International
2000 年 7 月 7 日
根据 Scott Ambler 最近一篇关于开发基本用例模型的技巧文章，他在用例模型中就标识参与者进行了剖析。本文改编自 The Object Primer 2nd Edition 的第 3 章。
参与者可以表示与您系统接口的任何事物和任何人。这可以包括人（不仅仅是最终用户）、外部系统和其它组织。参与者总在正在建模的系统的外部。它们从来不是系统的一部分。为了帮助发现系统中的参与者，您可以问自己以下问题：
- 谁是系统的主要客户？
- 谁从该系统获得信息？
- 谁向系统提供信息？
- 谁安装系统？
- 谁操作系统？
- 谁关闭系统？
- 其它系统与该系统交互什么？
- 在预设的时间，有事情自动发生吗？
- 谁将提供、使用或从系统删除信息？
- 系统从哪里获得信息？
参与者表示角色
当进行用例建模时，您的目的是使用参与者来对角色建模，而不是对物理的、现实世界的人、组织或系统本身。例如，在用例“参加研习班”中涉及到 Student 和 Registrar 参与者。是的，学生很可能是人。然而，考虑到 Registrar。现在，在大多数大学中，有一些人担当注册员的角色。但是，真的象这样吗？考虑一下注册员所做的。他们：
- 协调学校和学生之间的文书工作
- 验证学生提交的信息
- 为学生提供关于参加研习班的意见
前两项任务（协调文书工作和验证信息）很明显可以自动进行。第 3 项任务（为学生提供意见），极有可能可以使用人工智能（AI）专家系统来自动进行。这一点表明 Registrar 参与者可以由人或系统来实现。它甚至可以外包给专门从事注册活动方面的其它组织。如果您假定 Registrar 参与者表示人，那么您已经限制了系统设计可能发展的契机，这违背了基本建模的本性。相反，您希望描述作为一个注册员意味什么样的角色，而将设计问题留给您的设计活动。同样，这允许一个人担当多个角色的可能性。例如，如果学校的注册员也可以参加课程，他或她同时可以担当学生 和注册员。从用例的观点来看，这非常有效。
参与者不进行职位建模
理解参与者不进行职位建模，这一点也是很重要的。他们，例如，在大学中，系主任、终身教授、副教授和助教都能够输入分数和调整分数（可能大多数情况下就是如此）。虽然，的确是这些人做这些事情，但您不想在用例模型中描述这些。相反，您想问自己，在这个用例中，这些类型的人担当什么角色。在该示例中，这些用户看起来是担当年级管理员的角色。这种方法简化了序列图，并且没有使您考虑组织内的当前职位的层次结构。明年，当“终身教授”和“助教”的职位合并为“教师”时，您无须重新修改用例图。
编写参与者文档
为了描述一个参与者，您可能想给它一个名称来精确地反映其在模型中的角色。参与者名称通常是单数名词，譬如， 年级管理员、客户以及支付出纳员。您还应该提供一个参与者的描述，通常几个句子就可以做到，并且，如果需要，可以提供参与者的现实世界示例。图 1 显示了您可能如何描述年级管理员参与者。请注意，该描述是如何引用相关商业规则。（我总是在它们自己的构件中编写商业规则文档，这样我可以在用例、参与者定义或从任何其它相应开发构件中引用它们。）请注意，该示例是用来清楚地说明谁可能是年级管理员。
参考资料
如果想要了解用例模型中有关开发和标识参与者的详细信息，请参阅：
| 
