总体设计.

Presentation on theme: "总体设计."— Presentation transcript:

1 总体设计

2 什么是设计 把问题转化为解决方案的创造性过程；解决方案的描述也成为设计。 How to do?

3 设计和需求的不同 张军和李丽想做一栋房子，它们的需求如下： 三个小孩有玩耍的空间并各自有独立的睡房； 一间主人的睡房； 一个厨房；
冬天可以取暖，夏天可制冷； 室内通水通电； 等等

4 设计和需求的不同 设计师的方案： 楼上四间睡房 楼下客房，厨房，玩具房和杂物室 采用中央空调 其他方案？

5 软件设计 软件设计的目标和任务 详细设计 总体设计 体系结构 数据设计 过程设计
软件设计是软件开发的一个重要阶段，是获取高质量、低耗费、易维护软件的一个重要环节 软件设计 体系结构 数据设计 过程设计 详细设计 定义软件系统各主要结构性元素（即组成成份）及其相互间的关系 总体设计 把结构性元素转换成软件的过程性描述。在编码步骤，根据这种过程性描述，生成源程序代码，然后通过测试最终得到完整有效的软件 数据设计 Warnier图 层次方框图 数据字典 过程设计 逐步逐步做 侧重于实现软件所需的数据结构的定义

6 总体设计 设计过程 设计原理 启发规则 描绘软件结构的图形工具 面向数据流的设计方法

7 设计过程 设想供选择的方案 选取合理的方案 推荐最佳方案 功能分解 设计软件结构 设计数据库 制定测试计划 书写文档 审查和复审

8 总体设计 设计过程 设计原理 启发规则 描绘软件结构的图形工具 面向数据流的设计方法

9 软件设计应遵守的原则 抽象 逐步求精 模块化 信息隐蔽 模块独立

10 抽象 抽象是人们控制问题复杂性的重要手段 抽象是指忽视一个主题中与当前目标无关的那些方面，以便更充分地注意与当前目标有关的方面
软件设计中的主要抽象手段有：过程抽象和数据抽象

11 过程抽象 也称功能抽象，任何一个完成明确定义功能的操作都可被使用者当作单个实体看待，尽管这个操作实际上可能由一系列更低级的操作来完成 数据抽象 定义数据类型和施加于该类型对象的操作，并限定了对象的取值范围，只能通过这些操作修改和观察

12 软件工程过程的每一步都是对较高一级抽象的解作一次具体化的描述
系统定义阶段把整个软件系统抽象成计算机系统的一个组成部分 需求分析阶段是对问题域的抽象，使用问题域中的术语 经过概要设计、详细设计，抽象级别一次一次降低，到编码完成后，到达最低级别的抽象

13 例: 开发一个CAD软件的三层抽象 抽象层次I 抽象层次II 抽象层次III
问题域的抽象，即用问题所处环境的术语来描述这个软件: 软件包括一个计算机绘图界面，向绘图员显示图形，以及一个数字化仪界面，用以代替绘图板和丁字尺。所有直线、折线、矩形、圆及曲线的描画、所有的几何计算、所有的剖面图和辅助视图的实现等。 抽象层次II 任务需求的描述, CAD 软件任务: 用户界面任务；创建二维图形任务；显示图形任务；管理图形文件任务； 抽象层次III 面向实现的抽象 以2-D (二维)绘图生成任务为例.

14 PROCEDURE：2-D drawing creation REPEAT UNTIL (drawing creation task terminates) DO WHILE (digitizer interaction occurs) digitizer interface task; DETERMINE drawing request CASE; line： line drawing task; rectangle：rectangle drawing task; circle： circle drawing task; ……

15 数据抽象实例 例如，在CAD软件中，定义一个叫做drawing的数据对象。可将drawing规定为一个抽象数据类型，定义它的内部细节为:

16 TYPE drawing IS STRUCTURE number IS STRING LENGTH(12); geometry DEFIND …… notes IS STRING LENGTH(256); bom DEFIND END drawing TYPE; 数据抽象drawing本身由另外一些数据抽象，如geometry、bom (bill of materials) 构成 定义drawing的抽象数据类型之后，可引用它来定义其它数据对象，而不必涉及drawing的内部细节 例如，定义: blue-print IS INSTANCE OF drawing; 或 schematic IS INSTANCE OF drawing;

