第二部分 基础篇————在学习中思考
3.2参与者
一、基本概念
参与者是在系统之外与系统交互的某人或某事物。
1、参与者位于边界之外
确定边界之内与外，需要回答的两个问题
- 谁对系统有着明确的目标和要求并且主动发出动作？
- 系统是为谁服务的？
2、参与者可以非人
没有人参与的需求一定有别的事物在发中动的动作，应当找到这个事物，这个事物就是一个参与者，它可能是另一个计算机系统、一个计时器、一个传感器或者一个JMS消息。总之，任何需求者必须至少有一个启动者，如果找不到启动者，那么可以肯定地说这不是一个功能性需求。
二、找到参与者
在查找参与者的过程中，可以询问以下问题以帮助确定参与者
- 谁负责提供、使用或删除信息？
- 谁将使用此功能？
- 谁对某个特定功能感兴趣？
- 在组织中的什么地方使用系统？
- 谁负责支持和维护系统？
- 系统有哪能些外部资源？
- 其他还有哪能些系统将需要与该系统进行交互？
在找参与者时请注意，参与者一定是直接并且主动地向系统发出动作并获得反馈的，否则就不是参与者。
三、业务主角
业务主角（Business actor）是参与者的一个版型，特别用于定义业务的参与者，在需求阶段使用。业务主角是与业务系统有着交互的人和事物，他们用来确定业务范围。业务主角是参与者的一个版型，所以业务主解必须遵守参与者的所有定义。
如果对获得的业务主角不是很自信，请回答以下问题：
- 业务主角的名称是否是客户的业务术语？
- 业务主角的职责是否在客户的岗位手册 里有对应的定义？
- 业务主角的业务用例是否都是客户的业务术语？
- 客户是否对业务主角参顺利理解？
四、业务工人
完成主解的业务目标。
如何研究业务工人
- 他是主动向系统发出动作的吗？
- 他有完整的业务目标吗？
- 系统是为他服务的吗？
这三个问题的如果是否定的，那一定是业务工人。
五、参与者与涉众的关系
涉众是与要建设的这个系统有利益相关的一切人和事，涉众的利益要求会影响系统的建设。
参与者是涉众代表。
六、参与者与用户的关系
用户是指系统的使用者，通俗一点说就是系统操作员。用户是参与者的代表，或者说是参与者的实例或代理。并非所有的参与者都是用户，但是一个用户可以代理多个参与者。
七、参与者与角色的关系
角色是参与者的职责。角色是一个抽象的概念，从众多参与者的职责中抽象出相同的那一部分，将其命名而形成一个角色。一个角色代表了系统中的一类职责。由于一个用户可以代理多个参与者，因此一个用户可以拥有多个职责，也就是可以被指定多个角色。
八、参与者的核心地位
参与者是涉众的代表，它代表涉众对系统的利益要求，并向系统提出建设要求cd与者通过代理给其它用户或将自身实例化成用户来使用系统cd与者的职责可以用角色来归纳，用户被指定扮演哪个或哪些角色因此来获得参与者的职责。
九、检查点
如何保证发现的参与者是正确的呢？统一过程的官方文档里给出了一个检查点例表：
- 是否您已惶恐到所有的参与者？也就是说，是否您已经对系统环境中的所有角色都进了说明和建模？虽然你应该检查这一点，但是要到您找到并说明了所有用例后才能将其确定。
- 每个参与者是否至少涉及到一个用例？删除未在用例说明中提及的所有参与者，或与用例无通信关联关系的所有参与者。
- 您能否列出至少两名可以做为特定参与者的人员？如果不能，请检查参与者所建模的角色是否为另一角色的一部分。如果是这样，您应该将该参与者与另一参与者合并。
- 是否有参与者担任与系统相关的相似角色？如果有，您应该将他们合并到一个主角中。通信关联关系和用例说明表明参与者和系统是如何相互关联关系的。
- 是否有两个参与者担任与用例相关的同一角色？如果有，您应该利用参与者泛化关系来为他们的共享行为建立模型。
- 特定的参与者是否将以几种（完全不同的）方式使用系统？或者,他使用用例是否出于几个（完全不同的）目的？如果是这样，您也许应该有多个参与者。
- 参与者是否有直观名称和描述性名称？用户和客户是否都能理解这些名称？参与者的名称务必要与角色相符。否则，应对其进行更改。
3.3 用例
用例官方定义：用例定义了一组用例实例，其中每个实例都是系统所执行的一每系列操作，这些操作生成特定主角可以观测的值。
一个用例就是与参与者交互的，并且给参与者提供可观测的有意义的结果的一系列活动的集合。
一个场景就是一个用例的实例。
一个完整的用例定义由参与者、前置条件、场景、后置条件构成。
捕捉功能性需求，这就是用例的作用。
一、用例的特征
- 用例是相对独立的。
- 用例的执行结果对参与者来说是可观测的和有意义的。
- 这件事必须由一个参与者发起。不存在没有参与者的用例，用例不应该自动启动，也不应该主动启动另一个用例。
- 用例必然是以动宾短语形式出现的。
- 一个用例就是一个需求单元、分析单元、设计单元、开发单元、测试单元，甚至部署单元。
二、用例的粒度
在业务建模阶段，用例的粒度以每个用例能够说明一件完整的事情为宜。
在用例分析阶段，即概念建模阶段，用例的粒度以每个用例能描述一个完整的事件流为宜。
在系统建模阶段，用例视角是针对计算机的，因此用例的粒度以一个用例能够描述操作者与计算机的一次完整交互为宜。
用例粒度的划分依据（尤其是业务用例）最标准的方法是以该用例是否完成了参与者的某个完整目的为依据的。
粒度选择必须把握的原则是在同一个需求阶段，所有用例的粒度应该介同一个量级的。
