软件工程知识点汇总

前言

参考教材：《软件工程——原理、方法与应用》（第3版）

第1章 绪论

1.1 软件和软件危机

1.1.3 软件危机

软件危机指在计算机软件的开发和维护过程中所遇到的一系列严重问题。

软件工程方法的产生源于软件危机，软件的复杂性是产生软件危机的内在原因。

产生软件危机的原因：

• 软件维护费用急剧上升，直接威胁计算机应用的扩大。
• 软件生产技术进步缓慢，是加剧软件危机的重要原因。

Q：什么是软件危机？为什么会产生软件危机？
A：软件危机是指落后的软件生产方式无法满足迅速增长的软件需求，从而导致软件开发与维护过程中出现一系列问题现象。原因主要有：一，软件维护费用急剧上升，直接威胁计算机应用的扩大；二，软件生产技术进步缓慢。

1.2 软件工程学的范畴

1.2.1 软件开发方法学

软件的发展，大体上经历了程序、软件和软件产品 3 个阶段。

1.3 软件工程的发展

1.3.1 3种编程范型

• 过程式编程范型：着眼于程序的过程和基本控制结构，粒度最小。
• 面向对象编程范型：着眼于程序中的对象，粒度比较大。
• 基于构件技术的编程范型：着眼于适合整个领域的类对象，粒度更大。

由上可见，编程范型的演变是伴随着编程粒度的扩大而推进的，这也标志着软件开发技术的不断成熟。

Q：什么是软件生产工程化？工程化生产方法与早期的程序设计方法主要差别在哪里？
A：结构化程序设计的出现，使许多产业界认识到必须把软件生产从个人化方式改变为工程化。采用工程的概念、原理、技术和方法开发与维护软件，把经过时间考验而证明正确的管理技术和当前能够得到最好的技术方法结合起来，以经济地开发出高质量的软件并有效地维护它，这就是软件工程，同时这也是工程化生产方法。

第2章 软件生存周期与软件过程

2.1 软件生存周期

Q：什么是软件生存周期？把生存周期划分为阶段的目的是什么？
A：软件生存周期划分为计划、开发和运行三个时期；把整个生存周期划分为较小的阶段，给每个阶段赋予确定而有限的任务，就能够化简每一步工作内容，使因软件规模而增长而大大增加了软件复杂性得交易控制和管理。

软件生存周期的主要活动：

需求分析 → 软件分析 → 软件设计 → 编码（测试）→ 软件测试 → 运行维护

2.2 传统的软件过程

2.2.1 瀑布模型（大题常考）

瀑布开发模型是一种基于软件生存周期的线性开发模型。

瀑布模型的缺点是缺乏灵活性，特别是无法解决软件需求不明确或不准确的问题。

特点

• 阶段间的顺序性和依赖性
• 推迟实现的观点
• 保证质量的观点

阶段

• 用户要求
• 需求分析
• 概要/总体设计
• 详细设计
• 编码
• 测试
• 维护

缺点

由于用户不可能一次性的提出所有的需求，而瀑布模型是属于“线性”的开发模型，因而瀑布模型不能适应用户在开发后期提出的需求变更。

存在的问题

按照瀑布模型来开发软件，只有当分析员能够做出准确的需求分析时，才能够得到预期的结果。不幸的是，由于多数用户不熟悉计算机，系统分析员对用户的专业也往往了解不深，因而很难在开发的初始阶段彻底弄清软件需求。为了解决这一问题，人们提出了“快速原型模型”。

2.2.2 快速原型模型

原型化方法是用户和设计者之间执行的一种交互构成，适用于需求不确定性高的情况。

在快速原型模型的开发过程中，用原型过程来代替全部开发阶段所用模型是演化型原型模型。

原型开发的优越性

• 逼真
• 快速

软件开发人员向用户提供一个“样品”，用户向开发人员迅速作出反馈。

原型模型的启示

下图显示了快速原型软件开发的过程模型。

