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

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

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

计算机教学实验中心

第 2|83 页

下一页下一页

上一页上一页

停止放映停止放映

问题的提出

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

第 3|83 页

下一页下一页

上一页上一页


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

第 4|83 页

下一页下一页

上一页上一页


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

第 5|83 页

下一页下一页

上一页上一页


构件技术软件产业和软件工程技术正面临着新的挑战。而传统的软件设计思想根本无法应对。在这一背景下，构件技术应运而生。

构件技术是基于 OO技术上的更高级的抽象。它把底层的对象集合打成包，组成功能“插件”。基于构件技术的软件生产就是把已存在的构件组装（集成）到当前软件系统的框架结构中，从而生产出新的软件产品。

可以预见，构件技术是软件产业化革命的必然发展趋势。

第 6|83 页

下一页下一页

上一页上一页


构件技术概述 OO技术是在“数据十算法”的基础上提升了对事物的认识方法。而构件技术则在“对象 +算法”的基础上将认识事物的角度从对象个体本身提升到个体在群体中的作用。这个认识的提高具有本质的不同。

从抽象程度来看， OO技术已达到了类级重用（代码重用），它以类为封装的单位。而构件是对一组类的组合进行封装，可以将底层的多个逻辑组合成高层次上的粒度更大的新构件，甚至直接封装到一个系统，使模块的重用从代码级、对象级、架构级到系统级都可能实现。显然，构件技术将抽象的程度提到了一个更高的层次。

这种思想正在改变着软件的开发方法和人们的思维方式。

第 7|83 页

下一页下一页

上一页上一页


构件的属性构件是可独立配置的单元，因此构件必须自包容。

构件强调与环境和其他构件的分离，因此构件的实现是严格封装的，外界没机会或没必要知道构件内部的实现细节。

构件可以在适当的环境中被复合使用，因此构件需要提供清楚的接口规范，可以与环境交互。

可以看出，构件沿袭了对象的封装特性，但同时并不局限于一个对象，其内部可以封装一个或多个类、原型对象甚至过程，结构是灵活的。

第 8|83 页

下一页下一页

上一页上一页


构件的使用每个构件都需要先注册才能使用。构件是通过它们的接口特征来标识的，它们所提供的服务与访问方式是接口特征的一部分内容。要考虑的因素包括：

应用编程接口（ API）。构件所需的开发和集成。运行需求，例如资源的使用（内存和硬盘），时间或速度以及网络协议。

服务需求，例如操作系统的接口，或需要其他构件的支持等。

安全特征，例如访问控制和身份验证协议等。嵌入式设计假定，有特定的数值 / 非数值算法使用。异常处理。

第 9|83 页

下一页下一页

上一页上一页


实现构件技术的必备条件有标准软件体系结构，保证构件间通信协议统一，实现同步和异步操作控制，突破本地空间限制，充分利用网络环境。

构件有标准接口，保证系统可分解成多个功能独立的单元，用构件组装而成。

构件独立于编程语言。构件提供版本兼容，来实现应用系统的扩展和更新。

第 10|83 页

下一页下一页

上一页上一页


构件设计因为构件依赖于平台环境，所以设计时有特殊要求：⑴ 以接口为核心，使用开放标准。统一的开放标准有， C

ORBA、 DCOM、 EJB 等。⑵ 构件语义的描述要形式化。在不同标准中，它们都有自

己的形式化语义规定。如在 EJB中有会话 Bean和实体Bean事务描述符等。

⑶ 提炼封装构件过程要严格记录。由于构件允许第三方使用，所以要保证第三方用户能正确理解构件设计思想，就必须记录每次提炼的变化。通常，要用版本来管理。

⑷ 设计模式也可以重用。基于构件的系统开发的优点之一是重用，它的目标是代码、设计、解决方案都能重用。

⑸ 利用开发工具。利用开发工具创建构件和应用软件。工具如 Jbuilder、 EJBMaker 等。

第 11|83 页

下一页下一页

上一页上一页


中间件构件是依赖于平台环境的。那么在分布式异构环境中如何应用构件呢？

中间件就是基于跨环境的构件应用而发展起来的。中间件是介于应用层和网络层之间的一个功能层次，是使应用系统独立于由异构操作环境（操作系统、硬件平台及通信协议等）组成的开发环境。

中间件扩展了客户 / 服务器结构，形成了一个包括客户、中间件和服务器在内的三层次结构及多层次结构，为开发可靠的、可扩展的、复杂的事物密集型应用提供了有力的支持。

