2．3．2　演化过程模型

演化过程模型是一种全局的软件生存周期模型，属于迭代开发的模型。该模型的基本思想为：根据用户的基本需求，通过快速分析构造出该软件的原型，然后根据用户在使用原型过程中提出的意见和建议对原型进行改进，获得原型的新版本。重复这一过程，最终可以得到令用户满意的软件产品。该模型可以表示为

第一次迭代（需求→设计→实现→测试→集成）→反馈→第二次迭代→反馈→……

本小节主要介绍三种演化过程模型：原型模型﹑螺旋模型与协同开发模型。

1．原型模型

原型就是可以逐步改进成运行系统的模型。开发者在初步了解用户需求的基础上，凭借自己对用户需求的理解，通过强有力的软件环境支持，利用软件快速开发工具，构成﹑设计和开发一个实在的软件初始模型（原型，一个可以实现的软件应用模型）。利用原型模型进行软件开发的流程如图2－3所示。相对瀑布模型，原型模型更符合人们开发软件的习惯，是目前较流行的一种实用软件生存模型。

图2－3　原型模型

1）原型模型的优点

（1）开发人员和用户在“原型”上达成一致。这样一来，可以减少设计中的错误和开发中的风险，也减少了对用户培训的时间，从而提高了系统的实用性﹑正确性及用户满意度。

（2）原型模型采用逐步求精的方法完善原型，使得原型能够快速开发，避免了像瀑布模型一样冗长的开发过程中难以对用户的反馈作出快速响应。

（3）原型模型通过“样品”不断改进，降低了成本。

（4）原型模型的应用使人们对需求有了渐进的认识，从而使软件开发更有针对性。另外，原型模型的应用充分利用了最新的软件工具，使软件开发效率大为提高。

2）原型模型的缺点

虽然用户和开发者都非常喜欢原型模型，因为它使用户能够感受到实际的软件系统，开发人员能很快建造出一些内容。但该模型仍然存在着一些问题，其原因如下。

（1）用户看到的是一个可运行的软件版本，但不知道这个原型是临时搭建起来的，也不知道软件开发者为了使原型尽快运行，并没有考虑软件的整体质量或以后的可维护性问题。当被告知该产品必须重建才能使其达到高质量时，用户往往叫苦连天。

（2）开发人员常常需要在实现上采取折中的办法，以使原型能够尽快工作。开发人员很可能采用一个不合适的操作系统或程序设计语言，仅仅因为它通用或有名，也可能使用一个效率低的算法，仅仅为了实现演示功能。经过一段时间之后，开发人员可能对这些选择已经习以为常了，忘记了它们不合适的原因。于是，这些不理想的选择就成了软件的组成部分。

虽然会出现问题，但原型模型仍是软件工程的一个有效典范。使用原型模型开发系统时，用户和开发者必须达成一致：原型被建造仅仅是用户用于定义需求，不宜利用它来作为最终产品，之后被部分或全部抛弃，最终的软件是要充分考虑了质量和可维护性等方面之后才被开发。

2．螺旋模型

对于复杂的大型软件，开发一个原型往往达不到要求。螺旋模型将瀑布模型和原型模型结合起来，这不仅体现了两个模型的优点，而且还增加了两个模型都忽略了的风险分析，弥补了两者的不足。

1）螺旋模型的结构

螺旋模型的结构如图2－4所示，它由4部分组成：制订计划、风险分析、实施开发和客户评估。在笛卡儿坐标的4个象限中分别表达了4个方面的活动。

沿螺旋线自内向外每旋转一圈便开发出一个更为完善的新的软件版本。例如，第一圈时，在制订计划阶段，确定了初步的目标、方案和限制条件以后，转入风险分析阶段，对项目的风险进行识别和分析。如果风险分析表明需求有不确定性，但是可以承受风险，那么在实施开发阶段，所建的原型会帮助开发人员和用户对需求做进一步的修改。软件开发完成后，客户会对工程成果做出评价，给出修正建议。在此基础上进入第二圈螺旋，再次进行制订计划、风险分析、实施开发和客户评估等工作。假如风险过大，开发者和用户无法承受，那么有可能终止项目。多数情况下，软件开发过程是沿螺旋线的路径连续进行的，自内向外，逐步延伸，最终总能得到一个用户满意的软件版本。

图2－4　螺旋模型

2）螺旋模型的优点

螺旋模型的优点在于：设计上的灵活性，可以在项目的各个阶段进行变更；以小的分段来构建大型系统，使成本计算变得简单容易；客户始终参与每个阶段的开发，保证了项目不偏离正确方向及项目的可控性；随着项目推进，客户始终掌握项目的最新信息，从而能够与管理层有效地交互；客户认可这种公司内部的开发方式带来的、良好的沟通和高质量的产品。

3）螺旋模型的缺点

螺旋模型的缺点在于：很难让用户确信这种演化方法的结果是可以控制的；建设周期长，而软件技术发展比较快，所以经常出现软件开发完毕后，与当前的技术水平有较大的差距，无法满足当前用户的需求。

螺旋模型不仅保留了瀑布模型中系统地、按阶段逐步地进行软件开发和“边开发、边评审”的风格，而且还引入了风险分析，并把制作原型作为风险分析的主要措施。用户始终关心、参与软件开发，并对阶段性的软件产品提出评审意见，这对保证软件产品的质量是十分有利的。但是，螺旋模型的使用需要具有相当丰富的风险评估经验和专门知识，而且开发费用昂贵，所以只适合大型软件的开发。

3．协同模型

从程序设计的角度来说，协同就是通过将一组主动的片断黏合起来的方式来构建程序的过程。因此，可以将程序看成“程序＝协同＋计算”，以倡导在分布式程序设计中将分布的协同与局部的计算分离的思想。

通常意义上提到的软件协同技术包含两个层次的意思：一是其协同模型；二是该协同模型的软件实现。协同模型作为绑定一组分离的活动为一整体的黏合剂，为主动独立的协同实体之间交互的表达提供一个框架。它通常涉及被协同实体的创建与撤销、实体间的通信、实体的空间分布及它们活动的同步和时间安排等。

1）协同模型的描述

在描述协同模型的组成时，主要从以下三个部分进行研究。

（1）协同实体是并发运行的活动实体，它们是协同的直接主体，同时也是协同体系结构中的基本模块。这些被协同的实体（实际是指其类型），如对象、进程、线程、Web服务等，甚至可以包括一个软件和用户。

（2）协同媒介是将协同实体连接起来的媒介。它是协同发生的实际空间，支持协同实体间的通信，如信号量、通道，以及元组空间、消息、事件等。

（3）协同法则具体描述了模型框架的语义，即描述协同实体如何利用一组协同原语通过协同媒介进行协同的法则。

2）协同模型的分类

通常将协同模型分为如下三类。

（1）数据驱动的协同模型。该类模型关注的主要是协同实体之间的数据交换。这类协同模型大多要用到共享的数据空间。协同实体除了需要完成自身的计算任务之外，还需要通过调用协同原语从外界（数据空间）获取数据或向外界提供数据，以此来与其他实体协同。

（2）控制驱动协同模型。该类模型关注的是协同实体间的控制流程。通常协同实体被视为一个具有良好接口定义的黑盒。协同实体只需从自己的接口（常称为端口）获得输入数据，计算处理后放到自己的端口上，而（至少在形式上）无须考虑与其他实体的协同。

（3）混合驱动协同模型。该类模型不仅关注协同实体之间的数据交换，同时也关注协同实体之间的控制流程。协同模型的实现方式不局限于某种协同语言，利用可编程的软件协同技术，也可以实现这种体系结构。