第8章 软件设计基础 教学目的：理解软件设计过程、抽象与逐步求精、 模块化与信息隐藏等概念。 教学重点：几个软件设计的基本概念。 第8章 软件设计基础 教学目的：理解软件设计过程、抽象与逐步求精、 模块化与信息隐藏等概念。 教学重点：几个软件设计的基本概念。 教学难点： 模块划分与软件损耗的关系。 教 具：多媒体教室、电子教案 作 业：

第8章 软件设计基础 软件设计阶段的工作是以需求分析阶段的成果为前提和基础的，即经过系统分析小组签字认可的需求规格说明书及有关技术文档。经过软件工程师们多年的努力，一些软件设计技术、质量评估标准和设计表示法逐步形成并用于软件工程实践。 软件设计是软件工程的重要阶段。软件设计过程是对程序结构、数据结构和过程细节逐步求精、复审并编制文档的过程，本章讨论与软件设计有关的主要概念。

8.1 软件设计基本概念 8.1.1 软件设计过程 一般认为，软件开发阶段由设计、编码和测试三个基本活动组成，其中“设计”活动是获取高质量、低耗费、易维护软件的一个最重要环节。 需求分析阶段获得的需求规格说明书包括对将要实现的系统在信息、功能和行为等各个方面的描述，这是软件设计的基础。对此不论采用何种软件设计方法都将产生: 系统的总体结构设计（architectural design）； 系统的数据设计（data design）； 系统的过程设计（procedural design）。

8.1.1 软件设计过程 信息描述 数据设计 功能描述 设计 总体结构设计 集成并确认的软件 程序 编码 测试 行为描述 模块 过程设计 8.1.1 软件设计过程 程序 模块 总体结构设计 设计 编码 信息描述 过程设计 数据设计 集成并确认的软件 测试 功能描述 行为描述 其他需求 图8-1-1 开发阶段的信息流

8.1.1 软件设计过程 软件设计也可看作将需求规格说明逐步转换为软件源代码的过程。 从工程管理的角度软件设计可分为概要（preliminary）设计和详细（detail）设计两大步骤。 概要设计是根据需求确定软件和数据的总体框架，详细设计是将其进一步精化成软件的算法表示和数据结构。 而在技术上，概要设计和详细设计又由若干活动组成，除总体结构设计、数据结构设计和过程设计外，许多现代应用软件，还包括一个独立的界面设计活动。

8.1.2 抽象与逐步求精 抽象是控制复杂性的基本策略。“抽象” 要求人们将注意力集中在某一层次上考虑问题，而忽略那些低层次的细节。 软件设计过程应当是在不同抽象级别上考虑和处理问题的过程。最初，应在最高抽象级别上，用面向问题域的语言叙述“问题”，概括“问题解”的形式，而后不断地具体化，不断地用面向过程的语言描述问题，最后，在最低的抽象级别上给出可直接实现的“问题解”，即程序。

8.1.2 抽象与逐步求精 软件工程过程的每一步都是对较高一级抽象的解作一次进一步具体化的描述。 8.1.2 抽象与逐步求精 软件工程过程的每一步都是对较高一级抽象的解作一次进一步具体化的描述。 在系统定义阶段，软件系统被描述为基于计算机的大系统的一个组成部分； 在软件规划和需求分析阶段，软件用问题域约定的习惯用语表达； 从概要设计过渡到详细设计时，抽象级再一次降低； 编码完成后达到了抽象的最低级。 在上述由高级抽象到低级抽象的转换过程中，伴随着一连串的过程抽象和数据抽象。 过程抽象把完成一个特定功能的动作序列抽象为一个过程名和参数表； 数据抽象把一个数据对象的定义（或描述）抽象为一个数据类型名。

