参与者
1. 基本概念
UML建模是以人为本的，没有人就没有接下来的故事。
参与者（actor）在建模的过程中是处于核心地位的。官方定义为：是在系统之外与系统交互的某人或某事物。
1.1 参与者位于边界之外
主动启动业务的，就是参与者。
1.2 参与者可以非人
当某些需求没有人参与时，需求的启动者即为参与者。
2. 发现参与者
询问以下问题帮助确定参与者：
- 谁负责提供、使用或删除信息？
- 谁将使用此功能？
- 谁对某个特定的功能感兴趣？
- 在组织中的什么地方使用系统？
- 谁负责支持和维护系统？
- 系统有哪些外部资源？
- 还有哪些其他系统将需要与该系统进行交互？
- 情况一：机票购买者通过登录网站购买机票，那么机票购买者就是参与者。
- 情况二：机票购买者通过呼叫中心，由人工座席操作订票系统来购买机票，那么人工座席才是真正的参与者，而机票购买者实际上是呼叫中心的参与者。
- 情况三：如果机票购买者通过呼叫中心的自动语音预定机票而不是通过人工座席，那么呼叫中心就成为机票预订系统的一个参与者。这是一个参与者非人类的例子。
- 情况四：如果扩大系统边界，让呼叫中心成为机票预订系统的一个子系统，并且假设机票购买者将可以自主选择是通过人工座席、自动语音还是登录网站来预定机票，那么机票购买者是参与者，而人工座席则变成业务工人。
3. 业务主角
业务主角（business actor）是参与者的一个版型，在需求阶段使用，是与业务系统有着交互的人和事物，用来确定业务的范围。
业务主角的特殊之处在于，他针对的是业务人员，是客户实际业务里的参与者，而不是计算机用户。
4. 业务工人
处于系统边界内，就不再是参与者，但是确实参与了业务的执行过程，就被成为业务工人（business worker）。
如情况四中的人工座席。
如何分辨是参与者还是业务工人呢？
最直接的办法是判断在边界之外还是边界之内。如果边界尚不清楚，通过以下三个问题帮助澄清：
- 它是主动向系统发出动作的吗？
- 他有完整的业务目标吗？
- 系统是为他服务的吗？
如果是否定的，则是业务工人。
5. 参与者与涉众的关系
涉众（stakeholder），也称为干系人。涉众是与要建设的这个系统有利益相关的一切人和事，涉众的利益会影响系统的建设。
- 并不是所有的涉众都是系统的参与者，与系统的建设存在利益关系即为涉众；
- 而参与者是涉众代表，它们的要求是系统需求的来源。
6. 参与者和用户的关系
用户（user）是指系统的使用者，通俗来说就是系统的操作员。
- 用户是参与者的代表；
- 并非所有的参与者都是用户，但是一个用户可以代理多个参与者。
7. 参与者与角色的关系
角色（role）是参与者的职责。一个角色代表了系统中的一类职责。
由于一个用户可以代理多个参与者，因此一个用户可以拥有多个职责，也就是可以被指定多个角色。
8. 参与者的核心地位
- 参与者是涉众的代表，他代表涉众对系统的利益要求，并向系统提出建设要求；
- 参与者通过代理给其他用户或者将自身实例化为用户来使用系统；
- 参与者的职责可以用角色来归纳，用户被指定扮演哪个或哪些角色，来获得参与者的职责。
9. 检查点
通过一个检查点列表来保证发现的参与者是正确的：
- 是否您已经找到所有的参与者？也就是说，是否您已经对系统环境中所有角色都进行了说明和建模？虽然您应该检查这一点，但是要到您找到并说明了所有用例后才能将其确定。
- 每个参与者是否至少涉及到一个用例？删除未在用例说明中提及的所有参与者，或与用例无通信关联关系的所有参与者。
- 您是否列出至少两名可以作为特定参与者的人员？如果不能，请检查参与者所建模的角色是否为另一角色的一部分。如果是这样，您应该将参与者与另一参与者合并。
- 是否有参与者担任与系统相关的相似角色？如果有，您应该将它们合并到一个主角中。通信关联关系和用例说明表明参与者和系统是如何相互关联关系的。
- 是否有两个参与者担任与用例相关的同一角色？如果有，您应该利用参与者泛化关系来为它们的共享行为建立模型。
- 特定的参与者是否将以几种（完全不同的）方式使用系统？或者，他使用用例是否出于几个（完全不同的）目的？如果是这样，您也许应该有多个参与者。
- 参与者是否有直观名称和描述性名称？用户和客户是否都能理解这些名称？参与者的名称务必要与其角色相符。否则，应对其进行修改。
