「软件工程」期末复习
本文最后更新于：2023年4月15日 晚上
1 | 软件工程概述
1.0 | 考点
考题
- 软件的定义(2019)
- 什么是软件危机, 软件危机的表现及原因(2020)
- 软件工程生命周期及各阶段工作(2020, 2019)
1.1 | 知识点
软件
软件的定义: 文档加程序
软件危机
含义: 在计算机软件开发和维护过程中遇到的一系列严重问题
- 如何开发软件(怎样满足软件日益增长的需求)
- 如何维护数量不断膨胀的已有软件
具体表现:
- 对软件开发成本和进度的估计不准确
- 用户对「已完成的」软件不满意
- 软件质量不可靠
- 软件不可维护
- 没有合适的文档资料
- 软件成本上升
- 软件开发速度跟不上计算机普及的趋势
产生软件危机的原因:
- 软件本身的特点
- 软件开发与维护的方法不正确
- 忽略软件需求分析的重要性
- 忽视软件文档的重要性
解决软件危机的途径:
- 完整的配置组成(程序, 数据, 文档)
- 良好的组织管理
- 成功的技术方法
- 更好的软件工具
软件工程
软件工程的生命周期和各阶段的基本任务:
软件定义阶段: 1-3 软件开发阶段: 4-7 运行维护阶段: 8
- 问题定义 -> 确定要解决的问题
- 可行性研究 -> 估计工程规模与目标, 估计系统成本和效益
- 需求分析 -> 确定目标系统必须完成的工作
- 总体设计 -> 考虑不同的解决方案
- 详细设计 -> 将解决方案具体化
- 编码和单元测试 -> 将详细设计的结果翻译成程序, 测试编写的每个模块
- 综合测试 -> 通过各种类型的测试使软件达到预定的要求
- 软件维护 -> 通过必要的维护活动使系统持久地满足用户需求
软件开发模型:
- 瀑布模型 (将软件生存周期的各项活动规定为按固定顺序而连接的若干阶段工作)
- 快速原型模型 (快速构建一个可在计算机上运行的原型系统, 获取「用户反馈」)
- 螺旋模型 (快速模型的基础上增加了风险分析过程)
- 敏捷过程和极限编程 (大项目拆分成可独立运行的小项目)
- 微软过程 (计划->构想->开发->稳定->发布 「循环进行」)
2 | 可行性研究
2.0 | 考点
可行性分析的四个方面
数据流图的绘制
2.1 | 知识点
可行性分析的四个方面
- 经济可行性
- 法律可行性
- 技术可行性
- 操作可行性
数据流图
概念:
- 数据流图描绘系统的逻辑模型
- 图中没有物理元素, 只是描绘信息在系统中流动和处理情况
- 考虑系统必须完成的基本逻辑功能而不需要考虑如何实现
DFD分层数据流图
分层DFD的例子:
数据字典
定义:
数据字典是关于数据的信息的集合, 也就是对数据流图中包含的所有元素的定义的集合
关系:
数据流图和数据字典共同构成系统的逻辑模型
组成:
数据字典由对下列四类元素的定义组成:
- 数据流
- 数据流分量 (数据元素)
- 数据存储
- 处理
3 | 需求分析和项目管理
需求分析的三个基本活动: (张)
- 获取和理解用户需求
- 描述和分析用户需求
- 对用户需求进行评审
需求分析的任务: (姚)
- 确定对系统的综合要求
- 分析系统的数据要求
- 导出系统的逻辑模型
- 修改系统的开发计划
软件需求内容:
graph TD
A[软件需求]-->用户需求
A-->B[系统需求]
B-->功能需求
B-->非功能需求
B-->领域需求
结构化分析方法:
利用数据流图来帮助理解问题, 对问题进行分析, 基于功能分析和数据分析, 将功能和数据分离, 当系统进行变化时, 系统维护困难
面向对象方法:
类和对象, 与人类思维方法一致, 稳定性可重用性可维护性可扩展性好
结构化分析主要针对数据处理领域, 而面向对象分析方法主要适用于以控制为主的系统
4 | 形式化说明技术
4.0 | 考点
- 形式化, 半形式化, 非形式化的概念, 简述各自的优缺点
形式化, 非形式化和半形式化
用自然语言描述需求规格说明, 是典型的非形式化方法
用数据流图或实体-联系图建立模型, 是典型的半形式化方法
所谓形式化方法, 是描述系统性质的基于数学的技术
5 | 总体设计
5.0 | 考点
- 模块独立性的两个度量概念, 并指出设计原则及其内容
- 六种耦合
- 七种内聚
- 结构化设计的启发式规则(了解)
- 数据流图->软件结构图
模块独立性度量的两个概念
- 耦合->模块间依赖程度
- 内聚->模块内各元素结合紧密程度
六种耦合
由上到下耦合程度依次增加
- 非直接耦合(完全独立)
- 数据耦合
- 控制耦合
- 特征耦合
- 公共环境耦合
- 内容耦合
尽量使用非直接耦合, 少用数据耦合和控制耦合, 限制公共环境耦合的使用范围, 完全不用内容耦合
七种内聚
由上到下内聚程度依次减小
- 功能内聚
- 顺序内聚
- 通信内聚
- 过程内聚
- 时间内聚
- 逻辑内聚
- 偶然内聚
高内聚: (功能内聚, 顺序内聚)
中内聚: (通信内聚, 过程内聚)
低内聚: (时间内据, 逻辑内聚, 偶然内聚)
结构化设计的启发式规则
(知道启发式规则是什么)
启发规则：
- 改进软件结构提高模块独立性
- 模块规模应该适中
- 深度、宽度、扇出和扇入都应适当
- 模块的作用域应在控制域之内
- 力争降低模块接口的复杂程度
- 设计单入口单出口的模块
- 模块功能应该可以预测
数据流图->软件结构图
- 变换流
- 事务流
6 | 详细设计
6.0 | 考点
绘制程序流程图, 程序流程图转化为PAD图和NS图
程序流程图:
NS图(盒图):
PAD图:
7 | 编码和单元测试
7.0 | 考点
- 软件测试按阶段的划分, 每个阶段测试内容, 用到的技术, 参与人员 (单元测试->集成测试->验收测试(确认测试))
- 白盒测试的几种覆盖 (必考) (五种覆盖 + 基本路径测试)
- 黑盒测试等价类划分, 边界分析
| 测试阶段 | 人员 | 方式 | 要求 |
|---|---|---|---|
| 单元测试 | 开发小组 | 白盒测试 | 模块高内聚, 功能实现的一致性和正确性 |
| 集成测试 | 独立测试小组 | 白盒测试, 黑盒测试 | 模块组件一起工作正常, 可以集成为完整的系统 |
| 验收测试(确认测试) | 用户 | 黑盒测试 | 向用户表明系统能满足要求 |
白盒测试
考点: 语句覆盖, 判定覆盖, 条件覆盖, 判定/条件覆盖, 条件组合覆盖 + 基本路径测试
基本路径测试: 每条语句执行一次 + 每个判定都取T和F两种情况
8 | 软件维护
- 改正性维护：诊断和改正错误的过程
- 适应性维护：为了和变化了的环境适当地配合而进行的修改软件的活动
- 完善性维护：为了满足增加新功能或修改已有功能的要求和一般性的改进要求
- 预防性维护：主动性维护(唯一的主动维护)
9 | 面向对象设计
9.0 | 考点
- 用例图, 类图, 对象图
- 面向对象设计的原则: 模块化, 抽象, 信息隐藏, 弱耦合, 强内聚, 可重用
用例图:
类图:
classDiagram
Animal <|-- Duck
Animal <|-- Fish
Animal <|-- Zebra
Animal : +int age
Animal : +String gender
Animal: +isMammal()
Animal: +mate()
class Duck{
+String beakColor
+swim()
+quack()
}
class Fish{
-int sizeInFeet
-canEat()
}
class Zebra{
+bool is_wild
+run()
}
对比面向对象设计和结构化设计的启发式规则
| 设计 | 启发式规则 |
|---|---|
| 面向对象设计 | 1. 设计结果应该清晰易懂 2. 一般-特殊结构的深度应适当 3. 设计简单的类 4. 使用简单的协议 5. 使用简单的服务 6. 把设计变动减至最小 |
| 结构化设计 | 1. 改进软件结构提高模块独立性 2. 模块规模应该适中 3. 深度、宽度、扇出和扇入都应适当 4. 模块的作用域应在控制域之内 5. 力争降低模块接口的复杂程度 6. 设计单入口单出口的模块 7. 模块功能应该可以预测 |
押题
六道简答题, 每道6分 = 36
两道大题
简答题押题
- 软件的定义
- 软件生命周期 (必)
- 软件危机的定义, 表现, 产生原因
- 软件可行性分析四个方面
- 模块独立性的两个度量, 设计原则和具体内容 (必)
- 面向对象设计原则
- 测试步骤和每个阶段测试工作内容
- 四种软件维护
- 面向对象设计和结构化设计的区别
大题押题
- 数据流图设计
- 数据流图转软件结构图
- 白盒测试用例设计(六种覆盖, 基本路径测试)
- 流程图, PAD图, NS图之间的转换
- 用例图和类图的绘制
- 环形复杂度的计算