软件工程重点知识

第1章软件工程学概述

1.1软件危机

概念：指在计算机软件的开发和维护过程中所遇到的一系列严重问题。实际上，几乎所有软件都不同程度地存在这些问题。

原因：

1. 与软件本身的特点有关。1）软件不同于硬件，缺乏“可见性”，它是计算机系统的逻辑部件而不是物理部件。2）软件不同于一般程序，规模庞大，而且程序复杂性将随着程序规模的增加而呈指数上升。

2. 与软件开发与维护的方法不正确有关。1）忽视软件需求分析的重要性。对用户要求没有完整准确的认识就匆忙着手编写程序。2）认为软件开发就是写程序并设法使之运行。3）在软件开发的不同阶段进行修改需要付出的代价是很不相同的。4）轻视软件维护。

消除途径：

1. 对计算机软件有正确的认识：软件是计算机系统中与硬件相互依存的另一部分，它是包括程序，数据及其相关文档的完整集合。即Software =Program +Data +Document 。

2. 必须充分认识到软件开发是一种组织良好、管理严密、各类人员协同配合、共同完成的工程项目。

3. 推广使用在实践中总结出来的开发软件的成功技术和方法，并继续研究探索。

4. 开发和使用更好的软件工具。

1.2软件工程

软件工程：是指导计算机软件开发和维护的一门工程学科。

软件工程的本质特性：1. 软件工程关注于大型程序的构造；2. 软件工程的中心课题是控制复杂性；3. 软件经常变化；4. 开发软件的效率非常重要；5. 和谐地合作是软件开发的关键；6. 软件必须有效地支持它的用户；7. 在软件工程领域中是由具有一种文化背景的人替具有另一种文化背景的人创造产品。

软件工程包括技术和管理两方面的内容，是技术与管理紧密结合所形成的工程学科。

软件工程方法学的3要素：方法、工具和过程。

目前使用最广泛的软件工程方法学，分别是传统方法学和面向对象方法学。1. 传统方法学也称为生命周期方法学或结构化范型。结构化方法（Structure Method ）有：1）结构化设计方法（SD ）；2）结构化分析方法（SA ）；3）结构化分析与设计技术（SADT ）；4）JACKSON 方法；5）WARNIER 方法。2. 面向对象方法学是把数据和对数据的操作紧密结合起来的方法，模拟人类认识世界解决问题的方法和过程。面向对象方法学4个要点：对象(object)、类(class)、继承、消息。

1.3软件生命周期

软件生命周期由软件定义、软件开发和运行维护(也称为软件维护) 三个时期组成，每个时期又进一步划分成若干个阶段。

1.4软件过程

软件过程指为了获得高质量软件所需要完成的一系列任务的框架，它规定了完成各项任务的工作步骤。

1.

瀑布模型

传统瀑布模型实际瀑布模型

瀑布模型的特点：1) 阶段间具有顺序性和依赖性；2) 推迟实现的观点；3) 质量保证的观点。

瀑布模型的优点：1) 可强迫开发人员采用规范的方法；2) 严格地规定了每个阶段

3) 要求每个阶段交出的所有产品都必须经过质量保证小组的仔必须提交的文档；

细验证。

瀑布模型的缺点：1)“瀑布模型是由文档驱动的”这个事实也是它的一个主要缺点。2) 实际项目很少按照该模型给出的顺序进行；3) 用户常常难以清楚地给出所有需求；4) 用户必须有耐心，等到系统开发完成。

2. 快速原型模型

快速原型（Rapid Prototype Model ）：是快速建立起来的可以在计算机上运行的程序，它所能完成的功能往往是最终产品能完成的功能的一个子集。

快速原型模型的特点：1) 快速原型模型不带反馈环，软件产品的开发基本上是线性顺序进行的。2) 快速原型的本质是“快速”。应该尽可能快地建造出原型系统，以加速软件开发过程，节约成本。

原型模型存在的问题：1) 为了使原型尽快的工作，没有考虑软件的总体质量和长期的可维护性。2) 为了演示，可能采用不合适的操作系统、编程语言、效率低的算法，这些不理想的选择成了系统的组成部分。3) 开发过程不便于管理。3. 增量模型

增量模型(IncrementalModel) ：把软件产品作为一系列的增量构件来设计、编码、集成和测试。每个构件由多个相互作用的模块构成，并且能够完成特定的功能。增量模型的优点：

•人员分配灵活，刚开始不用投入大量人力资源。

•当配备的人员不能在设定的期限内完成产品时，它提供了一种先推出核心产品的途径。

•逐步增加产品功能可以使用户有较充裕的时间学习和适应新产品。•增量模型的难点：

•软件体系结构必须是开放的。

•模型本身是自相矛盾的。整体——独立构件。

•不同的构件并行地构建有可能加快工程进度，但是冒无法集成到一起的风险。

增量模型适用于：

•适用于需求经常改变的软件开发过程。

•如果在项目既定的商业要求期限之前不可能找到足够的开发人员，在这种情况下，增量模型显得特别有用。

4. 螺旋模型

螺旋模型(SpiralModel) ：使用原型及其他方法来尽量降低风险。把它看作在每个阶段之前都增加了风险分析过程的快速原型模型。

螺旋模型的优点：

•主要优势在于它是风险驱动的。

•对可选方案和约束条件的强调有利于已有软件的重用，也有助于把软件质量作为软件开发的一个重要目标；

•减少了过多测试或测试不足所带来的风险；

•维护只是模型的另一个周期，维护和开发之间没有本质区别。

螺旋模型的缺点：

•采用螺旋模型需要软件开发人员具有相当丰富的风险评估经验和这方面的专门知识，在风险较大的项目开发中，如果未能够及时标识风险，势必造成重大损失。

•过多的迭代次数会增加开发成本，延迟提交时间。

•螺旋模型适用于：

•特别适用于庞大、复杂并具有高风险的系统。

•适用于内部开发的大规模软件项目。

5. 喷泉模型