用户的介入和反馈，使它在原型的分析与设计阶段可能出现多次回溯和迭代，从而形成非线性的开发模型。

2.3 软件演化模型

常见的演化模型有增量模型与螺旋模型两种。它们都是瀑布模型和快速原型模型相结合的产物。

2.3.1 增量模型（incremental model）

2.3.2 螺旋模型（spiral model）

适用于大型软件的开发。

项目按照顺时针方向沿螺旋线移动时，每轮螺旋包含以下四种活动：

1. 计划
2. 风险分析
3. 建立原型
4. 用户评审

按此顺序周而复始，直到实现最终产品。

螺旋模型的特点，是在项目的所有阶段都考虑各类风险，从而能在风险变成问题之前降低它的危害。螺旋模型开发的成败，在很大程度上依赖于风险评估的准确性。

2.3.3 构件集成模型

适用于面向对象的软件开发。

统一建模语言（unified modeling language,UML），把众多面向对象分析和设计工具综合成一种标准，使面向对象的方法成为主流的软件开发方法。

面向对象思想最重要的特征是在解空间中引入了“对象”的概念。

面向对象方法学包含了对象（object）、类（class）、继承（inheritance）、消息（message）等核心概念。

面向对象 = 对象 + 分类（classification）+ 继承 + 消息通信（communication with messages）

2.4 形式化方法模型

软件开发方法可分为：

• 形式化方法——学术界流行
• 非形式化方法——工业界流行

2.4.1 转换模型（transformational model）

转换模型是将形式化软件开发和程序自动生成技术相结合的一种软件开发模型。

2.4.2 净室模型（cleanroom model）

净室模型是一种形式化的增量开发模型。

基本思想：力求在分析和设计阶段就消除错误，确保正确，然后在无缺陷或“洁净”的状态下实现软件的制作。

2.5 统一过程和敏捷过程

Q：RUP是什么？ 试比较RUP和XP的差异。
A：RUP（Rational Unified Process，统一软件开发过程，统一软件过程）是一个面向对象且基于网络的程序开发方法论。
RUP统一软件过程是描述软件开发中各个环节应该做什么，怎么做，什么时候做以及为什么要做，描述了以某种顺序完成的活动。其在一个二维空间中描述软件开发活动，可以分为初始阶段，细化阶段，构造阶段和迁移阶段。
XP 极限过程是一个轻量级的，敏捷的软件开发方法，同时也是一个非常严谨和周密的方法。它有四个价值观：交流，简单，反馈和勇气。

2.5.1 统一过程（Rational Unified Process,RUP）

统一过程描述了软件开发中各个环节做的内容：

• 做什么——产品（artifact）
• 怎么做——活动（activity）
• 什么时候做——工作流（workflow）
• 为什么要做
• 谁来做——人员（role）

统一过程包括四个阶段：

• 初始阶段
• 细化阶段
• 构造阶段
• 迁移阶段

2.5.2 敏捷过程

敏捷开发（agile development）是一种以人为核心、以迭代方式循序渐进开发的方法，其软件开发的过程称为“敏捷过程”。

下图为 4 个简单的价值观以及敏捷开发方法应遵循的 12 条原则：

2.5.3 极限编程（extreme programming,XP）

极限编程是敏捷过程的一种方法。

它有 4 个价值观：

• 交流
• 简单
• 反馈
• 勇气

即，任何一个软件项目都可以从 4 个方面入手进行改善：

• 加强交流
• 从简单做起
• 寻求反馈
• 勇于实事求是

XP方法包括以下 12 个核心实践：

2.6 软件可行性研究

可行性论证其实是在高层次上进行的一次大大简化了的需求分析与设计。

可行性研究进一步研究问题分析阶段所确定的问题是否有可行的解。

2.6.1 可行性研究的内容与步骤

1. 研究的内容

