基于构件开发方法的概念、目标和意义

基于构件的开发（Component-Based Development，简称CBD）或基于构件的软件工程（Component-Based Software Engineering，简称CBSE）是一种软件开发新范型，它是在一定构件模型的支持下，复用构件库中的一个或多个软件构件，通过组合手段高效率、高质量地构造应用软件系统的过程［Brown00］。由于以分布式对象为基础的构件实现技术日趋成熟，CBD已经成为现今软件复用实践的研究热点，被认为是最具潜力的软件工程发展方向之一。

 

一、        基本概念

 

下面简单介绍与本文相关的一些概念，包括构件、接口、契约、接口描述语言、构件框架等，另外还介绍了CBD的开发模式，以及构件技术和对象技术的关系。

在文献［Szyperski97］中，Szyperski把构件定义为“软件构件是一个仅带特定契约接口和显式语境依赖的结构单元”，同时他还写道：“软件构件可以独立部署，易于第三方整合。”

根据这个观点，可以认为构件由一方定义其规格说明，被另一方实现，然后供给第三方使用。接口（interface）是用户与构件发生交互的连接渠道，第三方只能通过构件接口的规格说明理解和复用构件，接口规格说明也是一种“契约”（contract）,它足够精确地描述构件实现的功能，同时又不把构件限定于唯一的实现方法，这种不确定带来多解决方案的灵活性。另一方面，虽然构件可以独立部署的，但是一个构件可能会用到其它构件或平台提供的服务，或者说基于构件的软件系统中通常是多个构件协作完成一定功能，所以构件依赖于组装环境或称为语境（context）。

构件基础设施（infrastructure）是异构构件互操作的标准和通信平台，构件框架（Framework）是构件实例“即插即用”的支撑结构。通过一定的环境条件和交互规则，构件框架允许一组构件形成一个“孤岛”，独立地与外部构件或其他框架交互和协作，因此构件框架及其内含的构件也可以视为一个构件，于是构件通过不断的迭代和合成，构成一个结构复杂的应用系统。目前，有多个组织和公司制定了构件基础设施的标准或开发了相关产品，也为构件、构件框架和接口建立了模型和技术规范，其中OMG CORBA［OMG01］、Microsoft COM／DCOM（或.NET）［Microsoft01, Box99］以及Sun JavaBean／EJB［Perrone01］占主导地位，本文第六章将重点讨论CORBA CCM（CORBA Component Model）构件模型，并介绍基于CCM技术的演化构件模型。

特别地，通过购买获得的第三方构件称为COTS（commercial off-the-shelf ，简称COTS）构件，作为内部（in-house）构件的对应概念。使用COTS是无源码的完全黑盒复用，既有成本低、即买即用的优点，又有不一定满足需求或误配的风险。

CBD遵循“购买而不创建（buy, don’t build）”的开发哲学［Clements95］，让人们从“一切从头开始”（build from scratch）的程序编制转向软件组装。基于构件的开发任务包括创建、检索和评价、适配（adaptation）、组装、测试和验证、配置和部署（deployment）、维护和演进，以及遗产系统（legacy）的再工程等主要活动，它们与传统的生命周期中的方法不尽相同。首先，CBD采用以构件库为中心的开发模式，构件检索和评价是CBD的一项关键任务，这里我们理解的构件库不仅仅是一个独立的数据库，而是广泛的、一切可获得的构件资源，尤其是通过互联网发布的软件构件。其次，构件形成是一种在软件体系结构支持下的组装过程，也就是说，在应用领域里需要用DSSA将独立的构件组装成完整的应用系统，可见构件的匹配和一致性验证也成为CBD的关键任务。再次，CBD过程中需要同一些技术标准化接轨，相同的构件可能由多个软件供应商生产，被多个用户使用，所以构件接口、构件基础设施必须标准化。最后，CBD需要配置管理（Configuration Management），即专门处理构件的集成、配置和发布（distribution）的有关事宜，于是构件的配置、适配和部署都是CBD的关键任务。

构件技术与面向对象技术紧密相关。构件和对象都是对现实世界的抽象描述，通过接口封装了可复用的代码实现，不同的是，首先在概念层面上，对象描述客观世界实体（identity），构件提供客观世界服务（service）［Petre00］，其次在复用策略上，对象是通过继承实现复用，而构件是通过合成实现复用；最后在技术手段上，构件通过对象技术而实现，对象按规定经过适当的接口包装（wrap）之后成为构件，一个构件通常是多个对象的集合体。

