《软件工程》复习总结

第二章:可行性研究

数据流图和数据字典 P40 P47

数据流图完成功能的需求,数据字典完成数据定义

画数据流图要注意哪些事项?
答:1.设计数据流图时只需考虑系统必须完成的基本逻辑功能,不需要考虑怎样具体的实现
这些功能。
2.从顶层数据流开始。
3.并不是所有数据存储和数据流都能直接从问题描述中提取出来;
4.当进一步分解将涉及如何具体地实现一个功能时,就不应该在分解了;
5.数据流图中个成分的命名要仔细推敲,看是否恰当;

1546826407679


1546827141760


数据字典:名字、别名、描述、定义、位置

定义中,=(是)、[ A|B ](A或B)、1{A}5(A重复1到5次)、A+B(A和B)、(A)(A可选)

1546826346837

第三章:需求分析阶段

结构化分析方法:面向数据流自顶向下逐步求精进行需求分析的方法

快速建立软件原型

E-R模型

状态图(状态转换图) P66

注意:初态是实心圆,终态是同心圆(内部实心圆),中间状态是圆形框

1546826778046

P69 IPO图

1546826913687

• 左边框中列出有关的输入
• 中间框中列出主要的处理
• 右边框中列出产生的输出
处理的顺序暗示了执行的顺序
• 箭头指出数据通信的情况

第五章:总体设计(系统设计阶段、结构设计阶段)

层次图和 HIPO 图(H图,带标签的层次图) P103

通常用层次图作为描述软件结构的文档

1546827667395

如图是HIPO图,去掉数字是层次图

数据流图转成软件结构图

软件结构图可在层次图基础上,在方框间加入箭头代表模块的调用关系

箭头尾部空心圆表示传递的是数据,实心圆表示传递的是控制信息


模块独立性:耦合、内聚 P97

低【数据耦合】、中【控制耦合、特征耦合、公共环境耦合】、高【内容耦合】

尽量用数据耦合,少使用控制、特征耦合,限制公共环境耦合的范围,不用内容耦合

低内聚【偶然内聚、逻辑内聚、时间内聚】、中内聚【过程内聚、通信内聚】、高内聚【顺序内聚、功能内聚】

耦合越低、内聚越高,独立性越好

第六章:详细设计

判定表和判定树 P127 、129

1546829101200

这是判定树(判定表的变种)

1546829150554

程序流程图和盒图 P125

程序流程图要区分 while-dodo-until两种,还有case语句图

1546828721769

下面是盒图:

盒图

依据伪码(PDL)画出流图,并计算复杂度 P138(以及控制结构测试中求出流图的独立路径) P166

流图有的地方也叫控制流图、程序图

McCabe方法

复杂度是E-N+2(边数-点数+2)

1546829371774

1546829617473

上面这个是判定a OR b

第七章:软件实现与测试

编码和测试统称为实现

软件测试在软件生命周期中横跨两个阶段:开发中的开发者进行的单元测试(编码和单元测试属于软件生命周期的同一阶段),专门测试人员负责的综合测试

测试是发现错误,最终目的是调试(诊断并改正错误,发生在测试之后)

调试方法:蛮干法、回溯法、原因排除法

可靠性模型

软件可靠性是程序在给定的 时间间隔内 ,按照规格说明书的规定成功地运行的概率

软件可用性是程序在给定的 时间点 ,按照规格说明书的规定,成功地运行的概率

应同时使用可靠性和可用性衡量

测试方法:黑、白盒测试

  • 黑盒测试又称功能测试,在程序接口进行的测试。按照规格说明书的规定功能是否有效,能否适当接收数据产生正确信息
    • 主要技术:等价划分、边界值分析、错误推测
  • 白盒测试又称结构测试,检测程序内部逻辑结构是否正确
    • 主要技术:逻辑覆盖、控制结构测试

逻辑覆盖分为:语句覆盖、判定覆盖、条件覆盖、(判定条件覆盖、条件组合覆盖)、路径覆盖 【覆盖强度依次增强】

  • 语句覆盖是保证每个语句至少执行一次
    • 如下图所示,语句K,J都执行一次,只能选择数据组1、2
  • 路径覆盖是走过所有路径,测试用例可以覆盖程序中所有可能的执行路径

