2004计算机软件工程考研串讲之一：自考学院|希赛网|中国系统分析师/中国系统分析员

站好最后一班岗。祝大家考试顺利。(以下资料均为网上搜索整理，仅用于学习交流)

软件工程复习

提示：设计与建模要点
结构化分析建模：数据流图、实体关系图、状态迁移图、数据字典
结构化设计建模：数据流图转换为系统结构图
结构化程序设计：程序流程图、N-S图
程序环路复杂性计算
测试用例设计：逻辑覆盖、循环测试、基本路径覆盖、因果图
可靠性分析：估算测试前程序中潜在错误
OMT建模：对象模型、动态模型（状态图、事件追踪图）
UML建模：用例图、类图、顺序图、活动图
第一章软件工程概念
软件的定义软件由计算机程序、数据及文档组成。
软件与硬件、数据库、人、过程等共同构成计算机系统。
软件按功能分类：应用软件、系统软件、支撑软件。
软件的发展经历了三个阶段：程序设计阶段、程序系统阶段、软件工程阶段。

软件工程定义
1968 年德国人 Bauer 在北大西洋公约组织会议上的定义： "建立并使用完善的工程化原则 , 以较经济的手段获得能在实际机器上有效运行的可靠软件的一系列方法"。
1983 年 IEEE 的软件工程定义： "软件工程是开发，运行 , 维护和修复软件的系统方法"。
1993 年 IEEE 的一个更加综合的定义： "将系统化的，规范的，可度量的方法应用于软件的开发 , 运行和维护的过程，即将工程化应用于软件中"。

软件工程的知识结构
软件工程过程与软件生存周期
ISO 9000定义：软件工程过程是把输入转化为输出的一组彼此相关的资源和活动。
从软件开发的观点看，它就是使用适当的资源（包括人员、硬软件工具、时间等），为开发软件进行的一组开发活动，在过程结束时将输入（用户要求）转化为输出（软件产品）。

软件工程过程定义了: 方法使用的顺序、要求交付的文档资料、为保证质量和适应变化所需要的管理、软件开发各个阶段完成的里程碑。
软件工程过程包含四种基本的过程活动：
plan : 软件规格说明
do : 软件开发
check : 软件确认
action : 软件演进

软件生存周期包含三个阶段：软件定义、软件开发及软件运行维护。
软件生存周期模型是软件工程思想的具体化，是跨越软件生存周期的系统开发、运行、维护所实施的全部活动和任务的过程框架。
常用的软件生存周期模型有瀑布模型，演化模型，螺旋模型，增量模型，喷泉模型，快速应用开发（ RAD ）模型。

演化模型
演化模型是迭代的，软件必须经过不断演化才能完善。
演化模型先开发一个“原型”软件，完成部分主要功能，展示给用户并征求意见，然后逐步完善，最终获得满意的软件产品。
业务和产品需求在变化中，采用线性开发方式是不实际的。
快速实现和提交一个有限的版本，可以应付市场竞争的压力。

螺旋模型
螺旋模型将瀑布模型与演化模型结合起来，并且加入两种模型均忽略了的风险分析。
螺旋模型沿着螺线旋转，自内向外每旋转一圈便开发出更完善的一个新版本。
制定计划
风险分析
实施工程
客户评估

增量模型
增量模型是迭代和演进的过程。
增量模型把软件产品分解成一系列的增量构件，在增量开发迭代中逐步加入。
每个构件由多个相互作用的模块构成，并且能够完成特定的功能。
早先完成的增量可以为后期的增量提供服务。
增量开发方法的新演进版本叫做 "极限程序设计（eXtreme Programming）" 。

喷泉模型
体现了迭代和无间隙的特性。
系统某个部分常常重复工作多次，相关对象在每次迭代中随之加入演进的软件成分。
无间隙是指在各项开发活动，即分析、设计和编码之间不存在明显的边界。
喷泉模型是对象驱动的过程。

快速应用开发（ RAD ）模型
快速应用开发模型是一种增量开发模型，该模型开发软件大量使用了可复用的构件。
每一个增量的开发经历五个阶段：
业务建模对业务功能的信息流建模。
数据建模对业务的数据对象和关系建模。
过程建模描述完成业务功能的数据变换。
应用生成应用构件和自动化工具建造。
测试与反复对新构件和接口进行测试。

