软件复用技术 授课教师：姜善林 授课时间：11  18周 联系方式：13518663112（短信） E_mail: jiangshanlin@gmail.com

说明与希望 教案中的内容和观点仅供同学们参考，对于不当之处，欢迎指正与帮助。希望同学们积极的参与，在本课程的教学中能够经常得到大家的批评与建议，也希望课程的教学方式能够更加灵活、多样，让我们共同配合，一起把这门课学好。 谢谢大家的合作！

课程主要内容 序言：软件复用的背景 软件复用的概念与术语 软件复用面临的问题 构建可复用资产 体系结构框架

课程参考资料 1、基于重用的软件工程－技术、组织和控制 电子工业出版社，2003 2、软件复用结构、过程和组织 机械工业出版社，2003 3、软件复用实践，机械工业出版社，2003 4、学术期刊全文库

意思相同术语说明 软件复用(Software Reuse) 软件重用 软件再用 组件(component) 构件 可重用部件

序言—软件复用的背景 一、历史必然性 1、问题的提出

序言—软件复用的背景

序言—软件复用的背景 激烈的竞争，使得成功意味着建立在软件之上的产品和服务必须“更快、更好、更便宜”。 更快：软件必须满足市场时间要求（开发、运行和维护） 更好：满足其所支持过程的要求、能够对过程提供支持，故障少、恢复快。 更便宜：软件的生产和维护成本必须较低。

序言—软件复用的背景 2、解决的途径 （1）更有效的生产软件； （2）重复利用已有的软件或软件的很大一部分。 现在全世界大约有1000亿（2003年）行程序在运行，很多功能被重复写了成千上万次。可见要想改进软件开发效能，软件复用必须成为软件工程战略的关键部分。

序言—软件复用的背景 二、软件复用技术的产生 1、概念的提出 1968年，Mcllroy在NATO首次讨论软件工程的国际会议上建议建立生产软组件的工厂，用产品目录上的软组件构成复杂系统，以作为解决软件危机的一种的一种可能技术途径。 自从出现以来，一直被视为可以促进软件质量和开发效率有一个数量级改进的惟一实用和现实的途径。

序言—软件复用的背景 传统产业的工业化生产模式

序言—软件复用的背景 软件产业的工业化生产模式 借鉴传统产业的工业化生产模式，软件复用被认为是解决“软件危机”，提高软件开发效率和质量，实现软件产业工业化生产方式的重要途径

序言—软件复用的背景 2、软件复用与软件工程 软件复用作为一门学科，在管理、组织和技术上推动了软件工程成为一门学科。 在其他工程学科中，复用都是良好工程设计的一个完整部分，而软件复用则成为一个问题，主要原因是： 软件资产一般包含很多信息，因此很难刻画、匹配并获取其相关性质。

序言—软件复用的背景 3、复用发生的前提 （1）所开发的计算机系统具有很多共同点； （2）通过重用以前开发团队的过程和产品解决新问题，能够提高生产率并改进最终系统的质量； 为了使软件复用达到企业范围内的有价值、可预测和可重复使用水平，必须解决三个层次上的问题：

序言—软件复用的背景 4、如何实现复用？ （1）技术领域：开发高质量组件技术，使得组件能 够得到广泛应用且经济合算； （2）组织领域：针对生产、使用和管理复用产 品 共享库，组建有要求、有纪律、有技能、有资源的 机构 （3）控制度量领域（经济学建模）：用于规划、控 制和评估机构达到其目标程度的成套的控制和管理 工具

序言—软件复用的背景 5、关键因素 软件构件技术(Software Component Technology) 领域工程(Domain Engineering) 软件构架(Software Architecture) 软件再工程(Software Reengineering) 开放系统(Open System) 软件过程(Software Process) CASE技术等 以及各种非技术因素。 Computer Aided Software Engineering的缩写，主要是指利用一整套的方法和工具对系统规则进行建模，并自动生成合适的程序

序言—软件复用的背景 开放系统技术的基本原则是在系统的开发中使用接口标准，同时使用符合接口标准的实现。当前，以解决异构环境中的互操作为目标的分布对象技术是开放系统技术中新的主流技术。 软件过程又称软件生存周期过程，是软件生存周期内为达到一定目标而必须实施的一系列相关过程的集合。一个良好定义的软件过程对软件开发的质量和效率有着重要影响。当前，软件过程研究以及企业的软件过程改善已成为软件工程界的热点，并已出现了一些实用的过程模型标准，如CMM、ISO9001/TickIT等。 软件复用同样需要CASE技术的支持。CASE技术中与软件复用相关的主要研究内容包括：在面向复用的软件开发中，可复用构件的抽取、描述、分类和存储；在基于复用的软件开发中，可复用构件的检索、提取和组装；可复用构件的度量等等。

