【软件工程及项目管理】知识点贯通全讲

【软件工程及项目管理】知识点串讲第1章 软件工程技术发展思索 21.1 软件工程技术发展历程 21.2 软件与软件特征 31.3 软件工程的主要研究内容 31.4 软件技术的发展趋势 7第2章 传统的软件工程过程 82.1 什么是软件生命周期 82.2 软件生命周期的六个阶段 92.3 软件生命周期的模型 10第3章软件工程之面向对象技术概述 12第4章 面向对象软件工程方法学实践 144.1是“设计主导”还是“程序主导” 144.2 面向对象方法与结构化方法比较 174.3 方法学是思路不是定律 18第5章中间件技术 19第6章 JavaEE技术软件工程专题 216.1 企业级Java 216.2 J2EE简介 226.2.1 J2EE的概念 236.2.2 J2EE的四层模型 246.2.3 J2EE的结构 266.3 JavaEE5 286.4 J2EE探险者系列 296.5 J2EE最佳实践 306.6 J2EE与SOA 316.7 J2EE与Web2.0 316.8StrutsVSSpring两种MVC框架比较 33第7章 面向方面编程AOP 357.1 引言 357.2 什么是方面 367.3 AOP：利与弊 377.4 SpringAOP:Spring之面向方面编程 37第8章 基于组件的软件工程-软件开发新挑战 408.1 软件开发面临的挑战 408.2 基于组件的开发中有几个危及其成功的不利因素 408.3 基于组件的软件工程 418.4 组件规范 418.5 基于组件系统开发生命周期 428.6 软件体系和基于组件的开发 438.7 UML和基于组件的系统模型 448.8 CORBA与DCOM技术 448.8.1分布式对象技术 448.8.2CORBA的设计模式 468.8.3DCOM技术 508.8.4CORBA与DCOM的主要异同 538.9 基于组件软件工程的未来 55第9章 软件测试新技术 569.1 正交试验设计 569.2 均匀试验设计 579.3 成对组合覆盖 579.4 软件测试的有效方法—确定软件测试技术 589.6 软件测试自动化框架 61第10软件工程新视角 6310.1 业发展：SOA与云计算相结合 6310.2 AgileSoftwareDevelopment（敏捷软件开发） 6310.3 极限编程 6510.4 可信软件 71第1章 软件工程技术发展思索1.1 软件工程技术发展历程30多年来,软件工程的研究和实践取得了长足的进步,其中一些具有里程碑意义的进展包括:•20世纪60年代末~70年代中期,在一系列高级语言应用的基础上,出现了结构化程序设计技术,并开发了一些支持软件开发的工具.•20世纪70年代中期~80年代,计算机辅助软件工程(CASE)成为研究热点,并开发了一些对软件技术发展具有深远影响的软件工程环境.•20世纪80年代中期~90年代,出现了面向对象语言和方法,并成为主流的软件开发技术;开展软件过程及软件过程改善的研究;注重软件复用和软件构件技术的研究与实践.软件是客观事物的一种反映,客观世界的不断变化促使软件技术的不断发展,这种事物发展规律促使软件工程的产生和发展.我们仅从解决软硬件的异构性和各种软件之间的异构性角度,就可窥见软件技术发展的一种途径.如,为屏蔽计算机硬件之间的异构性发展了操作系统,为屏蔽操作系统之间和编程语言之间的异构性出现了支撑软件和中间件,为屏蔽不同中间件之间的异构性发展了WebServices技术等等;随着解决问题的不断深入,易用性和适应性要求的不断提升,以及软件技术的不断发展,还会出现更新、更复杂的异构问题,它的解决会促进软件技术的不断发展.从学科角度来看,要不断提炼所要解决问题的概念,建立相应的模型,并寻找处理方法,从而解决这些问题的概念模型和处理问题逻辑间的映射问题,如图1所示.1.2 软件与软件特征软件是对客观世界中问题空间与解空间的具体描述,是客观事物的一种反映,是知识的提炼和“固化”.客观世界是不断变化的,因此,构造性和演化性是软件的本质特征.如何使软件模型具有更强的表达能力、更符合人类的思维模式,即如何提升计算环境的抽象层次,在一定意义上来讲,这紧紧围绕了软件的本质特征——构造性和演化性.在高级语言出现以前,汇编语言(机器语言)是编程的工具,表达软件模型的基本概念(或语言构造)是指令,表达模型处理逻辑的主要概念(机制)是顺序和转移.显然,这一抽象层次是比较低的.高级语言的出现,例如FORTRAN语言、PASCAL语言、C语言等,使用了变量、标识符、表达式等概念作为语言的基本构造,并使用3种基本控制结构来表达软件模型的计算逻辑,因此软件开发人员可以在一个更高的抽象层次上进行程序设计.随后出现了一系列开发范型和结构化程序设计技术,实现了模块化的数据抽象和过程抽象,提高了人们表达客观世界的抽象层次,并使开发的软件具有一定的构造性和演化性.近20年来,面向对象程序设计语言的诞生并逐步流行,为人们提供了一种以对象为基本计算单元,以消息传递为基本交互手段来表达的软件模型.面向对象方法的实质是以拟人化的观点来看待客观世界,即客观世界是由一系列对象构成,这些对象之间的交互形成了客观世界中各式各样的系统[1].面向对象方法中的概念和处理逻辑更接近人们解决计算问题的思维模式,使开发的软件具有更好的构造性和演化性.目前,人们更加关注软件复用问题,构建比对象粒度更大、更易于复用的基本单元——构件,并研究以构件复用为基础的软件构造方法,更好地凸现软件的构造性和演化特性.易于复用的软件,一定是具有很好构造性和演化性的软件.1.3 软件工程的主要研究内容从某种角度来说,软件开发的本质就是要实现“高层概念”到“低层概念”的映射,实现“高层处理逻辑”到“低层处理逻辑”的映射.对于大型软件系统的开发,这一映射是相当复杂的,涉及到有关人员、使用的技术、采取的途径以及成本和进度的约束,因此,我们可以把软件工程定义为:软件工程(softwareengineering)是应用计算机科学理论和技术以及工程管理原则和方法,按照预算和进度,实现满足用户要求的软件产品的定义、开发、发布和维护的工程或以之为研究对象的学科,软件工程与其他工程一样要有自己的目标、活动和原则,软件工程框架可以概括为图2所示的内容.软件工程的基本目标是生产具有正确性、可用性及开销合宜(合算性)的产品.正确性意指软件产品达到预期功能的程度;可用性意指软件基本结构、实现及文档达到用户可用的程度;开销合宜意指软件开发、运行的整个开销满足用户的需求.以上目标的实现不论在理论上还是在实践中均存在很多问题有待解决,制约了对过程、过程模型及工程方法的选取.软件工程活动是“生产一个最终满足用户需求且达到工程目标的软件产品所需要的步骤”,主要包括需求、设计、实现、确认以及支持等活动.需求活动是在一个抽象层上建立系统模型的活动,该活动的主要产品是需求规约,是软件开发人员和客户之间契约的基础,是设计的基本输入.设计活动定义实现需求规约所需的结构,该活动的主要产品包括软件体系结构、详细的处理算法等.实现活动是设计规约到代码转换的活动.验证/确认是一项评估活动,贯穿于整个开发过程,包括动态分析和静态分析.主要技术有模型评审、代码“走查”以及程序测试等.维护活动是软件发布之后所进行的修改,包括对发现错误的修正、对环境变化所进行的必要调整等.围绕工程设计、工程支持以及工程管理,提出以下软件工程基本原则:第1条原则是选取适宜的开发风范.以保证软件开发的可持续性,并使最终的软件产品满足客户的要求.第2条原则是采用合适的设计方法.支持模块化、信息隐蔽、局部化、一致性、适应性、构造性、集成组装性等问题的解决和实现,以达到软件工程的目标.第3条原则是提供高质量的工程支持.提供必要的工程支持,例如配置管理、质量保证等工具和环境,以保证按期交付高质量的软件产品.第4条原则是有效的软件工程管理.仅当对软件过程实施有效管理时,才能实现有效的软件工程.由以上软件工程的概念和框架可以看出,软件设计的主要目标就是要实现好的结构,使开发的软件具有良好的构造性和演化性.软件工程学科所研究的内容主要包括:软件开发范型、软件设计方法、工程支持技术和工程管理技术.其中,软件开发范型涉及软件工程的“方向”问题,研究正确的求解软件的计算逻辑;软件设计方法涉及软件工程的“途径”问题,研究“高层概念模型和处理逻辑”到“低层概念模型和处理逻辑”的映射;工程支持技术和过程管理技术涉及工程过程质量和产品质量问题,研究管理学理论在软件工程中的应用.如上所述,软件开发就是实施了一个从“高层概念模型”到“低层概念模型”的映射,从“高层处理逻辑”到“低层处理逻辑”的映射,而且在这一映射中还涉及到人员、技术、成本、进度等要素,那么就必须研究映射模式即软件生产模式问题.分析传统产业的发展,其基本模式均是符合标准的零部件(构件)生产以及基于标准构件的产品生产(组装),其中,构件是核心和基础,“复用”是必须的手段.实践表明,这种模式是软件开发工程化、软件生产工业化的必由之路[4].因此,软件产业的发展并形成规模经济,标准构件的生产和构件的复用是关键因素.实现软件复用的关键因素(技术和非技术因素),如图3所示,主要包括:软件构件技术(softwarecomponenttechnology)、领域工程(domainengineering)、软件构架(softwarearchitecture)、软件再工程(softwarereengineering)、开放系统(opensystem)、软件过程(softwareprocess)、CASE技术等,以及各种非技术因素,且各种因素是相互联系、相互影响的.近年来人们认识到,要提高软件开发效率,提高软件产品质量,必须改变手工作坊式的开发方法,采取工程化的开发方法和工业化的生产技术.青鸟工程“七五”期间,已提出了软件生产线的概念和思想[6],其中将软件的生产过程分成3类不同的生产车间,即应用构架生产车间、构件生产车间和基于构件、构架复用的应用集成组装车间.软件生产线的概念模式如图4所示.由上述软件生产线概念模式图中可以看出,在软件生产线中,软件开发人员被划分为3类:构件生产者、构件库管理者和构件复用者.这3种角色所需完成的任务是不同的,构件复用者负责进行基于构件的软件开发,包括构件查询、构件理解、适应性修改、构件组装以及系统演化等.图5给出了与上述概念图相对应的软件生产线——生产过程模型.从图4和图5中可以看出,软件生产线以软件构件/构架技术为核心,其中的主要活动体现在传统的领域工程和应用工程中,但赋予了它们新的内容,并且通过构件管理、再工程等环节将它们有机地衔接起来.另外,软件生产线中的每个活动皆有相应的方法和工具与之对应,并结合项目管理、组织管理等管理问题,形成完整的软件生产流程.1.4 软件技术的发展趋势Internet无疑是20世纪末伟大的技术进展之一,为我们提供了一种全球范围的信息基础设施.这个不断延伸的网络基础设施,形成了一个资源丰富的计算平台,构成了人类社会的信息化、数字化基础,成为我们学习、生活和工作的必备环境.如何在未来Internet平台上进一步进行资源整合,形成巨型的、高效的、可信的和统一的虚拟环境,使所有资源能够高效、可信地为所有用户服务,成为软件技术的研究热点.Internet平台具有如下基本特征:无统一控制的“真”分布性;节点的高度自治性;节点链接的开放性和动态性;人、设备和软件的多重异构性;实体行为的不可预测性;运行环境的潜在不安全性;使用方式的个性化和灵活性;网络连接环境的多样性等.因此,Internet平台和环境的出现,对软件形态、技术发展、理论研究提出新的问题,也提供了新的契机.传统软件的开发基于封闭的静态平台,是自顶向下、逐步分解的过程,因此传统软件的开发,基本都是首先确定系统的范围(即Scoping),然后实施分而治之的策略,整个开发过程处于有序控制之下.而未来软件系统的开发所基于的平台是一个有丰富基础软件资源但同时又是开放、动态和多变的框架,开发活动呈现为通过基础软件资源组合为基本系统,然后经历由“无序”到“有序”的往复循环过程,是动态目标渐趋稳态.未来软件基本模型由于所处平台的特性和开放应用的需求而变得比任何传统的计算模型都更为复杂,软件生命周期由于“无序”到“有序”的循环而呈现出不同于传统生命周期概念的“大生命周期概念”,程序正确性由于目标的多样化而表现为传统正确性描述的一个偏序集,软件体系结构侧重点从基于实体的结构分解转变为基于协同的实体聚合,软件生产过程和环境的变化导致基于Internet的面向用户的虚拟工厂的形成.由于软件系统所基于的计算机硬件平台正经历从集中封闭的计算平台向开放的Internet平台的转变,软件系统作为计算机系统的核心,随着其运行环境的演变也经历了一系列的变革.目前,面向网络的计算环境正由Client/Server发展为Client/Cluster,并正朝着Client/Network和Client/VirtualEnvironment的方向发展.那么,未来的基于Internet平台的软件系统又将会呈现出一个什么形态呢?从技术的角度来看,以软件构件等技术支持的软件实体将以开放、自主的方式存在于Internet的各个节点之上,任何一个软件实体可在开放的环境下通过某种方式加以发布,并以各种协同方式与其他软件实体进行跨网络的互连、互通、协作和联盟,从而形成一种与当前的信息Web类似的SoftwareWeb.SoftwareWeb不再仅仅是信息的提供者,它还是各种服务(功能)的提供者.由于网络环境的开放与动态性,以及用户使用方式的个性化要求,从而决定了这样一种SoftwareWeb,它应能感知外部网络环境的动态变化,并随着这种变化按照功能指标、性能指标和可信性指标等进行静态的调整和动态的演化,以使系统具有尽可能高的用户信赖度.我们将具有这种新形态的软件称为网构软件(internetware).网构软件是在Internet开放、动态和多变环境下软件系统基本形形态的独有的基本特征[1]:(1)自主性:是指网构软件系统中的软件实体具有相对独立性、主动性和自适应性.自主性使其区别于传统软件系统中软件实体的依赖性和被动性;(2)协同性:是指网构软件系统中软件实体之间可按多种静态连接和动态合作方式在开放的网络环境下加以互连、互通、协作和联盟.协同性使其区别于传统软件系统在封闭集中环境下单一静态的连接模式;(3)反应性:是指网构软件具有感知外部运行和使用环境并对系统演化提供有用信息的能力.反应性使网构软件系统具备了适应Internet开放、动态和多变环境的感知能力;(4)演化性:是指网构软件结构可以根据应用需求和网络环境变化而发生动态演化,主要表现在其实体元素数目的可变性、结构关系的可调节性和结构形态的动态可配置性上;演化性使网构软件系统具备了适应Internet开放、动态和多变环境的应变能力;(5)多态性:是指网构软件系统的效果体现出相容的多目标性.它可以根据某些基本协同原则,在动态变化的网络环境下,满足多种相容的目标形态.多态性使网构软件系统在网络环境下具备了一定的柔性和满足个性化需求的能力.综上所述,Internet及其上应用的快速发展与普及,使计算机软件所面临的环境开始从静态封闭逐步走向开放、动态和多变.软件系统为了适应这样一种发展趋势,将会逐步呈现出柔性、多目标、连续反应式的网构软件系统的形态.面对这种新型的软件形态,传统的软件理论、方法、技术和平台面临了一系列挑战.从宏观上看,这种挑战为我们研究软件理论、方法和技术提供了难得的机遇,使我们有可能建立一套适合于Internet开放、动态和多变环境的新型软件理论、方法和技术体系.从微观的角度来看,Internet的发展将使系统软件和支撑平台的研究重点开始从操作系统等转向新型中间件平台,而网构软件的理论、方法和技术的突破必将导致在建立新型中间件平台创新技术方面的突破.归结起来,网构软件理论、方法、技术和平台的主要突破点在于实现如下转变,即,从传统软件结构到网构软件结构的转变,从系统目标的确定性到多重不确定性的转变,从实体单元的被动性到主动自主性的转变,从协同方式的单一性到灵活多变性的转变,从系统演化的静态性到系统演化的动态性的转变,从基于实体的结构分解到基于协同的实体聚合的转变,从经验驱动的软件手工开发模式到知识驱动的软件自动生成模式的转变.建立这样一种新型的理论、方法、技术和平台体系具有两个方面的重要性,一方面,从计算机软件技术发展的角度,这种新型的理论、方法和技术将成为面向Internet计算环境的一套先进的软件工程方法学体系,为21世纪计算机软件的发展构造理论基础;另一方面,这种基于Internet计算环境上软件的核心理论、方法和技术,必将为我国在未来5~10年建立面向Internet的软件产业打下坚实的基础,为我国软件产业的跨越式发展提供核心技术的支持.当前的软件技术发展遵循软硬结合、应用与系统结合的发展规律.“软”是指件,“硬”是指微电子,要发展面向应用,实现一体化;面向个人,体现个性化的系统和产品.软件技术的总体发展趋势可归结为:软件平台网络化、方法对象化、系统构件化、产品家族化、开发工程化、过程规范化、生产规模化、竞争国际化.第2章 传统的软件工程过程2.1 什么是软件生命周期软件生命周期又称为软件生存周期或系统开发生命周期，是软件的产生直到报废的生命周期，周期内有问题定义、可行性分析、总体描述、系统设计、编码、调试和测试、验收与运行、维护升级到废弃等阶段，这种按时间分程的思想方法是\o"软件工程"软件工程中的一种思想原则，即按部就班、逐步推进，每个阶段都要有定义、工作、审查、形成文档以供交流或备查，以提高软件的质量。但随着新的面向对象的设计方法和技术的成熟，软件生命周期设计方法的指导意义正在逐步减少。生命周期的每一个周期都有确定的任务，并产生一定规格的文档（资料），提交给下一个周期作为继续工作的依据。按照软件的生命周期，软件的开发不再只单单强调“编码”，而是概括了软件开发的全过程。软件工程要求每一周期工作的开始只能必须是建立在前一个周期结果“正确”前提上的延续；因此，每一周期都是按“活动──结果──审核──再活动──直至结果正确”循环往复进展的。2.2 软件生命周期的六个阶段1、问题的定义及规划此阶段是软件开发方与需求方共同讨论，主要确定软件的开发目标及其可行性。2、需求分析在确定软件开发可行的情况下，对软件需要实现的各个功能进行详细分析。需求分析阶段是一个很重要的阶段，这一阶段做得好，将为整个软件开发\o"项目"项目的成功打下良好的基础。"唯一不变的是变化本身。"，同样需求也是在整个软件开发过程中不断变化和深入的，因此我们必须制定需求变更计划来应付这种变化，以保护整个项目的顺利进行。\o"软件生命周期之需求分析"3、软件设计此阶段主要根据需求分析的结果，对整个软件系统进行设计，如系统框架设计，数据库设计等等。软件设计一般分为总体设计和详细设计。好的软件设计将为软件程序编写打下良好的基础。4、程序编码此阶段是将软件设计的结果转换成计算机可运行的程序代码。在程序编码中必须要制定统一，符合标准的编写规范。以保证程序的可读性，易维护性，提高程序的运行效率。5、软件测试在软件设计完成后要经过严密的测试，以发现软件在整个设计过程中存在的问题并加以纠正。整个测试过程分单元测试、组装测试以及系统测试三个阶段进行。测试的方法主要有白盒测试和黑盒测试两种。在测试过程中需要建立详细的测试计划并严格按照测试计划进行测试，以减少测试的随意性。6、运行维护软件维护是软件生命周期中持续时间最长的阶段。在软件开发完成并投入使用后，由于多方面的原因，软件不能继续适应用户的要求。要延续软件的使用寿命，就必须对软件进行维护。软件的维护包括纠错性维护和改进性维护两个方面。2.3 软件生命周期的模型任何软件都是从最模糊的概念开始的：为某个公司设计办公的流程处理；设计一种商务信函打印系统并投放市场。这个概念是不清晰的，但却是最高层的业务需求的原型。这个概念都会伴随着一个目的，例如在一个“银行\o"押汇"押汇系统”的目的是提高工作的效率。这个目的将会成为系统的核心思想，系统成败的评判标准。1999年政府部门上了大量的OA系统（办公自动化系统），学过一点LotusNotes（LotusNotes是功能强大的多界面的Windows软件，它使人们能高效地协同工作。使用Notes人们可以突破平台技术组织和地理的限制，LotusNotes非常好用，通常要由许多应用程序来完成的任务，用Notes一次即可完成。）的人都发了财（\o"IBM"IBM更不用说了），但是更普遍的情况是，许多的政府部门原有的处理模式并没有变化，反而又加上了自动化处理的一套流程。提高工作效率的初衷却导致了完全不同的结果。这样的软件究竟是不是成功的呢？从概念提出的那一刻开始，软件产品就进入了软件生命周期。在经历需求、分析、设计、实现、部署后，软件将被使用并进入维护阶段，直到最后由于缺少维护费用而逐渐消亡。这样的一个过程，称为“生命周期模型”（LifeCycleModel）。典型的几种生命周期模型包括\o"瀑布模型"瀑布模型、\o"快速原型模型"快速原型模型、\o"迭代模型"迭代模型。瀑布模型（WaterfallModel）首先由\o"温斯顿·罗伊斯"温斯顿·罗伊斯（WinstonRoyce）提出。该模型由于酷似瀑布闻名。在该模型中，首先确定需求，并接受客户和软件质量保证（SQA）小组的验证。然后拟定规格说明，同样通过验证后，进入计划阶段…可以看出，瀑布模型中至关重要的一点是只有当一个阶段的文档已经编制好并获得软件质量保证小组的认可才可以进入下一个阶段。这样，瀑布模型通过强制性的要求提供规约文档来确保每个阶段都能很好的完成任务。但是实际上往往难以办到，因为整个的模型几乎都是以文档驱动的，这对于非专业的用户来说是难以阅读和理解的。想象一下，你去买衣服的时候，售货员给你出示的是一本厚厚的服装规格说明，你会有什么样的感触。虽然瀑布模型有很多很好的思想可以借鉴，但是在过程能力上有天生的缺陷。迭代式模型是\o"RUP"RUP（RationalUnifiedProcess，统一软件开发过程，统一软件过程)推荐的周期模型。在RUP中，迭代被定义为：迭代包括产生产品发布（稳定、可执行的产品版本）的全部开发活动和要使用该发布必需的所有其他外围元素。所以，在某种程度上，开发迭代是一次完整地经过所有工作流程的过程：（至少包括）需求工作流程、分析设计工作流程、实施工作流程和测试工作流程。实质上，它类似小型的瀑布式项目。RUP认为，所有的阶段（需求及其它）都可以细分为迭代。每一次的迭代都会产生一个可以发布的产品，这个产品是最终产品的一个子集。迭代的思想如下图所示。迭代和瀑布的最大的差别就在于风险的暴露时间上。“任何项目都会涉及到一定的风险。如果能在生命周期中尽早确保避免了风险，那么您的计划自然会更趋精确。有许多风险直到已准备集成系统时才被发现。不管开发团队经验如何，都绝不可能预知所有的风险。”（RUP）二者的区别如下图所示：由于瀑布模型的特点（文档是主体），很多的问题在最后才会暴露出来，为了解决这些问题的风险是巨大的。“在迭代式生命周期中，您需要根据主要风险列表选择要在迭代中开发的新的增量内容。每次迭代完成时都会生成一个经过测试的可执行文件，这样就可以核实是否已经降低了目标风险。”快速原型（RapidPrototype）模型在功能上等价于产品的一个子集。注意，这里说的是功能上。瀑布模型的缺点就在于不够直观，快速原型法就解决了这个问题。一般来说，根据客户的需要在很短的时间内解决用户最迫切需要，完成一个可以演示的产品。这个产品只是实现部分的功能（最重要的）。它最重要的目的是为了确定用户的真正需求。在我的经验中，这种方法非常的有效，原先对计算机没有丝毫概念的用户在你的原型面前往往口若悬河，有些观点让你都觉得非常的吃惊。在得到用户的需求之后，原型将被抛弃。因为原型开发的速度很快，设计方面是几乎没有考虑的，如果保留原型的话，在随后的开发中会为此付出极大的代价。至于保留原型方面，也是有一种叫做\o"增量模型"增量模型是这么做的，但这种模型并不为大家所接受。事实上，其实现在的软件组织中很少说标准的采用那一种模型的。模型和实用还是有很大的区别。软件生命周期模型的发展实际上是体现了软件工程理论的发展。在最早的时候，软件的生命周期处于无序、混乱的情况。一些人为了能够控制软件的开发过程，就把软件开发严格的区分为多个不同的阶段，并在阶段间加上严格的审查。这就是瀑布模型产生的起因。瀑布模型体现了人们对软件过程的一个希望：严格控制、确保质量。可惜的是，现实往往是残酷的。瀑布模型根本达不到这个过高的要求，因为软件的过程往往难于预测。反而导致了其它的负面影响，例如大量的文档、繁琐的审批。因此人们就开始尝试着用其它的方法来改进或替代瀑布方法。例如把过程细分来增加过程的可预测性。第3章软件工程之面向对象技术概述八十年代末以来，随着面向对象技术成为研究的热点出现了几十种支持软件开