软件开发范型(Paradigm)
范型又称为风范或开发模式 (Pattern)。
范型影响整个软件开发生存周期。它定义了：
特定问题和应用的开发过程中遵循的步骤
确定用于表示问题和解的那些成分的类型
利用这些成分表示与问题解决有关的抽象
直接得到问题的解的结构
范型支配了设计方法、编码语言、测试和检验技术的选择。

过程性范型把软件视为处理流，定义成由一系列步骤构成的算法。每一步骤都是带有输入和输出的一个过程，把这些步骤串联在一起可产生贯通于整个程序的控制流。
面向对象范型把标识和模型化问题领域中的实体做为系统开发的起点，面向对象系统中的对象是数据抽象与过程抽象的综合。
逻辑性范型是基于规则的，它把有关问题的知识分解成一组具体规则(如prolog语言)。

面向存取范型是一种在构造用户界面方面很有用的技术。
面向进程范型把一个问题分解成独立执行的模块。让不只一个程序同时运行。这些进程互相配合，解决问题。
函数型范型是基于规则的，它把有关问题的知识分解成一组具体规则，用语言的“if_then”等结构来表示这些规则。
说明性范型。

每种开发范型都有它的支持者和用户：
每种开发范型都特别适合于某种类型的问题或子问题；
每种开发范型都用不同的方式考虑问题；
每种开发范型都使用不同的方法来分解问题；
每种开发范型都导致不同种类的块、过程、产生规则。
系统开发时通常把大型问题分解成一组子问题。对于每个子问题采用适当的软件开发范型。
软件工程原则
软件工程原则有：
抽象与自顶向下、逐层细化
信息隐蔽和数据封装
模块化
局部化
确定性
一致性和标准化
完备性和可验证性

软件工程的基本原理有：
按软件生存周期分阶段制定计划并认真实施；
坚持进行阶段评审；
坚持严格的产品控制；
使用现代程序设计技术；
明确责任，使得工作结果能够得到清楚的审查；
用人少而精；
不断改进开发过程。
第二章需求分析
可行性研究

软件需求分析
需求分析的任务是发现、求精、建模和需求定义的过程。包括:
需求获取
需求建模
需求定义（规格说明、规约）
需求评审
需求管理
需求分析研究的对象是用户的要求。
1、需求获取
需求获取是在问题及其最终解决方案之间架设桥梁的第一步。
需求获取的目的是清楚地理解所要解决的问题，完整地获得用户的需求。
获取需求的一个必不可少的结果是对项目中描述的客户需求的普遍理解。一旦理解了需求，分析者、开发者和客户就能探索出描述这些需求的多种解决方案。
软件需求的层次
业务需求反映了组织或客户对系统、产品高层次的目标要求，它们一般在项目视图和范围文档中给予说明。
用户需求描述用户使用软件需要完成哪些任务，它们可通过使用实例图或脚本说明加以阐明。
功能―非功能需求定义了开发者必须实现的软件功能，而非功能需求如表所示:

