【软件工程导论】——软工学绪论及传统软件工程（学习笔记）

HinsCoder

已于 2024-03-31 23:31:56 修改

阅读量1.2k

点赞数 26

分类专栏：软件工程文章标签：软件工程学习笔记经验分享

于 2024-03-08 11:12:49 首次发布

❗ 转载请注明出处作者：HinsCoder 博客链接：

本文链接：https://blog.csdn.net/HinsCoder/article/details/136478360

版权

软件工程专栏收录该内容

4 篇文章 1 订阅

订阅专栏

📖 前言：随着软件产业的发展，计算机应用逐步渗透到社会生活的各个角落，使各行各业都发生了很大的变化。这同时也促使人们对软件的品种、数量、功能和质量等提出了越来越高的要求。然而，软件的规模越大、越复杂，软件开发越显得力不从心。于是，业界开始重视软件开发过程、方法、工具和环境的研究，软件工程应运而生。

在这里插入图片描述

🕒 1. 软件工程学概述

软件 = 程序（包含数据） + 文档

程序是为了解决某个特定问题而用程序设计语言描述的适合计算机处理的语句序列
数据是使程序能正常操纵信息的数据结构
文档是与程序开发，维护和使用有关的图文材料

🕘 1.1 软件和软件危机

软件与硬件的不同

软件开发不同于硬件设计
软件生产与硬件制造不同
软件维护不同于硬件维修

软件是逻辑的，而不是物理的

软件开发与人关系密切
软件开发成本大
软件生产是简单的拷贝
软件不会磨损和老化
软件受环境影响大
软件维护易产生新的问题

软件危机：是指落后的软件生产方式无法满足迅速增长的计算机软件需求，从而导致软件开发与维护过程中出现一系列严重问题的现象。

软件危机的表现：

对软件开发成本和进度的估算很不准确
用户很不满意
质量很不可靠
没有适当的文档
软件成本比重上升
供不应求：软件开发生产率跟不上计算机应用迅速深入的趋势

软件危机的原因：

客观：软件本身特点
- 逻辑部件
- 规模庞大、复杂度高
主观：不正确的开发方法
- 忽视需求分析
- 个人化方式：软件开发=程序编写
- 轻视软件维护

解决途径：

组织管理：工程项目管理方法
技术措施：软件开发技术与方法、软件工具

促使了软件工程的诞生：按工程化的原理和方法组织软件开发是软件开发中的问题一个主要出路

🕘 1.2 软件工程学的研究范畴

在这里插入图片描述

软件开发方法
- 为软件开发提供了 “如何做” 的技术
- 个性化方法 → 结构化方法 → 面向对象方法 → 软件复用
软件工具
- 为软件开发提供了自动的或半自动的软件支撑环境
- 单个工具 → 工具箱、集成工具 → 环境
软件工程管理
- 目的：为了按进度及预算完成软件计划
- 内容：成本估算、进度安排、人员组织、质量保证等

🕘 1.3 软件工程的发展

三种编程范型：

过程式编程范型
- 程序由一组被动数据和一组能动过程组成
- 程序 = 数据结构 + 算法
- 着眼于程序的过程和基本控制结构，粒度最小
面向对象编程范型
- 数据及其操作被封装在对象中
- 程序 = 对象 + 消息
- 着眼于程序中的对象，粒度比较大
基于构件技术的编程范型
- 构件是通用的、可复用的标准化对象类
- 程序 = 构件 + 架构
- 着眼于适合整个领域的类对象，粒度更大

三代软件工程：

传统软件工程：
- 结构化分析 →结构化设计 → 面向过程的编码 → 软件测试
面向对象软件工程：
- 面向对象基本概念：对象+类+继承+消息通信
- OO分析与对象抽取 → 对象详细设计 → 面向对象的编码和测试
基于构件的软件工程：
- 领域分析和测试计划定制 → 领域设计 → 建立可复用构件库 → 查找并集成构件

🕒 2. 软件生存周期与软件过程

🕘 2.1 软件生存周期

需求分析 → 软件分析 → 软件设计 → 编码（测试） → 交付测试 → 使用维护

