可复用构件
可复用构件是指可以在多个软件系统的开发过程中被重复使用的的软件产品。它可
以是需求分析、系统设计、程序代码、测试用例、测试数据、软件文档以及软件开发过
程中产生的其他软件产品。可复用构件是一种特殊的软件产品，它与只在一个软件系统
中使用的软件产品相比具有较大的差异。为了使可复用构件在软件开发过程中能被高
效、方便的重复使用，以达到提高软件开发的效率和质量、降低开发成本的目的，对可
复用构件一般有以下的要求：
（1）可复用构件应该具有功能上的独立性与完整性
建立构件  组装应用
生产者复用                消费者复用
     （为复用开发构件）       （使用构件开发应用）
图 6.1 生产者复用与消费者复用 4
一个可复用构件应该具有相对独立的完整功能，构件与构件之间的联系应该尽可能
少，彼此之间应该具有较为松散的耦合度，并且构件与构件之间的交互应该通过良好定
义的接口进行。一个功能不完整，与其他构件耦合紧密的构件对于复用是非常不利的。
（2）可复用构件应该具有较高的通用性
可复用构件的通用性的高低在很大程度上决定着它的适用范围。如果一个构件只能
在一个很特殊的环境或者条件下使用，那么它的复用程度是很低的，这也就失去了开发
可复用构件的意义。一般来说，构件的通用性（一般性）越高，它的适用范围就越广，
相应的可复用程度就越高，也就越能充分发挥软件复用的优势。所以在开发构件时，应
该尽量提高构件的通用性（一般性），使其可以在更多的软件系统的开发中被重复使用。
（3）可复用构件应该具有较高的灵活性
虽然可复用构件一般都具有较高的通用性，但是由于可复用构件被复用的软硬件环
境可能差异极大，要开发出一个不需要做出任何调整或修改就可以直接适用于许多不同
环境的构件是不现实的。所以可复用构件应该允许构件的用户根据具体情况对构件进行
适当的调整，以适应不同用户和环境的具体要求。因此在开发可复用构件时，应该提供
灵活的构件调整机制，以方便构件的重复使用，扩大构件的适用范围。
（4）可复用构件应该具有严格的质量保证
由于可复用构件是组装软件系统的“零部件”，如果构件的质量都无法保证，那么
使用构件组装的软件系统的质量保证也就无从谈起，也就更谈不上提高软件开发的质
量。因此构件的质量是软件系统质量的一个基本保证。所以在一个可复用构件被提供给
用户使用以前，必须对构件进行充分的测试，尽可能多地发现并纠正构件中的错误，同
时在复用构件的过程，如果发现构件潜藏的错误，要及时的加以修改。可复用构件的可
靠质量是其被复用的基础。因为可复用构件会在不同的软件系统中被重复使用，因此在
对构件进行测试时，需要考虑该构件在不同的软硬件环境中，构件是否是健壮和可靠的，
是否会出现与兼容性有关的错误。所以对于构件的测试工作应该在不同的软件和硬件环
境中进行。
（5）可复用构件应该具有较高的标准化程度
用于组装一个软件系统的可复用构件可能是由不用的组织或个人开发的，甚至可能
是采用不同编程语言编写的,这些存在很大差异的构件要在一个软件系统中和谐共存，
并且进行有效的交互（例如数据通信和功能调用），以构成一个完整的应用。这要求这
些异质的构件具有定义良好的接口，使构件之间的交互能够通过标准化的接口进行，使
得不同构件的组装变得容易。可见一个构件的标准化对构件的重用是至关重要的。所以
许多公司和学术组织正在积极的进行构件标准化的研究和实践，例如微软公司的 COM 和
OMG 的 CORBA 就是这方面的典型代表。
6.2.2 基于构件的软件工程
基于构件的软件工程与传统的或面向对象的软件工程相比，有着显著的差异。在软
件开发的各个阶段，开发人员应不断的考虑需要完成的这部分工作是否可以通过使用现
成的可复用构件组装完成，而无需从头开始构造，以此达到提高效率和质量，降低成本
的目的。例如在系统编码阶段，开发人员应考虑是否可以复用已有的源代码或目标代码；
在系统测试阶段，应考虑是否有可供重复使用的测试用例和测试数据。通过在软件开发5
的各个阶段，充分考虑重复使用已有软件产品，达到软件复用的目的，避免人力和财力
不必要的浪费和重复建设。
开发人员在选用可复用构件时，需要考虑：（1）是否存在企业组织内部开发的构件
可以满足需要？（2）是否存在第三方的商业构件可供使用？（3）选用的构件是否与系
统的其他部分和运行环境兼容？同时开发人员需要对不能由现成的可复用构件满足的
需求，使用传统的或面向对象的软件工程进行开发。对选用的可复用构件需要进行的开
发活动包括：（1）构件合格性认证（2）构件适应性的修改（3）构件组装（4）构件更
新。
基于构件的软件的开发过程包括两个并发的子过程，一个是领域工程，另一个是基
于构件的开发。领域工程完成一组可复用构件的标示、构造、分类和传播；基于构件的
开发完成使用可复用构件构造新的软件系统的工作。

