【软件工程】第五章 结构化设计

5.1 结构化设计的概念

5.1.1 设计的定义

何谓设计：

• 一种软件开发活动，定义实现需求规约所需的软件结构

目标：

• 依据需求规约在一个抽象层上建立系统软件模型，包括软件体系结构（数据和程序结构），以及详细的处理算法。
• 给出软件解决方案，产生设计规格说明书。

结构化设计分为：

• 总体设计：确定系统的整体模块结构（即系统实现所需要的软件模块以及这些模块间的调用关系）。
• 详细设计：详细描述模块。

5.1.2 整体框架：

1. 体系结构设计（MSD）：定义软件模块及其之间的关系，从分析模型（如数据流图）导出。
2. 接口设计：

• 外部接口设计（依据分析模型中的顶层数据流图得来，包括用户界面、目标系统与其他硬件设备、软件系统的外部接口）
• 内部接口设计（指系统内部各种元素间的接口）。

3. 数据设计：根据数据字典确定软件涉及的文件系统的结构及数据库的表结构。

5.1.3 对设计方法的需求：

1. 提供可体现“原理/原则”的一组术语（符号）。
2. 给出软件模型工具。
3. 给出设计的过程指导。

5.1.4 总体设计层概述

① 引入两个术语/符号：

② 引入模块结构图（MSD）:
例：

③ 过程指导

1. 如何将DFD转化为初始的MSD
2. 如何将初始的MSD转化为最终可供详细设计使用的MSD。

总体设计分为三个阶段：

1. 第一阶段：初始设计。在对给定的数据流图进行复审和精化的基础上，将其转化为初始的模块结构图。根据穿越系统边界的数据流初步确定系统与外部的接口。
2. 第二阶段：精化设计。依据模块“高内聚低耦合”的原则，精化初始的模块结构图，并设计其中的全局数据结构和每一模块的接口。
3. 第三阶段：设计复审阶段，对前两个阶段得到的高层软件结构进行复审，必要时还可能需要对软件结构做一些精化工作。

5.2 初始模块结构图的设计

5.2.1 数据流图分类：

变换型数据流图：

• 具有较明显的输入部分和变化部分之间的界面、变化部分和输出部分之间界面的数据流图。

事务型数据流图：

• 数据到达一个加工，该加工根据输入数据的值，在其后的若干动作序列（称为一个事务）中选出一个来执行，这类数据流图称为事务型数据流图。

两类数据流图的区别：

1. 原则上所有DFD都可以看成是变换型DFD。
2. 可以在变换型数据流图的基础上，局部采用事务型数据流图。
3. 对于事务型数据流图而言，一般接收一个输入数据，分成多条路径。

5.2.2 变换设计的基本步骤

以下图为例：

【第一步】复审并精化系统模型：

• 检查数据流图是否精确。

【第二步】确定输入、变换、输出这三部分之间的边界：

• 确定系统的逻辑输入和逻辑输出。

【第三步】系统模块结构图顶层和第一层的设计：

【第四步】自顶向下逐步求精：

• 此时已经从结构化需求层次转换到了结构化解决方案层次。

5.2.3 事务设计的基本步骤

以下图为例：

【第一步】复审并精化系统模型：

• 检查数据流图是否精确。

【第二步】确定事务处理中心：

• 即多个数据流集中处理于的地方。

【第三步】系统模块结构图顶层和第一层的设计：

1. 首先为事务中心设计一个主模块
2. 然后为每一条活动路径设计一个事务处理模块
3. 对其输入部分设计一个输入模块
4. 如果一个事务数据流图的活动路径集中于一个加工，则设计一个输出模块，否则第一层不设计输出模块。

【第四步】自顶向下逐步求精

5.3 初始模块结构图精化的原则

5.3.1 精化的概念

• 基于模块化原理“高内聚，低耦合”将初始的MSD转化为最终可供详细设计使用的MSD。

5.3.2 模块和模块化

区别：

• 模块：执行一个特殊任务的一组例程和数据结构。
• 模块化：把系统分解成若干模块的过程，使得程序能够被理性的管理。

模块化的目的：

• 解决一个较为复杂的问题的工作量，大于将这个问题分而治之的工作量之和。