喷泉模型(FountainModel) ：是典型的面向对象生命周期模型。“喷泉”这个词体现了面向对象软件开发过程迭代和无缝的特性。为避免使用喷泉模型开发软件时开发过程过分无序，应该把一个线性过程(例如，快速原型模型或图中的中心垂线)

作为总目标。

喷泉模型的优点：

•该模型的各个阶段没有明显的界限，开发人员可以同步进行开发。

•多次反复地增加或明确目标系统，而不是本质性的改动，降低错误的可能性。

喷泉模型的缺点：

•由于喷泉模型在各个开发阶段是重叠的，因此在开发过程中需要大量的开发人员，不利于项目的管理。

•要求严格管理文档，使得审核的难度加大，尤其是面对可能随时加入各种信息、需求与资料的情况。

喷泉模型适用于：

•适用于面向对象的软件开发过程。

基于构件的开发模型：

•支持软件复用。利用预先包装好的软件构件来构造应用系统。

形式化方法模型：

•形式化方法是建立在严格数学基础上的一种软件开发方法。软件开发的全过程中，从需求分析、规约、设计、编程、系统集成、测试、文档生成、直至维护各个阶段，凡是采用严格的数学语言，具有精确的数学语义的方法，都称为形式化方法。

6. Rational 统一过程(RationalUnified Process, RUP)

•RUP 是一种迭代的，以架构为中心的，用例驱动的软件开发方法。•RUP 是一种具有明确定义和结构的软件工程过程。

•RUP 还是一个过程产品，提供了可定制的软件工程的过程框架。

•RUP 被广泛应用在不同工业领域中的不同企业中。

RUP 总结了6条软件开发经验—最佳实践：迭代式开发、管理需求、使用基于构件的体系结构、可视化建模、验证软件质量、控制软件变更。

7. 敏捷过程与极限编程

价值观声明提出的软件过程统称为敏捷过程。

极限编程(eXtremeProgramming, XP) ：

•敏捷过程中最富盛名的一个；

•广泛适用于需求模糊且经常改变的场合；

•使得敏捷过程能够较好地适应商业竞争环境下对小型项目提出的有限资源和有限开发时间的约束。

微软过程模型

•每一个生命周期发布一个递进的版本，各生命周期持续快速地迭代循环；•优点：综合了Rational 统一过程和敏捷过程的优点；

•缺点：对方法、工具和产品等方面不够全面。

第2章：可行性研究

2.1可行性研究的任务

可行性研究的目的：用最小的代价在尽可能短的时间内确定问题是否能够解决。（不是解决问题，而是确定问题是否值得去解决。）

可行性分析主要包括技术可行性、经济可行性、操作可行性和社会可行性的研究。

2.2可行性研究过程

可行性研究过程包括：1）复查系统规模和目标；2）研究目前正在使用的系统；3）导出新系统的高层逻辑模型；4）重新定义问题；5）导出和评价供选择的解法（物理解决方案）；6）推荐行动方案；7）草拟开发计划；8）书写文档提交审查。

2.3系统流程图

系统流程图是概括地描绘物理系统的传统工具。

它的基本思想是用图形符号以黑盒子形式描绘组成系统的每个部件(程序，文档，数据库，人工过程等) 。

2.4数据流图

数据流图（DFD Data Flow Diagram ）是一种图形化技术，它描绘信息流和数据从输入移动到输出的过程中所经受的变换。

在数据流图中没有任何具体的物理部件，它只是描绘数据在软件中流动和被处理的逻辑过程，是系统逻辑功能的图形表示。

数据流图的用途：1）利用它作为交流信息的工具；2）作为软件分析和设计的工具。

2.5数据字典

数据流图和数据字典共同构成系统的逻辑模型。

数据字典是关于数据信息的集合，是对数据流图中包含的所有元素定义的集合。没有数据字典数据流图就不严格，没有数据流图数据字典也难于发挥作用。数据字典应该由对下列4元素的定义组成：1）数据流；2）数据元素（数据流分量）；3）数据存储；4）处理。

定义数据的方法：对数据自顶向下分解。

数据组成方式：顺序、选择、重复(三种基本类型) 以及可选（附加类型）。实现数据字典两种方式：1）计算机程序处理；2）卡片式人工书写。

2.6成本/效益分析

软件开发成本主要表现为人力资源的消耗。成本估计不能用精确科学来估计。成本估算技术包括：1）代码行技术、2）任务分解技术、3）自动成本估计、4）算法模型估计。

成本/效益分析要估计开发成本、运行费用和新系统将带来的经济效益。第3章需求分析

需求分析是软件定义时期的最后一个阶段，它的基本任务不是确定系统怎样完成它的工作，而是确定系统必须完成哪些工作，也就是对目标系统提出完整、准确、清晰、具体的要求。

3.1需求分析的任务

对系统的综合要求包括：1）功能需求、2）性能需求、3）可靠性和可用性需求、4）出错处理需求、5）接口需求、6）约束、7）逆向需求、8）将来可能提出的要求。

数据是软件系统的核心和血液，必须分析系统的数据要求。如：数据的元素组成、

数据元素之间的逻辑关系、数据结构的规范化描述等。

3.2与用户沟通获取需求的方法

包括：访谈、面向数据流自顶向下求精、简易应用规格说明技术、快速建立软件原型。

结构化分析方法就是面向数据流自顶向下逐步求精进行需求分析的方法。

3.3分析建模与规格说明

根据结构化分析准则，需求分析过程应该建立数据模型、功能模型和行为模型3种模型。

结构化分析是面向数据流进行分析的方法，主要建立以下几种模型：1）实体联

2）系图(Entity-RelationshipDiagram,E-R 图) 、数据流图（Data Flow Diagram,DFD ）、

3）状态转换图（State-Transition Diagram,STD ）。另外几种图形工具有：层次方框图、Warnier 图、IPO 图等。

软件需求规格说明书，是需求分析阶段得出的最主要的文档。

3.4实体-联系图

ER 图是用来建立数据模型的工具。

