基于构件开发的应用框架设计

基于构件开发的应用框架设计
--------------------------------------------------------------------------------
 
　　框架必须是健壮的、可扩展的、灵活的，且支持动态内容，它要求基于开放或共享标准。框架的设计要力求做到：完备性、灵活性、可扩展性、可理解性，同时抽象能用于不同的场合；用户能轻松地添加和修改功能，定制框架；用户和框架的交互清晰，文档齐全。框架设计的一个核心问题就是发现可重用的设计和“热点”，以保证框架具备充分的灵活性，使用户能在已有构件的基础上生成应用程序，实现“零代码编写”的理想目标。
一、如何设计应用框架？
　　目前在框架设计方面成熟的技术较少，大体可分为两类：实践法与系统法。
1. 实践法
　　许多专家甚至认为框架不可能是系统设计的结果，而只是在从底向上设计中的一个结果。实践法也可以说是实例(Example)驱动的设计方法,它是从若干个具体的典型应用中，抽象出相似点来构建框架，框架反过来又应用于不同的问题，并在解决不同问题的过程中得到更新，在框架的设计和实现的两步中，不断反复。等到框架逐渐成熟时，需要修改和反复的内容就会越来越少。
　　具体步骤为：
　　分析问题领域，确定所需框架。从一类应用而不是单个的程序去分析、比较各种不同的软件解决方案，寻求这些方案的共性和每个程序的唯一性特征。这些共性，尤其是那些经常被多个程序使用的部分将成为框架的基础。然后定义框架体系结构并设计，包括设计用户与框架间的交互、给用户提供的最终工具等。
　　框架的实现。包括框架核心类的实现、框架的测试、框架的试运行、框架的反复更新。
　　框架的部署。包括文档的提供、分发过程，为用户提供技术支持，维护和更新框架。
　　这种方法也就是先在具体类基础上进行泛化，提取出抽象类。抽象化也是框架开发的一个关键。不过，根据这种方法设计出的框架的可适用性很大程度上依赖于其基于的具体应用。
　　由于框架的开发具有反复性，且需要深入了解应用领域，因此框架的开发很难按进度表进行。框架的设计者也需要和应用开发者紧密合作，因为框架只有在使用它开发应用的过程中才能发现其哪些部分有待改进。
2. 系统法
　　由于有人认为框架的设计也可以通过系统的方法得到，因此人们提出了逐步泛化的框架设计方法。此时框架的设计分两步：
　　第一步是问题的泛化。它要求解决如下问题:问题领域中的哪些概念可以表现为变量，并且需要统一处理？是否可以发现一些具体的概念，它们能被泛化为一个更抽象的概念？
　　第二步是框架的设计。在这一步中，泛化是从反向考虑，以实现每一级的框架。换言之，最先实现最通用的框架，然后实现次通用的框架，以此类推。如图1所示, 其中，框架0就是最终要实现的框架。
　　这一步需要解决如下问题：系统的哪一部分可能需要改变？用户需要在什么地方向框架中加入自己的代码？
　　采用两步的设计方法可以避免在早期的开发过程中局限于应用专用的类和体系结构，并且有利于使用通用的设计模式。
　　框架的设计是一个反复的过程，在这个过程中需要领域和设计两方面的专家意见，框架用户和框架开发者之间的交流对框架的设计也很重要，因为框架是在不断反复的过程中逐步成熟的。
3. 框架设计与应用设计
　　框架的设计和应用的设计到底有何不同？一般而言，两者的侧重点不同。设计应用系统时，要求对专用领域的重要概念有深入的了解。这些概念通过建模演变成类，并作为实现整个应用的构建块。而设计框架时，重点在识别出必须具备灵活性的地方，也就是“热点”，这也是框架的关键所在。
　　构件库系统基于框架而不是具体的类，使得构件库系统的使用更具灵活性。但在框架基础上构建具体的应用时, 类的使用和开发总是随之而来，在框架上生成应用可以通过创建子类、配置各构件对象、调整实例等来获得。
4. 框架文档
　　文档必须包括如下内容:框架的目的，如何使用框架，框架的设计细节等。
二、框架采用哪些支持工具？
　　一般而言，没有支持工具的框架很难被使用。任何一个框架的提出总是配有一系列工具软件，这样基于框架的应用开发才切实可行。这些工具允许用户与应用框架交互、配置和构筑新的应用。下列工具通常被使用：
　　浏览工具 用户可以利用它浏览框架的类层次结构等信息。
　　编辑工具 用户用来调整和修改框架元素的属性等，如修改类或构件等。
　　帮助系统 为用户使用本框架系统提供向导功能，如可以采用HTML格式。
　　测试系统 用来测试生成的应用系统，通常支持仿真操作。
　　文档工具 帮助创建应用系统的文档，如Javadoc工具。理解并学会使用框架是一件费时的工作，这也是框架设计方法的唯一不足之处，因此要求框架的文档必须齐备。
　　配置管理工具 使用框架而不是具体的对象虽然提供了复用性，但它同时也带来了开发上的复杂性。框架内包含各种构件或构件库，一个框架可能需要和其他框架通信。一个框架也可能由其他子框架系统组成，这样一种组成结构必然提出配置管理的问题。例如，如何在多个框架内共享构件？如何由构件或子框架组装新框架？框架内的构件如何通信与协作？不同的框架间如何交互？
　　使用这些高级工具的最终目的就是减少编码和记忆的工作量,简化用户的操作。理想情况下，用户可以不用编一句代码而实现新系统的构建。例如，在一可视化界面上，通过选取一些图标就能生成可执行程序。目前已有一些类似的工具，如University of Geneva开发的Vista系统。
三、都有哪些著名的框架系统?
　　目前有许多框架系统，例如用户界面方面的框架有MVC、ET++等，其中ET++采用C++语言实现，运行于Unix等系统中；针对其他领域的则有FOIBLE、MacApp、FACE (Framework Adaptive Composition Environment)等。
　　早期一些框架系统多采用传统的面向过程语言实现，现在面向对象语言为软件和设计的重用提供了更强有力的支持。由于框架开发的学习曲线较复杂，因此框架开发的语言最好能对框架的文档建立提供有效的方法；框架的使用要求开发语言具备高可移植性;框架的设计其实也是一些高层的决策，很自然采用高级语言来实现。Java语言由于具有平台独立性以及轻量级的链接过程、自动垃圾回收、简单语言结构、标准软件包、面向对象等特性，因此可以说Java是进行框架构筑的合适语言。现在市场上已出现了许多采用Java语言编写的框架系统。
　　LEC India Software Centre Pvt. Ltd.公司研制了一个面向EJB 构件的应用框架系统。它主要面向基于EJB的应用程序，是一个服务器端的框架，能在EJB构件的开发中解决稳定性以及其他一些企业级的特性等问题。
　　现在又出现了许多采用J2EE编程环境的应用框架，如Pacific技术服务公司开发的一套多层框架，能用来开发Web应用服务器；Jcorporate公司开发的Expresso Framework是一使用java来建造分布式、重用、基于构件的安全的Web应用程序的应用框架。
四、 如何设计知识工程应用框架?
　　在知识爆炸的时代，如何从数据中提取信息，从信息中提取知识已成为一个重要的应用领域。越来越多的知识处理应用系统急待开发，若能有一个成熟可靠的知识处理框架系统，将大大加快此类应用系统的开发。针对这种情况，清华大学知识工程研究室结合自己的经验,目前提出了在知识工程应用领域的框架，主要针对网络计算模式下的知识获取、传输、管理和应用，基于Web的数据挖掘与知识发现等内容，所有的代码均采用Java实现。
　　将应用框架结构化为框架的框架，划分为如下三个子框架：
　　(1) 领域专用构件框架:提供领域专用的构件模型集合，并为分层的构件模型提供统一接口。
　　(2) 可视化组装框架:提供整个框架系统的图形化界面，并为可视化组装和操作构件提供工具。
　　(3) 连接框架:为构件间的交互、通信提供机制。
　　框架内各构件的分布如图2所示。
　　建立的基于框架的构件系统具有如下性能：
　　实现面向产品化、实用性的构件库系统，并具开放性、可扩展性；
　　支持异构环境中的框架、构件的互联和通信;
　　实现新旧系统的兼容性；
　　提供一致的接口分配；
　　遵循重要构件标准（如CORBA）；
　　构件具有透明本地化、平台无关性特点；
　　系统的配置、数据交换基于XML和Java的标准化格式；
　　支持个性化信息服务定制和可重构。
　　良好的用户学习曲线。
　　框架的设计本身也是一个循环迭代的过程，它在不断应用于实践的过程中，得到更新和提高。我们也在不断的完善这套系统。目前一些公用构件如电子表单自动生成系统、数据提取和文件转换系统等作为大粒度构件已得到广泛使用。
　　框架能使应用程序的开发简单，价格低廉，但是开发框架不是一件容易的事。它是一个需要领域和设计经验的反复过程。为了保证框架的灵活性，必须提取和发现热点。设计模式可以简化这个过程，因为它提供了对过去经验的抽象。应用框架能高度抽象同一领域内的问题，进而降低开发难度和强度。虽然框架和构件技术已经出现许多年了，开始走入实用,但还不成熟，有大量问题有待研究。

 

 

