软件复用技术

论使用复用设计

1、引言

复用是活动，而不是对象。在创建软件相关的系统的语境中，复用仅仅是非常简单的任何过程，该过程通过复用来自以前开发工作的某些东西来生产(或帮助生产)一个系统。那么，唯一的问题是：复用什么、什么是导致成功复用的过程。

在软件工程的范围内，复用既是旧概念，也是新概念。程序员从最早的计算时代已开始复用概念、对象、论据、抽象和过程，但是我们复用的途径是特定的。

本文对软件复用的讨论，将从以下四个方面进行：

1）软件工程师可以获得一系列可复用的软件制品，这些包括软件的技术表示(例如，规约、体系结构模型、设计和代码)、文档、测试数据，甚至包括过程相关的任务(如，检查技术)。

2）复用过程包括两个并发的子过程：领域工程和软件工程。领域工程的目的是在特定应用领域中标识、构造、分类和传播一组软件制品。然后，软件工程可在新系统开发中选取这些软件制品作为复用。

3）构件复用为软件质量、开发者生产率、以及整个系统成本带来了固有的收益，然而，在复用过程模型被广泛地用于软件产业前，必须克服很多障碍。

4）对可复用构件的分析、设计技术采用和在良好的软件工程实践中使用的相同原则和概念。可复用构件应该在一个环境中设计，该环境为每个应用领域建立标准数据结构、接口协议和程序体系结构。

2、可复用的软件制品

软件复用不仅仅涉及源代码，但是，还涉及多少东西呢？CaperJones定义了可作为复用候选的十种软件制品：

项目计划。软件项目计划的基本结构和许多内容(例如，SQA 计划)均是可以跨项目复用的。这样减少了用于制定计划的时间，也减低了和建立进度表、风险分析和其他特征相关的不确定性。

成本估计。因为经常不同项目中含有类似的功能，所以有可能在极少修改或不修改的情况下，复用对该功能的成本估计。

体系结构。即使当考虑不同的应用领域时，也很少有截然不同的程序和数据体系结构。因此，有可能创建一组类属的体系结构模板(例如，事务处理体系结构)，并将那些模板作为可复用的设计框架。

需求模型和规约。类和对象的模型和规约是明显的复用的候选者，此外，用传统软件工程方法开发的分析模型(例如，数据流图)也是可复用的。

设计。用传统方法开发的体系结构、数据、接口和过程化设计是复用的候选者，更常见的是，系统和对象设计是可复用的。

源代码。验证过的程序构件(用兼容的程序设计语言书写的)是复用的候选者。

用户和技术文档。即使特定的应用是不同的，也经常有可能复用用户和技术文档的大部分。

用户界面。可能是最广泛被复用的软件制品，GUI 软件经常被复用。因为它可占到一个应用的60％的代码量，因此，复用的效果非常显著。

数据。在大多数经常被复用的软件制品中，数据包括：内部表、列表和记录结构，以及文件和完整的数据库。

测试用例。一旦设计或代码构件将被复用，相关的测试用例应该“附属于”它们。

应该注意，复用可以扩展到上面所讨论的可交付的软件制品之外，它也包含了软件工程过程中的元素。特定的分析建模方法、检查技术、测试用例设计技术、质量保证过程、以及很多其他软件工程实践可以被“复用”，例如，如果某软件项目组有效地应用净室软件工程方法，该方法可能适用于另一个项目。为了作出决定，有必要定义一组描述功能，它们使得潜在的净室用户能够对其应用作出适当的决策。

3、复用过程

复用过程包括两个并发的子过程：领域工程和软件工程。

3.1、领域工程

领域工程的目的是标识、构造、分类和传播一组软件制品，它们对某特定应用领域中对现存的和未来的软件系统具有很好适用性。其整体目标是建立相应的机制，以使得软件工程师在工作于新的或现存的系统时可以分享这些软件制品——复用它们。

领域工程包括三个主要的活动——分析、构造和传播。在第20 章中已给出领域分析的概述，然而，本节中将再讨论这个话题。领域构造和传播将在本章以后几节中讨论。

有人争辩说“复用将消失，不是被消除，而是被集成”进软件工程实践之中，随着复用被更多的强调，人们相信在下个十年领域工程将变得和软件工程一样重要。

3.1.1、领域分析过程

在面向对象软件工程范围内领域分析的方法，过程中的步骤定义如下：

1).定义将被研究的领域。

2).分类从领域中抽出的物项。

3).收集领域中有代表性的应用样本。

4).分析样本中的每个应用。

5).开发对象的分析模型。