17 逐步求精 逐步求精是与抽象密切相关的概念，它是一种自顶向下的设计策略
其主要思想是：针对某个功能的宏观描述，用逐步求精的方法自顶向下不断分解，逐步确立过程的细节，直至该功能能用程序语言描述的算法为止 每求精一步，抽象级别就降低一个层次，上一层是下一层的抽象，下一层是上一层的求精

18 模块化 软件系统的模块化是指整个软件被划分成若干单独命名和可编址的部分，称之为模块。这些模块可以被组装起来以满足整个问题的需求。
把问题／子问题的分解与软件开发中的系统／子系统或系统／模块对应起来，就能够把一个大而复杂的软件系统划分成易于理解的比较单纯的模块结构。

19 模块与成本的关系： 假设：C( x )表示问题x的复杂程度 E( x )表示求解问题x所需的工作量 显然，对二个问题P1和P2
若C( P1 ) > C( P2 )，则E( P1 ) > E( P2 ) 在人们求解问题的过程中，发现以下性质： C( P1 + P2 ) > C( P1 ) + C( P2 ) E( P1 + P2 ) > E( P1 ) + E( P2 ) 此结论导致“分而治之”的方法，即把一个复杂问题分解成若干个小问题，更容易求解

20 模块数量的增多，使得每个模块的成本减少，但增加了模块之间通信的代价
模块与成本之间的关系曲线 模块数最好在最少成本区

21 信息隐蔽 由 parnas 方法提倡的信息隐蔽是指，每个模块的实现细节对于其它模块来说是隐蔽的（不可访问）。也就是说，模块中所包含的信息（包括数据和过程）不允许其它不需要这些信息的模块使用。 设计时可以把一些可能发生变化的因素隐蔽在某个模块中，以提高可维护性 信息隐蔽可减少错误向外传播

22 模块独立 模块（Module） “模块”，又称“组件”。它一般具有如下三个基本属性: 功能：描述该模块实现什么功能 逻辑：描述模块内部怎么做
状态：该模块使用时的环境和条件

23 在描述一个模块时，还必须按模块的外部特征与内部特征分别描述 模块的外部特征
模块的模块名、输入/输出参数，即模块需要的信息和产生的信息 模块的功能 模块的内部特征 完成其功能的程序代码（反映实现算法） 仅供该模块内部使用的数据（局部数据）

24 模块独立性 模块独立性, 是指软件系统中每个模块完成相对独立的子功能, 并且与软件系统中其它模块的接口是简单的
例如, 若一个模块只具有单一的功能且与其它模块没有太多的联系, 则称此模块具有模块独立性 一般采用两个准则度量模块独立性。即模块间耦合和模块内聚

25 耦合（coupling）是模块间相对独立性的度量，即模块间互相连接的紧密程度的度量。
内聚（cohesion）是模块相对功能性的度量，即一个模块内部各个元素彼此结合的紧密程度的度量。 模块独立性比较强的模块应是高内聚低耦合的模块。

26 模块间的耦合

27 非直接耦合(Nondirect Coupling)
两个模块之间没有直接关系，它们的任一个都不依赖于另一个而能独立工作。如图中 的F和C等非直 接耦合的模块 独立性最强。

28 数据耦合 (Data Coupling) 两个模块之间仅通过参数表传递简单数据 标记耦合 (Stamp Coupling) 两个模块之间通过参数表传递一个数据结构的一部分（如某一数据结构的子结构）

29 控制耦合 (Control Coupling) 如果一个模
块传送给另一 模块的参数中 包含了控制信 息（如开关、 标志等），该 控制信息用于 控制接收模块 中的执行逻辑， 则称控制耦合

30 外部耦合（External Coupling） 当模块间通过软件之外的环境联结（如I/O将模块耦合到特定的设备、格式、通信协议上）时，则称之为外部耦合。 公共耦合（Common Coupling） 若一组模块都访问同一个公共的全局数据区域，则它们之间的耦合就称为公共耦合。公共的数据区域可以是全局数据结构、共享的通信区等。

31 公共耦合的复杂程度随耦合模块的个数增加而显著增加。若只是两模块间有公共数据区域，则公共耦合有两种情况。松散公共耦合和紧密公共耦合。

