跳至主要內容

软件工程-重点

yyshino大约 19 分钟

第一章 绪论

软件工程的定义:软件工程师用科学知识和技术来定义、开发、维护软件的一门学科

软件生命周期

软件生命周期:指软件产品从考虑其概念开始,到该软件产品不再使用为止的整个时期,一般包括概念阶段、分析与设计阶段、构造阶段、移交和运行阶段等不同时期。

软件生命周期模型

定义

软件生命周期模型:从一个特定角度提出的对软件过程概括描述,是对软件开发实际过程抽象,包括构成软件过程的各种活动软件工件以及参与角色等。

与开发方法的关系

种类

  • 瀑布模型:线性的整体化模型

  • 增量模型:非整体化的开放模型

  • 螺旋结构:风险驱动模型

  • 喷泉模型:以用户需求为动力的对象驱动模型

  • 基于知识的模型:是瀑布模型和知识的结合

  • 变换模型:形式化开发模型

  • 统一过程模型:基于统一建模语言的软件开发过程,它是用例驱动和风险驱动的,以构架为中心,采用迭代和增量的软件开发过程开发模型:面向对象的开发方法

1. 瀑布模型

image-20230505094410772
image-20230505094410772

瀑布模型:将软件生存周期的各项活动规定为依照固定顺序连接的若干阶段工作,最终得到 软件产品。

特点

  1. 阶段间具有顺序性和依赖性。
  2. 推迟实现的观点。
  3. 质量保证的观点
    • 每个阶段必须完成规定的文档;
    • 每个阶段结束前完成文档审查,
    • 及早改正错误。

瀑布模型优缺点:

1、瀑布模型的优点(强迫开发人员使用规范的方法,严格规定了每个阶段必须提交的文 档,要求每个阶段)

  • 可以强迫开发人员采用规范的方法;
  • 严格规定了每个阶段必须提交的文档;
  • 要求每个阶段交出的所有产品都必须经过质量保证小组的仔细验证。

2、瀑布模型的缺点

  • 在软件开发的初期阶段就要求做出正确、 全面、完整的需求分析对许多应用软件来说 是极其困难的。
  • 在需求分析阶段,当需求确定后,无法及时验证需求是否正确、完整。
  • 作为整体开发的瀑布模型,由于不支持产品的演化,缺乏灵活性,对开发过程中很难 发现的错误,只有在最终产品运行时才能暴露出来, 从而使软件产品难以维护

2. 增量模型

image-20230505094644540
image-20230505094644540

增量模型:先完成一个系统子集的开发,再按同 样的开发步骤增加功能 (系统子集),如 此递增下去直至满足全部系统需求。

增量模型优缺点:

优点:

  1. 短时间内可提交完成部分功能
  2. 逐渐增加产品功能,用户适应产品快。

缺点:

  1. 增量构件划分以及集成困难。
  2. 容易退化为边做边改模型。

3. 螺旋模型

image-20230505094813134
image-20230505094813134

简化的螺旋模型

image-20230505094948557
image-20230505094948557

螺旋模型:在每个阶段之前都增 加了风险分析 过程的快速原型模型。 看作增加了风险分析 的快速原型模型。

螺旋模型优缺点: 优点:

  1. 利于把软件质量作为软件 开发目标。
  2. 减少测试
  3. 维护和开发不分开

缺点:

  1. 风险估计困难

4. 喷泉模型

image-20230505095441036
image-20230505095441036

改进的喷泉模型

image-20230505095518806
image-20230505095518806

喷泉模型:典型的面向对象软件过程模型。 体现迭代和无缝的特性。

5. 基于知识的模型

image-20230505095801703
image-20230505095801703

6. 变换模型

image-20230505095905166
image-20230505095905166

第二章 软件要求定义

纯收入

衡量工程价值的另一项经济指标是工程的纯收入,也就是在整个生命周期之内的系统累计经验效益(折合成现在值)之差。

投资回收期

通常用投资回收期衡量一项开发工程的价值。所谓投资回收期就是使累计的经济效益等于最初投资所需要的时间。

流程图

流程图的三种结构

image-20230505211729505image-20230506135834972

系统流程图

系统流程图:是一种描绘物理系统的图,用图形符号以黑盒子形式描绘物理系统的各部 件,表达数据在系统各部件之间流动的情况。而不是对数据进行加工处理 的控制过程。

作用:描述物理系统的工具,用于可行性研究和需求分析阶段。

系统流程图的符号

image-20230507161645181image-20230505101317158image-20230505101502672