数据模型是一种面向问题的数据模型，包含3种相互关联的信息：数据对象（实体）、数据对象的属性及数据对象彼此间相互连接的关系。

3.5数据规范化

通常用“范式(NormalForms)”定义消除数据冗余的程度。第一范式(1NF) 数据冗余程度最大，第五范式(5NF) 数据冗余程度最小。从实用角度看来，在大多数场合选用第三范式都比较恰当。

3.6状态转换图

状态转换图(简称为状态图) 通过描绘系统的状态及引起系统状态转换的事件，来表示系统的行为。此外，状态图还指明了作为特定事件的结果系统将做哪些动作(例如，处理数据) 。

状态是任何可以被观察到的系统行为模式，一个状态代表系统的一种行为模式。状态规定了系统对事件的响应方式。

事件是引起系统做动作或(和) 转换状态的控制信息。

3.7验证软件需求

验证软件需求的正确性，一般应从4个方面进行：一致性、完整性、现实性和有效性。

第5章总体设计

软件设计的任务：以软件需求规格说明书为依据，着手实现软件的需求，并将设计的结果反映在“设计规格说明书”文档中。

软件设计的重要性：是软件开发阶段的第一步，最终影响软件实现的成败和软件维护的难易程度。

总体设计任务：根据软件需求，设计软件系统结构和数据结构，确定程序的组成

模块及模块之间的相互关系。详细设计任务：确定模块内部的算法和数据结构；选定某种过程的表达形式来描述各种算法；产生精确描述各模块程序过程的详细文档，并进行评审。

5.1总体设计过程

总体设计由两个主要阶段组成：系统设计阶段，确定系统的具体实现方案；结构设计阶段，确定软件结构。

5.2设计原理

软件设计过程中应该遵循的基本原理包括：模块化、抽象、逐步求精、信息隐藏和局部化、模块独立。

模块的独立程度可以由两个定性标准度量：耦合与内聚。耦合衡量不同模块彼此间互相依赖（连接）的紧密程度，而内聚衡量一个模块内部各个元素彼此结合的紧密程度。

模块的耦合分四类：1）数据耦合、2）控制耦合、3）公用耦合、4）内容耦合。软件设计中应该：力求做到高内聚，尽量少用中内聚，不用低内聚。

5.3启发规则

用来改进软件设计的启发式规则包括：1）改进软件结构提高模块独立性、2）模块规模应该适中、3）深度、宽度、扇出和扇入都应适当、4）模块的作用域应该在控制域之内、5）力争降低模块接口的复杂度、6）设计单入口、单出口的模块、7）模块功能应该可以预测。

5.4图形工具

描述软件结构的图形工具包括：层次图、HIPO 图、结构图。

5.5面向数据流的设计方法

面向数据流的设计方法把信息流映射成软件结构，信息流的类型决定了映射的方法。信息流包括变换流和事务流两种类型。

面向数据流的设计将得到以数据流图为基础的软件模块结构图。

具有较明确的输入、变换（或称主加工）和输出界面的数据流图称为变换型数据流图。

事务型数据流图中存在一个事务中心（也就是数据处理、加工中心），它将输入分离成若干个发散的数据流，形成许多活动路径，并根据输入值选择其中一条路径。

变换设计就是从变换型数据流图映射出软件模块结构的过程，也称以变换为中心的设计。

面向数据流设计软件结构的基本步骤有七步：1）复审基本系统模型；2）复查并精化数据流图；3）确定数据流图具有变换特性还是事务特性；4）确定输入流和输出流的边界，从而孤立出变换中心；5）完成“第一级分解”；6）完成“第二级分解”；7）使用设计度量和启发式规则对第一次分割得到的软件结构进一步精化。

事务设计就是从事务型数据流图映射出软件模块结构的过程，也称为以事务为中心的设计。

事务设计的基本方法有两步：1）建立主控模块、接收输入类型分析模块和事务调度模块；2）分别设计输入类型分析模块和调度模块的下层模块结构。

第六章详细设计

1. 详细设计根本目标：确定如何具体实现所要求的系统。

任务：不是具体编写程序，而是设计程序的“蓝图”。

详细设计的结果决定最终程序代码的质量

2. 结构程序设计是一种设计程序的技术，它采用自顶向下逐步求精的设计方法和单入口单出

口的控制结构。经典的结构程序设计：只允许使用顺序、IF_THEN_ELSE选择DO_WHILE循环。

3. 设计人机界面过程中会遇到的4个问题：

1) 系统响应时间

系统响应时间指从用户完成某个控制动作，到软件给出预期的响应之间的这段时间。系统响应时间有两个重要属性：长度和易变性

2) 用户帮助设施

大多数现代软件都提供联机帮助设施，用户无须离开用户界面就能解决自己的问题。常见的帮助设施可分为集成的和附加的两类.

3) 出错信息处理

出错信息和警告信息，是出现问题时交互式系统给出的“坏消息.

4) 命令交互

多数情况下，用户既可以从菜单中选择软件功能，也可以通过键盘命令序列调用软件功能。

4. 设计过程

5. 过程设计的工具:

1) 程序流程图：是一种描述程序的控制结构流程和指令执行情况的有向图。

缺点：程序流程图的缺点：

(1)程序流程图本质上不是逐步求精的好工具，它诱使程序员过早地考虑程序的控制流程，而不去考虑程序的全局结构。

(2)程序流程图中用箭头代表控制流，因此程序员不受任何约束，可以完全不顾结构程序设计的精神，随意转移控制。

(3)程序流程图不易表示数据结构。

2) 盒图

特点：

(1)功能域明确，可以从盒图上一眼就看出来；

(2)不可能任意转移控制；

(3)很容易确定局部和全程数据的作用域；

(4)很容易表现嵌套关系，也可以表示模块层次结构

3)PAD 图

它用二维树形结构的图来表示程序的控制流，将这种图翻译成程序代码比较容易特点：

(1)使用表示结构化控制结构的PAD 符号所设计出来的程序必然是结构化程序；