发的面向对象方法。其中，Booch,

Coad/Yourdon,OMT和Jacobson的方法在面向对象软件开发界得到了广泛的认可，特别值得一提的是统一建模语言UML

（Unified

Modeling

Language），该方法结合了Booch,

OMT,

和Jacobson方法

的优点，统一了符号体系，并从其它的方法和工程实践中吸收了许多经过实际检验

的概念和技术。UML方法自去年提出后到现在已发展到1.1版，并已提交给对象管

理集团OMG，申请成为面向对象方法的标准。面向对象方法都支持三种基本的活动：识别对象和类，描述对象和类之间的关

系，以及通过描述每个类的功能定义对象的行为。为了发现对象和类，开发人员要在系统需求和系统分析的文档中查找名词和名

词短语，包括可感知的事物（汽车、压力、传感器）；角色（母亲、教师、政治

家）；事件（着陆、中断、请求）；互相作用（借贷、开会、交叉）；人员；场所；组织；设备；和地点。通过浏览使用系统的脚本发现重要的对象和其责任，是

面向对象分析和设计过程的初期重要的技术。

当重要的对象被发现后，通过一组互相关联的模型详细表示类之间的关系和对

象的行为，这些模型从四个不同的侧面表示了软件的体系结构：静态逻辑、动态逻

