《大象：thinking in uml 》(第二版) 3章 UML核心元素 1-2节版型、参与者

只供参考，喜欢请支持正版图书

3.1 版型

在UML里有一个概念叫版型（stereotype），有些书里也称为类型、构造型。这个概念是对一个UML元素基础定义的扩展，在同一个元素基础定义的基础上赋予特别的含义，使得这个元素适用于特定的场合。

UML中几乎每一个元模型都有很多版型。例如用例有“业务用例”、“业务用例实现”等版型；类就更多了，我们熟知的“接口”、“边界类”、“实体类”、“控制类”等都是类的版型，甚至“参与者”本身，也是一个特殊类的版型。

读者需要了解的是，版型只是UML的一种扩展手段，本身并不涉及太多的思想和方法，而是在建模的不同阶段，为了区分视图之间的不同观点，会采用不同的图示来表示。例如“业务用例”、“业务用例实现”就是专门应用在业务建模场合的。重要的不是业务用例的版型长什么样，而是理解当用例用于捕获需求时，用例会有一些特别的意义，而不要认为业务用例这个版型和用例是完全不同的两个元素。

3.2 参与者

以人为本是当代的流行词汇，UML建模也是以人为本的。可以说如果没有人，就不会有接下来的故事。如果读者回顾一下2.1建模一节就会想起来，建模是从寻找抽象角度开始的，那么定义人，准确地说是定义参与者，就是我们寻找抽象角度的开始。

3.2.1　基本概念

参与者（actor）在建模过程中是处于核心地位的。UML官方文档对参与者的定义为：actor是在系统之外与系统交互的某人或某事物。图3.1展示了上述定义中的关键点。

在实际的工作中，建模者常常会面临一个问题，谁是参与者？例如这样一个场景：小王到银行去开户，向大厅经理询问了办理手续，填写了表单，交给柜台职员，拿到了银行存折。在这个场景中，谁是参与者？

按照定义，要弄明白谁是参与者首先要弄明白系统的边界。但在这个场景中系统边界是不明确的，如何确定系统之外和系统之内呢？可以通过回答下面两个问题来确定，这两个问题非常有用，能帮助找出参与者从而确定边界。

■　谁对系统有着明确的目标和要求并且主动发出动作？
■　系统是为谁服务的？

显然在这个场景中，第一个问题的答案是小王有着明确的目标：开户，并且主动发出了开户请求的动作；第二个问题的答案是系统运作的结果是给小王提供了开户的服务。小王是当然的参与者，而大厅经理和柜台职员都不满足条件，在小王没有主动发出动作以前，他们都不会做事情，所以他们不是参与者。同时，由于确定了小王是参与者，相应地也就明确了系统边界，包括大厅经理和柜台职员在内的其他事物都在系统边界以内。

实际上在官方文档中，参与者还有另一种叫法：主角。笔者认为从含义上讲，主角这个译法比参与者更准确

我们确定了小王是参与者，那大厅经理和柜台职员怎么算呢，他们不也“参与”了业务了吗？在本节稍后读者可以看到，实际上大厅经理和柜台职员由于“参与”了业务，他们可以被称为业务工人（business worker）

建模者也常常会面临另一个问题，有些需求并没有人参与，参与者如何确定？例如这样一个需求：每天自动统计网页访问量，生成统计报表，并发送至管理员信箱。这个需求的参与者是谁？

读者会看到代表了功能性需求的用例有一个特征是“不存在没有参与者的用例，用例不应该自动启动，也不应该主动启动另一个用例”。这说明没有人参与的需求一定有别的事物在发出启动的动作，应当找到这个事物，这个事物就是一个参与者，它可能是另一个计算机系统、一个计时器、一个传感器或者一个JMS消息。总之，任何需求都必须至少有一个启动者，如果找不到启动者，那么可以肯定地说这不是一个功能性需求

3.2.2　发现参与者
在查找参与者的过程中，可以询问以下问题以帮助确定参与者：

■　谁负责提供、使用或删除信息？
■　谁将使用此功能？
■　谁对某个特定功能感兴趣？
■　在组织中的什么地方使用系统？
■　谁负责支持和维护系统？
■　系统有哪些外部资源？
■　其他还有哪些系统将需要与该系统进行交互？

查找参与者时请注意，参与者一定是直接并且主动地向系统发出动作并获得反馈的，否则就不是参与者。为了说明如何查找参与者，我们考虑一个机票预定系统，并分析以下几种情况。

3.2.3　业务主角

业务主角（business actor）是参与者的一个版型，特别用于定义业务的参与者，在需求阶段使用。业务主角是与业务系统有着交互的人和事物，他们用来确定业务范围（见注）。业务主角是参与者的一个版型，所以业务主角必须遵守参与者的所有定义。

