UML核心元素之参与者

 

一、概述：在系统之外与系统交互的某人或某事物。

（1）如何找到参与者，确定系统边界。

在一个业务中可以问自己两个问题：

A.谁对系统有着明确的目标和和要求并且主动发出动作。

B.系统是为谁服务。

参与者还有另一种叫法：主角。参与者容易让人误解为只要参与了业务的，都是参与者，而主角很明确的指出，只有主动启动这个业务的才是参与者。

（2）参与者可以非人

例如：每天自动统计网页访问量，生成统计表，并发送至管理员信箱。

这个需求是每天自动统计访问量，这个需求的参与者或者说主角是一个计时器，它每天在某一个固定的时刻启动这个需求。

二、发现参与者。

参与者的一个重要来源是涉众。参与者一定是直接并且主动地向系统发出动作并获得反馈的，否则不是参与者。

举个例子：机票预定系统。

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

情况二：加入机票购买者通过呼叫中心，有人工坐席订票系统购买机票，那么人工坐席才是真正的参与者，而机票购买者实际上是互交中心的参与者，如下图。

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

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

 

三、业务主角。

    业务主角是参与者的一个版型，特别用于定义业务的参与者。业务主角是客户实际业务里的参与者，没有计算机系统，没有抽象的计算机角色。业务角色必须在实际业务里能找到对应的岗位或人员。在建立业务模型、查找业务用例都必须使用业务主角，而不是普通的参与者。在做寻找业务主角的时候要抛开计算机，就算没有计算机系统这些业务人员也存在。

四、业务工人。

    处于系统边界内，却参与了业务执行过程。就想上面航空订票的第四种情况，人工坐席就是一个业务工人。

五、参与者与涉众的关系。

     涉众：与要建设的这个系统有利益相关的一切人和事，涉众的利益要求会影响的建设。参与者是涉众代表。

六、参与者与用户的关系。

用户是指系统的使用者。用户是参与者的代表。

七、参与者与角色的关系。

角色是参与者的职责。角色从重挫参与者的职责中抽象出相同的那一部分。

八、参与者的核心地位。

A.参与者是涉众的代表，代表涉众对系统的利益要求，并向系统提出建设要求。

B.参与者通过代理给其他用户或将自身实例化成用户来是使用系统

C.参与者的职责可以用角色来归纳，用户被制定扮演哪个或哪些角色因此来获得参与者的职责。

D.系统是以参与者的观点来决定。

（如图）

    

 

九.检查参与者是否正确。

回答一下几个问题

A.是否您已经找到所有的参与者？也就是说，是否您已经对系统环境中的所有角色进行了说明和建模？

B.每个参与者是否至少涉及到一个用例？

C.您能否列出至少两名可以作为特定参与者的人员？

D.是否有参与者担任与系统相关的相似角色。

E.是否有两个参与担任与用例相关的同一角色？如果有，应该利用参与者泛化关系来为他们的共享行为建立模型。

F.特定的参与者是否将以集中方式使用系统？

G.参与者是否有直观名称和描述性名称？