软件工程复习笔记

第一章 软件工程学概述

1.1软件危机

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

软件危机包含两方面问题：

1. 如何开发软件，以满足对软件开发日益增长的需求
2. 如何维护数量不断膨胀的已有软件

软件危机的表现

1. 对软件开发成本和进度的估计常常很不准确
2. 用户对“已完成的”软件系统不满意的现象经常发生
3. 软件产品的质量往往靠不住
4. 软件常常是不可维护的
5. 软件常常没有适当的文档资料
6. 软件成本在计算机系统总成本中所占的比例逐年上升
7. 软件开发生产率提高的速度，远远跟不上计算机应用迅速普及深入的趋势

一个软件从定义，开发，使用和维护直到最终被抛弃 称为生命周期

软件开发的流程： 问题定义 可行性研究 需求分析 概要设计 详细设计 编码 测试

软件开发的不同阶段进行修改需要付出的代价是不相同的，开发初期涉及的面少，代价也比较低，中期时软件配置的许多成分已经完成，再进行修改不仅工作量大而且逻辑上也更复杂，付出的代价剧增。后期时引入变动的代价会更高，因为这是软件已经是“已经完成”的阶段了。

软件：程序，数据以及相关文档的完整集合

程序：能够完成预定功能和性能的可执行的指令序列

数据：是程序能够适当的处理信息的数据结构

文档：开发，使用和维护程序所需要的图文字梁

软件工程支持环境：如果把各个阶段使用的软件工具有机地集合成一个整体，支持软件开发的全过程

1.2软件工程

定义

1. 软件工程就是为了经济地获得可靠的且能在实际机器上有效运行的软件，而建立和使用完善的工程原理
2. 软件工程是 ①把系统的、可规范的、可度量的途径应用于软件开发、运行和维护过程，也就是把工程应用于软件；②研究①中提到的途径

软件工程的本质特征

1. 软件工程关注于大型程序的构造
2. 软件工程的中心课题是控制复杂性
3. 软件经常变化
4. 开发软件效率非常重要
5. 和谐的合作是开发软件的关键
6. 软件必须有效的支持它的用户
7. 在软件工程领域中通常由具有一定文化北京的人替具有另一种文化背景的人创造产品

软件工程的基本原理

1. 用分阶段的生命周期计划严格管理
2. 坚持进行阶段评审
3. 实行严格的产品控制
4. 采用现代程序设计技术
5. 结果应能清楚地审查
6. 开发小组的人员应该少而精
7. 承认不断改进软件工程实践的必要性

管理：

通过计划，组织和控制等一系列活动，合理地配置和使用各种资源，以达到既定目标的过程

范型：

通常把在软件工程生命周期全过程中使用的一整套技术方法的集合称为方法学 也称为范型

软件工程学的三要素：方法 工具 过程

两种软件工程方法学：传统方法学和面向对象方法学

传统方法学

又称声明周期方法学或结构化范型。

采用结构化技术(结构化分析，结构化设计和结构化实现)来完成软件开发的各项任务，并使用适当的软件工具或软件工程环境来支持结构化技术的运行。

采用这种方法开发软件的时候，从对为题的抽象逻辑分析开始，一个阶段一个阶段地顺序进行开发（每个阶段的开始和结束有严格的标准）

面向对象方法学

传统方法学要么面向数据要么面向行为，没有既面向数据又面向行为的结构化技术，与之相反的面向对象方法学，把数据和行为看成是同等重要的，是一种以数据为主线，把数据和对数据的操作紧密地结合起来的方法。

面向对象方法学具有的四个要点

1. 把对象作为融合了数据及在数据上的操作行为的统一的软件构件。
2. 把所有对象都划分成类
3. 按照父类(基类)与子类（派生类）的关系，把若干个相关类组成一个层次结构的系统
4. 对象彼此间仅能通过发送消息互相联系

1.3软件生命周期

软件生命周期由软件定义，软件开发和运行维护三个时期组成，每个时期又进一步划分成如果个阶段。

软件定义(系统分析)： 确定软件开发工程必须完成的总目标；确定工程的可行性；导出实现工程目标应该采用的策略及系统必须完成的功能；估计完成该项工程需要的资源和成本，并制定工程进度表；