(2)PAD图所描绘的程序结构十分清晰；

(3)用PAD 图表现程序，通俗易懂，程序从图中最左竖线上端的结点开始执行，自

上而下，从左向右顺序执行，遍历所有结点；

(4)容易将PAD 图转换成高级语言源程序，这种转换可以用软件工具自动完成；

(5)可用于表示程序逻辑，也可用于描绘数据结构；

(6)PAD图的符号支持自顶向下、逐步求精的方法。

4) 判定表

当算法中包含多重嵌套的条件选择时，用程序流程图、盒图、PAD 图或后面即将介绍的过程设计语言(PDL)都不易清楚地描述判定表却能够清晰地表示复杂的条件组合与应做的动作之间的对应关系。

一个判定表由四部分组成：

--左上部列出所有条件

--左下部是所有可能做的动作

--右上部表示各种条件组合

--右下部是和每种条件组合相对应的动作

5) 判定树

判定树是判定表的变种，也能清晰地表示复杂的条件组合与应做的动作之间的对应关系。

6) 过程设计语言（PDL ）

过程设计语言(PDL)也称为伪码，它是用正文形式表示数据和处理过程的设计工具。PDL 的优点：

(1)可以作为注释直接插在源程序中间；

(2)可以使用普通的正文编辑程序或文字处理系统来完成PDL 的书写和编辑工作；

(3)现在已经有一些自动处理程序可以自动地把PDL 生成程序代码。

PDL 的缺点：不如图形工具形象直观.

6. 面向数据流的设计方法是根据数据流确定软件结构；面向数据结构的设计方法是根据数据结构设计程序处理过程，对程序处理过程进行描述。通常面向数据结构的设计方法的设计步骤如下：

(1)画出系统中输入、输出数据对应的数据结构图。

(2)根据数据结构图，映射得到相应的程序结构图。

(3)按照程序结构图，分析得到程序的详细过程性描述。

7. 在面向数据结构的设计方法中，最典型的代表是Jackson 方法和Warnier 方法

JACKSON 方法的特点：

优点：

1、适合于层次结构表达；

2、形象直观、可读性强；

3、同时表示数据结构和程序结构。

缺点：

不能直接在图上表示选择条件和循环结束条件。影响了图的表达能力，也不易直

接把图翻译成程序，此外，框间连线为斜线，不易在行式打印机上输出。为了解

决上述问题，本书建议使用图6.11中给出的改进的Jackson 图。

Jackson 结构程序设计方法由五个步骤组成：

1）分析并确定输入数据和输出数据的逻辑结构，并用Jackson 图描绘这些数据结构；

2）找出输入数据结构和输出数据结构中有对应关系的数据单元；

3）用三条规则从描绘数据结构的Jackson 图导出描绘程序结构的Jackson 图

A ．为每对有对应关系的数据单元，按照它们在数据结构图中的层次在程序结构

图的相应层次画一个处理框；

B ．根据输入数据结构中剩余的每个数据单元所处的层次，在程序结构图的相应

层次分别为它们画上对应的处理框；

C ．根据输出数据结构中剩余的每个数据单元所处的层次，在程序结构图的相应

层次分别为它们画上对应的处理框；

4）列出所有操作和条件（包括分支条件和循环结束条件），并且把它们分配到程序结

构图的适当位置；

5）用伪码表示程序。

8. 程序复杂度定量度量方法是评介详细设计阶段模块质量的一种比较成熟的方法。

计算环形复杂度的方法

(1)环形复杂度V （G ）＝流图中的区域数；

(2)环形复杂度V （G ）＝E －N+2，

其中：E 是流图中边的条数，N 是结点数；

(3)环形复杂度V （G ）＝P ＋1，

其中：P 为流图中判定结点的数目。

环形复杂度的用途; ：对测试难度的一种定量度量，也能对软件最终的可靠性给出某种预测。

第7章实现

1. 通常把编码和测试统称为实现。

编码：把软件设计结果翻译成用某种程序设计语言书写的程序，是对设计的进一步

具体化。

测试：检测程序并改正错误的过程。

测试的目的：在软件投入运行之前，尽可能发现软件中的错误，并改正错误。

2. 选择一种编程语言的理论标准：

1）有理想的模块化机制；

2）可读性好的控制结构和数据结构；

3）便于调试和提高软件可靠性；

4）编译程序发现程序错误的能力强；

5）有良好的独立编译机制。

3. 编码风格是指编程遵循的基本原则。良好的编码风格有利于弥补语言的缺陷，编写出

高质量的软件。包括程序内部的文档、数据说明、语句构造、输入/输出、效率等方面的问题。

4. 程序的效率是指程序的执行速度及程序所需占用的内存的存储空间。即程序的时空复

杂度。效率问题涉及3方面：

（1）程序运行时间

（2）存储器效率

（3）输入输出效率

5. 测试阶段的根本目标是尽可能多地发现并排除软件中潜藏的错误，最终把一个高质量

的软件系统交给用户使用。测试决不能证明软件是正确的，也不能证明错误的不存在，它只能证明错误的存在

6. 软件测试准则：

1）所有测试都应该能追溯到用户需求；

软件中的问题根源可能在开发前期的各阶段解决、纠正错误也必须追溯到前期工作。

2）应该远在测试前就制定出测试计划；

完成需求模型既可以着手制定测试计划，建立了设计模型之后就可以立即开始设计详细的测试方案。因此，在编码之前就可以对所有测试工作进行计划和设计。

3）把Pareto 原理应用到软件测试中

Pareto （帕雷特：意大利经济学家）原则：也称为80/20法则，即：在众多现象中，80%的结果取决于20%的原因。

4）从“小规模”测试逐步进行“大规模”测试；

通常，首先重点测试单个程序模块，然后把测试重点转向在集成的模块簇中寻找错误，最后在整个系统中寻找错误。

5）穷举测试是不可能的；

穷尽测试：包含所有可能情况的测试称为穷尽测试。

