第五章 系统设计

一、信息系统设计阶段（⭐）

1、概要设计

• 总体设计
• 总体布局设计
• 网络拓扑结构设计
• 资源配置设计
• 模块化结构设计
• 划分功能模块
• 模块功能和职责
• 模块间的调用关系
• 模块间的信息传递

2、详细设计

（1）代码设计
是信息分类和编码的工作，是将系统中有某些共同属性或特征的信息归并在一起，并利用便于计算机和人识别和处理的符号来表示这些信息的设计工作。
（2）数据库设计
构建既能客观、准确地反映外部世界，又便于人类大脑认识的概念模型，并在此基础上对数据进行建模，转化为数据库管理系统所支持的数据模型；选择合适的存储结构和存储方法，最终完成数据库的设计工作。
（3）输入/输出设计
输入/输出设计主要是对以记录为单位的各种输入输出报表格式的描述。另外，对人机对话格式的设计和输入输出装置的选择也在这一步完成。
（4）用户界面设计
用户界面设计是指用户与系统之间架起一座桥梁，主要内容包括：定义界面形式、定义基本的交互控制形成、定义图形和符号、定义通用的功能键和组合键的含义及其操作内容、定义帮助策略等。
（5）处理过程设计
则定义每个模块的内部执行过程，包括数据的组织、控制流、每一步的具体加工要求和实施细节。

二、处理流程设计（⭐⭐）

1、业务流程建模方法

（1）标杆瞄准
（2）IDEF（一系列建模、分析和仿真方法的统称）
（3）DEMO（组织动态本质建模法）
（4）Petri网
（5）业务流程建模语言
（6）基于服务的BPM

2、处理流程设计IDEF（⭐）

IDEF0：业务流程（功能）建模；
IDEF1：信息建模；
IDEF1X：数据建模（如ER模型）；
IDEF2：仿真建模设计；
IDEF3：过程描述获取；
IDEF4：面向对象设计；
IDEF5：本体论描述获取；
IDEF6：设计原理获取；
IDEF7：信息系统审计；
IDEF8：用户界面建模；
IDEF9：场景驱动信息系统设计；
IDEF10：实施架构建模；
IDEF11：信息制品建模；
IDEF12：组织结构建模；
IDEF13：三模式映射设计；
IDEF14：网络规划。

3、流程设计工具

（1）程序流程图：是表达系统执行过程的描述工具。
着重于表达：数据在系统中传输时所通过的存储介质和工作站，与物理技术密切联系。
缺点：不能反映系统结构、模块功能、无法评审是否符合要求。
绘制图的主要依据：信息处理的步骤和内容，每一步骤所涉及的物理过程，各步骤之间的物理和逻辑关系。
（2）IPO图：是一种反映模块的输入、处理和输出的图形化表格。描述了模块的输入输出关系、处理内容、模块的内部数据和模块的调用关系。
（3）HIPO图：分层次自顶向下分解系统，将每个模块的输入、处理和输出关系表示出来就得到了HIPO图。
（4）盒图
为避免流程图在描述程序逻辑时的随意性与灵活性，美国学提出了用方框代替传统的PFD，通常把这种图称为N-S图或盒图，与PFD类似，在N-S图中也包括五种控制结构，分别是顺序型、选择型、WHILE循环型（当型循环）、UNTIL循环型（直到型循环）和多分支选择型，任何一个N-S图都是这五种基本控制结构相互组合与嵌套的结果。
在N-S图中，过程的作用域明确；它没有箭头，不能随意转移控制；而且容易表示嵌套关系和层次关系；并具有强烈的结构化特征。但是当问题很复杂时，N-S图可能很大。
（5）问题分析图
问题分析图（Problem Analysis Diagram，PAD）是继PFD和N-S图之后，又一种描述详细设计的工具，它由日立公司于1979年提出，也是一种支持结构化程序设计的图形工具。PAD也包含五种基本控制结构，并允许递归使用。
（6）过程设计语言PDL
过程设计语言（Process Design Language，PDL）也称为结构化语言或伪代码（pseudo code），它是一种混合语言，采用自然语言的词汇和结构化程序设计语言的语法，用于描述处理过程怎么做，类似于编程语言。过程设计语言用于描述模块中算法和加工逻辑的具体细节，以便在开发人员之间比较精确地进行交流。
（7）判定表
对于具有多个互相联系的条件和可能产生多种结果的问题，用结构化语言描述则显得不够直观和紧凑，这时可以用以清楚、简明为特征的判定表（decision table）来描述。判定表采用表格形式来表达逻辑判断问题，表格分成四个部分，左上部分为条件说明，左下部分为行动说明，右上部分为各种条件的组合说明，右下部分为各条件组合下相应的行动。在表的右上部分中列出所有条件，“T”表示该条件取值为真，“F”表示该条件取值为假，空白表示这个条件无论取何值对动作的选择不产生影响，在判定表右下部分中列出所有的处理动作，“Y”表示执行对应的动作，空白表示不执行该动作；判定表右半部分的每一列实质上是一条规则，规定了与特定条件取值组合相对应的动作。
（8）判定树
判定树（decision tree）也是用来表示逻辑判断问题的一种常用的图形工具，它用树来表达不同条件下的不同处理流程，比语言、表格的方式更为直观。判定树的左侧（称为树根）为加工名，中间是各种条件，所有的行动都列于最右侧。

