第7章 软件工程基础 - 计算机与通信工程学院

Report
第7章 软件工程基础
本章要点:





软件工程基本概念,软件生命周期概念,软件工具
与软件开发环境
结构化分析方法,数据流图,数据字典,软件需求
规格说明书
结构化设计方法,总体设计与详细设计
软件测试的方法,白盒测试与黑盒测试,测试用例
设计,软件测试的实施,单元测试、集成测试和系
统测试
程序的调试,静态调试与动态调试
7.1 软件工程的基本概念
 7.1.1软件的定义、特点和发展
1.软件的定义
计算机软件(Software)是指计算机系统中与硬
件相互依赖的另一部分,包括程序、数据和有关的
文档。在国家标准(GB)中,软件被定义为与计算机
系统的操作有关的计算机程序、规程、规则,以及
可能有的文件、文档及数据。程序是对计算机的处
理对象和处理规则的描述,是软件开发人员根据用
户需求开发的、用程序语言描述的、适合计算机执
行的指令序列。数据能够保证程序的正常运行,文
档是程序的资源说明,是与程序的开发、维护和使
用相关的资料。
2.软件的特点
软件是逻辑产品,具有抽象性;硬件是物理产品,具有可见
性。
(1)软件开发更依赖于开发人员的业务素质、智力、人员
的组织、合作和管理。软件开发、设计几乎都是从头开始,成
本和进度很难估计。
(2)软件存在潜伏错误,硬件错误一般能排除。
(3)软件开发成功后,只需对原版进行复制。
(4)软件在使用过程中维护复杂:
① 纠错性维护—改正运行期间发现的潜伏错误;
② 完善性维护—提高或完善软件的性能;
③ 适应性维护—修改软件,以适应软硬件环境的变化;
④ 预防性维护—改进软件未来的可维护性和可靠性。
(5)软件不会磨损和老化。
3. 软件的发展
第一阶段——20世纪60年代中期以前,软件开发处于个
体化生产状态。在这一阶段中,软件还没有系统化的开发方
法。目标主要集中在如何提高时空效率上。
第二阶段——从20世纪60年代中期到70年代末期。软件开
发已进入了作坊式生产方式,即出现了“软件车间”。软件
开发开始形成产品。到20世纪60年代末,“软件危机”变得
十分严重。
第三阶段——从20世纪70年代中期到20世纪80年代末期。
软件开发进入了产业化生产,即出现了众多大型的“软件公
司”。在这一阶段,软件开发开始采用了“工程”的方法,
软件产品急剧增加,质量也有了很大的提高。
第四阶段——从20世纪80年代末期开始的。这是一个软件
产业大发展的时期。也是软件工程大发展的时期,人们开始
采用面向对象的技术和可视化的集成开发环境。
7.1.2软件危机与软件工程
软件工程的概念源自软件危机。软件危机是指在计算
机软件开发、使用与维护过程中遇到的一系列严重问题和
难题。
1.软件危机的表现
1)对软件开发成本和进度的估计常常很不准确。常常
出现实际成本比估算成本高出一个数量级、实际进度比计
划进度拖延几个月甚至几年的现象,从而降低了开发商的
信誉,引起用户不满。
2)用户对已完成的软件不满意的现象时有发生。
3)软件产品的质量往往是靠不住的。
4)软件常常是不可维护的。
5)软件通常没有适当的文档资料。文档资料不全或
不合格,必将给软件开发和维护工作带来许多难以想象的
困难和难以解决的问题。
6)软件成本在计算机系统总成本中所占比例逐年上升。
特别是软件维护成本迅速增加,已经占据软硬件总成本的
40%~75%,如图7.1所示。
图7.1软件、硬件成本变化趋势
7)开发生产率提高的速度远跟不上软件需求。
2.产生软件危机的原因
1)用户对软件需求的描述不精确。
2)软件开发人员对用户需求的理解有偏差,这将导致软
件产品与用户的需求不一致。
3)缺乏处理大型软件项目的经验。开发大型软件项目需
要组织众多人员共同完成。一般来说,多数管理人员缺乏大型
软件的开发经验,而多数软件开发人员又缺乏大型软件项目的
管理经验,致使各类人员的信息交流不及时、不准确、容易产
生误解。
4)开发大型软件易产生疏漏和错误。
5)缺乏有力的方法学的指导和有效的开发工具的支持。
软件开发过多地依靠程序员的“技巧”,从而加剧了软件产品
的个性化。
6)面对日益增长的软件需求,人们显得力不从心。从某种
意义上说,解决供求矛盾将是一个永恒的主题。
3.缓解软件危机的途径
到了20世纪60年代末期,软件危机已相当严重。这促使计
算机科学家们开始探索缓解软件危机的方法。他们提出了“软
件工程”的概念,即用现代工程的原理、技术和方法进行软件
的开发、管理、维护和更新。于是,开创了计算机科学技术的
一个新的研究领域。
4.软件工程的定义和三要素
为了消除软件危机,通过认真研究解决软件危机的方法,
1968年,北大西洋公约组织在原西德召开计算机科学会议,由
Fritz Bauer首次提出了“软件工程”的概念。软件工程就是试
图用工程、科学和数学的原则与方法开发、维护计算机软件的
有关技术和管理方法。
软件工程的定义:国标(GB)中指出软件工程是应用于计算
机软件的定义、开发和维护的一整套方法、工具、文档、实践
标准和工序。
软件工程由方法、工具和过程三部分组成,称软件工程
的三要素。软件工程中的各种方法是完成软件工程项目的技
术手段,它们支持软件工程的各个阶段。软件工程使用的软
件工具能够自动或半自动地支持软件的开发、管理和文档的
生成。软件工程中的过程贯穿于整个工程的各个环节,在这
一过程中,管理人员应对软件开发的质量、进度、成本等进
行评估、管理和控制,包括计划跟踪与控制、成本估算、人
员的组织、质量保证、配置管理等。
7.1.3软件工程过程与软件生命周期
1.软件工程过程(Software Engineering Process)
ISO9000中定义,软件工程过程是将输入转化为输出的
一组彼此相关的资源和活动。
事实上,软件工程过程是一个软件开发机构针对某类软
件产品为自己规定的工作步骤;当然它应当是科学的、合理
的,否则将影响软件产品的质量。
1.软件工程过程(Software Engineering Process)
通常把用户的要求变成软件产品的过程也叫做软件开发过
程。此过程包括对用户的需求进行分析,解释成软件需求,把
需求变换成设计,把设计用代码来实现并进行代码测试,有些
软件还需要进行代码安装和交付运行。
所以,软件工程过程是将软件工程的方法和工具综合起来,
以达到合理、及时地进行计算机软件开发的目的。软件工程过
程应确定方法使用的顺序、要求交付的文档资料、为保证质量
和适应变化所需要的管理、软件开发各个阶段完成的任务。
软件工程过程包含软件规格说明、软件开发、软件确认和
软件演进等4种基本活动。其中软件规格说明规定软件的功能
及其运行机制;软件开发产生满足规格说明的软件;软件确认
确保软件能够满足客户提出的要求;软件演进是为满足客户的
变更要求,软件必须在使用的过程中演进。
2.软件生命周期
软件产品从定义开始,经过开发、使用和维护,直到
最终退役的全过程称为软件生存周期。可将软件生存
周期划分为三个过程共九个阶段。
三个过程是:软件定义过程、软件开发过程、软件使
用与维护过程。
九个阶段有:可行性研究、需求分析、概要设计、
详细设计、实现、组装测试、验收测试、使用与维护、
退役。对每个阶段,都明确规定了该阶段的任务、实施
方法、实施步骤和完成标志,其中特别规定了每个阶段
需要产生的文档。它们之间的关系如图7.2所示。
图7.2 软件生存周期阶段的划分
7.1.4 软件工程的目标与原则
1.软件工程的目标及目标间的关系(如图7.3)
软件工程的目标是在给定成本、进度的前提下,开发出
具有有效性、可靠性、可理解性、可维护性、可重用性、可
移植性、可追踪性和可互操作性且满足用户需求的产品。
图7.3 软件工程目标之间的关系
(1)可修改性(modifiability),允许对软件系统进行
修改而不增加其复杂性。它支持软件调试与维护。
(2)有效性(efficiency),指软件系统的时间和空间
效率。这是一个应当努力追求的重要目标。
(3)可靠性(reliability),是指在给定的时间间隔内,
程序成功运行的概率。可靠性是衡量软件质量的一个重要
目标。
(4)可理解性(understandability),指系统具有清晰的结构,
能直接反映问题的需求。可理解性有助于控制软件系统的复杂
性,并支持软件的维护、移植和重用。
(5)可维护性(maintainability),是指软件产品交付使用后,
在实现改正潜伏的错误、改进性能等属性、适应环境变化等方
面工作的难易程度。由于软件的维护费用在整个软件生存周期
中占主要的比重,因此,可维护性是软件工程中的一个十分重
要的目标。软件的可理解性和可修改性支持软件的可维护性。
(6)可重用性(reusability),是指软部件可以在多种场合使
用的程度。
概念或功能相对独立的一个或一组相关模块可构成一个软
部件。软部件应具有清晰的结构和注释、正确的编码和较高的
时空效率。可将各种软部件按照某种规则放在软部件库中供开
发人员选用。
广义地讲,可重用性还应包括应用项目、规格说明、设计、
概念和方法等等的重用。一般来说,重用的层次越高,带来
的效益越大。
可重用性有助于提高软件产品的质量和开发效率、降低软
件开发和维护费用。
(7)可适应性(adaptability),是指软件在不同的系统约
束条件下,使用户需求得到满足的难易程度。
选择广为流行的软硬件支持环境、采用广为流行的程序设
计语言编码、采用标准的术语和格式书写文档可增强软件产
品的可适应性。
(8)可移植性(portability),是指软件从一个计算机系统
或环境移植到另一个上去的难易程度。
采用通用的运行支持环境和尽量通用的程序设计语言的标
准部分可提高可移植性。而应将依赖于计算机系统的低级
(物理)特征部分相对独立、集中起来。可移植性支持软件
的可重用性和可适应性。
基于上述目标,软件工程学所研究的主要内容包括:软
件开发技术和软件工程管理两个方面。其中:软件开发技
术包括:
(1)软件开发方法学(Software Development Methods )
①传统方法学,也称为生命周期方法学或结构化范型
②面向对象方法学:面向对象 = 对象 + 类 + 继承 + 消
息通信
(2)开发过程
(3)软件工具(Software Tools)
(4)软件工程环境(Software Engineering Environment,
简称SEE)
软件工程管理包括:软件管理学、软件工程经济学、软
件心理学等。
2.软件工程的原则
为了达到上述目标,在软件开发过程中必须遵循软件工程
的基本原则,这些基本原则包括抽象、信息屏蔽、模式化、
局部化、确定性、一致性、完备性和可验证性。
(1)抽象(abstraction),抽取各个事物中共同的最基
本的特征和行为,暂时忽略它们之间的差异。抽象使软件
的可理解性增强并有利于开发过程的管理。
(2)信息隐藏(information hiding),将模块内部的信
息(数据和过程)封装起来。其他模块只能通过简单的模
块接口来调用该模块,而不能直接访问该模块内部的数据
或过程,即将模块设计成“黑箱”。信息隐藏的原则可使
开发人员把注意力集中于更高层次的抽象上。
(3)模块化(model)模块是程序中相对独立的成分,
一个独立的编程单位,应有良好的接口定义。模块的大小
要适中,模块过大会使模块内部的复杂性增加,不利于模
块的理解和修改,也不利于模块的调试和重用;模块太小
会导致整个系统表示过于复杂,不利于控制系统的复杂性。
(4)局部化(localization),即在一个物理模块内集
中逻辑上相互关联的计算资源。局部化支持信息隐藏,从
而保证模块之间具有松散的耦合、模块内部有较强的内聚。
这有助于控制每一个解的复杂性。
(5)一致性(consistency),整个软件系统(包括程
序、数据和文档)的各个模块应使用一致的概念、符号和
术语;程序内部接口应保持一致;软件与环境的接口应保
持一致;系统规格说明应与系统行为保持一致;用于形式
化规格说明的公理系统应保持一致。
(6)完全性(completeness),软件系统不丢失任何
重要成分,完全实现所需的系统功能的程度。为了保证系
统的完全性,在软件的开发和维护过程中需要严格的技术
评审。
(7)可验证性(verifiability),开发大型软件系统需要
对系统逐层分解。系统分解应遵循易于检查、测试、评审
的原则,以使系统可验证。
 抽象、信息隐藏、模块化和局部化的原则支持可理解
