深入理解用例建模

UML用例建模解析

刘伟

UML（统一建模语言）是当前软件开发中使用最为广泛的建模技术之一，通过使用UML 可以构造软件系统的需求模型（用例模型）、静态模型、动态模型和架构模型。UML通过图形和文字符号来描述一个系统，它是绘制软件蓝图的标准语言。熟练掌握UML建模技术是一个优秀的软件从业人员所必备的基本技能之一，越来越多的软件企业在招聘中也需要应聘者具备一定的UML知识基础和实践经验。

作为UML的初学者，很多人也在尝试使用UML中的图形来描述一个软件系统，构造一个软件系统的蓝图。然而，在使用UML的过程中，一部分人并没有深入理解这些图的作用，以及这些图在绘制过程中的一些技巧。我将陆续通过几篇文章来帮助大家更快更好地学习UML，在软件项目中合理使用UML来提高软件开发效率并规范软件开发流程。

在本文中我将结合库存管理系统来深入浅出地讲述UML建模中的第一个模型——需求模型的构造，即用例建模，包括如何绘制规范的用例图、如何编写简洁而又清晰的用例文档、以及怎样通过用例图和用例文档来构造软件系统的需求模型。

在UML中，需求模型又称为用例模型，它主要用于描述系统的功能性需求，即软件可以实现的功能，如登录、注册、入库、出库、查看库存报表、增加员工信息等。常规的用例建模一般包括两个组成部分：绘制用例图和编写用例文档。

1. 绘制用例图

用例图是UML中比较简单的一种图形，它包含两个主要组成元素，分别是执行者(Actor)和用例(Use Case)。执行者又称为参与者或角色，用例又称为用况或案例。在用例图中，执行者用一个“小人”符号表示，用例用一个“椭圆”符号表示，因此用例图又有一个名字为“小人椭圆图”。最简单的用例图如下：

入库

仓库管理员

在该用例图中，“仓库管理员”表示执行者，“入库”表示一个用例，即系统的一个功能。

执行者是指直接和系统交互的一类事物，执行者主要有如下三类：

(1) 直接使用系统的人，如使用一个库存管理系统的仓库管理员、仓储部经理等用户，仓库管理员可以通过系统进行入库和出库操作，仓储部经理可以通过系统查看各种报表，如库存报表、财务报表等；

(2) 与该系统相关的其他系统，如在库存管理系统中如果涉及到付款操作，需要使用另一个软件——支付系统，此时支付系统就是库存管理的执行者之一；

(3) 自动发生的事件，如时间、温度等自动事件，如果库存管理系统要求每晚零点执行一个数据汇总操作，此时时间就成为该操作的执行者。

识别一个系统的执行者是用例建模的第一步，在识别出一个系统的执行者后，需要寻找系统的用例，即功能需求。用例是执行者对系统操作的一个动作序列，每一个用例对应执行者对系统的一个完整操作流程。如库存管理系统中，仓库管理员可以登录系统，可以进行入库、出库等操作，在这里登录、入库、出库都是用例，它们都对应系统所提供的一个功能。

执行者通过执行用例来完成相应的工作。用例体现了执行者和软件系统的交互过程，因此只用一个简单的“椭圆”来表示用例太过简单，对于每一个用例，需要编写一个详细的用例文档，在下一节将介绍如何编写用例文档。

在找出执行者和用例之后，下一步就是用例图的绘制了，这个过程看似简单，实际上要绘制出一个规范、标准、可读性强的用例图并不是件很容易的事情。绘制用例图的关键在于理清各种图符之间的关系，包括执行者与用例之间的关系、执行者之间的关系以及用例之间的关系。

(1) 关联关系

关联关系是指执行者与用例之间的关系，又称为通信关系，如果某个执行者可以对某个用例进行操作，它们之间就具有关联关系，如下图所示，“经理”有一个功能为“查看库存报表”，因此可以在执行者“经理”和用例“查看库存报表”之间建立一个关联关系，关联关系用实线表示。

