对于大中型信息系统，很难直接进行需求分析设计，需要借助模型来分析设计系统，根据系统调研数据，建立起目标系统的逻辑模型。

在软件工程的历史中，很长时间里人们一直认为需求分析是整个软件工程中最简单的一个步骤，但在过去十年中越来越多的人认识到它是整个过程中最为关键的一个过程。假如在需求分析时分析者们未能正确地认识到客户的需求的话，那么最后的软件实际上不可能达到客户的要求，或者导致需求的频繁变更，而软件无法在规定的时间里完工。

在需求分析阶段，要对经过可行性分析所确定的系统目标和功能作进一步的详细论述，确定系统“做什么？”的问题，最终建立起目标系统的逻辑模型。

首先是获得当前系统的物理模型。物理模型是对当前系统的真实写照，可能是一个由人工操作的过程，也可能是一个已有的但需要改进的计算机系统。首先是要对现行系统进行分析、理解，了解它的组织情况、数据流向、输入输出，资源利用情况等，在分析的基础上画出它的物理模型。然后抽象出当前系统的逻辑模型。

逻辑模型是在物理模型基础上，去掉一些次要的因素，建立起反映系统本质的逻辑模型。接下来建立目标系统的逻辑模型。通过分析目标系统与当前系统在逻辑上的区别，建立符合用户需求的目标系统的逻辑模型。最后补充目标系统的逻辑模型。对目标系统进行补充完善 ,将一些次要的因素补充进去，例如出错处理等。

UML（The Unified Modeling Language，即统一建模语言）是一种编制系统蓝图的标准化语言，可以对复杂的系统建立可视化的系统模型，目前已经被工业标准化组织OMG（Object Management Group）接受，一经推出便得到许多著名的计算机厂商如Microsoft、HP、IBM、Oracle等的支持，也在逐步开始应用到需求分析过程中。

在使用UML建立当前系统逻辑模型过程中，初学者通常会遇到一些问题：

1.什么时候真正需要业务模型？什么时候用例模型独立存在？

2.在进行精确的业务建模时能用哪些UML图形？如何知道是否用顺序图或者交互图？

3.业务模型如何涉及到其他模型（如领域模型，用例模型等等）呢？如何有机地组织这些模型？

本文将通过图书馆管理系统这个简单而典型的实例来进行一次UML需求分析实践之旅。

许多读者对图书馆图书管理工作比较熟悉，主要是围绕读者、图书和工作人员的借还书展开工作。我们先看看图书馆工作人员和部分读者的需求。

读者来图书馆借书，可能先查询书库的图书记录。查询可以按书名、作者、图书编号、关键字查询。查询有两种结果，如果查到则记下书号，交给工作人员，然后等候办理借书手续。如果该书已经被全部借出，则可做借书登记，等待有书时被通知。如果图书馆没有该书的记录，则做缺书登记。

办理借书手续时先要出示图书证，没有图书证则去申请图书证。如果借书数量超出规定，则提示“借书数量超限，不能继续借阅”。工作人员登记借阅人信息、借阅的图书信息、借出时间和应还书时间。系统自动修改书库的图书记录、读者库信息。

当一位读者还书时，工作人员根据图书证编号，找到读者的借书信息，查看是否超期，如果已经超期，则进行超期处罚。

如果图书有破损、丢失，则进行破损处罚。清除借阅记录，同时系统自动查看是否有等待借阅登记，如果有则发出通知，修改书库记录，该书设置为已预订状态，否则设置为可借状态。

图书采购人员进行图书采购时，要参考各类图书的库存数和借阅率，注意合理采购。如果有缺书登记则随时进行采购。正在采购的图书组成一个采购中书库。

采购到货后，进行验收，编号，同时加入图书库，修改采购中书库，并且查看订阅库，发出到书通知，并且已经修改书库的图书记录为已预订状态。

