发信人: williamlong()
整理人: williamlong(2000-04-24 11:01:10), 站内信件
|
《客户/服务器应用程序开发指南》详细介绍了 Visual Basic 企业版提供的开发
工具，并且为使用这些工具来构造三层客户/服务器应用程序的开发者提供了一套
体系结构设计思想。这里的应用程序模型将应用程序划分为逻辑上的服务组，而
服务组通过跨越企业网络作为独立物理部件来分别实现。物理部件具有可共享、
可扩展、可重定位等特点。
本书的每一部分分别说明如何使用 Visual Basic 企业版所提供的丰富工具和策
略，来设计并实现基于部件的客户/服务器应用程序的某个方面。从建立抽象的体
系结构开始，然后介绍详细设计和部件部署，最后涉及与企业数据源的接口。
章节
第一章 概述介绍用于分布式应用程序设计的三层模型，以及基于部件的设计所
需要使用的工具和技术。此外，还为工程管理者提供了一系列新的开发策略，利
用它们可以更好地构造分布式的应用程序。
第二章 设计指南为构造基于部件的解决方案提供了详细的设计指南。其中包括
：概念设计、逻辑设计和物理设计；如何实现 ActiveX 部件（即以前的 OLE 服
务器）用于分布式的部署；考查设计良好的部件应用程序的完整工作模型。
第三章 数据访问选项概述通过 Visual Basic 企业版进行客户/服务器模式数据
访问的不同方法：数据访问对象 (DAO) 和远程数据对象 (RDO)、RemoteData 控
件 (RDC)、开放数据库互连 (ODBC) 应用程序编程接口以及 Microsoft SQL Ser
ver 的 VBSQL 接口。
第一章概述
Microsoft Visual Basic version 5.0 企业版为群体开发者提供了开发、测试和
使用大型分布式客户/服务器应用程序所需的编程环境和集成工具。《客户/服务
器应用程序开发指南》则介绍了一种用于开发这种应用程序的体系结构和设计框
架。
有了这些工具和技术，就可以利用网络上那些可共享的、可重用的和可重定位的
部件“搭积木”，轻松地完成应用程序的开发。
概述部分简要介绍分布式应用程序设计的三层模型。这种模型与所用的工具和技
术结合，可以获得基于部件的设计方法的全部好处。这种模型还为开发策略提供
了一整套新思想，项目管理者可以用它来处理分布式应用程序开发中的新问题。
第一节 前 言
概要介绍将应用程序划分为既独立又相互配合的部件的好处，这里，划分好的部
件应该可以独立地定位在网络上。同时简要介绍企业版中关于基于部件的设计方
法的有关特性。
企业的客户/服务器计算模型正在发生日新月异的变化。今天的企业面对着来自全
球的竞争，需要采用新的业务方法，需要使自己的技术保持领先，为此必须建立
良好的信息管理系统，这直接关系到企业的兴衰。
企业版的 MicrosoftVisual Basic5.0 为企业开发者提供了一套先进的工具包，
辅之以抽象的设计战略和具体的实现指南。使用可重用、可重定位的软件部件，
建造出强健的、可扩展的分布式应用程序。
新的客户/服务器开发模型的关键概念是三层结构。这种模型将应用程序的任务在
逻辑上分为三个服务“层”，业务规则、数据访问和分布式的处理任务等都可封
装到部件之中。部件具有可共享、可重用的优点，根据性能、维护等方面的具体
要求，从物理上来说，可将部件部署在网络上的任何地点。这种多方面的适应性
能够最大程度地迎接变革的挑战。
主题
一． 基于部件的应用程序介绍将应用程序划分为可共享、可重用、可重定位的部
件的优点。
在企业版中，可使用三层结构的客户/服务器开发模型对应用程序进行任务划分。
在这一过程中，不同的项目组各自开发独立的部件，这有助于提高生产效率。然
后将这些部件部署在物理网络的多个计算系统上。
可用各种独立于语言的工具创建这些部件，也可从第三方购买。
这种基于部件的应用程序开发策略可以带来以下的好处：
■ 可重用性。许多应用程序可共享和重用封装在部件中的功能。
■ 灵活性。从桌面计算环境到功能更强的网络服务器，随处都可分配工作，这有
利于协调性能和网络带宽。
■ 可管理性。将大型复杂的工程细分为简单、安全的部件工程。
■ 易维护性。将业务逻辑部署在中央服务器上，而不是分散在用户桌面上，这有
助于处理各种变化，并缩短解决方案的往返时间。
面向用户服务、面向业务服务和面向数据服务以及在服务之间协商的业务逻辑都
包含在彼此独立的对象中，且与它们在网络上的位置无关，而对象之间可相互进
行操作。通过这种方式，系统以及系统所支持的企业将是灵活的和可扩展的，从
而能够满足不断发展的业务需求。
二． 使用 Visual Basic 进行企业开发介绍企业版中为支持三层客户/服务器模
型的开发而提供的工具和策略。
企业版的设计有助于将应用程序划分为分离的部件，并灵活地部署这些部件，且
有助于在逻辑上将应用程序的需求分为三种服务：
■ 用户服务
■ 业务服务
■ 数据服务
本书将介绍这种三层的逻辑应用程序模型，在这种模型中定义了应用程序的功能
，并将功能作为这些服务和彼此协作的部件的集合，这些部件共同工作以期满足
特定需求。通过这些集合，部件可以互相独立地提供用户、业务、数据服务。
例如，可用这种方法管理产品、顾客和收入数据，这三种数据是企业应用程序的
中心，并由变动频繁的规则定义。在三层模型中，规则可能在部件之中，而部件
使用取自数据库的信息进行计算，并将结果返回到用户的桌面上。部件为一个概
念层，专门用来运用业务规则并与编程逻辑分离开，编程逻辑负责处理数据访问
和用户交互任务。
可从客户机访问的封装部件部署在服务器上，它独立于数据和用户而进行操作，
用户看不到其工作过程。这种根据要素之间关系的划分，分别提供用户、业务和
数据服务。如果规则发生了改变，这种划分将减轻维护的工作量，只需要维护那
些发生变化的部件。
三．分布式的 ActiveX 部件说明 Visual Basic 5.0 版的功能，利用这些功能
构造并部署 ActiveX 部件。
将部件部署在网络上可以使大部分企业应用程序的功能更强。Microsoft 的分布
式计算平台包括一系列的设计与接口标准，即所谓的 ActiveX。ActiveX 标准是
对以前的 OLE 自动化技术的扩展。在企业版中，同一计算机上的 ActiveX 部件
可以通过 COM（Component Object Model）接口相互通讯，而不同计算机上的部
件也通过同样的 COM 进行通讯。在网络上进行通讯的时候，ActiveX 部件能够通
过两种远程机制响应客户端的请求：分布式的 COM，用于 Microsoft Windows 和
Windows NT等 32 位平台；远程自动化，用于 16 位的计算平台上。
这些远程平台的主要优点是：独立于具体的物理部件。就是说，使用 Visual Ba
sic 创建 ActiveX 部件时，不必预先知道如何来部署它。同样的部件可以位于本
地的计算机上，也可以被重定位到使用分布式 COM 或远程自动化的远程计算机上
，这在设计上提供了相当大的灵活性。另外，还可以对部署策略进行适当的修改
，而不需要重新编译部件。
ActiveX 标准非常适合为企业级的客户/服务器系统建造分离的部件，理由如下：
■ 因为分布式的 COM 和远程自动化技术都提供了与本地的自动化相同的编程接
口，所以将应用程序进行划分的技术与开发本地执行的应用程序相似。而且可以
很容易从任何客户端访问 ActiveX 部件。
■ 同 SQL 相比，使用 Visual Basic 语言可以更直接地描述复杂业务规则算法
，并加以注释和维护。Visual Basic 还为源代码的测试、调试和控制提供了更好
的环境。
■ ActiveX 部件可以是自行开发的（实现公司专门的业务规则），也可以是从第
三方购买的（用于一般性的服务）。
■ 由于可以部署在服务器上，ActiveX 部件可以省去桌面上的大量计算任务。
■ 无论本地执行还是远程执行，部件之间的二进制通讯接口是相同的，所以可将
部件在不同的机器上移动而无需对部件或其客户应用程序重新进行编译。
ActiveX 部件能够为 Visual Basic 开发者提供更多的方便、更强的功能、更大
的灵活性，因此，在创建企业级的客户/服务器系统应用程序时，ActiveX 部件是
基本的工具。
第二节 服务模型
描述了一种方法，把应用程序看成提供和接受服务业务对象的集合。这种方法提
供一种概念框架。在此基础上，可开发出三层客户/服务器应用程序。
要充分利用好 Microsoft Visual Basic 企业版中提供的工具和策略，关键在于
透彻地理解三层结构方案的客户/服务器模型。作为一种先进的协同应用程序开发
模型，这种方案将客户/服务器系统中各种各样的部件划分为三“层”服务，它们
共同组成一个应用程序：
■ 用户服务
■ 业务服务和其它的“中间层”服务
■ 数据服务
这些层并不一定与网络上的具体物理位置相对应。相反，它们只是概念上的层，
借助这些概念可以开发出健壮的、基于部件的应用程序。如果使用这种方法设计
应用程序，开发人员在网络上部署进程及数据时可以有相当大的灵活性，从而有
利于实现最佳的性能、更好的安全性以及更方便的维护。
我们将这种三层的应用程序设计模型称为“服务模型”。
主题
一．基于部件的应用程序开发服务模型提供了一种新的应用程序开发方法，它是
基于若干自包含的、可重用的、可重定位的部件的集成。
使用服务模型，可以把应用程序的需求分解成明确定义的服务。在定义了服务之
后，需要进一步创建具体的物理部件来实现它们。根据性能和维护的需求、工作
量、网络带宽以及其它的因素，可以在网络上灵活地部署这些部件。
这种基于部件的解决方案的方法将应用程序的开发分成两类大的任务。一类任务
是开发能被很多程序使用的核心部件（ActiveX 控件和服务器、存储过程等等）
。另一类任务是集成这些核心部件提供的服务，构造出特定的业务解决方案。
与传统的单片应用程序开发方法相比，基于部件的方法具有以下优点：
■ 开发人员可以专门做自己最擅长的工作。培训与再培训的费用将因此而显著地
减少。
■ 能够使用 Visual Basic、C/C++、SQL 或其它工具编写可重用部件。这在很大
程度上提供了程序语言和代理商的独立性，允许部件开发者使用最适合特定任务
的语言和工具。
■ 部件可以部署在网络上，从而取得效率、性能、安全和维护上的最大利益。可
以将一个应用程序的某些部件驻留在中央数据库服务器上，某些部署在部门性的
“业务”服务器上，另外的部分驻留在最终用户的客户机上。在设计功能强大、
需要良好协调的若干应用程序时，开发人员可以根据网络以及基础设施的实际情
况进行部署。部件的实际位置对最终用户是透明的。
■ 可重用性是指“创建能够被很多应用程序使用的通用部件”，这将减少开发的
开销。部件的使用者只需要理解向他们公开的接口，而不需要知道部件的内部结
构和部件使用的数据。这样就能够以最少的开销开发尽可能多的、高质量的应用
程序。这也有助于实现应用程序之间的高度一致性、兼容性和业务完整性。
部件方案的种种优点使它成为客户/服务器应用程序开发方法中的佼佼者。然而，
要获得这种方法所具有的好处，需要细心地策划和设计。通常，设计过程包括以
下步骤：
1. 确定应用程序的需求，即概念设计。
2. 把这些需求映射成抽象的业务对象（例如客户清单或会计帐簿）以及它们提供
的服务（例如生成结帐语句），这被称为逻辑设计。
3. 把业务对象及其服务映射为软件部件，即物理设计。
4. 决定部件在网络上的分布方式，即部署。
设计过程的每一步都需要经过反复调整。例如，在确定应用程序的需求时，设计
者首先调查最终用户和业务经理，写出叙述性的用户使用脚本。将该说明书发回
用户，以便进行核对并获得反馈信息。这个过程可能需要重复进行好几次，每一
次都使得需求说明更加详细和精确。下一步，这个叙述性的用户说明书需要翻译
成形式化的描述，分解为业务对象和服务，然后该文档需要再次进行优化。
二．理解服务模型服务模型将应用程序的需求划分为三个大的服务领域，为设计
可扩展的分布式应用程序提供了结构框架。
服务是一些相关功能的集合，这些功能可以响应操作请求和信息请求，请求必须
遵守公开的接口和规范，而且只能通过一致的接口进行访问，但是具体实现被封
装起来了，对外部是不可见的。
服务模型将应用程序看作用来满足客户需求的一组功能或服务。它鼓励开发人员
把应用程序划分为服务和功能的集合，开发出的功能模块能够被重用、被多个应
用程序共享，并能在网络上进行分布式的部署。
按照这种观点，服务的规格说明是服务的提供者与使用者之间达成的协议。服务
是通过接口来定义的。它允许提供者将具体的实现细节封装起来。正是这种协议
使重用成为可能，并且有利于在企业范围内实现一致的软件规范。
以 Microsoft 为例，字处理应用程序与电子表格应用程序可以共享同一个数据访
问部件，这样应用程序可以不知道数据的实际存储方式和存储地点。为了管理表
格性质的信息，字处理程序可以调用电子表格的服务。通过使用 ActiveX 控件、
对象和其它的可重用部件，许多服务对应用程序开发者是“立即可用的”。可以
自己开发提供这些服务的部件，也可以购买其它供应商的产品。
服务模型并不局限于某个特殊的产品包、某种技术或某个供应商。Visual Basic
提供了许多的工具和技术来开发基于服务的应用程序，它也可以很方便地与其它
工具结合。集体开发者能够在其组织内现有的或计划中的企业结构的基础上开发
基于服务的部件解决方案。
在典型的业务应用中，有三种服务类型。如下表所示，它们各自有各自的属性：
服务类型 服务的属性
用户服务 提供信息和功能、浏览定位、保护用户界面的一致性和完整性
业务服务 共享的业务政策，从数据中生成业务信息，保护业务的一致性
数据服务 数据的定义，永久数据的存储和检索，数据一致性的保护
除了定义应用程序中每一种服务的功能之外，上面的分类还为进行结构化开发的
开发小组和开发过程提供了一种组织线索。在“开发策略”中讨论了开发组和开
发过程模型。
注意 值得注意的是，有一些“中间层”服务不能很明确地归为三类之一。例如
，作为应用程序支持服务的图形处理、纯粹的数字计算以及安全服务等通常既不
属于用户服务和数据服务，也不是严格的业务服务。
各种服务通过网络联系在一起并且相互合作，从而支持一个或多个业务进程。在
这种模型下，应用程序是用户、业务以及满足一定需求的数据服务的集合体。
服务总是被设计成通用的，并且遵守公开的接口标准，所以它们可以被重用，并
能被多个应用程序所共享。
用户服务
用户服务提供了一个可视化的接口，用来表示信息和收集数据。它们确保业务服
务能够提供所需的业务处理能力，并且使用户与应用程序紧密结合起来，以处理
某项业务。
用户服务通常表现为用户界面，而且通常位于最终用户工作站上的一个可执行程
序中。然而，有时候几个服务可能位于几个分离的部件之中。例如，某种数据表
示方式需要使用可视化的网格显示数据，而网格位于另外的 ActiveX 控件中。
业务服务和其它的“中间层”服务
业务服务是联系用户服务和数据服务的“桥梁”。它们响应用户（或其它的业务
服务）发来的请求，执行某种业务任务。为了完成这些任务，它们对相应的数据
运用形式化的过程和业务规则。如果所需的数据驻留在数据库服务器上，通过它
们可以获得所需的数据服务，或运用需要的业务规则。用户不能够直接与数据库
打交道。
业务任务是由应用程序的需求定义的一种操作，例如添加一个定货单或打印客户
列表。业务规则是控制业务工作流程的策略。例如，在生成客户发票的时候，需
要在库存价值的基础上进行一定幅度的上调，这就是业务规则。
与任务相比，业务规则更容易发生改变。所以在实现时最好将业务规则封装在单
独的部件中，与应用程序的逻辑分隔开。
例如，某个应用程序需要“得到销售价格”，这项服务可以被封装在中央网络服
务器上的一个部件中，应用程序可以访问它。如果计算过程发生了改变，仅需要
在一个地方进行修改就可以了，应用程序本身是不需要修改的。一旦业务服务改
变了，所有的“得到销售价格”请求都将使用已修改的业务服务得到新的计算结
果。
需要再次说明的是，某些中间层服务严格地讲不能被视为业务服务。例如，登录
屏幕用来提示用户输入密码以获得网络访问权，它实际上是与中央数据库服务器
连接的自动部件。图形处理程序经常会把计算量大的图形处理任务转移到有更多
CPU 处理能力的部门级服务器上进行。
数据服务
数据服务包括数据的定义、维护、访问和更新，以及管理并响应业务服务的数据
请求。
与其它种类的服务相比，这种类型的服务已经被研究了很长时间，所以就好理解
得多。它们的物理实现可以在某种数据库管理系统 (DBMS) 上，也可以是一个异
种数据库的集合，这些数据库可能驻留在多种平台上，运行在服务器和大型计算
机上。
将数据服务与应用程序的其它部件分离开，在维护、修改甚至重构数据结构及访
问机制时，可以丝毫不影响业务服务和用户服务。在“数据访问选项”中讨论了
数据服务的物理实现。
三．服务模型与分层模型服务模型使用逻辑上的三层结构，这不同于需要网络的
三个物理层的部署模型。
在日益增长的分布式计算文献中，三层结构模型有时会与其它各种“分层”模型
相混淆，后者为每一种服务划分出一个物理层和一个逻辑层。
这种物理意义上的分层模型需要严格的交互结构（层到层），而这在应用中常常
是不必要的。另外，分层模型还隐含了一种部署结构，每一层对应于一种计算平
台：数据服务在数据库服务器上，业务服务在一个或多个业务服务器上，用户服
务在桌面工作站上。
有两种流行的分层模型：
■ 两层模型鼓励进行任务划分，但是其技术平台仅包含客户桌面和后端服务器，
因而受到了限制。
■ 三层模型准确地标识了三种基本类型的服务。但是，要求它们之间的关系是非
常结构化的，必须从用户层到业务层，再从业务层到数据层，反之亦然。
真正的服务模型强调的是逻辑结构（概念意义上的），而不是物理结构（部署意
义上的），因此上面的模型都不是真正的服务模型。与分层模型相反，服务模型
允许服务在物理上驻留在任何地方。任何服务都可以根据特定的功能需求激发任
何其它的服务。同其它模型提供的物理分层方法相比，服务模型提供了更高的灵
活性和可重用性。
服务是逻辑意义上的，而非物理意义上的
服务模型描述了应用程序的概念结构。它强调的是逻辑意义而不是物理意义。它
说明如何设计应用程序，而不是如何具体部署。
在开发的实现阶段，各种服务之间的区别可能是比较模糊的。例如，某些业务服
务可能被实现为基本数据库管理系统中的触发器或存储过程。
术语“服务”是指“递交的功能”。术语“部件”是指“在实现时被封装在一起
的一个或多个服务”。
四．根据需求确定服务在使用服务模型进行开发时，需要逐步确定应用程序需要
的服务。
服务模型是一种应用程序设计方法，可以用于指导整个的开发过程：从需求说明
到基于部件的应用程序部署。最开始，需求被映射到服务，然后将服务映射到部
件，部件是真正的软件，它们可以分布在不同的服务器和工作站上，组成最终的
应用程序。
在从应用需求中概括出服务的过程中，首先需要确定各种概念性的“业务对象”
。“业务对象”是指提供或者使用服务的功能实体。另外，还需要为每一种服务
设计出系统接口。
业务对象
对于几乎所有的应用需求，将应用程序设计划分成若干子系统都是必要的。在子
系统中，又可以用类似的方式再次进行划分，直到划分出的小块足够的小，可以
作为问题的某一方面作出明确的定义。这些方面常常被称作业务对象，也就是业
务感兴趣的对象或实体，例如客户或订单。问题到底被分成多少“级”将取决于
原始问题的大小。
利用业务对象，可以在逻辑上封装服务，为业务的运作提供功能组合。为了处理
服务种类繁多的复杂情况，必要时可将特定业务对象所需的全部服务包装在一起
。
在利用服务模型设计应用程序的时候，需要确定要“请求”每个业务对象作什么
，而它能“提供”什么。在这种意义下，服务是一组相关的功能，用来处理常见
的业务活动或提取相关的信息。
业务对象是一种逻辑单元，但不一定是物理单元。在实际实现中，一个物理部件
可能包含几个业务对象，也可能包含一个或几个业务对象的一部分。
系统接口
为了有效地使用业务对象和服务的概念，需要进行结构化的功能划分，并定义功
能块之间的相互操作。在将它们实现为部件时，需要认真定义每个部件与系统其
它部分之间的接口。在开始实现之前，甚至在设计的最早阶段，就应该考虑到这
些接口的基本要素。要先在逻辑层上进行定义，该接口并不需要考虑到具体的物
理细节，但是它必须描述系统内的数据流、事件以及信息。部件本身可以被看成
是一个黑箱，只需要确定它的输入条件和输出结果，而不需要关心内部的细节。
（一）确定所需的服务
在确定服务并把它们组织成业务对象时，需要遵循一定的步骤，下面归纳出其中
的要点。业务对象最终将被实现为部件或者一组部件：
1. 确定业务解决方案必须提供的功能。创建使用脚本是一个良好的开端，本章的
“确定所需的服务：示例”一节将讨论这个问题。
2. 根据功能需求确定业务对象和服务。随着后续步骤中细节的增加，这个过程将
反复进行下去。
3. 把所有服务分为三种基本类型的服务（用户、业务或数据）。
4. 对每一个服务，确定所需的数据和功能，以及它与其它的服务提供者之间的关
系与相互依赖关系。
5. 决定服务的组织层次。定义必要的接口，以便与其它服务进行通讯。
一个业务对象可以包含实现其功能的三种基本服务类型，也可以仅包含一种类型
的服务。例如：一个“客户”对象可能包含所有的三种服务类型（他的购物和订
货历史记录、根据过去的购买情况确定折扣、输入和浏览订单）。另一方面，“
库存清单”对象可能只包含数据服务。
在评价整体和子系统的多种实现方案时，将业务解决方案描述为“服务网络”是
很有帮助的。对服务的描述（只与业务有关）不应该受到特定技术的局限，尽管
技术确实会影响对它们进行描述的方式。但是，从部件的角度来看，如何实现业
务是相对独立于技术的。
在这一阶段必须理解的一点是：业务问题能够被分解为若干服务的集合，从这些
服务推导出部件，部件之间相互作用形成应用程序。
（二）确定所需的服务：示例
为了说明如何确定所需的服务，可举一个例子。开始，先分析构成业务问题的最
高层业务对象。下面讨论的是一个简单的订货处理问题。
有很多方法和表示法可用于建立以下示例的模型，但是这里最关心的并不是采用
何种表示法。为了阐述清楚，使用简化的表示法就可以表达最主要的观点；在实
际工作中，应该使用最方便的表示法。
简单地描述需要解决的问题，然后说明如何解决这个问题。在该例中，需要解决
的业务问题是接受并处理客户的订单。开始需要向该系统的用户了解情况，然后
写出一份叙述性的用户使用脚本。在进行了几次交流之后，可能形成如下的解决
方案说明：
“客户向我们订购产品。我们把产品发给客户，并且更新库库存清单。在货物发
走之后，开出一张发票并邮寄给客户”。
在分析这种叙述性的使用脚本时，经常会发现名词对应于业务对象，而动词可以
对应于服务。在这个例子（高度简化的）中，名词包括：
■ 客户
■ 产品
■ 库存
■ 发票
与此相关的动词有：
■ 定货
■ 发货
■ 更新
■ 开发票
■ 邮寄
下一步，需要精确地确定每一个业务对象应有的特性和功能（作为功能说明的一
部分）。从动词列表出发（利用背景知识），得到每个业务对象的主要功能，如
下所示：
这些功能（以及其它的功能）还可以进一步进行细分，但是通常情况下，可以认
为这些功能就是满足业务问题（处理订单）所需的服务。
这是一个不错的开端。已经确定了一组服务，并且能够勾勒出初步的子系统。现
在，可以关注最主要的业务服务了。在功能说明中，还需要说明其它的需求：在
提供用户服务的时候如何进行显示和输入。根据业务服务，可以确定需要提供的
数据服务。下面的逻辑服务模型（为了清楚起见，压缩了数据服务层）给出了完
整的“服务网络”和子系统。
注意，该例子最后被划分为五个较大的子系统，每一个子系统包含了许多服务，
服务之间存在着相互作用。这种分组是功能上的，并不意味着需要五个单独的物
理部件。
（三）服务间的相互关系
为了满足某些动作或信息请求，一个服务有时需要调用其它的服务。服务间的相
互作用可以借助于消费者与供应者的概念进行说明。
消费者与供应者
服务对于其使用者来说是供应者，服务的使用者是消费者。良好的服务应该是其
使用者的供应者，又是其它服务的消费者。
每个服务都应有良好的接口，使其它消费者能够使用它提供的功能。
服务的重用不仅限于与它有供应者-消费者关系的服务。在完成开发之后，封装了
服务的部件被编入.Visual Basic Component Manager 的目录中，以备其他开发
者查看和重用。
关于部件管理器的其它问题，请参阅“客户/服务器工具”。
调用服务
服务的行为细节被封装起来，只能通过定义良好的公开接口调用服务。服务仅需
要知道下列协议：如何向其它服务发送请求，如何处理应答或结果。
为了编入目录以供重用，所有的服务都应说明它们的输入参数和返回值。
某些外部事件或系统状态的变化可能引起服务间的相互作用，这可能需要调度（
可能是通过时钟），也可能是没有调度的（可能是被用户的动作或其它的服务请
求触发）。
在定义服务时与实现有关的问题
在实现时，应用程序服务被装入软件部件包中。服务的实现应该遵循以下原则：
使用子模块、调用方式简单、维护成本低。通常需要对颗粒度加以权衡：颗粒度
越低，子模块就越多；但是子模块越多，系统就越复杂。
还需要权衡性能、安全性、网络带宽以及其它因素。例如，某些业务规则本来可
以实现为 SQL 存储过程，为了使编码和调试的效率更高，可以将其实现为 Visu
al Basic 的远程自动化服务器。换一个角度来看，为了安全性或是数据传输方面
的原因，最好是在 DBMS 中实现业务规则。
每类服务的实现通常都采用特定的工具和技术，从而使每类服务的开发组只需集
中精力研究专门的技术领域。例如，业务服务组可能只需要擅长使用 Microsoft
C++ 和 Remote Automation 对象的创建，而不需要对 Microsoft Visual Basi
c 或某种 DBMS 有深入的了解。
服务类型之间的接口可以使用标准的工业技术，例如 Windows Open Services A
rchitecture (WOSA) 和 Component Object Model (COM)。如果一个公司遵循这
些规则，将能够从市场上购买其它厂商（甚至是在同一业务领域的竞争者）提供
的合乎这些标准的部件。
关于实现问题的详细讨论请参阅“设计指南”。
第三节 客户/服务器工具
描述了企业版中用于在网络上开发、测试和使用基于部件的应用程序的工具。这
些工具同时支持远程自动化和分布式部件对象模型 (COM)。
Microsoft Visual Basic 5.0 企业版，提供了在三层服务模式基础上建立基于部
件方案的设计策略。本章介绍用于建立这些分布式解决方案的软件工具和实用程
序。
此处描述的工具和实用程序，允许企业开发人员把业务规则或数据服务封装到可
重定位的部件中，在物理上，这些部件与用户界面和应用程序逻辑上是分开的，
允许在网络上的任何地方部署和共享它们。
这些工具所包括的功能和实用程序，既支持远程部件交互的分布式 COM，又支持
这种交互的远程自动化。这些工具包括一组创新的设计和调试功能，以创建与远
程客户/服务器数据库交互的对象，这些工具中还有功能齐全的性能资源管理器，
有了这个管理器就可用不同的部件配置方案进行试验，并在自己的网络上从物理
上度量它们的相对执行能力和弱点。
下列内容简要介绍和总结了每个工具的用途和优点，从而可以纵览企业版全貌，
了解它的功能。
主题
一． 分布式 COM 和远程自动化工具介绍工具和概念，以协助使用分布式 COM 和
远程自动化，使得部署和访问远程 Windows NT 和 Windows 95 系统上的 Activ
eX 部件（以前是 OLE Automation 服务器），就象处理本地部件一样。
建立基于部件的解决方案，需要预先建立部件，并为通过网络进行远程访问而部
署部件。它的复杂性是三层结构的客户/服务器方案没有被广泛采用的主要障碍。
Visual Basic 4.0 版在远程自动化的介绍中讲述了这一不足。目前已采用分布式
COM 改善其性能，分布式 COM 增强了行业标准化部件对象模型。远程自动化仍
然保持向后兼容性，可以部署在 16 位系统上。4.0 版提供的所有远程自动化实
用程序都支持两种远程系统。
Visual Basic 允许创建 ActiveX（以前是 OLE Automation）部件，也允许在远
程 Windows NT 和 Windows 95 系统上部署和访问这些部件，同处理本地部件一
样。客户执行与服务器执行没有任何区别，所以可在客户工作站或远程服务器上
运行 ActiveX 部件，而不用重新编译客户应用程序或 ActiveX 部件。
（一）DCOM与远程自动化之间的区别
在单机上，对于 ActiveX 部件与客户进程的连接的每一端，部件对象模型都自动
提供代理/通讯模块组合。
就物理上独立的机器而言，分布式部件对象模型对机器上的部件本质上是一视同
仁的，都提供透明的代理/通讯模块和网络传输服务。
远程自动化提供额外的软件部件，即自动化管理器，并用那些能够通过网络进行
通信的模块取代原代理/通讯模块组合。
自动化管理器驻留在远程计算机上，并把整理好的（已打包的）请求从本地机器
上的远程自动化代理传送给服务器上相应的远程自动化通讯模块。自动化管理器
将排列返回值，并通过远程自动化代理返回到 ActiveX 客户部件。不论客户机还
是服务器，都不知道连接是远程的。
下面各部分将进一步说明注册、编目和导出 ActiveX 部件的实用程序。这些实用
程序包括：
■ 客户注册实用程序
■ 远程自动化连接管理器
■ 缓冲池管理器
■ 部件管理器
建立和测试远程部件
为了建立和演示分布式 COM 以及远程自动化，在 Visual Basic 安装的 \Sampl
es\Entrpris\Hello 目录中提供了一个简单的示例应用程序。在《程序员指南》
的“发布应用程序”的“安装远程自动化和分布式 COM 部件”中，提供了在不同
的机器上分别建立客户和服务器部件的指令。
按照指令安装并注册部件后，就可以在本地计算机上运行客户端应用程序 (Helo
_cli,exe)，而服务器端部件 (Helo-svr.exe) 既可以本地运行，也可以远程运行
。要实现服务器端部件的部署在本地和远程切换，应使用远程自动化连接管理器
，这将在本章后面介绍。
（二）客户注册实用程序
客户注册实用程序用于在客户机上为远程执行注册 ActiveX 部件。该实用程序
要用到 Visual Basic 建立的部件的 .exe 文件和同时生成的 .vbr 文件。
客户注册实用程序有两种版本：Clireg16.exe 和 Clireg32.exe。16 位版用来为
16 位客户应用程序注册 ActiveX 部件。32 位版用来为 32 位客户应用程序注
册部件。如果相同客户机器上的 16 位和 32 位应用程序都用到服务器，则必须
同时使用这两个注册实用程序。
客户注册实用程序是命令行程序，主要由安装程序用来“暗中”注册 ActiveX 部
件。对于交互式连接管理，后面讲述的远程自动化连接管理器更便于使用。
（三）连接服务器
远程自动化连接管理器实用程序 Racmgr32.exe 位于 Visual Basic 的 \Clisvr
子目录中。它使 ActiveX 部件注册从本地到远程的切换更加简单，同时简化了
设置访问安全性选项。不要被其名称所迷惑，实际上，对于分布式 COM 和远程自
动化所使用的部件的注册，它都能胜任。
使用远程自动化连接管理器
连接管理器左端的列表框可显示类，而且 Windows 注册表把这些类当作潜在的
ActiveX 部件列出。在右端的标记对话框提供访问和连接设置值。
“服务器连接”选项卡提供了一些选项，从而可在本地机器上快速方便地测试、
调试远程自动化部件，然后直接为远程使用来部署它们，即使客户部件正在运行
也可以这样。
对于远程访问，对话框中的三个字段分别指定服务器名字、协议和身份验证选项
。下例所述的是这些字段的可能选项。
字段 示例项
Network Address VBSQLSVR
Network Protocol TCP/IP
Authentication Level (No Authentication)
要在远程访问和本地访问间进行转换，应在服务器名字上单击鼠标右键，并在已
出现的上下文菜单中选择“远程”或“本地”。从列表中选定多个项就可同时改
变几个类的注册。
“客户访问”选项卡允许在四个服务器安全性选项中可视地选择。
■ “禁止所有远程创建”禁止客户远程访问所有类。
■ “允许通过关键字进行远程创建”只有在选定了“允许远程激活”复选框时才
允许从类创建对象。这就在 Windows 注册表中改变了它的 CLSID，从而包含以下
子键设置值。
AllowRemoteActivation=Y
选择该选项就启动了“允许远程自动化”复选框。
■ “允许通过 ACL 进行远程创建”只有当 Windows 注册表中的 CLSID 的“访
问控件列表”包含该用户时才允许从类创建对象。这只对 Windows NT 有效。
选择该选项后就可使用 Edit ACL 按钮，通过该按钮可编辑访问控制表。
■ “允许所有远程创建”允许创建任何对象。
（四）缓冲池管理器
ActiveX 部件被调用时就已创建好还是接到请求时才创建，是影响远程部件部署
性能的重要因素。大型 ActiveX 部件服务器要用几秒钟进行初始化和加载。为了
避免这种性能冲突，可用缓冲池管理器概念来维护预创建对象缓冲池，一接到请
求就把缓冲池分配给客户。
\Samples\Entrpris\Poolmngr 子目录中的 PoolMngr 示例工程是一个工作示例，
说明如何实现缓冲池管理器。该示例应用程序是简单的缓冲池管理器，可为客户
应用程序维护已打开的 ActiveX 部件实例。在这一方案中，客户部件向缓冲池管
理器请求引用要使用的对象。缓冲池管理器检查资源缓冲池，然后接受或拒绝该
请求。该方法有以下几个优点：
■ 避免为每个客户请求耗费冗长的对象创建，因为缓冲池通常在客户需要对象之
前就创建好了。
■ 根据客户请求的频率、潜在的客户数量和服务器任务持续时间，可创建（甚至
根据要求去调整）缓冲池的大小，这比服务器到客户的一对一分配要小得多。事
实上，合理的冗余是允许的— 例如，五个 ActiveX 对象实例的缓冲池大小可满
足六十个客户的正常需要。
■ 它用一个阈值限制可创建的特定部件实例数量，该阈值已由服务器管理员确定
。这是非常有用的调整参数。
用来初始化、调整和管理缓冲池大小的调度算法可以简单，也可以复杂，这要根
据需要而定。管理缓冲池大小的自定义因素还要包括最高加载时间和任务的紧迫
程度。
因为 PoolMngr 示例工程是用 Visual Basic 编写的，故容易改动，以确定自定
义方案，该方案根据具体环境要求而制定。
另一个有价值的远程部署管理方案是队列管理器，该管理器在应用程序性能评测
器中实现，本章后面部分将会讨论到它。
二．UserConnection 设计器介绍 UserConnection 设计器，有了它，在设计时
就可创建连接、查询（基于 RDO rdoConnection 和 doQuery 对象的）对象、并
一直把它们当作工程级对象。
UserConnection 设计器使用 Visual Basic 新的 ActiveX 设计器体系结构，对
要编程的数据访问提供设计时的支持。它允许在设计时创建连接并查询对象（基
于 RDO rdoConnection 和 rdoQuery 对象）。并把这些连接和查询对象当作工程
级对象。可预先设置属性、定义新属性和方法并给对象编写代码来捕捉事件。
这不仅为响应由连接和查询而引起的事件，而且为在运行时调用已存储过程和客
户定义的查询提供了简单的方法。
下面是使用 UserConnection 设计器的基本步骤：
1. 在“部件”对话框的“设计器”选项卡上，选中 Microsoft UserConnection
，于是就启动了设计器，而对话框可在“工程”菜单上获得。
2. 在“工程”菜单上，从“添加 ActiveX 设计器”项中选定 Microsoft UserC
onnection，把 UserConnection 设计器插入到工程中。
3. 用 UserConnection 对象的属性页建立连接信息，为可在设计时设置的属性指
定设置值。
4. 在目标数据库中选择存储过程，或为用户定义的查询插入 SQL 代码，从而为
连接创建新的 Query 对象。
5. 在属性页上设置属性，配置每个 Query 对象。
6. 编写 Visual Basic 代码，创建新 UserConnection 类的实例，然后象调用方
法一样调用它的任一查询。
（一）插入新的UserConnection对象
插入新的连接对象的步骤
1 确保在“引用”对话框中引用了 Remote Data Object 2.0 库，该对话框可从
“工程”菜单获得。
2 确保在“部件”对话框的“设计器”选项卡上选中“Microsoft UserConnecti
on”，从而启动设计器，该对话框可在“工程”菜单上获得。
3 在“工程”菜单上，从“添加 ActiveX 设计器”项中选定“Microsoft UserC
onnection”，从而把 UserConnection 设计器插入到工程中。
4 在“插入基类”对话框中键入 ConnectionDesigner.MyConnection，其中，My
Connection 是要给 Connection 类起的名字。
连接设计器属性窗口
当插入 UserConnection 设计器时，新的连接类已添加到了当前工程中。并出现
该类的可视化表示，被其属性窗口所覆盖。
UserConnection 属性窗口有以下三个选项卡：Connection、Authentication 和
Miscellaneous。
Connection 属性
Connection 属性用于在设计时（为检索可用的已存储过程的列表）建立与服务器
的连接，并保持在新的 UserConnection 对象中。因而，该类在运行时被创建不
必指定连接信息。该连接信息由数据源名字（或者，如果选定了 Use DSN-less
Connection String，则为驱动器和服务器名字）与“其他 ODBC 属性”框中指定
的任何专用连接令牌一起组成。
“使用 ODBC 数据源”框显示当前计算机上的所有 DSNs。也可通过单击“新建”
按钮来定义新的 DSN。
Authentication 属性
“身份验证”选项卡包括连接到数据源所需要的信息，而数据源是在连接信息选
项卡中指定的。这些连接的属性可能和新的连接对象一起被保持，也可能不会，
这要根据页底的复选框的设置值来决定。详细信息请参阅下面的“身份验证的持
久性”。
“用户名称”和“密码”文本框都自带说明。在输入密码时，密码框显示星号。
“提示行为”组合框允许选择 rdoConnection 对象的提示性能。
身份验证的持久性
由于事关安全性和密码保护，所以对 UserConnection 对象的身份验证属性有两
个级别的持久性可用。缺省情况下，这两个级别的持久性都被关上，所以不会出
现身份验证属性的隐藏或持久。
如果选择“保存新建 Run-mode 类的连接信息”，则用户名和密码属性被存储在
实际的类属性中，并在编译好的可执行文件或 DLL 中被保持。
如果选择“保存设计时的连接信息”，则用户名字和密码属性只在设计时被保持
，未被写入编译好的 .exe 或 .dll 文件中。
Miscellaneous 属性
连接属性页上的最后一个选项卡允许开发者为新的 UserConnection 类调整 Tim
eout 属性和光标库。
可将“登录超时”和“查询超时”值设置成 RDO 2.0 中允许的任何值。
“游标驱动程序”组合框包含的选项映射为 "CursorDriver" 属性的 RDO 常数。
UserConnection 设计器窗体
在输入属性建立 UserConnection 对象的 ODBC 连接之后，单击“确定”关闭属
性窗口。新的对象显示在主 UserConnection 窗体中。
窗体顶部的工具栏按钮允许添加单个或多个查询、删除查询、检查或改变查询属
性以及改变 UserConnection 设计器的全局选项。
（二）插入新的Query对象
新的 UserConnection 对象插入到工程中后，就可为它添加新的 Query 对象。这
些查询对象可以是存储过程调用，也可以是用户定义的 SQL 语句。设计时定义的
每个查询对象都自动被当作新 UserConnection 类的方法来使用。
为了添加 Query 对象，应单击工具栏上最左面的按钮。新的 Query 对象出现在
UserConnection 对象层之下，并显示其“属性”窗口。
选定存储过程
选定“插入存储过程”来查看数据库上可用的存储过程。UserConnection 设计器
试图使用用户输入的连接属性来建立与数据库的连接。如果成功，它将列举数据
库上可用的存储过程，并允许选定一个过程来定义 Query 对象：
插入用户定义的查询
选择基于用户定义的 SQL，来创建针对远程数据库的本地查询。这将启动 SQL 属
性框，可在该属性框中输入 SQL 语句定义查询。
也可以单击“创建”按钮，打开 MS-Query 查询设计工具。MS-Query 提供可视化
界面，允许拖放数据库表和字段，定义条件并设置关系来定义查询。在退出 MS-
Query 时自动把可视设计的查询转换为 SQL 代码，并将其插入到用户定义的 SQ
L 属性框中。
详细信息 关于使用 MS-Query 查询生成器的详细信息，请参阅 Visual Basic
CD 的 \Tools 目录中的 MSQry.hlp。
设置其它查询属性
除上述定义的属性外，Query Property Page 还有另外两个选项卡用于定义 Par
ameters 和高级属性。
“参数”选项卡在查询属性页上，允许开发者为当前查询中的每个参数调整属性
。
可自动从查询源来决定“参数”列表框中显示的参数，但不能在此改变这些参数
。在查询的 SQL 语句（或已存储过程的调用语句）中对每个参数标记都生成参数
。根据 ODBC 规范，参数标记由一个“?”来指定。例如，下面的查询包括两个参
数：
SELECT * FROM authors WHERE state = ? AND zip = ?
可在此改变的参数属性是名称、方向、ODBC 绑定数据类型和 Visual Basic 数据
类型。
如果参数的实际名字很复杂或不直观的话，可以改变 Name 属性，使 Visual Ba
sic 代码通过熟悉的名字来识别参数。
对于某些 ODBC 数据库，驱动器不能确定参数的方向（输入、输入/输出、或返回
值），所以，对这些数据库有必要设置参数的方向。同样，为使数据类型成为代
码能够使用的 Visual Basic 数据类型，需要覆盖缺省类型转换。
高级的 Query 属性
“查询”属性页的“高级”选项卡通过设置限制和阈值来微调查询。
“调用语法”编辑框允许改变调用语法，而且 RDO 将用这种语法来调用存储过
程。编辑它可以调整参数数量和返回值的表示。编辑调用语法是高级操作，应该
只由了解细节的开发者来做。
在代码中使用 UserConnection 对象
就象对待任何类一样，可把 UserConnection 对象插入到 Visual Basic 代码中
，创建对象变量，并用已定义的 UserConnection 类的新实例来说明。例如：
Option Explicit
Private MyConnect As MyConnection
Set MyConnect = New MyConnection
可在插入的 UserConnection 对象“之后”编写自己的代码，清除由连接或它所
定义的任何查询引起的事件。也可实现自己的方法，或编写 Property Get 和 P
roperty Let 过程来实现自己的属性，并将这些属性添加到新对象的类型库中。
三．T-SQL 调试器介绍 T-SQL 调试器，该工具可交互式地调试已存储的远程过程
，该过程是用 Visual Basic 5.0 版开发环境的 Microsoft SQL Server's Tran
sact SQL 语言编写的。
T-SQL 调试器完全与本章前面所介绍的 UserConnection 设计器集成在一起。它
允许交互式地调试用 Microsoft SQL Server 的 Transact SQL 语言编写的已存
储的远程过程，而该语言是 Visual Basic 5.0 版的开发环境内的语言。用 T-S
QL 调试器可以：
■ 显示 SQL 调用堆栈、本地变量和 SQL 已存储过程的参数。
■ 控制和管理断点。
■ 查看和修改本地变量和参数。
■ 查看全局变量。
安装和兼容性
为了使用 T-SQL 调试器，必须拥有 SQL Server version 6.5 以及作为数据库服
务器安装的 Service Pack 1。调试器使用 SQL Server 的 Sdi.dll 所显露的功
能，并通过远程自动化来显露该功能。
在安装 Visual Basic version 5.0 时，选择安装所有企业版工具，则能够正确
地完成安装和配置 T-SQL 调试器的客户端部件。如果需要重复安装过程，在“C
D 安装”对话框中选择“自定义”，对于“企业版工具”选项选择“全选”。
服务器端的安装
随着 SQL Server version 6.5 和 Service Pack 1 的安装，可在服务器上安装
和注册 SQL 调试器接口和远程自动化部件。这些部件位于 Visual Basic 安装的
\Entrpris\Tsql\SrvSetup 目录中。在 Windows NT 4.0 上，只需直接运行安装
程序 Sdi_nt4.exe 即可。
注意 为了在 NT Server 3.51 上进行安装，必须手工复制和注册必要文件。此
过程的全部指令都在 \Entrpris\Tsql\SrvSetup 目录的 Readme.txt 文件中。
使用 TSQL 调试器
调用 T-SQL 调试有三种不同的方法。
1. 在设计时调试存储过程或批查询，可通过 Visual Basic 的外接程序管理器添
加 T-SQL Debugger Add-In。之后，在外接程序菜单项下选中 T-SQL Debugger
启动它。然后只需选一个 DSN，选择存储过程或批 SQL，按“执行”按钮。就可
以调用调试器并调试 SQL 了。
2. 在 Visual Basic UserConnection 对象内部调试存储过程，可在 Query 对象
上单击鼠标右键，从菜单中选择“调试存储过程”，启动该 Query 的存储过程的
调试对话。
3. 在调试 Visual Basic 代码（运行时调试）的同时调试存储过程，可在 Visu
al Basic 的“工具”菜单的“选项”对话框中选中“T-SQL 调试器选项”，则可
以：
■ 打开自动跟踪存储过程，每次逐语句运行到 RDO 方法（要执行存储过程）都
会启动 T-SQL 调试器。
■ 打开安全模式，自动回滚设计时调试的查询。
■ 调试设计时查询时，限制出现在 T-SQL 调试器的输出窗口的行数。
■ 设置调试器在连接到数据库时使用的登录超时值，以得到内部 SQL 状态。
选中“通过 RDO 连接自动地逐语句运行存储过程”复选框后，如果逐语句运行
(F8) 到一行代码，该行代码执行调用存储过程的 RDO 方法，则自动启动调试器
。这样就可以逐语句运行存储过程并继续调试 visual basic 代码。
注意 如果存储过程在完成之前产生了足够的数据填充缓冲区，那么 SQL Serv
er 将在存储过程执行结束前返回。此时，T-SQL 调试器和 Visual Basic 调试器
将同时激活。Visual Basic 代码必须在存储过程完成其执行前从 RDO 取出结果
集。还要确保 basic 代码通过设置 Visual Basic 为运行方式 (F5) 读取结果集
，并且在需要中止执行的位置设置断点。使用任务栏或 Alt-Tab 键可在 Visual
Basic 和 T-SQL 调试器之间切换。
启动调试器后，将建立 ODBC 连接并显示“输出未赋值的参数”对话框。
在 Value 字段中输入任何未赋值参数的值，然后单击“确定”。随后就出现了
T-SQL 调试器界面，并显示已存储过程的文本.
调试选项
随着所显示的 SQL 语句，在工具栏按钮和“调试”菜单上的几个调试选项是可用
的。这些选项包括：
■ 运行
■ 设置和清除断点
■ 单步执行
■ 逐语句运行子表达式
■ 逐过程运行子表达式
■ 运行到光标处
■ 停止调试
■ 重新启动
视图和选项
除“代码”窗口包含正在调试的 SQL 语句外，TSQL 调试器界面还为局部变量、
全局变量以及查询输出（结果集合）提供不同的输出窗口。“查看”菜单还允许
打开独立的“字体”窗口和“临时表转储”窗口，因而可在代码执行时检查这些
内容。
通过“选项”菜单可改变显示的字体和颜色，以定义 T-SQL 调试器的外观。
从 T-SQL 调试器中退出
当完成了调试会话时，可选择“文件”菜单的“退出”命令来关闭调试器并返回
到 Visual Basic 工程中的 UserConnection 查询。
为再次执行该查询，可选定“调试”菜单的“重新启动”命令。
疑难解答
如果使用 T-SQL 调试时有问题，需要检查服务器上的事件日志。SDI.DLL 将在事
件查看器的应用程序段记录事件。COM 或 分布式 COM 错误将在查看器的系统段
记录事件。
■ 确保两台机器能够通讯。如果是使用 TCP/IP，只需在服务器的命令状态下键
入 ping 以及客户机的名称。如果失败，检查并修复两台机器之间的连接问题。
■ 确保 SDI.DLL 和 SQLSERVR.EXE 在同一目录下。即，在 SQL Server 目录下
的 binn 子目录。缺省为 c:\mssql\binn。
■ 确保服务器端的 RPC 服务已经启动。可以启动控制面板，打开服务应用程序
，检查远程程序调用 ( RPC ) 服务和远程程序调用 ( RPC ) 定位程序正在运行
并设置为自动启动。
■ 确保 SQL Server 没有被设置为以 SystemAccount 登录。可以启动控制面板
，打开服务应用程序并双击 MSSQLServer 服务。如果服务被设置为以 SystemAc
count 运行，更改它使服务器以所在域一个合法的帐号登录。如果调试仍然失败
，那么应确保 SQL Server 的启动帐号有足够的权限在客户机上运行自动化服务
器。
■ 如果在事件日志看到 COM 错误 80080005。应确保未从命令状态启动远程自动
化 ( autmgr32 )。Autmgr32.exe 只能运行在以 SQL Server 的登录帐号登录的
windows 工作站。其它的 windows 工作站会产生问题。如果是这样，通过任务
管理器关闭 autmgr32.exe 并让 sdi.dll 和 autprx32.dll 通过 COM 加载 aut
mgr32。
■ 如果在服务器和客户机上都未安装和加载分布式 COM ( DCOM )，应确保远程
自动化成功地安装在服务器和客户机上。
■ 如果客户机是 NT 4.0 或更高的版本，应运行 DCOMCNFG 并确保每个用户都具
有对 vbsdicli.exe 运行和访问的权限。
四．应用程序性能评测器介绍一个（用 Visual Basic 编写的）软件实用程序，
该程序可直接运行自动化的“what-if”测试，以配置不同网络拓扑结构中的多层
应用程序的性能，并考虑诸如网络带宽、请求频率、数据传递要求、服务器性能
等因素。此外，APE 本身就是设计得很好的分布式应用程序的例子。
“应用程序性能评测器”(APE) 是用 Microsoft Visual Basic 编写的软件实用
程序，用来协助分布式客户/服务器应用程序的设计、计划部署和性能调整。有了
APE 就很容易运行自动的“what-if”测试，以便在不同的网络拓扑结构中配置
多层应用程序的性能文件，并考虑网络带宽、请求频率、数据传输要求、服务器
能力等因素。
此外，APE 本身也是一个设计得很好的分布式应用程序的示例。其 Visual Basi
c 源代码有很好的注释，结构也合理，可作为基于部件的客户/服务器应用程序的
“模板”。很容易用源代码作为自己的多层方案设计的起点。
详细信息 可在 Visual Basic 安装的 \Samples\Entrpris\Ape\Src 子目录中
找到应用程序性能评测器的源代码。
在分布式环境中配置性能文件
多层客户/服务器应用程序把功能分割成独立的部件，这些部件可通过种类广泛的
物理部署配置分布在网络上。对这些分布式应用程序的设计器来说，关键性能问
题不是调整不成熟的代码执行，而是为分布式的方案确定最适宜的网络拓扑结构
。
“应用程序性能评测器”允许在不同的网络配置中快速建立测试情况并测量不同
条件下的性能，从而协助这种设计。用 APE 来探究可选的方案很容易说清楚以下
问题：
■ 一定更有效地将服务打包成一个大型部件，还是用许多较小的部件将功能分解
？
■ 更好地在远程服务器上部署特殊的计算加强型任务以利用最佳计算资源呢，还
是在本地桌面机器上把网络通信量最小化？
■ 当添加更多的客户时会对方案有什么影响？
■ 在最坏的网络条件期间，方案的瓶颈是什么？
■ 当对后端服务器的请求超过其能力时在性能方面会出现什么问题？
远程部署模型
APE 为远程异步和同步执行与管理对象提供了内置模型。
APE 通过两个独立部件的合作模拟远程任务：运作器（worker）和服务（servic
e）。这是一种基于部件的良好的设计思想，把执行上下文（运作器）从实际的计
算例程或业务服务（服务）中分离出来。由于远程部件被最有效地包装成进程内
服务器，所以这些部件在执行它的远程机器上需要过程空间。工作者部件提供这
个过程空间和执行线程，而服务则封装应用程序指定的功能。
同步（直接例证）模型
应用程序性能评测器实现同步连接，就象从客户应用程序直接向位于远程网络服
务器请求一样。因为连接是同步的，所以客户应用程序将等候任务完成，而且在
服务器返回以前都被堵塞着。在“模式”菜单上选定“同步”，就可从 APE 的用
户界面上直观地解释了这种模式。
如简图所示，客户创建了运作器，运作器接着又创建执行工作的服务。当完成了
服务时，运作器和服务都被破坏。附加的客户创建附加的运作器和服务，而绝不
与其它客户共享运作器和服务。
异步（排好队的对象）模式
直接实现的一个缺点是启动运作器和服务对象所花费的开销。当运作器结束一个
客户时，运作器和服务都被破坏。
更好的方法是使运作器保持“活动”，减少它们初始化时的开销。对此有许多方
法，其中包括缓冲池管理器和队列管理器方案。如下所示，对于异步操作，APE
实现队列管理器。
在最简单的情况下，队列管理器创建一定数量的运作器，所有运作器最初状态是
“不忙”。当收到客户的请求时，队列管理器分配一个运作器，把它标记为“忙
”，用运作器来执行服务，直到完成才把它的状态改回到“不忙”。队列管理器
接受所有请求，并按照先到先服务的原则分配运作器。
因为队列管理器在内部维护其队列，所以不会拒绝客户请求。如果所有预先分配
的运作器都忙，则队列管理器直接等到某个运作器可用时才依次把它分配给下一
个正在等待的客户。在分布式方案中，可用这样的队列使运作器一直忙。这就使
服务器运行在最佳性能级上 ─ 即完全加载。
带有回调的、排好队的对象模式
以上仅指出了队列管理器完成工作所需的最少步骤。对于将状态信息返回给客户
，或者为了管理而登录事务信息，都没有作任何安排。
通常可用两种方法之一来传送返回信息：通过返回值同步传送，或通过间接的通
知机制异步传送。如前所述，同步（直接）方法使客户程序处于堵塞状态，等待
完成返回。对于异步操作则需要独立的通知机制。回调对象就提供了这样的机制
，该对象可通过 Visual Basic 中的 ActiveX 部件来实现。当服务器端要报告有
关事项时，回调允许客户继续处理并异步地得到通知。
为在队列模式中使用回调，额外的部件：“加速器”被用来排列返回给客户的信
息。
在操作中，客户实现一个内部回调类，它具有预先定义的方法。
1. 客户创建回调对象的实例，并把指向它的指针连同其工作请求一起传递给队列
管理器。
2. 队列管理器依次调用运作器，并传递回调对象指针。
3. 完成任务后，运作器用返回信息调用加速器并再次把指针传递给回调对象。
4. 最后，加速器异步回到客户对象中。
正如所示，队列管理器、运作器和加速器都被送进了记录器中。
建立和测试 APE
以下提供三种独立的安装方式
1. 管理器安装─ 这种安装方式安装了为在一台机器上使用 APE 所需的全部部件
。其中包括管理器用户界面、服务器部件和客户。在安装 Visual Basic versio
n 5.0 期间，当决定安装所有企业版部件时，自动采用这种安装方式。
2. 服务器安装─ 这种安装方式只在机器上安装服务器部件。如果想要把一台机
器当作服务器使用，而又不想使用管理器或任何客户，则用这种安装方式。
3. 客户安装─ 这种安装方式只在机器上安装客户，在多客户方案中用来创建远
程客户。
4. 运作器安装─ 这种安装方式只在机器上安装运作器，在多客户方案中用来创
建远程运作器。
管理器安装包括使用应用程序性能评测器所需的全部部件，其中包括服务器端部
件。在单机上运行时，尽管在这种配置中不能远程连接服务器端部件，但 APE 的
功能是完整的。为快速使用 APE，可在一台机器上运行客户安装，启动应用程序
，选择已提供的任何配置文件，然后单击“启动”。
要执行远程测试，必须在第二台机器上使用 APE 服务器或远程客户安装，以保证
能够网络连接，并在服务器部件上设置远程自动化权限。
在第二台（或服务器）机器上安装期间应设置权限，从而在 APE 使用的类上允许
远程激活：
■ AELogger.Logger
■ AEPoolMgr.PoolMgr
■ AEQueueMgr.QueueMgr
■ AEServerMgr.ServerMgr
■ AEWorker.Worker
注意，本章前面已作过说明，以后可用远程自动化连接管理器修改这些权限。
执行远程测试的步骤
1 如果想把“远程自动化”当作传送机制使用，则在服务器上启动“自动化管理
器”。如果正在使用分布式 COM，则需执行该步骤。
2 在客户机器上启动“性能评测器”。
3 从下拉式“配置文件”列表中选择异步配置文件。
4 在“查看”菜单上单击“服务器位置”。选择“远程连接到服务器”复选框，
输入服务器的机器名字。
5 在“查看”菜单上，单击“Connection 属性”。单击“使用远程自动化”或“
使用分布式 COM”按钮，选择传送机制。选择两个机器都支持的协议和身份验证
级。
现在，已经准备好配置每个部件对象并运行测试方案，如“使用 APE”中所述。
使用 APE
在自己的环境和机器上，应用程序性能评测器有助于探究不同的分布式应用程序
方案。
使用 APE 的基本步骤是：
1. 选择模式。
2. 配置部件对象。
3. 单击“启动”按钮，开始测试。
4. 在屏幕底部的结果面板中查看结果。
在以上模式基础上，性能评测器允许控制各种参数以及在应用程序上确定其全部
效果。DPE 中用“空”例程实现所有分布式模式，使得很容易指定自己的部件对
象为 Service。
选择模式
在“模式”菜单上选择“同步”或“异步”。还可通过在下拉式“配置文件”列
表中选择内置的配置文件来选择预先配置的模式。每个配置文件都包含各种部件
类型的设置值，这些设置值共同形成要模拟的方案的“配置文件”。
通过个别配置每个部件还可创建自己的配置文件，然后在“文件”菜单上选择“
保存配置文件”。
配置 Component 对象
分布部件所支持的每种模式都使用相同的部件对象类型集合，并使用用户设置值
来控制它们的各方面功能。对每种对象，通过单击“APE 管理器”界面中对象的
表示来配置这些对象。这样产生的对话框允许指定要创建对象的数量、数据传递
选项、定时要求、回调选项和其它构造对象和使用对象的形式，允许灵活模仿“
现实世界”的情节。
每种部件类型都独立提供显示状态窗体和登录事件信息的选项。使用每个选项卡
底部的两个复选框就可启动这些功能。
评测器的有趣问题
应用程序性能评测器是功能强大灵活的工具，并可用它来回答许多有趣问题。最
重要的是，对于改变主要输入参数的数量可直接测试效果：调用的数量、对象的
大小、Service 是进程内的还是进程外的等等。
APE 可协助探究的其它问题包括：
■ 早期绑定和后期绑定相比，性能优点是什么？
■ 当超过网的容量时，模式将会发生什么事情？
■ 对使用异步通知的性能有什么影响？
■ 对详细事件登录的性能有什么影响？
■ 对环境来说，最适宜的部件大小是多少？通过改变 Service 参数和平等取代
自己的 Service 部件，可检查不同部件的大小，帮助确定如何将部件细分。
■ 最好的网络协议是什么？使用在“连接”选项卡上找到的协议参数以及任何安
装好的 RPC 传输协议，这有可能与远程对象通讯。
■ 调用安全性的适当级别是什么？使用在“连接”选项卡上找到的身份验证参数
就有可能把身份验证设置为任何被支持的值。通常，身份验证的较高级别增加了
经常性开支─ 控制该参数有助于确定调用安全性对应用程序的影响。
■ 当工作完成时在队列系统上完成的队列的动力是什么？由于可控制 Service
是否使用处理器循环，所以可以模拟控制队列是在专门系统上操作，还是在另一
个远程服务器上停止。
■ 当这些事情有一个发生时，客户的响应事件将受到什么影响？
示例应用程序
Hello (Helo_cli.vbp, Helo_svr.vbp)
Pool Manager (Pmgr_cli.vbp, Pmgr_svr.vbp)
APE (Aeexpdtr.vbp, Aeinstnr.vbp, Aelogger.vbp, Aepool.vbp, Aequeue.vbp
, Aeservic.vbp, Aeworker.vbp, Aewrkpvd.vbp, Aeintrfc.odl)为建立和演示远
程自动化，Visual Basic 安装的 \Samples\Entrpris\Hello 目录中提供了一个
简单的示例应用程序。在 \Samples\Entrpris\Ape\ApeSrc 目录中包含有应用程
序性能评测器 (APE) 的完整代码和工程文件。而 Pool Manager 示例则放在 \S
amples\Entrpris\PoolMngr 目录中。
第四节 开发策略
根据 Microsoft 自己成功的开发策略，介绍了在开发基于部件的客户/服务器应
用程序时管理项目组和进度的新办法。
当今的客户/服务器计算向我们提出了新的挑战，并需要新的开发和项目管理策略
。
传统的自顶向下的组织结构和线性的、循序渐进的开发策略十分适合整体的、完
备的、独立的系统。相比而言，基于部件的客户/服务器系统具有分布式特征，使
之更适合于小型的、相互协作的、自主的组模型以及周期性和反复性特点更强的
开发过程。
“服务模型”集中论述了基于部件的应用程序模型本身，而开发策略主题的中心
是管理组和过程的创新途径，这些过程包括创建客户/服务器应用程序的过程。
主题
一．开发模型这个主题介绍两种基于部件的软件开发策略模型：组模型和过程模
型。以这些模型作为大规模项目组织的基础。
基于服务的应用程序由联系松散的部件组成，这些部件来源广泛，包括由内部和
第三方公司开发的部件。此外，如果这些解决方案具有很强的交互特性，则对制
定解决方案的人员来说，同他们的目标用户发展和保持密切的联系比以往更重要
。随着当今技术变化步伐的加快，这些因素加在一起，给技术合作、对外交流和
快速的交互式开发带来了极为沉重的负担。
面对这些挑战，现在的组织需要运用灵活的新方法来开发应用程序。这一章简要
介绍 Microsoft 的两种已被成功运用了的主要策略。一个策略是对如何将同一开
发项目上的工作人员组织起来进行指导，而另一个策略是就开发过程自身的方法
提出建议。
特别要介绍的两种模型是：
■ 组模型，基于一个小的“同事组”的组织
■ 过程模型，一个反复的、基于里程碑的开发模型
Microsoft 咨询服务 (MCS) 已经把这些策略正规化，并已经用于大型团体客户，
这些客户具有千变万化的结构和五化八门的开发要求。这里所概述的原理和结构
甚至已被成功地引入到团体文化中，而这种团体文化是在自顶向下的组织结构和
传统的大型项目模型上建立起来的。
因为话题太广泛，本章只对组模型和过程模型作概念性的介绍。有兴趣用这些模
型进行项目开发的组织可直接同 Microsoft 咨询服务联系，以获得有关培训研讨
班和其它教育及服务的信息。
二．组模型客户/服务器开发的组模型基于这样一种想法，即同事组相互依靠，
地位平等。组成员既独立又合作，提倡一种主人翁思想，生产更好的产品。
客户/服务器开发的组模型，是一个小同事组的概念，各成员在工作上相互依赖、
分工协作。每个组成员在项目中都有固定分工，并专注于某个具体的任务。这种
工作方法能够激励主人翁思想，有利于最终得到更好的产品。每个组的领导负责
进行管理、指导和协调，而组成员则专注于执行具体的任务。
在组模型中可识别六个组角色：
■ 产品管理
■ 程序管理
■ 开发
■ 测试和质量保证 (QA)
■ 用户培训
■ 后勤计划
根据项目的大小，每个角色，或者由单人负责，或者由有主管的一组人负责。另
一方面，也可一身多职。
六个项目组角色之间的关系如图 4.1 所示。
图 4.1 六个项目组角色
角色各不相同的成员都以同等身份加入项目组，每个成员都为产品做出一份不同
的、但又是同等重要的贡献。角色是根据组的任务、职责和所要求的技能来定义
的。本章稍后将讨论每个组角色的具体职责。
根据这些相互依赖的组的概念建立起来的项目组织具有下列优点：
■ 使每人都对系统的成功承担风险。
■ 形成一种鼓励清晰、效率、参与、承诺及团体精神的文化。
■ 明确责任，避免个人或组依赖他人完成工作。
■ 允许开发工作集中于创建一个稳定的、顺畅的系统。
相互依赖的组
这些组主要是由一些经验丰富、技术精湛的领导和能够自我激励的组成员组成的
，这种组模型的特点是规模小、凝聚力强。
把每个功能组限定在三到七人之间能有效地保持注意力。如果问题很复杂，使得
任何一种分工都要求一个更大的组，则组领导可把问题分解成能够进行管理的几
块。这种注意力的层次可以减少风险，并更为有效地管理项目。
这里组的概念是指最低层的协作单位。在大型项目上，它是一组开发人员集中精
力于一个少数功能的研制开发，或是处于一个组产品管理员协调之下的一组产品
管理员，如图 4.2 所示，组产品管理员在组中扮演着产品管理的角色。
图 4.2 在一个组产品管理员领导下的产品管理员组
然而，如果项目很小，则整个项目可能被作为单个组来运做。
组角色
这六个组角色都有各自具体的作用和职责。不论这种角色是在小型项目中由个人
独自完成，还是在大型项目中由一个组来完成，这一点始终是如此。后面几节将
说明每个组成员的分工。
产品管理
产品管理员（或产品管理组）为项目建立和维持业务往来，他们在辨别和设置目
标客户的业务优先级中起了关键作用。这包括保证清楚地表达业务所期望的目标
，并使其为项目组所理解，还要保证功能说明书反映业务优先权。
产品管理员掌握项目的构思声明，这是一个非正式文档，用来沟通项目的期望成
果和项目基于的假设条件。
产品管理员也负责高层的项目交流，如业务计划、项目开销、合同协商等。产品
管理员还就最高里程碑与最终用户及组的其它成员进行交流。
程序管理
程序管理员或程序管理组“掌握”关于应用程序的特征和功能的说明书，以便进
行日常协调工作，这对在组织的标准范围内一致、有效地开发和交付应用程序是
必要的。
在组模型图中，程序管理处在中心位置，所以，它起着关键的交流和协调作用，
利用其它组主管的输入，程序管理可以帮助产品管理来清楚地阐明项目构思。使
用这个构思，程序管理可草拟出功能说明书的最初版本，因而程序管理被认为是
功能说明书的解释者。程序管理负责有关分析、说明和架构的全部活动。
程序管理还负责确定项目如何同外部标准协调，保持对外技术合作和交流以及管
理主进度的安排。
开发
开发组负责交付一个与功能说明书完全相符的系统。
这个角色的一个重要方面是积极参与制定功能说明书的过程。当提供有关技术可
行性的想法和讨论设计的可选方案时，开发工作与程序管理工作齐头并进，制定
出概念明确的原型。当为功能说明书规定基线时，对于如何解决最重要的问题，
以及如何使它们在开发进度方面职责明确，开发和程序管理必须取得一致意见。
组模型的核心概念是尽早建立基线，然后通过正式的变更控制来管理对基线所做
的变动。例如，在核心功能上取得一致意见后，程序管理就可以配合开发一起为
功能说明书尽快确立基线。随后，在开发工作继续对实现的可选方案进行验证时
，程序管理负责来评价所建议的变更。
测试和质量保证 (QA)
测试和质量保证组验证系统是否符合功能说明书。遵照无缺陷编码的思想，测试
/ QA 组将积极参与开发过程，保证质量是在产品制作中形成的，而不是经测试才
得以保证。该分工独立于开发，但又与开发平行，并同开发一起来进行检查和维
持平衡。
用户培训（文档）
用户培训组设计、开发并出版印刷品和联机的系统文档，包括各种指导材料。
正如用户所建议，用户培训组参与设计并构造系统和接口原型。它还参与设计并
提交安装程序和过程。用户培训可推动并参与可用性测试，并改进产品的设计，
还可同程序管理和开发密切合作，以确保产品的种类及设计上的变更反映在文档
中。
后勤计划
后勤计划组管理着一个从开发到实用的顺利过渡过程，确保能够顺利发行、安装
、转交到实用和支持组。它同开发主管一起工作，确保采用一种便于安装和管理
的方式来包装系统。
后勤计划也同操作人员协作，考虑诸如安装、故障排除、日常管理（包括局域网
和服务器管理）、灾难恢复计划和版本控制策略之类的问题。
后勤计划成员需要极其熟悉组织的文化和基础设施。他们必须理解目标实现环境
的性能问题、容量计划设想和操作程序。
划分组角色
在项目中，项目组的分工可能有一些不同。本章所描述的六种分工指明了一个项
目组必须具有的功能。然而，这并不意味着项目组中必须至少有六个成员。
根据项目和组的大小，可几个人共有一个组角色，也可将数个角色合为一体。图
4.3 说明对三人组承担的小型项目，如何将组角色合并起来。
图 4.3 合并项目分工的示例
对于在一个大型项目上六个成员以上的组，这些组的组织方式乃是将功能组和特
性组结合起来。
功能组
功能组由一个组管理员领导，并由执行相同任务和分工的组成员构成。例如，产
品管理组和后勤组的成员可以组织为功能组，因为他们的职责都同应用程序的整
体有关，而不是与应用程序的特定方面相关（参见图 4.4）。
图 4.4 功能组成员都完成一个单独的任务
特性组
另一方面，一个特性组通常由一个程序管理员领导，并由执行不同任务和分工的
组成员组成。特性组一般由开发人员和测试人员组成，根据产品的一组特征来进
行组织。每个特性组虽小，但和交付完整应用程序的组一样，都有它自己的功能
说明书和进度安排，并严格地执行任务（参见图 4.5）。
图 4.5 特性组是完整的“微型”项目组
总体项目结构
为使“同事组”这一概念可行，要求有一个总体项目管理员，能理解和支持组成
员的分工和能动性。与其说项目管理员直接负责每天的指导和项目跟踪，不如说
他是一个推动者。这个管理员可以是指定的项目管理员、业务或信息系统管理员
，这取决于团体结构。
图 4.6 说明了一个总体项目结构，它包含所建议的项目组分工。
图 4.6 项目报告结构
项目管理组
项目管理组包括项目管理员和若干个主管（每个主管负责一个组分工）。他们共
同负责安排进度和资源，评估风险以及跟踪项目的进度。因为每个组必须完成一
组任务，依照它所做出的承诺来交付成果，所以，关键在于让每个主管都参与项
目计划和管理。例如：
■ 尽管项目管理员可能要考虑项目的各种特征，初步评估如何应用组模型，但每
个组的主管也都应该有机会来考虑所有的因素，并判断风险。
■ 所有各组的主管都参与功能说明书的协商。对功能说明书的基线所提议的任何
变更都要求得到所有各组主管的同意。
■ 与其从上面将进度计划与看法强加给下属，不如让每个关键人物都有机会对整
体的进度和估计作出自己的贡献。
■ 随着项目的进展，每个组主管都要负责评价风险并参与权衡利弊。
如果组成员的意见不一致，则在必要时，项目管理员自可拍板定夺，统一看法。
显然会有这样的倾向—逐渐向较为传统的自顶向下的项目管理风格过渡。而只有
团体文化才能保证避免这种情况。
三．过程模型过程模型是一种反复的、基于里程碑的开发模型，帮助组织来安排
优先顺序，以并行的策略来推进工作，而不考虑任务的最后期限。
服务模型是高度分布的基于部件的模型，该模型提出一些新看法，将那些开发应
用程序的组组织起来，与此相类似，它也对开发过程本身提出了新方法。
传统的整体应用程序开发通常遵循流水式过程模型，在这种模型中，批准的里程
碑是一个阶段完成和下一个阶段开始的先决条件。这不太适合于客户/服务器应用
程序的基于部件的特征，因为各部件是采用并行方式而不是串行方式开发的。此
外，流水式过程模型还缺乏足够的灵活性和反应速度，这使得它不太适合快速原
型开发工具，也不适用于设计 GUI 驱动的桌面系统用户界面。
由于有了本章中提出的基于里程碑的过程模型，所以能够以并行的和反复的方式
开发重要任务。通过明确组责任，这种模型使得本章所提出的组模型能够最大限
度地发挥优点。它通过评估风险来设置优先权，并鼓励快速地交付应用程序。
（一）．传统的过程模型
传统的系统开发生命周期 (SDLC) 是活动的或任务驱动的，曾被许多公司采用。
这种传统的生命周期在各种方法学上有许多变种，通常由以下几个显著阶段构成
：
■ 定义 ■ 分析 ■ 设计 ■ 构造
■ 测试 ■ 过渡和移植 ■ 生产
“阶段”这个术语含有这样的意思，即在下一阶段开始之前必须完成每一组任务
。通常，各个不同的组处理生命周期中的一个阶段，在每个阶段都必须做大量繁
重的文档工作，从而使另一组能够承接起下一阶段的工作。这样做的结果，会过
早使决定冻结起来，从而降低灵活性。
虽然这种模型设法对整个开发生命周期中出现的任务进行分类，但并不识别和影
响客户/服务器开发的各种特性。
使用流水式过程模型来进行客户/服务器开发的主要问题在于它是着眼于任务，而
不是面向过程。这使得它很难作出灵活的决定，以适应迅速变化着的优先权；而
对于管理具有多个部件并且还特别强调桌面用户界面的客户/服务器开发项目而言
，这种变化又是十分重要的。
（二）．基于里程碑的过程模型
要克服这些障碍，要有一种更灵活、可反复、面向过程的开发模型。这里，基于
里程碑的过程模型是由产品生命周期模型派生出来的，在 Microsof 公司内，产
品生命周期模型相当成功。基于里程碑的过程模型提倡从过程方面而不从任务方
面去考虑工作。过程中的那些自动调节点都记载在里程碑上。
里程碑驱动的模型具有以下四个特征：
■ 基于里程碑的方法
应用程序开发过程由外部或内部里程碑驱动，这些里程碑是引导开发过程的检查
点。
■ 所有权和责任明确
过程模型对把每个里程碑的责任与项目组担负的任务挂钩。
■ 风险驱动的进度安排
尽早完成项目中的高风险部分。
■ 版本发布
版本发布概念是整个系统开发生命周期中的重要概念，因为对如何提出期望以及
如何计划和管理整个项目，这个概念都会施加影响。
以后各节中将逐一讨论这些特征。
基于里程碑的方法
如图 4.7 所示，这种过程模型由四个高层里程碑组成。
图 4.7 过程里程碑
完成代码 QA 构想 批准构思/范围
这些里程碑描绘成螺旋线上的点，而不是直线上的点，以此强调过程是周期性、
反复性的，但不是线性的。里程碑不是冰点。它们是那些可交付的成果被置于变
更控制之下时的“基线”点，这些成果是由里程碑来描述的。这有助于灵活应变
以及精益求精。
以下简要说明，这四个主要里程碑：
1. 批准构思/范围里程碑
一旦新应用程序引起人们的兴趣，并得到人们认可，就可组织项目组确定产品。
通过构思提出报告，这个报告划定范围并指点方向。构思/范围批准里程碑对最终
用户和开发组都是一次机会，利用这次机会，他们可在构思和范围方面取得一致
意见。
2. 批准功能说明书里程碑
下一个可视里程碑可用于提供功能说明书基线。说明书详尽介绍了应用程序，因
此，项目组可着手论证资源需求并做出有关承诺。在此里程碑处，用户和组成员
要对欲交付的成果内容达成一致意见，安排优先处理权并提出期望达到的目标。
这是一次重新评估风险的机会，也是对早期进度和资源所做的估计重新进行有效
性验证的机会。
3. 完成代码里程碑
经批准的功能说明书为启动集中的开发工作提供了基线。开发组在过渡阶段设
置了许多中间的交付里程碑，当然，关键的里程碑还是完成代码里程碑。完成代
码里程碑为用户和组成员提供一次机会，对此版本进行最后评估，并验证大批量
生产和各种支持计划以及各项程序是否到位。在此里程碑处，停止所有新开发工
作，并把任何未及时完成的功能记录下来，留待下次发布工作中处理。
4. 产品发布里程碑
在为编码制定了基线之后，“预发布”的（ Beta 版）程序、测试和质量保证活
动将与进一步的编码开发工作同期进行，推动系统朝着发布里程碑进行。发布里
程碑就是项目组正式把应用程序（或“产品”）交付运行并提交给支持组的时刻
。
四个里程碑是主要进展时刻，它们体现了开发的所有主要概念。四个里程碑都是
复查里程碑。另外，对各里程碑，可交付的成果并未定型，仍然可作更改。
注意 在整个这一章中，正在开发的应用程序常被看作“产品”。这里所定义的
策略的确是用于开发商业的上市软件，但不仅限于此。更确切地说，形成一种应
用程序就是“产品”的意识将大有裨益，为此，就要迅速开发应用程序，宁愿把
将来版本中新的或有风险的功能搁置起来，严守固定的交接期限和装运日期。
（三）．中间里程碑
除非整个交付进度的时间安排只有三个月或更短，否则只有四个里程碑的项目计
划并没有给人以充分的机会来管理和控制项目。所以应建立中间里程碑，每个组
主管都要为达到这些里程碑作出承诺。这使管理组在复查进度和协调交接期限时
发现问题，程序管理也能对整个交付进度表产生的影响作出评价。
对于外部可视的中间里程碑（向整个组织宣布的里程碑）包括：
■ 常规时间表的管理复查会议。出席会议者必须针对可交付的成果评估和复查（
正式的或非正式的）变更请求。
■ 功能说明书草案的可用性。功能说明书应指定临时交付信息模型和用户任务分
析。应当和用户一起复查和验证说明书的有效性。
■ 功能说明书基线之后的会议。出席会议者将批准各阶段成品定型的时间，如构
思的定型、数据库的定型和功能的定型等。
对于开发组内部的中间里程碑，有这样的实例：
■ 短期的、可交付的内部成果。这些可交付的成果应该每隔 5～10 天递交一次
，这样就可以对进展和风险进行现实的评估。
■ 同步化的点。这些点将保证功能说明书的各个成分保持一致，并被同一组假设
驱动。这些点应由程序管理定义，它们包括对数据模型、业务模型、用户界面以
及系统架构进行的讨论。
■ 渐增的内部发布工作。发布工作由开发来确定，最大间隔为六个月（建议三个
月交付一次成果）。
（四）．达到里程碑
应当根据每个项目的目标和特征选择通向里程碑的方法和技术。这些方法和技术
也应该与组织的标准和政策一致。
特别要注意这里所讨论的过程模型不依赖于任何特殊的方法论。各组织可继续使
用数据建模标记、用户面谈技巧以及其它方便的分析方法。他们也可选用较新的
面向对象的设计和分析方法。这些方法在自动化工具和培训课程中得到越来越多
的支持。
唯一重要的事情就是，技术和方法论应足够灵活，以适应正在发展着的客户/服务
器的实现技术。
所有权和责任明确
过程模型明确每个组成员的责任。如图 4.8 所示，达到关键里程碑的责任要明确
地与每个项目组的角色挂钩。计划、管理和执行与里程碑相关的任务，都是里程
碑“拥有者”的职责。这将鼓励抓重点，促进组合作，这些正是成功交付的关键
。
图 4.8 项目计划和管理责任
里程碑 拥有者
批准构思/范围 产品管理
批准功能说明书 程序经理
完成代码 开发、用户培训
产品发布 Q/A测试、后勤计划
按组角色来指定应付责任，这将鼓励自底向上的方法，而不是自顶向下的方法，
因此能够自我调节。在自我调节过程中，如有必要做或想要做的时候，就可以鼓
励组成员修改这个过程。
（五）。定义项目构思范围
产品管理拥有批准的构思/范围里程碑，而程序管理则是主要的贡献者。可交付的
成果就是项目构思/范围文档。当项目组和用户对文档的内容意见一致，而且对文
档进行版本控制时，就算达到了这个里程碑。这时，应在应用程序的概念体系中
，借助于使用脚本、功能以及业务对象，用概念术语来表达用户的需求。随着分
析和设计活动的展开，含义明确的里程碑对项目范围进行复查和评价里程碑将会
督促修订和重新评价项目计划和时间表。
（六）。形成功能说明书
一旦建立起项目构思和范围，所有组成员都要参与制定功能说明书。程序管理保
管功能说明书，并拥有功能批准里程碑的说明书。开发与程序管理一起制定开发
计划和时间表。在交付个人的那一部分功能说明书时，每个组成员都评估风险。
组成员可进行并行复查，开发原型并制定计划，确保制做并交付说明书所要求的
东西。
功能说明书可作为所有组成员与用户的一个合同。从总的业务目标、用户类以及
每个用户类希望执行的活动就可产生这个合同。它把用户需求按类分成逻辑用户
服务、业务服务和数据服务。
功能说明书明确定义了应用程序的构思设计、功能接口以及数据需求。它还定义
了外部接口、互操作性、性能目标以及其它把方法结合到方案中去的假设和约束
条件。
功能说明书反映了所有组成员达成的共识和作出的承诺，并推进内部进度和对外
交流。
（七）。从编码完成到发布
当功能说明书文档已定好基线，开发组基本上就拥有了完成代码里程碑。而且，
这又是一个反复过程，可能包括并行的开发和多种来源的全部部件。它还可能包
括许多 Beta 版本或“预发布”版本。
当整个组朝着产品发布里程碑推进时，所有组成员都负有具体责任。在最后阶段
，测试/QA 主要负责核查发布工作是否准备好，并把项目转交给后勤计划。
风险驱动的进度安排
顾名思义，风险驱动的进度安排是尽早对那些代表开发过程中风险最大的因素的
任务和部件做进度安排，并优先进行安排。
以下是过程模型中用来完成风险驱动的进度安排的指导原则：
■ 在拟就功能说明书期间，用来定义开发角色的方法会鼓励人们使用早期概念并
实现原型，以消除或弱化风险。在批准功能说明书之前，开发组要搞清楚是否已
了解有关的风险。随后，这个组将递交一份关于开发和交付的进度安排，并优先
安排开发发布工作。
■ 必须在功能说明书的定义中建立优先安排。基于技术上的风险，该组和用户在
优先权上取得一致意见。这将保证能够最先得到那些有潜在风险的功能和对业务
特别重要的功能。
■ 主要的里程碑不是可交付的成果已定型的时刻，而是在变更控制下放置一组假
设条件的时刻，于是可对这一时刻之后辨识出的风险作出规划并集中处理。
■ 随着功能说明书进一步完善，可能在到达正式的里程碑之前就已启动开发工作
。但放开来说，在此里程碑之前发生的事情都不是开发工作，这没有什么不可思
议的。这一点有助于早期识别风险。
■ 开发工作要使用分阶段的发布进度安排。这通常要涉及 1～3 次中间（beta
或“测试”）发布。每次发布都会牵涉到发布管理和测?/TD>
|
|