知了博客

集天地之精华,吸日月之灵气

« 用HttpClient来模拟浏览器GET POSTapache+tomcat+mysql 负载平衡和集群 »

面向对象技术在软件重用和体系结构中的应用

    面向对象技术提供了一种新的认知和表示世界的思想和方法,它对计算机工业的影响是深远的。计算机从业人士利用它提出了面向对象的计算机程序设计语言、面向对象的软件设计方法、面向对象的数据库等等。同时面向对象技术为软件工业实现工程化提供了强有力的支持,正是面向对象技术造就了组件、构件、中间件等概念。

    1 可重用软件组件

    计算机的不断发展为计算机及网络应用提供了大量技术先进、功能强大的应用软件系统,同时也给软件开发者和用户带来了相应的问题:

    · 软件系统规模庞大,研制周期长,维护费用高;

    · 软件系统过于复杂,在一个系统中集成了各种功能,大多数功能不能灵活地装卸、单独升级或重复利用;

    · 应用软件不易集成,即使各应用程序是用相同的编程语言编写的,并且运行在相同的计算机上,特定应用程序的数据和功能也不能提供给其他应用程序使用。

    为克服上述困难,实现全行业范围内的软件"即插即用",关键是解决软件系统的可操作性、可扩展性、语言独立性和跨平台的操作能力。

    作为解决这类问题的一种方案,面向对象的程序设计思想20多年来得到很大发展。孤立的面向对象思想虽然功能强大,但目前其发展已接近极限,结果是产生了大量的"对象孤岛"。将面向对象思想与组件编程思想相接合发展起来的基于对象的组件软件结构为这一领域开辟了新的道路。

    从广义上说,软件组件是一种定义良好的独立、可重用的二进制代码,包括功能模块、被封装的对象类、软件框架和软件系统模型等。

    本世纪60年代末到80年代初,结构化的模块式软件开发思想占主导地位,当时的组件的含义是指一些定义良好的方法包或功能模块。

    80年代起,面向对象的软件开发思想迅速发展起来,这时的软件组件的含义就是类库。类虽然提供了封装性、多态性和继承性,但需要依赖于具体的编程语言,耦合度高,且需要用户对类库的结构和宿主语言有较深入的了解,因此,不能完全达到软件重用的可移植性和互操作性要求。

    90年代后,组件的内涵进一步加强,聚合性、独立性和重用性进一步提高。目前,基于对象的组件软件体系结构中的组件是指可方便地插入到语言、工具、操作系统、网络系统中的二进制代码和数据。

    这种软件组件可以看作是一种软件集成电路元件,具有以下特点:

    · 软件IC没有硬件IC的天然聚合性,构成粒度大小自由,便于扩展;

    · 通过规定一个统一的二进制标准,建立起机构之间的智能互操作机制和语言独立性;

    · 外界仅通过接口访问组件;

    · 多侧面性,即组件表达的语义层次高,可以从不同侧面进行连接,外部特性不唯一;

    · 支持封装、继承、多态性。

    基于经典面向对象技术的组件模型为软件体系结构设计和大型应用软件开发给予了强有力的支持,目前已经为软件行业所广泛接受。Microsoft的OLE/COM和SunSoft的JavaBeans都是典型的软件组件规范。

    1.1 JavaBeans

    Java Bean是基于Java环境的,可视的、可操纵的、可重用的组件;JavaBeans组件模型是SunSoft制定的关于Bean的软件组件标准,规定设计所有Bean所依据的框架,确保Bean在具备特定功能的同时,还能被可视化软件构造工具所识别、操纵,并能将这些设计信息保存下来,指导运行时的行为。

    作为可视化组件,所有JavaBean都具备如下特征:

    · 内省(introspection)机制,能够告诉软件构造工具其所能完成的功能,从而允许软件构造工具在设计时对其加以操纵;

    · 用户定制(customization)机制,允许程序员在软件开发阶段利用软件构造工具改变Bean的外观和行为方式。

    · 事件(event)机制,能捕捉事件、引发事件,并将其所能产生和处理的事件告知软件构造工具。

    · 特性(properties)机制,除在软件开发阶段支持用户定制外,还使得软件系统能够在运行时刻对Bean进行加工和控制;

    · 保持(persistence)机制,保存程序员开发时利用构造工具对Bean所做的修改,并在运行时予以恢复。

    · 设计时刻功能和运行时刻功能分离。

    JavaBean主要用于可视化环境,为软件构造工具所利用,但也能通过程序接口直接操纵,Java类库中提供了相应的控制类。

    1.2 OMA/CORBA

    对象管理集团OMG (Object Management Group)是一个国际性的软件行业协会,主要宗旨是促进面向对象的方法在软件工程中的应用,以及在面向对象的软件工程方法学的基础上,为大规模并行系统 (开放式并行计算)软件的开发与应用制定软件体系结构模型和通用接口规范。

    OMG 于1990年末提出了一个对象管理结构的基准结构OMA (Object Management Architecture)。OMA主要涉及用于面向对象语言、系统、数据库及应用程序框架的统一术语体系,面向对象软件系统的抽象框架和基于面向对象技术的分布式软件系统参考模型等。为了构造上述参考模型,OMA规定了四个方面的标准:

    1. 对象请求代理ORB (Object Request Broker),即关键通讯单元,在不同的应用程序对象之间以高度协同的方式发送消息;

    2. 对象模型,即独立设计的、可移植的抽象模型,可以与其他符合OMA规范的面向对象系统进行通讯;

    3. 对象服务,利用ORB实现基本对象功能,确定对象的逻辑模型和物理存储方式;

    4. 通用组件,包含了适用于很多应用领域的基本功能,这些功能可以通过符合OMA规范的类接口获得。

    OMG 于1991年末提出的CORBA (Common Object Request Broker Architecture),是OMA参考模型中的ORB接口技术规范。这一标准规定了如何定义、创建、调度、引用对象,以及对象之间如何通讯。符合 CORBA规范的ORB是典型的中间件,允许Client对象向Service对象发出请求。

    CORBA规范的基本组成如图所示