需求获取过程
需求获取包括以下活动：
发现和分析问题发现问题症结，并分析问题的原因/结果关系。
获取需求根据对问题的理解定义需求。
使用调查研究方法收集信息；
遵循需求获取框架，按照三个成分观察：即数据、过程和接口。
需求归档以草稿形式归档调查结果。形式有用例、决策表、需求表等。
2、需求建模
需求建模是为了分析需求，以确定项目的确切需求。
需求建模遵循三个原则：
划分：描述需求的整体–部分关系；
抽象：描述需求的一般化–特殊化关系；
投影：描述需求的多维视图；
定义系统模型要区分逻辑模型和物理模型。
常用模型有数据建模和过程建模。
3、需求定义
又称需求规格说明或需求规约。
需求定义的主要目的是分析需求草稿和模型，解决其中存在的二义性和不一致性，系统地准确地表达系统需求，形成需求规格说明。包括
系统应提供的功能和服务；
非功能需求；
系统开发或运行的限制条件；
与系统互连的其他系统的信息。
4、需求评审
又称需求验证。
需求评审的目的是确保需求编写正确。可能的错误有：
不正确的系统模型；
排版错误或语法错误；
互相矛盾的需求；
有二义性或用词不当的需求；
没有遵循文档编制规范要求的质量标准。
5、需求管理
需求管理就是管理需求变化的过程。
需求管理涉及需求变更如何被处理的策略、规程和过程。它规定了
应如何提交一个需求变更请求？
如何分析需求变更对范围、进度和成本的影响？
如何批准或驳回需求变更？
如果批准了变更，改变更如何实现？
常用的分析方法
面向数据流的结构化分析方法 (SA)
面向数据结构的Jackson方法 (JSD)
面向数据结构的结构化数据系统开发方法 (DSSD)
面向对象的分析方法 (OOA) 等
结构化分析方法
结构化分析方法最初只是着眼于数据流，自顶向下，逐层分解，建立系统的处理流程，以数据流图和数据词典为主要工具，建立系统的逻辑模型。
扩充后，将建模技术扩展到数据建模、功能建模和行为建模，以实体-关系图、数据流图和控制流图、状态-迁移图为工具，数据词典为核心，从不同视点建立系统的分析模型。

数据建模
数据模型包括三种互相关联的信息：数据对象，描述对象的属性，描述对象间相互连接的关系。
在需求分析阶段描述数据对象和它们之间的关系，使用了E-R 图。
例如，在教学管理中，一个教师可以教授零门、一门或多门课程，每位学生也需要学习几门课程因此，教学管理中涉及的对象有学生、教师和课程。。

功能建模和数据流

行为建模
状态迁移图
例如，有关处理器分配的进程状态迁移。
数据字典

需求规格说明的原则
软件需求规格说明的基本原则：
功能与实现分离，描述要“做什么”而不是“怎样实现”。
要求使用面向处理的规格说明语言，从而得到“做什么”的规格说明。
如果目标软件只是一个大系统中的一个元素，那么整个大系统也包括在规格说明的描述之中。
规格说明必须包括系统运行的环境。

系统规格说明必须是一个认识的模型，而不是设计或实现的模型。
规格说明必须是可操作的。
规格说明必须容许不完备性并允许扩充。
规格说明必须局部化和松散的耦合。当信息被修改时，只要修改某个单个的段落，能够很容易地加入和删去一些段落。
第三章软件设计

衡量设计的原则
衡量设计的技术原则：
设计出来的结构应是分层结构。
设计应当模块化。
设计应当包含数据抽象和过程抽象。
设计应当建立具有具有独立功能的模块。
设计应当建立能够降低模块与外部环境之间复杂连接的接口。
设计应能根据软件需求信息，建立可驱动可复用的方法。
模块独立性
模块间的耦合
模块内聚
软件体系结构

1、系统构造 (System Structuring)
体系结构设计的第一步是将系统分解为一系列相互作用的子系统。
在最抽象层次，系统可视为一个方框图，图中每个方框表示一个子系统。
每个方框内的方框表明子系统本身还可分解为子系统。
箭头表示一个子系统向另一子系统传送数据或控制。

组装机器人控制系统的方框图

体系结构方框图表示一个系统结构的概貌，软件工程师很容易理解它。
这种方框图的缺点是没有反映系统构件之间关系的本质，没有表明系统的外部特性。
根据各子系统如何共享数据、如何分布、如何相互交互，可开发更加特定的模型。
数据仓库模型
客户机/ 服务器模型
抽象机模型
1) 数据仓库模型 (repository model)
所有共享数据都存放于数据库中, 这些数据可为所有子系统存取。
每个子系统保有各自的数据库，通过传送消息，可在子系统之间交换数据。
大量的数据围绕一个共享数据库或数据仓库来组织。
这种系统主要适用于控制系统，信息管理系统，CAD系统，CASE工具集。
集成的CASE工具集的体系结构以数据仓库为核心
2) 客户机/服务器模型 (client/server model)
这是一种分布式系统模型, 表明各种数据和处理如何分布到各个处理器上。
有一组功能各自独立的服务器，为其他子系统提供服务，如打印服务器，文件服务器,编译服务器等。
有一组客户机, 它们调用服务器提供的服务，也可能存在一些客户机，可并发执行的客户机程序。
有一个网络, 使得客户机能够访问服务器。
film & picture library系统的体系结构