变革与突破—如何认识基于构件的软件开发方法

与传统的软件开发方式相比，基于构件的软件开发方法有什么突破呢？

 

一、体系结构

 

　　软件体系结构代表了系统公共的高层次的抽象，它是系统设计成败的关键。其设计的核心是能否使用重复的体系模式。传统的应用系统体系结构从基于主机的集中式框架，到在网络的客户端上通过网络访问服务器的框架，都不能适应目前企业所处的商业环境，原因是：

 

　　企业过分地依赖于某个供应商的软件和硬件产品。这种单一供应商使得企业难以利用计算供应商的免费市场，将计算基础设施的重要决定交给第三方处理，这显然不利于企业在合作伙伴之间共享信息。

 

　　不能适应远程访问的分布式、多层次异构系统。

 

　　封装的应用系统在出现某种组织需要时，难以用定制来维护系统，从而难以满足多变的需求。

 

　　不能实现分析、设计核心功能重用，最多只能实现代码重用。

 

　　如今，应用系统已经发展成为在Intranet和Internet上的各种客户端可远程访问的分布式、多层次异构系统。CBSD为开发这样的应用系统提供了新的系统体系结构。它是标准定义的、分布式、模块化结构，使应用系统可分成几个独立部分开发，可用增量方式开发。

 