软件开发的四个阶段：总体设计，详细设计，编码和单元测试，综合测试。前两个又称为系统设计，后两个又称为系统设计。

维护时期的任务：使软件持久地满足用户的需要

软件生命周期每个阶段的基本任务：

1. 问题定义 :解决问题是什么
2. 可行性研究 ：对上一阶段所确定的问题有行得通的解决办法吗
3. 需求分析：为了解决这个问题，目标系统必须做什么
4. 总体设计 ： 怎样实现目标系统
5. 详细设计 ： 具体的实现这个系统
6. 编码和单元测试：写出正确的容易理解，容易维护的程序模块
7. 综合测试：通过各种类型的测试(以及相应的调试)使软件达到预定的要求
8. 软件维护：通过各种必要的维护活动是系统持久地满足用户的需求

软件过程

过程：使用资源将输入转化为输出的活动所构成的系统

通常使用生命周期模型简洁地描述软件过程。生命周期模型规定了把生命周期划分成哪些阶段及各个阶段的执行顺序，也称为过程模型。

瀑布模型

传统瀑布模型的特点：

1. 阶段间具有顺序性和依赖性
2. 推迟实现的观点
3. 质量保证的观点
   

实际的瀑布模型是带“反馈环”的，下图实线代表开发过程，虚线代表维护过程，当在后面阶段发现前面阶段的错误时，需要沿图中左侧的反馈线返回前面的阶段，修正前面阶段的产品之后再回来继续完成后面阶段的任务。

第二章 可行性研究

可行性研究的目的不是解决问题，而是确定问题是否值的去解决

2.1 可行性研究的任务

研究可行性的三个方面

1. 技术可行性：使用现有的技术能否实现这个系统
2. 经济可行性：这个系统的经济效益是否能超过它的开发成本
3. 操作可行性：系统的操作方式在这个用户组织内行得通吗

可行性研究的根本任务是对以后的行动方针提出建议。

2.2可行性研究过程

1. 复查系统的规模和目标 ：确保分析员正在解决的问题确实是要求他解决的问题
2. 研究目前正在使用的系统 ： 从现有的系统中区获取信息，并以现有去衡量新的系统是否合格
3. 导出新系统的高程逻辑模型 ：优秀的设计过程通常是从现有的物理系统出发，导出现有系统的逻辑模型，再参考现有系统的逻辑模型，设想目标系统的逻辑模型，最后根据目标系统的逻辑模型构造新的物理系统
4. 进一步定义问题
5. 导出和评价供选择的解法：分析员从他建议的系统逻辑模型触发，导出若干个较高层次（较抽象的）的物理解法供比较和选择
6. 推荐行动方针：分析员清楚地表明继续开发工程
7. 草拟开发计划
8. 书写文档提交审查: 把上述可行性研究各个步骤的工作结果写成清晰的文档，请用户，客户组织的负责人及评审组审查，以决定是否继续这项工程及是否接受分析员推荐的方案。

2.4 数据流图

数据流图是一种图形化技术，它描述信息流和数据从输入移动到输出的过程中所经受的变换。

数据流图中的符号

附加符号：

画数据流图的基本目的是利用它作为交流信息的工具，和作为分析和设计的工具。

2.5数据字典

数据字典应该由对下列四类元素的定义组成

1. 数据流
2. 数据流分量(数据元素)
3. 数据存储
4. 处理

除数据定义之外，数据字典还需要包含的其他信息：

一般信息(名字，别名，描述等)

定义(数据类型，长度，结构等)

使用特点(值的范围，使用频率，使用方式—-输入输出，本地，条件值等)

控制信息（来源，用户，使用他的程序，改变权，使用权等）

分类信息（父结构，从属结构，物理位置—记录，文件和数据库等）

出现别名的三种原因：

1. 对于同样的数据，不同的用户使用了不同的名字
2. 一个分析员在不同时期对同一个数据使用了不同的名字
3. 两个分析员分别分析同一个数据流时，使用了不同的名字

定义数据的方法

由数据元素组成数据的方式的基本类型

1. 顺序 即以确定次序连接两个和多个分量
2. 选择 即从两个或多个可能的元素中选取一个
3. 重复 即把从指定的分量重复零次或多次
4. 可选 即一个分量是可有可无的

