摘自大象Thinking in UML 谭云杰一、参与者（Actor、主角）(一) 特点： 1)业务建模的核心。它是涉众代表，代表涉众对系统的利益要求，并向系统提出建设 要求。系统是以参与者的观点决定的，他对系统的要求，对系统的表述完全决定了 系统的功能性。 2)参与者位于边界之外 1.谁对系统有着明确的目标和要求，并且主动发出动作？ 2.系统是为谁服务的？ 3)业务工人（Business Worker） 4)参与者可以非人 5)涉众是发现参与者的重要来源 6)涉众（Stakeholder） ，又称干系人，指与建设系统有利益相关的一切人和事，但涉众 不一定是系统的参与者。参与者是涉众代表，他对系统的要求直接影响到系统的建 设，他们的要求就是系统需求的来源。参与者通过对系统提出要求来获得他所代表 的涉众的利益。由此可见，参与者也并不需要询问同一岗位所有人，而是找出可代 表该岗位的代表，与之沟通。 7)用户和参与者，用户是指系统的使用者，系统的操作员，他是参与者的代表。 8)角色是参与者的职责，是一个抽象的概念，从众多参与者的职责中抽象出相同的一 部分，将其定义一个角色。一般适用于概念阶段的模型，以表达业务的逻辑理解。 一个用户可以代理多个参与者，一个用户可以拥有多份职责，即可被指定多个角色。(二) 问题 1)谁负责提供、使用或删除信息？ 2)谁将使用此功能？ 3)谁对某个特定功能感兴趣？ 4)在组织中的什么地方使用系统？ 5)谁负责支持和维护系统？ 6)系统有哪些外部资源？ 7)其他还有哪些系统将需要与该系统进行交互？(三) 版型 1)业务主角（Business Actor） 定义业务的参与者，在需求阶段使用，用来确定业务范围。非常重要，建立业务模 型、查找业务用例都须用业务主角。 业务范围和系统范围不同，业务范围指项目涉及的所有客户业务，有些业务内容没 有系统参与也一样客观存在。 系统范围仅指软件要实现的业务功能。有些系统功能不在业务范围，如操作日志。 业务主角针对业务人员，而非计算机用户，也不应过早引入计算机系统的概念，以 免混淆，导致误导用户。业务主角必须在实际业务里能找到对应的岗位或人员。 常用问题： 业务主角的名称是否是客户的业务术语？ 业务主角的职责是否在客户的岗位手册里有对应的定义？ 业务主角的业务用例是否都是客户的业务术语？ 客户是否对业务主角能顺利理解？2)业务工人（Business Worker） BW 被动参与业务。 BW 处于系统边界内。 不需要为 BW 建立业务模型，只在主角的业务模型中出现。 虽然不参与业务建模，但他们仍然不可或缺，如领域模型、用例模型。缺少他们业 务模型就不完整，甚至不能运行。 判断他是在边界之内和边界之外，常用问题： 他是主动向系统发出动作的吗？ 他有完整的业务目标吗？ 系统是为他服务的吗？(四) 检查点（RUP 官方文档，非常有助于检查发现的参与者是否正确） 1)是否您已找到所有的参与者？也就是说，是否您已经对系统环境中的所有角色都进 行了说明和建模？虽然您应该检查这一点，但是要到您找到并说明了所有用例后才 能将其确定。 2)每个参与者是否至少涉及一个用例？删除未在用例说明中提及的所有参与者，或与 用例无通信关联关系的所有参与者。 3)您能否列出至少两名可以作为特定参与者的人员？如果不能，请检查参与者所建模 的角色是否为另一角色的一部分。如果是这样，您应该将该参与者与另一参与者合 并。 4)是否有参与者担任与系统相关的相似角色？如果有，您应该将他们合并到一个主角 中。通信关联关系和用例说明表明参与者和系统是如何相互关联关系的。 5)是否有两个参与者担任与用例相关的同一角色？如果有，您应该利用参与者泛化关 系来为他们的共享行为建立模型。 6)特定的参与者是否将以几种（完全不同的）方式使用系统？或者，他使用用例是否 出于几个（完全不同的）目的？如果是这样，您也许应该有多几个参与者。 7)参与者是否有直观名称和描述性名称？用户和客户是否都能理解这些名称？参与者 的名称务必要与其角色相符。否则，应对其进行更改。二、用例（Use Case） 用例是 UML 建模中最重要的元素。除了用例外，所有其他元素都是“封装” 、 “独立”的。这 些元素在没有外力作用时，是“老死不相往来”的。用例正是施加这一“外力”的元素，它使得 其他各自独立的元素能共同组成一篇有意义的文字。 用例是一种把现实世界的需求捕获下来的方法。首先有某人的一个愿望，这个愿望驱使人去 做事并获得一个确定的结果。一个系统就是由各种各样的愿望组成的。如果所有对系统有愿望的人要做的所有事情都找全了，那这个系统的功能性就被确定下来了。 官方定义：用例定义了一组用例实例，其中每个实例都是系统所执行的一系列操作，这些操 作生成特定主角可以观测的值。 本书定义：一个用例就是与参与者交互的，并且给参与者提供可观测的有意义的结果的一系 列活动的集合。 一个用例场景就是一个用例的实例。 一个完整的用例定义由参与者、前置条件、场景、后置条件构成。(一) 用例特征a)用例是相对独立的。用例是相对独立的。 不需要与其他用例交互而独自完成参与者的目的。如取钱是一个用例，而填写取款 单却不是。没人会只为了填写取款单跑一趟银行。 b)用例的执行结果对参与者来说是可观测的和有意义的。用例的执行结果对参与者来说是可观测的和有意义的。 例如，一个后台进程监控参与者在系统里的操作，在参与者删除数据之前执行备份。 虽然它是系统的一个必需组成部分，但它在需求阶段却不应该作为用例出现。因为 这是一个后台进程，对参与者来说是不可观测的，它应作为系统需求在补充规约中 定义。又比如，登录系统是一个用例，但输入密码不是。因为登录系统对参与者是 有意义的，这样他可以获得身份认证和授权，但单纯输入密码却是没有意义的。 c)这件事必须由一个参与者发起。不存在没有参与者的用例，用例不应该自动启动，这件事必须由一个参与者发起。不存在没有参与者的用例，用例不应该自动启动， 也不应该主动启动另一个用例。也不应该主动启动另一个用例。 如从 ATM 取钱是一个用例，ATM 吐钞却不是。 d)用例必然是以动宾短语形式出现的用例必然是以动宾短语形式出现的 如喝水是一个有效的用例，而“喝”和“水”却不是。很多用例中以“计算” 、 “统 计” 、 “报表” 、 “输出” 、 “录入”之类命名的并不在少数。 e)一个用例就是一个需求单元、分析单元、设计单元、开发单元、测试单元，甚至部一个用例就是一个需求单元、分析单元、设计单元、开发单元、测试单元，甚至部 署单元。署单元。(二) 用例粒度 粒度是令人困惑的。比如在 ATM 取钱的场景中，取钱、读卡、验证账号、打印回执 单等都是可能的用例。取钱粒度更大一些，其他则要小一些。作者经验在项目过程中根据阶段不同，使用不同的粒度。 在业务建模阶段，用例的粒度以每个用例能够说明一件完整的事情为宜。即一个用 例可以描述一项完整的业务流程。例如取钱、报装电话、借书等表达完整业务的用例， 而不要细到验证密码、填写申请单、查找书目等业务中的一个步骤。 在用例分析阶段，即概念建模阶段，用例的粒度以每个用例能描述一个完整的事件流为宜。可理解为一个用例描述一项完整业务中的一个步骤。这个阶段需要采用一些面 对对象的方法，归纳和抽象出业务用例中的关键概念模型并为之建模。例如，宽带业务 需求中有申报报装和申请迁移地址用例，在用例分析时，可归纳和分解为提供申请资料、 受理业务、现场安装等多个业务流程中都会使用的概念用例。 在系统建模阶段，用例视角是针对计算机的，因此用例的粒度以一个用例能够描述 操作者与计算机的一次完整交互为宜。例如，填写申请单、审核申请单、派发任务单等。 可理解为一个操作界面或一个页面流。在 RUP 中，项目计划要依据系统模型编写，因此 另一个可参考的粒度是一个用例的开发工作量在一周左右为宜。用例粒度的划分依据（尤其是业务用例）最标准的方法是以该用例是否完成了参与 者的某个完整目的为依据的。 一般来说，一个系统的业务用例定义在多于 10 个，少于 50 个之间，否则就应该考 虑一下粒度选择是否合适了。(三)