UML在信息系统需求分析模型中的应用

 

　　在软件工程中，需求分析指的是在建立一个新的或改变一个现存的电脑系统时描写新系统的目的、范围、定义和功能时所要做的所有的工作。需求分析是软件工程中的一个关键过程。在这个过程中，系统分析员和软件工程师确定顾客的需要。只有在确定了这些需要后他们才能够分析和寻求新系统的解决方法。在软件工程的历史中，很长时间里人们一直认为需求分析是整个软件工程中简单的一个步骤，但在过去十年中越来越多的人认识到它是整个过程中关键的一个过程。假如在需求分析时分析者们未能正确地认识到顾客的需要的话，那么的软件实际上不可能达到顾客的需要，或者软件无法在规定的时间里完工。

　　1 UML概述

　　统一建模语言 （UML）是非的第三代建模和规约语言。 UML是在开发阶段，说明，可视化，构建和书写一个面向对象软件密集系统的制品的开放方法。UML展现了一系列工程实践，这些实践在对大规模，复杂系统进行建模方面，特别是在软件架构层次已经被验证有效。UML可以贯穿软件开发周期中的每一个阶段。被OMG采纳作为业界的标准。UML适于数据建模，业务建模，对象建模，组件建模。UML作为一种模型语言，它使开发人员专注于建立产品的模型和结构，而不是选用什么程序语言和算法实现。当模型建立之后，模型可以被UML工具转化成指定的程序语言代码。IBM的Rational Rose和MS的Visio都是UML工具。

　　面向对象技术和UML的发展过程可用图形来表示，标准建模语言的出现是其重要成果。在美国，截止1996年10月，UML获得了工业界、科技界和应用界的广泛支持，已有700多个公司表示支持采用UML作为建模语言。1996年底，UML已稳占面向对象技术市场的85%,成为可视化建模语言事实上的工业标准。1997年11月17日，OMG采纳UML 1.1作为基于面向对象技术的标准建模语言。UML代表了面向对象方法的软件开发技术的发展方向，具有巨大的市场前景，也具有重大的经济价值和国防价值。UML是一个标准的图形表示法，它不是面向对象的分析和设计，也不是一种方法，它仅仅是一组符号而已。

　　2 常用需求分析方法及其不足

　　信息系统实质上是实际业务系统的一种计算机模型，因此，信息系统的开发实质上就是要建立业务模型与计算机模型系统之间的映射关系[5].一个综合性的信息系统要支持组织内各级多个部门的管理，结构复杂、规模庞大。因此，要想开发出一套高效的系统，首先要进行系统的需求分析，根据需求过程中工作性质的不同，信息系统需求分析可分为问题识别、分析与综合、编制需求分析文档、需求评审四个阶段。

　　但是，在实际需求分析过程中，由于信息系统所涉及的信息量非常庞大，以致在需求定义中常常忽略某个环节或环节间的必要联系，从而出现产品质量低下、开发周期漫长或遗漏关键功能等问题[6].

　　目前比较常用的需求分析方法主要有数据流分析法、原型分析法和基于用例的分析法三种。

　　（1）数据流分析法（DFA）

　　数据流分析是建立系统模型的一种主要需求分析方法，它采用分解的策略，将软件系统抽象为一系列的逻辑加工单元，单元接收输入数据流，加工后使之变换成输出数据流，从而表示出软件系统的处理内容和任务。但是随着信息技术的发展和企业业务过程的日益庞大复杂，信息系统复杂多变，易出错，难维护。

　　（2）原型分析法

　　原型法是指在系统尚不完善时就呈现给用户，不断修改改善，在完善过程中逐渐了解需求，但原型法也存在如下缺陷[7]:①原型的设计和修改工作量大，增加了系统的开发成本；②由于用户不关心或不理解原型的概念和实现，而且存在较大期望，使得与实际系统差别较大的原型增加了需求分析人员与用户交流的难度[3].

　　（3）基于用例（Use Case）的需求分析法