第一章 软件复用基本概念 §1.1 软件复用的概念与术语 §1.2 软件复用的目的和意义 §1.3 软件复用技术发展简史 第一章 软件复用基本概念 §1.1 软件复用的概念与术语 §1.2 软件复用的目的和意义 §1.3 软件复用技术发展简史 §1.4 软件复用产品及过程 §1.5 软件复用范例 §1.6 软件复用与构件技术 §1.7 软件分合原理

§1.1 软件复用的概念与术语 1、软件复用的定义 引例1：一个信息管理系统，编写一个通用的排序 函数，通过传递不同的参数，实现通用排序功 能。 分析： （1）这只是使用好的程序设计原则来提高程序质量， 并不是复用实践。 （2）理想情况下，除非在生产可重用产品的过程和使 用这些产品的过程之间存在某种独立性度量，否则不 认为有复用。

§1.1 软件复用的概念与术语 引例2：当其他程序员使用上述函数进行排序操作时，这是否发生了重用？ 分析： （1）软件复用的先决条件是生产和消费可复用产品的过程是系统化的。这只是“代码利用”。 （2）理想情况下，可重用资产的生产者对其代码将会被重用的可能性有某种程度的认识，并对代码将要被重用的应用领域有一定的了解。

§1.1 软件复用的概念与术语 引例3：程序员利用C编译器编写程序。对C编译器的重复使用是一个软件复用实例吗？ 分析： （1）不是。程序员并不是使用编译器从事再次开发活动，而是把编译器用作最终产品。 （2）复用的另一个条件是可复用资产要应用到软件开发过程中，集成到所开发的系统中。

§1.1 软件复用的概念与术语 在软件演化的过程中，重复使用的行为可能发生在三个维上： 时间维：使用以前的软件版本作为新版本的基础，加入新功能，适应新需求，即软件维护。 平台维：以某平台上的软件为基础，修改其和运行平台相关的部分，使其运行于新平台，即软件移植。 应用维：将某软件(或其中构件)用于其他应用系统中，新系统具有不同功能和用途，即真正的软件复用。 真正的复用是为了支持软件在应用维的演化，使用“为复用而开发的软件(构件)”来更快、更好地开发新的应用系统。

§1.1 软件复用的概念与术语 定义： （1）软件复用是指在两次或多次不同的软件开发过程中重复使用相同或相似软件元素（通常称为可复用构件、组件或软部件）的过程。 （2）软件复用是提高软件生产力和质量的一种技术，将已有软件的各种有关知识用于建立新的软件。 领域知识 开发经验 设计决定 体系结构 需求 设计 编码 测试用例 测试数据 文档等

§1.1 软件复用的概念与术语 构(组)件(component)―可以复用的软件成分，可被用来构造其他软件。 它可以是： 被封装的对象类 功能模块 软件框架（Framework） 软件架构（或体系结构Architecture） 文档 设计件、分析件、程序件、数据件 设计模式等

§1.1 软件复用的概念与术语 2、软件复用的优势 （1）生产率收益：通过复用现有资产，可以节省再次开发所需的人力物力； （2）质量收益：当组件被开发用来复用时，在保证质量上的大量投入会在多次使用中得到补偿；当可复用组件被很多人使用时，可以更彻底的发现、排除错误。 （3）开发进度收益：复用可以加快开发进度，可以转化为更短的产品投放市场时间。

§1.1 软件复用的概念与术语 3、软件复用的问题 （1）有限的复用潜能 （2）不能忽略的开销 （3）不能忽略的风险 （4）不能忽略的障碍：复用的引入需要对机构的运作过程做相当深入的变革。 软件复用并非万能药方，它需要精心的策划，现实的预期和长远的洞察力。

§1.2 软件复用的目的和意义 1、意义 使软件开发工作进行得“更快、更好、更省”； 提高软件生产率，降低软件生产代价； 提高软件质量；

§1.2 软件复用的目的和意义 2、对软件工程的新认识、新观点： 加深了软件是系统工程产品的认识 软件过程是软件质量的保证 软件只有适应变更才能生存 过程改善和技术提升的结合是软件产业发展的 趋势，软件复用和构件技术等正在逐步成为主流软 件技术，是软件工程化、工业化生产技术的核心技 术。

§1.3 软件复用技术发展史 1、时间编年史 60年代：手写软件，出现了软件危机 70年代中：软件工厂研究实验； 80年代后期: 构件库系统 80年代后期: 构件库系统 构件分类技术 取得进展的方面 可复用构件的创建与分发 复用支持环境 公司级复用计划 问题：复用范围太狭窄，没有达到预期的在 软件生产力和质量上的重大提高。 提出对软件复用的广义理解

§1.3 软件复用技术发展史 90年代：系统化复用 对软件体系结构的认识 对过程的改进 复用业务组织