32 内容耦合 (Content Coupling) 如果发生下列情形，两个模块之间就发生了内容耦合 (1) 一个模块直接访问另一个模块的内部数据; (2) 一个模块不通过正常入口转到另一模块内部; (3) 两个模块有一部分程序代码重迭(只可能出现在汇编语言中); (4) 一个模块有多个入口。

33 模块内聚 c

34 功能内聚 (Functional Cohesion) 一个模块中的所有部分都是为了完成一项具体功能而协同工作，紧密联系，不可分割的，则称该模块为功能内聚模块。 顺序内聚 (Sequential Cohesion) 当模块的处理元素相关，并必须顺序执行时，称为顺序内聚

35 通信内聚 (Communication Cohesion) 如果一个模块内所有处理元素集中在某个数据结构的一块区域上，则称之为通信内聚模块。 过程内聚 （Procedural Cohesion） 当模块的处理元素相关，并必须按指定的次序执行时，称为过程内聚

36 时间内聚（Temporal Cohesion） 当一个模块中的所有任务必须在相同的时间跨度里执行时，称为时间内聚。例如初始化模块和终止模块。

37 逻辑内聚（Logical Cohesion）
完成一组逻辑 相关的任务的 模块（如产生 所有类型的输 出的模块）称 为逻辑内聚

38 巧合内聚（Coincidental Cohesion） 巧合内聚 (偶然内聚)：完成一组相互松散相关的任务的模块称为巧合内聚模块，它是内聚程 度最低的模块。

39 总体设计 设计过程 设计原理 启发规则 描绘软件结构的图形工具 面向数据流的设计方法

40 启发规则 提高软件结构，提高模块的独立性 模块规模适中 深度、宽度、扇出和扇入都应当适当 模块分解和合并—降低耦合、提高内聚
模块规模不应太大(一般不超过60行) 模块规模不应太小（通讯开销大、应合并至上级模块） 深度、宽度、扇出和扇入都应当适当

41 程序结构 控制域：一个模块自身以及它可直接或间接调用的所有模块组成该模块的控制域 深度：程序结构中控制的层数
程序结构表明了程序各个部件(模块)的组织情况，通常用类似于树的图表示 控制域：一个模块自身以及它可直接或间接调用的所有模块组成该模块的控制域 扇入：能直接调用（控制）该模块的模块数 扇出：一个模块直接调用（控制）的模块数目 深度：程序结构中控制的层数 宽度：程序结构中同一层次上模块总数的最大值

42 程序结构的宽度和深度要适中，层数过多可能存在许多管理性的模块，可以合并；宽度过大说明系统较复杂
扇出过大表示模块复杂，扇出太小（如扇出为1）也不一定就好，一般以3-9为宜 扇出大时可考虑增加中间层，扇出小时可考虑将下层合并到上层 扇入大表示模块的共享性好，扇入越大越好 较好的程序结构应是顶层扇出较大，中间层扇出较小，底层扇入大

43 启发规则 模块的作用域应该在控制域之内 力争降低模块接口的复杂程度 设计单入口单出口的模块 模块功能应可以预测
作用域：受该模块内一个判定影响的所有模块集合 力争降低模块接口的复杂程度 QUAD_ROOT(TBL,X) QUAD_ROOT(A,B,CROOT1,ROOT2) 设计单入口单出口的模块 模块功能应可以预测

44 总体设计 设计过程 设计原理 启发规则 描绘软件结构的图形工具 面向数据流的设计方法

45 软件体系结构设计的图形工具 层次图和HIPO图

46 结构图（Structure Chart） 结构图反映程序中模块之间的层次调用关系和联系：它以特定的符号表示模块、模块间的调用关系和模块间信息的传递

47 ① 模块：模块用矩形框表示，并用模块的名字标记它

48 ② 模块的调用关系：模块之间用单向箭头（或直线）联结，箭头从调用模块指向被调用模块。

49 ③(接口)模块间的信息传递：当一个模块调用另一个模块时，调用模块把数据或控制信息传送给被调用模块，以使被调用模块能够运行。而被调用模块在执行过程中又把它产生的数据或控制信息回送给调用模块

50 ④ 结构图中可附加记号，菱形符号表示有条件地调用，环形箭头表示重复调用。如下图中：模块A有条件地调用模块B；模块A反复调用模块C和模块D。

