软件工程课件：现代软件工程

现代软件工程14.1现代软件工程发展的主要技术特点14.2开源软件运动14.3领域工程14.4敏捷软件开发过程及实践14.5测试驱动开发14.6现代软件工程其他新方法习题14

知识点

现代软件工程，软件开发新方法和技术。

难点

软件工程领域新的方法和技术。

基于工作过程的教学任务

通过本章的学习，了解现代软件工程发展的主要技术特点；了解开源软件、领域工程、敏捷软件开发过程及实践、测试驱动开发、模型驱动软件开发等软件工程新方法和技术。与传统软件工程方法相比较，这些方法和技术为现代软件工程实践提供了新的思路，已在许多软件工程实践中取得了积极的效果。

14.1现代软件工程发展的主要技术特点

在现代软件工程中，工程与管理技术和方法与软件开发方法具有同等重要的位置，并且要求保持相互联系、相互衔接、相互支持和协调工作。前者可以比拟为制造技术中的生产技术，后者是工艺技术、质量控制技术、管理技术。因此，在笼统地谈到技术和方法的时候，有时并不区分是需求分析技术还是配置管理方法等，而统称为“开发技术和方法”。

为了比较清楚地说明现代软件工程的发展现状，综合各有关资料，可把现代软件工程内涵分为四个关键领域或四个过程，即开发过程、支持过程、工程过程和管理过程。

现代软件工程依然采用生命周期模型，甚至包括瀑布模型。所不同的是，现代软件工程的生命周期模型不仅仅反映的是软件生产的前后工序，更是提供了一个过程管理的公共框架，即公共的认知、协同和控制的框架。

那么，现代软件工程发展了哪些新技术和新方法呢？

1.开发过程的新方法与新技术

开发过程包括需求分析、系统设计、实现与维护等软件开发的基本过程，是“传统软件工程的基本过程”。过程本身没有发生根本的变化，但技术方法有了很大的发展。

根据统一软件开发过程(RationalUnifiedProcess,RUP)的划分，在需求获取阶段，现代软件工程普遍采用了面向对象建模的思想和UML建模技术与方法，通过业务建模和系统建模，为用户和开发团队描述了一个能够共同理解的希望开发的系统的构想和场景，并基于该构想和场景，在业务用例模型和业务对象模型中定义项目的目标和范围，定义系统与组织的过程、角色和责任。

需求获取技术和方法的改进，使得对系统应该做什么、如何使开发人员和用户就某一问题描述达成共识，而变得较为容易求解。因而，该技术和方法更能适应用户与开发团队进行沟通和达成共识，更能适应需求的变更和管理。

在分析和设计阶段，面向对象的分析与设计模式、基于构件的系统构架方法和系统开发技术，为把需求转变为未来的系统，建立了一个健壮的框架基础。现代软件工程更强调系统结构的灵活性、可扩展性和可重用性。该要求被基于构件的系统构架分析、设计与开发所支持，而这个阶段的主要技术特点是面向对象的模式、构件、框架的研究。

在实现阶段，有一些技术方法(如中间件、构件/组件技术等)支持可重用软件系统的搭建。开发者首先会考虑重用构件库已有的构件产品。系统构建的活动是在层次化的子系统形势下，按定义代码的组织结构，以构件/组件的形式(源文件、二进制文件、可执行文件)实现类和对象的。最后，将开发出的组件作为单元进行测试以及集成由单个开发者(或小组)所产生的结果，使其成为可执行的系统。

所以，在开发过程中，现代软件工程比较注重的技术和方法是：统一建模语言UML、构架与构件技术、基于软件复用性的系统实现，以及统一的开发过程(UP)。

2.支持过程的工具和环境

支持过程包括一般意义上的开发工具与环境。现在，开发工具和环境的改进非常明显。但现代软件工程把注意力和关注点更多地放在发展整个开发过程的综合支持与支撑环境上。如全过程的文档支持，配置管理支持，质量保证支持，测试、分析、量化度量与控制支持等。

现代软件工程的过程是非常复杂的，所有的技术和方法都离不开具体实现的环境与工具。而现代软件工程思想的实现，如果没有工具的支持，也是不可能的。

按不同的工具分类方法，软件工程的工具可分为：

(1)软件开发工具：需求分析、设计、测试工具等；

(2)软件维护工具：版本控制、文档分析、逆向工程、再工程等；

(3)软件管理与支持工具：项目管理、开发资源库、配置管理、软件评审等。

按解决的问题，软件工程的环境可分为程序设计、系统集成、项目管理等。

按现有的软件开发环境的演变趋向，软件工程的环境可分为以语言为中心、面向结构、工具箱和基于方法的环境等。

软件工程环境提供了一个平台，基于该平台可以充分发挥各个工具的作用，并实现工具之间、各技术和方法之间的继承和协同支持。例如，计算机辅助软件工程(ComputerAidedSoftwareEngineering,CASE)就是这样一个平台。

CASE的集成机制包括以下内容：

(1)数据集成：工具间可交换数据；

(2)界面集成：工具具有相同的界面风格和交互方式；

(3)控制集成：工具激活后能控制其他工具的操作；

(4)过程集成：系统嵌入了有关软件过程的知识，根据软件过程模型，辅助用户启动各种软件开发活动。

(5)平台集成：工具运行在相同的硬件/软件操作系统下。

3.工程过程的过程和模型

工程过程包括各种生命周期模型、组织过程定义、组织培训、组织过程性能优化与改进、组织革新与部署等。

在工程过程中，现代软件工程新技术和新方法的核心出发点是：建立面向软件开发全过程、面向软件开发全组织的软件开发环境，包括过程规范和相应的控制机制。

过程规范包括生命周期模型的选择、组织过程的定义、培训、度量评价、优化改进等。

控制机制包括建立和组织软件开发项目过程相配套的支持和支撑机制、建立控制和监管软件项目进度的工具以及建立管理软件项目质量的机制。这些机制应能做到：配置和变更管理工具，实现如何在多个成员组成的项目中控制大量的制品(工件)、管理演化系统中的多个变体、跟踪软件创建过程中的不同版本的变更以及发布。软件项目管理机制平衡各种可能产生冲突的目标、管理风险，克服各种约束并成功交付使用户满意的产品等。

4.管理过程的标准和规范

管理过程包括一系列的标准、规范、评审标准等，其中包含针对软件开发的需求管理、配置管理、项目管理、质量管理等。

软件工程技术和工程管理如同现实世界中热恋的情侣，如果他们各自真正认为在这个世界上找到了自己的另一半，那么他们的结合，既是自然的，也是全方位的，绝不是简单的几套体系的合并。而现代软件企业最困难或者也是现代软件工程实践最成功的地方，就是这些体系的有机无缝的衔接。

例如：需求工程中软件需求的获取、分析、处理和验证过程，与项目管理的范围定义和控制、时间管理的WBS分解和基线，与配置管理的配置项识别、选择和确认，需求转化为配置项的状态变化和控制/报告/基线度量，与测试设计和测试组织实施、与质量管理的需求评审等过程，都是紧密联系、相互衔接、协同工作的。

