软件工程期末考点

  • Post author:
  • Post category:其他


参考教材:《软件过程导论(第六版)》张海藩 牟永敏 清华大学出版社

参考资料:合肥工业大学wkw老师PPT(文中图片来自PPT)

在这里插入图片描述

在这里插入图片描述

文章目录



Chapter 1 概述



软件定义

  • 多种术语和对象的组合,并将这些术语和对象有效的配置在一起
  • 程序 + 文档 + 数据



软件工程

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



软件特点

  • 软件是被工程化的逻辑结构
  • 软件一般没有磨损
  • 软件具有不同于一般实体系统的复杂性



软件危机



定义

  • 这些问题不是在解决具体问题时遇到的,而是软件开发过程中面临的具有普适性的问题
  • 在计算机软件开发和维护过程中遇到的一系列严重问题
  • 概括来说,就是开发周期长、成本高、质量差、适应性差和难维护四大难题



产生原因

  • 与软件本身的特点有关
  • 软件开发和维护的方法不正确
  • 在软件开发的不同阶段进行修改需要付出的代价逐渐增高



软件工程方法学



软件工程方法学三要素

  • 方法:完成软件开发的各项任务的技术方法
  • 工具:软件工程的支撑环境
  • 过程:规定了完成各项任务的过程



分类

  • 传统方法学
  • 面向对象方法学
  • 面向方面的软件开发方法
  • 面向组件的软件工程方法



软件生命周期

三个阶段、七个环节

  • 软件定义阶段




    \bullet












    问题定义




    \bullet












    可行性研究




    \bullet












    需求分析

  • 软件开发阶段




    \bullet












    概要设计




    \bullet












    详细设计




    \bullet












    编码和单元测试




    \bullet












    综合测试

  • 软件维护阶段



Scrum



概念

Scrum是以经验性过程控制理论作为理论基础的过程。Scrum采用迭代、增量的方法来优化可预见性并控制风险



Scrum模型的框架图

Scrum是一个轻量级的项目管理框架,


它的核心在于迭代



在这里插入图片描述



Scrum三大特点

  • “可能性的”艺术
  • 团队自组织、自管理
  • 面对面沟通



Scrum框架



Scrum团队模型(三种角色)

  • Scrum Master
  • Product Owner
  • Scrum Team



Scrum三种工件

  • 产品Backlog
  • Sprint Backlog
  • 产品增量



Scrum过程模型(5个活动+1个合约)

  • 迭代计划会议
  • 迭代合约
  • 回顾会议
  • 每日站立会议
  • 迭代
  • 迭代评审会议



Chapter 2 可行性研究



可行性研究



目的

  • 用最小的代价在尽可能短的时间内确定问题能否解决
  • 注意:不是为了解决问题,而是确定问题能否解决



任务

  • 技术可行性:使用现有的技术能实现该系统吗?
  • 经济可行性:这个系统的经济效益能超过它的开发成本吗?
  • 操作可行性:系统的操作方式在这个用户组织内行得通吗?



数据流图DFD

知识点知道了解就可以了,主要是学会画图



定义

数据流图是一种图形化技术,描述信息流和数据从输入移动到输出的过程中所经受的变换



符号

  • 正方形:数据的源点或终点
  • 圆角矩形:变换数据的处理
  • 开口矩形:数据存储
  • 箭头:数据的流动方向



层次结构的数据流图



编写数据流图的步骤

1、最高抽象层

  • 任务: 抽取数据的源点和终点
  • 处理顺序:(1)抽取数据的源点和终点信息;(2)抽取加工点的信息;(3)考虑数据流和数据存储信息

    2、细化处理
  • 任务:进一步分解数据流图的加工、数据流和存储信息
  • 处理顺序:(1)分析上层加工点的信息、细化加工点信息;(2)分析数据流和数据存储信息,细化数据流和数据存储信息;(3)对加工点、数据流和数据存储进行多层次的优化



绘制准则

  • 细化结束准则:当涉及到如何具体实现一个功能时就不应该再细化了
  • 细化一致性准则:当把一个处理细化为一些处理时,细化前后的数据流必须相同
  • 层次编号准则:对数据流图中的元素进行编号处理时应能够反映出元素的层次和分解关系
  • 数据分解简化性原则:数据流图中的元素不能太多,若太多就需要进行分层描述处理



创建数据流图的方法



语法分析方法:
  • 通过对软件需求的文本描述的分析,选取出其中的动词和名词
  • 动词为应用中的加工过程描述
  • 名词描述外部实体(方框)、数据或控制对象(箭头)、或数据存储(双线表示)


PPT例子