§1.3 软件复用技术发展史 2、关键技术介绍 OO技术的崇高目标：软件组件的高度复用 现实：20多年来，这个梦想仍是遥不可及 主要原因之一：受到传统瀑布式开发的影响， 着重于系统逻辑模型的分析设计。 反省： 过去我们对软件的基本假设(assumption) 在今天的分布式开放环境潮流中，是否仍 成立？

低技术 高技术 过程 成熟 低风险途径 高风险 途径 过程 不成熟 技术改进与过程改进的关系 —技术改进必须与过程改进同时并举 理想态 承制 原始态 可能无结果途径 技术改进与过程改进的关系 —技术改进必须与过程改进同时并举

§1.3 软件复用技术发展史 CMM (Capability Maturity Model)：软件过程管理与改进，控制软件开发过程，进而提升软件质量。 CMM是软件工程过程学科中的一个 管理与改进软件过程的模式，也是一种 衡量软件开发能力和成熟度的标准。 CMM，美国卡耐基梅隆大学的软件工程研究所（SEI）提出

§1.3 软件复用技术发展史 软件过程成熟度的五个等级 软件过程能力 成熟度等级 优化级(5) 管理级(4) 定义级(3) 重复级(2) 不断改进的过程 管理级(4) 可预测的过程 软件过程能力 定义级(3) 标准的一致的过程 重复级(2) 有纪律的过程 0 1 2 3 4 5 初始级(1) 成熟度等级

5个成熟度等级在开发过程中变化的显著特点 级别 特点 1 初始级 2 重复级 3 定义级 4 管理级 5 优化级 1 初始级 软件开发过程是一个偶然的甚至无序的过程,很少有明确的定义,成功完全依赖于个体的能力. 2 重复级 实施基本的项目管理:跟踪软件成本、进度和功能。依照以往项目成功的经验来建立基本的过程规则，使得其他相似项目能重复以往的成功。 3 定义级 软件过程的管理和实行方法都已文档化、标准化，使开发商有一个开发过程的标准。即所有项目都可以依照标准来开发和维护软件。 4 管理级 定义了评估软件过程和产品质量的度量。利用此度量对软件过程和产品做出推断和控制。 5 优化级 系统地引导新理念及技术的反馈，从而不断改进软件过程。

5个成熟度等级在开发过程中变化的显著特点

§1.3 软件复用技术发展史 CMM模型与软件复用思想不谋而和 Ivar Jacboson将软件复用能力与CMM的级别对应起来： 复用能力 没有可复用的构件 1级 非标准的代码和模块复用 2级 标准化的模块复用 3级 体系结构及子系统的复用 4级 复用时避免缺陷的复用 5级

§1.3 软件复用技术发展史 CMM每上升一级都是软件复用能力的一大步提升 CMM强调的是可重复性，不止是软件的重用。 模块重用 希望做到： 源程序重用 模块重用 体系结构重用 专家思想重用 作业：CMM的理解，与当前实践结合，如何对之进行改进或扩充。

§1.3 软件复用技术发展史 目前已经出现的几个RMM（Reuse Maturity Model）介绍 （1）IBM的RMM ①初始级( Initial) 不协调的复用努力.复用是个人的行为,没有库的支持,主要的复用对象是子程序和宏; ②监控级(Monitored) 管理上知道复用,但不作为重点. 复用是小组的行为,有非正式的、无监控的数据库,复用的对象包括模块和包;

§1.3 软件复用技术发展史 ③协调级(Coordinated) 鼓励复用,但没有投资. 复用的范围包括整个部门,有配置管理和构件文档的数据库, 复用的对象包括子系统、模式和框架; ④计划级(Planned) 存在组织上的复用支持. 在项目级别支持复用,有复用库,复用的对象包括应用生成器; ⑤固有级( Ingrained) 规范化的复用支持. 复用成为整个企业范围的行为,有一组领域相关的复用库,复用的对象包括DSSA (Domain-Specific Software Architecture)。

§1.3 软件复用技术发展史 （2）Loral Federal System 公司的五级RMM ①初始级：偶尔的开发过程复用; ②基本级：在项目级上定义的开发过程复用; ③系统化级：标准的开发过程复用; ④面向领域级：大规模的子系统复用; ⑤软件制造级：可配置的生成器及DSSA.

§1.3 软件复用技术发展史 （3）HP 的五级RMM ①无复用： - 20 %至20 %的复用率; 将复用成熟度与复用率联系起来: ①无复用： - 20 %至20 %的复用率; ②挖掘整理：15 %至50 %的复用率; ③计划复用：30 %至40 %的复用率; ④系统化复用：50 %至70 %的复用率; ⑤面向领域的复用：80 %至90 %的复用率.

§1.4 软件复用产品及过程 一、复用产品 1、复用什么？－可复用资产 可执行代码：具有一定的功能，通过功能属性索引； 源代码：通过功能属性和结构属性索引； 需求规格说明书：用户需求的获取机制和编码规则，通过其所获取的功能属性索引； 设计：结构信息，采用模型表示，通过其解决问题簇的性质索引；

