软件工程导论复习知识点

Posted 2021-06-30 Dreamchaser追梦

前言

这是我在准备软件工程基础考试时根据考点整理的一份知识点汇总。

一、软件工程概述

1.软件危机

• 软件是计算机系统中与硬件相互依存的另一部分，它是包括程序，数据及其相关文档的完整集合。

• 软件的特点是：

  • 软件是一种逻辑实体，而不是具体的物理实体。因而它具有抽象性。
  • 软件的生产与硬件不同，它没有明显的制造过程。对软件的质量控制，必须着重在软件开发方面下功夫。
  • 在软件的运行和使用期间，没有硬件那样的机械磨损，老化问题。
  • 软件的开发和运行常常受到计算机系统的限制，对计算机系统有着不同程度的依赖性。为了解除这种依赖性，在软件开发中提出了软件移植的问题。
  • 软件的开发至今尚未完全摆脱手工艺的开发方式。
  • 软件本身是复杂的。软件的复杂性可能来自它所反映的实际问题的复杂性，也可能来自程序逻辑结构的复杂性。
  • 软件成本相当昂贵。软件的研制工作需要投入大量的、复杂的、高强度的脑力劳动，它的成本是比较高的。
  • 相当多的软件工作涉及到社会因素。许多软件的开发和运行涉及机构、体制及管理方式等问题，甚至涉及到人的观念和人们的心理。它直接影响到项目的成败。

• 软件危机的原因

  • 与软件本身的特点有关
  • 与软件开发和维护的方法不正确有关

2.软件工程原理及方法学

• 软件工程基本原理
  • 用分阶段的生命周期计划严格管理
  • 坚持进行阶段评审
  • 实行严格的产品控制
  • 采用现代程序设计技术
  • 结果应能清楚的审查
  • 开发小组的人员应该少而精
  • 承认不断改进软件工程实践的必要性
• 软件工程方法学
  • 包括三个要素：方法、工具和过程
  • 最广泛的软件工程方法学：传统方法学和面向对象方法学

3.掌握软件生命周期

• 制定计划

• 需求分析

• 软件设计

• 程序编写 : 把软件设计转换成计算机可以接受的程序代码。

• 软件测试 : 在设计测试用例的基础上检验软件的各个组成部分。

• 运行／维护 : 已交付的软件投入正式使用，并在运行过程中进行适当的维护。

4.掌握软件过程模型

• 瀑布模型 : 瀑布模型规定了各项软件工程活动，包括：制定开发计划，进行需求分析和说明，软件设计，程序编码。测试及运行维护，参看图1.2。并且规定了它们自上而下，相互衔接的固定次序，如同瀑布流水，逐级下落。

​ 　　　 　　　 图1.2 软件生存周期的瀑布模型

• 快速原型模型 : 由于在项目开发的初始阶段人们对软件的需求认识常常不够清晰，因而使得开发项目难于做到一次开发成功，出现返工再开发在所难免。因此，可以先做试验开发，其目标只是在于探索可行性，弄清软件需求；然后在此基础上获得较为满意的软件产品。通常把第一次得到的试验性产品称为“原型”。

• 增量模型“：把产品作为一系列的增量构件来开发

• 螺旋模型 : 对于复杂的大型软件，开发一个原型往往达不到要求。螺旋模型将瀑布模型与演化模型结合起来，并且加入两种模型均忽略了的风险分析。螺旋模型沿着螺线旋转，如图1.3所示，在笛卡尔坐标的四个象限上分别表达了四个方面的活动，即：

  制定计划──确定软件目标，选定实施方案，弄清项目开发的限制条件；

  风险分析──分析所选方案，考虑如何识别和消除风险；

  实施工程──实施软件开发

  客户评估──评价开发工作，提出修正建议。

  沿螺线自内向外每旋转一圈便开发出更为完善的一个新的软件版本。
  

​ 图1.3 螺旋模型