如何从技术和工具层次上打通这些过程之间的信息通道，如何在变更和基线控制层次上，建立这些过程之间统一的、相互衔接和认同的度量标准，如何在总体和各个控制环节上，从不同管理要求的角度，实现对软件开发过程的可度量、有基准、全方位综合的整体管理，是现代软件工程、特别是管理过程的关键。

14.2

开源软件运动

在讨论现代软件工程的时候，特别是在大量的中、小软件企业的开发活动中，不能不谈到开源软件。

14.2.1开源软件的定义与由来

开放源码软件(Open-source-software,Oss)是一个新名词，它被定义为描述其源码可以被公众使用的软件，并且此软件的使用、修改和分发也不受许可证的限制。开源软件促进会(OSI)是通过对开源许可证的官方认可来确定软件的开源属性的。该文件共有10项标准，每项标准的主要意思分别为：

(1)确保软件再发布(redistribute)的自由；

(2)软件发布必须提供源代码；

(3)保障软件使用者对软件修改并形成衍生版本(DerivedWorks)的权利；

(4)保证软件作者源代码的完整性以维护其信誉；

(5)许可证不得歧视任何个人及组织，禁止将某些人排除在软件使用之外；

(6)软件许可证不得限制软件的使用领域；

(7)程序再发布除现许可证外不得有额外要求；

(8)适用于软件整体的许可证也应适用于该软件的部分；

(9)许可证不得限制与该软件一起发布的其他软件；

(10)许可证应保持技术中立，以便许可证能在不同的技术条件下达成。

Oss运动起源于自由软件运动。在国外，早期开发软件的有识之士在1984年提出了一个自由软件运动的计划：软件程序员要把他的产品——软件及其代码开放出来，让大家可以自由地使用、复制分发、研究学习。

因为不满当时大量的软件肆意地添加版权保护从而与金钱挂钩的现象，理查德·马修·斯托曼(RichardMatthewStallman，简称Stallman)首先发起了自由软件运动。自由软件运动的主要项目就是著名的GNU项目。

在这个计划之初，没人肯来帮助他，Stallman就自己先花费了近一年的时间完成了一个GNU软件—GNUEMACS(一个编辑器，类似于一种集成开发环境)。EMACS功能很强大，可以自由地分发拷贝。很快，EMACS就到处流传，并且开始有人帮助EMACS来添加些新功能、修补错误。

1985年，Stallman成立了一个基金会：FSF(FreeSoftwareFoundation，自由软件基金会，网址为)，以筹集资金帮助开发GNU项目。

FSF创立以后，不断接到很多厂商的捐款与赞助，Stallman开始以较低的工资雇用有理想的软件工程师编写GNU项目中的自由软件，他自己是不支薪的。

1985年9月，Stallman正式发表了GNU宣言，并对GNU计划作了更详细的阐述。

1989年，Stallman与一群律师起草了广为使用的GNUGPL(GNUGeneralPublicLicense,GNU通用公共协议证书)，创造性地提出了“反版权”或“版权属左(CopyLeft)”的概念。同时，GNU中的GCC(GNUCCompiler，GNU的C编译器)由于其优越的性能和自由的特点，也获得了巨大的成功。

1990年，所有GNU计划的重要组件均已基本找到或编写，就剩下了操作系统的内核。

1991年，芬兰大学生LinusBenedictTorvalds(林纳斯·本纳第克特·托瓦兹，简称

Linus)在GNUGPL条例下发布了自己编写的操作系统内核，并命名为GNU/Linux或简称Linux。该计划得到了全世界的众多开发者的参与支持，且做到了过去商业软件认为自由软件不可能做到的事—用分散的开发者、没有严格管理与计划的团队通过互联网，开发像内核系统这么复杂的软件。

14.2.2Oss项目的优势与开发经验

1. Oss项目的优势

总的来说，Oss的最大优势是软件信息的共享，有助于整个软件产业的快速发展，这也是Oss能拥有无数的拥护者与巨大动力的根源。但是，在软件业现存的还有闭源软件，也就是传统的软件开发模式，而且闭源软件的开发可以说仍是当今的主导。所以这里具体讨论相对于闭源软件项目，Oss有什么样的优势。

(1)降低风险。软件公司的产品一向是封闭源代码的。试想一下，若软件公司在一夜之间突然人间蒸发，运行的系统就无人维护，随时可能面临更换系统的境地。如果选择开源软件，可以将这种风险降到最低，活跃的开源软件通常会有源源不断的贡献者维护和更新，而且自己可以获取源代码，完全可以按照自己的意愿进行修改，无需担心某一天突然找不到依靠。

(2)产品质量更可靠。闭源软件质量通常与软件公司的开发人员水平息息相关，开发人员的水平通常参差不齐；因此闭源软件的质量通常也是参差不齐，而开源软件通常是由社区中的技术高手在维护，有时用户自身也可以参与维护，并且开源软件的用户较多，软件存在的bug一般都会被及时发现和修补，产品质量更加可靠。

(3)付出少、回报多。削减成本是商业成功至关重要的因素，bug修复、开发功能和编写文档都会消耗大量的人力、物力和财力，如果选择开源软件，这些事情都有人在默默奉献，不需要你付出什么，但却可以享用别人的劳动成果。

(4)降低开发成本—不花冤枉钱。使用开源软件开发一个产品是值得投资的，可以降低开发成本，并可以快速推出自己的产品，然而，许多团队都希望投放到生产环境中的产品能得到支持，于是诞生了许多提供企业级开源产品支持服务的专业型公司，开发团队可以根据自身的情况，有选择性地购买需要的服务。如果选择闭源产品，通常会多花钱，买到自己可能用不上的产品和服务。

(5)招揽优秀人才。开源社区中充满了大量的优秀人才，他们富有激情，才华横溢，乐意为开源软件奉献。试想一下，对开源软件有浓厚兴趣的人加入到你的开发团队，想不提高生产力都难。

(6)行业适应能力更强。因开源软件大多免费的缘故，在中、小型开发团队中迅速得到了广泛使用，这些使用开源软件的开发团队可能来自各行各业，经过长时间的使用，开源软件的适应能力更强，因此无论开发团队属于何种类型，都可放心使用。

(7)产品更透明。由于开源软件是由社区在推动，其透明度很好，bug的发现、新功能的提出都是在一个公开的论坛中进行的，参与者可以随时获取到最新信息，还可以参与进去。开源软件会根据使用者需求不断演变，而不是受限于一家公司的意愿，因此参与者可以了解开源软件的未来发展规划和方向，其透明度比闭源软件高出许多，开发团队可以做到心中有数。

