软件工程之乱七八糟

软件工程模式的研究和开发是软件工程的一项重要课题。1997年,美国Rational Software公司的Jacobson、Booch和Rumbaugh三人提出了统一的软件开发过程&＃xff08;The United Software Development Process&＃xff09;&＃xff0c;这是三人继UML之后推出的又一杰作。

    UML是一种基于OO方法的统一的可视化图形建模语言&＃xff0c;而不是统一的建模&＃xff08;软件开发&＃xff09;过程。尽管语言和过程不可分割&＃xff0c;但语言与过程所关心的重点毕竟不尽相同。因此&＃xff0c;在开发UML之后&＃xff0c;再开发一个统一的建模&＃xff08;软件开发&＃xff09;过程是十分适时的。这样统一的建模语言与统一的软件开发过程和工具就可以组成一种完整的基于OO技术的软件工程模式。

    一、软件工程模式的演化

    1&＃xff0e;瀑布模型&＃xff08;Waterfall model&＃xff09;

    这是从硬件工程学来的一种分阶段的、系统的和顺序的软件开发方法&＃xff0c;它由系统需求分析开始&＃xff0c;接着是软件的设计、编码、测试和维护。

    这种传统的生存期模型是当时使用最广泛的软件工程模式。但是这种模式的实质是面向阶段的和线性的&＃xff0c;除了确认和验证&＃xff0c;其他所有阶段都是线性执行的。也就是说&＃xff0c;每个阶段都只有当其前一阶段工作完成以后才能开始&＃xff0c;而且&＃xff0c;它的好坏一直要等到测试时才能知道。这种模式在硬件生产中使用效果很好&＃xff0c;但用于软件开发时争议却越来越大。因为用户很可能提出非常模糊的需求&＃xff0c;而这种模糊的需求又可能被开发者随意解释&＃xff1b;经验表明&＃xff0c;一旦用户使用一个计算机系统&＃xff0c;他们对目标系统的理解可能又会发生许多变化&＃xff0c;因此开发者随意附和用户需求的方式往往是一种冒险&＃xff1b;更为严重的事实是一个规模庞大的软件项目往往要用几年时间才能完成&＃xff0c;在这期间用户的需求和环境都有可能发生很大的变化&＃xff0c;从而使系统最终不能使用。

    某些领域&＃xff0c;如科学数值计算、嵌入式软件和实时控制系统&＃xff0c;最合适采用瀑布模型&＃xff0c;也是控制这类项目复杂性的最好途径。但是&＃xff0c;对更多的其他应用领域&＃xff0c;特别是商业数据处理&＃xff0c;这一方法存在着许多严重的不容忽视的缺陷&＃xff0c;是不适用的。

    2&＃xff0e;原型开发模型

    原型开发也是从了解用户需求开始。开发人员和用户一起来定义所有目标&＃xff0c;确定哪些需求已经清楚&＃xff0c;哪些还需要进一步定义;接着是快速设计&＃xff0c;主要集中在用户能够看得见的一些软件表示方面&＃xff08;如输入方法、输出形式等&＃xff09;&＃xff0c;用户有了原型就可对其进行评价&＃xff0c;然后修改需求&＃xff0c;重复上述各步骤&＃xff0c;直到该原型能够满足用户需求为止。

    从理论上说&＃xff0c;原型开发能够缓解用户需求的不确定性和变化所带来的风险&＃xff0c;但实际上也存在许多缺陷。因为开发单位给出的原型一定要是可执行的&＃xff0c;这就有周期和经费的问题。为了又快又省地开发出原型&＃xff0c;因此又把原型分为三类&＃xff1a;抛弃式&＃xff0c;目的达到即被抛弃&＃xff0c;原型不作为最终产品&＃xff1b;演化式&＃xff0c;系统的形成和发展是逐步完成的&＃xff0c;它是高度动态迭代和高度动态的&＃xff0c;每次迭代都要对系统重新进行规格说明、重新设计、重新实现和重新评价&＃xff0c;所以是对付变化最为有效的方法&＃xff0c;这也是与瀑布开发的主要不同点&＃xff1b;增量式&＃xff0c;系统是一次一段地增量构造&＃xff0c;与演化式原型的最大区别在于增量式开发是在软件总体设计基础上进行的。很显然&＃xff0c;其对付变化比演化式差。

    3&＃xff0e;螺旋开发模型

    螺旋开发模型综合了传统的生存期模型和原型开发模型的优点&＃xff0c;同时增加了一个新的元素&＃xff08;风险分析&＃xff09;&＃xff0c;用来弥补两者的不足。螺旋开发定义了四项主要活动&＃xff1a;计划、风险分析、工程和用户评价。螺旋开发就是围绕这四步一圈、二圈、三圈等重复进行。根据每一圈风险分析的结果&＃xff0c;做出继续还是停止的决择。如果风险太大&＃xff0c;项目只能终止。但在大多数情况下&＃xff0c;沿着螺旋的路径就可以建立起完整的系统&＃xff0c;而最终成为运行系统。这种开发模型是当前大型系统或软件开发最现实的和经常使用的方法。

    4&＃xff0e;四代技术

    四代技术&＃xff08;4GL&＃xff09;拥有一组工具&＃xff08;如数据查询、报表生成、数据处理、屏幕定义、代码生成、高层图形功能及电子表格等&＃xff09;&＃xff0c;每个工具都能使开发人员在高层次上定义软件的某些特性&＃xff0c;并把开发人员定义的这些软件自动地生成为源代码。这种方法需要四代语言&＃xff08;4GL&＃xff09;的支持。4GL不同于三代语言&＃xff0c;其主要特征是用户界面极端友好&＃xff0c;即使没有受过训练的非专业程序员&＃xff0c;也能用它编写程序&＃xff1b;它是一种声明式、交互式和非过程性编程语言。4GL还具有高效的程序代码、智能缺省假设、完备的数据库和应用程序生成器。目前市场上流行的4GL&＃xff08;如Foxpro等&＃xff09;都不同程度地具有上述特征。但4GL目前主要限于事务信息系统的中、小型应用程序的开发。

    5&＃xff0e;过程开发模型

    过程开发模型又叫混合模型&＃xff08;hybrid model&＃xff09;&＃xff0c;或元模型&＃xff08;meta-model&＃xff09;。

    为了克服瀑布模型的缺陷&＃xff0c;人们已经提出了原型等多种开发模式。这些可选的开发模式看起来十分严谨&＃xff0c;但整个项目的开发仍被限制在按定义所确定的阶段性的系统方向上。实际上任何一个项目的开发都取决于许多因素&＃xff0c;如软件的应用领域、规模大小、重用构件的大小和多少、软件实现的硬件及软件环境、开始和交付规定、周期和成本限制&＃xff0c;以及开发人员的素质等。其中任何一个因素的改变都会影响开发的进程。用户的需求从第一天开始就在变化&＃xff0c;一直到该软件被废弃为止。

    最早提出这个问题的是美国国防部软件工程研究所&＃xff08;DoDSEI&＃xff09;和卡内其·梅隆大学的一些研究人员。解决这个问题的方法之一就是把几种不同模型组合成一种混合模型&＃xff0c;它允许一个项目能沿着最有效的路径发展&＃xff0c;这就是过程开发模型&＃xff08;或混合模型&＃xff09;提出的背景。实际上&＃xff0c;一些软件开发单位都是使用几种不同的开发方法组成他们自己的混合模型。

    过程开发模型的研究成果最初只是用来代表美国DoD调查各软件开发机构开发过程的成熟程度&＃xff0c;最有代表性的就是1991年DoDSEI公布的CMM&＃xff08;The Capability Maturity Model&＃xff09;&＃xff0c;现在CMM已作为评估开发机构能力成熟程度的标准。

 6&＃xff0e;面向对象&＃xff08;OO&＃xff09;生存期模型

    随着OO技术的逐渐成熟&＃xff0c;人们又提出了OO软件工程生存期开发模型。

    OO开发与传统的结构化生存期比较&＃xff0c;具有更多的增量和迭代性质&＃xff0c;生存期的各个阶段可以相互重叠和多次反复&＃xff0c;而且在项目的整个生存期中还可以嵌入子生存期。所以有人称OO生存期模型为喷泉模型&＃xff08;fountain model&＃xff09;&＃xff0c;就像水喷上去又可以落下来&＃xff0c;可以落在中间&＃xff0c;也可以落在最底部。

    实际应用中大多把OO技术与传统的结构化技术搀和或搭配起来&＃xff0c;创造出多种混合开发生存期&＃xff0c;这是考虑到当前在传统的结构化技术上大量投资、经验很多、人员比较熟悉而OO技术还不尽完善的现实。

    7&＃xff0e;基于构件的软件开发

    基于构件的软件开发&＃xff08;CBD&＃xff09;方法是在软件重用技术和OO技术基础上发展起来的。前述六种开发模式都是面向过程的&＃xff0c;而CBD则是第一个面向产品结构的。

    二、 统一的软件开发过程   

    统一过程是基于构件的&＃xff0c;它使用新的可视化建模标准和统一的建模语言&＃xff08;UML&＃xff09;&＃xff0c;并依靠3个关键思想——使用用例驱动&＃xff08;Use-Case Driver&＃xff09;&＃xff0c;以体系结构为中心&＃xff08;Architecture-Centric&＃xff09;和迭代与增量&＃xff08;Iterative and Incremental&＃xff09;开发。为了按这些思想工作&＃xff0c;就要求构建多种过程&＃xff0c;人们要考虑周期&＃xff08;cycles&＃xff09;、阶段&＃xff08;phases&＃xff09;、工作流程&＃xff08;work flows&＃xff09;、风险缓解&＃xff08;risk mitigation&＃xff09;、质量控制&＃xff08;quality control&＃xff09;、项目管理&＃xff08;project management&＃xff09;以及配置管理&＃xff08;configuration control&＃xff09;等各个项目。这样统一过程构造的框架才能把上述所有的不同方面集成起来。

    这种框架的所有工作如同一张保护伞&＃xff0c;在它的下面&＃xff0c;工具商和开发者能够创造出各种不同的工具&＃xff0c;以支持过程的自动化&＃xff0c;支持各个工作流&＃xff0c;建立所有不同的模型&＃xff0c;并围绕生存期和所有模型一体化的工作。

    1&＃xff0e;使用用例驱动

    使用用例驱动是Ivar Jacobson在他1994年出版的《Object-Oriented Software Engineering》一书中首先提出来的&＃xff0c;这其中主要有三个理由&＃xff1a; 
    
    能够提供一个系统和直觉捕捉功能需求的方法。也就是说可以捕捉有价值的用户需求&＃xff0c;解决“做什么”&＃xff0c;并成为弄清需求用户目标和系统交互功能的起点。引入使用用例的概念是OO技术进入第二代的标志。

    能驱动整个开发过程。因为许多活动&＃xff08;如分析、设计和测试&＃xff09;的完成都是从使用用例开始&＃xff0c;也就是说使用用例可以导出过程&＃xff0c;一个开发项目是从使用用例中一系列的工作流着手的。使用用例可以帮助开发者找到类和开发出用户接口。

    可以帮助开发者完成迭代开发。一个项目的每次迭代都是通过使用用例的工作流作为驱动的&＃xff0c;在一次增量中完成从需求、设计到测试的一系列工作;另一方面&＃xff0c;在每次迭代中一定数量的使用用例是不可缺少的。 
    
    另外&＃xff0c;使用用例还可以帮助设计体系结构、书写用户手册等。

    2&＃xff0e;以体系结构为中心

    这是在统一的软件开发过程的生存期模型中第一次提出来的&＃xff0c;是过去所有生存期模型所没有的。那么&＃xff0c;为什么要以体系结构为中心呢&＃xff1f;

    一个软件系统的开发只凭想像是困难的&＃xff0c;因为它并不存在于人的三维世界中&＃xff0c;是没有前例的或在一些方面是异乎寻常的。经常使用没有被验证过的方法或一种新提出的混合方法&＃xff0c;有时虽可以扩展现有技术&＃xff0c;但也是非常有限的&＃xff0c;此外还必须建立一个能适应可进一步修改的庞大的类。由此可以看出&＃xff0c;结构的设计问题已远远超出了计算的算法和数据结构&＃xff0c;而定义和设计整个系统的体系结构将成为一个新的课题。

    此外&＃xff0c;通常现有的一些系统一般都完成了“建议系统”的某些功能&＃xff0c;显示出系统能够做哪些工作&＃xff0c;但只有很少的文档&＃xff0c;甚至没有文档&＃xff0c;所以开发者可以重用的仅仅是传统的代码&＃xff0c;所有这些都将增加开发的复杂性。因此&＃xff0c;开发一个软件系统&＃xff0c;特别是一个庞大的和复杂的软件系统&＃xff0c;需要一个体系结构&＃xff0c;这样开发者才能朝着共同的目标去工作。这样做的目的是&＃xff1a;懂得系统、组织开发、促进重用、发展系统。

    3&＃xff0e;迭代和增量开发

    迭代和增量开发最早是在OO生存期模型中提出的&＃xff0c;大家比较熟悉。我们之所以必须采用迭代和增量的开发方法&＃xff0c;其主要目的是控制软件的开发&＃xff0c;这种方法的好处包括&＃xff1a;

    早期致命的和重大的风险能得到控制。

    得到一个健壮&＃xff08;robust&＃xff09;的体系结构&＃xff0c;以指导软件开发。

    提供一个框架&＃xff0c;能较好地控制不可避免的需求和其他修改。

    构建一个系统&＃xff0c;多次增量接近比一次完成所带来的各种开销少&＃xff0c;而且质量好。

    提供一个开发过程&＃xff0c;让技术人员工作更为有效。

    让开发人员能获得早期学习的机会。

    统一的软件开发过程是软件生存期模型发展迄今为止的里程碑&＃xff0c;它集中了所有生存期模型的优点。当然&＃xff0c;要把这种方法实施还需要开发大量的相应工具和环境&＃xff0c;如果没有工具和环境的支持&＃xff0c;只能说是纸上谈兵。 
    
    软件开发过程

    软件工程是由硬件工程派生出来的&＃xff0c;它包含四个关键元素&＃xff1a;方法,提供了构造软件的技术&＃xff1b;语言,用以支持软件的分析、设计和实现&＃xff1b;工具,为方法和语言提供自动化或半自动化的支持&＃xff1b;软件工程的过程,是粘结剂&＃xff08;glue&＃xff09;&＃xff0c;把方法、语言和工具结合在一起&＃xff0c;它能使软件开发理性化和适时化。过程定义了方法使用的顺序、可交付产品&＃xff08;文档、报告和格式等&＃xff09;的要求、确保质量和修改的控制&＃xff0c;并使软件管理人员能对它们的进展进行评价。

    软件工程由一系列的方法、语言、工具和过程的步骤所组成&＃xff0c;这些步骤通常叫做软件工程模式&＃xff08;paradigms&＃xff09;&＃xff0c;有的叫做软件生存期模型&＃xff08;life cycle model&＃xff09;&＃xff0c;也有的叫做软件开发过程&＃xff08;development process&＃xff09;。