符号

= 等价于(或定义为)

• 和 连接两个分量

[ ] 或 从括号中列出的若干分量中选择一个

{ } 重复 重复花括号中的分量

（ ） 可选

**数据字典的用途 **

数据字典最重要的用途是作为分析阶段的工具。

实现

例子：

第三章 需求分析

需求分析是软件定义时期的最后一个阶段，它的基本任务是准确地回答“系统必须做什么”的问题

用于需求分析的结构化方法需要遵守的准则(三类模型)

1. 必须理解并描述问题的信息域，根据这条准则应该建立数据模型
2. 必须定义软件应完成的功能，这条准则要求建立功能模型
3. 必须描述作为外部事件结果的软件行为，这条准则要求建立行为模型
4. 必须对描述信息，功能和行为的模型进行分解，用层次的方式展示细节

3.1 需求分析的任务

3.1.1 确定对系统的综合要求

1. 功能需求 ： 从这方面的需求指定系统必须提供的服务
2. 性能需求 ： 指定系统必须满足的定时约束和容量约束
3. 可靠性和可用性需求 ： 可靠性定量的指定系统的可靠性， 如“机场雷达系统在一个月内不能出现两次以上故障”。 可用性与可靠性密切相关，量化了用户使用系统的程度
4. 出错处理需求 ： 这类需求说明系统对环境错误应该怎样响应
5. 接口需求 ： 接口需求描述应用系统与它的环境通信的格式
6. 约束 ： 设计约束和实现描述在设计和实现应用系统时应遵守的限制条件
7. 逆向需求 ： 逆向需求说明软件系统不应该做什么
8. 将来可能提出的要求 ： 应该明确的列出那些虽然不属于当前系统开发范畴，但是据分析将来可能会提出来的要求

3.1.2 分析系统的数据要求

3.1.3 导出系统的逻辑模型

3.1.4 修正系统开发计划

3.2 与用户沟通获取需求的方法

3.2.1 访谈

访谈分为正式访谈和非正式访谈

正式访谈 ： 系统分析员事先准备好问题

分正式访谈 ：分析员提出一些用户可以自由回答的开放性问题

调查大量人员的意见时，可以采用向被调查人分发调查表的方式

访问用户的过程中使用情景分析术往往非常有效。情景分析就是对用户来使用目标系统解决某个具体问题的方法和结果进行分析。

情景分析技术的用处

1. 能在某种程度上演示目标系统的行为，从而便于用户理解，还可能进一步揭示出一些分析员目前还不知道的需求
2. 使用情景分析比较容易被用户所理解，使用这种技术能保证用户在需求分析过程中始终扮演一个积极主动的角色。

3.2.2 面向数据流自顶向下求精

软件系统本质上是信息处理系统，而任何信息处理系统的基本功能都是把输入数据转变成需要的输出信息。

结构化分析方法就是面向数据流自顶向下逐步求精进行需求分析的方法。

3.2.3简易的应用规格说明技术

简易的应用规格说明技术提倡用户和开发者密切合作，共同标识问题，提出解决方案要素，商讨不同的方案并指定基本需求。

3.2.4 快速建立软件原型

快速原型就是快速建立起来的旨在演示目标系统主要功能的可运行的程序

快速构建和修改原型的三种方法和工具

1. 第四代技术 ： 包括众多数据库查询和报表语言、程序和应用系统生成器以及其他非常高级的分过程语言。
2. 可重用的软件构件：使用一组已有的软件构件来装配原型
3. 形式化规格说明和原型环境

3.6状态转换图

状态转换图通过描绘系统的状态及引起系统状态转换的事件，来表示系统的行为。

3.6.1状态

状态是任何可以被观察的系统行为模式，一个状态代表系统的一种行为模式。状态规定了系统对事件的响应方式。

状态图中定义的状态主要有： 初态，终态和中间状态，一张状态图中只能有一个初态，而终态则有0至多个

3.6.2 事件

事件是在某个特定时刻发生的事情，它是对引起系统做动作或(和)从一个状态转换到另一个状态的外界事件的抽象。

3.6.3符号

状态图的例子

3.8验证软件需求

验证软件需求的正确性的四个方面