(8)可值得借鉴的软件开发经验。发展开源软件只是作为商业软件的一种补充，为用户提供多一种选择。连微软都表示，要接受开源软件与商业软件“共存”的事实和前景。微软的一位主管认为：应向开源软件学习如何控制并降低软件模块化或集成成本的激增，如何学习社区开发机制的有益经验，如何增加软件的透明度以赢得用户信任度的增加等。

2.开源软件开发的经验

(1)早发布、常发布、听取用户的建议，把用户当作协作开发者和测试人员；

(2)精妙的数据结构和笨拙的代码所构成的组合好于笨拙的数据结构和精妙的代码；

(3)最好的设计是最精简的设计；

(4)好的程序员知道如何写代码，有经验的程序员知道如何重用或重构代码。

3.常见的Oss项目

2000年至今开放源代码运动一直在快速发展，已经有很多好的项目涌现出来。例如日常所用的有以下几个软件：

(1)

Linux：著名的操作系统内核程序。网址：/。

(2)

Apache：开源界最著名的产品之一，Web服务器，推动了Linux与开源产品在服务器领域的应用。网址：/。

(3)

QT：一种跨平台的C++编程平台。由Trolltech公司发布，分为商业版与Opensource版。QT跨平台能力十分优越，一个程序只需很少量的改动就可以在各个平台编译运行。网址：/products/qt/index.html。

(4)

GTK：一个跨平台的C语言图形用户界面工具包。网址：。

(5)

OpenOffice：著名的开源Office办公软件，基本可以和微软的Office系统匹敌。网址：/。

(6)

Firefox：著名的Web浏览器。对IE构成了一定的威胁。网址：/products/firefox/。

(7)

Mplayer：一个著名的多媒体播放器，在底层对于各种系统均作了优化，播放性能十分出众，号称可以播放现存的任何格式的多媒体数据。网址：http://www.mplayerhq.hu/。

(8)

Gimp：一个图形图像编辑软件，类似于Photoshop。网址：。

14.2.3如何看待开源软件

Oss的出发点是让尽可能多的程序设计人员能够阅读、分发和修改软件代码，从而使软件的错误可以得到迅速纠正，增强软件功能，使软件开发从公司行为变为社会行为。

具体来说，可以从以下几个角度来看待开源软件。

1.从用户的角度看

从用户角度来看开源软件的成本，从软件的整体与长期观点而言，开源软件可能需要用户付出更高的成本，这是因为：

更高的产品安装与导入成本、“再”教育训练成本、系统维护成本和开发成本；

程序的开发也许可以靠群体的热情，但吃力不讨好的技术支持就得由用户自己来承担，因为整体成本≠购买成本，整体成本=购买成本+软件部署+教育培训+技术支持+系统未来升级维护+数据转换。

开放源代码的软件拥有更佳的稳定性吗？一般人都以Unix产品的稳定性来想象Linux的稳定，实施的真相可能如下：

开源软件缺少相关的驱动程序的认证，系统文档的保护与内核模式的仿写功能难以保证有关软件的稳定性。

你的用户将会因此被迫牺牲更好的系统效能，硬件的驱动程序要去哪里找？

你的用户需要“即插即用”功能的支持吗？你的用户需要简易的安装与部署吗？

你的用户需要软件自动下载更新的功能吗？

你的用户需要容易上手的安装设置界面吗？还是可以忍受用手工的方式来设定所有的系统功能？

2.从软件产品开发看

任何系统的开发、维护和技术支持都需要成本。

RedHat已不再提供“免费”的Linux版本，否则无法维持庞大的成本。

没有健康的业务模式，使得软件开发厂商无法长期投入经费进行创新研发。

3.从创新的角度看

创新是IT科技进步与IT产业兴旺发展的源动力。

微软每年投入68亿美元从事软件的创新与研发，拉动了整个软件产业的发展。

自由/开源软件的发展，搞活了全球的软件产业，对重组软件产业提出了挑战。

以业务软件模式带动IT产业的成长。

14.3领域工程

领域是领域工程中的一个最基本的专业术语，是指共享某种功能性(Functionality)的系统或应用程序的集合。领域含义中包含了领域工程中的很多属性和方法。在领域工程中，软件开发人员在整个开发过程中要时刻保持与“领域专家”进行沟通、讨论。领域专家不仅需要懂得计算机系统，而且需懂得现实领域知识。

14.3.1基于领域工程的软件开发概述

大多数软件系统可以根据业务领域和它们支持的人物类型来划分类别，例如定期航班预定系统、医学记录系统、证券管理系统、订单处理系统、库存管理系统等。因此，可把根据系统类别而组织的领域称为纵向领域(VerticalDomain)。类似地，也可以根据软件系统部件的功能把它们分类，例如数据库系统、容器库、工作流系统、GUI库、数值代码库等。因此，可把根据软件部件的类别组织的领域称为横向领域(HorizontalDomain)。

领域工程是目前可复用资产基础设施建设的主要技术手段，包含领域分析、领域设计、领域实现三个重要的活动。基于领域工程的软件开发过程如图14-1所示。

如图14-1所示，1)领域分析：在对领域中若干典型成员系统的需求进行分析的基础上，考虑预期的需求变化、技术演化、限制条件等因素，确定恰当的领域范围，识别领域的共性特征和变化特征，获取一组具有足够可复用性的领域需求，并对其抽象形成领域模型；2)领域设计：以领域需求模型为基础，考虑成员系统可能具有的质量属性要求和外部环境约束，建立符合领域需求、适应领域变化性的软件体系结构；3)领域实现：以领域模型和软件体系结构为基础，进行可复用构件的识别、生产和管理。

图14-1基于领域工程的软件开发过程

学术界对领域工程的系统化研究开始于20世纪80年代初期。目前对于领域工程具有代表性的研究和实践工作包括：卡耐基梅隆大学软件工程研究所早期提出的面向特征的领域分析方法和现阶段的软件产品线方法，乔治梅森大学提出的演化的领域生命周期模型，贝尔实验室提出的面向家族的抽象、规约和翻译的领域工程方法，韩国浦项科学与技术大学在FODA方法基础上提出的面向特征的复用方法，惠普实验室综合FODA方法和RSEB方法提出的FeatuRSEB方法，德国FraunhoferInstituteforExperimentalSoftwareEngineering的产品线软件工程方法，以及北京大学提出的青鸟面向对象的领域工程方法等。

14.3.2基于构件的软件工程

基于构件的软件工程(Component-BasedSoftwareEngineering,CBSE)和基于构件的开发(Component-BasedDevelopment,CBD)是一种软件开发的新范型，它是在一定构建模型的支持下，复用构件库中的一个或多个软件构件，通过组合手段高效率、高质量地构造应用软件系统的过程。

CBSE/CBD的工程学目标包括降低费用、方便装配、提高复用性、提高可定制性和适应性、提高可维护性。CBSE/CBD的技术目标是降低构件之间的耦合度，提高构件内诸元素之间的内聚，控制构件的规模。

