（计算机软件与理论专业论文）分布式多层架构mis系统设计方法研究.pdf

摘耍 摘要 随着软件系统规模的不断增大，系统架构日益成为影响软件系统性能的重要 因素。系统架构设计的好坏很大程度上决定了一个软件系统的扩展性、可维护性、 执行效能等重要指标。 软件系统架构是关于我们如何把不同的部分放在一起构成整体系统的问题。 一个架构通常由一些规则、建议和习惯组成。它定义了系统的各组成部分是如何 通信和实现互操作的。 目前被广大软件开发人员所接受并在一些大型m 1 s 系统开发中被广泛采用 的是一种层次式的系统模型，也称作多层架构系统。其基本思想是根据系统职能 对系统进行层次架构的划分，不同层次完成不同的职能，以达到层间低耦合、层 内高内聚的设计思想，从而使系统的结构更加合理、有效，易于扩展。 本文将结合作者本人参加的医院综合营养配餐管理系统的开发实例，首先提 出多层架构设计问题，然后从m i s 系统开发的特点以及多层架构系统的基本概 念和相关技术入手，逐渐深入的阐述在m i s 系统开发中进行层次式设计的方法 以及采用组件技术如何实现多层架构系统。最后对于上述实例进行分析，总结在 m i s 系统开发中应用多层结构设计的利弊以及技术经验。 关键词：m i s 、多层架构系统、组件技术、面向对象 a b s t r a c t a b s t r a c t w i t ht h ea g g r a n d i z e m e n ts c a l eo fs o f t w a r es y s t e m ，s y s t e ma r c h i t e c t u r ei s i n c r e a s i n g l yb e c o m e so n eo ft h em o s ti m p o r t a n tf a c t o r st oi n f l u e n c et h ep e r f o r m a n c e o fs o f t w a r e t h ed e s i g nq u a l i t yo ft h es y s t e ma r c h i t e c t u r ec o u l dt oal a r g ee x t e n t a f f e c ts o m ei m p o r t a n ts t a n d a r d ss u c ha se x p a n s i b i l i t y , m a i n t a i n a b i l i t ya n de f f i c i e n c y o f t h es o f t w a r es y s t e m s o f t w a r ea r c h i t e c t u r ei st h ei s s u ea b o u th o wt op u td i f f e r e n tp a r t so fs o f t w a r e t o g e t h e rt oc o n s t i t u t eai n t e g r a t es y s t e m a na r c h i t e c t u r ei su s u a l l ym a d eu po fs o m e r u l e s ，s o m ea d v i c e sa n ds o m eu s a g e sa n di td e f i n e sh o we v e r yp a r t so ft h es o f t w a r e s y s t e mc o m m u n i c a t ea n dm u t u a lo p e r a t ew i t he a c ho t h e r n o w a d a y st h es y s t e ma r c h i t e c t u r et h a th a sb e e na d o p t e db ym o s ts o f t w a r e d e v e l o p e r sa n dw i d e l yu s e di nt h ed e v e l o p m e n to fl a r g em a n a g e m e n ti n f o r m a t i o n s y s t e mi sal a y e r e d a r c h i t e c t u r e ，a l s oc a l l e dm u l t i l a y e r e ds y s t e m t h em a i ni d e ao f t h em u l t i - l a y e r e da r c h i t e c t u r ei st od i v i d et h el a y e r so ft h es o f t w a r es y s t e ma c c o r d i n g t h ed i f f e r e n tf u n c t i o n t h ed i f f e r e n tl a y e ri m p l e m e n t st h ed i f f e r e n tf u n c t i o ni no r d e rt o a c h i e v et h ew e a kc o u p l i n gb e t w e e nd i f f e r e n t l a y e r sa n dh i 曲a g g r e g a t i o ni n s i d el a y e r t h e r e f o r et h es t r u c t u r eo ft h es o f t w a r es y s t e mw i l lb e c o m em o r er e a s o n a b l e ，m o r e e f f e c t i v ea n dm o r ee x p a n s i b l e t h i sp a p e rw i l li l l u s t r a t eap r o j e e te x a m p l ec a l l e dt h eh o s p i t a lm a n a g e m e n t i n f o r m a t i o ns y s t e m f i r s t l y , t h e p a p e rp r o p o s e s t h ed e s i g n p r o b l e mo ft h e m u l t i - l a y e r e ds y s t e m s e c o n d l y ，t h r o u g ht h ei n l r o d u c t i o no ft h ec h a r a c t e r i s t i c so ft h e m i sd e v e l o p m e n ta n dt h er e l a t i v et e c h n o l o g i e so ft h el a y e r e d s y s t e m ，i td i s c u s s e st h e m e t h o do ft h el a y e r e d m i sd e v e l o p m e n ta n dh o wt ou s et h ec o m p o n e n t sw i t h i nt h i s m e t h o d f i n a l l y , t h ep a p e rs u m m a r i z e st h ea d v a n t a g e sa n dd i s a d v a n t a g e so ft h e d e s i g nm e t h o dt h a th a sb e e na p p l i e dt ot h el a y e r e d - s y s t e ma c c o r d i n gt h i sp r o j e c t k e y w o r d s ：m i s ，m u l t i - l a y e r e ds y s t e m ，c o m p o n e n tt e c h n o l o g y ，o b j e c t - 0 r i e n t e d i i 独创性声明 本人声明所呈交的学位论文是本人在导师指导下进行的研究工作和取得的 研究成果，除了文中特别加以标注和致谢之处外，论文中不包含其他人已经发表 或撰写过的研究成果，也不包含为获得墨盗盘堂或其他教育机构的学位或证 书而使用过的材料。与我一同工作的同志对本研究所做的任何贡献均已在论文中 作了明确的说明并表示了谢意。 学位论文作者签名：庇明 签字日期： 口4 年 月，日 学位论文版权使用授权书 本学位论文作者完全了解盘垄盘茎有关保留、使用学位论文的规定。 特授权鑫壅盘堂可以将学位论文的全部或部分内容编入有关数据库进行检 索，并采用影印、缩印或扫描等复制手段保存、汇编以供查阅和借阅。同意学校 向国家有关部门或机构送交论文的复印件和磁盘。 ( 保密的学位论文在解密后适用本授权说明) 学位论文作者签名： 庇明新繇钆纲 签字日期：移争年7 月日 签字日期： d 声年7 月曰 第一章绪论 第一章绪论 管理信息系统( m i s 系统) 在知识经济时代迅猛发展，影响着人们工作生活 的方方面面，是计算机发展的重要方向之一。近年来，随着网络技术特别是 i n t e r n e t 技术的发展，我们经常需要在网络和分布式环境下开发大型信息系统。 管理信息系统( m i s ) 的开发过程中，有很多环节和因素都对其具有熏要的影响， 设计的优劣可能影响到系统的整体性能。其中系统的整体架构设计是最为重要的 因素之一在良好的架构下诞生的系统往往具有优越的性能，如果架构不合理则 会给系统带来各种各样的缺陷。 1 1 信息系统开发中关于系统架构的问题 过去在信息系统开发过程中所采用的传统的两层结构模型暴露出越来越多 的弊端和不适应性，它己经逐渐不能适应当今软件系统开发的需求，具体问题体 现在如下几个方面： 代码冗余。相同的或相似的代码在很多地方重复出现，虽然面向对象技 术能够在一定程度上减轻代码冗余，但却不是根本的解决之道。如果这 些冗余的代码中有b u g ，程序员必须对出现这些代码的地方一处一处的 反复检查，更改，然后一一进行测试。往往会有一些错误被遗漏，给系 统带来隐患。 程序业务逻辑混杂。程序中没有明确的区分开业务流程，界面控制，数 据库操作等，往往在一个函数或者方法中包含上述所说的所有内容。许 多函数因为逻辑混杂，函数体变得异常庞大和混乱，甚至包含数百上千 行代码，造成程序可读性极差。 系统可扩展性较差。由于系统结构的不合理以及比较封闭，往往对系统 进行一点小的更改，如增加一项功能，都要伤筋动骨修改结构，对程序 进行大量的调整，很多的底层逻辑都需要重新实现。进行系统集成则更 加麻烦，为了实现与其他系统的集成，往往要花相当大的功夫来给系统 提炼和设计接口。 第一章绪论 可维护性差。系统的可扩展性差必然也会带来可维护性不好的缺点，系 统由于架构不合理，造成一旦需要修改就必须修改原有结构，系统升级 安装也必然较为繁琐，尤其是大中型系统，这一点表现得更加突出。 以我本人曾亲身参加过的项目为例高校饮食综合物流管理子系统v 3 0 ， 该系统是为高校后勤管理部门量身定做的一个用于库房物流进销存管理的信息 系统软件，该软件总体规模并不算大，功能结构也不算复杂，但是由于初期设计 时就没有考虑软件架构的问题，仍采取了传统的两层结构进行设计，造成后续的 维护量巨大，花在系统后期运营维护和升级管理上的成本不断增长，难以控制。 由于该系统是定制软件，用户的需求经常会有所变化，因此时常需要对系统进行 修改，但由于架构的不合理，每次修改都会觉得比较吃力，不易扩展，而且随着 修改版本不断增加使得原本就不是很好的系统结构更加的零乱，形成一种恶性循 环。另外，由于架构的不合理造成系统升级时的工作量也很大，每次都需要将用 户所有客户端的程序全部卸载重装，随着用户应用靓模的不断增大也越发的感觉 吃力。以上所述种种问题究其缘由，主要是初期的系统体系结构设计不太合理。 1 2 解决思路的提出 那么上述的问题如何解决呢? 近些年，软件体系结构中的层次式结构思想逐 渐被广大的信息系统开发人员所接受，并得到了较为广泛的应用。 所谓层次式架构是指它为我们提供了一种对应用进行划分的方法，基本的思 想是将应用根据逻辑划分成不同的部分，然后单独的考虑并单独的编码实现，每 一部分实现不同的功能，并可能分布在不同的机器，不同的操作系统上。我们通 常以层( 1 a y e r ) 来描述划分的领域，是以称为多层架构。 多层架构系统相对于传统的两层结构系统有很多优势： 将系统的逻辑和功能划分到不同的层来实现，实际上是对问题域进行分 解，简化了理解和组织开发复杂系统的工作，提高了系统的可测性。 由于层之间的低耦合，层内的高内聚，在层接口不变的前提下，该层的 实现可以更改、替换。实现类似硬件“可拔插”的设计，解决方案的维 护和增强变得更容易。 第一章绪论 在系统中能够重用各个层所公开的功能，同一层的提供的接口可以在上 层中不同的地方调用，从而减少了不必要的冗余。 充分体现了软件集成的思想。我们不仅要设计和开发一些组件，同时可 以大量使用已经进入市场的组件产品，或者使用以前积累下来的组件库 中的组件，从根本上缩短了系统开发的周期。 使得系统易维护性大大提高。由于结构层次的清晰，使得模块、组件之 间的关系不再那么紧密，进行功能扩展和升级时可以将修改对于系统整 体的影响降到最低，因此升级工作通常不再像过去传统架构那样伤筋动 骨，可能只需要对于个别模块或者组件进行升级即可，从而使得系统维 护成本大大降低，可维护性大大提高。 正是由于这些优势使得多层架构思想的应用越来越广泛，本文就将结合我本 人的项目开发实例讨论关于在管理信息系统开发中应用多层结构思想的方法及 其实现技术。 1 3 论文组织结构 本文首先提出为什么要在s 系统开发中应用多层结构设计思想；然后逐次 介绍m i s 系统概论、多层结构系统概论以及多层结构系统设计的实现手段 组件技术等相关基本理论；再次，结合本人在医院综合营养配餐系统实际项目中 的应用阐述在实践开发中应用多层架构思想进行管理信息系统设计及实现的整 个过程；最后对于在m 【s 系统开发中应用多层结构设计思想的得失与利弊进行 总结。 第二章管理信息系统( 8 i s ) 概述 第二章管理信息系统( m i s ) 概论 本章中将就管理信息系统的一些基本概念和特点进行概要介绍。 2 1 m i s 系统基本概念 m i s ( m a n a g e m e n ti n f o r m a d o ns y s t e m 中文名称为管理信息系统) 作为一门 管理学、计算机科学、数学和系统科学等学科交叉组成的边缘学科是一门不断发 展的新型学科。由于m i s 涉及的内容在不断的扩大，所以很难准确给其下一个 定义。我们可以简单地把m i s 理解为在管理工作中以数据为核心的计算机应用。 2 2 m i s 系统作用 m i s 系统在当今的知识经济社会发展的大背景下呈现出高速发展的态势，并 且在实践应用中逐渐发挥出越来越大的作用，已经为广大企事业单位所接受并大 量使用，其主要作用如下： 1 辅助分析。对于企业的生产经营活动进行决策，需要各种生产经营数据作为 依据。通过计算机系统将数据组织起来，可以随时提供各种所需的数据。它 能保证决策的准确、及时。 2 规范化管理。企业中的许多数据管理并不像财务管理那样，有一个严格的制 度，常常带有较大的随意性，数据采集的时间、格式、计算方式等往往是根 据经验和记在脑子里的公式完成的，而且又不便于审核，容易引起混乱、错 误。计算机系统为数据处理提供明确的尺度，使之标准化、规范化。 3 节省人力。不仅大量的重复计算由计算机处理，可以减轻人的劳动强度，更 重要的是，在输入数据以后，所有的处理都由计算机系统来完成，可以免去 人工方式下许多中间的处理环节，达到减员的效果。 2 3 m i s 系统的开发 2 3 1 m i s 系统开发的特点和难点 m i s 的开发具有所有软件系统的一些共性，同时也存在以下一些特点： 4 第二章管理信息系统( m i s ) 概述 以数据为中心。“数据中心原理”是说，只要企业的性质和目标不变，它 的数据类就是稳定的，任何经营管理的瞬间，都是对这些数据类的数据 输入( 记录的增加、修改或删除) 和数据输出( 记录的检索或使用) ，信 息系统的开发应该面向数据，而不应该面向处理过程，因为处理过程是 多变的。 指导管理过程规范化。一个企业或部门在没有m i s 系统时的管理方式是 适应人的工作特点逐步形成的。这些方式是分散的、不规范的，而且一 般运作时间很长。而计算机系统适合处理大批量的、规范的数据，要求 处理的过程尽量简单。所蚍具备计算机系统特点的m i s 不仅提供了规范 数据的处理功能，同时也使工作方式变得简单、规范。 信息化建设的可持续性。一个企业的信息化建设要经历一个较长的时间， 在这段时间内，不断地开发功能单一的面向单独部门的m i s 。通过新老 系统的不断集成，最终完成整个企业的信息化建设。所以，企业的信息 化建设是一个持续发展的漫长过程。 系统开发的初期难以完全确立准确的目标和内容。由于企业在信息化建 设的初期没有这方面的经验，所以多数m i s 在开发的初期没有完全确立 的目标和内容。经过前期企业用户和开发人员的共同探索，系统的目标 和内容会逐步确定下来。 m i s 的这些特点同时也是它在开发上的难点： 建立系统的运行机制。m i s 建设是要用计算机系统把人工下的数据处理 控制起来。它涉及到计算机技术和管理工作两个方面。计算机技术的进 步只是解决了一个方面的问题。如果实际的管理过程比较规范，比如图 书馆系统，系统建设主要是程序开发的问题，这样的系统是比较容易成 功的。但m i s 建设大多涉及的是不够规范的管理工作，系统建设要对原 有的工作方式进行规范和整理，否则，m i s 不仅不能发挥应有的作用， 丽且由于系统结构的零乱，常常难以运行下去。 了解实际的数据流程及业务逻辑。企业的业务通常也是较为复杂的，并 有较大的变动可能性，这一部分的分析和规整工作也是m i s 开发的难点 之。 第二章管理信息系统( m i s ) 概述 控制开发过程。m i s 建设需要用户和开发人员一起来解决大量与实际业 务相关的问题。在开发期间，应该分出开发工作的轻重缓急，合理地配 置资源，把众多的人员协调一致，确保开发出的系统结构合理、功能实 用，这是m i s 开发的目的。事实上，这很难做到。我们常常见到的是开 发者在经过和用户简单的讨论之后就撇开用户，希望先开发出来再说； 或者，用户认为开发任务完全是开发方的责任，在整个开发期间不给予 积极的配合。在这种失控的状态下进行开发进本上很难达到m i s 的开 发目的。 此外，还有选择开发目标、与其他系统集成等其它方面的困难。 2 3 2 解决方法 虽然m i s 的开发涉及到管理、计算机科学技术等很多方面的问题，但本文着 重从软件系统架构的角度来考虑解决这些问题，其他角度的解决方法不在本文讨 论的范围内，不再详述。 前面已经简单提过，软件系统的体系结构很大程度上决定了其很多重要特 性，如：可扩展性、易维护性、运行效能等。正是由于m i s 系统在开发的过程 中存在上述的难点，因此设计一个优良的体系结构显得尤为重要。好的体系结构 可以为m i s 系统的开发和升级、维护工作带来极大的便利，极大的降低开发成 本。 层次式的软件体系结构是如今m i s 系统开发中被大家应用的很广的一种系 统架构设计方法，其层间低耦合、层内高内聚的特点使得系统的可扩展性、易维 护性都大大提高，特别是应用在相对大中型的系统开发中效果更为明显。由于 m i s 系统日益增长的整体复杂度，造成了系统开发过程中各个环节的复杂度和开 发成本都在增加，从数据分析、业务分析、流程分析到系统建模，其间都充满了 不确定性。多层架构的应用对于有效控制开发成本和提高开发成功率都有着重要 的作用。 6 第三章分布式多层结构系统 第三章分布式多层结构系统 本章介绍多层结构系统的相关概念以及基本分层思想。首先是软 牛开发体系 结构的演变过程回顾；然后重点说明多层体系结构的层次式模型。 3 1 软件开发结构的演变过程 首先我们需要明确的是应用程序的含义，所谓应用程序通常包含三个部分： 展示层( 或称之为用户界面层) 、商业逻辑层与数据库层。展示层( 用户界面层) 指的是应用程序呈现给用户的人机操作界面( u s e ri n t e r f a e e ) ，用户接口愈亲切 的软件通常越容易受到欢迎，这也就是为何当图形界面的操作系统推出后，在短 短的时间之内就大受欢迎并席卷全球。商业逻辑层主要是指用户完成业务所需要 遵守韵一些业务规则，如：某商店的购物顾客中非为两类，刷卡的顾客需要多负 担5 的费用，这就是一种商业规则，应用程序中进行计算和处理时必须忠实的 按照用户设定的方式进行工作。当商业规则运算完毕后，便将实际数据写入后台 的数据库中，以便记录和提供给今后的统计分析使用，这一段则属于刚才上面提 到的数据库层。 在软件开发结构过去的发展历程中，根据对以上所述这几层的处理方法和模 式的不同，应用信息系统的体系结构经过了几代的发展和变革。 3 1 1 大型主机终端结构 在过去的大型主机时代，应用程序所有的商业逻辑与运算均集中在后端主机 完成，前端部署的终端机只是一个显示屏，完全没有运算能力，用户只是通过终 端机输入或查询数据而已。此种模式对后端主机在性能上的要求很高，因此硬件 成本也不断提高。因此在大型主机时代，绝大多数的中小企业由于成本问题无法 应用信息系统作为辅助手段提高管理水平。这种状况随着p c 时代的来临而有所 改观，p c 低廉的价格和越来越高的综合性能使得企业的信息化水平提高成为可 能。 第三章分布式多层结构系统 3 1 2 桌面型单机应用程序 随着p c 的出现和普及，软件的开发慢慢形成了另一种新模式。在桌面型单 机应用程序时代，用户界面层、商业逻辑层、数据库层全部绑在一台p c 上处理。 这种应用程序的特点是结构简单，开发快速，缺点是只允许单人存取，很难应用 于网络环境，不利于进行大规模应用软件的开发。随着企业商业逻辑的复杂程度 越来越高，对于应用系统提出的要求也越来越高，这种单机的桌面系统很快便不 能满足企业日益增长的业务需要。 3 1 3 客户机，服务器结构应用系统 为了解决单机系统日益暴露出来的不足和缺陷，开发人员又提出了一种客户 机j j l i t 务器( c l i e n t s e r v e r ) 模式的应用系统结构，其最大的特色在于将应用程序 的数据层与展示层分离，数据放在后端的数据库服务器中，前端p c 负责数据的 展现接口。这种结构的优点在于：真正达到了数据共享的目的；后端数据库和前 端p c 都具有计算能力，可采用有效的分工合作模式。但此种客户机服务器模式 仍有很多不能很好解决的问题，如：商业逻辑层的位置问题，如果将商业逻辑层 放在服务器端，和数据库绑定在一起，则数据库平台的迁移和改变将会造成商业 逻辑层的重新开发；而将商业逻辑层放在客户端则意味着任何的商业逻辑修改都 必须更换所有的客户前端程序。这种结构对于系统可扩展性和易维护性的制约又 促成了新的应用程序结构的诞生。 3 1 4 分布式多层应用程序结构 为了解决客户机朋匣务器模式带来的问题，软件设计人员开始对原有应用系统 结构进行下一代的改进，即我们现在讨论的分布式多层应用程序结构。这种结构 的最大特点就是将用户界面层、商业逻辑层、数据层层次分明的彻底剥离，使每 一层都独立出来，因此也经常被称为3 层结构或n 层结构( 3 t i e r 或者n t i e r ) 。 由于其将各层彻底分离，因此在使得应用系统的可扩展性和为易维护性等方 面都大大提高，各层内部的修改对其他层的影响降到了最低，特别适用于一些大 第三章分布式多层结构系统 中型软件的开发。 3 。2 。分层基本思想 如上一节回顾软件体系开发结构演变过程中提高到层次概念，运用可分离性 原则，我们把应用划分成领域。领域是一个独立可标识的范围，代表着一部分系 统的功能或逻辑，可以单独的考虑并单独编码实现。 其实，分层的基本思想由来已久，我们熟知的t c p i p 的七层协议就是典型 的分层概念，通过分层对数据报进行层层封装，每一层各司其职，使每一层内部 的实现变得尽可能简单，最终实现在不同层次上解决不同的问题，使复杂的问题 变得简单化。 通常情况下，我们按照上述三层的概念认为应用系统包含了以下三个核心领 域： 表示逻辑，负责用户界面和外部接口逻辑。 业务逻辑，负责核心的商业规则及业务逻辑。 数据访问逻辑，负责读取和更新存储器中的数据。 将整个系统的逻辑分解到不同的领域中去的理由是这样更易于复用。事实 上，用户需求总是在不断变化的，但通常情况下不会整个系统都改变，变化的只 是系统的一部分功能或一部分逻辑。将表示逻辑，业务逻辑和数据访问逻辑分离， 能够将变化局域化在某一领域，降低部分修改对系统整体的影响，从而有助于提 高系统的可扩展性和可维护性。 9 第三章分布式多层结构系统 3 3 典型的三层结构模型 图3 - 1 典型三层结构模型 上图是典型三层结构模型，如图所示，模型将分层体系结构建立在三层基础 上：表示层、业务层和数据层。此模式概述了每一层的职责以及组成每一层的组 件。 三层架构是最常见的层次架构，下面分别介绍一下这三层。 3 3 1 表示层 表示层，顾名思义是主要负责向外界展示用的层次，即系统的用户交互接口， 表示层主要负责以下功能： 提供给用户的操作接口。 处理信息的显示，例如：提供某些窗体让用户链浏览信息。 处理用户界面事件，这些事件将触发业务逻辑层中的处理流程。 管理其它与外部系统之间的数据进出接口，例如：数据读入和产生法定 1 0 第三章分布式多层结构系统 的数据输出。 处理报表生成及批处理文件。 表示层的价值在于，它把业务逻辑和外界刺激产生的方式隔离开来。到达业 务逻辑层的请求应该看起来都样，不论它是来自操作员通过用户界面的输入， 还是由一封电子邮件，一次b 2 b 的通信，或是其它事件所触发。表示层的另一 个价值在于，它是客户唯一可以看到的应用程序部分。它从使用的角度出发，考 虑是客户的兴趣和利益；而业务逻辑从系统的功能出发，考虑的是企业的兴趣和 利益。它负责为与应用程序的交互提供任何形式的帮助，包括保持一些信息，如 用户偏好设置等。 3 3 2 业务逻辑层 业务逻辑层包含了核心业务规则相关的逻辑，这些逻辑表达了最终用户对系 统真正关心的东西。它负责确保行业规则被执行。如果个账户不允许负债，业 务逻辑必须确保这种情况不会发生。业务逻辑负责确保公司的业务数据的完整 性，一致性，只有允许的更新才能执行。 业务逻辑层还负责处理业务过程，某些业务对操作顺序有严格的要求。例如， 在一个办公自动化系统中，公文的流转就必须遵循一定的操作时序，首先到有关 部门审核，然后部门经理审核，然后由公司总经理审核通过，最后公文才能下达， 在整个过程中必须保证执行的先后顺序不能错，业务逻辑负责确保这一系列流程 的正确执行。 企业应用是围绕业务逻辑来开展的，因此业务逻辑层反映了系统的功能，是 一个应用系统架构的核心。 3 3 3 数据访问层 数据访问层主要负责如下工作： 实现对于数据的各种操作，如读取、写入、修改等。 第三章分布式多层结构系统 保证数据的正确性和一致性。 提供统一的数据访问借口，隔离业务逻辑，屏蔽数据结构对于上层的影 响。 该层最大的功能就是存储持久数据，实现业务逻辑层中数据逻辑视图与数据 存储的实际物理格式之间的转换，完成数据读写。 3 4 其他层次模型 上述的三层架构系统是分布式多层架构系统中最为简单的一种，它只是最粗 略的将表示层、业务逻辑层和数据访问层分开。其实对于更为复杂的应用还可以 将这三层分别进行细分，演变成更多的子层，从而使复杂系统的架构变得更为清 晰。例如j 2 e e 架构模型提出了自己的n - t i e r s 结构，这个架构模型主要针对j 2 e e 构建的分布式系统，将系统分为五层，它们是客户层( c l i e n t ) ，表示层 ( p r e s e n t a t i o n ) ，业务层( b u s i n e s s ) ，整合层( i n t e g r a t i o n ) ，资源层( r e s o u r c e ) 。 对于多层结构的划分还有很多其他的方法，这里不再一一列举，由于没有统 一的标准，应用系统开发者们通常都可以按照自己的理解去划分自己的多层系统 架构，但无论如何变化，都是从典型三层结构模型中衍生出来的细分，那些内容 不是本文讨论的重点，不再赘述。 3 5 本章小结 本章我们提及了分布式多层架构系统的演变由来以及分层架构的一些基本 思想和典型三层结构模型，并提到在分层架构中运用组件技术，下一章将就多层 架构的主要实现技术组件技术进行讨论。 1 2 第四章组件技术 第四章组件技术 前面阐述了多层架构系统的设计思想，但无论多好的设计思想如果没有好的 技术手段来支撑其可实现性都是纸上谈兵，没有实用价值。那么多层架构系统的 技术实现手段是什么呢? 组件技术就是多层结构设计思想最好的实现技术，本章 将主要讨论多层结构系统的实现技术组件技术。首先介绍组件的基本概念、 主要特征，然后介绍典型的组件模型以及使用组件技术的优点。 4 。1 。组件概念与特征 组件技术思想源于传统的软件模块概念和子程序库，它们的本质都是对问题 进行细分。以后，其原形中还出现了抽象数据类型以及在此基础上诞生的面向对 象开发思想。但是，组件技术超越了以上所有这些软件开发概念，采用组件技术 开发大规模的系统速度快两成本也得到大大降低。 4 1 1 组件的概念 到目前为止，我们还很难确定组件技术的明确定义。在日常用语中，组件可 以理解为一个部分或一种元件，它与其它一些组件共同组成一个整体。通常组件 是一个清楚可以分离的东西，在装配中它也不会完全辨识不出来，如果整体可以 拆卸的话，它可以被恢复成原来的样子。就像发动机可视为汽车的一个组件。我 们所说的“组件”，一词与日常用语相比，有着更为严格和明确的特殊含义。 k a t h a r i n ew h i t e h e a d 在她的作品基于组件开发中提出了c b d ( c o m p o n e n t - b a s e dd e v e l o p m e n t ) 的概念，c b d 的目标是改进软件开发的过 程，通过开发或使用一些软件组件来搭建软件系统。这是一种有可能解决“软件 危机”的方法。作者对组件给出了如下定义：组件是可执行软件的一个可分离的 部分，在某种环境支持下，可以与其它组件实现互操作，在进行了必要的安装和 配置之后，可以通过它所提供接口来访问它。 这个定义比较完整的描述了什么是组件，接下来我们要介绍一下组件的一些 基本特征。 第四章组件技术 4 1 2 组件的基本特征 组件是黑盒的，只能通过接口访问 组件的一个重要特性就是它是一个“黑盒”。它的内部结构对外部应用程序 来说是不可见的，外部应用程序只能通过接口来调用组件。接口是一组逻辑上相 关的函数集合，其函数也称为接口成员函数。组件通过接口成员函数为客户提供 各种形式的服务。如下图所示： 组件的可分离性 图4 - 1 组件示意图 定义组件的一个重要原则就是可分离性( s e p a r a b i l i t y ) 。可分离性是指组件 是上下文无关的，即一个组件能够从目前的上下文环境中分离出来，并在另一个 上下文环境中使用它。只有满足可分离性，才能真正实现组件在功能级的复用。 而复用使我们设计组件的主要目的之一。 4 2 。典型组件模型 组件模型的功能提供了定义接口的标准方法，而且它们还为组件提供运行时 刻支持。目前应用较为广泛的组件模型有如下几种：c o m ，c o r b a 和e j b ，不 同的组件模型提供的组件环境不同，下面分别简单介绍一下这几种主流的组件模 型。 4 2 1 c o m c o m 是组件对象模型的简称( c o m p o n e n to b j e c tm o d e l ) 。它是m i c r o s o f t 1 4 第四章组件技术 公司推出的一种组件模型。c o m 诞生于1 9 9 3 年，m i c r o s o f t 公司在o l e 2 ( o b j e c t l i n k i n ga n de m b e d d i n g ，对象链接与嵌入) 中第一次应用并提出c o m 。o l e 技 术以c o m 规范为基础，充分发挥了c o m 的优势，使w i n d o w s 操作系统上的应 用程序具有极强的可交互性。 d c o m ( d i s t r i b u t ec o m ) 是c o m 的扩展，它可以支持不同计算机上组件 对象与客户程序之间或组件对象之间的相互通信。d c o m 完全继承了c o m 的优 势，针对分布式环境也提供了一些新的特性，如位置透明，网络安全性等。 d c o m 进一步发展成为c o m + ，它把c o m 和微软的m t s ( m i c r o s o f t t r a n s a c t i o ns e r v e r ) 结合起来，同时增加了一些新特性。它们的关系如图所示： 图4 1 2c o m + 组成结构图 从c o m 的发展角度来看，c o m 最初作为桌面操作系统平台的组件技术， 随着d c o m 的发展，c o m 通过底层的远程支持技术使组件技术延伸到了分布式 应用领域。m t s 为c o m 添加服务器端组件管理和配置环境，c o m + 进步把三 者统一起来，形成真正适合企业应用的组件技术。如不需特别区分，我们一般统 称c o m ，d c o m 和c o m + 为c o m 技术。 由于c o m 是m i c r o s o f t 公司推出的标准，它与w i n d o w s 操作系统的结合很 紧密，如：c o m 组件的名字和配置信息都写入w i n d o w s 操作系统的注册表中。 尽管c o m 可以运行在某些非m i c r o s o f t 的平台上，如某些u n i x 系统，但是它只 是w i n d o w s 平台上广泛采用的组件模型。 第四章组件技术 c o r b a 是通用对象请求代理体系结构的简称( c o m m o no b j e c tr e q u e s t b r e a k e ra r c h i t e c t u r e ) ，是由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 是一个面向对象的分布式计算平台，它允许不同 的程序之间可以透明的进行互操作，而不用关心对方位于何地、由谁来设计、运 行于何种软硬件平台以及用和种语言实现等。c o r b a 类似于前面提到的 d c o m ，主要是解决远程对象之间的互操作问题，但它们的体系结构并不相同， c o r b a 体系结构的核心是对象请求代理o r b 。 c o r b a 模型是平台和语言无关的。它是真正跨平台的组件模型，可以运行 在任何对象请求代理o r b 产品能运行的平台上。c o r b a 的特性使它具备了构 建大型跨平台分布式应用的能力。 4 23j a v a b e a n 和e j b j a v a b e a n 规范将组件的概念引入到j a v a 编程领域。j a v a b e a n 的任务是实现 “w r i t eo n c e ，n ma n y w h e r e ，r e u s ee v e r y w h e r e ”，即一次性编写，任何地方执行， 任何地方重用。b e a n 本身是一些j a v a 类，可在一个可视的构建器工具中操作它 们，并且可以将他们一起编写到应用程序中。 e j b 是用于开发和部署分布式的，面向对象的j a v a 应用系统的跨平台体系 结构。与j a v a b e a n 相比e j b 是一种非可视化的组件，完全位于服务器端。e j b 和远程客户端程序通讯，并提供一定功能。 e j b 的重点是提供服务框架模型，通过e j b 服务器( e j bs e r v e r ) 和e j b 容器 ( e mc o n t a i n e r ) 来实现。其中，e j b 服务器的功能是管理e j b 容器；提供对操作 系统有关的底层细节，诸如和其它组件或系统的通讯协议，多线程，负载平衡等。 e j b 具有诸多优势，大大降低了应用开发的复杂性。它已经成为构建企业级 应用的主要工具，被广泛的应用在各个平台，各个领域。 第四章组件技术 4 2 4 几种组件模型的比较及选择 上面介绍了三种组件模型，它们各有优势，适应于不同领域。在实际开发中， 我们应当根据具体的情况来选择合适的组件模型。从运行效率方面将，c o m 是 一种二进制标准，相比较其他两种模型有相当的优势；从跨平台的角度讲，c o m 只能应用于w m d o w s 平台下，c o r b a 和e i b 则是跨平台的，能运行在当前绝 大多数的操作系统上。 本文讨论的医院综合营养配餐管理系统是运行在w i n d o w s 平台下的管理信 息系统，没有跨平台的要求，且效率有一定的要求，因此我们选用了c o m 组件 模型。 4 3 组件技术的优点 应用组件技术能够为应用程序的开发带来很多好处，如： 组件易替换。 “唯一不变的就是变化”，软件系统更是如此，因此软件开发人员总是在想 尽办法来控制由于软件改变带来的各种问题和开销，组件技术的一大优势就是能 够使得改变的影确交得尽可能小，维护尽可能容易。在没有组件技术豹时代，软 件的任何修改都意味着应用程序需要经过重新编译并逐台安装到用户的计算机 上。利用组件技术则不必再去更新整个应用程序，只要重建一个组件并发布即可。 组件适合于改变业务需求。 用户的需求是在不断变化中的，因此我们开发的应用程序也要不断更新和改 变。由于组件易于替换，可将易变的业务规则封装在组件中，以此来应对不断变 换的业务。 组件可有效地提高复用性。 组件由于其本身的特性可以实现一次编写多处应用，并使得软件的复用级别 从过去的源代码复用变成二进制码级的复用，有效提高开发效率。 第四章组件技术 4 4 本章小结 本章就组件技术进行了些简单的介绍，主要包括组件的基本概念、特征， 几种典型的组件模型以及使用组件技术的优点。正是由于组件的这些特点和优 点，使它成为能够有效解决软件体系结构问题的技术手段，下一章将就组件技术 对分布式多层架构系统的支持进行讨论。 1 r 第五章组件技术对分布式多层架构系统的支持 第五章组件技术对分布式多层架构系统的支持 上一章中对于组件技术的一些相关问题进行了阐述，本章主要就组件技术是 如何支持分布式多层架构系统开发的问题进行简要论述。 5 1 在分布式多层架构系统中应用组件技术 前面的讨论中已经提过，多层架构系统的实现通常以组件的形式构造架构领 域，组件的特点决定了它能够胜任这样的工作，也可以说组件的设计初衷就是为 了解决软件体系结构的问题。 最常用的方法是定义一个分层的架构。将不同的领域划分为不同的层。分层 架构的基本原则是处在相同层的组件都作为下一层组件的客户程序，对下层组件 来说，它们所扮演的角色相似。如图所示： 图5 1 三层架构组件关系示意图 请求发出是单向的，这有助于减少组件之间的依赖关系。因此，尽管一个表 示层的组件要求它用到的业务逻辑层必须存在，但是业务逻辑层组件并不会要求 任何表示层组件必须存在。如此以来，业务逻辑层组件就可以用在不同的上下文 中，与不同的表示层组件共存。类似的，业务逻辑组件要求提供特定接口的数据 访问组件必须存在，但数据访问组件不需要知道任何逻辑组件的知识。使用分层 为我们提供了简单的控制依赖性的方法，确保在一层中的组件都不会对调用它的 客户程序产生依赖。 应用组件技术来实现分层架构必须考虑的一个问题是：组件是否可以穿越一 个层次，直接与更底层的组件交互? 如果一层中的组件可以直接和非相邻层中的 第五章组件技术对分布式多层架构系统的支持 组件交互，这个架构就称为开放的；如果只能与相邻层的组件交互，则称为封闭 的。封闭的架构更为简单，但是不够灵活，可能导致一个层中的组件除了把调用 直接传给下一层之外什么事也不做，导致执行效率的降低。一个系统的架构设计 可以制定一个自己的方案，说明哪些情况下是可以跨层调用的，哪些是不允许的， 让设计人员根据具体情况采用具体的策略，这样能够带来一些效率的提高灵活 性，不过如果要保证设计的规范性和完整性，坚持封闭性也非不可。 5 2 w i n d o w s 平台下多层架构系统的支持技术 上一章中介绍过三种最典型的组件对象模型，这三种模型各有短长，分别适 用于不同的环境，本文讨论的m i s 系统开发选用的是w i n d o w s 平台，因此选择 的组件模型自然是微软定义的c o m ，本节将重点讨论c o m 及其相关技术，以 及它们对于多层架构系统开发的支持。 5 2 1 微软的组件对象模型c o m 微软的三层式结构中的业务层和数据层的基本程序单元是组件。组件是建立 在组件对象模型c o m 基础之上。在w i n d o w s 操作平台上，它以d l l 动态链接库或e x e 可执行程序的形式封装。组件由c o m 类( 或对象) 构成，每个c o m 类包含个或多个 接口，而每一个c o m 接口又包含一组相互关联的属性和方法，将属性和方法进行 分组是组件对象的一个重要特色。 组件中最为重要的概念是接口，接口代表组件调用者与组件实现者之间的一 种契约，是双方进行通讯的基础。客户只有通过组件暴露出来的接口，才能与该 组件相连。因此，为了使用一个组