• 经济可行性。实现这个系统有没有经济效益？多长时间可以收回成本？
• 技术可行性。现有的技术能否实现这一新系统？有哪些技术难点？建议采用的技术先进程度怎样？
• 运行可行性。为新系统规定的运行方式是否可行？
• 法律可行性。新系统的开发会不会在社会上或政治上引起侵权、破坏或其他责任问题？

2.6.2 软件风险分析

• 风险识别
• 风险预测
• 风险的驾驭和监控

第3章 结构化分析与设计

第一代（传统软件工程）→ 第二代（OO软件工程）→ 第三代（基于构件的软件工程）

本章重点介绍基于瀑布模型的结构化分析与设计。

3.1 概述

3.1.1 结构化分析与设计的由来

系统的整个开发流程，可以简明地表示为：

• DFD 图：Data Flow Diagram,数据流图
• PSPEC：加工规格说明
• CSPEC：控制规格说明
• SRS：Software Requirements Specification,需求规格说明书
• SC 图：Structure Chart,结构图

结构化分析（structured analysis,SA）

任务：

• 建立系统分析模型（analysis model）
• 编写软件需求规格说明书

步骤：

• 自顶向下对系统进行功能分解，画出分层 DFD 图
• 由后向前定义系统的数据和加工，编写 DD 和 PSPEC
• 最终写出 SRS

数据流图和数据字典共同构成了系统的逻辑模型，是需求规格说明书的主要组成部分。

结构化设计（structured design,SD）

SD 阶段先把分析模型中的 DFD 图转换为最终 SC 图。

软件设计 = 概要/总体设计 + 详细设计/模块设计

传统的软件设计又可细分：

• 面向数据流的设计
• 面向数据（数据结构）的设计

前者以 SD 方法为代表，后者以 Jackson 方法为代表。

3.1.2 SA 模型的组成与描述

1. SA 模型的组成

由图可见，数据字典（DD）处于模型的核心，它是系统涉及的各种数据对象的总和。从DD出发可构建 3 种图：

• 实体联系图（E-R 图）
• 数据流图（DFD）
• 状态变换图（STD）

下图重要

• DD：Data Dictionary,数据字典
• E-R 图：Entity-Relation Diagram,实体联系图
• STD 图：Status Transform Diagram,状态变换图

2. SA 模型的描述工具

(1) 数据流图（DFD）

高度抽象的软件系统功能模型：

数据流图只使用 4 种基本图形符号：

• 圆框代表加工
• 箭头代表数据的流向，数据名称总是标在箭头的边上；
• 方框表示数据的源点和终点
• 双杠（或单杠）表示数据文件或数据库

基于计算机的教材销售系统的 DFD 图：

(2) 数据字典（DD）

• 数据流
  

• 数据文件
  

• 数据项
  

(3) 加工规格说明

• 结构化语言
  

• 判定表或判定树
  某公司为推销人员制定了奖励办法，把奖金与推销金额及预收贷款的数额挂钩。凡每周推销金额不超过 10000 元的，按预收贷款是否超过 50%，分别奖励推销额的 6% 或 4%。若推销金额超过 10000 元，则按预收贷款是否超过 50% ，分别奖励推销额的 8% 或 5%。对于月薪低于 1000 元的推销员，分别另发鼓励奖 300、200 和 500、300 元。试分别采用判定表和判定树为 DFD 图中用来“计算奖金”的加工写出 PSPEC。
  下图分别显示了用判定表和判定树描述的 PSPEC，二者的含义相同。
  
  

3.1.3 SD 模型的组成与描述

1. SD 模型的组成

SD 模型是由 SA 模型映射而来的。

2. SD 模型的描述工具

其描述工具为结构图（structure chart），简称 SC 图。

软件结构图中，模块框之间若有直线连接，表示它们之间存在调用关系。

(1) SC 图的组成符号

(2) SC 图的模块调用

3.3 结构化系统设计

3.3.1 SD概述

• 面向数据流设计和面向数据设计
• 从分析模型导出设计模型
  