§1.4 软件复用产品及过程 1、复用什么？－可复用资产 测试数据：需要反复使用；通过系统输入域描述 或系统功能的某种一般指示索引； 文档：很多可复用资产都以文档表示。它通过所 描述的资产索引； 体系结构：将软件系统的结构定义为一组交换数 据的组件簇，规定了信息流、控制流或组件之间的 通信协议。通过具体化的标识表示，通过体系结构 性质索引。

§1.4 软件复用产品及过程 2、软件复用的级别 （1）代码复用 二进制形式的经过编译产生的目标代码； 文本形式的源代码； 其中目标代码的复用的抽象程度是最低的。目前大多数高级程序设计语言的开发环境都以库文件的形式向编程人员提供了对许多基本功能的支持，例如输入/输出、文件访问等功能。 源代码的复用级别略高于目标代码的复用，源代码的直接拷贝是非常原始的复用形式。

§1.4 软件复用产品及过程 （2）设计结果的复用 受实现环境的影响较小，使可复用构件被复用的机会更多，并且所需的修改更少。有三种途径： 从现有系统的设计结果中提取一些可复用的设计构 件，并把这些构件应用于新系统的设计中； 把一个现有系统的全部设计文档在新的软硬件平台 上重新实现，也就是把一个设计运用于多个具体的 实现； 独立于任何具体的应用，有计划地开发一些可复用 的设计构件。

§1.4 软件复用产品及过程 （3）分析结果的复用 可被复用的分析结果是针对问题域的某些事物或某些问题的抽象程度更高的解法，受设计技术及实现条件的影响非常小，所以可复用的机会更大。复用的途径也有三种： 从现有系统的分析结果中提取可复用构件用于新系 统的分析； 用一份完整的分析文档作输入产生针对不同软硬件 平台和其它实现条件的多项设计； 独立于具体应用，专门开发一些可复用的分析构件。

§1.4 软件复用产品及过程 （4）测试信息的复用 测试用例的复用 在多次的软件系统的测试过程中重复使用同一测试用例，以降低成本，提高软件测试的效率。 测试过程信息的复用 测试过程中记录的测试人员的操作信息，软件系统的输入、输出信息，软件系统的运行环境信息等与测试工作有关的信息。 这些信息可以在对同一软件进行修改后的后续测试工作中重复使用。

§1.4 软件复用产品及过程 3、复用的层次和粒度 （1）复用范围的五个层次： 数据复用 模块复用 结构复用 设计复用 规格说明复用 （2）复用的粒度(按粒度从大到小) ：代码和设计拷贝、源代码的复用、设计和软件体系结构复用、应用程序生成器、领域特定的软件体系结构；

§1.4 软件复用产品及过程 4、典型应用系统的构成 通用基本组件：在程序设计语言上提供通用程序设计支持的组件，包括基本的数据结构、用户界面元素等。一般最多占典型应用系统规模的20%； 领域共性组件：完成软件产品的应用领域专用的功能；最多占65％； 应用专用组件：满足特定应用需要，很难跨应用使用，一般最多占15％；

§1.4 软件复用产品及过程 4、典型应用系统的构成

§1.4 软件复用产品及过程 5、复用产品的组织－（重）复用库 可复用资产一般组织为重用库，重用库拥有一个对所包含资产的简单刻画，以方便用户浏览与检索。 （1）横向库：包含通用组件的重用库，不限于特定的应用领域； 优点：可跨应用领域使用，因而具备可供多个项目使用的能力； 缺点：仅对占应用系统规模的20％的程序起作用；

§1.4 软件复用产品及过程 5、复用产品的组织－（重）复用库 （2）纵向库：包含领域专用组件的重用库； 优点：重用资产可以最多减少必须开发的65％的代码量； 缺点：只能用在单一的应用领域内； （3）分析： 横向库提供跨领域的多样性，但在功能上有限； 纵向库提供更多的功能，但在领域多样性上有限；

§1.4 软件复用产品及过程 二、软件复用过程 1、人员及组织结构 （1）人员分类 公司管理层：发起、监督和收益； 领域工程团队：生产、分类和维护可复用资产； 应用工程团队：使用可复用资产，构建应用系统； （2）组织结构 确立各类人员的目标，协调相互关系。组织结构需要考虑因素： 各类相关人员必须有明确的目标

§1.4 软件复用产品及过程 （3）组织结构分类－最重要的组织决策之一 保证个人目标与全局目标一致 定义并实施技术标准 对各类人员提供充分激励 （3）组织结构分类－最重要的组织决策之一 以领域为中心：充分利用已有的可重用资产； 以应用为中心：以应用系统开发为主要目标 必须根据实际情况，选择组织结构，分派智力资源；

