再学UML-UML用例建模解析（三）

2. 编写用例文档

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

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

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

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

　　涉众利益是对用例执行过程和结果很关心但不直接操作用例的人，如仓库管理员在入库和出库时，虽然经理不直接入库，但是他们对这个过程和结果很关心；如在火车站买票时，直接使用售票系统的是售票员，但是乘客很关心用例的执行结果，担心是否会弄错时间和车次，因此乘客是涉众。执行者是直接执行用例的人，他们通过用例来直接执行系统提供的功能；涉众是执行者操作用例时的观众，他们对用例的执行过程和结果很关心，因为涉及到他们的利益。

　　路径又称为“流程”，是指执行者和系统交互的过程。用例文档中最关键的部分是基本路径，基本路径又称为“正常路径”或者“开心路径”，它是用户最想看到、也最关心的路径，是用例建模核心中的核心。在路径中包含若干步骤，这些步骤构成了一个完整的交互过程，在描述基本路径时，每一个步骤一般以执行者或者系统作为主语，如“仓库管理员输入待入库商品信息”，“系统验证该商品库存是否达到上限”等。在编写路径时需要注意以下几个问题：

　　(1) 需要对步骤进行编号，一般用阿拉伯数字1、2、3、…进行编号，表示步骤的先后次序。

　　(2) 不能出现专业术语，因为用例文档需要系统的客户和用户都能够看懂，因此不能出现诸如“JDBC”、“SQL”这样的专业术语。

　　(3) 尽量使用主动语句，每一个步骤均以执行者或系统作为主语。

　　(4) 不要涉及到界面细节，如不能出现“仓库管理员在文本框中输入帐号”、“仓库管理员在密码框中输入密码”等句子，应该使用“仓库管理员输入帐号和密码”来代替。

　　(5) 如果出现大量数据输入或处理，需要将数据放入“字段列表”中，如系统管理员在增加员工信息时，需要增加员工帐号、员工密码、员工所在部门、员工电话、员工邮箱等信息，可以在用例文档中使用“系统管理员输入员工信息”来代替，而对于“员工信息”的详细描述可以放在用例文档的“字段列表”中进行详细说明。

　　(6) 注意分支和循环的处理，在用例文档中，分支可放在接下来要介绍的扩展流程中；而循环可以直接放在步骤描述中，如在入库时可以一次入库多个商品的资料，中间某些步骤如下：“2. 仓库管理员输入待入库商品信息；3. 系统验证该商品库存是否达到上限；4. 系统提示该商品入库信息增加成功；”，如果需要重复这几步，可以在基本路径中用如下语句描述：“如果还有商品需要入库，重复第2-4步”。

 　　基本路径是用例文档的核心，通过路径可以清楚了解执行者如何通过用例来实现相应的功能，因此，在编写用例文档时，需要认真细致编写基本路径，确保非专业人员都能够在读完基本路径后理解执行者和系统的交互过程。

　　除了基本路径之外，很多用例都存在一些替换路径和异常路径，通常可以将替换路径和异常路径统称为扩展路径。识别出一个用例的基本路径并不难，但是要找到所有的扩展路径是件很辛苦的工作。一个优秀的系统分析人员应该认真分析业务流程，试图寻找出在基本路径中每一个步骤可能存在的扩展方式，寻找出所有可能的扩展路径。如仓库管理员在入库时可能会发生一些异常情况，如“供应商不存在”、“待入库商品不存在”、“入库时商品超过库存上限”等，需要使用扩展路径对这些情况进行清晰的描述，如“供应商不存在”，则需要设置一个扩展点，先执行“增加供应商信息”用例，再选择供应商编号，在扩展流程中可以这样表示：“1a. 供应商不存在  1. 扩展点1：执行用例——StockUC003增加供应商信息；2. 仓库管理员选择供应商编号。”。在这里需要注意扩展路径的编号，如果是基本路径中步骤1的扩展路径，可以使用1a、1b、1c等方式表示，然后对于扩展出来的子路径再用1、2、3、…进行编号，其中在该子路径的第1步指明这是一个扩展点，该扩展点名为“扩展点1”，在此时需要执行另一个用例StockUC003“增加供应商信息”，则用例“入库”和用例“增加供应商信息”之间是扩展关系，“增加供应商信息”是对“入库”操作的扩展。如果没有扩展点则直接书写步骤，与基本路径步骤写法一致。

　　字段列表、业务规则、非功能需求和设计约束是对用例的补充描述，字段列表中包含某些步骤所涉及到的一些数据字段，如在“增加商品信息”用例中可以在其“字段列表”中详细列出商品信息的内容，如“商品信息包括：商品编号，商品名称，商品型号，商品类别，商品单价，商品数量，库存上限，库存下限”，“字段列表”为后续的数据库设计工作提供了极大的帮助；业务规则用于描述在步骤中执行者或系统在执行某些操作时需要满足的条件，如在“增加商品信息”用例中，其“业务规则”包括“商品编号不能为空，商品数量必须是大于等于0的整数，库存下限必须低于库存上限”等；非功能需求用于描述用例在可靠性、安全性、可用性、移植性等方面的一些要求，如“系统响应时间不能超过30秒”、“可以支持同时100个用户在线访问”等；设计约束是指设计过程中存在的一些待解决的问题，如“商品编号的编码问题”、“如何快速输入商品编号”等。

　　在实际软件开发过程中，用例编号、用例名、执行者、前置条件、后置条件和基本路径是一个用例必不可少的组成部分，其他部分可根据实际情况确定，可有可无。下面提供库存管理系统中“入库”用例的用例文档，以供参考：

　　总之，用例建模包括用例图的绘制和用例文档的编写，其核心在于编写用例文档。用例建模是软件需求分析到最终实现的第一步，它从用户的角度来描述软件系统的功能，描述人们如何使用软件系统。构造意义明确、格式规范的用例模型是软件成功的第一步，希望大家在每个软件项目的开发过程中都能够认真、细致地进行用例建模，为顺利完成项目开发任务奠定坚实的基础。

文章出处：http://blog.csdn.net/lovelion/article/details/6226377