过程模式简介

一．什么是过程模式？

要定义过程模式，首先要探究一下“过程”和“模式”这两个词。“过程”就是一系列的行为，在这些行为中，一个或多个输入会生成一个或多个的输出。而要定义一个“模式”则会麻烦一点。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. 使复审结果生效。在复审期间，被审项目的优点和缺点都被记录成文档。此文档应该描述各种缺陷以及成为缺陷的原因，同时应该指出修复这些缺陷所需要做的工作。此文档将会提交给开发小组，这样他们可以按它的要求行动；审查经理可以将它用于后继的审查中，那时这些工作将再次被检查以检验缺陷被修复的情况。