软件设计师（六）结构化开发方法
结构化方法由结构化分析、结构化设计、结构化程序设计构成，它是一种面向数据流的开发方法。
| 分类 | 说明 |
|---|---|
| 结构化分析（SA） | 根据分解与抽象的原则，按照系统中数据处理的流程，用数据流图来建立系统的功能模型，从而完成需求分析工作 |
| 结构化设计（SD） | 根据模块独立性准则、软件结构优化准则将数据流图转换为软件的体系结构，用软件结构图来建立系统的物理模型，实现系统的概要设计 |
| 结构化程序设计（SPD） | 使用 3 种基本控制结构构造程序，任何程序都可以由顺序、选择和重复 3 种基本控制结构构造。 |
结构化方法总的指导思想是自顶向下、逐层分解，它的基本原则是功能的分解与抽象。
一、系统分析与设计概述
1、系统分析概述
系统分析是一种问题求解技术，它将一个系统分解成各个组成部分，目的是研究各个部分如何工作、交互，以实现其系统目标。
系统分析的目的是为项目团队提供对触发项目的问题和需求的更全面的理解，因此强调业务问题方面，而非技术或实现方面。
（1）系统分析的目的和任务
系统分析的主要任务：是对现行系统进一步详细调查，将调查中所得到的文档资料集中，对组织内部整体管理状况和信息处理过程进行分析，为系统开发提供所需的资料，并提交系统方案说明书。
系统分析侧重于从业务全过程的角度进行分析，主要内容有业务和数据的流程是否通畅、是否合理；数据、业务过程和组织管理之间的关系；原系统管理模式改革和新系统管理方法的实现是否具有可行性等。
系统分析报告，即系统方案说明书。
（2）系统分析的主要步骤
- 认识、理解当前的现实环境，获得当前系统的“物理模型”
- 从当前系统的“物理模型”抽象出当前系统的“逻辑模型”。
- 对当前系统的“逻辑模型”进行分析和优化，建立目标系统的“逻辑模型”
- 对目标系统的逻辑模型具体化(物理化)，建立目标系统的物理模型。
2、系统设计的基本原理
（1）抽象
抽象是一种设计技术，重点说明一个实体的本质方面，而忽略或者掩盖不太重要或非本质的方面。
抽象的最底层就是实现该软件的源程序代码
（2）模块化
模块在程序中是数据说明、可执行语句等程序对象的集合，或者是单独命名和编址的元素。
模块是可组合、分解和更换的单元。
模块化：是指将一个待开发的软件分解成若干个小的简单部分一一模块，每个模块可独立地开发、测试，最后组装成完整的程序。
模块化的目的是使程序的结构清晰，容易阅读、理解、测试和修改。
（3）信息隐蔽
信息隐蔽是开发整体程序结构时使用的法则，即将每个程序的成分隐蔽或封装在一个单一的设计模块中，在定义每一个模块时尽可能少地显露其内部的处理。
信息隐蔽原则对提高软件的可修改性、可测试性和可移植性都有重要的作用。
（4）模块独立
模块独立是指每个模块完成一个相对独立的特定子功能，并且与其他模块之间的联系简单。
衡量模块独立程度的标准有两个：耦合性和内聚性。
3、系统总体结构设计
系统总体结构设计是要根据系统分析的要求和组织的实际情况对新系统的总体结构形式和可利用的资源进行大致设计，这是一种宏观、总体上的设计和规划。
（1）系统结构设计原则
- 分解-协调原则
- 自顶向下的原则
- 信息隐蔽、抽象的原则
- 一致性原则
- 明确性原则
- 模块之间的耦合尽可能小，模块的内聚度尽可能高
- 模块的扇入系数和扇出系数要合理
- 模块的规模适当
（2）子系统划分
子系统的划分应遵循的原则
- 子系统要具有相对独立性
- 子系统之间数据的依赖性尽量小
- 子系统划分的结果应使数据冗余较小
- 子系统的设置应考虑今后管理发展的需要
- 子系统的划分应便于系统分阶段实现
- 子系统的划分应考虑到各类资源的充分利用
子系统结构设计
子系统结构设计的任务是确定划分后的子系统模块结构，并画出模块结构图。
（3）系统模块结构设计
模块的概念
模块是组成系统的基本单位，它的特点是可以组合、分解和更换。
根据功能具体化程度的不同，模块可以分为逻辑模块和物理模块。
模块的4个要素：输入和输出（外部特性）、处理功能（外部特性）、内部数据（内部特性）、程序代码（内部特性）。
模块结构图
模块结构图主要关心的是模块的外部属性，即上下级模块、同级模块之间的数据传递和调用关系，并不关心模块的内部。
模块结构图是结构化设计中描述系统结构的图形工具，由模块、调用、数据、控制信息和转接符号 5 种基本符号组成。
（4）数据存储设计
4、系统文档
文档的多种作用：
- 用户与系统分析人员在系统规划和系统分析阶段通过文档进行沟通。
- 系统开发人员与项目管理人员通过文档在项目期内进行沟通。
- 系统测试人员与系统开发人员通过文档进行沟通。
- 系统开发人员与用户在系统运行期间进行沟通。
- 系统开发人员与系统维护人员通过文档进行沟通
- 用户与维修人员在运行维护期间进行沟通
二、结构化分析方法 ( Structured Analysis , SA)
1、结构化分析方法概述
抽象和分解是处理任何复杂问题的两个基本手段。
自顶向下的过程是分解的过程，自底向上的过程是抽象的过程。
结构化方法的分析结果：一套分层的数据流图、一本数据词典、一组小说明 (也称加工逻辑说明)、补充材料。
2、数据流图（DFD）
数据流图也称数据流程图(Data Flow Diagram，DFD)，它是一种便于用户理解、分析系统数据流程的图形工具。
（1）数据流图的基本图形元素
| 元素 | 图元 | |
|---|---|---|
| 数据流 | 由一组固定成分的数据组成，表示数据的流向。每个数据流通常有一个合适的名词反映数据流的含义 |  |
| 加工 | 加工描述了输入数据流到输出数据流之间的变换，也就是输入数据流做了什么处理后变成了输出数据流 |  |
| 数据存储（文件） | 用来表示暂时存储的数据，每个文件都有名字。流向文件的数据流表示写文件，流出的表示读文件 |  |
| 外部实体 | 指存在于软件系统外的人员或组织 |  |
（2）数据流图的扩充符号
在 DFD 中，一个加工可以有多个输入数据流和多个输出数据流，此时可以加上一些扩充符号来描述多个数据流之间的关系。
| 星号(*) | 星号表示数据流之间存在“与”关系。如果是输入流则表示所有输入数据流全部到达后才能进行加工处理:如果是输出流则表示加工结束将同时产生所有的输出数据流 |
| 加号 (+) | 加号表示数据流之间存在“或”关系。如果是输入流则表示其中任何一个输入数据流到达后就能进行加工处理:如果是输入流则表示加工处理的结果是至少产生其中一个输出数据流 |
| 异或(⊕) | 异或表示数据流之间存在“互斥”关系。如果是输入流则表示当且仅当其中一个输入流到达后才能进行加工处理: 如果是输出流则表示加工处理的结果是仅产生这些输出数据流中的 |
（3）数据流图的层次结构
每张图中加工个数大致控制在“7加减2”的范围内。
为了方便对图进行管理和查找，可以采用下列方式对 DFD 中的图和加工编号
- 顶层图中只有一个加工 (代表整个软件系统)，该加工不必编号。
- 0 层图中的加工编号分别为 1、2、3···。
- 子图号就是父图中被分解的加工号。
- 对于子图中加工的编号，若父图中的加工号为x的加工分解成某一子图，则该子图中的加工编号分别为 x.1、x.2、x.3···。
（4）数据流图的平衡原则
父图与子图之间的平衡
子图内平衡
3、数据字典（DD）
数据流图描述了系统的分解，但没有对图中各成分进行说明。数据字典就是为数据流图中的每个数据流、文件、加工，以及组成数据流或文件的数据项做出说明。其中，对加工的描述称为“小说明”，也可以称为“加工逻辑说明”
三、结构化设计方法（Structured Design, SD）
结构化设计(Structured Design，SD) 方法是一种面向数据流的设计方法，它可以与 SA 方法衔接。基本思想是将系统设计成由相对独立、功能单一的模块组成的结构。
结构化设计方法中用结构图(Structure Chart) 来描述软件系统的体系结构，指出一个软件系统由哪些模块组成，以及模块之间的调用关系。
1、结构化设计的步骤
第一步是建立一个满足软件需求规约的初始结构图，第二步是对结构图进行改进。
（1）建立初始结构图
结构化方法本质上是一种功能分解方法。
功能模块的分解应满足自顶向下、逐步求精、信息隐蔽、高内聚低耦合等设计准则，
（2）对结构图的改进
初始结构图往往存在一些不合理的设计(包括不合理的模块分解)，因此，可根据设计准则对其进行改进。
（3）书写设计文档
在概要设计完成之后应书写设计规格说明，特别要为每个模块书写模块的功能、接口、约束和限制等，必要时可建立模块开发卷宗。
（4）设计评审
对设计结果及文档进行评审。
2、数据流图到软件体系结构的映射
结构化设计是将结构化分析的结果 (数据流图) 映射成软件的体系结构 (结构图)。
可将数据流图分为变换型数据流图和事务型数据流图。
（1）信息流的类型
交换流
信息沿着输入通路进入系统，同时将信息的外部形式转换成内部表示，然后通过变换中心(也称主加工)处理，再沿着输出通路转换成外部形式离开系统。具有这种特性的信息流称为变换流。变换流型的 DFD 可以明显地分成输入、变换 (主加工) 和输出三大部分。
事务流
信息沿着输入通路到达一个事务中心，事务中心根据输入信息 (即事务)的类型在若干个动作序列(称为活动流)中选择一个来执行，这种信息流称为事务流。事务流有明显的事务中心，各活动流以事务中心为起点呈辐射状流出。
（2）变换分析
变换分析是从变换流型的 DFD 导出程序结构图
确定输入流和输出流，分离出变换中心
第一级分解
第一级分解主要是设计模块结构的顶层和第一层。
第二级分解
第二级分解主要是设计中、下层模块.
事务分析
事务分析是从事务流型 DED 导出程序结构图。
SD方法的设计步骤
- 复查并精化数据流图。
- 确定 DFD 的信息流类型 (变换流或事务流)。
- 根据流类型分别实施变换分析或事务分析。
- 根据系统设计的原则， 对程序结构图进行优化
四、WebApp分析与设计
1、WebApp的特性
- 网络密集型
- 并发性
- 无法预知的负载量
- 性能
- 可用性
- 数据驱动
2、WebApp需求模型
建模以需求工程中确定的用户类别、可用目标、使用场景、业务环节等各类需求等为输入，产生如下 5 种主要的模型类型
（1）内容模型
内容模型给出由 WebApp 提供的全部系列内容，包括文字、图形、图像、音频和视频。
（2）交互模型
交互模型描述了用户与 WebApp 采用了哪种交互方式。交互模型由一种或多种元素构成，包括用例、顺序图、状态图、用户界面原型等。
（3）功能模型
（4）导航模型
导航模型为 WebApp 定义所有导航策略。
（5）配置模型
配置模型描述 WebApp 所在的环境和基础设施
3、WebApp设计
包括：架构设计、构件设计、内容设计、导航设计、美学设计、界面设计。
（1）架构设计
模型-视图-控制器(Model-View-Controller，MVC) 结构是WebApp 基础结构模型之一，它将 WebApp 功能及信息内容分离。
（2）构件设计
- 构件级内容设计
- 构件级功能设计
（3）内容设计
WebApp 的内容结构(线性或非线性)也影响架构，因此设计内容体系结构。
内容体系结构着重于内容对象(诸如网页的组成对象) 的表现和导航的组织，通常采用线性结构、网格结构、层次结构、网络结构四种结构及其组合。
（4）导航设计
建立了 WebApp 的体系结构及其构件后，定义导航路径，使用户可以访问 WebApp 的内容和功能。
五、用户界面设计
1、黄金原则
（1）用户操作控制
- 以不强迫用户进入不必要的或不希望的动作的方式来定义交互模式
- 提供灵活的交互
- 允许中断和撤销用户交互
- 当技能级别增长时可以使交互流线化并允许定制交互
- 使用户与内部技术细节隔离开来
- 设计应允许用户与出现在屏幕上的对象直接交互
（2）减少用户的记忆负担
- 减少对短期记忆的要求
- 建立有意义的默认
- 定义直观的快捷方法
- 界面的视觉布局应该基于真实世界的象征
- 以不断进展的方式揭示信息
（3）保持界面一致
- 允许用户将当前任务放入有意义的环境中
- 在应用系统家族内保持一致性
- 如果过去的交互模型已经建立起了用户期望，除非有不得已的理由，否则不要改变它
2、用户界面的分析与设计
（1）用户界面分析和设计模型
- 软件工程师所创建的设计模型(Design Model)。
- 人机界面设计工程师创建的用户模型 (User Model)。
- 最终用户在脑海里对界面产生的映像，称为用户的心理模型或系统感觉 (System Perception)。
- 系统实现者创建的系统映像(System Image)。
（2）用户界面分析和设计的过程
包括 4 个不同的框架活动：界面分析及建模、界面设计、界面构造和界面确认。
3、用户界面设计问题
在进行用户界面设计时，几乎总会遇到以下 4 个问题：系统响应时间、帮助设施、错误信息处理、菜单和命令标记。
（1）系统响应时间
系统响应时间是指从用户开始执行动作到软件以预期的输出和动作形式给出响应这段时间。
系统响应时间包括两方面的属性：时间长度和可变性。
可变性是指相对于平均时间的偏差（最重要的响应时间特性）。
（2）帮助设施
考虑帮助设施时需要在设计中解决以下问题：
- 进行性交互时，是否在任何时候对任何功能都能得到帮助？
答：有2种选择：提供部分功能的帮助 和 提供全部功能的帮助。 - 用户怎么请求帮助？
答：有 3 种选择：帮助菜单、特殊功能键和 HELP 命令。 - 如何表达帮助？
答：有 3 种选择：提供单独的帮助窗口、在另一个窗口中指示参考某个已印刷的文档、在屏幕特定位置给出一行或两行的简单提示。 - 用户如何回到正常的交互方式？
答：有3种选择：屏幕上显示的返回按钮、功能键或控制序列 - 如何构造帮助信息?
答：有 3 种选择：平面结构(所有信息均通过关键词来访问)、分层结构(用户可以进入分层结构得到更详细的信息) 和超文本的使用。
（3）错误信息处理
出错信息和警告是指出现问题时系统反馈给用户的“坏消息”。
具备特征：
- 消息以用户可以理解的语言描述问题。
- 消息应提供如何从错误中回复的建设性意见。
- 消息应指出错误可能导致哪些不良后果(例如破坏数据文件)，以便用户检查是否出现了这些情况。
- 消息伴随着视觉或听觉上的提示。也就是说，显示消息应该伴随警告声或者消息用闪烁方式显示，或以明显表示错误的颜色来显示。
- 消息不应是裁判性的，即不能指责用户
（4）菜单和命令标记
在提供命令或菜单标签交互时，必须考虑以下问题：
- 每个菜单选择是否都有对应的命令?
- 以何种方式提供命令? 有 3 种选择：控制序列(如 Alt+P)、功能键或输入命令
- 学习和记忆命令的难度有多大? 忘记命令怎么办?
- 用户是否可以定制和缩写命令?
- 在界面环境中菜单标签是不是自解释的?
- 子菜单是否与主菜单所指的功能相一致?