过程模式简介(Scott W. Ambler 著)

过程模式简介

 

 

一．什么是过程模式？

要定义过程模式，首先要探究一下“过程”和“模式”这两个词。“过程”就是一系列的行为，在这些行为中，一个或多个输入会生成一个或多个的输出。而要定义一个“模式”则会麻烦一点。Alexander (1979)在给出模式的定义时有过暗示，他指出：尽管这些宽特征（broad feature）在表面上不尽相同，但是相同的宽特征还是一次次重复出现。Alexander还指出虽然每一个创建过程都是唯一的，但他们都可以通过继承通用模式集来创建。换句话说，模式是普遍问题或论题的通解，从其中的一个通解可以得到一个特解。

 

Coplien(1995)在他《生产性开发——过程模式语言》一文中给出了过程模式的定义，他的描述是：公司（以及企业）内部的行为模式称为模式。出于本文的目的，我将过程模式定义成开发面向对象软件中的通用技术、行为、以及任务（或活动）。过程模式最重要的一个特征是它描述了什么是你应该做的但没有详细确切给出如何去做。当过程模式以有组织的方式被应用到一起时，它们可以为你的机构建立软件过程。这是因为过程模式并不说明如何执行给定的任务，他们可以被用作可重用的砌块（Reusable Building Block），用这些砌块你可以制作满足你的公司特定需求的软件过程。与过程模式有关系的是组织模式，它是一种描述公共管理技术或组织结构的模式。实际上，过程模式和组织模式是结合在一起的，但是本文的重点并非是组织模式。

 

 

二．过程模式的类型

过程模式有一个特点我相信是最重要的，那就是可以为各种目的来开发它们。需要指出的是单一的过程模式的范围可以从如何开发应用程序的高级观点到软件过程某特定部分更详细的观点。

 

我认为过程模式有三种类型，按范围扩大的顺序是：

1．  任务过程模式。这种过程模式描述了执行一项特定任务的详细步骤，如技术复审和重用初始过程模式。

2．  阶段过程模式。这种过程模式描述了单一设计阶段的步骤，这些步骤通常是反复执行的。设计阶段是过程模式的更高级形式。一个设计阶段通常由多个任务过程模式组成。图4中面向对象软件过程（Object-Oriented Software Process，OOSP）的每个设计阶段都代表了阶段过程模式，比如图2的编程阶段。

3．  状态过程模式。这种过程模式描述了阶段过程模式和单一项目状态之间的互动性，如开始状态和交付状态。图3中的构造模式就是一种状态过程模式，它是两个或多个阶段过程模式的集合。项目状态可以表现为多种方式，这对结构化开发和对象化开发都是可行的。在对象行业内普遍有这样的说法，就是面向对象开发技术在本质上是反复的。虽然这对九十年代初流行的一些小型项目来说可能是行得通的，但是对目前规模庞大、任务紧迫的应用程序却并不适合。实际上，通过交付时间上增加的版本，面向对象的开发技术在大范围内是连续的，在小范围内是反复的（Ambler 1998b）。由反复执行的阶段过程模式组成的状态过程模式是以连续的方式执行的。

 

至此，我认为过程模式中大量的重要工作都在任务过程模式中完成，而很少在阶段过程模式和状态过程模式中完成。在下面三节中我会对这三种过程模式各举一个例子，它们都来自OOSP过程模式语言（Ambler 1998b;Ambler 1998c）。在第六节中我会介绍面向对象软件过程OOSP，即被任务过程模式依次增强的阶段过程模式和状态过程模式所组成的生命周期。我的经验是当你从定义或为一个公司制作软件过程的角度来考虑过程模式时，你就需要使用本节中讲到三种过程模式。我相信任务过程模式是软件过程中关键的组成部分，而阶段过程模式和状态过程模式用于组织任务过程模式并将它们转化成有意义的上下文。

 

 

三．任务过程模式——技术复审

在开发过程中建立的可交付使用的部分必须先对其进行检验，以保证它们能够满足你的用户群和公司质量标准的要求。技术复审任务过程模式描述的是如何组织、引导并且在一个或多个可交付模块的复审上贯彻实施。这种模式与团队确认（Harrison,1996）、评论（Cpoplien,1995）、创建者评述员（Weir,1998）和群组确认（Coplien,1995）的任务过程模式是同一个主题。

 