6）为了达到最佳测试效果，应该由独立的第三方从事测试工作。

7. 测试方法包括：静态测试和动态测试

静态测试：基本特征是在对软件进行分析、检查和审阅，不实际运行被测试的软件。静态测试约可找出30～70%的逻辑设计错误。

动态测试：通过运行软件来检验软件的动态行为和运行结果的正确性。包括黑盒测试和白盒测试。动态测试的两个基本要素：

被测试程序

测试数据（测试用例）

动态测试方法：

(1)选取定义域有效值, 或定义域外无效值；

(2)对已选取值决定预期的结果；

(3)用选取值执行程序；

(4)执行结果与预期的结果相比不吻合，则程序有错

8. 如果知道产品的内部工作过程，可以通过测试来检验产品内部动作是否按照规格说明书的规定正常进称为白盒测试。

如果已经知道了产品应该具有的功能，可以通过测试来检验是否每个功能都能正常使用称为黑盒测试。

9. 白盒测试的内容：对程序模块的所有独立执行路径至少测试一次、对所有的逻辑判定，

取“真”与取“假”的两种情况都能至少测试一次、在循环的边界和运行边界内执行循环体、

测试内部数据结构的有效性。

黑盒测试的内容：Alpha/BetaTesting 、菜单/帮助测试、发行测试、回归测试。

优点黑盒测试①适用于各阶段测试

②从产品功能角度测试

③容易入手生成测试数据白盒测试①可构成测试数据使特定程序部分得到测试②有一定的充分性度量手段③可获较多工具支持

缺点①某些代码得不到测试①通常不易生成测试数据

②如果规格说明有误，则无法发现②无法对未实现规格说明的部分进行测试

③不易进行充分性测试③工作量大，通常只用于单元测试，有应用局限10软件测试的步骤

1). 模块测试

模块测试又称单元测试，它把每个模块作为单独的实体来测试。

2). 子系统测试

子系统测试是把经过单元测试的模块放在一起形成一个子系统来测试.

3) 系统测试

系统测试是把经过测试的子系统装配成一个完整的系统来测试。

4). 验收测试

验收测试把软件系统作为单一的实体进行测试（利用用户的实际数据测试）。

5) 平行运行

平行运行是同时运行新开发出来的系统和将被它取代的旧系统，以便比较新旧两个系统的处理结果。

11. 单元测试通过编译系统检查并改正程序中所有的语法错误。然后用详细设计模块说明

为

指南，对重要的控制路径进行测试，以便发现模块内部的错误。

测试重点：

1). 模块接口

主要检查下述几个方面：参数的数目、次序、属性或单位系统与变元是否一致；是否修改了只作输入用的变元；全局变量的定义和用法在各个模块中是否一致。

2). 局部数据结构

局部数据说明、初始化、默认值等方面的错误。

3). 重要的执行通路

选择最有代表性、最可能发现错误的执行通路进行测试就是十分关键的。应该设

计测试方案用来发现由于错误的计算、不正确的比较或不适当的控制流而造成的

错误.

4). 出错处理通路着重测试下述一些可能发生的错误：

(1)对错误的描述是难以理解的；

(2)记下错误与实际遇到的错误不同；

(3)在对错误进行处理之前，错误条件已经引起系统干预；

(4)对错误的处理不正确；

(5)描述错误的信息不足以帮助确定造成错误的位置。

5. 边界条件

边界测试是单元测试中最后的也可能是最重要的任务，软件常常在它的边界上

失效。

12. 计算机测试

必须为每个单元测试开发驱动程序和(或) 存根程序。

驱动程序是一个“主程序”，它接收测试数据，传送给被测试的模块，并打印出有关的结果。（自底向上的集成测试）

存根程序（虚拟子程序或做桩程序）代替被测试的模块所调用的模块。它使用被它代替的模块的接口，可能做最少量的数据操作，打印出对入口的检验或操作结果，并且把控制归还给调用它的模块。（自顶向下的集成测试）

13. 集成测试是组装软件的系统化技术，它将经过单元测试的模块联系在一起进行测试。

由

模块组装成程序时有两种方法：

1）非渐增式测试方法

先分别测试每个模块，再把所有模块按设计要求放在一起结合成所要的程序。

2）渐增式测试方法

每次增加一个待测试模块，把它同已经测试好的那些模块结合起来进行测试，反复进行。直到完成所有模块测试的方法

14. 自顶向下集成是一种递增的装配软件结构的方法，这种方法应用非常广泛。它需要存

根

程序，但是不需要驱动程序。包括：

1）深度优先策略

先组装软件结构的一条主控制通路上的所有模块，选择哪条主控制通路，具有较大的任意性。

2）宽度优先策略

沿着软件结构水平地移动，把处于同一个层次的所有模块组装起来。

15. 自顶向下集成方法的基本过程如下：

1）对主控模块进行测试，测试时用存根程序代替所有直接被主控模块调用的模块；

2）根据选定的结合策略（深度优先或宽度优先），每次用一个实际模块代替一个存根

程序（新结合的模块往往又需要新的存根程序）；

3）每结合一个模块，就测试一个；

4）为保证不引入新的错误，需要进行回归测试，即重复以前进行过的部分或全部测试；

5）重复回到第二步，直到构成整个软件结构。

16. 自底向上集成方法的基本过程如下：

1）把底层模块组合成实现一个特定软件子功能的族

2）为每个模块设计一个驱动程序，作为测试的控制程序，以协调测试用例的输入和输出。

3）对模块进行测试；

4）用实际模块代替驱动程序组装成新的模块族，在新加入的实际模块上面加上新的驱动程序进行测试；

5）重复第二到第四步，逐渐向上加入实际模块，直至构造出整个软件结构。

17. 回归测试是指重新执行已经做过的测试的某个子集，以保证修改变化没有带来非预期的副作用。回归测试集（已执行过的测试用例的子集）包括下述3类不同的测试用例：

（1）检测软件全部功能的代表性测试用例；