需求分析
- 明确需要解决的问题（从用户的视角）
- 建立需求模型：功能、性能、约束、接口等
软件分析
- 从开发人员的视角对软件进行分析
- 建立分析模型：软件的逻辑模型
软件设计
- 确定软件的总体结构和各部件的数据结构和操作
- 建立软件设计模型：考虑实现技术和平台
编码
- 用程序设计语言将设计文档翻译成源程序
- 建立软件实现模型：包含现有软件构件包
软件测试
- 发现程序中的错误、提高软件质量
- 单元测试、集成测试、确认测试、系统测试
运行维护

软件过程：围绕软件开发所进行的一系列活动

软件过程模型

把软件生存周期中软件开发活动的有序流程用一个合理的框架来规范描述。
软件过程模型是一种软件过程的抽象表示法，它从一个特定的角度表现一个开发过程。

软件生存周期中的阶段和软件过程中的活动是基本一致的。

🕘 2.2 传统的软件过程

🕤 2.2.1 瀑布模型（Waterfall Model）

瀑布开发模型是一种基于软件生存周期的线性开发模型，它与软件生存周期的特点是一致的，强调软件文档，每一个阶段必须完成规定的文档，每一个阶段都要复审完成的文档。

在这里插入图片描述
特点

阶段的顺序性和依赖性
推迟实现的观点
质量保证的观点

存在问题

不适合需求模糊的系统
开发初始阶段很难彻底弄清软件需求

🕤 2.2.2 快速原型模型（Rapid Prototype Model）

快速原型模型是一种基于原型的迭代化开发模型。中心思想是先建立一个能够反映用户主要需求的原型（Demo），让用户实际看一下未来系统的概貌，以便判断哪些功能是符合需要的，哪些方面还需要改进。然后将原型反复改进，直至建立完全符合用户要求的新系统。

在这里插入图片描述
特点

“逼真”的原型可以使用户迅速作出反馈
循环回溯和迭代：非线性模型
使用快速开发工具

种类

渐进型：对原型补充和修改获得最终系统
抛弃型：原型废弃不用

应防止的偏向：舍不得抛弃，从而影响软件质量

小结：瀑布模型是纸上谈兵，快速原型模型是真枪实干。

🕘 2.3 软件演化模型

演化开发模型：使所开发的软件在迭代中逐步完善。

🕤 2.3.1 增量模型（Incremental Model）

定义：把软件看作一系列相互联系的增量，每次迭代完成一个增量。

在这里插入图片描述
增量

小而可用的软件
第一个增量通常是软件的核心

特点

在前面增量的基础上开发后面的增量
每个增量的开发可用瀑布或快速原型模型
每个增量开发的顺序性和总体的迭代性相结合

🕤 2.3.2 螺旋模型（Spiral Model）

在这里插入图片描述

特点

瀑布模型（顺序性、边开发边复审）+ 快速原型（迭代性）
风险分析 → 发现、控制风险

一个螺旋式周期

计划：确定目标，选择方案，选定完成目标的策略
风险分析：从风险角度分析该策略
开发：启动一个开发活动
评审：评价前一步的结果，计划下一轮的工作

🕤 2.3.2 构件集成模型（Component Integration Model）

在这里插入图片描述

构件

在某个领域内具有通用性，可以复用的软件部件
将可以复用的构件存储起来，形成构件库

特点

面向对象
基于构件库
融合螺旋模型特征
支持软件开发的迭代方法
软件复用

🕘 2.4 形式化方法模型

形式化方法模型：基于程序变换和验证技术的软件开发

🕤 2.4.1 转换模型（Transformational Model）

在这里插入图片描述
开发过程

确定形式化需求规格说明书
进行自动的程序变换
针对形式化开发记录进行测试

特点

形式化软件开发方法
- 形式化需求规格说明
- 变换技术
程序自动生成技术
确保正确

🕤 2.4.2 净室模型（Cleanroom Model）

在这里插入图片描述

净室思想

在分析和设计阶段消除错误
在“洁净”状态下实现软件制作

形式化

盒结构表示分析和设计
正确性验证

增量模型

把软件看成一系列的增量

软件过程模型的特点汇总：

开发模型	特点	适用场合
瀑布模型	线性模型，每一阶段必须完成规定的文档	需求明确的中、小型软件开发
快速原型模型	用户介入早，通过迭代完善用户需求，原型废弃不用	需求模糊的小型软件开发
增量模型	每次迭代完成一个增量，可用于OO开发	容易分块的大型软件开发
螺旋模型	典型迭代模型，重视风险分析，可用于OO开发	具有不确定性大型软件开发
构件集成模型	软件开发与构件开发平行进行	领域工程、行业的中型软件开发
转换模型	形式化的规格说明，自动的程序变换系统	理想化模型，尚无成熟工具支持
净室模型	形式化的增量开发模型，在洁净状态下实现软件制作	开发团队熟悉形式化方法，中小型软件开发

