软件工程导论复习知识点

Posted Dreamchaser追梦

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了软件工程导论复习知识点相关的知识,希望对你有一定的参考价值。

前言

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

一、软件工程概述

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所示。在表的右上半部分中列出所有条件,“T”表示该条件取值为真,“F”表示该条件取值为假,空白表示这个条件无论取何值对动作的选择不产生影响。在判定表右下半部分中列出所有的处理,画“Y”表示要做这个动作,空白表示不做这个动作。判定表右半部的每一列实质上是一条规则,规定了与特定条件取值组合相对应的动作。

图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.可维护性

软件文档

分类:用户文档,系统文档

①用户文档

描述内容:

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

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

②系统文档

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

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

以上是关于软件工程导论复习知识点的主要内容,如果未能解决你的问题,请参考以下文章

计算机安全导论期末复习小笔记

人工智能导论期末复习合集

软件工程导论期末复习重点

软件工程导论期末复习试题集

如何评测软件工程知识技能水平?

网络空间安全导论期末复习资料