用例图(用例图的组成要素)

上一篇中介绍了UML中的类图，本篇笔者将与大家介绍UML中的用例图的三个方面内容：用例（U Ca）; 参与者（Actor）; 参与者、用例之间的关系。

用例图（U Ca Diagrame）：描述了人们希望如何使用一个系统，将相关用户、用户需要系统提供的服务以及系统需要用户提供的服务更清晰的显示出来，以便使系统用户更容易理解这些元素的用途，也便于开发人员最终实现这些元素。

之所以说用例图至关重要，是由于用户并不关心系统的实现和内部结构，只关心产品所呈现出来的外部特征动态。而用例图恰好就是描述软件产品外部特性的视图，它从用户的角度而不是从开发者的角度来描述需求，分析产品的功能和动态行为。

用例图包括三方面内容：用例（U Ca）; 参与者（Actor）; 参与者、用例之间的关系。用例图模型如下图所示，参与者用人形图标显示，用例用椭圆形表示，连线描述之间的关系。

一、参与者（Actor）1. 概念

参与者是系统外部的一个实体，它以某种方式参与了用例的执行过程，在UML中，通常用名字写在下面的人形图标表示。

值得注意的是：参与者不一定是人，也可以是任何的事，通常可以将参与者分为以下三类：

1）真实的人，即用户

这一类是最常用的参与者，几乎在每个系统中。在命名这一类参与者时，应该按照业务而不是位置命名，因为一个人有可能有多重身份。

比如：汽车租赁公司的客户服务代表，通常情况下是客户服务代表，但在她有租赁行为时，就变成了客户。因此，按照业务而不是位置命名可以获得更加稳定的参与者。

2）其他的系统

在有的系统中，还需要建立与其他系统的接口，依然以汽车租赁系统为例，它可能要与外部应用程序建立练习，比如：说外部信用卡应用程序，这时候外部信用卡应用系统就是一个参与者。

3）可运行的进程

以时间为例，当经过一定时间触发系统中的某个时间时，时间就成了参与者。比如：在汽车租赁系统中，到了还车时间客户仍未归还，系统便会提醒客户代表致电客户。由于时间不再在人的控制内，因此它也是一个参与者。

2. 参与者间的关系

对于一些参与者来说，它既扮演者自己的角色，同时也扮演更一般的角色，在案例图中用泛化关系来描述他们（此点与上一节类图中介绍的泛化关系类似）。

假设汽车租赁系统可以接受客户的电话预定和网上预订，那么参与者“客户”就描述了参与者“电话客户”和“网上用户”所扮演的一般角色。泛化关系与类图一样都使用一个空心三角箭头表示，指向扮演一般角色的超类。

在确定参与者当中，如果不考虑客户是如何与系统接触的，就使用一般角色参与者，即父类；如果强调接触发生的形式，则必须采用实际的参与者，即子类。

二、用例（U Ca）1. 概念

用例：是对系统的用户需求（主要是功能需求）的描述，用例表达了系统的功能和所提供的服务，描述了活动者与系统交互中的对话。

以汽车租赁系统为例，客户向系统发出租赁请求，并向系统中输入数据（姓名等信息），系统响应活动者的请求，进行相应的处理，并且将结果返回活动者。

每个用例都必须有一个唯一的名字以示区别，用例名字是一个字符串，包括简单名（simple）和路径名（path name），这和类图中的类名是相同的。

左图：简单名/右图：路径名

2. 用例与事件流

用例分析处于系统的需求分析阶段，这个阶段尽量避免考虑系统实现的细节问题。但若要建立系统还需要更加具体的细节，这些细节可以写在事件流中。

事件流描述的是一个系统做什么，而不是怎么做，举个栗子，在汽车租赁系统中用例“用户登录”可以采取一下方法：

主事件流：客户输入自己的用户名和密码时，用户开始。输入的用户名和密码被提交后，服务器判断密码是否正确。如果正确，则用户成功登录，系统为其展示租赁页面。异常事件流：用户用户名或密码错误，不能登录，用例重新开始。异常事件流：在提交密码前，用户清楚用户名或密码，重新填写。三、参与者、用例之间的关系1. 关联关系

这是最常使用的关系，用带箭头的实线来描述。以汽车租赁系统中的“客户”参与这以及和他交互的3个用例（预定、取车和换车）为例。

2. 泛化关系（Generalization）

一个用例可以被列举为多个子用例，这就被成为用例泛化，这与类间的泛化关系类似。在用例泛化中，子用例表示父用例的特殊形式，可从父用例处继承行为和属性。泛化关系的图形用空心实线箭头表示，箭头指向父类。

如下图所示是汽车租赁公司用例图中的用例“预定汽车”，该用例有两个子用例“预定大巴中巴”和“预订小车”。

3. 包含关系（Include）

包含：指的是其中一个用例（称为基础用例）的行为包含了另一个用例（称为包含用例）。

基础用例包含用例并依赖包含用例的执行结果。但是二者不能访问对方的属性。包含关系的图形为虚线箭头加<<include>>，箭头指向包含用例。

再举个栗子：仍然是汽车租赁系统，客户无论是预定、取车还是还车，都需要用户登录，所有此时使用例“登录”被用例“预定”、“取车”和“还车”所包含，这样就能避免许多重复的动作。

4. 扩展关系（Extend）

扩展用例可以被定义为：基础用例的增量扩展，它俩之间为扩展关系。

简单来说，就是当某特定条件出现时，该扩展用例的行为才会被执行。扩展关系的图形为虚线箭头加上<<<exclude>>>，箭头指向基础用例。

如下图，客户在还车超过了一定期限就需要缴纳罚款，其中“借车超期”为特定条件，只有该条件出现，才执行“缴纳罚款”用例行为，“还车”用例和“缴纳罚款”之间就是扩展关系。

四、练习：QQ音乐用户及其相关用例（简易版）其中参与者【用户】可以泛化为QQ用户与微信用户。【建立歌曲列表】用例包含了【听歌】和【登录】用例，因为必须要先登录才能在听歌页面添加到歌曲列表中。在【听歌】用例中，有1个扩展点，是有的收费歌曲需要购买才能收听，其中歌曲收费为特定条件。相关阅读

《产品经理必学UML（一）：类图》

本文由 @AugTalk 原创发布于人人都是产品经理，未经许可，禁止转载。

题图来自Unsplash，基于CC0协议。