第 12|83 页

下一页下一页

上一页上一页


构件和中间件中间件是构件技术的一种实现，是构件存在的基础，它的本质是对分布式应用的抽象，应用是在中间件提供的环境中以构件的形式存在。

基于中间件开发的应用是面向需求的构件应用；构件专门用于处理应用的业务逻辑，而中间件负责解决与业务无直接关系的分布式应用中的支撑环境问题（例如，通信、互操作、可靠性、容错性等）。

构件的封装、设计与实现隔离，构件间的交互通过规范定义的接口进行；中间件在分布式交互模式上都规定了接口机制，可以解决构件间的交互问题。

中间件将应用构件与系统资源隔离，使得构件开发者不用考虑下层的系统平台。

中间件提供了构件封装、构件交互规则、构件与环境隔离等机制，为软件重用提供了解决方案。

中间件可实现互操作。

第 13|83 页

下一页下一页

上一页上一页


中间件分类① 基于远程过程调用 RPC（ Remote Procedure Cal

l）的中间件，被调用的对象可以在分布系统中的任何物理平台上。 SunSoft的 ONC+ 属于这种中间件。

② 面向消息的中间件，支持基于消息机制的进程间通信方式。例如， SunSoft的 ToolTalk。

③ 基于对象请求代理 ORB（ Object Request Brokers）的中间件，消息通过 ORB进行路由选择， ORB同时处理集成和安全方面的问题。如 Microsoft的 COM、OMG的 CORBA 等。

④ 数据库中间件，支持对异构的关系数据库系统的透明访问。例如 Sybase的 Open Server、 Oracle的 SQL Connect和 BEA 公司的WebLogic 等。

第 14|83 页

下一页下一页

上一页上一页


中间件面临的问题中间件提供的服务不是万能的，它所应遵循的一些原则离实际还有很大距离。表现在：

多数流行的中间件服务使用专有的 API和专有的协议，使得应用建立于单一厂家的产品，来自不同厂家的实现很难互操作。

有些中间件服务只提供一些平台的实现，从而限制了应用在异构系统之间的移植。

应用开发者在这些中间件服务上建立自己的应用还要承担相当大的风险，随着技术的发展他们往往还需要重写自己的系统。

第 15|83 页

下一页下一页

上一页上一页


J2EE 技术简介 Java 平台的第一个参考实现是 JDK（ Java Developme

nt 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有机地结合、适合服务器端构件体系结构的开发。

第 16|83 页

下一页下一页

上一页上一页


J2EE 的核心技术

第 17|83 页

下一页下一页

上一页上一页


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。

第 18|83 页

下一页下一页

上一页上一页


EJB 技术 EJB（ Enterprise Java Beans）不是一种“产品”，而是为开发和使用基于事务和分布对象应用的服务器端构件而定义的一种技术规约。 EJB体系结构相对于 CORBA而言，其最大的特点是简单性，可帮助软件开发人员快速地构建分布式应用系统。

在 EJB组件模型中，一个组件本身只需执行那些与企业应用的业务逻辑密切相关的代码，而将组件的生存周期管理、命名与查找、并发控制、安全性、持久性、事物处理等服务交由组件的运行环境去执行。

EJB的目标是为服务器端构件系统定义一个技术规范，该规范能提供一个标准的、分布的、基于 OO的体系结构；能屏蔽复杂的系统级功能需求；能兼容 CORBA 标准；具有与非 Java应用之间的互操作能力。

第 19|83 页

下一页下一页

上一页上一页


EJB 组件的分类 EJB组件模型将 EJB组件划分为两大类：

• 实体组件• 会话组件• 消息驱动组件（ EJB2.0 还包括第三类）

组件模型对组件类型的划分实际上是将在应用实践中证明行之有效的设计模式固化在组件模型中，为开发人员提供一种简单、有效的组件开发与部署途径。

第 20|83 页

下一页下一页

上一页上一页


EJB 的特点包括：清晰的体系结构：支持多层应用体系结构和基于构件开发。简化的编程模型： EJB构件的开发者只需关注于业务服

务实现，复杂的任务比如生命周期管理、持久性、事务处理、安全、一致性及资源管理等等都是由 EJB容器负责。

通用的编程模型：提供各种服务的高层 API， Java是其编程语言。

易移植性：可以部署到任何兼容的 EJB容器中。支持事务处理：可通过在代码外的描述来定义事务处理。可扩展性：可以根据应用的增长而扩展， EJB 服务器往

