Lazy loaded image
学习笔记
💣软件工程导论复习笔记
字数 4823阅读时长 13 分钟
2025-7-1
2025-7-10
type
status
date
slug
summary
tags
category
icon
password

《实用软件工程(第3版)》考点总结

一、简答题(5题,33分)

重点考查基础概念,需掌握以下内容及对应章节:
  • 软件的分类(第1章"1.1.2 软件的分类")
  • 软件危机(第1章"1.2 软件危机")
  • 软件工程的概念(第1章"1.3.1 软件工程的概念")
  • 软件开发的方法(结构化方法参考第4、5章,面向对象方法参考第6章)
  • 软件工程工具(第1章"1.5 软件工程工具")
  • 软件生命周期(概念及6个阶段划分,第2章"软件过程")
  • 可行性研究的内容及主要评估的可行性方面(第3章"可行性研究与项目开发计划")
  • 软件设计的原则(模块化、耦合与内聚,第5章"3.2 软件结构设计")
  • 黑盒测试与白盒测试的概念(第10章"软件测试"相关内容)
  • 软件维护的分类(第10章"10.15.3 软件维护的分类")
  • 软件工程管理的内容(第11章"软件工程管理"中11-1至11-3节)

二、分析题(2题,20分)

围绕图表分析,需掌握以下图表的绘制与理解,结合三四班练习中的三个项目:
  • 数据流图(第4章"2.5 数据流图")
  • E-R图(第4章"2.4 实体-关系图")
  • 软件结构图(第5章"3.3 软件结构设计的图形工具")
  • 程序流程图(第5章"5.8.1 程序流程图")

三、设计题(3题,47分)

侧重实际设计能力,需结合案例和代码进行绘制:
  1. 详细设计图表:根据程序源代码绘制程序流程图(第5章"5.8.1 程序流程图")和盒图(N-S图)。
  1. 类图:根据案例文字描述绘制类图(第6章"6.3.2 类图和包",参考书本P135-140 7-3节)。
  1. 软件结构图:根据文字描述绘制软件结构图(第5章"3.3 软件结构设计的图形工具",结合练习掌握)。

四、其他重点章节内容

  • 第2章"软件过程":掌握瀑布模型、了解喷泉模型等软件过程模型。
  • 第4章"结构化分析":4-1节全部内容,重点理解数据流图例子。
  • 第5章"结构化设计":5-3节重要内容,5-5-1节软件结构图(特别重要),5-8-1节程序流程图(重点)。
  • 第7章"面向对象软件设计与实现":全章重点,尤其是7-2-1节,7-3节类图绘制(重中之重),7-3-3节数据流图表示功能模型,7-3-4节至少掌握三条关系。
  • 第8-10章:8-4节、8-5节(系统相关),10-1节、10-6节、10-7节内容。

复习建议

围绕四次练习,确保所有题目能准确完成,重点掌握各类图表的绘制逻辑和方法,结合教材对应章节的具体案例加深理解。

软件的定义

软件 = 程序 + 数据 + 文档
notion image
 

软件的特点

  • 软件具有抽象特征。
  • 软件具有无明显制造过程特征。
  • 软件无备件的特征。
  • 手工制作特征。
  • 成本昂贵特征。
 

软件的分类(第1章“1.1.2 软件的分类”)

根据功能和用途,软件可分为三类:
分类
定义
例子
系统软件
控制和管理计算机硬件资源
操作系统(Windows、Linux)、编译器
支撑软件
支持开发、维护与运行的工具性软件
数据库管理系统、开发环境(如Eclipse)
应用软件
面向特定任务或问题求解的软件
办公软件(Word、Excel)、ERP系统
 

软件危机(第1章“1.2 软件危机”)

“软件危机”是指在软件开发过程中出现的成本超支、进度拖延、质量低劣等问题。
原因包括:
  • 需求不明确
  • 缺乏规范的开发流程
  • 用户需求频繁变更
  • 软件规模庞大、复杂度高
  • 缺乏有效的测试手段
notion image
 