CBSE强调使用可复用的软构件来设计和改造基于计算机的系统。构件复用是指充分利用过去软件开发过程中基类的成果、知识与经验，去开发新的软件系统，使人们在新系统的开发中着重于解决出现的新问题、满足新需求，从而避免或减少软件开发中的重复劳动。图14-2给出了一个典型的CBSE过程模型。

其中，领域工程的目的是标识、构造、分类和传播一些软件构件，这些构件将适用于某特定领域中现有的和未来的软件系统。

领域工程的总体目标是建立相应的机制，使得软件工程师在开发新系统或改造老系统时可以共享这些构件，即复用它们。领域工程包括三个主要活动：分析、构造和传播。基于构件的开发CBD是一个与领域活动并行的CBSE活动。一旦建立了体系结构，就必须向其中增加构件，这些构件可从复用库中获得，或者根据特定需要开发。因此，CBD的任务流有两条路径：当可复用构件有可能被集成到体系结构中时，必须对它们进行合格性检验和适应性修改；当需要新的构件时，则必须重新开发。构件组装的任务是将经过合格性检验的、适应性修改的以及新开发的构件组装到为应用建立的体系结构中，最后再进行全面的测试。图14-2一个典型的CBSE过程模型

14.3.3领域工程建模过程

1.领域模型(DomainModel)

领域模型是对领域内的概念类或现实世界中对象的可视化表示，又称概念模型、领域对象模型、分析对象模型。领域系统开发人员通过分析整个领域中所有系统之间的共同特征和可变特征，同时对刻画这些特征的对象和操作进行研究、分析，从中抽象出领域系统的需求和操作，从而形成领域模型。领域系统开发人员依据领域模型产生出领域中共同具有的DSSA(特定领域的软件构架)，并进行可重用构件的抽取和开发。构建领域模型是领域工程中的核心环节，也是领域系统需求分析的关键步骤。

领域模型设计的步骤如下：

(1)从领域中所有相关环节的描述中提取领域字典，并对领域字典进行分类；

(2)从领域中提取领域对象，形成操作对象集；

(3)从领域对象集中抽象业务模型，建立问题域的概念；

(4)用UML提供的方法和图例进行领域模型设计、确定模型之间的关系。

2.领域构件的抽取

领域构件的抽取主要是从领域工程中的三个阶段中抽取。

(1)领域分析阶段的构件获取：领域分析是领域工程的重要组成部分。此阶段主要是收集、分析、组织、描述领域中的所有相关信息，并在定义领域边界、明确分析对象、识别信息源等基础上，确定哪些资源可被领域系统共享，从而抽取相应的构件。此阶段抽取的构件主要包含文档说明构件、领域对象构件等。

(2)领域设计阶段的构件获取：领域设计阶段主要是获得领域系统构架DSSA。领域设计是一个高层次的设计，该设计必须适应领域中的所有应用系统需求和领域构件划分。此阶段抽取的构件主要包含各种框架设计构件。

(3)领域实现阶段的构件获取：此阶段主要是对以上两个阶段中获取的领域构件进行实现以及管理。构件的实现可以通过现有的系统中提取得到，也可以通过自行编码开发得到。此阶段抽取的构件主要包含领域框构架件、领域描述构件(用特定的语言描述)和代码构件等。

经过以上三个阶段后，当需要开发一个领域的新应用系统时，就可以像组装产品一样，根据具体的需求，将需要的构件按照应用系统设计去组装形成，而无需从零开始。

3.参与人员

与对应用工程的研究类似，参与领域工程的人员可以划分为四种角色：领域专家、领域分析员、领域设计员和领域实现员。以下将对这四种角色分别通过回答三个问题进行介绍：这种角色由什么人员来充当?他们在领域工程中承担什么任务?他们需要具有哪些技能?

(1)领域专家包括该领域中系统的有经验的用户、从事该领域中系统的需求分析设计、实现以及项日管理的有经验的软件工程师等。主要任务包括提供关于领域中系统的需求规约和实现的知识,帮助组织规范的、一致的领域字典，帮助选择样本系统作为领域工程的依据，复审领域模型、DSSA等领域工程产品等。

(2)领域分析员应由具有知识工程背景的有经验的系统分析员来担任。主要任务包括控制整个领域分析过程，进行知识获取，将获取的知识组织到领域模型中，根据现有系统、标准规范等验证领域模型的准确性和一致性,维护领域模型。

(3)领域设计员应由有经验的软件设计人员来担任。主要任务包括控制整个领域设计过程，根据领域模型和现有的系统开发DSSA，对DSSA的准确性和一致性进行验证，建立领域模型和DSSA之间的联系。

(4)领域实现员应由有经验的程序设计人员来担任。主要任务包括根据领域模型和DSSA，或者从头开发可复用构件，或者利用再工程的技术从现有系统中提取出可复用构件，对可复用构件进行验证，建立DSSA与可复用构件间的联系。领域实现员应熟悉软件复用、领域实现及软件再工程技术，熟悉程序设计，并具有一定的该领域的经验。

14.4敏捷软件开发过程及实践

敏捷一词有轻巧、机敏、迅捷、灵活、活力、高效等含义。2001年，17位软件开发方法学家齐聚一堂，将各自的开发方法进行了汇总，并共同定义了术语敏捷(Agile)。会议最终制定了敏捷软件开发宣言(ManifestoforAgileSoftwareDevelopment)，并确立了一系列敏捷开发方法的价值观念和实用原则。敏捷软件开发涵盖了众多的开发方法，其中包括极限编程XP、自适应软件开发ASD、水晶方法族CrystalMethods、动态系统开发方法DSDM、特征驱动的开发FDD以及SCRUM方法等。

14.4.1敏捷思想与实践原则

现有的软件开发方法大致可分为两类：重型和轻型软件开发方法。重型软件开发方法一般具有严格和详尽的软件开发过程，软件开发需产生大量的文档；而轻型软件开发方法则强调软件开发过程的简洁性和灵活性，软件开发只需编写少量的文档。

敏捷软件开发是一类轻型的软件开发方法，它提供了一组思想和策略来指导软件系统的快速开发并响应用户需求的变化。不同于已有的其他软件开发方法，该方法对软件开发具有以下四个方面的基本认识：

(1)较之于过程和工具，应更加重视人和交互的价值。优秀的软件开发团队离不开人员之间良好的沟通与合作，相比较而言，团队的合作与沟通能力比单纯的编程能力更为重要，改善人员之间的交流与合作将有助于提升团队的软件开发水平。

(2)较之于面面俱到的文档，应更加重视可运行软件的价值。编制过多的文档不仅会耗费大量时间和精力，而且当用户需求变化时难以实现文档与代码的同步。敏捷软件开发方法提倡在软件开发过程中只编写少量短小精炼的文档。

(3)较之于合同谈判，应更加重视客户合作的价值。成功的软件开发不应单纯依赖于合同条款和工作说明，而应将用户和软件开发团队紧密地结合在一起，让用户积极参与软件开发并提供持续不断、频繁的反馈信息。