必须注意，领域分析适用于任意软件工程范型，并且可以用于传统的以及面向对象的软件开发。

Prieto－Diaz扩展了上面给出的领域分析的第二个步骤，建议了一个8 步骤的标识和分类可复用软件制品的方法：

1).选择特定的功能/对象。

2).抽象功能/对象。

3).定义分类法。

4).标识公共特征。

5).标识特定的关系。

6).抽象关系。

7).导出功能模型。

8).定义领域语言。

领域语言使得在领域中进行应用的规约及构造成为可能。

虽然上面的步骤提供了一个有用的领域分析模型，但是它没有提供帮助决定哪些软件制品是复用候选的有用的指南。Hutchinson 和Hindley提出了下面一组实际的问题，它们可以用作标识可复用软件构件的指南：

*构件功能对未来的实现工作是需要的吗？

*在领域中构件功能的公共性怎样？

*在领域中存在构件功能的重复吗？

*构件是否依赖于硬件？

*在不同实现之间硬件是否保持不变？

*硬件细节可被移动到另一个构件吗？

*设计为下面的实现进行过足够的优化吗？

*我们能够将一个不可复用的构件参数化以使其变成可复用的吗？

*构件是否可以仅仅经过少许修改就能够在很多实现中复用吗？

*通过修改进行复用是可行的吗？

*某不可复用的构件能够通过被分解以产生一组可复用构件吗？

*针对复用的构件分解是有效的吗？

关于领域分析的深入讨论不在本书范围之内，更多的信息可见。

3.1.2、结构建模和结构点

当使用领域分析时，分析员寻找在某领域中应用间的重复模式。结构化建模(Structuralmodeling)是一种基于模式的领域工程方法，应用该方法的前提假设是：每个应用领域有重复的模式(功能的、数据的和行为的)，它们具有可复用的潜在可能。

Pollak 和Rissman描述结构建模如下：

结构模型由少量的用于表明清晰的交互模式的结构元素组成。使用结构模型的系统的体系结构通过多个由这些模型元素组成的东西来刻划，这样，在系统的体系结构单元间的复杂交互可以用在这些少量元素间的简单交互模式来描述。

每个应用领域可用一个结构模型来刻划(例如，飞行器电子设备在细节上差异很大，但是在该领域的所有现代软件具有相同的结构模型)，因此，结构模型是一种体系结构制品，它可以也应该在领域内所有应用中被复用。

McMahon描述结构点(structure Point)为：“在结构模型中的一个独特构成物”，结构点有三个显著的特征：

1).一个结构点是一个抽象，它应该有有限数量的实例。用面向对象的行话来陈述，类层次的规模应是小的。此外，该抽象应该在领域中所有应用中不断重现，否则，用于验证、文档化和传播结构点所需的努力不可能是成本合算的。

2).管理结构点的使用的规则应该是容易理解的。此外，结构点的接口应该相当简单。

3).结构点应该通过隐藏所有包含在结构点内部的复杂性而实现信息隐蔽，这会减少整个系统可被感知的复杂性。

作为把结构点当作系统的体系结构模式的一个例子，考虑警报系统的软件领域，该领域可能包含如SafeHome①这样简单的系统，或如工业过程警报系统这样复杂的系统，然而，在每种情形，均可以遇到一组可以预测的结构模式：*界面，使用户能够和系统交互。

*范围设置机制，允许用户设置将被测度的参数的范围。

*传感器管理机制，和所有的监控传感器通讯。

*反应机制，对传感器管理系统提供的输入作出反应。

*控制机制，使用户能够可以控制监控执行的方式。

这些结构点中的每一个被集成到一个领域体系结构中。

定义跨越一组不同的应用领域的类属的结构点是可能的：

*应用前端。GUI，包括所有菜单、面板、输入和命令编辑设施。

*数据库。所有和应用领域相关的对象的仓库。

*计算引擎。操作数据的数值和非数值模型。

*报告设施。产生所有种类的输出的功能。

*应用编辑器。根据用户特定需要定制应用的机制。

结构点已被建议作为在软件成本估计中代码行和功能点的替代物。

4、构件复用

关于创建可复用的软件并没有任何神奇之处。抽象、隐蔽、功能独立性、求精、以及结构化程序设计等设计概念，连同面向对象方法、测试、SQA、以及正确性验证方法——所有均对可复用软件构件的创建有贡献。本节中，我们将不重复讨论这些话题，而是考虑特定于复用的问题，它们是对完整的软件工程实践的补充。

4.1、为了复用的分析和设计

数据、功能和行为模型(用一系列不同符号表示)可以被创建以描述特定应用必须完成的任务，书面的规约被用于描述这些模型并生成完整的需求描述。

