《软件工程导论》期末复习知识总结

最新推荐文章于 2024-05-09 23:35:17 发布

淘淘是只狗

最新推荐文章于 2024-05-09 23:35:17 发布

阅读量5.1k

点赞数 16

分类专栏：杂

本文链接：https://blog.csdn.net/qq_43477721/article/details/106885416

版权

杂专栏收录该内容

22 篇文章 6 订阅

订阅专栏

第一章软件工程概论

软件：是计算机程序、方法、规则、相关的文档以及运行计算机系统时所必需的数据的总和(狭义定义：软件＝程序+数据+文档)
软件的特性：软件是复杂的、软件是不可见的、软件是不断变化的和软件质量难以稳定。
软件的质量特性：功能性、可靠性、易用性、效率、维护性、可移植性。

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

1.1.1 软件危机的主要表现：

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

1.1.2 软件危机产生的主要原因:

软件日益复杂和庞大
软件开发管理困难和复杂
软件开发技术落后
生产方式落后
开发工具落后
软件开发费用不断增加

1.1.3 软件危机如何解决：既要有技术措施（方法和工具），又要有必要的组织管理措施。

1.2 软件工程：是指导计算机软件开发和维护的一门工程学科。采用工程的概念、原理、技术和方法来开发与维护软件，把经过时间考验而证明正确的管理技术和当前能够得到的最好的技术方法结合起来，以经济地开发出高质量的软件并有效地维护它。

1.2.1 软件工程的本质特性

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

1.2.2 软件工程的基本原理

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

1.2.3 软件工程方法学：把软件生命周期全过程中使用的一整套技术方法的集合成为方法学(也称范型paradigm)，包括三个要素:方法,工具和过程，目前使用最广泛的是传统方法学和面向对象方法学

传统方法学(也称生命周期方法学或结构化范型)
面向对象方法学: 有4个要点; 它是一个多次反复迭代的演化的过程; 特有的继承性和多态性进一步提高了面向对象软件的可重用性

1.3 软件生命周期

问题定义:确定要解决的问题是什么(通过客户的访问调查,系统分析员写出问题的性质,工程目标和工程规模的书面报告,并得到客户的确认)
可行性研究:不是具体解决问题,而是研究问题的范围,探索问题是否值得去解,是否有可行的解决方法
需求分析:准确地确定"为了解决这个问题,目标系统必须做什么",主要是确定目标系统必须具备哪些功能
总体设计:设计出目标系统的多种方案;设计程序的体系结构
详细设计:详细的设计每个模块,确定要实现模块功能所需要的算法和数据结构
编码和单元测试:写出正确的容易理解,容易维护的程序模块
综合测试:通过各种类型的测试(及相应的的调试)使软件达到预定的要求
软件维护:通过各种必要的维护活动使系统持久地满足用户的需要

1.4 软件过程:指为了获得高质量软件所需完成一系列任务框架,它规定了完成各项任务的工作步骤;通常使用生命周期模型简洁地描述软件过程

生命周期模型:也称过程模型规定了把生命周期划分成哪些阶段及各个阶段的执行顺序

瀑布模型

快速原型模型

增量模型

螺旋模型

喷泉模型

（具体看课本介绍，内容有点多）

第二章可行性研究

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

可行性：技术可行性、经济可行性、操作可行性。

2.2可行性研究过程

复查系统规模和目标
研究正在使用的系统
导出新系统的高层逻辑模型
进一步定义问题
导出和评价供选择的解法
推荐行动方针
草拟开发计划
书写文档提交审查

2.3 系统流程图：是概括地描绘物理系统的传统工具。用图形符号以黑盒子形式描绘组成系统的每个部件（程序，文档，数据库，人工过程等）。表达的是`数据在系统各部件之间流动的情况`

2.4 数据流图: 数据流图(DFD)是一种图形化技术, 它描绘数据从输入移动到输出的过程中所经受的变换。在数据流图中没有任何具体的物理部件,它只是描绘数据在软件中流动和被处理的逻辑过程

2.5 数据字典定义组成：数据流；数据流分量（即数据元素）；数据存储；处理