注：不可能无限制的划分问题来减小工作量，因为随着模块数量的增长，集成模块所需党的工作量也在增长。

5.3.3 高内聚 低耦合

耦合的定义：

• 不同模块间相互依赖程度的度量。

耦合的强度所依赖的因素：

1. 模块间的引用
2. 模块间传递的数据量
3. 模块间的施加控制量
4. 模块间接口复杂度

耦合类型（由高到低）：

1. 内容耦合：一个模块直接修改或操作另一个模块的数据。
2. 公共耦合：两个及以上的模块共引用一个全局数据项。
3. 控制耦合：一个模块向另一个模块传递控制信号。
4. 标记耦合：两个模块至少有一个通过界面传递的公共参数，包含内部数据，如数组，字符串等。
5. 数据耦合：模块间通过参数传递基本类型的数据。

所以：如果模块间必须存在耦合，尽量使用数据耦合，少用控制耦合，限制公共耦合的范围，坚决避免使用内容耦合。

内聚的定义：

• 一个模块之内各成分之间相互依赖程度的度量。

内聚类型（由低到高）：

1. 偶然内聚：一个模块之内各成分之间没有任何关系。
2. 逻辑内聚：几个逻辑上相关的功能放在同一模块中。
3. 时间内聚：一个模块完成的功能必须在同一时间内完成，而这些功能只是因为时间因素关联在一起。
4. 过程内聚：处理成分必须以特定的次序执行。
5. 通信内聚：各成分都操作在同一数据集或生成同一数据集。
6. 顺序内聚：各成分与一个功能相关，且一个成分的输出作为另一成分的输入。
7. 功能内聚：模块的所有成分对完成单一功能是最基本的，且该模块对完成这一功能而言是充分必要的。

5.4 初始化模块结构图精化的启发式规则

5.4.1 常见的启发式规则

什么叫启发式规则：

• 根据设计准则，从长期的软件开发实践中，总结出来的规则。

常见的六种启发式规则：

① 改进软件结构，提高模块独立性：

如：多个模块公用的子功能可以独立形成一个模块，供这些模块调用。

② 模块规模适中，每页60行语句：

• 模块语句>30之后，可理解性迅速下降。
• 方法：进一步分解过大的模块，将频繁调用的小模块合并到上级模块中。

③ 深度、宽度、扇入扇出适中：

• 深度：控制的层数。
• 宽度：同一层次上的模块总数的最大值。
• 扇入：表示直接调用本模块的上层模块的数量，在不违背模块独立性的条件下，越大越好。
• 扇出：一个模块直接控制（调用）的下级模块数目，越大意味着过分复杂，典型的3~4个最优，好的系统一般呈顶层扇出高，中层扇出少，底层扇入高，的“葫芦”型。

④ 模块的作用域力争在控制域之内:

• 作用域：受该模块内一个判定影响的所有模块的集合。
• 控制域：模块本身和所有直接或间接从属于它的模块的集合。
• 如果超出控制域，等同于发生了控制耦合，应尽量避免。

⑤ 降低模块接口的复杂性：

• 接口过于复杂或不一致往往会导致紧耦合和低内聚

⑥ 模块功能应该可以预测：

• 如果模块带有内部状态，而输出取决于内部状态，则称为功能不可预测。

5.4.2 总体设计案例

数字仪表板系统：

【第一步】确定逻辑输入和逻辑输出

【第二步】确定顶层模块结构图

【第三步】输入部分细化

【第四步】输出部分细化

【第五步】输入部分精化

【第六步】输出部分精化

• 将相同或类似的物理输入（“显示”模块）合并为一个模块，以减少模块间的关联。

【第七步】变换部分的精化

• 变换部分的精化没有固定的准则，对经验要求较高。

5.5 接口设计

5.5.1 接口设计的分类

三个方面：

1. 模块或软件构件间的接口设计
2. 软件与其他软硬件系统间的接口设计
3. 软件与人（用户）之间的交互设计

• 系统的接口设计（包括用户界面设计及与其他系统的接口设计）是由穿过系统边界的数据流定义的。
• 在最终的系统中，数据流将成为用户界面中的表单、报表或与其他系统进行交互的文件或通信。

5.5.2 人机交互界面

设计者需要了解到：