往还提供了负载平衡。安全性：由 EJB 服务器提供资源的访问权限控制。

第 21|83 页

下一页下一页

上一页上一页


COM+ 技术简介 COM（构件对象模型）是Microsoft提出的第一个构件模型。它起源于 OLE，当时的 OLE使用 DDE( 动态数据交换 )机制来支持程序之间的通信，由于 DDE 建立在Windows 消息机制基础上，稳定性和效率都很差，由此诞生了 COM。

DCOM（分布构件对象模型）是 COM技术在分布式环境中的延伸（ COM 仅支持同一台计算机上构件之间的互操作）。 DCOM用网络协议来代替本地进程之间的通信，并针对分布环境提供了一些新的特性，如网络安全性、跨平台调用等。

MTS（ Microsoft 事务服务器）是为满足企业应用而提供的基础设施。MTS可以为分布式企业应用提供服务器端的构件运行和部署环境，它把企业应用系统的客户程序、应用构件和各种资源有机结合起来（而 COM ／ DCOM无法有效地实现）。

第 22|83 页

下一页下一页

上一页上一页


Windows DNA 为了使Windows 真正成为企业应用平台，Microsof 公司

又推出了Windows DNA（分布式互联网应用体系结构）。它是一个完整的、多层的新一代企业应用体系结构，也是一个服务器端的开发平台，它包含以下主要产品：

Windows NT ／ 2000 ：操作系统。 DCOM ：支持分布式构件的核心技术。 MSMQ ：消息队列产品，支持构件间的异步通信。 MTS ：管理构件的应用服务器。 Microsoft Wolfpack ：支持集群服务器的软件。 Microsoft SQL Server ：一种关系型数据库管理系统。 Microsoft IIS ： Web 服务器。 Microsoft Management Console ：部署和管理工具。工具、数据库、操作系统、编程模型和应用服务等。

第 23|83 页

下一页下一页

上一页上一页


COM+ 为了把 COM、 DCOM和MTS统一起来，形成真正适合于企业级应用的构件技术，诞生了 COM+。

COM+是一种中间件技术的规约，其要点是提供建立在操作系统上的、支持分布式企业级应用的“服务”。 COM+与Windows DNA一起，使得用户可以采用Microsof 公司的技术开发服务器端的构件。

COM+的核心是改进的 COM/DCOM和MTS的集成，但是 COM+ 增加了一些非常重要的构件服务，比如负载平衡、驻留内存数据库、事件模型、队列服务等。 COM+ 还支持所谓的申述式编程模型，它允许开发人员以较通用的方式开发构件，而一些细节则留到部署时再确定。

第 24|83 页

下一页下一页

上一页上一页


COM+ 主要特点真正的异步通信。 COM+底层提供了队列构件服务，允许客户和构件进行异步通信。

事件服务。新事件机制利用系统服务简化了事件模型，避免了 COM可连接对象机制的琐碎细节，使事件源和事件接收方实现事件功能更加灵活。

灵活性。动态负载平衡以及驻留内存数据库、对象池等系统服务为 COM+的灵活性提供了技术基础。

可管理和可部署性。 COM+申述式编程模型和构件管理环境支持应用系统在开发完成后的管理和部署。

易于开发。 COM+开发模型比以前的 COM构件开发更为简化。

第 25|83 页

下一页下一页

上一页上一页


COM+ 的基本结构

COM+ 目录

负载平衡

驻留内存数据库

对象池

新的事件模型

构件管理和部署

JIT 激活

MTS

事务支持

资源分发管理

安全模式

易于管理

远程支持 DCOM

分布式构件服务

COM+

COM

基于接口的编程模式

基本的构件服务

第 26|83 页

下一页下一页

上一页上一页


CORBA 技术简介 CORBA（ Common Object Request Broker Architect

ure，公共对象请求代理体系结构）是 OMG 制定的、体系结构最完整、最清晰、跨越平台最多的分布对象模型。通过CORBA接口定义语言 IDL 定义接口，使用不同编程语言、不同编译器实现的构件，可以通过对象请求代理 ORB进行连接，形成一个跨平台的应用。

CORBA一般有两层意思：一是指对象管理组织 OMG提出的分布式对象体系结构标准；另一层意思是按这种体系结构开发的中间件产品。 CORBA作为一种应用级的互联标准得到了广泛的认同和应用。

CORBA是一套规约，而不是一个产品，开发商可以开发不同的产品来实现 CORBA规约。例如， IBM 公司的 ComponentBroker 等。