3．1 影响因素

这里有几个会激发技术复审过程模式的影响因素。首先，开发过程中产生的可交付的模块、原形、文档和源码等对定义要发布给用户群的软件和相关产品是有帮助的，所以，在每一个可交付的部分构建之前，你应该验证它们的质量是否足够高。其次，因为等到错误在你的工作中象丢雪球一样被发现时，那么修改这些错误的成本就会增加了。这时，你就希望能尽早发现这些错误来及早修复它们（也是廉价的）。第三，因为你很难评价你自己的工作，所以你需要由“第二双眼睛”来审查可交付的部分。第四，你需要就你的工作与别人进行交流，其中一种方法就是让你的队友来审查你所完成的可交付部分。

 

3．2 准备工作

现在，有一个或几个可交付部分待审。这些可交付部分已经准备好，开发团队也作好了审查它们的准备。

 

3．3 解决方案

图1列出了技术复审过程模式的六个基本步骤，它们是：

1.       开发团队准备复审。收集、合理组织并包装需要复审的项目内容，这样它们就可以出现在评论者的面前了。

2. 开发团队指出他们准备接受复审。当开发团队打算并且已准备好接受一次复审时，他们必须通知审查经理，而他通常是一名质量保证人员。

3. 审查经理先进行一次粗略的审查。审查经理要做的第一件事是确定开发小组是否已经完成了将被审查的工作。他可能需要就开发小组的工作与小组负责人进行讨论,并且对他们的产品作好简要的提纲。其主要目的是保证待审查的工作足以把审查小组吸引到一起。

4. 审查经理策划并且组织复审。审查经理必须安排好评论所需的场所和其他设备，邀请合适的人员参加，并且提前分发复审所需的材料。可能审查的内容将在下节中讨论。

5. 复审开始进行。技术复审可能会花上几个小时到几天，这取决于待审工作的数量，但是复审最好少于两个小时，这样不至于使相关人员感到疲惫。整个开发小组都应该参加复审，至少负责被审部分的人员应该参加，他们可以回答提出的问题、解释阐明自身的工作。一般包括审查经理在内会有三到五名复审人，他们都负责审查工作。所有的待审材料都要完成复审。这看上去太容易了，但却不能迅速发现错误并也不嫩假定它是正确的。复审推动者要保证的工作是每件事都被考虑到每件事都被询问到。

6. 使复审结果生效。在复审期间，被审项目的优点和缺点都被记录成文档。此文档应该描述各种缺陷以及成为缺陷的原因，同时应该指出修复这些缺陷所需要做的工作。此文档将会提交给开发小组，这样他们可以按它的要求行动；审查经理可以将它用于后继的审查中，那时这些工作将再次被检查以检验缺陷被修复的情况。

 

图1 —— 技术评论过程模式

准备 评论

说明评 论准备 就绪

进行 粗略的 检查

组织 评论

保持 评论

按 评论结果执行

 

 

 

 

 

 

 

 

3．4 复审结果。

这样的高级管理保证了开发小组开发出的是符合用户群要求的高质量的产品。开发小组和复审人员对他们制作的产品以及这些产品如何进入全部软件项目具有较深入的理解。单个的小组成员和复审人员可能在复审中学到新的技术，包括应用于产品自身的技术、复审过程中的管理技术以及复审中提出的改进产品的开发技术。

 

 

四．阶段过程模式——编程

在软件开发的多个需要确定的方面中，最重要的是源代码的真正开发。有经验的开发人员知道，坐在电脑前敲代码与真正的编程相去甚远。编程阶段过程模式描述的是编程的反复的任务或反复的活动。

 

4．1 影响因素

       程序员开发的软件要能满足用户群的需要，要能够满足建模阶段、需求定义阶段和需求激活阶段生成的模型和文档的需要。源代码应该能反映包含在这些可交付产品中的信息，然而当程序员对领域知识有了详细的了解之后（一般会比模型更具体），这些信息可能会发生改变。而且，很多公司在希望软件能够及时高效地开发的同时，也希望它是可维护可扩展的，以便日后能迅速高效地进行修改。

 

4．2  准备工作/进入条件

       在开始编程以前必须满足几个条件。第一，你设计的模块必须适用于你将要写的代码。第二，在开始状态（参见图4）的定义基础结构阶段所定义的基础结构必须是恰当的，它包含了你的程序员要使用的开发工具和支持工具以及你要遵循的标准和原则。第三，程序员必须有时间工作。

 