3.3.2 SD的步骤：从DFD图到SC图

1. 数据流图的类型

(1) 变换型结构

由传入路径、变换中心和传出路径 3 部分组成。

下图显示了该型结构的基本模型和数据流：

(2) 事务型结构

事务型结构由至少一条接受路径、一个事务中心与若干条动作路径组成。

3.3.5 优化初始SC图的指导规则

1. 对模块划分的原则

一般来说，模块的总行数应该控制在 10-100 行的范围内，最好为 30-60 行，能容纳在一张打印纸内。

2. 高扇入/低扇出的原则

扇入高则上级模块多，能够增加模块的利用率；扇出低则表示下级模块少，可以减少模块调用和控制的复杂度。

设计良好的软件通常具有瓮型（oval-shaped）结构，两头小，中间大，如图所示。这类软件在下部收拢，表明它在低层模块中使用了较多高扇入的共享模块。

软件结构图的形态特征能反映程序重用率的是扇入。

3.4 模块设计

3.4.1 目的与任务

目的：为 SC 图中的每个模块确定采用的算法和块内数据结构，用选定的表达工具给出清晰的描述。

任务：编写软件的模块设计说明书。

3.4.2 模块设计的原则与方法

• 清晰第一的设计风格
• 结构化的控制结构
• 逐步细化的实现方法

3.4.3 常用的表达工具

• 流程图
• N-S 图
• 伪代码（PDL语言）

第4章 面向对象与UML

4.2 UML简介

4.2.1 UML的组成

UML 是一种基于面向对象的可视化建模语言。

1. UML的模型元素

以下是几种主要连接关系的含义：

• 关联（association）：模型元素实例之间的固定对应关系，为永久性的结构关系。
• 泛化（generalization）：表示一般与特殊关系，“一般”元素是“特殊”元素的泛化，“特殊”元素是“一般”元素的特化（specialization）。
• 依赖（dependency）：表示一个元素以某种方式依赖于另一个元素，为短暂性关系。
• 实现（realization）：表示接口和实现它的模型元素之间的关系。
• 聚集（aggregation）：表示“整体”与“部分”关系，“部分”元素是“整体”元素的一部分。
• 组合（composition）：表示强烈的“整体”与“部分”关系，“部分”不能独立于“整体”而存在。

Q：请指出 UML 类图中类之间的除聚合与组合之外的关系有哪些？聚合与组合关系有什么区别和联系？
A：还有的关系有：关联、依赖、继承、实现。聚合与组合的区别是：聚合表示两个对象之间是整体和部分的弱关系，部分的生命周期可以超越整体；组合表示两个对象之间是整体和部分的强关系，部分的生命周期不能超越整体，或者说不能脱离整体而存在。聚合是一种特殊的关联，而组合又是一种特殊的聚合。

2. UML 的元模型结构

下一层是上一层的基础，上一层是下一层的实例。

(1) 元元模型

元元模型定义了用于描述元模型的语言，它是任何模型的基础。

(2) 元模型

元模型定义了用于描述模型的语言。

(3) 模型

模型定义了用于描述信息领域的语言，它组成了 UML 的基本元素。

(4) 用户模型

用户模型是模型的实例，它用于表达一个模型的特定情况。

3. 图和视图

(1) 图（diagram）

• 用例图描述系统功能
• 类图描述系统的静态结构
• 对象图描述系统在某个时刻的静态结构
• 构件图描述实现系统的元素的组织
• 部署图描述系统环境元素的配置，亦可称为配置图
• 状态图描述系统元素的状态条件和响应
• 时序图按时间顺序描述系统元素间的交互
• 协作图按照连接关系描述系统元素间的交互
• 活动图描述系统元素的活动流程

(2) 视图（view）

4.2.2 UML的特点

• 统一标准
• 面向对象
• 表达能力强大、可视化

4.3 静态建模

UML的静态建模机制包括：

• 用例图
• 类图
• 对象图