在这里插入图片描述

2.6 成本效益分析的方法及如何运算:

第一步估计开发成本、运行费用和新系统将带来的经济效益。需从货币时间价值,投资回收期,纯收入,投资回收率
方法有三种：

代码行技术：软件成本 = 每行代码的平均成本*估计的源代码总行数
任务分解技术：单本任务成本=任务所需人力估计值*每人每月平均工资；软件开发项目总成本=每个单独任务成本估计总和
自动估计成本技术：采用自动估计成本的软件

第三章需求分析

准确地确定"为了解决这个问题,目标系统必须做什么"

目前有许多不同的用于需求分析的 结构化分析方法（SA）,但是,所有这些分析方法都遵守下述准则。

必须理解并描述问题的信息域,根据这条准则应该建立数据模型（E-R 图）
必须定义软件应完成的功能,这条准则要求建立功能模型（DFD图）
必须描述作为外部事件结果的软件行为，这条准则要求建立行为模型（状态转换图）
必须对描述信息、功能和行为的模型进行分解,用层次的方式展示细节

3.1 需求分析的任务

确定对系统的综合要求
- 功能需求
- 性能需求
- 可靠性和可用性需求
- 出错处理需求
- 接口需求
- 约束
- 逆向需求
- 将来可能提出的要求
分析系统的数据要求
导出系统的逻辑模型
修正系统开发计划

3.3 分析建模与规格说明

模型: 就是为了理解事物而对事物作出的一种抽象,是对事物的一种无歧义的书面描述。通常，模型由一组图形符号和组织这些符号的规则组成
需要建立的三种模型：数据模型，功能模型 ，行为模型
在这里插入图片描述

实体-联系图：描绘数据对象、数据对象的属性及数据对象之间的关系，用于建立数据模型
数据流图：描绘当数据在软件系统中流动和被处理的逻辑过程，是建立功能模型的基础
状态转换图：描绘了系统的状态及引起状态转换的事件，是建立行为模型的基础

3.7 其他图形工具

层次方框图
Warnier 图

第四章形式化说明技术

（我们不学，所以。。。）

第五章总体设计（概要设计或初步设计）

5.1 设计过程

设计过程：2个阶段 ( 系统设计阶段: 确定系统的具体实现方案 和 结构设计阶段: 确定软件结构)
9个步骤：

设想供选择的方案
选取合理的方案
推荐最佳方案
功能分解
设计软件结构
设计数据库
制定测试计划
书写文档
审查和复审

5.2 设计原理

5.2.1 模块化：就是把程序划分成独立命名且可独立访问的模块，每个模块完成一个子功能，这些模块集成起来构成一个整体，可以完成指定的功能满足用户的需求

5.2.2 抽象：抽出事物本质特性而暂时不考虑细节

5.2.3 逐步求精：为了能集中精力解决最主要问题而尽量推迟对问题细节的考虑。逐步求精是人类解决复杂问题时采用的基本方法，也是许多软件工程技术的基础

5.2.4 信息隐藏：应该这样设计和确定模块，使得一个模块内包含的信息对于不需要这些信息的模块来说是不能访问的。局部化：是指把一些关系密切的软件元素物理地址放得彼此靠近

5.2.5 模块独立：是模块化、抽象、信息隐藏和局部化的概念的直接结果。独立的程度测量标准：内聚、耦合

`高内聚低耦合`

5.3 启发规则

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

5.4 描绘软件结构的图形工具

5.4.1 层次图：描绘软件的层次结构。一个矩形框代表一个模块，方框间的连线表示调用关系

5.4.2 HIPO图：“层次图加输入/处理/输出图”，就是在层次图的每个方框加编号

5.4.3 结构图：每个方框代表一个模块，框内注明模块的名字或主要功能，方框间的箭头（或直线）代表模块的调用关系，注释表示来回传递的信息【尾部空心圆表示传递数据，实心圆代表传递控制信息】

第六章详细设计

6.2 人机界面设计指南

一般交互指南
信息显示指南
数据输入指南

6.3 过程设计的工具