面向对象技术在软件重用和体系结构中的应用

    主要包括:

    · 对象请求代理ORB (Object Request Broker),是CORBA的核心。作为一个软件组件,对象可以通过ORB发出请求并接收响应。在CORBA中,所有的通讯都通过ORB进行,因而无论一个对象是本地的还是远程的,对于与之进行通讯的其他对象来说都是等价的。CORBA并没有规定如何具体实现一个ORB,几乎每一个不同的产品都有其具体的ORB实现。

    · 接口定义语言IDL (Interface Definition Language),是用于描述对象接口的一种高级符号语言。IDL不涉及任何接口的实现细节,所有COBRA系统都根据IDL用某种特定语言来实现接口。CORBA为C、C++、Smalltalk和JAVA制定了规范,ADA95和COBOL的映射规范也正在制定中。IDL描述通常以接口库 (Interface Repository)的方式进行存贮。

    · 接口库(Interface Repository),其中包括了所有描述服务对象属性、操作、自定义数据类型及异常处理的IDL定义。

    · 基本对象适配器BOA (Basic Object Adapter),描述了ORB和服务器端应用程序之间的接口。BOA负责调度服务器端应用程序维护的对象,并与服务对象交换消息。

    · 静态请求接口SII (Static Invocation Interface)。SII假设在编译时刻客户对象能够明确了解服务对象的接口,即客户与服务器之间的关系应当是可知的、固定的,服务接口的任何改变都会导致软件系统的重新编译。SII是由IDL描述的。

    · 动态请求接口DII (Dynamic Invocation Interface)是一组与服务器无关的通用接口。与新服务对象及其行为相关的信息可以通过接口库获得,客户程序根据这些信息可以在运行时刻动态构造请求。DII使得开发智能化即插即用的软件系统成为可能,但需要涉及大量CORBA API调用,增加了软件的复杂度。

    总之,CORBA提供了一个集成框架,应用程序只要给出用接口定义语言IDL (Interface Definition Language)书写的界面,就可插入框架,与其他对象协同工作,为在分布式环境下实现不同应用程序即插即用的集成提供了有力支持。

    1.3 OLE/COM

    与CORBA一样,Microsoft的OLE/COM是基于分布式对象模型的开放标准,得到多系统软件开发商、独立软件开发(ISV)商和用户的支持。

    OLE实际上是建立在组件对象模型(COM)基础上的一组高层次技术。从基本中间件功能视图的角度来说,COM与CORBA非常相似,同样支持对象的定义、创建、调度、引用及对象之间的通讯,同样提供了接口定义语言(IDL)。

    但是两者之间也存在显著的差异。例如,COM支持由不同程序设计语言或不同编译器实现的对象之间的二进制兼容,以及OLE Automation等。

    服务控件管理SCM (Service Control Manager)集中负责搜索服务对象和在客户与服务器之间建立信道。当客户向某个特定的对象发出初始化请求时,SCM判断包含该对象的服务程序是否已经运行,如否,则通过注册表查找服务程序所在的位置。随后,客户端SCM建立起与服务器端SCM连接的RPC信道;服务器端SCM也进行同样的处理,并在必要的情况下起动服务程序。最后,信道两端的SCM分别将代理程序(proxy stub)载入到客户进程和服务器进程中。

    OLE/COM提供了与CORBA IDL类似的高级描述语言,用于定义COM概念上的接口,即一组逻辑相关的操作或方法。

    OLE/COM结构的另一要素是Automation,允许客户程序动态构造请求(包括方法名、相关参数的类型和取值等),并将请求发送到远端对象。在 CORBA中,客户程序能够通过接口库(repository)获取对象接口的相关信息;而OLE/COM则更进一步,任何符合OLE/COM规范的对象都能自动提供其所能支持的接口信息。

    2 分布式对象中间件

    90年代以来,计算技术逐步进入以网络为中心的新时期,用户迫切希望在网络上建立更为丰富的分布式客户/服务器应用;不仅实现数据共享,而且支持知识共享和各类计算资源的共享;并能实现包括整个企业在内的各个层次的的协同工作。

    为适应上述要求,分布对象技术成为分布式计算环境发展的主流方向。其技术特点为:

    1. 主要针对异构环境下的应用互操作问题;

    2. 系统核心的对象管理将客户/服务器模型与面向对象技术结合在一起;

    3. 提供面向对象的API;

    4. 已经成为建立集成框架和软件部件标准的核心技术。

    在此基础上,为解决大型应用系统的集成性与可扩展性之间的矛盾,中间件(Middleware)技术应运而生。

    中间件是软件中介于在应用层和网络层之间的一个功能层次,使应用系统独立于由异构的操作系统、硬件平台与通信协议组成的底层环境。

 