第 27|83 页

下一页下一页

上一页上一页


OMG

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

第 28|83 页

下一页下一页

上一页上一页


CORBA 的发展 CORBA规约的第一代主要集中在为分布式对象定义一个基础，其核心是 ORB和 IDL。

CORBA 2.0 增加了 ORB互操作性规约，主要是基于 TCP ／ IP的 IIOP 协议（因特网 ORB互联协议）。 1995年。

CORBA 2.1 增加了 COM/CORBA互操作规范。 1997年。 CORBA 2.2 增添了易移植的对象适配器 POA和 IDL到 Jav

a 语言的映射规约。与此同时，对象管理体系结构 OMA中增加了领域接口。 1998年。

CORBA 3.0 增加了 CORBA构件模型 CCM（与 COM+和 EJB 核心概念相似），提供容器（为构件提供运行环境）作为构件的运行环境，而诸如事务处理、安全处理、事件处理等公共服务都是通过公共 API 访问。 2001年。

但是，目前还没有成熟的、完全实现 CORBA 3.0规约的产品。

第 29|83 页

下一页下一页

上一页上一页


CORBA 的主要特征在 CORBA环境下应用系统间的互联是以对象或程序的调用方式进行的，实现系统间实时互操作。原则上，一个系统内部能够完成的操作，在系统之间通过 CORBA都可以实现。

CORBA的 OO的特点还保证了各对象的封装性和内部细节的隐蔽性。这不仅可以简化各种功能的使用，还提高了系统的安全性。

CORBA 比较适合于分层结构的应用集成，这一技术比较适合于互联网应用系统核心业务逻辑的应用程序的集成。此外，由于目前应用服务器大多提供 CORBA接口，这样利用 CORBA技术完成应用程序和平台之间的无缝连接也比较容易。

第 30|83 页

下一页下一页

上一页上一页


OMA 基准模型 CORBA的基准模型是 OMA。该模型描述了分布式对象系统的基本成分，有四个主要层次：• 对象服务是一组系统级的对象，为实现和管理对象提供了基本的功能，包括名字、生存周期服务、事务服务、安全服务等。

• 对象请求代理 ORB是核心，它提供了一种机制，使得对象可以透明地发送请求和接受响应。 ORB与对象服务相结合，确保符合 CORBA基准的应用构件之间有效的通信。

• 公共设施是适用于众多应用领域的通用构件，例如信息管理、系统管理、任务管理和用户界面等。

• 应用对象是专用于特定领域的应用构件， OMG没有为它制定标准。

第 31|83 页

下一页下一页

上一页上一页


接口定义语言 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将客户从对象实现细节中清晰地分离出来，从而更利于软件复用，因此被广泛接受。

第 32|83 页

下一页下一页

上一页上一页


软件复用技术软件复用是指在软件开发过程中重复使用相同或相似软件元素的过程。软件复用是在软件开发中避免重复劳动的解决方案，它使得应用系统的开发不再采用一切从零开始的模式，而是以已有的工作模式为基础，充分利用过去应用系统开发中积累的知识和经验，从而将开发的重点集中于应用的特有构成成分。

为了能够在软件开发过程中重用已有的复用件，必须不断地进行复用件的积累，并将它们组织成复用件库。因此，软件复用不仅要解决如何检索所需的复用件，还要解决如何选取复用件、如何组织复用件库等问题。这类项目通常称为软件复用项目。

软件重用过程可借助于支持软件重用的 CASE工具，其主要任务是：用某种组织结构实现复用件库的存储，提供友好的人机界面，帮助用户浏览、检索和修改复用件库，并且对用户感兴趣的复用件进行解释。

第 33|83 页

下一页下一页

上一页上一页


软件复用方式分类⑴ 依据复用的对象分类；可以分为：

• 产品复用指复用已有的软件构件，通过构件集成得到新系统。产品复用是目前现实的、主流的途径。

• 过程复用指复用已有的软件开发过程，过程复用依赖于软件自动化技术的发展。

⑵ 依据对可复用信息进行复用的方式分类，可分为：• 白盒复用指已有构件并不能完全符合用户要求，需要根据用户需求进行适应性修改后才能使用。

• 黑盒复用指对已有构件不需作任何修改，通过构件组装的方式直接进行复用。这是目前的研究热点，也是将来的发展趋势。

第 34|83 页

下一页下一页

上一页上一页


