设计模式（2）用例图之一

导言

为了说明用例图，我们将先介绍用例的定义，然后介绍用例图的相关内容，比如参与者、次要参与者等等。

用例

简介

在用例建模方法中，功能性需求参与者（系统的用户）和用例来描述。

参与者另可称为执行者，执行者执行用例，参与者可以说是参与者参与了用例，或参与了用例的实现

定义

用例 定义了一个或多个参与者和系统之间的交互序列。

用例是在系统中执行的一系列动作，这些动作将生成特定执行者可见的价值结果。
一个用例定义一组用例实例。
在需求阶段，用例模型将系统考虑成黑盒，并以包含用户输入和系统响应的叙述形式描述参与者和系统的交互

用例模型

用例模型用参与者和用例描述系统的功能性需求。系统被看作黑盒，即处理系统会做什么来响应参与者输入，而不是系统如何做的内部细节。

用例理解

用例总是从参与者的输入开始。典型地，一个用例包含了参与者和系统之间的交互序列。每个交互由参与者的输入以及后续的系统响应组成。

参与者向系统提供输入，而系统向参与者提供响应。

系统总是被考虑成为一个黑盒，使得其内部细节不会被暴露。尽管一个简单的用例可能只包含参与者和系统之间的一个交互，但更为典型的用例是会由参与者和系统之间的多个交互组成。更复杂的用例也可能涉及了不止一位参与者。

用例例子

这里可以举出一个例子:
简单的银行系统：
自动提款机（ATM）允许客户从他们的银行账户中取款。这里有一个参与者“ATM客户”(ATM Customer)和一个用例“取款”（Withdraw Funds）,如下图所示：

“取款”用例描述了客户和系统之间的交互序列。用例始于客户将一张ATM卡插入到读卡器中，然后，客户响应系统提示输入密码（PIN），最终客户接收到ATM机发出的现金。

参与者（执行者）

定义

参与者（执行者）是在系统之外，透过系统边界与系统进行有意义交互的任何事物。
参与者描绘了一个与系统交互的外部用户(即在系统之外)

在用例建模中，参与者是与系统交互的唯一外部实体。换句话说，参与者是在系统之外的，不是系统的一部分
引入参与者（执行者）的目的：帮助确定系统边界。

参与者、角色和用户区别

参与者代表了应用领域中扮演的一种角色；典型地，该角色是人类用户扮演的。用户是一个个体，而参与者代表了相同类型的所有用户所扮演的角色。
比如，“银行系统”（上面的实例）中有多位客户，他们都由参与者ATM Customer来代表。因此，参与者ATM Customer是对一种用户类型的建模；单个的客户是该参与者的实例。
参与者常常是人类用户。因为这个原因，所以，在UML中，参与者都是用人性图标来表示的。在许多的信息系统中，人是唯一的参与者。但是在其他系统中，会有其他类型的参与者作为人类参与者的补充或者替代。
因此，参与者可能是一个和本系统通过接口连接的外部系统。在某些应用中，参与者还可以是外部输入输出（I/O）设备或计时器。外部I/O设备和计时器参与者在实时签入系统中是非常普遍的。在这些系统中，本系统通过传感器和执行器与外部环境进行交互。

主要参与者和次要参与者区别

主要参与者启动用例。因此，用例始于主要参与者的输入，系统必须相应主要参与者。
其他参与者称为次要参与者，可以参与到用例中。

一个用例中的主要参与者，可以是另一个用例中的次要参与者。
至少有一个参与者必须从用例中获得价值；通常，这就是主要参与者。

主要参与者和次要参与者的实例

主要参与者和次要参与者的实例如下图:

参与者“远程系统”（Remote System）启动“生成监控数据”（Generate Monitoring Data）用例，该用例中远程系统发送监控数据，向监控操作员显示。在该用例中，”远程系统”是主要参与者，它启动了用例；“监控操作员”（Monitorig Operator）是次要参与者，它接收监控数据，并因此从该用例中获得价值。

对参与者建模

人类参与者