4.3.1 用例图与用例模型

1. 组成符号

2. 建立用例图

3. 用例之间的关系

(1) 扩展关系（extend）

根据指定的条件，一个用例中有可能加入另一个用例的动作，这两个用例之间的关系就是扩展关系。

(2) 包含关系（include）

当一个用例的行为包含另一个用例的行为时，这两个用例之间就构成了包含关系。如果若干个用例有某些行为是相同的，即可把这些相同的行为抽取出来单独成为一个用例，称为抽象用例。

用例图中包含关系是指一个用例继承了另一个用例。（×）

4.3.2 类图和对象图

类图是最重要的模型图，它描述了系统中各类对象以及它们之间的各种关系。

1. 类图和对象图

不同的属性具有不同的可见性。常见的可见性和在 UML 中的表示：

• Public（+）
• Private（-）
• Protected（#）

类图可描述类与类之间的静态关系：

• 关联
• 聚集
• 泛化
• 依赖以及组合
• 约束与派生

4.3.3 包

在 OO 设计中，可将许多类集合成一个更高层次的单位，形成一个高内聚、低耦合的类的集合。

UML 把这种将一些模型元素组织成语义上相关的组的分组机制称为包。

4.4 动态建模

4.4.1 消息

UML 定义的消息类型有以下 3 种：

• 简单消息（simple message）：表示简单的控制流。
• 同步消息（synchronous message）：表示嵌套的控制流。
• 异步消息（asynchronous message）：表示异步控制流。

4.4.2 状态图

状态图（state diagram）用来描述一个特定对象的所有可能状态以及引起其状态转移的事件。

4.4.3 时序图和协作图

交互图有顺序图和协作图两种形式。

1. 时序/顺序图

时序图（sequence diagram）用来描述对象之间的动态交互，着重体现对象间消息传递的时间顺序。

2. 协作图

协作图（collaboration diagram）用于描述相互协作的对象间的交互和链接。

4.4.4 活动图

活动图（activity diagram）显示动作流程及其结果，它既可用来描述操作（类的方法）的行为，也可以描述用例和对象内部的工作过程。

4.5 物理架构建模

4.5.2 构件图和部署图

• 构件图显示软件构件之间的依赖关系
• 部署图描述系统硬件的物理拓扑结构以及在此结构上执行的软件

4.6 UML工具

• Rational Rose
• StarUML

第5章 需求分析与建模

需求分析阶段最重要的的技术文档之一是需求规格说明书（SRS）。

在需求分析中，分析员要从用户那里解决的最重要的问题是明确软件做什么。

5.1 软件需求工程

5.1.1 软件需求的定义

软件需求主要指一个软件系统必须遵循的条件或具备的能力。

这里的条件或能力可以从两个方面来理解：

• 一是用户解决问题或达到目标所需的条件或能力，即系统的外部行为。
• 二是系统为了满足合同、规范或其他规定文档所需具有的条件或能力，即系统的内部特性。

软件需求一般包括 3 个不同的层次：

• 业务需求
• 用户需求
• 功能需求

5.1.2 软件需求的特性

• 功能性
• 可用性
• 可靠性
• 性能
• 可支持性
• 设计约束

5.2 需求分析与建模

需求分析的目的主要是为待开发的软件系统进行需求定义与分析，并建立一个需求模型（requirement model）。

5.2.1 需求分析的步骤

软件的需求分析一般包括如下的 4 个步骤：

• 需求获取
• 需求建模
• 需求描述（即编写 SRS）
• 需求验证/需求审评

5.3 需求获取的常用方法

5.3.1 常规的需求获取方法

• 建立联合分析小组
• 用户访谈
• 问题分析与确认

5.3.2 用快速原型法获取需求

第四代开发技术（4GT）是快速原型法的常用技术。

5.4 需求模型

5.4.1 需求模型概述

1. 结构化需求模型