d) 喷泉模型 : 喷泉模型对软件复用和生存周期中多项开发活动的集成提供了支持，主要支持面向对象的开发方法。“喷泉”一词本身体现了迭代和无间隙特性。系统某个部分常常重复工作多次，相关功能在每次迭代中随之加入演进的系统。所谓无间隙是指在开发活动，即分析、设计和编码之间不存在明显的边界。如图1.4所示。

图1.4 喷泉模型

5.掌握软件过程的四个基本活动

• plan——软件规格说明

• do——软件开发，产生满足规格说明的软件。

• check——软件确认，确认软件能够满足客户提出的要求。

• action——软件演进。

二、可行性研究

1.研究的目的

以最小的代价在尽可能短的时间内确定问题是否能够解决

2.研究的方面

• 经济可行性
• 技术可行性
• 法律可行性
• 方案的选择

3.数据流图

4.数据字典

• 组成元素：数据流、数据流分量（即数据元素）、数据存储、处理
• 定义数据的方法

三、需求分析

1.掌握需求分析阶段的工作成果

• 分析建模

  • 为了更好理解复杂事务，人们常常采用建立事物模型的方法
  • 模型：理解事物而对事物作出的一种抽象

• 数据模型

  包括三种互相关联的信息：数据对象，描述对象的属性，描述对象间相互连接的关系。

  • 数据对象 ：是需被目标系统所理解的复合信息的表示。所谓复合信息是具有若干不同特征或属性的信息。

  • 属性 ：定义了数据对象的特征。它可用来：① 为数据对象的实例命名；② 描述这个实例；③ 建立对另一个数据对象的另一个实例的引用。如学生数据对象的属性可以有学号、姓名、性别、出生年月、籍贯等。

  • 关系 ：各个数据对象的实例之间有关联。如一个学生“张鹏”选修两门课程“软件工程”与“计算机网络”，学生与课程的实例通过“选修”关联起来。实例的关联有三种：① 一对一(1:1)；② 一对多(1:m)；③ 多对多(n:m)。这种实例的关联称为“基数”。基数表明了“重复性”。如1位教师带学生班的30位同学，就是1:m的关系。但也有1位教师带0位同学的情形。所以实例关联有是“可选”还是“必须”之分。用“〇”表示关系是可选的，用“│”表示关系必须出现1次。如图2.4所示。这表明了关系的“参与性”。

• 功能模型

  功能建模的思想就是用抽象模型的概念，按照软件内部数据传递、变换的关系，自顶向下逐层分解，直到找到满足功能要求的所有可实现的软件为止。根据DeMarco的论述，功能模型使用了数据流图来表达系统内数据的运动情况，而数据流的变换则用结构化英语、判定表与判定树来描述。

• 规格说明

描述系统的数据要求、功能需求、性能需求等

2.ER图和STD图

• ER图：即实体-联系图

• STD图：即状态转移图

  • 状态：被观察到的系统行为模式

  • 事件：引起状态转换的外界事件抽象，

  

  事件表达式 = 事件名 + [条件]

  • 行为：进入某状态所作动作

  

  行为用活动表表示：活动表 = 事件名 + / + 动作表达式

  • 例子

3.应从哪些方面验证软件需求

• 一致性
• 完整性
• 现实性
• 有效性

四、总体设计

1.软件设计过程中应遵循的基本原理及相关概念

• 软件设计过程
  • 设想供选择的方案
  • 选取合理的方案
  • 推荐最佳方案
  • 功能分解
  • 设计软件结构
  • 设计数据库
  • 制定测试计划
  • 书写文档
  • 复查和审查
• 基本原理
  • 模块化
  • 抽象
  • 逐步求精
  • 信息隐藏和局部化
  • 模块独立

2.耦合和内聚