性、可修改性、可靠性等目标,并可提高软件产品的质量
和开发效率;
 一致性、完全性和可验证性等原则可以帮助软件开发
人员去实现一个正确的系统。
7.1.5软件开发工具与环境
软件开发的工具软件:支持软件项目的开发、管理、
维护活动的软件
例如,项目管理工具、需求分析工具、设计工具、编
码工具、测试工具、维护工具等。
软件开发环境是指支持软件产品开发的软件系统,它
由软件工具集和环境集成机制构成。工具集包括支持软件
开发相关过程、活动、任务的软件工具,以便对软件开发
提供全面的支持。环境集成机制为工具集成和软件开发、
维护与管理提供统一的支持,它通常包括数据集成、控制
集成和界面集成3个部分。
在软件工程活动中,人们按照软件工程的原则和方法,利用
计算机及其集成的软件开发环境,辅助软件项目的开发、维护
及管理的过程,称为计算机辅助软件工程(即CASE,
Computer-Aided Software Engineering)。
CASE工具和环境的核心是软件工程信息库。这些工具和环
境应遵循统一的标准,在操作系统、网络和数据库的支持下工
作,以便使开发者们方便地相互通信并协同工作。
7.2 结构化分析方法
结构化方法是结构化分析、结构化设计和结构化编程的总
称;其核心和基础是结构化程序设计理论。
7.2.1 需求分析和需求分析方法
1. 需求分析
软件需求分析是指用户对目标软件系统在功能、行为、性
能、设计约束等方面的期望。需求分析的任务是发现需求、求
精、建模和定义需求的过程。
(1)需求分析的定义
1997年在IEEE软件工程标准词汇表中对需求分析定义是:
①用户解决问题或达到目标所需的条件或权能;
②系统或系统部件要满足合同、标准、规范或其他正式规
定文档所需具有的条件或权能;
③一种反映①或②所描述的条件或权能的文档说明。
(2)需求分析阶段的工作
需求分析阶段的工作可概括为需求获取,需求分析,编写需
求规格说明书和需求评审。
2. 需求分析方法
常见的需求分析方法有结构化分析方法和面向对象的分析
方法。
7.2.2 结构化分析方法(SA)
SA(Structured Analysis)是结构化程序设计理论在软件
需求分析阶段的运用;是20世纪70年代中期由E.Yourdon等人
倡导的一种面向数据流的分析方法。T.DeMarco对SA所下的
定义为“结构化分析就是使用数据流图(DFD)、数据字典(DD)、
结构化语言、判定表和判定树等工具,来建立一种新的称为结
构化说明书的目标文档”。随着计算机的发展,结构化分析方
法有了一些改进,但最基本的内容还是应用DFD、DD和
PSPEC(Process Specification,加工说明)来描述系统的功
能模型。
结构化分析方法的实质是着眼于数据流,自顶向下,逐层
分解,建立系统的流程,以数据流图和数据字典为主要工具,
建立系统的逻辑模型。
结构化分析的步骤:
1)通过对用户的调查,以软件的需求为线索,获得当前系
统的具体模型;
2) 去掉具体模型中非本质因素,抽象出当前系统的逻辑模
型;
3)根据计算机的特点,分析当前系统与目标系统的差别,
建立目标系统的逻辑模型;
4)完善目标系统并补充细节,写出系统的软件需求规格
说明;
5)评审直到确认完全符合用户对软件的需求。
1.结构化分析的常用工具
(1)数据流图(Data Flow Diagram, DFD)
数据流图是描述数据处理过程的工具,是需求理解的逻辑模
型的图形表示,它直接支持系统的功能建模,它从数据传递和
加工的角度,刻画了数据流从输入到输出的移动变换过程,数
据流图的基本符号的含义说明如下:
表7.1数据流图的基本符号的含义
数据流图的附加符号图7.4,表示数据流之间的关系。
图7.4 表明多个数据流与加工之间关系的符号
(2) 数据流图的绘制步骤(以学生成绩管理系统为例)
①画顶层数据流图。通常把整个系统当作一个大的加工,
标出系统的输入、输出及数据的源点与汇点,如图7.5。
图7.5 学生成绩管理系统的顶层DFD
②画第二层数据流图。
图7.6 学生成绩管理系统的分层DFD
③画第三层数据流图。第二层数据流图中的加工细节还不够
清晰,需要把每个加工继续分解成更小的加工。
图7.7 学生成绩管理系统查询细化DFD
图7.8 学生成绩管理系统统计细化DFD
图7.9 学生成绩管理系统编辑细化DFD
(3)数据字典
数据字典(Data Dictionary,DD)是结构化分析方法的
另一种有力工具,是结构化分析方法的核心。数据字典是对所
有与系统相关的数据元素的一个有组织的列表,以及精确的、
严格的定义,使得用户和系统分析员对于输入、输出、储存成分
和中间计算结果有共同的理解。
概括地说,数据字典的作用是对DFD中出现的被命名的图
形元素做确切解释。通常数据字典包含的信息有:名称、别名、
何处使用/如何使用、内容描述、补充信息等。
同时,数据字典也是软件维护时使用的一种重要资料。如
果要求所有开发人员都根据公共的数据字典描述数据和设计模
块,则能避免许多麻烦的接口问题,提高开发的效率和质量。
①数据字典的内容
数据字典是对数据流图中出现的所有数据元素给出定义。它
对数据流图上的数据流名字、加工名字和文件名字给出了确切
的解释,并按照字典的方式组织起来,以便于查询和维护。主
要
包括:数据流词条描述、数据项词条描述、数据文件词条描
述、加工逻辑词条描述、源点及汇(终)点词条描述。
②数据字典的数据定义方法
在对数据进行定义时,可以使用数据各成分的组合来表
示该数据,这些组合又由更底层的成分组合进行定义
表7.2 数据字典定义式中的符号
含
义
说
明
符 号
=
表示定义为
用于对=左边的条目进行确切的定义
+
表示与关系
X=a+b表示X由a和b共同构成
[ | ]
或[ , ]
表示或关系
X=[a|b]与X=[a,b]的等价,表示X由a或b组成
( )
表示可选项
X=(a)表示a可以在X中出现,也可以不出现
{ }
表示重复
大括号中的内容重复0到多次
表示规定次数的重复
重复的次数最少m次,最多n次
“ ”
表示基本数据元素
“ ”中的内容是基本数据元素,不可再分
..
连接符
Month=1..12表示month可取1~12中的任意值
* *
表示注释
两个星号之间的内容为注释信息
m{ }n
总之,数据字典与数据流图应相辅相成、互相配合,并 应
遵守以下约定:
1)有关数据的流向在数据流图中描述;
2)有关数据的组成在数据字典中描述;
3)有关数据的加工细节在数据字典中描述;
4)编写数据字典时不能有遗漏和重复,即遵循不重不漏的
原则;
5) 数据字典小的条目的排列要有一定规律,要能通过名
字方便地查阅条目的内容,如按英文字母表顺序或按汉字笔划
顺序排列或按功能分类等;
6)数据字典的编写要易于更新修改。
7.2.3软件需求规格说明书
软件需求规格说明书(Software Requirement
Specification, SRS) 是需求分析阶段的最后成果,是软件开发中
的重要文档之一。
1.软件需求规格说明书的作用:
(1)便于用户、开发人员进行理解和交流。
(2)反映出用户问题的结构,可以作为软件开发工作的基础
和依据。
(3)作为确认测试和验收的依据。
2.软件需求规格说明书的内容
软件需求规格说明书的内容包括概述、数据描述、功能
描述、性能描述、参考文献和附录等。
3.软件需求规格说明书的特点:
正确性、无歧义性、完整性、可验收性、一致性、可理
解性、可修改性、可追踪性。
7.3 结构化设计方法