理想地，分析分析模型以确定模型中的那些指向现存的可复用软件制品的元素。问题是以能够导致“规约匹配”的形式从需求模型中抽取信息。Bellinzoni 及其同事描述了一种针对面向对象系统的方法：

构件被在不同的抽象层次定义和存储为规约、设计和实现类——每个类是来自以前应用的某产品的工程化描述。规约知识——开发知识——被以复用建议(reuse-suggestion)类的形式存储，它们包括对以构件的描述为基础检索可复用构件及检索后组装和剪裁构件的指导。

使用自动化工具浏览构件库，以试图匹配当前规约中所标记的需求和那些为现存可复用构件(类)描述的需求。领域特征和关键词被用于发现潜在的可复用构件。

如果规约匹配生成符合当前应用需要的构件，设计者可从可复用构件库中提取这些构件并将它们用于新系统的设计中。如果没能找到设计构件，软件工程师必须应用传统的或面向对象的设计方法去创建它们。正是在这点——当设计者开始创建新的构件时——应该考虑为了复用的设计(DFR)。

我们已经提到过，为了复用的设计需要软件工程师应用已有的设计概念和原则，但是，也必须考虑应用领域的特征。Binder建议了作为为了复用的设计的基础而应该考虑的一系列关键问题：

标准数据。应该研究应用领域，并标识出标准的全局数据结构(例如，文件结构或完整的数据库)，那么所有设计构件可以使用这些标准数据结构来刻划。

标准接口协议。应该建立三个层次的接口协议：模块内接口的本质、外部的技术(非人)接口的设计、以及人机界面。

程序模板。结构模型可以作为新程序的体系结构设计的模板。一旦已经建立了标准数据、接口和程序模板，则设计者有了一个可在其中创建设计的框架。

符合这个框架的新的构件对以后的复用有更高的概率。

4.2、构造方法

和设计一样，可复用软件制品的构造依赖于本书中其他地方已经讨论过的软件工程方法，构造可以使用传统的第三代语言、第四代语言和代码生成器、可视化程序设计技术、或更高级的工具来完成。

更高级的构造技术的一个有代表性例子是Netron公司开发Frame技术Netron

方法定义了一组自适应的、称作Frame 的类属构件。和对象一样，Frame 封装数据和操作，但是，它扩展了对象的定义，它结合进了使软件工程师能够通过选择、删除、修改或重复那些构成该Frame 的任意子构件而对Frame 进行适应性修改的机制。

可以通过组装来自Frame 层次的构件而构造应用。在该层次底部的Frame 类似于在因子化体系结构中的工作者(worker)模块，即，它们包含执行低层系统功能(例如，操作系统交互、接口构造、数据库交互)的操作和数据结构；在Frame 层次中层的Frame 着重于和特定信息系统领域相关的功能(例如，事务处理、银行业务、客户服务)；在层次的顶部是“规约fream”，它的作用是作为“系统的主要蓝图和开发者创建来定义系统的唯一的Frame”。

4.3、基于构件的开发

当复用占据了一个应用开发的主导地位时，则构造方法有时被称为基于构件的开发或构件软件。如我们已经看到的，领域工程提供了基于构件的开发所需要的可复用构件库。这些可复用构件中的某些是内部开发的，其他的可以从现存应用中抽取的，还有一些可以从第三方获取。

但是，我们如何创建一个具有一致结构的构件库——它可以被一系列不同的内部和外部源查询并且还可以被集成进在某应用领域内的任意系统？答案是对这样的构件的标准的采用。4 个“体系结构成分”将被用于实现基于构件的开发：数据交换模型。应该对所有的可复用构件定义使得用户和应用间能够交互和传递数据的机制(例如，拖和放、剪切和粘贴)。数据交换机制不仅应允许人和软件、构件和构件间的数据传递，而且也应使得能够在系统资源间进行数据传递(例如，将一个文件拖到某打印机图符上以实现输出)。

自动化。应实现一系列工具、宏和脚本为可复用构件间的交互服务。

结构化存储。包含在“复合文档”中的异质数据(例如，图形数据、声音、文本和数值数据)应该被作为单独的数据结构来组织和访问，而不是作为一组分开的文件。“结构化数据维持了嵌套结构的一个描述性索引，使得应用可以自由地进行导航浏览以定位、创建或编辑个体数据内容，就象终端用户直接操作一样”。

