参与者(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)是参与者的职责。角色是一个抽象概念,从众多参与者的职责中抽象出来相同的那一部分,将其命名为角色。一个角色代表了系统中的一类职责。
参与者的核心地位
参与者是涉众的代表,它代表涉众对系统的利益要求,并向系统提出建设要求;参与者通过代理给其他用户或者将自身实例化成为用户来使用系统;参与者的职责可以用角色来归纳,用户被指定扮演哪个或哪些角色因此来获得参与者的职责。
同时,系统是以参与者的观点来决定的。参与者对系统的要求对系统的表述完全决定了系统的功能。