在建模中，关于参与者准确的来说就是寻找抽象角度的开始。

参与者(actor)在建模的过程中是处于核心地位的。UML官方文档对于参与者的定义为：actor 是在系统之外与系统交互的某人或某物。如下图所示：

上图说明系统被一个边界包裹着。系统之外的定义说明在参与者与系统之间有一个明确的边界。参与者只能存在于边界之外，边界内的所有人或事物都不是参与者。

在官方文档中对参与者还有另一种叫法：“主角”，参与者可以是非人。

那么，在系统建模中，我们如何发现参与者？其实，参与者其中重要的一个来源是涉众，从涉众中找出那些直接对系统发出动作，或者直接从系统中接收反馈信息的涉众。

什么是业务主角？

业务主角是参与者的一个版型（或是说类型），特别用于定义业务的参与者，在需求阶段使用，业务主角是与业务系统交互的人或事物，它们用来确定业务范围，因为业务主角是参与者的一个版型，所以业务主角必须遵守参与者的所有定义。

业务主角的特殊性在于：它针对的是业务人员，而非计算机用户，所在查找业务主角的时候必须抛开计算机。没有计算机系统这些业务人员也客观存在，在引入计算机系统前他们的业务也一直跑得很顺畅。

业务主角是非常重要的，建立业务模型，查找业务用例都必须使用业务主角而不是普通的参与者。

什么是业务工人？

建模者经常会被一个问题困扰，有些人员参与了业务，但是身份很尴尬，它是被动参与业务的，不好说它有什么具体的目的，但是它又的确在业务中做了很多事情。那到底要不要给这种人建模呢?

参与者这个叫法不可避免的带来一些问题，会让人觉得，凡是参与了业务的或在业务流程中做了事情的，都是参与者。这是一种误解，如何换一种叫法，叫“主角”，应当就会避免这种歧义。

那么如何区分是参与者还是业务工人呢？最直接的办法是判断在边界之内还是边界之外，如何边界尚不清楚，可以通过以下三个方法判断：

1：它是主动向系统发出动作的吗？

2：它有完整的业务目标吗？

3：系统是为它服务的吗？

这三个答案是否定的，那他一定是业务工人。