【例8.1】考虑适用于低级CAD的图形软件包 抽象Ⅰ 该CAD软件系统配有能与绘图员进行可视化通信的图形界面，能用鼠标代替绘图工具，画各种直线和曲线；能完成所有几何计算以及所有截面视图和辅助视图的设计。图形设计的结果存在图形文件中，图形文件可包含几何的、正文的和其他各种补充设计信息。 显而易见，在这一抽象级别上，用问题域本身的术语来描述问题的解。

【例8.1】考虑适用于低级CAD的图形软件包 抽象Ⅱ CAD软件任务； 用户界面子任务； 创建二维图形子任务； 显示图形子任务； 管理图形文件子任务； end CAD. 在这一抽象级别上，给出了组成CAD软件任务的所有主要子任务，尽管术语已与问题域有所不同，但仍然不是实现所用的语言。

【例8.1】考虑适用于低级CAD的图形软件包 抽象Ⅲ（仅以“创建二维图形子任务”为例） PROCEDURE 创建二维图形 REPEAT UNTIL <创建图形任务终止> DO WHILE <出现与数字仪的交互时> 数字仪接口任务； 判断作图请求： 线：画线任务； 圆：画圆任务； ┇ END；

【例8.1】考虑适用于低级CAD的图形软件包 DO WHILE <出现与键盘的交互时> 键盘接口任务； 选择分析或计算： 辅助视图：辅助视图任务； 截面视图：截面视图任务； ┇ END； END REPEAT； END PROCEDURE.

【例8.1】考虑适用于低级CAD的图形软件包 在这一抽象级别上，给出了初步的过程性表示，此时所有术语都是面向软件（比如采用do‑while结构）并且模块结构也开始明朗。求精过程还可继续下去，直至产生源代码。

数据抽象 数据抽象与过程抽象一样，能使设计者按不同的详细程度表示数据对象。 仍以CAD软件为例，我们可定义一个称为drawing（图）的数据对象： TYPE drawing IS STRUCTURE DEFINED number IS STRING LENTH(12); geometry DEFINED… notes IS STRING LENTH(256); bom DEFINED… END drawing TYPE;

数据抽象 在此，drawing被表示为一种结构，其各个组成部件本身又可为某种数据抽象，比如geometry（几何图形）和bom。 blueprint IS INSTANCE OF drawing; 或 schematic IS INSTANCE OF drawing; 说明blueprint和schematic具有drawing的一切特性。 blueprint——蓝图，schematic——简（略）图。

数据抽象 在抽象数据类型的定义中可以附加一组操作的定义，用以确定在此类数据对象上可进行的操作。以抽象数据类型drawing为例，可以定义擦除（erase）、存储（save）、分类（catalog）和拷贝（copy）等操作。 许多程序设计语言都提供了对抽象数据类型的支持，Ada 的程序包机制是对数据抽象和过程抽象的双重支持

逐步求精 关于“逐步求精”，N.Wirth曾经做过如下说明： “我们对付复杂问题的重要办法是抽象，因此，对一个复杂的问题不应该立即用计算机指令、数字和逻辑符号来表示，而应该用较自然的抽象语言来表示，从而得出抽象程序。抽象程序对抽象的数据进行某些特定的运算并用某些合适的记号（可能是自然语言）来表示。对抽象程序做进一步分解，进入下一个抽象层次，重复这一精化过程直到程序能被计算机接受为止。这时的程序可能是用某种高级语言或机器指令书写的。”

过程求精与数据求精 因为求精的每一步都是用更为详细的描述替代上一层次的抽象描述，所以在整个设计过程中产生的，具有不同详细程度的各种描述，组成了系统的层次结构。层次结构的上一层是下一层的抽象，下一层是上一层的求精。 在过程求精的同时自然伴随着数据的求精，无论是过程还是数据，每一步细化都蕴涵着某些设计决策，因此设计人员必须掌握一些基本的准则，比较各种可能的候选方案。

