概述

介绍如下内容:

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

基本任务

总体设计,也称为概要设计或初步设计。

这时是站在全局高度研究软件产品该如何实现,所以具体的程序、算法、数据库等并不是重点。

归纳出来,总体设计主要的工作有两个:

  • 制定实现方案(根据数据流图,制定多个方案供选)
  • 是划分整个目标系统的结构(划分功能模块,顶层和底层)

附属工作有两个:

  • 是实现数据库(根据ER图和数据字典实现)
  • 是制定测试计划(编码后就可以根据这个直接开始测试)

总体设计的必要性:总体设计可以站在全局的高度上,以较小的成本,从抽象层次上分析对比多种可能的实现方案和软件结构并选出合理的方案以降低软件开发成本。

设想供选择的方案

系统分析员考虑各种可能的实现方案。

常用的方法是设想出处理数据流图中各个分组的各种可能的方法,抛弃无法实现的方法,余下的就是可供选择的实现方案。

选取合理的方案

当得到了多个能够实现的合理方案之后,通常至少选取低成本、中成本、高成本三个。对每个方案都要给出系统的一些基本资料(流程图、成本、进度计划等)。

功能分解

为了最终的目标实现,必须设计出程序、文件(或数据库)。

程序的设计分两个阶段:结构设计和过程设计

  • 结构设计:确定程序由哪些模块组成,以及模块间的关系;
  • 过程设计:确定每个模块的处理过程

结构设计,就是总体设计的另一个主要任务(之前一个是制定方案)
过程设计,就是生命周期下一阶段,详细设计的任务

为了设计软件结构,系统分析员必须从实现角度把复杂的功能进行分解。

分析员结合算法描述,仔细分析数据流图中的每个处理,如果一个处理过于复杂,则将它分解成多个简单的处理,这个分解要求程序员可以轻松地理解。

功能分解导致了数据流图的进一步细化,也应同步更新IPO图状态转换图等描述需求的模型。

设计软件结构

将功能模块分成良好的层次结构,顶层功能模块调用下层模块
下层再调用更下层的模块,最底层模块完成最具体的功能。

抽象与逐步求精

作为蓝星人类最强的思维工具之一的“抽象”在设计软件结构的时候也相当有用。

米勒法则:一个人在任何时候都只能把注意力集中在(7±2)个知识块上。

如果每次面临的因素太多,就丌可能做出精确思维,所以只能从抽象到具体的分析过程。逐步求精和模块化的概念,不抽象是紧密相关的。在总体设计阶段采用自顶向下、逐步求精的方法,也就是从抽象到具体的过程。

软件结构顶层的模块控制了系统的主要功能并且影响全局;在软件结构底层的模块完成对数据的一个具体处理。

逐步求精方法的强大作用就在于,它能帮助软件工程师,把精力集中在不当前开发阶段最相关的那些方面上,而忽略那些对整体解决方案来说虽然是必要的,然而目前还丌需要考虑的细节,这些细节将留到以后再考虑。

抽象不求精是一对互补的概念。抽象使设计者能够抽出事物的本质特性而暂时丌考虑它们的细节(上层)。求精帮助设计者在设计过程中逐步揭示低层细节(下层)。

模块独立性

耦合

耦合是对一个软件结构内各个模块之间互连程度的度量。耦合强弱取决于模块间接口的复杂程度,调用模块的方式,以及通过接口的信息。

原则:尽量使用数据耦合,少用控制耦合,限制公共耦合,完全不用内容耦合。

  • 数据耦合:一个模块访问另一个模块时,彼此之间是通过简单数据参数 (不是控制参数、公共数据结构或外部变量)来交换输入、输出信息。
  • 特征耦合/标记耦合:两个模块都与同一个数据结构有关系。
  • 控制耦合:传递控制变量,当一个模块调用另一个模块时。被调用的模块通过该控制变量的值有选择地执行模块内某一功能。
  • 公共耦合:指通过一个公共数据环境相互作用的那些模块间的耦合。
  • 内容耦合:当一个模块直接另一模块的内部数据,或通过非正常入口而转入另一个模块内部,这种模块间的耦合为内容耦合,这种情况往往出现在汇编程序设计中。

内聚

内聚标志一个模块内各个元素彼此结合的紧密程度,它是信息隐蔽和局部化概念的自然扩展。简单地说,理想内聚的模块只做一件事情。

低内聚

  • 偶然耦合:模块内各部分之间没有联系,或即使有联系,也很松散,是内聚程序最低的模块。
  • 逻辑内聚:若干个逻辑相似的功能放在同一个模块里。
  • 时间内聚:又称为经典内聚,大多为多功能模块,模块的各个功能的执行与时间有关,如初始化模块和终止模块。

中内聚

  • 过程内聚:把流程图中某一部分划出组成模块,即过程内聚,如循环部分、判定部分、计算部分分成三个模块。
  • 通信内聚:模块内各功能部分使用了相同的输入数据或产生相同的输出数据。

高内聚

  • 顺序内聚:模块内处理元素和同一个功能密切相关,且这些处理元素必须顺序执行。
  • 功能内聚(最强):模块内所有的元素共同完成一个功能缺一不可。

软件结构的启发式规则

  1. 改进软件结构提高模块独立性。提高模块的独立性,就是力求达到低耦合高内聚。
  2. 模块的规模应该适中,一个模块最好在一页纸内,尽量不超过60条命令。
  3. 深度、宽度、扇出、扇入都应适当。
    • 深度:表示软件结构的层次,不宜过多,也不要太少。
    • 宽度:同一层的模块总数,宽度越大(功能越多)系统越复杂。
    • 扇出:是该模块控制的所有下层模块。
    • 扇入,是该模块被其他模块调用的次数。
  4. 力争降低模块接口的复杂程序。
  5. 设计单入口单出口的模块,模块从上到下执行,单入口单出口,容易理解,容易测试,容易维护。
  6. 模块的功能应该能预测,单入口带入数据,通过模块的功能,应该能预测输出结果。

面向数据流的设计方法

通常说的结构化设计方法(Structure Design方法,简称SD方法)就是基于数据流的设计方法。面向数据流的设计,就是根据数据流设计出软件结构。

数据流的类型有两种,变换流和事务流。

  • 变换流:数据进入软件系统,经过处理后离开系统,这就是变换流。
  • 事务流:在数据进入系统之后,要先判断数据进行哪一种处理从多种处理方式中选择一种进行。就是更复杂的变换流是,数据流的先一步分析之后再处理。

设计数据库

根据ER图和数据字典,遵循数据规范化的原则。

制定测试计划

这里的测试计划,主要是针对代码和功能的文档的测试,其实从软件生命周期的开始就已经在进行了。

书写文档

系统说明书

包括如下内容:

  • 系统流程图描绘的系统构成方案
  • 组成系统的物理元素清单
  • 成本/效益分析
  • 对最佳方案的概括描述
  • 简化的数据流图
  • 用层次图或结构图描绘的软件结构
  • 用IPO与或其他工具(如PDL语言)简要描述的各个模块的算法
  • 模块间的接口关系
  • 需求、功能和模块三者之间的交叉参照关系等

用户手册

根据总体设计阶段的结构,修改和正常在需求分析阶段产生的初步的用户手册。

测试计划

包含如下内容:

  • 测试策略
  • 测试方案
  • 预期的测试结果
  • 测试进度计划等

详细的事先计划

数据库设计结果

审查和复审

对总体设计的结果进行严格的技术审查,在技术审查通过再由使用部门的负责人从管理角度进行复审。