在这里插入图片描述

在这里插入图片描述

在这里插入图片描述

在这里插入图片描述

在这里插入图片描述



习题

在这里插入图片描述

在这里插入图片描述

在这里插入图片描述

在这里插入图片描述

在这里插入图片描述



数据字典



定义

数据字典是关于数据的信息的集合,也就是对数据流图中包含的所有元素的定义的集合



内容

  • 数据流
  • 数据流分量
  • 数据存储
  • 处理



例子

在这里插入图片描述

在这里插入图片描述




Chapter 3 需求分析



面向过程的需求分析

参考链接:

面向过程的分析



三类模型

  • 数据模型

    主要采用ER图描述,描述数据对象及数据对象之间的关系
  • 功能模型

    主要采用数据流图描述,描述当数据在条件系统中移动时被变换的逻辑过程,执行系统具有的变换数据的功能
  • 行为模型

    采用状态转换图描述,指明了作为外部事件结果的系统行为



实体联系图



作用

描绘数据对象及数据对象之间的联系



内容

  • 数据对象

    可由一组属性来定义的实体都可以被认为是数据对象
  • 数据对象的属性
  • 数据对象之间的关系

    联系的方式:一对多;多对多;一对多



建立ER图的过程

  • 第一层:提取所有对象和对象之间的关系
  • 第二层:建模它们之间的关系的整体模型
  • 第三层:进一步描述所有实体、关系的属性信息



数据流图

参考Chapter 2




Chapter 5 总体设计



总体设计

  • 基本目的

    回答“系统如何实现”的问题
  • 重要任务

    设计软件的结构,也就是确定系统中每个程序是由哪些模块组成的,以及这些模块之间的联系



设计原理



模块化

模块的三个基本要素:

  • 功能:描述该模块实现什么功能
  • 逻辑:描述模块内部怎么做
  • 状态:该模块使用时的环境和条件



抽象



逐步求精



信息隐藏和局部化

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



模块独立



模块独立性



概念

指软件系统中每个模块只涉及软件要求的具体的子功能,而和软件系统中其他的模块的接口是简单的



模块独立的重要性
  • 有效的模块化的软件比较容易开发出来
  • 独立的模块比较容易测试和维护


衡量模块独立性的标准
  • 耦合(模块间)
  • 内聚(模块内)



耦合



定义

耦合是模块之间的互相连接的紧密程度的度量



模块之间耦合的种类

在这里插入图片描述



设计原则
  • 尽量使用数据耦合
  • 少用控制耦合和特征耦合
  • 限制公共环境耦合的范围
  • 完全不用内容耦合



内聚



定义

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



模块内聚的种类

在这里插入图片描述



设计原则
  • 事实上,没必要精确确定内聚的级别
  • 设计时力争做到高内聚,并能够辨认出低内聚的模块
  • 有能力通过修改设计提高模块的内聚程度并降低模块间的耦合程度



启发规则

  • 改进软件结构提高模块独立性

  • 模块规模应适中

  • 深度、宽度、扇出和扇入都应适当

    尽可能减少高扇出结构,随着深度增大扇入

    补充:

    (1)扇出:一个模块被其他模块调用的个数

    (2)扇入:一个模块调用其他模块的个数

  • 模块的作用域应在控制域内

    作用域:受该模块内一个判定影响的所有的模块的集合

    控制域:模块本身以及所有直接或间接从属于它的模块的集合

  • 力争降低模块接口的复杂程度

  • 设计单入口单出口的模块

  • 模块功能应可以预测



总体设计



总体设计阶段的基本目的

  • 用比较抽象概括的方式确定系统如何完成预定的任务
  • 即应该确定系统的物理配置方案,并进而确定组成系统的各个程序的结构



总体设计阶段的组成

  1. 进行系统设计,从数据流图出发,设想完成系统功能的若干种组合的物理方案,最终确定最佳方案
  2. 进行软件结构设计,确定软件由哪些模块组成,以及这些模块间的动态调用关系



Chapter 6 详细设计



详细设计



根本目标

确定应怎样具体的实现所要求的系统,得出对目标系统的精确描述



任务

设计出程序的“蓝图”



详细设计

  • 确定软件各个组成部分内的算法,以及各部分的内部数据组织
  • 选定某种过程的表达形式来描述各种算法
  • 进行详细设计的评审



结构程序设计



结构程序定义



经典定义

若一个程序的代码块仅仅通过顺序、选择、循环这三种基本控制结构进行连接,并且每个代码块只有一个入口和一个出口,则称这个程序是结构化的



更全面的定义