(4)较之于遵循计划，应更加重视响应用户需求变化的价值。为了适应用户需求的变化，敏捷软件开发认为软件开发计划不应考虑得太远，不要进行过于周密、详细的计划，只应覆盖短期的工作任务，对于中长期的任务只需有一个粗略的规划即可，并根据需求的变化适时地调整计划。

在上述思想的指导下，敏捷软件开发提出了以下十二条原则来指导软件系统的开发：

(1)尽早和持续地交付有价值的软件，以使用户满意。敏捷软件开发最关心的是软件系统的交付。该原则主张迭代性的软件开发，但迭代周期不宜太长。每次迭代结束以后，就向用户交付一个可运行的、实现部分需求的软件产品。

(2)即使到了软件开发后期，也欢迎用户需求的变更。敏捷软件开发主张采用模式、迭代和重构等技术，以适应用户需求的变更，获得软件结构的灵活性。

(3)不断交付可运行的软件系统，交付周期可以从几周到几个月。敏捷软件开发主张软件开发团队应经常性地向用户交付可运行的软件系统，而不是大量的文档或者计划。交付的周期要适宜，太长易使用户失去耐性，软件开发团队也无法从用户处及时获得反馈信息；过短会使用户难以接受持续不断的软件产品版本。

(4)在整个软件项目开发期间，用户和开发人员最好能每天一起工作，及时获得反馈。

(5)由积极主动的人来承担项目开发，给他们提供所需环境和支持，信任他们的能力。

(6)团队内部最有效的信息传递方式是面对面的交谈。敏捷软件开发主张软件开发团队人员之间采用面对面交谈的方式来进行沟通，文档不作为人员之间交流的默认方式，只有在万不得已的情况下，才去编写文档。

(7)将可运行的软件作为衡量软件开发进度的首要衡量标准。

(8)可持续性的开发，出资方、开发方和用户方应当保持长期、恒定的开发速度。不应盲目追求高速，软件开发速度过快可能使软件开发人员陷入疲惫状态，可能会出现一些短期行为，导致给软件项目留下隐患。

(9)关注优秀的技能和良好的设计会增强敏捷性。敏捷的一个重要体现是响应变化的能力。良好的设计是提高软件系统应变能力的关键。

(10)简单化。软件开发工作应着眼于当前欲解决的问题，不要把问题想得太复杂(如去预测将来可能出现的问题)，并采用最为简单的方法去解决它，不要试图去构建那些华而不实的系统。

(11)最好的构架、需求和设计出自于自组织的团队。

敏捷团队应当是自组织的，以适应需求的变化。软件开发任务不是从外部直接分配到团队成员，而是交给软件开发团队，然后再由团队自行决定任务应当怎样完成。敏捷团队所有成员对于软件项目的所有部分都有权参与。

(12)软件开发团队应定期就如何提高工作效率的问题进行反思，并进行相应的调整。

根据上述敏捷思想与实践原则，敏捷软件开发应更加适合于小规模软件开发团队，因为过多的软件开发人员势必会使得软件开发人员之间的交流变得非常复杂；同时也使它更加适合于需求易变的软件系统的开发，从而充分发挥该方法的技术优势。

14.4.2支持敏捷软件开发的技术和管理手段

从技术的角度来看—敏捷思想和实践原则对软件系统的开发提出了以下一组要求：尽快开发出可运行的软件系统；当用户需求改变时应迅速地响应变化；获得良好的软件设计，以便当需求变化时对软件设计进行不断的调整和优化；保证软件系统的质量；提高敏捷软件开发的效率等。现阶段软件工程领域有以下一组技术可以有效地满足上述要求，支持敏捷软件开发。

1.测试驱动开发

测试驱动开发要求软件开发人员在编写程序代码之前，先确定和编写好测试。或者说，软件开发人员首先要思考如何对某个功能进行测试，设计好相应的测试用例，编写好相关的测试代码，然后编写相应的程序代码以通过软件测试。该技术支持软件系统功能的逐步实现，有助于保证任何程序代码都是可测试的，从而确保软件系统的质量。见本章14.5节。

2．敏捷设计

敏捷软件开发对软件系统的设计提出了更高的要求。为了支持用户需求的动态变化以及由此而引发的对软件设计的持续调整和优化，软件系统的设计应易于改动和调整，具有稳固性、可理解性、简单性、干净性和简洁性等特点。

针对这一要求，RobertC.Martin提出一组支持敏捷软件开发的设计原则，包括：①单一职责原则，每个模块只具有一个职责，主要体现模块的内聚度；②开放封闭原则，扩展时无需更改模块的源代码和可执行代码，要尽可能利用抽象类，以体现软件设计的灵活性和可重用性；③依赖倒置原则，抽象不应该依赖细节，细节应依赖于抽象；④接口隔离原则，使用多个专门的接口比使用单一的总接口要好，因为这样会职责分离、分工明确。

3.模式运用

充分利用各种成熟模式，包括体系结构模式和设计模式来进行软件系统的设计，以支持软件系统的可重用性和应对用户需求的变化。

4.快速原型技术

快速原型技术有助于迅速生成软件系统的原型，并以此为媒介支持软件开发人员和用户之间的交流和沟通，促使软件开发人员关注于用户的需求，适应用户需求的动态变化，帮助软件开发人员尽快从用户处及时获得反馈信息。

5.模型驱动软件开发技术—MDA技术

MDA强调将软件系统的功能规约与实现这些功能的技术和平台相分离，它区分两类不同的软件系统模型：平台无关的模型和平台相关的模型，并通过模型映射在不同模型之间建立桥梁，从而有助于保护用户的业务模型，促进软件系统的快速开发和部署。

6.计算机辅助软件工程(CASE)工具

目前已有许多支持敏捷软件开发的软件工具，包括由Microtool公司研发的ActifExetreme，它支持敏捷过程管理；由Ideogramic公司开发的IdeogramicUML，它支持针对敏捷过程的UML建模；由Borland公司开发的TogetherToolSet，它支持敏捷开发和极限编程中的诸多活动等。

从管理的角度来看，敏捷思想和实践原则对软件系统的开发提出了以下一组要求：管理好用户的需求；确保软件过程支持持续性的交付软件系统；管理好软件开发团队；支持软件开发人员和用户之间的交流、合作以及问题的及时反馈；以人为本，充分发挥人的积极性和主动性；保证软件开发速度的稳定性和持续性；不断改进和优化软件开发团队等。为了应对这些要求，基于敏捷软件开发方法的软件项目应遵循以下管理方法。

(1)软件过程模型的选择。基于敏捷软件开发方法的软件项目组应选择那些支持渐进、迭代开发的软件过程模型，如迭代模型、螺旋模型、RUP和快速原型等。

(2)团队建设。基于敏捷软件开发方法的软件项目开发团队应充分发挥人的主体作用，将用户作为软件开发团队中的成员，并与软件开发人员一起工作和交流；支持团队成员，尤其是开发人员和用户之间的双向交流和沟通。

