故障处理 软件 需求_软件工程系列-结构化设计方法3

本系列文章为笔记，内容根据北京大学《软件工程》MOOC

详细设计工具

概览

• 详细设计任务：定义每一模块

——主要引入了关于三种动作控制结构的术语/符号
三种控制结构：顺序，选择和循环

• 结构化程序设计的概念：

设计具有如下结构的程序：一个程序的代码块仅仅通过顺序、选择和循环这3种基本控制结构进行连接，并且每个代码块只有一个入口和一个出口

伪码
类程序设计语言PDL

• 顺序

begin s1;s2…sn end;

• 选择

if 条件表达式 then s1 else s2;

• 循环

while 条件表达式 do s;

程序流程图

缺点：1.不是逐步求精的工具，过早的考虑程序的控制流程，而不是全局结构
2.表达的控制流，可以不受约束的随意转移
3.不易表示数据结构
问题分析模型-PAD图

优点：

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

N-S图（盒图）

判定表判定树
当算法种包含多重嵌套的条件筛选时，用程序流程图、盒图、PAD图、PDL都不易清楚描述，这时可以选择判断表来表达复杂的条件组合与应做的动作之间的对应关系
判定树是判定表的变种，也能清晰地表达复杂的条件组合与应做的动作之间的对应关系，形式简单，但简洁性不如判定表，数据元素的同一个值往往需要重复写多次，而且越接近树的叶断重复次数越多

软件设计规约

概念
软件设计规约是对软件的组织或其组成部分的内部结构的描述，满足系统需求规约所指定的全部功能及性能要求
组成：软件设计规约通常有概要设计规约和详细设计规约，分别为相应设计过程的输出文档

概要设计规约

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

还应包括有关软件测试方面的要求和说明
软件概要设计是面向软件开发者的文档，主要作为软件项目管理人员、系统分析人员与设计人员之间交流的媒体
详细设计规约
详细设计规约是对软件各组成部分内部属性的描述，它是概要设计的细化。即在概要设计规约的基础上，增加以下内容：

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

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

设计规约格式

• 引言
  • 编写目的
  • 背景说明
    • 给出待开发软件产品的名称
    • 说明本项目的提出者、开发者及用户
    • 说明该软件产品将做什么，如有必要，说明不做什么
  • 术语定义

列出本文档种所用的专门术语的定义，以及简写的原意

• 参考资料

• 总体设计
  • 需求规定

说明本软件的主要输入、输出、处理的功能及性能要求

• 运行环境

简要说明本软件运行的软硬件环境和支持环境的要求

• 处理流程

说明本软件的处理流程，尽量用图、文、表的形式

• 软件结构

在DFD图的基础上，用模块结构图来说明各层模块的划分及其相互关系，划分原则上应细到程序级，每个单元必须执行单独一个功能

• 运行设计
  • 运行模块的组合

说明对系统施加不同的外界运行控制时所引起的各种不同的运行模块的组合，说明每种运行所经历的内部模块和支持软件

• 运行控制

说明各运行控制方式、方法和具体的操作步骤

• 系统出错处理
  • 出错信息简要说明每种可能的出错或故障情况出现时，系统输出信息的格式和含义
  • 出错处理方法及补救措施

说明故障出现后可采取的措施，包括：

• 后备技术：当原始系统数据万一丢失时启用的副本的建立和启动的技术，如周期性的信息转储
• 性能降级：使用另一个效率稍低的系统或方法（如手工操作、数据的人工记录等），以求得到所需结果的某些部分
• 恢复和再启动：用建立恢复点等技术，使软件再开始运行

• 模块设计说明

以填写模块说明表的形式，对每个模块给出下述内容：

• 模块的一般说明，包括名称、编号、设计者、所在文件、所在库、调用本模块的模块名和本模块调用的其他模块名
• 功能概述
• 处理描述：使用伪码描述算法、公式及步骤
• 引用格式
• 返回值
• 内部接口，说明本软件内部各模块间的接口关系，包括：
  • 名称
  • 意义
  • 数据类型
  • 有效范围
  • I/O标志

结构化方法总结
结构化方法的世界观
结构化方法看待世界的基本观点：一切系统都是由信息流构成的（其中包括一些必要的数据变换），每一个信息流都有自己的起点-数据源，有自己的归宿-数据谭，有驱动信息流动的加工，因此所谓信息处理主要表现为信息的流动
基本原理和原则

• 基于的基本原理/原则

• 结构化方法是一种结构化的软件系统建模方法，从测试的角度看，结构化方法是一种特定的建立验证和确认所需标尺的方法学，包括结构化分析和结构化设计

组成

问题

软件设计评审

概念
设计评审，就是对设计文档的评审。
对于软件设计来说，评审与其技术设计方法本身是一样重要，评审对于研制项目的成功而言是绝对必要的。对设计进行评审是为了尽早发现软件的欠缺，尽可能把这些缺欠在进入下一阶段工作之前，予以纠正，从而避免后期付出更多的代价
方法
非正式评审/正式技术评审

指南

• 概要设计评审和详细设计评审应该分开进行，不允许合并为一次复审
  • 概要设计评审评价从需求到设计数据和体系结构的变换
  • 详细设计评审，通常叫详细设计走查，注重算法过程的正确性
• 建立一个议事日程并遵循
• 评审设计文档，不评审设计者
• 评审中提出的问题应详细记录，但不要谋求当场解决
• 限制参与人数和坚持充分准备
  • 除开发人员，必须有用户代表参加，必要时可邀请有关领域的专家到会
  • 详细设计评审一般不邀请用户和其它领域的代表
• 为设计文档开发一个检查表，以帮助评审人员集中在重要问题上
• 为了提高评审的效率，所有评审的参加者应接受一定的培训
• 评审结束前，应作出本次评审能否通过的结论

评审检查表

• 概要设计评审检查表
  • 软件体系结构是否反映了软件需求？
  • 达到高的模块化吗？模块功能独立吗？
  • 模块与外部系统元素接口定义了吗？
  • 数据结构与软件需求一致吗？
  • 考虑了可维护性吗？
  • 是否直接评价了质量因素？
• 详细设计评审检查表
  • 算法能完成所要求的功能吗？
  • 算法逻辑正确吗？
  • 接口与体系结构设计一致吗？
  • 逻辑的复杂性合理吗？
  • 是否规定了错误处理和反故障处理？
  • 正确地定义了区别数据结构吗？
  • 都使用了结构化编程构造吗？
  • 设计的细节使用后实现语言吗？
  • 用的是哪个操作系统或语言独立性质？
  • 考虑到可维护性吗？