三、软件架构设计（⭐）

1、架构的概念

架构设计就是需求分配，即将满足需求的职责分配到组件上。
软件架构风格是描述某一特定应用领域中系统组织方式的惯用模式。架构风格定义一个系统家族，即一个体系结构定义一个词汇表和一组约束。词汇表中包含一些构件和连接件类型，而这组约束指出系统是如何将这些构件和连接件组合起来的。
软件架构为软件系统提供了一个结构、行为和属性的高级抽象，由构成系统的元素的描述、这些元素的相互作用、指导元素集成的模式以及这些模式的约束组成。
软件架构是项目干系人进行交流的手段，明确了对系统实现的约束条件，决定了开发和维护组织的组织结构，制约着系统的质量属性
软件架构使推理和控制的更改更加简单，有助于循序渐进的原型设计，可以作为培训的基础
软件架构是可传递和可复用的模型，通过研究软件架构可能预测软件的质量

2、软件架构风格

（1）数据流风格：批处理序列、管道-过滤器
（2）调用/返回风格：主程序/子程序、面向对象、层次结构
（3）独立构件风格：进程通信、事件驱动系统（隐式调用）
（4）虚拟机风格：解释器、基于规则的系统
（5）仓库风格：数据库系统、超文本系统、黑板系统

四、结构化设计（⭐⭐⭐）

1、功能模块设计的原则

（1）模块大小适中：50~100行，最多不超过500行
（2）适宜的系统深度和宽度比例，尽可能减少调用的深度
（3）适度控制模块的扇入扇出：扇出 3~4一般不超过7，扇入越大越好
（4）单入口，单出口
（5）模块的作用域应该在模块之内
（6）功能应该是可预测的
（7）高内聚低耦合
（8）系统分解有层次
（9）较小的数据冗余

2、模块独立性的度量

（1）聚合：衡量模块内部各元素结合的紧密程度

• 偶然聚合：模块完成的动作之间没有任何关系，或者仅仅是一种非常松散的关系。
• 逻辑聚合：模块内部的各个组成在逻辑上具有相似的处理动作，但功能用途上彼此无关。
• 时间聚合：模块内部的各个组成部分所包含的处理动作必须在同一时间内执行。
• 过程聚合：模块内部各个组成部分所要完成的动作虽然没有关系，但必须按特定的次序执行。
• 通信聚合：模块的各个组成部分所完成的动作都使用了同一个数据或产生同一输出数据。
• 顺序聚合：模块内部的各个部分，前一部分处理动作的最后输出是后一部分处理动作的输入。
• 功能聚合：模块内部各个部分全部属于一个整体，并执行同一功能，且各部分对实现该功能都比不可少

（2）耦合：度量不同模块间互相依赖的程度