客户机 / 服务器方法可用来实现基于数据仓库的系统，由数据仓库作为服务器提供系统服务。
各子系统作为客户访问数据仓库，但各子系统还有自己的数据管理功能。
服务器与客户间交换数据以执行处理。
对于大量的数据交换，可通过高速网络来解决性能问题。
客户机 / 服务器系统多用于具有多个分布式处理器的网络系统。
3) 抽象机模型 (abstract machine model)
一个体系结构的抽象机模型也称为层次模型。
此模型可以建立各个子系统的接口，它把系统组织成一系列的层次，每一层次提供一组服务，定义一个抽象机。
每一个抽象机由其下一层的抽象机的代码构成。
例如，网络协议的参考模型 OSI 即为典型的层次模型，而TCP/IP 通信协议则为四层的层次模型。

抽象机模型支持系统抽象程度递增的系统开发，具有可变更性和可移植性。
当一个层次开发出来后，就可以为其上层提供有效的某些服务。
如果接口是预定义的，则一个层次可为另一个层次所替换。
若一个层次的接口发生变更，仅相邻层次受到影响。
层次系统将机器依赖性局部化到它的内部层次上。

2、控制模型 (Control model)
在体系结构层次上的控制模型进一步考虑子系统之间的控制流。
集中控制模型
事件驱动模型
1) 集中控制模型 (centralised control model)
在集中控制模型中，将一个子系统设计为系统控制器，其职责是管理其他子系统的执行。
集中控制模型可以：
控制子系统顺序执行
控制子系统并发执行
作为集中控制器的子系统在将控制转交给另一子系统后，该子系统完成它的功能后控制权还要归还给集中控制器子系统。
调用-返回模型 (Call-Return model)
此即熟悉的自顶向下的子程序模型。
控制始于子程序层次的顶部，通过子程序调用，从层次结构较高层的程序向较低层的程序传递控制信息。程序执行结束将向较高层的父程序返回。
这种程序模型仅应用于顺序系统。
该模型可以在模块层使用，以控制函数或对象。
控制的Call-Return模型
管理器模型 (manager model)
这种模型应用于并发系统。
模型中有一个系统构件被设计为系统管理器，它控制开始、终止，并协调其他系统进程。
一个进程可以是子系统，也可以是模块，它可以与其他进程并行执行。
这种模型也可应用于顺序系统。管理例程根据某些状态变量的值调用特定的子系统。

一个实时系统的集中控制模型
2) 事件驱动系统 (Event-driven system)
集中控制模型通过一些系统状态变量值决定控制的流向；事件驱动模型则是通过外部生成的事件来驱动系统。
广播模型
中断驱动模型
广播模型 (Broadcast model)
在这种模型中，一个事件向所有的子系统广播，由能够处理此事件的子系统响应它。
这种模型的控制策略不嵌入在事件和消息处理器内。子系统决定它需要哪些事件，而事件和消息处理器负责将事件发送给它们。
在广播模型中，子系统注册有关特定事件的信息。一旦事件发生，控制将转移到能够处理该事件的子系统。

对于在网络中跨越不同计算机分布的集成子系统，广播模型十分有效。
实时系统一定是事件驱动的，它要求快速处理外部生成的事件。
事件处理器通常还支持点对点通信。
中断驱动模型 (Interrupt-driven model)
这种模型专用于实时处理系统。系统中只有有限的几种中断类型。每一中断都与中断向量中的一个存储位置相关联，该位置中存储了相应中断处理器的入口地址。
当系统接收到一个特定类型的中断时，硬件开关立即将控制以间址方式转移到相应的中断处理器，进行相应的中断处理。
中断处理器对事件的响应将是启动或停止其他某一进程。

