UML在设备大小修文件包系统需求分析中的应用(1)

需求分析的目的是建立可理解的现实世界模型，基本任务是准确地回答“系统必须做什么”的问题，是软件生命周期中最重要的一个阶段。本文使用标准建模语言UML（Unified Modeling Language）对设备大小修文件包系统需求分析阶段建模，可以准确、透彻地理解系统要完成的功能。

1  需求分析的重要性

在软件工程的历史中，很长一段时间人们一直认为需求分析是整个软件工程中最简单的一个步骤，但在过去十年中，越来越多的人认识到它的重要性。

由于人们过去对需求分析缺乏重视，以下情况可能出现：需求结果不能准确反映用户实际要求，遗漏系统关键功能，直接影响后面各个阶段设计的合理和实用性；软件尚未交付，需求已经变更；项目组不断返工，交付推迟。由于需求分析不当，可能会导致开发周期延长，费用增加，产品质量下降，信誉受损等后果。

国外著名公司，如IBM和HP等公司，曾对公司内部的软件开发进行研究发现，如果把编码阶段发现和修复一个错误所需要的努力用1个成本单元来表示的话，那么需求阶段的错误修复成本是它的5-10倍，在维护阶段修正由于需求阶段产生的错误所花费的成本将是200倍。

2  UML需求建模

随着人们对需求分析越来越重视，需求分析所遇到的问题也越来越清晰化。目前，需求分析阶段遇到的两个主要问题是：用户刚开始提出的需要不完全，考虑欠妥，太乐观；使用复杂的工具和不同的技术进行需求分析会打消获得一个完整的和细致的结果的希望。采用UML进行需求分析，可以充分解决以上两大问题。

UML是为了解决由于纷繁芜杂的建模工具的出现，给软件开发人员技术交流造成很大困扰的问题，由美国rational软件公司G Booch、J Rumbaugh和I Jacobson三位面向对象大师在1996年共同提出。经过短短几年的发展，已成为在软件工程中占有支配地位的建模语言。它可运用于信息系统、控制系统、实时系统、分布式系统等不同类型的多个领域中，最近几年还被应用于软件再生工程、质量管理、过程管理、配置管理等方面，已成了业界事实上的统一建模语言。

UML在需求分析阶段建模基本步骤如下：

（1）获取用户需求         

由系统分析员和客户或客户指定的具有业务知识的人面谈，捕获业务目标，熟悉业务活动，识别协作系统，了解系统领域专业词汇，建立相应的记录文档或系统活动图。

（2）建立用例图（use case） 

在获取用户需求后，定义系统的角色，划分用例，建立用例图。角色是指与系统打交道的参与者，可以是人或其他系统。用例指系统内部功能单元。用例图是由角色、用例及二者之间的关系组成，用例和用例之间存在扩展、包括和使用关系。在系统分析时，可能对有些用例还可以进行细分。

（3）编写用例说明          

除建立用例图外，对每个用例还应进行描述，编写用例说明文档。对每一个用例应说明的基本内容是：用例怎样开始和结束、正常的事件流、变通的事件流、意外情况的事件流等。

（4）建立用例行为图       

对重要用例可建立用例活动图或顺序图，详细阐述业务流程。

完成上述步骤后，由系统分析员再与用户反复协商，不断修改完善，最终对需求达成共识可见。可见需求产物是系统分析员与用户反复讨论的产物，这也正体现了UML建模过程反复迭代的特点。需求分析的基本步骤如下图1所示。

图1：需求分析步骤

3  利用UML进行需求分析

3.1  获取用户需求

设备大小修文件包系统是为完善设备的大小修过程的设备管理和施工技术管理而建立的管理文件系统[5]。开发此系统的主要目的是辅助维修管理人员完成文件包的信息化入库，方便部门人员的查询打印，为维修提供技术支持；有效监控检修流程，记录分析维修结果，使设备检修工作处于有序和受控状态，提高维修质量和效率。在满足功能实现基础上，该系统主要由2个子系统组成：文件包管理子系统和大小修过程管理子系统。

文件包管理子系统实现文件包的建库和管理。包括文件包的精心编制，主管部门的校对、审批，最终生成有效文件投入使用；文件包的修编更新，补充完善。

大小修过程管理子系统实现检修工程进度和质量的监控及信息记录管理。根据文件包指定的工序要求，设定质量控制点，通过实行相关责任人的签点机制，比较监督数据，进行工程结果评估。

Q4w CAMM Stock管理系统为厂内已有的系统，负责提供设备的基本信息，被确认为协作系统。下面以文件包管理子系统为例进行分析。

3.2 建立用例图

图2：文件包生命周期管理用例图