第10章 软件演化、再工程与逆向工程
软件工程导论名词解释
名词解释1.数据词典——是描述数据信息的集合，它对数据流图中的各个元素按规定格式进行详细的描述和确切的解释,是数据流图的补充工具。
2.数据流图——他以图形的方式反映系统的数据流程3.白盒测试——按照程序内部的结构测试程序，检验程序中的每条路径是否都能按预定要求正确工作。
有两种测试法既逻辑覆盖测试法和路径测试法4.黑盒测试——按照程序的功能测试程序，检验与程序功能有关的输入、输出与程序执行是否正确。
有四种方法既等价分类法、边界值分析法、错误猜测法和因果图法5.完善性维护——为了适应用户业务和机构的发展变化而对软件的功能、性能进行修改、扩充的过程称为完善性维护。
因为各种用户的业务和机构在相当长的时期内不可能是一成不变的，所以功能、性能的增加是不可避免的，而且这种维护活动在整个维护工作中所占的比重很大6.软件可靠性——指在给定的时间内，程序按照规定的条件成功地运行的概率7.软件配置——是一个软件在生存周期内，他的各种形式、各种版本的文档与程序的总称8.软件再工程——运用逆向工程、重构等技术，在充分理解原有软件的基础上，进行分解、综合、并重新构建软件，用于提高软件的可理解性、可维护性可复用性或演化性。
9.α测试——是在一个受控的环境下，由用户在开发者的“指导”下进行的的测试，由开发者负责记录错误和使用中出现的问题。
10.β测试——是由软件的最终用户（多个）在一个或多个用户场所来进行。
由用户负责记下遇到的所有问题，包括主观认定的和真实的问题，定期向开发者报告，开发者在综合用户的报告之后进行修改，最后将软件产品交付给全体用户使用。
11.聚集关系——表示类或对象之间的整体与部分的关系12.泛化关系——表示类或对象之间的一般与特殊的关系13.内聚——一个模块内部各个元素彼此结合的紧密程度的度量。
14.耦合——一一个软件结构内不同模块之间互连程度的度量。
名词解释：一章：软件危机：是指在计算机软件的开发和维护过程中所遇到的一系列严重问题。
第10章 软件产品线体系结构
小议软件保护措施中的软件逆向工程技术
图。
（ ）程 序 切 片 。 二 切 片 技 术 是 将 程 序 简 化 为 和 某 个 特 殊 计 算 相 关 的 语 句 的 技 术 ，来 源 于 数 据 流 分 析 方 法 。 切 片 技 术 自动 将 程 序 分 解 为 较 小 的 称 为切 片 的代码 段 ，使 关注 点确定 在一 个较 小 范 围 而 不 必 关 注 整 个 程 序 。 一 个 程 序 切 片 是 由程序 中的一 些语 句和判 定表达 式组 成的集 合 。 这 些 语 句 和 判 定 表 达 式 可 能 会 影 响 在 程 序 的某个 位置 （ 用 行号标 识） 所 定义或使 常 上 用 的 变 量 的 值 。 切 片 技 术 己经 成 为 很 多 程 序 理 解 工 具 的基 础 。 （ ） 象解释 。 三 抽 抽 象 解 释 是 对 程 序 语 言 的 语 义 形 式 上 构 建 一 个 保 守 的 近 似 ，用 基 于 语 义 的 分 析 来 确
一
三 、逆 向工 程 的 分 析 方 法 （ ） 形化 方 法 。 一 图 图形化 方法 包括 控制流 分析 、数据 流分 析 以 及 程 序 依 赖 图 。 控 制 流 分 析 对 执 行 语 句 的若 干可 执行路 径进 行分 析，确 定程 序的控
制 结构 ，建立控 制流 图 控 制流 分析 有两种 形 式 ： 程 内分 析 和 过 程 间 分 析 。 过 程 内分 析 过 通 过 构 建 控 制 流 图Ｃ Ｇ（ｏ ｔｏ ｆ ｏ ｒ ｐ ） Ｆ ｃ ｎ ｒ ｌ ｌｗ ｇ ａ ｈ 进行 ，可 确定 子程序 内语 句的执 行顺 序 。构 建 ＣＧ Ｆ 必须 先确定 子程序 的基本块 。一个基 本 块 对 应 Ｃ Ｇ 一 个 节 点 ，是 一 些 连 续 语 句 的 Ｆ中 最 大 集 合 。在 该 语 句 集 合 中 ，控 制 只 能 从 第 条语句 开始 ，也 只能从 最后 一条语 句经 条 件 分 支 或 非 条 件 分 支 转 出 。 就 是 说 基 本 块 的 第 一 句 执 行 ， 基 本 块 中所 有 语 句 都 会 执 行 。 基 本 块 可 以直 接 通 过 遍 历 Ａ Ｔ 定 ，再 用控 制 Ｓ确 流 弧 线 连 接 基 本 块 来 创 建 Ｃ Ｇ 过 程 间 控 制 Ｆ。 流 分析 是确 定系统 子程序 之 间可 能的控制 流 路 径 的 过 程 ， 用 调 用 图 （ａｌ ｇ ａ ｈ 表 Ｔ ｃ ｌ ｒｐ ） 。 调 用 图给 出了一个 系统 中对子 程序 的可 能调 用 。调 用 图 是 树 、 有 向 无 环 图 还 是 一 般 的 图 由 系 统 结 构 决 定 。 调 用 图 中 的 结 点 和 子 程 序 对 应 ， 节 点 之 间 的 有 向 弧 标 识 出调 用 关 系 。 控 制 流 分 析 对 执 行 语 句 的 若 干 可 执 行 路 径 进 行 分 析 ，确 定 程 序 的 控 制 结 构 ， 建 立 控 制 流
软件工程导论课件(第六版)(张海潘编著)(1-13章)
13
件，把经过时间考验而证明正确的管理技术和当前能够得 到的最好的技术方法结合起来，以经济地开发出高质量的 软件并有效地维护它，这就是软件工程。
第1章 软件工程学概述
1.2.1
软件工程的介绍
1.2 软件工程
1968年在第一届NATO会议上曾经给出了软件工程的一个
14
早期定义：“软件工程就是为了经济地获得可靠的且能在 实际机器上有效地运行的软件，而建立和使用完善的工程 原理。” 1993年IEEE进一步给出了一个更全面更具体的定义： “软件工程是： ①把系统的、规范的、可度量的途径应用 于软件开发、运行和维护过程，也就是把工程应用于软件； ②研究①中提到的途径。
第1章 软件工程学概述
1.2.1
软件工程的介绍
1.2 软件工程
软件具有的本质特性
软件工程关注于大型程序的构造 软件工程的中心课题是控制复杂性 软件经常变化 开发软件的效率非常重要 和谐地合作是开发软件的关键 必须有效地支持它的用户 两种背景的人创造产品这个特性与前两个特性紧密相关
15
第1章 软件工程学概述
充分认识到软 2件开发不是某 种个体劳动的 神秘技巧 ， 而应该是各类 人员协同配合， 共同完成的工 程项目。 推广使用在实 3践中总结出来 的开发软件的 成功的技术和 方法，并且研 究探索更好更 有效的技术和 方法。
11
首先应该对计 1算机软件有一 个正确的认识。
应该开发和使 4用更好的软件 工具。
1.4 软件过程
1.4 软件过程
1.4.1 瀑布模型
34
瀑布模型一直是唯一被广泛采用的生命周期模型，现在它 仍然是软件工程中应用得最广泛的过程模型。如下图所示为 传统的瀑布模型
图1.2传统的瀑布模型如图1.2所示为传统的瀑布模型。
【软件体系结构】 复习
第一章1. 体系结构发现、演化、重用体系结构发现解决如何从已经存在的系统中提取软件的体系结构，属于逆向工程范畴。
由于系统需求、技术、环境、分布等因素的变化而最终导致软件体系结构的变动，称之为软件体系结构演化。
体系结构重用属于设计重用，比代码重用更抽象。
由于软件体系结构是系统的高层抽象，反映了系统的主要组成元素及其交互关系，因而较算法更稳定，更适合于重用。
2.基于软件体系结构的软件开发方法：问题定义—>软件需求—>软件体系结构—>软件设计—>软件实现3.评价软件体系结构的方法权衡分析方法（ATAM方法），软件体系结构分析方法（SAAM方法）,中间设计的积极评审（ARID方法）第二章1. 建模结构模型：研究结构模型的核心是体系结构描述语言。
以体系结构的构件，连接件和其他概念来刻画结构。
并力图通过结构来反映系统的重要语义内容。
框架模型：与结构模型类似，但不太侧重细节，而侧重于整体结构。
动态模型：是对结构和框架模型的补充，研究系统大颗粒的行为性质。
过程模型：研究构造系统的步骤和过程，结构是遵循某些过程脚本的结果。
功能模型：认为体系结构是由一组功能构件按层次组成，下层向上层提供服务。
功能模型可以看作是一种特殊的框架模型。
4+1视图模型：逻辑视图、进程视图、物理视图、开发视图和场景视图逻辑视图主要支持系统的功能需求，即系统提供给最终用户的服务。
在逻辑视图中，系统分解成一系列的功能抽象，这些抽象主要来自问题领域。
这种分解不但可以用来进行功能分析，而且可用作标识在整个系统的各个不同部分的通用机制和设计元素。
在面向对象技术中，通过抽象、封装和继承，可以用对象模型来代表逻辑视图，用类图来描述逻辑视图开发视图通过系统输入输出关系的模型图和子系统图来描述。
进程视图侧重于系统的运行特性，主要关注一些非功能性的需求。
物理视图主要考虑如何把软件映射到硬件上。
逻辑视图和开发视图描述系统的静态结构，而进程视图和物理视图描述系统的动态结构。
软件工程-课程目录-大纲视图(全国高等教育自学考试指定教材-计算机网络专业-独立本科)
第一章绪论1.1 软件工程概念的提出与发展1.2 软件开发的本质1.3 本章小结第二章软件需求与软件需求规约2.1 需求与需求获取2.1.1需求定义2.1.2 需求分类2.1.3 需求发现技术2.2 需求规约2.2.1 需求规约定义2.2.2 需求规约（草案）格式2.2.3 需求规约（规格说明书）的表达2.2.4 需求规约的作用2.3 本章小结第三章结构化方法3.1 结构化需求分析3.1.1 基本术语1.数据流2.数据存储3.数据源和数据谭3.1.2 系统功能模型表示数据流图（Dataflow Diagram）3.1.3 建模过程1.建立系统环境图, 确定系统语境2.自顶向下, 逐步求精, 建立系统的层次数据流图3.定义数据字典数据流条目给出所有数据流的结构定义数据存储条目给出所有数据存储的结构定义数据项条目给出所有数据项的类型定义4.描述加工（1）结构化自然语言（2）判定表（3）判定树3.1.4 应用中注意的问题（1）模型平衡问题（2）信息复杂性控制问题3.1.5 需求验证3.2 结构化设计3.2.1 总体设计1.总体设计的目标及其表示（1）Yourdon提出的模块结构图（2）层次图（3）HIPO图2.总体设计步骤（1）变换型数据流图——变换设计（2）事物型数据流图——事物设计3.模块化及启发式规则（1）模块化1）耦合①内容耦合②公共耦合③控制耦合④标记耦合⑤数据耦合2）内聚①偶然内聚②逻辑内聚③时间内聚④过程内聚⑤通信内聚⑥顺序内聚⑦功能内聚（2）启发式规则1）改进软件结构, 提高模块独立性2）力求模块规模适中3）力求深度、宽度、扇出和扇入适中4）尽力使模块的作用域在其控制域之内5）尽力降低模块接口的复杂度6）力求模块功能可以预测3.2.2 详细设计1.结构化程序设计2.详细设计工具（1）程序流程图（2）盒图（N-S图）（3）PAD图（Problem Analysis Diagram）（4）类程序设计语言IPO图、判定树和判定表等也可以作为详细设计工具3.3 本章小结第四章面向对象方法——UML 4.1 UML术语表4.1.1 表达客观事物的术语1.类与对象1）类的属性（Attribute）2）类的操作3）关于类语义的进一步表达①详细叙述类的职责（Responsibility）②通过类的注解和/或操作的注解, 以结构化文本的形式和/编程语言, 详述注释整个类的语义和/或各个方法③通过类的注解或操作的注解, 以结构化文本形式, 详述注释各个操作的前置条件和后置条件, 甚至注释整个类的不变式④详述类的状态机⑤详述类的内部结构⑥类与其他类的协作4）类在建模中的主要用途①模型化问题域中的概念（词汇）②建立系统的职责分布模型③模型化建模中使用的基本类型2.接口（Interface）（1）采用具有分栏和关键字《interface》的矩形符号来表示（2）采用小圆圈和半圆圈来表示3.协作（Collaboration）4.用况（Use Case）5.主动类（Action Class）6.构件（Component）7.制品（Artifact）8.节点（Node）4.1.2 表达关系的术语1.关联（Association）（1）关联名（Name）（2）导航（3）角色（Role）（4）可见性（5）多重性（Multiplicity）（6）限定符（Qualifier）（7）聚合（Aggregation）（8）组合（Composition）（9）关联类（10）约束①有序（ordered）②无重复对象（set）③有重复对象（bag）④列表（list）或序列（sequence）⑤只读（readonly）2.泛化（Generalization）①完整（Complete）②不完整（Incomplete）③互斥（Disjoint）④重叠（Overlapping）3.细化（Realization）4.依赖①绑定（Bind）②导出（Derive）③允许（Permit）④实例（InstanceOf）⑤实例化（Instantiate）⑥幂类型（Powertype）⑦精化（Refine）⑧使用（Use）可模型化以下各种关系（1）结构关系1）以数据驱动2）以行为驱动（2）继承关系（3）精化关系（4）依赖关系4.1.3 表达组合信息的术语——包1）访问（Access）2）引入（Import）4.2 UML模型表达格式1.类图（Class Diagram）（1）模型化待建系统的概念（词汇）, 形成类图的基本元素（2）模型化待建系统的各种关系, 形成该系统的初始类图（3）模型化系统中的协作, 给出该系统的最终类图（4）模型化逻辑数据库模式2.用况图（Use Case Diagram）所包含的内容（1）主题（Subject）（2）用况（Use Case）（3）参与者（Actor）（4）关联、泛化与依赖模型化工作1）关于系统/业务语境的模型化①系统边界的确定②参与者与用况的交互③参与者的语义表达④参与者的结构化处理2）关于系统/业务需求的模型化①确定系统/业务的基本用况②用况的结构化处理③用况的语义表达3.状态图（1）状态1）名字2）进入/退出效应（Effect）①entry②exit③状态内部转移3）do动作或活动4）被延迟的事件（2）事件1）信号（Signal）事件2）调用（Call）事件3）时间事件4）变化事件（3）状态转移①源状态②转移触发器③监护（guard）条件④效应（effect）⑤目标状态实际应用中, 使用状态图的作用①创建一个系统的动态模型②创建一个场景的模型4.顺序图（1）术语解析1）消息2）对象生命线3）聚焦控制（the Focus of Control）（2）控制操作子1）选择执行操作子（Operator for Optional Execution）2）条件执行操作子（Operator for Conditional Execution）3）并发执行操作子（Operator for Parallel Execution）4）迭代执行操作子（Operator for Iterative Execution）4.3 本章小结第五章面向对象方法——RUP5.1 RUP特点1.以用况为驱动2.以体系结构为中心3.迭代增量式开发5.2 核心工作流5.2.1 需求获取1.列出候选需求2.理解系统语境（1）业务用况模型（2）业务对象模型3.捕获系统功能需求（1）活动1: 发现并描述参与者（2）活动2: 发现并描述用况（3）活动3: 确定用况的优先级（Priority）（4）活动4: 精化用况（5）活动5: 构造用户界面原型1）用户界面的逻辑设计2）物理用户界面的设计3）开发用户界面原型并演示为了执行该用况, 用户怎样使用该系统（6）活动6: 用况模型的结构化5.2.2 需求分析1.基本术语（1）分析类（Analysis Class）1）边界类（Boundary Classes）2）实体类（Entity Classes）3）控制类（Control Classes）（2）用况细化（Use Case Realization）（3）分析包（Analysis Package）2.分析模型的表达3.分析的主要活动（1）活动1: 体系结构分析（Architectural Analysis）1）任务1: 标识分析包2）任务2: 处理分析包之间的共性3）任务3: 标识服务包4）任务4: 定义分析包的依赖5）任务5: 标识重要的实体类6）任务6: 标识分析包和重要实体类的公共特性需求（2）活动2: 用况分析1）任务1: 标识分析类①标识实体类②标识边界类③标识控制类2）任务2: 描述分析（类）对象之间的交互（3）活动3: 类的分析1）任务1: 标识责任2）任务2: 标识属性①关于实体类属性的标识②关于边界类属性的标识③关于控制类属性的标识3）任务3: 标识关联和聚合①关于关联的标识②关于聚合的标识③关于泛化的标识（4）活动4: 包的分析4.小结（1）关于分析模型1）分析包2）分析类3）用况细化（2）关于分析模型视角下的体系结构描述（3）用况模型和分析模型比较（4）分析模型对以后工作的影响1）对设计中子系统的影响2）对设计类的影响3）对用况细化[设计]的影响5.2.3 设计1.设计层的术语（1）设计类（Design Class）（2）用况细化[设计]（3）设计子系统（4）接口（Interface）2.设计模型、部署模型以及相关视角下的体系结构描述（1）设计模型及其视角下的体系结构描述1）子系统结构2）对体系结构有意义的设计类3）对体系结构有意义的用况细化[设计]（2）部署模型及该模型视角下的体系结构描述3设计的主要活动（1）活动1: 体系结构的设计1）任务1: 标识节点和它们的网络配置2）任务2: 标识子系统和它们的接口①标识应用子系统②标识中间件和系统软件子系统③定义子系统依赖④标识子系统接口3）任务3: 标识在体系结构方面有意义的设计类和它们的接口4）任务4: 标识一般性的设计机制①标识处理透明对象分布的设计机制②标识事务管理的设计机制（2）活动2: 用况的设计1）标识参与用况细化的设计类2）标识参与用况细化的子系统和接口（3）活动3: 类的设计1）任务1: 概括描述设计类2）任务2: 标识操作3）任务3: 标识属性4）任务4: 标识关联和聚合5）任务5: 标识泛化6）任务6: 描述方法7）任务7: 描述状态（4）活动4: 子系统的设计1）任务1: 维护子系统依赖2）任务2: 维护子系统所提供的接口3）任务3: 维护子系统内容4.RUP设计小结1）RUP设计的突出特点2）关于RUP的设计方法①给出用于表达设计模型中基本成分的4个术语, 包括子系统, 设计类, 接口, 用况细化[设计]②规约了设计模型的语法, 指导模型的表达③给出了创建设计模型的过程以及相应的指导3）RUP的设计模型①设计子系统和服务子系统②设计类（其中包括一些主动类）, 以及他们具有的操作、属性、关系及其实现需求。
软件工程_张海蕃
应该推广使用在实践中总结出来的开发软件的成功 的技术和方法，并且研究探索更好更有效的技术和 方法，尽快消除在计算机系统早期发展阶段形成的 一些错误概念和做法。 应该开发和使用更好的软件工具。正如机械工具可 以“放大”人类的体力一样，软件工具可以“放大” 人类的智力。在软件开发的每个阶段都有许多繁琐 重复的工作需要做，在适当的软件工具辅助下，开 发人员可以把这类工作做得既快又好。如果把各个 阶段使用的软件工具有机地集合成一个整体，支持 软件开发的全过程，则称为软件工程支撑环境。
与软件开发和维护有关的许多错误认识和作法的形 成，可以归因于在计算机系统发展的早期阶段软件 开发的个体化特点。错误的认识和作法主要表现为 忽视软件需求分析的重要性，认为软件开发就是写 程序并设法使之运行，轻视软件维护等。
事实上，对用户要求没有完整准确的认识就匆忙着 手编写程序是许多软件开发工程失败的主要原因之 一。只有用户才真正了解他们自己的需要，但是许 多用户在开始时并不能准确具体地叙述他们的需要， 软件开发人员需要做大量深入细致的调查研究工作， 反复多次地和用户交流信息，才能真正全面、准确、 具体地了解用户的要求。对问题和目标的正确认识 是解决任何问题的前提和出发点，软件开发同样也 不例外。急于求成，仓促上阵，对用户要求没有正 确认识就匆忙着手编写程序，这就如同不打好地基 就盖高楼一样，最终必然垮台。事实上，越早开始 写程序，完成它所需要用的时间往往越长。
另一方面还必须认识到程序只是完整的软件产品的 一个组成部分，在上述软件生命周期的每个阶段都 要得出最终产品的一个或几个组成部分(这些组成 部分通常以文档资料的形式存在)。也就是说，一 个软件产品必须由一个完整的配置组成，软件配置 主要包括程序、文档和数据等成分。必须清除只重 视程序而忽视软件配置其余成分的糊涂观念。 作好软件定义时期的工作，是降低软件成本提高软 件质量的关键。如果软件开发人员在定义时期没有 正确全面地理解用户需求，直到测试阶段或软件交 付使用后才发现“已完成的”软件不完全符合用户 的需要，这时再修改就为时已晚了。
《逆向工程技术》课程标准
《逆向工程技术》课程标准一、课程简介逆向工程技术是一门融合了机械设计、测量技术、计算机技术、数据处理等多学科的综合性技术，广泛应用于制造、设计、测量等领域。
本课程旨在让学生了解逆向工程的基本概念、原理和方法，掌握逆向工程的实践技能，培养其在实际工作中运用逆向工程技术解决复杂问题的能力。
二、课程目标1. 掌握逆向工程的基本原理和方法，包括三维测量、数据处理、模型重构等；2. 学会使用逆向工程相关软件，如3D扫描仪、Geomagic、Imageware 等；3. 能够独立完成简单的逆向工程设计任务；4. 培养良好的团队协作和沟通能力，能够在实际工作中与其他专业人员有效配合。
三、教学内容1. 基础知识：介绍逆向工程的基本概念、原理和方法，包括三维测量技术、数据处理方法、模型重构技术等；2. 软件操作：学习使用逆向工程相关软件，如3D扫描仪、Geomagic、Imageware等，掌握软件的安装、使用方法和基本操作技巧；3. 实践操作：通过实际案例，让学生独立完成简单的逆向工程设计任务，包括数据采集、模型重构、后处理等；4. 综合应用：结合实际生产案例，培养学生运用逆向工程技术解决复杂问题的能力，提高其在实际工作中的应变能力和创新能力。
四、教学方法与手段1. 理论讲授与实践操作相结合：采用案例教学、互动教学等方式，让学生在学习过程中逐步掌握逆向工程的基本原理和方法，并能够熟练运用相关软件进行实践操作；2. 小组合作：将学生分成若干小组，通过实际案例的实践操作，培养学生的团队协作和沟通能力，提高其实践操作能力和解决问题的能力；3. 定期考核：通过定期的考核和评估，及时了解学生的学习情况，发现问题并及时调整教学策略，确保教学质量。
五、课程评估本课程的评估方法包括平时作业、实践操作、小组作品展示和期末考试等。
平时作业主要考察学生对逆向工程基本原理和方法的掌握情况；实践操作主要考察学生运用逆向工程相关软件进行实践操作的能力；小组作品展示则是让学生以小组为单位，展示实际案例的实践操作成果，考察学生的团队协作和沟通能力；期末考试则主要考察学生对本课程知识的综合运用能力。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
第10章软件演化、再工程与逆向工程10.1 软件演化的基本概念10.1.1 软件演化、软件维护与软件复用10.1.2 软件演化的分类10.2 设计时演化10.2.1 设计模式对设计时演化的支持10.2.2 构件技术对设计时演化的支持1. 构件包装2. 基于继承机制的构件演化10.2.3 框架技术对设计时演化的支持1.白箱框架2. 黑箱框架10.3 软件再工程10.3.1 概述软件再工程是指对既存对象系统进行调查，并将其重构为新形式代码的开发过程。
最大限度地重用既存系统的各种资源是再工程的最重要特点之一。
从软件重用方法学来说，如何开发可重用软件和如何构造采用可重用软件的系统体系结构是两个最关键问题。
不过对再工程来说前者很大部分内容是对既存系统中非可重用构件的改造。
在软件再工程的各个阶段，软件的可重用程度都将决定软件再工程的工作量。
（1）再分析。
再分析阶段的主要任务是对既存系统的规模、体系结构、外部功能、内部算法、复杂度等进行调查分析。
这一阶段早期分析最直接目的就是调查和预测再工程涉及的范围。
北京工业大学软件工程研究所研制开发的“软件再工程辅助调查工具——SFRE”正是从整体上支持该分析阶段的再工程自动化工具。
重用是软件工程经济学最重要原则之一，重用得越多，再工程成本越低，所以逆向工程再分析阶段最重要的目的是寻找可重用的对象和重用策略，最终确定的再工程任务和工作量也将依存于可重用对象范围(重用率)和重用策略。
与一次工程不同，再工程分析者最终提出的重用范围和重用策略将成为决定再工程成败以及再工程产品系统可维护性高低的关键因素。
如果重用对象都是既存代码级的当然理想，然而可能性有限。
但是再工程分析者如果因此而放弃重用，以为“改他人的代码不如自己重新编写”，便犯了再工程的大忌。
因为一个运行良久的既存系统，最起码的价值是在操作方法和正确性上已被用户接受。
而再高明的程序员在软件没有经过用户一段时间的使用验证之前都不敢保证自己的程序正确无误;更何况越是有经验的程序员越是知道对一个处于局部变更地位的程序进行重新编写远比一次工程的原始编程复杂得多，因为他需要对应无数的“副作用”，正所谓“碰一筋而动全身”。
所以，读文档——即使是“破烂不堪”、读代码——即使是“千疮百孔”，也要坚持住，并且从中筛出可重用对象。
（2）再编码。
根据再分析阶段做成的再工程设计书，再编码过程将在系统整体再分析基础上对代码做进一步分析。
如果说再分析阶段产品是再工程的基本设计书，那么再编码阶段如同一次工程一样，先要产生的是类似详细设计书的编码设计书。
但是再工程比一次工程更难以进行过程分割，换言之，瀑布模型更不适应再工程，无法将再分析、再设计、再编码截然分开。
（3）再测试。
一般来说，再测试是再工程过程中工作量最大的一项工作。
如果能够重用原有的测试用例及运行结果，将能大大降低再工程成本。
对于重用的部分，特别是可重用的（独立性较强的）局部系统，还可以免除测试，这也正是重用技术被再工程高度评价的关键原因之一。
当然再工程后的系统总有变动和增加的部分，对受其影响的整个范围都要毫无遗漏地进行测试，不可心存侥幸，以免因“一个苍蝇坏了百年老汤”。
软件再工程的两部分：首先，逆向过程：从代码开始推导出设计或是规格说明（可理解性）；其次，改善软件的静态质量（可维护性、复用性或演化性）。
为什么实施软件再工程？（1）再工程可帮助软件机构降低软件演化的风险。
（2）再工程可帮助机构补偿软件投资。
（3）再工程可使得软件易于进一步变革。
（4）软件再工程有着广阔的市场。
（5）再工程能力扩大CASE工具集。
（6）再工程是推动自动软件维护发展的动力。
10.3.2实用的重用战略在判断既存系统应该如何重用时，首先要明确哪些是可重用对象，以及如何使用这些可重用对象。
下面以既存LAN系统重构成Web系统的再工程为例，说明再分析和再编码将遇到的一些重用课题。
我们可以将既存LAN系统划分成界面、逻辑、数据三个层次。
用既存系统的三个层次去分别对应典型Web系统的表示层、逻辑层和数据层。
由此从逻辑上得到对应每个层次的输入和输出，然后为每一层寻找能够实现最大程度重用的重构方法。
（1）界面重用策略界面模拟方法：将基于文本的旧界面包装为新的图形界面。
旧界面运行在终端上，新界面可以是基于PC的图形界面，也可以是运行在浏览器上的HTML页面。
新用户界面通过一个界面模拟工具与旧界面通信。
此方法重用率相当高。
但是不修改既存系统会同时将旧系统的结构性缺点全部继承下来。
基于客户端的Web应用（Java Applet）：Applet可以实现从界面、逻辑到数据库的许多功能。
完全用Java语言重写一个系统是不现实的，重用率也不会很高，这不是软件再工程所提倡的。
但目前已有许多Applet自动转化工具，而且其转化后代码的重用率相当高。
基于服务器端的Web应用：重新开发界面。
这种方法看上去没有重用既存界面代码，其实不然。
首先，界面设计完全可以重用，从而节省设计时间；其次，我们可以将某些界面做成可重用的，这样也会减少工作量。
（2）逻辑层包装原则通过对逻辑层的分解可得到可重用和不可重用的两部分代码。
对可重用部分可直接使用，对于不可重用部分则应尽量通过各种包装技术按统一标准将其改造成可重用构件。
包装方法有很多，如对象包装法、部件包装法等。
（3）数据层重用策略数据层通常要求更高的重用率。
逻辑和数据休戚相关，如果改动数据库，逻辑势必不能正常运行，对逻辑部分的重用也就无从谈起。
如果非改不可的话，也要以保证最大限度的重用为原则，争取做到只增不删，以保证数据的完整性。
再工程工具。
再工程工具用来支持重构一个功能和性能更为完善的软件系统。
目前的再工程工具主要集中在代码重构、程序结构重构和数据结构重构等方面。
10.3.3 软件再工程过程典型的软件再工程过程模型如图所示，该模型定义了6类活动。
在某些情况下这些活动以线性顺序发生，但也并非总是这样，例如，为了理解某个程序的内部工作原理，可能在文档重构开始之前必须先进行逆向工程。
在图中显示的再工程范型是一个循环模型。
这意味着作为该范型的组成部分的每个活动都可能被重复，而且对于任意一个特定的循环来说，过程可以在完成任意一个活动之后终止。
下面简要地介绍该模型所定义的6类活动。
图软件再工程过程模型1. 库存目录分析每个软件组织都应该保存其拥有的所有应用系统的库存目录。
该目录包含关于每个应用系统的基本信息（例如，应用系统的名字，最初构建它的日期，已做过的实质性修改次数，过去18个月报告的错误，用户数量，安装它的机器数量，它的复杂程度，文档质量，整体可维护性等级，预期寿命，在未来36个月内的预期修改次数，业务重要程度等）。
每一个大的软件开发机构都拥有上百万行老代码，它们都可能是逆向工程或再工程的对象。
但是，某些程序并不频繁使用而且不需要改变，此外，逆向工程和再工程工具尚不成熟，目前仅能对有限种类的应用系统执行逆向工程或再工程，代价又十分高昂，因此，对库中每个程序都做逆向工程或再工程是不现实的。
下述3类程序有可能成为预防性维护的对象：（1）预定将使用多年的程序；（2）当前正在成功地使用着的程序；（3）在最近的将来可能要做重大修改或增强的程序。
应该仔细分析库存目录，按照业务重要程度、寿命、当前可维护性、预期的修改次数等标准，把库中的应用系统排序，从中选出再工程的候选者，然后明智地分配再工程所需要的资源。
2. 文档重构老程序固有的特点是缺乏文档。
具体情况不同，处理这个问题的方法也不同：（1）建立文档非常耗费时间，不可能为数百个程序都重新建立文档。
如果一个程序是相对稳定的，正在走向其有用生命的终点，而且可能不会再经历什么变化，那么，让它保持现状是一个明智的选择。
（2）为了便于今后的维护，必须更新文档，但是由于资源有限，应采用“使用时建文档”的方法，也就是说，不是一下子把某应用系统的文档全部都重建起来，而是只针对系统中当前正在修改的那些部分建立完整文档。
随着时间流逝，将得到一组有用的和相关的文档。
（3）如果某应用系统是完成业务工作的关键，而且必须重构全部文档，则仍然应该设法把文档工作减少到必需的最小量。
3. 逆向工程软件的逆向工程是分析程序以便在比源代码更高的抽象层次上创建出程序的某种表示的过程，也就是说，逆向工程是一个恢复设计结果的过程，逆向工程工具从现存的程序代码中抽取有关数据、体系结构和处理过程的设计信息。
4. 代码重构代码重构是最常见的再工程活动。
某些老程序具有比较完整、合理的体系结构，但是，个体模块的编码方式却是难于理解、测试和维护的。
在这种情况下，可以重构可疑模块的代码。
为完成代码重构活动，首先用重构工具分析源代码，标注出和结构化程序设计概念相违背的部分。
然后重构有问题的代码（此工作可自动进行）。
最后，复审和测试生成的重构代码（以保证没有引入异常）并更新代码文档。
通常，重构并不修改整体的程序体系结构，它仅关注个体模块的设计细节以及在模块中定义的局部数据结构。
如果重构扩展到模块边界之外并涉及软件体系结构，则重构变成了正向工程。
5. 数据重构对数据体系结构差的程序很难进行适应性修改和增强，事实上，对许多应用系统来说，数据体系结构比源代码本身对程序的长期生存力有更大影响。
与代码重构不同，数据重构发生在相当低的抽象层次上，它是一种全范围的再工程活动。
在大多数情况下，数据重构始于逆向工程活动，分解当前使用的数据体系结构，必要时定义数据模型，标识数据对象和属性，并从软件质量的角度复审现存的数据结构。
当数据结构较差时，应该对数据进行再工程。
由于数据体系结构对程序体系结构及程序中的算法有很大影响，对数据的修改必然会导致体系结构或代码层的改变。
6. 正向工程正向工程也称为革新或改造，这项活动不仅从现有程序中恢复设计信息，而且使用该信息去改变或重构现有系统，以提高其整体质量。
正向工程过程应用软件工程的原理、概念、技术和方法来重新开发某个现有的应用系统。
在大多数情况下，被再工程的软件不仅重新实现现有系统的功能，而且加入了新功能和提高了整体性能。
10.4 软件逆向工程软件逆向工程(software reverse engineering):分析软件系统，确定其构成成分及各成分间的关系，提取并生成系统抽象和设计信息的工程。
软件逆向工程包含数据收集、知识组织和信息浏览三项规范活动。
这三者构成软件逆向工程的基本过程。
数据收集本活动中所收集的数据是指作为学习、推理和讨论基础的实际信息。
原始数据是构作和浏览高层抽象的基础，因而数据收集是软件逆向工程的一项基本活动。
知识组织本活动中的知识是指所知内容的总和，包括数据以及从数据中导出的关系和规则。
所收集的数据必须按某种数据模型保存起来，以便实现有效的存储和检索，从而帮助分析人员实现对对象及其关系的分析。