　　用例本质上是用户与系统之间为达到某个目的而进行的某种形式的交互的描述。但是，以用例为中心，从用例开始的需求分析存在如下缺陷：①对于划分Use Case的粒度大小、Use Case的分类、Use Case的提取还没有一个特定的标准和较好的方法，完全由需求分析人员凭经验来掌握，这样很容易造成系统分析的失误；②对于大规模信息系统，Use Case的定义、分析、审查需要花费大量成本，而且不恰当地选择Use Case往往给识别系统中的对象带来困难，导致系统的对象结构设计不合理，影响系统功能。

　　3 基于UML的信息系统需求分析模型

　　针对上述常用需求分析方法存在的不足，UML作为一种强大的图形化建模语言，是理想的需求描述和建模分析工具，它对信息系统的大规模、复杂、不断变化的用户需求有很强的控制力，为解决人员交流和通信障碍提供了有力的工具[8].

　　基于UML的信息系统需求分析模型，不从用例开始进行需求分析，而从业务流程分析开始，从静态和动态两个方面对系统的需求建模，该模型如图1所示。

　　（1）相关人员培训：该模型涉及三类人员：领域、用户代表、需求分析员。通常情况下，领域和用户代表缺少计算机方面的知识，不精通需求分析及建模技术；需求分析员又缺少用户的业务知识，不熟悉其业务流程，因此，在需求分析前，对领域和用户代表进行UML知识的培训，使其了解各种视图的含义；对需求分析员进行业务知识的培训，使其对该领域中的一些基本知识和常用术语等有所了解[9].

　　（2）初始需求的捕获：通过调研和建立联合分析小组等方式，了解用户的业务流程，进而获取用户对系统的初需求，并用UML活动图对以用户业务流程为的初始用户需求进行描述[10].

　　（3）用例模型的创建：分析步骤（2）所得活动图中每个活动的参与者，找出该活动中与之相对应的动作，二者形成一个用例。通过确定系统边界和分析活动的转移，删除多余的用例，合并相同的用例，填补遗漏的用例；采用活动图的泳道技术对用例进行集成，形成一个完整的用例模型。

　　（4）动态模型、静态模型的创建：分析步骤（2）所得活动图中每个活动所涉及到的对象及对象之间的关系，根据活动的改变而引起对象状态的变化和对象的交互，创建相应的对象图、状态图和交互图（顺序图、协作图）；应用顺序图对步骤（2）所得活动图中的每个活动进行分析，发掘新的需求，完善描述初始用户需求的活动图；通过顺序图对步骤（3）所得用例模型中的每个用例进行处理，创建相应的类图。

　　4 基于UML的信息系统需求分析模型的应用

　　基于UML的信息系统需求分析模型对MIS系统的开发具有较好的适应性，结合具体实践，本节以运动会信息管理系统的开发为例，说明该模型在MIS系统开发中的应用[11].

　　（1）捕获初始需求：通过大量调研，给出该系统的初始需求描述：运动会信息管理系统要实现运动员报名、各类人数统计、竞赛日程设定、初秩序册生成、检录和成绩处理、新秩序册生成、团体分统计、破纪录人数统计等功能。该系统的活动图模型如图2所示。

　　（2）创建用例模型：通过对图2中每个活动的参与者的分析，所获得运动会信息管理系统的完整用例模型如图3所示。

　　（3）创建动态模型、静态模型：通过对图2中"比赛成绩处理"活动所涉及到的对象、对象之间的关系分析，获取的比赛成绩处理顺序图如图4所示，其他活动顺序图的获取与此类似。

　　基于UML的需求分析模型以简单的图形建模语言UML为基础，为人员交流提供了统一的平台，消除了语言理解分歧；该模型涵盖了领域知识学习、建模方法培训、系统需求分析构造等环节，并从实施的角度考虑了角色构成及其职责分配，使各类人员能够更好地交流与合作，为得到完善的需求分析打下了坚实的基础。通过MIS的开发实践表明，该模型不但能缩短软件开发的周期，而且减少了软件开发的风险，有效提高了开发软件的质量。