7.3.1有关软件设计的基本内容
1.软件设计的任务和目标
软件设计是软件工程的重要阶段,是一个把软件需求转
换为软件表示的过程。软件设计的基本目标是用比较抽象、
概括的方式确定目标系统如何完成预定的任务,即软件设计
是确定系统的物理模型。
从技术观点上看,软件设计包括软件结构设计、数据设
计、接口设计和过程设计。其中,结构设计定义软件系统各
主要部件之间的关系;数据设计将分析时创建的模型转化为
数据结构的定义;接口设计是描述软件内部、软件和协作系
统之间以及软件与人之间如何通信;过程设计则是把系统结
构部件转换为软件的过程性描述。
从工程管理角度来看,软件设计包括概要设计和详细设
计两部分。
概要设计:将软件需求转换为软件结构和数据结构,并编
写概要设计说明书;
详细设计:通过对软件结构的细化,得到软件的详细的算
法和数据结构,产生描述软件的详细设计文档。
2.软件设计的基本原理
软件设计遵循软件工程的基本目标和原则,建立了适用于
在软件设计中应该遵循的基本原理和软件设计有关的概念。
(1)抽象:抽象是一种思维工具,就是把事务的本质的共同
特性提取出来,而不用考虑其他细节。
(2)模块化:模块化是指把一个待开发的软件分解成若干小
的简单部分。
(3)信息隐蔽:信息隐蔽是指在一个模块内包含的信息(过
程或数据),对于不需要这些信息的其他模块来说是不能访问
的。