8.1.3 模块化与信息隐藏 软件总体结构（下一节讨论）体现了模块化思想，即把软件划分为可独立命名和编制的部件，每个部件称为一个模块，当把所有模块组装到一起时，便可获得满足问题需要的一个解。 “模块化是唯一对软件中的程序进行智能化管理的一个属性”。

8.1.3 模块化与信息隐藏 假设： 函数C（X）——问题X的复杂性； 函数E（X）——求解问题X需要花费的工作量（时间）； 8.1.3 模块化与信息隐藏 假设： 函数C（X）——问题X的复杂性； 函数E（X）——求解问题X需要花费的工作量（时间）； 对于问题P1和P2，如果 ： C（P1）>C（P2） 则有 : E（P1）>E（P2） 结论：解决一个复杂问题总比解决一个简单问题耗费 更多的工作量。 同时 有：C（P1+P2）>C（P1）+C（P2） 结论：由P1、P2组合而成的问题的复杂性往往比考虑 单个问题复杂性的和更大。 于是有： E（P1+P2）>E（P1）+E（P2）

8.1.3 模块化与信息隐藏 软件总成本 成本或 工作量 最小成本 区域M 用于接口的成本 每个模块成本之和 模块总数 O 8.1.3 模块化与信息隐藏 软件总成本 成本或 工作量 最小成本 区域M 用于接口的成本 每个模块成本之和 模块总数 O 图8-1-2 模块与软件耗费

1．信息隐蔽 信息隐蔽原理告诉我们，模块应该设计得使其所含信息（过程和数据）对于那些不需要这些信息的模块不可访问；每个模块只完成一个相对独立的特定功能；模块之间仅仅交换那些为完成系统功能必须交换的信息，即模块应该独立。显然，模块独立的概念是模块化、抽象、信息隐蔽和局部化等诸多概念的直接结果。

信息隐蔽原理的好处 它不仅支持模块的并行开发，而且还可减少测试和后期维护的工作量。因为测试和维护阶段不可避免地要修改设计和代码，模块对大多数数据和过程处理细节的隐蔽可以减少错误向外传播。此外，整个系统欲扩充功能亦只需“插入”新模块，原有的多数模块无须改动。

2．内聚度（cohesion） 内聚度是前述信息隐蔽和局部化概念的自然扩展，它标志一个模块内部各成分彼此结合的紧密程度。 内聚度按其高低程度可分为七级，内聚度越高越好。

1）偶然性内聚——低级内聚 偶然性内聚（coincidental cohesion）。是指一个模块内各成分为完成一组功能而组合在一起，它们相互之间即使有关系，也很松散。常见的偶然性内聚情形是，当程序员写完一个程序后发现有一组语句多处出现，于是为节省内存便将这组语句单独组成一个模块。 X Y Z W

2）逻辑性内聚——低级内聚 如果一个模块完成的诸任务逻辑上相关，则称之为逻辑性内聚（logical cohesion） 例如：一个模块产生所有与类型无关的输出，即为逻辑性内聚。 又如：模块X、Y分别调用A、B，A、B相似，将其合并为模块AB，模块AB即为逻辑性内聚。 S S X Y X Y A B AB

3）时间性内聚——低级内聚 如果一个模块包含的诸任务必须在同一时间段内执行（例如一个初始化模块），则称之为时间性内聚（temporal cohesion）。 以上三种内聚形式通常认为是低级内聚。

4）过程性内聚——中级内聚 过程性内聚（procedural cohesion） 模块的过程性内聚度是指，模块内成分彼此相关，并且必须按特定的次序执行； 过程内聚模块的各组成功能由控制流联结在一起。

通信性内聚（communicational cohesion）。 5）通信性内聚度——中级内聚 通信性内聚（communicational cohesion）。 模块的通信性内聚度是指，模块中各成分都将对数据结构的同一区域进行操作，以达到通信的目的。 例如，模块A的处理单元是由同一数据文件的数据产生不同的表格 模块A 从文件FILE读出数据 1. 由数据产生报表一 2. 由数据产生报表二