辑、静态物理和动态物理。

静态逻辑模型描述实例化（类成员关系）、关联、聚集（整体/部分）、和一

般化（继承）等关系。这被称为对象模型。一般化关系表示属性和方法的继承关

系。定义对象模型的图形符号体系通常是从用于数据建模的实体关系图导出的。对设计十分重要的约束，如基数（一对一、一对多、多对多），也在对象模型中表

示。动态逻辑模型描述对象之间的互相作用。互相作用通过一组协同的对象，对象

之间消息的有序的序列，参与对象的可见性定义，来定义系统运行时的行为。Booch方法中的对象交互作用图被用来描述重要的互相作用，显示参与的对象和对

象之间按时间排序的消息。可见性图用来描述互相作用中对象的可见性。对象的可

见性定义了一个对象如何处于向它发送消息的方法的作用域之中。例如，它可以是

方法的参数、局部变量、新的对象、或当前执行方法的对象的部分。

静态物理模型通过模块描述代码的布局。动态物理模型描述软件的进程和线程

体系结构。

八十年代末以来，随着面向对象技术成为研究的热点出现了几十种支持软件开

发的面向对象方法。其中，Booch,

Coad/Yourdon,

OMT,

和Jacobson的方法在面

向对象软件开发界得到了广泛的认可。特别值得一提的是统一的建模语言UML