（2）专门针对可能受修改影响的软件功能的附加测试；

（3）针对被修改过的软件成分的测试。

18. 确认测试也称为验收测试，它的目标是验证软件的有效性。确认测试的范围：

确认测试必须有用户积极参与，或者以用户为主进行。用户应该参与设计测试方案，使用用户界面输入测试数据并且分析评价测试的输出结果。

确认测试通常使用黑盒测试法。应该仔细设计测试计划和测试过程，测试计划包括要进行的测试的种类及进度安排，测试过程规定了用来检测软件是否与需求一致的测试方案。通过测试和调试要保证软件能满足所有功能要求，能达到每个性能要求，文档资料是准确而完整的，此外，还应该保证软件能满足其他预定的要求。

19.Alpha 测试：用户在开发者的场所进行测试，并且在开发者的指导下进行，测试在受控环

境中进行，开发者记录发现的错误和问题；

Beta 测试：用户在一个或多个客户场所进行测试，不受开发者控制，测试者记录发现的问题和错误，定期将问题报告发送给开发者。

20逻辑覆盖测试的5种标准：

1). 语句覆盖——设计的测试用例能使程序中每条语句至少执行一次

2). 判定覆盖——选取足够的测试用例，使得程序中每个判断的可能结果都至少执行一

次，也就是说使程序的每个判断分支至少通过一次。

3) 条件覆盖——选择足够的测试用例，使得程序中每个判定表达式的每个条件都取到各种可能的结果.

4) 判定/条件覆盖——判定/条件覆盖是指：选取足够的测试用例使得同时满足判定覆盖和条件覆盖的要求。

6). 点覆盖——点覆盖是指：选取足够多的测试用例，使得程序执行路径至少经过程序图中每个节点一次。

7) 边覆盖——边覆盖是指：选取足够多的测试用例，使得程序执行路径至少经过程序图中每条边一次。

8) 路径覆盖——路径覆盖是指：选取足够多的测试用例，使得程序的每条可能路径都至少执行一次。

\21黑盒测试技术

黑盒测试力图发现下述类型的错误：

①功能不正确或遗漏了功能；

②界面错误；

③数据结构错误或外部数据库访问错误；

④性能错误；

⑤初始化和终止错误。

黑盒测试技术：等价划分法、边界值分析法、错误推测法、因果图法等。

22. 价类划分是一种黑盒测试技术，这种技术把程序的输入域划分成若干个数据类，据此导出测试用例。等价类别或等价区间是指测试相同目标或者暴露相同软件缺陷的一组测试用例。划分等价类的规则：

(1)如果输入条件规定了取值范围，可定义一个有效等价类和两个无效等价类

(2)如果输入条件代表集合的某个元素，则可定义一个有效等价类和一个无效等价类

(3)如规定了输入数据的一组值，且程序对不同输入值做不同处理，则每个允许的输入值是一个有效等价类，并有一个无效等价类(所有不允许的输入值的集合) 。

(4)如果规定了输入数据必须遵循的规则，可确定一个有效等价类（符合规则）和若干个无效等价类（从不同角度违反规则) 。

(5)如已划分的等价类各元素在程序中的处理方式不同，则应将此等价类进一步划分成更小的等价类

23. 边界值分析是指在设计测试用例时，使用正好等于、正好大于、正好小于边界值的数据进行测试。边界值分析法与等价类划分法区别：

(1)边界值分析不是从某等价类中随便挑一个作为代表，而是使这个等价类的每个边界都要作为测试条件。

(2)边界值分析不仅考虑输入条件，还要考虑输出空间产生的测试情况。

24调试（也称为纠错）作为成功测试的后果出现，也就是说，调试是在测试发现错误之后排除错误的过程。试就是把症状和原因联系起来的尚未被人深入认识的智力过程。调试途径：

1). 蛮干法：打印内存的内容，从中寻找错误的线索，是效率最低的程序调试方法。

2). 回溯法：从发现问题的程序段开始人工地往回追踪分析程序代码，直到找到错误。

3). 原因排除法包括：对分查找法、归纳法、演绎法

25. 软件可靠性：是程序在给定的时间间隔内，按照规格说明书的规定成功地运行的概率。

软件可用性是：程序在给定的时间点，按照规格说明书的规定，成功地运行的概率。可靠性和可用性的区别是：可靠性是在0到t 时间间隔内，系统没有失效的概率。而可用性是在t 时刻，系统是正常运行的概率。

第8章维护

1. 软件工程的主要目的：提高软件的可维护性，减少软件维护所需要的工作量，降低软件系统的总成本。

2. 软件维护的类型

1）改正性维护

交付给用户使用的软件，即使通过严格的测试，仍可能有一些潜在的错误在用户使用的过程中发现和修改。诊断和改正错误的过程称为改正性维护。

2）适应性维护

随着计算机的飞速发展，新的硬件系统和外部设备时常更新和升级，一些数据库环境、数据输入/输出方式、数据存储介质等也可能发生变换。为了使软件适应这些环境变化而修改软件的过程叫做适应性维护。

包括外部环境和数据环境的变化

3）完善性维护

在软件投入使用过程中，用户可能还会有新的功能和性能要求，可能会提出增加新功能、修改现有功能等要求。为了满足这类要求而进行的维护称为完善性维护。

包括功能和性能的要求。

4）预防性维护

为了改进软件未来的可维护性或可靠性，或者为了给未来的改进奠定更好的基础而进行

的修改，称为预防性维护

3. 软件维护过程实质上是一个修改和压缩了的软件定义和开发过程。事实上远在提出一项维护要求之前，与软件维护有关的工作已经开始了。

首先，建立维护的机构；

其次，确定报告及评价的过程，为每一个维护申请规定标准的处理步骤；

此外，建立适用于维护活动的记录保管过程，并规定复审的标准。

4. 软件可维护性是指维护人员理解、改正、改动或改进这个软件的难易程度，决定软件的可维护性的因素主要有下述5个：可理解性、可测试性、可修改性、可移植性、可重用性。