需求分析问题识别(11种)

  1. 功能需求分析
  2. 性能需求分析
  3. 数据分析
  4. 环境需求分析
  5. 输入,输出分析
  6. 安全分析
  7. 文档分析
  8. 进度分析
  9. 资源分析
  10. 质量控制分析
  11. 界面需求分析

第三章 软件设计

耦合性和内聚性

特点

定义

强弱

模块间耦合类型

image-20230505133413946
image-20230505133413946
  • 非直接耦合:不直接联系。

  • 数据耦合:通过数据参数(注意 是参数,不是区域也不是子结构!)联系。

  • 标记耦合:传递的信息是子结构(结构体、对象等)。

  • 控制耦合:A模块控制B模块

  • 外部耦合:访问同一外部变量,与公共耦合不同的是,一个是区域,一个是变量。

  • 公共耦合:访问同一公共区域

  • 内容耦合:内容重叠,

    • 如果发生下列情形,两个模块之间就发生了内容耦合。
      1. 一个模块直接访问另一个模块的内部数据
      2. 一个模块不通过正常入口转到另一模块内部;
      3. 两个模块有一部分程序代码重叠(只可能出现在汇编语言中);
      4. 一个模块有多个入口

模块的内聚性类型

模块间的耦合和模块的内聚是度量模块独立性的两个准则。内聚是模块功能强度的度量,即模块内部各个元素彼此结合的紧密程度。一个模块内部各元素之间的紧密程度越高,则其内聚性越高,模块独立性越好。

一般来讲,聚合类型共分七种, 以下为从弱到强的排序:

image-20230505134547257
image-20230505134547257
  • 偶然内聚或巧合内聚:指一个模块内的各处理元素之间没有任何联系。
  • 逻辑内聚:指模块内执行若干个逻辑上相似的功能,通过参数确定该模块完成哪一个功能。
  • 时间内聚:把需要同时执行的动作组合在一起形成的模块。
  • 过程内聚:指一个模块完成多个任务,这些任务必须按指定的次序执行。
  • 通信内聚:指模块内的所有处理元素都在同一数据结构上操作,或者各处理使用相同的输入数据或产生相同的输出数据。
  • 顺序内聚:指一个模块中的各个处理元素都密切相关于同一各功能且必须顺序执行,前一个功能元素的输出就是下一个功能的输入。
  • 功能内聚:指模块内的所有元素共同作用完成一个功能,缺一不可。

总结: 容易混淆的是过程内聚和顺序内聚, 虽然都是按固定顺序执行, 但顺序内聚要求前一个功能的输出是下一个功能的输入

image-20230505135632080
image-20230505135632080

软件结构准则

  1. 模块独立性准则
  2. 控制范围与作用范围之间的准则
  3. 软件结构的形态准则
  4. 模块大小的准则
  5. 模块的接口准则

算法描述(4种方法)

  • 盒图(N-S图)
  • 程序流程图
  • PAD图
  • 自然语言描述

扩展(了解)

  1. 自然语言描述算法:使用自然语言描述的好处是任何人都能看懂。当然相比于伪代码或者程序语言而言,使用自然语言描述有时会显得繁琐。
  2. 流程图描述算法:流程图(Flow Diagram)是一种通用的图形符号表示法是一种非正式的,可以清楚描述步骤和判断。
  3. 伪代码描述算法:伪代码(Pseudocode)是一种非正式的,类似于英语结构的,用于描述模块结构图的语言。
  4. 程序语言描述算法:程序语言描述算法,实际上就是用程序语言实现算法。不同的编程语言其语法不尽相同。

模块属性

  1. 接口
  2. 功能
  3. 逻辑
  4. 状态

扩展(了解)

  1. 名称:模块的名称,通常是一个有意义的、描述性的名称,用于唯一标识和识别模块。
  2. 功能:模块所提供的具体功能或服务的描述,包括模块的输入、输出以及对外部系统或用户的交互方式。
  3. 接口:模块与其他模块或外部系统之间的交互接口,描述了模块的输入、输出、调用的函数或方法等信息。
  4. 数据结构:模块内部使用的数据结构,包括数据类型、变量、常量等的定义和描述。
  5. 依赖关系:模块与其他模块之间的依赖关系,描述了模块所依赖的其他模块或外部组件,以及被依赖的关系。
  6. 耦合度:模块与其他模块之间的耦合程度,描述了模块之间的关联程度和依赖程度,例如紧密耦合、松散耦合等。
  7. 内聚度:模块内部功能之间的相关性和一致性,描述了模块内部功能的组织和关联程度,例如高内聚、低内聚等。
  8. 复用性:模块的可重用程度,描述了模块是否可以在不同的系统或项目中进行复用,以提高开发效率和质量。
  9. 可测试性:模块的可测试程度,描述了模块是否易于进行单元测试、集成测试和功能测试等,以保证模块的质量和稳定性。

