第一章 软件工程学概述
- 软件危机的定义
软件危机是指落后的软件生产方式无法满足迅速增长的计算机软件需求，从而导致软件开发与维护过程中出现一系列严重问题的现象。
软件危机产生的原因：1.软件本身的特点 2.软件开发和维护的方式不正确
- 软件工程方法学的种类
传统方法学和面向对象方法学
传统方法学：用结构化技术完成软件开发的各项任务，一个阶段一个阶段顺序开发，维护起来很困难
面向对象方法学：把数据和对数据的操作紧密结合起来
- 理解瀑布模型、增量模型、螺旋模型等不同软件开发模型
- 瀑布模型：阶段间具有顺序性和依赖性、保证质量、保证前面没有错误
缺点：开发结束后可能没有完成满足用户的需求（用户需求会变化）
- 快速原型模型：先快速建立一个满足用户需求的原型，让用户使用，用户提出修改意见，再进行修改
本质是快速节约开发成本
- 增量模型：把整个软件产品分解成许多个增量构件，分批地逐步向用户提交产品
可以使用户有充足的时间适应新产品
但要保证每一个构件集成到现有体系中不能破坏原来的产品
- 螺旋模型：使用原型及其他方法来降低风险，风险驱动规模与进度
每个阶段都增加了风险分析，适用于内部开发的大规模软件项目，风险分析成本高，对程序员判断风险的能力有要求
- 软件生命周期的基本阶段
三个时期：软件定义、软件开发、运行维护
软件定义分为：问题定义、可行性研究、需求分析
软件开发分为：总体设计、详细设计、编码和单元测试、综合测试
阶段：问题定义、可行性研究、需求分析、开发阶段、维护
第二章 可行性研究
- 数据流图的定义
一种图形化技术，描述数据从输入移动到输出过程中经受的变化，以及在软件中流动和被处理的逻辑过程
- 数据字典的定义
对数据流图中包含的所有元素的定义的集合，没有数据字典，数据流图就不严格，没有数据流图，数据字典难以发挥作用
数据流图的一些符号：
= 等价于
+ 和
[] 或，用|隔开选择的分量
{} 括号内的分量可重复，下限和上限写在括号两边
() 括号内的分量可有可无
- 能够写出给定例子的数据字典（结合课件PPT）
用户定义的标识符是长度不超过8个字符的字符串，其中第一个字符是字母，随后的字符可以是字母也可以是数字
第三章 需求分析
- 需求分析的基本任务
确定系统的综合要求
分析系统的数据要求
导出系统的逻辑模型（用数据流图等）
修正系统开发计划
- 需求规格说明书的作用
需求规格是是需求分析阶段得出的最主要的文档
便于用户、开发人员进行理解和交流。
反映出用户问题的结构,可以作为软件开发工作的基础和依据。
作为确认测试和验收的依据。
第五章 总体设计
- 耦合、内聚的不同类型
耦合：不同模块之间彼此依赖紧密程度
内聚：一个模块内部各元素彼此结合的紧密程度
耦合分为：数据耦合、控制耦合、公共环境耦合、内容耦合
数据耦合：系统中至少必须存在这种耦合，当模块的输出数据作为另一些模块的输入数据，系统才能完成有价值的功能
控制耦合：增加系统的复杂程度是多余的
公共环境耦合：公共环境类似于全局变量，多个模块向公共环境存取数据
内容耦合：两个模块有重叠部分，一个模块访问另一个模块内的数据
设计原则：尽量使用数据耦合，少用控制耦合，限制公共环境耦合的范围，完全不用内容耦合
内聚分为：
偶然内聚：模块内的任务有点关系，但关系松散
逻辑内聚：一个模块内的任务在逻辑上属于相同或相似的一类
时间内聚：一个模块内的任务必须在同一段时间内执行
上面三种都是低内聚
过程内聚：一个模块内的处理元素必须以特定次序执行
通信内聚：所有元素使同一个输入数据产生同一个输出结果
上面两种是中内聚
顺序内聚：一个模块内的处理元素功能密切相关，处理必须顺序执行
功能内聚：一个模块内的所有元素属于一个整体，完成一个单一功能
上面两种是高内聚
要高内聚、低耦合
- 启发规则都有哪些
启发规则：在开发计算机软件长期实践中积累了丰富的经验，总结出的规则
- 改进软件结构提高模块独立性
改进结构力求高内聚低耦合
- 模块规模要适中
模块不能太大，太大不好理解，太大原因是任务分解不充分
模块不能太小，太小效率低，而且模块数量会很多，使系统接口复杂
- 深度、宽度、扇入、扇出要适中
深度是结构中控制的层数
宽度是同一个层次上模块总数的最大值
扇出是模块直接调用其他模块的数目，过大说明模块复杂
扇入是多少个模块调用这个模块，扇入大说明共享该模块的数量多，有些好处，但扇入不能太多
都要适中
- 模块作用域要在控制域范围中
控制域是收到该模块功能影响的其他模块的集合
- 降低模块接口的复杂程度
- 设计单入口单出口的模块
这条规则是说模块中不要出现内容耦合
- 模块功能应可预测
可预测：黑盒测试中输入相同的数据应该有相同的输出
第六章 详细设计
- 程序的基本控制结构
顺序结构、分支结构、循环结构
- 详细设计和结构程序设计的目标
详细设计的目标：得出对目标系统的精确描述，在编码阶段可以直接根据这个描述翻译成某个程序设计语言写的程序
结构程序设计的目标：提高程序执行效率、提高可靠性、使程序结构简单清晰，增加可读性
- 过程设计的工具。理解和区分6.3.1-6.3.6不同工具的特点。会画PAD图
程序流程图： 历史悠久、容易掌握，但不易表示数据结构，随意转移，不能逐步求精
盒图： 不能随意转移，功能域明确，局部和全局数据作用域明确，容易表示模块的层次结构
PAD图⭐⭐：用二维树形结构表示程序控制流，翻译成代码比较方便
PAD符号
流程图转换为PAD图：
对应的盒图
判定表： 能清晰表示复杂的条件组合和对应动作之间的关系
判定树： 用树形表示判定表，更加清晰，但不如判定表简洁
过程设计语言： 伪代码
- 程序复杂度的度量
第七章 实现
- 实现的定义
编码和测试
- 白盒测试方法的种类；会画流图、计算环形复杂度
软件测试层次：
- 单元测试：模块是否有错误（白盒）
单元测试通常在每个模块写完后对它进行测试
- 集成测试：总体结构是否有错误（黑盒）
把模块组装起来进行测试
- 确认测试：是否满足用户需求（黑盒）
必须有用户的测试，分为alpha测试和beta测试，在下面有
流图、环形复杂度见上面六.4
- 软件测试的目标
发现软件中的错误，提高软件质量
- 黑盒测试中的边界值分析与等价类划分
- 等价类划分
是把所有可能的输入数据,即程序的输入域划分成若干部分（子集）,然后从每一个子集中选取少数具有代表性的数据作为测试用例。该方法是一种重要的,常用的黑盒测试用例设计方法。
- 边界值分析
边界值分析法就是对输入或输出的边界值进行测试的一种黑盒测试方法。通常边界值分析法是作为对等价类划分法的补充，这种情况下，其测试用例来自等价类的边界。
- 单元测试的测试重点
模块接口、局部数据结构、重要的执行通路、出错处理通路、边界条件
- 模块接口：数据能否正确进出
- 局部数据结构：局部数据初始化、默认值是否有错误
- 重要执行通路：选取最具有代表性，最有可能出错的通路
- 出错处理通路：设置适当处理错误的通路
- 边界条件：测试在边界值上是否有错误
- ⭐⭐理解白盒测试中不同的逻辑覆盖标准，能按不同标准选择出测试用例
- 语句覆盖：每个语句至少执行一次，是很弱的逻辑覆盖
- 判定覆盖：不仅每个语句至少执行一次，每个判断取真、取假都至少执行一次
- 条件覆盖：不仅每个语句至少执行一次，判定表达式的每个条件都要取到各种可能的结果
- 判定/条件覆盖：同时满足这两种条件的覆盖
- 条件组合覆盖：每个判定表达式中各种条件的组合都至少出现一次（最强的逻辑覆盖）
- 路径覆盖：覆盖程序中所有可能执行的路径
举例：
语句覆盖：a=2,b=2,c=2
判定覆盖：a=2,b=2,c=2(覆盖12345) a=0,b=0,c=0(覆盖135)
条件覆盖：a=2,b=2,c=4(覆盖a>0,b>0,a>1,c>1) a=-1,b=0,c=-1(覆盖a<=0,b<=0,a<=1,c<=1)
判定条件覆盖：a=2,b=2,c=4(覆盖a>0,b>0,a>1,c>1， 取值均为T) a=-1,b=0,c=-1(覆盖a<=0,b<=0,a<=1,c<=1，取值均为F)
- 7.5.3Alpha和Beta测试
alpha测试由用户在开发者的场所进行，在开发者的指导下进行
beta测试由用户自己进行，开发者不会在现场
第八章 维护
- 软件维护的定义
在软件交付使用之后，为了改正错误或满足新的需要而修改软件的过程
- 软件维护的不同类型和占比
第九章 面向对象方法学引论
- 用例图的画法（结合课件PPT中的用例图部分）
用例图：从用户观点对系统行为的描述，系统应该为每个用户提供什么，能够让使用者理解系统功能
椭圆是用例，火柴人是行为者，线表示行为者和用例之间的关系
用例就是一个完整的功能，比如自动售货机的用例就是售货、供货、取货款
画用例图分为两步：1.寻找行为者 2.寻找用例
例
从题目中可以得出，行为者是客户（开账户）、银行职员（客户通过银行职员开户取钱等，区别于其他银行职员，括号里可以写客户代理）、其他银行的职员（因为有银行间转账）、系统管理员，还有银行职员来管理账户，做的时候要思考地全面
用例是：开户、存款、取款、转账、注销，这些由银行职员中的客户代理帮助客户完成，客户需要做的是校验密码，其中转账又分为银行间转账和银行内转账，银行间转账需要其他银行职员，账户管理需要银行职员中的管理人员和系统管理员，系统管理员还负责报表生成。
根据题目意思画
第十三章 软件项目管理
- 13.3.1
估算开发时间P312
Walston_Felix模型 T=2.5E^0.35
原始的COCOMO模型 T=2.5E^0.38
COCOMO2模型 T=3.0E^(0.33+0.2×(b-1.01))
Putnam模型 T=2.4E^(1/3)
E 是开发工作量（以人月为单位， 20人月等于1人用20个月完成该任务）
T 是开发时间，以月为单位
Brooks规律：向一个已经延期的项目增加人力，只会使得它更加延期
存在一个最佳的项目组规模Popt，这个规模的项目组其总生产率最高。项目组的最佳规模是5.5人，即Popt=5.5