5. 文档是影响软件可维护性的决定因素。往往文档比程序代码更重要。

6. 软件系统的文档可以分为用户文档和系统文档两类。

用户文档--主要描述系统功能和使用方法，并不关心这些功能是怎样实现的；

系统文档--描述系统设计、实现和测试等各方面的内容。

7. 软件再工程是一类软件工程活动，是一个工程过程, 它将逆向工程、重构和正向工程组合起来, 将现存系统重新构造为新的形式。典型的软件再工程过程模型定义了6类活动：库存目录分析、文档重构、逆向工程、代码重构、数据重构、正向工程。

8. 可维护性复审概念：测试结束时进行正式的可维护性复审，称为配置复审。

目的：保证软件配置的所有成分是完整的、一致的和可理解的。

第九章面向对象方法学引论

1. 面向对象方法学(Object-OrientedMethodology ) 的出发点和基本原则：尽可能模拟人类习惯的思维方式，使开发软件的方法与过程尽可能接近人类认识世界解决问题的方法与过程。即：是描述问题的问题空间（问题域）与现实解法的解空间（求解域）在结构上尽可能一致。

2. 面向对象方法具有四个要点：

A. 认为客观世界是由对象组成；

B. 把所有对象都划分成各种对象类（Class ）；

C. 把若干对象类组成一个层次结构的系统（类等级）；

D ．对象彼此间仅通过传递消息互相联系。

OO =Objects +Class +Inheritance

+Communication with message

3.OOM 与传统方法的比较：

①传统方法：面向过程设计，以计算为核心; 数据与操作分离，不易理解。

OOM ：以object 为核心，强调对现实概念的模拟而不强调算法。“面向对象方

法学的基本原则，是按照人们习惯的思维方式建立问题域的模型，开发出尽可

能直观、自然地表现求解方法的软件系统”。

②传统方法：结构依赖于功能，不稳定

OOM ：以object 模拟实体，需求变化不会引起结构的整体变化，因为实体相对

稳定，故系统也相应稳定。

③传统方法：通过建立标准函数库来重用软构件。但标准函数缺少必要的“柔性”，难

以适应不同场合不同需要。

OOM ：一个class 所有的实例(instances)都可重用它的代码；由继承性(inheritance)派生出的新的class 可重用其父类的代码，并且可以修改、扩充而不影响其父类

的使用。

④传统方法：可维护性是最令人头痛的问题。

OOM ：从以下几方面改善了可维护性

稳定性好：软件功能需求的变化不牵动全局，只需局部修改；

Class 独立性强：只要修改不涉及class 的对外接口，则内部修改完全不影

响外部调用；

继承性(Inheritance)和多态性(polymorphism)使其很容易被修改和扩充；

容易理解、容易测试、调试。

4. 面向对象方法的优点

(1)与人们习惯的思维方法一致；

使用现实世界的概念抽象地思考问题从而自然地解决问题。

(2)稳定性好；

系统的功能需求变化时不会引起软件结构的整体变化，往往仅需要作一些局部性的修改。

(3)可重用性好；

对象是比较理想的模块和可重用的软件成分。

(4)较易开发大型软件产品；

可以把一个大型软件产品分解成一系列相互独立的小产品来处理

(5)可维护性好。

易于理解、修改、测试

5. 面向对象的概念

1）对象是具有相同状态的一组操作的集合。

对象是对属性值和操作的封装

2）类是对具有相同数据和相同操作的一组相似对象的定义

3）实例就是由某个特定的类所描述的一个具体的对象。

4）消息就是用来请求对象执行某个处理或回答某些信息的要求

5）方法是对象所能执行的操作

6）属性是类中定义的数据

7）封装就是信息隐藏，通过封装对外界隐藏了对象的实现细节。

8）继承，是指能够直接获得已有的性质和特征，而不必重复定义它们。继承是一种“求

同存异”的高度抽象方式

9）多态性，指子类对象可以象父类对象那样使用，同样的消息既可以发送给父类对象，

也可以发送给子类对象。

10）函数重载指在同一作用域内的若干个参数特征不同的函数可以使用相同的

函数名字。

10）运算符重载指同一运算符可以施加于不同类型的操作数上面。当被操作数类

型不同时，运算符的含义是不同的。

6. 面向对象建模就是根据面向对象观点(模拟人类习惯的思维方式) 建立问题的解模式. 面向对象的实现能将此模式在计算机上实施。用OOM 开发软件，通常需要建立三种形式的模型，它们分别是：

（1）对象模型：描述系统的数据结构；

（2）动态模型：描述系统的控制结构；

（3）功能模型：描述系统的功能

7. 对象模型表示静态的、结构化的系统的“数据”性质。它是对模拟客观世界实体的对象以及对象彼此间的关系的映射，描述了系统的静态结构。

8. 关联表示两个类的对象之间存在某种语义上的联系。例如，作家使用计算机，我们就认为在作家和计算机之间存在某种语义连接，因此，在类图中应该在作家类和计算机类之间建立关联关系。

聚集表示类与类之间是整体与部分的关系。

9. 动态模型表示瞬时的、行为化的系统的“控制”性质，它规定了对象模型中的对象的合法变化序列。

每一个对象都具有自己的生命周期（或称为运行周期）。对一个对象来说，生命周期由许多阶段组成。生命周期中的阶段也就是对象的状态。

10以用例图建立起来的系统模型称为用例模型，它描述的是外部行为者所理解的系统功能。11三种模型之间的关系

1）针对每个类建立的动态模型，描述了实例的生命周期或运行周期。

2）状态转换驱使行为发生，这些行为在数据流图中被映射成处理，在用例图中被映射成用例，它们同时与类图中的服务相对应。

3）功能模型中的处理（或用例）对应于对象模型中的类所提供的服务。

4）数据流图中的数据存储，以及数据的源点/终点，通常是对象模型中的对象

5）数据流图中的数据流，往往是对象模型中对象的属性值，也可能是整个对象。

