第一章-软件维护概述
软件维护是软件生命周期的最后一个阶段，软件从部署完毕到退役的整个时间内对软件的改动所做的工作都是维护的内容。
改进：从较低级，较简单或较差的状态持续修改到更高，更复杂或更好的状态的过程。
可维护性：能够实施维护的容易程度。
维护：使某个实体处于维修，高率或有效性状态，防止失效或退化。
软件：将计算机变得对人们有用的程序、文档和操作过程
• 软件维护：用户投入使用以后对系统变更所做的任何工作，称为维护
• 软件产品交付之后的修改目的是修改缺陷、提高性能或其他属性，或使该软件产品适应经过修改后的环境。
• 新开发活动在一定的约束条件下从头开 始实施； • 维护活动必须在现有系统的限定和约束 条件下实施。 • 在实施系统开发和维护工作之前，应该执行“影响分析”
为什么需要软件维护和需要进行软件维护的原因见第一章ppt。
软件维护的类型:（重点）
- 纠错性维护:为了识别和纠正软件错误、改正软件性能上的 缺陷、排除实施中的误用，应当进行的诊断和改 错的过程。
- 适应性维护:为了使软件适应外部环境（新的硬、软件配置）或数 据环境（数据库、数据格式、数据输入/输出方式、数据 存储介质）发生的变化，而去修改软件的过程。
- 完善性维护:为了满足用户使用过程中对软件提出的新的功能与性 能要求，需要修改或再开发软件，以扩充软件功能、增 强软件性能、改进加工效率、提高软件的可维护性。(工作量最大)
- 预防性维护:“把今天的方法学用于昨天的系统以满足明天的需要”
第二章-软件维护框架
• 信息间隙: 这是系统用户和系统维护人员所拥有的知识体系,与双方为了满足更改请求需要拥有的知识体系之间的矛盾
• 维护挑战: 维持系统继续运行的需要
• 软件维护框架: 实施软件维护活动的背景和环境
软件工程要点
• 封装代码部分意味着，执行程序的特定部分不会意外地修改与那部分代码无关的变量。
• 恰当地将数据与代码分开，可避免不必要的代码修改。
• 恰当的使用接口明确的系统之间的真正互操作性，是实现真正灵活性的途径，是构建可维护系统的飞跃。
维护过程---重要元素
• 更改需求获取: 找出所要求的更改是什么?
• 程序设计实践变化: 编写程序和维护程序所使用的方法的差别，包括影响程序结构的功能或者操作的使用良好的程序设计实践指南: 避免使用GOTO语句；标示符有意义；按逻辑分化程序；适当注释
• 错误检测与修改: 无错软件不存在，功能再强的测试手段和工具也很难检测“残留”错误
软件维护面临的软件产品问题：应用程序领域的成熟度和难度、文档的质量、程序的可塑性、内在质量。
影响维护活动的人员因素
1.人员流动性—造成软件维护人员非原始软件编码人员
2.领域专门知识—员工转项目或部门，没系统领域知识，也没应用领域知识，产生波及效益
3.工作实践—前一维护人员的工作实践方式直接影响后面维护人员的完成任务的难易程度
软件更改分类：
纠正性：由于软件中的缺陷引起的修改（设计错误、逻辑错误、编码错误）解决方案：修补
适应性：是适应软件系统环境变化的需要所做的更改
完善性：为扩展系统的现有需求而实施的更改
预防性：为解决软件系统结构退化问题而对软件系统所做的工作
软件进化定律——Lehman定律：持续变化定律：复杂性增长定律：自我调整定律：保持机构稳定性定律：保持熟悉定律持续增长定律：质量下降定律：反馈系统定律（详情见ppt）
第三章-软件维护过程
三个有代表性的软件过程模型和生存周期模型
编码与修改模型——老模型
瀑布模型——已经很完善的模型
螺旋式模型——新模型
软件维护过程：快速修改模型、Boehm模型、Osborne模型、迭代增长模型、面向重用模型
Osborne（奥斯本）模型特点：直接面对维护环 境的现实，允许实际情况是什么样的就是什么样 的，没有理想的假设，比如假设存在完备的文档 Osborne认为：维护期间出现的很多技术问题都 是管理沟通不充分引起的
Osborne推荐采用包含以下内容的策略： 1. 包含维护需求的更改规格说明 2. 确定质量保证需求的软件质量保证程序 3. 检验维护目标是否达到的手段 4. 向经理提供反馈的绩效评审
迭代增长模型特点：针对维护进行修改后，假设有完备的文档，它对文档的修改作为每轮迭代的开始迭代增强模型是三个阶段的循环：分析、对提出更改的描述、重新设计和实现迭代增强模型的问题根源：假设有完整文档，并且维护团队有能力全面的分析现有产品
面向重用模型基本原理：维护可以看作是包含重用现有程序组件的一种活动。
Basili描述的重用模型有四个步骤： 1.标识可重用的老系统部件 2.理解这些部件 3. 修改部件，使其适应新需求 4. 把修改过的部件集成到新系统中
从生产功能上看，软件维护是一种典型的三阶段图：
1.投资：低资源、低收益，对应于紧急修改和强制增强有强烈要求的新发布软件产品
2.高回报：机构通过软件产品得到不断增强的回 报，初始问题被解决。因此资源被投入到用户增强、文档和效率上，累积收益迅速增长
3.效应减少阶段：到了一定阶段累积效益增长速 率逐渐变慢。产品达到有用性顶峰，彻底更改变得不经济
软件能力成熟度模型（重点）
- 初始级：软件过程是临时定制的。基本上没有自己定义的过程。成功取决于个人的能力
2. 可重用级：已建立基本过程、跟踪本体、进度和功能类似应用项目的成功是可重复的
3. 已定义级：过程被文档化、标准化。已经制定机构内部的软件开发和维护的标准过程。
4. 定量管理级：收集详细测量信息，既包括产品过程也包括产品质量的测量信息，已经实现定量理解和控制
5. 优化级：来自过程和创新思想与技术前导的定量反馈的到评估。使得过程能够持续改进
成功实现软件经验库的四要素：
- 文化变革——人们必须对共享知识、使用其他人的知识和经验逐渐感到自然，以便软件经验库更活跃并被使用
- 稳定性——不稳定的业务环境不适合知识和经验共享文化或系统的发展
- 业务价值——任何系统为了能够在今天的业务世界中被使用和有用，必须提供人们能够感觉到的回报
- 渐进实现——小步渐进实现软件经验库，就是要使过程接近用户，提供有效的反馈，防止软件经验库变成遥远和无关的实体
第四章-程序理解
维护人员及其信息需要
经理：经理的主要职责是:作出决策，经理需要决策支持只是，以便作出有远见的决定，所要求的理解水平取决于要做出的决定。经理不一定必须知道系统体系结构设计或下层程序实施细节
分析员：在开发期间，分析员需要理解问题域以便承担诸如确定功能需求和非功能需求，确定系统和环境之间的关系。在维护期间，分析员要关注了解这种环境的变化会怎样影响系统更改前，分析员要对系统有一个全局的认识，要理解主要功能单元之间交互的整体情况与经理一样，分析员不需求局部认识
设计员：提取信息，确认通过现有系统的体系结构、数据结构、数据流和控制流如何适应系统的增强通过现有系统的源代码，大致了解工作规模、会受影响的系统部件以前程序设计团队完成这种工作所需要的知识和技能
程序员：维护程序员需要理解不同抽象层次上的系 统执行结果、因果关系知识和产品—环境关系知识较高抽象层次上：程序员需要了解单个组件的功能及因果关系 在较低抽象层次上：程序员需要理解“每个程序语句做什么，执行顺序，数据对象的转换效 果和程序语句集合的用途”
程序理解策略三模型：自顶向下、自底向上、机会
自顶向下的模型
• 原则：理解者从理解程序的顶层细节开始，逐渐以从上到下的方式转向理解下层细节
• 从合成和理解两个认知过程来理解此模型，合成表示设计的产生，理解表示对设计的了解
• 合成——通过程序设计语言，使程序在问题域中要完成的功能映射到程序设计域中
• 理解——合成的逆过程，要从程序设计域转化到问题域，包括构造这些域及其之间的关系
• 这种重新构造过程包括假设的创建、确认和不断细化
• 生成和细化这些假设所需的信息都包括在“程 序信号”的外部属性和内部属性中自底向自底向上/团结模型
• 程序员不断认知程序中的模式，把这些模式迭代地组成高层、在语义上更有意义的结构，然后再按照自底向上的方式，把高层结构组合在一起，构成更大的结构
自顶向下和自底向上的弱点
• 没有考虑其他因素的影响，如理解的现有支持工具
• 程序理解过程很少像这些模型所描述的那样定义完备
机会模型
• 使用机会模型时，理解者既使用自底向上的模型，又使用自顶向下的策略
• 根据机会模型，程序理解依赖：知识库、概念模型和同化过程三个关键和互补的特性
• 知识库——表示维护人员带到理解任务中的专门知识和背景知识
• 概念模型——表达程序员对目标程序的当前理解
• 同化过程——描述通过各种来源，例如源代码和系统文档获得信息的规程
影响理解的因素：
专门知识、程序设计实践与现实问题、文档、程序组织与表示、支持工具与进化环境
以下方式改进的程序表示可以改善程序理解：
1. 提供程序概念模型的清晰，正确的表达，通过这种模型与程序的读者沟通；
2. 强调程序的层次结构和结构背后的程序员在逻辑和句法方面的意图的控制流；
3. 通过缩进，空行，方框和阴影，可视地改进源代码
第五章-****
****，也叫反求工程（reverse engineering）。是根据已有的东西和结果，通过分析来推导出具体的实现方法。
• 前向工程——从需求分析开始逐步实现系统的传统工程方法
• 再工程——检查和修改过程，首先对系统使用****，然后使用前向工程进行系统修改
• 结构调整——系统从一种表示形式转化成另一种表示形式
• ****——分析主系统的过程，目标是
（1）表示系统组件及其之间的关系
（2）以另一种形式或者更高抽象层次创建系统的表示
• 实物逆向：它是在已有产品实物的条件下，通过测绘和 分折，从而再创造；其中包括功能逆向、性能逆向、方 案、结构、材质等多方面的逆向。实物逆向的对象可以 是整机、零部件和组件。
• 软件逆向：产品样本、技术文件、设计书、使用说明书 、图纸、有关规范和标准、治理规范和质量保证手册等 均称为技术软件。软件逆向有三类：既有实物，又有全 套技术软件；只有实物而无技术软件；没有实物，仅有 全套或部分技术软件。
• 影像逆向：设计者既无产品实物，也无技术软件，仅有 产品的图片、广告介绍或参观后的印象等，设计者要通 过这些影像资料往构思、设计产品，该种逆向称为影像逆向。
对于软件系统，主要有三类抽象：功能抽象、数据抽象、过程抽象
• 功能抽象——又称作“规程抽象”，从目标系统引出功能，对数据对象进行操作并产生相应的输出
• 只关心功能做什么，不在乎如何操作
• 数据抽象——从目标系统引出数据对象和操作这些数据对象的功能。
• 它的焦点是数据对象，实现细节被认为与数据抽象无关过程抽象
• 过程抽象——从目标系统中提取执行操作的确切顺序
• 两类过程可以抽象——并发过程和分布过程
• 并发过程通过存储在指定内存空间中的共享数据通信
• 分布过程通过“消息传递”通信，没有共享数据区
****的好处和目标见第五章ppt。
****分析方法（重点）
• 词法分析和语法分析：该方法主要是对程序源码进行分析,得到程序信息的多种有用表示,其中常用的就是交叉引用列表。
• 通过语法分析可以得到两类表示:分析树 (parse tree) 、抽象语法树AST(abstract syntax tree) ,其中AST 是更复杂的程序分 析工具基础,包含了和程序的实际内容相关的细节。
• 图形化方法：图形化方法包括控制流分析、数据流分 析以及程序依赖图。控制流分析是在确 定程序语法结构之后进行。数据流分析 关注于解决程序中从定义到使用的过程 的相关的问题,程序依 • 赖图是数据流分析的进一步改进,比数据 流分析更复杂。在程序依赖图中,控制流 和数据流依赖放在一起处理。
• 程序切片：切片技术来源于数据流分析方法,已经成 为很多程序理解工具的基础。一个程序 切片是由程序中的一些语句和判定表达 式组成的集合。
• 动态分析：静态分析是对程序源码进行分析。动态 分析则是在程序运行时进行分析,基本方法是对程序进行植入。植入是在一种在全局范围内更改源代码以添加额外操作的过程。
支持手段
• 正向工程： • 正向工程也叫改造，用从现存软件的设计恢 复中得到的信息去重构现存系统，以改善其 整体质量。 • 正向工程过程应用软件工程的原则、概念和 方法来重建造某现存应用。 • 在大多数情况，正向工程并不仅仅是创建某 旧程序的一个现代等价物，而是将新的用户 和技术需求集成到再工程中，重新开发的程 序扩展了旧应用的能力。
• 结构调整： • 结构调整包括在相同的相对抽象层次上 ，不改变系统的功能或语义地把系统从 一种表示形式转换为另一种表示形式。 • 控制流驱动的结构调整； • 效率驱动的结构调整； • 适配驱动的结构调整
• 再工程： • 研究并改变目标系统实现所要求的修改 的过程； • 对目标系统运用****，以便理解并 以一种新的形式表示； • 运用****，实现和集成新的需求， 后得到新的经过增强的系统。
第六章-重用与可重用性
重用的对象
• 代码的重用
• 与重用程序有关的知识的重用
• 过程、模块、程序包的重用
• 可重用性——上述对象能够被重用的程度
• 用来评估可重用性的一些属性——重用的结构、功能、测试层次、复杂性和频度
• 可以重用
过程
• 过程重用——运用给定的方法论解决不同的问题
• 越来越多的实验表明：过程重用对生产率和产品质量影响很大
• 人们会逐渐熟悉所重复使用的操作，发现并解决问题，重复使用所得到收益很可能增长
人员
• 人员重用意味着重用人员在以前类似的问题或者应用领域上获得的知识
• 这种专门的知识称为“领域知识”
• 这类知识很难作为理论讲授
• 人员知识的重用极不稳定，不可看成是机构的一 种固定资产？——知识获得的难度，软件行业人员流动性大
• 方法——解决高流动性问题，建立软件经验库
产品
• 产品重用包括使用类似项目的产品作为工作产品，包括：数据、设计、程序的重用数据
数据：可重用的数据使得数据能够在应用系统之间共享，并促进程序的普遍重用；可重用数据在数据库系统中起着关键的作用
产品的设计：即体系结构设计和详细设计
• 体系结构设计——软件产品主要组件的抽象或者图表示
• 详细设计——体系结构设计的细化
• 系统设计表示方式：背景图、数据 流图、实体-关系图、状态转移图、对象模型程序
•程序重用：重用经过少量修改或不需要修改就可以集成到软件系统中的代码组件；函数库、高级语言或者面向对象的语言、商品化的软件包（电子表格）
重用的目标和好处见第六章ppt
重用方法——合成：被重用的组件是要装配到目标系统中的原子构件块，即组件在被重用后，仍然保持其基本特性。 比如程序模块、例程、函数和对象
• 合成机制的一个简单例子——UNIX管道，即将一个程序的输出连接到另一个程序的输入，它可合并较小的程序形成更大的程序
• 在面向对象编程中，使用继承原理可得到这种合成机制，可通过现有组件构造新的组件（另一组件的修改，或其他组件的组合）
• 合成的两种方式——黑盒 VS 白盒
• 黑盒合成——合成期间，要重用的组件没有修改
• 白盒合成——组件被重用前需要修改
重用方法——生成重用
• 可重用的组件式用来生成目标系统的主动实体，生成目标产品的程序
• 应用系统生成器
• 基于转换的系统
• 介于生成器系统的进化
领域分析
• 重用组件的两大类：横向可重用组件和纵向可重用组件
• 横向重用——是能够在各种不同领域中运用的组件，例如算法和数据结构
• 纵向重用——针对给定问题域内部应用系统的组件重用
• 纵向重用具有面向应用领域的性质，因此常常需要标识领域内的共有问题，并试图对这 些问题提出“标准”解决方案，这可以使用领域分析
• ——标识、获取和组织开发和维护软件系统所使用信息的过程，目的是时其在维护现有
系统时能够被重用
• 领域分析最好由具有开发同一领域很多系统经验的领域专家进行，对于专门开发特定软件系统解决特定问题集的机构来说，这一点非常重要
• 领域分析的好处和妨碍机构实施领域分析的因素见第六章ppt。
• 组件获得途径：（1）为重用而设计的一种过 程，开发要在多种场合使用的组件；（2）通
过****
• 可重用性组件设计的特性：
• 1. 通用性——组件要潜在的用于范围很广地应用系统或在问题域
• 2. 内聚性与交合性，内聚性——内部属性， 描述元素的相关程度，交合性——外部属性，刻画给定系统中两个或者多个模块之间的相互独立性
• 3. 交互性：应尽量降低每行源代码的读写语句数量表示与用户之间的交互性
• 4. 统一性与标准化——对于不同级别的软件采用标准会提高软件组件的可重用性，如界面设计，程序设计风格、数据结构设计和文档
• 5. 数据与控制抽象性——数据抽象包括抽象数据类型，封装和继承；控制抽象包括外部模块和调用者
• 6. 可互操作性——可互操作性会使系统能够利用远程服务提高可重用性重用库
• 组件库设计和获取候选组件有关的几个问题：
• 1. 粒度和尺度两难问题——在设计组件库时，组件要具有合适的尺寸，以便提高组件可理解性和通用潜力，这意味着组件库要包含很多小型组件，但这样又会带来分类和搜索问题
• 2. 搜索问题——如果没有合适的机制描述组件库的内容，用户很难找出与待构建系统的需求吻合的组件，从组件库中查找合适的软件可能比从新编写代码都难
• 3. 分类问题——在组件库中存储有关组件库中包含哪些组件的信息是很重要的。常可按照：功能（组件做什么）、环境（组件用在什么地方）和实现细节（组件怎么做）来分类
• 4. 规格说明与灵活性问题——在组件库中描述系统要做什么很难，描述系统如何做和对系统的使用约束也很难
根据工具所支持的特定任务可以将软件维护工具分为以下几类： –1、版本控制工具； –2、文档分析工具； –3、开发信息库工具； –4、程序理解和****工具； –5、再工程工具； –6、配置管理支持工具
通用重用模型5步骤
1. 理解要解决的问题，根据已有的预先定义的组件标识解决方案结构
2. 重新配置解决方案结构，以最大限度提高当前和下一阶段的重用潜力。
这阶段要吸收下一阶段的领域专家研究当前阶段所提出的解决方案，并标识下一阶段可用的可重用组件。可使用多种手段来标识可重用组件，可用功能、
逻辑、前提、后果等要素作为选择组件的准则
3. 准备好解决方案结构中所标识的可重用组件，随时准备集成。包括获取可重用组件，根据要解决的问题修改和实例化这些组件。对于不能获取的组件或从经济上看不能修改的组件，需要开发新的可重用组件
4. 将已经完成的组件集成到软件生存周期下一个阶段所要求的产品中。
5. 以前的经验被用来评估两类组件的可重用性第一类组件是需要针对问题开发的组件，这些问题没有现成的可重用组件；第二类是通过适配以前定义过的组件获得的组件。进行这种评估的结果再用来更新当前的可重用组件库
提高维护生产率的方法见第六章ppt。