5.2.1　参与者

1．参与者的概念

参与者（Actor）是指存在于系统外部并直接与系统进行交互的人、系统、子系统或类的外部实体的抽象。每个参与者可以参与一个或多个用例，每个用例也可以有一个或多个参与者。在用例图中使用一个人形图标来表示参与者，参与者的名字写在人形图标下面，如图5-3所示。

很多初学者都把参与者理解为人，这是错误的。参与者代表的是一个集合，通常一个参与者可以代表一个人、一个计算机子系统、一个硬件设备或者时间等。人是其中最常见也是最容易理解的参与者，对于上一节中提到的银行自动取款机（ATM）来说，它的参与者就是银行用户。

一个系统也可以作为参与者，大家去商场购物，经常会采用刷卡付款的方式，这时候就需要商场的管理程序和外部的应用程序建立联系，来验证信用卡以便完成信用卡的付款操作。其中，外部信用卡程序就是一个参与者，是一个系统。

而在有的系统中，一个进程也可以作为参与者，例如时间。如果家里开通上网包月的话，当包月时间快结束的时候，系统就会提示相关服务人员，再由这些人员通知包月到期的用户。由于时间不在人的控制范围内，因此也是一个参与者。

要注意的是，参与者虽然可以代表人或事物，但参与者不是指人或事物本身，而是表示人或事物当时所扮演的角色。例如小王是银行的工作人员，他参与银行管理系统的交互，这时他既可以作为管理员这个角色参与管理，也可以作为银行用户来取钱，在这里小王扮演了两个角色，是两个不同的参与者。因此，不能将参与者的名字表示成参与者的某个实例，例如小王作为银行用户来取钱，但是参与者的名字还是银行用户而不能是小王。

一个用例的参与者可以划分为发起参与者和参加参与者。发起参与者发起了用例的执行过程，一个用例只有一个发起参与者，可以有若干个参加参与者。在用例中标明发起参与者是一个明智的做法。

参与者还可以划分为主要参与者和次要参与者。主要参与者指的是执行系统主要功能的参与者，次要参与者指的是使用系统次要功能的参与者。标明主要参与者有利于找出系统的核心功能，往往也是用户最关心的功能。

2．确定参与者

在获取用例前首先要确定系统的参与者，寻找参与者可以从以下问题入手：

• 系统开发完成后，使用系统主要功能的是谁。
• 谁需要借助系统来完成日常的工作。
• 系统需要从哪些人或其他系统中获得数据。
• 系统会为哪些人或其他系统提供数据。
• 系统会与哪些其他系统交互？其他系统包括计算机系统和计算机中的其他应用软件。其他系统可以分为两类：一类是该系统要使用的系统；另一类是启动该系统的系统。
• 系统是由谁来维护和管理的，以保证系统处于工作状态。
• 系统控制的硬件设备有哪些？
• 谁对本系统产生的结果感兴趣。

要注意的是，寻找参与者的时候不要把目光只停留在使用计算机的人身上，直接或间接地与系统交互的任何人和事都是参与者。另外，由于参与者总是处于系统外部，因此他们或它们可以处于人的控制之外。让我们来看一个比较特殊的参与者—系统时钟。有时候需要在系统内部定时地执行一些操作，如检测系统资源使用的情况、定期地生成统计报表等等。这些操作并不是由外部的人或系统触发的，它是由一个抽象出来的系统时钟或定时器参与者来触发的，如图5-4所示。

3．参与者之间的关系

由于参与者实质上也是类，因此它拥有与类相同的关系描述，即参与者与参与者之间主要是泛化关系（或称为“继承”关系）。泛化关系的含义是把某些参与者的共同行为提取出来表示成通用行为，并描述成超类（或父类）。泛化关系表示的是参与者之间的一般或特殊关系，在UML图中，使用带空心三角箭头的实线表示泛化关系，如图5-5所示，箭头指向超类参与者。

在需求分析中很容易碰到用户权限问题，就拿一个公司来说，普通职员有权限进行一些常规操作，而销售经理和人事经理在常规操作之外还有权限进行销售管理和人事管理。用例图如图5-6所示。

在这个例子中，我们会发现销售经理和人事经理都是一种特殊的用户，他们拥有普通用户所拥有的全部权限，此外他们还有自己独有的权限。这里可进一步把普通用户和销售经理、人事经理之间的关系抽象成泛化（Generalization）关系。

如图5-7所示，职员是父类，销售经理和人事经理是子类。通过泛化关系，可以有效地减少用例图中通信关联的个数，简化用例模型，便于大家理解。