6）顺序性内聚 ——高级内聚 顺序性内聚（sequential cohesion） 。 如果一个模块内的各处理成分均与同一功能相关，且这些处理必须顺序执行，则称顺序内聚； 通常，一个处理成分的输出是另一个处理成分的输入。例如： 1. 输入系数 2. 求方程的根 3. 打印方程的根 求一元二次方程 根的模块

7）功能性内聚——高级内聚 功能性内聚（functional cohesion）。 如果模块内所有成分形成一个整体，完成单个功能，则称功能内聚，功能内聚是最高程度的内聚形式。 例如，一个模块仅完成一个矩阵的输出，就是一个具有功能性内聚的模块。 设计软件时，应该能够识别内聚度的高低，并通过修改设计尽可能提高模块内聚度，从而获得较高的模块独立性。

3．耦合度 耦合度是对软件结构中模块间关联程度的一种度量。 耦合的强弱取决于模块间接口的复杂性、进入或调用模块的位置以及通过界面传送数据的多少等。 与内聚度正好相反，在设计软件时应追求尽可能松散耦合的系统。因为对这类系统中任一模块的设计、测试和维护相对独立。由于模块间联系较少，错误在模块间传播的可能性也随之变小。 模块间的耦合程度直接影响系统的可理解性、可测试性、可靠性和可维护性。 耦合度也可以分为七级

如果两模块中任一个都不依赖于对方能独立工作，则称这两模块为（nodirect coupling），这类耦合度最低。例如： 1）非直接耦合——最松散的耦合 耦合度也可以分为七级： 如果两模块中任一个都不依赖于对方能独立工作，则称这两模块为（nodirect coupling），这类耦合度最低。例如： X Y A B 无关系

通过参数 传递数据 2）数据耦合 数据耦合（data coupling） 如果两模块间通过参数交换信息，而信息仅限于数据，则称这两模块为数据耦合。一般软件系统中都存在数据耦合，它是完成大多数功能所必需的。例如： A 通过参数 传递数据 B

produce report cards calculate average print report card 3）特征耦合 特征耦合（stamp coupling） 介于数据耦合和控制耦合之间的是特征耦合（stamp coupling）。例如，传递了求平均成绩以外的参数： produce report cards studengt record averrage averrage studengt record calculate average print report card

4）控制耦合 控制耦合（control coupling）。 如果两模块间通过参数交换信息，此时若传递的信息中含有控制信息，则耦合度上升为控制耦合。控制耦合通常会增加系统的复杂性，有时适当分解模块可消除控制耦合。

5）外部耦合 外部耦合（external coupling）。 当若干模块均与同一个外部环境关联（例如，I/O处理使所有I/O模块与特定的设备、格式和通信协议相关联），它们之间便存在外部耦合。外部耦合尽管需要，但应限制在少数几个模块上。

6）公共耦合 公共耦合（common coupling） 当若干模块通过全局的数据环境相互作用时，它们之间存在公共耦合。全局数据环境中可能含有全局变量、公用区、内存公共覆盖区、任何存储介质上的文件、物理设备等。

7）内容耦合 内容耦合（content coupling）。 最高耦合度是内容耦合，出现内容耦合的情形包括：当一个模块使用另一个模块内部的数据或控制信息；一个模块直接转移到另一个模块内部，等等。

8.1.3 模块化与信息隐藏 一般来说，设计软件时应尽量使用数据耦合，减少控制耦合，限制外部环境耦合和公共数据耦合，杜绝内容耦合。 值得指出，模块化设计的思想适用于任何软件系统的设计。当某些软件系统（如实时软件等），因不能容忍子程序调用引起的时间开销而必须以整块软件的形式出现时，软件设计仍然应该以模块化设计的思想为指导，直至编码时再改用代入式（in‑line）方法。这样，源程序中虽不含明显的模块，但模块化设计所带来的大部分益处却已被系统获得。