51 实例：某火车售票查询子系统 数据流程图如下所示： 录入员 旅客 3 按日期查询 查询结果 日期 查询 信息 查询 信息 查询 结果 查询
1 接受查询 2 分析查询 4 按班次查询 6 查询显示 录入员 班次 5 按线路查询 线路 查询结果 旅客

52 程序结构图 查询信息 接受查询 查询显示 按日期查询 按班次查询 按线路查询 输入信息 列车查询主模块 分析查询 查询结果 查询结果

53 总体设计 设计过程 设计原理 启发规则 描绘软件结构的图形工具 面向数据流的设计方法

54 面向数据流的设计方法 结构化设计方法 （Structured Design简称SD）
SA、SD、SP组成结构化方法，相互衔接 结构化设计方法是一种典型的面向数据流的设计方法 信息流可分为两类： 变换流（transform） 事务流（transaction）

55 变换流 变换流型的DFD图可明显地分成输入、变换、输出三部分
信息沿着输入通路进入系统，并将外部形式转换成内部形式，进入系统的信息通过变换中心的处理，再沿着输出通路转换成外部形式后离开系统，具有这种特征的信息流称为变换流

56 事务流 接收事务（输入数据） 分析每个事务以确定它的类型 根据事务类型选取一条动作通路
数据流沿着输入通路到达一个事务中心，事务中心根据输入数据的类型在若干条动作通路（action path）中选出一条来执行，具有这种特征的信息流称为事务流 事务中心的任务是： 接收事务（输入数据） 分析每个事务以确定它的类型 根据事务类型选取一条动作通路

57

58 面向数据流 的设计过程

59 变换分析 复审基本系统模型（顶层图），以确保系统的I/O数据流符合规格说明要求 复审和精化DFD图 确定DFD图的类型（变换流/事务流）
划定输入流和输出流的边界，孤立出变换中心 将DFD图映射成变换型的程序结构 把DFD图中的每个加工映射成程序结构中的一个适当的模块 采用启发式设计策略，精化所得到的程序结构，改良软件质量

60 第四步：划定输入流和输出流的边界，孤立出变换中心 概念
物理输入：系统输入端的数据流 物理输出：系统输处端的数据流 逻辑输入：变换中心的输入数据流 逻辑输出：变换中心的输出数据流 * 物理输入要经过编辑、格式转换、合法性检查等辅助性加工后变成纯粹的逻辑输入再传给变换中心；变换中心产生的逻辑输出要经过格式转换、组成物理块、缓冲处理等辅助性加工后变成物理输出，再送到系统外。

61 确定逻辑输入： 从物理输入端开始，一步步向系统的中间移动，可找到离物理输入端最远的，但仍可被看作系统输入的那个数据流，就是逻辑输入 确定逻辑输出： 从物理输出端开始，一步步向系统的中间移动，可找到离物理输出端最远的，但仍可被看作系统输出的那个数据流，就是逻辑输出 确定变换中心： 确定了所有的逻辑输入/输出后，位于逻辑输入和逻辑输出之间的部分就是变换中心 这种划分可能因人而异，并不唯一，但差别不会很大，对最后的软件结构影响也不大 例：传感器监测子系统的流边界

62

63 第五步：将DFD图映射成变换型的程序结构 主控模块：完成整个系统的功能 输入流控制模块：接收所有输入数据
变换流控制模块：对内部形式的数据进行加工处理，实现输入到输出的变换 输出流控制模块：产生所有输出数据 输出流 控制模块 变换流 输入流 主控模块

64 对大型系统可以将上述的一个模块画成多个模块（如每个输入/输出通路画一个模块）
例：传感器监测子系统所映射的结构图如下 警报输出 控制模块 警报条件 传感数据输 入控制模块 传感器 监测执行 对大型系统可以将上述的一个模块画成多个模块（如每个输入/输出通路画一个模块） 分解的原则是在完成控制功能，并保持低耦合高内聚的前提下，尽量减少模块数

