前言：此文档为个人大学时期应付期末考试时自行总结，用于理解并背诵相应的基本概念。一些计算和画图之类的内容需要结合书本例题进行复习，多做习题深刻掌握。中间大标题为老师给出的考纲中建议每一章需要掌握的一些知识点。
如若需要doc文档版打印复习，请留言或私信本人。。
第一章：
软件危机的概念 表现
软件工程的概念 内容 两种方法学 基本要素
软件生命周期的三个时期和8个阶段 软件过程模型
♣软件危机（软件萧条或软件困扰）是指在计算机开发和维护过程中所遇到的一系列严重的问题。它包含两方面的问题：①如何开发软件，以满足对软件日益增长的需求；②如何维护数量不断膨胀的已有软件。
♣软件危机的典型表现：
- 对软件开发成本和精度的估计常常不准确
- 用户对“已完成的”软件系统不满意的现象经常发生
- 软件产品的质量往往靠不住
- 软件常常是不可维护的
- 软件通常没有适当的文档资料
- 软件成本在计算机系统总成本中所占的比例逐年上升
- 软件开发生产率提高的速度，远远跟不上计算机引用速度普及深入的趋势
☺产生软件危机的原因：①软件本身的特点（如缺乏可见性、规模庞大）②软件开发与维护的方法不正确（主要原因：在实践中或多或少地采用了错误的方法和技术，错误的认识和做法主要表现在：忽视软件需求分析）③对软件生命周期认识不够④未能正确理解软件成分⑤修改代价⑥开发人员轻视维护⑦软件开发技术落后⑧软件管理技术差
☺生命周期：通常把软件经历从定义、开发、使用和维护，直到最终被废弃，这一漫长的时期称为生命周期。
☺软件生命周期的过程：问题定义（解决的问题是什么）---可行性研究（是否存在可行的解）---需求分析（说明系统必须做什么，与用户密切配合，得出经过用户确认的系统逻辑模型，另外还要产生规格说明书）---总体设计（概括的说，应该怎样实现目标系统。这一步确定了解决的问题策略及目标系统中应包含的程序。还需要设计程序的体系结构，包括有哪些模块组成以及模块间的关系）---详细设计（怎样具体地实现这个系统。设计出程序的详细规格说明。详细地涉及每个模块，确定每个模块功能所需要的算法和数据结构）---编码和单元测试（写出正确的容易理解、容易维护的程序模块。把详细设计的结果翻译成用选定的语言书写的程序，并且仔细测编写出的每一个模块）---综合测试（包括集成测试和验收测试、另外要用正式的文档把软件测试的过程数据记录下来）----运行维护（4类软件维护活动：改正性维护、适应性维护、完善性维护、预防性维护。每次维护活动都要准确记录下来，作为正式的文档资料加以保存）
每一次维护活动本质上都是一次压缩和简化了的定义和开发过程。
♣软件生命周期的三个时期和8个阶段
软件定义：问题定义、可行性研究、需求分析
软件开发：总体设计、详细设计、编码和单元测试、综合测试（系统设计、系统实现）
软件维护：运行维护
♣软件配置主要包括程序、文档和数据等成分；软件是程序、数据以及相关文档的完整集合
1983年IEEE为软件下的定义是：计算机程序、方法、规则、相关文档资料以及在计算机上运行程序时所必需的数据。其中方法和规则通常是在文档中说明并在程序中实现的。
软件工程正是从管理和技术两个方面研究如何更好地开发和维护计算机软件的一门新兴学科。
♣软件工程的概念：
一般定义：软件工程是知道计算机软件开发和维护的一门学科。采用工程的概念、原理、技术和方法来开发与维护软件，把经过时间考验而证明正确的管理技术和当前能够得到的最好的技术方法结合起来，以经济地开发出高质量的软件并有效地维护它，这就是软件工程。
两个典型定义：
①1968年在第一届NATO会议上提到：软件工程就是为了经济地获得可靠的且能在实际机器上有效地运行的软件，而建立和使用完善的工程原理。
②1993年IEE进一步给出了一个更全面更具体的定义：软件工程是：①把系统的、规范的、可度量的途径应用于软件开发、运行和维护过程，也就是把工程应用于软件；②研究①中提到的途径。
☺软件工程的7条基本原理：
用分阶段的生命周期计划严格管理；坚持进行阶段评审；实行严格的产品控制；采用现代程序设计技术；结果都能清除地审查；开发小组的人员应该少而精；承认不断改进软件工程实际的必要性；
当改变需求时候，为了保持软件各个配置成份的一致性，必须实行严格的产品控制，其中主要是实行基准配置管理。所谓基准配置又名基线配置，它们是经过阶段评审后的软件配置成分。基准配置管理也称为变动控制：一切有关修改软件的配置，特别是涉及对基准配置的修改建议，都必须按照严格的规程进行评审，获得批准以后才能实行修改。
♣软件工程包括技术和管理两方面内容。
♣软件工程方法学包含3个要素：方法、工具和过程
☺通常把在软件生命周期全过程中使用的一整套技术方法的集合称为方法学，也称为范型。
♣目前使用最广泛的软件工程方法学，分别是传统方法学和面向对象方法学。
传统方法学（又名生命周期方法学或结构化范型）：阶段1完成且合格---阶段2才能开始--每个阶段都得技术审查和管理复审--并且没个阶段是相互独立的。它强调自顶向下顺序地完成软件开发的各阶段任务。（面向行为、面向数据二者其一）
面向对象方法学开发软件的过程，是一个主动地多次反复迭代的演化过程。（既可以面向行为又可面向数据，它把数据和行为看成同等的重要）
面向对象方法学=对象+类+继承+用消息通信
面向对象方法学简化了软件开发和维护，提高了软件的可重用性
☺软件过程是为了获得高质量软件所需要完成的一系列任务的框架，它规定了完成各项任务的工作步骤；ISO9000把过程定义为：使用资源将输入转化为输出的活动所构成的系统。系统的含义是广义的：系统是相互关联或相互作用的一组要素。
☺通常使用生命周期模型简洁第描述软件过程。生命周期模型规定了把生命周期划分成哪些阶段及各个阶段的执行顺序，因此，也称为过程模型。
♣软件过程模型：瀑布模型、快速原型模型、增量模型、螺旋模型、喷泉模型
瀑布模型（文档驱动模型）清楚地区分逻辑设计与物理设计，尽可能推迟程序的物理实现，
（带有反馈环） 是按照瀑布模型开发软件的一条重要的指导思想
（传统生命周期方法学）但最终开发出来的软件产品可能不是用户真正需要的
快速原型模型（不带反馈环）快速建立一个能够反映用户主要需求的原型系统，让用户在计算机上试用它，通过时间来了解目标系统的概貌。通常用户使用原型系统之后会提出许多修改意见，开发人员按照用户意见快速地原型系统，然后继续重复上述步骤，直到用户认为可以，然后就根据这个原型书写规格说明文档。
它基本能够做到线性顺序开发。
增量模型（分批向用户提交产品）一次开发一部分功能，一个功能当成一个构建。软件产品被分成多各构件。分解需要遵守的唯一的约束条件：当把新构建集成到现有软件中时，所形成的产品必须是可测试的。但是把现有的每个新的增量构建集成到现有的软件体系结构中的时候，必须不破坏原来已经开发出的产品。软件体系结构必须是开放的（开放的话更好维护但是也很困难实现）
螺旋模型（风险驱动模型）使用原型及其他方法来尽量降低风险。理解这个模型：把它看作是在每个阶段之前都增加了风险分析的快速原型模型。主要适用于内部开发的大规模软件项目。（只有开发人员具有风险分析和排除分析的经验以及专门知识时，使用这种模型才会成功）
喷泉模型（面向对象）迭代是软件开发过程中普遍存在的一种内在属性。喷泉这个词体现了面向对象软件开发过程迭代和无缝的特性。面向对象范型经常要求对开发活动进行迭代或求精。
第二章：（成本只是预期工程总成本的5%-10%）（是什么）
可行性研究的三个方面
系统流程图
数据流图（DFD）
☺可行性研究的目的，就是用最小的代价在尽可能段的时间内确定问题是否能够解决。
步骤：澄清问题定义--导出系统逻辑模型--从逻辑模型探索若干主要解法--探索每一个解法的可行性。
复查系统规模和目标--研究目前正在使用的系统（只需要了解系统做什么、为什么怎么做以及代价，另外注意记录本系统与其他系统的接口）--导出新系统的高层逻辑模型（数据流图和数据字典共同定义了新系统的逻辑模型）--进一步定义问题（分析员和用户一起再次复查，然后循环前四个步骤，直到提出的逻辑模型完全符合系统目标）--导出和评价供选择的解法（从3方面考虑，最后为筛选出的系统指定实现进度表，这个表只需要估计生命周期每个阶段的工作量）--推荐行动方针（分析员推荐最好的一种解法并说明理由）--草拟开发计划（分析员为自己推荐的系统草拟一份开发计划）--书写文档提交审查（把上述可行性研究的各个步骤的工作结果写成清晰的文档，最后请用户、客户组织的负责人及评审组审查）
♣一般，从下述3个方面研究每种解法的可行性：
技术可行性：现有技术可以实现吗？
经济可行性：经济效益>开发成本？
操作可行性：系统操作方式在这个用户组织内行得通吗？
☺分析员应该为每个可行的解法指定一个粗略的实现进度。
☺可行性研究最根本的任务是对以后的行动方针提出建议。
♣系统流程图是概括地描绘物理系统的传统工具。（因为进入设计阶段以后应该把设想的新系统的逻辑模型转变成物理模型，所以需要描绘未来的物理系统的概貌）
☺系统流程图在表达分析员对现有系统的认识和描绘他对未来的系统的设想时是一个很好的工具。
♣系统流程图实质上是物理数据流图。它描绘组成系统的主要舞力元素以及信息在这些元素间流动和处理的情况。
☺系统流程图的基本思想是用图形符号以黑盒子的形式描绘组成系统的每个部件（程序、文档、数据库、人工过程等）
☺系统流程图表达的是数据在系统各部件之间流动的情况，而不是对数据进行加工处理的控制过程。
☺面对复杂系统时候，一个比较好的办法就是分层次的描绘这个系统。首先用一张高层次的系统流程图描绘系统总体概貌，表明系统的关键功能。然后把每个关键功能扩展到适当的详细程度，画在单独的一页纸上。
♣数据流图DFD是一种图形化技术，它描绘信息流和数据从输入移动到输出过程中所经受的变换。
♣在数据流图中没有任何具体的物理部件，它只是描绘数据在软件中流动和被处理的逻辑过程。
☺数据流图是系统逻辑功能的图形表示。它是分析员与用户之间极好的通信工具。设计数据流图的时候只需要考虑系统必须完成的基本逻辑功能，完全不需要考虑怎样实现这些功能。
☺数据流图的4种基本符号：正方形（立方体）表示源点/终点、圆角矩形（或圆形）表示变换数据的处理、开口矩形（或两条平行横行啊）表示数据存储、箭头代表数据流，即数特定数据流动的方向。
☺在数据流图中应该秒回所有可能的数据流向，而不应该描绘出现某个数据流条件。
☺处理并不一定是个程序。 一个数据存储也并不等同于一个文件。
数据存储和数据流都是数据，仅仅所处的状态不同，数据存储是处于静止状态的数据，数据流是处于运动中的数据。
通常DFD图中忽略出错处理。数据流图的基本要点是描绘“做什么”，而不考虑“怎样做”。
☺数据流图还有几种附加的符号：星号（*）表示数据流之间是与的关系（同时存在）
加号（+）表示或关系
异或（⊕）表示只能从中选一个（互斥关系）
☺任何计算机系统本质上都是信息处理系统，也就是说计算机系统本质上都是把输入数据变换成输出数据。
☺绘制数据流图的四个步骤：（自顶向下的画，先抽象再细化具体）
1、确定4种成份
2、绘制抽象的数据流图
3、划分处理
4、把处理再次细分
☺处理和数据存储都加了编号，这样做的目的是便于引用和追踪。
☺当进一步分解将涉及如何具体实现一个功能的时候就不再分解了
☺当数据流图分层细化时必须保持信息连续性，也就是分解处理的时候，分解前和分解后的输入输出数据必须相同。
☺给数据流图的成份起名字的时候应该注意：
- 为数据流（或数据存储）命名
名字要代表整个xx的内容而不是仅仅反映它的某些成分
不要使用空洞、缺乏具体含义的名字
起名困难可能是分解不恰当
- 为处理命名
先为数据流命名，再为与之关联的处理命名
名字应该反映整个处理的功能，而不是它一部分的功能
名字中仅包含一个动词。两个动词需要分解成连个处理
起名困难可能是分解不恰当
☺画数据流图的用途：
☺画数据流图的基本目的是利用它作为交流信息工具
☺作为分析和设计的工具
☺从数据流图出发映射出软件结构的方法--面向数据流的设计方法
☺数据字典是关于数据信息的集合。也就是对数据流图中包含的所有元素的定义的集合。
☺任何字典的最主要的用途都供人查阅对不了解的条目的解释。数据字典的作业也正是在软件分析和设计的过程中给人提供数据的描述信息。
☺数据流图和数据字典共同构成系统的逻辑模型。
☺一般，数据字典应该由下列4类元素的定义组成：数据流、数据流分量（即数据元素）、数据存储、处理。
☺虽然应该尽量减少使用别名，但是我们不能完全消除它。
☺定义数据元素就是对数据自顶向下的分解。
☺数据元素组成数据的方式只有下列3中基本类型：顺序、选择、重复、可选
☺=意思是等价于（或定义为）+意思是和（即连接两个分量）
[ ]意思是或（从方括弧内列出若干个分量中选择一个，通常使用“|”来间隔）
{ }意思是重复（即重复花括弧内的分量）
（）意思是可选（即圆括弧里的分量可有可无）
通常使用上限和下限进一步注释表示重复的花括弧。P48
☺数据字典最重要的用途就是作为分析阶段的工具。数据字典是开发数据库的第一步，而且是很有价值的一步。
☺成本/效益分析的目的正是从经济角度分析开发一个特定的新系统是否划算，从而帮助客户组织的负责人正确地作出投资于这项开发工程的决定。
☺3种成本估计方法：代码行技术、任务分解技术、自动估计成本技术
代码行技术：每行平均代码的平均成本*代码行数
任务分解技术：总成本=求和单独任务成本 ；每个单独任务的开发成本=求和人力*每人每月的工资 （综合测试阶段需要的人力最多）
自动估计成本技术：要长期搜集的大量历史数据为基础
第三章：（做什么）
需求分析的任务
软件需求规格说明书
建立三种模型
验证软件需求
♣需求分析是软件定义时期的最后一个阶段。它的基本任务是准确地回答“系统必须做什么”。
♣需求分析的任务仅仅是确定系统必须完成那些工作，也就是对目标系统提出完整、准确、清晰、具体的要求。（需求分析阶段，要写出软件需求规格说明书）
♣需求分析是发现、求精、建模、规格说明和复审的过程
☺所有的分析方法都遵循下述准则：
必须理解并描述问题的信息域，因此要建立 数据模型 (实体-联系图 ER图)
必须定义软件应该完成的功能，因此要建立 功能模型 (数据流图 DFD图)
必须描述作为外部世界结果的软件行为，因为此要建立 行为模型 (状态图)
必须对描述信息、功能、行为的模型进行分解，用层次的方式展示细节
♣需求分析的任务
①确定对系统的综合要求
功能需求、性能需求。可靠性和可用性需求、出错处理需求、接口需求、约束、
逆向需求、将来可能提出的需求
②分析系统的数据要求
分析系统的数据要求通常采用建立数据模型的方法。
数据结构表示数据元素之间元素的逻辑关系。
常用的图形工具层次方框图和Warnier描绘数据结构。
③导出系统的逻辑模型
通常用数据流图、实体联系图、状态转换图、数据字典和主要处理算法描述逻辑模型。
④修正系统开发计划
☺用户沟通获取需求的方法（4种）
- 访谈（正式和非正式） 情景技分析技术 （用户被动）
- 面向数据流自定向上求精 结构化分析方法 （把DFD分析到数据元素级，分析员分析讲解DFD、IPO、数据字典给用户，通过功能分解完善细化他们。）（用户被动）
- 简易的应用规格说明技术 面向团队的需求收集法（用户和分析员密切合作）
- 快速建立软件原型 （快速原型的两个特性：快速、容易修改）
快速地构建和修改原型的3种方法和工具：
第四代技术（较理想）、可重用的软件构建（已有的一组构建来装配原型，不关注细节，只是用工鞥呢）、形式化规格说明和原型环境
♣结构化分析实质上就是一种建模活动，在需求分析阶段通常建立数据模型、功能模型、行为模型。
♣多数用实体-联系图建立数据模型、数据流图建立功能模型、状态图建立行为模型。
☺实体-联系图：描绘数据对象及数据对象之间的关系。（包含了实体、关系、属性3中基本成分）
关系用菱形 实体用矩形 属性用椭圆 联系用直线
数据流图：描绘当数据在软件系统中移动时被变换的逻辑过程，指明系统具有的变换数据的功能。
状态转换图：指明了外部事件结果的系统行为
一张状态转换图只能一个初态，而终态则可以有0至多个。
描绘 系统循环过程：不关心系统怎样启动 单生命周期：要标明初态终态
☺需求分析阶段可能用到的其他图形工具
描绘信息层次结构：层次方框图（调用关系）、warnier图（可说明重复出现、条件约束）
描绘算法的有效工具：IPO图
♣从哪些方面验证软件需求的正确性：一致性、完整性、现实性、有效性
一致性（形式化的描述） 现实性（仿真或性能模拟技术）完整和有效性（快速建立原型）☺数据字典描述在数据模型、功能模型和行为模型中出现的数据对象及控制信息的特性给出他们的精确定义。
第五章：（系统如何实现？怎么做 确定模块和模块之间的关系）
总体设计的两个阶段
设计原理
描绘软件结构的图形工具
☺总体设计阶段的基本目的是用比较抽象概括的方式确定系统如何完成预定的任务，也就是说，应该确定系统的物理配置方案，并且进而确定组成系统的每个程序的结构。
♣总体设计过程通常由两个主要阶段组成：系统设计阶段和结构设计阶段
系统设计阶段：确定系统具体实现方案 结构设计阶段：确定软件结构
♣结构设计是总体设计阶段的任务 过程设计是详细设计阶段的任务
☺总体设计过程包括下面9个步骤
- 设想供选择的方案
- 选取合理的方案（要准备：系统流程图、组成系统的物理元素清单、成本/效益分析、实现这个系统的进度计划）
- 推荐最佳方案（要为推荐且通过的方案制详细的实现计划）
- 功能分解（为确定软件结构要细化DFD同时要用IPO图和其他工具简要描述细化后每个处理的算法）
- 设计软件结构（描绘模块组成的系统（调用关系）：层次图或结构图 他们用这些来映射软件结构 ；淡入如何DFD已经细化到一定程度那么可以直接映射成软件结构 这就是面向数据流设计）
- 设计数据库
- 指定测试计划（测试先行）
- 书写文档
- 审查和复审 （技术审查 管理复审（用户））
♣设计原理（应该遵循的基本原理和相关概念）
模块化、抽象、逐步求精、信息隐藏和局部化、模块独立
♣模块是有边界元素限定的相邻程序元素
♣按照模块的定义，过程，函数，子程序和宏等，都可以作为模块
♣模块是构成程序的基本构建
♣把复杂问题分解成许多容易解决的小问题，原问题也就容易解决了。记得接口
♣每个程序都相应地有一个最适当的模块数目M，使得系统的开发成本最小。
♣抽象就是抽象事务本质特效而暂时不考虑它们的细节。
♣逐步求精定义为：为了能集中精力解决主要问题而尽量推迟对问题细节的考虑。
♣Miller法则:一个人在任何时候都只能把注意力集中在（7±2）个知识块上。
♣可以把逐步求精看作是一项把一个是时期内必须解决的种种问按优先级排序的技术
♣求精实际上就是细化过程。 逐步求精（自顶向下的设计过程）
♣抽象与求精是一对互补的概念。抽象使设计者忽略低层细节。求精帮助设计者揭示它。
♣信息隐藏原理：一个模块内包含的信息（过程和数据）对于不需要这些信息的模块来说，是不能访问的。
♣局部化是指把一些关系密切的软件元素物理地放得彼此靠近。
♣局部化有利于实现信息隐藏。隐藏的是模块的实现细节，有助于维护和修改。
♣模块独立的概念是模块化、抽象、信息隐藏和局部化概念的直接结果。
♣模块独立是好设计的关键，而设计又是决定软件决定质量的关键环节。
♣在进行软件结构设计时应该遵循的最主要的原理是模块独立原理。
♣模块独立程度的两个定性标准：内聚和耦合。
♣耦合：衡量不同模块彼此间互相依赖（连接）的紧密程度
♣内聚：衡量一个模块内部各个元素彼此结合的紧密程度。
♣类型：数据耦合、控制耦合、特征耦合、公共环境耦合、内容耦合
♣内容耦合不允许出现，有下列情况之一表示有：
一个模块访问另一各模块的内部数据
一个模块不通过正常入口而转到另一个模块的内部
两个模块有一部分程序代码重叠（只可能出现在汇编程序中）
一个模块有多个入口（这意味着一个模块有几种功能）
♣类型：偶然内聚、逻辑内聚、时间内聚、过程内聚、通信内聚、顺序内聚、功能内聚
♣设计“力争高内聚、低耦合”
♣启发式规则（有益于改进软件设计质量）
改进软件结构提高模块独立性、模块规模应该适中、深度宽度扇出扇入都应该适当
力争降低模块接口的复杂程度、设计单入口单出口的模块（不要出现内容耦合）、模块功能应该可以预测
♣深度：表示图案简洁口中控制的层数
♣宽度：软件结构内同一个层次上的模块总数的最大值
♣扇出：一个模块直接控制（调用）的模块数目
♣扇入：表示有多少个上级模块直接调用它
♣一个设计的好的典型系统的平均扇出通常是3或4（扇出上限是5-9）
♣扇出太大，适当增加中间模块 扇出太小，分解或合并
♣扇入越大则共享该模块的上级模块数目越多
♣通常，顶层扇出比较高，中层扇出较少，底层扇入到公共的使用模块中去（底层模块有高扇入）
♣模块的作用域定义为受该模块内一个判断影响的所有模块的集合
♣模块的控制域是这个模块本身以及所有直接或间接从属于它的模块得集合
♣作用域要在控制域内。（不符合则适当调整）
♣描绘软件结构的图形工具：层次图、HIPO图、结构图
☺层次图结构图都表示调用关系、描绘软件的结构常用工具）层次图是描绘软件层次结构。
☺HIPO图：H表示层次图（有编号），再为对应每个编号的模块画IPO图
☺结构图：有注释、默认上面调用下面的。空心圆表示传递的是数据、实心圆是控制信息
☺层次图和机构图只表明一个模块调用那些模块。至于模块内还有没有其他模块完全没表示。从左到右也不是调用顺序。
☺层次图通常作为描绘软件结构的文档 结构图作为文档并不是很合适（信息多清晰度低）
♣面向数据流的设计方法（DFD细化到一定程度 那么DFD可以直接映射成软件结构）
♣面向数据流的设计方法的目标是给出设计软件结构的一个系统化的途径。
♣结构化设计方法（SD）也是基于数据流的设计方法
☺变换流：外部-内部-外部形式 事务流：有处理T时事务变换中心 输入-T-选择对应通路
♣变换分析和事务分析
☺设计优化应该力求做到在有效的模块化的前提下使用最少量的模块，以及在能够满足信息要求的前提下使用最简单的数据结构，
♣映射软件结构：
如果有了详细的DFD图，可以用面向数据流的设计方法，用形式化方法有DFD映射出软件结构。（这只是初步的软件结构，然后再根据设计原理和启发式规则修改就好了）
如果没有就用工具：细化DFD图 用层次图、结构图之类的
第六章：（系统是如何具体实现的？每个模块的处理过程是怎样的）
结构化程序设计
过程设计工具
程序的环形复杂度（3种计算方法）
☺详细设计阶段的根本目标是确定应该怎样将具体地实现所要求的系统
☺详细设计的结果基本上决定了最终的程序代码的质量
☺详细设计阶段的任务是要设计出程序的“蓝图”，程序员以后根据这个“蓝图”写出实际的程序代码。
☺详细设计的目标不仅仅是逻辑上正确地实现每个模块的功能，更重要的是设计出处理过程应该尽可能简明易懂。
☺结构化程序设计技术是实现上述目标的关键技术，因此是详细设计的逻辑基础
♣结构化程序设计有三种基本的控制结构是“顺序”、“选择”、和“循环”
♣结构化程序的经典定义：如果一个程序的代码块仅仅通过顺序、选择和循环这3种基本控制结构进行连接，并且每个代码只有一个入口和一个出口，则称这个程序是结构化的。
♣结构程序设计的定义可能更全面：结构程序设计是尽可能少用GO TO语句的程序设计方法。最好仅在检测出错误时才是用GO TO语句，而且应该总是使用向前GO TO语句。
☺经典的结构程序设计：IF_THEN_ELSE型分支/顺序/DO_WHILE循环
扩展的结构程序设计：基本3种+DO_CASE型分支/DO_UNTIL型分支
修正的结构程序设计：上面的+LEAVE(或BREAK)结构
☺设计问题：系统响应时间，用户帮助设施、出错信息处理、命令交互
☺人机界面设计指南：一般交互指南、信息显示指南、数据输入指南
♣描述程序处理过程的工具过程设计工具，它可以分为图形、表格和语言3类。
♣工具的基本要求：能提供设计的无歧义的描述，也就是应该能知名控制流程、处理功能、数据组织以及其他方面的实现细节
♣图形：程序流程图、盒图（N-S图）、PAD图（问题分析图）
表格：判定树、判定表
语言：PDL（伪码）
☺使用表示结构化控制结构的PAD符号所设计出来的程序必然是结构化程序
☺PAD图中的竖线的总条数就是程序的层次数
☺判定表能够清晰地表示复杂的条件组合与应做的动作之间的对应关系。但它并不适用于作为一种通用的设计工具，没有一种简单的方法使它能同时清晰地表示顺序和重复等处理
☺判定树的简洁性不如判定表。但能够一眼就看出它的含义。它的叶子结点就是动作
☺PDL具有严格的关键字外部语法，用于定义控制结构和数据结构
♣面向数据结构的设计方法：Jason方法、Warnier方法
♣程序复杂度的定量度量可以进一步仔细衡量详细设计阶段之后每个模块的质量
♣流图：主要用来计算程序环形复杂度，实质上是退化了的程序流程图。
♣计算环形复杂度的3种方法：
流图中的线性无关的区域数=环形复杂度
边数—结点数+2=环形复杂度
判定结点+1=环形复杂度
♣环形复杂度V(G)=10是模块规模的合理上限
☺过程设计应该在数据设计、体系结构设计和接口设计完成之后进行，它的任务是设计解题的详细步骤（即算法），它是详细的设计阶段应完成的主要工作。
第七章：（实现：编码、测试）
实现两个阶段
软件测试的目标
测试的方法/技术
测试步骤
♣通常把编码和测试统称为实现
☺程序的质量主要取决于软件设计的质量
☺测试的目的就是在软件投入生产性运行之前，尽可能多地发现软件中的错误
☺软件测试仍然是保证软件质量的关键步骤，它是对软件规格说明、设计和编码的最后复审
♣软件测试在软件生命周期横跨两个阶段：
① 编码和单元测试（模块的编写者和测试者是同一个人或审查小组（编写者也会参与））
② 综合测试（包括集成测试和验收测试 是专门的测试人员参与的）
☺调试就是把症状和原因联系起来的尚未被深入认识的智力的过程
☺通过测试发现错误之后还必须诊断并改正错误，这就是调试的目的。
☺调试时是测试阶段最困难的工作。调试不是测试
☺调试的任务：在测试过程中发现团建错误必须及时改正
☺调试途径：蛮干法、回溯法、原因排除法
☺编码：选择程序设计语言、编码风格
☺高级程序设计语言较汇编语言有很多优点（除非在一些非常必要的场合，不然都用前者）
☺程序内部的良好文档资料、有规律的数据说明格式。简单清晰的语句构造和输入输出格式等，都对提高程序可读性有很大作用，用时改进了可维护性。
☺软件工程其他阶段都是“建设性”的，从抽象逐步设计系统再到写可执行的代码
测试阶段测试人呀u能写出测试方案目的是为了“破坏”已经构造好的软件系统，竭力证明程序中有错误，不能按照预定要求正确工作。
♣测试阶段的根本目标：尽可能多地发现并排除软件中潜藏的错误，最终把一个高质量的软件系统交给用户使用。
♣软件测试正确的定义：为了发现程序中的错误而执行程序的过程
♣测试阶段的根本任务是发现并改正软件错误
♣测试的目标是：暴露程序中的错误。
☺测试决不能证明程序是正确的，测试只能查找出程序中的错误，不能证明程序中没有错误。
☺穷尽测试就是把程序所有可能的执行路径都检查一遍的测试。
♣测试方法：黑盒测试 白盒测试
☺黑盒测试：如果已经知道了产品应该具有的功能，可以通过测试来检验是否每个功能都能正常使用。
☺白盒测试：如果知道产品的内部工作过程，可以通过测试来检验产品内部动作是否按照规格说明书的规定正常进行。
☺黑盒测试把程序看作一个黑盒子，完全不考虑程序的内部结构何处理过程。
☺白盒测试把程序看成装在一个透明的白盒子里，测试者完全知道程序的结构和冲击力算法。
♣测试步骤：模块/单元测试->子系统测试->系统测试->验收测试（确认测试）->平行运行
☺子系统测试和系统测试，都兼有检测和组装的含义，通常称为集成测试
☺平行运行就是同时运行新开发出来的系统和将被它取代的旧系统，以便比较新旧两个系统的处理结果，
☺测试方案：不仅仅把测试时使用的输入数据（称为测试用例），还应该包括每组输入数据预定要检验的功能，以及每组输入数据与其应该得到的正确输出。
☺大型软件的测试应该分阶段地进行，通常至少分为单元测试/系统测试/验收测试3阶段
☺单元测试主要使用白盒测试技术
♣白盒测试技术有两种：代码审查（人工测试）、计算机测试（驱动程序、存根程序）
☺驱动程序：接收测试数据 存根程序：简化地模拟这些下层模块（代替底层次的模块）
♣集成测试是测试和组装的系统化技术。
♣模块到程序有两种方法：非渐增式测试 渐增式测试
♣渐增式：自顶向下（存根）、自底向上（驱动）
☺集成测试策略：混合策略（改进的自顶向下测试方法、混合法（上自顶向上 下自底向上）））
☺回归测试是指重新执行以及做过的测试的每个自己，保证上述那些变化没有带来非预期的副作用。
☺确认测试使用黑盒测试技术。
☺确认：为了保证软件确实满足用户需求而精彩的一系列活动
☺验证指的是保证软件确实满足了用户需求而进行的一系列活动
☺软件有效性：如果软件的功能和性能如同用户所合理期待的那样。
☺确认测试的一个重要内容是复查软件配置。目的是保证软件配置的所有成分完全。
☺验收测试的两种：Alpha测试（受控）、Bata测试（不受控）
☺所谓的测试方案包括具体的测试目的，应该输入的测试数据和预期结果。
☺通常把测试数据和预期的输出结果称为测试用例
♣白盒测试技术：逻辑覆盖、基本路径测试、条件测试
逻辑覆盖：语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖、点覆盖、边覆盖、路径覆盖
控制结构测试：基本路径测试、条件测试、循环测试
♣黑盒测试技术：等价划分、边界值分析、错误推测
☺软件可靠性：程序在给定的时间间隔内，按照规格说明书的规定成功地运行的概率、
☺软件可用性：程序在给定的时间点，按照规格说明书的规定成功运行的概率。
☺程序中潜在的错误的数目，直接决定了软件的可靠性，
☺估计错误总数的方法： 植入错误法 分别测试法
☺
第8章：维护
软件维护的概念
四类维护活动
♣所谓软件维护就是在软件已经交付使用之后，为了改正错误或满足新的需求而修改软件的过程。
♣四类维护活动：改正性维护、适应性维护、完善性维护、预防性维护、
☺软件维护的特点：非结构化维护（开发过程没有文档）、结构化程序（开发过程有文档）
☺维护过程本质上是修改和压缩了的软件定义和开发过程。
☺软件维护过程：维护组织--维护报告--维护的事件流--保存维护记录--评价维护活动
☺所谓的“救火”维护要求，这种情况需要立即把资源用来解决问题
♣软件的可维护性定义为：维护人员理解、改正、改动或改进这个软件的难易程度.
♣软件可维护性的因素：可理解性、可测试性、可修改性、可以移植性、可重用性
☺软件系统的文档可以分为用户文档和系统文档。
☺用户文档主要描述系统功能和使用方法，并不关心这些功能是怎样实现的
☺系统文档描述系统设计、实现和测试等各方面的内容
♣可维护性是所有软件都应该具备的基本特点，必须在开发阶段软件具有可维护性因素。
♣在设计和编码过程中应该尽量使用可重用的软件构建，如果需要开发新的构建，也应该注意提高构件的可重用性。
♣软件再工程：重建
♣局部的再工程：部分重建
♣预防性维护方法是Miller提出来的，他把这种方法定义为：把今天的方法学应用到昨天的系统上，以支持明天的需求。
♣典型的软件再工程过程定义了6类活动：库目录分析、文档重构、逆向工程、代码重构、数据重构、正向工程。
第10章：OOA
☺分析就是提取系统需求并建立问题域精确模型的过程。
☺分析工作主要包括3项内容：理解、表达和验证
☺分析的目标是全面深入第理解问题域，其中不应该设计具体实现的考虑
☺分析过程得出的最重要的文档资料是软件需求规格说明
☺需求分析过程是系统分析员与用户及领域专家反复交流和多次修正的过程。
☺理解和验证的过程通常交替进行，反复迭代。
♣在面向对象分析中，主要有对象模型、动态模型和功能模型组成
☺OOA的关键是识别出问题域内的类与对象，并分析它们相互间的关系，最终建立问题域的正确模型。
♣对象模型是最基本、最重要、最核心的、
♣面向对象分析就是抽取和整理用户需求并建立问题域精确模型的过程
☺面向对象分析从分析陈述用户需求的文件开始。（需求陈述一般不完整、非正式）
☺分析需求陈述的过程中一般反复迭代且利用原型，准确提炼用户的需求
☺OOA（需求陈述--抽象建模--认真向专家学习）
♣面向对象建模得到的模型包含3个要素：静态结构、交互次序、数据变换
♣对应3个子模型 ：（对象模型、动态模型、功能模型）
类图 DFD/用例图 状态图
♣大型复杂的对象模型通常有5个层次：主体层、类与对象层、结构层、属性层、服务层
☺面向对象分析从下述两个方面来体现这条原则：控制可见性和指导读者的注意力。
♣面向对象分析过程中建立对象模型的主要活动：
寻找类与对象、识别结构、识别主题、定义属性、建立动态模型、建功能模型、定义服务
（不必按顺序进行，反复迭代，一般采用上述顺序而已，另外要和用户、专家反复交流）
☺需求陈述的内容应该阐明“做什么”，指出哪些是系统必要的性质，哪些是任选的性质，不要过多描述系统的内部结构等P233-P234上
☺系统分析员必须把需求与实现策略分开
☺需求成熟仅仅是理解用户需求的出发点，它不是一成不变的文档。
♣进行面向对象分析的目的，就是全面深入地理解问题域和用户的真实需求，建立起问题域的精确模型。
♣面向对象分析的关键工作，是分析、确定问题域中的对象及对象间的关系，并建立问题域的对象模型。
☺分析模型是系统分析员同用户及领域专家交流时有效的通信手段。
☺一个好的分析应该正确完整地反映问题的本质属性，且不包含与问题无关的内容
建立对象模型：
☺面向对象分析首要的工作，是建立问题域的对象模型。
☺对象模型描述了现实世界中“类与对象”以及它们之间的关系，表示了目标系统的静态数据结构。用面向对象方法开发软件时，一般先建立对象模型再建立另外两个模型。
☺确定类与对象：找出候选的xx--筛选出正确的xx
非正式分析：用自然语言书写的需求陈述为依据，把陈述中的名次作为类与对象的候选者，用形容词作为确定属性的线索，把动词作为服务（操作）的候选者
☺确定关联（确定类与类之间的关系 识别结构）：初步确定--筛选--进一步完善
☺划分主题：按照使不同主题内的对象相互间依赖和交互最少的原则来确定主题
☺确定属性：分析陈述--选择
☺识别继承关系：
两种方式建立（自底向上（归纳思维）划出父类 --自顶向下（演绎思维）类划出子类 ）
☺反复修改
建立动态模型：
☺编写脚本--设想用户界面--画事件跟踪图--画状态图--审查动态模型
☺编写脚本目的：保证不遗漏重要的交互步骤，有助于确保整个交互过程的正确性和清晰性
☺编写脚本的过程实质上就是分析用户对系统交互行为的要求的过程
☺脚本是指在系统在某一执行期间内出现的一系列事件
☺对于每个事件都应该指明触发该事件的动作对象、接收事件的目标对象、该事件的参数
☺大多数交互行为分为：应用逻辑（内在）和用户界面（外在）
☺完整、正确的脚本为建立动态模型奠定了必要的基础
☺状态图描绘事件与对象状态的关系 ☺由事件引起的状态改变称为转换
☺用一张状态图描绘一类对象的行为，它确定了由事件序列引出的状态序列
☺各个类的状态图通过共享事件合并起来，构成系统的动态模型
建立功能模型：
☺功能模型表明了系统中数据之间的依赖关系，以及有关的数据处理功能，它由一组数据流图组成
☺画出基本系统模型--画出功能级数据流图--描述处理框的功能
☺说明性描述规定输入值和输出值之间的关系，以及输出值应遵循的规律
☺过程性描述通过算法说明“做什么”。（说明性（不会隐含具体实现方面的考虑）描述由于过程性）
☺定义服务
第11章：OOD
♣设计是把分析阶段得到的需求转变成符合成本和质量要求、抽象的系统设计方案的过程。
☺面向对象设计就是面向对象观点建立求解域模型的过程
☺分析和设计活动是一个反复多次迭代的的过程
♣面向对象设计把设计分为：系统设计和对象设计 （界限模糊）
系统设计：确定实现系统的策略和目标系统的高层结构
对象设计：确定解空间中的类、关联、接口形式及实现服务的算法
☺优秀设计是使得目标系统在整个生命周期中总开销最小的设计，为获得优秀的设计结果，应遵循一些基本准则
♣面向对象设计的准则：模块化 抽象 信息隐藏 弱耦合 强内聚 可重用
☺抽象（4种）：过程抽象 数据抽象 规格说明抽象 参数化抽象
☺信息隐藏（接口和实现分离）
☺耦合（2类）：交互耦合（要降低 方法中的参数越低越好）、继承耦合（要提高）
☺内聚（3类）：服务内聚 类内聚 一般-特殊内聚（泛化）
♣启发规则：设计结果清晰易懂 一般-特殊结构的深度适当（7±2） 设计简单的类
使用简单的协议 使用爱你单的服务 把设计减至最小
♣重用也叫再用或复用，是指同一事物不做修改或稍加改动就多次重复使用
♣重用是提高软件生产率和目标系统质量的重要途径
♣软件重用的3个层次：知识重用、方法和标准重用、软件成份的重用
♣软件重用的3个级别：代码重用、设计结果重用、分析结果重用
♣类构件（可重用的类）的3种重用方式：实例重用、继承重用、多态重用
☺可重用的构建应该具备：模块独立性强、具有高度可塑性、接口清晰简明可靠
♣系统的主要组成部分成为子系统。各个子系统应该具有尽可能简单、明确的接口
♣面向对象设计模型4大组成部分想象成整个模型的4个垂直切片：
人机交互部分 问题与部分 任务管理部分 数据管理部分
♣OOD也可以想象成整个模型的5个水平切片
主题层、类与服务层、结构层、属性层、服务层
♣子系统之间的两种交互方式：客户-供应商关系 平等伙伴关系
♣组织系统的两种方案：水平层次组织 垂直块组织
♣层次结构分为：封闭式和开放式
☺设计问题域子系统： 多重继承模式：窄菱形模式 阔菱形模式
☺设计人机交互子系统：
☺设计任务管理子系统：
☺设计数据管理子系统：
第12章：面向对象实现（编码和测试 OOP面向对象编程）
♣面向对象实现主要包括两项工作：把面向对象设计结果翻译成用某种程序语言书写的面向对象程序；测试并调试面向对象的程序。
☺面向对象程序的质量基本上由面向对象设计的质量决定
☺面向对象测试的目标，也就是用尽可能低的测试成本发现尽可能多的软件错误
☺面向对象程序中特有的封装、继承和多态等机制
☺面向对象设计的结果既可以用面向对象语言、也可以用非面向对象语言实现
☺面向对象语言的3个优点：一致的表示方法 可重用性 可维护性
☺两大类面向对象语言：纯面向对象语言 混合型面向对象语言
☺选择面向对象语言的考虑因素：未来是否占主导地位 可重用性 类库和开发环境 其他
♣程序设计风格应该遵循的一项准则：提高可重用性、扩充性、健壮性
☺策略方法：负责做出决策没提供变元，并且管理全局资源
☺实现方法：负责完成具体的操作，但却并不作出是否执行这个操作的决定
☺继承机制：调用子过程 分解因子 使用委托 把代码封装在类中
☺所谓健壮性：就是在硬件故障、输入数据无效或操作错误等意外环境下，系统能做出适当响应的程度。（在异常情况下，软件能正常运行的能力）
☺面向对象的测试：单元测试（类和对象） 集成测试（要进行回归测试） 确认测试
☺对每个类进行单元测试，测试类时使用的方法：随机测试、划分测试、基于故障的测试
☺集成测试的两种不同策略：基于线程的测试 基于使用的测试
☺面向对象系统的确认测试也是面向黑盒的
♣面向对象方法学把分析、设计和实现很自然地联系在一起了。
第13章软件项目管理
很多工程项目失败是因为管理不善
☺所谓管理就是通过计划、组织和控制等一系列活动，合理地配置和使用过各种资源，以达到既定目标的过程
♣软件项目管理先于任何技术活动之前开始，并且贯穿于软件的整个生命周期之中
☺软件项目管理过程从一组项目计划活动开始，而制定计划的基础是工作量估算和完成期限估算。为了估算项目的工作量和完成期限，首先需要估算软件的规模
♣估算软件规模的两个技术：代码行技术 功能点技术
☺代码行技术：（L表示总代码行） 单位：代码行LOC（程序小）千代码行KLOC（程序大）
L= 最小规模a 最大规模b 最可能规模m （平均值）
☺功能点技术依据对软件信息域特性和软件复杂性的评估结果 单位：FP功能点
☺信息域5个特性：输入项数Inp、输出项数Out、查询数Inq、主文件数Maf、外部接口数
☺估算功能点（软件规模）的步骤：
计算未调整的功能点数UFP
计算技复杂性因子TCF
计算功能点数FP： FP=UFP*TCF
♣工作量是软件规模KLOC或FP的函数，工作量的单位通常是人月pm
☺没有一个估算模型可以适用于所有类型的软件和开发环境
☺静态单变量模型 动态多变量模型 COCOMO2模型
☺一个任务集合包括一组软件工程工作任务、里程碑和可交付的产品
☺项目管理者的目标是定义全部项目任务，识别出关键任务，跟踪关键任务的进展状况，以保证能及时发现拖延进度的情况。为达到上述目标，管理者必须制定一个足够详细的进度表，以便监督项目进度并控制整个项目
♣制定进度计划的两个重要工具和：工程网络和Gannt图（甘特图）
♣Gannt图
优：能够形象地描绘任务分解情况，以及每个子任务（作业）的开始时间和结束时间
是进度计划和进度管理的有力工具
具有至关简明和容易绘制、容易掌握的有点
缺：不能显示地描绘各项作业彼此间的依赖关系
进度计划的关键部分不明确，难于判断哪些部分应当是主攻和主控的对象
计划中有潜力的部分及潜力的大小不明确，往往造成潜力的浪费
♣工程网络是指定进度计划时另一种常用的图形工具，它同样能描绘任务分解情况以及每项作业的开始时间和结束时间，此外，它还显示地描绘各个作业彼此间的依赖关系。
♣工程网络图比Gannt图优越的地方：
显示地定义时间以及作业之间的依赖关系 Gannt图只能隐含地表示这种关系
Gannt图的形式比工程网络更简单更直观，为更多人熟悉
可以同时使用互相取长补短来指定和管理进度计划
♣因此，工程网络是系统分析和系统设计强有力的工具
☺引入虚拟作业是为了显示地表示作业之间的依赖关系
♣关键路径之中的任务如果被延误则整个项目会延误。
♣关键路径之外的任务如果被延误的时间不算太多（机动时间内）那么整个项目还好
♣估算工程进度
最早时刻EET=MAX{开始事件EET+持续时间} 从左往右
最迟时刻LET=MIN{结束事件LET-持续时间} 从右往左
关键路径：LET=EET
机动时间：结束事件LET-开始事件EET-持续时间
第一个事件的最早时刻EET是该事件可以发生的最早时刻
最后一个事件（工程结束）的最迟时刻LET就是它的最早时刻
♣在制定进度计划时仔细考虑和利用工程网络中的机动时间，往往能够安排出既节省资源有不影响竣工时间的进度表
☺3种典型的人员组织方式：
民主制程序组 （完全平等 小组工作和改错积极性高 采用非正式组织方式）
主程序组 （不现实 难找 小组成员工作和改错积极性低 会依赖组长 组长最后还要审查）
（两个重要特性：专业化 层次性）
现代程序组（合理常用）
☺软件质量就是“软件与明确地和隐含地定义的需求相一致的程度”
更具体地说，软件质量是软件与明确地叙述的功能和性能需求、文档汇总明确描述开发标准以及任何专业开发的软件产品都应该具有的隐含特征相一致的程度
☺软件质量保证SQA的措施：
基于非执行的测试（复审或评审）
基于执行的测试（软件测试）
程序正确性证明（数学方法）
☺任何软件开发都是迭代过程。在开发软件的过程中，变化既是必要的又是不可避免的
♣软件配置管理是在软件的整个生命期内管理变化的一组活动。
具体地说，这组活动用来：
标识变化
控制变化
确保适当地实现了变化
向需要知道这类信息的人报告变化
☺软件配置管理不同于软件维护
维护是在软件交付给用户使用后才发生的
配置管理是在软件项目启动时就开始，并且一直持续到软件退役后才终止的一组跟踪和控制活动
☺软件配置管理的目标，使变化更正确且更容易被适应，在必须变化时减少所需花费的工作量。
♣软件配置项（也就是软件过程的输出信息）
软件过程的输出信息可以分为3类；
- 计算机程序（源代码和可执行程序）
- 描述计算机程序的文档（供技术人员或用户使用）
- 数据（程序内包含的或在程序外的）
上述这些项组成了软件过程中产生的全部信息，人们把他们统称为软件配置
☺可以把软件配置管理看作是应用于整个软件过程的软件质量保证活动，是专门用于管理变化的软件质量的保证活动
☺基线就是通过了正式复审的软件配置项。
在软件配置项变成基线之前，可以迅速而非正式地修改它
一旦建立基线之后，虽然仍然可以变化但是需要引用特定、正式的过程来评估实现和验证每个变化
♣软件配置管理主要有5项任务:标识、版本控制、变化控制、配置审计和报告
♣能力成熟度CMM模型：初始级、可重复级、已定义级、已管理级、优化级
☺CMM是改进软件过程的有效策略