• 包括数据流图和加工规格说明的功能模型
• 主要由数据字典和 E-R 图等组成的数据模型
• 由状态转换图、控制流图和控制规格说明等组成的行为模型

2. 面向对象需求模型

• 用例模型
  • 用例图
  • 用例规约
• 补充规约
• 术语表

5.4.2 面向对象的需求建模

步骤：

1. 画用例图
2. 写用例规约
3. 描述补充规约
4. 编写术语表

用例规约文档一般包含以下内容：

• 简要说明
• 事件流
  • 基本流
  • 备选流
• 特殊需求
• 前置条件和后置条件

5.5 软件需求描述

SRS包括：

• 引言
• 信息描述
• 功能描述
• 行为描述
• 质量保证
• 接口描述
• 其他描述

5.6 需求管理

5.6.1 需求管理的内容

1. 需求管理的特定实践

2. 需求变更的流程

变更申请 → 审批 → 更改 → 重新确认

对软件影响大的需求变更，应该提交给SCCB（软件变更控制委员会）审批。

Q：需求分析的任务是什么？怎样理解分析阶段的任务是决定“做什么”，而不是“怎么做”？
答：需求分析主要有两个任务：
1）通过对问题及其环境的理解、分析和综合建立分析模型；
2）是在完全弄清用户对软件系统的确切要求的基础上，用“软件需求规格说明书”把用户的需求表达出来。需求分析的任务就是为了明确要开发的是一个什么系统，而不是怎么去实现这个系统。

第6章 面向对象分析

6.1 软件分析概述

6.1.1 面向对象软件分析

UML 是面向对象分析（object-oriented analysis,OOA）的重要表达工具。

1. OOA的主要任务

首先要理解用户的需求，包括全面理解和分析用户需求，明确所开发的软件系统的职责，形成文件并规范地加以表述。然后进行分析，提取类和对象，并结合分析进行建模。

2. OOA的模型

如图所示，处于 OOA 模型核心的是以用例模型为主体的需求模型。当软件开发小组获得软件需求后，分析员即可据此创建一组场景（scenario）。

3. OOA的优点

与传统的软件分析方法相比较，面向对象分析具有如下优点：

• 同时加强了对问题空间和软件系统的理解。
• 改进包括用户在内的与软件分析有关的各类人员之间的交流。
• 对需求的变化具有较强的适应性。
• 很好地支持软件复用。
• 确保从需求模型到设计模型的一致性。

4. 分析模型的一般特点

分析模型由一组子模型组成。

特点：

• 全面覆盖软件的功能需求
• 分析模型与软件的实现无关
• 分析模型的表述方法与所采用的分析技术有关

6.1.2 面向对象分析模型

1. 典型的五层次模型

• 建立类/对象层
• 建立属性层
• 建立服务层
• 建立结构层
• 建立主题层

6.2 面向对象分析建模

6.2.1 识别与确定分析类

1. 分析类的类型

通常，分析类被划分为 3 种类型：

• 边界类
• 控制类：作为完成用例任务的责任承担者，协调、控制其他类共同完成用例规定的功能或行为。
• 实体类

可分别用标记

• 《boundary》
• 《control》
• 《entity》

来表示。

第7章 面向对象设计

在面向对象设计阶段着重完成“如何做”的问题，也就是着重考虑对象的实现细节。

7.1 软件设计概述

在面向对象的设计中，我们应遵循的设计准则除了模块化、抽象、低耦合、高内聚以外，还有信息隐蔽。

7.1.1 软件设计的概念

1. 模块与构件

• 模块：一个拥有明确定义的输入、输出和特征的程序实体。
• 软件构件：可重复使用的软件组件。

3. 信息隐藏

系统分解为模块时应遵循的指导思想。

这一指导思想的目的，是为了提高模块的独立性。

7.1.3 模块化设计

2. 模块独立性

独立性可以从两个方面来度量：

• 模块本身的内聚（cohesion）：模块内部各个成分之间的联系，所以也称为块内联系或模块强度。
• 模块之间的耦合（coupling）：一个模块与其他模块间的联系，所以又称为块间联系。