1. 用户界面应具有的特性？
2. 使用软件的用户是什么人？
3. 用户怎样学习与新的计算机系统进行交互？
4. 用户需要完成哪些工作？

用户界面应具备的特性：

• 可使用性：使用简单、界面一致、拥有help帮助功能、快速的系统响应和低的系统成本、容错能力等。
• 灵活性：考虑到用户的特点、能力和知识水平，应该使用户接口满足不同用户的要求，对于不同的用户使用不同的界面形式。
• 可靠性：指无故障使用的间隔时间，用户界面应当能够保证用户正确、可靠地使用系统，保证有关程序和数据的安全性。

用户类型：

1. 外行型：对计算机系统认知很少或毫无了解。
2. 初学型：对计算机有一定经验，对系统的认识不足或经验很少，需要很多界面支持。
3. 熟练型：对一个系统有很多经验，需要较少的界面支持，但不能处理意外错误。
4. 专家型：了解系统的内部构造，需要为他们提供能够修改和扩充系统能力的复杂界面。

5.5.3 设计原则

遵循的原则：

• 一致性：指界面风格一致。
• 操作步骤少
• 不要“哑播放”：指使用进度条，加载条等能够证明系统正在运行的标志。
• 提供Undo功能：指“取消”等能够撤销用户错误操作的功能。
• 减少人脑的记忆负担：指“记住密码”，“从上次的地方开始播放”等功能。
• 提高学习效率：指用户能够很容易的学会交互的方法

5.6 数据设计

• 在设计阶段必须对要存储的数据及其格式进行设计。

5.6.1 文件设计

适用于文件存储的情况：

1. 数据量较大的非结构化数据，如多媒体信息。
2. 数据量大，信息松散，如历史记录，档案文件等。
3. 非关系层次化数据。如系统配置文件
4. 对数据的存取速度要求极高。
5. 临时存放的数据。

文件设计的主要工作：

• 根据：
  使用要求、处理方式、存储的信息量、数据的活动性、所提供的设备条件等。

• 确定：
  文件类型、选择文件媒体，文件组织方式，文件记录格式，文件容量。

5.6.2 数据库设计

设计要领：

1. 数据对象的映射
2. 关系的映射

5.7 详细设计工具

5.7.1 概览

详细设计的任务：

• 引入关于三种动作控制结构的术语：顺序，选择，循环来定义每一模块。

要求：

1. 一个程序的代码块仅仅通过顺序、选择和循环三种基本控制结构进行连接。
2. 每个代码块只有一个入口和一个出口。

5.7.2 伪码（PDL）

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

优点：

1. 既可作为设计工具，也可作为注释工具，直接插在源程序中间，以保持文档和程序的一致性，提高了文档质量。

缺点：

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

5.7.3 程序流程图

优点：

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

缺点：

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

5.7.4 问题分析图（PAD）

支持逐步求精：

• s₃可逐步定义为s₄，s₅，s₆的过程。

优点：

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

5.7.5 结构化流程图（N-S）

支持逐步求精设计：

优点：

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

5.7.6 判定表和判定树

• 当算法中包含多重嵌套的条件选择时，可以选择判定表来表达复杂的条件组合与应做的动作之间的对应关系。

5.8 软件设计规约

5.8.1 概念和组成

什么是软件设计规约：

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

组成部分：

1. 概要设计规约。
2. 详细设计规约。

5.8.2 概要设计规约

作用：

• 主要作为软件项目管理人员、系统分析人员与设计人员之间交流的媒体。

主要内容：
① 系统环境

• 硬件、软件接口与人机界面
• 外部定义的数据库
• 与设计有关的限定条件

② 设计描述

• 数据流和主要数据结构
• 软件模块的结构
• 模块间的接口

③ 对每个模块的描述

• 处理过程外部行为
• 界面定义
• 数据结构
• 必要的注释

④ 文件结构和全局数据

• 文件的逻辑结构、记录描述以及访问方式
• 交叉引用信息

⑤ 软件测试方面的要求和说明

5.8.3 详细设计规约

作用：

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

主要内容：

• 各处理过程的算法
• 算法所涉及的全部数据结构的描述，对主要数据结构往往包括与算法实现有关的描述。

5.8.4 设计规约格式

（完）