软件生命周期的六个主要阶段(基本任务)

  • 可行性研究:判断项目是否值得做,评估技术、经济、操作可行性
  • 需求分析:收集并分析用户需求,明确系统功能和性能要求
  • 软件设计:根据需求进行系统结构设计和详细设计
  • 编码:编写程序代码,并对各个模块进行测试
  • 软件测试:将模块整合,进行整体测试,确保符合需求
  • 软件维护:系统投入使用后的持续支持、修改和完善
 

常见软件生命周期模型

模型
特点
适用场景
瀑布模型
各阶段严格顺序执行,强调文档驱动
需求明确、变化少的项目
快速原型模型
先构建原型供用户反馈,再完善需求
用户需求不清晰时
增量模型
分批次交付功能模块
功能可分阶段实现的项目
螺旋模型
结合风险分析的迭代模型
大型复杂项目
喷泉模型
面向对象方法常用,阶段无明显界限
OOP 开发环境下的项目

瀑布模型(Waterfall Model)

🔍 定义:
瀑布模型是一种线性顺序执行 的软件开发模型。各阶段严格按顺序进行,且每个阶段完成后才能进入下一阶段。

瀑布模型的三个主要阶段

瀑布模型通常包含以下三个主要阶段:
  • 计划阶段:包括可行性研究、需求分析和定义
  • 开发阶段:包括概要设计、详细设计、编码和单元测试、软件测试
  • 运行阶段:包括运行维护
 
特点:
  • 阶段间顺序性强
  • 文档驱动
  • 阶段间无重叠
  • 强调前期需求明确
优点:
优点
说明
结构清晰
每个阶段目标明确,易于管理
易于控制进度
各阶段有明确交付成果
文档完整
强调文档编写,便于后期维护
❌ 缺点:
缺点
说明
不灵活
一旦进入下一阶段,不能回头修改
风险高
若前期需求错误,后期代价大
不适合需求变化频繁的项目
用户反馈机制差

适用场景:

  • 需求明确、稳定的项目
  • 政府、军工、金融等对文档要求高的行业
  • 传统管理系统(如工资系统、库存系统)
notion image
notion image

喷泉模型(Fountain Model)

🔍 定义:
喷泉模型是一种面向对象的软件开发模型 ,强调迭代和无明显阶段界限,各个阶段可以并行或反复进行 ,更符合现代软件开发的实际需要。

📈 特点:

  • 迭代性 :开发过程可多次重复某一阶段
  • 无明显阶段界限 :需求、设计、编码等阶段可交叉进行
  • 以对象为核心 :基于面向对象技术进行建模
  • 用户参与度高 :在开发过程中持续获取用户反馈
优点:
优点
说明
灵活性强
可随时调整需求和设计
更贴近实际开发过程
允许不断优化
支持面向对象开发
适合复杂系统和互联网产品
❌ 缺点:
缺点
说明
管理难度大
因为没有固定流程,难以控制进度
对团队协作要求高
需要良好沟通机制和文档习惯
初期投入较大
建模和原型开发耗时多

适用场景:

  • 面向对象开发项目
  • 需求不明确或经常变更的项目
  • 互联网产品、移动应用、游戏等创新类项目
 
 
简述瀑布模型和喷泉模型的主要区别,并说明它们各自适用的项目类型。
参考答案:
瀑布模型是一种线性顺序执行的开发模型,各阶段之间不可逆,适用于需求明确、变化少的传统管理系统;
喷泉模型是面向对象的迭代模型,阶段之间无明显界限,允许反复修改,适用于需求不确定、需持续优化的创新型项目,如互联网产品或移动应用。
 
口诀:瀑布顺流而下,喷泉来回循环;瀑布文档先行,喷泉面向对象。
 

请对比黑盒测试和白盒测试

黑盒测试(大功能模块)把被测试的软件系统看成是一个黑盒子,并不需要关心盒子的内部结构和内部特性,而只关注软件产品的输入数据和输出结果,从而检查软件产品是否符合它的功能说明。
(功能测试)主要用于集成测试、确认测试和系统测试阶段。
白盒测试(小功能模块)关注软件产品的内部细节和逻辑结构,即把被测的程序看成是一个透明的盒子。
(结构测试)主要用于单元测试阶段
 