(3)需求管理。尽管用户需求在整个软件开发过程中是动态变化的，但是每次迭代欲实现的用户需求应该是稳定的，所生成的需求文档应处于受控状态，与项目计划、产品和活动相一致，并作为开展软件开发工作的基础。软件开发人员通过和用户的充分和持续性交流，支持需求确认和评审。

(4)软件项目计划。软件开发人员和用户一起参与计划的制定，包括估算规模和进度、确定人员分工。软件项目计划不应过细，应保留一定的灵活性。多个迭代欲实现的系统功能和迭代周期要大致相当，防止软件开发周期的剧烈变化，支持稳定和可持续的软件开发。此外，每次迭代的软件开发周期要适中，不宜过长，否则用户会失去耐心，无法及时得到反馈；也不宜过短，否则用户难以消化，同样影响反馈。

(5)跟踪监督。在对敏捷软件开发项目的跟踪和监督过程中，软件项目管理人员要特别关注以下软件风险：①对规模和工作量的估算过于乐观，该软件风险将影响项目的周期性迭代；②软件开发人员和用户之间的沟通不善，该软件风险将可能导致软件需求得不到用户的认可和确认；③需求定义不清晰和不明确，该软件风险将可能导致需求不清，所开发的软件系统和用户要求不一致；④项目组成员不能有效地在一起工作，该软件风险将可能导致软件开发效率和软件项目组敏捷度的下降；⑤任务的分配和人员的技能不匹配，该软件风险将导致软件开发不能做到以人为本；⑥软件设计低劣，该软件风险将可能导致所开发的软件系统无法适应用户需求的不断变化和调整等。

14.4.3极限编程

极限编程(ExtremeProgramming,XP)是由KentBeck在1996年提出的一种特殊的敏捷软件开发方法，它提出了更加具体和实际的指导方法以支持软件系统的敏捷开发。极限编程将其价值观归结为四条：①交流，侧重于基于口头(而不是文档、报表和计划)的交流；②反馈，主张通过持续、明确的反馈来获得软件的状态；③简单，主张用最简单的技术来解决当前的问题；④勇气，强调快速开发并在必要时具有重新进行开发的信心。

在此基础上，极限编程定义了五条指导原则和十二条必须遵循的核心准则。按照极限编程创始人KentBeck的观点，极限编程并没有引入任何新的概念，它的创新之处在于：将经过数十年检验的准则结合在一起，确保这些准则相互支持并能够得到有效执行。

1.指导原则

极限编程的四条价值观构成了整个方法学的基础，在此基础上极限编程引出了五条原则作为行为与实践的指南。

(1)快速反馈。极限编程要求软件开发人员从用户那里快速得到有关软件系统的反馈情况，比如软件开发人员通过小步迭代迅速了解用户的反应，以确认当前所做的开发工作是否满足用户的需求，通过经常性的自动化测试和集成迅速了解软件系统的运行状况。

(2)简单性假设。极限编程要求软件开发人员只考虑当前迭代所面临的问题，无需考虑将来(如下一次迭代)所面临的问题，并且用简单的方法和技术来解决问题。

(3)逐步更改。极限编程要求通过一系列细微的修改来逐步解决问题和完善系统，不要期望一次迭代就开发出一个完整的软件系统。

(4)支持变化。极限编程要求在软件开发过程欢迎用户改变需求，支持用户需求的动态变化。

(5)高质量的工作。极限编程要求采用诸如测试驱动开发等技术高质量地开展工作，确保所开发软件系统的质量。

2.核心准则

极限编程总结出的十二条核心准则在日常的软件开发中已大多为人们所采用，然而单独采用某些准则却有可能会导致混乱，极限编程的独特之处在于将这些核心准则有机结合在一起达到最佳效用。

(1)计划游戏(PlanningGame)。旨在帮助软件开发团队快速制定下一次迭代的软件开发计划。参与计划游戏的人员包括软件开发人员和业务人员。

(2)隐喻(Metaphor)。是指使用一组与业务相关的术语来描述用户需求，促使软件开发人员和业务人员对系统达成共同和一致的理解，该准则有助于加强他们之间的沟通和合作，及时从用户处获得反馈并支持用户更好地参与到软件项目之中。

(3)小型发布。经常性地给用户发布能给他带来业务价值的可运行软件系统，每次发布的软件系统仅提供少量的功能。小型发布不仅有助于缩短软件开发周期，提高软件开发小组对软件开发进度的估算能力和精度，也有助于从用户处获得对软件系统使用情况的真实反馈信息。

(4)简单设计。是指程序代码能够运行所有的测试、没有重复的逻辑、清晰地反映程序的意图、包含尽可能少的类和方法。与大多数传统软件开发方法不同的是，极限编程要求只为当前的需求做设计，而不必考虑将来可能的需求。过多考虑将会增加不必要的成本和开销。

(5)测试驱动开发。极限编程要求测试应在编写代码之前进行，而不是等到开发结束后再安排一个专门的阶段对软件系统进行测试。实践表明，采用极限编程的这种测试方法能使软件系统的质量不断得到提高。见本章14.5节。

(6)重构—重整和优化(Refactoring)。是指在不改变程序代码功能的前提下，改进程序代码的设计，使程序代码更加简单，更易于扩展。极限编程通过重构使软件系统具有灵活的结构，易于接受变化。

(7)结对编程。是指两名程序员同时在一台计算机上共同开展编程工作。其优势在于：

①软件开发过程中的每一项决定都至少由两个人来共同完成，对系统的每一部分至少有两个人熟悉，这可以降低人员流动带来的软件风险；

②在进行结对编程过程中，一人着眼于实现细节，而另一人则可以从全局的角度进行考虑，可以有效地分离关注视点，有助于对软件系统的开发进行全面的考虑；

③有助于在编码的同时进行代码复审，有助于提高程序代码的质量；

④参与结对编程的程序员之间相互讨论，可以强化知识共享。

(8)代码集体拥有。是指开发小组的任何成员都可以查看并修改任何部分的代码。代码集体拥有与结对编程、编码标准等极限编程准则是相辅相成的，如果没有这些准则的支持而单独采用代码集体拥有，将使软件项目陷入混乱。

(9)渐进式持续集成。不要等到所有软件模块完成之后再进行软件系统的集成，而是应经常性地进行集成。集成的周期应当尽可能短，可能是几个小时或者几天(而不是几周或几个月)集成一次。

(10)每周工作40小时。极限编程倡导质量优先，不主张为了追求开发速度而片面延长工作时间，即使程序员自愿，也不提倡加班。

(11)把现场用户作为开发团队成员。极限编程要求用户代表在现场办公，参与软件开发的全过程，确保软件开发人员能够及时得到交流与反馈信息。

(12)编码标准与规范。在软件开发过程中，程序员遵循统一的编码标准，这有助于提高软件系统的可理解性和可维护性。例如，代码集体拥有允许每个软件开发人员都可修改每个模块的程序代码，如果没有统一的编码标准，这种修改必将导致混乱。