面向对象技术在软件重用和体系结构中的应用
 


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

    中间件可以分为四种类型:

    1. 基于RPC (Remote Procedure Calls) 的中间件。RPC是传统程序设计语言中过程调用的扩展,被调用的对象可以在分布系统中的任何物理平台上。OSF的DCE和SunSoft的ONC+等均属此类中间件。

    2. 面向消息的中间件,支持基于消息传递的进程间通讯方式。这种中间件既适用于客户/服务器模型,也适用于对等网模型,一般比基于RPC的中间件具有更高的运行效率。典型的系统有:SunSoft的ToolTalk、PeerLogic的Pipes和Talarian的SmartSockets等。

    3. 基于ORBs (Obecjt Request Brokers) 的中间件,此类中间件是面向对象应用程序的首选。消息通过ORB进行路由选择,ORB同时处理集成和安全方面的问题。Microsoft的OLE/COM /DCOM和OMG的CORBA均属此类中间件。

    4. 数据库中间件,支持对异构的传统关系数据库的透明访问。现有的此类系统包括Sybase的Open Server、Oracle的SQL Connect和BEA公司的WebLogic等。

    3 基于面向对象技术的应用软件体系结构

    软件体系结构是一个程序或系统的构件的组织结构、它们之间的关联关系以及支配系统设计和演变的原则和方针。一般地,一个系统的软件体系结构描述了该系统中的所有计算构件,构件之间的交互、连接件以及如何将构件和连接件结合在一起的约束。

    研究软件体系结构的首要问题是如何表示软件体系结构,即如何对软件体系结构建模。针对规模日益庞大、结构日益复杂的应用应用软件,系统模型的设计目标是提高实际应用系统的开放性和集成性,同时兼顾效率。
