UML 核心元素之 参与者

参与者（actor）在建模过程中是处于核心地位的。UML官方文档对actor的定义为：参与者（actor）是在系统之外与系统交互的某人或某事物。“系统之外”的定义说明在参与者和系统之间有一个明显的边界，参与者（actor）只可能存在于边界之外，边界之内的所有人或者事物都不是参与者。

参与者（actor）还有另外一种叫法：主角。主角这一叫法则很明确的说明了只有主动启动了业务的，才是参与者。 

发现参与者

首先了解一个概念：涉众（stakeholder），也称为干系人。涉众是与要建设的这个系统有利益相关的一切人和事，涉众的利益要求会影响系统的建设。参与者的一个重要来源是涉众，从涉众中找出那些直接对系统发出动作，或者直接从系统中接受反馈的涉众。参与者是涉众代表，参与者对系统的要求直接影响系统的建设，他们的要求就是系统需求的来源，参与者通过对系统提出要求来获得他所代表的涉众的利益。参与者的另一个来源是客户的岗位设置。

在查找参与者的过程中，尝试寻找一下问题的答案有助于你确定参与者：

1、谁负责提供、使用或者删除信息？

2、谁将使用此功能？

3、谁对某个特定功能感兴趣？

4、在组织中的什么地方使用系统？

5、谁负责支持和维护系统？

6、系统有那些外部资源？

7、其他还有那些系统将需要与该系统进行交互？

参与者一定是直接并且主动向系统发出动作并获得反馈的，否则就不是参与者。

 

业务主角（business actor）

       业务主角是参与者的一个版型，特别用于定义业务的参与者，在需求阶段使用。业务主角是与业务系统有着交互的人和事物，他们用来确定业务范围。业务主角的特殊性在于，它针对的是业务人员而非计算机用户。要建设一个符合客户需要的计算机系统，首要条件是完全彻底地搞清楚客户的业务，而不是预想已经有了一个计算机系统，再让客户来假设需要计算机系统帮助他们完成什么。

       所以在初始需求阶段，请务必使用业务主角，时时牢记业务主角是客户实际业务里的参与者，没有计算机系统，没有抽象的计算机角色。业务主角必须在实际的业务里能找到对应的岗位或人员。

业务工人（business worker）

   在建模过程中，有些人员虽然参与了业务，但是身份很尴尬，因为他们是被动参与业务的，不好确定其目的是什么，但是又确确实实在业务过程中做了事情。出现这种困扰的原因是打破了对边界的定义，这样的人员实际上应该是边界内的人员，被称为业务工人（business worker）。

    如何区分参与者和业务工人呢？最直接的方法是判断他是出现在系统边界之内还是在边界之外。如果边界不清楚，可以通过以下三个问题来澄清。

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

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

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

如果以上三个问题的答案都是否定的，那么他一定是业务工人。

 

参与者与用户和角色的关系

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

       角色（role）是参与者的职责。角色是一个抽象概念，从众多参与者的职责中抽象出来相同的那一部分，将其命名为角色。一个角色代表了系统中的一类职责。 

参与者的核心地位

       参与者是涉众的代表，它代表涉众对系统的利益要求，并向系统提出建设要求；参与者通过代理给其他用户或者将自身实例化成为用户来使用系统；参与者的职责可以用角色来归纳，用户被指定扮演哪个或哪些角色因此来获得参与者的职责。

       同时，系统是以参与者的观点来决定的。参与者对系统的要求对系统的表述完全决定了系统的功能。