借书登记是当欲借的书被借空后，读者自愿选择的一种操作，它应该记录读者名和联系方式，一旦有这本书后可通知读者。

到书通知，当读者预订的书来到之后，按照读者给出的联系方式发出通知。

缺书登记是当读者需要的书库内查询没有记录时，将此信息转入缺货库，通知采购员采购。

图书注销，如果图书丢失或旧书淘汰，则将该书从书库中清除。

根据需求描述整理一张需求表：

需求分析时首先要识别出系统的参与者，在简单的图书馆管理系统中，可以划分出两种参与者：读者和管理员。当然，根据业务的复杂程度，参与者也可以进行细分，比如读者可以再分为学生读者、教师读者、校外读者，管理员根据业务和权限的不同可以再细分为库房管理员、借还书操作员、系统维护人员、图书馆管理人员等不同角色。在这里，为了简化处理，我们只列出了读者和管理员。对参与者描述如下：

（1）读者

描述：读者可以借阅、预定、归还物理书刊，可以对书籍和个人信息进行查询，可以取消预定，可以提出办卡申请。

示例：持有借阅卡的任何人和组织。

（2）管理员

描述：图书管理员对系统进行维护，包括读者信息的创建、修改、删除，书刊信息的维护，条目信息的维护，还有系统信息的维护。

示例：图书管理员。

通过识别的参与者，对需求进一步分析，将业务需求进行分解，获得每个参与者的使用用例。在本例中，我们可以得到以下用例：

1.书籍借出：提供借阅物理书刊的功能。

2.书籍归还：提供归还物理书刊的功能。

3.读者办卡：提供为读者办理借阅卡的功能。

4.预定书刊：提供对某一个种类的书刊的预约功能。

5.取消预定：提供对预定进行取消的功能。

6.书籍查询：为读者提供网上的书籍查询功能。

7.信息查询：为读者提供信息查询的功能。

8.读者信息维护：提供读者信息的录入、修改、查询、删除的功能。

9.书刊信息维护：提供物理书刊的录入、修改、查询、删除的功能。

10.条目信息维护：提供书刊条目的录入、修改、查询、删除的功能。

11.系统信息维护：提供对系统的参数的设置。

12.登录：管理员需要先登录才能进入系统。

并且，可以画出如下系统用例图：

通过用例图，可以对系统功能有一个大概的了解，对于复杂系统，我们可以结合IDEF方法，通过分层分解，逐步细化的方法来描述系统的功能。对于用例图，建议不要画的过于复杂，特别是用例之间的关系，因为复杂的用例图不仅不能让需求分析人员与客户之间更好的沟通，反而是制造了一种沟通障碍。

下一步就是编制每一个用例的详细说明，对用例说明的主要信息包括有：用例名称、编号、用例的简短描述、用例的参与者、与其他用例的管理、用例启动的前提条件、用例结束后的事后条件、用例的输入、输出、用例的执行事件流等。在实际项目中，我们并不一定要面面俱到，而是根据实际情况对用例描述进行裁减。其中有几点重要信息是不能裁减的：用例名称、描述、输入、输出、执行事件流、参与者。另外，如果实际情况需要，还可以使用MS Visio等工具画出界面的示意图来。

如上例所述，我们对每一个用例都进行详细的描述，建立当前系统的功能用例模型。需求沟通与分析是一个迭代的过程，通过与用户的不断沟通，最终达成对目标系统的一致理解。如果用户确认了需求分析的成果，一般是需求规格说明书之后，项目开始进入系统分析设计阶段，也就是开始构造目标系统的逻辑模型。

为了让系统设计能够以结构、组织方式和代码重用的形式表现出来，要对系统进行设计规划，设计阶段应该与分析阶段交迭。需求是不断地发展，而设计本身也会推动需求的发展(反之亦然) 。在图书馆管理系统的建模设计中，以下3个方面的问题是要关注的：业务对象的表示、业务服务的实现、用户界面的组织。

业务对象的表示

