软件复用技术

论使用复用设计

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①这样简单的系统，或如工业过程警报系统这样复杂的系统，然而，在每种情形，均可以遇到一组可以预测的结构模式：*界面，使用户能够和系统交互。

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

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

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

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

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

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