可复用的复用件Caper Jones 定义了可候选的十种复用件：⑴ 项目计划：计划的基本结构和内容（如， SQA计划）。⑵ 成本估计：有可能复用对某个功能的成本估计。⑶ 体系结构：可能创建一组类属的体系结构模板（例如，事务处理体系结构），并将模板作为可复用的设计框架。

⑷ 需求模型和规约：类和对象的模型和规约是可复用的，用传统软件工程方法开发的分析模型（例如，数据流图）也是可复用的。

⑸ 设计：用传统方法开发的体系结构、数据、接口和过程化设计是复用的候选者，更常见的是，系统和对象设计是可复用的。

⑹ 源代码：验证过的程序构件（用兼容的程序设计语言书写的）。⑺ 用户和技术文档：对特定的不同应用，可复用大部分用户和技术文档。⑻ 用户界面：可能是最广泛被复用的（例如 GUI）。⑼ 数据：包括：内部表、列表和记录结构，以及文件和完整的数据库。⑽ 测试用例：一旦设计或代码构件将被复用，相关的测试用例也可复用。

第 35|83 页

下一页下一页

上一页上一页


建立复用途径的一些建议⑴ 建立内部的软件复用计划。这样一个计划可以帮助组织

控制软件的质量和成本。⑵ 要求将软件复用作为任何技术和管理培训的内容。对 O

O的培训尤其应该如此。⑶ 按照内部的软件复用计划，寻求对软件复用有积极贡献的工具和库。

⑷ 鼓励采用已被证明为可以促进软件复用的方法和工具。⑸ 跟踪并测度软件复用以及软件复用的影响；应客观评价，而不是主观臆测。

⑹ 管理上必须积极地鼓励软件的复用。⑺ 认识除“模块”外，工具、测试数据、设计、计划、环境及其他软件均可复用。

⑻ 最重要的是认识到软件复用不是“平常的业务”，大多数技术和管理人员是不接受软件复用的概念的。

第 36|83 页

下一页下一页

上一页上一页


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

第 37|83 页

下一页下一页

上一页上一页


复用的障碍自负；太多的开发人员认为不是他们亲自编写的程序不可能是好程序；

检索问题。如何从庞大的复用件库中所需要的复用件；

几乎没有相应的复用培训；复用代价昂贵。有人估计，仅使一个构件可复用，就将至少增加 60%的成本；

虽然存在软件复用的 CASE工具或构件，但大多数软件开发者并不使用它们；

经济利益方面。一些开发人员尽力避免编写那些太通用的例程，唯恐使自己失业。

第 38|83 页

下一页下一页

上一页上一页


技术方面的问题采用软件复用可以降低开发成本，但如果其原件存在的某些问题代码，可能会导致其他采用该代码的系统具有相同的问题代码；这种情况称之为继承性缺陷。

因此当原件的问题代码被修改后，往往无法自动更新实用软件中相应的代码；最终导致实用软件中的问题代码依旧存在。这种非但没有降低开发成本，反而增加维护消耗的复用技术显然是失败的。

第 39|83 页

下一页下一页

上一页上一页


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

第 40|83 页

下一页下一页

上一页上一页


C/S 技术客户机 / 服务器系统也称 C/S(Client/Server)系统，它是基于局域网／广域网的系统。

在 C/S中存在着服务器和客户端。为了充分利用客户机的计算能力，计算和事务处理在服务器和客户机之间分配。

服务器承担数据的集中管理、通信和客户管理的任务，因为数据在服务器端，对数据的处理和计算都在服务器端执行。

而人机界面和一些需要实时响应的事件或人机交互的处理等在客户端进行，这些程序都运行在客户端。

C/S系统往往需要数据库服务器。

第 41|83 页

下一页下一页

上一页上一页


C/S 系统体系结构特征计算和处理分布在服务器和客户机之间。

数据管理集中在服务器端。软件驻留在服务器和客户机。

第 42|83 页

下一页下一页

上一页上一页


C/S 应用系统的特征分布数据。出于安全性和负载平衡的考虑，数据库可以分布在多个数据库服务器上。

分布过程。不同的过程（事务处理、数据库连接等）可以在不同服务器上进行。

客户为中心。把需要在客户端执行的程序和定制的程序放在客户端，以使客户快速得到响应。把对数据进行处理的过程放在数据库服务器端，以加快数据处理速度。

异构硬件和软件。在 C/S体系结构中很容易加入多层结构，屏蔽不同的硬件和软件。例如，加入应用服务器可以基于不同的操作系统和计算机主机，同样客户端安装的中间件可以基于不同的客户端系统，例如， Linux，Windows。