65 第六步：把DFD图中的每个加工映射成程序结构中的一个适当的模块
输入流控制模块的分解： 从变换中心的边界开始，沿着输入通路向外移动，把输入通路上的每个加工映射成程序结构中输入流控制模块的一个低层模快 输出流控制模块的分解： 从变换中心的边界开始，沿着输出通路向外移动，把输出通路上的每个加工映射成软件结构中输出流控制模块的一个低层模快 变换流控制模块的分解： 把变换中心的每个加工映射成受变换控制模块控制的一个低层模块

66 例：传感器监测子系统的分解结果如下图 警报输出 控制模块 警报条件 传感器 监测执行 传感数据输 入控制模块 获取 响应信息 读 传感数据
建立 选择 电话号码 格式化 显示 生成 产生 警报信息 连通 电话网 拨号脉冲

67 说明每个模块，内容包括： 模块的接口描述 模块的局部信息（局部数据结构） 处理过程陈述，包括判断点和任务 约束和限制条件

68 第七步：采用启发式设计策略，精化所得到的程序结构 对“传感器监测子系统”的程序结构的优化：
因只存在唯一一条输入路径，故“传感数据输入控制模块”可删除 将“选择电话号码”并入“建立警报条件”，删除“警报条件控制模块” 将“格式化显示”和“生成显示”合并成“产生显示”

69 例：传感器监测子系统的精化结果如下图 传感器 监测执行 警报输出 控制模块 建立 警报条件 获取 响应信息 读 传感数据 产生 警报信息
显示 连通 电话网 拨号脉冲

70 事务分析 复审基本系统模型（顶层图），以确保系统的I/O数据流符合规格说明要求 复审和精化DFD图 确定DFD图的类型（变换流/事务流）
指出事务中心，确定事务中心发出的每一动作通路的数据流特性（变换流/事务流） 将DFD图映射成事务型的程序结构 分解事务结构，并分解每条动作通路所对应的结构 采用启发式设计策略，精化所得到的程序结构，改良软件质量

71 第四步：指出事务中心，确定事务中心发出的每一动作通路的数据流特性（变换流/事务流）
确定事务中心： 事务中心位于数条动作通路的起点，这些动作通路呈辐射状从该点流出 确定每条动作通路的流特性： 每条动作通路或是变换流，或是事务流（判断方法同前）

72 例：用户交互子系统

73 第五步：将DFD图映射成事务型的程序结构
发送模块 接收模块 顶层 控制模块 动作通路2 动作通路1 动作通路n …

74 顶层控制模块：完成整个系统的功能 接收模块：接收输入数据 发送模块：根据输入事务类型，选择一个动作通路控制模块 动作通路控制模块：完成相应的动作通路所执行的（子）功能

75 例：用户交互子系统映射的程序结构图如下 启动 命令处理 读 用户命令 用户交互 执行 启动/停止 系统 系统配置 控制模块 口令处理

76 第六步：分解事务结构，并分解每条动作通路所对应的结构
接收模块的分解： 类同变换分析中输入流控制模块的分解 动作通路控制模块的分解 把每条动作通路映射成与其流特性相对应的结构

77 例：用户交互子系统分解后的结构图如下

78 设计的后处理 陈述每个模块的处理过程 描述每个模块的接口 根据数据字典定义数据结构指出所有的设计约束和限制 进行概要设计的评审
进行设计的优化(如果需要和可能的话)

79 设计优化原则 既满足功能和性能的要求，又符合一般的设计原则和启发式规则 软件结构的修改越早越好 可并行开发若干个软件结构，从中选择最佳设计
程序结构应该简洁，以利于调试和维护 在不违反模块化原则的前提下，应使用尽可能少的模块 只要满足信息要求，尽量使用简单的数据结构

80 对时间复杂性有特殊要求的应用，通常存在20%规则：20%的代码占用80%的处理时间，80%的错误出自20%的代码，可采用下列对策：
在先不考虑时间复杂性的情况下，设计并精化软件结构 使用CASE工具模拟分析运行时的性能，定位出低效的部分 详细设计时对最耗时的模块仔细推敲，以减少时间开销 用高级语言编程 对大量占用CPU资源的模块，必要时用低级语言重编，以提高效率

81 合理的方案 系统流程图 组成系统的物理元素清单 成本效益分析 实现这个系统的进度计划

82 总体设计阶段的文档 系统说明（概要设计说明书） 用户手册 测试计划 详细地实现计划 数据库设计结果（数据库设计说明书）