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