第 1 章软件开发方法 ( 三）软件开发技术

第1章软件开发方法 (三）软件开发技术计算机教学实验中心

问题的提出 • 什么是构件、中间件？ • 什么是CORBA、DOM和JEB？ • 什么是软件复用？ • 什么是C/S？B/S？ • C/S和B/S的区别？ • ……

1．了解目前主要的软件开发技术 2．了解构件技术 3．了解软件复用技术 4．了解CORBA、DCOM和J2EE技术 5．了解C/S和B/S技术及开发基础

软件开发技术 • 构件技术 • 软件复用技术 • C/S技术 • B/S技术

构件技术 • 软件产业和软件工程技术正面临着新的挑战。而传统的软件设计思想根本无法应对。在这一背景下，构件技术应运而生。 • 构件技术是基于OO技术上的更高级的抽象。它把底层的对象集合打成包，组成功能“插件”。基于构件技术的软件生产就是把已存在的构件组装（集成）到当前软件系统的框架结构中，从而生产出新的软件产品。 • 可以预见，构件技术是软件产业化革命的必然发展趋势。

构件技术概述 • OO技术是在“数据十算法”的基础上提升了对事物的认识方法。而构件技术则在“对象+算法”的基础上将认识事物的角度从对象个体本身提升到个体在群体中的作用。这个认识的提高具有本质的不同。 • 从抽象程度来看，OO技术已达到了类级重用（代码重用），它以类为封装的单位。而构件是对一组类的组合进行封装，可以将底层的多个逻辑组合成高层次上的粒度更大的新构件，甚至直接封装到一个系统，使模块的重用从代码级、对象级、架构级到系统级都可能实现。显然，构件技术将抽象的程度提到了一个更高的层次。 • 这种思想正在改变着软件的开发方法和人们的思维方式。

构件的属性 • 构件是可独立配置的单元，因此构件必须自包容。 • 构件强调与环境和其他构件的分离，因此构件的实现是严格封装的，外界没机会或没必要知道构件内部的实现细节。 • 构件可以在适当的环境中被复合使用，因此构件需要提供清楚的接口规范，可以与环境交互。 • 可以看出，构件沿袭了对象的封装特性，但同时并不局限于一个对象，其内部可以封装一个或多个类、原型对象甚至过程，结构是灵活的。

构件的使用 • 每个构件都需要先注册才能使用。构件是通过它们的接口特征来标识的，它们所提供的服务与访问方式是接口特征的一部分内容。要考虑的因素包括： • 应用编程接口（API）。 • 构件所需的开发和集成。 • 运行需求，例如资源的使用（内存和硬盘），时间或速度以及网络协议。 • 服务需求，例如操作系统的接口，或需要其他构件的支持等。 • 安全特征，例如访问控制和身份验证协议等。 • 嵌入式设计假定，有特定的数值/非数值算法使用。 • 异常处理。

实现构件技术的必备条件 • 有标准软件体系结构，保证构件间通信协议统一，实现同步和异步操作控制，突破本地空间限制，充分利用网络环境。 • 构件有标准接口，保证系统可分解成多个功能独立的单元，用构件组装而成。 • 构件独立于编程语言。 • 构件提供版本兼容，来实现应用系统的扩展和更新。

构件设计 • 因为构件依赖于平台环境，所以设计时有特殊要求： ⑴ 以接口为核心，使用开放标准。统一的开放标准有，CORBA、DCOM、EJB等。 ⑵ 构件语义的描述要形式化。在不同标准中，它们都有自己的形式化语义规定。如在EJB中有会话Bean和实体Bean事务描述符等。 ⑶ 提炼封装构件过程要严格记录。由于构件允许第三方使用，所以要保证第三方用户能正确理解构件设计思想，就必须记录每次提炼的变化。通常，要用版本来管理。 ⑷ 设计模式也可以重用。基于构件的系统开发的优点之一是重用，它的目标是代码、设计、解决方案都能重用。 ⑸ 利用开发工具。利用开发工具创建构件和应用软件。工具如Jbuilder、EJBMaker等。

中间件 • 构件是依赖于平台环境的。那么在分布式异构环境中如何应用构件呢？ • 中间件就是基于跨环境的构件应用而发展起来的。中间件是介于应用层和网络层之间的一个功能层次，是使应用系统独立于由异构操作环境（操作系统、硬件平台及通信协议等）组成的开发环境。 • 中间件扩展了客户/服务器结构，形成了一个包括客户、中间件和服务器在内的三层次结构及多层次结构，为开发可靠的、可扩展的、复杂的事物密集型应用提供了有力的支持。

构件和中间件 • 中间件是构件技术的一种实现，是构件存在的基础，它的本质是对分布式应用的抽象，应用是在中间件提供的环境中以构件的形式存在。 • 基于中间件开发的应用是面向需求的构件应用；构件专门用于处理应用的业务逻辑，而中间件负责解决与业务无直接关系的分布式应用中的支撑环境问题（例如，通信、互操作、可靠性、容错性等）。 • 构件的封装、设计与实现隔离，构件间的交互通过规范定义的接口进行；中间件在分布式交互模式上都规定了接口机制，可以解决构件间的交互问题。 • 中间件将应用构件与系统资源隔离，使得构件开发者不用考虑下层的系统平台。 • 中间件提供了构件封装、构件交互规则、构件与环境隔离等机制，为软件重用提供了解决方案。 • 中间件可实现互操作。

中间件分类 ① 基于远程过程调用RPC（Remote Procedure Call）的中间件，被调用的对象可以在分布系统中的任何物理平台上。SunSoft的ONC+属于这种中间件。 ② 面向消息的中间件，支持基于消息机制的进程间通信方式。例如，SunSoft的ToolTalk。 ③ 基于对象请求代理ORB（Object Request Brokers）的中间件，消息通过ORB进行路由选择，ORB同时处理集成和安全方面的问题。如Microsoft的COM、OMG的CORBA等。 ④ 数据库中间件，支持对异构的关系数据库系统的透明访问。例如Sybase的Open Server、Oracle的SQL Connect和BEA公司的WebLogic等。

中间件面临的问题 • 中间件提供的服务不是万能的，它所应遵循的一些原则离实际还有很大距离。表现在： • 多数流行的中间件服务使用专有的API和专有的协议，使得应用建立于单一厂家的产品，来自不同厂家的实现很难互操作。 • 有些中间件服务只提供一些平台的实现，从而限制了应用在异构系统之间的移植。 • 应用开发者在这些中间件服务上建立自己的应用还要承担相当大的风险，随着技术的发展他们往往还需要重写自己的系统。

J2EE技术简介 • Java平台的第一个参考实现是 JDK（Java Development Kit），但 JDK并不支持服务器端构件开发。为了提供服务器端部署的企业级服务，Sun公司开发了一些Enterprise API。但是早期的这些应用服务器暴露了Enterprise API的许多问题。为了解决Enterprise API的问题，Sun公司提出了三个不同的Java平台： • J2ME（Java 2 Platform，Micro Edition）是可用于Java设备（如Palm Pilots、呼机、手表等）开发平台。 • J2SE（Java 2 Platform，Standard Edition）支持标准JDK编程，包含基本的Java语言支持、JFC库及其对applet和application的支持。 • J2EE（Java 2 Platform，Enterprise Edition）是一个基于Java的完整的企业级应用开发平台，它与Java Enterprise API有机地结合、适合服务器端构件体系结构的开发。

J2EE的核心技术

J2EE的核心技术 • EJB是J2EE规约中最重要的部分。EJB提供了让客户端使用远程分布式对象的框架，规定了EJB构件如何与EJB容器进行交互等服务。 • RMI-IIOP用于实现Java和CORBA应用之间互操作。 • Java 名字及目录接口JNDI提供命名服务和目录服务，它是客户端代码连接EJB构件所必需的关键技术。 • 数据库访问接口JDBC同ODBC一样，允许程序员使用相同的接口访问不同的数据库，JDBC还具有跨平台访问各种数据库的功能。 • 消息服务JMS是一套与消息驱动的中间件通信的API。 • Java Server Papes（JSP）可以使不懂Java的人也能用Java编写动态网页。 • Java 接口定义语言IDL通过建立远程接口支持Java和CORBA应用的通信。 • Java Mail基于Java的电子邮件API。

EJB技术 • EJB（Enterprise Java Beans）不是一种“产品”，而是为开发和使用基于事务和分布对象应用的服务器端构件而定义的一种技术规约。EJB体系结构相对于CORBA而言，其最大的特点是简单性，可帮助软件开发人员快速地构建分布式应用系统。 • 在EJB组件模型中，一个组件本身只需执行那些与企业应用的业务逻辑密切相关的代码，而将组件的生存周期管理、命名与查找、并发控制、安全性、持久性、事物处理等服务交由组件的运行环境去执行。 • EJB的目标是为服务器端构件系统定义一个技术规范，该规范能提供一个标准的、分布的、基于OO的体系结构；能屏蔽复杂的系统级功能需求；能兼容CORBA标准；具有与非Java应用之间的互操作能力。

EJB组件的分类 • EJB组件模型将EJB组件划分为两大类： • 实体组件 • 会话组件 • 消息驱动组件（ EJB2.0 还包括第三类） • 组件模型对组件类型的划分实际上是将在应用实践中证明行之有效的设计模式固化在组件模型中，为开发人员提供一种简单、有效的组件开发与部署途径。

EJB的特点包括： • 清晰的体系结构：支持多层应用体系结构和基于构件开发。 • 简化的编程模型：EJB构件的开发者只需关注于业务服务实现，复杂的任务比如生命周期管理、持久性、事务处理、安全、一致性及资源管理等等都是由EJB容器负责。 • 通用的编程模型：提供各种服务的高层API，Java是其编程语言。 • 易移植性：可以部署到任何兼容的EJB容器中。 • 支持事务处理：可通过在代码外的描述来定义事务处理。 • 可扩展性：可以根据应用的增长而扩展，EJB服务器往往还提供了负载平衡。 • 安全性：由EJB服务器提供资源的访问权限控制。

COM+技术简介 • COM（构件对象模型）是Microsoft提出的第一个构件模型。它起源于OLE，当时的OLE使用DDE(动态数据交换)机制来支持程序之间的通信，由于DDE建立在Windows消息机制基础上，稳定性和效率都很差，由此诞生了COM。 • DCOM（分布构件对象模型）是COM技术在分布式环境中的延伸（COM仅支持同一台计算机上构件之间的互操作）。DCOM用网络协议来代替本地进程之间的通信，并针对分布环境提供了一些新的特性，如网络安全性、跨平台调用等。 • MTS（ Microsoft 事务服务器）是为满足企业应用而提供的基础设施。MTS可以为分布式企业应用提供服务器端的构件运行和部署环境，它把企业应用系统的客户程序、应用构件和各种资源有机结合起来（而COM／DCOM无法有效地实现）。

Windows DNA • 为了使Windows真正成为企业应用平台，Microsof公司又推出了Windows DNA（分布式互联网应用体系结构）。它是一个完整的、多层的新一代企业应用体系结构，也是一个服务器端的开发平台，它包含以下主要产品： • Windows NT／2000：操作系统。 • DCOM：支持分布式构件的核心技术。 • MSMQ：消息队列产品，支持构件间的异步通信。 • MTS：管理构件的应用服务器。 • Microsoft Wolfpack：支持集群服务器的软件。 • Microsoft SQL Server：一种关系型数据库管理系统。 • Microsoft IIS：Web服务器。 • Microsoft Management Console：部署和管理工具。 • 工具、数据库、操作系统、编程模型和应用服务等。

COM+ • 为了把COM、DCOM和MTS统一起来，形成真正适合于企业级应用的构件技术，诞生了COM+。 • COM+是一种中间件技术的规约，其要点是提供建立在操作系统上的、支持分布式企业级应用的“服务”。COM+与Windows DNA一起，使得用户可以采用Microsof公司的技术开发服务器端的构件。 • COM+的核心是改进的COM/DCOM和MTS的集成，但是COM+增加了一些非常重要的构件服务，比如负载平衡、驻留内存数据库、事件模型、队列服务等。COM+还支持所谓的申述式编程模型，它允许开发人员以较通用的方式开发构件，而一些细节则留到部署时再确定。

COM+主要特点 • 真正的异步通信。COM+底层提供了队列构件服务，允许客户和构件进行异步通信。 • 事件服务。新事件机制利用系统服务简化了事件模型，避免了COM可连接对象机制的琐碎细节，使事件源和事件接收方实现事件功能更加灵活。 • 灵活性。动态负载平衡以及驻留内存数据库、对象池等系统服务为COM+的灵活性提供了技术基础。 • 可管理和可部署性。COM+申述式编程模型和构件管理环境支持应用系统在开发完成后的管理和部署。 • 易于开发。COM+开发模型比以前的COM构件开发更为简化。

COM+ COM+目录负载平衡驻留内存数据库对象池新的事件模型构件管理和部署 JIT激活 MTS 事务支持资源分发管理安全模式易于管理远程支持 DCOM 分布式构件服务 COM 基于接口的编程模式基本的构件服务 COM+的基本结构

CORBA技术简介 • CORBA（Common Object Request Broker Architecture，公共对象请求代理体系结构）是OMG制定的、体系结构最完整、最清晰、跨越平台最多的分布对象模型。通过CORBA接口定义语言IDL定义接口，使用不同编程语言、不同编译器实现的构件，可以通过对象请求代理ORB进行连接，形成一个跨平台的应用。 • CORBA一般有两层意思：一是指对象管理组织OMG提出的分布式对象体系结构标准；另一层意思是按这种体系结构开发的中间件产品。CORBA作为一种应用级的互联标准得到了广泛的认同和应用。 • CORBA是一套规约，而不是一个产品，开发商可以开发不同的产品来实现 CORBA规约。例如，IBM公司的ComponentBroker等。

OMG • OMG是一个开放标准的非盈利组织，其目标是制定行业标准和对象管理标准，为应用开发提供一个公共框架，推动构件市场的发展。OMG成立于1989年，目前已拥有会员近千个，包括许多研究机构、大学和大公司，如IBM，HP等。

CORBA的发展 • CORBA规约的第一代主要集中在为分布式对象定义一个基础，其核心是ORB和IDL。 • CORBA 2.0增加了ORB互操作性规约，主要是基于TCP／IP的IIOP协议（因特网ORB互联协议）。1995年。 • CORBA 2.1增加了COM/CORBA互操作规范。1997年。 • CORBA 2.2增添了易移植的对象适配器POA和 IDL到 Java语言的映射规约。与此同时，对象管理体系结构OMA中增加了领域接口。1998年。 • CORBA 3.0增加了CORBA构件模型CCM（与COM+和EJB核心概念相似），提供容器（为构件提供运行环境）作为构件的运行环境，而诸如事务处理、安全处理、事件处理等公共服务都是通过公共 API访问。2001年。 • 但是，目前还没有成熟的、完全实现CORBA 3.0规约的产品。

CORBA的主要特征 • 在CORBA环境下应用系统间的互联是以对象或程序的调用方式进行的，实现系统间实时互操作。原则上，一个系统内部能够完成的操作，在系统之间通过CORBA都可以实现。 • CORBA的OO的特点还保证了各对象的封装性和内部细节的隐蔽性。这不仅可以简化各种功能的使用，还提高了系统的安全性。 • CORBA比较适合于分层结构的应用集成，这一技术比较适合于互联网应用系统核心业务逻辑的应用程序的集成。此外，由于目前应用服务器大多提供CORBA接口，这样利用CORBA技术完成应用程序和平台之间的无缝连接也比较容易。

OMA基准模型 • CORBA的基准模型是OMA。该模型描述了分布式对象系统的基本成分，有四个主要层次： • 对象服务是一组系统级的对象，为实现和管理对象提供了基本的功能，包括名字、生存周期服务、事务服务、安全服务等。 • 对象请求代理ORB是核心，它提供了一种机制，使得对象可以透明地发送请求和接受响应。ORB与对象服务相结合，确保符合CORBA基准的应用构件之间有效的通信。 • 公共设施是适用于众多应用领域的通用构件，例如信息管理、系统管理、任务管理和用户界面等。 • 应用对象是专用于特定领域的应用构件，OMG没有为它制定标准。

接口定义语言IDL • OMG IDL是CORBA的重要组成部分，是一种严格定义的接口定义语言。用OMG IDL编写的接口定义能完整地定义接口，并完备地说明每个操作的参数。OMG IDL已被ISO ORB采纳，自1991年公布以来，基本上没有改变。 • OMG IDL是独立于具体编程语言的，一个IDL文件可以向多种编程语言映射。CORBA包含IDL向具体编程语言的映射规约，例如，IDL到C，C++，Java等的映射。 • OMG IDL是独立于平台的，由IDL定义的接口可以在不同的ORB和平台上一致地表达。 • OMG IDL是一个纯规约，不涉及实现问题，IDL定义的接口不对对象实现进行任何约束。IDL将客户从对象实现细节中清晰地分离出来，从而更利于软件复用，因此被广泛接受。

软件复用技术 • 软件复用是指在软件开发过程中重复使用相同或相似软件元素的过程。软件复用是在软件开发中避免重复劳动的解决方案，它使得应用系统的开发不再采用一切从零开始的模式，而是以已有的工作模式为基础，充分利用过去应用系统开发中积累的知识和经验，从而将开发的重点集中于应用的特有构成成分。 • 为了能够在软件开发过程中重用已有的复用件，必须不断地进行复用件的积累，并将它们组织成复用件库。因此，软件复用不仅要解决如何检索所需的复用件，还要解决如何选取复用件、如何组织复用件库等问题。这类项目通常称为软件复用项目。 • 软件重用过程可借助于支持软件重用的CASE工具，其主要任务是：用某种组织结构实现复用件库的存储，提供友好的人机界面，帮助用户浏览、检索和修改复用件库，并且对用户感兴趣的复用件进行解释。

软件复用方式分类 ⑴ 依据复用的对象分类；可以分为： • 产品复用指复用已有的软件构件，通过构件集成得到新系统。产品复用是目前现实的、主流的途径。 • 过程复用指复用已有的软件开发过程，过程复用依赖于软件自动化技术的发展。 ⑵ 依据对可复用信息进行复用的方式分类，可分为： • 白盒复用指已有构件并不能完全符合用户要求，需要根据用户需求进行适应性修改后才能使用。 • 黑盒复用指对已有构件不需作任何修改，通过构件组装的方式直接进行复用。这是目前的研究热点，也是将来的发展趋势。

可复用的复用件 Caper Jones定义了可候选的十种复用件： ⑴ 项目计划：计划的基本结构和内容（如，SQA计划）。 ⑵ 成本估计：有可能复用对某个功能的成本估计。 ⑶ 体系结构：可能创建一组类属的体系结构模板（例如，事务处理体系结构），并将模板作为可复用的设计框架。 ⑷ 需求模型和规约：类和对象的模型和规约是可复用的，用传统软件工程方法开发的分析模型（例如，数据流图）也是可复用的。 ⑸ 设计：用传统方法开发的体系结构、数据、接口和过程化设计是复用的候选者，更常见的是，系统和对象设计是可复用的。 ⑹ 源代码：验证过的程序构件（用兼容的程序设计语言书写的）。 ⑺ 用户和技术文档：对特定的不同应用，可复用大部分用户和技术文档。 ⑻ 用户界面：可能是最广泛被复用的（例如GUI）。 ⑼ 数据：包括：内部表、列表和记录结构，以及文件和完整的数据库。 ⑽ 测试用例：一旦设计或代码构件将被复用，相关的测试用例也可复用。

建立复用途径的一些建议 ⑴ 建立内部的软件复用计划。这样一个计划可以帮助组织控制软件的质量和成本。 ⑵ 要求将软件复用作为任何技术和管理培训的内容。对OO的培训尤其应该如此。 ⑶ 按照内部的软件复用计划，寻求对软件复用有积极贡献的工具和库。 ⑷ 鼓励采用已被证明为可以促进软件复用的方法和工具。 ⑸ 跟踪并测度软件复用以及软件复用的影响；应客观评价，而不是主观臆测。 ⑹ 管理上必须积极地鼓励软件的复用。 ⑺ 认识除“模块”外，工具、测试数据、设计、计划、环境及其他软件均可复用。 ⑻ 最重要的是认识到软件复用不是“平常的业务”，大多数技术和管理人员是不接受软件复用的概念的。

软件复用面临的问题 ⑴ 管理问题。没有相应的鼓励机制等。 ⑵ 复用的障碍。 ⑶ 技术方面的问题 ⑷ 法律问题 • 显然，很多其他相关问题对复用也有影响，政治的、文化的、财政的、市场的、以及产品化等方面的问题也必须考虑。

复用的障碍 • 自负；太多的开发人员认为不是他们亲自编写的程序不可能是好程序； • 检索问题。如何从庞大的复用件库中所需要的复用件； • 几乎没有相应的复用培训； • 复用代价昂贵。有人估计，仅使一个构件可复用，就将至少增加60%的成本； • 虽然存在软件复用的CASE工具或构件，但大多数软件开发者并不使用它们； • 经济利益方面。一些开发人员尽力避免编写那些太通用的例程，唯恐使自己失业。

技术方面的问题 • 采用软件复用可以降低开发成本，但如果其原件存在的某些问题代码，可能会导致其他采用该代码的系统具有相同的问题代码；这种情况称之为继承性缺陷。 • 因此当原件的问题代码被修改后，往往无法自动更新实用软件中相应的代码；最终导致实用软件中的问题代码依旧存在。这种非但没有降低开发成本，反而增加维护消耗的复用技术显然是失败的。

法律问题 • 合同软件带来的法律问题。有些软件合同规定软件产品是属于客户的。因此，当软件开发人员为另一个客户开发一个新产品时，如果他复用了另一个客户产品中的一个构件，在本质上是侵犯第一个客户的版权。

C/S技术 • 客户机/服务器系统也称C/S(Client/Server)系统，它是基于局域网／广域网的系统。 • 在C/S中存在着服务器和客户端。为了充分利用客户机的计算能力，计算和事务处理在服务器和客户机之间分配。 • 服务器承担数据的集中管理、通信和客户管理的任务，因为数据在服务器端，对数据的处理和计算都在服务器端执行。 • 而人机界面和一些需要实时响应的事件或人机交互的处理等在客户端进行，这些程序都运行在客户端。 • C/S系统往往需要数据库服务器。

C/S系统体系结构特征 • 计算和处理分布在服务器和客户机之间。 • 数据管理集中在服务器端。 • 软件驻留在服务器和客户机。

C/S应用系统的特征 • 分布数据。出于安全性和负载平衡的考虑，数据库可以分布在多个数据库服务器上。 • 分布过程。不同的过程（事务处理、数据库连接等）可以在不同服务器上进行。 • 客户为中心。把需要在客户端执行的程序和定制的程序放在客户端，以使客户快速得到响应。把对数据进行处理的过程放在数据库服务器端，以加快数据处理速度。 • 异构硬件和软件。在C/S体系结构中很容易加入多层结构，屏蔽不同的硬件和软件。例如，加入应用服务器可以基于不同的操作系统和计算机主机，同样客户端安装的中间件可以基于不同的客户端系统，例如，Linux，Windows。

C/S技术目标 • 集成处理资源。把客户端、服务器端的处理能力充分利用，集成在一起完成系统的功能要求。 • 降低开发资源要求。在客户端和服务器端运行的程序分别存放，使得程序调试方便，开发比较简单，需要的资源也减少。在传统的数据库应用体系结构中（基于主机-多终端），数据库是应用程序“私有的”。虽然它也可以将数据文件放置在某台机器上供不同的用户共同访问，但所有的操作、规则，都是在一个包罗万象的应用程序内部实现的。应用程序因此具有最大的复杂性。 • 降低硬件和软件的要求。在 C/S系统中，客户机既有部分处理能力，价格相对较低，可以降低系统软硬件成本。 • 降低系统维护成本。因为在服务器端的处理和计算程序只需在服务器端维护，与客户机无关，而客户端程序比较简单，所以系统维护较方便，成本较低。 • 可扩充能力强。C/S应用很容易扩充，只要C/S联入网络即可。服务器有负载平衡的能力就可以允许不断增加并发客户。

C/S系统构成 • C/S结构发展经历了两个阶段：两层结构和三（多）层结构。

两层结构C/S系统 • 第一层是客户端软件，由应用程序和相应的数据库链接程序组成，企业的业务过程都在程序中表现。 • 第二层包括数据库服务器，根据客户端软件的请求进行数据库操作，然后将结果传送给客户端软件。 • 两层应用软件的开发工作主要集中在客户端，客户端软件不但要完成用户界面和数据显示的工作，还要完成一部分对商业和应用逻辑的处理工作。 • 两层结构的C/S系统仅能在各自的客户机和数据库服务器之间使用，分割了界面和数据，使得客户机要管理复杂的软件，导致“肥胖”客户机的产生。 • 两层 C/S系统不能进行有效的扩展，使这些系统不能支持大量用户的访问和高容量事务处理的应用。

三（多）层结构C/S系统 • 客户机上只安装具有用户界面和简单的数据处理功能的应用程序，负责处理与用户的交互和与应用服务器的交互。 • 而将商业和应用逻辑的处理功能移到中间层——应用服务器上。应用服务器负责处理商业和应用逻辑，接受客户端应用程序的请求，然后根据商业和应用逻辑将这个请求转化为数据库请求后与数据库服务器交互，并将与数据库服务器交互的结果传送给客户端应用程序。 • 数据库服务器软件根据应用服务器发送的请求进行数据库操作，并将操作的结果传送给应用服务器。

三层C/S结构优点 • 整个系统被分成不同的逻辑块，层次清晰，一层的改动不会影响其他层次； • 能够使“肥胖”的客户机变“瘦”； • 开发和管理工作向服务器端转移，使得分布的数据处理成为可能； • 管理和维护变得相对简单。

C/S结构的局限性 • 第一，C/S结构的计算能力过于分散，网络中服务器和客户机的数目正发生“细胞”分裂，使得系统的管理费用以几何级数的方式增长。 • 第二，C/S结构中数据库信息的使用只限于局域网的范围内，无法利用Internet的网络资源。 • 第三，在C/S结构中，无论多小的企业都必须安装自己的服务器，而服务器和服务器软件的管理和维护都是非常复杂的工作，需要专门人员负责，小企业往往无力购买高性能的服务器和聘用专门人员。因此，C/S结构不利于小企业计算机应用的发展。

应用子系统设计的指导原则 ⑴ 表示/交互子系统通常放置在客户端。基于图形界面的应用及程序驻留在客户端，这可快速响应用户的交互请求。尤其是在实现图形图像等复杂应用时，对于需要与本地资源（如调用本地磁盘文件等）进行交互性的操作，更是需要驻留在客户端的程序。这样做还可以降低网络流量。 ⑵ 如果需要多个客户共享数据，则数据库及数据库管理系统应该放在服务器端。 ⑶ 对DB进行操作的存储过程放在DB服务器上。对数据库进行插入、更新、删除的存储过程或触发器程序最好放在相应的DB服务器上，以减少DB连接、网络传输的时间消耗，降低DB连接过载发生的可能性。 ⑷ 用于引用的静态数据应该分配到客户端。把数据存放在需要它的最近地方，不必在网络中传输，减少服务器压力。

基于Web工程设计基础 • 基于 Web技术的 Intranet近年来正受到广泛的关注，这种以TCP/IP协议为基础、以Web技术为中心的应用正吸引着越来越多的企业以更快的速度、更低的费用去创建企业的应用系统。 • Web技术吸引人的地方是采用超链接和多媒体信息。Web服务器使用HTML描述网络的资源，创建网页，并以HTML数据文件的形式保存，以供Web浏览器阅读。 • Web 浏览器是一个用于文档检索和显示的客户应用程序，并通过HTTP协议与Web服务器相连。 • 目前，流行的IE和Netscape Navigator除提供基本的文档检索、显示和导航特性外，还支持HTML的高级显示（如表和帧）以及Active X、Java、JavaScript等特性。

第 1 章 软件开发方法 ( 三）软件开发技术