结构化程序设计的基本结构包括 顺序结构、选择结构、循环结构 三种。

详细设计层

详细设计概览

详细设计的任务：定义每一模块
三种控制结构：顺序、选择、循环

伪码

伪码是一种混合语言。外 部采用形式语言定义控制 结构和数据结构，内部使 用自然语言。

顺序
begin s1;s2; ….sn end;
选择
if 条件表达式 then  s1
else       s2;
循环
while 条件表达式 do s;

优点：

PDL不仅可以作为设计工具，而且可作为注释工具，直接插在源程序中间，以保持文档和程序的一致性，提高了文档的质量.

缺点

1. 不如图形工具那样形象直观.
2. 当描述复杂的条件组合与动作间的对应关系时，不如 判定表和判定树那样清晰简单加粗样式.

程序流程图

优点

对控制流程的描绘很直观，便于初学者掌握.

缺点

1.不是一种逐步求精的工具，程序员过早地考虑程序的控制流程，而不是全局结构.
2. 所表达的控制流，可以不受约束随意转移。
3. 不易表示数据结构.

PAD图

优点：

1. 支持自顶向下、逐步求精的结构化详细设计，可使 用 "def"符号逐步增加细节.
2. PAD 图最左边的竖线是程序的主线，随着程序层次的增加，逐步向右延伸，每增加一个层次，图形向右扩展一条竖线，从而使PAD图所表现的处理逻辑易读、易懂和易记。

N-S图

优点

支持自顶向下逐步求精的结构化详细设计，并且严格限制了控制从一个处理到另一个处理的转移.

判定表

当算法中包含多重嵌套的条件选择时， 用程序流程图、盒图、PAD图、PDL 都不易清楚描述， 这时可以选择判断表来表达复杂的条件组合与应做的动作之间的对应关系.

判定表能够清晰地表示复杂的条件组合与应做的动作之间的对应关系
判定表的四个部分：
·左上部列出所有条件
·左下部是所有可能做的动作
·右上部表示各种条件组合
·右下部是和每种条件组合相对应的动作

判定表的每一列实质上是一条规则，规定了与特定的条件组合相对应的动作。

判定树

优点

形式简单，不需任何说明，易看出含义，易于掌握和使用

缺点

· 简洁性不如判定表，
·相同的数据元素往往要重复写多遍，而且越接近树的叶端重复次数越多。

例题

软件设计规约(软件设计说明书)

概念和组成

什么是软件设计规约？

软件设计规约对软件的组织或其组成部分的内部结构的描述，满足系统需求规约所指定的全部功能及性能要求。

软件设计规约的组成

软件设计规约通常有概要设计规约和详细设计规约，分别为相应设计过程的输出文档。

概要设计规约

概要设计规约指明软件的组织结构

(1)系统环境
硬件、软件接口与人机界面
外部定义的数据库
与设计有关的限定条件
(2)设计描述
数据流和主要数据结构
软件模块的结构
模块之间的接口
(3)对每个模块的描述
处理过程外部行为
界面定义
数据结构
必要的注释
(4)文件结构和全局数据
文件的逻辑结构、记录描述以及访问方式
交叉引用信息

软件概要设计是面向软件开发者的文档，主要作为软件项目管理人员、系统分析人员与设计人员之间交流的媒体。

详细设计规约

详细设计规约是对软件各组成部分内部属性的描述，它是概要设计的细化。即在概要设计规约的基础上，增加:
① 各处理过程的算法
② 算法所涉及的全部数据结构的描述，特别地，对主要数据结构往往 包括与算法实现有关的描述

软件设计规约主要作为软件设计人员与程序员之间交流的媒体。

设计规约格式

1. 引言
   1.1 编写目的
   1.2 背景说明
   1.3 术语定义
   1.4 参考资料
2. 总体设计
   2.1 需求规定
   2.2 运行环境
   2.3 处理流程
   2.4 软件结构
3. 总体设计
   2.1 需求规定
   2.2 运行环境
   2.3 处理流程
   2.4 软件结构
4. 系统出错处理
   4.1 系统输出信息的格式和含义
   4.2 出错处理方法及补救措施
5. 模块设计说明
   (1)模块的一般说明，包括名称、编号、设计者、所在文件、所在库、 调用本模块的模块名和本模块调用的其他模块名；
   (2)功能概述；
   (3)处理描述，使用伪码描述本模块的算法、计算公式及步骤；
   (4)引用格式；
   (5)返回值；
   (6)内部接口
   (7)外部接口，说明本软件同其他软件及硬件间的接口关系
   (8)用户接口，说明将向用户提供的命令和命令的语法结构，以及软件 的回答信息

模块说明表

软件设计评审

设计评审

设计评审就是对设计文档的评审。对设计 进行评审是为了尽早发现软件的欠缺，尽可能把这些缺欠 在进入下一阶段工作之前，予以纠正，从而避免后期付出 更多的代价。

设计评审方法

1. 非正式评审
2. 正式技术评审

软件设计评审的指南

1. 概要设计评审和详细设计评审应该分开进行，不允许合并为一次复审
2. 建立一个议事日程并遵循它
3. 评审设计文档，不评审设计者
4. 限制参与人数和坚持充分准备
5. 为设计文档开发一个检查表，以帮助评审人员集中在重要问题上
6. 为了提高评审的效率，所有评审的参加者应接受一定的正规的培训

评审检查表

概要设计评审检查表:

● 软件体系结构是否反映了软件需求?
● 达到高的模块化吗?模块功能独立吗?
● 模块与外部系统元素接口定义了吗?
● 数据结构与软件需求一致吗?
● 考虑了可维护性吗?
● 是否直接评价了质量因素?

详细设计评审检查表:

● 算法能完成所要求的功能吗?
● 算法逻辑正确吗?
● 接口与体系结构设计一致吗?
● 逻辑的复杂性合理吗?
● 是否规定了错误处理和反故障处理?
● 正确地定义了局部数据结构吗?
● 都使用了结构化变成构造吗?
● 设计的细节适用于实现语言吗?
● 用的是哪个操作系统或语言独立性质?
● 考虑到可维护性吗?

结构化方法总结

1. 结构化方法的世界观:
   一切系统都是由信息流构成的每一个信息流都有自己的起点-数据源有驱动信息流动的加工所谓信息处理主要表现为信息的流动.

2. 基于的基本原理/原则

1. 自顶向下功能分解
2. 数据抽象
3. 功能/过程抽象
4. 模块化

3. 结构化方法是一种系统化的软件系统建模方法
   

4. 该方法的组成
   

例题