4．3 解决方案

       图2 描述了编程阶段的过程模式，它表明了这个阶段除了写原代码还有很多事要做：你需要理解模型，寻找以前写的可重用的模块以减轻你的工作负担，证明一下你将要写的东西，然后写代码，检查改进，再测试修改，最后打包。

图2 —— 编程的过程模式

同步源码与模型

准备待审源码

理解 模型

准备 集成计划

书写 源代码

集成 和打包

撰写源码文档

构建 软件

重用已有的代码和组件

优化 代码

打包后的应用程序源代码

模型， 项目 基础构造

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

程序员在编程前的首要任务是必须花时间去理解规定了他们将作什么的模型。虽然这听起来很简单也很明白，但经常有人没有进行这一步。如果编程前程序员不用花时间理解模型，那么为何还要如此麻烦地先将模型创建出来呢（理想情况下，程序员是参与设计模型的开发的）？程序员的目的是理解相关的设计观点，设计协定，以及如何使代码与整个应用程序相符。在编写代码前，他们必须花时间理解问题及其解决方法。

       一旦你的程序员对模型进行了检查，了解了需要生成的东西，他们就应该注意查看已经生成的部分。面向对象的开发技术允许递增式的重用，但是你必须明白如果你选择了重用，那么在你的项目中你只能增加重用。这就意味着程序员必须设法重用已存在的模块或代码，而最好的方法是在开始编码前寻找可重用的部分。你的整个设计也应该考虑到了重用的问题。

       在你开始编码前，首先要撰写文档。尽管这好象是非直觉的，但是经验表明从撰写描述代码逻辑的简要提纲开始来编码的程序员比不喜欢这么做的同行要高效得多。原因很简单：编程最困难的是使逻辑正确而不是写实现逻辑的实际代码。撰写文档前就编码是一种过程反模式，如果可能，这是可以避免的。以简要注释形式撰写的逻辑文档称为伪代码，你要花时间获得合适的逻辑性，避免写了很多代码后因为他们不能正常工作而必须将其丢弃的情况。所以，先思考再编码。

       一旦程序员花时间理解了将要实现的模型，查找了减少工作量的可重用组件，又为编码撰写了原始文档，那么他们才真正准备编写面向对象的源代码。程序员所写的代码应该遵循项目中定义或选择的标准和指导思想，这种一致性在代码复审时会被检查。

       在整个编码过程中，程序员必须时刻注意使源代码与模型保持同步。而模型或文档并未包含编码者所需的全部信息，这一点在编码过程中会很清楚。如果是这样，那么程序员和建模者应该首先确定一种解决方案，然后根据这个方案修改模型和代码。重要的是代码反映了包含在模型和副本中的信息。

       开发小组编写的代码将被整体或局部地审查，这是小阶段（Small stage,Ambler,1998b）测试的一部分。要准备一次应用了技术复审任务过程模式的代码复审，程序员应该在一定程度上能保证自己的代码可以通过审查。这意味着代码能满足设计要求，能够符合标准，文档完备，易于理解并且书写规范。

 

       我的经验是把优化留到最后，因为你要优化的仅仅是需要优化的代码：经常是代码中比例很小的一部分导致了非常主要的处理时间，那么这就是你应该优化的代码。经验不足的程序员常犯的典型错误是试图优化所有的代码，甚至是已经运行得非常快的代码。就我个人而言，我喜欢优化确实需要优化的代码，然后去做更感兴趣的事，而不是设法榨出每个单一的CPU周期.

       创建构件是Java和C++这样的编译型语言编译连接源代码的行为，亦或是Smalltalk这样的语言包装源代码的行为。正如你期望的一样，你可以使用编译器、连接器和打包器等工具来创建构件，为了讨论方便，我将把这些工具称作“构件器”。成功的构件将生成可运行和测试的软件，而反之，则会出现构件器与你的代码不符的现象。构件能帮助你发现代码里综合性的错误，因而它很重要。如果你的代码不能很好地集成，它可能会破坏你的构件，创建了构件就表明你的代码实际执行了编译，而这对开发小组来说往往具有难以置信的士气鼓舞作用。      

       在对你的应用程序打包或集成之前，你应该作好计划。负责应用程序打包或集成的开发人员必须具有三样关键的东西：一份描述了进度表、资源、集成应用程序各部分具体方法的集成计划，一份描述了应用程序各个部分及其相互关系的版本描述文档（VDD，Version Description Document），以及一份表明了软件在用户群中配置方式的配置图。要打包或集成应用程序，你必须构建并测试你的软件，生成支持文档，并为你的软件制作安装程序。如果你每天都执行构建，那么很明显第一步要做的是，把已经存在的构件过程凑在一起，构建源代码文件，组成你的应用程序。

 

