（软考笔记）—— 系统架构设计师 - 系统开发基础知识笔记

系统开发基础知识笔记

软件开发方法

软件开发生命周期

     传统的软件生命期（software life cycle）是指软件产品从形成概念（构思）开始，经过定义、开发、使用和维护，直到最后被废弃（不能再使用）为止的全过程。按照传统的软件生命周期方法学，可以把软件生命期划分为软件定义、软件开发、软件运行与维护三个阶段。

软件定义时期

1. 问题定义： 按照软件系统工程需求来确定问题空间的性质。
2. 可行性研究： 确定问题是否有解，解决办法是否可行。
3. 需求分析：需求分析的任务是确定软件系统的功能需求、性能需求和运行环境的约束，写出软件播求规格说明书、软件系统测试大纲、用户手册概要。

     需求分析该过程是非常重要的，应该由系统分析员、软件开发人员与用户共同完成，反复讨论和协商，并且逐步细化、一致化、完全化等，直至建立一个完整的分析模型。需求分析工作完成后要提交软件需求规格说明（Sofware Requirements Specification，SRS）。

软件开发时期

     软件开发时期就是软件的设计与实现，可分成：

1. 概要（总体）设计： 是在软件需求规格说明的基础上，建立系统的总体结构（含子系统的划分）和模块间的关系，定义功能模块及各功能模块之间的关系。
2. 详细设计： 对概要设计产生的功能模块逐步细化，把模块内部细节转化为可编程的程序过程性描述。详细设计包括算法与数据结构、数据分布、数据组织、模块间接口信息和用户界面等的设计，并写出详细设计报告。
3. 编码： 又称编程，编码的任务是把详细设计转化为能在计算机上运行的程序。
4. 测试： 分成单元测试、集成测试、确认测试和系统测试等。通常把编码和测试称为系统的实现，

软件运行和维护

     软件运行就是把软件产品移交给用户使用。软件投入运行后的主要任务是使软件持久满足用户的要求。
     软件维护是对软件产品进行修改或对软件需求变化做出响应的过程，也就是尽可能地延长软件的寿命。

软件开发模型

     软件生存周期模型又称软件开发模型（software develop model）或软件过程模型（software process mndel），它是从某一个特定角度提出的软件过程的简化描述。软件过程模型的基本概念;软件过程是制作款件产品的一组活动以及结果，这些活动主要由软件人员来完成，软件活动主要如下一些：

1. 软件描述： 必须定义软件的功能以及使用的限制。
2. 软件开发： 软件的设计与实现，软件工程人员制作出满足描述的软件。
3. 软件有效性验证： 软件的有效性必须经过严格的验证，以保证能够满足客户的需求。
4. 软件进化： 软件随着客户的需求变化而不断地改进。

瀑布模型

     瀑布模型（waterfall model）可以说是最早使用的软件生存周期模型之一。由于这个模型描述了软件生命的一些基本过程活动，所以它称为软件生命周期模型。

     瀑布模型的特点是因果关系紧密相连，前一个阶段工作的结果是后一个阶段工作的输入。或者说，每一个阶段都是建筑在前一个阶段正确结果之上，前一个阶段的错漏会隐鼓地带到后一个阶段。

     主要缺点：

1. 软件需求分析的准确性很难确定，甚至是不可能和不现实的。
2. 用户和软件项目负责人要相当长的时间才能得到初始版本，这时如果改变需求，将会带来巨大的损失（例如人力、财力、时间等）。该模型的应用有一定的局限性。

原型模型

     原型模型又称为快速模型。主要有以下两个阶段：

1. 原型开发阶段： 软件开发人员根据用户提出的软件系统的定义，快速璃开发一个原型。该原型应该包含目标系统的关键问题和反映目标系统的大致面貌，展示目标系统的全部或部分功能、性能等。
2. 目标软件开发阶段：在征求用户对原型的意见后对原型进行修改完普，确认软件系统的需求并达到一致的理解，进一步开发实际系统。

     原型模型的开发流程如图所示：

螺旋模型

     螺旋模型（Spiral Model）是在快速原型的基础上扩展而成。也有人把螺旋模型归到快速原型。实际上，它是生命周期模型与原型模率的一个结合，这种模型将软件开发流程分为多个阶段，每一个阶段由4部分组成：