注：在软件项目里，业务范围和系统范围是不同的。业务范围指这个项目所涉及的所有客户业务，这些业务有没有计算机系统参与都客观存在。系统范围是指软件将要实现的那些对应于业务功能的系统功能，从功能性需求来说系统范围是业务范围的一个子集。但是一些系统功能则会超出业务范围，例如操作日志。有没有操作日志并不影响业务目标的达成，客户也不一定会提出这个要求，但从系统角度出发，操作日志会使得系统更加健壮。

业务主角的特殊性在于，它针对的是业务人员而非计算机用户。在查找业务主角时必须抛开计算机，没有计算机系统这些业务人员也客观存在，在引入计算机系统之前他们的业务也一直跑得很顺畅。这是因为在初始需求阶段，我们需要获得的是客户的业务模型，根据业务模型才能建立计算机系统模型。如果在了解业务的阶段就引入计算机系统的概念，将会混淆现有业务和将来有计算机参与时的业务。请记住，要建设一个符合客户需要的计算机系统，首要条件是完全彻底地搞清楚客户的业务，而不是预先假设已经有了一个计算机系统，再让客户来假想需要计算机系统帮他们做什么

业务主角是非常重要的，建立业务模型、查找业务用例都必须使用业务主角，而不是普通的参与者。很多需求分析人员是由程序员或设计师担任的，由于有开发计算机系统的背景，使得他们在建立业务模型时非常容易犯一个错误，喜欢从计算机系统的角度来思考问题，在向客户收集需求的时候总是在第一时间想到计算机将如何实现它，常常津津乐道于跟客户讨论计算机系统将如何实现客户的需求，并且指望客户能够用这种方式来确认需求。这样做将导致如下两个后果：

客户不能理解将来计算机实现是一个什么样子，但是出于信任所谓计算机专家，将信将疑地回答：是，就是这样做的。其结果是当计算机系统真正展现在客户面前时，客户大声说道：不，这不是我想要的。

需求分析人员在一开始就加入了自己的主观判断，假设了业务在计算机系统里的实现方式，而没有真正去理解客户的实际业务。其结果是当计算机系统建设完成后，客户抱怨说：不对，流程不是这样的；开发人员也很委屈：我是按需求来做的啊！

所以在初始需求阶段，请务必使用业务主角，时时牢记业务主角是客户实际业务里的参与者，没有计算机系统，没有抽象的计算机角色。业务主角必须在实际业务里能找到对应的岗位或人员。如果你对获得的业务主角不是很自信，请回答以下问题：

■　业务主角的名称是否是客户的业务术语？
■　业务主角的职责是否在客户的岗位手册里有对应的定义？
■　业务主角的业务用例是否都是客户的业务术语？
■　客户是否对业务主角能顺利理解？

3.2.4　业务工人

建模者经常会被一个问题困扰，有些人员参与了业务，但是身份很尴尬，他是被动参与业务的，不好说他有什么具体的目的，但是他又的确在业务过程中做了事情，到底要不要为这样的人建模？这种情况就是图3.5中的人工座席。人工座席可以定票，可是他本身是系统边界里的一部分，而且没有购票人拨打电话，他是不会去定票的。看上去他只是购票人的一个响应器，或者他是为购票人购票过程中服务的一环。如果要为人工座席建立业务模型，总是感觉到很别扭，因为它无法跟购票人放在一起。实际上，这种困扰是因为违背了参与者的定义：参与者必须要在边界以外。如果试图把边界内和边界外的参与了业务的人都叫做参与者而建立模型，就会出现混乱和尴尬。图3.6展示了这种矛盾。实际上，图3.6中的人工座席由于处于系统边界内，他就不再是参与者，虽然他的确参与了业务的执行过程。他应当被称为业务工人（business worker）。

参与者这个叫法不可避免地带来一个歧义，会让人觉得凡是参与了业务的或在业务流程中做了事情的，都是参与者。这是一个误解，如果换一个叫法，把参与者换成“主角”，应当就会避免这种歧义

业务工人虽然不需要建立业务模型，但是他们是业务模型中非常重要的部分，经常出现的地方是领域模型（详见5.5节领域模型）和用例场景。缺少了他们业务模型就不完整，甚至不能运行

那么如何区分是参与者还是业务工人呢？最直接的办法当然是判断是在边界之外还是边界之内。如果边界尚不清楚，可以通过下面的三个问题帮助澄清：

■　他是主动向系统发出动作的吗？
■　他有完整的业务目标吗？
■　系统是为他服务的吗？

