1.4.2　以面向对象的建模为基础的开发模式

正如任何事物一样，软件也有其孕育、诞生、成长、成熟和衰亡的生命过程，我们称其为“软件的生命周期”。软件的生命周期可以分为六个阶段，即制定计划、需求分析、设计、编码、测试、运行和维护。软件开发可以采用多种途径进行开发。软件开发模式是跨越整个软件生命周期中系统开发、运行和维护所实施的全部工作的框架，它给出了软件开发活动各个阶段之间的关系。软件项目可以遵循不同类型的开发过程，目前，可以将常见的软件开发模式大致可分为如下的4种类型：

（1）在第一代软件开发过程模式中，软件需求是要求完全确定的，如瀑布模型等。这类开发模式的特点是软件需求在开发阶段已经基本上被完全确定，软件生命周期的各项活动按顺序固定，软件开发按阶段进行。其缺点是如果在开发后期要改正早期已经存在的问题，那么需要付出昂贵的代价，从用户这个角度来讲，开发需要等待较长时间才能够看到软件产品，这样大大增加了软件开发的风险系数。

（2）由于第一代软件开发过程模式的改进，诞生了在开始阶段只提供基本需求的渐进式开发模型，如喷泉模型和演化模型等。这类开发模型的特点是软件开发的开始阶段只需要提供基本的需求，软件开发过程的各个活动是迭代的，所以也被称为迭代式开发。通过迭代过程实现软件的逐步演化，最终得到软件产品。在此引入了风险管理，采取早期预防措施，增加了项目成功的几率，提高了软件质量；其缺点是由于在开始阶段需求的不完全性，对于软件的总体设计带来了困难，从而也削弱了产品设计的完整性，这对风险技能管理水平带来了很大的挑战。

（3）以体系结构为基础或基于构件的开发模型，如基于构件的开发模型和基于体系结构的开发模型等。这类模型的特点是首先利用获取的需求分析结果来设计出软件的总体结构，然后通过基于构件的组装方法来构造软件系统。这样软件体系结构的出现使得软件的结构框架更清晰，有利于系统的设计、开发和维护。

（4）轻量级的开发模型，这种开发模型强调适应性而非预测性、强调以人为中心，而不以流程为中心，以及对变化的适应和对人性的关注，其特点是轻载、基于时间、紧凑、并行并基于构件的软件开发过程。在所有的敏捷方法中，XP（eXtreme Programming）方法是最引人注目的一种轻型开发方法。

以下将简单地分析瀑布模型、喷泉模型、基于构件的开发模型、XP（eXtreme Programming）方法等软件开发模型。

1．瀑布模型

瀑布模型也被称为生命周期模型，其核心思想是按照相应的工序将问题进行简化，将系统功能的实现与系统的设计工作分开，便于项目之间的分工与协作，即采用结构化的分析与设计方法将逻辑实现与物理实现分开。瀑布模型将软件生命周期划分为项目计划、需求分析、软件设计、软件实现、软件测试、软件运行和维护这6个阶段，并且规定了它们自上而下的次序，如同瀑布一样下落，每一个阶段都是依次衔接的。采用瀑布模型的软件开发过程如图1-7所示。

瀑布模型是最早出现的软件开发模型，在软件工程中占有重要的地位，它提供了软件开发的基本框架。它的过程是从上一项活动接收该项活动的工作对象作为输入，利用这一输入实施该项活动应完成的内容，然后给出该项活动的工作成果，并作为输出传给下一项活动。同时评审该项活动的实施，若确认，则继续下一项活动；否则返回到前一项，甚至更前面的活动。

瀑布模型为项目提供了按阶段划分的检查点，这样有利于在软件开发过程中人员的组织及管理。瀑布模型让项目人员在当前阶段完成后，才去关注后续阶段，这样有利开发大型的项目。然而，软件开发的实践表明，瀑布模型也存在以下的缺陷：

（1）只有在项目生命周期的后期才能看到结果。

（2）通过过多的强制完成日期和里程碑来跟踪各个项目阶段。在项目开发过程中缺乏足够的灵活性，特别是对于需求不稳定的项目更加麻烦。

（3）在软件需求分析阶段，要完全的确定系统用户需要的所有需求是一件比较困难的事情，甚至可以说是不太可能的。

尽管瀑布模型存在一定的缺陷，但是它对很多类型的项目而言依然是有效的，特别是在一些大型项目进行开发时依然有效。如果正确地使用瀑布模型，可以节省大量的时间和金钱。对于正在进行开发的项目而言，是否使用瀑布这一模型主要取决于开发者能否理解客户的需求以及在项目的进程中这些需求的变化程度，对于能够在前期进行确定需求分析的项目，瀑布模型还是有其价值的。

2．喷泉模型

喷泉模型是一种以对象为驱动、以用户需求为动力的模型，主要用于描述面向对象的软件开发过程。该模型认为软件开发过程自下而上、周期的各阶段是相互重叠和多次反复的，就像水喷上去又可以落下来，类似一个喷泉。各个开发阶段没有特定的次序要求，并且可以交互进行，可以在某个开发阶段中随时补充其他任何开发阶段中的遗漏。采用喷泉模型的软件开发过程如图1-8所示。

喷泉模型主要用于面向对象的软件项目，软件的某个部分通常被重复多次，相关对象在每次迭代中随之加入渐进的软件成分，各项活动之间无明显边界。由于对象概念的引入，表达分析、设计及实现等活动只用对象类和关系，从而可以较容易地实现活动的迭代和无间隙。