综上所述，XP很像一个由很多小块拼起来的智力拼图，单独看每一小块都没有什么意义，但拼装好后，一幅美丽的图画就会呈现在你面前。

14.4.4其他敏捷软件开发方法

1.自适应软件开发(AdaptiveSoftwareDevelopment,ASD)

ASD由JimHighsmith在1999年正式提出。其思想主要来源于复杂系统的混沌理论。ASD自适应软件开发过程的生命周期包括三个阶段：思考(自适应循环策划及发布时间计划)、协作(需求获取及规格说明)、学习(构件实现、测试及事后剖析)。

2.水晶方法族(CrystalMethods,CM)

CM由AlistairCockburn在20世纪90年代末提出。其核心思想是：不同类型的项目需要不同的方法，它们包含具有共性的核心元素，每一个都含有独特的角色、过程模式、工作产品和实践。虽然水晶系列不如极限编程XP有那样好的生产效率，但会有更多的人接受并遵循它的过程原则。

3.动态系统开发方法(DynamicSystemDevelopmentMethod,DSDM)

DSDM倡导以业务为核心，快速而有效地进行系统开发。实践证明：DSDM是成功的敏捷开发方法之一。DSDM不但遵循了敏捷方法的原理，而且也适合于那些坚持成熟的传统开发方法又具有坚实基础的软件开发团队。DSDM的生命周期包括：可行性研究、业务建模、功能模型迭代、设计和构建迭代、实现迭代。

4.特征驱动的开发(FeatureDrivenDevelopment,FDD)

FDD由PeterCoad、JeffdeLuca、EricLefebvre共同提出，是一套针对中、小型软件开发项目的开发模式。此外，FDD是一个模型驱动的快速迭代开发过程，它强调的是简化、实用。FDD易于被开发团队接受，适用于需求经常变动的项目。FDD方法定义了五个过程活动：全局模型开发、特征列表改造、特征计划编制、特征设计与特征构建。

5. SCRUM方法

SCRUM是一种迭代式增量化软件开发过程，通常用于敏捷软件开发。SCRUM在英语的意思是“橄榄球的争球”，该方法由KenSchwaber和JeffSutherland提出，旨在寻求充分发挥面向对象和构件技术的开发方法，是对迭代式面向对象方法的改进。它是一个包括了一系列实践和预定义角色的经验化过程骨架，产品负责人代表利益所有者，开发团队包括了所有开发人员，它使得团队成员能够独立地、集中地在创造性的环境下工作。SCRUM过程流包括：产品待定项、冲刺待定项、待定项的展开与执行、每日15分钟例会、冲刺结束时对新功能的演示。

相较传统的软件开发模型(瀑布模型)，Scrum的优势在于：

(1)采用迭代式开发，有效降低软件开发的风险；

(2)灵活应付软件开发中的变更，注重团队成员之间的沟通；

(3)明确的产出物，相较于传统的开发模型，敏捷模型能够减轻开发人员的负担；

(4)每阶段的目标明确，有能够被认同的产出物，提升团队对产品的认知与成就感。

14.5测试驱动开发

测试驱动开发方式能够编写出更加简单、更易于理解和维护的程序代码，有助于提高程序代码的质量，而且当它与敏捷软件开发方法、极限编程和重构技术等相结合时，有助于获得简单和健壮的软件设计。．

14.5.1测试驱动开发思想

测试驱动开发是指在编写程序代码之前，首先确定和设计好测试(在明确要开发某个软件功能后，程序员首先要思考如何对这个功能进行测试，设计好相应的测试用例并编写好相关的测试代码)，然后再编写与该软件功能相对应的程序代码，以运行测试程序来对程序代码进行测试。如此循环反复，直至实现软件系统的全部功能。

传统的软件测试方法往往会存在以下几个方面的问题：

(1)当程序员编写完代码后，由于赶进度，经常没有足够的时间对代码进行详尽和充分的测试。如果测试不够充分，那么代码中就会遗留许多未知的软件故障和bug等。

(2)如果测试人员是基于相关的文档(而不是代码)来设计测试用例和编写测试代码的，那么当这些文档与代码不一致时，对代码进行的测试就会存在诸多问题，如设计的测试用例不正确、与代码不一致等。

(3)测试通常是在代码编写完后才进行的，无法保证编写程序和软件测试同步进行。

(4)对于许多程序员而言，更愿意编写程序代码，而不愿测试程序。因为编写程序是一个创造和生产的过程，让他们觉得有成就感；而测试通常被视为是一件乏味的工作。

测试驱动开发的精髓在于：将软件测试方案的设计工作提前到编写程序代码之前；从测试的角度来验证、分析和指导设计；同时将测试方案当作程序编码的准绳，有效地利用它来检验程序编码的每一个步骤，及时发现其中的问题，实现软件开发的“小步快走”。因此，测试驱动开发具有以下特点：

(1)根据测试来编写代码。

测试驱动开发强调：首先编写出用于测试某项功能是否符合要求的测试项(包括测试代码和测试用例等)，然后再去编写相应的程序代码来实现这一功能。因此，它体现了一种由测试来驱动软件开发的思想。

(2)程序员设计并维护一组测试，编写测试的目的不仅仅是为了测试程序代码能否正常工作，而且被用于定义程序代码的内涵。

例如，假设要编写一个列表类List。传统的做法是先编写完列表类的所有程序代码(包括其所有的属性和方法)，然后设计测试用例和编写测试代码对它进行测试。在测试驱动开发中，其过程正好相反。程序员首先要确定和设计一个测试，如空列表的长度应该为0，并编写以下的测试代码。

PublicvoidtestEmptyList(){

ListemptyList=newList();

assertEquals(“Thesizeofemptylistshouldbe0”,0,emptyList.size());

}

程序员然后将测试作为列表类的一种行为规约来指导列表类程序代码的编写。根据上述测试用例和测试代码的描述，程序员首先要实现和编写List类的方法size()，对于任何空列表而言，该方法的返回值均为0。

(3)确保任何程序代码都是可测试的。

由于在测试驱动开发中，程序员首先考虑的是如何测试软件系统的功能(即确定和编写测试)，然后再考虑如何实现系统的功能(即编写程序代码)，因此，测试驱动开发可以确保所有的程序代码都是根据程序员所设计的测试集来编写的，所编写的任何程序代码都是可测试的。这有助于有效地发现程序代码中的故障、提高软件系统的质量。

测试驱动开发应遵循的原则：

①测试隔离。不同代码的测试应该相互隔离。对某一代码的测试只考虑此代码本身，不要考虑其他的代码细节。

②任务聚焦。在测试驱动开发过程中，程序员往往需要实施多种不同形式的工作并进行多次的迭代，比如设计测试用例、编写测试代码、编写程序代码、对代码进行重构、运行测试等。在此情况下，程序员应将注意力集中在当前工作(即当前欲完成的软件功能)，而不要考虑其他方面的内容，无谓地增加工作的复杂度。