第 43|83 页

下一页下一页

上一页上一页


C/S 技术目标集成处理资源。把客户端、服务器端的处理能力充分利用，集成在一起完成系统的功能要求。

降低开发资源要求。在客户端和服务器端运行的程序分别存放，使得程序调试方便，开发比较简单，需要的资源也减少。在传统的数据库应用体系结构中（基于主机 -多终端），数据库是应用程序“私有的”。虽然它也可以将数据文件放置在某台机器上供不同的用户共同访问，但所有的操作、规则，都是在一个包罗万象的应用程序内部实现的。应用程序因此具有最大的复杂性。

降低硬件和软件的要求。在 C/S系统中，客户机既有部分处理能力，价格相对较低，可以降低系统软硬件成本。

降低系统维护成本。因为在服务器端的处理和计算程序只需在服务器端维护，与客户机无关，而客户端程序比较简单，所以系统维护较方便，成本较低。

可扩充能力强。 C/S应用很容易扩充，只要 C/S 联入网络即可。服务器有负载平衡的能力就可以允许不断增加并发客户。

第 44|83 页

下一页下一页

上一页上一页


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

第 45|83 页

下一页下一页

上一页上一页


两层结构 C/S 系统第一层是客户端软件，由应用程序和相应的数据库链接程

序组成，企业的业务过程都在程序中表现。第二层包括数据库服务器，根据客户端软件的请求进行数据库操作，然后将结果传送给客户端软件。

两层应用软件的开发工作主要集中在客户端，客户端软件不但要完成用户界面和数据显示的工作，还要完成一部分对商业和应用逻辑的处理工作。

两层结构的 C/S系统仅能在各自的客户机和数据库服务器之间使用，分割了界面和数据，使得客户机要管理复杂的软件，导致“肥胖”客户机的产生。

两层 C/S系统不能进行有效的扩展，使这些系统不能支持大量用户的访问和高容量事务处理的应用。

第 46|83 页

下一页下一页

上一页上一页


三（多）层结构 C/S 系统客户机上只安装具有用户界面和简单的数据处理功能的应用程序，负责处理与用户的交互和与应用服务器的交互。

而将商业和应用逻辑的处理功能移到中间层——应用服务器上。应用服务器负责处理商业和应用逻辑，接受客户端应用程序的请求，然后根据商业和应用逻辑将这个请求转化为数据库请求后与数据库服务器交互，并将与数据库服务器交互的结果传送给客户端应用程序。

数据库服务器软件根据应用服务器发送的请求进行数据库操作，并将操作的结果传送给应用服务器。

第 47|83 页

下一页下一页

上一页上一页


三层 C/S 结构优点整个系统被分成不同的逻辑块，层次清晰，一层的改动不会影响其他层次；

能够使“肥胖”的客户机变“瘦”；开发和管理工作向服务器端转移，使得分布的数据处理成为可能；

管理和维护变得相对简单。

第 48|83 页

下一页下一页

上一页上一页


C/S 结构的局限性第一， C/S结构的计算能力过于分散，网络中服务器和客户机的数目正发生“细胞”分裂，使得系统的管理费用以几何级数的方式增长。

第二， C/S结构中数据库信息的使用只限于局域网的范围内，无法利用 Internet的网络资源。

第三，在 C/S结构中，无论多小的企业都必须安装自己的服务器，而服务器和服务器软件的管理和维护都是非常复杂的工作，需要专门人员负责，小企业往往无力购买高性能的服务器和聘用专门人员。因此， C/S结构不利于小企业计算机应用的发展。

第 49|83 页

下一页下一页

上一页上一页


应用子系统设计的指导原则⑴ 表示 /交互子系统通常放置在客户端。基于图形界面的应用及程序驻留在客户端，这可快速响应用户的交互请求。尤其是在实现图形图像等复杂应用时，对于需要与本地资源（如调用本地磁盘文件等）进行交互性的操作，更是需要驻留在客户端的程序。这样做还可以降低网络流量。

⑵ 如果需要多个客户共享数据，则数据库及数据库管理系统应该放在服务器端。

⑶ 对 DB进行操作的存储过程放在 DB 服务器上。对数据库进行插入、更新、删除的存储过程或触发器程序最好放在相应的 DB 服务器上，以减少 DB 连接、网络传输的时间消耗，降低 DB 连接过载发生的可能性。