在图书馆管理系统系统中，业务对象主要是数据库和数据实体类的表示方式。建模时，可以构造出系统的静态模型，也就是系统类图来表示。如下图则描述了借书这一用例的静态结构图。为了体现类之间的关系，在下图中没有显示出每一个类的属性和基本操作。

业务服务的实现

业务服务的实现需要完成的功能是各种业务规则和逻辑的实现,如借书处理的业务逻辑。每个模块的信息录入、修改、删除、查询等。业务规则和逻辑的实现基本相似，没有太多的规律可循。采用UML来进行业务服务的建模，可以使用UML 的序列图、状态图、活动图。这个部分的工作,通常通过一系列的类之间的交互来完成。为了在更动态的层面上描述系统，UML 提供了许多其他类型的图。

对于B/S系统设计而言，情节图(Scenario Diagram) 特别有用。情节图分成两种：协作图(Collaboration Diagram) ，序列图(Sequence Diagram) 。UML 建模工具Rational Rose 能够从协作图生成序列图也可以从序列图生成协作图。例如，借阅书刊的业务过程可以采用如下序列图来描述：

借阅书刊过程主要包括：管理员选择“借阅书刊”菜单，弹出对话框，管理员输入书刊信息和用户信息，系统查找数据库，是否存在该种物理书刊，如果不存在，显示提示信息，用例结束;是否存在借阅者信息，如果不存在，显示提示信息，用例结束;否则，管理员单击确认按钮后，该图书借阅给该借阅者，系统存储借阅信息到数据库。

用户界面的组织

用户界面布局图能够帮助组织系统页面、文件、服务的布局结构。在UML 中，对于页面和文件的组织，可以使用构件图(Component Diagram) 或类图(Class Diagram) 建模型。本系统中使用类图对界面组织建模，页面结构以及各种业务服务被捆绑到不同的区域。

在 UML 中，系统的体系结构使用部署图(DeploymentDiagram) 来完成。应用部署的规划对于规划整个B/ S 系统是很有用的。它确定了一种有效的应用部署的规划组织方式,还可以作为一个模式在多个类似B/ S 系统上应用。

在建模完成后，开发人员利用一些UML Case工具如Rational ROSE生成程序代码框架，并对代码框架进行修改和补充，形成完整代码;而且，还可根据代码逆向生成 UML模型。这就较好地保证了模型与代码的一致性。

测试必须在整个项目周期中进行，对每个阶段都要用所建立的模型进行测试，这样才能保证开发的质量，减少开发的风险。

统一建模语言 UML 是国际软件工程领域具有划时代意义的重要成果，适用于以面向对象技术来描述任何类型的系统，而且适用于系统开发的不同阶段，从需求规格描述直至系统完成后的测试和维护。软件系统的规模越来越大，复杂度不断提高，RUP迭代式增量开发方式可以降低风险，同时可以适应需求变化的需要。

在本次UML实践之旅中，我们通过对图书馆管理系统的需求进行分析，将 UML 应用于系统开发的各个阶段，建立了系统的需求模型、静态模型和动态模型，同时遵循Rationl统一过程(RUP)的核心思想和基本原则，采用以用例为驱动、以体系构架为核心的迭代化面向对象分析和设计过程。

图1：系统用例图

图2：用况活动图

图3：借书部分的类结构图

UML行为图

用况图（use case diagram）描述了一组用况和参与者（一种特殊的类）以及它们之间的关系。

交互图（interaction diagram）是顺序图和协作图的统称。

顺序图(sequence diagram)是强调消息的时间次序的交互图。

协作图(collaboration diagram)是强调收发消息的对象的结构组织的交互图。

状态图显示了一个由状态，转换，事件和活动组成的状态机。

活动图显示了系统中从活动到活动的流。

组织简介 | 联系我们 |   Copyright 2002 ®  UML软件工程组织 京ICP备10020922号

京公海网安备110108001071号