第五章 软件测试

黑白盒测试

白盒方法

逻辑覆盖

  1. 语句覆盖:被测试程序中的每条语句至少执行一次
  2. 判定覆盖:使得被测程序中每个判定表达式至少获得一次“真”值和“假”值
  3. 条件覆盖:使得判定表达式中每个条件的各种可能的值至少出现一次
  4. 判定/条件覆盖:使得判定表达式中的每个条件的所有可能取值至少出现一次,并使每个判定表达式所有可能的结果也至少出现一次。(判定+条件)
  5. 条件组合覆盖:设计足够多的测试用例,使得每个判定表达式中条件的各种可能 的值的组合都至少出现一次
  6. 路径覆盖:覆盖被测程序中所有可能的路径
控制结构

基本路径测试

通过分析由控制构造的环路的复杂性,导出基本路径集合,从而设计测试用例,保证这些路径至少通过一次。

基本测试步骤

  1. 以详细设计或源程序为基础,到处程序流程图的拓扑结构——程序图(流图)
  2. 计算程序图G的环路复杂性V(G)
  3. 确定只包含独立路线的基本路径集
  4. 设计测试用例

示例:

image-20230509135720991image-20230509135740924image-20230509140106388

条件测试

循环测试

黑盒方法

等价类划分法

划分等价类的规则(理解即可)

  • 如果输入条件规定了取值范围,可定义一个有效等价类和两个无效等价类。

  • 如果输入条件代表集合的某个元素,则可定义一个有效等价类和一个无效等价类。

  • 如规定了输入数据的一组值,且程序对不同输入值做不同处理,则每个允许的输入值是一个有效等价类,并有一个无效等价类(所有不允许的输入值的集合)。

  • 如果规定了输入数据必须遵循的规则,可确定一个有效等价类(符合规则)和若干个无效等价类(从不同角度违反规则)。

  • 如已划分的等价类各元素在程序中的处理方式不同,则应将此等价类进一步划分成更小的等价类。

设计测试用例:

  1. 形成等价类表,每一等价类规定一个唯一的编号;
  2. 设计一测试用例,使其尽可能多地覆盖尚未覆盖的有效等价类,重复这一步骤,直到所有有效等价类均被测试用例所覆盖;
  3. 设计一新测试用例,使其只覆盖一个无效等价类,重复这一步骤直到所有无效等价类均被覆盖;

示例:

报表日期输入条件的等价类表

image-20230509122713268image-20230509123003189image-20230509123032153

边界值分析法
  • 输入等价类和输出等价类的边界就是应该着重测试的程序边界情况。选取的测 试数据应该刚好等于、刚好小于、刚好大于边界值

边界值分析原则(了解即可):

(1)如果输入条件规定了值的范围,可以选择正好等于边界值的数据作为合理的测试用例,同时选择刚好越过边界值得数据作为不合理的测试用例。 (2)如果输入条件指出了输入数据的个数,则按最大个数、最小个数、比最大个数多1、比最小个数少1等情况设计测试用例。 (3)对每个输出条件分别按照以上两个原则确定输出值的边界情况。 (4)如果程序的需求说明给出的输入或输出域是个有序集合(如线性表、链表等),则应选集合中第一个和最后一个元素作为测试用例。

常见的错误推测法

(1)零值、缺省值、空白、空值等测试值易使程序出错。

(2)分析规格说明书中的漏洞,编写测试数据。

(3)根据尚未发现的软件错误与已发现的软件错误成正比的规律,再进一步测试时重点测试已发现错误的程序段。

(4)等价类划分与边界值分析容易忽略组合的测试数据,因而可以采用判定表和判定树列出测试数据。

(5)与人工代码审查相结合,两个模块中共享的变量已被修改的,可以用来做测试用例。

因果图法

因果图适合于描述对于多种输入条件的组合,相应产生多个动作的形式来设计测试用例。因果图方法最终生成的是判定表。

示例:

image-20230509124000206image-20230509124025312image-20230509124134113

黑盒测试与白盒测试优缺点比较

黑盒测试白盒测试
优点1. 适用于各阶段测试 2. 从产品功能角度测试 3. 容易入手生成测试数据1. 可构成测试数据使特定程序部分得到测试 2. 有一定的充分性度量手段 3. 可获得较多工具支持
缺点
性质

