第一章 软件工程概述1、1968 年北大西洋公约组织的计算机科学家在联邦德国召开国际会议，讨论软件危机问题，在这次会议上正式提出并使用了“软件工程”这个名词，一门新兴的工程学科就此诞生了。2、软件危机：是指在计算机软件的开发和维护过程中所遇到的一系列严重问题。3、软件危机包含下述两方面的问题：如何开发软件，以满足对软件日益增长的需求；如何维护数量日益增长的已有软件。4、产生危机的原因与软件本身的特点有关与软件开发与维护的方法不正确有关。5、软件的生命周期：一个软件从定义、开发、使用、维护，直到被废弃，要经历一个漫长的时期，这就如同人要经过胎儿、儿童、青年、中年、老年，直到最终死亡的漫长周期一样。通常把软件经历的这个漫长的时期称为生命周期。6、软件工程定义：软件工程是指导计算机软件开发和维护的一门工程学科。采用工程的概念、原理、技术和方法来开发和维护软件。把经过时间考验而证明正确的管理技术和当前能够得到的最好技术方法结合起来，以经济地开发出高质量的软件并有效的维护它，这就是软件工程。7、软件工程 7 个本质特征：软件工程关注与大型程序的构造软件工程的中心课题是控制复杂性软件经常变化开发软件的效率非常重要和谐地合作是开发软件的关键软件必须有效的支持它的用户在软件工程领域中通常由具有一种文化背景的人替另一种文化背景的人创造产品8、软件工程的 7 条基本原理：用分阶段的生命周期计划严格管理坚持进行阶段评审实行严格的产品控制采用现代程序设计技术结果应能清楚的审查开发小组的人员应该少而精承认不断改进软件工程实践的必要性9、通常把软件周期全过程中使用的一整套技术方法的集合称为方法学，也成为范型。10、软件工程的方法包含 3 个要素：方法、工具和过程。其中方法是完成软件开发的各项任务的技术方法回答“怎样做”的问题；工具是为运用方法而提供的自动或半自动的软件工程支撑环境；过程是为了获得质量的软件所需要完成的一系列任务的框架，它规定了完成各项任务的工作步骤。11、软件的生命周期由软件定义、软件开发和运行维护 3 个时期组成，每个时期又进一步划分成若干阶段。软件定义时期：问题定义可行性研究需求分析。开发时期：总体设计详细设计编码和单元测试综合测试维护时期：主要任务是是软件持久地满足用户的需要。12、瀑布模型的特点：阶段间具有顺序性和依赖性推迟实现的观点质量保证的观点第二章 可行性研究1、可行性研究方面：技术可行性：使用现有的技术是否能实现这个系统。经济可行性：这个系统的经济效益能否超过它的开发成本。操作可行性：这个系统的操作方式在这个用户组织内是否可行。可行性研究步骤：复查系统规模和目标研究目前正在使用的系统导出新系统的高层逻辑模型进一步定义问题导出和评价供选择的解法推荐行动方针草拟开发计划书写文档提交审查。2、数据流图（会画）3、数据流图（DFD）：是一种图形化技术，它描绘信息流和数据从输入移动到输出的过程中所经受的变换。4、数据流图 4 种基本符号：正方形（或立方体）表示数据的源点或终点；圆角矩形（或圆形）代表变换数据的处理；开口矩形（或两条平行横线）代表数据存储；箭头表示数据流，即特定数据的流动方向。5、数据字典(P47)：数据字典是关于数据的信息的集合，也就是对数据流图中包含的缩影元素的定义的集合。6、数据字典的内容：由四类元素的定义组成：数据流数据流分量（即数据元素）数据存储处理7、由数据元素组成数据的方式只有下述三种基本类型：顺序：以确定次序连接两个或多个分量。 选择：从两个或多个可能的元素中选取一个。重复：把指定的分量重复零次或多次。可选第三章 需求分析1、系统的综合要求：功能需求: 这方面的需求指定系统必须提供的服务。通过需求分析应该划分出系统必须完成的所有功能 性能需求: 性能需求指定系统必须满足的定时约束或容量约束，通常包括速度（相应时间） 、信息量速率、主存容量、磁盘容量、安全性等方面的需求 可靠性和可用性需求: 可靠性需求定量地指定系统的可靠性 出错处理需求:这类需求说明系统对环境错误应该怎样响应 接口需求：描述应用系统与它的环境通信的格式 约束：设计约束或实现约束描述在设计或实现应用系统时鹰遵守的限制条件 逆向需求：说明软件系统不应该做什么 将来可能提出的要求：在设计过程中对系统将来可能的扩充和修改预做准备以便一旦确实需要时能比较容易的进行这种扩充和修改2、分析系统的数据要求：通常采用建立数据模型的方法3、导出系统的逻辑模型： 综合上述两项分析的结果可以导出系统的详细的逻辑模型，通常用数据流图、实体-联系图、状态转换图、数据字典和主要的处理算法描述这个逻辑模型。4、获取需求的方法：访谈 面向数据流自顶向下求精 简易的应用规格说明技术 快速建立软件原型5、分析建模：需求分析过程应建立模型：数据模型、功能模型、行为模型6、实体-联系图，描绘数据对象及数据对象之间的关系，是用于建立数据模型的图形。 数据流图，描绘当数据在软件系统中移动时被变换的逻辑过程，指明系统具有的变换数据的功能，因此，数据流图是建立功能模型的基础。状态转换图(状态图)，指明了作为外部事件结果的系统行为。为此，状态转换图描绘了系统的各种行为模式（状态)和在不同状态间转换的方式。状态转换图是行为建模的基础。7、验证软件需求的正确性一致性：所有需求必须是一致的，任何一条需求不能喝其他需求互相矛盾。完整性：需求必须是完整的，规格说明书应该包括用户需要的每一个功能或性能。现实性：指定的需求应该是现有的硬件技术和软件技术基本上可实现的。对硬件技术的进步可以做些预测，对软件技术则很难做出预测，只能从现有技术水平出发判断需求的现实性。有效性：必须证明需求是正确有效的，确实能解决用户面对的问题。第五章 总体设计1、总体设计过程通常有两个主要阶段组成：系统设计阶段，确定系统的具体实现方案；结构设计阶段，确定软件结构。2、典型总体设计过程包括下面 9 个步骤：设想供选择的方案选取合理的方案推荐最佳方案功能分解设计软件结构设计数据库制定测试计划 书写文档（系统说明、用户手册、测试计划、详细的实现计划、数据库设计结果）审核和复审3、设计原理模块化（P94）：模块是由边界元素限定的相邻程序元素的序列，而且有一个总体标识符代表它。模块化就是把程序划分成独立命名且可独立访问的模块，每个模块完成一个子功能，把这些模块集成起来构成一个整体，可以完成指定的功能满足用户的需求抽象：人类在认识复杂现象的过程中使用的最强有力的思维工具。人们在实践中认识到，在现实世界中一定事物、状态或过程之间总存在着某些相似的方面（共性）。把这些相似的方面集中和概括起来，暂时忽略它们之间的差异，这就是抽象。或者说抽象就是抽出事物的本质特性而暂时不考虑它们的细节。逐步求精：为了能集中精力解决主要问题而尽量推迟对问题细节的考虑。逐步求精之所以如此重要，是因为人类认知过程遵循 Miller 法则：一个人任何时候只能把注意力集中在（7+2）个知识块上。信息隐藏和局部化：模块独立：模块独立的概念是模块化/抽象/信息隐藏和局部化概念的直接结果。开发具有独立功能而且和其他模块之间没有过多的相互作用的模块，就可以做到模块独立。模块独立程度可以有两个定性标准度量：内聚和耦合。耦合衡量不同模块彼此间相互依赖（连接）的紧密程度；内聚衡量一个模块内部各个元素彼此结合的紧密程度。耦合【数据耦合】：两个模块间彼此通过参数交换信息，而且交换带信息仅仅是数据。（数据耦合是低耦合，系统中必须存在这种耦合）【控制耦合】：传递的信息中有控制信息（控制耦合是中度耦合，它增加了系统的复杂程度，它往往是多余的）【特征耦合】：当把整个数据结构作为参数传递而被调用的模块只需要使用其中一部分数据元素是，就出现了特征耦合。【公共环境耦合】：当两个或多个模块通过一个公共数据环境互相作用时，它们之间的耦合称为公共耦合。【内容耦合】：最高程度耦合是内容耦合。出现下列情况之一就出现了内容耦合：一个模块访问另一个模块的内部数据。一个模块不通过正常入口而转到另一个模块内部。两个模块有一部分程序代码重叠（只可能出现在汇编中）一个模块有多个入口（意味着一个模块有多种功能）内聚实践证明，内聚比耦合更重要。【偶然内聚】：如果一个模块完成一组人物，这些人物彼此间即使有关系，关系也是松散的，这就是偶然内聚。【逻辑内聚】：如果一个模块完成的人物在逻辑上属于相同或类似的一类，则称为逻辑内聚。【时间内聚】：如果一个模块包含的人物必须在同一段时间内执行，则称为时间内聚。中内聚主要有两类：如果一个模块内的处理元素是相关的，而且必须以特定次序执行，则称为【过程内聚】 ；使用流程图作为工具设计软件时，常常通过研究流程图确定模块的划分，这样得到的往往是过程内聚的模块。如果模块中的所有元素都使用同一个输入数据和（或）产生同一个输出数据，则称为【通信内聚】高内聚也分为两类：如果一个模块内的处理元素和同一个功能密切相关，而且这些处理必须顺序执行，则称为【顺序内聚】 。根据数据流图划分模块时，通常得到顺序内聚的模块，这种模块彼此间的链接往往比较简单。如果模块内所有处理元素属于一个整体，完成一个单一的功能，则称为【功能内聚】 。功能内聚是最高程度的内聚。4、启发式规则：改进软件结构提高模块的独立性。模块规模应该适中。深度、宽度、扇出、扇入都应适当。模块作用域应该在控制域之内力争降低模块接口的复杂程度设计单入口单出口的模块模块功能可以预测5、描绘软件结构的图形工具： 层次图 、HIPO 图 、结构图6、数据流的设计步骤：（信息流的类型：变换流 、事务流）步骤： 复查基本系统模型 复查并精化数据流图 确定数据流图具有变换特性还是事务特性 确定输入流和输出流的边界，从而孤立出变换中心 完成“第一级分解” 。变换型数据流图被映射成一个输入、变换和输出的信息处理过程 完成“第二级分解” 。把数据流图中的每个处理映射成软件结构中一个适当的模块 使用设计度量和启发式规则对第一次分割得到的软件结构进一步精化。第六章 详细设计1、详细设计阶段的根本目标是确定应该怎样具体的实现所要求的系统。2、过程设计的工具（会画图 P124）【程序流程图】【盒图】特点：功能域明确，可以从盒图一眼看出不可能任意转移控制很容易确定局部和全程数据的作用域很容易表现嵌套关系，也可以表示模块的层次结构【PAD 图】问题分析图。优点：P126【判定表】能够清晰地表示复杂的条件组合与应做的动作之间的对应关系。【判定树】优点在于，它的形式简单到不需任何说明，一眼就可以看出其含义，因此易于掌握和使用。第七章 实现1、软件测试的目标测试是为力发现程序中的错误而执行程序的过程。好的测试方案是极可能发现迄今为止尚未发现的错误的测试方案。成功的测试是发现了至今为止尚未发现的错误的测试。2、软件测试准则所有测试都应该能追溯到用户的需求。应该远在测试开始之前就制定出测试计划把 Prareto 原理应用到软件测试中应该从“小规模”测试开始，并逐步进行“大规模”测试穷举测试是不可能的3、软件测试方法黑盒测试是把程序看作一个黑盒子，完全不考虑程序的内部结构和处理过程。就是说，黑盒测试是在程序接口进行的测试，它只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数据并产生正确的输出信息，程序运行过程中能否保持外部信息的完整性。黑盒测试又称为功能测试。白盒测试正好相反，它的前提是可以把程序看成装在一个透明的白盒子里，测试者完全知道程序的结构和处理算法。这种方法按照程序内部的逻辑测试程序，检测程序中的主要执行通路是否都能按预定要求正确工作。白盒测试又称为结构测试。4、软件测试步骤模块测试子系统测试系统测试验收测试平行运行5、单元测试的五个方面模块接口局部数据结构重要的执行通路出错处理通路边界条件软件可靠性是程序在给定时间间隔内，按照规格说明书的规定成功地运行的概率。软件可用性是程序在给定的时间点，按照说明书的规定，成功的运行的概率。第八章 维护1、软件维护（四项活动）把诊断和改正错误的过程称为【改正性维护】 。【适应性维护】 ，也就是为了和变化了的环境适当地配合而进行的修改软件的活动，是既必要又经常的活动当一个软件系统顺利地运行时，常常出现第三项活动：在使用软件过程中用户往往提出增加新功能货修改已有功能的建议，还可能提出一般性的改进意见。为了满足这类要求，需要进行【完善性维护】 。这项为何活动通常占软件维护工作的大部分。当为了改进为了的可维护性或可靠性，或为了给未来的改进奠定更好的基础而修改软件时，出现了第四项维护工作【预防性维护】 ，目前相对较少。2、软件的可维护性：可理解性可测试性可修改性可移植性可重用性