3、模块分解 (Modular decomposition)
在设计出一个结构性体系结构后，下一步就是将子系统分解为模块。
在系统分解和模块分解之间没有严格的区别。
将子系统分解为模块时用到两种模型：
对象模型
数据流模型
如有可能，应避免并发设计，因为顺序设计在设计、编码、验证和测试都比较容易。
对象模型 (Object model)
在对象模型中，将系统分解为一组对象。对象具有松散耦合和仔细定义的界面，对象的状态是私有的，对象的操作是基于其状态定义的。
对象具有诸如封装、隐蔽、继承等良好的特性。对象必须自己维护其数据的一致性。
对象是系统的构件。因此对象分解的焦点在于对象类、对象属性及对象操作。实现时，对象就是从这些类中产生。
数据流模型 (Data-flow model)
在数据流模型中，将系统分解为一系列功能模块。
这种结构包括批处理和管道及过滤器。
在体系结构中的每一个成份都有一套输入和输出数据，都依输入-变换-输出的方式工作。
进行数据变换的构件叫做过滤器。
把数据从一个过滤器的输出导入到另一个过滤器的输入，就叫做管道。
特定领域的体系结构
对于一个特殊的应用领域，还可使用特定于它的体系结构模型，在开发新的系统时可以复用其公共体系结构。这种体系结构模型即为特定领域的体系结构。
存在两种特定领域的体系结构模型：
类属模型 (Generic model)
参考模型 (Reference model)
1、类属模型
类属模型是从许多实际系统中抽象出来的模型，它封装了这些系统的主要特征。
例如，在实时系统中，对于不同类型的系统，如数据采集系统、监控系统等，有它们各自的类属模型。
又例如，在语言的编译器中包括有词法分析器、语法分析器、语义分析器、代码生成器等，还有在编译过程中建立的符号表、语法树等。
编译器的数据流模型
编译器用数据流体系结构实现，处理流程按词法分析?语法分析?语义分析?代码生成的顺序执行，但处理共享数据时，使用了当作数据仓库用的符号表。

编译器还可以使用基于数据仓库的模型来组织类属系统的构件。
在这种模型中，符号表、语法树等起到中央信息仓库的作用，各种工具或工具件的通信都经过它。此外，有关程序的语法定义、输出格式定义等都从工具中取出，归入到数据仓库中。
语言处理系统的数据仓库模型
2、参考模型
一般的软件体系结构模型反映的是已有系统的体系结构，而参考模型反映了一大类系统的体系结构。
参考模型源于对应用领域的研究，它描述了一个理想化的包含了系统应具有的所有特征的软件体系结构。
典型的例子是OSI参考模型。它描述了开放系统互连的标准。如果一个系统遵从这个标准，就可以与其他遵从该标准的系统互连。
OSI参考模型的体系结构
分布式系统体系结构
所有大型计算机系统现在都是分布式系统。
分布式系统的信息处理分布在多个计算机上，而不是只限于单个计算机上。
在分布式系统中，系统软件运行于用网络相连的一组松散地集成在一起的处理器上。
例如，银行的ATM系统、预定系统、群件(Groupware) 系统等。

1、分布式系统的主要特征
资源共享共享使用硬件、软件资源。
开放性兼容不同厂家的硬件和软件的产品。
并发性在网络的不同计算机上可同时运行多个进程，它们在运行期间可以互相通信。
可伸缩性可通过增加新资源来满足新需求。
容错性可容忍某些硬件或软件的失效。
透明性对用户隐藏系统的分布情况。用户可完全透明地访问系统的资源。
2、典型的分布式系统的体系结构
1) 多处理器体系结构
多处理器系统由多个不同的进程组成，这些进程可以在不同的处理器上运行。
进程分配到哪一台处理器，可以是预先确定的，也可以用分配器控制进行分配。
多进程的软件系统不一定是分布式系统。但如果有多个处理器可用，可考虑分布式实现。
多处理器交通控制系统

