Appearance
软件工程
软件工程概述
软件工程过程是指为获得软件产品，在软件工具的支持下由软件工程师完成的一系列软件工程活动，包括以下4个方面。
- (1)P(Plan)一 。规定软件的功能及其运行时的限制。
- (2)D(Do)— 。开发出满足规格说明的软件。
- (3)C(Check)一 。确认开发的软件能够满足用户的需求。
- (4)A(Action)一 。软件在运行过程中不断改进以满足客户新的需求。
软件要经历这样的全过程，这个全过程称为软件的生命周期。软件生命周期描述了软件从生到死的全过程。
为了使软件生命周期中的各项任务能够有序地按照规程进行，，有时也称之为软件生命周期模型。
软件开发生命周期
- 软件定义时期：包括可行性研究和详细需求分析过程，任务是确定软件开发工程必须完成的总目标，具体可分成问题定义、可行性研究、需求分析等。
- 软件开发时期：就是软件的设计与实现，可分成概要设计、详细设计、编码、测试等。
- 软件运行和维护：就是把软件产品移交给用户使用。
软件系统的文档可以分为用户文档和系统文档两类，用户文档主要描述系统功能和使用方法，并不关心这些功能是怎样实现的：系统文档描述系统设计、实现和测试等各方面的内容。
软件工程过程是指为获得软件产品，在软件工具的支持下由软件工程师完成的一系列软件工程活动，包括以下4个方面。
- (1)P(Plan)一一软件规格说明。规定软件的功能及其运行时的限制。
- (2)D(Do)一一软件开发。开发出满足规格说明的软件。
- (3)C(Check)一一软件确认。确认开发的软件能够满足用户的需求。
- (4)A(Action)一一软件演进。软件在运行过程中不断改进以满足客户新的需求。
软件系统工具通常可以按软件过程活动将软件工具分为软件开发工具、软件维护工具、软件管理和软件支持工具。
- 软件开发工具：需求分析工具、设计工具、编码与排错工具、测试工具等。
- 软件维护工具：版本控制工具、文档分析工具、开发信息库工具、逆向工程工具、再工程工具。
- 软件管理和软件支持工具：项目管理工具、配置管理工具、软件评价工具、软件开发工具的评价和选择。
软件设计包括四个既独立又相互联系的活动，即数据设计、架构（体系结构）设计、人机界面（接口)设计和过程设计，这四个活动完成以后就得到了全面的软件设计模型。
软件工程核心概念
🎯 一句话结论：软件工程的核心思想是将工程化方法应用于软件开发、运行和维护全过程。
软件过程基本活动（4项）： 软件描述 → 软件开发 → 软件有效性验证 → 软件进化 软件生存周期模型： 为各项任务提供规程约束的工作模型，不等于软件开发模型本身。
软件开发生命周期（SDLC）
| 时期 | 内容 | 具体步骤 |
|---|---|---|
| 软件定义时期 | 确定总目标 | 问题定义、可行性研究、需求分析 |
| 软件开发时期 | 设计与实现 | 概要设计、详细设计、编码、测试 |
| 软件运行和维护 | 交付使用并持续维护 | 维护、更新 |
软件设计四大活动： 数据设计 → 架构设计 → 人机界面设计 → 过程设计。
软件工程过程（PDCA）
| 阶段 | 内容 |
|---|---|
| P（Plan）— 软件规格说明 | 规定软件功能及运行时限制 |
| D（Do）— 软件开发 | 开发满足规格说明的软件 |
| C（Check）— 软件确认 | 确认软件满足用户需求 |
| A（Action）— 软件演进 | 运行中不断改进满足新需求 |
软件系统工具分类
| 类别 | 包含工具 |
|---|---|
| 软件开发工具 | 需求分析工具、设计工具、编码与排错工具、测试工具 |
| 软件维护工具 | 版本控制工具、文档分析工具、开发信息库工具、逆向工程工具、再工程工具 |
| 软件管理和软件支持工具 | 项目管理工具、配置管理工具、软件评价工具 |
软件过程模型 ★
核心模型对比
| 特性 | 瀑布模型 | 螺旋模型 | 原型化模型 | 增量模型 | 喷泉模型 | CBSD | 形式化方法 |
|---|---|---|---|---|---|---|---|
| 核心思想 | 线性顺序分阶段 | 迭代原型+风险分析 | 快速原型交互理解需求 | 逐步开发核心和非核心 | 迭代无间隙，面向对象 | 预包装构件构造系统 | 严格数学基础 |
| 适用 | 需求明确，结构化高 | 庞大复杂高风险 | 需求不明确需快速迭代 | 可逐步交付的复杂系统 | 面向对象开发 | 高复用性需求 | 高可靠性系统 |
| 用户参与 | 低 | 高 | 高 | 高 | 高 | 中 | 低 |
| 风险控制 | 中 | 高 | 中 | 中 | 中 | 中 | 高 |
| 复用性 | 低 | 中 | 中 | 中 | 中 | 高 | 低 |
各模型详解（软件过程模型）
瀑布模型
瀑布模型(SDLC):结构化方法中的模型，是结构化的开发，开发流程如同瀑布一般，一步一步的走下去，直到最后完成项目开发，（需求稳定），
当需求不明确时，最终开发的项目会错误，有很大的缺陷。
结构化开发方法的标准模型，前阶段输出 = 后阶段输入，每个阶段结束有里程碑。
阶段：可行性分析 → 需求分析 → 软件设计 → 编码（含单元测试）→ 测试 → 运行维护。
- 优点：概念清晰、易于理解、进度好控制
- 缺点：需求难一次确定、变更代价高、各阶段不能并行
- 阶段数量：6 个（可行性分析 → 需求分析 → 软件设计 → 编码 → 测试 → 运行维护）
- 关键记忆：功能清晰、需求明确 → 选瀑布模型
⚠️ 常见坑：「瀑布模型可以有效避免风险」— 错！瀑布模型的缺点恰恰是需求变更代价高、不能有效避免风险（风险控制的正确答案是螺旋模型）。
⚠️ 常见坑：「每个阶段都能完全解决所有问题，不会出现遗漏或错误」— 错！前阶段的错误和疏漏会隐蔽地带到后阶段。
瀑布模型 (Vaterfall Model)是最早使用的软件过程模型之一，包含一系列活动。
这些活动从一个阶段到另一个阶段逐次下降，它的工作流程在形式上很像瀑布，因此被称为瀑布模型，如图所示：
瀑布模型的特点是因果关系紧密相连，。每一个阶段都是建筑在前一个阶段正确实施的结果之上。(一组检查条件)，对该阶段的工作进行审查和确认。
瀑布模型的主要缺点：
- (1)，甚至是不可能和不现实的。
- (2)瀑布模型是一个，使得用户和软件项目负责人要才能得到一个可以看得见的软件系统。
- (3)瀑布模型的基本原则是在。
原型模型
原型模式，又称为：快速原型。
原型：与瀑布模型相反，原型针对的就是需求不明确的情况，首先快速构造一个功能模型，演示给用户看，并按用户要求及时修改，中间再通过不断的演示与用户沟通，最终设计出项目，就不会出现与用户要求不符合的情况，采用的是迭代的思想。
不适合超大项目开发。
解决瀑布模型需求难以一次确定的缺点。
两个阶段：原型开发 → 目标软件开发。
| 类型 | 说明 |
|---|---|
| 抛弃型原型 | 原型仅用于需求确认，确认后抛弃，继续用瀑布模型 |
| 演化型原型 | 不断补充完善原型，直至形成完整产品 |
- 特点：对用户需求动态响应、逐步纳入，构造方便快速造价低
- 原型化模型主要目的：通过迭代获取用户满意的系统
- 原型分类（按最终结果）：抛弃型原型和演化型原型
- 抛弃型原型的主要作用：需求确认后被抛弃，确认后继续用瀑布模型
螺旋模型
螺旋模型：是多种模型的混合，针对需求不明确的项目，与原型类似，但是增加了风险分析，这也是其最大的特点。。四阶段迭代：。
演化软件过程模型，风险驱动，适用于庞大复杂高风险系统。
四个象限：制定计划 → 风险分析 → 实施工程 → 客户评估。
- 两个显著特点：① 采用循环方式逐步加深系统定义和实现深度，降低风险；② 确定一系列里程碑，确保利益相关者都支持
- 本质：瀑布模型 + 快速原型模型的结合体，强调风险分析
- 包含维护周期，维护和开发之间没有本质区别
- 适用于：面向规格说明、面向过程、面向对象的软件开发方法均可
⚠️ 常见坑：「螺旋模型仅适用于面向对象开发」— 错！螺旋模型适用于多种开发方法和组合。
增量模型
增量模型：，而后与用户确认，之后再开发次核心模块的功能，即每次开发一部分功能，并与用户需求确认，最终完成项目开发，优先级最高的服务最先交付。由于并不是从系统整体角度规划各个模块，因此不利于模块划分。难点在于如何将客户需求划分为多个增量。与原型不用的是增量模型的每一次增量版本都可作为独立可操作的作品，而。
首先开发核心模块，优先级最高的服务最先交付。
- 优点：逐步确认降低风险
- 缺点：不利于模块划分（非整体规划）
- 与原型区别：增量模型每次版本都是独立可操作的作品，原型构造一般是为了演示
🎯 迭代 vs 增量辨析 ★: 迭代 = 重复开发过程（精化已有功能），增量 = 逐步添加功能。两者概念不同但常结合使用（如 RUP 增量迭代）。一个增量可以包含多次迭代。
喷泉模型
喷泉模型：特点是面向对象的模型，而上述其他的模型都是结构化的模型，使用了迭代思想和无间隙开发。
喷泉模型：是一种的模型，适合于的开发方法。使开发过程具有迭代性和无间隙性。
基于构件的开发模型 CBSD
基于构件的开发模型CBSD: 。构件可以是组织内部开发的构件，也可以是商品化成品软件构件。
基于构件的开发模型CBSD:特点是增强了复用性，在系统开发过程中，会构建一个构件库，供其他系统复用，因此可以提高可靠性，节省时间和成本。
形式化方法模型
形式化方法模型：建立在严格数学基础上的一种软件开发方法，主要活动是生成计算机软件形式化的数学规格说明。
敏捷模型
开发宣言：个体和交互胜过过程和工具、可以工作的软件胜过面面俱到的文档、客户合作胜过合同谈判、响应变化胜过遵循计划。
开发宣言：个体和交互 > 过程和工具；可工作的软件 > 面面俱到的文档；客户合作 > 合同谈判；响应变化 > 遵循计划。
两个核心特点："适应性" 而非预设性；"面向人" 而非面向过程。
| 方法 | 核心理念 | 关键实践 |
|---|---|---|
| 极限编程（XP） | 交流、朴素、反馈、勇气 | 测试先行，近螺旋式开发，小周期迭代 |
| 水晶系列 | 以人为中心 | 机动性方法，共性核心元素 |
| 并列争球法（Scrum） | 迭代增量化过程 | **冲刺（Sprint）**约 30 天/次，固定周期 + 三个核心角色（Scrum主管/产品负责人/开发团队）+ 每日站会；产品 Backlog 管理产品需求列表，Sprint Backlog 管理冲刺任务 |
| 特性驱动（FDD） | 人+过程+技术 | 5 核心过程：整体对象模型→特征列表→计划→设计→构建；开发人员分为首席程序员和"类"程序员 |
| 动态系统开发（DSDM） | 以业务为核心 | 强调业务需求驱动，固定时间和资源下最大化功能交付 |
| 开源开发方法 | 地域分布广的团队 | 适用于程序开发人员地域分布很广的开发团队，"眼睛越多错误越少" |
主要敏捷方法：
- (1)极限编程（XP)。基础和价值观是，即任何一个软件项目都可以从4个方面入手进行改善：
- XP是一种的开发方法，它：通过积极的交流、反馈以及其他一系列的方法，开发人员和客户可以非常清楚开发进度、变化、待解决的问题和潜在的困难等，并根据实际情况及时地调整开发过程。
- XP提倡，为了将以后出现bug的几率降到最低。
- (2)水晶系列方法。都有的理念，但在实践上有所不同。其目的是发展一种提倡“机动性的”方法，包含具有共性的核心元素，。
- (3)并列争球法（Scrum)。该方法侧重于。Scrum是，通常用于。Scum包括了一系列实践和预定义角色的过程骨架（是一种流程、计划、模式，用于有效率地开发软件)。
- 在Scrum中，使用，产品Backlog是一个。根据Backlog的内容，将。在Sprint中，Scrum团队从产品Backlog中挑选最高优先级的需求组成Sprint backlog。在每个迭代结束时，Scrum团队将递交潜在可交付的产品增量。当所有Sprint结束时，团队提交最终的软件产品。
- (4)特性驱动开发方法(FDD)。是一个的开发模型。认为有效的软件开发需要3个要素：。有5个核心过程：。
敏捷方法的核心思想：
- (1)敏捷方法是适应型，而非可预测型。拥抱变化，适应变化。
- (2)敏捷方法是以人为本，而非以过程为本。发挥人的特性。
- (3)迭代增量式的开发过程。以原型开发思想为基础，采用法代增量式开发，发行版本小型化。
统一过程模型（RUP）☆
RUP描述了如何有效地利用商业的、可靠的方法开发和部署软件，是一种重量级过程。RUP类似一个在线的指导者，它可以为所有方面和层次的程序开发提供指导方针、模版以及事例支持。
重量级过程模型，。
4 个阶段： 初始 → 细化 → 构造 → 移交。
9 个核心工作流： 业务建模、需求、分析与设计、实现、测试、部署、配置与变更管理、项目管理、环境。
4+1 视图模型： 用例视图（场景）→ 逻辑视图（功能/类图）→ 实现视图（模块组织/包图组件图）→ 进程视图（并发性能/活动图）→ 部署视图（拓扑结构/部署图）。
9 个核心工作流
RUP软件开发生命周期是一个二维的软件开发模型，RUP中有9个核心工作流，如下：
- 业务建模：理解待开发系统所在的机构及其商业运作，确保所有参与人员对待开发系统所在的机构有共同的认识，评估待开发系统对所在机构的影响。
- 需求：定义系统功能及用户界面，使客户知道系统的功能，使开发人员理解系统的需求，为项目预算及计划提供基础。
- 分析与设计：把需求分析的结果转化为分析与设计模型。
- 实现：把设计模型转换为实现结果，对开发的代码做单元测试，将不同实现人员开发的模块集成为可执行系统。
- 测试：检查各子系统之间的交互、集成，验证所有需求是否均被正确实现，对发现的软件质量上的缺陷进行归档，对软件质量提出改进建议。
- 部署：打包、分发、安装软件，升级旧系统；培训用户及销售人员，并提供技术支持。
- 配置与变更管理：跟踪并维护系统开发过程中产生的所有制品的完整性和一致性。
- 项目管理：为软件开发项目提供计划、人员分配、执行、监控等方面的指导，为风险管理提供框架。
- 环境：为软件开发机构提供软件开发环境，即提供过程管理和工具的支持。
RUP把软件开发生命周期划分为多个循环，每个循环生成产品的一个新的版本，每个循环依次由4个连续的阶段组成，每个阶段完成确定的任务。这4个阶段如下。
- 初始阶段：定义最终产品视图和业务模型，并确定系统范围。
- 细化阶段：设计及确定系统的体系结构，制订工作计划及资源要求。
- 构造阶段：构造产品并继续演进需求、体系结构、计划直至产品提交。
- 移交阶段：把产品提交给用户使用。
RUP中定义了如下一些核心概念，理解这些概念对于理解RUP很有帮助。
- 角色：Who的问题。角色描述某个人或一个小组的行为与职责。RUP预先定义了很多角色，如体系结构师、设计人员、实现人员、测试员和配置管理人员等，并对每一个角色的工作和职责都做了详尽的说明。
- 活动：How的问题。活动是一个有明确目的的独立工作单元。
- 制品：What的问题。制品是活动生成、创建或修改的一段信息。
- 工作流：When的问题。工作流描述了一个有意义的连续的活动序列，每个工作流产生一些有价值的产品，并显示了角色之间的关系。
核心概念
RUP 的特点
- 用例驱动
- 以体系结构为中心
- 迭代与增量
RUP的特点：
- (1)：需求分析、设计、实现和测试等活动都是用例驱动的。
- (2)：包括系统的总体组织和全局控制、通信协议、同步、数据存取、给设计元素分配功能、设计元素的组织、物理分布、系统的伸缩性和性能等。是一个多维的结构，会采用多个视图来描述。
在典型的4+1视图模型中：
- 关心的是系统的行为，会侧重于用例视图；
- 关心的是系统的功能，会侧重于逻辑视图；
- 关心的是系统的配置、装配等问题，会侧重于实现视图；
- 关心的是系统的性能、可伸缩性、吞吐率等问题，会侧重于进程视图：
- 关心的是系统的发布、安装、拓扑结构等问题，会侧重于部署视图。
(3)。把整个项目开发分为。在每次选代中，只考虑系统的一部分需求，进行分析、设计、实现、测试和部署等过程；每次迭代是在己完成部分的基础上进行的，每次增加一些新的功能实现，以此进行下去，直至最后项目的完成。
4+1 视图模型
| 视图 | 关注点 | UML 对应 |
|---|---|---|
| 逻辑视图 | 系统功能需求，最终用户 | 类图、对象图、状态图 |
| 开发视图（实现视图） | 软件模块组织管理，程序员 | 包图、组件图 |
| 进程视图 | 运行特性、并发/分布/容错，系统集成人员 | 活动图 |
| 物理视图（部署视图） | 软件→硬件映射、拓扑结构，系统工程师 | 部署图 |
| 场景（用例视图） | 使4个视图有机联系 | 用例图 |
V模型
🎯 一句话结论：V模型最突出的特点是测试贯穿始终，左半部分验证右半部分的对应阶段。
V模型从整体上看起来，就是一个V字型的结构，由左右两边组成。左边的下画线分别代表了需求分析、概要设计、详细设计、编码。
右边的上画线代表了单元测试、集成测试、系统测试与验收测试。
V模型的特点如下：
- (1)的主要目的是针对可能存在的各种错误
- (2)的主要目的是针对中可能存在的问题
- (3)主要针对，检查系统作为一个整体是否有效地得到运行；
- (4)通常由业务专家或者用户进行，以确认产品能真正符合用户业务上的需要。
- (5)V模型用于的情形。
特别注意：。
W模型
W模型强调。
RAD 快速应用开发
概念：RAD是，适用比传统生命周期快得多的开发方法，它强调极短的开发周期，通常适用基于构件的开发方法获得快速开发。
过程：业务建模→数据建模→过程建模→应用生成→测试与交付
适用性：RAD对，如果某项功能不能被模块化，则其构件就会出问题；如果高性能是一个指标，且必须通过调整结构使其适应系统构件才能获得，则RAD也有可能不能奏效；
- RAD要求开发者和客户必须在很短的时间完成一系列的需求分析，任何一方配合不当都会导致失败；
- RAD只能用于管理信息系统的开发，不适合技术风险很高的情况。
🎯 一句话结论：RAD 是基于构件的增量型开发方法，强调极短的开发周期，模块化程度要求高。
RAD 流程（5步，按顺序）：
- 业务建模 — 信息流建模（最先）
- 数据建模 — 将信息流精化为数据对象
- 过程建模 — 数据对象的增删改查处理
- 应用生成 — 自动化工具 + 构件组装
- 测试与交付 — 测试新构件和接口
RAD 适用条件： 系统模块化程度高 | 不适用：新技术多、系统互操作性强、用户参与不足
能力成熟度模型
能力成熟度模型 CMM
对软件组织化阶段的描述，，软件组织的能力经过这些阶段逐步提高。针对软件研制和测试阶段。分为如下五个级别：
| 级别 | 特点 | 关键过程区域数 |
|---|---|---|
| 1. 初始级 | 过程无明确定义，成败依赖个人 | 无 |
| 2. 可重复级 | 建立基本项目管理过程，能跟踪费用/进度/功能 | 6 个（配置管理、质量保证、子合同管理、项目跟踪监督、项目策划、需求管理） |
| 3. 已定义级 | 过程文档化/标准化，整合为组织标准软件过程 | 7 个（同行评审、组间协调、产品工程、集成管理、培训大纲、过程定义、过程焦点） |
| 4. 已管理级 | 制定详细度量标准，定量理解和控制 | 2 个（质量管理、定量过程管理） |
| 5. 优化级 | 定量分析+过程持续改进 | 3 个（过程更改管理、技术改革管理、缺陷预防） |
CMMI（能力成熟度模型集成）
CMMI 是 CMM 的升级版，支持多工程学科和领域。
主要用于。CMM提供了一个软件能力成熟度的框架，它将软件过程改进的步骤组织成，共包括18个关键过程域，52个过程目标，3168种关键时间，它为软件过程不断改进奠定了一个循序渐进的基础。
两种表示方法：
| 模型 | 关注点 | 特点 |
|---|---|---|
| 阶段式模型 | 组织整体成熟度 | 5 级：初始级→已管理级→已定义级→定量管理级→优化级 |
| 连续式模型 | 每个过程域的能力 | 不同过程域可达不同能力等级 |
阶段式模型
阶段式模型：类似于CMM,它关注组织的成熟度，五个成熟度模型如下：
CMMI 阶段式 5 级：
| 级别 | 特点 |
|---|---|
| 1.初始级 | 过程不可预测且缺乏控制 |
| 2.已管理级 | 过程为项目服务（需求管理、项目计划、配置管理、度量和分析等） |
| 3.已定义级 | 过程为组织服务（需求开发、技术解决方案、验证、确认、风险管理等） |
| 4.量化管理级 | 过程已度量和控制（组织过程性能、定量项目管理） |
| 5.优化级 | 集中过程改进和优化（组织级改革与实施、因果分析和解决方案）；使用从多个项目收集的数据关注组织级绩效 |
CMMI 级别易混辨析 ★：
| 级别 | 关键识别词 |
|---|---|
| 2.已管理级 | 过程为项目服务，能策划/执行/监督/控制项目级过程，过程已文档化 |
| 3.已定义级 | 过程为组织服务，标准化过程，量身定制 |
| 4.量化管理级 | 定量理解和控制，过程性能可预测 — 与已定义级的核心区别 |
| 5.优化级 | 持续改进，关注组织级绩效数据 |
⚠️ 易错辨析：量化管理级 vs 已定义级的关键区别是过程性能的可预测性（不是标准化程度也不是项目管理严格程度）。
CMMI 体系文件四层（自顶向下）★：
🎯 一句话结论：方针 → 过程 → 规程 → 模板（①→③→④→②）。
| 层次 | 内容 | 说明 |
|---|---|---|
| 1 | 顶层方针 | 组织质量方针和目标 |
| 2 | 过程文件 | 描述做什么、由谁做 |
| 3 | 规程文件 | 描述如何做 |
| 4 | 模板类文件 | 具体执行时的表单、检查单 |
CMMI 四个知识体系： 系统工程 + 软件工程 + 集成产品与过程开发 + 供应商采购
连续式模型
连续式模型：关注每个过程域的能力，一个组织对不同的过程域可以达到不同的过程域能力等级。
逆向工程
软件复用是将已有软件的各种有关知识用于建立新的软件，以缩减软件开发和维护的花费。软件复用是提高软件生产力和质量的一种重要技术。早期的软件复用主要是代码级复用，被复用的知识专指程序，后来扩大到包括领域知识、开发经验、设计决定、体系结构、需求、设计、代码和文档等一切有关方面。
逆向工程：分析已有程序，在比源代码更高抽象层次上建立程序表示的过程。目的是理解程序、恢复设计、软件复用、改进优化。
四个级别（抽象级别从低→高，完备性从高→低）：
| 级别 | 内容 | 备注 |
|---|---|---|
| 实现级 | 抽象语法树、符号表、过程设计表示 | 抽象最低，完备性最高 |
| 结构级 | 调用图、结构图、程序和数据结构 | 反映程序分量间相互依赖关系 |
| 功能级 | 数据和控制流模型 | 反映程序段功能及关系 |
| 领域级 | E-R 模型 | 抽象最高，完备性最低 |
其中，。
相关概念辨析：（与逆向工程相关的一些概念）
| 概念 | 说明 |
|---|---|
| 重构 | 在同一抽象级别上转换系统描述形式，提高可读性和可维护性 |
| 设计恢复 | 借助工具从已有程序中抽象出数据设计、结构设计和过程设计信息 |
| 再工程（Re-engineering） | 逆向工程基础上修改或重构已有系统，产生系统新版本。包含：逆向工程 → 考虑新需求 → 正向工程 |
| 正向工程 | 从现有系统恢复设计信息，改变或重构以改善整体质量 |
关键辨析：逆向工程 = 低级别描述→高级别抽象；再工程 = 逆向 + 修改重构 → 产生新版本。
练习题
软件逆向工程就是分析己有的程序，寻求比源代码更高级的抽象表现形式。在逆向工程导出信息的四个抽象层次中，( )包括反映程序各部分之间相互依赖关系的信息；(2)包括反映程序段功能及程序段之间关系的信息。
问题1
- A.实现级
- B.结构级
- C.功能级
- D.领域级
答案与解析
答案：B
问题2
- A.实现级
- B.结构级
- C.功能级
- D.领域级
答案与解析
答案：C
(41)是在逆向工程所获取信息的基础上修改或重构已有的系统，产生系统的一个新版本。
- A.逆向分析Reverse Analysis)
- B.重组(Restructuring)
- C.设计恢复(Design Recovery)
- D.重构工程(Re-engineering)
答案与解析
答案：D