1. 目标设定；
2. 风险分析；
3. 开发和有效性验证；
4. 评审；

     开发过程就是上面4个部分的迭代，每迭代一次，软件系统生成一个新的版本，这个版本实际上是对目标系统的的一个逼近。具体的过程如图：

     该模型支持大型软件开发，适用于面向规格说明、面向过程和面向对象的软件开发方法，也适用于集中开发方法的组合。

基于可重用构建的模型

     近几年来，出现了以组件为基础的软件工程方法，基于构件组装的软件过程模型也随之产生并被广泛使用。

     显然，一个系统将依赖构件的健壮性。但是毫无疑问，构件组装模型使软件可以重用，而重用给软件工程师提供了大量的好处。构件组装模型具有极其广阔的实用性和深远的意义。

基于面向对象的模型

     面向对象技术自从问世后，很快被人们所接受，并得到广泛的应用。面向对象技术确实有很多的优点，其中构件重用是非常重要的技术之一。对象技术强调了类的创肆与封装，一旦一个类创建与封装成功，就可以在不同的应用系统中被重用。在这个模型中，一个系统可以由重用构件组装而成，甚至通过组装可重用的子系统而创建更大的系统，模型结构如图所示：

基于四代技术的模型

     四代语言（4th Generation Language，4GL）是在大型数据库管理系统的基础上发展起来的程序设计语言。程序设计语言可分成机器语言、汇编语言、高级语言和第四代语言，以及为人工智能领域应用而设计的语言——第五代语言。

四代语言的定义

1. 用于快速开发应用软件的高产工具（重点强调了提高软件开发的生产率）；
2. 用于快速事物处理系统的高产工具（突出了主要应用领域）。

四代语言主要特征描述

1. 它是非过程化的语言，目的在于高效、直接地实现各种应用系统。
2. 它与数据库的关系密切，能够对大型数据库进行高效处理。被广泛的应用于数据库管理系统中。

     以4GL， 为核心的软件开发技术称为四代技术。使用四代技术可以给我们带来许多方便，在软件开发的时间、成本和质量等方面都会取得较好的效果，但它毕竟在系统开发全过程中应用有限。

敏捷方法

敏捷方法的特点

1. 敏捷方法是“适应性(adaptive)”而非“预设性(predictive)”的。
2. 敏捷型方法是“面向人的(people-oriented)”而“面向过程的(process-oriented)”。

敏捷方法的核心思想

1. 敏捷方法是适应型，而非可预测型。
2. 敏捷方法是以人为本，而非以过程为本。
3. 迭代增量式开发过程。

敏捷型方法的含义及其特征

1. ）敏捷型方法的思想是"自适应"的，而非如"预设"的重型方法试图预先固定需求并拟定详细开发计划，敏捷型方法适应需求的变化，甚至可以说其初衷就是针对变化的需求的。
2. ）敏捷型方法的思考角度是"面向人"的，而非"面向开发过程"的。重型方法在实践原则中总是把开发者看作是一个泛化的生产要素，而忽视了作为决定性因素的人的特殊性;而堑捷型方法师强调以人为本，并贯穿实践始纹。由上可知敏捷型方法其实是软件开发方法论从无到重型再进一步发展的成果。

敏捷方法的适用范围

     敏捷方法和传统方法相比，敏捷方法比较适合需求变化比较大或者开发前期需求不是很清晰的项目，以它的灵活性来适应需求的变化，有效地控制项目进度和成本。另外，敏捷方法对设计者、开发者和客户之间的有效沟通和及时反馈要求比较高，所以不易在开发团队比较庞大的项目中实施，当然这也不是绝对的。

敏捷方法的主要内容

     4个核心价值观分为：

1. 沟通：强调设计者、开发者和客户三者之间的有效交流是开发成功的关键;
2. 简单：是设计和编码的指导原则，强调只满足当前功能需求，不做假想设计，尽量使代码简化；
3. 反馈：强调设计者、开发者和客户之间及时和详尽的意见反馈是开发成功的保证；
4. 勇气： 是开发适应变化的前提，要求设计者和开发者在必需做出取舍或重构时，勇于抉择，勇于实践；

     依据敏捷方法的 4个核心价值观，提出 12 条过程实践规则，分别为：

1. 简单设计；
2. 测试驱动；
3. 代码重构；
4. 结对编程；
5. 持续集成；
6. 现场客户；
7. 发行版本小型化
8. 系统隐喻；
9. 代码集体所有制；
10. 规范代码；
11. 规划策略；
12. 40小时工作机制；

敏捷开发方法简介

