软件复用

第十章软件复用

10.1软件复用概述

10.1.1 软件复用目的

软件复用使得应用系统的开发不再采用一切从“零”开始的模式，可以充分利用过去应用系统开发中积累的知识和经验，从而可以高效、高质地开发和维护软件系统，主要表现在以下几个方面：

1、缩短软件开发和维护的时间；

2、降低软件开发和维护的成本；

3、保证软件的可靠性；

4、保证软件的一致性；

5、保护投资者的利益。

10.1.2 软件复用的类型

软件复用可以分为横向复用和纵向复用两种类型。横向复用是指复用不同应用领域中的软件成份，如数据结构、算法、人机界面构件等。纵向复用活动的关键在于领域分析：根据应用领域的特征和相似性，预测软件成份的可复用性。一旦确认了软件成份的可复用价值，便进行开发，然后将开发得到的软件制品存入可复用构件库，供未来开发项目使用。

10.1.3 软件复用的内容

软件复用的内容，除了源程序代码外，还有许多其它软件制品，甚至特定的分析建模方法、检查技术、质量保证过程等，均可以被复用。C.Jones定义了10种可能复用的软件制品：

（1）项目计划：软件项目计划的基本结构和许多内容，如SQA计划，均可以跨项目复用。

（2）成本估计：由于不同项目中常包含类似的功能，所以有可能在极少修改或不修改的情况下，复用对该功能的成本估计。

（3）体系结构：即使应用论域千差万别，但程序和数据的体系结构很少有截然不同的情形。因此，有可能创建一组类属的体系结构模板，如事务处理结构，将这些模板作为可复用涉及的框架。

（4）需求模型和规格说明：数据流图、类模型等均可以复用。

（5）设计：系统和对象设计等是常见的复用成份。

（6）源代码

（7）用户文档和技术文档：即使特定的应用不同，也有可能复用用户文档和技术文档中的大部分内容。

（8）用户界面：用户界面可能是最广泛地被复用的软件制品。由于它可能占一个应用软件的60%的代码量，所以复用的效果最明显。

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

相关的测试用例应该“附属于”它们。一旦设计或代码被复用，测试用例：）10（．

10.1.4 针对复用的过程模型

针对复用的过程模型强调并行的工作方式。领域工程执行一系列工作，以建立一组可以被软件工程师复用的软件制品。

领域工程创建应用领域的模型，以用作在软件应用工程流中分析用户需求的基础。软件体系结构为应用软件的设计提供基础。最后，在可复用软件制品被构造好后（作为领域工程的一部分），它们可以在软件建造活动中被软件工程师所用。领域工程和应用工程是并行的

10.1.5 软件复用成功实施的关键

软件复用的实施除了建立和使用可复用制品库外，还需要在软件开发方法、工具、度量等方面为复用提供支持。除非一个组织明确地和正式地实施复用，否则它不可能重复地利用在多个软件项目中的复用机会。实施复用是困难的，有大量的工作要做，但如果成功地实施复用，那么复用带来的回报是巨大的，下面是成功实施复用的关键。

1. 管理者的支持

获得管理者的支持对于保证成功实施复用是非常重要的。向公司引入复用必须得到各级管理者的积极配合，因为它影响了企业的组织结构、文化和软件技术等方面。

2. 复用组织的支持

要成功地实施复用，必须建立一个正式的复用支持组，以承担可复用软件制品的建立、获取、验证、分类和管理。

3. 复用库的支持

可复用软件制品除了应有较高的质量外，还应容易被快速找到、易于理解，并且能被安全地修改等。复用库就是用来对可复用软件制品进行分类、组织、存储和管理。

4. 复用驱动的方法支持

与复用有关的活动和技术必须加入到有关开发方法中，一方面指导可复用制品的建立人员识别复用机会和侯选的可复用制品，并建立一个可复用制品，另一方面指导应用软件开发人员寻找可复用制品，并利用它们组装成新的应用。

10.1.6 复用成熟度模型

在IBM的RMM（Reuse Maturity Model，缩写为RMM）中，将软件复用水平分为五级。

复用比例过程复用制品范围工具

成熟度等级

子程序没有复用没有库个人初始级特定的过程宏－20%至20%

非正式的数据原始的复用模块小组项目级的过程监控级库 50% 至

包 10% 子系统有配置管理功计划的复用部门协调级标准的过程模型能的数据库40%

至30% 框架复用库现场应用程序生大规模的复用正式的复用计

10.1.7 针对复用的软件项目组织

针对复用的软件项目组织必须有两个职能，并由两个部门分别承担。一个职能是

创建可复用制品，相应的部门是创建者或领域工程部门。另一个职能是利用可复用制品来建立系统，相应的部门是复用者或应用工程部门。

10.2 领域工程

10.2.1 领域工程与应用工程

在单个应用系统工程（简称应用工程）的开发过程中，软件开发人员的任务是在特定的条件下，针对一组特定的需求产生一组特定的设计和实现。

与应用工程相比，领域工程处于一个较高的抽象级别上，对领域中相似系统的共同特征进行抽象，并通过领域模型和领域构架DSSA表示了这些共同特征之间的关系。

领域工程和应用工程是相互联系的。一方面，领域工程的主要信息来源是通过应用工程得到的现有系统，包括需求规格说明、设计、实现等。另一方面，领域工程和应用工程需要解决一些相类似的问题。不过，领域工程要适用于一族系统，而不只是一个系统。因此，领域工程比应用工程要复杂，往往不能事先设计划好，也很难实施管理。

10.2.2 领域工程过程

有关领域工程的基本活动和任务如下：

1）领域分析

领域分析的目标主要是获得领域模型。领域模型描述了领域中应用系统之间的共同需求。

2）领域设计

领域设计的目标是获得领域构架DSSA。领域构架DSSA描述了在领域中表示的需求的解决方案，它不是单个应用系统的设计，而是能够适应领域中多个系统需求的一个高层次的设计。

3）领域实现

领域实现的主要目标是定义将需求翻译到由可复制品创建的系统的机制。

领域工程是一个反复的、逐渐精化的过程，在实施过程中都可能返回到以前的步骤，对以前的步骤得到的结果进行修改和完善后，再回到当前步骤。

10.2.3 领域工程参与人员

领域工程的人员可以划分四种角色：领域专家、领域分析员、领域设计员和领域实现员。

1）领域专家

在领域工程中，领域专家可能包括该领域中应用系统有经验的用户。

2）领域分析员

领域分析员由应具有知识工程背景的有经验的系统分析员来担任。．

3）领域设计人员

领域设计人员应由有经验的软件设计人员来担任。

4）领域实现员

领域实现员应由有经验的程序设计人员来担任。

10.2.4 领域模型

领域模型描述了领域中一些基本的概念，如功能、特性、数据、对象类和需求，以及这些概念间的相互关系，是领域内系统的通用和差异属性、属性和领域概念的意义以及差异属性之间的依赖性的明确表示。一般情况下，领域模型包括以下成分：

1. 领域定义