当今，构件技术已经成为计算环境的基本组成之一，众多中间件产品和开发工具提供了对不同构件模型的实现支持，特别在分布式、企业级应用软件系统中，无不把软件的构件化作为解决维护、扩展和升级的唯一途径。然而，虽然业已存在了大量的CBD概念、方法和工具，软件业并未完全迁移到CBD软件开发范型，一个主要原因是缺少一套成熟的CBD开发方法学，至今尚未完全解决如下关键问题［Bergner99］：

l        必须建立一个完善的CBD概念框架，用数学方法定义构件相关概念的形式化模型，既要尽可能的简单，又要足以描述已有的构件基本概念和开发技术。

l        必须有切实可行的构件描述方法和技术。在构件概念框架基础上，为构件开发者建立相互交流的特殊语言，例如UML［Booch01］的图形化描述技术和CORBA IDL［OMG01］的文本描述技术，理想的描述技术可以提供系统的一致性约束和正确性验证。

l        要为CBD的开发流程建立一个合理的过程模型，特别要研究如何为扮演不同角色的开发者分配相应的任务，例如软件体系结构设计师负责软件构架设计的详细职责和结果验收标准。

l        要有支持描述技术和过程模型的辅助开发工具，至少需要具备开发构件、实现应用系统和生成文档的工具。理想的开发工具还包括关键系统特征的验证工具。

显见，上述这些问题和前面介绍的软件复用目的和任务紧密相关， 必须从软件复用的认识高度分析CBD方法中存在的问题，重点是使用知识表示方法和演化计算方法解决构件的语义模型和自动过程问题，包括CBD原理和技术中的构件模型、构件体系结构和描述语言和基于构件的开发过程等几方面内容。

二、          CBSE/CBD的工程学目标

 

CBSE/CBD的工程学（管理）目标如下：

（1）     降低费用：这是所有软件开发方法学的共同目标，CBSE/CBD把成本效率提高到软件复用方法的最高境界。

（2）     方便装配：CBSE/CBD的最大特征是一系列构件的装配过程。

（3）     提高复用性：全面考虑构件在多个应用系统中的复用潜力。

（4）     提高可定制性和适应性：开发者可以按需配置构件；

（5）     提高可维护性：在系统中可以方便地添加、删除和修改构件。

三、          CBSE/CBD的技术目标

 

CBSE/CBD的技术目标如下：

（1）     降低耦合：耦合指构件之间的相关性；

（2）     提高内聚：内聚指构件内元素之间的相关性；

（3）     控制粒度：粒度系统中构件对应问题域的规模，包括构件数量和大小两个方面；

四、          CBSE/CBD的研究方向

 

CBSE/CBD的研究方向：

（1）             基于构件软件工程方法的概念模型过程模型；

（2）             构件模型：研究构件的本质特征及构件间的关系；

（3）             构件获取：有目的的构件生产和从已有系统中挖掘提取构件；

（4）             构件描述语言：以构件模型为基础，解决构件的精确描述、理解及组装问题；

（5）             构件库（构件分类与检索）：研究构件分类策略、组织模式及检索策略，建立构件库系统，支持构件的有效管理；

（6）             构件集成组装：在构件模型的基础上研究构件组装机制，包括源代码级的组装和基于构件对象互操作性的运行级组装；

（7）             标准化：构件模型的标准化和构件库系统的标准化；

（8）             构件系统的安全性问题和时效（real-time）问题;

（9）             非技术因素对CBD的影响：法律法规、商业实践、组织结构等方面的挑战和策略。

 

 

参考文献：

 

[Brown00]	A. Brown. Large-Scale Component-Based Development. New Jersey: Prentice Hall, Inc., 2000.
[Szyperski97]	C. Szyperski. Component Software-Beyond OO Programming. Addison-wesley,1997
[OMG01]	OMG CORBA, http://www.corba.org,2001
[Microsoft01]	Microsoft corporation, http://www.microsoft.com/com,2001
[Box99]	Don Box, Essential COM, Addison-Wesley, ISBN 0-201-63446-5,1999
[Perrone01]	Paul J. Perrone, et al. J2EE构建企业系统—专家级解决方案. 北京: 清华大学出版社, 2001
[Clements95]	P.C. Clements, From Subroutines to Subsystems: Component Based Software Development. American Programmer, vol. 8, No. 11, November 1995.
[Petre00]	Luigia Petre. Components vs. Objects. Turku Centre for Computer Science, TUCS Technical reports, No 370, October 2000
[Bergner99]	Klaus Bergner, Andreas Rausch, Marc Sihling, Alexander Vilbig. Componentware – Methodology and Process，19th March 1999
[Booch01]	Grady Booch, James Rumbaugh, Ivar Jacobson著.邵维忠、麻志毅、张文娟、孟祥文译，UML用户指南,机械工业出版社，2001.6