基于构件的软件复用技术研究与应用实践之令狐文艳创作

基于构件的软件复用技术研究与应用实践

令狐文艳

基于构件的软件复用技术研究

谷今杰莫继红 ((湖南大学软件学院，长沙410082)

通常情况下．应用软件系统的开发过程包含以下几个阶段：需求分析、设计、编码、测试、维护等。当每个应用系统的开发都是从头开始时，在系统开发过程中就必然存在大量的重复劳动，如：用户需求获取的重复、需求分析、编码、测试的重复和文档等。探讨应用系统的本质，发现其中通常包含：①通用基本构件：是特定于计算机系统的构成成分，如基本的数据结构、用户界面元素等，它们可以存在于各种应用系统中；②领域共性构件：是应用系统所属领域的共性构成成分，它们存在于该领域的各个应用系统中；③应用专用构件：是每个应用系统的特有构成成分。应用系统开发中重复劳动主要在于前两类构成成分的重复开发。

软件复用是在软件开发中避免重复劳动的解决方案。其出发点是应用系统的开发不再采用一切“从零开始”的模式，而是以已有的工作为基础，充分利用过去应用系统开发中积累的知识和经验，如：需求分析结果、设计方案、源代码、测试计划及测试案例等．从而将开发的重点集中于应用的特有构成成分。通过软件复用，在应用系统开发中可以充分利用已有的开发成果．消除了包括分析、设计、编码、测试等在内的许多重复劳

动，从而提高了软件开发的效率：同时，通过复用高质量的已有开发成果时，避免了重新开发可能引入的错误，从而提高软件的质量。

软件复用指重复使用“为了复用目的而设计的软件”的过程。相应地，可复用软件是指为了复用目的而设计的软件。与软件复用的概念相关，重复使用软件的行为还可能是重复使用“并非为了复用目的而设计的软件”的过程，或在一个应用系统中的不同版本间重复使用代码的过程，这两类行为都不属于严格意义上的软件复用。真正的复用是为了支持软件，使用“为复用而开发的软件(构件)”来更快、更好地开发新的应用系统。复用技术在整体上对软件产业的影响却并不尽如意。这是由于技术方面和非技术方面的种种因素造成的，其中技术上的不成熟是一个主要原因。近十几年来，面向对象技术出现并逐步成为主流技术，为软件复用提供了基本的技术支持。软件复用研究重新成为热点。被视为解决软件危机。提高软件生产效率和质量的

现实可行途径。

（复用分类）软件复用可以从多个角度进行考察。依据复用的对象，可以将软件复用分为产品复用和过程复用。产品复用指复用已有的软件构件．通过构件集成(组装)得到新系统。过程复用指复用已有的软件开发过程．使用可复用的应用生成器来自动或半自动地生成所需系统。过程复用依赖于软件自动化技术的发展，目前只适应于一些特殊的应用领域。产品复用是目

前现实的、主流的途径。

依据对可复用信息进行复用的方式。可以将软件复用区分为黑盒(Black—box)复用和白盒(White—box)复用。黑盒复用指对已有构件不需作任何修改，直接进行复用。这是理想的复用方式。白盒复用指已有构件并不能完全符合用户的需求。需要根据用户需求进行适应性修改后才使用。而在大多数应用的组装过程中，构件适应性修改是必需的。

软件复用按抽象程度的高低, 可以划分为如下的复用级别: (1) 代码的复用, 包括目标代码和源代码的复用。当前大部分编程语言的运行支持系统都提供了连接(L ink) 、绑定(Binding) 等功能来支持这种复用; ( 2) 设计的复用, 设计结果比源程序的抽象级别更高, 因此它的复用受到实现环境的影响较少, 从而使可复用构件被复用的机会更多, 并且所需的修改更少; (3) 分析的复用, 可复用的分析成分是针对问题域的某些事物(问题) 的抽象程度更高的解法。

软件复用有三个基本问题．一是必须有可一是必须有可以复用的对象。二是所复用的对象必须是有用的。三是复用者需要知道如何去使用被复用的对象。软件复用包括两个相关的过程：可复用软件(构件)的开发

(Development, for Reuse)和基本可复用软件(构件)的应用系统构造(集成和组装)(Development withReuse)。解决好这几个方面的问题才能实现真正成功的软件复用。

2构件技术

2．1构件技术模型

构件复用是软件复用的核心问题，因此有关构件的研究得到日益重视并且形成了软件工程学科的一个分支。在产业界正在逐渐形成一种产业模式，即构件生产商负责生产构件，构件销售商负责构件的销售，构件集成商负责构件集成。目前已经商品化的构件有微软的COM／DCOM、Sun公司的Java Bean和对象管

理组织(OMG)的CORBA。

构件是一种不透明的功能实现．要通过构件模型进行构造，要能够与第三方进行合成，这样就存在构件模型标准化的问题。构件模型的标准化要能同时满足构件生产者和构件消费者需求，学术界普遍接受的是“3C”(Concept，Content，Context)模型[2]，即component=(Concept，Content，Context)，在这个模型中：

Concept：概念．描述软件完成什么功能。描述构件的接口和

语义，概念和内容(Content)能够进行通信；

Content：内容，描述如何实现这个构件，一般情况下，构件

的内容信息对临时用户是隐藏的。只有需要对构件作修改的用户才是可知的；

Context：上下文、组件在其适用领域内的配置，通过对概

念、操作和实现特征的详细说明。上下文能够使软件寻找到满足应用需求的组件。

2．2构件的开发

构件的开发技术有多种．其中比较有代表性的是CBSD技术。

CBSD是CMU／SEI提出的构件设计参考模式，这种设计模式的原则是：组件具的扩充独立性：组件模型必须给出一些标准以保证独立开发的组件能够配置到公共的环境中，而不会出现不可预知的问题；开发时间短，这样会减少整个开发和维护费用；提高可预知性。

基于构件的系统来源于基于构件的设计策略，构件技术包括支持这种设计策略的产品的概念，这种设计策略与组件描述的设计模式和交互模式的构造类型非常相近，组件(即构件)反映的设计模式如图1。

图1中，①构件实现是能够在物理或者逻辑设备中执行的软件实现。一个构件可以有一个或者多个接口②。构件满足一定的规范，这里称为契约，这些契约的作用是保证独立开发的构件符合给定的规则，以便以可预知的方式进行交互并配置到标准的建造环境和运行环境④中。基于构件的系统是建立在少数不同的构件类型上。每一个构件的类型在⑤中扮演的一个特定的角色，由接口②对其进行描述。构件模型⑥是组件类型、接口和组件间相互作用的模式说明书集合。构件构架⑦提供多种服务⑧来支持和加强构件模型。

3 COTS构件

当前的软件已不再是一个简单的系统．规模越来越大，通常是一复杂的“系统中的系统”。大型软件尤其如此，从头开始做每一件事情来建造系统几乎是不可能的。于是出现了

COTS(Commercial OffThe Shelf)技术。COTS构件是从市场上