⑷ 用于引用的静态数据应该分配到客户端。把数据存放在需要它的最近地方，不必在网络中传输，减少服务器压力。

第 50|83 页

下一页下一页

上一页上一页


基于 Web 工程设计基础基于 Web技术的 Intranet近年来正受到广泛的关注，这种以 TCP/IP 协议为基础、以Web技术为中心的应用正吸引着越来越多的企业以更快的速度、更低的费用去创建企业的应用系统。

Web技术吸引人的地方是采用超链接和多媒体信息。Web服务器使用 HTML 描述网络的资源，创建网页，并以 HTML数据文件的形式保存，以供Web浏览器阅读。

Web 浏览器是一个用于文档检索和显示的客户应用程序，并通过 HTTP 协议与Web 服务器相连。

目前，流行的 IE和 Netscape Navigator除提供基本的文档检索、显示和导航特性外，还支持 HTML的高级显示（如表和帧）以及 Active X、 Java、 JavaScript 等特性。

第 51|83 页

下一页下一页

上一页上一页


B/S 技术浏览器／服务器系统也称 B/S（ Browser/Server）系统，它也是基于局域网／广域网的系统。它的客户端是标准的浏览器（如 IE 等），服务器端为标准的Web 服务器，可协同应用服务器响应浏览器的请求。

B/S是一种三层结构的系统：第一层客户机是用户与整个系统的接口。客户应用程序就是一个通用的浏览器。

第二层是Web 服务器，它负责启动相应的进程来响应处理请求，并动态生成一串嵌入了处理结果的 HTML代码，并返回给客户端的浏览器。如果客户机提交的请求包括数据的存取，Web 服务器还需与 DB 服务器协同完成这一处理工作。

第三层数据库服务器的任务类似于 C/S模式，负责协调不同的Web 服务器发出的 SQL 请求，管理数据库。

第 52|83 页

下一页下一页

上一页上一页


B/S 系统的特点⑴ B/S系统采用 B/W/D结构。即客户端只安装一个浏览器（ Browser）。中间层是Web 服务器。再根据需要安装小支持库，如 Java 或 VB的 DDL以处理特殊应用。

⑵ B/S结构简化了客户端。客户机上只需安装通用的浏览器软件。节省客户机的硬盘空间与内存 .

⑶ 简化了系的开发和维护。系统的开发者只需把所有的功能都实现在Web 服务器上，并就不同的功能为各个组别的用户设置权限就可以了。相对于 C/S模式， B/S的维护具有更大的灵活性。如果一个公司有上千台客户机，并且分布在不同的地点，那么便于维护将显得更加重要。

⑷ 用户操作更简单。客户端只用浏览器。不用培训即可使用。⑸ B/S适用于网上信息发布，这使得企业的大部分书面文件可以被电子文件取代，从而提高了企业的工作效率，使企业行政手续简化，节省人力、物力。

第 53|83 页

下一页下一页

上一页上一页


B/S 系统设计的框架和特点 B/S系统本质上是一个查询系统，其客户端的输入输出

很简单，所以它的开发比 C/S系统有很大的不同。 B/S系统的开发过程实际上是网站开发过程。包括确定

网站目标、对网站进行规划、估算成本、开发进度，估计风险、建立网站的需求模型及分析需求，之后进入工程阶段。

在工程阶段与 C/S系统有很大差别。 B/S一般是三层结构系统，对每一层都要进行设计。此外由于 B/S是查询系统，因此导航系统设计和界面设计就显得格外重要。

网站开发的主要工作不是编程，而是网页设计 / 制作，大量工作是使用制作工具进行文本、声音、图形和图片等的设计和编辑。

内容设计、网页的制作和网站结构设计是并行的。

第 54|83 页

下一页下一页

上一页上一页


B/S 系统设计要点⑴ 设计目标。首先要确定目标、用户以及内容范围。包括：

• 信息目标：向终端用户提供哪些特定的信息内容？• 应用目标：在网站上完成哪些任务？• 用户目标：网站的用户群，他们的背景、爱好和知识。• 商业目标：网站靠什么赚钱？如何实现商业目标？

⑵ 计划和分析。• 内容分析：标识要处理的信息、它们相互关系及信息的层次结构。• 交互分析：描述交互方式，例如哪些需要用户提交。• 功能分析：给出用户交互界面、定义系统功能等。• 配置分析：要描述网站的基础设施和服务器环境。例如它是 Inter

