5．1 Metrics, Morphology and External Observations of Reusability
Outline
什么是软件复用
如何度量可复用性
可复用构件的层次和形态
可复用性的外部观察
1.什么是软件复用？
软件复用是使用现有软件组件实现或更新软件系统的过程
1.1两种软件复用的观点
为了复用编程
基于复用编程
1.2为什么要复用？
成本有效性和及时性
可生成可靠的软件
标准化
1.3复用的代价
跨组织、技术和流程更改，支持这些更改的工具的成本，更新工具和更改培训人员的成本
1.4面向复用开发
可复用的开发代价比具体的开发代价高
可复用性改善成本不应该是项目成本
泛型组件的空间效率可能较低，而且执行时间较长
开始 -> 名称泛化 -> 操作泛化 -> 异常泛化 -> 构件泛化 - > 完成
1.5基于复用开发
开发和维护用于架构、设计、文档和代码的组件管理工具
设计体系结构 -> 制定组件 -> 搜索可复用组件 -> 合并已发现组件
关键问题：
增加功能：额外的功能必须加到组件中
删减功能：删除不需要的功能
修改功能：某些实现可能需要修改
2.如何度量可复用性？
在不同场景中，软件多久重用一次（被使用次数越多，重用几率越大）
可重用性
可重用性意味着对构建、打包、分发、安装、配置、部署、维护和升级问题进行某种明确的管理
一个高度复用的软件应该：简单、可移植性和兼容性好、灵活、可扩展、通用和参数化、模块化、将变化限制在局部、稳定
3.可复用组件的层次与形态
3.1复用的层次
可重用组件可以是代码
从更广泛更高层次的角度来看，可以重用那些东西，就能带来哪些好处：需求、设计与规格、数据、测试用例、文档
3.2复用的形态
设计模式：跨应用程序出现的泛型抽象被标示为显示抽象和具体对象及交互的设计模式
基于组件的开发：系统是通过集成组件（对象集合）来开发的，这些组件符合组件的模型标准
应用框架：抽象类和具体类的集合，他们可以被修改和扩展以创建应用程序系统
系统遗留包装：可以通过定义一组接口“包装”的遗留系统，并通过这些接口提供对这些遗留系统的访问
面向服务的系统：系统通过链接外部提供的共享服务来开发
应用生产线：一个应用程序类型是围绕一个公共体系结构进行概括的，这样他就可以以不同的方式适应不同的客户
COTS整合：通过集成现有的应用程序来开发系统
可配置的垂直应用程序：设计一个通用系统，以便能够根据特定系统客户的需要进行配置
程序库：实现常用抽象的类和函数库可用于复用
程序生成器：生成器系统嵌入了特定类型的应用程序的知识，可以在该领域生成系统或系统片段
面向方面的软件开发：在编译程序时，共享组件被编织到不同位置的应用程序中
3.3 代码复用的类型
白盒复用：代码本身可用时，重复使用代码，通常需要某种修改或改编
黑盒复用：通过提供一些“胶水”来组合现有代码，但是不需要改变代码本身（没有代码访问权）
3.4 源码级别的复用
维护问题、出错率高、需要访问源码
3.5 模块级别的复用
继承：类扩展了现有类的属性/行为；另外，他们可能会Override现有的行为
委派：委托是一个对象依赖另一个对象来实现其功能的某个子集（一个实体将某 个事物传递给另一个实体）。
3.6库级别的复用：API/包
库：一组提供可重用功能的类和方法（APIs）
易学、易使用、难失误、易于阅读和维护、满足需求、易于进化、适合观众
3.7系统级别的重用：框架
框架用于子系统设计，包含抽象类和具体类的集合以及每个类之间的接口
框架具有可重用性和可扩展性
白盒框架：
通过继承和动态绑定实现可扩展性
通过子类化框架基类和重写预定义的钩子方法来扩展现有功能
设计模式通常用于覆盖钩子方法
黑盒框架：
通过为可以插入到框架中的组件定义接口来实现可拓展性
通过定义与特定接口一致的组件，可以重用现有功能
这些组成部分通过授权与框架相结合
4.可复用性的外部观察
4.1 类型变化
可重用组件应该是类型参数化的，以便他们能够适应不同的数据类型
泛型：可重用组件应该是泛型的
4.2 实施差异
难以做到单一模块满足需求，需要一组可复用模块
4.3 常规分组
一个可自我实现的可重用模块将需要包含一组例程，每个例程对应一个例程进行
4.4 代表权独立
内部实现可能会经常变化，但客户端不应受到影响。需要实现表示独立性、信息隐藏。