🕘 2.5 统一过程和敏捷过程

🕤 2.5.1 统一过程（Rational Unified Process，RUP）

统一过程描述了软件开发中各个环节应该做什么、怎么做、什么时候做以及为什么要做，描述了一组以某种顺序完成的活动。

统一过程将软件开发分为四个阶段：

先启：定义整个项目的范围
精化：制定项目计划、描述功能、建立体系架构框架
构建：构造软件产品
迁移：将软件产品移交到最终用户手中

在这里插入图片描述

🕤 2.5.2 敏捷过程（Agile Process）

敏捷开发是一种以人为核心、迭代、循序渐进的开发方法，其软件开发过程称为“敏捷过程”

🕤 2.5.3 极限编程（extreme programming，XP）

极限编程是敏捷过程中的一种，是轻量级的、敏捷的软件开发方法。

🕘 2.6 软件可行性研究（Feasibility Study）

目的

研究项目是否可能实现和值得进行
回答 Why to do?

研究的内容：经济可行性、技术可行性、运行可行性、法律可行性

可行性研究的步骤：

对当前系统进行调查和研究
- 弄清当前系统
- 导出新系统逻辑模型
导出新系统的解决方案
- 设计不同的解决方案
提出推荐的方案
- 本项目的开发价值
- 推荐这个方案的理由
编写可行性认证报告
- 系统概述
- 可行性分析
- 结论意见

软件风险分析：

风险识别：项目风险、技术风险、商业风险
风险预测
- 风险发生的可能性
- 风险发生后的后果
风险的驾驭和监控

🕒 3. 结构化分析（Structured Analysis，SA）与设计（SD）

🕘 3.1 概述

结构化分析与设计最初系由结构化程序设计扩展而来

是瀑布模型的首次实践
SA与SD的流程
- 结构化分析（工具：DFD、PSPEC） → 分析模型（分层DFD图）+ SRS
- 结构化设计（工具：SC图） $\stackrel{映射}{\rightarrow}$ 初始设计模型（初始SC图）
- 初始设计模型（初始SC图） $\stackrel{优化}{\rightarrow}$ 最终设计模型（最终SC图）
基本任务与指导思想
- 结构化分析
  - 建立分析模型（Analysis Model）
  - 编写需求说明（Software Requirements Specification，SRS）
- 结构化设计
  - 软件设计 = 总体设计 + 详细设计
  - SC图须分两步完成：初始SC图、最终SC图
- 细化与分解
  - 逐步细化，细化的本质就是分解

🕤 3.1.1 SA模型的组成与描述

SA模型的描述工具：

DFD、DD和PSPEC：这是早期SA模型的基本组成部分；
CFD（Control Flow Diagram，控制流图）、CSPEC（Control Specification，控制规格说明）和STD（Status Transform Diagram，状态转换图）：是早期SA模型的扩展成分，适应实时软件的建模需要；
E-R图（Entity-Relation Diagram）：适用于描述具有复杂数据结构的软件数据模型；

在这里插入图片描述

数据流图（Data Flow Diagram，DFD）
- 指明数据在系统中移动时如何被变换，描述对数据流进行变换的功能和子功能。
- 组成符号
  - 圆框代表加工；
  - 箭头代表数据的流向，数据名称总是标在箭头的边上；
  - 方框表示数据的源点和终点；
  - 双杠（或单杠）表示数据文件或数据库
  - 文件与加工之间用带箭头的直线连接，单向表示只读或只写，双向表示又读又写

在这里插入图片描述

数据字典（Data Dictionary，DD）
- 对软件中的每个数据规定一个定义条目。
- ①数据流、②数据文件、③数据项

数据流图与数据字典共同构成系统的逻辑模型

加工说明（Process Specification，PSPEC）
- 对数据流图中出现的每个加工/处理的功能描述
- 主要工具：结构化语言，判定树或判定表

例题：某公司为推销人员制订了奖励办法，把奖金与推销金额及预收货款的数额挂钩。凡每周推销金额不超过10000元，按预收货款是否超过50％，分别奖励推销额的6％或4％。反之若推销金额超过10000元，则按预收货款是否超过50％，分别奖励推销额的8％或5％。对于月薪低于1000元的推销员，分别另发鼓励奖300、200和500、300元。