6.3.1 程序流程图：

优点：对控制流程的描绘直观，初学者很容易掌握
缺点：1.程序流程图不是精益求精的好工具，它诱使程序员过早地考虑程序的控制流程，而不去考虑全局结构
2.程序流程图中用箭头代表控制流 ，因此程序员不受任何约束，可以完全不顾结构程序设计的思想，随意转移
3.程序流程图不易表示数据结构

在这里插入图片描述

6.3.2 盒图（N-S图）的特点：

1.功能域明确
2.不可能任意转移控制
3.很容易确定局部和全局数据的作用域
4. 很容易表现嵌套关系，也可以表示模块的层次结构

在这里插入图片描述

6.3.3 问题分析图（PAD图）其优点：

1.使用PAD符号设计出来必然是结构化程序
2.PAD图描绘的程序结构十分清楚
3.PAD图表现程序的逻辑，易读、易懂、易记
4.很容易将PAD图转化为高级语言程序,
5.即可表示程序逻辑，也可表示数据结构
6.PAD符号支持自动向下，逐步求精

在这里插入图片描述

6.3.4 判定表：当算法中含有多重嵌套的条件选择时

优点：能清晰表示复杂的条件组合与应做的动作之间的关系
缺点：1.判定表的含义不能一眼看出来
2.当数据元素多于两个时，判定表的简洁程度下降

在这里插入图片描述

6.3.5 判定树：判定表变种

优点：一眼看出其含义，易于掌握，使用
缺点：1.简洁性不如判定表，数据元素需重复写多遍
2.判定树的分支次序对画出的判定树的简洁程度有较大影响

在这里插入图片描述

6.3.6 PDL（过程设计语言）

也称伪码,具有严格的关键字外部语法,用于定义控制结构和数据结构,内部语法灵活自由,适应各种工程项目。

其优点：
1.可作为注释直接插在源程序中间
2.可使用普通的正文编辑程序或文字处理系统完成PDL的书写和编辑
3.已有自动处理PDL的程序，可自动生成程序代码

其缺点：
不如图形工具形象直观，描述复杂的条件组合与动作间的对应关系时，不如判定表清晰简单

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

6.5.1 McCabe方法：McCabe根据程序控制流的复杂程度度量程序的复杂程度，这样度量出的结果称为程序的环形复杂度

1.流图的表示：

结点：用圆表示，一个圆代表一条或多条语句
边：箭头线称为边，代表控制流
区域：由边和结点围成的面积 称为区域，当计算区域数时应该包括图外未被围起来的区域
判定结点：包含条件的结点

2.计算环形复杂度的方法:

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

在这里插入图片描述

3.环形复杂度的用途

程序的环形复杂度取决于程序控制流的复杂程度,即取决于程序结构的复杂程度。
当程序内分支数或循环个数增加时,环形复杂度也随之增加。
因此它是对测试难度的一种定量度量,也能对软件最终的可靠性给出某种预测。

第七章实现（编码和测试）

编码：把详细设计结果翻译成某种程序语言书写的程序
软件测试：是保证软件质量的关键步骤，是对软件规格说明、设计和编码的最后复审

7.1编码

7.1.2 编码风格

源程序代码的逻辑简明清晰，易读易懂，应遵循以下规则

程序内部的文档
数据说明
语句构造
输入输出
效率

7.2 软件测试基础

7.2.1 软件测试的目标和目的

目的是：尽可能多地发现并排除软件中潜藏的错误,最终把一个高质量的软件系统交给用户使用
目标：

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

7.2.2 软件测试准则

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

7.2.3 测试方法

黑盒测试（着重软件功能）
黑盒测试力图发现下述类型的错误:
(1) 功能不正确或遗漏了功能。
(2) 界面错误。
(3) 数据结构错误或外部数据库访问错误。
(4) 性能错误。
(5) 初始化和终止错误。
- 等价划分
- 边界值分析
- 错误推测
白盒测试（侧重数据测试）
- 逻辑覆盖
  - 语句覆盖
  - 判定覆盖
  - 条件覆盖
  - 判定 / 条件覆盖
  - 条件组合覆盖
  - 点覆盖
  - 边覆盖
  - 路径覆盖
