第四章 可重用性和可移植性
合集下载
相关主题
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
第四章 可重用性和可 移植性
本章重点: 重用的概念； 可重用的软件成份； 重用对可维护性的影响； 重用的障碍； 可移植性的概念； 实现可移植性的技术。
4.1重用的概念
重用也叫再用或复用，是指同一事物不作 修改或稍加改动就多次重复使用。在软件 工程中，重用是指使用一个产品中的组件 来简化另一个不同的产品的开发。
1．软件构件的生产 开发者获取并生产可重用的构件，其基础工作是建立可重用构件库和构 件分类检索方案。软件构件的生产步骤如下： 领域分析：分析和抽象该领域的通用成分和应用体系结构； 基准模型：构建领域基准体系结构模型，该模型应具有可扩充性； 寻找构件：在基准体系结构模型基础上寻找和确定可能的构件； 性能分析：挑选具有特殊性的构件，并从通用性和局部可修改性（通 过消息传递、继承等方式）进行归并、扩充和完善； 创建构件：建立可重用构件； 构件测试：严格测试，提高可靠性。其测试用例可以与构件一起被重 用； 商业包装：特征描述，以方便客户对测试过的构件存储和检索，存入 构件库。
4.1.2 典型的可重用软件成分
（1）项目计划。跨项目重用软件项目计划的基本结构和 许多内容，可以减少用于制定计划的时间，降低与建立进 度表和进行风险分析等活动相关联的不确定性。 （2）成本估计。不同项目中常含有类似的功能，只做极 少修改或根本不做修改就重用对该功能的成本估计结果。 （3）体系结构。很少有截然不同的程序和数据体系结构， 有可能创建一组类属的体系结构模板，把那些模板作为可 重用的设计框架。 （4）需求模型和规格说明。用传统软件工程方法开发的 分析模型，是可重用的。面向对象开发方法中，类和对象 的模型及规格说明也是经常被重用的对象。 （5）设计。用传统方法开发的体系结构、数据、接口和 过程设计结果，是重用的候选者；系统和对象设计也是可 重用的。
2．软件构件的使用 软件构件的使用步骤如下： 体系结构：以构件生产者提供的基准体系结构模型为基础，经裁剪或 扩充而成。 寻找构件：从构件库、遗留软件或构件供应商中查询适合待开发软件 要求的构件。 筛选构件：从寻找到的构件中进一步比较，挑选出最适合待开发软件 要求的构件。 修改构件：调整和修改选中的构件，使之完全满足系统要求。 软件开发：对新的软件系统中不能重用的部分进行开发。 组装构件：将调整后的构件和新开发的部分组装成一个新的软件系统。 集成测试：对新组装成的软件系统进行集成测试。 构件评价：对可重用构件提出改进意见，发现新的可重用构件并向生 产者推荐。
高级（重用）经理
部门经理 系统开发部门 创建者
部门经理 支持部门 支持者
部门经理 应用开发部门 重用者
系统地进行软件重用的组织结构示意图
各职能部门职责如下： 1．系统开发部门：可重用构件创建者。其职能是创建高质量的可重 用资产，为众多重用者服务；与应用开发部门（重用者）并列，集中 精力设计和创建可重用构件；尽量接近重用者，以保证其生产的可重 用构件符合实际需要。 2．应用开发部门：可重用构件使用者。其职能是更多、更快、低成 本地利用可重用资产完成应用项目的开发；将软件重用时发现的问题 与修改意见及时反馈给系统开发部门，完善可重用构件。 3．支持部门：用来完成前两个部门不能涉及而又必须作的工作，为 可重用资产的获取、管理、维护提供全面的支持，与系统开发部门和 应用开发部门并列。 4．高层经理：在3个职能部门之上。其职责是关注总体目标，从总体 目标高度上权衡创建者和重用者的得失；协调3个职能部门之间的工 作，仲裁3个职能部门之间的发生的冲突；对于大公司，可设立重用 管理委员会，设经理、体系结构设计师等职位，由委员会集体讨论和 仲裁各部门之间的矛盾。
最早的软件重用技术:人们建造了子程序库， 开发成运行时支持程序，使用时只需要调 用相应的函数或方法即可，而不用从头开 始建造相应的程序。
随着软件开发技术的不断发展和软件重用 技术的需求，又提出软件构件和软件构件 库的概念。
重用不但可以缩短开发过程、降低开发成 本、提高软件产品的质量，还可以减少维 护的时间和降低维护成本。
（6）源代码。用兼容的程序设计语言书写的、经过验证 的程序构件，是重用的候选者。 （7）用户文档和技术文档。即使针对不同的应用，也有 可能重用用户文档和技术文档的大部分。 （8）用户界面。GUI（图形用户界面）软件可占到一个 应用程序的60%代码量，经常被重用，重用的效果非常显 著，这可能是最广泛被重用的软件成分。 （9）数据。在大多数被重用的软件成分中，被重用的数 据包括： 内部表、列表和记录结构，以及文件和完整的数 据库。 （10）测试用例。如果设计或代码构件被重用，相关的测 试用例也会一同被重用。
为提高软件的可移植性，应尽量使软件与 具体的设备无关，即提高软件的设备独立 性。 可移植性还意味着能够容易地修改文档以 反映目标配置，而不需要重新写一个新的 文档。
分析软件的可移植性需要考虑： 不同的体系结构之间二进制形式的应用软件是不 可移植的，如果是源程序，必须对其进行重新编 译才可以在新的环境中运行。 相同体系结构的硬件平台上，如果操作系统也相 同，二进制形式的应用软件可移植，否则必须对 源程序进行相应的修改后重新编译链接生成新的 可执行文件才可以在不同的操作系统下运行。 对于同一种语言编写的程序在不同版本编辑器之 间的可移植性，取决于该语言的标准化程度和编 译器实现时对语言标准的严格遵守程度。
4.2软件重用的实施与组织
系统地软件重用实施是指有目的地创建、 管理、支持和重用软件资产。
软件资产是那些有价值的、高质量的软件 工作制品、工具、模型、过程步骤、算法 等。在系统地软件重用描述中，经常用软 件资产代替构件。
管理 计划、资金 协调、培训
创建 领域分析、工具 体系结构、构件
支持 维护、分类、文档 包装、验证
4.3重用的障碍
重用会面临这样的一些障碍： 1．很多软件专业人员宁可自己从头编写一个程序，也不 愿重用别人编写的程序。 2．重用的对象最好自身没有错误也不会给相关程序带来 错误。 3．可重用的组件很多，如何进行存储和管理以便进行检 索去重用？ 4．对于合同软件会产生司法问题。 5．重用的对象是现成的软件产品组件时，相应的源代码 对软件开发组织来说是保密的。 6．重用会增加成本。 这些障碍只是一些主要的障碍，在原则上是可以克服的。
3．根据重用方式划分 （1）黑盒重用：对可重用的构件不加任何 修改，直接重用。 这种重用的构件为通用型可重用构件，具有 良好的封装性和标准的接口，并具有高可 靠性和质量保证，因此这种类型构件重用 率很高。 （2）白盒重用：对可重用的构件进行部分 修改，以适应新系统的要求。
4.1.5可重用软件构件的生产和使用
4.4可移植性
软件可移植性指的是把程序从一种计算环 境（硬件配置和操作系统）转移到另一种 计算环境并使之正常运行的难易程度。可 移植性有时也被描述为跨平台性。它从软 件对新环境的适应性这一方面反映了软件 的质量。
好的软件产品可以在它的整个生存期间，在三个或 更多的不同的硬件配置上实现。 为解决这个问题，可以采用不同的方法: 一种方法是购买向上兼容的硬件，这样做仅需要 花钱购买相应的硬件产品，而不需要对软件作变 动。 另一种方法是把与硬件、操作系统以及其他外部 设备有关的程序代码集中放到特定的程序模块中， 把因环境变化而必须修改的程序局限在少数程序 模块中，从而降低修改的难度。
大量使用可重用的组件来开发软件，可以从下述两 个方面提高软件的可维护性：
第一方面，通常可重用的组件在开发时经过很严 格的测试，可靠性比较高，且在每次重用过程中 都会发现并清除一些错误，随着时间推移，这样 的组件将变成实质上无错误的。 第二方面，很容易修改可重用的组件使之再次应 用在新环境中，因此，软件中使用的可重用的组 件越多，维护也就越容易。
2．根据实现重用的途径划分 （1）组装（集成）式重用：建立可重用构件库， 开发新的软件时从构件库中选取合适构件组装 （集成）成新系统。 这种重用的基础是一个逐渐完善、高效率的构件库 系统。在这种重用方式中，可重用的构件应该有 简明的特征描述以便检索，并有标准接口；并且 着重源代码的重用。 （2）生成式重用：通过形式化语言描述，利用程 序自动生成器生成相应的软件系统。
4.1.3软件成分重用的过程
系统集成 目标软件
实例化
软件成分
软件成分 抽象
检索 软件成分
可重用软件构 件库
软件成分
4.1.3软件成分重用的过程
软件重用的一般过程如下： 抽象：对一个可重用的软件成分，首先要对其进行“抽象” 概括，即描述该软件成分的本质、功能、适用范围和特点， 以此作为关键字，方便使用者在调用时进行检索； 存储：以关键字作为索引，放置在“可重用的软件成分库” 中备用； 检索：在组建（集成）新系统时，利用关键字，根据需要 从可重用的软件成分库检索挑选适合新系统功能要求的软 件成分； 实例化：对选取的软件成分进行简单的修改调试，变成完 全适合新系统要求的软件成分； 系统集成：最后进行系统集成，完成新系统的组建。
4.1.4软件重用形式的划分
1．根据重用跨越的问题领域划分 （1）垂直式重用：在同一应用领域中重用。 采用这种重用方式的各个应用系统具有共性或相似性。对于 这种形式，便于获得通用模型，重用面广；大多数软件组 织采用这种重用形式。 （2）水平式重用：在不同领域中重用通用的软件元素。 由于各个应用系统一般差异较大，可重用的构件较少。常用 的通用软件元素有数据结构、算法、人机界面等。现在互 联网中的中间构件及各种应用平台已经变成水平式重用的 发展趋势。
重用 选择、集成、修改 建造、测试
软件产品
系统地软件重用在实施过程中涉及的4个并发过程
1．创建过程：其目标是标识和提供可重用软件资产。此 过程的活动包括清理分析遗留的软件资产、领域分析、重 用客户需求分析、定义体系结构、构建构件、测试和包装 软件资产。 2．支持过程：对可重用资产的获取、管理和维护提供全 面支持。涉及的活动包括验证和分发可重用资产，为构件 分类编目、提供附加文档、收集反馈信息。 3．重用过程：利用可重用资产生产应用软件产品。涉及 的活动包括验证领域模型和用户需求、选择和修改可重用 资产、组建和测试应用软件。 4．管理过程：对系统地软件重用全过程进行统筹、计划 和协调。涉及的活动包括制定和协调进度计划、安排资金 使用方向和额度、组织培训等。
软件的可移植性是软件共享的源程序文本 资源的一个特性，它可以从两方面来解释： 原程序可以从一台处理机转向另一台处理 机，从一个编译程序转向另一个编译程序， 只需要很小的改动或根本不需要修改；源 程序模块只需要很小的改动或不需要改动 就可以集结到不同的软件包中。
4.5实现可移植性的技术
源自文库
对于可移植的系统软件，一种技术是可以 隔离任何必须依赖于实现的程序段，而不 是禁止所有依赖于实现的特性方面。 另一种有用的技术是使用抽象层次来实现 可移植性。
领域知识
问题领域分析
客户需求
软件开发与软 件构件开发 软件构件
目标软件
理解
软件构件 确认
检索 软件构件
可重用软件构 件库
软件构件
图4-1面向软件构件复用的软件开发过程
4.1.1软件成分的重用级别
软件成分的重用划分成以下3个级别： (1) 代码重用 调用库中的模块。可以采用下列形式： 源代码剪贴：缺点是复制或修改原有代码时可能出错。 源代码包含：许多程序设计语言都提供包含(include)库中源代码的机制。 继承：重用类库中的类时无须修改已有的代码，就可扩充或具体化在库 中找出的类。 (2) 设计结果重用 重用某个软件系统的设计模型(即求解域模型)。 (3) 分析结果重用 重用某个系统的分析模型。适用于用户需求未改变，但系统体系结构发 生了根本变化的场合。
本章重点: 重用的概念； 可重用的软件成份； 重用对可维护性的影响； 重用的障碍； 可移植性的概念； 实现可移植性的技术。
4.1重用的概念
重用也叫再用或复用，是指同一事物不作 修改或稍加改动就多次重复使用。在软件 工程中，重用是指使用一个产品中的组件 来简化另一个不同的产品的开发。
1．软件构件的生产 开发者获取并生产可重用的构件，其基础工作是建立可重用构件库和构 件分类检索方案。软件构件的生产步骤如下： 领域分析：分析和抽象该领域的通用成分和应用体系结构； 基准模型：构建领域基准体系结构模型，该模型应具有可扩充性； 寻找构件：在基准体系结构模型基础上寻找和确定可能的构件； 性能分析：挑选具有特殊性的构件，并从通用性和局部可修改性（通 过消息传递、继承等方式）进行归并、扩充和完善； 创建构件：建立可重用构件； 构件测试：严格测试，提高可靠性。其测试用例可以与构件一起被重 用； 商业包装：特征描述，以方便客户对测试过的构件存储和检索，存入 构件库。
4.1.2 典型的可重用软件成分
（1）项目计划。跨项目重用软件项目计划的基本结构和 许多内容，可以减少用于制定计划的时间，降低与建立进 度表和进行风险分析等活动相关联的不确定性。 （2）成本估计。不同项目中常含有类似的功能，只做极 少修改或根本不做修改就重用对该功能的成本估计结果。 （3）体系结构。很少有截然不同的程序和数据体系结构， 有可能创建一组类属的体系结构模板，把那些模板作为可 重用的设计框架。 （4）需求模型和规格说明。用传统软件工程方法开发的 分析模型，是可重用的。面向对象开发方法中，类和对象 的模型及规格说明也是经常被重用的对象。 （5）设计。用传统方法开发的体系结构、数据、接口和 过程设计结果，是重用的候选者；系统和对象设计也是可 重用的。
2．软件构件的使用 软件构件的使用步骤如下： 体系结构：以构件生产者提供的基准体系结构模型为基础，经裁剪或 扩充而成。 寻找构件：从构件库、遗留软件或构件供应商中查询适合待开发软件 要求的构件。 筛选构件：从寻找到的构件中进一步比较，挑选出最适合待开发软件 要求的构件。 修改构件：调整和修改选中的构件，使之完全满足系统要求。 软件开发：对新的软件系统中不能重用的部分进行开发。 组装构件：将调整后的构件和新开发的部分组装成一个新的软件系统。 集成测试：对新组装成的软件系统进行集成测试。 构件评价：对可重用构件提出改进意见，发现新的可重用构件并向生 产者推荐。
高级（重用）经理
部门经理 系统开发部门 创建者
部门经理 支持部门 支持者
部门经理 应用开发部门 重用者
系统地进行软件重用的组织结构示意图
各职能部门职责如下： 1．系统开发部门：可重用构件创建者。其职能是创建高质量的可重 用资产，为众多重用者服务；与应用开发部门（重用者）并列，集中 精力设计和创建可重用构件；尽量接近重用者，以保证其生产的可重 用构件符合实际需要。 2．应用开发部门：可重用构件使用者。其职能是更多、更快、低成 本地利用可重用资产完成应用项目的开发；将软件重用时发现的问题 与修改意见及时反馈给系统开发部门，完善可重用构件。 3．支持部门：用来完成前两个部门不能涉及而又必须作的工作，为 可重用资产的获取、管理、维护提供全面的支持，与系统开发部门和 应用开发部门并列。 4．高层经理：在3个职能部门之上。其职责是关注总体目标，从总体 目标高度上权衡创建者和重用者的得失；协调3个职能部门之间的工 作，仲裁3个职能部门之间的发生的冲突；对于大公司，可设立重用 管理委员会，设经理、体系结构设计师等职位，由委员会集体讨论和 仲裁各部门之间的矛盾。
最早的软件重用技术:人们建造了子程序库， 开发成运行时支持程序，使用时只需要调 用相应的函数或方法即可，而不用从头开 始建造相应的程序。
随着软件开发技术的不断发展和软件重用 技术的需求，又提出软件构件和软件构件 库的概念。
重用不但可以缩短开发过程、降低开发成 本、提高软件产品的质量，还可以减少维 护的时间和降低维护成本。
（6）源代码。用兼容的程序设计语言书写的、经过验证 的程序构件，是重用的候选者。 （7）用户文档和技术文档。即使针对不同的应用，也有 可能重用用户文档和技术文档的大部分。 （8）用户界面。GUI（图形用户界面）软件可占到一个 应用程序的60%代码量，经常被重用，重用的效果非常显 著，这可能是最广泛被重用的软件成分。 （9）数据。在大多数被重用的软件成分中，被重用的数 据包括： 内部表、列表和记录结构，以及文件和完整的数 据库。 （10）测试用例。如果设计或代码构件被重用，相关的测 试用例也会一同被重用。
为提高软件的可移植性，应尽量使软件与 具体的设备无关，即提高软件的设备独立 性。 可移植性还意味着能够容易地修改文档以 反映目标配置，而不需要重新写一个新的 文档。
分析软件的可移植性需要考虑： 不同的体系结构之间二进制形式的应用软件是不 可移植的，如果是源程序，必须对其进行重新编 译才可以在新的环境中运行。 相同体系结构的硬件平台上，如果操作系统也相 同，二进制形式的应用软件可移植，否则必须对 源程序进行相应的修改后重新编译链接生成新的 可执行文件才可以在不同的操作系统下运行。 对于同一种语言编写的程序在不同版本编辑器之 间的可移植性，取决于该语言的标准化程度和编 译器实现时对语言标准的严格遵守程度。
4.2软件重用的实施与组织
系统地软件重用实施是指有目的地创建、 管理、支持和重用软件资产。
软件资产是那些有价值的、高质量的软件 工作制品、工具、模型、过程步骤、算法 等。在系统地软件重用描述中，经常用软 件资产代替构件。
管理 计划、资金 协调、培训
创建 领域分析、工具 体系结构、构件
支持 维护、分类、文档 包装、验证
4.3重用的障碍
重用会面临这样的一些障碍： 1．很多软件专业人员宁可自己从头编写一个程序，也不 愿重用别人编写的程序。 2．重用的对象最好自身没有错误也不会给相关程序带来 错误。 3．可重用的组件很多，如何进行存储和管理以便进行检 索去重用？ 4．对于合同软件会产生司法问题。 5．重用的对象是现成的软件产品组件时，相应的源代码 对软件开发组织来说是保密的。 6．重用会增加成本。 这些障碍只是一些主要的障碍，在原则上是可以克服的。
3．根据重用方式划分 （1）黑盒重用：对可重用的构件不加任何 修改，直接重用。 这种重用的构件为通用型可重用构件，具有 良好的封装性和标准的接口，并具有高可 靠性和质量保证，因此这种类型构件重用 率很高。 （2）白盒重用：对可重用的构件进行部分 修改，以适应新系统的要求。
4.1.5可重用软件构件的生产和使用
4.4可移植性
软件可移植性指的是把程序从一种计算环 境（硬件配置和操作系统）转移到另一种 计算环境并使之正常运行的难易程度。可 移植性有时也被描述为跨平台性。它从软 件对新环境的适应性这一方面反映了软件 的质量。
好的软件产品可以在它的整个生存期间，在三个或 更多的不同的硬件配置上实现。 为解决这个问题，可以采用不同的方法: 一种方法是购买向上兼容的硬件，这样做仅需要 花钱购买相应的硬件产品，而不需要对软件作变 动。 另一种方法是把与硬件、操作系统以及其他外部 设备有关的程序代码集中放到特定的程序模块中， 把因环境变化而必须修改的程序局限在少数程序 模块中，从而降低修改的难度。
大量使用可重用的组件来开发软件，可以从下述两 个方面提高软件的可维护性：
第一方面，通常可重用的组件在开发时经过很严 格的测试，可靠性比较高，且在每次重用过程中 都会发现并清除一些错误，随着时间推移，这样 的组件将变成实质上无错误的。 第二方面，很容易修改可重用的组件使之再次应 用在新环境中，因此，软件中使用的可重用的组 件越多，维护也就越容易。
2．根据实现重用的途径划分 （1）组装（集成）式重用：建立可重用构件库， 开发新的软件时从构件库中选取合适构件组装 （集成）成新系统。 这种重用的基础是一个逐渐完善、高效率的构件库 系统。在这种重用方式中，可重用的构件应该有 简明的特征描述以便检索，并有标准接口；并且 着重源代码的重用。 （2）生成式重用：通过形式化语言描述，利用程 序自动生成器生成相应的软件系统。
4.1.3软件成分重用的过程
系统集成 目标软件
实例化
软件成分
软件成分 抽象
检索 软件成分
可重用软件构 件库
软件成分
4.1.3软件成分重用的过程
软件重用的一般过程如下： 抽象：对一个可重用的软件成分，首先要对其进行“抽象” 概括，即描述该软件成分的本质、功能、适用范围和特点， 以此作为关键字，方便使用者在调用时进行检索； 存储：以关键字作为索引，放置在“可重用的软件成分库” 中备用； 检索：在组建（集成）新系统时，利用关键字，根据需要 从可重用的软件成分库检索挑选适合新系统功能要求的软 件成分； 实例化：对选取的软件成分进行简单的修改调试，变成完 全适合新系统要求的软件成分； 系统集成：最后进行系统集成，完成新系统的组建。
4.1.4软件重用形式的划分
1．根据重用跨越的问题领域划分 （1）垂直式重用：在同一应用领域中重用。 采用这种重用方式的各个应用系统具有共性或相似性。对于 这种形式，便于获得通用模型，重用面广；大多数软件组 织采用这种重用形式。 （2）水平式重用：在不同领域中重用通用的软件元素。 由于各个应用系统一般差异较大，可重用的构件较少。常用 的通用软件元素有数据结构、算法、人机界面等。现在互 联网中的中间构件及各种应用平台已经变成水平式重用的 发展趋势。
重用 选择、集成、修改 建造、测试
软件产品
系统地软件重用在实施过程中涉及的4个并发过程
1．创建过程：其目标是标识和提供可重用软件资产。此 过程的活动包括清理分析遗留的软件资产、领域分析、重 用客户需求分析、定义体系结构、构建构件、测试和包装 软件资产。 2．支持过程：对可重用资产的获取、管理和维护提供全 面支持。涉及的活动包括验证和分发可重用资产，为构件 分类编目、提供附加文档、收集反馈信息。 3．重用过程：利用可重用资产生产应用软件产品。涉及 的活动包括验证领域模型和用户需求、选择和修改可重用 资产、组建和测试应用软件。 4．管理过程：对系统地软件重用全过程进行统筹、计划 和协调。涉及的活动包括制定和协调进度计划、安排资金 使用方向和额度、组织培训等。
软件的可移植性是软件共享的源程序文本 资源的一个特性，它可以从两方面来解释： 原程序可以从一台处理机转向另一台处理 机，从一个编译程序转向另一个编译程序， 只需要很小的改动或根本不需要修改；源 程序模块只需要很小的改动或不需要改动 就可以集结到不同的软件包中。
4.5实现可移植性的技术
源自文库
对于可移植的系统软件，一种技术是可以 隔离任何必须依赖于实现的程序段，而不 是禁止所有依赖于实现的特性方面。 另一种有用的技术是使用抽象层次来实现 可移植性。
领域知识
问题领域分析
客户需求
软件开发与软 件构件开发 软件构件
目标软件
理解
软件构件 确认
检索 软件构件
可重用软件构 件库
软件构件
图4-1面向软件构件复用的软件开发过程
4.1.1软件成分的重用级别
软件成分的重用划分成以下3个级别： (1) 代码重用 调用库中的模块。可以采用下列形式： 源代码剪贴：缺点是复制或修改原有代码时可能出错。 源代码包含：许多程序设计语言都提供包含(include)库中源代码的机制。 继承：重用类库中的类时无须修改已有的代码，就可扩充或具体化在库 中找出的类。 (2) 设计结果重用 重用某个软件系统的设计模型(即求解域模型)。 (3) 分析结果重用 重用某个系统的分析模型。适用于用户需求未改变，但系统体系结构发 生了根本变化的场合。