基于统一过程的软件开发研究

仝行靠

[摘要]文章分析软件开发方法的发展过程，简单介绍UML(Unified Modeling Language)的概念，详细介绍统一过程的基本内容和具体实施，并对支持统一过程的产品及应用进行相应的描述，展望统一过程的应用前景。

[关键词]软件开发；统一过程；统一建模语言

[作者简介]仝行常，石河子大学商学院教学科研办公室网络管理中心助教，高级程序员，研究方向：软件开发方法，新疆五家渠市，831300

[中图分类号]TP311.52[文献标识码]A[文章编号]1007-7723(2009)01-0027-0003

一、引言

计算机自诞生以来，就一直以令人难以置信的速度飞快发展，其中软件开发也得到了长足的发展。自从上世纪70年代发生软件危机后，人们经过反思后，开始致力于软件开发方法的研究，于是多种软件开发方法应运而生，如结构化方法和面向对象方法等。但在方法的使用上又有许多变化以至于软件开发过程缺乏统一性，严重影响了软件工程活动的质量和软件本身的质量。软件过程的标准化势在必行，从上世纪90年代开始，面向对象技术的三大流派开始进行模型整合，人们提出了UML和统一过程等概念。

二、UML

UML即统一建模语言，它集可视化、详述、构造和文档化等特点于一身，是一种绘制软件蓝图的标准建模语言。在以往面向对象建模语言的基础上，它提供了一系列标准化的图形符号，所建立的模型清晰完整、便于理解且有助于用户及软件开发人员间的交流和协商。UML作为一种软件开发的有效工具将贯穿于整个软件开发过程之中，它提供了多种视图从不同角度表现出所开发系统的静态、动态特征，有助于完成系统体系结构的设计，也能够为最终的软件产品提供相关的细节文档资料。虽然UML仅仅只是一种建模语言，但却能与Java、c++、VB等实际编程语言直接相关，并支持双向工程，即既能够根据所建立的UML模型推导出相应的编程代码，同时也能根据实际的编程代码构造出相应的UML模型。UML提供了9种视图从不同角度表现整个系统的特征，即类图、对象图、用况图、顺序图、协作图、状态图、活动图、构件图和实施图，并描绘出A种事物和A种关系，即结构事物、行为事物、分组事物、注释事物和依赖、关联、泛化及实现关系。通过UML建立的模型既能够让软件开发人员逐渐加深对正在或将要开发的软件系统的理解，也能让用户从较直观的角度理解系统的设计，有利于系统开发者与使用者之间的交流。UML以其自身的特点，成为开发软件系统最为有效的建模工具。虽然UML作为一种建模语言独立于实际的开发过程，但如果将这种有效的描述工具使用在以用例为驱动(use case)、以体系结构(architecture)为中心、不断迭代(iterative)与增量(incremental)的开发过程之中，将能更充分地发挥其功效，使整个系统的开发更加有效。

三、统一过程

统一过程(united Process，UP)是由统一建模语言UML的缔造者们提出来的，并为对象管理组织(Object Management Group，OMG)所推荐。UML不仅统一了Booch、Rumbaugh和Jacobson的表示方法，而且对其作了进一步的发展，并最终统一为大众所接受的标准建模语言。统一过程是UML的缔造者们权衡了30年的软件开发实践而形成的产物。它把当前处于分离的方法学集合于一起，称之为“统一方法”。它不仅统一了缔造者们的工作，而且使得开发方法得以统一，方法学家的工作得以统一。它也包含了很多其他人员和公司对UML做出的巨大贡献。例如它来自于数百个用户多年的现场经验以及Rational公司多年的工作成果。统一过程对于如何运用UML的概念进行软件开发提供了详细指导，它指导开发队伍安排其开发活动的次序，为各开发者和整个开发组指定任务，明确地规定需要开发的制品，提供对项目中的制品和活动进行监控与度量的准则。简言之，统一过程将用户需求转换成开发软件系统的活动集合，适合于软件专业人员使用，恰好它是以用例为驱动、体系结构为中心、迭代和增量的。

四、具体实施

统一过程与以往软件开发方法最大的不同就在于它强调了不断迭代与增量的开发过程，并将此理论化、系统化。其实，只有通过认识一再认识这样不断循环与深化的过程才能真正认清事物的本质，对于软件开发也是如此。由于种种原因面对如此庞大的软件系统，开发人员不可能一开始就完整确切地了解用户需求，更不可能一次就设计出一个完美可行的设计方案和最终的软件产品。只有在不断迭代与增量的实践和认识过程中，才能真正认清用户的需求，才能不断完善整个系统的设计，最终得到一个既令用户满意又能从最大程度发挥其功能的软件产品。统一过程强调尽量在开发早期解决致命风险，所以就以风险来驱动迭代与增量的开发，将根据开发过程中面临风险的大小，逐个排除风险并解决问题，尽量降低开发过程中的错误判断以及不必要的开支。其实整个开发过程就是在不断重复构成系统生命周期的循环。每次循环都会以向用户提供一个产品为终结，并在不断迭代与增量的过程之中经历初始、细化、构造和移交四个阶段，同时完成需求、分析、设计、实现和测试的工作。