- 控制结构测试
  - 基本路径测试
  - 条件测试
  - 循环测试

7.2.4 测试步骤

模块测试: (单元测试) 保证每个模块作为一个单元能正常运行。这个测试往往发现的是编码和详细设计的错误
子系统测试: 把经过模块测试的模块放在一起形成子系统来测试。这个步骤主要测试接口
系统测试: 把经过测试的子系统装配成一个完整的系统来测试。往往发现的是软件设计的错误
验收测试: (确认测试) 把系统作为单一的实体进行测试。目的是验证系统是否满足用户的需求,往往发现的是系统需求说明书的问题
平行运行: 就是同时运行新开发出来的系统和将被它取代的旧系统,以便比较两个系统的运行结果

7.2.5 测试阶段的信息流

软件配置：需求说明书，设计说明书，源程序清单
测试配置：测试计划，测试方案

7.3 单元测试

7.3.1 测试重点

模块接口
局部数据结构
重要的执行通路
出错处理通路
边界条件

7.3.2 代码审查

7.3.3 计算机测试

7.4 集成测试

渐增式测试（`目前主流`）

自顶向下集成
- 深度优先策略
- 广度优先策略
自底向上集成

非渐增式测试

7.5 确认测试

通常使用黑盒测试

Alpha 测试
Beta 测试

第八章维护

8.1 软件维护的定义

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

8.2 软件维护的特点

8.2.1 结构化维护和非结构化维护差别巨大

非结构化维护

如果软件配置的唯一成分是程序代码，那么维护活动从评价代码开始，而且由于内部文档不足而使评价更困难
非结构化维护需要付出巨大代价，是没有使用良好定义的方法学开发出来的必然结果
结构化维护

如果有一个完整软件配置存在，那么维护从评价设计文档开始就很规范

减少精力的浪费，提高维护的总体质量

8.2.2 维护的代码高昂

8.2.3 维护的问题很多

8.3 软件维护的过程

维护组织
维护报告
维护的事件流
保存维护记录
评价维护活动

8.4 软件的可维护性

决定软件可维护的因素：

可理解性
可测试性
可修改性
可移植性
可重用性

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

9.1.1 面向对象方法学要点：

基本原则：尽可能模拟人类习惯的思维方式，是开发软件的方法和过程尽可能接近人类认识的世界解决问题的方法和过程
4个要点
- 软件是由对象组成的，任何元素都是对象，复杂软件对向由比较简单的软件对象组成
- 所有对象都划分成对象类，类都定义了一组数据和一组方法
- 若干对象类组成一个层次的系统
- 对象间仅能通过传递消息互相联系

9.1.2 面向对象方法学优点

与人类习惯的思维方法一致
稳定性好
可重用性好
较易开发大型软件产品
可维护性好

9.2.1 对象：是描述该对象属性的数据以及对这些数据施加的所有操作封装在一起构成的统一体

对象的定义

对象是具有相同状态的一组操作的集合
对象是对问题域中某个东西的抽象
对象::=<ID,MS,DS,MI>。ID是对象的标识或名字，MS操作集合，DS数据结构，MI对象受理的消息名集合

对象的特点

以数据为中心
对象是主动
实现了数据的封装
本质上具有并行性
模块独立性好

其它概念

类：是一组具有相同属性和相同操作的对象的集合。
实例：由某个特定的类所描述的一个具体的对象。
消息：要求某个对象执行在定义它的那个类中所定义的某个操作的规格说明。组成部分：接收消息的对象；消息名；消息变元
方法：就是对象所能执行的操作，也就是类中所定义的服务。
属性：属性就是类中所定义的数据，它是对客观世界实体所具有的性质的抽象。
封装：对象封装了对象的数据以及对这些数据的操作。
继承：继承是子类自动地共享基类中定义的数据和方法的机制。
多态性：指子类对象可以像父类那样使用
重载：指在同一作用域内的若干参数特征不同的函数可以使用相同的函数名