(4)模块的独立性:模块的独立性是指在每一个模块只完
成系统要求的独立的子功能,并且与其他模块的联系最少且
接口简单。
模块的独立程度是评价设计好坏的重要度量标准。衡量
软件的模块独立性使用耦合性和内聚性两个定性的度量标准。
在程序结构中,各模块的内聚性越强,则耦合性越弱。一般
较优秀的软件设计,应尽量做到高内聚,低耦合,即减弱模
块之间的耦合性和提高模块内的内聚性,有利于提高模块的
独立性。
1)内聚性:内聚性是一个模块内部各个元素间彼此结合
的紧密程度的度量。
2)耦合性:耦合性是模块间相互连接的紧密程度的度量。

7.3.2有关结构化设计方法的基本内容

与结构化需求方法相对应的是结构化设计方法。结构化
设计方法是采用最佳的可能方法设计系统的各个组成部分以
及各成分之间的内部联系的技术。也就是说,结构化设计方
法是这样一个过程,它决定用哪些方法把哪些部分联系



起来,才能解决好某个具体的、有清楚定义的问题。

结构化设计方法的基本思想是将软件设计成由相对独立、
有单一功能的模块组成的结构。以面向数据流的结构化方法
为例,结构化设计方法主要包括概要设计和详细设计。

1. 概要设计(又称为初步设计或总体设计)的主要任务:

(1)设计软件系统结构

(2)设计数据结构及数据库

(3)编写概要设计文档

(4)概要设计文档评审

2. 设计软件结构的图形工具

(1)层次图和HIPO图:层次图用来描绘软件的层次结构,
很适于在自顶向下设计软件的过程中使用。在图7.10中已经
非正式地使用了层次图。
图7.10学生成绩管理系统的层次图