可行性研究内容

1.技术可行性研究主要考虑项目使用技术的成熟程度;与竞争者技术相比,所采用技术的优势及缺陷;技术转换成本;技术发展趋势及所采用技术的发展前景;技术选择的制约条件等。
2.操作可行性研究主要考虑系统是否能够真正解决问题;系统一旦安装后,是否有足够的人力资源来运行系统;用户对新系统具有抵触情绪是否可能是操作不可行;人员的可行性等问题。
3.经济可行性研究主要是把系统开发和运行所需要的成本与得到的效益进行比较,进行成本效益分析。
 

问题定义和需求说明

notion image
 
 
 
 
 

黑盒测试

等价类划分

方法
notion image
notion image
有效等价类设计一个测试用例,无效每条都设计一个
notion image
 
 
 
 
 
 

画图

数据流图

数据流图(Data Flow Diagram,简称 DFD) 是一种图形化工具,用于描述系统中数据的流动、处理和存储。它帮助分析和设计信息系统时理解数据如何在系统中被输入、变换和输出。
DFD 广泛应用于软件工程、业务流程建模和系统分析中,尤其适合表达系统的功能需求和数据交互关系。

数据流图的层级结构

DFD 通常分为多个层次,从宏观到微观逐步细化:
  1. 上下文图(Context Diagram)
      • 最高层级,将整个系统看作一个“黑盒”过程。
      • 显示系统与外部实体之间的数据交互。
  1. 第0层图(Level-0 DFD 或 顶层DFD)
      • 把系统拆分成若干主要过程。
      • 展示这些过程之间的数据流、外部实体和数据存储。
  1. 更细层级(Level-1, Level-2 等)
      • 对每个过程进一步分解,展示更详细的数据处理步骤。
数据流图的作用
  • 系统分析 :帮助理解系统的逻辑结构和数据流向。
  • 沟通工具 :便于开发人员、用户和管理人员之间交流需求。
  • 设计辅助 :为后续的系统设计、数据库设计提供基础。
  • 发现漏洞 :通过绘制DFD,可以发现遗漏的功能或不合理的数据流程。
 
notion image
 
notion image
notion image

数据流图:

notion image
  1. 顶层数据流图(0层数据流图)
系统和外部实体之间的交换(没有数据存储)
notion image
  1. 一层数据流图
进一步细化(0层的泡泡)
notion image

ER图:

实体(矩形)、关系(菱形)、属性(椭圆)
与之前不同的是一对一、一对多、多对多的关系表达
notion image
notion image
 

软件结构图:

  1. 层次图&HIPO图:
notion image
  1. 结构图:
notion image

类图:

notion image
notion image
notion image
关系
notion image
notion image
 

程序流程图:

notion image
notion image
notion image
notion image

盒图:

notion image

用例图

notion image

活动图

notion image
notion image

1.概述

有经验的同学一定看到过产品经理给的业务流程图,UML的活动图和流程图画法是很相似的,只是相对于流程图来说,活动图有更丰富的图标可以表达更加丰富的语义。此外,在与uml的用例图对比中,如果说用例图是表达了参与者与系统功能之间的关系,那么活动图就是对用例中系统功能更详细的描述
简单的说,活动图描述的就是用例中的功能流程实现细节,例如:从哪里开始到哪里结束,中间有什么判断条件,有没有异步处理,哪里可以做存储等等。活动图是对业务功能流程细节的分析,能够为代码开发提供指导作用,适用的人群一般是研发同学。

在我的另一篇文章《用例图(Use Case Diagram)》中讲述了用例图特点及其画法,不熟悉用例图的同学又有兴趣了解的同学,可以去看一看。

2.常用的节点图例

2.1.开始、结束、动作节点

