文档介绍：大象thinking in uml读书笔记[宝典]
摘自《大象——Thinking in UML》 谭云杰
一、参与者(Actor、主角)
(一) 特点:
1) 业务建模的核心。它是涉众代表，代表涉众对系统的利益要求，并向系统提出建设要
求。系统是以参与者的观点决定的，他对系统的要求，对系统的表述完全决定了系统
的功能性。
2) 参与者位于边界之外
1. 谁对系统有着明确的目标和要求，并且主动发出动作,
2. 系统是为谁服务的,
3) 业务工人(Business Worker)
4) 参与者可以非人
5) 涉众是发现参与者的重要来源
6) 涉众(Stakeholder)，又称干系人，指与建设系统有利益相关的一切人和事，但涉众不
一定是系统的参与者。参与者是涉众代表，他对系统的要求直接影响到系统的建设，
他们的要求就是系统需求的来源。参与者通过对系统提出要求来获得他所代表的涉众
的利益。由此可见，参与者也并不需要询问同一岗位所有人，而是找出可代表该岗位
的代表，与之沟通。
7) 用户和参与者，用户是指系统的使用者，系统的操作员，他是参与者的代表。
8) 角色是参与者的职责，是一个抽象的概念，从众多参与者的职责中抽象出相同的一部
分，将其定义一个角色。一般适用于概念阶段的模型，以表达业务的逻辑理解。一个
用户可以代理多个参与者，一个用户可以拥有多份职责，即可被指定多个角色。
(二) 问题
1) 谁负责提供、使用或删除信息,
2) 谁将使用此功能,
3) 谁对某个特定功能感兴趣,
4) 在组织中的什么地方使用系统,
5) 谁负责支持和维护系统,
6) 系统有哪些外部资源,
7) 其他还有哪些系统将需要与该系统进行交互,
(三) 版型
1) 业务主角(Business Actor)
定义业务的参与者，在需求阶段使用，用来确定业务范围。非常重要，建立业务模型、查找业务用例都须用业务主角。
业务范围和系统范围不同，业务范围指项目涉及的所有客户业务，有些业务内容没有系统参与也一样客观存在。
系统范围仅指软件要实现的业务功能。有些系统功能不在业务范围，如操作日志。
业务主角针对业务人员，而非计算机用户，也不应过早引入计算机系统的概念，以免混淆，导致误导用户。
业务主角必须在实际业务里能找到对应的岗位或人员。
常用问题:
业务主角的名称是否是客户的业务术语,
业务主角的职责是否在客户的岗位手册里有对应的定义,
业务主角的业务用例是否都是客户的业务术语,
客户是否对业务主角能顺利理解,
2) 业务工人(Business Worker)
BW被动参与业务。
BW处于系统边界内。
不需要为BW建立业务模型，只在主角的业务模型中出现。
虽然不参与业务建模，但他们仍然不可或缺，如领域模型、用例模型。缺少他们业务模型就不完整，甚至不能运行。
判断他是在边界之内和边界之外，常用问题:
他是主动向系统发出动作的吗,
他有完整的业务目标吗,
系统是为他服务的吗,
(四) 检查点(RUP官方文档，非常有助于检查发现的参与者是否正确) 1) 是否您已找到所有的参与者,也就是说，是否您已经对系统环境中的所有