判定覆盖和条件覆盖的区别

  • 判定覆盖:不仅每个语句必须至少执行一次,而且每个判定的每种可能的结果都应该至少执行一次,也就是每个判定的每个分支都至少执行一次
  • 条件覆盖:类似判定覆盖,但是保证每个判定中的每个条件语句都可取到各种结果

1546701860223

对这里的条件覆盖为什么不能选8,因为第2、4组只能使得x<1取到一种结果

  • 判定-条件覆盖

1546849983561

  • 条件组合覆盖

1546849900736

Pareto原理:80%的错误很可能由20%的模块造成

测试应该从小规模开始,逐步进行大规模测试,不可能穷举测试

测试四步骤:

  • 单元测试:针对各个单独模块,采用白盒测试
  • 集成测试:各个模块集成一起形成完整软件包,同时测试。常用黑盒测试,也可使用部分白盒
    • 集成模块时,又分渐增式和非渐增式测试
    • 自顶向下集成
    • 自底向上集成
    • 回归测试( 回归测试 是指重新执行已经做过的测试的某个子集,以保证上述这些变化没有带来非预期的副作用)
  • 确认测试:仅使用黑盒测试,验证需求分析阶段确认的标准
  • 系统测试

软件测试包括哪些步骤?同时说明这些步骤的测试目的是什么?

答:(1)单元测试,目的是代码达到模块说明书的要求

(2)集成测试,目的是将经过单元测试的模块逐步组装成具有良好一致性的完整的程序

(3)确认测试,目的是确认程序系统是否满足软件需求规格说明书的要求

(4)系统测试,目的是检查能否与系统的其余部分协调运行,并且完成SRS对他的要求。

控制结构测试 P166 【这也是一种白盒测试方法】

分为 基本路径测试条件测试循环测试(包含简单、嵌套、串接循环三种)

  • 基本路径测试流程:
    1. 一般是根据伪码画出流图
    2. 求出流图复杂度
    3. 确定线性独立路径的基本集合 【独立路径数同复杂度值
      • 独立路径至少包含一条在定义该路径之前不曾用过的边
    4. 设计每条路径的测试用例

第八章:软件维护(生命周期最后一个阶段)

  • 改正错误
  • 满足新的需求

1546745763355

完善性维护占主要,其次是改正性、适应性维护

决定可维护性的因素:

  • 软件的可理解性、可测试性、可修改性
  • 文档描述符合要求、用户文档简洁明确、系统文档完整标准

第九章:面向对象分析

优点:

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

对象的特点:以数据为中心,实现了数据的封装,对象是主动的,并行性,模块独立性好

  1. 对象模型:类图 P218
  2. 动态模型:每个类用一张状态图(状态转换图)描述,状态图见3.6节,P66;事件跟踪图(时序图)
  3. 功能模型:使用 UML 中的用例图 P225

功能模型直接地反映了用户对目标系统的需求

描述系统静态结构的对象模型、描述系统控制结构的动态模型、以及描述系统计算
结构的功能模型。其中,对象模型是最基本、最核心、最重要的

用例图怎么画

1546760577001

扩展关系:向一个用例中加入一些新的动作后构成了另一个用例,这两个用例之间的关系就是扩展关系,后者通过继承前者的一些行为得来,通常把后者称为扩展用例

使用关系:当一个用例使用另一个用例时,这两个用例之间就构成了使用关系

类图怎么画

类图是静态模型,是构建状态图、协作图等基础

类图包括类的定义和类之间的关系

属性名和类型名必须有,其他操作部分根据需要可有可无

类的名字
属性
操作

属性用+-#分布表示public、private、protected

1546761260457

状态图怎么画

1546761428933

顺序图(时序图)怎么画

两个坐标轴,横坐标表示不同对象,纵坐标表示时间

1546763155022

事件跟踪图是简化的顺序图,下面这个是顺序图