模块的独立性愈高，则块内联系越强，块间联系越弱。

C.Myers 把内聚和耦合各划分为 7 类，现分别介绍如下。

(1) 内聚

内聚是从功能的角度对模块内部聚合能力的量度。

最强：功能性内聚
最弱：偶然性内聚

(2) 耦合

耦合是对软件内部块间联系的度量。

最强：内容耦合
最弱：非直接耦合

Q：衡量模块独立性的两个定性标准是什么？这两个标准的定义分别是什么？在我们的软件设计中，关于模块独立性我们追求的目标是什么？
A：衡量模块独立性的两个定性标准是内聚和耦合。耦合是指对一个软件结构内不同模块彼此之间互相依赖（连接）的紧密程度；而内聚则标志一个模块内部各个元素彼此结合的紧密程度。在我们的软件设计中，关于模块独立性我们追求的目标是紧密内聚松散耦合（或者高内聚低耦合）。

7.2 面向对象设计建模

7.2.1 面向对象设计模型

OO 设计模型由

• 系统架构层：描述了整个系统的总体结构，使所设计的软件能够满足客户定义的需求，并实现支持客户需求的技术基础设施。
• 类和对象层：包含类层次关系，使得系统能够以通用的方式创建并不断逼近特殊需求，该层同时包含了每个对象的设计表示。
• 消息层：描述对象间的消息模型，它建立了系统的外部和内部接口，包含使得每个对象能够和其协作者通信的细节。
• 责任层：包含针对每个对象的所有属性和操作的数据结构和算法的设计。

4 个层次组成。

7.2.2 面向对象设计的任务

正如传统设计可分为概要设计和详细设计两个阶段，OOD 的软件设计也可划分为两个层次：

• 系统架构设计
• 系统元素设计

设计任务：将分析阶段建立的分析模型转变为软件设计模型。

设计目标：细化解决方案的可视化设计模型，确保设计模型最终能平滑地过渡到程序代码。

软件系统架构是指系统主要组成元素的组织或结构，以及其他全局性决策，组成元素之间通过接口进行交互。

系统元素包括组成系统的类、子系统与接口、包等。系统元素设计是对每一个设计元素进行详细的设计。

7.2.3 模式的应用

每个模式都描述了一个在某个特定环境中不断出现的问题，然后描述该问题解决方案的核心。就其抽象的级别而言，软件模式可以分为：

• 架构模式
• 设计模式
• 习惯用法

7.3 系统架构设计

• 设计系统高层结构
  • 应用子系统层
  • 业务专用层
  • 中间件层
  • 系统软件层
• 确定设计元素
• 确定任务管理策略
• 实现分布式机制
• 设计数据存储

7.4 系统元素设计

• 子系统设计
• 分包设计
• 类/对象设计

第8章 编码与测试

8.4 测试的基本概念

8.4.2 测试的特性

1. 挑剔性

2. 复杂性

3. 不彻底性

E.W.Dijkstra 有一句名言：“程序测试只能证明错误的存在，不能证明错误不存在。”

4. 经济性

8.5 黑盒测试和白盒测试

8.5.1 黑盒测试

黑盒测试就是根据被测试程序功能来进行测试，所以也称为功能测试。

1. 等价分类法（equivalence partitioning）

2. 边界值分析法（boundary value analysis）

边界值分析方法是取输入/输出等价类的边界值来构成测试用例的测试方法。

3. 错误猜测法（error guessing）

8.5.2 白盒测试

白盒测试以程序的结构为依据，所以又称为结构测试。

白盒测试仅与程序的内部结构有关，完全可以不考虑程序的功能要求。

1. 逻辑覆盖测试法

判定覆盖不一定包含条件覆盖，条件覆盖也不一定包含判定覆盖。