教学题目 8.1.4~8.1.6，8.2，8.3 教学目的：理解软件设计的概念，掌握几种设计技术和工具，了解设计规格说明和评审。 教学重点：几种设计技术和工具。 教学难点： 判定表。 教 具：多媒体教室、电子教案 作 业：

8.1.4 软件总体结构设计 软件总体结构（software architecture）应该包括两方面内容： 1) 由系统中所有过程性部件（即模块） 构成的层次结构，即程序结构； 2) 对应于程序结构的输入输出数据结构。 软件总体结构设计的目标就是产生一个模块化的程序结构并明确各模块之间的控制关系，此外还要通过定义界面，说明程序的输入输出数据流，进一步协调程序结构和数据结构。

8.1.4 软件总体结构设计 软件总体结构（software architecture）应该包括两方面内容： 1) 由系统中所有过程性部件（即模块） 构成的层次结构，即程序结构； 2) 对应于程序结构的输入输出数据结构。 软件总体结构设计的目标就是产生一个模块化的程序结构并明确各模块之间的控制关系，此外还要通过定义界面，说明程序的输入输出数据流，进一步协调程序结构和数据结构。

1. 结构演变 软件“解” S1 S4 S2 待解问题 S3 P1 P2 P4 P3 图8-1-3 结构演变

2. 同一个“问题”的多种软件解 M 问题P M M4 M1 M2 M M1 M2 M1 M2 M3 M4 M3 M4 M3 结构3 结构1 2. 同一个“问题”的多种软件解 M 问题P M M4 M1 M2 M M1 M2 M1 M2 M3 M4 M3 M4 M3 结构3 结构1 结构2 图8-1-4 对应于同一问题的各种软件结构

3. 表示程序结构的工具 类树图（tree‑like diagram） Warnier‑Orr图 Jackson图 最常见的是如图8-1-5所示的类树图。为便于讨论，下面定义几个有关的术语和度量。

M a b c 深度 d e f g h i j k m n o p q r s t 宽度 4. 有关程序结构的术语 M 扇出 a b c 深度 d e f g h i j k m n o p q r 扇入 s t 宽度 图8-1-5 有关程序结构的术语

4. 有关程序结构的术语 一个软件的深度（depth）— 控制的层数； 一个软件的宽度（width）— 其控制的层数和跨度； 一个模块的“扇出数”（fan‑out）— 该模块直接控制的其他模块数； 一个模块的“扇入数”（fan‑in）指能直接控制该模块的模块数。

4. 有关程序结构的术语 如果一个模块控制另一个模块，称前者为“主控”模块，后者为“从属”模块。在图8-1-5中模块M主控模块a、b、c，模块d从属模块a，因此也从属M。 此外，软件结构中还有两个重要的特性，即可见域和连通域。 模块的可见域——该模块可直接或间接引用 的一组模块； 模块的连通域——仅包括该模块可直接引用 的模块。

8.1.5 数据结构设计 数据结构描述各数据分量之间的逻辑关系，数据结构一经确定，数据的组织形式、访问方法、组合程度及处理策略等随之而定，所以数据结构是影响软件总体结构的重要因素。 数据结构与程序结构一样，也可以在不同的抽象级别上表示。以栈为例，作为一个抽象数据类型，在概念级上只关心“先进后出”特性，而在实现级上则要考虑物理表示及内部工作的细节，比如，用向量实现，或用链表实现等。

8.1.5 数据结构设计 数据结构对程序结构和过程复杂性有直接的影响，从而在很大程度上决定了软件的质量。 数据设计的目标是为在需求规格说明中定义的那些数据对象选择合适的逻辑表示，并确定可能作用在这些逻辑结构上的所有操作（包括选用已存在的程序包）。 数据抽象和信息隐蔽两个概念是数据设计的基础。 通常，数据设计方案不是唯一的，有时需进行算法复杂性分析、综合各种因素之后才能从多种候选方案中筛选出最佳的设计方案。