考题

  • 由代码画出程序盒图,并求出环形复杂度
  • 给出一段文字,分析,然后画用例模型
  • 使用UML,画出类图
  • 画数据流图,给出说明
  • 白盒测试,黑盒测试,给出最小测试用例组

  • 数据流图—建立功能模型
  • 实体联系图(E-R)—建立数据模型
  • 状态图—建立行为模型
  • 测试阶段有关的文档——————需求规格说明书
  • 维护阶段的文档——————软件问题报告、概要设计说明书

(需求分析节点产生)需求规格说明书作用:

  1. 软件验收依据
  2. 软件设计依据
  3. 用户与开发人员对软件要做什么的共同理解

需求规格说明书主要组成部分:数据流图和数据字典【二者也共同构成了系统的逻辑模型】

  • 软件的生存周期一般分成哪几个阶段?
    答:三个时期:软件定义,软件开发,运行并维护。八个阶段:问题定义,可行性研究,需求分析,概要(总体)设计,详细设计,编码和单元测试,综合测试,运行维护
  • 分别叙述“瀑布模型”和“快速原型模型”的优缺点
    1. 瀑布模型:优点:可强迫开发人员采用规范的方法;严格的规定了每个阶段必须提交的文档;要求每个阶段交出的所有产品都必须经过质量保证小组的仔细验证。
      缺点:瀑布模型是文档驱动的。缺乏灵活性
    2. 快速原型模型:优点:软件产品的开发基本上是按线性顺序进行的。
      缺点:所选用的开发技术和工具不一定符合主流的发展; 快速建立起来的系统结构加上连续的修改可能会导致产品质量低下;

喷泉模型,”喷泉“体现了迭代和无缝特点。

瀑布模型关键不足在无法适应需求的动态变更(不适应用户的需求变更),因为是依赖文档的

快速动态模型可以有效地适应用户需求的动态变化

螺旋模型在瀑布模型和增量模型基础上增加了风险分析活动

软件详细设计主要采用方法:结构化程序设计

一般把数据流图中的数据划分为事务流和交换流

需求分析过程中无需确定软件系统运行的平台

非功能性需求,是指软件产品为满足用户业务需求而必须具有且除功能需求以外的特性。软件产品的非功能性需求包括系统的性能、可靠性、可维护性、可扩充性和对技术和对业务的适应性等

需求分析阶段分为四个方面:对问题的识别、分析与综合、编写需求文档、需求分析评审

程序的三种基本控制结构:顺序、条件、循环

软件工程三要素:方法、工具、过程

软件组成:程序、文档、数据

详细设计阶段所使用到的设计工具:程序流程图、PAD图、N-S图、HIPO图、判定树、判定表

软件生命周期中花费最多的阶段是:测试与维护阶段

度量可靠性的指标:成功运行的概率、平均故障时间

软件的风险分析包括 风险识别风险预测风险管理

通过软件测试未发现错误,并不一定代表软件是正确的

在可行性研究中最难决断和最关键的问题是技术可行性

类与对象的静态关系主要有 关联、聚集、泛化、依赖

  • 关联:
  • 聚集
  • 泛化
  • 依赖

数据字典主要由数据流描述、加工描述、文件描述组成,它对数据流图上每一个成分:数据项、文件(数据结构)、数据流、数据存储、加工和外部项等给以定义和说明

结构化设计的主要思想

  • 自顶向下、逐步求精的程序设计方法
  • 使用三种基本结构、单入单出口

面向对象设计准则包括:模块化、信息隐藏、抽象和逐步求精、低耦合、高内聚

软件可行性研究实质上是进行一次 简化、压缩的需求分析、设计过程

软件结构图的形态特征反映程序重用率的是 扇入

要显示描绘软件开发项目各作业的依赖关系,应选择( B )。

A. Gantt图 B.工程网络

C. COCOMO模型 D.数据流图

COCOMO模型 是成本估算方法

黑白盒测试都属于动态测试

系统流程图使用了描述系统物理模型的


有几个单词简写要了解DFD图(数据流图)、DD(数据字典)、PAD图、sc图(结构图)

SA(结构化分析方法)、SD(结构化设计方法)、SP(结构化程序设计方法)

觉得有帮助的话,不妨加个鸡腿,O(∩_∩)O哈哈~