2) 客户机/服务器体系结构
应用程序被模型化为一组由服务器提供的服务和一组使用这些服务的客户机。
客户机需要知道服务器的存在，但通常不知道其他客户机的存在。
客户机与服务器是不同的进程。通常讨论它们时，把它们当作逻辑进程，可以不关心它们物理上放在哪一台计算机上。
客户机/服务器体系结构
逻辑模型，进程与处理器之间不一定是一对一的映射。
客户机/服务器网络中的计算机
物理模型，是逻辑模型的具体实现
客户机/服务器的三层结构
表示层处理与用户的交互和显示提交给用户的信息。
应用处理层实现应用的逻辑。
数据管理层定义和操作数据库。
在集中式系统中，三层的界限不必分得这样清楚。
在分布式系统中必须清楚地给出它们之间的界限，以便将每一层分布到不同的机器上。
客户机/服务器的二层结构
二层客户机/服务器体系结构有两种形态:
瘦客户机模型所有应用处理与数据管理都在服务器上，客户机只负责表示功能。
胖客户机模型服务器只负责数据管理，客户机负责应用逻辑与系统用户的交互。

电子商务系统常用的B/S体系结构
数据层数据存储
应用逻辑层业务处理、业务流转、系统管理、日志管理、消息管理、权限管理、码表维护、其他等；
表示层用户接口；
分布式对象体系结构
分布式系统设计的更通用的方法是去掉客户机与服务器的差别，用分布式对象系统进行设计。
在分布式对象体系结构中，对象是基本系统构件。对象提供一组服务，并提供对外这些服务的接口。
对象之间不存在客户机与服务器的界限。接受服务者即扮演客户机的角色，提供服务者就是服务器。

对象可能分布在网络的多台计算机上，它们通过中间件相互通信。这个中间件被看作软件总线，它提供服务实现对象通信和增删。

这个中间件叫做对象请求代理，它的作用是在对象之间提供一个无缝的接口。
原则上，系统中的对象可以通过不同的程序语言来实现，可以运行于不同的平台上，而它们的名字在系统中可以不为其他对象所知。中间件就像“胶水”一样实现无缝的对象通信。
有两种主要的支持分布式对象计算的标准。
CORBA（通用对象请求代理体系结构）
DCOM（分布式构件对象模型）
结构化设计方法
该方法实施的要点是：
首先研究、分析和审查数据流图，从软件的需求规格说明中弄清数据流加工的过程，对于发现的问题及时解决。
然后根据数据流图确定数据处理的类型。典型的类型有两种：变换型和事务型。针对两种不同类型分别进行分析处理。
由数据流图推导出系统的初始结构图。

利用一些启发式原则改进系统初始结构图，直到得到符合要求的结构图为止。
修改和补充数据词典。
制定测试计划。
变换型系统结构图
变换型数据处理问题的工作过程大致分为三步，即取得数据，变换数据和给出数据。
相应于取得数据、变换数据、给出数据，变换型系统结构图由输入、中心变换和输出等三部分组成。

事务型系统结构图
它接受一项事务，根据事务处理的特点和性质，选择分派一个适当的处理单元，然后给出结果。
在事务型系统结构图中，事务中心模块按所接受的事务类型，选择某一事务处理模块执行各事务处理模块并列。
每个事务处理模块可能要调用若干个操作模块，而操作模块又可能调用若干个细节模块。

变换设计
变换设计方法由以下四步组成：
重画数据流图；
区分有效 (逻辑) 输入、有效 (逻辑) 输出和中心变换部分；
进行一级分解，设计上层模块；
进行二级分解，设计输入、输出和中心变换部分的中、下层模块。

事务设计
在很多软件应用中，存在某种作业数据流，它可以引发一个或多个处理，这些处理能够完成该作业要求的功能这种数据流就叫做事务。
与变换设计一样，事务设计也是从分析数据流图开始，自顶向下，逐步分解，建立系统的结构图。
事务设计的过程
复审基本系统模型。
复审和细化软件的数据流图。
确定数据流图中含有变换流特征还是含有事务流特征。
以上三步与变换映射中的相应工作相同。
识别事务中心和每一条操作路径上的流特征。事务中心通常位于几条操作路径的起始点上。

将数据流图映射到事务型系统结构图。
输入分支
分类事务处理分支（调度）
输出分支
分解和细化该事务结构和每一条操作路径的结构。
利用一些启发式原则来改进系统的初始结构图。

变换设计是软件系统结构设计的主要方法。
一般，一个大型的软件系统是变换型结构和事务型结构的混合结构。所以，我们通常利用以变换设计为主，事务设计为辅的方式进行软件结构设计。

