目录
第17、18章 软件构造和代码设计
1.构造包含的活动
详细设计；编程；测试；调试；代码评审；集成与构建；构造管理。
2.名词解释
（1）重构：修改软件系统的严谨方法，它在不改变代码外部表现的情况下改进其内部结构
（2）测试驱动开发：测试驱动开发要求程序员在编写一段代码之前，优先完成该段代码的测试代码。
测试代码之后，程序员再编写程序代码，并在编程中重复执行测试代码，以验证程序代码的正确性。
（3）结对编程：两个程序员挨着坐在一起，共同协作进行软件构造活动
3.给定代码段示例，对其进行改进或发现其中的问题
复杂决策：使用有意义的名称封装复杂决策，例如对于决策“ If( (id>0) && (id<=MAX_ID))”，可以封装为“If ( isIdValid(id) )”，方法isIdValid(id)的内容为 “return ((id>0) && (id<=MAX_ID) )”
数据使用
（1）不要将变量应用于与命名不相符的目的。例如使用变量total表示销售的总价，而不是临时客串for循环的计数器。
（2）不要将单个变量用于多个目的。在代码的前半部分使用total表示销售总价，在代码后半部分不再需要“销售总价”信息时再用total客串for循环的计数器也是不允许的。
（3）限制全局变量的使用，如果不得不使用全局变量，就明确注释全局变量的声明和使用处。
（4）不要使用突兀的数字与字符，例如15（天）、“MALE”等，要将它们定义为常量或变量后使用。
明确依赖关系：类之间模糊的依赖关系会影响到代码的理解与修改，非常容易导致修改时产生未预期的连锁反应。对于这些模糊的依赖关系，需要进行明确的注释
4.契约式设计
契约式设计又称断言式设计，它的基本思想是：如果一个函数或方法，在前置条件满足的情况下开始执行，完成后能够满足后置条件，那么这个函数就是正确、可靠的。见书上示例P308
（1）异常
（2）断言：assert Expression1( : Expression2)
Expression1 是一个布尔表达式，在契约式设计中可以将其设置为前置条件或者后置条件；Expression2 是一个值，各种常见类型都可以；
如果Expression1 为true，断言不影响程序执行；如果Expression1 为false，断言抛出AssertionError 异常，如果存在Expression2 就使用它作为参数构造AssertionError。
5.防御式编程
优点：显著提高可靠性
防御式编程的基本思想是：在一个方法与其他方法、操作系统、硬件等外界环境交互时，不能确保外界都是正确的，所以要在外界发生错误时，保护方法内部不受损害。与契约式设计有共同点，又有很大的差异。共同点是他们都要检查输入参数的有效性。差异性是防御式编程将所有与外界的交互都纳入防御范围，如用户输入的有效性、待读写文件的有效性、调用的其他方法返回值的有效值……
编程方式：异常与断言。
输入参数是否合法？
用户输入是否有效？
外部文件是否存在？
对其他对象的引用是否为NULL？
其他对象是否已初始化？
其他对象的某个方法是否已执行？
其他对象的返回值是否正确？
数据库系统连接是否正常？
网络连接是否正常？
网络接收的信息是否有效？
6.表驱动
对于特别复杂的决策，可以将其包装为决策表，然后用使用表驱动编程的方式加以解决。示例见书上P307
7.单元测试用例的设计
MockObject创建桩程序
第19章 软件测试
1. 考试题
- 给出功能需求，设计功能测试用例
- 给出设计图，按要求写集成测试用例，Stub和Driver
- 给出方法的描述，按要求写单元测试用例，Mock Object
- Junit基本用法
2.白盒测试和黑盒测试的常见方法，并比较优缺点【必考】
（1）黑盒测试：基于规格的技术，是把测试对象看做一个黑盒子，完全基于输入和输出数据来判定测试对象的正确性，测试使用测试对象的规格说明来设计输入和输出数据。
常见方法：等价类划分（把输入按照等价类划分，包括有效和无效）；边界值分析；决策表；状态转换。
（2）白盒测试：基于代码的技术，将测试对象看成透明的，不关心测试对象的规格，而是按照测试对象内部的程序结构来设计测试用例进行测试工作。
.能解释并区别白盒测试三种不同的方法【必考】
语句覆盖、分支覆盖和路径覆盖。教材329页
语句覆盖：确保被测试对象的每一行程序代码都至少执行一次
条件覆盖：确保程序中每个判断的每个结果都至少满足一次
路径覆盖：确保程序中每条独立的执行路径都至少执行一次
【题型】给出一个场景，判断应该使用哪种测试方法，如何去写（JUnit基本使用方法）
给出功能需求——写功能测试用例
给出设计图——写集成测试用例，Stub和Driver
给出方法描述——写单元测试用例，MockObject
第20、21章 软件交付、软件维护与演化
1.软件维护的重要性
（1）由于会出现新的需求，如不维护软件将减小甚至失去服务用户的作用。
（2）随着软件产品的生命周期越来越长，在软件生存期内外界环境发生变化的可能性越来越大，因此，软件经常需要修改以适应外界环境的改变
（3）软件产品或多或少的会有缺陷，当缺陷暴露出来时，必须予以及时的解决
2.开发可维护软件的方法
（1）考虑软件的可变性：分析需求易变性、为变更进行设计
（2）为降低维护困难而开发：编写详细的技术文档并保持及时更新、保证代码可读性、维护需求跟踪链、维护回归测试基线
3.演化式生命周期模型
初步开发—演化—服务—逐步淘汰—停止
（1）初步开发
初始开发阶段按照传统的软件开发方式完成第一个版本的软件产品开发。第一版的软件产品可以实现全部需求，也可以（通常是）只包含部分需求——对用户来说非常重要和紧急的最高优先级需求。
（2）演化
可能会有预先安排的需求增量，也可能完全是对变更请求的处理，它们的共同点都是保持软件产品的持续增值，让软件产品能够满足用户越来越多的需要，实现更大的业务价值。
总的来说，该阶段可能的演化增量有：预先安排的需求增量；因为问题变化或者环境变化产生的变更请求；修正已有的缺陷；随着用户与开发者之间越来越相互熟悉对方领域而新增加的需求。
演化阶段的软件产品要具备两个特征：(1) 软件产品具有较好的可演化性。一个软件产品在演化过程中复杂性会逐渐增高，可演化性会逐渐降低直至无法继续演化。演化阶段的软件产品虽然其可演化性低于初始开发阶段的软件产品，但是还没有到达无法演化的地步，还具有较好的可演化性。(2) 软件产品能够帮助用户实现较好的业务价值。只有这样，用户才会继续需要该产品，并持续提供资金支持。
如果在演化过程中，一个软件产品开始不满足第（2）条特征，那么该产品就会提前进入停止阶段。如果软件产品满足第（2）条的同时不满足第（1）条特征，那么该产品就会进入服务阶段。如果开发团队因为竞争产品的出现或者其他市场考虑，也可以让同时满足上面两条特征的软件产品提前进入服务阶段。
（3）服务
服务阶段的软件产品不再持续的增加自己的价值，而只是周期性的修正已有的缺陷。
服务阶段的产品还仍然被用户使用，因为它仍然能够给用户提供一定的业务价值，所以开发团队仍然需要修正已有缺陷或者进行一些低程度的需求增量，保证用户的正常使用。
（4）逐步淘汰
在逐步淘汰阶段，开发者已经不再提供软件产品的任何服务，也即不再继续维护该软件。虽然在开发者看来软件的生命周期已经结束，但是用户可能会继续使用处于该阶段的软件产品，因为它们仍然能够帮助用户实现一定的业务价值。只是用户在使用软件时必须要容忍软件产品中的各种不便，包括仍然存在的缺陷和对新环境的不适应。对于该阶段的产品，开发者需要考虑该产品是否可以作为有用的遗留资源用于新软件的开发，用户需要考虑如何更换新的软件产品并转移已有的业务数据。
（5）停止
一个软件正式退出使用状态之后就进行停止状态。开发者不再进行维护，用户也不再使用。
4.用户文档、系统文档
（1）用户文档：这里的文档支持是指为用户编写参考指南或者操作教程，常见的如用户使用手册、联机帮助文档等，统称为用户文档。
文档内容的组织应当支持其使用模式，常见的是指导模式和参考模式两种。指导模式根据用户的任务组织程序规程，相关的软件任务组织在相同的章节或主题。指导模式要先描述简单的、共性的任务，然后再以其为基础组织更加复杂的任务描述。
参考模式按照方便随机访问独立信息单元的方式组织内容。例如，按字母顺序排列软件的命令或错误消息列表。如果文档需要同时包含两种模式，就需要将其清楚地区分成不同的章节或主题，或者在同一个章节或主题内区分为不同的格式。
（2）系统文档：更注重系统维护方面的内容，例如系统性能调整、访问权限控制、常见故障解决等等。因此，系统管理员文档需要详细介绍软硬件的配置方式、网络连接方式、安全验证与访问授权方法、备份与容灾方法、部件替换方法等等。
5.逆向工程、再工程
（1）逆向工程：分析目标系统，标识系统的部件及其交互关系，并且使用其它形式或者更高层的抽象创建系统表现的过程。逆向工程的基本原理是抽取软件系统的需求与设计而隐藏实现细节，然后在需求与设计的层次上描述软件系统，以建立对系统更加准确和清晰的理解。
（2）再工程：检查和改造一个目标系统，用新的模式式及其实现复原该目标系统。目的是对遗留软件系统进行分析和重新开发，以便进一步利用新技术来改善系统或促进现存系统的再利用。
主要包括：改进人们对软件的理解；改进软件自身，通常是提高其可维护性、可复用性和可演化性。
常见具体活动有：重新文档化；重组系统的结构；将系统转换为更新的编程语言；修改数据的结构组织。
第22、23章 软件开发过程模型
1.软件生命周期模型
需求工程—软件设计—软件实现—软件测试—软件交付—软件维护
2.解释与比较不同的软件过程模型
【题型】对给定场景，判断适用的开发过程模型（要求、特征描述、优点、缺点）
（1）构建-修复模型
- 特征：
- a.没有对开发过程进行规范和组织，因此一旦开发过程超出个人控制能力，就会导致开发过程无法有效进行而失败。
- b.对需求的真实性没有进行分析
- c.没有考虑软件结构的质量，导致结构在修改中越来越糟，直至无法修改
- d.没有考虑测试和程序的可维护性，也没有任何文档，导致难以维护
- 适用场景：软件规模很小，只需要几百行程序，其开发复杂度是个人能力能够胜任的；软件对质量的要求不高，即使出错也无所谓；只关注开发活动，对后期维护的要求不高，甚至不需要进行维护。
（2）瀑布模型（文档驱动）
- 特征：
- a.对于软件开发活动有明确阶段划分
- b.每个阶段的结果都必须验证，使得该模型是“文档驱动”
- 优点：清晰的阶段划分有利于开发者以关注点分离的方式更好的进行复杂软件项目的开发。
- 缺点：
- a.对文档期望过高；
- b.对开发活动的线性顺序假设（线性顺序与迭代相反）；
- c.客户、用户参与度不够（需求被限制在一个时间段）
- d.里程碑粒度过粗（软件复杂使得每个阶段时间长，无法尽早发现缺陷）
- 适用：需求非常成熟、稳定，没有不确定的内容，也不会发生变化；所需的技术成熟、可靠，没有不确定的技术难点，也没有开发人员不熟悉的技术问题；复杂度适中，不至于产生太大的文档负担和过粗的里程碑。
（3）增量迭代模型（需求驱动）与演化模型互为补充
- 特征：项目开始时，通过系统需求开发和核心体系结构设计活动完成项目的前景范围的界定，然后将后续开发活动组织为多个迭代、并行的瀑布式开发活动。第一个迭代完成的往往是核心工作，满足基本需求，后续迭代完成附带特性。
- 优点：
- a.更符合软件开发实践
- b.并行开发可以缩短产品开发时间
- c.渐进交付可以加强用户反馈，降低开发风险。
- 缺点：
- a.要求高：软件需要有开放式的体系结构
- b.不确定性太多，导致难以在项目开始就确定前景和范围
- 适用：比较成熟和稳定的领域
（4）演化模型（需求驱动）
- 特点：更好地应对需求变更，更适用于需求变更比较频繁或不确定性较多的领域。将软件开发组织为多个迭代、并行的瀑布式开发活动。是迭代＋并行＋渐进
- 优点：
- a.适用于需求变更频繁或者不确定性多的系统的开发
- b.并行开发可以缩短开发时间
- c.加强用户反馈，降低开发风险
- 缺点：
- a.无法在项目早起确定项目范围
- b.后续迭代活动以前导迭代为基础，容易使后续迭代忽略分析与设计。退化为构建－修复方式。
- 适用：不稳定领域的大规模软件系统
（5）原型模型（需求驱动）
- 特点：大量使用抛弃式原型（抛弃式原型：通过模拟“未来”的产品，将“未来”的知识置于“现在”进行推敲，解决不确定性）。
- 优点：
- a.加强与客户、用户的交流，更好的产品满意度
- b.适用于不确定性大的新颖领域
- 缺点：
- a.成本较高，有耗尽时间和费用的风险
- b.有人不舍得抛弃“抛弃式原型”，使得较差代码进入产品，降低质量
- 适用：有着大量不确定性的新颖领域
（6）螺旋模型（风险驱动）
- 特点：基本思想是尽早解决比较高的风险，如果有些问题实在无法解决，那么早发现比项目结束时再发现要好，至少损失要小得多。风险是指因为不确定性（对未来知识了解有限）而可能给项目带来损失的情况，原型能够澄清不确定性，所以原型能够解决风险。
- 迭代与瀑布的结合：开发阶段是瀑布式的，风险分析是迭代的
- 优点：降低风险，减少因风险造成的损失
- 缺点：
- a.使用原型方法，为自身带来风险
- b.模型过于复杂，不利于管理者依据其组织软件开发活动。
- 适用性：高风险的大规模软件系统开发
3.软件工程知识体系的知识域
需求、设计、构造、测试、维护、配置管理、工程管理、工程过程、工程工具和方法、质量