软考笔记（七）高级系统架构师/分析师：系统分析 系统设计
目录
- 软考官网 报名通道
- 软考架构师笔记（一）：计算机系统基础
- 软考架构师笔记（二）：计算机网络基础与信息安全
- 软考架构师笔记（三）：操作系统基础
- 软考架构师笔记（四）：企业信息化与系统规划
- 软考架构师笔记（五）：系统需求工程 需求分析
- 软考架构师笔记（六）：数据库
- 软考架构师笔记（七）：系统分析 系统设计
- 软考架构师笔记（八）：系统架构
- 软考架构师笔记（九）：软件工程与项目管理
- 软考架构师笔记（十）：系统测试 维护 稳定性
系统设计
图的选择
（1）需求分析阶段：数据流图。
（2）概要设计阶段：模块结构图、层次图和HIPO图。
（3）详细设计阶段：程序流程图、伪代码、盒图。
处理流程设计
业务流程建模：
- 标杆瞄准
确定需要进行标杆研究的流程和影响流程成败的关键因素确定瞄准目标的标杆企业、组织及其流程通过走访、调研、会谈、广告等采集数据，并进行分析从众多标杆数据中，选定最佳改进标准。
根据标杆指标，评估企业的既有流程，并确立改进目标 - IDEF（一系列建模、分析和仿真方法的统称）
IDEF0（业务流程 功能建模）、
IDEF1（信息建模）、
IDEF1X（数据建模）、
IDEF2（仿真建模设计）、
IDEF3（过程描述获取）、
IDEF4（面向对象设计）、
IDEF5（本体论描述获取）、
IDEF6（设计原理获取）、
IDEF7（信息系统审计）、
IDEF8（用户界面建模）、
IDEF9（场景驱动信息系统设计）、
IDEF10（实施架构建模）、
IDEF11（信息制品建模）、
IDEF12（组织建模）、
IDEF13（三模式映射设计）
IDEF14（网络规划）。 - DEMO（组织动态本质建模法）
- Petri网
- 业务流程建模语言
- 业务流程重组BPR
BPR是对企业的业务流程进行根本性的再思考和彻底性的再设计，从而获得可以用诸如成本、质量、服务和速度等方面的业绩来衡量的显著性的成就 - 业务流程管理BPM
BPM是一种以规范化的构造端到端的卓越业务流程为中心，以持续的提高组织业务绩效为目的的系统化方法。
IDEFO的建模特点使它可以用来描述企业的业务流程，它的阶梯层次可用来描述业务流程的阶梯结构特性。从高层次看，IDEFO的功能活动与业务流程相对应；而从低层次看，功能活动与流程的业务活动相对应。利用IEDFO的活动描述方式及活动之间的联系方式，可以很好地描述业务流程的架构。IDEF0模型形象、直观、易于理解和分析，但是，这种图形化的模型没有深刻揭示业务流程的内部结构特征和规律，而且当业务流程很复杂时，所对应的有向图就成为一个相互交叉、混乱的网络，不利于分析流程的特征。
BPM与BPR管理思想最根本的不同就在于流程管理并不要求对所有的流程进行再造。构造卓越的业务流程并不是流程再造，而是根据现有流程的具体情况，对流程进行规范化的设计
人机界面设计
- 置于用户控制之下
以不强迫用户进入不必要的或不希望的动作的方式来定义交互方式
提供灵活的交互
允许用户交互可以被中断和撤消
当技能级别增加时可以使交互流水化并允许定制交互
使用户隔离内部技术细节
设计应允许用户和出现在屏幕上的对象直接交互
- 减少用户的记忆负担
减少对短期记忆的要求
建立有意义的缺省
定义直觉性的捷径
界面的视觉布局应该基于真实世界的隐喻
以不断进展的方式揭示信息
- 保持界面的一致性
允许用户将当前任务放入有意义的语境在应用系列内保持一致性
如过去的交互模型已建立起了用户期望，除非有迫不得已的理由下要改变它
结构化设计
系统设计的主要内容包括概要设计和详细设计。
- 抽象化
- 自顶而下、逐步求精
- 信息隐蔽
- 模块独立（高内聚、低耦合）
概要设计又称为系统总体结构设计，它是系统开发过程中很关键的一步，
其主要任务是将系统的功能需求分配给软件模块，确定每个模块的功能和调用关系，形成软件的模块结构图，即系统结构图。
在概要设计中，将系统开发的总任务分解成许多个基本的、具体的任务，为每个具体任务选择适当的技术手段和处理方法的过程称为详细设计。
内聚与耦合
内聚
- 功能内聚：完成一个单一功能，各个部分协同工作，缺一不可
- 顺序内聚：处理元素相关，而且必须顺序执行
- 通信内聚：所有处理元素集中在一个数据结构的区域上
- 过程内聚：处理元素相关，而且必须按特定的次序执行
- 瞬时内聚（时间内聚）：所包含的任务必须在同一时间间隔内执行
- 逻辑内聚：完成逻辑上相关的一组任务
- 偶然内聚（巧合内聚）：完成一组没有关系或松散关系的任务
耦合
- 非直接耦合：两个模块之间没有直接关系，它们之间的联系完全是通过主模块的控制和调用来实现的
- 数据耦合：一组模块借助参数表传递简单数据
- 标记耦合：一组模块通过参数表传递记录信息（数据结构）
- 控制耦合：模块之间传递的信息中包含用于控制模块内部逻辑的信息
- 外部耦合：一组模块都访问同一全局简单变量，而且不是通过参数表传递该全局变量的信息
- 公共耦合：多个模块都访问同一个公共数据环境
- 内容耦合：一个模块真接访问另一个模块的内部数据；一个模块不通过正常入口转到另一个模块的
面向对象设计
基本过程
- 分析模型：设计用例模型， 分析模型
- 设计师：设计用例实现方案，设计技术支撑实施，设计用户界面，细化设计模型
- 设计模型：架构图（用包图表示），用例实现图（用交互图表示），类图（完整、精确），其他（状态图、活动图等）
设计原则
- 单一职责原则：设计目的单一的类
- 开放-封闭原则：对扩展开放，对修改封闭
- 李氏（Liskov）替换原则：子类可以替换父类依赖倒置原则：要依赖于抽象，而不是具体实现；针对接口编程，不要针对实现编程
- 接口隔离原则：使用多个专门的接口比使用单一的总接口要好
- 组合重用原则：要尽量使用组合，而不是继承关系达到重用目的
- 迪米特（Demeter）原则（最少知识法则）：一个对象应当对其他对象有尽可能少的了解
设计模式
模式概念
架构模式：软件设计中的高层决策，例如C/S结构就属于架构模式，架构模式反映了开发软件系统过程中所作的基本设计决策
设计模式：主要关注软件系统的设计，与具体的实现语言无关
惯用法：是最低层的模式，关注软件系统的设计与实现，实现时通过某种特定的程序设计语言来描述构件与构件之间的关系。每种编程语言都有它自己特定的模式，即语言的惯用法。例如引用-计数就是C++语言中的一种惯用法
逆向工程
逆向工程（reverse engineering）有的人也叫反求工程，其大意是根据已有的东西和结果，通过分析来推导出具体的实现方法。软件逆向工程的基本原理是抽取软件系统的主要部分而隐藏细节，然后使用抽取出的实体在高层上描述软件系统。
逆向工程抽取的实体应比源代码更容易推理和接近应用领域，同时在高层上对软件系统的抽象表示要求简洁和易于理解。在软件工程领域，迄今为止没有统一的逆向工程定义。较为通用的是Eliot Chikafsky和Cross在文献中定义的逆向工程的相关术语。
正向工程：从高层抽象和独立于实现的逻辑设计到一个系统的物理实现的传统开发过程。
逆向工程：分析目标系统，认定系统的构件及其交互关系，并且通过高层抽象或其他形式来展现目标系统的过程。
与逆向工程相关的其他术语包括：再文档（Redocumentation）：根据源代码，在同一层次上创建或修改系统文档。
设计恢复（Design Recovery）：结合目标系统、领域知识和外部信息认定更高层次的抽象。
重构（Restructuring）：保持系统外部行为（功能和语义），在同一抽象层次上改变表示形式。
再工程（Reengineering）：结合逆向工程、重构和正向工程对现有系统进行审查和改造，将其重组为一种新形式。
体系结构再现：用于从源码、性能分析信息、设计文档及专家知识等现有信息中抽象出一个更高层次表示的技术和过程。
其中，再文档、设计恢复不改变系统。重构改变了系统，但不改变其功能。再工程通常涉及逆向工程与正向工程的联合使用，逆向工程解决程序的理解问题，正向工程检验哪些功能需要保留、删除或增加。再工程改变了系统的功能和方向，是最根本和最有深远影响的扩展。由此可见，重构是指在同一抽象层次上改变系统的表示形式，将某种形式表示的软件转换成更高抽象形式表示的软件的活动不属于重构，而属于软件的逆向工程。
