(通信与信息系统专业论文)组件技术在多层分布式系统开发中的研究与应用.pdf_第1页
(通信与信息系统专业论文)组件技术在多层分布式系统开发中的研究与应用.pdf_第2页
(通信与信息系统专业论文)组件技术在多层分布式系统开发中的研究与应用.pdf_第3页
(通信与信息系统专业论文)组件技术在多层分布式系统开发中的研究与应用.pdf_第4页
(通信与信息系统专业论文)组件技术在多层分布式系统开发中的研究与应用.pdf_第5页
已阅读5页,还剩61页未读 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

摘要 本课题来源与爱帝诺软件技术( 常州) 公司合作开发的项目。以生产制造软件系统的 主生产计划m p s 子系统为背景,针对软件系统在可重用性、可扩展性和可维护性方面存 在的问题,本文提出了一个基于组件和可复用框架的分布式应用系统的开发方案。 本文首先利用u m l 面向对象建模方法完成了m p s 系统的需求分析和数据库的设计, 使需求分析过程与开发过程更紧密地结合起来,为组件的抽取、开发与组装奠定了基础: 然后将典型三层系统结构中的业务逻辑层分为业务实体层、数据访问逻辑层和业务规则 层,提出了一个更加清晰、易于开发和复用的总体框架结构,并设计了框架中不同组件的 开发策略;最后利用c o 啪m t s c o m + 组件技术完成了基于本框架的m p s 系统中各层组 件的开发、分布式事务处理及部署通信,调试了系统的运行,实现了系统的功能。 组件技术在多层分布式应用系统开发的应用,不仅可以实现源代码或功能的重用,利 用已有的组件去构造新的软件系统,减少重复性劳动;而且组件的接1 2 与实现相分离的原 则,使得系统的修改和扩展更加容易。 关键词:组件、分布式系统、u m l 、框架 a b s t r a c t t h e s u b j e c t r o o t si nt h e c o o p e r a t i v ep r o j e c t w i t hi d n u os o f t w a r e t e c h n o l o g y c o m p a n y ( c h a n g z h o u ) w i t h t h em a s t e rp r o d u c t i o n s c h e d u l e ( m p s ) s u b s y s t e m o ft h e m a n u f a c t u r i n gm a n a g e m e n ts y s t e ma st h eb a c k g r o u n d t h et h e s i sb r i n g sf o r w a r dan e ws y s t e m d e v e l o p m e n ts o l u t i o nb a s e do nc o m p o n e n t sa n d r e u s a b l ef r a m e w o r kt os o l v es o f t w a r ep r o b l e m s i nm u s a b i l i t y , r e p l a n t a t i o na n de x p a n s i b i l i t y t h em p s s y s t e mr e q u i r e m e n t sa n a l y s i sa n d t h ed e s i g no f d a t a b a s ea r ec o m p l e t e dw i t hu m l m o d e l i n gt e c h n o l o g y ,w h i c hi n o s c u l a t e s t h e s y s t e m sr e q u i r e m e n ta n a l y s i sp r o c e s s a n dt h e c o m p o n e n t - b a s e ds o f t w a r ed e v e l o p m e n tp r o c e s sa n dp a v ew a y f o rt h e a b s t r a c t ,d e v e l o p m e n ta n d a s s e m b l yo fc o m p o n e n t s t h e nt h et h e s i sd i v i d e st h eb u s i n e s sl a y e ri n t h et y p i c a lt h r e e - t i e r a r c h i t e c t u r ei n t oa n o t h e rt h r e es u b l a y e r st h a ta l et h ed a t ae x p r e s sl a y e r , d a t aa c c e s sl o g i cl a y e r a n db u s i n e s sr u l el a y e r ,a n daf r a m e w o r kt h a ti sm o r ee x p l i c i ta n de a s i e rt od e v e l o pa n dr e u s ei s c o n s t r u c t e d i nt h i sf r a m e w o r k ,t h ed e s i g ns t r a t e g ya n dm e t h o do fc o m p o n e n t si nd i v e r s el a y e r s a r eg i v e nt oc o m p l e t et h e i rc o r r e s p o n d i n gf u n c t i o n s f i n a l l yt h ed e v e l o p m e n t ,a s s e m b l ya n d d e p l o yo fc o m p o n e n t si ne v e r yl a y e ra r ef i n i s h e dw i t hc o m m t s c o m + m o d e l t om a k et h e w h o l e s y s t e m r u n s m o o t h l yi nt h ec l i e n te n d i nc o n c l u s i o n ,t h e a p p l i c a t i o n o fc o m p o n e n tt e c h n o l o g yi nn t i e rd i s t r i b u t e ds y s t e m d e v e l o p m e n tr e a l i z e s s o f t w a r er e u s a g ei d e aa n da v o i d sr e p e t i t i v ec o d i n gp h e n o m e n a t h e s e p a r a t i o nb e t w e e n i n t e r f a c ea n di m p l e m e n tm a k e ss y s t e mm a i n t e n a n c ea n dr e p l a n t a t i o nm u c h e a s j e l k e y w o r d s :c o m p o n e n t ;d i s t r i b u t e ds y s t e m ;f r a m e w o r k ;u m l ( u n i f i e d m o d e l i n gl a n g u a g ) 第一章绪论 1 1 分布式应用系统 第一章绪论 1 1 1 分布式系统概述及发展状况 自分布式系统出现以来,它己成为软件工程领域中的一个重要研究课题。一个分布式 系统其实是一些独立的计算机的集合,整个应用系统的执行分成数个不同部分并且执行在 不同的机器中,但对这个系统的用户来说系统就像运行在一台计算机上【1 1 。 逻辑上,分布式系统根据业务逻辑间的所属关系及数据的传递形式,将一个具体的业 务处理细化为几个步骤的调用,每一个步骤都隶属于应用服务器的某一层次,相连层次的 步骤之间是上下关系,同一层次的步骤之间是平行关系,跨层次的步骤之间一般不能直接 相互调用。物理上,分布式系统中的数据库服务器和应用服务器可以在同一机器上,也可 以分部在不同的机器上,根据业务量可随时改变应用服务器的位置和数量。这种物理上分 步式的目的是为了降低主服务器的负荷,平衡网络中计算机业务处理的分配,提高计算机 系统协同处理的能力和可维护性,使应用的实现更为灵活。 二十世纪九十年代以来,随着个人计算机和工作站的普及以及网络通信技术的发展, 计算资源和信息资源被分布在网络的各个节点上,这使得计算模式由原来的主机系统向客 户服务器及浏览器月艮务器发展,分布计算逐渐成为计算技术的主流。总的看来,计算机 应用系统的体系结构经历了四个阶段的变化 2 1 :基于主机的计算机系统;p c 与传统的网络 技术相结合的文件服务器结构:客户服务器( c s ) 的系统结构;在c s 或者b s 结构 基础上扩充起来的包括客户端、数据库服务器、应用服务器构成的三层或多层结构。大部 分分布式应用系统结构主要是后两种结构。 1 ) 双层客户机服务器系统( c s ) 早期的信息系统大多采用双层结构的c s ( 客户机服务器) 模式【3 】,即用具有较强处理能 力的工作站或p c 机作为客户机,后台的网络服务器来充当数据库引擎。应用系统的商业 逻辑通常封装在客户端的程序中,或在后台d b m s 中以触发器存储过程的形式实现,如 图1 1 所示。在两层结构的系统里,业务逻辑可以放在客户端的用户界面控制流中,也可 以嵌在服务器端的数据库中,一般是客户端和服务器端各实现一部分业务逻辑。 这种模式的优点在于系统设计相对简单,数据访问比较容易实现,g u i 图形用户界面 可以与数据源直接绑定在一起,系统的连接方便,可根据需要随时地增减用户。同时开发 和运行的环境都相对简单,只要把客户机和服务器在网络上连接,利用一些快速应用开发 工具( r a d ) ,就可以很快地开发出小规模应用系统。 不过双层客户机服务器模型也存在许多局限性【4 】:服务器将消耗部分系统资源用于处 理与客户端的连接工作,因而可能无法及时响应数据请求,而且安全性不好;客户端应用 程序的分发工作相当烦琐,每台客户机都需安装客户端程序的执行文件,而每次对客户端 程序的修改和升级,意味着上述分发过程的又一次重复:难于维护和移植,系统中某处商 业逻辑的改变往往涉及多个客户机上的应用,需要分别修改并且要重新编译。 圈1 1 双层客户服务器系统模型 2 ) 三层结构系统 三层系统是对早期双层模式的拓展,即在客户端与后台数据库中添加应用服务器,其 各层划分如下: ( 1 ) 表示层:提供一个可视化接口,向用户显示信息和收集用户数据。表示层本身 不进行复杂的业务数据处理,只负责向业务逻辑层发出请求。 ( 2 ) 业务逻辑层:将原置于客户端的业务逻辑分离出来,集中于本层处理。它处理 来自表示层的应用请求,完成业务逻辑的计算任务,向数据服务层存取访问数据,并将处 理结果返回给表示层。本层是应用系统的核心部分。 ( 3 ) 数据服务层:负责数据的定义、访问、更新和维护,管理并响应来自业务层的 数据操作请求。本层实现了数据的持久性存储和系统级的安全访河控制。 三层结构里又可划分为c s 模式【5 】和b s 模式吼三层c s 模式是在传统的两层c s 应用结构中的客户端与服务端之间插入一层或几层中间件( m i d d l e w a r e ) 或称为应用服务 器( a p p l i c a t i o ns e r v e r ) 。c s 模式的优点是图形用户界面功能强大,交互性强,更利于处 理大量数据。图1 2 是三层结构的客户服务器结构示意图。 业务逻辑中心控制 图i 2 三层客户,服务器系统模型 三层b s 模式是一种以w e b 技术为基础的新型系统模式,专门为i n t r a n e t i n t e m e t 的应 用而设计的,特点是不需要专门的客户端程序,客户端只要有浏览器即可使用。客户端是 一个通用的浏览器软件,各个用户透过h t r p 请求调用w e b 服务器上的处理程序;第二层 w e b 服务器启动相应的进程去响应来自浏览器的请求,从而完成计算处理并将结果返回给 客户端:第三层数据库服务器受责完成w e b 服务器端发出的数据操作请求。b s 模式的优 2 第一章绪论 点是简化了客户端,用户的操作更加简单,适用于网上信息发布。 由于企业应用集成系统本身的需要,既要处理内部业务,又要与外部进行交互,因此 出现了c s 和b s 相结合的模式,具体结构如图1 3 所示f 7 】。 圈1 3 典型的多层分布式系统结构 3 ) 三层结构在分布式系统开发中的优势 在系统开发中,选择三层及多层分布式系统的体系结构具有如下优势 8 , 9 , 1 0 】: ( 1 ) 使各层在逻辑上保持相对独立性,允许更灵活有效地选用相应的平台和硬件系 统,分别负责不同的业务处理,并且这些平台及其组成部分具有良好的可升级性和开放性。 ( 2 ) 可以并行开发各层的逻辑功能,选择各自适合的开发工具和开发团队。这样就 缩短了开发周期,使得软件拥有较高的性价比,并且开发小组可根据各自能力进行分工。 ( 3 ) 应用服务层有效地将表示层与数据层隔离起来,未授权的用户难以绕过业务逻 辑层去非法访问数据层,这使得分布式计算体系更加安全可靠,保证了数据的安全性。 由于三层结构的优势,越来越多的公司在项目开发中选择了三层体系结构, 1 1 2 组件技术在系统开发中的应用 目前分布式系统都在系统结构方面向三层发展,在开发技术方面也出现了许多新的方 案,其中以组件技术为主。在系统开发中常采用的分布式组件对象模型如c o r b a 、c o m 、 r m i 等都已经成熟,这也使得组件化的软件开发方式得到了飞速的发展。目前国内许多大 工程、大项目都纷纷采用这项技术,如我国8 6 3 计划的近一半项目、通信方面许多大型项 目的投标、金融行业的业务处理系统等。都在朝这个方向走【l ”。 据2 0 0 3 中国软件平台发展战略研究报告调型胫】,目前软件分布式平台表现出两种 新趋势:一是软件基础架构平台的兴起,二是业务基础软件平台的诞生。前者是种为复 杂应用软件系统提供通用技术基础架构的软件平台,较为熟悉的有b e a 的w e b l o g i c 、i b m 的w e b s p h c m 分布式组件开发平台;后者是指以业务导向和驱动的、可快速构建分布式应 用的平台。业务基础构架平台有两种表现途径:第一种是“组件化业务基础软件平台”, 其代表厂商有国内的东软金算盘、用友、金蝶等,第二种是“模型化业务基础软件平台”, 代表厂商有国外的j l l s t e p 、b a a n 、s a p 等。这两种做法各有特点,所包含的基本内容及 适应对象不尽相同,但都提供组件化系统开发的环境。 在国外的企业信息系统方面,美国的b a a n 公司在前不久签署的一项协议中,表示计 3 冒圈 组件技术在多层分布式系统开发中的研究与应用 划建立基于组件的c s 应用软件。o r a c l e 曾许诺在1 9 9 7 年底之前所有的软件都被j a v a 组 件化,并通过o r a c l e 网络计算结构n c a 将应用软件转换成更为分布化的系统。j d e d w a r d s 计划在1 8 个月内交付他们有4 0 0 0 0 个组件组成的e r p 应用程序套件。s a p 公司已经推出 了代表r 3 系统部分的1 7 0 种组件。这些公司都计划把他们的应用程序重新建立在数以百 计的基于j a v a 小程序的组件和模块上1 1 3 j 。 软件组件化是2 1 世纪软件工业发展的大势趋,g a r m e rg r o u p 认为:“到2 0 0 3 年,至 少7 0 的新应用系统将主要建立在如软件组件和应用框架这类构造块之上;应用开发 的未来就在于提供一开放的体系结构,以方便组件的选择、组装和集成” 1 4 1 1 2 应用背景一主生产计划m p s 子系统 本课题来源于作者在印度爱帝诺软件技术( 常州) 公司实习期间所参与开发的一个制 造企业生产管理软件系统。期间作者翻阅了大量的文献资料,深入常州市西玛仪器制造公 司,对企业的生产制造流程进行了详细的调研,为本课题的研究做了理论和实践的准备。 生产管理系统对生产进行计划、组织与控制,它以生产计划为主线,使各种资源按计 划所规定的流程、时间和地点进行合理配置与管理1 1 5 1 。编制生产计划是生产与运作管理的 一项基本任务,是组织生产运作活动的依据。它根据市场的需求和企业的技术、设备、人 力物资、动力等资源能力条件,合理地安排计划期内应当生产的品种、产量和出产进度, 以便充分地满足客户订单的要求。 主生产计划m p s ( m a s t e rp r o d u c t i o ns c h e d u l e ) 是生产计划编制的起点,它确定每一 个具体产品在每一个具体时间段的生产任务,按照时间分段计划企业所要生产的最终产品 的数量和交货期,具体输入输出如图1 4 所示。它是企业产品生产的详细报告,常伴随着 粗能力计划的运行,需要对关键资源进行平衡,确定所需要的资源是否能得到满足。 预测+ 生产计划大纲+ 客户定单+ 能力限制 【主生产计划 + 识别生产品种 + 安排生产时同 + 确定生产数量 产品挺前期獬4 图1 4m p s 输入输出圈 粗能力计划r c c p ( r o u g h - c u tc a p a c i t yp l a n n i n g ) 是同主生产计划相伴而行的能力需 求计划,它对生产中所需要的关键资源进行计算和分析,分阶段、分工作中心计算出入员 负荷和设备负荷,进行瓶颈计算并调整生产负荷,给出能力需求的概貌“。 主生产计划的对象是最终产品,即产成品,两一个产品可能是由成百上千神零配件组 装而成的,那么如何安排这些零配件的生产计划呢,这是物料需求计划所要解决的问题。 4 第章绪论 修改 n 调整能力数据 生产规划 销售需求信息 皇 主生产计划 ( m p s ) 丽舞酾 ( r c c p ) $ 砺再害量翮 ( m r p ) 两斋丽 ( c r p ) , :与苷、= 必要时修改 修改 n 采购作业i1车间作业 投入与产出控制 图1 5m r p 生产运作流程圈 1 3 研究内容 1 3 1 主要解决的问题 它将主生产计划排产的产品分解成 各自制零部件的生产计划和采购件的采 购计划,解决企业要生产什么,生产多少, 要用到什么,已有什么,还缺什么,何时 安排等问题。 能力需求计划是对各个生产阶段的 工序( 工作中心) 所需要的资源如时间、 机器负荷、工人数量等,进行精确计算, 确定物料需求计划的可行性。 从图1 5 中可以看出,企业的物料需 求计划、车间作业计划、采购计划等均来 源于主生产计划,即先由主生产计划驱动 物料需求计划的生成,再由物料需求计划 生成车间作业计划和采购计划。所以主生 产计划在e r p 企业资源计划系统中起着 承上启下的作用,所处的位置非常重要 1 5 1 本文针对软件开发中的一些问题和m p s 系统的要求,主要需要解决了以下问题: ( 1 ) 使分布在不同网络节点的各个系统之间相互通信,共享数据和逻辑计算功能 企业的各个系统如销售系统、采购系统、生产系统及财务系统等分布在企业局域网的 不同节点上,为了加强各部门之间的联系与协作,分散在不同网络节点的各个系统之间应 该能够通信,提高信息的畅通和数据的共享,尽量去避兔数据的分散性、重复性和维护困 难等问题,同时要避免在各系统之间存在过多的对同一个业务的计算处理,改变系统的封 闭、庞杂的结构。 ( 2 ) 设计一个灵活的可复用的框架,提高软件系统的可重用性和可扩展性、维护性 许多应用系统都在不停地重复开发,但要么由于系统需求分析时的考虑不周,要么由 于体系设计时采用了传统的两层c s 模式,或者开发时采用了结构化系统开发方式,当移 植到其他企业、其他项目或者应用系统本身的逻辑处理规则发生变动时,有时不得不对软 件进行大规模全方位的修改,系统的可维护性比较差。 组件技术在多层分布式系统开发中的研究与应用 我们所开发的主生产计划系统是作为一个产品,而不是为具体某个企业定做的项目, 因此系统必须具备较强的可复用性和可移植性,当应用在不同的企业时,向客户端提供的 接口不变,只要修改局部内容,不必去大规模调整,以便减少重复开发,提高效率。 ( 3 ) 把系统的需求分析过程与组件化开发过程更紧密地结合起来,给组件的抽取、 开发与组装提供一个可行的方案 组件化软件开发方法中组件的抽取、开发与组装是关键问题。利用传统的结构化分析 方法( s a ) 去做系统的需求分析时,更强调通过功能模块的一步步分解去实现业务需求, 而组件化软件开发方法强调通过组装对象的行为及交互去完成系统总体功能,彼此不能融 洽地结合起来。结构化分析中所得到的实体关系e - r 图是关系模型,不是对象模型,只有 属性,没有方法;在流程图中对数据对象本身的行为和彼此的交互的描述不是很清晰,这 都不利于组件的抽取与组装,给系统开发带来了困难。 1 3 2 本文所做的工作 在理论方面,为了使分布在不同网络节点的各个子系统之间共享数据和逻辑计算功 能,提高系统的可重用性、可扩展性、可维护性,本文提出了一个新的基于组件的分布式 应用系统总体框架结构,对框架中各层组件的功能及实现策略做了设计,解决了数据的表 示、访问方式和业务逻辑的组织及封装方式。本文设计的框架独立于具体的软件系统,完 全可以应用到其他系统中,具有较高的复用性。 在实际应用方面,本文完成了如下工作: ( 1 ) 针对企业分布式信息系统的特点,完成了基于u m l 面向对象建模的m p s 系统 的需求分析,建立了需求模型和分析模型,为组件的抽取、开发与组装奠定了基础; ( 2 ) 将m p s 需求分析中的类图映射到数据库表中,完成了数据库的设计; ( 3 ) 按照u m l 建模图和总体框架中各层组件的设计策略,完成了业务逻辑层的三种 组件即业务规则组件、实体组件和数据访问组件的开发和组装,实现了系统的功能。 1 4 研究意义 由于软件规模的快速发展,如何避免大量的重复工作,提高软件维护的容易性,使软 件走向工业化生产,越来越受到行业的关注。而采用组件技术开发应用系统,不仅可以实 现源代码的重复性使用,利用已有的组件去构造新的软件系统,减少重复性劳动;而且组 件的接口与实现相分离的原则,使得组件的修改、升级更加容易。 但是组件技术仍然处于发展的阶段,要做到全面地设计组件的功能与服务,合理地划 分组件的粒度,使组件的重用性和可维护性以及执行效率达到最佳平衡仍然是比较困难 的。特别是当需求差别很大,如果组件设计不合理,结果可能重复编码现象依然很严重, 开发效率依然很低,因此仍然有许多问题有待于进一步地挖掘和分析。 6 第二章基于组件的软件开发方法 第二章基于组件的软件开发方法 2 1 组件的定义及特点 组件是基于面向对象的、支持拖放( d r a g a n d d r o p ) 和即插即用( p l u g a n d p l a y ) 的软件开 发概念,它是独立于特定的程序设计和应用系统、可重用和自包含的软件成分【1 7 】,如被封 装的类、一些功能模块、软件构架、系统模型和软件的文档等。 2 0 世纪6 0 年代末到8 0 年代初,结构化的软件开发思想占主导地位,当时组件的含义 是指一些定义良好的方法包或功能模块。8 0 年代起,面向对象的软件开发思想迅速发展起 来,这时软件组件的含义就是类库。类虽然提供了封装性、多态性和继承性,但需要依赖 于具体的编程语言,耦合度比较高,并且开发人员需要对类库的结构和宿主语言有较深的 了解,因此不能完全达到软件的可移植性和互操作性要求。9 0 年代后,组件的内涵进一步 加强,聚合性、独立性和重用性进一步提高,并且得到了分布式对象技术和组件对象模型 的大力支持,使得基于组件的应用软件开发变得更加容易和方便【l ”。 组件是“系统中一个可替换的物理部分,它遵循并提供了一组公共接口的实现” 1 9 o 组件可由一组相关对象封装而成,是一种比对象重用粒度更大的二进制软件构造模块。组 件提供给用户的只是接口信息,把具体的实现细节完全隐藏起来,实现了真正意义上的封 装 2 0 , 2 1 。因此组件的特点有: ( 1 ) 构成粒度大小自由,便于扩展; ( 2 ) 通过规定一个统一的二进制标准,建立起智能互操作机制和语言独立性; ( 3 ) 外界仅通过接口访问组件: ( 4 ) 多侧面性,即组件表达的语义层次高,可以从不同侧面进行连接,外部特性不唯一; ( 5 ) 支持封装、继承和多态性。 2 2 分布式组件对象模型 组件对象模型是为开发者定义软件组件而建立的体系结构和应用编程接口a p i ( a p p l i c a t i o n p r o g r a m m i n g i n t e r f a c e ) 集,其思想是创建可重用的组件并将其组合到容器中, 以得到新的应用系统。它定义了标准的组件结构和组件接口,并在组件之间建立通信机制, 使组件能协调工作。目前,国际上广泛应用的组件开发模型有 2 2 】:o m g 组织的c o r b a 、 m i c r o s o f t 公司的c o m m t s c o m + 和s u n 公司的j a v a b e a n 。 2 2 1c o r b a 、c o m m t s c o m + 、j a v ab e a n s 模型 1 ) c o r b a 规范“3 1 c o r b a ( c o m m o no b j e c tr e q u e s t b r o k e ra r c h i t e c t u r e l 是一组标准,用来定义”分布式对 7 组件技术在多层分布式系统开发中的研究与应用 象系统”,由o m g ( o b j e c tm a n a g e m e n tg r o u p ) 作为发起和标准制定单位。c o r b a 的目的 是定义一套协议,让符合这套协议的对象可以彼此交互,不论它们是用哪种语言编写的, 也不论它们运行在哪种机器和操作系统上,因此c o r b a 使用接口定义语言i d l 来描述对 象外部的接口,并制定了一套对象间通信的协议,通信介质被称为o r b ( o b j e c tr e q u e s t b r o k e r ) ,它借助i i o p ( i n t e m e ti n t e r - - o r bp r o t o c 0 1 ) 通信协议,负责在客户端与服务器端 的对象之间传递消息,承担了在异质平台和系统之间统一数据格式、查找并启动实现模块 等功能。 通过使用o r b ,一个客户程序可以直接调用一个服务器对象上的方法,而服务器程序 和客户程序可以分步在同一个机器上也可以是通过网络连接的。无论客户程序运行在哪 里,当它调用这些方法的时候就像调用本地函数一样。o r b 截取调用请求,当找到一个可 以实现该请求的对象后就进行响应,传递相关的参数,调用对应函数,并返回其结果。客 户程序不必考虑对象在哪里,其编程语言是什么,操作系统是什么,或其他任何不属于对 象提供的接口的内容。这样,o r b 提供了在不同的分布式环境下不同机器上的应用程序之 间的协同工作能力,而且可以将多个对象系统以用户透明的方式连接起来。 2 )c o m 伍仃s c o m + 模型m 4 c o m 是目前应用最广的软件组件模型,由m i c r o s o f t 公司推出,它提供了大量集成服 务、大量的应用程序和可重用的组件。c o m 引进了”组件”的概念一可复用的代码块,可以 将多个独立函数的功能进行组合。分布式的c o m 即d c o m 扩展了组件对象模型技术,提 供了一种协议,使其能够支持在局域网、广域网上不同计算机的对象之间的通讯,因此系 统可以在物理上达到分布性,从而满足实际应用的要求。 为了解决如何实现对c o m 组件的事务处理和安全管理等问题,微软推出了m t s 系统。 m t s ( m i c r o s o f tt r a n s a c t i o ns e f v e r ) 实际上是一个中间件,它实现了复杂的组件管理功能, 能够自动支持组件的事务处理,进行基于角色的安全管理。其中单个应用可以被分隔成不 同的包,不同的包实际上是在不同的进程中运行的,这样大大提高了应用系统的容错能力。 c o m + 是操作系统w i n d o w s2 0 0 0 上新的功能和特性之中最值得关注的一个。通过 c o m + 管理程序m m c ( m i c r o s o f tm a n a g e m e n tc o n s o l e ) ,可以设置c o m + 应用系统和 c o m + 组件的属性信息。c o m + 把大多数的组件信息保存在一个新的数据库中,称为c o m + 目录,它把c o m 和m t s 的注册模型统一起来,并提供了一个专门针对组件的管理环境。 同时,c o m + 新增了一些服务,主要有队列组件、负载平衡、内存数据库和事件服务等, 提供了更强大的分布式系统开发支持。 3 ) j a v ab e a n s ,e j b 【2 6 0 7 】 j a v a b e a n 可以运行在所有支持j a v a 的平台上,是一种基于j a v a 的软件组件,它的开 发需要遵守由s u n 和其他几个大公司制定的称为j a v a b e a n s a p i 的命名约定。目前较为常用 的e j b ( e n t e r p r i s ej a v a b e a n s ) 技术是在此基础上发展起来的,它己成为j a v a 企业计算平 台的核心技术。1 9 9 8 年3 月在s a n f r a n c i s c o 召开的j a v a o n e 9 8 开发者大会上,s u n 公司芷 第二章基于组件的软件开发方法 式发布了e j b l 0 版规范说明,其中对e j b 的定义是:e j b 是用于开发和部署多层结构的、 分布式的、面向对象的j a v a 应用系统的跨平台的组件体系结构。e j b 是一种非可视化的组 件,完全位于服务器端,它可以和远程的客户端程序通讯,并提供一定的功能。与j a v a b e a n s 相比,e j b 的重点是给出服务框架模型,以保证j a v a 组件能够进行可移植性的部署。 e j b 组件模型定义了企业j a v a 组件和j a v a 组件容器之间的关系,提供了许多服务例如 生存周期管理、事务控制、持续管理、透明的分布服务和安全服务等,并提供三种与远程 对象交互的机制,即通过j d b c 数据库访问协议访问数据库服务器、通过l l o p 访问c o r b a 服务器、通过远程方法调用( 砌) 访问j a v a 服务器。 2 2 2 本文对c o m m t s c o m + 模型的选择 使用e j b j a v a b e a n s 模型时,e j b 的数量非常多,很难对这些e j b 进行跟踪和管理;如 果开发人员不能正确地使用e j b ,可能导致不恰当的系统设计,使得应用系统的总体性能 下降。而且远程调用方法r m i 完成的功能有限,目前未能得到工业界主流的很好支持【2 ”, 使得分布式通信成为问题。当然如果考虑使用纯j a v a 编程,e j b r m i 是必要的。 c o r b a 和c o m 肌t s c o m + 二者的基本原理相似,都具有可扩展性和健壮性的结构, 都支持用不同的程序设计语言编写的组件,能很好地实现分布式应用。它们之间一直是一 种竞争关系,c o r b a 对象基于1 9 9 1 年颁布的一个标准规范;c o m 规范和代码则是处于 一个不停地变化的过程中( d c o m m t s c o m + ) 【2 8 1 。但是从开发的角度来看,由于微软 极力推崇自己定义的c o m d c o m ,因此在微软所提供的流行开发工具如v i s u a lc + + 、 v i s u a lb a s i c 等,都不支持c o r b a 组件的编程,这对c o r b a 在w i n d o w s 这一最主要的操 作系统平台上的普及造成了很大的障碍。相反,c o m 己经是用户为w i n d o w s 购买的大多 数开发工具的一部分,它是一个全面的体系结构,覆盖从前端到后端到服务器和数据库。 基于c o r b a 的系统需要将o r b 安装到使用此系统的所有p c 机上,而当考虑在整个企业 内部署的复杂度和范围时,可能会出现重大的管理和维护问题。 所以在本文的m p s 系统开发中,为了系统的稳定性,选择了比较成熟、而且广泛使 用的c o m 模型。实体组件的开发是使用的c o m 模型,而数据访问逻辑组件和业务规则 组件的开发使用的是m t s c o m + 模型。 2 3 本文对组件化开发方式的选择 2 3 1 结构化开发方法及其不足 1 ) 概论 结构化方法有狭义和广义的定义,狭义的定义是指在程序设计中不使用g o t o 语句, 仅使用w h i l e 和i f 等控制语句,在设计时采用自顶向下的方法。广义上讲,结构化方法 是指任何包括结构设计的软件开发技术。结构化设计技术可以使程序被分解为不同的模块 9 组件技术在多层分布式系统开发中的研究与应用 和过程,在编写各个模块时不需要了解其它模块的内部细节,从而可采用自顶向下和逐步 求精的方法。逐步求精策略是一个迭代的过程,在每一步迭代的步骤中,待解的大问题被 分解为一些子问题并分别处理,最后所有子问题的解加在一起,通过简单的控制结构而组 成成原始问题的解。因此,结构化方法处理软件复杂性的办法主要是将要解决的问题一步 一步地分解,直到每个小问题都足够简单,并且易于处理1 3 0 】。 2 ) 结构化开发方法的优缺点 结构化的系统开发方法是在批判传统的自发的系统开发方法的基础上,通过很多学者 的不断探索和努力而建立起来的一种系统化方法。这种方法的突出优点是:它强调系统开 发过程的整体性和全局性,强调在燕体优化的前提下来考虑具体的分析设计问题,即所谓 的自顶向下的观点。它严格地区分开发阶段,强调一步一步地严格地进行系统分析与设计, 每一步工作都及时地总结、发现问题,从而避免了开发过程的混乱状态。它是目前被广泛 采用的系统开发方法之一。 但是随着时间的推移,这种开发方法也逐渐露出了很多缺点和不足,它的起点太低, 所使用的工具落后,致使系统开发周期过长而带来了一系列的问题。同时,这种方法要求 系统开发者在早期调查中就需要充分地掌握用户需求、管理状况以及预见可能发生的变 化,不符合人们认识事物的循序渐进的规律性,因此给实际开发带来了困难。同时系统的 扩充、版本的更新和维护的难度也比较大。 2 3 2 面向对象开发方法及其不足 1 ) 概论 面向对象技术是自2 0 世纪8 0 年代以来迅速发展起来的一种软件技术。其中比较著名 的面向对象的分析和设计方法有c o a d y o u r d o n 方法、b o o c h 方法、s h l a e r - - m e l l b r 方法 和j r u m b a u g h 的o m t 方法( o b j e c tm o d e l i n gt e c h n i q u e ) 以及i v a rj a c o b s o n 提出的基于 使用案例( u s e rc a s e ) 的面向对象软件工程方法( o o s e ) 等等 3 1 1 。 面向对象技术用对象描述客观事物,符合人们对现实世界描述的自然规律,使得建模 过程和人们认识客观世界的方法一致。它是利用面向对象的信息建模概念如类、关系、属 性等以及封装、继承、多态等机制来构造、模拟现实系统的方法。对象封装了客观世界中 实体的属性和行为,类是同一类对象公共属性和行为的抽象,因此对象是它所属类的一个 实例。面向对象建模方法提供了从对象、类、类库直至专用系统框架的多层次抽象机制, 能够支持复杂系统层次模型的建立,是研究集成化软件工程的重要工具,适宜于大型系统 模型的建立【32 1 。同时面向对象技术的封装性有助于改善软件的可重用性和灵活性【3 3 。 2 ) 面向对象的不足 面向对象模型比以往的模型有了很大的进步,但仍有不足。对象之间的联系是一种点 对点的直接联系,当系统中对象数目增加时,通讯连接数以平方级激增;为支持通讯,每 个对象实体都要维护一个包含所有对象实体功能的信息库,这部分信息不但重复,而且还 1 0 第二章基于组件的软件开发方法 要保证一致性。这些开销降低了系统的效率,更大的问题还在于对象的接口没有一致的标 准,不同开发商所提供的软件对象不能在同一地址空间里交互协作,更不能跨越线程空间、 网络空间、或者机器结构的边界,造成了向系统中扩充对象时的随意性与不规范性,不利 于系统的维护和对象的复用。 因此,面向对象的软件设计给我们带来的是一个个分离在应用程序中孤立的对象体 【3 4 】。从理论上说,面向对象技术应该支持软件的复用和集成;但实际上,面向对象技术只 能作为一种基础,它需要和新的技术结合起来,共同解决软件开发中的问题。 2 3 3 组件化软件开发方法 1 ) 概论 基于组件的开发方法是在模块化系统、结构化设计和面向对象技术的基础上发展起来 的 3 5 1 。按照它的思想,系统开发中需要将单独的、庞大而复杂的应用程序分成多个模块, 每个模块保持一定的功能独立性,并且还可以将每一个模块继续划分成更小的单元,每一 个这样的单元称为一个组件,它们可以运行于同一台机器上,也可以运行在局域网、广域 网甚至i n t e m e t 上的不同机器上【3 6 1 。一个设计良好的应用系统往往被划分成许多组件,这 些组件可以单独开发,单独编译,甚至单独调试和测试,然后组装为一个完整的应用系统。 因此在基于组件的软件开发( c b s d ) 中,应用系统是由一些标准的组件( 通用的和专 用的) 组装而成,这些组件可以通过商业采购、定制或自主开发获得。具体步骤有: ( 1 ) 以领域体系结构的需求信息为指导进行专项的生产开发,可理解为定制组件。 ( 2 ) 按体系结构的要求购买合适的通用基础组件或业务组件,即为广义的组件开发。 ( 3 ) 从现有的系统或组件库中提取、修改、包装而得到,充分体现了组件的可复用性。 与传统的软件开发方法不同,基于组件的方法重在组件的集成,而不是软件的编程。 虽然在实现中免不了编程的过程,但是c b s d 将编程细节任务从软件系统的开发者转移到 了组件开发者身上。开发人员只需将这些组件组装起来,构成一个应用系统。组件模型( 标 准) 、组件的生产( 创建) 、组件库系统、组件的复用和组装( 集成) 是c b s d 研究的主要 内容。图2 1 给出了基于组件的软件开发过程 7 1 。 图2 1 基于组件的软件开发过程 1 1 组件技术在多层分布式系统开发中的研究与应用 因此该方法是对传统的软件开发模式的一种转变,它使得软件开发从代码开发转移到 对己测试、己使用的、并且在内部互操作的组件的集成。在传统的开发方法中,系统集成 通常是实现工作的结束部分,而在本方法中,组件集成是构造系统的核心内容,在决定获 取、重用甚至构造组件时,可集成性是所需考虑的关键因素。 2 ) 组件化开发方法的优势 由于它的组装开发思想,组件化软件开发方法有以下优点: ( 1 ) 提高开发速度,降低开发成本。由于组件开发商己经编制好了大量的组件模型, 提供许多底层的支持,因此减少了开发的工作量,成本也得到减少。 ( 2 ) 适应业务需求更改,增加应用软件的灵活性口踟。在组件软件中,可以将业务规 则放在少数几个组件中。当业务规则发生改变时,只需修改原组件或重建并发布新组件。 ( 3 ) 有助于并行开发。一个大型的系统由许多组件组成,不同层次的组件的实现可 以由不同的人员负责,因此整个开发过程可以并列进行。 ( 4 ) 降低软件维护费用。由于基于组件的应用软件一般都是通过修改组件来实现, 不需要对软件进行全方位的大规模修改,软件维护费用可大幅度降低。 所以利用组件,可像堆积木似的搭建软件系统,实现软件的大粒度复用,缩短开发周 期,降低维护成本,使软件开发摆脱小作坊的工作模式,按照大规模的工业化方式进行。 2 4 基于u m l 的系统分析与设计方法 2 4 。1 统一建模语言u m l 1 ) u m l 简介 面向对象标准建模语言u m l ( u n i f i e dm o d e l i n gl a n g u a g e ) 是由世界面向对象专家 g r a d yb o o c h 、j a m e sr u m b a u g h 和i v a r j a c o b s o n 于1 9 9 4 年提出的。它集b o o t h 与o o s e 方法和o m t 方法之所长,广泛征求意见,不断完善,于1 9 9 7 年被o m g 批准为标准i j 。 u m l 语言是一种定义良好、易于表达、功能强大且普遍适用的建模语言,融入了软件工程 领域的新思想、新方法和新技术,支持从需求分析开始的软件开发全过程。采用u m l 对 模型进行形式化描述有助于对模型进行合理的抽象、优化以及便于开发人员之间进行交 流。它擅长为并行、分布式系统建模,广泛用于各种应用领域,得到了工业界的普遍支持, 已成为国际软件界广泛认可的标准 4 。 2 ) u m l 组成 u m l 定义了多种图形表示各种模型的不同方面,包括以下几类4 1 】:用例图( u s e r c a s e d i a g r a m ) 、类图( c l a s sd i a g r a m ) 、对象图( o b j e c td i a g r a m ) 、包图( p a c k a g ed i a g r a m ) 、状 态图( s t a t ed i a g r a m ) 、活动图( a c t i v i t yd i a g r a m ) 、顺序图( s e q u e n c ed i a g r a m ) 、协作图 ( c o l l a b o r a t i o nd i a g r a m ) 、组

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论