UML建模图文详解教程02——用例图

---

版权声明

• 本文原创作者：谷哥的小弟
• 作者博客地址：http://blog.csdn.net/lfdfhl
• 本文参考资料：《UML面向对象分析、建模与设计（第2版）》吕云翔，赵天宇 著

---

用例图概述

用例图(use case diagram)是表示一个系统中用例与参与者之间关系的图。它描述了系统中相关的用户和系统对不同用户提供的功能和服务。用例图是 UML 中对系统的动态方面建模的五种图之一(其他四种是活动图、状态机图、顺序图和通信图)，它是对系统、子系统和类的行为进行建模的核心。

用例图中的主要元素包括参与者、用例以及元素之间的关系。

用例图核心知识

请务必熟悉并掌握以下核心知识点。

参与者

参与者(actor,也被译为执行者),是与系统主体交互的外部实体的类元，描述了一个或一组与系统产生交互的外部用户或外部事物。参与者以某种方式参与系统中一个或一组用例的执行。

著名的 计算机科学家 Martin Fowler 认为,参与者(actor)这一词汇是源于瑞典语的误译，更适合的术语应该是角色(role)。

参与者表示方式如下：

用例

用例(use case,又被译作用况)是类元(一般是系统、子系统或类)提供的一个内聚的功能单元，表明系统与一个或多个参与者之间信息交换的顺序，也表明了系统执行的动作。

简单来说，用例就是某一个参与者在系统中做某件事从开始到结束的一系列活动的集合，以及结束时应该返回的可观测、有意义的结果。举例来说，在某图书管理系统中会员的借书行为就可以视作一个用例。借书用例的参与者是会员，用例从会员来到服务台请求借书开始到会员借书成功或失败为止。

在UML中用例用一个包含名称的椭圆形来表示。

用例图中的关系

在此，介绍 用例图中常见的关系。

参与者间的泛化关系

对参与者建立泛化关系可将这些具有共同行为的一般角色抽象为父参与者。子参与者则可以继承父参与者的行为和含义并能拥有自己特有的行为和含义。

参与者间的泛化关系表示方法：一条实线 + 空心箭头。其中，空心箭头指向父参与者。

例如：付费会员拥有普通会员的权限也拥有一些普通会员没有权限的操作，因此二者之间可以建立泛化关系。

例如：客户这一参与者是抽象的，它有三个子参与者：直接客户、电话客户和网上客户，因此他们之间可以建立泛化关系。

类似地，用例间也有泛化关系。例如：评价教职工与评价教师、评价清洁工人也构成泛化关系。

用例间的包含关系

包含指的是一个用例(基用例)可以包含其他用例(包含用例)具有的行为，其中包含用中定义的行为将被插入基用例定义的行为中。

用例间的包含关系表示方法：一条虚线+实心箭头并附加上<< include >>；箭头从基用例指向包含用例。即谁包含了谁，那么箭头就从谁指向谁。

例如，在某个在线交易系统的用例图中用户创建订单的行为一定需要包括选择商品的行为序列，且创建订单的行为依赖于选择商品的结果。因此二者之间构成包含关系。

用例间的扩展关系

扩展指的是一个用例(扩展用例)对另一个用例(基用例)行为的增强。

用例间的扩展关系表示方法：一条虚线+实心箭头并附加上<< extend>>；箭头从扩展用例指向基用例。即谁扩展了谁，那么箭头就从谁指向谁。

例如，对于系统的“注册”用例而言，用户可以填写实名信息从而获得系统较高的信任等级。这就需要引人一个“检查实名信息”的用例。这一用例对于每个注册用例的实例而言不是必需的。而且，注册用例本身对于检查实名信息的存在是不知情的，即它不需要检查实名信息的结果就可以继续执行。因此二者之间构成扩展关系。

航空购票系统简介

航空购票系统（Airline Ticketing System；简称ATS）是亚太航空公司推出的一款网上购票系统。从本节教程开始，我们将以该项目作为演示案例讲解UML软件建模的方法。

首先，我们在EA中创建该项目。

单击文件选择新建项目，图示如下：

填写文件名并选择存储位置，图示如下：

选择不选再单击确定，图示如下：

项目创建完毕，图示如下：

至此，项目创建完毕。

航空购票系统用例图

在该系统中，未登录的用户只能查询航班信息，已登录的用户还可以网上购买机票，查看行程，也可以退订机票。系统管理员可以安排系统中的航班信息。此外，该购票系统还与外部的一个信用评价系统有交互。当某用户一个月之内退订两次及以上的机票时需要降低该用户在信用评价系统中的信用等级当信用等级过低时不允许该用户再次购买机票。

确定参与者

在了解完系统语境后，首先应该分析确定系统中的参与者。根据系统的背景说明，我们可以分析出需要订票的用户肯定要参与其中，并且用户根据是否已登录有不同的系统使用权限。负责安排航班信息的管理员和与系统产生交互的外部信用评价系统也应该属于系统的参与者。

通过以上分析可以得出，系统主要有三类参与者,分别是用户、管理员与信用评价系统。其中，用户包括游客与注册用户表示为参与者的泛化关系。由于用户一定属于二者其中之一故用户应该是一个抽象参与者。

请在项目中右键单击Model选择增加再单击新建增图，然后选择用例图；图示如下：

创建完毕，图示如下：

右键单击用例图选择添加图再选择UML Behavioral，图示如下：

创建完毕，图示如下：

点击左上角的箭头，打开工具箱；图示如下：

拖动工具箱至项目浏览器底部，图示如下：

左键单击Actor，鼠标挪动至绘图区后松开左键；填写参与者名字；最后单击确定；图示如下：

第一个参与者绘制完毕，图示如下：

重复刚才的操作完成其它参与者即游客、注册用户、管理员、用户评价系统；图示如下：

利用Use Case Relationships表示游客与用户的泛化关系；图示如下：

类似地，表示注册用户与用户的泛化关系；图示如下：

确定用例

分析出系统中的参与者之后就可以通过分析每个参与者是如何使用系统确定系统中的用例。在本系统中游客可以注册系统和查询航班信息；注册用户可以登录系统、查询航班信息、购买机票、查看行程和退订机票；管理员可以登录系统和设定航班安排；信用评价系统可以修改和检查信用等级。需要注意的是，修改和检查信用等级的用例并非是由信用评价系统主动触发的，信用评价系统对这两个用例而言只是副参与者。

左键单击Use Case，鼠标挪动至绘图区后松开左键；填写用例名称；最后单击确定；图示如下：

第一个用例绘制完毕，图示如下：

利用Use Case Relationships表示游客与注册的关联关系；图示如下：

选中关联关系在高级中选择改变方向再选择起始–>目标；图示如下：

类似地，绘制其它用例；图示如下：

确定用例之间的关系

在确定完所有用例之后,需要具体考虑各个用例的工作流程从而添加用例之间的依赖关系以此保证模型的高内聚与低耦合。对于机票预订系统，我们注意到“购买机票”用例在执行时需要先查询相关的航班信息然后再选择感兴趣的航班购票并且在购票前需要检查该用户的信用等级是否足够高。因此该用例与“查询航班”用例和“检查信用等级”用例之间可以分别建立包含关系。此外，在退订机票时，如果这是该用户本月第二次以上的退订，那么需要降低该用户的信用等级。由于这一关系是有条件的，所以二者构成扩展关系。

添加包含关系；图示如下：

添加扩展关系；图示如下：

至此，我们完成了项目的用例图；图示如下：

扩展实践练习

请完成图书管理系统的用例图，图示如下：