§1.4 软件复用产品及过程 2、领域工程 （1）领域分析 （2）领域工程 定性、广泛深入的分析，确定复用可能性； 区分相同点和不同点，确定开销及性价比； （2）领域工程 开发可重用基础设施：通用体系结构、结构共同点、 一组匹配体系结构的规格说明；

§1.4 软件复用产品及过程 （3）资产获取 （4）资产分类 （5）资产维护 基于复用的开发：需满足通用、可靠、可维护和文档编制要求，成本增加； 购买 （4）资产分类 分类、存储，方便检索和评估； （5）资产维护 更正性、完善性 领域工程团队的活动集中于后三个功能过程。

§1.4 软件复用产品及过程 3、应用工程 （1）采用重用开发 自顶向下 需求规格说明：描述应用系统需求 产品设计：细化到可以在重用库中找到潜在设计单元； 检索：查找与评估组件； 编写不存在单元的代码； 集成与测试

§1.4 软件复用产品及过程 将检索移至产品设计之前，可充分利用库中 已有的组件； （2）描述可重用资产 （3）复用的再工程 自底向上 以便委托领域工程团队开发； （3）复用的再工程 选择重用已开发的特定系统的组件，对之进行 再工程，以满足可复用性标准

§1.5 软件复用范例 1、软件检索范例 （1）浏览：遍历重用库，熟悉库内容，发生于产品 设计之前； （2）检索：产品设计之后 确切检索法：搜索标识精确的、满足需要的库资产； 近似检索法：搜索所有近似满足需求的库资产，然 后适配；

§1.5 软件复用范例 2、软件适配范例 （1）黑盒复用 不需知道资产的设计和实现细节，只需知道其 功能与调用协议，原封不动的使用； 普遍认识的两种重用模式： （1）黑盒复用 不需知道资产的设计和实现细节，只需知道其 功能与调用协议，原封不动的使用； （2）白盒复用 在分析与理解其实现细节的基础上，进行适配 修改后，再使用；

§1.5 软件复用范例 （3）面临问题： 黑盒复用效益更大，但较少出现； 白盒复用经常出现，但效益较小； 白盒复用的问题： 生产率损失：阅读、分析、透彻理解组件需大 量时间，可能会破坏过程； 降低程序质量：任何修改都会影响已有组件的 质量；

§1.5 软件复用范例 3、软件合成范例 （1）组合式开发 （2）生成式开发 可重用资产是完成了的可编译/可执行形式的 软件产品； 可重用资产表示为可实例化的模式，而非已完 成的产品，通过提供具体层次参数，实例化嵌入可 重用资产；

§1.5 软件复用范例 4、软件复用的形式总结： （1）根据复用活动跨越的领域可分为: 垂直(纵向)复用 水平(横向)复用 （2）根据实现复用的途径可分为: 组装式复用 生成式复用 （3）根据复用的方式可分为: 黑盒复用 白盒复用

§1.5 软件复用范例 （4）特定领域的复用 可复用软件资产的获取和生产是成功实施软件复用计划的基础 软件复用的研究和实践表明，特定领域的软件复用活动更容易取得成功

§1.5 软件复用范例 特定领域复用的基本思想

1.6 软件复用与构件技术 软件构件技术是支持软件复用的核心技术，其主要研究内容包括： 构件获取：有目的的构件生产和从已有系统中挖掘提取构件； 构件模型：研究构件的本质特征及构件间的关系； 构件描述语言：以构件模型为基础，解决构件的精确描述、理解及组装问题；

1.6 软件复用与构件技术 构件分类与检索：研究构件分类策略、组织模式及检索策略，建立构件库系统，支持构件的有效管理； 构件复合组装：在构件模型的基础上研究构件组装机制，包括源代码级的组装和基于构件对象互操作性的运行级组装； 标准化：构件模型的标准化和构件库系统的标准化。 研究构件软件的两个核心： 如何获取可复用构件 如何组装成系统并能实现互操作

1.6 软件复用与构件技术 1、可复用构件的特点 可复用构件是指可以在多个软件系统的开发过程中被重复使用的的软件产品。对可复用构件一般有以下的要求： （1）具有功能上的独立性与完整性 构件与构件之间应该具有较为松散的耦合度，并且构件与构件之间的交互应该通过良好定义的接口进行。 （2）具有较高的通用性 通用性的高低在很大程度上决定着它的适用范围；

1.6 软件复用与构件技术 （3）具有较高的灵活性（适应性） 构件应该具备灵活的调整机制，以方便重复使用，扩大其适用范围。 （4）具有严格的质量保证 可靠质量是构件被复用的基础。必须对构件进行充分的测试，测试工作应该在不同的软件和硬件环境中进行。需要考虑该构件在不同的软硬件环境中，构件是否是健壮和可靠的，是否会出现与兼容性有关的错误。

