文章目录
- 软件工程
- 结构化分析与设计——设计
- 结构化设计方法
- 3.6 概要设计
- 任务
- 表示形式
- 结构化设计方法的设计
- 优化结构设计的指导规则
- 有效模块化设计的启发式原则
- 概要设计值得注意的问题
- 详细设计与概要设计的不同
- 3.7 详细设计
- 结构化程序设计
- 详细设计的原则和方法
- 详细设计常用工具
- 详细设计规格说明与复审
- Jackson方法
- 结构化软件设计的内涵
- 内聚
- 耦合
- 用户（人机）界面设计
- 人机界面的交互方式
- 控制界面的设计
- 界面设计开发
- 实现工具
- 设计评估
- HELP系统设计
- 好的设计具备的特性
- 软件设计文档
- 设计复审
软件工程
结构化分析与设计——设计
结构化设计方法
- 结构设计（概要设计）
- 体系结构设计（SC结构图）
- 接口设计（SC图）
- 过程设计（详细设计）
- 模块的处理过程（N-S图、PAD问题分析图、IPO图、PDL等）
3.6 概要设计
任务
把系统的功能需求分配给软件结构，形成软件的模块结构图。简要的讲，就是把流程图中的加工（处理）转化成模块，形成模块结构图。
表示形式
- 层次（hierarchy）图
- HIPO图
- SC图
SC图：结构图是精确表达程序结构的图形表示方法。它作为软件文档的一部分，清楚地反映处程序中模块之间的层次调用关系和联系：它不仅严格地定义了各个模块的名字、功能和接口，而且还集中地反映了设计思想。换句话说，它以特定的符号表示模块、模块间的调用关系和模块间信息的传递。
一般地，在系统结构图中有6中类型的模块：
- 传入模块：从下属模块取得数据，经过某些处理，再讲其结果传给上级模块。它传送的数据流叫逻辑输入数据流。
- 传出模块：从上级模块获得数据，进行某些处理，再将其结果传送给下属模块。它传送的数据流叫作逻辑输出数据流。
- 变换模块：也叫加工模块，它从上级模块取得数据，进行特定的处理，转换成其他形式，再传送回上级模块。它加工的数据流叫作变换数据流。大多数计算模块（原子模块）属于这一类。
- 源模块
- 漏模块
- 控制模块
在实际系统中有些模块属于上述某一类型，有些模块是上述各种类型的组合。在形成的SC图下应有模块的简要说明，包括：
- 进出该模块的信息（接口描述）；
- 模块内部的信息（功能、数据）；
- 过程陈述，包括主要判定点及任务等；
- 对约束、限制的说明。
结构化设计方法的设计
由数据流模型到处系统（模块）结构图
- 变换分析与变换设计
由变换型数据流映射得到的程序结构。
变换分析（步骤）：
- 划分DFD图的边界
- 建立初始SC图的框架
- 顶层都只含一个用于控制的主模块
- 第一层包括传入、传出和中心变换三个模块
- 分解SC图的各个分支
- 分解实质上是“映射”
- 最后可组成初始SC图
- 事务分析与事务设计
由事务性数据流映射得到的程序结构。
事务分析（步骤）：
- 在DFD图上确定边界
- 事务中心
- 接收部分（包括接受路径）
- 发送部分（包括全部动作路径）
- 画出SC图框架
- DFD图的三个部分分别映射未事务控制模块，接收模块和动作发送模块
- 分解和细化接受分支和发送分支
【归纳】
- 如果数据流不具有显著的事务特点，最好使用变换设计；
- 如果具有明显的事务中心，应该采用事务设计方法；
- 不要机械遵循规则，根据实际情况将模块进行合并或分解。
优化结构设计的指导规则
- 对模块分割、合并和变动调用关系的指导规则
- 提高模块独立性（按四项基本原则调整）
- 模块大小合适（可脱离DFD图进行调整）
- 保持高扇入/低扇出的原则（提高共享模块的使用率）
- 作用域/控制域规则
- 作用域不要超出控制域的范围
- 位置离受它控制的模块越近越好
有效模块化设计的启发式原则
- 评估软件结构的初始模型以降低耦合并提高内聚；
- 高层高扇出使结构最小化；当深度增加时（特别是底层）争取提高扇入；
- 将模块的作用范围限制在模块的控制范围内
- 作用范围：受模块内一个判定影响的所有模块的集合。
- 控制范围：模块本身及其所有下属模块的集合。
- 评估模块接口以降低复杂度和冗余并提高一致性。
- 定义功能可以预测的模块（如对于相同的输入，输出使恒定的），但要过分限制模块（如数据结构的大小、控制流的选择、外部接口的模式等限制）。
概要设计值得注意的问题
- 一个不能工作的“最佳设计”的价值是值得怀疑的；
- 应该在设计的早期阶段对软件结构进行精化；
- 结构简单通常既表示设计风格优雅又表明效率高。
详细设计与概要设计的不同
- 在概要设计阶段，数据项和数据结构的描述比较抽象，主要是：形成SC（模块结构）图；
- 详细设计要提供关于算法的更多细节。
3.7 详细设计
目的：确定模块采用的算法和块内数据结构。
任务：编写软件的“详细设计说明书”
- 为每个模块确定采用的算法；
- 确定每一模块使用的数据结构；
- 确定模块接口的细节。
三种基本控制结构：顺序结构、选择结构、循环结构。
结构化程序设计
结构化程序设计技术是一种程序设计技术，它采用自顶向下逐步求精的设计方法和单入口单出口的控制结构，并且只包含顺序、选择和循环三种结构。其基本要求是提供对设计的无歧义的描述，即能制命控制流程、处理功能、数据组织以及其他方面的实现细节。
目标：
- 是程序的控制流程线性化，即程序的动态执行顺序符合静态书写结构；
- 关于goto语句的建议：
- 当出现算法的自然结构被破坏的异常情况时，应保留goto语句。
- 一个好的原则是避免使用跳转表达正常的循环和条件语句。
常用的算法表示形式：图形、表格和语言
详细设计的原则和方法
- 清晰第一的设计风格：结构第一，效率第二。
- 结构化的控制结构：所有的模块只使用单入口、单出口的三种基本控制结构。
- 逐步细化的实现方法：把给定的模块功能转换成详细过程性描述。
详细设计常用工具
- 程序流程图
- 优点：对控制流程的描绘很直观；
- 缺点：本质上不是逐步求精的好工具、可以随意转移控制、不易表示数据结构。
- N-S图
- 又称为盒图，其目标是构造一种不允许波坏结构化程序设计的图形。同流程图相比，N-S图严格地限制从一个处理到另一个处理的控制转移。
- 盒图的基本特征：
- 功能域定义明确，表示清晰；
- 不允许随意更改控制；
- 局部和全局数据的作用域很容易确定；
- 表示递归算法很方便。
- 伪代码和PDL语言
- 用文字形式表示数据结构和处理过程；
- PDL是以一种“混合”语言：
- 具有严格的关键字外部语法
- 使用自然语言表示实际操作和判定条件
- 优点：可以作为注释直接插在源程序中间；可以使用普通的文字处理程序完成PDL的书写和编辑；已经又自动处理程序存在，可以自动由PDL生成程序代码。
- 缺点：不如图形工具形象直观；描述复杂的条件组合与动作间的对象关系时，不如判定表或判定树清晰简单。
- PAD（Problem Analysis Diagram）图
- 用二维树形结构来表示程序的控制流。
- 特点：
- 用PAD构成元素设计出来的程序必然是结构化程序；
- 问题分析图所描绘的程序结构十分清晰；
- 问题分析图表示的程序逻辑易读、易懂、易记；
- 程序从图中最左竖线上端的结点开始执行，自上而下，从左向右按顺序执行，遍历所有结点；
- 容易将PAD转换成高级语言源程序，该转换可由软件自动完成，有利于提高软件可靠性和软件生产；
- 既可用于表示程序逻辑，也可用于描绘数据结构；
- PAD的元素支持自顶向下、逐步求精方法的使用。
详细设计规格说明与复审
详细设计说明书是详细设计阶段的文档，它是程序运行过程的详细描述。
复审是针对设计文档的复审。
- 复审原则：复审的目的是为了及早找出程序中的错误，一般不请用户和其他领域的代表参加。复审中提出的问题应做详细记录，但不谋求当场解决。复审结束前，应做出本次复审能否通过的结论。
- 复审的主要内容：审查模块的设计是否满足功能和性能要求，选择的算法和数据结构是否合理、是否符合编码语言特性，设计描述是否简单清晰等。
- 复审的方式：复审分正式和非正式两种方式。非真实复审的特点是参加人员少，均为同行，方便灵活。“走查”就是一种非正式复审，复审时有一名设计人员逐行宣读设计资料，由到会同行跟随他指出的次序一行行的往下审查，发现问题就做好记录，然后根据多数参加者的意见，决定是否通过改设计资料。正式复审除软件开发人员外，还邀请用户代表和领域专家参加，通常采用大便方式，回答与会者的问题并记录各种重要的评审意见。
Jackson方法
- 实体动作
- 实体结构
- 初始建模
- 系统功能
- 系统时间
- 系统实现
结构化软件设计的内涵
- 软件设计的任务
- 软件设计的基本概念
- 模块化设计
- 设计需要处理的的问题
- 设计文档及复审
设计是把问题转化为解决方案的创造性过程，解决方案的描述也称为设计。
软件设计的两个阶段
- 设计者必须同时满足用户和系统开发人员的要求
- 概要设计书
- 详细设计书
- 设计者迂回于各种活动中：
- 理解需求
- 提出可能的方案
- 测试方案的可能性
- 向用户描述各种可能
- 向编程人员提供设计文档
软件设计的内容
- 体系结构设计
- 定义软件部件间的关系
- 接口设计
- 软件内部、外部及与人之间的通信
- 数据设计
- 信息模型
- 软件数据结构
- 过程设计
- 软件组件的过程性描述
软件设计的任务
分析模型-》设计模型-》设计文档
分解和模块化
系统设计方法：
- 功能分解：将功能作为组件
- 面向数据的分解：基于外部数据结构
- 面向事件的分解：基于系统必须处理的事件
- 外部输入设计：基于系统的用户输入
- 面向对象设计：定义对象的类及其相互联系
模块和模块化
- 模块化：当系统的每项功能恰好由一个输入输出都明确定义的组件完成的时候，我们称这个系统模块化。
- 模块：表示能够用计算机程序代码实现的，相对独立的单一数据处理功能，所以模块有时也叫功能模块。
- 进一步明确模块是拥有明确定义的输入、输出和特性的程序实体。
设计方法的选择
- 应该允许不同的设计者使用他们喜欢的技巧，只要他们的文档能让其他设计者明白就行。
- 设计方法的选择有时取决于设计者的偏好，而更多的时候取决于系统要求的结构或数据。
软件设计中涉及的问题
- 抽象与细化
- 抽象：分层次考虑和处理问题（数据和过程）。
- 细化：从高到底的逐步分解过程。
- 信息隐藏：对其他模块隐藏模块内部的数据和过程。
抽象
抽象是对具体对象（问题）进行概括，抽出这一类对象的公共性质并加以描述的过程。
- 先注意问题的本质及描述，其次是实现过程或细节。
- 数据抽象：描述某类对象的属性或状态（对象相互区别的物理量）。
- 代码抽象：描述某类对象的共有的行为特征或具有的功能。
- 抽象的实现：通过类的声明。
模块化设计的好处
- 信息隐藏
- 从不同角度了解系统
- 将难以解决的问题独立出来；抽象层次通过逐层分析来了解问题。
- 允许不同的模块采用不同的设计方法。
模块化设计
- 把大型软件按照规定的原则分成一个个较小的、相对独立但又相互关联的模块。
分解
- 模块化是为了使一个复杂的大型程序额能被人的智力所管理
模块划分的基本原则
- 模块独立性强
- 块内联系强
- 块间联系弱
- 高内聚
- 模块内部各成分之间
- 低耦合
- 一个模块与其他模块之间
- 公共（共享）模块
- 多个模块公用
上述原则概括了把软件划分为模块时要遵守的准则，也是判断模块构造是不是合理的标准。但是到目前为止，没有统一的标准判断一个系统划分成几个模块是最优的。
模块独立性
- 有效模块化的软件容易开发出来
- 独立的模块比较容易测试和维护
内聚
内聚是模块功能强度（一个模块内部各个元素彼此结合的紧密程度）的度量。一个模块内部各个元素之间的联系越紧密，则它的内聚性就越高，相对地，它与其他模块之间的耦合就会减低，而模块独立性就越强。
内聚与耦合
内聚和耦合是相互关联的。在程序结构中各模块的内聚程度越高，模块间的耦合程度就越低，但这也不是绝对的。软件概要设计的目标是力求增加模块的内聚，尽量减少模块间的耦合，但增加内聚比减少耦合更重要，应当把更多的注意力集中到提高模块的内聚程度上来。
低内聚
- 偶然性内聚
模块内各部分没有联系，或者即使有联系，这种联系也很松散。 - 逻辑性内聚
这种模块把几种相关的功能组合在一起，每次调用时，由传送给模块的判定参数来确定该模块应执行哪一种功能。这种模块是单入口的多功能模块。类似的有错误处理模块，它接受出错信号，对不同类型的错误打印出不同的出错信息。 - 时间性内聚
时间内聚又称为经典内聚。这种模块大多为多功能模块，但模块的各个功能执行与时间有关，通常要求所有功能必须在同一时间段内执行。例如初始化模块和终止模块。
中内聚
- 过程性内聚
如果一个模块内的处理是相关的，而且必须以特定次序执行，则称这个模块为过程内聚模块。 - 通讯性内聚
如果一个模块内各功能部分都使用了相同的输入数据或产生了相同的输出数据，则称之为通信内聚模块。
高内聚
- 顺序性内聚
如果一个模块内的处理元素和同一个功能密切相关，而且这些处理必须顺序执行。（通常一个处理元素的输出数据作为下一个处理元素的输入数据） - 功能性内聚
一个模块中各个部分都是某一具体功能必不可少的组成部分，或者说该模块中所有部分都是为了完成一项具体功能而协同工作，紧密联系，不可分割的。则称该模块为功能内聚模块。
耦合
对一个软件结构内不同模块之间互连程度的度量，耦合强弱取决于模块间接口的复杂程度、调用模块的方式以及哪些信息通过接口。在软件设计中应该追求尽可能松散耦合的系统。
- 非直接耦合
如果两个模块之间没有之间关系，它门之间的联系完全是通过主要模块的控制和调用来实现的，这就是非直接耦合。 - 数据耦合
如果一个模块访问另一个模块时，彼此之间是通过数据参数（不是控制参数、公共数据结构或外部变量）来交换输入、输出信息的，则称这种耦合为数据耦合。 - 标记耦合
如果一组模块通过参数表传递记录信息，就是标记耦合。事实上，这组模块共享了这个记录，它是某一类数据结构的子结构，而不是简单变量。这要求这些模块都必须清楚该记录的结构，并按结构要求对此记录进行操作。 - 控制耦合
如果一个模块通过传递开关、标识、名字等控制信息，明显的控制选择另一模块的功能，就是控制耦合。 - 外部耦合
一组模块都访问同一全局简单变量而不是同一全局数据结构，而且不是通过参数表传递该全局变量的信息，则称之为外部耦合。 - 公共耦合
若一组模块都访问同一个公共数据环境，则它们之间的耦合称为公共耦合。公共的数据环境可以是全局数据结构、共享的通信区、内存的公共覆盖区等。公共耦合会引起下列问题：
- 所有公共耦合模块都与某一个公共数据环境内部各项物理安排有关，若修改某个数据的大小，将会影响到所有的模块。
- 无法控制各个模块对公共数据的存取，严重影响软件模块的可靠性和适应性。
- 公共数据名的使用，明显降低了程序的可读性。
- 内容耦合
如果出现下列情况之一，两个模块间就发生了内容耦合：
- 一个模块访问另一个模块的内部数据；
- 一个模块不通过正常入口而转到另一个模块的内部；
- 两个模块有一部分程序代码重叠（只可能出现在汇编程序中）；
- 一个模块有多个入口（这意味着一个模块有几种功能）。
关于耦合的设计原则
- 尽量使用数据（特征）耦合；
- 少用控制耦合；
- 限制公共环境耦合的范围；
- 完全不用内容耦合。
建立公共（共享）模块
建立公共模块的目的是减少冗余，减少不必要的重复工作，划出某项功能成为一个能被几个模块共同利用模块。也就是模块结构图的形态是中层宽大、上下小的。
自顶向下和自底向上设计
- 自顶向下：顶层开始，逐步分解。
- 易于修改和扩展
- 整体测试较易通过
- 需要进行详细可行性论证
- 有底向上：选择关键部分先设计，而后扩展到整个系统。
- 可能导致较大的重新设计
- 整体测试可能在模块接口间发现不一致等问题
- 如果在可行性上出现问题，可以较早发现
用户（人机）界面设计
人机界面也成为用户界面，界面设计主要包括三个方面：
- 设计软件构件之间的接口；
- 设计模块和其他非人的信息生产者和消费者的界面；
- 设计人（如用户）和计算机间的界面。
界面的设计原则
- 分析用户类型
- 应用程序和界面分离
- 一致性
- 尽量减少用户工作
- 提供反馈
- 出错处理和帮助功能
- 增加可视化图形表示
Theo Mandel黄金原则：
- 置于用户控制之下（定义一组允许用户操作控制的原则）
- 以不强迫用户进入不必要的或不希望的动作的方式来定义交互方式
- 提供灵活的交互
- 允许用户交互可以被中断和撤消
- 当技能级别增加时可以使交互流水化并允许定制交互
- 使用户隔离内部技术细节
- 设计应允许用户和出现在屏幕上的对象直接交互
- 减少用户的记忆负担
- 减少对短期记忆的要求
- 建立有意义的缺省
- 定义直觉性的捷径
- 界面的视觉布局应该基于真实世界的隐喻
- 以不断进展的方式揭示信息
- 保持界面一致
- 用户应以一致的方式展示和获取信息
- 所有可视信息的组织均按照均按照贯穿所有屏幕显示所保持的设计标准
- 输入机制被约束到有限的集合，在整个应用中被一致地使用
- 从任务到任务的导航机制被一致地定义和实现
- 允许用户将当前任务放入有意义的语境
- 在应用系列内保持一致性
- 如果过去的交互模型已建立起了用户期望，除非有迫不得已的理由，不要改变它。
用户友好性设计
用户友好性一般属于软件的性能特性，它独立于所有具体功能，却影响着所有功能的重用性。用户友好性应体现在与用户有接口的软件特性上。其根本目的是为了软件可重用性、可维护性。
标志：可操作性、健壮性、易学习性、可扩展性。
界面设计模型
以下四种模型可能相差甚远，界面设计人员的任务就是消除这些差距，导出一致的界面表示
- 软件工程师创建的设计模型
- 人员工程师创建的用户模型
- 终端用户对未来系统的假想
- 系统实现后得到的系统映象
用户界面设计过程
- 用户、任务和环境分析及建模
- 界面设计
- 界面构造
- 界面确认
影响用户行为特性的因素
- 人-机匹配性
- 人的固有技能
- 人的固有弱点
- 用户的知识经验
- 用户对系统的期望和态度
用户对计算机系统的要求
- 让用户灵活地使用
- 适应不同类型用户
- 系统的行为及效果对用户透明
- 用户对系统的期望和态度
- 提供联机帮助功能
- 人机交互尽可能和人际通信相似
用户技能方面的使用需求
- 应让系统去适应用户
- 使用易于理解、掌握的准自然语言
- 一致性的系统设计
- 用户对系统的期望和态度
- 能通过系统学习
- 系统提供演示及范例
用户习性方面的使用需求
- 系统应让用户有耐心
- 系统应很好地对付人的易犯错误
- 系统应对不同用户提供不同交互方式
用户经验、知识方面的使用需求
- 系统应能让未经专门训练的用户使用
- 系统能对不同经验用户做出不同反应
- 提供统一系统的一致性，建立标准化人-机界面
- 系统必须适应用户在应用领域的知识变化，提供动态的自适应的设计
用户对系统的期望方面的要求
- 用户界面应提供形象、生动、美观的布局显示和操作环境。
- 系统处理问题应尽可能简单，提供学习机制。
- 系统应对不同用户提供不同交互方式
人机界面的交互方式
菜单界面
- 按显示形象分类:
- 正文菜单
- 图标菜单
- 正文图标混合菜单
- 按屏幕位置和操作风格分类:
- 固定
- 浮动
- 下拉式
- 嵌入式
对话
- 对话形式:
- 必须回答式
- 无需回答式
- 警告式
- 对话实现方式:
- 标准对话
- 定做式对话
控制界面的设计
- 用控制对话选择操作命令
- 用菜单界面进行控制
- 用功能键定义操作命令
- 用图标表示对象或命令
界面设计开发
界面设计过程的步骤
- 建立任务的目标和意图
- 为每个目标和意图制定特定的动作序列
- 按在界面上执行的方式对动作序列进行规约
- 指明系统状态，即执行动作时的界面表现
- 定义控制机制，即用户可用的改变系统状态的设备和动作
- 指明控制机制如何影响系统状态
- 指明用户如何通过界面上的信息解释系统状态
定义界面对象和动作
为创建描述图符的图形设计和放置、描述性屏幕文字的定义、窗口的规约和命名、菜单项的规约的屏幕布局提供基础。响应时间、命令和动作结构、错误处理和帮助设施等设计问题应该在精化设计模型时考虑。
导航方式
- 线性方式
- 层次方式
- 网络式
- 混合式
数据输入界面设计
- 数据输入的规则
- 明确的输入
- 明确的动作
- 明确的取消
- 确认删除
- 提供反馈
- 允许编辑
- 提供复原（Undo）
- 自由格式
- 提示输入的范围
- 数据显示的规则
- 只显示必要的数据
- 在一起使用的数据显示在一起
- 显示出的数据应与用户执行的任务有关
- 每一屏数据的数量不应超过整个屏幕面积的30%
- 屏幕布局规则
- 尽量少用代码和缩写
- 多个显示画面，应建立统一格式
- 提供明了的标题、标栏及其它提示信息
- 遵循用户习惯
- 采用颜色、字符大小、下划线、不同字体等方式强化重要数据
实现工具
用户界面工具箱
用户界面开发系统(UIDS):采用预包装的软件构件来构造用户界面。UIDS的固有机制:
- 管理输入设备
- 确认用户输入
- 处理错误和显示出错信息
- 提供反馈(如自动的输入响应)
- 提供帮助和提示
- 处理窗口、域和窗口内的滚动
- 建立应用软件和界面间的连接
- 将应用程序与界面管理功能分开
- 允许用户定制界面
设计评估
界面设计评价周期：
- 初步设计
- 创建原型界面
- 用户评估界面
- 设计者研究评估结果
- 修改设计（返回步骤2）
HELP系统设计
HELP系统设计不属于界面设计范围，涉及系统整体结构，是结构级用户友好性设计。
帮助方式
- 操作指南文档（植入系统、未植入系统）
- 基于帮助文件的要求性帮助（命令级帮助）
- 说明性帮助
- 嵌入系统的要求性帮助
- 嵌入培训功能的智能帮助系统
好的设计具备的特性
- 模块独立性
- 异常的识别和处理
- 检错和容错机制
软件设计文档
软件设计说明书：
- 范围
- 数据设计
- 体系结构设计
- 接口设计
- 模块的过程设计
- 其他。包括测试的考虑，确保设计满足所有需求，设计约束和一些特殊注解等内容。
设计复审
- 及早发现设计中的缺陷
- 差错的传播
- 复审的内容
- 概要设计复审
- 系统的总体结构，模块划分，内外接口
- 详细设计复审
- 各个模块的具体设计
复审的指导原则
- 在传统软件设计中，概要设计复审与过程设计复审应该分开进行，不允许合并为一次复审。
- 除软件开发人员外，概要设计复审必须有用户代表参加，必要时还可邀请有关领域的专家到会；过程设计复审一般不邀请用户和其他领域的代表。
- 参加复审的设计人员应欢迎别人提出批评和建议，不要为设计的缺陷“护短”。
- 复审中提出的问题应详细记录，但不要谋求当场解决。
- 复审结束时，应作出本次复审能否通过的结论。
