（计算机应用技术专业论文）构件式开发平台的设计与实现.pdf

硕士学位论文 i 摘 要 摘 要 随着软件技术的飞速进步，软件工程学也逐渐得到一系列的关注和研究。从 软件工程学诞生的那天开始，软件工程学经历了许多具有里程碑意义的阶段，最 早的是一种传统的软件工程模式，该模式将软件的设计提升到工程级的高度。然 后，人们根据软件技术基于算法的发展方向提出了适合基于算法设计的线性模 型。随后，人们逐渐认识到客户需求的重要性，由此提出了与客户互动性较高的 原型实现模型和螺旋模型。如今，基于构件的软件开发技术极大地提高了软件的 生产效率，这也使得基于构件的软件工程方法学得到了广泛的专注。 阐述了传统的软件工程各个模型的优势以及其不足的地方，介绍了基于构件 的软件工程的特点，并将传统的软件工程与基于构件的软件工程进行比较，最后 表明了构件式的软件工程是软件工程学发展的重要方向，与此同时，本文还介绍 了构件式软件工程的设计过程、设计方法以及一些重要的设计工具等等。 研究了经典的 mvc 模式，并在此基础上进行了改造，运用 mvc 模式加上 command 模式对构件式开发平台进行设计，在设计的过程中提出了三个世界的 构想，使得整个平台层次分明。基于此平台上开发出的产品，从仿生学的角度看 就像一个蜂房的结构，由一个个功能不同结构相似的构件构成，这样的结构使得 在此平台上开发出来的产品具有很好的规范性和可装配性。 设计并实现了构件式开发平台， 并通过 erp 产品中的一个小工具对此平台进 行了可行性验证，介绍了构件的设计过程以及配置用例的设计过程，然后利用平 台引擎将设计好的构件和配置用例进行整合使之成为可发布的产品。 此应用实例 的介绍不但验证了此平台的可行性， 而且充分展现了基于此平台开发的产品的易 维护性和易装配性。 关键词：构件；软件复用；蜂房结构；领域分析；关键词：构件；软件复用；蜂房结构；领域分析；mvc；erp；dao 构件式开发平台的设计与实现 ii abstract the development of software technology is through several phases, from program design based on algorithms to structured software development, from object oriented programming software development which is prevalent recently to software development based on component technologies. the development of software technologies brings the software engineering to the world and it develops continuously with the development of software technologies. the development of software technology is also through several phases, from traditional software engineering to recent object oriented software engineering and software engineering based on component technologies. this thesis introduces the characteristics of software engineering based on components and analyzes the advantages and disadvantages of each models of traditional software engineering. it also compares the software engineering based on components with the traditional software engineering and proves that the software engineering based on components is the trend of software engineering development. finally, it introduces the process, methods and tools of software engineering based on components in brief. the thesis researches the classic mvc pattern and reconstruct on this pattern. it applies command pattern to the mvc pattern in the design of component developing platform and introduces the concept of “three worlds” in the process of design that makes the levels of whole platform clear. the products that develop from this platform seem as a honeycomb in the perspective of bionics, since they are composed by many components which are different in function but similar in structure. the products in this structure are excellent in normalization and friendly assemblage. this thesis designs and implements component developing platform and validate the feasibility of this platform through a small tool in an erp product. it introduces the process of component design and the process of configuration examples design, then it composes the designed components and configuration examples using platform engine, which makes the whole a releasable product. the introduction of this application example not only validates the feasibility of this platform, but also exhibits the friendly maintainability and assemblage of the products which developed from this platform sufficiently. 硕士学位论文 iii key words：component；software reuse；honeycomb structure；domain analysis；mvc；erp；dao 中南民族大学中南民族大学 学位论文原创性声明学位论文原创性声明 本人郑重声明：所呈交的论文是本人在导师的指导下独立进行研究所 取得的研究成果。除了文中特别加以标注引用的内容外，本论文不包含任 何其他个人或集体已经发表或撰写的成果作品。对本文的研究做出重要贡 献的个人和集体，均已在文中以明确方式标明。本人完全意识到本声明的 法律后果由本人承担。 作者签名： 日期： 年 月 日 学位论文版权使用授权书学位论文版权使用授权书 本学位论文作者完全了解学校有关保留、使用学位论文的规定，同意 学校保留并向国家有关部门或机构送交论文的复印件和电子版，允许论文 被查阅和借阅。本人授权中南民族大学可以将本学位论文的全部或部分内 容编入有关数据库进行检索，可以采用影印、缩印或扫描等复制手段保存 和汇编本学位论文。 本学位论文属于 1、保密，在_年解密后适用本授权书。 2、不保密。 （请在以上相应方框内打“” ） 作者签名： 日期： 年 月 日 导师签名： 日期： 年 月 日 硕士学位论文 -1- 第1章第1章 绪 论 绪 论 1.11.1 本研究课题的学术背景 本研究课题的学术背景 .1 构件技术的发展 构件技术的发展 软件技术是软件工程的主要研究内容之一， 从公元二十世纪五十年代到现在 软件开发技术的发展经历了许多阶段， 从早期的基于算法的开发技术到结构化的 开发技术以及后来的面向对象开发技术，到目前的构件技术等1。在公元二十世 纪九十年代初期， 美国的微软公司开发的 vb 软件开发平台对整个软件世界产生 了极大的影响。 因为使用微软公司所提供的此开发平台的工程师能够方便的使用 系统的 dll（dynamic link libraries） ，而这种调用系统的 dll 的方式就是构件 式开发的前期表现形式。然而，随着软件开发工具逐渐发展到今天，各式各样的 可视化开发工具不断发展， 工程师可以使用极少的编码就能通过对现有的功能模 块进行重组最终快速地达成各个系统的应用需求。与此同时，这些已有的功能模 块也越来越标准， 接口越来越统一， 从而使得开发软件变得和搭积木一样容易了。 这些开发工具中包含的“积木”就相当于软件系统的构件2。这种软件复用技术 极大地简化了应用软件的开发过程，它不但能降低软件开发过程中的开支，还使 得软件生产工业化。构件技术的提出还极大地提高了软件的开发效率，减短了软 件的开发周期，并且在软件的复用开发过程中，没有任何资源的消耗。相反，构 件在多次复用后，经过了不断的修改及完善，其构件的质量也越来越高，可靠性 也越来越强。 从多年的发展可以看出，软件开发技术一直都未能跟上实际需求增长的脚 步。尤其是随着计算机硬件技术的进步以及信息化建设需求的增加，当越来越多 的大型软件项目开发工程被摆在台前时，开发周期长、超出预算、软件可靠性和 可维护性差等问题也逐渐凸显出来，形成了尖锐的矛盾，甚至因此引发了“软件 危机” 。于是，软件业开始模仿制造业的开发模式，希望采用标准零部件的重组 的方式来开发软件。这种开发模式能够极大地提高软件的开发效率，因为零件的 标准化，制造产品的过程变得非常简易和快速。因此，解决“软件危机”这个瓶 颈的方法出现了，即软件复用。在结构化的软件开发过程中，其复用性是由函数 参数来适应不同应用的差异，然后通过函数和模块的复用最终达到软件的复用。 但是，可以看出，这种结构化软件的复用会导致系统结构不清晰，整体的效率也 会降低，因为函数的复用力很有限。然而，面向对象技术的提出，则很好的解决 了这个问题。面向对象技术提出了“类”这个概念，借由“类”的封装，继承， 构件式开发平台的设计与实现 -2- 应用等特性，面向对象的开发思想可以真正地实现代码级的复用。不幸的是，面 向对象技术所带来的代码级复用并没有彻底地解决“软件危机” 。因为面向对象 的复用思想（即代码级的复用思想）复用的粒度很小，因此这种小粒度的复用方 式并不能使得整个软件业完全实现产品的工业化。 于是， 构件复用思想得以提出， 并且受到越来越多的关注，该思想和传统工业中的生产标准零件的思想相同，将 软件系统进行模块化划分，制定统一的接口，通过组装的方式开发软件。软件构 件具有可替换性，标准化，复用性强等特征。通过构件复用的思想开发的软件具 有开发周期短，开发效率高，开发成本低等优势，同时还可以不断的复用，适应 性强。基于构件的开发过程模型是一种范型，它给基于构件的软件开发过程提供 了一系列开发过程模板。这些使用构件开发模式开发出的软件适应性强，能够满 足不同软件系统的不同需求。因此，构件技术和基于构件技术的开发模式成为了 解决“软件危机”这个瓶颈的最佳方法3。 如今，这种基于构件的软件开发模式已经使用广泛，许多公司都开始使用构 件开发模式。尽管如此，这种技术和模式尚未完全成熟，仍需要经过一定时间的 进化，最终将完全统治软件业，使得软件业产生翻天覆地的变化。 .2 关于 erp 软件及其现状 关于 erp 软件及其现状 erp (enterprise resource planning)企业资源计划系统是一种为企业决策层提 供决策选择的管理系统，该系统是 mrp ii（manufacturing requirement planning） 制造资源计划的升级版。都是基于信息技术，系统化的管理思想，突破企业自身 范围的限制，把信息集成的范围扩大到企业的上下游，管理整个供需链，实现供 需链制造。总而言之，erp 企业资源计划系统就是整合了企业管理理念、业务流 程、基础数据、人力物力及信息资源、计算机硬件和软件于一体的企业资源管理 系统4 ，5，6。 遗憾的是，许多 erp 应用系统的一个共性问题就是很难找到真正适合某个 企业的 erp 应用系统。所以 erp 应用系统的成功率一直非常低下，通常只有百 分之五到百分之十五7。这样一个两难的困境就出现了，选择已有的 erp 应用 系统就意味着需要进行二次开发，开发周期难以保障；选择企业根据自己的需求 单独定制 erp 应用系统就意味着成本难以接受。 根据分析调查，erp 系统通常有以下几方面的缺点： (1) 行业适应性差 许多公司号称旗下的 erp 系统可以全方位的实现企业信息化，但是各个行 业的特征迥异，企图用一套软件来适应所有行业特征的想法是非常幼稚的。 (2) 没有先进的管理思想 erp 系统是否优秀通常取决于其是否拥有一套先进的管理思想。 但是许多现 硕士学位论文 -3- 存的 erp 系统仍使用老式的管理模式，在管理思想发展快速的今天，显然是要 落伍的。 (3) 闭门造车，缺乏实用性 在没有对企业业务实际有深入了解的情况下， 想当然的闭门造车， 随意规划， 造成某些产品中既无进出口贸易管理系统，也无对外管理系统，也不符合企业实 际情况。根本无法对企业进行全面的管理，其幼稚性，不成熟性昭然若揭。 (4) 以次充好，假冒伪劣 某些 erp 产品虽然有 mps（master production schedule，主生产计划）和 mrp 的计算，但其参数设定却漏洞百出，计算结果更是错误不断，对于企业来 说根本就没有任何用处，只是一个摆设。我们知道 erp 系统生产制造部分的核 心是 mps 和 mrp，试想，对于一个连 mps 和 mrp 计算都无法得出正确结果的 系统，怎么能称作 erp。 (5) 模块功能分散，整体功能无法体现 erp 系统与企业的整体性需要高度的契合，如果某 erp 系统不能将整个系 统与企业的计划系统连接起来，如果有任何连接断了，将使得整个系统无法发挥 整体的效力，企业的动作就无法统一起来8。 综上所述，如何提出一种适合国内国情的 erp 产品的关键就是充分利用构 件技术的复用性和重构性。erp 构件可以有效并且快速的组装出一套 erp 应用 系统，是一个专门为 erp 业务所定制出来的专业构件9。 1.2 本研究课题的理论与实际意义本研究课题的理论与实际意义 构件式软件开发技术，彻底颠覆了软件的设计模式，通常来说， “代码”是 软件的基本单元，但是基于构件的软件开发以“构件”替代了“代码” ，成为了 软件的一种新的基本结构单元。由于完全推翻了以前软件基于代码层开发方式， 面向构件的开发方式可以完全实现“构件组装” ，因此极大地提高了软件的生产 效率，同时客户需求也能灵活的满足。面向构件的开发方式开发周期短，软件质 量优良，可维护性好，客户可以根据其不同的需求快速地定制出适合该行业特性 的软件。 erp（企业资源计划系统产品）是一种为企业决策层提供决策选择的管理平 台，该系统将信息技术，先进的管理思想，企业的所有资源信息融合一体，对企 业的物流、资金流、信息流全方位全局的进行控制管理。由于全球化的进程日益 加快，先进的管理思想不断更新，企业对 erp 系统产生了新的需求。如今，一 个优秀的 erp 系统意味着必须集成各种信息管理系统的资源，实现真正的信息 一体化，给企业用户提供最佳的决策方案。根据 erp 系统的发展要求，可以看 构件式开发平台的设计与实现 -4- 出，基于构件的开发模式能较好的应用在 erp 系统的开发中。 基于构件开发的 erp 系统有以下三大优势： (1) 极大地提高 erp 系统的适用性，从根本上解决 erp 系统的实用性低的 缺点。 (2) 基于构件的开发模式能够迅速建立一套完善的 erp 系统，上线时间短， 人力资源成本低，能快速的抢占市场份额。 (3) 将 erp 系统的开发过程从手工编码的方式提升成产业化生产， 即将 erp 业务封装成构件的形式进行组装。 1.3 本文主要研究工作本文主要研究工作 当今的信息管理系统早己不再是简单的以软件技术为核心的高科技产品， 它 已成为现代企业管理不可或缺的手段。它正朝着功能上的系统化、柔性化、集成 化、智能化，性能上的高速、高精、高效、高可靠性方向发展。这种发展的动力 来自于计算机技术、信息技术和现代管理模式等相关学科的快速发展和相互融 合。特别是计算机技术的发展，使得高度模块化、高度构件化、高度兼容性成为 了以计算机为基础的软硬件产品所应具备的要求。随着这些要求的不断提高，在 此提出了构件式开发平台的思想， 就是基于此平台能够开发出各种适应于软件的 构件，然后通过一定的机制进行整合，使得软件的可维护性及其可扩展性更强。 本文的主体结构就是分为构件式开发平台的设计和在此之上的领域工程及 应用工程的设计与实现，重点放在构件式开发平台的设计。基于构件的开发设计 的困难主要集中在以下几点： (1) 如何抽象出此平台业务构件的接口 (2) 如何构造系统所需的构件 (3) 如何维护、升级、调用构件 (4) 如何将构件组装成 erp 系统并能实现互操作 构件相互之间的集成和装配是一个关键技术核心问题。 根本目的是能够用构 件集成应用系统，使构件能够装配更换。 解决以上问题最终就是为了实现构件式开发平台， 此构件式开发平台的实现 将会使在此平台上开发出来的产品具有易装配性和易维护性， 因为在平台上开发 出来的构件从仿生学的角度上讲就像一个一个小的蜂房， 通过此平台提供的展现 引擎就能将一个一个小的蜂房组成一个大的蜂巢，并且相当容易进行蜂巢的扩 展。 硕士学位论文 -5- 1.4 论文的结构论文的结构 论文的整体结构和各章节的主要内容如下： 第 2 章介绍了软件工程的发展过程所经历的几个阶段， 给出了目前存在的一 些传统软件工程模型的优劣点， 之后分析了螺旋模型中基于构件的开发模型的优 势。然后分析了基于构件的开发模式过程，该模式的过程主要由两个并行的子过 程组成：领域工程和应用工程。此章是本文的理论基础。 第 3 章首先对 mvc 模式做介绍，并对其意义及作用进行简要的分析，然后 再对蜂房结构作简要的介绍。接着就介绍了构件式开发平台的设计，首先从宏观 的角度将整个平台分为了三个世界进行分析， 接着介绍了此平台的持久化机制是 基于 dao（data access object，数据访问对象）模式设计的一个数据引擎，最 后介绍了此平台的结构。 第 4 章是在此构件式开发平台的上的应用，为了验证其平台的可行性。此部 分主要介绍了一些基础构件，然后介绍怎样通过此平台将这些构件整合为产品。 最后总结了此构件式开发平台优点以及不足之处， 以及对此平台今后的发展 进行了展望。 将传统的 mvc 模式进行了改进，在 mvc 模式之上加入了 command 模式， 并在此之上对平台进行了设计与实现， 使得此平台从仿生学的角度上看类似一个 蜂房的结构。基于构件式开发平台开发出来的构件，都具有统一的应用结构，在 此基础上开发的软件具有很好的可装配性和易维护性。 本文不但对此构件式开发 平台进行了设计与实现，并且利用了一个应用实例对此平台进行了可行性验证， 充分证明了此平台的可行性。 构件式开发平台的设计与实现 -6- 第2章第2章 基于构件的软件工程 基于构件的软件工程 随着软件系统的日益庞大，其复杂度也越来越高，系统开发面临着巨大的挑 战。传统的软件开发模式，例如顺序模型，已经很难满足软件开发中所出现的问 题。通过对软件系统开发模式的研究，一种崭新的软件开发模式，演化模式10 越来越受到大量的关注。演化模式能够较为有效地提高软件开发的效率，同时还 能降低软件开发的成本，软件的质量也能得到很好的保障。 2.1 传统软件开发模型的弊端传统软件开发模型的弊端 简单的来说，模型其实就是一种开发策略，它可以提供一套模板，软件工程 中的不同阶段都可以找到相应的范型。 这样就能使软件开发过程的进展达到原本 预期的期望。一个软件，不管其规模的大小，都应基于该软件的性质、特点以及 软件系统中的约束等种种因素来确定一套适合的开发模型。如果模型选择不恰 当， 将会造成项目的延期甚至倒闭11。 以下是几种不同的软件过程模型的优劣对 比： （1） 线性顺序模型 线性顺序模型是早期提出的一种软件过程模型， 同时也是目前应用最广泛的 一种软件过程模型。由于它最先给出了软件开发过程中系统的开发方法，所以有 时候它也可称为传统生存周期模型或者瀑布模型。线性顺序模型的开发流程为： 系统，需求分析，设计，编码，测试，支持12。图 2.1 为线性顺序模型的示意图。 图 2.1 线性顺序模型 线性顺序模型给软件开发过程提供了一个范型， 这个范型可以全局指导软件 开发过程中的分析，设计，编码，测试，支持的方法等多个阶段，这样是的软件 开发从最早的随意性软件开发上升到一个系统的阶段。 与此同时，线性顺序模型这种软件过程模型也有很多缺点：第一，由于在实 际的开发过程中，软件是千变万化的，不可能依照统一的阶段顺序来统一进行开 发，因此即使开发过程中一点微小的变化都可能最终变成巨大的差异；第二，在 实际的软件开发过程中，客户很难一次就给出最终的需求，但是线性顺序模型却 系统/信息工程 分析 设计 编码 测试 硕士学位论文 -7- 期望客户给出的需求是明确的；第三，通常情况下，客户只有在软件开发周期的 末期才看的到项目的大体轮廓，如果此时才发现与原本的需求不和符合，其后果 是非常严重的。第四，由于线性顺序模式的开发过程是线性的，那么每个过程不 可并行进行，因此必然会有一部分成员处于闲置的状态，最后可能造成整个开发 过程中人员的等待时间比整体用于开发的时间还要漫长。 （2） 原型实现过程模型 原型实现过程模型能有利地加强客户与开发者的互动， 从最早的需求分析开 始，客户和开发者就一起合作，给出项目的大体目标，讨论较为明确的已知需求 和仍需要深入讨论的未知需求。然后，通过“快速设计” ，将项目中客户方可见 的部分先开发出来，这样就相当于创建了一个原始的模型13。客户通过该原始 模型，来进一步确定该项目的具体需求。整个过程就是如此迭代的进行调整，最 后直到客户对该原始模型满意为止。整个过程为首先，客户提出建议，然后修改 原始模型，再对该原始模型进行测试，再由客户根据修改后的原始模型再次提出 建议。 该模型的一个重要的特点就是能让客户在整个开发过程中都能体验实际的 系统。因此，这种模型得到客户和开发者的一致好评。原型实现过程模型如图 2.2 所示： 图 2.2 原型实现过程模型 原型实现过程模型在抢占客户市场上很有优势， 因为客户和开发者在软件的 开发过程中比较容易达成一致的协议，所以是软件开发的首选模式。该模式中原 型的建造仅仅是为了明确客户的需求， 项目的最终版本不一定要建立在该原型的 基础上。 当然，原型实现过程模型也有其不足的地方，例如其忽略了项目质量保障这 个环节以及可维护性这个重要的软件要素； 由于原型主要是为了演示给客户观看 的，所以往往原型开发工具的选取只考虑到其快速和简易性，很容易造成开发工 具的选取错误，和此同理，操作系统的选取也可能会犯同样的错误；由于原型的 不断更替，很可能会出现某些质量问题，因此最终不得不重新选取模型。 听 取 客 户意见 建造/修 改原型 客户测试 运行原型 构件式开发平台的设计与实现 -8- （3） 快速应用开发过程模型 快速应用开发过程模型可以称为线性模型的一种“高速”变种。因为其强调 的就是高速性， 是一种利用构件的构造方法以获得快速的开发周期。 在一般的 “信 息系统”的项目开发上，快速应用开发过程模型具有较强的优势，因为“信息系 统”通常需求都较为明确，并且功能也有一定的重复性。该模型是一种类似于增 量型的软件开发过程模式，其主要过程顺序如下：业务建模，数据建模，过程建 模，应用生成，测试和反复。快速应用开发过程模式最主要的特定是其复用性， 即构件复用性。rad 模式的开发过程如图 2.3 所示： 图 2.3 快速应用开发过程模型 该模型的一个最重要的特点也是其最有优势的地方，即对“信息系统”的开 发效果非常良好，并且在开发速度快速的同时，还能较好的保证产品的质量。 快速应用开发过程模型也有很多缺憾： 第一， 一般来说， 只能用于信息系统。 第二，和线性顺序模型类似，要求需求明确，并且由于时间的紧迫性，要求需求 分析阶段能在很短的时间内完成，因此任何配合上的失误可能使项目最终失败。 第三，人力资源要求较高，特别是在大型的系统开发中，需要大量的人力去建立 所需的快速应用开发组。第四，由于该模型是有构件搭建而成的，所以对模块化 的要求较高。第五，如果某项目的技术风险很高，那么快速应用开发过程模型将 不能使用于该项目14。 （4） 螺旋过程模型 螺旋过程模型是一种原型实现模型和线性顺序模型的结合体， 它既有拥有原 业务 建模 数据 建模 处理 建模 应用 生成 测试及 反复 业务 建模 数据 建模 处理 建模 应用 生成 测试及 反复 业务 建模 数据 建模 处理 建模 应用 生成 测试及 反复 第一小组 第二小组 6090 天 第三小组 硕士学位论文 -9- 型实现模型的迭代特征，也同时兼有线性模型的控制花和系统化的优点。在螺旋 模型中，软件的开发类似一个演化的过程，是一系列的增量发布，其可以快速地 开发出项目的增量版本。和原型实现模式相同，在每一次迭代中，项目的完美版 本逐渐完成。通常，该模式可以划分成一些框架活动，这些框架活动也可以称作 任务区域。最典型的螺旋模型可以分为三到六个框架活动。具体的框架活动为： 风险分析：这个框架活动的内容主要是评估技术上和管理上的风险；客户评估： 这个框架活动的内容主要是通过在工程阶段， 软件安装阶段的评估结果来了解客 户的反馈信息；客户交流：这个框架活动的内容主要是保障开发人员和客户能进 行有效地交流通信；构造与发布：这个框架活动的内容主要是构造，测试，安装 和提供用户支持；计划：这个框架活动的内容主要是定义信息，主要包括的信息 有资源信息，进度信息和其他的一些项目相关信息；工程：这个框架活动的内容 主要是建立应用的一个或多个表示。 由于该模型是如今一个相对较新的模型，因此其最终的效果还不能断定。该 模型的具体示意图如图 2.4 所示： 图 2.4 螺旋过程模型 螺旋模型的主要优点在于：对于大型系统及软件的开发，这种模型是一个很 好的方法。开发者和客户能够较好地对待和理解每一个演化级别上的风险。 螺旋模型也有其一些重要的特点， 由于客户和开发人员能够在每一个演化级 别上较好的理解和对待该级别上所可能产生的风险， 因此它较适用于大型软件的 开发。 与此同时，螺旋模型也有其不足的地方：第一，由于螺旋模型的新颖性导致 该模型的应用暂时较为狭窄，并且该模型的功效也还未得到验证15。第二，螺旋 构件式开发平台的设计与实现 -10- 模型的成功在很大程度上依赖于风险分析评估这一项专门的技术。第三，如果任 何一个较大的风险问题在开发过程中被忽略了， 将会使得整个演化的过程不在控 制之中，最终导致严重的后果。 2.2 基于构件的软件工程基于构件的软件工程 .1 构件的定义和分类 构件的定义和分类 目前来说，对于构件的定义还不统一，因此下面将列举了一些具有代表性的 构件定义，并在这些定义的基础上，分析并给出构件的本质特征： (1) 欧洲面向对象编程会议上提出的定义： 软件构件是一个具有规范接口和明确的上下文依赖的组装单元。 软件构件能 够被独立部署和被第三方组装16。 (2) lemens szyperski 在 1998 年给出的定义： 软件构件是可单独生产、获取、部署的二进制单元，它们之间可以互相作用 构成一个功能系统。 (3) cmu/sei 的 felix bachman 等人在 2000 年 5 月的一份关于基于构件的软 件工厂报告中给出的定义： 软件构件是一个不透明的功能实现；能被第三方组装；符合一个构件模型。 (4) 波音公司的 guijun wang 对构件的定义： 构件是一个带有契约化接口和显示上下文依赖的组装单元， 它能被独立发布 并且可以被第三方组装17。 (5) desmond dsouza 和 alan wills 对构件定义： 软件构件是一个可以独立交付的软件单元，封装了设计和实现的内容，并向 外提供接口，通过接口与其它构件组装成更大的整体。 (6) franz huber 等从对象实现技术的角度给出了构件的定义18： 构件由一个动态变化的对象集合组成， 这些对象既可以在构件的内部也可能 是其接口的一部分。构件之间可以直接交互，也可以通过独立的对象进行整合。 尽管对于构件的定义尚不明确，但是综上所述，可总结构件的特点如下： （1）构件的设计应具有较高的抽象程度： 构件的复用程度是指软件构件在开发各种软件时可被复用的难易程度。 软件 构件越具体，其复用程度越低。为了提高软件构件的可复用度，应尽量把构件一 般化，使软件开发人员能够有效地复用这些构件及其设计思想。 （2）构件应易于调整： 可复用构件应该具有较高的通用性。然而，开发特定软件时，必须把这些软 件构件具体化，以用于具体的环境。因此，必须提供构件的具体化机制。 硕士学位论文 -11- （3）软件构件应易于组装： 基于可复用构件的复用途径， 一般来说是从可复用构件库中选出若干构件组 装成所需要的软件。因此，构件组装软件的难易程度是影响软件复用大规模实用 化的重要因素之一。所以，为了易于组装，除构件之间应具有松散的耦合度外， 还应提供便于组装的机制。 （4）构件应具有可替换性： 当软件系统将大量的构件组装起来后，如果以后需要更改时，可以直接用具 有相同的组装标准并且接口相同的其他构件将需要修改的那个构件替换掉。 在整 个替换的过程中， 不需要作任何的代码修改， 并且替换后该系统仍能照常运行19。 构件的粒度是描述软件构件实现功能多少的概念。构件就像白糖一样，具有 不同的粒度。使用者可以用粒度精细的构件来构建应用，也可以用粒度较粗的构 件。粒度可以用构件所提供的功能数量来度量，特别是用功能点的数目来度量。 迄今， 在软件工程领域， 对于构件的粒度方面仍没有一个统一的标准。 目前来说， 只要构件是符合高内聚这一原则的，那么构件的粒度大小不加以限制，因为构件 时一个高内聚的软件包。 然而， 通常来说， 构件粒度应从可复用构件， 领域构件， 商业构件这一顺序成递增的趋势20。 构件有不同的分类方法，按照可重用程度和范围可分为三类：通用构件、领 域共性构件和应用专用构件；按构件粒度分为四种：系统构件、组织构件、分子 构件和原子构件21。通常是按前者进行分类的。通用构件是可通用于所有领域的 应用构件，例如：一些基础的服务像日志、安全等。领域共性构件是可通用于特 定领域的构件，是经过一个或多个该领域应用系统实际顺利运行所验证的构件， 是构件重用中运用得最多的一种。 应用专用构件， 是指一个应用系统特定的构件， 只能在该应用系统内部被重用，不能供其他应用系统直接重用。但是，系统专用 构件可能在经过提取共性、摒除特性之后，或者经过某种包装、经过抽象和客户 化之后成为可重用的通用构件或领域共性构件。基于构件技术的开发应用系统， 就是把上述的通用构件、领域共性构件和应用专用构件组装成一个可运行的系 统。目前，制定构件实现规范标准有：微软公司的 windows dna 2000、对象管 理组织 omg 的 corba 以及 sun 公司的 j2ee 等22。 在九十年代初期， 出现了开放市场构件， 这种构件时可以购买的。 例如 com， java，microhelp 公司的 vbtools，基于微软 vb 构件模型，该模型后来成长为 基于 com（component object model，组件对象模型）的构件，而现在成了基 于.net 的构件23，这些都是可以在开放市场上购买的可重用构件。 如今，由于局域网逐渐成为 internet 的分布式，应用构件将不仅仅是处于某 个局域网的某个服务器上，而将是处于整个 internet 中。这样，网络服务构件， 网络服务给出了问题的解决方案， 因为网络服务和网络服务构件将不仅仅只是提 构件式开发平台的设计与实现 -12- 供了一个整体的应用，还同时提供了可供个人使用的构件。 .2 基于构件的开发过程模型 基于构件的开发过程模型 一般来说，面向对象技术的类可以在不同的计算机体系结构中复用，而且可 以适用于不同的应用。面向对象模型最重要的特征为类的创建，类中可以封装数 据和使用该数据的一些方法。因此，面向对象技术的这些重要特征给构件过程模 型提供了良好的技术框架。基于构件的过程模型通常是使用预先包装好的类（即 构件）来构造软件系统24。基于构件的过程模式其实本质上来说是演化型的，具 有迭代性，因为它较好的融合了许多螺旋模型的优点。基于构件的开发模式过程 如图 2.5 所示： 图 2.5 基于构件的开发过程模型 根据传统的产业工业化生产方式，构件过程模型主要由以下两个活动组成： 可复用软件资产的生产和基于可复用软件资产的应用系统开发。其中，在可复用 软件资产的生产阶段，邻域工程是一个重要的技术，它由以下三个阶段组成：领 域分析、领域设计和领域实现。领域分析是系统地获取特定领域可复用软件需求 的活动，它覆盖了对领域需求的获取、分析、规约和检验/验证的整个过程。利 用这个模型过程，所有的系统都可以在大量复用的基础上进行，比如在分析，设 计，实现等阶段软件资产可以进行复用25。这样，一个新系统的开发就不需要一 切从零开始了。 根据基于构件的软件开发模型的特征， 我们可以看出这个开发模式有以下三 个优点： （1）由于构件可以复用，这样就非常有效地提高了开发效率。 （2）由于构件可以支持即插即用，这样整个系统在不重新编译的情况下， 标 识 候 选构件 在库中查 找构件 可 用 否？ 提取 构件 构造 构件 新 构 件 入库 构 造 系统 n y 硕士学位论文 -13- 可以进行升级或者排错， 甚至在某些设计良好的构架之下可以实现多种业务流程 的重组。 （3）构件都是以接口为核心的，与此同时，由于构件的接口和实现分离的 特征，允许相同的接口拥有不同的实现方式26。 目前，定制的软件和标准的软件都有其优势，同时也有其各自的劣势。举例 来说，定制软件由于没有基于复用的软件开发方法，模块间的耦合度高，导致软 件的开发周期十分缓慢， 并且后期的维护也会变得十分吃力， 开发效率十分低下， 但是它能够较好的满足客户的多种需求。反观标准软件来说，由于标准软件使用 的是一套标准的业务流程，这样，就不能满足不同客户迥异的要求，虽然开发效 率很高，但是在软件开发之前，需求分析阶段的工作较为庞大，需要对客户所提 出的业务流程进行大量的重组， 因此软件的灵活性和功能适应能力都不如定制的 软件。 然而， 这种基于构件的软件开发模型将定制软件和标准软件进行了完美的融 合，同时具备了两者的所有优势。即构件都是标准化的构件形式，但是在针对不 同的客户需求时，采用不同的组装方式来提高适用性，这样就能在兼顾标准化的 同时，仍然保持软件的灵活性。 2.3 本章小结本章小结 本章开始首先简单的介绍了软件工程发展过程所经历的线性顺序模型、 原型 实现过程模型、快速应用开发过程模型等的阶段，给出了目前存在的一些传统软 件工程模型的优劣点，之后分析了螺旋模型中基于构件的开发模型的优势。然后 分析了基于构件的开发模型的基本内容。 构件式开发平台的设计与实现 -14- 第3章 构件式开发平台的设计 第3章 构件式开发平台的设计 本文所介绍的构件式开发平台是基于一个 mvc （model-view-controller， 模 型-视图-控制器） 的思想进行设计， 并在此基础上做了一些修改， 加入了 command 模式，这种设计的从仿生学的角度上来讲类似于一个蜂房的结构。下面将介绍此 平台的设计。 3.1 mvc 模式模式 .1 mvc 模式简介 mvc 模式简介 20世纪70年代， mvc模式是在smalltalk-80的gui （graphical user interface， 图形用户界面）的设计过程中提出来的。mvc 将界面显示、逻辑控制和对数据 的访问进行分离，这样的设计使得系统层次清晰，结构非常灵活多变27。 mvc 模式是由三层组成： model、 view 和 controller， 它们分别表示模型层、 视图层、控制器层。这三层的关系如图 3.1 所示。 图 3.1 mvc 模式结构图 模型（model）呈现了系统的底层数据以及控制这些数据进行操作的业务规 则。 视图（view）是底层模型的界面呈现形式。视图可以是 winform 的形式呈 现或者是以网页的形式，甚至可能是以另一种的界面形式展现。基于 mvc 构架 的系统的特点就是可以存在多个视图调用同一个底层模型的情况， 虽然是调用的 模模 型型 封装应用程序状态 响应状态查询 应用程序功能 通知视图改变 视视 图图 解释模型 模型更新请求 发送用户输入给控制器 允许控制器选择视图 控制器控制器 定义应用程序行为 用户动作映射成模型更新 选择响应的视图 状态查询 通知改变 状态改变 视图选择 用户请求 方法调用 事件 硕士学位论文 -15- 是同一个模型，但是它们展现的形式可以各不相同，它们只需要将最新的数据展 现给用户以及将用户的响应转换模型相应的信号改变。 控制器（controller）是为了将数据与视图分离开，使得系统的结构更加清 晰、更易维护。控制器的工作主要是将用户在视图上的响应进行处理，然后利用 处理完成的结构更改模型状态， 当模型状态发生改变时控制器会利用模型的最新 状态更新视图上的数据，使得模型和视图同步。 mvc 使得视图、控制器、模型这三者之间形成了两两映射的关系，视图不 能直接与模型打交道，而是利用控制器来对模型进行数据的交互。当用户在界面 上进行数据的输入时，视图将利用控制器调整模型的信号标识，然后模型再将自 己的信号标识改变的信息通过控制器通知给相应的视图， 视图得到这些通知后将 发生一系列改变，将模型的改变呈现给用户。这样的设计，减少了各层之间的耦 合度，使得系统有着更强的复用性28。 .2 使用 mvc 模式的意义和作用 使用 mvc 模式的意义和作用 一般来说处理问题的方式分为两种，一是从底向上的方式，这种方式是先从 某个细节进行考虑，然后在围绕着这个细节进行扩张，逐渐逐渐的向上层的解决 方案过渡。另外一种方式则是自顶向下的方式，这种方式是先设计出处理问题的 整体结构，然后逐渐将其细化，这样一层一层下去直至底层的问题得以解决。 对于当今的软件设计来说， 大多数的设计采用了自顶向下的方式进行软件系 统的设计。利用这种方式，首先要做的是设计并构建出一个整体的构思，暂时不 去考虑细节的实现问题。这样整体的构架一般是长久不变的，而支持高层构架的 底层技术在不断更新从而更好的支持顶层的构架， 这也在一定程度上推动了新技 术的发展。然而可能在某一时刻底层技术发展到一定的阶段时，顶层的设计构架 不能完全适应底层技术的发展，这时顶层的构架就会相应的进行更新。这样顶层 构架与底层技术相辅相成并且互相推进， 总之顶层设计和底层技术是一组紧耦合 的相互促进和约束的对象。 从整个软件的发展现状来看， 软件体系构架的设计还停留在一个非形式化的 基础上，软件体系构架的设计往往依赖于某个构架师个人的经验进行设计，这样 的设计使得整个软件构架的设计通常是以非形式化的图形文字来描述， 很难对系 统期望的存在于构件之间的接口进行描述， 更不能描述不同的组成系统的组合关 系的意义。 这种描述方法难以被开发人员理解， 难以适于进行形式化分析和模拟， 缺乏相应的支持工具帮助设计师完成设计工作， 更不能用来分析其一致性和完整 性等特性29。 通过 mvc 模式对软件进行设计，就像是从软件的顶层来对软件的整体构架 进行设计，通过提高代码的复用度来提高系统开发的效率和系统的易维护性。在 构件式开发平台的设计与实现 -16- 普通的设计中，往往会存在这样的问题，当视图界面的不断增多，界面对应的程 序也会随着视图界面的增多而增多， 相应的对数据操作代码也会随之增多。 mvc 模式是存在着视图-控制器、控制器-模型这样的映射关系，当视图界面增多时， 如果两个界面的功能相识则可以用一个控制器进行控制， 当某一类界面视图访问 的数据也属于同一类时完全可以用同一个模型进行维护30，这样的分层使系统 的代码得到了很大程度的复用，又由于视图、控制器、模型各层之间是属于弱耦 合的关系， 在系统进行维护时也不会出现动了这点代码别的代码也需要相应改的 问题，使得维护的