软件工程期末复习
文章目录
- 一、软件工程概述
-
- 软件的概念与特点
- 软件危机与软件工程（概念）
- 软件开发过程
- 软件过程模型
-
- （一）瀑布模型
- （二）增量模型
- （三）螺旋模型
- （四）喷泉模型
- （五）原型模型
- 软件工程概述总结
- 二、软件需求工程
-
- 软件需求的基本概念
- 需求工程的基本活动
- 需求分析与建模技术（数据流图）
-
- （一）结构化分析（SA）方法
- （二）面向对象的分析（OOA）方法
- 软件需求工程总结
- 三、需求分析用例图
-
- 用例建模实例
- 四、面向对象分析与设计
-
- 静态模型
-
- （一）类图（举例POS机系统）
- 动态模型
-
- （一）状态图
- （二）顺序图
- 五、软件设计
-
- 软件设计阶段任务
- 软件设计过程
- 系统结构性模型——层次结构模型
- 模块分解
- MVC设计模式
- 六、软件测试
-
- 软件测试的基本概念
- 软件测试的特点和基本原则
- 白盒测试法
-
- （一）语句覆盖
- （二）判定覆盖
- （三）条件覆盖
- （四）判定-条件覆盖
- 黑盒测试法
-
- （一）等价分类法
- （二）边界值分析法
- 软件测试的概念
-
- （一）单元测试
- （二）集成测试
- （三）确认测试
- （四）系统测试
- 七、软件维护
-
- 软件维护的基本概念
一、软件工程概述
软件的概念与特点
软件 = 程序+数据+文档
软件是程序，以及开发、使用和维护程序所需的所有文档。
程序：计算机可以接受的一系列指令，运行时可以提供所要求的功能和性能。
数据：使得程序能够适当地操作信息的数据结构。
文档：描述程序的研制过程、方法和使用的图文资料。
特点：
- 复杂性
- 不可见性
- 一致性
- 可变性
软件危机与软件工程（概念）
软件危机： 反应在软件可靠性没有保障、软件维护工作量大、费用不断上升、进度无法预测、成本增长无法控制、程序、人员无限度地增加等各个方面，以至于形成人们难以控制软件开发的局面。
主要体现为两方面：
1.软件产品质量低劣，甚至在开发过程中就夭折。
2.软件生产效率低，无法满足需要。
软件工程：
- 将系统性的、规范化的、可定量的方法应用于软件的开发、运行和维护，即工程化应用到软件上；
- 对 1 中所述方法的研究。
目标： 提高软件的质量和软件的生产率。
软件工程三要素： 过程、方法、工具。
软件开发过程
软件开发过程： 问题定义–》需求开发–》软件设计–》软件构造–》软件测试–》软件维护
问题定义：
需求开发：
软件设计：
软件构造：
软件测试：
软件维护：
软件过程模型
定义： 是描述软件过程中各种活动如何执行的描述。
（一）瀑布模型
定义： 将基本的开发活动看成是一系列界限分明的独立阶段，这是一种计划驱动的软件过程，有利于规范软件开发活动。
以预测性为原则
以文档驱动开发过程
以过程控制为核心
特点：
- 活动间具有顺序性和依赖性；
- 推迟实现观点；
- 质量保证观点；
- 缺少对变化的适应;
适用范围：
瀑布模型适用于功能、性能明确、完整、无重大变化的软件系统的开发
（二）增量模型
定义： 在每一个新的发布中逐渐增加功能直到构造全部功能。
（三）螺旋模型
定义： 螺旋模型将瀑布模型与增量模型结合起来,并加入了风险分析。
特点：
- 瀑布模型+增量模型+风险分析
- 迭代过程
（四）喷泉模型
定义： 以用户需求为动力，以对象为驱动的模型，主要用于采用面向对象技术的软件开发项目。
其开发过程自下而上周期的各阶段是相互重叠和多次反复的，可以并行工作。
优点：
- 各个阶段没有明显的界限，开发人员可以同步进行开发
- 提高软件项目开发效率，节省开发时间
缺点：
由于各个开发阶段是重叠的，因此在开发过程中需要大量的开发人员，不利于项目的管理
（五）原型模型
定义： 原型是一个部分开发的产品，用于加强对系统的理解，有助于明确需求和选择可行的设计策略。
特点：
- 快速开发工具
- 循环
- 低成本
软件工程概述总结
二、软件需求工程
软件需求的基本概念
定义： 1)用户解决问题或达到目标所需条件或权能(Capability)。 (2)系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或权能。 (3)一种反映上面(1)或(2)所述条件或权能的文档说明。
软件需求的任务：
确定系统的综合要求 ：确定系统功能、性能和运行要求
分析系统的数据要求 ：数据要求和数据处理要求
导出系统的逻辑模型 ：采用结构化分析方法或面向对象分析方法导出系统逻辑模型
修正系统的开发计划 ：对系统成本和进度进行估算，进一步修改开发计划
需求工程的基本活动
- 获取需求
- 需求分析与建模
- 需求规格说明
- 确认需求
- 需求管理
软件需求的分类：
需求分析与建模技术（数据流图）
（一）结构化分析（SA）方法
定义： 其基本思想是用系统工程的思想和工程化的方法，根据用户至上的原则，自始自终按照结构化、模块化，自顶向下地对系统进行分析与设计。
描述方法：
- 数据流图(DFD图)
- 数据词典
- 加工逻辑说明
检查DFD图的正确性：
数据守恒
父图与子图的平衡
（二）面向对象的分析（OOA）方法
定义： 识别问题域内的对象,分析它们之间的关系,并建立起三类模型。
软件需求工程总结
三、需求分析用例图
用例建模实例
如：
某酒店订房系统描述如下：
(1) 顾客可以选择在线预订，也可以直接去酒店通过前台服务员预订；
(2) 前台服务员可以利用系统直接在前台预订房
(3) 不管采用哪种预订方式，都需要在预订时支付相应订金；
(4) 前台预订可以通过现金或信用卡的形式进行订金支付，但是网上预订只能通过信用卡进行支付；
(5) 利用信用卡进行支付时需要和信用卡系统进行通信；
(6) 客房部经理可以随时查看客房预订情况和每日收款情况。
参与者：
1、顾客
2、前台服务员
3、信用卡系统： 该订餐系统和信用卡系统有交互，所以说信用卡系统也是参与者。
4,、客房部经理
参与者用到了系统中的功能：
1、顾客：在线预订、通过信用卡进行支付
2、前台服务员：在前台预订房间、通过现金进行支付
3、信用卡系统：信用卡进行支付时需要和信用卡系统进行通信
4,、客房部经理：查看客房预订情况和每日收款情况
四、面向对象分析与设计
静态模型
（一）类图（举例POS机系统）
识别类–》识别属性–》识别类的操作–》识别类的关系–》建立交互图
POS机系统识别类的操作和类及属性
POS机系统类图示例
动态模型
（一）状态图
用来描述一个特定的对象所有可能的状态,以及由于各种事件的发生而引起的状态之间的转移和变化。
并不是所有的类都需要画状态图，有明确意义的状态，在不同状态下行为有所不同的类才需要画状态图。
例如学生请假管理系统：
（二）顺序图
顺序图直观地表示对象之间的行为关系以及操作和消息的时序关系。
帮助分析人员对照检查用例中描述需求，是否已经落实给具体对象去实现
提醒分析人员去补充遗漏的对象类或操作
帮助分析人员识别哪些对象是主动对象
通过对一个特定的对象群体的动态方面建模，深入地理解对象之间的交互
例如：
五、软件设计
软件设计阶段任务
将分析阶段获得的需求说明转换为计算机中可实现的系统。包括：
- 软件体系结构的设计
- 用户界面的设计
- 数据结构的设计
- 算法的设计
软件设计过程
大体分为如下活动：
- 软件体系结构的设计
- 抽象说明书
- 接口设计
- 构件设计
- 数据结构设计
- 算法设计
系统结构性模型——层次结构模型
层次结构模型将系统划分为若干层次，每个层次提供相应的服务，并且下层的服务只向它的直接上层提供。
这种结构非常适合增量的软件开发，新增加的部分将位于原有的系统之上或将原系统包裹起来，进而扩展了原系统的功能。
模块分解
目的： 将系统“分而治之”，以降低问题的复杂性，使软件结构清晰，便于阅读和理解，易于测试和调试，因而有助于提高软件的可靠性。
MVC设计模式
优点：
- 可以为一个模型在运行时同时建立和使用多个试图。
- 视图与控制器的可接插性。
- 模型的可移植性。
不足：
- 增加了系统结构和实现的复杂性。
- 视图与控制器间的过于紧密的连接。
- 视图对模型数据的低效率访问。
- 目前，一般高级的界面工具或构造器不支持MVC模式。
六、软件测试
软件测试的基本概念
定义： 使用人工或自动手段，来运行或测试某个系统的过程。
目的： 检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别。
软件测试的特点和基本原则
特点：
- 软件测试的开销大
- 不能进行“穷举”测试
- 软件测试难度大
基本原则：
- 应尽早地和不断地进行软件测试。
- 开发人员应尽量避免进行软件测试。
- 关键是注重测试用例的选择。
- 充分注意测试中的群集现象。
- 避免测试的随意性，严格执行测试计划
- 妥善保存测试过程中的一切文档，为软件维护提供方便。
白盒测试法
定义： 允许测试人员利用程序内部的逻辑结构及有关信息，设计或选择测试用例，对程序所有逻辑路径进行测试。
（一）语句覆盖
定义： 程序中的每个可执行语句至少被执行一次。
（二）判定覆盖
定义： 程序中每个判断的取真和取假分支至少经历一次，即判断真假值均被满足。
（三）条件覆盖
定义： 每个判断中每个条件的可能取值至少满足一次。
（四）判定-条件覆盖
定义： 判断中所有条件的可能取值至少执行一次，且所有判断的可能结果至少执行一次。
黑盒测试法
定义： 完全不考虑程序内部的逻辑结构和内部特性，只依据程序的需求规格说明书，检查程序的功能是否符合它的功能说明。
（一）等价分类法
定义： 等价类划分是将输入域划分成尽可能少的若干子域，在划分中要求每个子域两两互不相交，每个子域称为一个等价类。
等价类类型：
- 有效等价类是对规格说明有意义、合理的输入数据构成的集合，能够检验程序是否实现了规格说明中预先规定的功能和性能。
- 无效等价类是对规格说明无意义、不合理的输入数据构成的集合，以检查程序是否具有一定的容错性。
例如：
（二）边界值分析法
定义： 是对输入或输出的边界值进行测试的一种方法，它通常作为等价类划分法的补充，这种情况下的测试用例来自等价类的边界。
基本思想： 故障往往出现在程序输入变量的边界值附近边界值分析法是基于可靠性理论中称为“单故障”的假设，即有两个或两个以上故障同时出现而导致失效的情况很少。
先确定边界： 通常输入或输出等价类的边界就是应该着重测试的边界情况。选取正好等于、刚刚大于或刚刚小于边界的值作为测试数据，而不是选取等价类中的典型值或任意值。
软件测试的概念
（一）单元测试
定义： 单元测试（Unit Testing）是对软件中的最小可测试单元进行检查和验证。
（二）集成测试
定义： 在单元测试的基础之上，将所有模块按照设计要求组装成一个完整的系统而进行的测试
（三）确认测试
定义： 验证系统的功能、性能等特性是否符合需求规格说明。
（四）系统测试
定义： 验证系统中每个部分均已得到正确的集成，并能完成指定功能。
- 功能测试
- 性能测试
- 安全测试
- 恢复测试
- 强度测试
- 文档测试
七、软件维护
软件维护的基本概念
软件维护 是软件被投入运行使用后人们对软件产品所进行的修改，变更通常是修改现有的组件或增加新的组件，一般不涉及体系结构的重大变化。
维护类型：
- 纠错性维护：修改软件缺陷或不足
- 适应性维护：修改软件使其适应不同操作环境，主要包括硬件变化、操作系统变化或者其他支持软件变化等
- 完善性维护：增加或修改系统功能，使其适应业务的变化
- 预防性维护：对需要维护的软件或软件中的一部分进行重新设计、编码和测试
特性：
- 时间长、工作量大、成本高
- 维护的副作用
- 源代码、数据和文档的副作用
- 软件维护困难
- 读懂别人程序困难
- 软件维护工作难出成果
- 文档的不一致性
- 软件开发人员和软件维护人员时间上的差异