在层次图(H图)里除了最顶层的方框之外,每个方框
都加编号。像图7.11这样带编号的层次图称为HIPO图(层
次图加输入/处理/输出图的英文缩写)。
图7.11学生成绩管理系统HIPO图
(2)结构图(Structure Chart,SC)
 结构图(也叫程序结构图、软件结构图、系统结构图)的
符号
 方框代表模块,框内注明模块的名字或主要功能。
 方框之间的大箭头或直线表示模块的调用关系。
 带注释的小箭头表示模块调用时传递的信息及其方向。尾
部加空心圆的小箭头表示传递数据信息,加实心圆的小箭
头表示传递控制信息。
 结构图是SD方法使用的主要描述工具,用来描述软件的组
成模块及其调用关系。
 依据结构化设计思想,构成结构图的基本形式如图7.12所
示。经常使用的结构图有四种类型模块如图7.13所示。
图7.12 结构图构成的基本形式
图7.13系统结构图中的模块类型
。






1)传入模块 :从下属模块取得数据,经过某些处理,
再将其传送给上级模块。
2)传出模块 :从上级模块获得数据,进行某些处理,
再将其传送给下属模块。
3)变换模块 :即加工模块。它从上级模块取得数据,
进行特定的处理,转换成其他形式,再回传给上级模块。
大多数计算模块(原子模块)属于这一类。
4)协调模块 :对所有下属模块进行协调和管理的模块。
在系统的输入/输出部分或数据加工部分可以找到这样的
模块。在一个好的系统结构图中,协调模块应在较高层出
现
结构图的形态特征包括深度(模块的层数)、宽度(一层
中最大的模块个数)、扇出(一个模块直接调用下属模块的
个数)和扇入(一个模块直接上属模块的个数)。
画结构图时,同一名字的模块在结构图中只出现一次;
调用关系只能从上到下;模块调用次序一般从左到右。






3. 面向数据流的设计方法
所有系统的DFD结构可分为两种典型形式:即变换型结
构和事务型结构。相应地,由数据流图转换成的软件结构图
也有变换型和事务型两种结构。
(1)变换型结构
变换型数据流图中数据的处理过程大致可分为3步,即输入
数据、变换数据和输出数据。
将变换型数据流图映射为软件结构图的方法是:首先将
数据流图的输入、变换和输出部分分别转换为输入、变换和
输出模块;然后在输入、变换和输出模块之上增加总控模块,
以调度这3个模块,协调完成任务。
总控模块的工作过程如下:
 调用输入模块,获取输入数据;
 调用加工模块,将获取的输入数据传给加工模块,获取
加工模块加工好的数据;
 调用输出模块,将获取的加工好的数据传给输出模块,
由输出模块输出该数据。






(2)事务型结构
事务型数据流图有一个明显的事务中心,它接受一项
事务,根据该事务的特点和性质,选择分配一个适当的处
理单元,然后输出结果。所以,事务型数据流图由接受事
务、事务中心和若干处理单元输出结果部分组成。
将事务型数据流图映射为软件结构图的方法是:首先
将数据流图中的各个部分转换成软件结构图中的相应模块;
然后增加调度模块,让它调度n个处理单元,最后让事务
中心模块调度接受事务、调度和输出结果模块。
事务中心模块的工作流程如下:
a) 调用接受事务模块,接受一项事务;
b) 调用调度模块选择分配处理单元,获取处理结果;
c) 调用输出模块输出结果。
4. 设计准则
面向数据流设计方法的设计准则包括提高模块独立性;
模块规模适中;深度、宽度、扇出和扇入适当;使模块的
作用域在该模块的控制域内;应减少模块的接口和
界面的复杂性;设计成单入口、单出口的模块;设计功能可
预测的模块。

7.3.3详细设计

在概要设计阶段完成了软件系统的总体设计,规定了各
个模块的功能及模块之间的联系之后,进一步就要考虑实现
各个模块规定的功能,也就是进行软件的详细设计,也称为
过程设计。
在详细设计阶段,要根据概要设计对每个模块的定义进
行设计,以实现指定的功能、算法和外部接口所要求的模块
内部的数据结构和程序的逻辑结构。
详细设计的重点在如何描述程序的逻辑结构。只有有了
好的详细设计,才能设计出可维护性好质量好的软件。详细
设计阶段主要采用结构化程序设计方法(Structured
Programming,SP),与SA和SD方法相衔接。当前流行的
表示程序逻辑结构的方式有3种:


 图形描述
 语言描述
 表格描述


其中图形描述工具主要有程序流程图、N-S图及PAD图等;
语言描述工具主要有PDL;表格描述有判定表及判定树等。
1.程序流程图(Program Flow Chart)又称为程序框图。
基本符号如图7.14所示。
图7.14程序流程图的基本符号
为使用流程图描述结构化程序,必须限制流程图只能使用
如图7.15所给出的5种基本控制结构。
图7.15 五种基本控制结构
 任何复杂的程序流程图都应由这5种基本控制结构组成;
其含义分别为:
顺序型:几个连续的加工步骤依次排列,执行时按先后顺
序执行;
选择型:依逻辑判断式的取值决定选择两个加工中的一个
来执行;
先判定型循环:先对循环控制条件进行判定,成立时,重
复执行选定的加工否则退出循环;
后判定型循环:先执行一次循环体,再对结束循环控制条
件进行判定,成立时,退出循环,否则重复执行循环体;
多情况型选择:列举多个加工情况,根据控制变量的取值
,选择执行其一。
表7.3常用标准程序流程图符号
符
号
说
明
起止端点,表示转向外部环境或从外部环境转入的端点符
数据的输入及输出
处理过程
准备或预处理
条件判断
流程线
虚线
注解或注释
2. N-S图
N-S图也称盒图(Box-Diagram),是由Nassi 和
Shneiderman提 出的一种符合结构化程序设计原则的图形描述
工具。
在N-S图中,相应规定了5种图形构件,如图7.16所示。
图7.16 N-S图的5种基本控制结构