• 耦合

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

  • 数据耦合

    模块交换信息仅仅是数据

  • 控制耦合

    模块间交换的信息包括控制信息（尽管也以数据呈现）

  • 特征耦合

    传递数据结构的信息大于模块所需要的信息

  • 公共环境耦合

    模块通过一个公共数据环境相互作用

  • 内容耦合（最高程度耦合）

    一个模块访问另一个模块的数据；

    一个模块不通过正常入口而转到另一个模块的内部；

    两个模块有一部分程序代码重叠（只可能出现在汇编程序中）；

    一个模块有多个入口（意味着一个模块由几个功能）

• 内聚

  内聚标志着一个模块内各个元素彼此结合的紧密程度

  • 偶然内聚（低内聚）

    模块的任务之间关系很松散

  • 逻辑内聚（低内聚）

    模块完成的任务在逻辑上是相同或者相似的一类

  • 时间内聚（低内聚）

    模块包含的任务必须在同一段时间内执行（如各种初始化工作）

  • 过程内聚（中内聚）

    模块内的处理元素是相关的，而且必须以特定次序执行

  • 通信内聚（中内聚）

    模块内所有元素使用同一个数据或产生同一个输出数据

  • 顺序内聚（高内聚）

    模块内的处理元素和同一个功能密切相关，且必须顺序执行

  • 功能内聚（高内聚）

    模块内所有元素属于一个整体，完成一个单一的功能

3.软件设计的启发规则

• 改进软件结构提高模块独立性
• 模块规模应该适中
• 深度、宽度、扇出和扇入都应适当
• 模块的作用域应该在控制域内
• 力争降低模块接口的复杂程度
• 设计单入口单出口的模块
• 模块功能应该可以预测

4.图形工具

层次图（H图）

体系框图。又称层次图（H图），是可视目录表的主体，用它表明各个功能的隶属关系。它是自顶向下逐层分解得到的，是一个树形结构。

HIPO图

即层次图 + 输入/处理/输出图 的英文缩写，由一张H图和一组IPO图组成。

H图（层次图），是给每个模块加上编号的层次图。 IPO图，要为H图中的每个模块画一张IPO图。 通常将HIPO图作为软件结构的描绘,列入设计文档。

面向数据流的设计方法（SD方法）

• 信息流的类型

  • 变换流
  • 事务流

五、详细设计

1.程序设计的基本控制结构

• 顺序结构
• IF_THEN_ELSE型选择（分支）结构
• DO_WHILE型循环结构

2.人机界面设计问题及设计指南

• 设计问题
  • 系统响应时间
  • 用户帮助措施
  • 出错信息处理
  • 命令交互
• 设计指南
  • 一般交互指南
  • 信息显示指南
  • 数据输入指南

注：详细信息不列举了，主要就是为了更好的用户体验

3.过程设计的主要工具

①程序流程图

程序流程图独立于任何一种程序设计语言，比较直观、清晰，易于学习掌握。但流程图也存在一些严重的缺点。例如流程图所使用的符号不够规范，常常使用一些习惯性用法。特别是表示程序控制流程的箭头可以不受任何约束，随意转移控制。这些现象显然是与软件工程化的要求相背离的。为了消除这些缺点，应对流程图所使用的符号做出严格的定义，不允许人们随心所欲地画出各种不规范的流程图。例如，为使用流程图描述结构化程序，必须限制流程图只能使用图4.24所给出的五种基本控制结构。

②盒图（N-S图）

Nassi和Shneiderman 提出了一种符合结构化程序设计原则的图形描述工具，叫做盒图，也叫做N-S图。为表示五种基本控制结构，在N-S图中规定了五种图形构件。参看图4.26。

图4.26 N-S图的五种基本控制结构

③PAD图

PAD是Problem Analysis Diagram的缩写，它是日本日立公司提出，由程序流程图演化来的，用结构化程序设计思想表现程序逻辑结构的图形工具。现在已为ISO认可。

PAD也设置了五种基本控制结构的图式，并允许递归使用。

图4.28 PAD的基本控制结构