用例驱动的含义是在产品开发的各个阶段中都可以回溯到用户的真正需求，即它驱动开发过程，以用例为单位制定计划、分配任务、监控执行和进行测试等，将核心工作流结合为一体。用例的引入有助于模型之间的追踪和系统演化。由用例能得到体系结构和其他制品。先选择在体系结构上具有重要意义的用例，实现那些关键的用例，构造出初步的体系结构，再逐步得到稳定的体系结构。各模型采用统一的建模语言即UML，方便各个阶段不同工作人员之间的沟通，大大提高了工作效率。通过枚举用例的不同执行路径，可导出测试案例和测试规程。通过用例还可估算系统性能、硬件需求和可用性，并能进行用户界面设计，用例也是编写用户手册的起点。对用例的细化在一定程度上涉及系统的内部功能，对各用例进行完整的功能描述。细化时要区分用例中的三类事物：反映系统与参与者(actor)之间接口的事物、系统中的现实事物和对前两项进行协调和控制的事物。

以体系结构为中心，简单地讲，系统体系结构源自系统需求(用例模型)，从不同角度描述要构造的系统，注重于系统的显著的静态和动态结构。用户和其他关注者要理解它，以对系统概貌的远景达到共识。要用系统的体系结构控制系统的开发、复用和演化。系统体系结构描述系统中诸如子系统、依赖关系、接口、协作、节点和主动类这样的最重要的模型元素，而忽略其他细节。用这些元素指导系统开发。这些重要的元素由体系结构设计者

完成，其余的由各设计者分别完成。

得到系统体系结构的简略步骤：

·在普遍了解用例之后，得到系统体系结构的粗略纲要(独立于特定用例和平台)；

·关注关键用例；

·随着对用例的规约，导致更多成熟的用例，继续发现更多的系统体系结构部分。

系统的体系结构经过多次迭代，在精化阶段结束时，得到可执行的体系结构基线fArchitecture Baseline)。它是系统框架，最初包括系统件、中间件、要复用的遗产系统、系统分布等情况。随后体系结构基线是由早期版本的用例模型、分析模型、设计模型等模型组成的集合(其中用例模型和分析模型较为成熟)，关注子系统体系结构的内部发布版本，包括构造阶段结束时系统中的所有模型，它与最终系统(对客户发布的产品)有同样的骨干。从体系结构基线到最终系统之间要经过几个内部发布，体系结构基线的最后结果为一个模型集合和一个体系结构描述，其中包括最重要的用例及其实例。

建立可执行的体系结构基线是精化阶段的一个目标，进入内造阶段的体系结构基线应是坚实的：精化阶段结束时的体系结构基线在构造阶段变化不大，即体系结构基线到最终系统的体系结构之间的改动不大。体系结构描述是模型的体系结构视图的集合，包括用例模型的体系结构视图(取用例的重要部分)、设计模型的体系结构视图、部署模型的体系结构视图和实现模型的体系结构视图。在开发过程中，要对体系结构基线进行改写，以体现重要的设计问题，方便对问题的理解、讨论、解决和反馈，为开发者提供所需信息的高层视图，不遗漏大的技术问题。然而体系结构描述中不包括体系结构基线中的非体系结构级的元素。这是因为体系结构基线要对系统需求建模，以制定详细的开发计划，因此其用例模型中包含的内容比系统体系结构的要多。

其实体系结构基线与体系结构描述同时开发，指导整个生命周期的软件开发。体系结构描述在系统生命周期中不断更新，以反映体系结构基线的变化，包括新的抽象类和接口的发现、为已有系统增加新功能、可复用构件的版本更新、进程结构的重新组织、体系结构基线的新的表示形式等。

五、总结

统一过程汲取了面向对象的软件工程领域多年来的优秀研究成果，利用了新的可视化建模标准UML，是软件开发标准化要求的必然产物，是Rational等公司的实践产物。同时Rational及其他公司开发了一系列支持应用的产品，如可视化建模工具Rational Rose，用于项目小组跟踪和管理开发生命周期中的所有变更活动的需求变更管理产品Rational ClearQues等产品，这些产品与流行的开发工具紧密结合，最终实现分析、设计、编码和文档管理的一体化，进一步推动了统一过程在业界的应用，取得了相当好的效果。