　　这样的体系结构实现了CBSD的以下几点目标:

 

　　能够通过内部开发的、第三方提供的或市场上购买的现有构件，来集成和定制应用软件系统。

 

　　鼓励在各种应用系统中重用核心功能,努力实现分析、设计的重用。

 

　　系统都应具有灵活方便的升级和系统模块的更新维护能力。

 

　　封装最好的实践案例，并使其在商业条件改变的情况下，还能够被采用，并能保留已有资源。
由此看出,CDSD从系统高层次的抽象上解决了复用性与异构互操作性，这正是分布式网络系统所希望解决的难题。

 

二、开发过程

 

　　传统的软件开发过程在重用元素、开发方法上都与CBSD有很大的不同。虽然面向对象技术促进了软件重用，但是，只实现了类和类继承的重用。在整个系统和类之间还存在很大的缺口。为填补这个缺口，人们曾想了许多方法，如系统体系结构、框架、设计模式等。

 

　　自从构件出现以来，软件的重用才得到了根本改变。CBSD实现了分析、设计、类等多层次上的重用。图1显示了它的重用元素分层实现。在分析抽象层上，重用元素有子系统、类；在设计层上重用元素有系统体系结构、子系统体系结构、设计模式、框架、容器、构件、类库、模板、抽象类等。

 

 

 

 

　　在软件开发方法上，CBSD引导软件开发从应用系统开发转变为应用系统集成。建立一个应用系统需要重用很多已有的构件模块，这些构件模块可能是在不同的时间、由不同的人员开发的，并有各种不同的用途。在这种情况下，应用系统的开发过程就变成对构件接口、构件上下文以及框架环境一致性的逐渐探索过程。例如，在J2EE平台上，用EJB框架开发应用系统，主要工作是将应用逻辑,按session Bean、entity Bean设计开发,并利用JTS事务处理的服务实现应用系统。其主要难点是事务划分、构件的部署与开发环境配置。概括地说，传统的软件开发过程是串行瀑布式、流水线的过程;而CBSD是并发进化式，不断升级完善的过程。图2显示了它们的不同。

 

 

 

 

三、软件方法学

 