1. 一致性 : 所有需求必须是一致的，任何一条需求不能和其他需求互相矛盾
2. 完整性：需求必须是完整的，规格说明书应该包括用户需要的每一个功能或性能
3. 现实性：指定的需求必须是用现有的软件技术和硬件技术基本上可以实现的
4. 有效性 ： 必须证明需求正确有效，确实能解决用户面对的问题

第五章 总体设计

总体设计的基本目的就是回答“概括地说，系统应该如何实现这个问题”，总体设计又称为概要设计或初步设计。

5.1设计过程

总体设计过程通常由两个主要阶段组成： 系统设计阶段，确定系统的具体实现方案；结构设计阶段，确定软件结构。

典型总体设计过程包括的9个步骤

1. 设想供选择的方案
2. 选择合理的方案
3. 推荐最佳方案
4. 功能分解
5. 设计软件结构
6. 设计数据库
7. 制定测试计划
8. 书写文档
9. 审查和复审

5.2设计原理

1. 模块化 : 模块化就是把程序划分成独立命名且可独立访问的模块，每个模块完成一个子功能，把这些模块集合起来构成一个整体，可以完成制定的功能满足用户的需求。
2. 抽象 ：人类在认识复杂现象的过程中使用的最强最有力的思维工具是抽象。
3. 逐步求精 ：逐步求精是人类解决复杂问题时采用的基本方法，也是许多软件工程技术的基础
4. 信息隐藏和局部化
5. 模块独立 ：模块独立的概念是模块化、抽象、信息隐藏和局部化概念的直接结果

模块独立程度的两个定性标准度量 ： 内聚 和 耦合

耦合：

耦合是对一个软件结构内不同模块之间互连程度的度量。

耦合类型：

数据耦合 ： 两个模块彼此间通过参数交换信息，而且交换的信息仅仅是数据，那么这种耦合称为数据耦合

（数据耦合属于低耦合）

控制耦合 ：如果传递的信息中有控制信息，则这种耦合称为控制耦合(控制耦合属于中等程度的耦合)

公共环境耦合：当两个或多个模块通过一个公共数据环境相互作用时，它们之间的耦合称为公共环境耦合，公共环境可以是全程变量，共享的通信去，内存的公共覆盖去，任何存储介质上的文件，物理设备等

(公共环境耦合的复杂程度随耦合的模块个数而变化，当耦合的模块个数增加时复杂程度显著增加)

最高程度的耦合是内容耦合，出现内容耦合的情况：

1. 一个模块访问另一个模块的内部数据
2. 一个模块不通过正常入口而转到另一个模块的内部
3. 两个模块有一部分程序代码重叠(只可能出现在汇编程序中)
4. 一个模块有多个入口(这代表一个模块有几种功能)

内聚：

内聚标志着一个模块内各个元素彼此结合的紧密程度，它是信息隐藏和局部化概念的自然扩展。理想内聚的模块只做一件事情。

偶然内聚 ： 一个模块完成一组任务，这些任务彼此间即使有关系，关系也是松散的

逻辑内聚 ：如果一个模块完成的任务在逻辑上属于相同或相似的一类(例如一个模块产生各种类型的全部输出)

时间内聚 ：如果一个模块包含的任务必须在同一段时间内执行(例如，模块完成各种初始化工作)

过程内聚 ：如果一个模块内的处理元素是相关的，而且必须以特定次序执行

通信内聚 ： 如果模块中所有元素都使用同一个输入数据和(或)产生同一个输出数据，则称为通信内聚

顺序内聚 ： 如果一个模块内的处理元素和同一个功能密切相关，而这些处理必须顺序执行

功能内聚 ：如果模块内所有处理元素属于一个整体，完成一个单一的功能，则称为功能内聚，功能内聚是最高程度的内聚

5.3启发原则

1. 改进软件结构提高模块独立性
2. 模块规模应该始终
3. 深度，宽度，扇出和扇入都应适当
4. 模块的作用于应该在控制域之内
5. 力争降低模块接口的复杂程度
6. 设计单入口单出口的模块
7. 模块功能应该可以预测

5.5 面向数据流的设计方式

变换流：