做为PAD应用的实例，图4.29给出了图4.25程序的PAD表示。PAD所描述程序的层次关系表现在纵线上。每条纵线表示了一个层次。把PAD图从左到右展开。随着程序层次的增加，PAD逐渐向右展开。

PAD的执行顺序从最左主干线的上端的结点开始，自上而下依次执行。 每遇到判断或循环，就自左而右进入下一层，从表示下一层的纵线上端开始执行，直到该纵线下端，再返回上一层的纵线的转入处。如此继续，直到执行到主干线的下端为止。

图4.29 PAD实例

④判定表

当算法中包含多重嵌套的条件选择时，用程序流程图、N-S图或PAD都不易清楚地描述。然而，判定表却能清晰地表达复杂的条件组合与应做动作之间的对应关系。仍然使用图4.16的例子。为了能适应判定表条件取值只能是“T”和“F”的情形，对原图稍微做了些改动，把多分支判断改为两分支判断，但整个图逻辑没有改变。见图4.30。

图4.30 不包含多分支结构的流程图实例

与图4.30表示的流程图对应的判定表如图4.31所示。在表的右上半部分中列出所有条件，“Ｔ”表示该条件取值为真，“Ｆ”表示该条件取值为假，空白表示这个条件无论取何值对动作的选择不产生影响。在判定表右下半部分中列出所有的处理，画“Ｙ”表示要做这个动作，空白表示不做这个动作。判定表右半部的每一列实质上是一条规则，规定了与特定条件取值组合相对应的动作。

图4.31 反映程序逻辑的判定表

判定表的优点是能够简洁，无二义性地描述所有的处理规则。但判定表表示的是静态逻辑，是在某种条件取值组合情况下可能的结果，它不能表达加工的顺序，也不能表达循环结构，因此判定表不能成为一种通用的设计工具。

⑤判定树

判定表的变种

⑥PDL ( Program Design Language )

PDL是一种用于描述功能模块的算法设计和加工细节的语言。称为设计程序用语言。它是一种伪码。一般地，伪码的语法规则分为“外语法”和“内语法”。外语法应当符合一般程序设计语言常用语句的语法规则；而内语法可以用英语中一些简单的句子、短语和通用的数学符号，来描述程序应执行的功能。

PDL就是这样一种伪码。它具有严格的关键字外语法，用于定义控制结构和数据结构，同时它的表示实际操作和条件的内语法又是灵活自由的，可使用自然语言的词汇。下面举一个例子，来看PDL的使用。
　 PROCEDURE spellcheck IS 查找错拼的单词
BEGIN
split document into single words 把整个文档分离成单词
lood up words in dictionary 在字典中查这些单词
display words which are not in dictionary 显示字典中查不到的单词
create a new dictionary 造一新字典
END spellcheck

从上例可以看到，PDL 语言具有正文格式，很像一个高级语言。人们可以很方便地使用计算机完成PDL的书写和编辑工作。

PDL作为一种用于描述程序逻辑设计的语言，具有以下特点：

• 有固定的关键字外语法，提供全部结构化控制结构、数据说明和模块特征。属于外语法的关键字是有限的词汇集，它们能对PDL正文进行结构分割，使之变得易于理解。为了区别关键字，规定关键字一律大写，其它单词一律小写。

• 内语法使用自然语言来描述处理特性。内语法比较灵活，只要写清楚就可以，不必考虑语法错，以利于人们可把主要精力放在描述算法的逻辑上。

• 有数据说明机制，包括简单的（如标量和数组）与复杂的（如链表和层次结构）的数据结构。

• 有子程序定义与调用机制，用以表达各种方式的接口说明。

使用PDL语言，可以做到逐步求精：从比较概括和抽象的PDL程序起，逐步写出更详细的更精确的描述。

但不直观！

4.面向数据结构的设计方法

①Jackson图

图4.21 三种基本控制结构的图解