1. XP(Extreme Programming， 极限编程)： 在所有的敏捷型方法中，XP 是最引人瞩目的。
2. Cockburn的水晶系列方法： 是一种最少纪律约束的极限编程方法改良。
3. 开放式源码： 开放式源码项目有一个特别之处，就是程序开发人员在地域上分布很广
4. SCRUM：该方法强调这样一个事实，即明确定义了的可重复的方法过程只限于在明确定义了的可重复的环境中，为明确定义了的可重复的人员所用，去解决明确定义了的可重复的问题。
5. Coad的功用驱动开发方法(Feature Driven Development, FDD)： 致力于短时的迭代阶段和可见可用的功能。
6. ASD方法：ASD(Adaptive Software Development)方法核心是三个非线性的、重叠的开发阶段：猜测、合作和学习。

RUP(Rational Unified Process)

RUP概述

     Ratiomal 表示 RUP 是由 Rational 公司提出的，Unified表示 RUP 是最佳开发经验总结，而 Procsg 表示 RUP 是一个软件开发过程。

RUP的生命周期

1. 业务建模(business modeling)；
2. 需求（requirements）；
3. 分析与设计（analysis & design）；
4. 实现（implementation）；
5. 测试（test）；
6. 部署（deployment）；
7. 配置与变更管理（configuration & change Management）；
8. 项目管理（project management）；
9. 环境（environment）；

     RUP吧软件声明周期划分为多个循环(cycle)， 每个cycle生产产品的一个新的版本，依次分为四个阶段：

1. 初始阶段（inception）：定义最终产品视图和业务模型，并确定系统范围。
2. 细化阶段（elaboration）：设计及确定系统的体系结构，制定工作计划以及资源要求。
3. 构造阶段（construction）：构造产品并继续演进需求、体系结构、计划直至产品提交。
4. 移交阶段（transition）：把产品提交给用户使用。

     每一个阶段都由一个或多个连续的迭代（iteration）组成。迭代并不是重复地做相同的事，而是针对不同用例的细化和实现。每一个迭代都是一个完整的开发过程，它需要项目经理根据当前迭代所处的阶段以及上次迭代的结果，适当地对核心工作流中的行为进行裁剪。在每个阶段结束前有一个里程碑（milestone）评估该阶段的工作。如果未能通过该里程碑的评估，则决策者应该做出决定，是取消该项目还是继续做该阶段的工作。

RUP的核心概念

1. 角色（role）
2. 活动（activity）
3. 制品（artifact）
4. 工作流（workflow）

RUP的特点

     即 RUP 是用例驱动的、以体系结构为中心的、迭代和增量的软件开发过程。

     软件采用迭代和增量的方式有以下好处：

1. 在软件开发的早期就可以对关键的、影响大的风险进行处理。
2. 可以提出一个软件体系结构来指导开发。
3. 可以更好地处理不可避免的需求变更。
4. 可以较早的得到一个可运行的系统，鼓舞开发团队的士气，增强项目成功的信心。
5. 为开发人员提供一个能更有效工作的开发过程。

RUP裁剪

     针对一个软件项目，RUP裁剪可以分为以下几步：

1. 确定本项目的软件开发过程需要哪些工作流。
2. 确定每个工作流要产出哪些制品。
3. 确定4个阶段（初试、细化、构造和移交）之间如何演进。
4. 确定每个阶段内的迭代计划。
5. 规划工作流内部结构。

软件系统工具

     通常可以按软件过程活动将软件工具分为 ：

1. 软件开发工具：软件开发工具有需求分析工具(基于自然语言或图形描述的工具和基于形式化需求定义语言的工具，其他需求分析工具)、设计工具、编码与排错工具、测试工具等。
2. 软件维护工具：软件维护工具辅助软件维护过程中的活动，辅助维护人员对软件代码及其文档进行各种维护活动。
3. 软件管理工具和软件支持工具：软件管理过程和软件支持过程往往要涉及到软件生存阔期中的多个活动，软件管理和软件支持工具用来辅助管理人员和软件支持人员的管理活动和支持活动，以确保软件高质高效地完成。

编码与排错工具

     编码工具和排错工具用以辅助程序员进行编码活动。编码工具辅助程序员用某种程序语言编制源程序，并对源程序进行翻译，最终转换成可执行的代码，因此编码工具通常与编码所使用的程序语言密切相关。

编码工具

     主要有编辑程序、汇编程序、编译程序和生成程序

