Skip to content

重点

知识点

软件工程概述

编程语言代数 特征 代表语言 优点 缺点 适用领域
第一代 机器语言 ASCII 与硬件接口直接,执行效率高 可读性差,编写和调试困难 底层系统编程和嵌入式系统开发
第二代 汇编语言 汇编语言(如x86汇编) 相对易读写和理解,调试相对容易 与硬件紧密相关,可移植性差 底层系统编程、驱动程序开发
第三代 高级语言 过程:BASIC 、PASCAL、FORTRAN、C;对象:Visual C++、Visual Basic、 易读写、易理解、可移植性强,开发效率高 执行效率相对较低 通用软件开发、应用程序开发
第四代 领域特定语言 SQL、MATLAB、R等 更贴近问题领域,开发效率高 适用范围有限,不适合通用编程任务 数据库管理、科学计算、数据分析等特定领域
第五代 逻辑编程语言、人工智能语言 Prolog、Lisp、Haskell等 支持逻辑推理和智能问题求解,表达能力强 学习曲线陡峭,适应性较差 人工智能、专家系统、自然语言处理等
  • 软件工程管理
  • 开发人员管理:软件项目的成功与否往往与开发人员的能力和团队合作密切相关。开发人员管理涉及到招聘、培训、指导和激励开发团队成员,以确保他们具备适当的技能和知识来完成项目任务。
  • 组织机构管理:软件项目通常由一个组织机构来负责管理和执行。组织机构管理涉及到确定项目的组织结构、职责分工和沟通渠道,以确保团队成员之间的合作和协调。
  • 经费管理:软件项目的开发和维护需要一定的经费支持。经费管理涉及到预算编制、资金分配和成本控制等活动,以确保项目在可接受的成本范围内完成。
  • 投资回收期是指投资所需资金从项目开始到资金全部回收所经历的时间。
  • 软件包含:程序、数据、文档
  • 程序=数据结构+算法
  • 软件=程序+软件构建
  • 软件公司=软件+商业模式
  • 对象=(算法+数据结构)
  • 程序=(对象+对象+ …… )
  • 软件特点:复杂性、不可见性、易变性、服从性、非连续性
  • 分类:系统软件、应用软件和支撑软件
  • 软件工程
  • 定义:应用系统的、规范的、可量化的方法来开发、运行和维护软件,即将工程应用到软件;及对以上各种方法的研究
  • 发展:程序设计-软件设计-软件工程
  • 软件危机
  • 软件危机是指在计算机软件的开发和维护过程中所遇到的一系列严重问题。软件危机的表现有:成本和进度的估计不准确,软件产品不能满足用户要求,软件系统的规模和复杂度高,软件可靠性低等
  • 造成软件危机的原因
  • 客观上是由于软件本身的特点造成的,软件由复杂的 逻辑部件构成,同时规模又十分庞大;
  • 主观上是由不正确的开发方法造成的
  • &&生命周期
  • 问题的定义与可行性研究、需求分析(面向用户)、设计阶段、实现阶段、测试阶段、运行与维护
  • 计划时期、开发时期、运行时期
    • 计划时期可分为问题定义、可行性研究两个阶段
    • 开发时期包括需求分析、概要设计、详细设计、编码、测试等阶段
    • 运行时期主要进行软件维护和重构
  • 生命周期模型
  • 瀑布模型(结构化开发
    • 每一步的结果都是可验证的减少风险
  • 原型模型:
    • 先构造小型软件系统进行测试,获得反馈
  • 软件体系结构:构件、连接件、约束、质量、物理分布
  • 软件工程三要素:方法、工具和过程

可行性分析

  • 软件可行性研究的目的是用最小的代价 在尽可能短的时间内确定该软件项目是否能够开发,是否值得开发
  • &&技术可行性(最关键)、经济可行性、运行可行性、法律可行性
  • 因为用户无法准确知道自身的需求,所以必须由开发方理解用户的问题,并给出有效的解决方案 。这是现代软件开发的重点

需求分析

  • 软件需求:就是用户对系统提出的要求
  • 目标:软件需求规格说明书
  • 具有一定法律效力的合同文档,并依据供需双方达成的共识,清楚 地描述软件在什么情况下需要做什么以及不能做什么
  • 需求获取:理解应用域、建造业务模型、不断迭代
  • 需求来源:监管部门、技术团队本身、
  • 获取方法:焦点小组、卡片分类、快速原型法、人类学调研、A/B测试
  • 快速原型调研是一种通过创建原型来帮助收集、验证和澄清需求的方法。它可以帮助需求分析师和利益相关者更好地理解系统的功能、界面和交互方式,并在早期阶段就能获得反馈和确认。

  • 功能需求:功能需求规定开发人员必须在产品中实现的软件功能,用户利用这些功能来完成任务,满足业务需求。

  • 非功能需求:非功能性需求是指依一些条件判断系统运作情形或其特性,而不是针对系统特定行为的需求。包括安全性、可靠性、互操作性、健壮性、易使用性、可维护性、可移植性、可重用性、可扩充性
  • NABCD:需求、做法、好处、竞争、交付
  • image-20230612100136338
  • 需求验证:评审、原型化、模型验证、确认测试
  • 思想:抽象、划分、投影、建模
  • 需求分析方法
  • 结构化分析与设计方法
  • 面向对象设计与分析方法

面向对象

  • 对象就是一个包含数据以及与这些数据有关的操作的集合。 每个实体都是对象。
  • 类是一组具有相同数据结构和相同操作的对象集合。类是对象的抽象,而对象是类的具体实例。
  • OOA面向对象分析、OOD面向对象设计、OOP面向对象编程
  • 实体类、边界类、控制类
  • 实例变量:定义在实例中的变量,只作用于当前实例
  • 类变量:类变量是所有实例公有的变量。定义在类中,在方法体之外。
  • 类方法:类方法是将类本身作为对象进行操作的方法。

设计

  • 概要详细设计说明书
  • 概要设计/详细设计
  • 流程:制定规范、软件系统结构的总体设计、处理方式设计、数据结构设计、可靠性设计
  • 原则:
  • 模块化:最古老
    • 分解、信息隐藏、独立性
    • 子程序、函数、过程、编译文件等都可以作为模块
  • 结构化SD
    • 面向数据流
    • DFD->SC结构图
    • 分解: 分解是将复杂的问题或系统划分为较小、更易处理的子问题或子系统的过程。
    • 抽象: 抽象是将问题或系统的关键特征提取出来,忽略不必要的细节,以便更好地理解和处理。
  • 面向对象
  • 模块化关注代码的组织和复用,而结构化编程关注代码的控制流程(顺序选择循环)和可读性。
  • 软件工程基本定理:C(P1+P2)>C(P1)+C(P2) E(P1+P2)>E(P1)+E(P2)
  • 将两个独立的任务分别完成所需的成本,往往小于将这两个任务合并为一个任务然后完成的成本。
  • 将两个独立的任务分别完成所需的工期,往往小于将这两个任务合并为一个任务然后完成的工期。
  • 内聚与耦合
  • 内聚性是程序结构中各个模块内部相互关联的度量, 它取决于模块内部各个元素之间联系的紧密程度。
    • image-20230612102613745
  • 耦合性是程序结构中各个模块之间相互关联的度量, 它取决于各个模块之间接口的复杂程度、调用模块的方 式以及哪些信息通过接口。
    • image-20230612102618698
  • image-20230616114004929
  • 其他设计方法:形式化的方法、文学化编程
  • 详细设计的目的: 为软件结构图 (SC) 中的每一个模块确定采用的算法和模块内数据结构、接口、测试用例等
  • 概要设计:关注系统的功能模块模块之间的关系以及系统的总体架构。概要设计通常以较高的抽象级别进行,不涉及具体的实现细节。】

界面设计

  • UI界面是人与机器进行交互的操作平台,即用户与机器相互传递信息的媒介
  • 原则;
  • 置用户于控制之下、减少用户记忆负担、保持界面的一致
  • 尽快提供可感触的反馈、系统界面符合用户的现实惯例、用户有自由控制权、一致性和标准、适合各种类型的用户、帮助用户识别诊断并修复错误
  • 设计分析:用户特性分析、用户工作分析
  • 用户界面设计的类型:有菜单、图形与图表、对话 以及窗口等
  • 输入规则:减少用户工作量(缩写、默认、省却、选择)、确认、交互、反馈、范围

编码

  • 任务:使用选定的程序设计语言,把模块的过程性描述(不可执 行)翻译为用该语言书写的源程序或源代码(可执行)
  • 保证软件的质量和可维护性(程序设计语言的特性、程序设计风格)
  • 程序设计语言
  • 三要素:语法、语义(描述了程序设计语言中的各种语句和表达式的含义和行为)、语用
  • 基本成分:数据成分(名称、类型、作用域)、运算成分、控制成分、传输成分(I/O)
  • 心里特性、工程特性、应用特性
  • 程序需要转化为机器代码才能运行
  • 编译方式 :通过编译程序(编译、链接)将整个程序转换为机 器语言。
  • 解释方式 :通过解释程序,逐行转换为机器语言,转换一行运 行一行
  • image-20230612111107869
  • 选择:知识、应用领域、运行环境、性能、编译器
  • 编码风格:编码产生的源程序应该正确可靠、简 明清晰而且具有较高的效率。
  • 精确一致、缩进(空格、空行等)、括号、命名(下划线、驼峰,含义明确、不太长、不相似混淆)、注释
  • 序言性注释通常置于每个程序模块的开头部分,描述功能、接口、局部变量及历史
  • 功能性注释通常嵌在源程序体内,主要描述程序段的功能
  • 在一行内只写一条语句、程序编写首先应当考虑清晰性、程序要能直截了当地说明程序员的用意
  • 结构化编程
  • 自顶向下、逐步细化的设计方法和单入口单出口的控制结构。这种控制结构包 括有:顺序、选择和循环
  • 非结构化image-20230612111858261
  • 结构化image-20230612111913493
  • 程序复杂性主要是指模块内部程序的复杂性。它 直接关系到软件开发费用的多少、开发周期的长短和 软件内部潜伏错误的多少。
  • 代码行度量法
  • McCabe 度量法
  • Halstead 度量:根据运算符、对象的种类和数目使用公式计算预测的错误数目
  • 程序效率是指程序的执行速度及程序占用的 存储空间。
  • 应把变化范围大的循环变量放在内层
  • 应尽量把与循环变量无关的运算移到循环外去
  • 软件质量= 程序质量+ 软件工程质量
  • 程序的质量体现在软件外在功能的质量。
    • 功能测试,基本的判断可以用“是| 否”来判定
    • 服务质量
  • 程序的质量还有其它方面,例如用户体验的质量、国际化 的质量和安全性的质量。
  • 软件工程的质量:开发过程的可见性、风险控制、内部模块的交付质量、开发成本的控制、内部质量指标的完成情况
  • CMMI
  • 完成级:无法保证在实施 同类项目的时候仍然能够完成任务,对实施人员有很大的依 赖性
  • 管理级:体现了对项目的一系列管理程序,排除了完成任务随机性
  • 明确级:企业能够根据自身的特殊情况以及自己的标 准流程,将这套管理体系与流程予以制度化,在不同类项目上一样能够成功地实施
  • 量化管理级:通过量化技术来实现流程的稳定性,实现管理的 精度,降低项目实施在质量上的波动
  • 优化级:能够主动地改善流程,运用新技术,实现流程的优化
  • 代码复审:自我复审、同伴复审、团队复审
  • 内容:概要部分、设计规范部分、具体代码部分、效能、可读性、可测试性

测试

  • 软件质量保证QA:软件团队为了让软件达到事先定义 的质量标准而进行的所有活动,包括测试工作

  • 软件测试:运用一定的流程和工具,验证软件能实现预先设计的功能 和特性.

  • 软件测试关键在于测试用例的设计生成和执行
  • bug:症状、程序错误、根本原因
  • 测试内容
  • 一是检查与规格说明书的一致性(正向)
  • 二是处理反向案例/错误(尝试让程序出错)
  • 三是进行用户体验,从用户角度出发,检查是否给用 户传递了好的体验
  • 特点:开销大,不能进行穷举测试,难度大,自底向上、逐步集成,低 一级为上一级测试准备条件。
  • image-20230615183415616
  • 静态测试工具(通常集成程序理解功能):主要集中在需 求文档、设计文档及程序结构上,可以进行类型分析、 接口分析、输入输出规格说明分析等
  • 动态测试工具:功能确认与接口测试、覆盖率分析、性能分析、内存分析等。
  • 错误类型
  • 语法错误
  • 结构性错误(常见的各种运行错误)
  • 功能性错误

黑盒

  • 测试程序的功能/接口
  • &&等价分类法
  • 把输入数据的可能值划分为若干个等价类,使每类中的任何一个测试用例,都能代表同一等价类中的其它测 试用例(有效等价类、无效等价类)
  • 划分等价类重要的是:集合的划分,划分为 互不相交的一组子集,而子集的并是整个集合(完备、无冗余)
  • 划分方式
    • 如果输入条件规定了取值范围,或者是值 的个数,则可以确立一个有效等价类和两个无效 等价类。
    • 如果输入条件规定了输入值的集合,或 者是规定了“必须如何”的条件,这时可确立一 个有效等价类和一个无效等价类
    • 如果输入条件是一个布尔量,则可以确定 一个有效等价类和一个无效等价类
    • 如果规定了输入数据是一组值,而且程 序要对每个输入值分别进行处理。这时可为每一 个输入值确立一个有效等价类,此外再针对这组确 立一个无效等价类,它应是所有不允许输入值的 集合
    • 如果规定了输入数据必须遵守的规 则,则可以确定一个有效等价类(符合规则) 和若干个无效等价类(从不同角度违反规则)
  • &&边界值分析法
  • 实践表明,程序员在处理边界情况时,很容易因忽略或考虑 不周发生编码错误。
  • 基本思想: 取输入变量在 最小值、 略高于最小值、 正常值、 略低于最大值、 最大值。
  • 决策树法
  • image-20230615184754512
    • 条件与行动
  • 因果图法
  • image-20230615184926240
  • 错误猜测法
  • 猜测被测程序放在哪些地方容易出错,然后 针对可能的薄弱环节来设计测试用例。

白盒

  • 可以看到程序根据程序的代码结构进行测试

  • &&逻辑覆盖法

  • 语句覆盖:每条语句至少执行一次
    • image-20230615181138152
  • 判定(分支)覆盖:每一判定的每个分支至少执行一次
    • image-20230615181148327
  • 条件覆盖:每一判定中的每个条件,分别按“真”、 “假”至少各执行一次
    • image-20230615181157383
  • 判定/条件:覆盖同时满足判定覆盖和条件覆盖的要求
    • image-20230615181215149
  • 条件组合覆盖:求出判定中所有条件的各种可能组合值,每一可能的条件组合至少执行一次
    • image-20230615181225264
    • 仍然不能保证完全覆盖
  • 路径测试法
  • 路径测试:设计足够的测试用例覆盖程序中每一 条可能的程序执行路径至少测试一次,如果程序中含有 循环(在程序图中表现为环),则每个循环至少执行一次(在较复杂的情况中覆盖每一条路径实际上是不现实的)
  • 点覆盖对应语句覆盖
  • 边覆盖对应判定覆盖
  • 基本路环境测试
    • 程序圈复杂度:McCabe复杂性度量。从程序的环路复杂性 可导出程序基本路径集合中的独立路径条数,这是确定程序 中每个可执行语句至少执行一次所必须的测试用例数目的上 界。
    • 一条独立路径是指,和其他的独立路径相比,至少引入一个新处理语句或一个新判断的程序通路,通俗的来说就是该路径要比其他路径至少多一个新的路径,并且该路径应该是从头至尾的,不可间断。
    • 导出测试用例:根据圈复杂度和程序结构设计用例数据输入 和预期结果。
    • 准备测试用例:确保基本路径集中的每一条路径的执行。

测试流程

  • image-20230615185345854
  • 单元测试
  • 通过对模块的静态分析与动态测试,使其 代码达到模块说明的需求。
  • 在单元测试时,需要为被测试模块编制若干测试软件,给它的上级模块或下级模块作替身。代替上级模块的称为测试驱动模块,代替下级模块的称为测试桩
  • 白盒为主
  • image-20230615190729523
  • 集成测试
  • 通过单元测试的模块要按照一定的策略组装为完整的程序,在该组装过程中进行的测试称为集成测试或组装测试
  • 自顶向下测试:先广度后深度实施、先深度后广度实施(需要准备测试桩模块)
  • 自底向上测试:从下⼀层模块中找出⼀个没有下级模块的模块,由下向上 地逐加新模块,组成程序中的⼀个⼦系统或模块群;
  • 白盒黑盒
  • 确认测试
  • 其目的在于确认组装完毕的程序是否满足 软件需求规格说明书的要求。
  • 有效性测试和配置复审
  • 系统测试
  • 目的是检查把确认测试合格的软件安装到 系统中以后,能否与系统的其余部分协调运行,并且完 成需求规格说明对它的要求。系统测试由用户单位实施
  • 验收测试:如果软件是给一个客户开发的,需要进行 一系列验收测试来保证满足客户所有的需求。验收测试 主要由用户而不是开发者来进行的。
  • Alpha测试:是在⼀个受控的环境下,由用户在开发者的指导下进⾏测试,由开发者负责记录错误和 使用中出现的问题。
  • Beta测试:由最终用户在自⼰的场所进⾏,开发者通常不在场,也不能控制应用的环境。由用户记录 错误和使用中出现的问题,并定期地交给开发者来 解决
  • 终止测试:
  • 白盒测试时一般可规定以完全覆盖为标准,语句覆盖和判 定覆盖的覆盖率达100%。
  • 黑盒测试时,可结合程序的实际情况选择一或数种方法来 设计测试用例,当把所有测试用例全部用完后,测试便可 结束。
  • 如果已经积累了丰富的测试经验,可以把查出的预定数量 的错误作为某类应用程序的测试终止标准。
  • 测试类型:功能测试(最重要)、安全测试、性能测试、接口测试

软件调试

  • 测试:发现软件失效;调试:定位软件错误并将其修复
  • image-20230615192055876
  • 面向对象
  • 面向对象软件是基于类/对象,而传统测试则基于模块

发布与维护

  • 维护的种类:修正性维护(修正错误)、适应性和改善性维护(适应环境、需求的变化)、预防性维护(增加系统的可维护性)
  • 不包括定期检测维护

  • image-20230615192803780

  • 设计变更DCR(Design Change Request) Bug的修复,因为经过Alpha阶段后,会收到很多用户反 馈,使得原来的设计需要改进,这会产生很多Bug,需要 修复,从而进入到Beta发布;
  • 软件维护:在软件发布后修改软件系统或组件的过程,用以修正错误、改进性能或者适应变化了的环境
  • 由于软件维护人员通常不是程序代码的编写者,软件维护非常困难,难在程序理解和影响分析上。
  • 逆向工程:从可运行的程序系统出发,运用解密、反汇编、系统 分析、程序理解等多种计算机技术,对软件的结构、 流程、算法、代码等进行逆向拆解和分析 ,推导出软 件产品的源代码、设计原理、结构、算法、处理过程 、运行方法及相关文档等。(理解软件)
  • 软件重构:重构是源代码的内部修改,在不改变外观的前提下,用以改善系统质量、提高可理解性,降低修改成本。
  • Lehman法则:系统功能增强,随之质量下降且内部复杂性增加
  • 内容:重复的代码、过长的函数、过大的类、过长的参数列、发散式变化(一个类由于不同的原因而被修改,进行拆分)、霰弹式修改(遇到变化时需要修改许多 不同的类,对类进行合并)

金融软件

  • 第一阶段为金融电子化、信息化阶段,着重于IT技术的 后台应用;第二阶段为互联网金融阶段,聚焦于前端服务渠道的互 联网化和移动化;第三阶段为金融科技阶段,强调业务前、中、后台的全 流程科技应用变革,向自动化、智能化方向迈进。
  • image-20230615194333452
  • 将巨大的数据计算处理程序分解成无数个小程 序,然后通过多部服务器组成的系统进行处理和分析这些小程 序得到结果并返回给用户。(分布式计算)

绘图

&&DFD

  • image-20230612101250396
  • image-20230612101840981

数据字典DD

  • 对DFD中数据的格式与内容进行定义、解释

活动图

  • 分叉可以用来描述并发线程,每个分叉可以有一个输入转换和两个或多个输出转换,每个转换都可以是独立的控制流。
  • 汇合代表两个或多个并发控制流同步发生,当所有的控制流都达到汇合点后,控制才能继续往下进行。
  • 实心圆表示初始节点(只有一个),圆圈内加一个实心圆来表示活动终点(可有多个)。
  • image-20230612103513000

用例图

  • image-20230612101359078
  • image-20230612101313215

ER

  • image-20230612100612925
  • 实体、属性、关联

SC结构图

  • 由DFD转化得到

image-20230612103810422

顺序图

  • image-20230612101022508
  • image-20230612101923834

类图

  • image-20230612100957852
  • image-20230612101640861
  • image-20230612101709407

&&程序流程图

  • 问题:随意转移goto

  • image-20230612104725286

  • image-20230612104610913
  • image-20230612104643307

&&NS图

  • 解决goto,绘制、修改麻烦

  • image-20230612104812947

  • image-20230612104822081

&&PAD图

  • 支持逐步求精方法(函数)

  • image-20230612105012884

  • image-20230612105044137

&&PDL伪代码

  • 格式: TYPE <变量名> AS<限定词1> <限定词2>(TYPE number AS STRING LENGTH (12))
  • begin end
  • if then; else ;endif
  • do while; enddo
  • repeat until; endrep
  • do loop ;exit when ;endloop
  • do for; endfor
  • case of ;when select;endcase;
  • read/write to;

&&程序图(mccabe环路复杂度)

  • 利用程序的控制流来度量程序的复杂性
  • 对于复杂度超过10的程序,应分成几个小程序,以 减少程序中的错误
  • image-20230612112256931
  • m-n+2或P(判定结点的数目,有多条输出边)+1或图中区域的数目
  • 习题
  • 从程序的环路复杂性 可导出程序基本路径集合中的独立路径条数,这是确定程序 中每个可执行语句至少执行一次所必须的测试用例数目的上 界。
  • image-20230616000104670

补充&题目