8.1.6 软件过程设计 过程设计紧跟在数据结构和程序结构设计之后，其基本任务是描述模块内各处理元素和判断元素的顺序，图8-1-6展示了模块B的内部过程。 过程说明 模块B 程序结构 模块B ┇ ┇ ┇ 图8-1-6 模块B的内部结构

8.1.6 软件过程设计 所谓过程，应包括有关处理的精确说明，诸如事件的顺序、判断的位置和条件、循环操作以及数据的组成，内部变量和外部变量的引用问题等等。 过程设计也应遵循“自上而下，逐步求精”的原则和单入口单出口的结构化设计思想。 过程设计的任务是描述算法的细节。结构化程序流程图、盒图（N-S图）、判定表和判定树，以及过程设计语言（PDL）、PAD图等是人们经常使用的工具。

8.2 软件过程设计技术和工具 8.2.1 结构化程序设计 结构化程序设计定义：是程序设计技术，它采用自顶向下逐步求精的设计方法和单入口单出口的控制构件。 结构化程序设计的思想，应该在软件设计中体现出来，但这并不排除为效率或其他原因对结构化程序设计作一点修正。随着面向对象、软件重用等新的软件开发方法和技术的发展，更现实、更有效的开发途径可能是自顶向下和自底向上两种方法有机地结合。

F 第一个任务 F T T else部分 then部分 第二个任务 循环体 8.2.2 图形表示法 1．流程图（也称为程序框图）是最常用的一种表示法， “顺序”、“分支”和“循环”三个基本控制构件用流程图表达的形式如图8-2-1所示。 F 第一个任务 F T 分支条件 循环条件 T else部分 then部分 第二个任务 循环体 顺序结构 If‑then‑else结构 do‑while循环 图8-2-1 流程图构件

第一个任务 第二个任务 第三个任务 条件 else 部分 then 部分 do-while 部分 8.2.2 图形表示法 2．盒图也称为N-S图或Chapin图。这种表达方式取消了流程线，它强迫程序员以结构化方式思考和解决问题。 第一个任务 第二个任务 第三个任务 F 条件 T 循环条件 else 部分 then 部分 do-while 部分 顺序结构 if-then-else结构 循环结构 图8-2-3 盒图的构件

8.2.3 判定表与判定树 当模块中包含复杂的条件组合，并要根据这些条件的组合选择动作时，只有判定表和判定树能够清晰地表达出复杂的条件组合与各种动作之间的对应关系。 判定表由四部分组成： 左上部——列出所有条件； 左下部——列出所有可能的动作； 右上部——所有可能的条件组合（矩阵）； 右下部——条件组合与动作之间的对应关系。 判定表的每一列可解释为一条处理规则。

8.2.3 判定表与判定树 【例8.2】问题处理描述：耗电记费系统可以采用固定价格收费、浮动价格收费和其他方式收费三种方式。若采用固定价格方式收费，对每月耗电100kW•h以下的用户只征收最低标准费，超过100kW•h的用户按价格表A收费；若采用浮动价格方式收费，则每月耗电100kW•h以下的用户按价格A收费，超过100kW•h的用户按价格B收费。

规 则 1 2 3 4 5 固定价格方式 耗电＜100kW.h T F 收取最低标准费 按价格表A收费 按价格表B收费 √ 表8‑1 判定表 规 则 1 2 3 4 5 固定价格方式 浮动价格方式 耗电＜100kW.h 耗电≥100kW.h T F 收取最低标准费 按价格表A收费 按价格表B收费 其他处理 √ 条件 动作

【例8.2】判定树 耗电＜100kW·h — 收取最低标准费 固定方式 耗电≥100kW·h — 按价格表A收费 耗电收费 浮动方式 耗电≥100kW·h — 按价格表B收费 其他方式— 其他处理 图8-2-5 用判定树表示计算耗电收费的算法