1.6 软件复用与构件技术 （5）具有较高的标准化程度 构件的实现者、实现技术可能存在差异，构件必须具有定义良好的接口，以使构件之间的交互能够通过标准化的接口进行，使组装变得容易。 （6）有用性(Usefulness) 构件必须提供有用的功能； （7）可用性(Usability) 构件必须易于理解和使用； （8）可标识性

1.6 软件复用与构件技术 2、基于构件的软件工程（CBSE） 包括两个并发的子过程： （1）领域工程：完成一组可复用构件的标识、构造、分类和传播； 领域分析 构件开发 构件库

1.6 软件复用与构件技术 （2）基于构件的开发：开发完成使用可复用构件构造新的软件系统的工作。 构件复用（产品复用的主要形式） 对选用的可复用构件需要进行的开发活动包括： 构件合格性认证； 构件适应性的修改； 构件组装； 构件更新；

1.6 软件复用与构件技术 2.1、领域分析 对特定应用领域中共同的特征、知识、需求的标识、分 析和规约，是特定领域内软件重用的基础； 目标：发现和挖掘在特定领域内可以被复用的构件。 过程归纳： 发现并描述可重用的实体； 对这些实体及它们之间的关系进行抽象化、一般化和参 数化； 对可重用的实体进行分类、归并，以备日后重用。

领域 分析 1.6 软件复用与构件技术 领 域 模 型 领 域 知 识 源 技术文件 分类方法 已完成的软件项目 复用标准 用户评述 功能/行为模型 专家建议 领域语言 目前/未来的需求 领域分析的输入和输出 领域分析是要提取出一个特定的应用领域中所有的应用系统具有的共性，并以此作为开发适用于该领域的可复用构件的基础。它具有比需求分析更一般、更抽象、更广泛的特征。

1.6 软件复用与构件技术 2.2 构件的开发 （1）设计 以领域分析的结果，作为选取和开发的指导性原则； 创建并遵循领域构件的设计框架，有助于提升构件质量； （2）编码 要充分的考虑到可复用构件与一般应用程序的显著区别； 要尽量实现可复用构件所应具备的特点：独立灵活、通用完整、高质量、标准化、可标识； 1993 年被提出的“领域专用软件体系结构”（简称DSSA），它指出了对基于DSSA 的软件开发，应采用新的软件生命 周期观点，研究符合其特点的软件开发过程。

1.6 软件复用与构件技术 （3）测试 在不同的软硬件环境中对构件进行严格和充分测试，以保证构件的质量和可靠性； （4）分类存储 分类： 需求及设计级软部件 代码级软部件 存储： 构件提交到构件库，进行存储和管理； 对构件的特征和属性进行描述的文档也需要一并提交，以保证能够进行科学的管理和高效的检索。

1.6 软件复用与构件技术 2.3 构件库（component library） （1）应具备的功能： 支持各种基本的维护操作，如增加、删除、更新操作； 支持分类存储，根据构件的分类标准和模型将构件置于合适的构件类型中。 支持高效检索，既包括精确匹配；也包括模糊匹配。

1.6 软件复用与构件技术 支持方便的、友好的用户管理和使用界面； （2）主要技术问题 构件分类 构件检索

1.6 软件复用与构件技术 2.4 构件分类 大多数的构件分类模式可以归纳为以下三种类型： （1）枚举分类 通过定义一个层次结构来对构件进行分类。 构件库中的可复用构件按照某种标准被分成了若干个大类，每个大类中的构件再被划分成若干个小类，依此类推，最终形成一个构件分类的层次结构，层次结构的最低层罗列的就是实际的构件。

1.6 软件复用与构件技术 图形用户界面枚举分类： 在形成的树形结构中，从上到下，是一个从抽象到具体的分类过程。 易于理解和检索，但在建立层次结构之前，必须进行科学的领域分析，寻找合适的分类结构。

1.6 软件复用与构件技术 （2）刻面分类 通过领域分析，构件可以被标识出来的一组基 本的描述特征，被称为刻面。一个刻面描述构件某 一个方面的特征。 刻面分类是从不同的侧面对构件进行分类。不 同的刻面根据其重要性可以设置不同的优先级。

1.6 软件复用与构件技术 动态修改菜单项构件进行刻面描述： 用户可以使用提供的一组刻面值描述所需构件的特征。结合同义词词典可以提高检索效率。 刻面分类具有较好的灵活性，易于加入新的刻面值，比枚举分类更易于扩展和修改。

1.6 软件复用与构件技术 （3）属性-值分类 定义构件的一组属性，并赋予相应的属性值。开发人员通过指定一组属性值在构件库中对构件进行检索。 与刻面分类方法的不同： 属性的数量没有限制，而刻面描述一般限制在7 或8 个刻面； 属性没有优先级，而刻面根据其重要程度，有相应的优先级； 属性一般不使用同义词字典功能，而刻面需要使用。

