第一章软件工程学概述
软件工程方法学包含3个要素：方法、工具和过程。
软件生命周期由软件定义、软件开发和运行维护（软件维护）3个时期组成，每个时期又进一步划分成若干个阶段。
1.4.1瀑布模型（看到文档优先考虑）
瀑布模型的成功在很大程度上是由于它基本上是一种文档驱动的模型
特点：（1）顺序性和依赖性（2）延迟实现（3）质量保障
优点：文档驱动
缺点：需求模糊的系统可能不满足用户需求
1.4.2快速原型模型
快速原型模型的第一步是快速建立一个能反映用户主要需求的原型系统，让用户在计算机上试用它，通过实践来了解目标系统的概貌。
特点：（1）快速开发工具（2）循环（3）低成本
优点：关注满足客户需求；可以作为最终交付成果的一部分。
缺点：系统设计差，效率低，难于维护。
1.4.3增量模型（递增模型）
增量模型它分批次地逐步向用户提交产品，整个软件产品被分解成许多个增量构建，开发人员一个构件接一个构件地向用户提交产品
优点：较短时间内向用户提交可完成有用的工作产品；用户的学习时间更加充分；软件构件必须开放，方便向现有产品加入新构件。
缺点：需要非常好的体系结构，如果体系结构不够强壮可能导致设计差，效率低。
1.4.4螺旋模型
螺旋模型主要适用于内部开发的大规模软件项目
优点：大型软件项目有良好的风险控制能力。
缺点：软件开发人员应该擅长寻找可能的风险，准确地分析风险，否则将会带来更大的风险。
适用范围：只适用于大规模软件项目，特别是内部项目。
第二章可行性研究
为什么要进行可行性研究？
为了避免人力、物力、财力上的浪费
要进行哪些方面的可行性研究？
（1）技术可行性（2）经济可行性（3）操作可行性（4）法律社会效益可行性
数据流图（DFD）是一种图形化技术，它描绘数据流和数据从输入移动到输出的过程中所经受的变换。在数据流图中没有任何具体的物理部件，它只是描绘数据在软件中流动和被处理的逻辑过程。
在数据流图中应该描绘所有可能得数据流向，而不应该描绘出现在出现某个数据流。
数据存储和数据流都是数据，仅仅所处的状态不同。数据存储是处于静止状态的数据，数据流是处于运动中的数据。
通常在数据流图中忽略出错处理，也不包括诸如打开或关闭文件之类的内务处理。数据流图的基本要点是描绘“做什么”，而不考虑“怎样做”。
第三章需求分析
（数据模型）数据对象说明——实体关系图（ER图）
（功能模型）加工说明——数据流图（DFD）
（行为模型）控制说明——状态转换图（STD）
第4章形式化说明技术
所谓形式化方法，是描述系统性质的基于数学的技术，也就是说，如果一种方法有坚实的数学基础，那么它就是形式化的。
4.3 Petri网
对Petri网的一个重要扩充是加入禁止线
第五章总体设计
1、耦合
在软件设计中应该追求尽可能松散耦合的系统。否则影响系统的可理解性、可测性、可靠性和可维护性。
耦合是影响软件复杂程度的一个重要因素。应该采取下述设计原则：尽量使用数据耦合，少用控制耦合和特征耦合，限制公共环境耦合的范围，完全不用 内容耦合。
2、内聚
内聚耦合密切相关，模块内的高内聚往往意味着模块间的松耦合。
修改设计提高模块的内聚程度并且降低模块间的耦合程度，从而获得较高的模块独立性。
深度、宽度、扇出和扇入都应适当（大题）（p100）
深度：表示软件结构中控制的层数，它往往能粗略地标志一个系统的大小和复杂程度。如果层数过多则应该考虑是否有许多管理模块过分简单了，能否适当合并。
宽度：是软件结构内同一个层次上的模块总数的最大值。一般说来，宽度越大系统越复杂。对宽度影响最大的因素是模块的扇出。
影响宽度的因素：对宽度影响最大的因素是模块的扇出，即模块可以调用的下级模块数越多，软件结构的宽度就越大。而宽度过大则可通过增加中间层来解决
扇出：是一个模块直接控制(调用)的模块数目。
扇出过大：意味着模块过分复杂，需要控制和协调过多的下级模块，应该适当增加中间层次的控制模块。
扇出过小：(例如总是1)也不好，可以把下级模块进一步分解成若干个子功能模块，或者合并到它的上级模块中去。经验表明，一个设计得好的典型系统的平均扇出通常是3或4。
模块的作用域定义为受该模块内一个判定影响的所有模块的集合。
变换流：信息沿输入通路进入系统，同时由外部形式变换成内部形式；进入系统的信息通过变换中心，经加工处理；再沿输出通路变换成外部形式离开软件系统。
事务流：数据沿输入通路到达一个处理T（事务中心），处理T根据输入数据的类型在若干个动作序列中选出一个来执行，称为事务流
第六章详细设计
6.4.1 Jackson图
逻辑关系只有顺序、选择和重复3类，逻辑数据结构也只有这3类
1、顺序结构2、选择机构3、重复结构
第七章实现
7.2.3测试方法（p151）
1、黑盒测试：如果已经知道了产品应该具有的功能，可以通过测试来检验是否每个功能都能正常使用
2、白盒测试：如果知道产品的内部工作过程，可以通过测试来检验产品内部动作是否按照规格说明书的规定正常进行。
7.2.4测试步骤（p151）
1、模块测试（单元测试）：保证每个模块作为一个单元能正确运行
2、子系统测试：把经过单元测试的模块放在一起形成一个子系统来测试
3、系统测试：把经过测试的子系统装配成一个完整的系统来测试
4、验收测试： 验证系统确实能够满足用户的需要，发现系统需求说明书中的错误
5、平行运行：同时运行新开发出来的系统和将被它取代的旧系统，以便比较新旧两个系统的处理结果
7.6白盒测试技术（p162-165）
1、语句覆盖（最弱）：至少每个语句应该执行一次
2、判定覆盖（分支覆盖）：每个语句必须执行一次，且每个判定的每种可能都应该执行一次
3、条件覆盖：每个语句至少执行一次，且是判定表达式中的每个条件都取到可能得结果
4、判定/条件覆盖：判定表达式中的每个条件都取到各种可能得值，且每个判定表达式也都取到各种可能得结果
5、条件组合覆盖：判定表达式中条件的各种可能组合都至少出现一次
7.6.2控制结构测试（大题）
基本路径测试：在程序控制流图的基础上，通过分析控制构造的环路复杂性，导出基本可执行路径集合，从而设计测试用例的方法。保证这些路径至少通过一次。
基本路径测试步骤：一、导出流图。二、计算流图的环形复杂度。三、确定线性独立路径的基本集合。四、设计每条路径的测试用例。
7.7黑盒测试技术
7.7.1等价划分（p172）：把所有可能得输入数据（程序的输入域）（有效和无效）划分成若干各部分；从每个等价类中选取少数代表性的数据作为测试用例（一个用例尽可能多的覆盖有效数据，一个用例覆盖一个无效数据）
7.7.2边界值分析
7.7.3错误推测
7.9软件可靠性
7.9.1基本概念
1、软件可靠性：软件可靠性是程序在给定的时间间隔内，按照规格说明书的规定成功地运行的概率
第八章维护
软件维护:软件已经交付使用之后，为了改正错误或满足新的需要而修改软件的过程
4项活动，具体定义软件维护：
1、改正性维护：诊断和改正错误的过程（占17~21%）
2、适应性维护：为了和变化了的环境适当的配合而进行的修改软件的活动，是既必要又经常的维护活动（占18%~25%）
3、完善性维护：为了满足用户提出增加新功能或修改已有功能的活动。这项活动通常占软件维护工作的大部分（占全部维护活动的50%~60%）
4、预防性维护：为了改进未来的可维护性或可靠性，或为了给未来的改进奠定更好的基础而修改软件。目前这项维护活动相对比较少。（占4%）
第九章面向对象方法学引论
面向对象的方法学可以用下列方程来概括：面向对象方法（OO）=对象（objects）+类（classes）+继承（inheritance）+用消息通信（communication with messages）
属性（attribute）：类中所定义的数据，它是对客观世界实体所具有的性质的抽象
封装（encapsulation）：在面向对象的程序中，把数据和实现操作的代码集中起来放在对象内部
继承（inheritance）：子类自动共享基类中定义的数据和方法的机制
重载(overloading)
函数重载：在同一作用域内的若干个参数特征不同的函数可以使用相同的函数名字；
运算符重载：同一个运算符可以施加于不同类型的操作数上面
9.4.1类图的基本符号
类图描述类及类与类之间的静态关系。类图是一种静态模型，它是创建其他UML图的基础。一个系统可以由多张类图来描述，一个类也可以出现在几张类图中。