③循序渐进。一个软件模块的功能很多，程序员应该针对软件模块的功能，设计相应的测试，并形成测试列表。然后根据测试列表不断地完成相应的测试用例、测试代码和功能代码，逐步完成整个软件模块的功能。这种循序渐进的做法可以防止疏漏，避免干扰其他工作。

④测试驱动。要实现某个功能、编写某个类，程序员首先应编写相应的测试代码和设计相应的测试用例，然后在此基础上编写程序代码。

⑤先写断言。在编写测试代码时，程序员应首先编写对功能代码进行判断的断言语句，然后再编写相应的辅助语句。

⑥及时重构。程序员在编码和测试过程中应对那些结构不合理、重复的程序代码进行重构，以获得更好的软件结构，消除冗余代码。

与传统的软件编码和测试方式相比较，测试驱动开发具有以下优点：①编码完成后即完工。在程序代码编写完成并通过测试之后，意味着编码任务的完成。而在传统的方式中，由于编码完成之后需要进行单元测试，因而很难知道什么时候编码任务结束。②易于维护。软件系统与详尽的测试集一起发布，有助于将来对程序进行修改和扩展，并在开发过程中及时对程序代码进行重构，提高了软件系统的可维护性。③质量保证。任何程序代码都经过了测试，有助于有效地发现程序代码中的错误，提高软件系统的质量。

14.5.2支持测试驱动开发的软件工具

可支持测试驱动开发的软件工具包括cppUnit、csUnit、CUnit、DUnit、DBUnit、JUnit、NDbUnit、OUnit、PHPUnit、PyUnit、NUnit、VBUnit等。

JUnit是一个由ErichGamma和KentBeck二人共同开发的开源Java单元测试框架。JUnit框架提供了一组类来支持单元测试。通过继承重用这些类，程序员可以方便地编写测试程序代码，运行测试程序以发现程序代码中的故障。JUnit的主要类结构如图14-3所示。

图14-3JUnit的主要类结构

(1)

Test接口。所有测试类(包括TestCase和TestSuite)必须实现该接口。Test提供了两个方法：countTestCase方法用于计算一个测试将要运行的测试用例的数目；run方法用于运行一个测试并收集它的测试结果。

(2) Assert。该类定义了软件测试时要用到的各种方法。例如assertEquals方法用于判断程序代码的运行结果是否等同于预期结果；assertNull和assertNotNull方法用于判断对象是否为空等等。

(3)

TestCase。TestCase类实现了Test接口并继承Assert类，它是程序员在编写测试程序时必须扩展的类。通过继承，程序员可以方便地利用该类提供的方法对程序单元进行测试。

(4)

TestSuite。TestSuite类实现了Test接口并提供了诸多方法来支持测试，当程序员试图将多个测试集中在一起进行测试时必须扩展该类。

目前，许多软件开发工具和环境(如Eclipse)集成了JUnit以支持软件测试。JUnit具有以下特点：①提供了一组API，支持程序员编写可重用的测试代码；②提供了多种方式(文本或者图形界面)来显示测试结果；③提供了单元测试用例成批运行的功能；④超轻量级而且使用简单；⑤整个框架设计良好，易于扩展。

14.5.3测试驱动开发过程

测试驱动开发的思想非常朴素和简单，就是根据要实现的功能编写测试，然后根据测试来编写程序代码，最后运行程序代码以通过测试。测试驱动开发的过程如图14-4所示。

图14-4测试驱动开发的过程

14.6现代软件工程其他新方法

1.模型驱动体系结构(MDA)软件开发方法

(1)

MDA方法的提出。复杂软件系统的开发面临着两方面关键问题的解决。首先，当业务需求发生变化时，如何关注于变化了的业务需求，并根据所选择的技术和平台，尽快生成相应的软件系统；其次，当实现系统的方法、技术和平台发生变化时(如从C++转为EJB/J2EE)，如何根据系统的业务需求模型，快速生成基于新方法、新技术和新平台的软件系统。

由对象管理组织(ObjectManagementGroup,OMG)提出和倡导的模型驱动体系结构(ModelDrivenArchitecture,MDA)方法通过将业务需求与实现业务需求的技术相分离，可以有效地促进上述两个问题的解决。

(2)

MDA的思想。该方法强调将软件系统的功能规约与实现这些功能的技术和平台相分离，并与OMG所推出的各种技术标准相融合。MDA将软件系统的模型分为两类：一类是平台无关的模型(PlatformIndependentModel,PIM)，另一类是平台相关的模型(PlatformSpecificModel,PSM)。这里所指的平台是指一系列子系统和技术的集合，它们通过各种特定的接口和使用模式为应用系统的开发和运行提供一组相关的功能，如J2EE、COBRA、VisualStudioC++、.Net/C＃等。

MDA方法实际上是OMG所提出的(ObjectManagementArchitecture,OMA)技术的演化，它们都想解决软件系统的集成和互操作问题，并试图将这一问题的解决贯穿于软件系统的整个生命周期，包括建模、分析、设计、构造、组装、集成、发布、管理和演化。MDA的上述思想体现了OMG关于软件系统开发的四个基本原则：

①定义良好的系统模型(符号表示模型)是理解和开发软件系统的基础；

②软件系统的开发是一个建立软件系统模型、实现不同系统模型之间相互转换的过程；

③元模型是描述和分析系统模型的形式化基础，它有助于促进系统模型之间的集成和转换，是通过工具实现软件开发自动化的基础；

④接受和采纳基于模型的软件开发方法需要工业界的技术标准，从而为用户提供开放性，促进开发商之间的竞争。

为了支持上述原则，MDA试图与现有的各种软件开发技术标准相集成。图14-5描述了MDA与一组软件开发技术标准之间的关系。图的中心部分描述了支持MDA的三种OMG建模语言：UML，MOF(Meta-ObjectFacility)和CWM(CommonWarehouseMeta-Model)，它们通常是建立平台无关模型的主要表示工具。UML是OMG推出的面向对象建模语言，它基于对象技术，提供了一组元概念和可视化的模型，对不同视点(如结构视点和行为视点等)、不同抽象层次的系统模型进行建模。

MOF不仅提供了模型的标准化仓库，而且定义了相应的结构来支持不同软件开发小组能够针对这些模型一起开展工作。CWM为数据存储集成提供了工业标准，可用于表示各种数据模型(模式)、模式转换、OLAP和数据挖掘模型等。图14-5的中间层部分描述了一组支持MDA的、与目标平台相关的技术，包括WebServices、CORBA、Java(包括企业JavaBeans/J2EE)、C#/.NET、XML/XMI/SOAP等。借助于诸如普适计算、目录、安全、事件、事务等一组服务，MDA方法可用于支持诸如电子商务、金融、电信、医疗、交通、制造等应用领域的开发。

图14-5OMG的模型驱动体系结构

MDA的核心是要将商