信息沿输入通路进入系统，同时由外部形式转换成内部形式，进入系统的信息通过变换中心，经加工处理以后再沿输出通路变换成外部形式离开软件系统。

事务流：

数据沿输入通路到达一个处理T，这个处理根据输入数据的类型，在若干个动作序列中选出一个来执行

第六章 详细设计

详细设计阶段的根本目标是确定应该怎样具体地实现所要求的系统

6.1 结构程序设计

定义 ：

① 如果一个程序的代码块仅仅通过顺序，选择和循环这3中基本控制结构进行连接，并且每个代码块只有一个入口和一个出口，则称这个程序是结构化的。

②结构程序设计是尽可能少用GO TO语句的程序设计方法，最好仅在检测出错误时才是用GO TO语句，而且应该总是使用前先GO TO 语句

6.3 过程设计的工具

6.3.1 程序流程图

程序流程图的缺点：

1. 程序流程图本质上不是逐步求精的好工作，它诱使程序员过早地考虑程序的控制流程，而不去考虑程序的全局结构
2. 程序流程图中用箭头表示控制流，因此程序员不受任何约束，可以完全不顾结构程序设计的精神，随意转移控制
3. 程序流程图不易表示数据结构

6.3.2 盒图

盒图又称 N-S图，它的特点是：

1. 功能域(即一个特定控制结构的作用域)明确，可以从盒图上一眼就看出来
2. 不可能任意转移控制
3. 很容易确定局部和全程数据的作用域
4. 很容易表现嵌套关系，也可以表示模块的层级结构

盒图没有箭头，因此不允许随意转移控制

6.3.3 PAD图

PAD—问题分析图

PAD图的重要有点

1. 使用表示结构化控制结构的PAD符号所设计出来的程序必然是结构化程序。
2. PAD所描绘的程序结构十分清晰。
3. 用PAD图表现程序逻辑，易读，易懂，易记。
4. 容易将PAD图转换成高级语言源程序，这种转换可用软件工具自动完成，从而可省去人工编码的工作，有利于提高软件可靠性和软件生产率
5. 即可用于表示程序逻辑，也用于描绘数据结构
6. PAD图的符号支持自顶向下，逐步求精方法的使用。

6.3.4 判定表

一张判定表由四部分组成，左上部列出所有条件，左下部是所有可能做的动作，右上部是表示各种条件组合的一个矩阵，右下部是和每种条件组合向对应的动作。判定表右半部的每一列实际上是一条规则，规定了与特定的条件组合相对应的动作。

6.3.5判定树

判定树是判定表的变种，优点在于形式简单到不需要任何说明，一眼就可以看出其含义，因此易于掌握和使用。

6.5 程序复杂程度的定量度量

流图 ： 流图仅仅描绘程序的控制流程，完全不表现对数据的操作以及分支或具体条件

流图中用圆表示节点，一个圆代表一条或多条语句。

计算环形复杂度的方法

1. 流图中线性无关的区域数等于环形复杂度
2. 流图G的环形复杂度V(G) = E - N + 2其中E是流图中边的条数，N是结点数
3. 流图G的环形复杂度V(G) = P + 1，P是流图中判定节点的数目

7.实现

7.2 软件测试基础

7.2.1 软件测试的目标

1. 测试是为了发现程序中的错误而执行程序的过程
2. 好的测试方案是极可能发现迄今为止尚未发现的错误的测试方案
3. 成功的测试是发现了至今为止尚未发现的错误的测试

7.2.2 软件测试准则

1. 所有的测试都应该能追溯到用户需求
2. 应该远在测试开始之前就制定出测试计划
3. 把Pareto原理应用到软件测试中
4. 应该从小规模测试开始，并逐步进行大规模测试
5. 穷举测试是不可能的
6. 为了达到最佳的测试效果，应该由独立的第三方从事测试工作

7.2.3 测试方法

黑盒测试与白盒测试

黑盒测试是在程序接口进行的测试，它只检测程序功能是否能按规格说明书的规定正常使用，程序是否能适当地接收输入数据并产生正确的输出信息，程序运行过程中能否保持外部信息(例如数据库或文件)的完整性。黑盒测试又称为功能测试

白盒测试按照程序内部逻辑测试程序，检测程序中主要中兴通路是否都能按预定要求正确工作，又称结构测试