查看库存报表

经理

(2) 泛化关系

执行者之间的关系只有一种，即泛化关系，用一个带有空心三角形的实线表示，如下图所示，在该图中，仓库管理员、系统管理员、经理都是员工的一种，因此员工拥有的功能这三者都拥有，如登录、修改个人信息等，为了减少用例的个数并且使系统更加符合面向对象设计规范，可以对执行者进行泛化，将各类执行者都具有相同的功能移至父执行者，而将每类执行者特有的功能保留在子执行者中。

修改个人信息

登录

入库增加员工信息查看库存报表

常见的用例之间的关系有两种，分别是包含关系和扩展关系，下面介绍这两种关系的含义以及在用例图中如何表示。

(3) 包含关系

如果多个用例都具有一部分相同的行为，可以将这部分相同的行为作为一个单独的用例抽取出来，与原来的用例形成一个包含关系。如仓库管理员在进行入库、出库等操作之前需要先登录，登录是入库、出库流程的基本组成部分，因此用例“入库”和“出库”包含用例“登录”。为了更加清晰地描述多个用例的相同行为，在用例图中提供了用例与用例之间的包含关系。

在UML中，包含关系用依赖线（虚线）加一个<>表示，由原始用例指向包含

用例，如下图所示：

<>

<>仓库管理员

入库

出库

登录

(4) 扩展关系

扩展关系又称为延伸关系，如果一个用例在执行时可能会使用到另一个用例，或者使用一个新的用例对原有用例的行为进行扩展时可以使用扩展关系，

如仓库管理员在入库时发现某种商品在系统中暂不存在，则可以增加新的商品信息；如果入库商品均已存在，则无需增加商品信息，此时用例“增加商品信息”可以作为用例“入库”的扩展用例。在需要扩展的用例（原始用例）中需指定一个扩展点（即需扩展的位置），在下一节编写用例文档中将学习如何设置扩展点。 在UML 中，包含关系用依赖线（虚线）加一个<>表示，由扩展用例指向原始用例，如下图所示：

<>入库

增加商品信息

关于包含关系和扩展关系箭头的指向，可以记住两句口诀：包含进来，箭头向外；扩展出去，箭头向里。

除了上述的包含关系和扩展关系外，用例之间还存在一种与执行者泛化类似的泛化关系，但不太常见，在这里不予以详细介绍。

2. 编写用例文档

绘制用例图只是完成了用例建模最基本也是最简单的一步，用例建模的核心在于编写用例文档，用例文档又称为用例规约或用例描述。顾名思义，用例文档是用于描述用例的文档，每一个用例对应于一个用例文档，在用例文档中需要用文字的方式描述用例的执行过程，即执行者与系统的交互过程。

用例文档需要通俗易懂，不仅项目的开发人员能够理解，系统的用户以及客户也能够看懂用例文档。一个完整的用例文档包括用例编号、用例名、执行者、前置条件、后置条件、涉众利益、基本路径、扩展路径、字段列表、业务规则、非功能需求和设计约束等组成部分。

一般在系统中需要给所有的用例一个统一规范的编号，如库存管理系统，可以使用StockUC001、StockUC002等来对用例进行编号。每一个用例都需要提供一个清晰易懂的用例名，一般使用“动词+名词”的形式，如“查看库存报表”、“增加员工信息”、“增加商品信息”等，对于一些俗语可以使用简写，如“登录”、“注册”、“入库”、“出库”等。

前置条件是用例执行之前系统所处的状态，它必须是软件系统可以识别到的状态，如用例“入库”的前置条件是“仓库管理员已成功登录”，而不能是“仓库管理员已打开电脑”，因为是否“打开电脑”库存管理系统不能识别到；后置条件是用例执行之后系统应该具备的状态，它也必须是系统能够识别到的，如用例“入库”的后置条件是“系统保存入库信息，