《软件工程导论》学习笔记
考试大纲
1.软件工程学概述
内容：软件和软件工程的概念以及特点、软件危机概念、软件危机产生原因、软件生存周期及软件开发的各种模型。
2.可行性研究
内容：可行性研究的任务与主要工作、可行性研究的目的与步骤、系统流程图、成本/效益分析可行性研究包含的内容。
3.需求分析
内容：需求分析的描述工具和基本任务、需求分析的方法、分析建模与规格说明、需求分析的任务和原则。
4.总体设计
内容：软件设计的概念与原则、描绘软件结构的图形工具、面向数据流的设计方法、概要设计的步骤和方法。
5.详细设计
内容： 面向数据结构的设计方法、程序复杂程度的度量计算、详细设计的方法与表达工具。
6.软件编码
内容：编码原则、编码风格。
7.软件测试
内容：单元测试、集成测试、确认测试、白盒测试用例设计、黑盒测试用例设计。
8.软件维护
内容：软件维护的分类、软件维护的定义、软件维护的实施机构、软件可维护性的度量。
9.面向对象方法学
内容：面向对象的基本概念和特征、面向对象分析与设计方法、UML的基本功能与使用方法。
10.软件项目管理
内容：项目管理的概念、软件度量、软件项目的评估：成本估计、效益分析、软件风险分析和管控。
第一章、 软件工程学概述
1.1 软件危机
软件危机概念：计算机软件开发和维护过程中所遇到的一系列严重问题。
软件危机产生原因：
(1) 一方面与软件本身的特点有关： 缺乏可见性、较难维护、规模庞大。
(2) 另一方面与软件开发与维护的方法不正确有关。
软件危机的典型表现：
(1) 对软件开发成本和进度的估计常常很不准确。
(2) 用户对已完成的软件系统不满意的现象经常发生。
(3) 软件产品质量靠不住。
(4) 软件常常是不可维护的。
(5) 软件常常没有适当的文档资料。
(6) 软件成本在计算机系统总成本所占比例逐年上升。
(7) 软件开发生产率提高的速度，远远跟不上计算机应用迅速普及深入的趋势。
消除软件危机的途径：
(1) 对计算机软件要有一个正确的认识。
(2) 充分认识到软件开发应该是组织良好、管理严密、各类人员协同配合、共同完成的工程项目（非个体劳动的神秘技巧）。
(3) 开发和使用更好的软件工具。
1.2 软件工程
软件概念：软件=程序+数据+相关文档
软件特点：
(1) 软件是一种逻辑实体，是抽象的。
(2) 软件是人类智力产品。
(3) 开发过程复杂。
(4) 需长期维护。
(5) 成本昂贵。
(6) 软件可以复制。
软件工程概念：
a. 把系统的、规范的、可度量的途径应用于软件开发、运行和维护过程，也就是把工程应用于软件；
b. 研究a中提到的途径。
软件工程特点：
(1) 软件工程关注于大型程序的构造。
(2) 软件工程的中心课题是控制复杂性。
(3) 软件经常变化。
(4) 开发软件的效率非常重要。
(5) 和谐的合作是开发软件的关键。
(6) 软件必须有效的支持它的用户。
(7) 在软件工程领域中通常由具有一种文化背景的人替具有另一种文化背景的人创造产品。
软件工程的基本原理：
(1) 用分阶段的生命周期计划严格管理。
(2) 坚持进行阶段评审。
(3) 实行严格的产品控制。
(4) 采用现代程序设计技术。
(5) 结果应能清楚的审查。
(6) 开发小组的人应该少而精。
(7) 承认不断改进软件工程实践的必要性。
1.3 软件生命周期
软件生命生存周期：概括由软件定义，软件开发，软件维护三个时期组成。
a.软件定义阶段：问题定义、可行性研究、需求分析。
b.软件开发阶段：总体设计、详细设计、编码和单元测试、综合测试。
c.软件维护阶段
1.4 软件过程
软件过程与软件生命周期关系：通常使用生命周期模型简洁的描述软件过程。生命周期模型也称过程模型。
瀑布模型：瀑布模型一直是唯一被广泛采用的生命周期模型，至今仍是软件工程应用的最广泛的过程模型。
特点：(1) 阶段间具有顺序性和依赖性。
(2) 推迟实现的观点。
(3) 质量保证的观点。
瀑布模型的优点：有利于大型软件开发过程中人员的组织、管理，有利于软件开发方法和工具的研究，从而提高了大型软件项目开发的质量和效率。
瀑布模型的缺点：
（1）开发过程一般不能逆转，否则代价太大；
（2）实际的项目开发很难严格按该模型进行；
（3）客户往往很难清楚地给出所有的需求，而该模型却要求如此。
（4）软件的实际情况必须到项目开发的后期客户才能看到，这要求客户有足够的耐心。
瀑布模型的使用范围：
（1）用户的需求非常清楚全面，且在开发过程中没有或很少变化；
（2）开发人员对软件的应用领域很熟悉；
（3）用户的使用环境非常稳定；
（4）开发工作对用户参与的要求很低。
快速原型模型：是快速建立起来的可以在计算机上运行的程序，它所能完成的功能往往是最终产品所能完成功能的一个子集。快速原型模型又称原型模型，它是增量模型的另一种形式；它是在开发真实系统之前，构造一个原型，在该原型的基础上，逐渐完成整个系统的开发工作。
快速原型模型的优点：
（1）可以得到比较良好的需求定义，容易适应需求的变化；
（2）有利于开发与培训的同步；
（3）开发费用低、开发周期短且对用户更友好。
快速原型模型的缺点：
（1）客户与开发者对原型理解不同；
（2） 准确的原型设计比较困难；
（3） 不利于开发人员的创新。
快速原型模型的使用范围：
（1）对所开发的领域比较熟悉而且有快速的原型开发工具；
（2）项目招投标时，可以以原型模型作为软件的开发模型；
（3）进行产品移植或升级时，或对已有产品原型进行客户化工作时，原型模型是非常适合的。
增量模型：分批次的逐步向用户提交产品，整软件产品被分解成许多个增量构件，开发人员一个构件接一个构件向用户提交产品。
增量模型的优点：
（1）采用增量模型的优点是人员分配灵活，刚开始不用投入大量人力资源；
（2）如果核心产品很受欢迎，则可增加人力实现下一个增量；
（3）可先发布部分功能给客户，对客户起到镇静剂的作用。
增量模型的缺点：
（1）并行开发构件有可能遇到不能集成的风险，软件必须具备开放式的体系结构；
（2）增量模型的灵活性可以使其适应这种变化的能力大大优于瀑布模型和快速原型模型，但也很容易退化为边做边改模型，从而是软件过程的控制失去整体性。
增量模型的使用范围：
（1）进行已有产品升级或新版本开发，增量模型是非常适合的；
（2）对完成期限严格要求的产品，可以使用增量模型；
（3）对所开发的领域比较熟悉而且已有原型系统，增量模型也是非常适合的。
螺旋模型 ：可以看做在每个阶段之前都增加风险分析过程的快速原型模型。
螺旋模型的优点：
（1）设计上的灵活性,可以在项目的各个阶段进行变更；
（2）以小的分段来构建大型系统,使成本计算变得简单容易；
（3）客户始终参与每个阶段的开发,保证了项目不偏离正确方向以及项目的可控性；
（4） 随着项目推进,客户始终掌握项目的最新信息 , 从而他或她能够和管理层有效地交互。
螺旋模型的缺点：
（1）采用螺旋模型需要具有相当丰富的风险评估经验和专门知识，在风险较大的项目开发中，如果未能够及时标识风险，势必造成重大损失；
（2）过多的迭代次数会增加开发成本，延迟提交时间。
螺旋模型的使用范围：螺旋模型只适合于大规模的软件项目。
喷泉模型 ：喷泉模型是一种以用户需求为动力，以对象为驱动的模型，主要用于描述面向对象的软件开发过程。该模型认为软件开发过程自下而上周期的各阶段是相互重叠和多次反复的，就像水喷上去又可以落下来，类似一个喷泉。各个开发阶段没有特定的次序要求，并且可以交互进行，可以在某个开发阶段中随时补充其他任何开发阶段中的遗漏。
喷泉模型的优点：
（1）提高软件项目开发效率；
（2）节省开发时间；
（3）适应于面向对象的软件开发过程；
喷泉模型的缺点：
（1）由于喷泉模型在各个开发阶段是重叠的,因此在开发过程中需要大量的开发人员，因此不利于项目的管理；
（2）此外这种模型要求严格管理文档，使得审核的难度加大，尤其是面对可能随时加入各种信息、需求与资料的情况；
喷泉模型适用场所：适应于面向对象的软件开发过程。
第二章、 可行性研究
2.1 可行性研究的任务
可行性研究的目的：不是解决问题，而是确定问题是否值得去解决。
可行性研究的任务（本质）：进行一次大大压缩简化了的系统分析和设计的过程，也就是在较高层次上以较抽象的方式进行的系统分析和设计的过程，从技术可行性，经济可行性，操作可行性等方面评价系统是否值得做，是否能做。
2.2 可行性研究过程
可行性研究的步骤：
（1）复查系统规模和目标（确保不偏题）；
（2）研究目前正在使用的系统（目的是了解现有系统能做什么，而不是了解它怎样做这些工作的）；
（3）导出新系统的高层逻辑模型（参考现有物理系统—>导出现有系统的逻辑模型—>参考现有逻辑模型，设计目标逻辑模型—>设计目标系统）；
（4）进一步定义问题（上述4步骤实质上构成一个循环）；
（5）导出和评价供选择的解法（评价原则：技术可行性，经济可行性，操作可行性）；
（6）推荐行动方针（分析员对于所推荐的系统进行成本/效益分析，决定是否继续进行这项开发工程）；
（7）草拟开发计划（工程进度表、各类开发人员和各类资源的需要情况、估算系统生命周期每个阶段的大致成本、给出需求分析阶段进度表及成本）；
（8）书写文档提交审查；
2.3 系统流程图
1. 符号
基本符号：
系统符号：
2. 例子
某装配厂有一座存放零件的仓库，仓库中现有的各种零件的数量以及每种零件的库存量的库存临界值等数据记录在库存清单主文件中。当仓库中零件数量有变换时，应该及时修改库存清单主文件，如果哪种零件的库存量少于它的库存临界值时，则应报告给采购部门一边订货，规定每天向采购部门报送一次订货清单。
3. 分层
面对复杂的系统 ----分层描绘首先用一张高层次的系统流程图描绘系统总体概貌，表明系统的关键功能。然后分别把每个关键功能扩展到适当的详细程度，画在单独的一页纸上。便于阅读者按从抽象到具体的过程逐步深入地了解一个复杂的系统。
2.4 数据流图
1. 符号
基本符号：
附加符号：
2. 例子（参考教材P42）
3. 命名
包括为数据流（数据存储）命名与处理命名两部分，命名注意事项见P45。
4. 用途
（1）作为交流信息的工具。
（2）供有关人员审查确认。
（3）作为分析与设计的工具。
2.5 数据字典
1. 定义：数据字典是关于数据信息的集合，是数据流图中所有元素严格定义的集合。
2. 内容：1.数据流、2.数据流分量(数据项)、3.数据存储(文件)、4.处理(基本加工)。
数据流 ：要定义数据流图中的数据流就要用数据流条目。数据流条目给出了某个数据流的定义，通常是列出该数据流的各个组成数据项。
数据流条目的描述内容：
（1）名称：数据流名。
（2）别名：数据流的另一个名字。
（3）简述：对数据流的简单描述和说明。
（4）组成：描述数据流由哪些数据项组成，使用如表3-1所示的描述符号来表示数据流的组成
例如：
订货单(数据流条目)=配件号(数据项)+配件名+规格+数量+顾客名+地址；
数据流分量条目 ：数据流的组成成员是数据项，数据项条目是不可再分解的数据单位，是组成数据流和数据存储的最小元素。数据项条目的描述内容如下：
（1）名称：数据项名。
（2）别名：数据项的另一个名字
（3）简述：对数据项的简单描述
（9）注解：对数据项的其它补充说明。
3. 数据元素组成数据的方式：顺序，选择，重复，可选。
4. 数据字典用途：
（1）作为分析阶段的工具；
（2）帮助开发数据库。
5. 数据流图与数据字典关系：数据流图与数据字典共同构成系统的逻辑模型，两者相互依存。
2.6 成本/效益分析
成本估计方法：代码行技术、任务分解技术、自动估计成本技术（通过估算软件工具）。
成本/效益分析方法：货币的时间价值、投资回收期、纯收入、投资回收率。
第三章、需求分析
概念：需求分析是软件定义时期的最后一个阶段，基本任务是准确回答系统必须做什么，确定系统必须完成那些工作，对目标系统提出完整，准确，清晰，具体的要求。
需求分析原则：
（1）必须理解并描述问题的信息域，根据这条准则应该建立数据模型；
（2）必须定义软件应完成的功能，这条准则应完成功能模型；
（3）必须描述作为外部事件结果的软件行为，这条准则要求建立行为模型；
（4）必须对描述信息、功能和行为的模型进行分解，用层次的方式展示细节；
3.1 需求分析的任务
需求分析的任务：
（1）确定系统的综合要求（功能需求、性能需求、可靠性与可用性需求、出错处理需求、接口需求、约束、逆向需求、将来可能提出的要求）；
（2）分析系统的数据要求；
（3）导出系统的逻辑模型；
（4）修正系统开发的计划；
3.2 与用户沟通获取需求的方法
（1）访谈；
（2）面向数据流自顶向下求精；
（3）简易的应用规格说明技术；
（4）快速建立软件原型；
3.3 分析建模与规格说明
模型概念：为了理解事物而对事物作出的一种抽象，是对事物的一种无歧义的书面描述。
结构化建模实质上是一种创建模型的活动
需求分析过程应该建立的三种模型： 数据模型（E—R图）、功能模型（数据流图）和行为模型（状态转化图）。
定义系统模型要区分逻辑模型和物理模型。
3.4 实体-联系图（E—R图）
数据模型（E—R图）包括：数据对象、数据对象的属性及数据对象彼此间相互联系的关系。
3.5 数据规范化
为了减少数据冗余，避免出现插入异常或删除异常，简化修改数据的过程，常常对数据进行规范化。通常用“范式（normal forms）”定义消除数据冗余的程度。
第一范式：每个属性值都必须是原子值，即仅仅是一个简单值而不含内部结构。
第二范式：满足第一范式的条件，而且每个非关键字属性都由整个关键字决定（而不是由关键字的一部分来决定）。
第三范式：符合第二范式的条件，每个非关键字属性都仅由关键字决定，而且一个非关键字属性不能仅仅是对另一个非关键字属性的进一步描述（即一个非关键字属性值不依赖另一个非关键字属性值）。
注意：
（1）第一范式数据冗余程度最大，第五范式数据冗余程度最小；
（2）范式级别越高，储存同样数据就需要分解成更多张表，“储存自身”的过程也就越复杂；
（3）随着范式级别提高，数据的存储结构与基于问题域的结构间的匹配程度也随之下降，稳定性下降；
（4）范式级别提高则需要访问的表就越多，性能下降。
3.6 状态转换图（行为模型）
状态：状态是任何可以被观察到的系统的行为模式，一个状态代表了一种行为模式。主要定义的状态有初态（实心圆），终态（同心圆），中间状态（用圆角矩形表示，上面部分为状态的名称，必须有，中间部分为状态变量的名字和值，可选，下面部分是活动表）。一张状态图中只能有一个初态，终态可以有0到多个。
事件：事件是某个特定时刻发生的事情，它是对引起系统做动作或重一个状态转换到另一个状态的的外界事件的抽象。事件就是引起系统做动作的或转换状体的控制信息。
符号
3.7 其他图形工具
1. 层次方框图
层次图也叫H图，它是一个表示信息系统 结构的有效工具。同模块结构图类似，但比较简单。层次图一个方框表示一个模块，方框内写模块名称。用方框间的连线表示模块间的层次关系。
2. Warnier图
法国计算机科学家Warnier提出了表示信息层 次结构的另外一种图形工具。 Warnier图可以表明信息的逻辑组织，它可以 指出一类信息或一个信息元素是重复出现的，也可以表示特定信息在某一类信息中是有条件地出现的。
3. IPO图
是输入—输出—处理图的简称。它也是美国IBM公司发展并完善起来的一种图形工具。它 具有简单、易用、描述清晰的特点，用来表示一个加工比较直观，对设计很有帮助。一个完整的 IPO图由三个大方框组成。左边的方框内写有关 的输入数据，称输入框；中间的方框列出对输入数据的处理，称处理框；右边的方框写处理所产生的输出数据，称输出框。处理框中从上至下的顺序表明系统操作的次序。
3.8 验证软件需求
验证软件需求的方法：
（1）验证需求的一致性；
（2）验证需求的现实性；
（3）验证需求的完整性和有效性；
第四章、形式化说明技术
4.1 概述
按照形式化的程度，可以把软件工程使用的方法划分为非形式化、半形式化、形式化3类.
【注】
（1）用自然语言描述需求规格说明是典型的非形式化方法。
（2）用数据流图或E-R图建立的模型是典型的半形式化方法。
（3）形式化方法是描述系统性质的基于数学的技术，即如果一种方法有坚实的数学基础，那么它就是形式化的。
非形式化方法的缺点：自然语言书写的规格说明书可能存在矛盾、二义性、含糊性、不完整性及抽象层次混乱等问题。
形式化方法的优点：
（1） 数学可以简介准确的描述物理现象、对象、动作的结果。用基于数学的形式化方法书写的规格说明书，可以准确到没有二义性，而且可以用数学方法来验证，以发现存在的矛盾和不完整性，且没有含糊性。
（2） 可以在不同的软件工程活动之间平滑的过渡。
（3） 提供了高层确认的手段。
应用形式化方法的准则：
（1）应该选用适当的表示方法。
（2）应该形式化，但不要过分形式化。
（3）应该估算成本。
（4） 应该有形式化方法顾问随时提供咨询。
（5）不应该放弃传统的开发方法。
（6）应该建立详尽的文档。
（7）不应该放弃质量标准。
（8）不应该盲目依赖形式化方法。
（9）应该测试、测试再测试。
（10）应该重用。
4.2 有穷状态机
4.3 Petri网
4.4 Z语言
第五章、总体设计
5.1 设计过程
总体设计通常由两个主要阶段组成：第一，系统设计阶段，确定系统具体实现方案；结构设计阶段，确定软件结构；
典型的总体设计过程包括9个步骤：
（1）设想供选择的方案；
（2）选取合理方案；
（3）推荐最佳方案；
（4）功能分解；
（5）设计软件结构；
（6）设计数据库；
（7）制定测试计划；
（8）书写文档；
（9）审查和复查。
5.2 设计原理
设计原理：
（1）模块化；
（2）抽象；
（3）逐步求精；
（4）信息隐藏和局部化；
（5）模块独立（高内聚，低耦合）；
5.3 启发规则
（1）改进软件结构提高模块独立性；
（2）模块规模应当适中；
（3）深度、宽度、扇出和扇入都应当适中；
（4）模块的作用域应该在控制域之内；
（5）力争降低模块接口的复杂程度；
（6）设计单入口单出口的模块；
（7）模块功能应该可以预测；
5.4 描绘软件结构的图形工具
描绘软件结构的图形工具：描述软件结构常用工具是结构图和层次图。
1.层次图和HIPO图
层次图用来描绘软件的层次结构。在图3.2 中已经非正式地使用了层次图。虽然层次图的形式和第3.7节中介绍的描绘数据结构的层次方框图相同，但是表现的内容却完全不同。
方框间的连线表示调用关系而不像层次方框图那样表示组成关系。层次图中的一个矩形框代表一个模块,最顶层的方框代表正文加工系统的主控模块，它调用下层模块完成正文加工的全部功能；第二层的每个模块控制完成正文加工的一个主要功能
HIPO图具有可追踪性，在H图(层次图)里除了最顶层的方框之外，每个方框都加了编号。
2.结构图
结构图和层次图类似，也是描绘软件结构的图形工具，图中一个方框代表一个模块，框内注明模块的名字或主要功能；方框之间的箭头(或直线)表示模块的调用关系。尾部是空心圆表示传递的是数据，实心圆表示传递的是控制信息。
常用符号：
附加符号：
5.5 面向数据流的设计方法
面向数据流的设计方法的目标是给出设计软件结构的一个系统化的途径。
（1）在软件工程的需求分析阶段，信息流是一个关键考虑，通常用数据流图描绘信息在系统中加工和流动的情况。
（2）面向数据流的设计方法定义了一些不同的“映射”，利用这些映射可以把数据流图变换成软件结构。
通常所说的结构化设计方法(简称SD法 )，也就是基于数据流的设计方法。
1.概念
面向数据流的设计方法：把信息流映射为软件结构，信息流的类型决定了映射方法。
数据处理的类型
在需求分析阶段，面向数据流的SA方法产生数据流图DFD。
在软件设计阶段，面向数据流的SD方法将DFD转换成程序结构图。
数据处理即为在DFD中从系统的输入数据流到系统的输出数据流所经历的一连串连续变换。
数据处理的类型分为变换流型与事务流型。
变换流:
数据沿着输入通路进入系统，经过一系列数据变换，将数据的外部形式转换成对应的内部表示，然后通过变换中心（也称主加工）处理，再沿着输出通路转换成外部形式离开系统。具有这种特性的数据流称为变换流。
变换流型DFD可以分成： 输入＋变换中心（主加工）＋输出
相应于取得数据、变换数据、给出数据，变换流型系统结构图由输入、变换中心和输出等三部分组成。
事物流：
数据沿输入通道到达一个处理T，这个处理根据输入数据的类型在若干个动作序列中选出一个来执行，这类数据流称事物流。
2.变换分析（一系列设计步骤总称）
变换分析从变换流型的数据流图导出系统结构图.
重画数据流图；
区分有效（逻辑）输入、有效（逻辑）输出和变换中心部分；
进行一级分解，设计模块结构的顶层和第一层模块；
顶层模块：其功能就是整个系统的功能；
输入控制模块：接收所有的输入数据；
变换控制模块：实现输入到输出的变换；
输出控制模块：产生所有的输出数据。
进行二级分解，设计输入、输出和中心变换部分的中、下层模块。
输入控制模块的分解：从变换中心的边界开始，沿着各输入通路，把输入通路上的每个加工映射成输入控制模块的一个低层模块。
输出控制模块的分解：从变换中心的边界开始，沿着各输出通路，把输出通路上的每个加工映射成输出控制模块的一个低层模块。
变换控制模块的分解：变换控制模块通常没有通用的分解方法，应根据数据流图中变换部分的实际情况进行设计。
第六章、详细设计
6.1 结构程序设计
3中基本的控制结构：顺序结构、选择结构、循环结构。
6.2 人机界面设计
1.设计问题：系统响应时间、用户帮助设施、出错信息处理、命令交互。
2.设计过程
3.人机界面设计指南：
（1）一般交互指南：保持一致性、提供有意义的反馈、在执行有较大破坏性的动作之前要求用户确认、允许取消绝大多数操作、减少在两次操作之间必须记忆的信息量、提高对话，移动和思考的效率、允许犯错误、按功能对动作分类，病据此设计屏幕布局、提供对用户工作内容敏感的帮助设施、用简单动词或动词短语作为命令名。
（2）信息显示指南：只显示与当前工作有关的信息、用用户迅速吸取信息的方式来表示数据、使用一致的标记，缩写和可预知的颜色、允许用户保持可视化的语境、产生有意义的出错信息、使用大小写，缩进和文本分组以帮助理解、使用窗口分隔不同的信息、使用“模拟”显示方式表示信息，以使信息更容易被用户提取、高效率的使用显示屏。
（3）数据输入指南：尽量减少数据输入的动作、保持数据输入与信息显示的一致性、允许用户自定义输入、交互应该是灵活的，并且可调整为用户最喜欢的输入方式、使用当前动作语境中不适用的命令不起作用、让用户控制交互流、对所有输入动作都提供帮助、消除冗余的输入。
6.3 过程设计的工具
1.程序流程图（程序框图）
2.盒图（N-S图）
特点：功能域明确、不能任意转移控制、容易确定数据的作用域、容易表现嵌套关系，也可以表示模块的层次结构。
3.PAD图（问题分析图）
优点：
（1）使用表示结构化控制结构的PAD符号所设 计出来的程序必然是结构化程序。
（2）PAD图所描绘的程序结构十分清晰。圈表语句标号，等号表定义。
（3）用PAD图表现程序逻辑，易读、易懂、易记。
（4）容易将PAD图转换成高级语言源程序， 这种转换可用软件工具自动完成，从而可省去人工编码的工作，有利于提高软件可靠性和软件生产率。
（5）即可用于表示程序逻辑，也可用于描绘数据结构。
（6）PAD图的符号支持自顶向下、逐步求精方法的使用。
4.判定表（适用于算法中含多重嵌套的条件选择）
一张判定表由4部分组成，左上部列出所有条件，左下部是所有可能做的动作，右上部是表示各种条件组合的一个矩阵，右下部是和每种条件组合相对应的动作。判定表 右半部的每一列实质上是一条规则，规定了与特定的条件组合相对应的动作。
5.判定树
判定树是判定表的变种，也能清晰地表示复 杂的条件组合与应做的动作之间的对应关系
优点：
（1）它的形式简单到不需任何说明，一眼就可以看出其含义，因此易于掌握和使用。
（2）多年来判定树一直受到人们的重视，是一种比较常用的系统分析和设计的工具。
6.过程设计语言
也称为伪码，它是用正文 形式表示数据和处理过程的设计工具。 PDL具有严格的关键字外部语法，用于定义控 制结构和数据结构；另一方面，PDL表示实际操作和条件的内部语法通常又是灵活自由的，可以适应各种工程项目的需要。因此， 一般说来，PDL是一种“混杂”语言。
6.4 面向数据结构的设计方法
Jackson方法和Warnier方法是最著名的两个面向数据结构的设计方法，层次图表现的是调用关系，而Jackson图表现的是组成关系。
1.Jackson图
a.顺序结构
b.选择结构
c.重复结构
优点：
（1）便于表达层次结构，而且是对结构进行自顶向下分解的有力工具。
（2）形象直观可读性好。
（3）既能表示数据结构也能表示程序结构。
2.改进的Jackson图
3.Jackson方法
6.5 程序复杂程度的定量度量
程序复杂程度的定量度量：McCabe方法，Halstead方法
1.McCabe方法
（1）流图
（2）计算环形复杂度的方法
（3）环形复杂度的用途
2.HaLstead方法
第七章、实现
实现：通常把编码和测试统称为实现：
7.1 编码
1.编码原则：
（1）系统用户的要求；
（2）可以的使用的编译程序；
（3）可以得到的软件工具；
（4）工程规模；
（5）程序员知识；
（6）软件可移植性要求；
（7）软件的应用领域；
2.编码风格
（1）程序内部的文档：包括适当的标识符、适当的注解和程序的视觉组织等；
（2）数据说明：数据说明的次序应该做到标准化（次序有序容易查阅）；
（3）语句构造：避免多个语句同写一行、避免复杂的条件测试、减少对“非”条件的测试、避免大量使用循环嵌套和条件嵌套、利用括号使逻辑表达式或算数表达式的运算次序清晰直观；
（4）输入输出：对输入数据要进行检验、检查输入项重要组合的合法性、保持输入格式简单、使用数据结束标记，不要要求用户指定数据的数目、明确提示交互式输入的请求，详细说明可用的选择或边界数值、当程序设计语言对格式有严格要求时，应保持输入格式一致、设计良好的输出报表、给所有输出数据加标记；
（5）效率：程序运行时间、存储器效率、输入输出效率。
7.2 软件测试基础
软件测试在软件生命周期中横跨两个阶段。
1.软件测试的目标：
（1）测试是为了发现程序中的错误而执行程序的过程；
（2）好的测试方案是极有可能发现迄今为止尚未发现的错误的测试方案；
（3）成功的测试是发现了至今为止尚未发现的错误的测试。
2.软件测试准则：
（1）所有测试都应追溯到用户需求；
（2）在测试之前就应定好测试计划；
（3）把Pareto原理应用到软件测试中；
（4）应从小规模测试逐步转向大规模测试；
（5）穷举测试是不可能的；
（6）最好由第三方进行测试工作。
3.测试方法：主要分为黑盒测试和白盒测试。
黑盒测试：功能测试，如果已经知道了产品应该具有的功能，可以通过测试来检验是否每个功能都能正常使用；
a. 等价划分
b.边界值分析
c.错误推测
白盒测试：结构测试，如果知道产品的内部工作过程 ，可以通过测试来检验产品内部动作是否按照规格说明书的规定正常进行。
a.逻辑覆盖：是以程序内部的逻辑结构为基础的设计测试用例的技术。是对一系列测试过程的总称，这组测试过程逐渐进行越来越完整的通路测试。它属白盒测试。 语句覆盖 判定覆盖 条件覆盖 判定－条件覆盖 条件组合覆盖 路径覆盖 点覆盖 边覆盖。
b.控制结构测试：基本路径测试，调减测试，循环测试，
4.测试步骤：
（1）模块测试；
（2）子系统测试；
（3）系统测试；
（4）验收测试；(把软件系统作为单一的实体进行测试，测试内容与系统测试基本类似，但是在用户积极参与下进行的。也称确认测试)
（5）平行运行。
5.测试阶段的信息流
（1）软件配置：需求说明书、设计说明书、源程序清单等。
（2）测试配置：测试计划、测试方案。
7.3 单元测试
1.测试重点
（1）模块接口；
（2）局部数据结构；
（3）重要的执行通路；
（4）出错处理通路；
（5）边界条件；
2.代码审查
3.计算机测试
7.4 集成测试
集成测试是测试和组装软件的系统化技术。
一种方法是先分别测试每个模块，再把所有模块按设计要求放在一起结合成所要的程序，这种方法称为非渐增式测试方法；另一种方法是把下一个要测试的模块同已经测试好的那些模块结合起来进行测试，测试 完以后再把下一个应该测试的模块结合进来测试。这种每次增加一个模块的方法称为渐增式测试，这种方法实际上同时完成单元测试和集成测试。
目前在进行集成测试时普遍采用渐增式测试方法。
1.自顶向下集成：
自顶向下集成方式是一个递增的组装软件结构的方法。从主控模块（主程序）开始沿控 制层向下移动，把模块一一组合起来。
分两种方法：
第一：先深度：按照结构，用一条主控制路径将所有模块组合起来；
第二：先 宽度：逐层组合所有下属模块，在每一层水 平地 集成测试 沿着移动。
2.自底向上集成：
自底向上的集成方式是最常使用的方法。其他集成方法都或多或少地继承、吸收了这种集成方式的思想。
集成思想：自底向上集成方式从程序模块结构中最底层的模块开始组装和测试。因为模块是自底向上进行组装的，对于一个给定层次的模块，它的子模块（包括子模块的所有下属模块）事前已经完成组装并经过测试，所以不再需要编制桩模块（一种能模拟真实模块，给待测模块提供调用接口或数据的测试用软件模块）。
3.不同集成测试策略的比较
4.回归测试
7.5 确认测试
确认测试也成验收测试，目标是验证软件的有效性。
1.确认测试的范围
2.软件配置复查
3.Alpha和Beta测试
Alpha测试：由用户在开发者的场所进行，并且在开发者对用户的“指导”下进行测试。开发者负责记录发现的错误和使用中遇到的问题。总之，Alpha测试是在受控的环境中进行的。
Beta测试：由软件的最终用户们在一个或多个客户场所进行。与Alpha测试不同，开发者通常不在Beta测试的现场，因此，Beta 测试是软件在开发者不能控制的环境中的“真实”应用。
7.6 白盒测试技术
1.逻辑覆盖：
（1）语句覆盖；
（2）判定覆盖；
（3）条件覆盖；
（4）判定/条件覆盖；
（5）条件组合覆盖；
（6）点覆盖；
（7）边覆盖；
（8）路径覆盖；
2.控制结构测试
（1）基本路径测试；
（2）条件测试；
（3）循环测试；
7.7 黑盒测试技术
白盒测试在测试阶段的早期进行，黑盒测试主要用于测试阶段后期进行。与白盒测试互补，很可能发现白盒测试不易发现的其他类型的错误。
黑盒测试力图发现下列类型的错误：
（1）功能不正确或遗漏的功能；
（2）界面错误；
（3）数据结构错误或外部数据库访问错误；
（4）性能错误；
（5）初始化和终止错误；
1.等价划分
2.边界值分析
3.错误推测
7.8 调试
1.调试过程
2.调试途径：
（1）蛮干法；
（2）回溯法；
（3）原因排除法；
7.9 软件可靠性
1.概念
软件可靠性：软件可靠性的基本定义：软件可靠性是程序在给定的时间间隔内，按照规格说明书的规定成功地执行地运行的概率。
软件的可用性：程序在给定的时间点，按照规格说明书的规定，成功的运行的概率。
2.估算平均无故障时间的方法
（1）符号；
（2）基本假定；
（3）估算平均无故障时间；
（4）估计错误总数方法；
第八章、维护
8.1 软件维护的定义
1.软件维护定义：在软件完成交付后，为了改正错误或者新的需求而修改软件的过程。
2.软件维护的分类：改正性维护（17% ~ 21%）、适应性维护（18% ~ 25%）、完善性维护（50%~66%）、预防性维护（4%）。
8.2 软件维护的特点
1.结构化维护与非结构化维护差别巨大
2.维护的代价高昂
3.维护的问题很多
8.3 软件维护过程
1.维护组织
2.维护报告
3.维护的时间流
4.保存维护记录
5.评价维护活动
8.4 软件的可维护性
1.决定软件可维护性的因素：可理解性、可测试性、可修改性、可移植性、可重用性。
2.文档（软件可维护性的决定因素）：用户文档（系统功能和使用方法）、系统文档（系统设计、实现和测试等各方面内容）。
8.5 预防性维护
8.6 软件再工程过程
1.库存目录分析
2.文档重构
3.逆向工程
4.代码重构
5.数据重构
6.正向工程
第九章、面向对象方法学引论
OO = object + class + inheritance + communication with messages
面向对象 = 对象 + 分类 + 继承 + 消息通信
面向对象即使用对象又使用类和继承等机制，而且对象直接仅能通过传递消息实现彼此通信，
面向对象方法学的优点：
与人类习惯的思维方法一致。
稳定性好。
可重用性好。
较易开发软件产品。
可维护性好。
面向对象的概念：
对象：对问题域中某个实体的抽象，设立某个对象就表示系统具有保存有关它的信息与它进行的交互能力。特点：以数据为中心，对象是主动的，实现了数据的封装，本质上有并行性，模块独立性好。
其他概念：
类：具有相同数据和数据操作的一组相似对象的定义。
实例：由某个实例的类所描述的一个具体的对象。
消息：要求某个对象执行在定义它的那个类中所定义的某个操作的规格说明，接收消息的对象，消息选择符，零个或多个变元。
方法：对象所能执行的所有操作，就是类中所定义的服务。
属性：类中所定义的数据，即对客观世界所具有的性质的抽象。
封装：有清晰的边界，有确定的接口(协议)，受保护的内部实现，
继承：直接获得已有的性质和特性。
多态性：在类等级的不同层次中可以共享一个行为的名字。
重载：函数重载，在同一作用域内的若干个参数特征不同的函数可以使用相同的函数名字，运算符重载，同一运算符可以施加于不同类型的操作数上。
面向对象建模：
3种 形式的模型，、
第一是描述系统数据结构 的对象模型(UML类图)，
第二是描述系统控制结构的动 态模型(状态转化图)；
第三是描述系统功能的功能模型(用例图)。
对象模型：：表示静态的、结构化的系统的“数 据”性质。 它是对模拟客观世界实体的对象以及对象彼 此间的关系的映射，描述了系统的静态结构。
类与类之间通常有关联、泛化(继承)、依赖和 细化等4种关系。
扫一扫
3233
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