底层对象模型。对象模型保证在不同平台上用不同程序设计语言开发的构件可以互操作，即，对象必须能够跨网络进行通信。为了达到这个目标，对象模型定义了构件互操作标准，该标准是语言独立的，并使用接口定义语言(IDL)来定义。因为复用对软件产业的潜在影响非常巨大，一些主要的公司和产业联盟①已经提出了对构件软件的建议标准：

OpenDoc。主要技术公司(包括IBM、Apple、和Novell)的一个联盟已经提出了复合文档和构件软件的标准OPenDoc。该标准定义了为使得由某开发者提供的构件能够和另一个开发者提供的构件相互操作而必须实现的服务、控制基础设施、和体系结构。

OMG/CORBA。对象管理组织发布了公共对象请求代理体系结构(OMG/CORBA)。一个对象请求代理(ORB)提供了一系列服务，它们使得可复用构件(对象)可以和其他构件通信，而不管它们在系统中的位置。当用OMG/CORBA 标准建立构件时，那些构件在某系统内的集成(没有修改)可以得到保证。

使用客户/服务器的比喻，在客户端应用中的对象向ORB 服务器请求一个或多个服务，请求是通过IDL 或在运行时动态地进行的。一个接口池包含了所有关于服务请求和回答格式的信息。

OLE2.0。微软开发了一个构件对象模型(COM)，它提供了对在单个应用中使用不同厂商生产的对象的规约。对象连接和嵌入(OLE)是COM 的一部分，定义了可复用构件的标准结构。OLE 已成为微软操作系统(Windows 95、Windows NT)的一部分。

这些标准中哪一个将在产业中占据支配地位？这在当前是不容易回答的问题。当前OLE 被用得更广一些(由于基于Windows 应用的广泛使用)，但是，很多OMG/CORBA 工具和开发环境正在被引入。

5、分类和检索构件

考虑一个大的大学图书馆，成千上万的书籍、期刊和其他信息资源是可用的。但是为了访问这些资源，必须有合适的分类模式。为了在这些大量的信息中导航浏览，图书馆管理者定义了一种分类模式，它包括分类码、关键词、作者名、以及其他索引条目，所有这些使得用户可以快速和方便地找到所需资源。

现在考虑一个大的构件仓库，其中存放了成千上万的可复用构件。但是，软件工程师如何找到他所需要的构件呢？为了回答这个问题，又出现了另一个问题：我们如何以无二义的、可分类的术语来描述软件构件？这些是困难的问题，至今还没有确定性的答案。在本节中，我们探讨当前的研究方向，这将使得未来的软件工程师可以导航浏览复用库。

5.1、描述可复用构件

可以用很多方式来描述可复用软件构件，但是理想的描述包括TracZ提出的3C 模型——概念(concePt)、内容(content)和语境(context)。软件构件的概念是“对构件做什么的描述”。构件的接口被完整地描述，而且语义——表示在前置条件后置条件的语境中——被标识。概念将传达构件的意图。

构件的内容描述概念如何被实现。在本质上，内容是对一般用户隐蔽的信息，只有那些企图修改该构件的人才需要了解的信息。

语境将可复用软件构件放置到其应用的领域中。即，通过刻划概念的、操作的和实现的特征，语境使得软件工程师能够发现适当的构件以满足应用需求。

为了可用在实际环境中，概念、内容和语境必须被转换为具体的规约模式。已有很多的文章涉及可复用构件的分类模式。①所提出的方法可以分为三大类：图书馆和信息科学方法、人工智能方法、以及超文本系统。目前为止，绝大部分研究工作建议使用图书馆科学方法进行构件分类。

大多数软件构件分类模式可归为如下的三类：

1)枚举分类(Enumerated Classification)。通过定义一个层次结构来描述构件，在该层次中定义软件构件的类以及不同层次的子类。实际的构件被罗列在枚举层次的任何路径的最低层，例如，对窗口操作的枚举层次可能是：window operations

display

open

menu-based

OpenWindow

system－based

sysWindow

close

via pointer

…

resize

viacommand

setWindowSize，stdResize，shrinkwindow

viadrag

pullwindow，stretchWindow

up/downshuffle

…

move

…

close

…

枚举分类模式的层次结构使得它易于理解和使用，然而，在建立层次之前，必须进行领域工程以获得在层次中适当的项的足够的信息。

刻面分类(Faceted Classification)。分析领域，并标识出一组基本的描述特征，这些特征，称为刻面，被根据其重要性区分优先次序并被联系到构件。刻面可以描述构件执行的功能、被操作的数据、构件应用的语境或任意其他特征。描述构件的刻面的集合称为刻面描述子，通常，刻面描述被限定不超过7或8个刻面。

作为一个简单的在构件分类中使用刻面的例子，考虑使用下列构件描述子的模式：