（Unified

Modeling

Language），该方法结合了Booch,

OMT,

和Jacobson方法

的优点，统一了符号体系，并从其它的方法和工程实践中吸收了许多经过实际检验

的概念和技术。UML方法自去年提出后到现在已发展到1.1版，并已提交给对象管

理集团OMG，申请成为面向对象方法的标准。面向对象方法都支持三种基本的活动：识别对象和类，描述对象和类之间的关

系，以及通过描述每个类的功能定义对象的行为。

为了发现对象和类，开发人员要在系统需求和系统分析的文档中查找名词和名

词短语，包括可感知的事物（汽车、压力、传感器）；角色（母亲、教师、政治

家）；事件（着陆、中断、请求）；互相作用（借贷、开会、交叉）；人员；场

所；组织；设备；和地点。通过浏览使用系统的脚本发现重要的对象和其责任，是

面向对象分析和设计过程的初期重要的技术。

当重要的对象被发现后，通过一组互相关联的模型详细表示类之间的关系和对

象的行为，这些模型从四个不同的侧面表示了软件的体系结构：静态逻辑、动态逻

辑、静态物理和动态物理。

静态逻辑模型描述实例化（类成员关系）、关联、聚集（整体/部分）、和一

般化（继承）等关系。这被称为对象模型。一般化关系表示属性和方法的继承关

系。定义对象模型的图形符号体系通常是从用于数据建模的实体关系图导出的。对

计十分重要的约束，如基数（一对一、一对多、多对多），也在对象模型中表

示。

动态逻辑模型描述对象之间的互相作用。互相作用通过一组协同的对象，对象

之间消息的有序的序列，参与对象的可见性定义，来定义系统运行时的行为。

Booch方法中的对象交互作用图被用来描述重要的互相作用，显示参与的对象和对象之间按时间排序的消息。可见性图用来描述互相作用中对象的可见性。对象的可

见性定义了一个对象如何处于向它发送消息的方法的作用域之中。例如，它可以是

方法的参数、局部变量、新的对象、或当前执行方法的对象的部分。

静态物理模型通过模块描述代码的布局。动态物理模型描述软件的进程和线程体系结构。第4章 面向对象软件工程方法学实践两位研究面向对象软件工程的美国学者(StaveHalladay和MichaelWiebel)曾这样说：“一般的面向对象编程(OOP)思路不过是一批乌合之众，把灵机一动、随机应变的技巧用于他们绞尽脑汁抽象出来的‘对象’而已。即使是最优秀的OOP程序员，他们所能对付的极限也莫过于中等规模的开发项目。倘若程序员经验不足，系统规模又很大，那么采用OOP只能把你引入漫无边际的泥沼之中。”