人类参与者通常使用多种I/O设备与系统进行物理交互。人类参与者通过标准的I/O设备频繁地与系统交互，例如键盘、显示器或鼠标等。然而，在某些情况下，人类参与者也会通过非标准的I/O设备与系统交互，如各种各样的传感器。所有这些情况中，人是参与者，I/O设备不是参与者。因此，参与者是终端用户。
比如下面的例子

参与者是ATM客户，他通过多种的I/O设备与“银行系统”进行交互，包括了读卡器、吐钞机和凭条打印机，另外还有键盘和显示器。

外部系统参与者

参与者可以是外部系统参与者，或者启动（作为主要参与者）或者参与（次要参与者）用例。外部参与者的一个例子是“应急监控系统”中的“远程系统”。“远程系统”启动“生成监控数据”用例，如下面所示：

远程系统发送要显示给监控操作员的监控数据。

输入设备参与者（输入/输出设备参与者）

当用例中没有人的参与、向系统通过外部输入的参与者是输入设备或I/O设备时，这种情况就会发生。

典型地，输入设备参与者通过传感器与系统交互。输入设备参与者通过传感器与系统交互。输入设备参与者的一个例子是“监控传感器”（Monitoring Sensor），它为“生成警报”（Generate Alarm）用例提供传感器输入，如下所示：

“监控操作员”（Monitoring Operator）在该用例中也是次要参与者。

计时器参与者

参与者可以是计时器参与者，周期性地向系统发送定时事件。当系统需要定时地输出某些信息时，就需要周期性用例。

“报告计时器”（Report Timer）参与者启动“显示每日报告”（Display Daily Report）用例，该用例周期性地（比如，每天中午）准备一份每日报告，并将其显示给用户。如下图所示：

在这个例子中，计时器是主要参与者，用户是次要参与者。在计时器是主要参与者的用例中，通常是次要参与者(本例中的用户)从用例中获得价值。

注意

如果一个人类用户可能会扮演两个或两个以上的独立角色，则每个角色由不同的参与者来表示。
比如，同样的用户可能在不同的时间会扮演“ATM操作员”（ATM Operator）角色（当向ATM机现金吐钞中补充现金时）和“ATM客户”（ATM Customer）角色（当取现金时），于是会被建模成为两个参与者

参与者之间的泛化（继承）关系

在某些系统中，不同参与者可能拥有一些公共的角色，但其他的角色却不相同。在这种情况下，这些参与者都被泛化，使得他们角色中的公共部分部分能被捕获为泛化的参与者，而不同的部分则作为特化的参与者。
如下所示:

选取其中一部分

如何识别执行者？

执行者是指直接和系统交互的一类事物，执行者主要有如下三类：
(1) 直接使用系统的人，如使用一个库存管理系统的仓库管理员、仓储部经理等用户，仓库管理员可以通过系统进行入库和出库操作，仓储部经理可以通过系统查看各种报表，如库存报表、财务报表等；
(2) 与该系统相关的其他系统，如在库存管理系统中如果涉及到付款操作，需要使用另一个软件——支付系统，此时支付系统就是库存管理的执行者之一；
(3) 自动发生的事件，如时间、温度等自动事件，如果库存管理系统要求每晚零点执行一个数据汇总操作，此时时间就成为该操作的执行者。

思路

谁使用系统？
谁改变系统的数据？
谁从系统获取信息？
谁需要系统的支持以完成日常工作任务？
谁负责维护、管理并保持系统正常运行？
系统需要和哪些外部系统交互？
有没有自动发生的事件？

辨别谁是参与者

有时候并不能明确谁是参与者。实际上，最先的评估可能是不正确的。
例如，在报告失窃卡片的用例中，用户参与者电话告知银行他的ATM卡遭窃了。这看上去很明显客户是参与者，然而，如果客户实际上是通过电话向银行职员告知，而银行职员实际上将信息录入系统，那么银行职员才是参与者。
在比如在公交上上，乘客要订票上车。看上去是乘客订票，实际上操作者却是售票员，售票员与其售票系统进行交互。

接下来的文章会介绍如何识别用例，以及用例之间的关系，并配备实例进行一个建模过程的显示。（请期待~~）