8.2.3 判定表与判定树 判定树的优点：形式简单，直观明了，易于掌握。 判定树的缺点： ①存在着数据冗余的问题，相同的数据元素往往要重复多次，而且越接近树的叶端重复的次数越多。 ②判定树要求对条件进行层次划分，若条件所处层次不对，可能会导致增加判定树的复杂性。

8.2.4 过程设计语言（PDL） PDL（Procedure Design Language）也称为结构英语或伪码，是所有正文形式的过程设计工具的统称。 PDL经常表现为一种“混杂”的形式，允许自然语言（如英语）的词汇与某种结构化程序设计语言（如Pascal、C、Ada等）的语法结构交织在一起

8.2.4 过程设计语言（PDL） PDL应具有下述特点： 1．关键字采用固定语法并支持结构化构件、数据说明机制和模块化； 2．处理部分采用自然语言描述； 3．允许说明简单（标量、数组等）和复杂（链表、树等）的数据结构； 4．子程序的定义与调用规则不受具体接口方式的影响。

8.2.4 过程设计语言（PDL） 考察一个PDL的原型，它可以建立在任意一个通用的结构化程序设计语言之上。基本成分包括：子程序定义、界面描述、数据说明、块结构、分支结构、循环结构和I/O结构。 数据说明的形式为： TYPE <变量名> IS <限定词1> <限定词2> 其中： < 变量名 >——局部变量或全局变量； <限定词1>——某个特定关键字（例如，SCALAR，ARRAY，LIST，STRING，STRUTURE等）； <限定词2>——说明此处定义的变量在该过程或整个程序中应如何使用。

8.2.4 过程设计语言（PDL） 可进行抽象数据类型的定义，例如 : TYPE table_1 IS INSTACE OF symbol_table 而symbol_table在另一处已定义如下： TYPE symbol_table IS STRUCTURE DEFINED

8.2.4 过程设计语言（PDL） 该PDL的块结构描述一个过程元素，即一个块内的所有语句将作为一个整体执行，形式为 BEGIN [<块名>] <语句序列> END 该PDL的分支结构有if-then-else和case两种形式，分别为 IF <条件描述> THEN <块结构或语句> ELSE <块结构或语句> ENDIF

8.2.4 过程设计语言（PDL） CASE OF <情况变量名> WHEN <第1种情况> SELECT <块结构或语句> WHEN <第2种情况> SELECT <块结构或语句> … WHEN <最后一种情况> SELECT <块结构或语句> DEFAULT:<块结构或语句> ENDCASE

8.2.4 过程设计语言（PDL） 循环结构包括三类，表达形式分别为 ： DO WHILE <条件描述> <块结构或语句> ENDWHILE REPEAT UNTIL <条件描述> ENDREPEAT DOFOR <循变> = <循变取值范围,表达式或序列> ENDFOR

8.2.4 过程设计语言（PDL） 此PDL还提供了NEXT和EXIT两种语句： EXIT语句，退出本层循环； PROCEDURE <子程序说明> <属性表> INTERFACE <参数表> <块结构或语句序列> END 其中属性表指明该子程序的引用特性（比如，是INTERNAL还是EXTERNAL模式）和其他依赖于实现（即程序设计语言）的特性。

8.2.4 过程设计语言（PDL） 输入/输出说明部分常用的形式有 READ/WRITE TO <设备> <I/O表> 或 ASK <询问> ANSWER <响应选择项> 后一种形式多用于人机交互部分的设计。

8.3 设计规格说明与评审 软件设计阶段的输出主要是设计规格说明书： 第一节：描述与设计活动有关的各个方面，该节中许多信息取自系统规格说明书和系统定义阶段产生的其他文档。 第二节：具体指明引用信息的出处。 第三节：设计描述，是概要设计的产物，此时设计由信息驱动，即软件总体结构主要受数据流程、数据结构的影响，需求分析时产生的DFD或其他某种形式的数据表示将在这一节中进一步精化，用于确定软件结构。当信息流程确定后，界面亦可作为整个软件的一部分进行描述。