喷泉模型不像瀑布模型那样，需要分析活动结束后才开始设计活动，设计活动结束后才开始编码活动。该模型中的各个阶段没有明显界限，开发人员可以同步进行开发。其优点是可以提高软件项目的开发效率，节省开发时间，适应于面向对象的软件开发过程。由于喷泉模型在各个开发阶段是重叠的，因此在开发过程中需要大量的开发人员，由此不利于项目的管理。此外这种模型要求严格管理文档，使得审核的难度加大。

3．基于构件的开发模型

基于构件的开发模型利用模块化方法将整个系统模块化，并在一定构件模型的支持下复用构件库中的一个或多个软件构件，通过组合手段高效率、高质量地构造应用软件系统的过程。基于构件的开发模型融合了喷泉模型的许多特征，本质上是后者演化而来的，开发过程是迭代的。基于构件的开发模型由软件的需求分析和定义、体系结构设计、构件库建立、应用软件的构建，以及测试和发布5个阶段组成，采用这种开发模型的软件开发过程如图1-9所示。

构件作为重要的软件技术和工具得到了极大地发展，这些新技术工具有Microsoft的DCOM、Sun的EJB，以及OMG的CORBA等。基于构件的开发活动从标识候选构件开始，通过搜查已有构件库，确认所需要的构件是否已经存在。如果已经存在，则从构件库中提取出来复用；否则采用面向对象的方法开发构件。之后，利用提取出来的构件通过语法和语义检查，再将这些构件通过“胶合”代码组装到一起来实现最终系统，这个过程是迭代的。

基于构件的开发方法使得软件开发不再一切从头开发，开发的过程就是构件组装的过程，维护的过程就是构件升级、替换和扩充的过程。它的优点是构件组装模型催生了软件的复用，提高了软件开发的效率。构件可由一方定义其规格说明，再由另一方来实现，然后供给第三方使用。构件组装模型允许多个项目同时开发，因而降低了费用，提高了可维护性，可实现分步提交软件产品。

由于采用自定义的组装结构标准，缺乏通用的组装结构标准，因而引入了较大的风险。可重用性和软件高效性不易协调，需要精干的有经验的分析人员和开发人员，一般开发人员插不上手。客户的满意度低，并且由于过分依赖于构件，所以构件库的质量影响着产品的质量。

4．XP方法

敏捷方法是20世纪90年代兴起的一种轻量级的开发方法，到现在已经非常成熟，它强调适应性而非预测性、强调以人为中心，而不以流程为中心，以及对变化的适应和对人性的关注，其特点是轻载、基于时间、紧凑、并行并基于构件的软件开发过程。在所有的敏捷方法中，XP（eXtreme Programming）方法是最引人注目的一种轻型开发方法，它规定了一组核心价值和方法，消除了大多数重量型开发过程中不必要的产物，建立了一个渐进型的开发过程。该方法将开发阶段的四个活动（分析、设计、编码和测试）混合在一起，在全过程中采用迭代增量开发、反馈修正和反复测试。它把软件生命周期划分为用户故事、体系结构、发布计划、交互、接受测试和小型发布6个阶段，采用这种模型的软件开发过程如图1-10所示。

XP模型通过对传统软件开发的标准方法重新进行审视，提出了由一组规则组成的一些简便易行的过程。由于这些规则是通过在实践中观察使软件高效或缓慢的因素而得出的，因此它既考虑了保持开发人员的活力和创造性，又考虑了开发过程的有组织、有重点和持续性。XP模型是面向客户的开发模型，重点强调用户的满意程度。开发过程中对需求改变的适应能力较强，即使在开发的后期，也可较高程度地适应用户的改变。

XP开发模型与传统模型相比具有很大的不同，其核心思想是沟通（Communication）、简单（Simplicity）、反馈（Feedback）和进取（Aggressiveness）。XP开发小组不仅包括开发人员，还包括管理人员和客户。该模型强调小组内成员之间要经常进行沟通和交流，在尽量保证质量的前提下力求过程和代码的简单化；来自客户、开发人员和最终用户的具体反馈意见可以提供更多的机会来调整设计，保证把握正确的开发方向；进取则包含于上述3个原则中。

XP开发方法中有许多新思路，如采用“用户故事”代替传统模型中的需求分析，“用户故事”由用户用自己领域中的词汇，在不考虑任何技术细节的情况下，准确地表达自己的需求。XP模型的优点如下：

（1）采用简单计划策略，不需要长期计划和复杂模型，开发周期短。

（2）在全过程采用迭代增量开发、反馈修正和反复测试的方法，软件质量有保证。

（3）能够适应用户经常变化的需求，提供用户满意的高质量软件。

上面讲述的各种开发模型或方法，或许不能一概而论地作为面向对象的建模基础之开发模式，但是在这些开发模型或方法中，都包含了软件的需求分析、软件的设计、软件的开发、软件的测试和软件的部署。在每一个阶段，可以借助于面向对象的建模和这些开发模型形成一套适合自己或企业的开发方式。

开发模式或方法毕竟是方法，如同在冷兵器时代的排兵布阵和火器时代的排兵布阵一样，都有自己的技巧和策略，由于一个是面向过程而另一个是面向对象，这种的不同也就赋予了不同的方法论。在这些开发模型中，对于适用UML和面向对象的开发的代表就是Rational统一过程（Rational Unified Process，RUP），我们将在第4章详细讲解。