一方面是几乎没有一位软件工程学者认为OOP是完美无缺的，另一方面是OOP势如破竹，近乎每一种最新推出的程序开发工具或语言都采用了OOP思路;一方面是越来越多的“乌合之众”在毫无章法、随心所欲地处理着“对象”，另一方面是经过近30年的积累已经拥有了最大多数用户的结构化软件方法的日渐萎缩……面对这一现实，研究软件工程方法学的专家们纷纷指出：“当前摆在软件开发方法学面前的一个重要课题是：从理论上理解OOP具有强大生命力的天然合理性，并完善面向对象软件工程方法学体系。”一年来我们通过国内外一些实用系统的开发实践，对面向对象的软件工程方法进行了较为深入的学习和探讨，特别是在北京市公路局计算机系统的一期工程实践中，借鉴国外软件设计经验，较系统地采用了面向对象软件工程方法，受益匪浅。4.1是“设计主导”还是“程序主导”在一个系统开发过程中是只采用OOP还是采用了OOSE(面向对象软件工程)方法，关键看整个开发过程是“设计主导”还是“程序主导”。近年来，大量先进程序开发工具进入我国，这对提高软件开发效率无疑具有很大的作用。然而，它们又往往使程序主导型软件开发人员在“以程序代系统”、“以算法代设计”的误区里越陷越深。一般的软件开发人员(包括那些只见程序不见系统的程序员)主观上都认为：软件开发不应“系统设计主导”而应“程序算法主导”。但是用下面几个问题考察一下，结果往往相反。问题1在进行软件设计和选择软件开发工具之前，是否进行开发方法学的选择?所谓方法学是指组织软件生产过程的一系列方法、技术和规范。方法学是软件开发者长年失败和成功经验的理论性总结，从软件重用的思路来说，方法学重用的价值远非某些程序组件重用可比。以北京市公路局系统为例。首先，在系统调查阶段我们了解到：这个系统要分期(递增式)开发。由于处于机构改革时期，系统生存期内的用户需求和系统结构变因很多。这表明目标系统应该具有较强的可维护性，即每期开发成果应在后续工程中具有较高的可重用率。其次，一期工程的工作量相当大(最后成果包括124个模块、72类报表、119个数据库表、439个窗口、912个数据窗口)，而开发者对公路局业务不了解，多为经验不足的大学生，理解需求的能力较低。这表明采用的开发方法学必须能最大限度地减少重复劳动，实现开发过程中的成果共享和重用;必须能支持消除需求理解误差的调整工序，使下游成品阶段的设计变更比较容易进行。在开发此系统之前，我们承接了一个国外软件的下游开发任务。由于它采用了面向对象的软件设计，使我们深刻认识到国内外软件开发方法学和技术上的差距，颇受启发。参照我们承接的国外软件开发工作量计算方法，即仅下游120个模块(含报表)的编码和测试为41人月，那么公路局系统从上游设计开始近200个模块和报表、100多个数据库表的开发工作量至少也应在120人月以上。由于采用了面向对象的软件工程方法，尽管开发人员大多经验不足，但是第一期工程总工时最终仍控制在80人月以内，降低成本1/3左右。同时在系统可维护性、重用度及其他功能和性能指标上，均超过了我们以往采用结构化方法开发的系统。对停留在程序主导级开发的软件开发人员来说，他们选择OOP的原因也往往是被动的。其实，在程序主导开发者的辞典中是找不到“方法学”这一词的，或者把“方法学”与“程序算法”混为一谈。至于把OOP看成是OOSE的全部就更不足为怪了。问题2对象抽象的出发点是现实世界的问题描述，还是可执行的实例对象?在现实世界早期抽象阶段，面向对象方法与其他方法区别并不大，都要从现实世界的问题描述出发，即从用户接口、问题领域的知识和经验出发，构筑现实世界的问题模型，也就是确定目标系统是“做什么的”。面向对象的问题分析模型从3个侧面进行描述，即对象模型(对象的静态结构)、动态模型(对象相互作用的顺序)和功能模型(数据变换及功能依存关系)。软件工程的抽象原则、层次原则和分割原则同样适用于面向对象方法，即对象抽象与功能抽象原则是一样的，也是从高级到低级、从逻辑到物理，逐级细分。每一级抽象都重复对象建模(对象识别)→动态建模(事件识别)→功能建模(操作识别)的过程，直到每一个对象实例在物理(程序编码)上全部实现。对象抽象是从逻辑级还是物理级出发，与开发前是否进行方法学选择一样，也是区分OOSE与OOP的试金石。由于许多工具或语言(如PB、C++、Motif)都支持OOP，使一些程序级系统开发人员可以很方便地不经过逻辑抽象就直接开发物理对象，在早期阶段意识不到从物理层即实例对象出发进行系统开发的祸患，孰不知正是这种随心所欲的OOP不仅无法发挥面向对象方法应有的优越性，而且还会给开发后期带来大量返工作业。和以往采用结构化方法一样，我们在系统设计阶段也引入了原型化方法，以便用系统样品即原型与用户对话，求得对需求理解的勾通，避免或减少后期返工。大多OOP工具都为开发原型提供便利，问题在于原型与最终产品间的关系，即原型是逻辑对象还是物理对象的样品。若是后者，那就等同于最终产品。在木已成舟时再让用户评审，若发现问题，要么推倒重来，要么强迫用户削足适履。事实上，我们为设计评审而基于逻辑对象开发的原型，相当部分被用户否决。但由于尚未进行对象实例即物理级开发，而是使用超类对象原型统一模拟对象事件和操作，所以无论是对象模型、动态模型还是功能模型，修改起来都不困难。问题3设计阶段是否先设计超类，是否在实例对象设计开始之前完成超类对象的实现?面向对象方法开发出的软件具有较强的可重用性，这种重用包括开发项目内部的重用和外部的重用。重用依存于超类设计，没有超类的对象系统好比“把洗衣机当米缸”，不能物尽其用。超类设计的好与不好，首先看其内部重用率的高低，内部重用率高，必然外部重用率也高。由于系统开发工期紧、工作量大，而我们的开发队伍年轻，经验和人力都不足，内部重用率高的超类开发无疑是我们的救星。它可以减少重复劳动,易于统一规格,对复杂问题统一攻关、统一解决,便于统一维护。对超类的抽象即实例对象的泛化原则，我们是从下面几个方面考虑的：(1)寻找大多数实例对象的共同行为。例如“打印报表”、“查询静态代码表”、“录入数据库表数据”等。(2)超类的多态性设计要保证使用超类继承关系可以满足各子类的操作要求。例如，继承同一个“数据录入”祖先窗口，可以完成不同结构数据库表的数据录入。(3)利于信息的隐蔽性，不会破坏数据的完整性，利于将复杂问题简单化。例如，对具有复杂关系、结构及相关存取操作的数据库表集的维护。如果不使用一个泛化类将数据结构及其相关操作封装起来，下层程序员要想操作有关库表就必须对库表设计有深入的了解，并且确保程序算法设计不得破坏数据的相关一致性，这将大大增加程序设计和测试的难度，要求程序员有较丰富的经验。而采用这种泛化类(公用函数、公用存储过程)后，程序员所要做的只是发“消息”和取“输出信息”了。(4)有利于推行开发规范，统一界面风格。我们在开发国外软件中受到的最大磨练是：国外对用户界面(报表、屏幕)一丝不荀的严格要求。所有屏幕按钮的高、宽、起始位置都用精确到小数点后3位的X、Y座标进行规定。这样出来的产品使人看上去就有赏心悦目之感。但是如果人人都做界面窗口、按钮的精细调整，工作量势必成倍增长。采用屏幕界面模版超类的继承关系，结合特化处理，问题便可迎刃而解。显然，超类的设计和实现必须在程序员普遍进行实例对象开发之前完成。也就是说，OOSE的上游系统设计人员必须文武(设计与编程)双全，能够担负起超类对象的程序实现与测试任务，这与结构化方法的上层系统设计人员基本可以不编程有所不同。同时，超类对象在下游开发过程中必须经常吸收特化过程中的反馈(包括来自用户的反馈)，进行相应的调整修改。所以OOSE担任超类对象设计与实现的设计人员很难像结构化方法那样进入编程阶段后就可以稍事轻松，他们往往始终离不开编程现场。如果设计阶段不预先设计和开发出超类对象，在同一项目的多数开发者之间没有可以共同继承的祖先对象，甚至在各个开发人员自己的作用范围内都不使用继承关系，那么这不仅不是OOSE，就连称之为OOP都很勉强。问题4 如何处理对象模型面向对象关系数据库模式的映射?面向对象的数据库设计方法可以用于各种数据库，如层次型、网络型、关系型，当然也包括面向对象型。OOSE中的数据库设计无疑必须采用面向对象的数据库设计方法。数据库设计也称数据库模式，基本上由3个层次的模式构成：从特定DB应用角度来看待DB设计的外部模式;从组织或企业角度出发进行的DB设计即概念模式;处理对应特定DBMS特征与局限性的DB设计即内部模式。具体而言，内部模式是数据库的SQL定义，逻辑模式是表集合的逻辑定义，外部模式是从特定应用角度看的局部DB。外部模式与逻辑模式之间的接口是视图、存储过程或其他驻在服务器端的DB处理程序。如果在抽象出的对象模型中，各个应用分别是一个或多个超类对象的子对象，那么，选择适当细分层次的对象模型将其映射到概念模型，是数据库库表对象设计的关键。外部模式与概念模式之间的接口越少、越简单越好，这样的程序设计简单，数据库和程序都易于维护。也就是说，局部化是个重要的设计原则。OOP多是数据库的后端处理，是基于既存数据库的。因此无论是否进行过问题世界的对象建模，以及是否将对象模型合理地映射到数据库逻辑模式(面向对象数据库设计)，OOP都可以工作。问题5编程时是否先调查有无可重用(继承)对象，是否参与下层对象对上层对象、超类对象的反馈?埋头于自己分担的程序对结构化方法或许是必须的，但在面向对象方法中担任程序设计的开发人员，应该先去调查对象数据辞典中有无其他开发人员已经完成、自己稍加特化就可重用的对象。从总体上说，对象的共享、重用应该由上层设计人员统一管理，以便保证对象风格的一致性，避免冲突。但是，对象的独立性、封装性和多态性都很便于重用，这是结构化系统所不能比拟的，而重用是软件开发方法学的最重要思想之一。上层设计人员往往不可能面面俱到，懂得软件设计理论的开发人员，即使只开发下层程序也应采用最省力、最有效率的编程方法，即大量使用重用对象。在继承超类对象和重用他人对象时，若发现有设计不合理的地方，应该及时反映给对象开发的承担者。对上层设计人员来说，一方面应该鼓励程序实现人员重用既存对象，另一方面应通过开发人员共享对象数据辞典，使个别的对象重用能够立即反映到整体对象模型中，以保证设计变更时的一致性。4.2 面向对象方法与结构化方法比较分析是问题抽象(做什么)，设计是问题求解(怎么做)，实现是问题的解(结果)。任何方法学对客观世界的抽象和求解过程都是如此。在问题抽象阶段，结构化方法面向过程，按照数据变换的过程寻找问题的结点，对问题进行分解。因此，与面向对象方法强调的对象模型不同，描述数据变换的功能模型是结构化方法的重点。如果问题世界的功能比数据更复杂或者更重要，那么结构化方法仍然应是首选的方法学。如果数据结构复杂且变换并不多，那么如以过程主导分析和设计，一旦有系统变更就会给下游开发带来极大混乱。由于对过程的理解不同，面向过程的功能细分所分割出的功能模块有时会因人而异。而面向对象的对象细分，从同一问题领域的对象出发，不同人得出相同结论的比率较高。在设计上，结构化方法学产生自顶向下、结构清晰的系统结构。每个模块有可能保持较强的独立性，但它往往与数据库结构相独立，功能模块与数据库逻辑模式间没有映射关系，程序与数据结构很难封装在一起。如果数据结构复杂，模块独立性很难保证。面向对象方法抽象的系统结构往往并不比结构化方法产生的系统结构简单，但它能映射到数据库结构中，很容易实现程序与数据结构的封装。在软件工程基本原则中有一条“形式化原则”，即对问题世界的抽象结论应该以形式化语言(图形语言、伪码语言等)表述出来。结构化方法可以用数据流图、系统结构图、数据辞典、状态转移图、实体关系图来进行系统逻辑模型的描述;而面向对象方法可以使用对象模型图、数据辞典、动态模型图、功能模型图。其中对象模型图近似系统结构图与实体关系图的结合，动态模型图类似状态迁移图，功能模型图类似数据流图。公路局系统有100多个数据库表，但数据的加工(变换)很单纯，如果当初选择结构化方法学，情况会怎么样?在问题抽象的最初阶段不会有太大差异。由于数据变换少，可以把对象和对象的操作看成一一对应，即最初问题描述的对象模型与功能模型基本一致。以其中计划管理处子系统为例，对象是计划管理员、规划管理员、概预算管理员、统计管理员，功能(操作)是计划、规划、概预算、统计。问题存在于下层抽象里。首先，许多公共超类对象设计与结构化方法相悖，因为它破坏了过程的连续性及系统结构的逻辑层次性，把一些下层模块及在过程分析中没有语义的对象，放在系统结构的上层。因此如果采用结构化方法，须将继承关系改为下层模块调用关系。但是事实上，祖先对象的一些状态(属性值)是从主控模块直接得到指示而确定的;从控制角度说，它的确处于系统的上层地位。如果采用结构化方法，结果将是要么把系统结构变成网络状，失去结构化特征，要么放弃这种统一完成重复性劳动的设计方案。其次，应用对象模型向数据库概念模式的映射设计也是该系统采用面向对象方法的一个标志。如果使用结构化方法，数据库模式可能映射客观世界的数据结构。由于公路、养路单位、管理单位、路况、桥梁、隧道及道路上的绿化情况等各实体间客观存在着复杂的多重关系，其结果可能定义出一个像蜘蛛网似的关系库结构，因而大大加重了数据库前端应用编程和数据库维护的负担。总之，该系统若使用结构化方法，系统结构和数据库结构都可能成为网状结构，且互相无关。而目前采用的面向对象方法，系统结构和数据库结构都是多重继承结构，相互存在映射关系。显然前者较后者复杂性高、可维护性差、内部重用难度大、重用率低。其实，无论是用什么方法学开发软件，交给用户的都应该是满足用户当前需求的软件。用户在短期内不会发现开发者使用先进方法学给他们带来的益处，倒是开发者本身由于大大减轻了开发负担而最先受益。但是随着时间的推移，获得最大收益的还是用户，因为软件的长期质量(包括维护成本低和生存周期长)给用户带来的好处才是根本的。4.3 方法学是思路不是定律对于方法学，我们是这样理解的：(1)方法学的目的是：使后人分享前人的成功，避开前人的失败，把注意力集中在尚未开拓领域的创造性劳动上。所以方法学与开发人员的创造性是绝不冲突的。它既不能像法律那样靠权威来界定是非边界，也不能像定律那样通过证明和推理给出普遍结论。如果一定要做比喻的话，它好比人的世界观。(2)没有放之四海而皆准的方法学，任何方法学都有其局限性，所以软件开发人员大可不必拘泥于某种特定的方法学。例如，面向对象方法的对象模型图，这种形式化语言远不如结构化方法的结构图和数据流图简单明了，倘若把公路局系统全部用对象模型图表述出来，至少也要几十页。由于最上层功能模型与对象模型是一致的，所以我们采用的是结构化方法的系统结构图。(3)事实表明，由OOP带动的OOSE方法确实比结构化方法更能自然地抽象现实世界，而且一些OOP工具确实已相当成熟。相反，结构化方法及开放平台下的结构化程序开发工具，虽然不能说止步不前，但其近年来的进步是有限的。(4)根据我们的体会，对实践OOSE有以下一些建议：1最好在选定方法学后，对全体开发人员进行一次关于面向对象方法学的培训。2由于有超类对象的提前开发工作，OOSE的上游设计工作量比结构化方法的上游工作负担重，时间和人力应该更充足一些。否则到下游开发后再追加或多次修改变更超类对象，容易造成混乱和无效劳动。3由于系统越大对象类越多，为了便于内部重用和共享，应该建立电子化的对象数据辞典，以便对对象进行统一归类管理。4应该有严格的命名规则，如果可能，应将命名规则集成到数据辞典中。5下层开发铺开后，如果发现应该对某些实例对象泛化成新的超类对象，必须尽快进行新超类追加的设计，变更越快越好。6子对象继承超类对象后，发现超类设计的缺陷是常有的事。开发队伍内部应有很畅通的反馈渠道，使超类得到及时的修正。子对象切不可轻易将超类对象封杀掉，使系统失去统一控制。遵从系统设计中定义的继承关系进行实例对象开发应该成为全体开发人员的理念。7面向对象设计的好处越到后来越显著，特别是在系统维护和扩充方面。第5章中间件技术一什么是中间件为解决分布异构问题，人们提出了中间件(middleware)的概念。中间件是位于平台(硬件和操作系统)和应用之间的通用服务，如图1所示，这些服务具有标准的程序接口和协议。针对不同的操作系统和硬件平台，它们可以有符合接口和协议规范的多种实现。图1中间件也许很难给中间件一个严格的定义，但中间件应具有如下的一些特点：满足大量应用的需要运行于多种硬件和OS平台支持分布计算，提供跨网络、硬件和OS平台的透明性的应用或服务的交互支持标准的协议支持标准的接口由于标准接口对于可移植性和标准协议对于互操作性的重要性，中间件已成为许多标准化工作的主要部分。对于应用软件开发，中间件远比操作系统和网络服务更为重要，中间件提供的程序接口定义了一个相对稳定的高层应用环境，不管底层的计算机硬件和系统软件怎样更新换代，只要将中间件升级更新，并保持中间件对外的接口定义不变，应用软件几乎不需任何修改，从而保护了企业在应用软件开发和维护中的重大投资。三、主要中间件的分类中间件所包括的范围十分广泛，针对不同的应用需求涌现出多种各具特色的中间件产品。但至今中间件还没有一个比较精确的定义，因此，在不同的角度或不同的层次上，对中间件的分类也会有所不同。由于中间件需要屏蔽分布环境中异构的操作系统和网络协议，它必须能够提供分布环境下的通讯服务，我们将这种通讯服务称之为平台。基于目的和实现机制的不同，我们将平台分为以下主要几类：远程过程调用（RemoteProcedureCall）面向消息的中间件（Message-OrientedMiddleware）对象请求代理（ObjectRequestBrokers）它们可向上提供不同形式的通讯服务，包括同步、排队、订阅发布、广播等等，在这些基本的通讯平台之上，可构筑各种框架，为应用程序提供不同领域内的服务，如事务处理监控器、分布数据访问、对象事务管理器OTM等。平台为上层应用屏蔽了异构平台的差异，而其上的框架又定义了相应领域内的应用的系统结构、标准的服务组件等，用户只需告诉框架所关心的事件，然后提供处理这些事件的代码。当事件发生时，框架则会调用用户的代码。用户代码不用调用框架，用户程序也不必关心框架结构、执行流程、对系统级API的调用等，所有这些由框架负责完成。因此，基于中间件开发的应用具有良好的可扩充性、易管理性、高可用性和可移植性。二分类1、远程过程调用远程过程调用是一种广泛使用的分布式应用程序处理方法。一个应用程序使用RPC来“远程”执行一个位于不同地址空间里的过程，并且从效果上看和执行本地调用相同。事实上，一个RPC应用分为两个部分：server和client。server提供一个或多个远程过程；client向server发出远程调用。server和client可以位于同一台计算机，也可以位于不同的计算机，甚至运行在不同的操作系统之上。它们通过网络进行通讯。相应的stub和运行支持提供数据转换和通讯服务，从而屏蔽不同的操作系统和网络协议。在这里RPC通讯是同步的。采用线程可以进行异步调用。在RPC模型中，client和server只要具备了相应的RPC接口，并且具有RPC运行支持，就可以完成相应的互操作，而不必限制于特定的server。因此，RPC为client/server分布式计算提供了有力的支持。同时，远程过程调用RPC所提供的是基于过程的服务访问，client与server进行直接连接，没有中间机构来处理请求，因此也具有一定的局限性。比如，RPC通常需要一些网络细节以定位server；在client发出请求的同时，要求server必须是活动的等等。2、面向消息的中间件MOM指的是利用高效可靠的消息传递机制进行平台无关的数据交流，并基于数据通信来进行分布式系统的集成。通过提供消息传递和消息排队模型，它可在分布环境下扩展进程间的通信，并支持多通讯协议、语言、应用程序、硬件和软件平台。目前流行的MOM中间件产品有IBM的MQSeries、BEA的MessageQ等。消息传递和排队技术有以下三个主要特点：通讯程序可在不同的时间运行:程序不在网络上直接相互通话，而是间接地将消息放入消息队列，因为程序间没有直接的联系。所以它们不必同时运行。消息放入适当的队列时，目标程序甚至根本不需要正在运行；即使目标程序在运行，也不意味着要立即处理该消息。对应用程序的结构没有约束:在复杂的应用场合中，通讯程序之间不仅可以是一对一的关系，还可以进行一对多和多对一方式，甚至是上述多种方式的组合。多种通讯方式的构造并没有增加应用程序的复杂性。程序与网络复杂性相隔离:程序将消息放入消息队列或从消息队列中取出消息来进行通讯，与此关联的全部活动，比如维护消息队列、维护程序和队列之间的关系、处理网络的重新启动和在网络中移动消息等是MOM的任务，程序不直接与其它程序通话，并且它们不涉及网络通讯的复杂性。3、对象请求代理随着对象技术与分布式计算技术的发展，两者相互结合形成了分布对象计算，并发展为当今软件技术的主流方向。1990年底，对象管理集团OMG首次推出对象管理结构OMA(ObjectManagementArchitecture)，对象请求代理（ObjectRequestBroker）是这个模型的核心组件。它的作用在于提供一个通信框架，透明地在异构的分布计算环境中传递对象请求。CORBA规范包括了ORB的所有标准接口。1991年推出的CORBA1.1定义了接口描述语言OMGIDL和支持Client/Server对象在具体的ORB上进行互操作的API。CORBA2.0规范描述的是不同厂商提供的ORB之间的互操作。对象请求代理(ORB)是对象总线，它在CORBA规范中处于核心地位，定义异构环境下对象透明地发送请求和接收响应的基本机制，是建立对象之间client/server关系的中间件。ORB使得对象可以透明地向其他对象发出请求或接受其他对象的响应，这些对象可以位于本地也可以位于远程机器。ORB拦截请求调用，并负责找到可以实现请求的对象、传送参数、调用相应的方法、返回结果等。client对象并不知道同server对象通讯、激活或存储server对象的机制，也不必知道server对象位于何处、它是用何种语言实现的、使用什么操作系统或其他不属于对象接口的系统成分。值得指出的是client和server角色只是用来协调对象之间的相互作用，根据相应的场合，ORB上的对象可以是client，也可以是server，甚至兼有两者。当对象发出一个请求时，它是处于client角色；当它在接收请求时，它就处于server角色。大部分的对象都是既扮演client角色又扮演server角色。另外由于ORB负责对象请求的传送和server的管理，client和server之间并不直接连接，因此，与RPC所支持的单纯的Client/Server结构相比，ORB可以支持更加复杂的结构。4、事务处理监控事务处理监控（Transactionprocessingmonitors）最早出现在大型机上，为其提供支持大规模事务处理的可靠运行环境。随着分布计算技术的发展，分布应用系统对大规模的事务处理提出了需求，比如商业活动中大量的关键事务处理。事务处理监控界于client和server之间，进行事务管理与协调、负载平衡、失败恢复等，以提高系统的整体性能。它可以被看作是事务处理应用程序的“操作系统”。总体上来说，事务处理监控有以下功能：进程管理，包括启动server进程、为其分配任务、监控其执行并对负载进行平衡。事务管理，即保证在其监控下的事务处理的原子性、一致性、独立性和持久性。通讯管理，为client和server之间提供了多种通讯机制，包括请求响应、会话、排队、订阅发布和广播等。事务处理监控能够为大量的client提供服务，比如飞机定票系统。如果server为每一个client都分配其所需要的资源的话，那server将不堪重负（如图2所示）。但实际上，在同一时刻并不是所有的client都需要请求服务，而一旦某个client请求了服务，它希望得到快速的响应。事务处理监控在操作系统之上提供一组服务，对client请求进行管理并为其分配相应的服务进程，使server在有限的系统资源下能够高效地为大规模的客户提供服务。JavaEE技术软件工程专题JavaEE以前称为J2EE，可以帮助开发和部署可移植、健壮、可伸缩且安全的服务器端Java应用程序。JavaEE是在JavaSE的基础上构建的，它提供Web服务、组件模型、管理和通信API，可以用来实现企业级的面向服务体系结构（SOA）和Web2.0应用程序。本专题汇集大量相关技术资源，帮助您理解这些Java服务器端技术如何独立以及共同工作，这是您成功开发Java企业级应用的关键。6.1 企业级Java企业Java计算模型由四部分组成：标准平台定义（企业JavaAPIs）、工业强度的应用服务器、构件架构和简化编码工作的开发工具。