8.3 设计规格说明与评审 第四、五两节是概要设计向详细设计过渡后形成的。 第四节：模块指软件中可单独编址的部件，如函数和过程，最初用自然语言描述它们的功能，随后采用某种过程设计工具将这些自然语言描述转换为结构化描述。 第五节：主要描述数据组织结构，包括辅存的文件结构、全局数据（例如FORTRAN公共区）的赋值以及这些文件与全局数据的交叉访问关系。

8.3 设计规格说明与评审 第六节：是与需求规格说明书的交叉访问表，根据交叉访问表可断定设计是否满足所有需求，这对于完成某个具体需求的模块来说十分重要。 第七节：是测试的初步计划。一旦软件结构和模块间界面确定下来之后，即可制定模块单元测试和联调的计划。某些场合，要求同时开发测试规格说明书与设计规格说明书，此时第七节可从设计规格说明书中删去。 第八节：将逐条说明各种限制和造成的影响。 第九、十两节：包括若干辅助数据，如从其他文档中节选的算法描述、候选的过程、表格化数据和其他相关信息，这些信息是对设计的一种特殊注释 最后开发一基本操作规格说明或安装手册作为附录。

设计规格说明书示例 Ⅰ.作用范围 A. 系统目标 B. 硬件、软件和人机界面 C. 主要的系统功能 D. 外部数据库定义 E. 主要的设计约束和限制 Ⅱ.文档 A. 现有的软件文档 B. 系统文档 C. 卖主（硬件的和软件的）的有关文档 D. 技术参考书

设计规格说明书示例 Ⅲ.设计描述 A.数据描述 1.数据流复审 2.数据结构复审 B. 导出的程序结构 C. 结构之间的界面

设计规格说明书示例 Ⅳ. 模块描述；针对每个模块给出 A. 处理过程陈述 B. 接口描述 C. 设计语言（或其他形式）描述 D. 引用的模块 E. 数据组织 F. 注释

设计规格说明书示例 Ⅴ.文件结构及全局数据 A. 外部文件结构 1.逻辑结构 2.逻辑记录描述 3.访问方式 B. 全局数据 C. 文件与数据的交叉访问表 Ⅵ.需求交叉访问矩阵

设计规格说明书示例 Ⅶ. 测试准备 A. 测试指南 B. 集成策略 C. 特殊考虑 Ⅷ. 装配 A. 特殊的程序覆盖要求 B. 转换方面的考虑 Ⅸ. 特别注释 Ⅹ. 附录

设计规格说明的评审 为了确保文档的质量，还必须对设计文档进行评审。评审的目的在于及早发现设计中的缺陷和错误。 评审包括软件总体结构、数据结构、结构之间的界面以及模块过程细节四个方面，重点考虑：软件结构能否满足需求？结构的形态是否合理？层次是否清晰？模块的划分是否遵循模块化和信息隐蔽的思想？系统的人机界面、各模块的接口以及出错处理是否恰当？模块的设计能否满足功能与性能要求？选择的算法与数据结构是否合理，能否适应编程语言，等等。

设计规格说明的评审 评审分正式与非正式的两种方式。 正式评审除软件开发人员外，还邀请用户代表和领域专家参加，通常采用答辩形式，与会者有备而来（即提前审阅了文档），设计人员在对设计方案详细说明后，答复与会者的问题并记下各种重要的评审意见。 非正式评审多少有些同行切磋的性质，不拘时间，不拘形式。 需求阶段使用的“走查”法同样适用于设计评审，此时由一名设计人员带领到会的同事逐行审阅文档，记录发现的问题。 评审应对事不对人，防止把评审变为质询或辩论。最后，对评审中提出的问题应详细记录。评审结束前，还应对本次评审做出结论。 返回目录