7.2.4测试步骤

1. 模板测试 ： 模板测试的目的是保证每个模板作为一个单元能正确运行，所以模板测试通常又称为单元测试
2. 子系统测试：子系统测试是把经过单元测试的模块放在一起形成一个子系统来测试。模块相互间的协调和通信是这个测试过程中的主要问题，因此，这个步骤着重测试模块的接口
3. 系统测试 ： 系统测试就是把经过测试的子系统装配成一个完整的系统来测试
4. 验收测试 ： 验收测试把软件系统作为单一的实体进行测试，测试内容与系统测试基本类似。但是它是在用户积极参与下进行的，而且可能主要是用实际数据来进行测试
5. 平行运行

7.3 单元测试

单元测试集中检测软件设计的最小单元—模块

单元测试主要使用白盒测试技术

单元测试的测试重点

1. 模块接口 ： 主要检查 ： 参数的数目，次序，属性或单位系统与变元是否一致；是否修改了置作输入用的变元；全局变量的定义和用法在各个模块中是否一致。
2. 局部数据结构 ： 局部数据说明，初始化，默认值等方面
3. 重要的执行通路 ： 应该设计测试方案用来发现由于错误的计算，不正确的比较或不适当的控制流而造成的错误
4. 出错处理同路 ： 好的设计应该能预见出现错误的条件，并且设置适当的处理错误的通路，以便在真的出现错误时执行相应的出错处理通路或干净地结束处理
5. 边界条件

7.4 集成测试

7.4.1 自顶向下的集成

从主控制模块开始，沿着程序的控制层次向下移动，逐渐把各个模块结合起来。在把附属于(及最终附属于)

主控制模块的哪些模块组装到程序结构中去时，或者使用深度优先的策略，或者使用宽度优先的策略。

步骤：