改进系统结构的启发式原则
模块功能完善化
一个完整的模块应当有以下几部分：
执行规定的功能部分；
出错处理的部分;
函数在完成数据加工或结束时，应当给它的调用者返回一个状态码。
消除重复功能，改善软件结构
模块的作用范围应在控制范围之内

尽可能减少高扇出结构。
避免或减少使用病态联接。
直接病态联接
公共数据域病态联接
通信模块病态联接
模块的大小要适中。
设计功能可预测的模块

过程设计（详细设计）
在过程设计阶段，要决定各个模块的实现算法，并精确地表达这些算法。
对每个模块规定的功能以及算法的设计，给出适当的算法描述：
图形工具：程序流程图， N-S ，PAD， HIPO
表格工具：判定表
语言工具： PDL ， HIPO
1) 程序流程图
2) N-S 图
3) 问题分析图 (PAD)
4) PDL (Program Design Language)
PDL是一种用于描述功能模块的算法设计和加工细节的语言。称为设计程序用语言。它是一种伪码。
伪码的语法规则分为“外语法”和“内语法”。
PDL具有严格的关键字外语法，用于定义控制结构和数据结构，同时它的表示实际操作和条件的内语法可使用自然语言的词汇。

第四章软件测试
软件测试的原则
1. 应当把“尽早地和不断地进行软件测试”作为软件开发者的座右铭。
2. 测试用例应由测试输入数据和对应的预期输出结果这两部分组成。
3. 程序员应避免检查自己的程序。
4. 在设计测试用例时，应包括合理的输入条件和不合理的输入条件。

5. 充分注意测试中的群集现象经验表明，测试后程序中残存的错误数目与该程序中已发现的错误数目成正比。
6. 严格执行测试计划，排除测试的随意性。
7. 应当对每一个测试结果做全面检查。
8. 妥善保存测试计划，测试用例，出错统计和最终分析报告，为维护提供方便。

测试与软件开发各阶段的关系
软件开发是一个自顶向下，逐步细化的过程
软件计划阶段定义软件范围（作用域）
软件需求分析阶段建立软件信息域、功能和性能需求、约束等
软件设计阶段建立软件体系结构、用户接口、数据结构和细部设计
程序编码阶段把设计用某种程序设计语言转换成程序代码

测试过程是依相反顺序安排的自底向上，逐步集成的过程。
测试方法与测试用例设计
逻辑覆盖
逻辑覆盖是以程序内部的逻辑结构为基础的设计测试用例的技术，它属白盒测试。
语句覆盖
设计若干个测试用例，运行被测程序，使得每一可执行语句至少执行一次。
在图例中，正好所有的可执行语句都在路径 L1 上，所以选择路径 L1 设计测试用例。
【 (2, 0, 4) , (2, 0, 3) 】

判定覆盖
设计若干个测试用例，运行被测程序，使得程序中每个判断的取真分支和取假分支至少经历一次。
对于图例，如果选择路径 L1 和 L2 ，就可得满足要求的测试用例:
【(2, 0,4) , (2, 0, 3)】覆盖 ace【 L1 】
【(1, 1, 1), (1, 1, 1)】覆盖 abd【 L2 】
如果选择路径 L3 和 L4 ，还可得另一组可用的测试用例。

测试用例覆盖分支条件取值
【 (2, 0, 4), (2, 0, 3) 】 L1(c,e)
【 (1, 1, 1), (1, 1, 1) 】 L2(b,d)
【 (3, 1, 2), (3, 1, 3) 】 L3(b,e)
需要注意的是，在测试用例中可能有些条件取值在执行时覆盖不到，需要增加测试用例。

判定－条件覆盖
设计足够的测试用例，使得判断中每个条件的可能取值至少执行一次，每个判断中的每个分支至少执行一次。
测试用例覆盖分支条件取值
【(2, 0, 4), (2, 0, 3)】 L1(c, e)
【(1, 1, 1), (1, 1, 1)】 L2(b, d)
【(3, 1, 2), (3, 1, 3)】 L3(b, e)

