在
软件工程的范围内，复用既是旧概念，也是新概念 。
程序员从最早的计算机时代开始，就已经开始复用概念、对象、论据、抽象和过程，但是早期的途径是特定的。今天，复杂的、高质量的基于计算机的系统必须在非常短的时间内建立，这要求更有组织的复用方法。
基于组件的软件工程（component-based software engineering,CBSE）是强调使用可复用的
软件组件来设计和构造基于计算机的系统。
系统开发
从表面看，CBSE似乎类似于传统的或
面向对象的软件工程。当软件小组使用传统的需求诱导技术建立了待建造系统的需求时，该过程开始，系统结构设计被建立，但是，并不是立即转向更细节的设计任务，小组检查需求以确定系统的什么子集可以直接通过组装而不是构造完成。也就是说，小组针对每个系统需求询问如下问题：
l 是否存在商用成品组件（component off-the-shelf，COTS）可实现该需求？
l 是否存在内部开发的可复用组件可实现该需求？
l 可用组件的接口与待建系统兼容吗？
小组试图修改或去除那些不能用COTS和自有组件实现的系统需求。如果需求不能被修改或删除，传统的或面向对象的
软件工程方法被用于开发那些必须被开发以满足需求的新组件。但是，对那些可被现存组件满足的需求，采用不同的
软件工程活动：
l 组件合格性认证。系统需求和
体系结构定义了所需的组件。可复用的组件（不管是COTS的还是自有的）通常是通过它们的接口特征来标识的，即“被提供的服务，以及客户访问这些服务的方式”被作为组件接口的一部分而描述。但是，接口并不提供组件是否符合
体系结构和需求的全面描述。
软件工程师必须通过一个发现和分析过程来认证每个组件的合格性。
l 组件适应性修改。
软件体系结构表示了由组件（功能性单元）、连接和协同构成的设计模式。在某些情形中，现存的可复用组件可能和
体系结构的设计规则不匹配，这些组件必须被自适应以满足体系结构的需要或被丢弃而被其它更合适的组件代替。
l 组件组装。
体系结构风格再次在
软件组件被集成以形成工作系统的方式中扮演了关键角色。通过标识连接和协同机制（如设计时的运行时性质），
体系结构指导最终产品的组装。
l 组件更新。当系统由COTS组件实现时，更新由于第三方的进入而变得复杂（即开发可复用组件的组织可能是在
软件工程组织的直接控制范围之外）。
领域工程
领域工程的目的是标识、构造、分类和传播一组
软件组件，它们对某特定应用领域中现存的和未来的
软件系统具有很好适用性。其整体目标是建立相应的机制，来使得
软件工程师在开发新的或现存的系统时可以共享这些软件复制品。领域工程包括三个主要的活动----分析、构造和传播。
CBSE过程
CBSE过程的刻画：不仅标识候选的组件，还认证每个组件接口合格性、适应性修改组件以消除
体系结构不匹配、组装组件到选择的体系结构风格中以及当系统需求变化时更新组件。
基于组件的软件工程的工程模型强调并行的轨迹，其中
领域工程和基于组件的开发并发地发生。
领域工程完成一系列工作，以建立一组可以被其它
软件工程师复用的
软件结构，然后这些软件结构被越过分隔领域工程和基于组件的开发的“边界”传送
领域工程创建应用领域的模型，该模型被用作在
软件工程流中分析用户需求的基础。类属的软件体系结构为应用的设计提供了输入。最后，在可复用组件已经被购买、从现存库中选出或构造好后（作为
领域工程的一部分），它们可以被从事基于组件开发的
软件工程师使用。
基于组件开发
基于组件的开发是一个和
领域工程并行发生的CBSE活动。一旦
体系结构被建立，它必须用组件去充实，这些组件或者可从复用库中获得，或者根据专门需要而开发。因此，基于组件的开发的任务流有两个并行的路径。当可复用组件可被用于潜在地集成进
体系结构中时，它们必须被进行鉴定和适应性修改。当需要新的组件时，必须重新开发，然后，产生的新组件被“组装”（集成）到
体系结构模板中，并进行全面测试。
组件鉴定、适应性修改和组装
如我们已经看到的那样，
领域工程提供了
基于组件的软件工程所需的可复用组件的库。某些可复用组件是自行开发的，有些可从现存系统中抽取得到，而有些可从第三方获得。
不幸的是，可复用组件的存在并不能保证这些组件可以被容易地或有效地集成到为新应用选择的体系结构中。正是为此，当某些组件被提交复用时，一系列基于组件的开发活动被进行。
(1)组件鉴定
组件的鉴定保证某候选组件将完成所需的功能，将合适地“安装”到为系统选定的
体系结构风格中，并且将展示该应用所需的质量特性（如性能、可靠性、可用性）。
接口描述提供了关于组件的操作和使用的有用信息，但是，它并不提供确定是否被提出的组件能够事实上被有效地复用于新的应用中所需的所有信息。在组件认证中考虑的很多因素是：
l 应用编程接口（API）。
l 组件所需的开发和集成。
l 运行时需求，包括资源使用（如内存和
存储器）、时间或速度以及网络协议。
l 服务需求，包括
操作系统接口和来自其它组件的支持。
l 嵌入式设计假定，包括特定的数值或非数值算法的使用。
当开发自身的可复用组件被提出时，这些因素的每一个均是相当容易评估的。如果好的
软件工程实践被应用于软件开发中，对所列出的这些问题的回答可以得到。然而，确定COTS或第三方组件的内部细节是相当困难的，因为唯一可用的信息可能只是接口规定本身。
(2)组件适应性修改
在理想的情况下，
领域工程创建可以被容易地集成到应用
体系结构中的组件库。“容易集成”的含义是：
l 对库中的所有组件已经实现了一致的资源管理方法
l 对所有组件存在诸如数据管理等公共活动
l 已经以一致的方式实现了体系结构内部及外部环境的接口
在现实中，即使在组件已经针对在应用
体系结构中的使用而进行过认证，它也可能在刚才提到的一个或多个区域中展示出冲突。为了缓解这些冲突，经常使用一种称为组件包装的适应性技术。当软件小组对某组件的内部设计和代码有完全的访问权时，可以进行白盒包装。和其软件测试中的对应物一样，白盒包装检查组件的内部处理细节，并通过代码级的修改以消除任何冲突。当组件库提供了使得能够消除或掩盖冲突的组件扩展语言或API时，可以使用黑盒包装。黑盒包装需要在组件接口中引入前处理、后处理以消除或掩盖冲突。软件小组必须确定是否适应性地包装组件所需的工作量是值得的或是否应该代之以开发定制组件（专门设计以消除遇到的冲突）。
(3)组件组装
组件组装任务将认证后的、适应性修改后的和开发的组件组装到为应用建立的
体系结构中。为了达成此目标，必须建立一个基础设施以绑定组件到某运行系统中。该基础设施（通常是专门组件的库）提供了组件协同的模型和使组件能够相互协同并完成共同任务的特定服务。
在很多用于创建有效的基础设施的机制中，一组4个“
体系结构成分”将用于实现组件的组装：
l 数据交换模型。对所有的可复用组件应该定义使用户和应用间能够交互和传递数据的机制（例如，拖和放、剪切和粘贴）。数据交换机制不仅应允许人到软件、组件到组件的数据传递，而且也应使得能够在
系统资源间进行数据传递（例如，将一个文件拖到某打印机图符上以实现输出）。
l 自动化。应实现一系列工具、宏和脚本以帮助可复用组件间的交互。
l 结构化存储。包含在一个“
复合文档”中的异质数据（例如，图形数据、声音、文本和数值数据）应该被作为单独的数据结构组织和访问，而不是作为一组分开的文件。“
结构化数据维持了嵌套结构的一个描述性索引，应用可以自由地进行导航浏览以定位、创建或编辑个体数据内容，就像终端用户直接操作一样”。
l 底层对象模型。对象模型保证在不同平台上用不同
程序设计语言开发的组件可以互操作，也就是说，对象必须能够跨网络进行通信。为了达到这个目标，对象模型定义了组件互操作的标准。
因为复用和CBSE对软件产业的潜在影响非常巨大，一些主要的公司和产业联盟已经提出了一些
构件软件的建议标准：
l OMG/CORBA。对象管理组织发布了
公共对象请求代理体系结构（OMG/CORBA），一个对象请求代理（ORB）提供了一系列服务，它们使得可复用组件（对象）可以和其它组件通信，不管它们在系统中的位置如何。当组件用OMG/CORBA标准建立时，那些组件在某系统内的集成（没有修改）可以得到保证，如果对每个组件创建一个接口定义语言（IDL）接口。使用客户/服务器的比喻，在客户端应用中的对象向ORB服务器请求一个或多个服务，请求是通过IDL或在运行时动态地进行的。一个接口池包含了所有关于服务请求和响应格式的信息。
l
微软的COM。
微软开发了一个
组件对象模型（COM），它提供了在运行于Windows操作系统之上的单个应用中使用不同厂商生产的对象的规约。COM包括两个元素：COM接口（实现为COM对象）和在COM接口间注册和传递消息的一组机制。从应用的观点看，“重点不在于COM对象如何被实现，仅在于一个事实：对象具有在系统中注册的接口，且对象使用组件系统和其它COM对象通信”。
l SunJavaBean。SunJavaBean组件系统是一个可移植的、平台独立的CBSE基础设施，使用Java
程序设计语言开发。JavaBean系统扩展了Java Applet以适应基于组件的软件开发所需的更复杂的软件
构件。JavaBean
构件系统包含一组工具，称为Bean开发工具箱（Bean Development Kit,BDK），它允许开发者作以下工作：
Ø 定制他们的行为和外观
Ø 建立协同和通讯机制
Ø 开发用于特定应用的定制Bean
Ø 测试和评估Bean的行为
这些标准中哪一个将在产业中占据支配地位？这不是当前容易回答的问题。虽然很多开发者已经选择了某个标准，但是，根据应用的类别和选定的平台有可能大型软件组织将选择使用所有三个标准。
为了复用的分析和设计
理想地，分析模型被分析以确定模型中的那些指向现存的可复用软件制品的元素。问题是以能够导致“规则匹配” 的形式从需求模型中抽取信息。Bellinzoni、Gugini和Pernici描述了一种针对
面向对象系统的方法：
组件被在不同的抽象层次定义和存储为规约、设计和实现类——每个类是来自以前应用的某产品的工程化描述。规约知识（开发知识）被以复用建议类的形式存储，它们包括各种用法指导，例如，对以组件的描述为基础检索可复用组件的指导，对在组件检索完成后组装和剪裁组件的指导。
自动工具被用于浏览组件库，通过试图匹配在当前规约中记录的需求和那些对现存可复用组件（类）描述的需求。领域特征和关键词被用于发现潜在的可复用组件。
如果规约匹配产生符合当前应用的组件，设计者可以从可复用组件库中提取这些组件并将它们用于新系统的设计中。如果设计组件没能找到，
软件工程师必须应用传统的或
面向对象的设计方法去创建它们。正是在这点（当设计者开始创建新的组件时）为了复用的设计（Design for reuse,DFR）应该被考虑。
作为为了复用的设计的基础而应该考虑的一系列关键问题：
l 标准数据。应该研究应用领域，标识出标准的全局
数据结构（例如，文件结构或完整的数据库），所有设计组件可以通过使用这些标准数据结构来刻画。
l 标准
接口协议。应该建立三个层次的接口协议：模块内接口的本质、外部技术（非人）接口的设计以及人机界面。
l 程序模板。结构模板可作为新程序的
体系结构设计的模板。
一旦标准数据、接口和程序模板已经建立，设计者就有了一个可在其中创建设计的
框架，新的符合这个框架的组件对以后的复用有更高的概率。
分类检索组件
考虑一个大的大学图书馆，数万本的书籍、期刊和其它信息资源都是可用的。但是为了访问这些资源，必须有合适的分类模式。为了在这些大量的信息中导航浏览，图书馆管理者定义了一种分类模式，它包括分类码、关键词、作者名以及其它索引条目，所有这些都使用户可以快速而方便地找到需要的资源。
考虑一个大的组件存储库，成千上万的可复用组件存放在其中。但是，
软件工程师如何找到他所需要的组件呢？为了回答这个问题，又出现了另外一个问题：我们如何以无二义性的、可分类的术语来描述
软件组件呢？
描述可复用组件
可复用软件组件可用很多方法来描述，但是理想的描述是围绕Tracz提出的3C模型——概念、内容和语境。
软件组件的概念是“对组件做什么的描述”。组件的接口被完整地描述，而且在前置条件和后置条件的语境中被表示的语义标识。概念将传达组件的意图。
组件的内容描述概念如何被实现。在本质上，内容是对一般用户隐藏的信息，只有那些企图修改该组件的人需要了解它。
语境将可复用
软件组件放置到其可应用的领域中。也就是说，通过刻画概念的、操作的和实现的特征，语境使得
软件工程师能够发现适当的组件以满足应用需求。
为了在实际环境中可用，概念、内容和语境必须被翻译为具体的规约模式。
主要使用图书馆科学方法进行组件分类。
“受控的索引词汇”限制了可以用来分类对象（组件）的术语和语法，“不受控的索引词汇”则对描述的性质没有限制。大多数
软件组件分类模式可归为以下三类：
(1)枚举分类。通过定义一个层次结构来描述组件，在该层次中定义了
软件组件的类以及子类的不同层次。实际的组件被罗列在枚举层次的任何路径的最低层，例如，对窗口操作的枚举层次可能是：
window operations
display
open
menu-based
openwindow
system-based
sysWindow
close
via pointer
…
resize
via command
setWindowSize,stdResize,shrinkWindow
via drag
pullWindow,stretchWindow
up/down shuffle
…
move
…
close
…
枚举分类模式的层次结构使得它易于理解和使用，然而，在建立层次之前，必须进行
领域工程，使得在层次中适当的项含有足够的信息。
(2)刻面分类。领域被分析，可以标识出一组基本的描述特征，这些特征成为刻面，刻面被根据其重要性区分优先次序并被联系到组件。一个刻面可以描述组件完成的功能、被操作的数据、组件应用的语境或任意其它特征。描述组件的刻面的集合称为刻面描述子，通常，刻面描述被限制在不超过7或8个刻面。
作为一个简单的使用刻面组件分类的例子，考虑使用下列组件描述子的模式：
{function,object type,system type}
在刻面描述子中的每个刻面可取一个或多个值，这些词一般是描述性关键词，例如，如果功能是某组件的刻面，可赋给该刻面的典型值可能为：
function=(copy,from) or (copy,replace,all)
多个刻面值的使用使得原函数copy能够被更完全地精化。关键词被赋给在复用库中每个组件的刻面集，当某
软件工程师在设计中希望查询组件库以发现可能的组件时，一个值表被给出，然后到库中去寻求匹配。使用的自动工具可以结合词典功能，这样使得查找不仅仅考虑
软件工程师给出的关键词，还考虑这些关键词的技术同义词。刻面分类模式给
软件工程师在刻画组件的复杂描述子是带来了更大灵活性，因为新的刻面值可以很容易地加入，因此，刻面分类模式比枚举分类方法更易于扩展和适应。
(3)属性-值分类。为领域中的所有组件定义一组属性，然后为这些属性赋值，其方式和刻面分类方法非常相似。事实上，属性-值分类方法和刻面分类方法是类似的，除了下面几点不同：
l 对使用的属性的数量没有限制
l 属性没有优先级
l 不使用词典功能
复用环境
软件组件复用必须有环境的支撑，一个复用环境应包含如下元素：
l 能存储组件和查找组件必需的组件分类信息的组件数据库。
l 提供对组件数据库访问的库管理系统。
l 允许客户应用从组件库服务器中检索组件和服务的
软件组件检索系统（如
对象请求代理）。
l 支持被复用的组件到新设计或新实现中集成的CASE工具。
这些功能的每一个在复用库的范围内交互或者被包含在复用库中。
复用库是一个大型CASE中心
存储库的一个元素，并且为一系列可复用软件制品（例如，规约、设计、代码、测试案例、用户指南）的存储提供设施。复用库包含了一个数据库以及必需的支持数据库查询和组件检索的工具，组件分类模式是组件库查询的基础。
查询经常用前面描述的3C模型中的语境来刻画，如果某初始查询产生大量的候选组件，则查询被求精以减少候选对象。然后，概念和内容信息被抽取出来（在候选组件集得到后）以辅助开发者选择合适的组件。
CBSE经济学
在直觉上，
基于组件的软件工程是很有吸引力的。从理论上讲，它将为软件组织提供在质量和时间上的优势，而这些将直接导致成本的节省。
对质量、生产率和成本的影响
大量来自产业实例研究的证据表明从积极的
软件复用可以导出实质性的商业收益、开发生产率和整体成本都将得到改善。
(1)质量
理想情况下，为了复用而开发的
软件组件已被验证是正确的且不含有错误。在现实中，形式化验证并不能例行公事地进行，错误可能而且也确实存在。然而，随着每一次复用，错误被发现和消除，组件的质量也随之改善。随着时间的推移，组件变成实质上无错误的。
在HP公司的研究中，Lim报告说：被复用代码的
缺陷率是每KLOC有0.9个缺陷，而新开发代码的缺陷率是每KLOC有4.1个缺陷。对一个包含复用代码的应用来说，
缺陷率是每KLOC有2.0个缺陷——相对应用的无复用开发，对期望的缺陷率有51%的改善。Henry和Faller的研究指出在质量上有35%的改善。虽然不同的报告跨越了质量改善百分率的一个合理的范围，但是，显然我们可以说，复用对交付的软件在质量和可靠性方面确实带来的实质性的收益。
(2)生产率
当可复用软件制品被应用于软件开发过程中，在创建对开发一个可交付系统所需要的计划、模型、文档、代码和数据方面所花费的时间自然要少，导致的结果是：用较少的努力给客户提供了相同级别的功能，因此生产率得到了改善。虽然，对生产率改善百分率的报告是众所周知难于解释的，但是，似乎30%到50%的复用可以生产25%到40%的生产率改善。
(3)成本
复用带来的纯成本节省如下估算：估算出项目如果是从头开始开发所需的成本Cs，然后减去和复用关联的成本Cr与软件被交付时实际Cd的本质和。
和复用相关的成本Cr包括：
l 领域分析和建模。
l 为方便复用所增加的文档量。
l 可复用组件的支持和增强。
l 对从外部获取的组件的版税和许可证费。
l 对设计和构造复用人员的培训。
复用度量
为了测试复用在基于计算机的系统中的收益，已有一系列的
软件度量体系被提出。在系统S中和复用关联的收益可以表示为：
R(S)=(Cnoreuse-Creuse)/Cnoreuse (3.1)
其中，Cnoreuse是不基于复用开发的成本， Creuse是基于复用开发的成本。R(S)为如下范围内的无量纲值：
0=＜R(S)＜=1
在
面向对象系统中对复用的一种一般性测度，称为复用倍率(reuse leverage)，被定义如下：
Rlev=OBJreused/OBJbuilt (3.2)
其中，OBJreused是系统中复用的对象数，OBJbuilt是
构件系统的对象数。