｛function，object type，system tyPe｝

刻面描述子中的每个刻面可含有一个或多个值，这些值一般是描述性关键词，例如，如果功能(function)是某构件的刻面，赋给此刻面的典型值可能是：function=(copy，from)or(copy，replace，all) 多个刻面值的使用使得原函数copy 能够被更完全地精化。

关键词(值)被赋给复用库中的每个构件的刻面集，当软件工程师在设计中希望查询构件库以发现可能的构件时，规定一列值，然后到库中寻找匹配项。可使用自动工具以完成同义词词典功能，这使得查找不仅包括软件工程师给出的关键词，还包括这些关键词的技术同义词。

刻面分类模式给领域工程师在刻划构件的复杂描述子时更大的灵活性，因为可以很容易地加入新的刻面值，因此，刻面分类模式比枚举分类方法易于扩展和进行适应性修改。

属性—值分类(Attribute－Value Classification)。为领域中的所有构件定义一组属性，然后值被以和刻面分类方法非常相似的方式赋给这些属性，事实上，属性-值分类方法和刻面分类方法是类似的，除了下面几点不同：(1)对可使用的属性数量没有限制，(2)属性没有优先级，(3)不使用同义词词典功能。

基于对上面分类技术的实验研究，Frank 和Pole指出没有明显“最好”的技术和“没有某种方法比别的方法在查找效果上更适度…”。对复用库有效的分类模式的开发仍有许多工作要做。

5.2、构件复用环境

软件构件复用必须有环境的支撑，环境应包含如下元素：

*用于存储构件和对检索构件必需的分类信息的构件库。

*提供对构件库访问的库管理系统。

*允许客户应用从构件库服务器中检索构件和服务的软件构件检索系统(如，

对象请求代理)。

*将复用的构件集成到新设计或实现中的CASE 工具。

每一个功能在复用库的范围内交互或者被包含在复用库中。

复用库是一个更大型CASE仓库的一个元素，并且为一系列可复用软件制品(例如，规约、设计、代码、测试用例、用户指南)的存储提供设施。复用库包含一个数据库以及查询数据库和构件检索所必需的工具，构件分类模式是构件库查询的基础。

查询通常用前面描述的3C 模型中的语境来刻划，如果某初始查询产生大量的候选构件，则查询被求精以减少候选对象。然后，概念和内容信息被抽取出来(在找到候选构件集后)以辅助开发者选择合适的构件。

6、总结

过去几年，大量来自产业实例研究的证据表明从积极的软件复用可获得实质性的商业收益，产品质量、开发生产率、以及整体成本都将得到改善。

质量。理想情况下，为了复用而开发的软件构件已被验证是正确的且不含有错误。在现实中，形式化验证并不能定期地执行，错误可能、也确实存在。然而，随着每一次复用，错误被发现和消除，构件的质量也随之改善。随时间的推移，构件变成实质上无错误的。

在HP 公司的研究中，Lim报告说：被复用代码的错误率是每KLOC有0.9个错误，而新开发代码的错误率是每KLOC有4.1个错误。对一个包含60％复用代码的应用来说，错误率是每KLOC有2.0个错误——对期望的错误率有51％的改善，相对于不使用复用的开发。Henry和Faller的研究指出在质量上有35％的改善。虽然不同的报告得到不同的改善率(位于合理的范围内)，但是，公正地说，复用对交付的软件在质量和可靠性方面确实带来了实质性的收益。

生产率。当可复用软件制品被应用于软件开发全过程中，对开发一个可交付系统所必需的计划、模型、文档、代码和数据的创建工作将花费较少的时间，导致的结果是用较少的投入给客户提供了相同级别的功能，因此生产率得到了改善。虽然，对生产率改善百分率的报告是众所周知难于解释的，①但是，似乎30％到50％的复用可以产生25％到40％的生产率改善。

成本(COST)。对复用带来的净成本节省估算如下：估算出项目如果是从头开始开发所需的成本C，然后减去和复用关联的成本C与被交付的软件的实际成本C s 之和。C s可以用估算技术的一个或多个来确定，和复用关联的成本C s包括：*领域分析和建模。

*领域体系结构开发。

*为促进复用所增加的文档量。

*可复用软件制品的维护和增强。

*对从外部获取的构件的版税和许可证(licenses)费。

*可复用构件库的创建或者获得以及操作。

*对设计和构造复用的人员的培训。

虽然和领域分析与复用库操作相关联的成本可能是实质性的，但是它们由很多项目分担。上面提到的很多其他成本所强调的问题实际上是一个好的软件工程习惯的一部分，不管是否优先考虑复用。