面向对象技术在软件重用和体系结构中的应用

 
    软件系统的开放性包括数据的开放性、功能的开放性和系统的可扩充性,是否具备良好的开放性基本取决于系统模型。软件系统的集成性是指通过一致的信息描述手段和处理机制将各功能子系统统一到同一个集成环境,集成性的好坏也基本取决于系统模型。软件系统的效率通常包括系统运行的效率和应用开发的效率。运行效率是系统运行时的时空复杂度,而应用开发的效率指开发的难易程度和执行效率。效率大部分取决于系统模型,也与系统的具体实现有关。

    开放的系统模型使得子功能部件的集成易于实现,同时也必然提高应用开发的效率;集成和高效反过来又有利于更好地达到开放的目的。这三者相辅相成,其中又以开放性作为集成和效率的基础,只有开放才有集成,只有开放才有效率。

    针对应用软件系统的开放性,曾先后出现了许多类系统模型,代表了应用软件技术与产业发展的不同阶段。各阶段中有代表性的系统模型依次为:以数据为中心的系统模型、以执行为中心的系统模型、面向对象的系统模型、和基于总线的系统模型。

    以数据为中心的系统模型如图2a所示。这类模型将数据库放在系统的核心层次共享,各功能部件采用统一的数据描述,各子系统的开发过程完全独立;子系统间有统一的数据交换接口;整体的可扩充性好,可任意增加符合数据交换标准的应用程序。但是,这种模型整体结构松散,集成性不够良好;只能做到数据复用,不能做到功能复用,造成大量的代码冗余;由于应用相关数据的存在,难于定义符合所有应用需求的数据接口标准,因此会出现数据语义失真。从开放性的角度来讲,这类系统只具有数据开放性,不具有功能开放性,但其可扩充性很好。

    以执行为中心的系统模型着眼于将不同的应用系统通过统一的执行中心来实现数据和用户界面的共享和一致,如图2b所示。这类模型将共有的计算和执行功能从应用程序中分离出来,放在执行中心,避免了代码冗余;用户与系统的交互与应用程序相分离,便于实现统一风格的用户界面;和数据库的任何数据交换都要通过执行中心进行,有利于数据的严格管理,保证了数据的一致性。这类模型解决了以数据为中心的系统模型的代码冗余及界面风格不统一等问题,但仍存在一些缺陷:执行中心的功能设计复杂,很难确切定义符合所有应用要求的功能集合,而且实现起来也相当困难;执行中心同时与用户界面和所有应用程序保持通讯,又管理着数据,负担过重,容易形成瓶颈。总之,这类模型既具有数据的开放性,又具有功能的开放性,可扩充性也好,整体上优于以数据为中心的系统模型。

    随着面向对象技术的成熟,出现了更为简炼的面向对象的系统模型,与前两类模型的设计思想有较大差别,如图2c所示。其中,系统内核对象中封装的是能为用户界面对象和所有应用对象所共享的数据及相应的操作;用户界面对象中封装的是用户界面数据及相应的操作;应用对象中封装的是应用数据及相应的操作。所有这些对象通过相互间的通讯协调来完成指定的功能。从系统构成的角度来说,这类模型的结构是无中心的,系统由各对象实体构成,各对象实体具有平等的地位,这与以数据为中心和以执行为中心的模型不同。面向对象的系统模型的主要优点在于,数据和功能的合理封装降低了由于数据和功能的集中管理所带来的通讯上的开销和操作上的复杂性;另外,系统的无中心结构也使系统的构成变得更加灵活。从整体上看,面向对象的系统模型无论其开放性还是其有效性都要优于前两类模型。

    面向对象模型比以往的模型有了很大的进步,但仍有不足:对象之间的联系是一种点对点的直接联系,当系统中对象数目增加时,通讯链接数将以平方级激增;同时,为支持通讯,每个对象实体都要维护一个包含所有对象实体功能服务信息的功能服务信息库,这部分信息不但重复,而且还要保证其一致性。这些开销都损害了系统的效率。更大的问题还在于:对象的接口没有一致的标准,造成向系统中扩充对象时的随意与不规范,不利于系统的维护以及对象的复用。

    以面向对象为基础的组件和中间件技术的逐渐成熟又为应用软件系统的建模引入了新的思想,产生了基于总线的系统模型,如图2d所示。组件、中间件是继面向对象技术之后发展起来的新的软件工程技术,是面向对象技术的延伸。基于总线的系统模型仍然是一种面向对象的结构,但系统中的对象是按照规范设计的模块,这些定义良好的软件模块(组件)在系统中共存,并且充分地相互作用。按照这种结构,可以将若干组件组合起来,以建立更大和更复杂的系统。

    这种模型的关键在于一种高效的总线结构,使组件之间能以一个公共的接口互相连接,做到组件的即插即用,无缝集成。这种模型的系统中,组件间的通讯链接数是线性的,并且由于各组件接口规范的一致性,通讯的复杂度大大下降,也提高了组件的互操作性。

    根据组件在系统中地位的差异,应用软件系统中的组件可以分为两个层次:核心组件和应用组件。相对于核心组件来说,应用组件所要求的系统服务要少得多,请求服务的频度也较低。相应地,总线也可以分为核心总线和应用总线,从而形成双总线结构。在这种总线结构中,核心组件和应用组件之间仍然保持良好的互操作性,但应用总线屏蔽了应用组件的一部分服务请求,减少了核心总线上的流量,从而提高了应用软件系统核心的效率。

    核心组件与核心总线构成了应用软件系统的原型和框架,在此基础上与各应用组件集成。

    通常在分布式环境中,应用组件不是直接连结到应用总线(也称Broker)上,而是通过一个软件代理(Agent)间接地连在总线上,如图3所示。 Agent的作用在于,一方面代理应用组件的复杂通讯过程,使应用组件更专注于功能的实现;另一方面将适应不同应用需求的组件内部的异构数据转换成同构数据,以保证Broker上通讯语言的统一。由此可见,在基于总线的系统模型中,Broker与Agent构成了介于应用组件(客户)与核心系统(服务器) 之间的中间件。