1. 编辑程序： 辑程序用以较入源程序，并对其进行增加、拟除和临改等操作。
2. 汇编程序： 汇编程序用以将汇编语言书写的程序翻译成等价的机器语言程序。
3. 编译程序： 编译程序用以将高级程序语言书写的程序翻译成等价的低级程序语言程序。
4. 生成程序： 生成程序通常根据与领域有关的甚高级语言或某种专用语言描述的用户需求，自动生成高级程序语言或低级程序语言描述的程序。

排错工具

     已有的排错工具主要有源代码排错程序和排错程序生成程序两类。

1. 源代码排错程序：源代码排错程序用以帮助程序员理解程序的执行状态，可通过对程序执行过程中各种状态的判别进行程序错误的识别、定位及改正。
2. 排错程序生成程序：排错程序生成程序是一种通用的排错工具。对给定的程序语言，它能生成一个相应的源代码排错程序。

软件维护工具

     软件维护工具主要有：

1. 版本控制工具： 在软件开发和维护过程中一个软件会有多个版本，版本控制工具用来存储、更新、恢复和管理一个软件的多个版本。
2. 文档分析工具： 文档分析工具用以对软件开发过程中形成的文档进行分析，给出软件维护活动所需的维护信息。
3. 开发信息库工具： 开发信息库工具用来维护软件项目的开发信息，包括对象、模块等。
4. 逆向工程工具： 在软件生存周期中，将某种形式表示的软件转换成更高抽象形式表示的软件的活动称为逆向工程。
5. 再工程工具： 再工程工具用来支持重构一个功能和性能更为完善的软件系统。目前的再工程工具主要集中在代码重构、程序结构重构和数据结构重构等方面。

软件管理和软件支持工具

     常用的工具有：

1. 项目管理工具： 通常项目管理活动包括项目的计划、调度、通信、成本估算、资源分配及质量控制等。
2. 配置管理工具： 配置管理工具用以辅助完成软件配置项的标识、版本控制、变化控制、审计和状态统计等基本任务，使各配置项的存取、修改和系统生成易于实现，从而简化审计过程，改进状态统计，减少错误，提高系统的质量。
3. 软件评价工具： 软件评价工具用以辅助管理人员进行软件质量保证的有关活动。

软件开发工具的评价和选择的衡量标准

1. 功能
2. 易用性
3. 稳健性
4. 硬件要求和性能
5. 服务和支持

需求管理

     软件需求开发的最终文档经过评审批准后，则定义了开发工作的需求基线（baseline）。这个基线在客户和开发者之间构筑了计划产品功能需求和非功能需求的一个约定（agreement）。需求约定是需求开发和需求管理之间的桥梁。需求管理的主要活动如图所示：

     需求管理强调：

1. 控制对需求基线的变动；
2. 保持项目计划与需求一致；
3. 控制单个需求和需求文档的版本情况；
4. 管理需求和联系链，或者管理单个需求和其他项目可交付产品之间的依赖关系；
5. 跟踪基线中的需求状态。

需求管理原则

     过程能力成熟度模型（Capability Maturity Model，CMM）在软件开发机构中被广泛用来指导软件过程改进。该模型描述了软件处理能力的5 个成熟级别。为了达到过程能力成熟度模型的第二级，组织机构必须具有6个关键过程域（Key Process Area，KPA）。

需求规格说明的版本控制

     在软件开发过程中，可能出现测试人员使用已过时的软件规格说明，结果发现了—大堆的错误，为了避免这种情况的发生，需求规格说明的版本暂理就翼得非常重要了。版本控制管理需求的一个必要方面，是必须要统一确定需求文档的每一个版本。

需求属性

     除了文本，每一个功能需求应该有一些相关的信息与它联系，我们把这些信息称为需求属性。对于一个大型的复杂项目来说，丰富的属牲类别显得尤为重要。在文档中，明确考虑和明确如下的属性：

1. 创建需求的时间；
2. 需求的版本号；
3. 创建需求的作者；
4. 发热者认可该需求的人员；
5. 需求状态；
6. 需求的原因和根据；
7. 需求涉及的子系统；
8. 需求涉及的产品版本号；
9. 使用的验证方法或接受的测试标准；
10. 产品的优先级或者重要程度；
11. 需求的稳定性；

需求变更

     软件需求文档应该精确地描述要交付的产品，这是一个基本的原则，为了能够使开发组织能够严格的控制软件项目，应该确保如下事项：

