CPT304 SoftwareEngineeringII 软件工程 2 Pt.5 软件复用（Software Reuse）

文章目录

[1. 软件复用的介绍](#1. 软件复用的介绍)
- [1.1 为什么软件复用很重要？](#1.1 为什么软件复用很重要？)
- [1.2 现实中的作用](#1.2 现实中的作用)
[2. 软件复用的优点和挑战](#2. 软件复用的优点和挑战)
- [2.1 软件复用的优点](#2.1 软件复用的优点)
- [2.2 软件复用的挑战](#2.2 软件复用的挑战)
[3. 常见的软件复用策略](#3. 常见的软件复用策略)
- [3.1 Application framework（应用框架）](#3.1 Application framework（应用框架）)
- - [3.1.1 Extending Framework（扩展框架）](#3.1.1 Extending Framework（扩展框架）)
  - [3.1.2 Application Framework（应用框架）和 Software Library（软件库）的区别](#3.1.2 Application Framework（应用框架）和 Software Library（软件库）的区别)
- [3.2 Software Product Lines（SPL，软件产品线）](#3.2 Software Product Lines（SPL，软件产品线）)
- - [3.2.1 SPL 的优点](#3.2.1 SPL 的优点)
  - [3.2.2 SPL Specializations（软件产品线的专门化 / 定制化类型）](#3.2.2 SPL Specializations（软件产品线的专门化 / 定制化类型）)
  - [3.2.3 SPL 的缺点](#3.2.3 SPL 的缺点)
  - [3.2.4 练习](#3.2.4 练习)
- [3.3 Commercial Off-The-Shelf（COTS，商业现成软件 / 商用现成软件）](#3.3 Commercial Off-The-Shelf（COTS，商业现成软件 / 商用现成软件）)
- - [3.3.1 COTS 的方法](#3.3.1 COTS 的方法)
  - [3.3.2 COTS 的优点](#3.3.2 COTS 的优点)
  - [3.3.3 COTS 与 SPL 的区别](#3.3.3 COTS 与 SPL 的区别)
  - - [3.3.3.1 Salesforce Case Study（Salesforce 案例研究）](#3.3.3.1 Salesforce Case Study（Salesforce 案例研究）)
  - [3.3.4 Testing COTS Systems（测试商业现成软件系统）](#3.3.4 Testing COTS Systems（测试商业现成软件系统）)
  - [3.3.5 COTS 的缺点](#3.3.5 COTS 的缺点)
  - [3.3.6 练习](#3.3.6 练习)
[4. 讨论](#4. 讨论)
- [4.1 Application Framework（应用框架）](#4.1 Application Framework（应用框架）)
- [4.2 SPL（软件产品线）](#4.2 SPL（软件产品线）)
- [4.3 COTS（商业现成软件）](#4.3 COTS（商业现成软件）)
[5. 现实世界中的软件复用](#5. 现实世界中的软件复用)

1. 软件复用的介绍

1.1 为什么软件复用很重要？

像 Google 和 Netflix 这样的公司，通过重复使用已有代码，可以节省数百万美元。在这章中，我们也将学习如何做到类似的事情。

定义：软件复用就是使用已有的软件组件，比如代码、设计方案等，来构建新的系统（Software reuse is the practice of using existing software components (code, designs, etc.) to build new system）。

1.2 现实中的作用

Faster development（开发更快）
因为复用已有代码，不用每次都从零开始写，所以开发速度会变快。
例子：
TensorFlow 支撑了 Google 内部多个 AI 工具。
Google 为云客户推出 TensorFlow Enterprise，并且不额外收费。
Fewer bugs（更少的错误 / bug 更少）
复用成熟的代码组件，因为它们已经被测试和使用过，所以通常比新写的代码更稳定。
React 的可复用组件减少了 Meta 各个平台上的错误。
更多的例子有 Facebook、Instagram 和 WhatsApp。

为什么它令人兴奋：软件复用不只是提高效率，它还是现代软件工程中的关键技能。

2. 软件复用的优点和挑战

2.1 软件复用的优点

节省成本：软件复用可以减少开发和维护成本。（Cost savings: Reuse reduces development and maintenance cost）
交付更快：可以更快地把产品推向市场。（Faster delivery: Get products to market quicker）
质量更高：已经测试过的组件通常 bug 更少。（Higher quality: Tested components mean fewer bugs）
利用专家知识：可以使用专家已经完成的工作，不用重复造轮子。（Specialist knowledge: Leverage experts' work without reinventing the wheel）

例子：Spotify 在网页版和手机 App 中复用 UI 组件，以保持一致性并提高开发速度。

如下图所示。

使用复用虽然前期先花时间做一些可以重复使用的代码、模块、组件或框架。

所以一开始成本可能比较高，因为要先设计和开发可复用组件。

但是后面项目越来越多时，就可以反复使用这些组件。

项目越多，平均成本越低。

总结一下就是：面向复用的软件开发在一开始会有较高的成本，但随着相似产品中反复使用相同组件，成本会逐渐降低。

2.2 软件复用的挑战

维护成本：复用的代码可能会变旧，或者和新系统不兼容。（Maintenance costs: Reused code may become outdated or incompatible）
工具支持：有些工具不能很好地和复用组件集成。（Tool support: Some tools don't integrate well with reuse components）
"非我发明综合征"：开发人员可能不愿意使用别人写的代码。（Not-invented-here syndrome: Developers may resist using others' code）
寻找和修改组件：找到合适的组件并修改它并不容易。（Finding and Adapting components: It can be hard to locate and modify the right components）

例子：Ariane 5 火箭在发射后 40 秒爆炸，原因是软件复用了阿丽亚娜 4 号火箭中的一个软件组件，但是没有进行正确的适配。

3. 常见的软件复用策略

软件复用不是只有"复制旧代码"一种方式，它有几种常见做法。

应用框架：已经搭建好的软件结构，比如 Django、Spring，你可以在它的基础上继续开发。（Application framework: Pre-built structures (e.g. Django, Spring) that you extend）
软件产品线：一组相似的软件产品，它们共享一部分相同的组件。（Software Product Lines(SPL): Families of similar products with shared components (e.g. Salesforce CRM variants)）
商业现成软件 / 商用现成软件：已经做好的软件，买来或拿来后，根据自己的需求进行调整。（COTS (Commercial Off-The-Shelf): Ready-made software adapted for specific needs (e.g. WordPress for websites)）
其他复用方式包括：基于组件的复用（比如把登录模块、支付模块、搜索模块做成独立组件，以后其他项目也可以继续用）、开源库、设计模式（我们前两章介绍的）。

下图展示了一个例子，这里复用了已有的 YOLO 库和模型，然后在自己的系统中直接调用它完成目标检测。

3.1 Application framework（应用框架）

应用框架：建立在一个坚实的基础上。

一个通用的软件结构，开发者可以扩展它，用来创建具体的应用程序。

例如：

网站开发框架： Django（Python）、Spring（Java）。
手机应用开发框架：Flutter（跨平台 App）

框架就像已经提前建好的基础结构。你不用从零开始开发，只需要在这个基础上添加自己的功能，就可以节省时间。

框架的工作方式是：它提供一些通用功能，比如安全功能、数据库支持，然后你可以根据自己的项目需求进行修改和扩展。

可以把框架想象成一栋房子的基础设施，比如水管、电路、屋顶和墙。我们可以自己设计细节，并添加自己的装修。

3.1.1 Extending Framework（扩展框架）

当我们使用一个应用框架时，不是只能直接使用它，还可以在框架的基础上加入自己的功能。

开发者可以通过不同方式，把自己的代码加到框架里面，让框架按照你的需求工作。方法如下：

继承：从框架已有的类中创建子类。（Inheritance: Create subclasses from framework classes.）
回调函数：注册一些函数，让它们在特定时间或事件发生时被调用。（Callbacks: Register functions to be called at specific times or events.）
钩子：在框架预先设置好的位置插入自己的代码。（Hooks: Insert custom code at predefined points.）

想象我们正在用 React 或 Django 这样的框架，开发一个动态网页应用，比如一个实时音乐播放列表编辑器。

我们的应用需要响应用户操作和生命周期事件。

我们可以这么使用回调函数：

比如用户点击按钮时，执行一个函数：

javascript 复制代码

button.onclick = function() {
  console.log("User clicked the button");
}

在 React 里也可以这样：

javascript 复制代码

<button onClick={addSong}>Add Song</button>

在 React 里，hooks 是一种特殊机制，用来让函数组件拥有状态管理、生命周期控制等能力。

比如：

javascript 复制代码

const [songs, setSongs] = useState([]);

这里 useState 是一个 hook，用来保存歌曲列表。

再比如：

javascript 复制代码

useEffect(() => {
  console.log("Component loaded");
}, []);

这里 useEffect 也是 hook，常用于处理组件加载、数据变化等生命周期事件。

3.1.2 Application Framework（应用框架）和 Software Library（软件库）的区别

简单来说，Framework 是一个大的开发框架，你的代码要按照它的规则放进去。

Library 是一个工具包，你需要哪个功能就调用哪个功能。

对比项目 Item	应用框架 Application Framework	软件库 Software Library
定义 Definition	中文：一个预先构建好的、可复用的软件结构或骨架，为开发应用程序提供基础。 English: A pre-built, reusable structure or skeleton that provides a foundation for developing applications. 例子 Examples: Django, Spring	中文：一组可复用的函数、类或工具，开发者可以调用它们来完成特定任务。 English: A collection of reusable functions, classes, or utilities that developers call to perform specific tasks. 例子 Examples: NumPy, jQuery
控制流程 Control Flow	中文：使用控制反转模型，也就是框架控制程序流程。开发者把自己的代码放入框架预设的位置，例如 hooks 和 callbacks。 English: Uses an inversion of control model. The framework controls the flow, and developers plug their code into predefined entry points such as hooks and callbacks.	中文：开发者保留控制权。需要某个功能时，开发者主动调用库。 English: The developer retains control. You call the library when you need its functionality.
范围和规模 Scope and Scale	中文：范围较广，通常覆盖整个应用程序领域。 English: Broad scope, often covering an entire application domain.	中文：范围较窄，通常专注于某些具体任务或功能。 English: Narrower scope, focusing on specific tasks or features.
定制方式 Customization	中文：定制必须在框架的规则和限制内完成。开发者可以扩展或重写框架预定义的行为。 English: Customization happens within the framework's constraints. Developers extend or override its predefined behaviors.	中文：更加灵活。开发者只使用自己需要的部分，并可以按照自己的方式集成。 English: More flexible. Developers use only what they need and integrate it however they want.
依赖程度 Dependency	中文：应用程序高度依赖框架。框架通常是系统的主干，如果移除框架，可能需要大规模重写。 English: Your application depends heavily on the framework. It is the backbone of the system, and removing it would require a major rewrite.	中文：依赖较轻。库通常不是系统结构的核心，因此替换或移除库的影响较小。 English: Dependency is lighter. You can swap out or remove a library with less impact because it is not integral to the app's structure.

3.2 Software Product Lines（SPL，软件产品线）

SPL 就是开发一组相似的软件产品，它们共用一套核心功能，但根据不同需求做出不同版本。

例如，Salesforce 提供面向销售、客服和市场营销的不同 CRM 版本，这些版本都来自同一个软件产品线。

3.2.1 SPL 的优点

在多个产品之间复用（Reuse across multiple products）。
开发新版本更快（Faster development for new variants）。

这类似于不同型号的汽车，功能配置不同，但是发动机可能是同一套。

当我们需要创建多个相似、但有轻微差异的软件产品时，SPL 很适合。

3.2.2 SPL Specializations（软件产品线的专门化 / 定制化类型）

我们根据需求的不同，可以让不同产品根据不同情况进行"专门化修改"。

平台专门化 / 平台适配（Platform specialization）
适配不同设备。
例子：网页端、手机端、嵌入式设备。
功能专门化（Functional specialization）
为特定用户增加功能。
例子：销售、客服支持。
环境专门化（Environment specialization）
根据不同运行环境进行调整。
例子：高安全环境、独立运行环境。
流程专门化（Process specialization）
支持不同工作流程。
例子：现金支付、信用卡支付、借记卡支付。

3.2.3 SPL 的缺点

前期投入高：设计一个可以被多个产品共同使用的核心系统，需要花很多时间和成本（Upfront investment：High cost and time to design a reusable core）。
例子：例如 Salesforce 要做销售版、客服版、市场营销版 CRM，它必须先想清楚哪些功能可以共用。
复杂性高：随着产品家族越来越大，管理不同版本会变得很复杂（Complexity：Managing variants can get messy as the family grows）。
例子：要让所有 App 或所有版本保持一致更新很难。

3.2.4 练习

一个软件开发团队要开发一个健身追踪应用。

这个应用需要：

支持多个用户角色。
包含健身计划 / 训练计划功能。
集成外部可穿戴设备。
客户要求在五个月内交付。
客户重视可维护性。

因为题目强调五个月内交付、需要可维护性、还要集成设备，用框架开发比较合适。

原因1：它提供可复用的结构和通用功能，所以团队可以在五个月内更快开发出健身应用。

原因2：框架可以提高可维护性，因为应用会遵循清晰的结构，以后更新用户角色、训练功能和可穿戴设备集成都更容易。

3.3 Commercial Off-The-Shelf（COTS，商业现成软件 / 商用现成软件）

用于快速部署的现成软件。

已经预先开发好的软件，我们可以买来并进行调整使用，但通常不修改它的源代码。

例子：用 WordPress 做网站。用 HubSpot 做 CRM 客户关系管理。用 HubSpot 做 CRM 客户关系管理。

3.3.1 COTS 的方法

COTS 可以通过以下方式进行定制。

配置设置（Configure settings）
比如在 WordPress 里设置网站主题、菜单、用户权限；在 HubSpot 里设置客户字段、销售流程等。
插件（Plugins）
比如 WordPress 本身可以做网站，如果你想加在线支付、SEO、表单功能，就可以安装插件。
API 调用（API calls）
比如你的系统想从 HubSpot 里读取客户信息，就可以通过 API 调用 HubSpot 的数据，而不用直接改 HubSpot 的源代码。

3.3.2 COTS 的优点

部署快（Fast deployment）
因为软件已经做好了，不需要从零开发，所以可以很快上线使用。
开发风险更低（Lower development risk）
因为 COTS 通常已经被很多用户使用和测试过，比自己从零开发更稳定，出严重错误的风险相对较低。
供应商支持（Vendor support）
如果软件出问题，或者需要升级、维护，通常可以由软件公司提供技术支持。

3.3.3 COTS 与 SPL 的区别

COTS 是现成的通用软件，买来就能用，但定制能力有限。

SPL 是一组相关的软件产品，共享核心，但可以根据不同需求做出不同版本。

具体对比如下：

COTS	SPL
• Single product for broad use • 面向广泛使用的单一产品 • Limited customization • 定制能力有限 • Ready to use • 可直接使用 / 开箱即用	• Family of products for specific domains • 面向特定领域的产品家族 • Highly customizable • 高度可定制 • Requires upfront works • 需要前期工作

还有个巨大的区别在于客户不会购买 SPL；他们购买的是产品家族中的具体产品。

3.3.3.1 Salesforce Case Study（Salesforce 案例研究）

我们基于前面比较的最后一点看一下 Salesforce 的案例。

在公司内部，Salesforce 使用 SPL 软件产品线策略来开发它的一系列产品。

Salesforce 对外把这些产品作为单独的 COTS 产品卖给客户。

一个 SPL 软件产品线可以被打包，然后作为 COTS 产品出售。

但是，并不是所有 SPL 都会作为 COTS 产品出售。

3.3.4 Testing COTS Systems（测试商业现成软件系统）

COTS 软件本身已经经过测试，但它和你公司的实际运营流程集成时，可能不一定顺利。

因此 COTS 的测试重点是集成测试。

重点测试 COTS 软件如何与你的实际业务流程互动。

确保这个 COTS CRM 能和你现有的邮件系统很好地集成。

3.3.5 COTS 的缺点

定制能力有限（Limited Customization）
COTS 通常只能通过配置来调整，比如改设置、装插件、调用 API，但不能完全按照自己的想法重写系统。
例子：WordPress 可以换主题、装插件、改页面，但它的核心结构不能随便完全重写，所以灵活性有限。
依赖供应商（Vendor Dependency）
使用 COTS 时，公司会依赖软件供应商的更新和技术支持。
例子：如果 SAP 系统出现 bug，用户公司可能不能自己马上修复，只能等 SAP 官方发布补丁或提供支持，所以可能会有延迟。

3.3.6 练习

现在想象以下自己是一名软件工程顾问，被一家开发手机应用的公司聘请。

这家公司给不同行业开发手机 App，包括健康、金融、教育。

公司现在想采用软件复用技术从而减少开发时间、成本，并且保持高质量。

他们现在想了解 Application framework 和 Software Product Lines（SPL）有什么区别。

公司计划为小型企业开发一组新的手机 App，包括：给零售商店用的销售点系统 App。

给服务型企业用的预约安排 App。

给仓库用的库存管理 App。

所有这些 App 都需要同时运行在 iOS 和 Android 上，并且它们都要共享一些共同功能，比如：用户认证 / 登陆注册、支付处理、数据分析。

现在的问题是：

定义 Application Frameworks（应用框架）和 Software Product Lines, SPL（软件产品线），并说明它们的主要区别。
推荐哪一种技术更适合这家公司，并且至少给出三个理由，这些理由要结合前面的场景。
指出公司在实施推荐的技术时可能遇到的两个挑战。

参考答案：

应用框架 Application Frameworks 是一种预先构建好的、可复用的软件结构，可以为开发应用程序提供基础。开发者需要在框架的基础上扩展功能，并按照框架的规则进行开发。例如 Flutter、React Native、Django 和 Spring。
软件产品线 Software Product Lines, SPL 是一组相关的软件产品，它们共享一个共同的核心部分，但可以根据不同需求进行定制。共同核心可以包括通用功能，而每个产品变体可以加入自己特有的功能。
二者的主要区别是：应用框架主要帮助开发者更高效地构建一个应用程序，而 SPL 主要用于从一个共享核心中开发多个相关的软件产品。
对于这家公司来说，更适合的技术是 Software Product Lines, SPL（软件产品线）。
首先，公司要开发的是一组相关的移动应用，包括 POS 收银 App、预约安排 App 和库存管理 App。这些 App 虽然功能不同，但都属于小型企业业务应用这一相近领域。
第二，所有 App 都共享一些共同功能，例如用户认证、支付处理和数据分析。使用 SPL 可以把这些共同功能开发成一个可复用的核心，然后在所有 App 中重复使用。
第三，SPL 支持针对不同业务需求进行定制。例如，POS App 需要销售和结账功能，预约 App 需要预约管理功能，库存 App 需要库存控制功能。SPL 可以让每个 App 拥有自己的专门功能，同时仍然共享同一个核心系统。
此外，SPL 也有助于提高可维护性。因为像支付处理、用户认证这样的共同功能可以统一管理和更新，从而保持所有产品的一致性。
像 Flutter 这样的应用框架仍然可以用于开发 iOS 和 Android 版本，但作为主要的软件复用策略，SPL 更适合这个场景。
第一个挑战是前期投入高。公司需要花时间和成本来设计可复用的核心功能，例如用户认证、支付处理、数据分析和共享数据结构。
第二个挑战是管理不同产品变体比较复杂。随着 App 数量增加，公司可能很难管理不同功能、保持所有 App 的一致更新，并避免共享核心功能和各 App 特定功能之间发生冲突。

4. 讨论

我们这一章学习了多种复用策略：

Application Framework（应用框架）
SPL（软件产品线）
COTS（商业现成软件）
它们是如何解决 Fred Brooks 在《No Silver Bullet》这篇文章中提到的至少两个"软件开发本质困难"的呢？

4.1 Application Framework（应用框架）

复杂性（Complexity）：
像 Django 这样的框架可以通过提供清晰的软件结构、可复用模块和通用开发模式来降低一部分复杂性。例如，Django 可以帮助开发者用标准方式组织用户账户、数据库操作和网页功能。但是，框架主要减少的是偶然复杂性，例如代码结构混乱、重复开发等问题。它不能消除软件本身的本质复杂性。开发者仍然需要自己设计支付规则、安全机制、退款流程、用户角色和数据管理等复杂业务逻辑。
可变性（Changeability）：
当新的需求符合框架已有的扩展方式时，框架可以让修改变得更容易。例如，添加 Stripe 这样的支付网关可能会更方便，因为 Django 支持 apps、中间件和可复用包。但是，这并不只是简单地"插入"一个组件。开发者仍然需要处理测试、安全、错误处理、支付失败、退款，以及和现有系统的集成。因此，框架可以提高软件的可变性，但不能完全解决软件需求变化带来的困难。
批判性观点（Critical point）：
应用框架很有用，但它不是"银弹"。它可以帮助开发者管理复杂性和可变性，但也会带来限制。开发者必须遵守框架的规则，而且以后如果想更换框架，可能会很困难。

4.2 SPL（软件产品线）

复杂性（Complexity）：
SPL 可以通过为一组相关产品创建一个可复用核心来降低一部分复杂性。例如，移动端和桌面端电商应用可以共享结账、库存、用户认证和支付逻辑。这样可以避免重复设计，也可以让不同产品版本之间保持一致。但是，SPL 主要减少的是偶然复杂性，例如重复实现、重复设计等问题。它不能消除业务领域本身的本质复杂性。实际上，设计可复用核心和管理多个产品变体本身也会带来新的复杂性，尤其是当不同产品有不同平台要求、用户需求和业务规则时。
适应性（Conformity）：
SPL 可以通过在共同核心基础上进行专门化，使不同产品适应现实环境中的限制。例如，移动端版本可以适应触屏输入，而桌面端版本可以支持键盘导航。但是，适应性并不只是平台适配。产品还可能需要适应不同法规、业务流程、支付系统和客户环境。因此，SPL 可以帮助管理这些适应性问题，但不能完全解决它们。开发团队仍然需要仔细设计共享核心和各产品的专属功能，才能让系统真正适合不同现实场景。
批判性观点（Critical point）：
SPL 适合开发一组具有共同功能的相关产品，但它不是"银弹"。它可以减少重复开发、提高一致性，但也需要较高的前期设计投入，并且需要认真管理不同产品变体。

4.3 COTS（商业现成软件）

复杂性（Complexity）：
像 Shopify 这样的 COTS 产品可以通过提供现成的电商解决方案来降低一部分复杂性，例如购物车、支付处理和数据分析功能。这样开发者就不需要从零开始设计所有功能。但是，COTS 主要减少的是偶然复杂性，比如重复开发通用功能。它不能消除业务领域本身的本质复杂性。企业仍然需要处理自己的业务规则、客户流程、税务要求、库存规则，以及和已有系统的集成问题。
可变性（Changeability）：
COTS 可以通过配置、插件或 API 调用来支持一些变化。例如，可以通过 Shopify 插件增加折扣功能。但是，这种灵活性受到供应商平台的限制。如果是较大的变化，比如重写结账流程、改变数据模型，或者支持非常特殊的业务流程，COTS 可能很难甚至无法实现。因此，COTS 可以帮助应对小范围、标准化的变化，但不能完全解决软件可变性问题。
批判性观点（Critical point）：
COTS 适合快速部署，也能减少开发工作量，但它不是"银弹"。它可以降低一部分开发复杂性，但也可能带来系统集成问题、定制能力限制和供应商依赖。

5. 现实世界中的软件复用

我们以 Netflix 在它的平台中复用微服务为例。

优点：

可扩展性（Scalability）
复用微服务可以帮助 Netflix 支持大量用户。
比如很多人同时看 Netflix，如果某个服务压力很大，Netflix 可以增加更多这个服务的实例。
灵活性（Flexibility）
此外 Netflix 可以用已有的微服务，更容易地添加新的服务或功能，而不会影响其他服务。
可靠性（Reliability）
已经测试过的微服务可以被复用，不需要每次都从零测试。

我们这里的可扩展性（Scalability）指的是系统可以继续增长，但不会崩溃。

灵活性（Flexibility）可以单独部署和扩展某个服务，而不会影响其他服务。

大约在 2016 到 2017 年左右，有资料说 Netflix 大约有 700 个微服务。

2023 年 Netflix TechBlog 的文章和 2024 年 GeeksforGeeks 的文章显示，Netflix 现在可能运行着数百个，甚至上千个微服务。

根据目前能找到的数据和合理推测，Netflix 可能大约有 1000 到 1500 个微服务。

我们可以看到软件复用不仅节省了时间、金钱和精力。

现实中的公司还需要依靠软件复用来保持竞争力。

CPT304 SoftwareEngineeringII 软件工程 2 Pt.5 软件复用（Software Reuse）

文章目录

1. 软件复用的介绍

1.1 为什么软件复用很重要？

1.2 现实中的作用

2. 软件复用的优点和挑战

2.1 软件复用的优点

2.2 软件复用的挑战

3. 常见的软件复用策略

3.1 Application framework（应用框架）

3.1.1 Extending Framework（扩展框架）

3.1.2 Application Framework（应用框架） 和 Software Library（软件库） 的区别

3.2 Software Product Lines（SPL，软件产品线）

3.2.1 SPL 的优点

3.2.2 SPL Specializations（软件产品线的专门化 / 定制化类型）

3.2.3 SPL 的缺点

3.2.4 练习

3.3 Commercial Off-The-Shelf（COTS，商业现成软件 / 商用现成软件）

3.3.1 COTS 的方法

3.3.2 COTS 的优点

3.3.3 COTS 与 SPL 的区别

3.3.3.1 Salesforce Case Study（Salesforce 案例研究）

3.3.4 Testing COTS Systems（测试商业现成软件系统）

3.3.5 COTS 的缺点

3.3.6 练习

4. 讨论

4.1 Application Framework（应用框架）

4.2 SPL（软件产品线）

4.3 COTS（商业现成软件）

5. 现实世界中的软件复用

3.1.2 Application Framework（应用框架）和 Software Library（软件库）的区别