在UML里有一个概念叫版型（stereotype）/类型/构造型。这个概念是对一个UML元素基础定义的扩展，在同一个元素基础定义的基础上赋予特别的含义。版型只是UML的一种扩展手段，本身并不涉及太多的思想和方法，而是在建模的不同阶段，为了区分视图之间的不同观点，会采用不同图示来表示。
参与者（actor）在建模过程中是出于核心地位的。actor是在系统之外与系统交互的某人或某事物。
要弄明白谁是参与者首先要弄明白系统的边界。如何确定系统之外和系统之内呢？可以通过回答以下两个问题来确定：
功能需求的用例有一个特征是：“不存在没有参与者的用例，用例不应该自动启动，也不应该主动启动另一个用例”。这说明没有人参与的需求一定有别的事物在发出启动动作，应当找到这个事物，这个事物就是一个参与者，它可能是另一个计算机系统、一个计时器、一个传感器或者一个JMS消息。
在查找参与者的过程中，可以询问一下问题，帮助确定参与者：
参与者一定是直接并且主动地向系统发出动作并获得反馈的，否则就不是参与者。
业务主角（business actor）是参与者的一个版型，特别用于定义业务的参与者，在需求阶段使用。业务主角是与业务系统有着交互的人和事物，他们用来确定业务范围。业务主角是参与者的一个版型，所以业务主角必须遵守参与者的所有定义。
注：在软件项目里，业务范围和系统范围是不同的。业务范围指这个项目所涉及的所有客户业务，这些业务有没有计算机系统参与都客观存在。系统范围则是指软件将要实现的那些对应于业务功能的系统功能，从功能性需求来说系统范围是业务范围的一个子集。
在初始需求阶段，请务必使用业务主角，时时牢记业务主角是客户实际业务里的参与者，没有计算机系统，没有抽象的计算角色。业务主角必须在实际业务里能找到对应的岗位或人员。如果你对获得业务主角不是很自信，请回答以下问题：
如何区分是参与者还是业务工人？最直接的办法是判断是在边界之外还是边界之内。如果边界尚不清楚，可以通过下面的三个问题帮助澄清：
这三个问题答案如果是否定的，那一定是业务工人。以人工坐席这个例子来说，人工坐席只有在购票人打电话的情况下才会购票，因此他是被动的；订票的最终目的是拿到机票，但人工坐席只负责订，最终票并不到他的手里，因此他没有完整的业务目标；系统是为购票者服务的。非常明显，人工坐席只可能是一个业务工人。
涉众（stakeholder），也称为干系人。涉众是与要建设的这个系统有利益相关的一切人和事，涉众的利益要求会影响系统的建设。但并不是所有的涉众都是系统的参与者。
参与者是涉众代表。参与者对系统的要求直接影响系统的建设，他们的要求就是系统需求的来源。参与者通过对系统提出要求来获得他所代表的涉众的利益。
用户（user）是指系统的使用者，通俗一点说就是系统的操作员。用户是参与者的代表，或者说是参与者的实例或代理。并非所有的参与者都是用户，但是一个用户可以代理多个参与者。
角色（role）是参与者的职责。角色是一个抽象的概念，从众多参与者的职责中抽象出相同的那一部分，将其命名而形成一个角色。一个角色代表了系统中一类职责。
另外，由于一个用户可以代理多个参与者，因此一个用户可以拥有多个职责，也就是可以被指定多个角色。
如何保证发现的参与者是正确的呢？下面提供了一个checklist：
原文：http://www.cnblogs.com/simpro/p/4356822.html