1. 仔细评估已建议的变更；
2. 挑选合适的人选对变更作出决定；
3. 变更应及时通知所有涉及的人员；
4. 项目要按一定的程序来采纳需求变更；

变更控制过程

     需求变更管理过程如图所示：

1. 问题分析和变更描述，产生一个更明确的需求变更提议。
2. 变更分析和成本计算。
3. 变更实现。

     我们可以参考以下的需求变更策略：

1. 所有需求变更必须遵循变更控制过程。
2. 对于为获取批准的变更，不应该做设计和实现工作。
3. 变更应该由项目变更控制委员会决定实现哪些变更。
4. 项目风险承担者应该能够了解变更数据库的内容。
5. 决不能从数据库中删除或者修改变更请求的原始文档。
6. 每一个集成的需求变更必须能跟踪到一个经核准的变更请求。

     在实际中，人们总是希望使用自动工具来执行变更控制过程。问题跟踪工具也可以随时按照变更状态分类报告变更请求的数目，挑选工具可以考虑以下几个方面：

1. 可以定义变更请求的数据项；
2. 可以定义变更请求的生存期的状态转换图；
3. 可以加强状态转换图使经授权的用户能做出所允许的状态改变；
4. 记录每一种状态变更的数据，确认做出变更的人员。
5. 可以定义在提交新请求或请求状态被更新后应该自动通知的设计人员。
6. 可以根据需要生成标准的或定制的报告和图表。

变更控制委员会

     一个有效率的变更控制委员会定期地考虑每个变更请求，并且基于由此带来的影响和获益做出及时地决策。变更控制委员会只要能决定合适的人做正确的事就足够了，不必追求大而全。变更控制委员会可能包括如下方面的代表：

1. 产品或计划管理部门
2. 项目管理部门
3. 开发部门
4. 测试或质量保证部门
5. 市场部或客户代表
6. 制作用户文档的部门
7. 技术支持部门
8. 帮助桌面或用户的热线部门
9. 配置管理部门

需求跟踪

1. 客户需求向前追溯软件需求
2. 从软件需求回溯相应的客户需求
3. 从软件需求向前追溯到下一级工作产品
4. 从产品部件回溯到软件需求

     跟踪能力联系链记录了单个需求之间的父层、互相连接和依赖的关系。当某个需求变更（被删除或修改）后，这种信息能够确保正确的变更传播，并将相应的任务做出正确的调整。一个项目不必拥有所有种类的跟踪能力联系链，要根据具体的情况调整。

需求变更的代价和风险

     "变更是免费的"这种误解是造成项其范围延伸的主要原因之一。影响分析是需求管理的一个重要组成部分。影响分析可以提供对建议的变更的准确理解，帮助做出信息量充分的变更批准决策。

开发管理

项目的范围、时间、成本

范围

     范围定义的输入包括以下的内容：

1. 项目章程
2. 项目范围管理计划
3. 组织过程资产
4. 批准的变更申请

时间

     项目时间管理包括按时完成所必须的管理过程。项目提出后比较明确的一般只是项目的目标，为了使得项目目标得以实现并且制订出比较完善的项目进度计划，则在对项目进行分解的基础上还必须对分解出的目标进行定义，只有这样才能使目标更明确，因此对活动的定义是非常必要的。

成本

     它包括在批准的预算内完成项目所需要的诸过程，主要有如下一些。

1. 成本估算：编制一个为完成项目各项活动所需要的资源成本的近似估算。
2. 成本预算：将总的成本估算分配到各项活动和工作包上，来建立一个成本的基线。
3. 成本控制：控制项目预算的变更。

     项目成本管理这种广义的观点常被称为“全生命周期成本计算”。为保证项目能够完成预定的目标，必须要加强对项目实际发生成本的控制，一旦项目成本失控，就很难在预算内完成项目，不良的成本控制常常会使项目处于超出预算的危险境地。可是在项目的实际实施过程中，项目超预算的现象还是屋见不鲜。

配置管理、文档管理

配置管理

     配置管理在项目管理中具有重要的地位和作用。近年来，信息系统项目的规模越来越大，复杂性越来越高;管理上的失误给我们的教训也越来越深刻。这都使得人们不得不重视配置管理问题。配管理是过按术和行政手段对产品及其开发过程和生命周期进行控制、规范的一系列措施和过程。

文档管理

     总的来说，软件文档应该满足下述要求：

