第十章 软件复用
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% 框架 复用库 现场应用程序生 大规模的复用 正式的复用 计划级． 牢固级 50%至70% 领域分析 软件组装过程 成器 特定领域体 公司 一组特定领域 至80%90% 系结构 复用库的集合
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. 领域定义 2. 领域字典 3. 概念模型 4. 特征模型 10.2.5 领域架构 领域构架是使用可复用制品来构造领域中应用系统的高层设计模型。它可以采用过程交互模型，模块结构图等形式，这取决于选择何种类型的模型来表示系统设计。 软件构架描述了构建系统的元素、元素间的交互、指导元素组合的模式以及对这些模式的限制。管道/过滤器模式和层次体系结构模式是两种典型的软件构架模式。 在管道/过滤器模式的软件体系结构中，每个构件都有一组输入和输出，构件读输入的数据流，经过内部处理，然后产生输出数据流。 在层次体系结构模式中，每一层为上层服务，并作为下层客户。 许多现有的软件系统是两层的体系结构，也称为客户机/服务器体系结构。 三层模型则可以明显地改善系统的可扩展性和可复用能力。 10.2.6 FODA方法 FODA（Feature-Oriented Domain Analysis）方法是由卡内基·梅隆大学的软件工程研究所提出的领域工程方法。它支持对某领域中系统共性和个性的发现、分析和文档记录。FODA方法的有关步骤如下： 1）上下文分析 2）领域建模 3）构架建模 10.3 组件技术概述 10.3.1 组件的定义与复用 组件（Component），亦称构件，是指语义完整、语法正确和有可重用价值的单位软件，它是语义描述、通信接口和实现代码的复合体。组件是具有一定的功能，能够独立工作或能同其它组件装配起来协调工作的程序体，其使用同它的开发、生产无关。组件可分为源代码组件和二进制代码组件。 组件复用有白盒和黑盒两种方式。黑盒是指不作修改的直接引用；白盒指进行适应性修改的引用。 随着对软件复用理解的深入，组件的概念不再局限于源代码和二进制代码，而是包括一切对开发活动有用的信息，如需求规约、软件体系结构（构架）、文档、． 数据等。本书将广义的组件用软件制品（简称制品）来称呼，而组件则仍是指源代码和二进制代码。 10.3.2 组件模型 组件模型通常由基于各种语言开发工具、组件嵌入机制和相关服务（事务、安全、认证、负载均衡等）组成。目前，比较成熟的组件模型有OMG的CORBA、SUN的EJB（Java Bean）和Microsoft的COM/DCOM/COM+。 10.3.3 组件获取与描述 组件获取： （1）从现存组件中获取得符合要求的组件，直接使用或作适应性修改，得到可复用的组件； （2）通过遗产工程，将具有潜在复用价值的组件提取出来，得到可复用的组件； （3）从市场上购买现成的商业组件，即COTS（Commercial Off-The-Shelf）组件； （4）开发新的符合要求的组件。