结构程序设计是尽可能少用GO TO语句的程序设计方法,最好仅在检测出错误时采用GO TO语句,而且应该总是使用前向GO TO 语句



结构化程序的三种基本控制结构

  • 顺序
  • 选择:IF-THEN-ELSE
  • 循环:DO-WHILE



过程设计的工具



判定表

判定表能清晰的表示复杂的条件组合与应做的动作之间的对应关系



组成

  • 左上部列出所有条件
  • 左下部是所有可能做的动作
  • 右上部是表示各种条件组合的一个矩阵
  • 右下部是和每种条件组合相对应的动作

判定表右半部分的每一列实质上是一条规则,规定了与特定的条件相对应的动作



举例

在这里插入图片描述

在这里插入图片描述



判定树

判定树是判定表的变种,能清晰的表示负责的条件组合与应做动作之间的对应关系



举例

在这里插入图片描述




Chapter 7 实现



软件测试

关于软件测试在“软件测试”这门课已经详细讲述了,可参考具体的课程内容



软件测试的原则

  • 所有的测试都应该能追溯到用户需求
  • 应该远在测试开始之前就指定出测试计划
  • 把Pareto原理应用到软件测试中(测试存在群集现象)
  • 应该从“小规模”测试开始,并逐步进行“大规模”测试
  • 穷举测试是不可能的

PPT补充

  • 为了达到最佳的测试结果,应由独立的第三方从事测试工作
  • 应当把“尽早的和不断地进行软件测试”作为软件开发者的座右铭
  • 测试用例应由测试输入数据和对应的预期输出结果组成
  • 在设计测试用例时,应当包括合理的输入条件和不合理的输入条件
  • 应当对每个测试结果做全面的检查
  • 妥善保存测试计划、测试用例、出错统计和最终分析报告,为维护提供方便



单元测试



说明

  • 单元测试是针对软件设计的最小单位——程序模块,进行正确性检验的测试工作
  • 单元测试和编码属于软件过程的同一个阶段
  • 可以应用人工测试和计算机测试两种不同类型的测试方法进行单元测试
  • 单元测试主要使用白盒测试技术,且对多个模块的测试可以并行进行



测试重点

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



代码审查

代码审查是指由审查小组正式对源程序进行人工测试



计算机测试

模块不是一个独立的程序,因此必须为每个单元测试开发驱动软件和存根软件

  • 驱动程序:是一个主程序,它接收测试数据,把这些数据传送给被测试的模块,并印出有关的结果
  • 存根程序“桩模块”:桩模块代替被测试的模块所调用的模块,它使用被它代替的模块的接口,可能做最少量的数据操作,印出对入口的检验或操作结果,并把控制归还给调用它的模块



白盒测试



逻辑覆盖

  • 语句覆盖:选择足够多的测试样例,使被测程序中每个语句至少执行一次
  • 判定覆盖:不仅每个语句必须至少执行一次,而且每个判定的每种可能的结果都应该至少执行一次
  • 条件覆盖:不仅每个语句至少执行一次,而且使判定表达式中的每个条件都取到各种可能的结果
  • 判定/条件覆盖:选取足够多的测试数据,使得判定表达式中的每个条件都取到各种可能的值,且每个判定表达式也都取到各种可能的结果
  • 条件组合覆盖:选取足够多的测试数据,使得每个判定表达式中条件的各种可能组合都至少出现一次
  • 点覆盖:点覆盖标准和语句覆盖标准是相同的
  • 边覆盖:通常边覆盖和判定覆盖是一致的
  • 路径覆盖:选取足够多的测试数据,使得程序的每条可能的路径都至少执行一次(若程序图中有环,则要求每个环至少经过一次)



控制结构测试



基本路径测试



步骤
  • 根据过程设计结果画出相应的流图

    在这里插入图片描述
  • 计算流图的环形复杂度
  • 确定线性独立路径的基本集合
  • 设计可强制执行基本集合中每条路径的测试用例



条件测试



循环测试



黑盒测试



等价划分

  • 把程序的输入域划分为若干个数据类,据此导出测试用例
  • 一个理想的测试用例能独自发现一类错误



边值分析



错误推测法



软件调试



调试

  • 调试作为成功测试的后果出现,是在测试返现错误之后排除错误的过程
  • 软件错误的外部表现和内在原因之间可能没有明显的联系。调试就是把症状和原因联系起来的尚未被人深入认识的智力过程



过程

从执行一个测试用例开始,评估测试结果,若发现实际结果与预期结果不一致,则这种不一致就是一种症状,它表明在软件中存在隐藏的问题。调试过程试图找出产生症状的原因,以便改正错误