图4.19 信用卡记账系统的输出

②Warnier方法

此方法仅了解名字即可

5.环型复杂度的计算方法

环路复杂度用来定量度量程序的逻辑复杂度。以McCabe方法来表示。

在程序控制流程图中，节点是程序中代码的最小单元，边代表节点间的程序流。一个有e条边和n个节点的流程图F，可以用下述3种方法中的任何一种来计算环形复杂度。
（1）流图中的区域数等于环形复杂度。
（2）流图G的环形复杂度V(G)=E-N+2，其中，E是流图中边的条数，N是结点数。
（3）流图G的环形复杂度V(G)=P+1，其中，P是流图中判定结点的数目。

环路复杂度越高，程序中的控制路径越复杂。

六、实现

1.选择程序设计语言的依据及编码风格的选择

• 依据
  • 系统用户的要求
  • 可以使用的编译程序
  • 可以得到的软件工具
  • 工程规模
  • 程序员的知识
  • 软件可移植性的要求
  • 软件的应用领域
• 编码风格
  • 程序内部的文档
  • 数据说明
  • 语句构造
  • 输入输出
  • 效率

2.软件测试基础

• 目标：为了发现程序中的错误

• 测试准则

  • 所有测试都应该能追溯到用户需求
  • 应该远在测试开始之前就制定测试计划
  • 把P阿勒to原理应用到软件测试中（软件的80%的错误是由20%的模块引起的）
  • 应该从小规模测试开始，并逐步转向大规模测试
  • 穷举测试是不可能
  • 应该由独立的第三方从事测试工作

• 测试方法

  • 黑盒测试

    测试者不知道程序的内部结构和处理程序

  • 白盒测试（结构测试）

• 测试方法

  • 模块测试
  • 子系统测试
  • 系统测试
  • 验收测试
  • 平行测试（新旧系统同时运行以作对比）

3.单元测试、集成测试和确认测试

①单元测试

测试重点为：

• 模块接口

• 局部数据结构

• 重要的执行通路

• 出错处理通路

• 边界条件

②集成测试

测试和组装软件的系统化技术

测试顺序：

• 自顶向下集成

  先测上层控制模块，然后逐步向下测试

• 自底向上集成

③确认测试

也称验收测试，为了验证软件的有效性

通常使用黑盒测试法

4.白盒测试和黑盒测试的主要方法

①白盒测试

• 逻辑覆盖
  • 语句覆盖
  • 判定覆盖
  • 条件覆盖
  • 判定/条件覆盖
  • 条件组合覆盖
  • 点覆盖
  • 边覆盖
  • 路径覆盖
• 控制结构测试
  • 基本路径测试
  • 条件测试
  • 循环测试

②黑盒测试

黑盒测试试图发现下述类型的错误：

• 功能不正确或遗漏了功能
• 界面错误

技术：

• 等价划分

  将输入互粉为若干个数据类

• 边界值分析

  确定程序边界情况

• 错误推测

  列举出程序中可能有的错误和容易发生的错误的特殊情况，并据此选择测试方案

5.调试的过程和途径

1.调试过程

2.调试途径

• 蛮干法

• 回溯法

• 原因排除法

七、软件维护

1.软件维护的概念及类型

定义：在软件交付使用之后，为了改正错误或满足新的需要而修改软件的过程

类型：

• 改正性维护
• 适应性维护
• 完善性维护
• 预防性维护

2.可维护性

软件文档

分类：用户文档，系统文档

①用户文档

描述内容：

• 功能描述
• 安装文档
• 使用手册
• 参考手册
• 操作员指南

要求：应能使用户获得对系统的准确的初步印象，文档的结构方式应该使用户能够方便地根据需要阅读有关的内容。

②系统文档

从问题定义、需求说明到验收测试计划这样一系列和系统实现有关的文档

• 控制结构测试
  • 基本路径测试
  • 条件测试
  • 循环测试