1. 对主控制模块进行测试，测试时用存根程序代替所有直接附属于主控制模块的模块
2. 根据选定的结合策略(深度优先或宽度优先)，每次用一个实际模块代换一个存根程序(新结合进来的模块往往又需要新的存根程序)
3. 在结合进一个模块的同时进行测试
4. 为了保证加入模块没有引进新的错误，可能需要进行回归测试(即全部或部分地重复以前做过的测试）

从 2 开始不断地重复进行上述过程，直到构造起完整的软件结构为止。

7.4.2 自底向上集成

自底向上测试从“原子”模块(即在软件结构最低处的模块)开始组装和测试。

因为从底部向上结合模块，总能得到所需的下层模块处理功能，所以不需要存根程序

步骤

1. 把底层模块组合成实现某个特定的软件子功能的族
2. 写一个驱动程序(用于测试的控制程序)，协调测试数据的输入和输出
3. 对由模块组成的子功能组进行测试
4. 去掉驱动程序，沿软件结构自下向上移动，把子功能组组合起来形成更大的子功能组。

7.4.3 不同集成测试策略的比较

自顶向下测试方法

主要优点是不需要测试驱动程序，能够在测试阶段的早期实现并验证系统的主要功能，而且能在早期发现上层模板的接口错误

缺点是：需要存根程序，可能遇到与此相联系的测试困难，底层关键模块中的错误发现较晚，而这种方法在早期不能充分展开人力。

自底向上测试方法的优缺点与自顶向下测试方法的优缺点相反

7.5 确认测试

Alpha测试由用户在开发者的场所进行，并且在开发者对用户的“指导”下进行测试。开发者负责记录发现的错误和使用中遇到的问题

Beta测试由软件的最终用户们在一个或多个客服场所进行。与Alpha测试不同，开发者通常不在Beta测试的现场，因此Beta测试是软件在开发者不能控制的环境中的“真实”应用

7.6 白盒测试

7.6.1 逻辑覆盖

1. 语句覆盖 ： 为了暴露程序中的错误，每个语句应该执行一次
2. 判定覆盖 ：不仅每个语句必须至少执行一次，而且每个判定的每种可能的结果都应该至少执行一次，每个判定的分支都至少执行一次
3. 条件覆盖 ： 不仅每个语句至少执行一次，而且使判定表达式中的每个条件都取到各种可能的结果
4. 判定/条件覆盖 ：选取足够多的测试数据，使得判定表达式中的每个条件都取到各种可能的值，而且每个判定表达式也都取到各种可能的结果
5. 条件组合覆盖 ： 选取足够多的测试数据，使得每个判定表达式中条件的各种可能组合都至少出现一次
6. 点覆盖
7. 边覆盖
8. 路径覆盖

7.6.2 控制结构测试

基本路径测试

步骤：

1. 根据过程设计结果画出对应的流图
2. 计算流图的环形复杂度
3. 确定线性独立路径的基本集合
4. 设计可强制执行基本集合中每条路径的测试用例

7.7 黑盒测试

7.7.1 等价划分

等价划分把程序的输入域划分成若干个（有效或无效的）数据类，据此导出测试用例。等价划分法力图设计出能发现若干类程序错误的测试用例，从而减少必须设计的测试用例的数目。

根据等价类设计测试方案时主要使用下面两个步骤。

(1) 设计一个新的测试方案以尽可能多地覆盖尚未被覆盖的有效等价类，重复这一步骤直到所有有效等价类都被覆盖为止。

(2) 设计一个新的测试方案，使它覆盖一个而且只覆盖一个尚未被覆盖的无效等价类，重复这一步骤直到所有无效等价类都被覆盖为止。

#等价类划分的启发式规则（了解之后做题用）：

（1）如果规定了输入值的范围，则可划分出一个有效的等价类，两个无效的等价类。

（2）如果规定了输入数据的个数，则类似地也可以划分出一个有效的等价类和两个无效的等价类。

（3）如果规定了输入数据的一组值，而且程序对不同的输入值做不同处理，则每个允许的输入值是一个有效的等价类，此外还有一个无效的等价类。

（4）如果规定了输入数据必须遵循的规则，则可以划分出一个有效的等价类和若干个无效的等价类。

（5）如果规定了输入数据为整型，则可以划分出正整数、零和负整数3个有效类。

（6）如果程序的处理对象是表格，则应该使用空表，以及含一项或多项的表。

7.9 软件可靠性

可靠性可用性基本概念

软件可靠性是程序在给定的时间间隔内，按照规格说明书的规定成功地运行的概率。（0到t时间段）

时间越长，运行出现程序故障的概率会增加，所有软件可靠性随着给定的时间间隔的加大而减少。

软件可用性是程序在给定的时间点，按照规格说明书的规定，成功地运行的概率。（在时刻t）

第八章 维护

维护阶段是软件生命周期的最后一个阶段，基本任务是八正软件在一个相当唱的周期能正常运行

1.定义和分类

定义：所谓软件维护就是在软件已经交付使用之后，为了改正错误或满足新的需要而修改软件的过程。可以通过描述软件交付使用后可能进行的4项活动，具体地定义软件维护。

分类：

改正性维护： 在任何大型程序的使用期间，用户必然会发现程序错误，并且把他们遇到的问题报告给维护人员。把诊断和改正错误的过程称为改正性维护。

适应性维护: 适应性维护，也就是为了和变化了的环境适当地配合而进行的修改软件的活动，是既必要又经常的维护活动。

完善性维护: 在使用软件的过程中用户往往提出增加新功能或修改已有功能的建议，还可能提出一般性的改进意见。为了满足这类要求，需要进行完善性维护。这项维护活动通常占软件维护工作的大部分。

预防性维护: 当为了改进未来的可维护性或可靠性，或为了给未来的改进奠定更好的基础而修改软件时，出现了第四项维护活动。这项维护活动通常称为预防性维护，目前这项维护活动相对比较少。

2、决定软件可维护性的因素(软件的可维护性定义为：维护人员理解，改正，改动或改进这个软件的难易程度)

1. 可理解性 ： 软件可理解性表现为外来读者理解软件的结构、功能、接口和内部处理过程的难易程度。

2. 可测试性 **：**对于程序模块来说，可以用程序复杂度来度量它的可测试性。

3. 可修改性 ： 软件容易修改的程度和本书第5章讲过的设计原理和启发规则直接有关。耦合、内聚、信息隐藏、局部化、控制域与作用域的关系等，都影响软件的可修改性。

4. 可移植性 **：**软件可移植性指的是，把程序从一种计算环境（硬件配置和操作系统）转移到另一种计算环境的难易程度。

5. 可重用性 **：**所谓重用（reuse）是指同一事物不做修改或稍加改动就在不同环境中多次重复使用。大量使用可重用的软件构件来开发软件，可以从下述两个方面提高软件的可维护性。

6. 维护代价高昂的原因

7. 维护费用

8. 当看起来和里的有关改错或修改的要求不能及时满足时将引起用户不满

9. 由于维护时的改动，在软件中引入了前夫的错误，从而降低了软件的质量

10. 当必须把软件工程师调去从事维护工作时，将在开发过程中造成混乱

11. 生产率的大幅度下降

第九章 面向对象方法学引论

面向对象方法把对象作为有数据及可以施加在这些数据上的操作所构成的统一体

面向对象基本特征：抽象、封装、继承、多态

面向对象的要点：

①面向对象的软件系统是由对象组成的，软件中的任何元素都是对象，复杂的软件对象由简单的对象组合而成；

②把所有对象都划分为对象类（简称类 class），每个对象类都定义了一组数据和一组方法，数据用于表示对象的静态属性，是对象的状态信息；

③按照子类（派生类）与父类（基类）的关系，把若干个对象组成一个层次结构的系统（类等级）；

④对象彼此之间仅能通过传递信息互相联系。

1、面向对象方法学的优点

a.与人类习惯的思维方法一致

b.稳定性好

c.可重用性好

d.较易开发大型软件产品

e.可维护性好

2、面向对象建模

面向对象方法开发软件，通常需要建立3种形式的模型，它们分别是描述系统数据结构的对象模型，描述系统控制结构的动态模型和描述系统功能的功能模型。

【一个典型的软件系统使用数据结构（对象模型），执行操作（动态模型），并且完成数据值的变化（功能模型）】

【对象模型（静态的、结构化的系统的“数据”性质）：类图；

动态模型（瞬时的，行为化的系统的“控制”性质）：状态图；

功能模型（变化的系统的“功能”性质）：用例图】

3、用例图概念

l UML提供的用例图是进行需求分析和建立功能模型的强有力工具。在UML中把用用例图建立起来的系统模型称为用例模型。

l 用例模型描述的是外部行为者(actor）所理解的系统功能。用例模型的建立是系统开发者和用户反复讨论的结果，它描述了开发者和用户对需求规格所达成的共识。

4、用例图包含哪些基本元素

一幅用例图包含的模型元素有系统、行为者、用例及用例之间的关系

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-pouYxxkO-1653726021379)(https://secure2.wostatic.cn/static/feBTPab4h98tZTFjYxNzex/image.png)]

第十章 面向对象分析

面向对象分析关键是识别出问题域内的类与对象，并分析它们相互间的关系，最终建立起问题域的简洁、精确、、可理解的正确模型。

3个模型与5个层次

在面向对象分析中，主要由对象模型、动态模型和功能模型组成。

【面向对象建模得到的模型包含系统的3个要素：静态结构（对象模型）、交互次序（动态模型）和数据变换（功能模型）。】

复杂问题（大型系统）的对象模型通常由下述5个层次组成：

主题层、类与对象层、结构层、属性层、服务层

层次对应在面向对象分析过程中建立对象模型的5项主要活动：找出类与对象，识别结构，识别主题，定义属性，定义服务（没必要顺序完成）

三个模型中，对象模型是最基本、最重要、最核心的。

第十一章 面向对象设计

1、面向对象设计的准则

模块化、抽象、信息隐藏、弱耦合、强内聚、可重用

2、面向对象设计的启发规则

①设计结果应该清晰易懂；

②一般一特殊结构的深度应适当；

③设计简单的类；

④使用简单的协议；

⑤使用简单的服务；

⑥把设计变动减至最小。

3软件重用

a.重用也叫再用或复用，是指同一事物不作修改或稍加改动就多次重复使用。

广义地说，软件重用可分为以下3个层次：知识重用、方法和标准的重用、软件成分的重用

b.软件成分的重用级别

代码重用；设计结果重用；分析结果重用。

3、面向对象设计模型（分为四个垂直切片）四大组成部分（系统分解并分别设计）：人机交互部分、问题域部分、任务管理部分、数据管理部分。