4．4 结果或退出条件

       在编程阶段结束之前，下列情况必定会发生：首先，你的代码应该已经通过审查；其次，代码须能工作（通过测试）；第三，代码应经过充分地优化；第四，如果软件可以应用，那么为了交付，它必须经过打包和集成。

 

 

五．状态过程模式

构造状态，即图4中面向对象软件过程（OOSP）的第二个连续状态，它的主要目的是构建将被测试和将被交付给用户群的可运转的软件。这个软件附带有开发的模型和源代码，证明软件可以工作的测试计划，能够用于未来项目的可重用部件以及支持这个软件的初始文档和培训计划。

 

5．1 影响因素

       有几个因素会影响构造状态，包括高级管理人员和开发人员对如何使状态起作用缺乏理解；包括毫无根据的着眼于编程而忽视了建模、测试和概括；包括每个人都想抄近路走捷径的倾向而这会导致软件质量低劣并延迟交付超出预算。

 

5．2 准备工作/进入条件

构造过程可以通过两种不同的方式进入，一种是从初始状态进入，另一种是从维护和支持状态进入（见图4）。不管怎样，构造过程开始前必定会遇到几种情况：第一，关键项目管理文档（项目计划、评估、进度表、风险估计）可以获得并且是最新的。第二，项目的基础结构应该已定义，至少应该定义了大部分，这样你的开发小组就能获得工具、方法和标准。第三，软件的高级需求应该安排在适当的位置，同样，开发小组的项目许可证也是如此。第四，应用于软件的维护变化应该被定位到你所在工作的版本上（这只对正在更新的已存在软件适用）。最后，在你的项目需要开发小组时，他们应该是经过精挑细选并保证可用的。

 

5．3 解决方案

图3代表了构造状态过程模式。它的一个重要含义是，当你进入构造状态时，你不是从涂鸦开始的——而是项目计划和初始风险评估等重要的管理文档，应用程序的初始需求，项目的基础结构（至少大部分）已经被定义并且已经获得项目的资金和许可证。构造状态的四种反复的阶段是紧密相关的。建模阶段（Model Stage）通过图表、文档和原型的使用，主要关注技术和（或）问题域的提取。编程阶段（见图2）关注于开发和编写程序源代码。归纳阶段会评价你的公司中重用的效果，因为这一阶段关注的是确认可重用的部件或者经过修改可以变成可重用的部件。这是一种有效的“机会主义重用”而不是“系统化的重用”。因为你企图通过在事实背后获得成功来开发可重用部件，而在“系统化的重用”中你是在建立可重用模型的过程中设计软件的。小规模测试阶段的目的是校验和证实构造状态的其他阶段开发的可交付部件。在很大程度上这个阶段相当于来自结构化世界的结合了代码检查和技术复审等质量保证技术的单元测试。

图3 构造过程模式

       就是因为构造状态本质上是反复的，所以它并不意味着你的开发人员可以开始编码了。软件开发的事实是你必须最先确定和理解某事物的需求，然后你必须建立他们的模型，接着编码。如果你没有定义需求，那么你构建软件又是为了什么呢？你是否也承认开始编码前花时间考虑和建模能够提高生产率呢？真正拔尖的开发人员也明白在转向下一个任务前必须检验他们的工作。为无效的需求建模或在错误的模型上编码都是没有价值的。这就是说，在开发过程中你就需要测试自己的工作，而不要到开发的末尾，到那时修改发现的问题将为时已晚。我并不是说你必须首先定义所有需求，然后建立所有模型，最后编写所有代码。我说的是你写的任何代码都应该基于有效的模型，你建立的任何模型都应该基于一个或几个有效的需求。

 