调试途径

  • 蛮干法
  • 回溯法
  • 原因排错法

    对分查找法

    归纳法

    演绎法



Chapter 8 维护

这章考点比较少



软件维护的定义

在软件已经交付使用后,为了改正错误或满足新需要而修改软件的过程



包括

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



Chapter 9 面向对象方法学引论



重点!面向对象和面向过程的比较



计算机处理的实体对象

  • 面向对象方法

    对象指数据以及可施加在这些数据上的操作所构成的统一体

    类 = 数据 + 行为

  • 结构化方法

    是各种预定义类型的变量、数组、记录和文件等数据描述

    模块 = 数据 + 部分行为



计算机处理对象的操作

  • 面向对象方法:通过消息驱动对象主动地执行自身的数据处理行为
  • 结构化方法:通过对象传送,并调用外部的处理功能来处理对象



处理观点上不同

  • 面向对象方法:把程序看做是相互协作而又彼此独立的对象的集合。每个对象就是一个微型的程序,有自己的数据、操作、功能和目的
  • 结构化方法:看做是工作在数据之上的一系列过程或函数的集合



通讯机制

  • 面向对象方法:消息的传递
  • 结构化方法:模块调用和参数的传递



思维的特点

  • 面向对象方法

    1.使用现实世界的概念抽象的思考问题,从而自然的解决问题

    2.强调模拟现实世界中的概念,而不强调算法

    3.重点针对需要处理的问题进行分析

  • 结构化方法

    1.以算法为核心,把数据和过程作为相互独立的部分,数据代表问题空间中的客体,程序代码则用于处理这些数据

    2.这种思维方式和计算机处理问题的方法是一致的



软件开发过程的特点

  • 面向对象方法: 重点强调反映现实需求的对象业务模型的建立,相对而言设计和编码部分的工作则较为次要
  • 结构化方法:重点在软件处理过程的设计和实现上



使用范围比较

  • 面向对象方法:适用于比较大型的应用
  • 结构化方法:对于要求设计底层处理的应用或需要较高处理效率直接对硬件系统进行操作的系统比较适用



一般特点比较

  • 面向对象方法:稳定、可重用、易维护;但执行效率低
  • 结构化方法:执行效率高,但难维护



两种方法的交互性

  • 面向对象方法:是在传统软件过程方法上发展起来的一种新方法,许多传统的软件工程方法在面向对象的分析上也同样起作用
  • 结构化方法:在面向对象的设计中还存在一些不可消除的作用,当前提出的面向方面的设计就是这种作用的体现



软件过程



喷泉模型



RUP模型



各阶段里程碑

  • 初始阶段:生命周期目标里程碑
  • 细化阶段:生命周期结构里程碑
  • 构造阶段:初始运行能力
  • 交付阶段:产品发布里程碑



说明

  • 每个阶段结束于一个主要的里程碑
  • 在每个阶段结尾执行一次评估以确定这个阶段的目标是否已经满足



对象模型

通常使用UML提供的类图来建立对象模型



类图



定义

  • 描述类及类与类之间的静态关系
  • 是一种静态模型,是创建其他UML图的基础



类图的基本符号

类名 + 属性 + 服务



表示关系的符号

类与类之间通常有关联、泛化、依赖、细化四种关系



动态模型

状态图



功能模型



用例图



例子

在这里插入图片描述



系统

  • 系统被看做是一个提供用例的黑盒子
  • 边框表示系统的边界,用于划定系统的功能范围



行为者



用例

  • 一个用例是可以被行为者感受到的、系统的一个完整性的功能
  • 在UML 中把用例定义为系统完成的一系列动作,动作的结果能被特定的行为者觉察到



Chapter 10 面向对象分析



面向对象设计



三类模型

  • 对象模型(静态结构)
  • 动态模型(交互结构)
  • 功能模型(数据变换)



五个层次

  • 主题层
  • 类与对象层
  • 结构层
  • 属性层
  • 服务层



软件重用



定义

重用也叫再用或复用,指同一实物不作修改或稍加修改就多次重复使用



分为三个层次

  • 知识重用
  • 方法和标准重用
  • 软件成分的重用



软件成分的重用级别

  • 代码重用

    源代码剪贴

    源代码包含

    继承
  • 设计结果重用

    重用某个软件系统的设计模型
  • 分析结果重用

    重用某个系统的分析模型



典型的10中可重用软件成分

  • 项目计划
  • 成本估计
  • 体系结构
  • 需求模型和规格说明
  • 设计
  • 源代码
  • 用户文档和技术文档
  • 用户界面
  • 数据
  • 测试用例



版权声明:本文为qq_45800517原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。