EnterpriseJavaBeans和EnterpriseJavaBeanAPIsEnterpriseJavaBeans(EJB)使开发者只编写一次构件，然后便可在最适合他们的应用程序和企业需要的服务器环境中使用它们。标准化的EnterpriseJavaBeanAPIs使这成为可能。正如Sun在EnterpriseJavaBeans--Java的服务器构件？中所说明的企业的Java平台由一套标准的应用程序编程接口(API)到一套核心的企业-类基础服务(其中包括生命周期、命名、远程唤醒、消息处理、交易、数据库访问和管理)组成。这些基础访问经常是使用不同的产品和技术在不同的平台上实现的，所以很难创建可移植的企业-类应用程序系统。JavaEnterpriseAPIs提供了一个无需考虑实现方式，为经常服务奠定基石的公共接口。应用程序服务器应用程序服务器为执行由EnterpriseJavaBeans创建的中间件提供了一个平台。这些服务器必须具有高度的可伸缩性以支持多用户。用户端可安全的且同时的访问应用程序。应用程序能够在任何服务器平台上执行。若想了解更多的信息，请参阅IBM的应用程序服务器。构件架构构件是可被用来构造其它应用程序系统的应用程序。在企业内部，重要的部件提供一下的商业服务：交易、安全的数据库访问等等。构件可被方便的导入开发工具中并用来为快速开发基于Java的商业应用程序提供架构。它们被用来设置应用程序并由Web服务器或数据库系统执行。这些构件遵从EnterpriseJavaBeans的规范。若想了解更多的信息，请参阅IBM的构件架构。开发工具企业Java开发工具为创建Java兼容的应用程序、applet、servlets和JavaBean构件提供了一个途径。通过将Java客户端自动连接到现存的服务器数据、交易和应用程序上，客户便可以利用现存的商业应用程序和web上日常的商业运作。6.2 J2EE简介6.2.1 J2EE的概念目前，Java2平台有3个版本，它们是适用于小型设备和智能卡的Java2平台Micro版（Java2PlatformMicroEdition，J2ME）、适用于桌面系统的Java2平台标准版（Java2PlatformStandardEdition，J2SE）、适用于创建服务器应用程序和服务的Java2平台企业版（Java2PlatformEnterpriseEdition，J2EE）。J2EE是一种利用Java2平台来简化企业解决方案的开发、部署和管理相关的复杂问题的体系结构。J2EE技术的基础就是核心Java平台或Java2平台的标准版，J2EE不仅巩固了标准版中的许多优点，例如"编写一次、随处运行"的特性、方便存取数据库的JDBCAPI、CORBA技术以及能够在Internet应用中保护数据的安全模式等等，同时还提供了对EJB（EnterpriseJavaBeans）、JavaServletsAPI、JSP（JavaServerPages）以及XML技术的全面支持。其最终目的就是成为一个能够使企业开发者大幅缩短投放市场时间的体系结构。J2EE体系结构提供中间层集成框架用来满足无需太多费用而又需要高可用性、高可靠性以及可扩展性的应用的需求。通过提供统一的开发平台，J2EE降低了开发多层应用的费用和复杂性，同时提供对现有应用程序集成强有力支持，完全支持EnterpriseJavaBeans，有良好的向导支持打包和部署应用，添加目录支持，增强了安全机制，提高了性能。J2EE的优势J2EE为搭建具有可伸缩性、灵活性、易维护性的商务系统提供了良好的机制:保留现存的IT资产:由于企业必须适应新的商业需求，利用已有的企业信息系统方面的投资，而不是重新制定全盘方案就变得很重要。这样，一个以渐进的（而不是激进的，全盘否定的）方式建立在已有系统之上的服务器端平台机制是公司所需求的。J2EE架构可以充分利用用户原有的投资，如一些公司使用的BEATuxedo、IBMCICS,IBMEncina,、InpriseVisiBroker以及NetscapeApplicationServer。这之所以成为可能是因为J2EE拥有广泛的业界支持和一些重要的'企业计算'领域供应商的参与。每一个供应商都对现有的客户提供了不用废弃已有投资，进入可移植的J2EE领域的升级途径。由于基于J2EE平台的产品几乎能够在任何操作系统和硬件配置上运行，现有的操作系统和硬件也能被保留使用。高效的开发:J2EE允许公司把一些通用的、很繁琐的服务端任务交给中间件供应商去完成。这样开发人员可以集中精力在如何创建商业逻辑上，相应地缩短了开发时间。高级中间件供应商提供以下这些复杂的中间件服务:状态管理服务--让开发人员写更少的代码，不用关心如何管理状态，这样能够更快地完成程序开发。持续性服务--让开发人员不用对数据访问逻辑进行编码就能编写应用程序，能生成更轻巧，与数据库无关的应用程序，这种应用程序更易于开发与维护。分布式共享数据对象CACHE服务--让开发人员编制高性能的系统，极大提高整体部署的伸缩性。支持异构环境:J2EE能够开发部署在异构环境中的可移植程序。基于J2EE的应用程序不依赖任何特定操作系统、中间件、硬件。因此设计合理的基于J2EE的程序只需开发一次就可部署到各种平台。这在典型的异构企业计算环境中是十分关键的。J2EE标准也允许客户订购与J2EE兼容的第三方的现成的组件，把他们部署到异构环境中，节省了由自己制订整个方案所需的费用。可伸缩性:企业必须要选择一种服务器端平台，这种平台应能提供极佳的可伸缩性去满足那些在他们系统上进行商业运作的大批新客户。基于J2EE平台的应用程序可被部署到各种操作系统上。例如可被部署到高端UNIX与大型机系统，这种系统单机可支持64至256个处理器。（这是NT服务器所望尘莫及的）J2EE领域的供应商提供了更为广泛的负载平衡策略。能消除系统中的瓶颈，允许多台服务器集成部署。这种部署可达数千个处理器，实现可高度伸缩的系统，满足未来商业应用的需要。稳定的可用性:一个服务器端平台必须能全天候运转以满足公司客户、合作伙伴的需要。因为INTERNET是全球化的、无处不在的，即使在夜间按计划停机也可能造成严重损失。若是意外停机，那会有灾难性后果。J2EE部署到可靠的操作环境中，他们支持长期的可用性。一些J2EE部署在WINDOWS环境中，客户也可选择健壮性能更好的操作系统如SunSolaris、IBMOS/390。最健壮的操作系统可达到99.999%的可用性或每年只需5分钟停机时间。这是实时性很强商业系统理想的选择。6.2.2 J2EE的四层模型J2EE使用多层的分布式应用模型，应用逻辑按功能划分为组件，各个应用组件根据他们所在的层分布在不同的机器上。事实上，sun设计J2EE的初衷正是为了解决两层模式(client/server)的弊端，在传统模式中，客户端担当了过多的角色而显得臃肿，在这种模式中，第一次部署的时候比较容易，但难于升级或改进，可伸展性也不理想，而且经常基于某种专有的协议�D�D通常是某种数据库协议。它使得重用业务逻辑和界面逻辑非常困难。现在J2EE的多层企业级应用模型将两层化模型中的不同层面切分成许多层。一个多层化应用能够为不同的每种服务提供一个独立的层，以下是J2EE典型的四层结构:运行在客户