这三个问题的答案如果是否定的，那一定是业务工人。以人工座席这个例子来说，人工座席只有在购票人打电话的情况下才会去购票，因此他是被动的；定票的最终目的是拿到机票，但人工座席只负责定，最终票并不到他的手里，因此他没有完整的业务目标；系统是为购票者服务的。非常明显，人工座席只可能是一个业务工人。

3.2.5　参与者与涉众的关系
涉众（stakeholder），也称为干系人。涉众是与要建设的这个系统有利益相关的一切人和事，涉众的利益要求会影响系统的建设。关于涉众，本书第二部分的8.3节会有更多的讨论，读者在这里需要了解，只要和这个系统有利益关系的都是这个项目的涉众。涉众虽然与这个系统有利益相关，但并不是所有的涉众都是系统的参与者。假设一个系统的建设是由一家国际风险投资机构投资的，这个系统必然与这家投资机构有着利益关系，有时系统必须满足投资方的一些特殊要求，作为涉众，投资方的意见或许会构成一些约束。但投资方并不会参与系统的建设，它只是从资本上拥有这个系统并从将来的收入中获得回报。

参与者是涉众代表。参与者对系统的要求直接影响系统的建设，他们的要求就是系统需求的来源。参与者通过对系统提出要求来获得他所代表的涉众的利益。例如要建立一个办公自动化系统，这个系统将为所有的办公室文员归档和查找文件带来利益。但是并不需要把所有的办公室文员都找来询问需求，一个称之为“文员”的参与者可以代表这批涉众来向系统提出如何归档和如何查询的要求，以此来获得涉众利益。

3.2.6　参与者与用户的关系
用户（user）是指系统的使用者，通俗一点说就是系统的操作员。用户是参与者的代表，或者说是参与者的实例或代理。并非所有的参与者都是用户，但是一个用户可以代理多个参与者。例如在建设办公自动化系统的过程中常常会有这样的情况，局长是一个参与者，他向系统提出了如何审批的要求。但是局长这个参与者最终可能并不是系统用户，他将所有的操作都交给秘书，这时秘书作为局长代理来使用系统。另一种情况是，局长还分为正局长和副局长，但是实际上只有副局长最终使用系统，这时副局长就作为局长这一参与者的实例来使用系统。

3.2.7　参与者与角色的关系
角色（role）是参与者的职责。角色是一个抽象的概念，从众多参与者的职责中抽象出相同的那一部分，将其命名而形成一个角色。

一个角色代表了系统中的一类职责。例如办公自动化系统中，正副处长、正副局长都可以审批文件，审批文件这一职责就可以用一个角色来代表，比如命名一个文件审批者角色来代表审批文件这一职责。

角色一般适合用在概念阶段的模型里，以表达业务的逻辑理解

另外，由于一个用户可以代理多个参与者，因此一个用户可以拥有多个职责，也就是可以被指定多个角色。

3.2.8　参与者的核心地位
从上面的描述中我们得知，参与者是涉众的代表，它代表涉众对系统的利益要求，并向系统提出建设要求；参与者通过代理给其他用户或将自身实例化成用户来使用系统；参与者的职责可以用角色来归纳，用户被指定扮演哪个或哪些角色因此来获得参与者的职责。

3.2.9　检查点
经过上面的讨论，读者应该已经知道如何去定义和发现一个参与者。但是如何保证发现的参与者是正确的呢？统一过程的官方文档里给出了一个检查点列表，回答这个检查点列表中的问题非常有助于检查发现的参与者是否正确，读者可以参考之。

■　您是否已找到所有的参与者？也就是说，您是否已经对系统环境中的所有角色都进行了说明和建模？虽然您应该检查这一点，但是要到您找到并说明了所有用例后才能将其确定。

■　每个参与者是否至少涉及到一个用例？删除未在用例说明中提及的所有参与者，或与用例无通信关联关系的所有参与者。

■　您能否列出至少两名可以作为特定参与者的人员？如果不能，请检查参与者所建模的角色是否为另一角色的一部分。如果是这样，您应该将该参与者与另一参与者合并。

■　是否有参与者担任与系统相关的相似角色？如果有，您应该将他们合并到一个主角中。通信关联关系和用例说明表明参与者和系统是如何相互关联关系的。

■　是否有两个参与者担任与用例相关的同一角色？如果有，您应该利用参与者泛化关系来为他们的共享行为建立模型。

■　特定的参与者是否将以几种（完全不同的）方式使用系统？或者，他使用用例是否出于几个（完全不同的）目的？如果是这样，您也许应该有多个参与者。

■　参与者是否有直观名称和描述性名称？用户和客户是否都能理解这些名称？参与者的名称务必要与其角色相符。否则，应对其进行更改。

只供参考，喜欢请支持正版图书