5．4 结果/退出条件

       当声明了编码冻结或开发冻结时，构造状态就结束了。对于一个正式的编码冻结或开发冻结，下列可交付部件必须具备：模型（类模型、用例模型、顺序图……），需求分配矩阵（RAM），源代码，主测试（或质检）计划，用户文档、操作文档、支持文档、软件本身、培训计划、发布计划和教学课程。这时你的软件正准备转换到交付状态（见图4），在这个状态软件将被大规模测试，按需要重新编写并发布给你的用户群。

 

六．为什么使用过程模式

       过程模式是一种交流软件开发途径的优秀的机制，人们已经证明了它在实际中是有效的。而且，过程模式是可复用的砌块，你的公司可以用它来构建成熟的软件过程。比如，在图4中我们可以看到面向对象的软件过程（OOSP）的描述，它由四个连续的状态组成，而这些状态依次由反复的阶段组成（Ambler, 1998b; Ambler, 1998c）。图4 底部的大箭头表示应用于开发各个阶段的项目成功所必须的主要任务。状态过程模式和阶段过程模式，也就是大箭头中的任务，由任务过程模式依次提高。OOSP形式的过程模式已经用于建立一种针对使用对象技术、大规模的紧急开发任务的成熟的软件过程。

图4  面向对象的软件过程（OOSP）

       正如你在图4中看到的一样，OOSP有四种项目状态：开始、构造、交付和维护与支持，其中的每一种都被称作一种状态过程模式。同样是在图4中，你可以看到OOSP中有14个项目阶段：调整、定义和验证初始需求、定义初始管理文档、定义基础结构、建模、编程、小规模测试、归纳、大型测试、重写、发布、评估、支持以及识别优缺点，其中每一个阶段称为一个阶段过程模式。项目阶段在一个单一项目状态的范围内以重复的方式执行，然而，项目状态在OOSP范围内却以连续的方式执行。

       如同上面所指出的，我相信过程模式是你的机构编制或定义成熟的软件过程的关键方法。然而，过程提高的事实是你不能立即作出你想要的所有变化；这只是因为变化太大了你的机构不能马上吸收掉。这就是为什么我们致力于软件工程学院的能力成熟度模型（SEI’s CMM）和国际标准化组织的软件过程能力提升规定（IOS’s SPICD）。这两个机构都建议区分你的公司需做的过程改进的优先次序，希望你用几年的时间来做必要的修改，并希望在做的过程中能经历各种困难。经验表明试图进行立即的大规模的过程修改的机构很可能反而完不成这一过程。

 

 

七．过程反模式

       和存在过程模式这种被实践证明有效的开发方式一样，也存在过程反模式这种被实践证明无效的开发方式。过程反模式的一个例子是码砖，一种在编码前很少花或不花时间去分析和设计的开发方式。最根本的是，你首先需要分析，然后设计，然后编码。除此以外别无它路，没有一款软件能被改成用别的方法开发。没有先前为软件定义需求你怎么可能开发得出来？如果没有需求，那么你为什么要构建这个软件呢？其次，是编码前画一些图帮你圈出设计来得简单些呢，还是丢开各个部分不管，一味疯狂地编码然后发现它不能工作而重写来得简单些呢？我想你会同意从一些计划和规则开始的说法的。一开始就编码是毫无意义的，你首先必须做一些分析和设计工作。

 

       可总是有一些开发人员已经开始了编码，他们认为他们正在做的软件是这条规则的一个例外。因为他们做的是通常用于系统层或持续层的技术软件，他们自欺欺人地认为他们并不需要由分析开始。我自己参加的就是纯技术性软件的开发，我们每次都是由撰写需求开始的，然后对我们的设计建模，然后才是编码。在这个过程中，我们发现如果我们遗漏了一些需求那么我们将被迫修改已有的设计和代码。必须指出的是在考虑什么是我们要构建的和我们如何构建之前，我们不会去胡乱地堆砌代码。的确，这是常识，但很多开发人员似乎没有这种概念。

 

 

八．总结

       过程模式是可复用的砌块，你的机构可以用它来构建一个成熟的软件过程。在此白皮书中，我讲述了三类过程模式：任务过程模式——描述一项特定任务中的详细步骤、阶段过程模式——描述一系列反复的任务、状态过程模式——描述许多反复阶段的集合。过程模式描述了已被证实了的软件开发的方式，也是在你的机构里用于提高软件质量、软件可维护性和软件可扩展性的方式。