1. 必须描述如何使用这个系统，没有了这种描述即使是最简单的系统也无法使用。
2. 必须描述怎样安装和管理这个系统。
3. 必须描述系统需求和设计。
4. 必须描述系统的实现和测试，以便使系统成为可维护的。

用户文档

     用户文档是用户了解系统的第一步，它可以让用户获得对系统的准确的初步印象。用户文档至少应该包括下述 5方面的内容：

1. 功能描述： 说明系统能做什么。
2. 安装文档： 说明怎样安装这个系统以及怎样使系统适应特定的硬件配置。
3. 使用手册： 简要说明如何着手使用这个系统。
4. 参考手册： 详尽的描述用户可以使用的所有系统设施以及它们的使用方法，并解释系统可能产生的各种出错的信息的含义。
5. 操作员指南：说明操作员应该如何处理使用中出现的各种情况。

系统文档

     所谓系统文档指从向题定义、需求说明到验收测试计划这样一系列和系统实现有关的文档。描述系统设计、实现和测试的文档对于理解程序和维护程序来说是非常重要的。

软件开发的质量与风险

软件质量

     ISO9000 对项目质量的定义是∶一组固有特性满足需求的程度。需求指明示的、通常隐含的或必须履行的需求或期望。特性是指可区分的特征，可以是固有的或赋予的、定性的或定量的、有各种类别（物理的、感官的、行为的、时间的、功能的等）。

     质量与范围、成本和时间是项目成功的关键因素。

软件开发风险

     项目风险是一种不确定的事件或条件，一旦发生，会对项目目标产生某种正面或负面的影响。对项目风险进行管理，国际上已经成为项目管理的重要方面。如世界银行对每一个贷款项目都进行风险分析，制定风险管理计划，写在有关的文件之中，并付诸行动。

设计方法

结构化设计方法

     何谓结构程序设计，目前尚无定论，较流行的定义为;绪构程序设计是程序设计技术，它采用自顶向下逐步求精的设计方法和单入口单出口的控制构件。程序设计结构一般可以定义为：顺序结构、分支结构和循环结构。随着面向对象、软件重用等新的软件开发方法和技术的发展，更现实、更有效的开发途径可能是自顶向下和自底向上两种方法有机的结合。

面向对象的分析设计

     面向对象的分析模型主要由顶层架构图、用例与用例图、领域概念模型构成。面向对象的软件设计流程如下图所示：

软件的重用

     软件元素包括需求分析文档、设计过程、设计文档、程序代码、测试用例和领域知识等。标准函数库是一种典型的、原始的横向重用机制。因为，在两个截然不同的应用领域之间实施软件重用的潜力不大，所以纵向重用才广受瞩目，并成为软件重用技术的真正希望所在。不难理解，纵向重用活动的主要关键点即是域分析，根据应用领域的特征及相似性预测软部件的可重用性。软件重用方法如图所示：

     使用重用技术可以减少软件开发活动中大量的重复性工作，这样就能够提高软件生产率，降低开发成本，缩短开发周期。同时，由于软部件大都经过严格的质量认证，并在实际运行环境中得到检验，因此重用软部件有助于改善软件质置。此外，大量使用软部件，软件的软件逆工程灵活性和标准化程度也可望得到提高。

逆向工程和重构工程

     逆向工程与重构工程是目前预防性维护采用的主要技术。一般认为，凡是在软性生命周期内将软件某种形式的描述转换成更为抽象形式的活动都可称为逆向工程。

恢复信息的级别

     逆向工程导出的信息可以分为如下4个层次：

1. 实现级： 包括程序的抽象语法树、符号表等信息；
2. 结构级： 包括反映程序分量之间的相互依赖关系的信息；
3. 功能级： 包括反映程序段功能以及程序段之间关系的信息；
4. 领域级： 包括反映程序分量或程序诸实体与应用领域概念之间对应关系的信息；

恢复信息的方法

     在逆向工程中用于恢复信息的方法有 4 类：

1. 在用户指导下的搜索与变换(User-Directed Search and Transformation)
2. 变换式方法(Transformational Approaches)
3. 基于领域知识的(Domain Knowledge-Based)
4. 铅板恢复法

     尽管每个软件组织都可能有数百万行代码可供重构，但由于缺乏时机和支持工具或者因为经济上得不偿失，往往只有那些决定或移植、或重新设计、或为重用而需验证正确性的程序才被选择实施逆向工程。