6）用例图中的行为者，可能是对象模型中的对象。

7）功能模型中的处理（或用例）可能产生动态模型中的事件。

8）对象模型描述了数据流图中的数据流、数据存储以及数据源点/终点的结构。

第10章软件产品线

1. 软件产品线涉及软件工程、管理技术和商业规划等多个方面，几乎涵盖了软件工程的所

有方向。

软件产品线的基本思想：大部分的软件需求并不是全新的，而是已有系统需求的变体软件产品线开发的核心思想是：采用特定领域体系结构和构件重用技术来解决一类具有相似需求的领域应用问题。

2. 软件产品线定义

定义1、利用产品间公共方面，预期考虑了可变性等设计的产品族称为产品线（Weiss 和Lai ）。

定义2、产品线就是由在系统的组成元素和功能方面具有共性和个性的相似的多个系统组成的一个系统族。

定义3、软件产品线就是在一个公共的软件资源集合基础上建立起来的，共享同一个特性集合的系统集合（Bass 、Clements 和Kazman ）。

•产品线的定义强调了以下几点：

–预先定义的生产方式

–共享的软件核心资源

–以核心资源为基础的软件开发

3. 软件产品线的基本活动：核心资源开发、软件项目开发和技术协调、组织管理三大活动

4. 核心资源开发

核心资源开发活动的输出包括：

–产品线范围：是关于产品线所能包含的产品描述，列举出所有产品的共性和

彼此之间存在的个性差异

–核心资源：是产品线中应用系统创建的基础设施。

–开发计划：描述了如何利用产品线中的核心资源去开发软件项目。

4. 软件项目开发

•软件项目开发活动依赖于核心资源开发活动的输出结果，即产品线范围、核心

资源和开发计划

•软件项目开发活动的输入包括：

–项目实际需求，被表示为领域中一些通用产品描述的变化或增量，也可表示

为产品线需求集合的一个增量，通过比较应用需求与产品线需求模型来获

得。

–产品线范围，指出当前所要开发的软件项目是否可由产品线来实现，指明该

项目可由产品线实现的模块，同时，还应该说明应用系统开发依赖于产品线

的程度。

–用于创建该项目的核心资源。

–开发计划，详细描述了如何利用核心资源来设计实现该软件项目。

5. 软件产品线工程与其它复用技术相比，主要存在以下两方面的差异：

软件产品线工程涉及一系列具有相似应用需求的软件产品。

软件项目开发是以公共核心资源为基础来进行的

6. 软件产品线需求建模是产品线开发过程中的关键性活动，其质量将直接决定整个产品线的成败。软件产品线需求建模包括：

1）产品线领域范围定义

2）产品线领域需求收集

3）产品线领域需求分析

4）产品线领域需求层次划分

5）产品线领域需求规格说明

6）应用系统需求收集

7）应用系统需求分析

8）应用系统需求规格说明

7. 软件产品线需求分析的特点

产品线领域需求包括固定部分和变化成分。

其中：固定部分：包括：所有产品公共功能和特征，变化部分：不同产品的独特性。•需求模型是客户、领域专家和系统分析师之间进行沟通的有效手段。

•需求抽取是一个发现、评审、文档化、理解用户需求和阐明系统约束的过程。•需求分析是一个提炼用户需求和系统约束的过程。

•需求规格说明是一个清晰地文档化用户需求和严格地阐明系统约束的过程。•需求确认是一个保证系统需求完整、正确、一致和清晰的过程。

8. 软件产品线开发评价

1）核心资源开发评价

2）软件项目开发评价

3）产品线管理评价

9.

软件产品线的双生命周期模型

整个模型由两个重叠的软件生命周期复合而成，即领域工程生命周期和应用工程生命周期。

•在领域工程和应用工程中，又分别有各自的分析过程、设计过程和实现过程。

•产品线领域工程的主要任务是：针对特定领域应用需求，创建可共享的公共软件体

系结构、构件和开发模型。

•应用工程是在领域工程的基础上开发软件项目的过程。

•在领域工程和应用工程的相应阶段之间，存在着纵向连接线，其含义是：产品线领

域工程指导应用工程的实施。

•应用工程的结果可以反馈给领域工程，促进核心资源的建设，因此，整个软件产品

线是一个互相迭代和相互完善的过程。

•领域工程是一个在较高抽象层次上，从领域遗留系统中抽取公共的、可重用的核心

资源，创建软件产品线以支持应用开发的过程。

•应用工程使用领域工程所创建的产品线体系结构和构件资源来开发应用系统，此外，

还要根据应用的特殊需求来定制新构件。

若新定制的构件具有领域可重用特性时，则需要进行泛化处理，将其加入到产品线核心资源中

10软件产品线的N 生命周期模型•

第一层是产品线工程，主要包括：产品线分析与计划、产品线确认与分类、产品线标准与规范和产品线发布。

•第二层是企业工程，描述了使用产品线来开发应用系统的软件企业的内部组织结构、

生产过程控制和发展模式。

•第三层是领域工程，包括产品线确认、领域分析、体系结构设计和体系结构实现。•第四层是应用工程，包括市场分析、应用需求分析、应用系统设计和应用系统实现。11软件产品线组织划分为4个部分：

市场分析人员：是产品线、应用系统和客户需求之间的沟通桥梁；

核心资源组：负责软件产品线体系结构和构件资源的开发工作；

软件项目组：负责完成应用系统的开发工作；

产品线管理者：负责开发过程的协调和计划

12. 软件产品线的优缺点

优点：

降低开发费用、缩短上市时间、灵活的人员配备、更高的可预测性、更高的质量、减低维护成本、减少系统设计复杂度、便于估计开发成本

缺点

•产品线的前期投资比较大，投资回报的周期比较长，而且失败的风险也比较大。•难以制定遗留系统向软件产品线迁移的有效策略。

•软件产品线理论还缺少策略化的重用模型和支持系统化重用的发展策略。•核心资源设计的通用性要求可能会导致其质量下降，适用范围缩小。•