试分别采用判定表和判定树为DFD图中用来“计算奖金”的加工写出加工说明（即PSPEC）。
在这里插入图片描述

🕤 3.1.2 SD模型的组成与描述

在这里插入图片描述

包含数据设计、体系结构设计、接口设计与过程设计。
体系结构设计是用来确定软件结构的，其描述工具为结构图，简称SC图。
过程设计主要指模块内部的详细设计

SC图的组成符号

矩形框来表示模块，带箭头的连线表示模块间的调用，并在调用线的两旁标出传入和传出模块的数据流

SC图的模块调用：为了画面简洁，在下图中调用线的两旁均未标出数据流。在实际的 SC 图中不允许这种省略。
在这里插入图片描述

🕘 3.2 结构化系统分析

定义：结构化分析就是使用DFD、DD、结构化英语、判定表和判定树等工具，来建立一种新的、称为结构化说明书的目标文档。

结构化分析的基本步骤

由顶向下对系统进行功能分解，画出分层DFD图
由后向前定义系统的数据和加工，编制DD和PSPEC
最终写出SRS

画分层数据流图：（自顶向下，逐步细化）

好处：便于实现，便于使用

顶层DFD：通常把整个系统当作一个大的加工标明系统的输入与输出，以及数据的源点与终点（统称为“外部项”）

在这里插入图片描述

第二层DFD：

在这里插入图片描述

第三层DFD——销售子系统：
在这里插入图片描述

第三层DFD——采购子系统：
在这里插入图片描述

确定数据定义与加工策略（从数据的终点开始定义数据和加工）
数据定义—DD

例如：发票
- 发票＝学号＋姓名＋｛书号＋单价＋数量＋总价｝＋书费合计

加工策略—PSPEC

数据定义DD
加工策略PSPEC
需求规格说明书SRS

需求分析的复审

🕘 3.3 结构化系统设计

SD概述

面向数据流设计和面向数据设计
- 面向数据流：数据流是考虑一切问题的出发点
- 面向数据：以数据结构作为分析与设计的基础
从分析模型导出设计模型
结构化设计的描述工具：SC图

从分析模型导出设计模型：
在这里插入图片描述

数据流图（DFD）的类型：

变换（transform）型结构
- 传入路径
- 变换中心
- 传出路径
事务（transaction）型结构
- 一条接受路径
- 一个事务中心
- 若干条动作路径

同时存在两类结构：
在这里插入图片描述
SD方法的步骤

复审DFD图，必要时可再次进行修改或细化
鉴别DFD图所表示的软件系统的结构特征，确定它所代表的软件结构是属于变换型还是事务型
按照SD方法规定的一组规则，把DFD图为初始的SC图
- 变换型DFD图 $\stackrel{变换映射}{\rightarrow}$ 初始SC图
- 事务型DFD图 $\stackrel{事务映射}{\rightarrow}$ 初始SC图
按照优化设计的指导原则改进初始的SC图，获得最终SC图

🕤 3.3.1 变换映射

划分DFD图的边界
建立初始SC图的框架
- 顶层都只含一个用于控制的主模块
- 第一层包括传入、传出和中心变换三个模块
分解SC图的各个分支
- 分解实质上是“映射”

例题：用变换映射规则从下图导出初始 SC图
在这里插入图片描述

划定边界：左边是输入流、中间是变换中心、右边是输出流
在这里插入图片描述

一级分解：
在这里插入图片描述

M_C：控制模块，可以将整个系统的名称作为控制模块
M_A：传入模块，输入流整体作为传入模块
M_T：变换模块，变换中心作为变换模块
M_E：传出模块，输出流整体作为传出模块

二级分解：对传入、传出和变换模块的分解
在这里插入图片描述

从变换分析导出的初始 SC 图：
在这里插入图片描述

深度：5层；宽度（广度）：7层；

注意：必须对一个模块的全部直接下属模块都设计完成之后，才能转向另一个模块的下层模块的设计；在设计下层模块时，应考虑模块的耦合和内聚问题；使用“黑箱”技术，先把这个模块的所有下层模块定义成“黑箱”，不考虑其内部结构和实现；一个模块的直接下属模块一般在五个左右，如果直接下属模块超过10个，可设立中间层次。