面向对象技术在软件重用和体系结构中的应用
 

    4 并发面向对象技术

    并行计算是未来计算机的发展方向。将面向对象与并行计算的相结合的并发面向对象技术是一个比较新的研究领域,许多问题有待解决。

    目前一些流行的面向对象程序设计语言(如C++)只提供了描述程序顺序执行的能力;即使有些语言(如Smalltalk)提供了描述程序并发执行的机制,但往往采用一些传统的并发控制模式和设施,没有从对象模型本身的特点来考虑并发控制,从而造成并发与对象模型中一些概念(如封装、继承及自治等)相冲突。

    近年来,许多面向对象并发编程的方案被提出,可归纳为3种不同方法:

    1. 设计全新的并发面向对象语言;
    2. 扩展现存的顺序面向对象语言;
    3. 使用现有的顺序面向对象语言,通过外部库提供并发抽象。

    并发类库正成为并发面向对象技术中最为重要的方法。这种方法的优点是不需要修改原有顺序面向对象语言,保留原有编程方法,可以更好地利用面向对象技术中的一些特性,用户容易接受。

    为了在面向对象模型中引进并发机制,并发类库的设计必须能与对象模型中一些现有的特性有机结合,为面向对象程序设计语言扩展描述系统并发行为的能力。此外,这种方法一般还需要某种底层特殊软件(运行支撑系统)的支持,并将支撑系统的复杂性全部隐藏在类库中。

    顺序对象模型由一组被动的对象构成。系统的执行行为是,外界激活其某个对象的某个方法,该方法的执行中向系统中其他对象发送消息,从而激活这些对象的方法的执行。这里的消息发送就是过程调用,即消息发送者必须等到消息接受者的相应方法执行完毕,才能继续执行下去,整个系统只有一个执行线程 (Thread)。

    在面向对象的并发模型中,可并发执行的基本单位是对象,称为并发对象。与普通对象不同的,并发对象具有自己的控制线索和独立的地址空间,多个并发对象可以并发运行,通过方法(消息传递)请求相互作用。目前存在两种构造并发对象的典型方案:

    1. 采用异步消息发送。即一个对象向另一个对象发送消息后,前者不必等待后者处理消息即可继续执行下去,后者则对消息进行缓存;

    2. 对象可以有一个体(Body),一旦对象被创建,这个体就开始执行。

    在方案1中,由异步消息发送产生新的执行线程,从而引起系统的并发。由于采用异步消息发送,必须提供今后如何取得返回值的设施。异步消息发送的不足之处在于:它使得程序的行为难以把握,不利于对程序的推理(Reasoning)。

    方案2通过创建新对象产生新的执行线程,在对象体执行的同时,对象还可以接收和发送消息,消息发送可采用同步方式,但应允许对象内部的并发,否则容易造成死锁。

    处于并发环境中的对象,随时都会面临环境对其方法的并发调用。为了保证对象状态的一致性与完整性,必须对方法的并发调用加以同步控制。同步控制可以由消息发送者执行,也可以由消息接受者执行。但是,若同步控制仅由消息发送者执行,当消息发送者由于种种原因没有进行同步控制时,将会产生对消息接受者方法的并发调用,造成消息接受者内部状态的不一致与不完整。因此,消息接受者本身必须提供同步控制。

    并发对象的同步控制可以分成两类:条件同步和互斥。条件同步是指对象在某种状态下只能接受某些消息;互斥是指当处于某种状态下的对象可以接受(处理)多个消息时,由于这些消息的处理都有可能使用对象的成员变量,如果让它们同时执行,就存在共享对象的成员变量问题,为了保证对象状态的完整性和一致性,这些方法必须互斥地使用共享变量。

    如何在并发对象类中描述对象的同步控制,一般存在两种方式:集中控制和分散控制。

    集中控制方式是把对象的同步控制放在对象(类)中某一个地方集中进行描述。这种方式要求设计者必须对对象的并发行为有整体的了解,还有可能带来继承异常,即在定义子类时,必须对父类的同步控制描述进行重定义,才能把新定义的方法考虑进来。

    分散控制方式是把对象的并发控制描述分布到对象的各方法上。其中一种方案是在对象各方法的实现中进行同步控制,对象无条件地接收消息,在消息的处理方法中,根据对象目前的状态决定是等待还是继续执行。这种方案的不足之处在于:被挂起的方法往往使得对象处于一种不稳定状态,使得对象此时不适合于处理其他消息;并且当在子类中改变父类某方法的同步控制时,需对整个方法重定义。另一种方案是在对象类中给每个方法加一个激励条件,当对象接收到消息时,将根据相应方法的激励条件来决定是否处理该消息,对不满足激励条件的消息让其等待。这种方案优于前一种方案,因为,当定义子类时可以对父类中各方法的激励条件和方法的实现分开进行继承,从而避免了不必要的重定义。

  • 相关文章:

发表评论:

◎欢迎参与讨论,请在这里发表您的看法、交流您的观点。

日历

最新评论及回复

最近发表

Powered By Z-Blog 1.8 Arwen Build 90619 Code detection by Codefense  theme by BokeZhuti

Copyright know blog. Some Rights Reserved.站长(msn):webmaster#webgou.info(#换成@) 粤ICP备09183716号