从上面图可以看出,N-S图有以下几个特点:
a) 图中每个矩形框都是明确定义了的功能域。
b) 图中的控制转移不能任意规定,必须遵守结构化程
序设计要求。
c)从图中可以很容易地确定局部数据和全局数据的作用
域。
d)图中很容易表现嵌套关系及模块的层次结构。
3. PAD图
PAD(Problem Analysis Diagram,问题分析图),是
日本日立公司提出的用结构化程序设计思想表现程序逻辑结
构的图形工具。现在已被ISO认可。PAD也设置了5种基本
控制结构的图式,并允许递归使用。这5种基本控制结构如
图7.17所示。
图7.17 PAD的基本控制结构


其中:
①表示按顺序先执行A,再执行B。
②给出了判断条件为P的选择型结构。当P为真时执行
上面的A框中的内容,当P为假时执行下面的B框中的内容。
如果这种选择型结构只有A框,没有B框,表示该选择结构
中只有THEN后面有执行语句A,没有ELSE部分。
③与④中P是循环判断条件,S是循环体。
⑤是CASE型结构。当判定条件P=1时,执行A1框的内
容,P=2时,执行A2框的内容,P=n时,执行An框的内容。
PAD的执行顺序是从上到下,从左到右,即从最左主干
线的上端的结点开始,自上而下依次执行。 每遇到判断或循
环,就自左而右进入下一层,从表示下一层的纵线上端开始
执行,直到该纵线下端,再返回上一层的纵线的转入处。如
此继续,直到执行到主干线的下端为止。


用PAD所表达的程序,结构清晰并且结构化程度高。作
为一种详细设计的工具,它比流程图更易读,且由于PAD是
一种树形结构,比流程图更容易在计算机上处理,容易将
PAD图转换成程序。另外,PAD除了可以描述程序的逻辑结
构,还可以描述数据结构。
4.判定表与判定树
(1)判定表(Decision Table)
判定表一般由4部分组成:左上半部分列出所有条件、
左下半部分列出所有动作、右上半部分列出各种条件组合,
右下半部分列出和每组条件取值组合对应的动作。其结构图
如图3.33所示。
图
3.33 判定表结构示意图
判定表的优点是能够简洁,无二义性的描述所有的处
理规则。
缺点是它所表示的是静态逻辑,是在某种条件组合情
况下可能的结果,它不能表达加工的顺序,也不能表达循
环结构。因不能成为一种通用的设计工具,一般配合其他
工具一起使用。
(2)判定树(Decision Tree)
判定树实质上是判定表的一种变形,本质上是
一样的。判定树的优点是形式简单、比较直观、易
于掌握和使用。缺点是不如判定表简洁。
5. 过程设计语言PDL(Program Design Language)

PDL是一种用于描述功能模块的算法设计和加工细节的
语言,称为设计程序用语言。它是一种伪码,是一个笼统的
名称,现在有许多种不同的过程设计语言在使用。
PDL作为一种用于描述程序逻辑设计的语言,具有以下
特点:
(1)有固定的关键字外语法,提供全部结构化控制结
构、数据说明和模块特征。
(2)内语法使用自然语言来描述处理特性。
(3)有数据说明机制,包括简单的(如标量和数组)
与复杂的(如链表和层次结构)的数据结构。
(4)有子程序定义与调用机制,用以表达各种方式
的接口说明
7.4软件测试
7.4.1 软件测试的目的和准则
1. 软件测试的目的
测试的目的就是在软件投入运行之前,尽可能多地发现
软件中的错误。软件测试是对软件规格说明、设计和编码的
最后复审,所以软件测试贯穿在整个软件开发期的全过程。
软件测试是为了发现错误而执行程序的过程。或者说,软件
测试是根据软件开发各阶段的规格说明和程序的内部结构而
精心设计一批测试用例(即输入数据及其预期的输出结果),
并利用这些测试用例去运行程序,以发现程序错误的过程。
Grenford J.Myers就软件测试目的提出了以下观点:
(1)测试是程序执行的过程,目的在于发现错误。
(2)个好的测试用例在于能发现至尽尚未发现的错误。
(3)一个成功的测试是发现了至今尚未发现的错误的测试。
2.软件测试的原则
(1)应当尽早规划和不断地进行软件测试。
(2)测试用例设计应包括测试输入数据和与之对应的预期输
出结果。
(3)程序员应避免检查自己的程序。
(4)在设计测试用例时,应包括合理的输入条件和不合理的
输入条件。
(5)充分注意测试中的群集现象。
(6)严格执行测试计划,排除测试的随意性。
(7)应当对每一个测试结果做全面检查。
(8)妥善保存测试中的有关数据和最终分析报告,为维护提
供方便。
2.软件测试的原则(续)
(9)应该从“小规模”测试开始,并逐步进行“大规模”测试。
(10)穷举测试是不可能的,应有一个终止的标准
7.4.2软件测试技术与方法
按照测试过程是否执行程序来分,有静态分析和动态测试;
按照测试数据的设计依据和功能可分为黑盒法与白盒法。
1.静态分析和动态测试
静态分析不执行被测软件,通常对需求分析说明书、软件
设计说明书与源程序作结构检查、流程图分析、编码分析等来
发现软件错误,这是十分有效的软件质量控制方法。
动态测试以执行程序并分析程序来查错。需要事先准备好
测试数据:输入数据和预期的输出结果。把输入数据和与之对
应的预期输出结果称为测试用例。怎样设计测试用例是动态测
试的关键。
2.白盒测试和黑盒测试
(1)白盒测试
白盒测试方法也称为结构测试或逻辑驱动测试。此方法把
测试对象看做一个透明的盒子,它允许测试人员利用程序内部
的逻辑结构及有关信息,设计或选择测试用例,对程序所有逻
辑路径进行测试。
白盒测试的基本原则是:保证所测模块中每一独立路径至
少执行一次;保证所测模块所有判断的每一支至少执行一次;
保证所测模块每一循环都在边界条件和一般条件下至少执行一
次;验证所有内部数据结构的有效性。
白盒测试的主要方法有逻辑覆盖、基本路径测试等。
逻辑覆盖测试泛指一系列以程序内部的逻辑结构为基础的
测试用例设计技术。通常,程序中的逻辑表示有判断、分支、
条件等几种表示方式。逻辑覆盖测试包括语句覆盖、路径覆盖、
判定覆盖、条件覆盖、判断一条件覆盖五种测试用例设计技术。
(2)黑盒测试
黑盒测试也称为功能测试或数据驱动测试。这种方法是把
测试对象看做一个黑盒子,测试人员完全不考虑程序内部的逻
辑结构和内部特性,只依据程序的需求规格说明书,检查程序
的功能是否符合它的功能说明。
黑盒测试方法主要有等价类划分法、边界值分析法、错误推
测法、因果图等,主要用于软件确认错误。
等价类划分法是一种典型的黑盒测试方法。它是将程序的
所有可能的输入数据划分成若干部分,然后从每个等价类中选
取数据作为测试用例。
使用等价类划分法设计测试方案,首先要划分输入集合的等
价类。等价类包括:

有效等价类:合理、有意义的输入数据构成的集合。

无效等价类:不合理、无意义的输入数据构成的集合。
边界值分析法是对各种输入、输出范围的边界情况设计测
试用例的方法。实践证明,程序往往在处理边缘情况时出错,
因而检查边缘情况的测试实例查错率较高,这里边缘情况是指
输入等价类或输出等价类的边界值。
错误推测法在很大程度依靠直觉和经验进行,它的基本想
法是列出程序中可能有的错误和容易发生错误的特殊情况,并
且根据它们选择测试方案。
7.4.3软件测试的实施
软件测试是保证软件质量的重要手段。软件测试是一个过
程,其测试流程是该过程规定的程序,目的是软件工作系统化。
软件测试过程一般按四个过程进行,即单元测试、集成测
试、验收测试和系统测试,通过这些步骤的实施来验证软件是
否合格,能否交给用户使用。
1.单元测试:指对软件设计的最小单位—模块进行正确
性检测的过程。其目的是发现模块内部可能存在的各种错误。
单元测试的技术可以采用静态分析和动态测试。单元测试的
依据是详细设计说明书和源程序。
单元测试主要针对模块来进行。它主要包括模块接口测
试,局部数据结构测试,重要的执行路径检查,出错处理测
试和影响以上各点及其他相关点的边界条件测试。
2.集成测试:指测试和组装软件的过程。它是把模块在
按照设计要求组装起来的同时进行测试,主要目的是发现与
结构有关的错误。集成测试的依据是概要设计说明书。
在集成测试的过程中将模块组装成程序,通常采用非增
方式组装与增量方式组装两种方式。非增量式组装方式也叫
一次性组装方式,又叫做整体拼装。使用这种方式,先对每
个模块分别进行模块测试,再把所有模块放在一起结合成所
要的程序,进行测试。增量式组装方式是把下一个要测试的
模块同已经测试好的那些模块结合起来进行测试,测试完
以后再把下一个应该测试的模块结合进来测试。增量方式包括
自顶向下、自底向上、自顶向下与自底向上相结合的混合增量
方法。
3确认测试:也称验收测试,任务是验证软件的功能和性
能及其他特性是否满足了规格说明书中确定的各种需求,以及
软件配置是否完全、正确,包括α测试和β测试
4.系统测试:将通过测试的软件作为整个基于计算机系统
的一个元素,与计算机硬件、外设、支持软件、数据和人员等
其他系统元素组合在一起,在实际运行环境下对计算机系统进
行一系列的集成测试和确认测试。
系统测试的目的在于通过与系统的需求定义作比较,发现
软件与系统定义不符合或与之矛盾的地方。系统测试的测试用
例应根据需求分析规格说明来设计,并在实际使用环境下运行。
系统测试的具体实施一般包括功能测试、性能测试、操作
测试、配置测试、外部接口测试、安全性测试等。。
7.5 程序的调试
7.5.1程序调试的基本概念
程序调试的任务是诊断和修改程序中的错误。程序调试活
动由两部分组成,其一是根据错误的迹象确定程序中错误的确
切性质、原因和位置。其二是对程序进行修改,排除这个错误。
1.程序调试的基本步骤:
(1)错误定位。错误定位是从错误的外部表现形式入手,研
究有关部分的程序,确定程序中出错的位置,找出错误的内在
原因。
(2)修改设计和代码,以排除错误。排错是软件开发过程中
一项艰苦的工作,这也决定了调试工作是一个具有很强技术性
和技巧性的工作。
(3)进行回归测试,防止引进新的错误。修改程序可能带来
新的错误,重复进行暴露这个错误的原始测试或某些有关测试,
以确认该错误是否被排除、是否引进了新的错误。
2.程序调试原则和注意事项
(1)确定错误的性质和位置时,应该分析、思考与错误征兆
有关的信息;避开死胡同;只把调试工具当作辅助手段来使用;
避免用试探法,最多只能把它当作最后手段。
(2)修改错误时应该注意,在出现错误的地方,很可能有别
的错误;修改错误的一个常见失误是只修改了这个错误的征兆
或这个错误的表现,而没有修改错误本身;修正一个错误的同
时有可能会引入新的错误;修改错误的过程将迫使人们暂时回
到程序设计阶段;修改源代码程序,不要改变目标代码。
7.5.2软件调试方法
调试的关键在于推断程序内部错误的位置和原因。软件调
试从是否跟踪和执行程序的角度,类似于软件测试,可分为静
态调试和动态调试。软件测试中讨论的静态分析方法同样使用
于静态调试。静态调试主要指通过人的思维来分析源程序代码
和排错,是主要的调试手段,而动态调试是辅助静态调试的,
主要调试方法可以采用:强行排错法、回溯法、原因排除法。
1.强行排错法作为传统的调试方法,其过程可概括为设置断
点、程序暂停、观察程序状态、继续运行程序。涉及的调试技
术主要是设置断点和监视表达式。
2.回溯法适合于小规模程序的排错,即一旦发现了错误,先
分析错误征兆,确定最先发现“症状”的位置。然后,从发现
“症状”的地方开始,沿程序的控制流程,逆向跟踪源程序代
码,直到找到错误根源或确定出错产生的范围。