1.6 软件复用与构件技术 2.5、基于构件的开发 （1）构件的鉴定 考察和鉴别构件能否满足应用的需要，能否达到应用所需要的性能、可靠性、质量的要求。 （2）构件的适配 为满足软件、硬件环境和具体应用的需要，对构件进行的必要的调整和修改 （3）构件的组装 将经过鉴定和调整的构件集成到应用系统中去。通常还必须构建一个基础设施提供构件协同的模型和使构件能够交互并完成共同任务的特定服务。

CBSE过程模型 构件生产线 领域分析 构 件 开 发 构件提交 构架细化 构件/构架库 领域构架 领域构件 系统 开发 系 统 组 装 领域知识 构件生产线 领域构 件需求 领域专家经验 领域分析 构 件 开 发 分析 设计 编程 测试 领 域 构 件 现有系统资料 领域构架 构件提交 构架细化 构件/构架库 领域构架 领域构件 系统 开发 系 统 组 装 分析 设计 编程 系统 测试 问题域 应用 系统 用户需求 专 用 构 件 开 发 分析 设计 编程 测试 系统专用构件 系统生产线

1.6 软件复用与构件技术 3、构件接口（组装）技术 为促进软件构件技术的企业级软件开发，工业界提出若干构件模型。构件模型定义了开发、使用、部署(deployment)、运行和维护软件构件所必须遵守的协议和标准，即构件接口技术。 目前产业界广泛使用的具有代表性的构件模型主要有: 对象管理组织(OMG)的CORBA Microsoft的COM SUN公司的EJB/J2EE

1.6 软件复用与构件技术 4、软件架构 （1）软件构架是对系统整体结构设计的刻划，包括： 全局组织与控制结构 构件间通讯 同步和数据访问的协议 设计元素间的功能分配 物理分布 设计元素集成 伸缩性和性能 设计选择 等 。

1.6 软件复用与构件技术 （2）构架是对系统较高级别性质的描述和分析。 在基于复用的软件开发中，为复用而开发的软件构 架可以作为一种大粒度的、抽象级别较高的软件构件进 行复用，而且软件构架还为构件的组装提供了基础和上 下文，对于成功的复用具有非常重要的意义。 （3）软件构架研究如何快速、可靠地从可复用构件构造系 统的方式，着重于软件系统自身的整体结构和构件间的 互联。 主要包括：软件构架原理和风格，软件构架的描述 和规约，特定领域软件构架，构件向软件构架的集成机 制等。

青鸟软件生产线 1 2 3 4 1基础构件，2功能构件 3接口构件，4用户界面构件 领域 1 领域 2 ... 应用 系统 应用 构架库 组装 车间 构件库 4 应用构架 提取车间 构件生 产车间 1基础构件，2功能构件 3接口构件，4用户界面构件 标准规范 与 质量保证

1.6 软件复用与构件技术 青鸟软件开发过程

1.6 软件复用与构件技术 青鸟III型系统的体系结构

1.7 软件分合原理－模块与组件的区别 1、软件开发技术潮流跟随着企业管理制度思潮的演变 （1）1980年以前： 面向任务应用系统弱点： 主流管理思潮是“面向任务”(task-oriented) 层次式的组织机构(organization hierarchy)。 面向任务的软件结构是主流 面向任务应用系统弱点： 无法促进流程的顺畅。不合乎潮流，软件设计潮流也转向流程思维，于是以流为依归的软件逐渐红透半天边。

1.7 软件分合原理－模块与组件的区别 （2）1980-1995年： 面向流程系统弱点： 主流管理思潮是“面向流程”(process-oriented) 扁平式组织 进行企业流程再造 (business process reengineering, 简称BPR)。 面向流程系统弱点： 模块无法提供弹性以支持快速的流程变迁及产品组装。

1.7 软件分合原理－模块与组件的区别 （3） 1996-2005年： 主流管理思潮是“网络”(network)与知识工作者(knowledge worker) 采取价值网的组织，强调快速组装、量身订做。 软件设计潮流转向组件思维，知识工作者（即企业里的组件）与软件组件（即软件里的知识工作者）合为一体，组件迅速组装来支持知识工作者，知识工作者迅速组合来支持流程，提供给顾客快速的反应和服务。于是具有高度弹性及低维护费用的组件软件即将独领风骚。

1.7 软件分合原理－模块与组件的区别 2、模块化与组件化 本质几乎相同，两者的目的也几乎相同，但是两者 所依循的基本思维几乎完全不相同。 都是由一堆相关的函数(function)的集合体，函数 内有一串程序代码。所以本质是一样的。 目的都是要将一个大软件“分而治之”，让人们能 治大国如烹小鲜般地治理大型软件固有的复杂性。 区别只是：分而治之的“手艺”大异其趣。还有两 者背后的理念思维几乎没有交集。