简单循环设计测试用例的例子：求最小值
k=i; j=i+1;
while ( j <= n)
{
if (A[j] < A[k])
k = j;
j++;
}
测试用例选择
等价类划分
等价类划分是一种典型的黑盒测试方法。
等价类划分方法把所有可能的输入数据，即程序的输入域划分成若干部分，然后从每一部分中选取少数代表性的数据做为测试用例。
使用这一方法设计测试用例，要经历划分等价类（列出等价类表）和选取测试用例两步。
等价类的划分有两种不同的情况：有效等价类和无效等价类。

划分等价类
如果输入规定了取值范围或值的个数，可确立一个有效等价类和两个无效等价类。
如果输入规定了输入值的集合或规定了“必须如何”的条件，可确立一个有效等价类和一个无效等价类。
如果规定了输入数据的一组值，且程序要对每个输入值分别处理，可为每个输入值确立一个有效等价类，并可确立一个无效等价类，它是所有不允许的输入值的集合。

如果规定了输入数据必须遵守的规则，则可以确立一个有效等价类和若干个无效等价类（从不同角度违反规则）。
确立测试用例
在确立了等价类之后，建立等价类表，列出所有划分出的等价类。

从划分出的等价类中选择测试用例：
为每一个等价类规定一个唯一编号；
以尽可能少的测试用例覆盖尚所有的有效等价类；
每个无效等价类设计一个测试用例。
用等价类划分法设计测试用例的实例
在某 PASCAL 语言版本中规定： "标识符是由字母开头的字母数字串，有效字符数 8 个，最大字符数 80 个标识符必须先说明再使用。在同一说明语句中标识符至少必须有一个。"

用等价类划分方法，建立输入等价类表:

下面选取 9 个测试用例，覆盖所有的等价类。
① var x, T1234567 : real；
begin x := 3.414 ；
T1234567 := 2.732 ；
...…
(1),(2),(4),(8),(9),(12),(14)
② var : real; (3)
③ var x, : real; (5)
④ var T12345678 : real; (6)

⑤ var T12345...... : real； (7)
多于 80 个字符
⑥ var T$ : char； (10)
⑦ var GOTO : integer； (11)
⑧ var 2T : real； (13)
⑨ var PAR : real； (15)
begin PAP := 2.5 + (3.14*0.8)/6 ；
边界值分析
边界值分析是对等价类划分方法的补充。
从测试工作经验可知，大量的错误是发生在输入或输出范围的边界上，而不是在输入范围的内部。因此针对各种边界情况设计测试用例，可以查出更多的错误。
使用边界值分析方法设计测试用例，首先应确定边界情况应当选取正好等于，刚刚大于，或刚刚小于边界的值做为测试数据。
错误推测法
人们也可以靠经验和直觉推测程序中可能存在的各种错误，从而有针对性地编写检查这些错误的例子，这就是错误推测法。
错误推测法的基本想法是：列举出程序中所有可能有的错误和容易发生错误的特殊情况，根据它们选择测试用例。
因果图
如果在测试时必须考虑输入条件的各种组合，这就需要利用因果图。
因果图方法最终生成的就是判定表，它适合于检查程序输入条件的各种组合情况。
用因果图生成测试用例的基本步骤
分析软件规格说明描述中，找出原因 (即输入条件或输入条件的等价类) 和结果 (即输出条件) ，并标识每个原因和结果。

分析软件规格说明描述的语义，找出原因与结果之间对应的关系？根据这些关系，画出因果图。
在因果图上用一些记号标明某些原因与原因间，结果与结果间的约束或限制条件。
把因果图转换成判定表。
把判定表的每一列拿出来作为依据，设计测试用例。
在因果图中出现的基本符号
在因果图中用 Ci 表示原因，用 Ei 表示结果.

例如，有一个处理单价为 5 角钱的饮料自动售货机，软件测试用例的设计规格说明如下：

若投入 5 角钱或 1 元钱的硬币，押下〖橙汁〗或〖啤酒〗的按钮，则相应的饮料就送出来;若售货机没有零钱找，则一个显示〖零钱找完〗的红灯亮，这时在投入 1 元硬币并押下按钮后，饮料不送出来而且 1 元硬币也退出来；若有零钱找，则显示〖零钱找完〗的红灯灭，在送出饮料的同时退还 5 角硬币。”