常用构件标准

　　1.'COM/DCOM/COM+

　　COM是个开放的组件标准，它有很强的扩充和扩展能力。COM把组件的概念融入到Windows虚用中。DCOM在COM的基础上添加了许多功能和特性，包括事务特性、安全模型、管理和配置等，使COM成为一个完整的组件架构。COM+将COM、DCOM和MTS形成一个全新的、功能强大的组件架构。

　　DCOM是基于客户机和服务器模型的，客户程序和构件程序是相对的，进行功能请求调用的是客户程序而响应该请求的是构件程序。构件程序也可以作为客户程序去调用其他的构件程序，正是这种角色的转换和相互调用关系使构件程序最终构成一个软件系统。

　　COM+并不是COM的新版本，我们可以把它理解为COM的新发展，或者为COM更高层次上的应用。COM+的底层结构仍然以COM为基础，它几乎包容了COM的所有内容。COM+倡导了一种新的概念，它把COM组件软件提升到应用层而不再是底层的软件结构，它通过操作系统的各种支持，使组件对象模型建立在应用层上，把所有组件的底层细节留给操作系统。

　　COM+不再局限于COM的组件技术，它更加注重于分布式网络应用的设计和实现，已经成为Microsoft系统平台策略和软件发展策略的一部分。COM+继承了COM几乎全部的优势，同时又避免了COM实现方面的一些不足。COM+紧紧地与操作系统结合起来，通过系统服务为应用程序提供仝面的服务。

　　2.CORBA

　　CORBA（Common Object Request Broker Architecture,公共对象请求代理架构）是由OMG组织制订的一种标准的面向对象的应用程序体系规范。或者说CORBA架构是对象管理组织（Object Management Group,OMG）为解决分布式处理环境（DistributedComputing Envifonment,DCE）中硬件和软件系统的互连而提出的一种解决方案。

　　OMG组织成立后不久就制订了对象管理架构（Object Management Architecture,OMA）参考模型，该模型描述了OMG规范所遵循的概念化的基础结构。OMA由对象请求代理ORB、对象服务、公共设施、。域接口和应用接口这几个部分组成，其核心部分是对象请求代理（Object Request Broker, ORB）。对象服务是为使用和实现对象而提供的基本服务集合：公共设施是向终端用户应用程序提供的一组共享服务接口；域接口是为应用领域服务而提供的接口：应用接口是由开发商提供的产品，用于它们的接口，不属于OMG标准的内容。ORB提供了一种机制，通过这种机制，对象可以：透明她发出请求和接收响应。分布的、可以互操作的对象可以利用ORB构造可以互操作的应用。

　　CORBA标准由OMG设立并进行控制。CORBA分布计算技术，是由绝大多数分布计算平台厂商所支持和遵循的系统规范技术，具有模型完整、先进，独立于系统平台和开艟语言，被支持程度广泛的特点，已逐渐成为分布计算技术的标准。COBRA标准主要分为三个层次：对象请求代理、公共对象服务和公共设施。昂底层是对象请求代理ORB,规定了分布对象的定义（接口）和语言映射，实现对象间的通讯和互操作，是分布对象系统中的“软总线”;在ORB之上定义了很多公共服务，可以提供诸如并发服务、名字服务、事务（交易）服务、安全服务等各种各样的服务；最上层的公共设施则定义了组件框架，提供可直接为业务对象使用的服务，规定业务对象有效协作所需的协定规则。

　　3.EJB

　　EJB用于封装业务，而业务可分为业务实体和业务过程。在J2EE模型当中，中间层的业务功能通过EJB构件实现，使用JsP实现业务逻辑处理结果的动态发布，构成动态的HTML页面，中间层也可以使用Servlet实现更为灵活的动态页面。

　　EJB组件存活在EJB容器中，客户应用程序通过其业务和主接口访问它们。主接口封装构件的生命周期方法（创建、破坏、查找）。业务口定义了业务方法，客户使用EJB组件的主接口来获取对EJB组件的业务接口的引用；实现类是真正的分布式对象，在运行时被实例化i客户端对业务接口的调用实际是对实现类的访问。