开始、结束是通过圆形的图标来表示,其中开始是实心圆,结束是一个空心圆中包含了一个小一点的实心圆,动作则是通过一个圆角方框来表示,他们之间的执行流程通过实现箭头来表示,箭头的方向就是流程运行的方向。
活动图表达的是业务流程,所有的业务流程都是有始有终的,如下图:
notion image
动作(action)节点表示的是需要执行的任务,它是当前活动流程中的一个原子性步骤,通过动词来进行描述,下面是一个极简版的商品购买流程:
notion image

2.2.决策、合并节点

我们在实际的流程一般不会这么简单,在流程中往往会存在一些条件分支,通过不同的条件来执行不同的子流程,这样的条件分支在代码中体现为if/else这样的代码块,而在活动图当中是通过决策节点来描述的。
决策节点可以通过一个空心菱形来表示,在指向子流程的箭线上可以写上条件,意思是满足xxx条件后,会进入这个分支,如下图所示:
notion image
空心菱形除了可以表示决策节点外,还可以表示合并节点。所谓的合并节点就是不同的条件中分支子流程执行后,最终都会在某个节点上进行合并,执行同一个后续流程。对于上图中的后续动作,有时候会看到如下图的表示方式:
notion image

我们在选购商品的过程中,有两种下单的方式,一种是立即购买,另一种是先加入购物车等逛得差不多了以后,再统一进行结算。所以我们就可以在选购商品后加入决策节点,并在生成订单之后加入一个合并节点。上面的活动图修改过后的图示如下:
notion image

2.3.fork、join 节点

fork、join节点与上面的决策、合并节点类似,都是将一个流程分叉成多个子流程链路,最终再合并到一起,不同的是,fork节点分叉出的子流程是并行执行的,也就是异步操作。join节点也很好理解,就是在某个位置等待所有异步执行的流程都执行完毕后,再合并成同一个流程运行。
fork、join节点都是通过一根又黑又粗又长的直线来表示的,如下图:
notion image

在购买商品的流程中,用户支付成功之后需要修改支付订单的状态为成功,同时需要生产快递单以进行配送,这两个动作可以并行执行,则可以表示为:
notion image

2.4.泳道

在上面的商城下单支付业务活动图中,已经可以看到大致业务流程,相信大家已经注意到了,图中不同的动作节点应该属于不同的角色来触发的,但是现在所有的节点都试混杂在一起的,不容易理解,为了避免这样的情况,我们可以将同一种类型的动作按照角色、流程阶段等维度进行分组。
在活动图中提供分组功能的图例就是接下来要说的泳道,由多个并列的长矩形框组成,由酷似泳池中的泳道而得名,如下图:
notion image

通过泳道,可以将上面的商品购买流程东西表示的更加精确,不仅仅展示了流程的运行方向,也展示了流程中不同角色之间的交互关系,例如添加购物车、立即购买这样的东西应该时由用户触发,生成订单、支付、支付结果更新这样的动作应该属于支付服务,而快递单、配送订单等应该属于快递服务。
我们将流程节点进行分组并放置到不同的泳道之后,展示的信息如下:
notion image
可以看到的是,加入了泳道之后流程的信息表达的更加丰富、也更加准确了。
总结
本篇主要是讲述了活动图以及活动图中的常用节点图例,活动图是用例图细节的补充,我们在活动中可以表达的是一个完整的功能流程,通过决策、fork/join等节点展示出条件分支、异步功能特点,并指导研发人员进行代码开发。
我们在梳理一条完整的功能链路的时候,使用泳道对活动节点进行分组的方式更佳,但泳道使信息变得丰满的同时,也会增加画图的复杂度以及耗时,所以在画一些相对简单的流程时,可以选择不使用泳道。
最后再总结一下本篇文章中需要注意的一些细节点:
  • 动作节点:表达的是一个具有原子性的动作,描述的文字一定是动词
  • 决策/合并节点:都是通过空心菱形来表示,合并节点不是必须存在的。
  • fork/join节点:join节点只有在多个异步流程会重新聚合成一个同步流程的时候才需要画出来。

图例重其意而不重其形,在标准图例的基础上可以适当的做一些修改,只要整个团队中都能够理解其含义即可。
 
上一篇
Lombok的一个强大注解:@Builder注解
下一篇
Steam破解教程