UML--核心元素之参与者Actor

参与者（actor）：在系统之外与系统交互的某人或某事物。例如，管理员，用户等等。

参与者位于边界之外，边界之内的都不叫参与者。用一个词来形容更准确，主角。也就是只有主动启动了这个业务的人，才是参与者。

第二点要注意的是，参与者可以非人。参与者可以是另一个计算机系统、一个计时器、一个传感器等。任何一个功能性需求，都有参与者启动。

我们通过机票预订系统来分析一些情况。

情况一：机票购买者通过登录网站购买机票，那么机票购买者就是参与者。

情况二：假如机票购买者通过呼叫中心，由人工座席操作订票系统购买机票，那么人工座席才是真正的参与者，而机票购买者是呼叫中心的参与者。

情况三：如果机票购买者通过呼叫中心的自动语音预定机票而不是通过人工座席，那么呼叫中心就成为机票预定系统的一个参与者。

情况四：如果扩大系统边界，让呼叫中心成为机票预定系统的一个子系统，并且假设机票购买者可以自主选择是通过人工座席、自动语音还是登录网站预定机票，那么机票购买者是参与者，而人工座席则变成业务工人。

业务主角（business actor）：业务主角是参与者的一个版型。业务主角，针对的是业务人员而非计算机用户。在没有计算机系统，这些业务人员 也客观存在，在引入计算机系统之前他们的业务也一直跑得很顺畅。

在建设一个符合客户需要的计算机系统之前，首要条件是很好地搞清楚客户的业务。

在初始需求阶段，务必使用业务主角，业务主角是客户实际业务里的参与者，没有计算机系统，没有抽象的计算机角色。

业务主角，必须在实际业务里能找到对应的岗位或人员。

业务工人（business worker）：有些人员参与了业务，但是身份很尴尬，他是被动参与业务的。这些在系统边界内的人员，被称为业务工人。

通过三个问题，来分析是否是业务工人。

一、他是主动向系统发出动作的吗？

二、他有完整的业务目标吗？

三、系统是为他服务的吗？

如果答案都是否定的，那他一定是业务工人。

涉众（stakeholder），也称为干系人。参与者是涉众代表。例如要建立一个办公自动化系统，这儿系统将为所有办公室文员归档和查找文件带来利益。但是并不需要把所有的办公室文员都找来询问需求，一个称为“文员”的参与者可以代表这批涉众来向系统提供如何归档和如何查询的要求。

myself：突然感觉，系统的好处就是在于文档的电子化，方便查询和归档。我们目前要为聋校做的系统，也是一个电子归档化的过程。将老师平时的一些电子稿信息归档。但是前提，要有一些基础信息的管理。包括老师和学生的一些基础信息。学生的健康信息等。老师上课的信息与工资信息等等。学生的听力信息管理等等。老师考核信息管理，学生成绩管理。等多角度的文档归档与查询。说白了，就是这样。没那么神秘。

用户（user）：是指系统的使用者，通俗点说就是系统的操作员。用户是参与者的代表，或者说参与者的实例或代理。并非所有的参与者都是用户，但是一个用户可以代理多个参与者。

角色（role）：是参与者的职责。是参与者职责中抽象出相同的那一部分。一个用户可以代理多个参与者，拥有多个职责，指定为多个角色。

通过这个图，来理解参与者与各概念之间的关系。