　　软件方法学是从各种不同角度、不同思路去认识软件的本质。传统的软件方法学是从面向机器、面向数据、面向过程、面向功能、面向数据流、面向对象等不断创新的观点反映问题的本质。整个软件的发展历程使人们越来越认识到应按客观世界规律去解决软件方法学问题。直到面向对象方法的出现，才使软件方法学迈进了一大步。但是，高层次上的重用、分布式异构互操作的难点还没有解决。CBSD发展到今天，才在软件方法学上为解决这个难题提供了机会。它把应用业务和实现分离，即逻辑与数据的分离，提供标准接口和框架，使软件开发方法变成构件的组合。因此，软件方法学是以接口为中心，面向行为的设计。图3是其开发过程。

 

 

 

 

　　归纳起来，CBSD的软件开发方法学应包括下面几方面：

 

　　对构件有明确的定义。

 

　　基于构件的概念需要有构件的描述技术和规范，如UML、JavaBean、EJB、Servlet规范等。

 

　　开发应用系统必须按构件裁剪划分组织，包括分配不同的角色。

 

　　有支持检验构件特性和生成文档的工具，确保构件规范的实现和质量测试。

 

　　总之，传统的软件方法学从草稿自顶向下进行，对重用没有提供更多的辅助。CBSD的软件方法学要丰富得多，它是即插即用，基于体系结构，以接口为中心，将构件有机组合，它把自顶向下和自底向上方法结合起来进行开发。

 

四、开发组织机构

 

　　传统软件的开发组织一般由分析员、设计员、程序员和测试员组成。对一个小的应用系统来说，一个熟练的开发人员，可能兼顾以上多个角色。但对CBSD来说,因为构件开发与应用系统集成往往是分开进行的，因此整个开发过程由六个角色来完成，他们是:

 

　　构件开发者 也是构件供货商，这些大多数是中间件构件提供者。

 

　　应用构件集成者 针对某应用领域将已有构件组合成更大的构件模块或容器， 作为系统部署的基本单元。

 

　　应用系统部署者 将系统部署基本单元放入选定的平台环境或基本框架中，完成软件定制的要求。

 

　　开发平台服务器供应商 提供服务器、操作系统和数据库等基本软件。

 

　　应用系统开发工具供应商 提供构件公共设施服务。

 

　　系统管理员 配置硬件、网络和操作系统，监督和维护应用系统者。

 

　　这六个角色的工作专业性很强，要兼顾成为多面手很不容易。目前已形成构件开放市场，而且还很火红。这也是当今软件人才大战所遇的一个困惑。因此，在CBSD中，如何组织好开发队伍尤为重要，必须按本企业所具备人才来组织。特别重要的是:开发初期必须选好标准框架，以及统一的开发指导方针，保证在整个开发过程中,各角色能随时互相沟通。一般来说，CBSD的人员素质决定了构件的重用率。

 

五、构造方法

 

　　传统应用软件的构造是用白盒子方法，应用系统的实现全在代码中，应用逻辑和数据粘结在一起。而CBSD 的构造是用白盒子和黑盒子相结合的方法。 基于构件的框架是用两个概念来支持演变：第一个概念是构件有很强的性能接口，使构件逻辑功能和构件模型的实现都隐藏起来。这样，只要接口相同，构件就可以被替换。

 

　　第二个概念是隐式调用，即在基于构件的框架中，从来不直接给构件的接口分配地址，只在识别构件用户后才分配地址。因此，构件用户只要了解接口要求和为构件接口提供的引用后的返回信息 (该引用可能是一个构件，也可能是一个构件代理。对构件用户来说，构件代理就是构件，不用区分) 。 构件接口的信息并不存入构件内，而是存入构件仓库或注册处。这样才能保证构件替换灵活，并很容易利用隐式调用去重新部署构件。由于构件的实现对用户透明，因此也使构件能适应各种不同的个性化要求。为此，构件提供自检和规范化两个机制。自检保证在不了解构件的具体实现时，就能获得构件接口信息。例如，JavaBean提供的自检机制是Reflection和BeanInfo， 通过Reflection 可直接获得Bean构件的全部方法，通过BeanInfo可直接获得构件的许多复杂信息。

 

　　规范化允许不访问构件就可以修改它，如JavaBean提供的规范化是property sheet和customizer(定制器)。 通过property sheet提供一组简单参数，修改Bean的属性。复杂的修改由用户通过定制器设置参数完成。