原因排除法是通过演绎、归纳和二分法来实现的。
 演绎法:是一种从一般原理或前提出发,经过排除和精
化的过程来推导出结论的思考方法。
 归纳法:是一种从特殊推断出一般的系统化思考方法,
其基本思想是从一些线索着手,通过分析寻找到潜在的
原因,从而找出错误。
 二分法:如果已知每个变量在程序中若干个关键点的正
确值,则可以使用定值语句(如赋值语句、输入语句等)在
程序中的某点附近给这些变量赋正确值,然后运行程序
并检查程序的输出,这是二分法实现的基本思想。
习题7
一、选择题
 1、下列叙述中正确的是
。(2005年9月)
A)程序设计就是编制程序
B)程序的测试必须由程序员自己去完成
C)程序经调试改错后还应进行再测试
D)程序经调试改错后不用进行再调试
 2、下列描述中正确的是
。(2005年9月)
A)软件工程只是解决软件的管理问题
B)软件工程主要解决软件产品的生产率问题
C)软件工程的主要思想是强调在软件开发的过程中需要应用
工程化原则
D)软件工程只是解决软件开发中的技术问题
3、在软件设计中,不属于过程设计工具的是
。(2005
年9月)
A)PDL(过程设计语言)
B)PAD图
C)N—S图
D)DFD图
4.下列叙述中正确的是
。(2005年9月)
A)软件交付使用后还需要进行维护 B)软件一旦交付使用
就不需要再进行维护
C)软件交付使用后其生命周期便结束 D)软件维护是指修
复程序中被破坏的指令
5.两个或两个以上模块之间关联的紧密程度称为
。
(2006年4月)
A)耦合度 B)内聚度 C)复杂度 D)数据传输特性
6.下列叙述正确的是
。(2006年4月)
A)软件测试应该由程序开发者来完成
B)程序经调试不需要再测试
C)软件维护只包括对程序代码的维护 D)以上三项都不对
7.从工程管理角度,软件审计一般分为两步完成,它们是
。
(2006年9月)
A) 概要设计和详细设计
B)数据设计和接口设计
C) 软件结构设计和数据设计 D)过陈设计和数据设计
8.下列选项中不属于软件生命周期开发阶段任务的是
。
(2006年9月)
A)软件测试
B)概要设计
C)软件维护
D)详细设计
9.下列叙述中正确的是
。
A) 软件测试的主要目的是发现程序中的错误
B) 软件测试的主要目的是确定程序中错误的位置
C) 为了提高软件测试的效率,最好由程序编制者自己来完
成软件测试的工作
D) 软件测试是证明软件没有错误
10.软件是指
。
A)程序
B)程序和文档
C) 算法加数据结构
D)程序、数据与相关文档
11.软件调试的目的是_____。
A)发现错误
B)更正错误
C)改善软件功能
D)验证软件的正确性
12.下列对于软件测试的描述中正确的是_______。(2005年4月)
A) 软件测试的目的是证明程序是否正确
B) 软件测试的目的是使程序运行结果正确
C) 软件测试的目的是尽可能的多发现程序中的错误
D) 软件测试的目的是使程序的符合结构化原则
13.下列描述中正确的是
。(2005年4月)
A)程序就是软件
B)软件开发不受计算机系统的限制
C)软件既是逻辑实体又是物理实体
D)软件是程序、数据与相关文档的集合
14.在软件生命周期中,能准确地确定软件系统必须做什么和必
须具备哪些功能的是
。
A)概要设计 B)详细设计 C)可行性分析 D)需求分析






15.下列不属于软件工程的三个要素的是
。
A)工具
B)过程
C)方法
D)环境
16.检查软件产品是否符合需求定义的过程称为
。
A)确认测试 B)集成测试 C)验证测试 D)验收测试
17.下列不属于软件设计原则的是
。
A)抽象
B)模块化
C)自底向上 D)信息隐蔽
18.程序流程图(PFD)中箭头代表的是
。
A)数据流 B)控制流
C)调用关系 D)组成关系
19.下列工具中需求分析常用的工具是
。
A)PAD
B)PFD
C)N-S
D)DFD
20在结构化方法中,软件功能分解属于下列软件开发中的阶
段是
。
A)详细设计 B)需求分析 C)总体设计 D)编程调试
21.软件调试的目的是(
)
A)发现错误
B)改正错误
C)改善软件的性能 D)挖掘软件的潜能
二、填空题
1.在进行模块测试时,要为每个被测试的模块另外设计两类模
块:驱动模块和承接模块(桩模块).其中_
____的作用是将
测试数据传送给被测试的模块,并显示被测试模块所产生的结
果.(2005年9月)
2.程序测试分为静态测试和动态测试。其中___ ___是指不执
行程序,而只是对程序文本进行检查,通过阅读和讨论,分析
和发现程序中的错误。(2006年4月)
3.___
__的任务是诊断和改正程序中的错误(2006年9月)
4.软件测试分为白盒(箱)和黑盒(箱)测试,等价类划分法属于
___ ____(2007年4月)
5.软件的规格说明书具有完整性、无歧义性、可正确性、可修
改性等特性,其中最重要的是____
__(2007年9月)
6.在两种基本测试方法中,___
_ __测试的原则之一是保
证所测模块中每一个独立路径至少要执行一次。(2007年9月)
7.诊断和改正程序中错误的工作通常称
。(2005年
4月)
8.软件是程序、数据和
的集合。
9软件工程研究的内容主要包括:
技术和软件工程管
理。
10.数据流图的类型主要有
和事务型。
11.Jackson方法是一种面向
结构化方法。
12.软件开发环境是全面支持软件开发过程的
集合。
谢 谢!

similar documents