系统测试(讲了一页)

系统测试:将子系统组装为一个完整的系统进行测试。子系统测试和系统测试总 称为“集成测试” 。

系统测试的特点:功能测试、性能测试、安全测试、回归测试

集成测试

目标:发现与接口有关的问题

实施者:独立的测试机构或第三方人员

集成方法:

  1. 非渐增测试
  2. 渐增测试
    1. 自顶向下集成:从主控模块开始,沿着程序的控制层次
    2. 自顶向下移动,逐步添加新的模块自底向上集成:从最底层模块开始组装

自顶向下与自底向上相结合的方法:

  1. 上层模块使用自顶向下方法
  2. 下层模块采用自底向上方法

回归测试: 重新执行已经做过测试的某个子集,以保证程序的变化没有带来非预 期的副作用。

测试用例的定义

测试用例的定义:是一组输入和期待的结果,它根据引起故障和检查的目的来使用组件。

软件错误类型

  • 功能错(需求分析错误)

  • 软件结构错

  • 数据错

  • 编码错

  • 软件集成错

  • 测试定义与测试执行错误

软件可测试的特性

  1. 可操作性
  2. 可观察性
  3. 可控制性
  4. 可分解性
  5. 简单易理解性

调试时修改错误的原则

修改错误的原则

  • 注意错误的群集现象,在错误近邻检查
  • 找到错误的本质并修改
  • 采用回归测试,避免因修改而引起的新错误

调试原则

  • 在调试方面,许多原则本质上是心理学方面的问题,调试由两部分组成,调试原则也分成两组。
  • 确定错误的性质和位置的原则
  • 用头脑去分析思考与错误征兆有关的信息
  • 避开死胡同
  • 只把调试工具当做辅助手段来使用,利用调试工具,可以帮助思考,但不能代替思考
  • 避免用试探法,最多只能把它当做最后手段

测试组件(单元测试)

单元测试(模块测试):将每个模块作为一个单独的实体进行测试。发现的错误编码和详细设计阶段的错误

测试依据:详细设计文档

测试技术(设计测试用例的方法):白盒测试技术

着重点:

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

第六章 软件维护

软件维护的副作用

编码、文档、数据的副作用

维护是为了延长软件的寿命,让软件创造更多的价值,但是维护会产生潜在的错误或 其他不希望出现的情况,这称为维护的副作用。维护的副作用有编码副作用、数据副作用 和文档副作用三种。

1.编码副作用

使用程序设计语言修改源程序时可能会引入错误。在修改程序的标号、标识符、运算 符、边界条件和程序的时序关系等时要特别仔细,避免引入新的错误。

2.数据副作用

修改数据结构时可能会造成软件设计与数据结构不匹配,因而导致软件错误。如在修 改局部量、全局量、记录或文件的格式、初始化控制或指针、输入输出或子程序的参数等 时,容易导致设计与数据不一致。

3.文档副作用

对数据流、软件结构、模块逻辑或其他任何特性进行修改时,必须对相关的文档进行相应的修改,否则会导致文档与程序功能不匹配,文档不能反映软件当前的状态。因此,必须在软件交付之前对软件配置进行评审,以减少文档的副作用。

第八章 结构化方法

DFD数据流图

描述信息流和数据从输入到输出过程所经受的变换。没有任何具体物理部件, 只是描绘数据在软件中流动被处理逻辑过程

image-20230507201433883image-20230507201712307image-20230506164933741

数据字典

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

1.数据字典的内容:数据流、数据流分量(数据元素)、数据存储、处理。

数据字典用途: 在软件分析和设计的过程中给人提供关于数据的描述信息。

① 作为分析阶段的工具

② 估计改变一个数据将产生的影响

③ 是数据库开发的第一步

image-20230506165036891image-20230506165102431image-20230506165341822

结构化语言判定表判定数

判断表判定树

判定表:当算法中包含多重嵌套的条件选择时判定表却能够清晰地表示复杂的条件组合与应做的动作之间的对应关系。

组成:

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

判定树

依据判断表来画

依据条件分类

SC结构图

image-20230506205150739image-20230506205243117

面向数据流设计方法也称为结构化设计方法(SD)

数据流图分类

(1)变换流:由输入、变换中心和输出三部分组成。

(2)事务流:在多种事务中选择一个执行。

变换分析: 把具有变换流特点的数据流图映射成软件结构。

变换型数据流图 => 软件结构图

事物型数据流图 => 软件结构图