Q：简述软件测试的目的、任务与动态测试类型。
A：软件测试是一个为了寻找软件错误而运行程序的过程。目的就是为了发现软件中的错误。软件测试的任务是通过在计算机上执行程序，暴露程序中的潜在的错误。（一个好的测试用例是指很可能找到迄今为止尚未发现的错误的用例。一个成功的测试是指揭示了迄今为止尚未发现的错误的测试。）动态软件测试主要分为白盒测试和黑盒测试两大类。

8.7 多模块程序的测试策略

8.7.1 测试的层次性

按照软件工程的观点，多模块程序的测试共包括 4 个层次。

在进行软件测试时，首先应当进行单元测试，然后再进行组装测试，最后再进行有效性测试。

8.7.2 单元测试

通过对象模块的静态分析与动态测试，使其代码达到模块说明书的需求。

单元测试阶段主要涉及详细设计的文档。

8.7.3 集成测试

将经过单元测试的模块逐步组装成具有良好一致性的完整的程序。

8.7.4 确认测试

确认组装完毕的程序是否满足软件需求规格说明书（SRS）的要求。

针对软件需求分析所进行的软件测试是指确认测试。

8.7.5 系统测试

检查把确认测试合格的软件安装到系统中以后，能否与系统的其余部分协调运行，并且实现 SRS 的要求。

单元测试是发现编码错误，集成测试是发现模块的接口错误，确认测试是为了发现功能错误，那么系统测试是为了发现性能、质量不合要求的错误。

第9章 软件维护

产生软件维护的副作用是指因修改软件造成的错误。

软件生命周期中所花费用最多的阶段是软件维护。

9.5. 软件配置管理

2. 软件配置项

软件过程的输出信息可以分为 3 个主要类别：其一是计算机程序（源代码和可执行程序），其二是描述计算机程序的文档（针对技术开发者和用户），其三是数据（包含在程序内部或外部）。这些项包含了所有在软件过程种产生的信息，总称为软件配置项。

其它

回归测试是指重新执行已经做过的测试的某个子集，以保证由于调试或其他原因引起的变化，不会导致非预期的软件行为或额外错误的测试活动。

针对下面一个程序段

if ((A > 1) && (B == 0)) {
	X = X / A;
}
if ((A == 2) || (X > 1)) {
	X++;
}

选取测试用例：CASE 1：A=2 B=0 X=3，该测试用例满足了语句覆盖。

软件是程序及其文档。

文档是软件产品的一部分，没有文档的软件就不称其为软件。

软件工程的三要素是工具、过程和方法。

系统边界是一个系统所包含的所有系统成分与系统以外各种事物的分界线。

在用例之间，会有三种不同的关系：

• 包含（include）
• 扩展（extend）
• 泛化（generalization）

一台计算机有很多零部件，例如：键盘、鼠标、主板、显示器等等，我们可以用一个聚集图来描述，也就是说计算机是一个聚集体。

数据管理部分的设计是 OOD 模型中的一部分，负责使用关系数据库存储和检索永久对象。（×）

一个软件从开始立项起，到废止不用止，统称为软件的生命周期。

软件生存周期主要活动：

• 需求分析
• 软件分析
• 软件设计
• 编码
• 软件测试
• 运行维护

从心理学角度看，对数据流程图的数据处理泡进行分解，一次分解为7±2个泡为宜。

结构化程序设计采用的三种基本控制结构：

• 顺序
• 选择
• 循环

结构化程序设计主要强调的是程序易读性。

解释下列名词：（1）模块；（2）模块化；（3）模块化设计。
答：模块是一个拥有明确定义的 、输出和特性的程序实体。
模块化是指解决一个复杂问题时自顶向下逐层把软件系统划分成若干模块的过程。每个模块完成一个特定的子功能，所有的模块按某种方法组装起来，成为一个整体，完成整个系统所要求的功能。
模块化设计是把大型软件按照规定的原则划分成一个个较小的、相对独立但又相互关联的模块。但又相互关联的模块。