net 还是 Intranet？是否需要数据库服务器？采用什么Web 服务器？客户端需要配置什么样的浏览器？网站是托管还是租用虚拟服务器等。在硬件方面需要那些设备？是否需要防火墙？

⑶ 工程、发布和用户评价。工程即网站的设计和开发。发布包括本地调试、测试、建立网站，网站试运行。用户评价就是进行用户测试，最后验收，正式发布。

第 55|83 页

下一页下一页

上一页上一页


选择 Web 服务器考虑因素• 与企业现有网络的配合性；• 与数据库服务器的结合性；• 开发Web 页面的难易程度；• 安全性；• 稳定性；• 与企业现有的系统密切配合。如果现有的企业网络系统是Window NT，则可考虑选择 Microsoft IIS ；如果企业的数据库是 Oracle，那么 Oracle WebServer是一个适当的选择。

第 56|83 页

下一页下一页

上一页上一页


B/S 和 C/S 的比较近年来，对于 B/S、 C/S 两种结构软件的优劣，国内基本已经达成共识，普遍认为 B/S结构软件将全面取代 C/S结构软件。

下面从技术特性和商业特性两个方面进行比较。

第 57|83 页

下一页下一页

上一页上一页


技术特性比较1、数据安全性比较。由于 C/S结构的数据分布特性，客户端的数据易攻击。对大型企业的异地软件应用，数据要在多个服务器之间进行数据同步，每个数据点上的数据安全都影响整个应用的数据安全。

对于 B/S结构的软件来讲，由于其数据集中存放在数据库服务器，客户端不保存任何业务数据和数据库连接信息，安全问题好多了。

2、数据一致性比较。在 C/S结构的解决方案中，在异地经营点都采用区域级服务器，进行数据同步操作。由于局部网络故障造成个别数据库不能同步，或即使可同步，各服务器数据也有时差，数据无法一致，不能用于决策。

对于 B/S结构来讲，其数据是集中存放的，客户端发生的每一笔业务单据都直接进入到中央数据库，不存在数据一致性的问题。

3、数据实时性比较。 C/S结构不随时随地看到当前业务的情况，看到的都是事后数据；而 B/S结构可以实时看到当前发生的所有业务，方便了快速决策，有效地避免了企业损失。

第 58|83 页

下一页下一页

上一页上一页


技术特性比较（续）4、数据溯源性比较。由于 B/S结构的数据集中存放，总公司可以直接追溯到各级分支机构的原始业务单据，即结果可溯源。

C/S结构则不同，为了减少数据通信量，仅上传中间报表数据，在总部不可能查到各分支机构的原始单据。

5、服务响应及时性比较。对 C/S结构软件，由于应用是分布的，所以即使非常小的更新都需要很长的重新部署时间，为保证程序版本的一致性，必须暂停一切业务进行更新（“休克更新”）。

而 B/S结构软件，如若更新，仅在总部服务器段操作。6．网络应用限制比较。 C/S结构软件仅适用于局域网内部用户或宽带用户；而 B/S结构软件可以适用于任何网络结构（包括拨号入网方式），特别适于宽带不能到达的地方。

第 59|83 页

下一页下一页

上一页上一页


商业特性比较1．投入成本比较。 B/S结构软件一般只有初期一次性投入成本。而 C/S结构软件则随着应用范围扩大，投资会连绵不绝。2．硬件投资保护比较。当应用扩大，系统负载上升时， C/S结构的解决方案是购买更高级的中央服务器，这是由于 C/S软件的两层结构造成的，这类软件的服务器程序必须部署在一台计算机上；

而 B/S结构则不同。随着服务器负载的增加，可通过增加服务器数并在各服务器之间均衡负载来解决。有效地保护原有硬件投资。

3．企业快速扩张支持上的比较。对于 C/S结构软件来讲，由于必须同时安装服务器和客户端、建设机房、招聘专业管理人员等，所以无法适应企业快速扩张的特点。

而 B/S结构软件，只需一次安装，以后只需设立账号、培训即可。其次，随着软件应用的扩张，对系统维护人才的需求有可能成为企业

快速扩张的制约瓶颈。如果企业开设许多站点，对计算机专业人才的需求就将是企业面临的巨大挑战之一。

第 60|83 页

下一页下一页

上一页上一页


欢迎参加计教中心网站的学习讨论。中心网址：

http ： //ctec.xjtu.edu.cn课件下载地址 :

ftp: //ctec.xjtu.edu.cn我的 E-mail 地址 :

谢谢，再见！

Documents

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

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