1.7 软件分合原理－模块与组件的区别 （1）组件：以新手法切出来的软件零件就称为组件模块 (component module)，简称为“组件”； （2）模块：传统手法切出来的软件零件就称为功能模块 (functional module)，简称为“模块”。 从本质面看，组件就是以新手艺切出来的模块， 而模块就是传统手艺切出来的组件。

1.7 软件分合原理－模块与组件的区别 3、系统分析员的两大任务 理清企业工作流程及描述user如何使用系统（包括 画面及操作程序）。 从企业领域(domain) “分”析出组件。 为什么许多组件软件开发项目（或OO项目）会陷 入困境？ 系统分析员没有做上述的第2项工作－没有“解析” 企业及软件的体系结构，也没有依循体系结构去“分 解”成为零件。而一致地认为分解出软件组件的工作 应该归给系统的实现人员去做。

1.7 软件分合原理－模块与组件的区别 4、软件分合与组件化技术 传统的企业目标是大量生产，其基本组成组件是 部门。现在的网络企业目标则是快速量身订做，其组 件则是知识工作者。 企业的目标改变了，也促成企业组成组件的“分” 法改变了。 “分”法的改变是为了更易于组“合”来 达成企业的目标。 企业分合方式改变了，促使软件的分合也随之改 变，最大的改变是：过去是拿流程来分出模块，现在 是依循结构而分出组件，依赖流程来引导组件的组合。

1.7 软件分合原理－模块与组件的区别 5、软件分合基本概念 为什么软件开发必须重视“分”呢？ 因为软件必须快速“合”成多样化的应用程序，为顾客量身订做，提供贴心的服务。 分得好，才能合得快、合得妙！

1.7 软件分合原理－模块与组件的区别 6、模块化思维的系统分析工作 只是分析user需要什么？需要什么数据、报表、 画面等等？ 但未用心分析需要什么零件(模块)来组成 软件！   零件（模块）任由经验不足的程序设计师随心所 欲的切“分”而得，规格和品质常有问题，维护费用 自然而然急速上升。 由于“分”得不好，就“合”得不快、也合不出 高品质而多样化的软件系统！

1.7 软件分合原理－模块与组件的区别 软件的分析应该跟庖丁一样，要考虑整个企业领 域(domain)的骨架结构，做为分组件的依据，才能游 刃有余。 许多没理清模块化与组件化之间区别的PM和SA， 认为：我们仔细分析了企业领域(domain)的工作流程 (work flow)，怎么会说我们没有考虑企业的整体骨架 结构呢？ 问题：软件人员直觉认为工作流程就是企业的骨架结 构，想从流程来切分应用程序，然后由应用程序切分 组件。

1.7 软件分合原理－模块与组件的区别 工作流程是企业的骨架吗？ 工作流程是筋？还是肉？ SA在分析工作流程时的目的： 可能只是想理清User需要什么应用程序，什么画 面、报表，然后将应用程序交给程序设计师去切分模 块， SA心中的目的并不是要解析而后切分零件。

1.7 软件分合原理－模块与组件的区别 实例分析：某公司开发组件式ERP系统方法 步骤1: 仔细分析企业的工作流程。 步骤2: 将各工作流程切分为许多小的任务(task)。 步骤3: 将各项任务切分为许多小的功能函 数(operation 或function)。 步骤4: 将相关的功能组合(grouping)起来成为组件。 问题：流程是变化多端的。从不稳定的流程而量身切分出零件，零件也因而不稳定，不稳定的零件能组合出稳定的软件系统吗？ 在传统模块化思维下，软件人员为流程而量身订做组件，而不是由组装零件来量身订做流程

1.7 软件分合原理－模块与组件的区别 原因分析： 一个软件开发团队的整体从模块化转型到组件化， 其工程相当浩大的主要原因： 有些软件人员习惯于模块化思维和方法，觉得组件化并不 那么自然。 有些软件人员认为模块化就是组件化，懒得去理清两种方 法在精神和思维上的巨大而微妙的落差。 组件化手艺其实是很简单的，并没有比模块化手艺困难。 组件化是人类自然天赋的能力。组件化是较接近人们 的生活习惯，比模块化更自然。

1.7 软件分合原理－模块与组件的区别 7、组件化思维 8、总结 组件化思维：企业架构主导分，流程引导合！ 模块化思维：将流程切出模块； 企业体系结构(architectutre)决定如何“分”组件，企业工作流程(flow)决定要组“合”出什么，食谱(pattern)决定如何组合。 8、总结 组件化思维：企业架构主导分，流程引导合！ 模块化思维：将流程切出模块； 组件化是将组件组合而支持流程的千变万化。 分得好才能合得妙，不但可缩短软件开发推出时间(time-to-market)，且可创造无限的零件重复使用(reuse)机会。