• 非直接耦合：两个模块之间没有直接关系，它们的联系完全是通过主模块的控制和调用来实现的。
• 数据耦合：两个模块彼此间通过数据参数交换信息。
• 标记耦合：一组模块通过参数表传递记录信息，这个记录是某一个数据结构的子结构，而不是简单变量。
• 控制耦合：两个模块彼此间传递的信息中有控制信息。
• 外部耦合：一组模块都访问同一全局简单变量而不是同一全局数据结构，而且不是通过参数表传递该全局变量的信息。
• 公共耦合：两个模块之间通过一个公共的数据区域传递信息。
• 内容耦合：一个模块需要涉及到另一个模块的内部信息。

3、系统结构图

系统结构图（Structure Chart，SC）又称为模块结构图，它是软件概要设计阶段的工具，反映系统的功能实现和模块之间的联系与通信，包括各模块之间的层次结构，即反映了系统的总体结构。在系统分析阶段，系统分析师可以采用SA方法获取由DFD、数据字典和加工说明等组成的系统的逻辑模型；在系统设计阶段，系统设计师可根据一些规则，从DFD中导出系统初始的SC。常用的SC主要有变换型、事务型和混合型三种。
SC包括模块、模块之间的调用关系、模块之间的通信和辅助控制符号等四个部分。

五、面向对象设计（⭐⭐⭐⭐）【案例】

1、过程

2、设计原则

• 系统设计 – 面向对象设计 – 设计原则
• 单一职责原则：设计目的单一的类
• 开放-封闭原则：对扩展开放，对修改封闭
• 李氏(Liskov)替换原则：子类可以替换父类
• 依赖倒置原则：要依赖于抽象，而不是具体实现；针对接口编程，不要针对实现编程
• 接口隔离原则：使用多个专门的接口比使用单一的总接口要好
• 组合重用原则：要尽量使用组合，而不是继承关系达到重用目的
• 迪米特(Demeter)原则(最少知识法则)：一个对象应当对其他对象有尽可能少的了解

3、设计模式

（1）概念

架构模式：软件设计中的高层决策，例如C/S结构就属于架构模式，架构模式反映了开发软件系统过程中所作的基本设计决策
设计模式：主要关注软件系统的设计，与具体的实现语言无关
惯用法：是最低层的模式，关注软件系统的设计与实现，实现时通过某种特定的程序设计语言来描述构件与构件之间的关系。每种编程语言都有它自己特定的模式，即语言的惯用法。例如引用-计数就是C++语言中的一种惯用法

（2）设计模式分类

（i）创建型模式与对象的创建有关，抽象了实例化过程，它们帮助一个系统独立于如何创建、组合和表示它的那些对象。一个类创建型模式使用继承改变被实例化的类，而一个对象创建型模式将实例化委托给另一个对象。
（ii）结构型模式处理类或对象的组合，结构型设计模式涉及如何组合类和对象以获得更大的结构。结构型类模式采用继承机制来组合接口或实现。结构型对象模式不是对接口和实现进行组合，而是描述了如何对一些对象进行组合，从而实现新功能的一些方法。
（iii）行为模式涉及算法和对象间职责的分配。行为模式不仅描述对象或类的模式，还描述它们之间的通信模式。行为型类模式使用继承机制在类间分配行为，这里包括模板类模式和解释器类模式。行为对象模式使用对象复合而不是继承。一些行为对象模式描述了一组对等的对象怎样相互协作以完成其中任一对象都无法单独完成的任务。

（3）设计模式适用场景
（i）创建型模式

（ii）结构型模式

（iii）行为型模式

  

7、人机界面设计

（1）置于用户控制之下
以不强迫用户进入不必要的或不希望的动作的方式来定义交互方式
提供灵活的交互
允许用户交互可以被中断和撤消
当技能级别增加时可以使交互流水化并允许定制交互
使用户隔离内部技术细节
设计应允许用户和出现在屏幕上的对象直接交互

（2）减少用户的记忆负担
减少对短期记忆的要求
建立有意义的缺省
定义直觉性的捷径
界面的视觉布局应该基于真实世界的隐喻
以不断进展的方式揭示信息

（3）保持界面的一致性
允许用户将当前任务放入有意义的语境
在应用系列内保持一致性
如过去的交互模型已建立起了用户期望，除非有迫不得已的理由，不要改变它