跳至主要內容

系统分析与设计

BraumAce2026年1月2日软考系统架构设计师系统分析与设计约 6936 字大约 23 分钟

系统分析与设计

1. 系统设计

1.1 概念

  1. 设计工程是指在整个软件开发过程中，通过对需求工程的结果进行分析和设计，制定出系统的整体设计方案，包括概要设计、详细设计、应用设计等多个部分。
  2. 主要目的：为系统制定蓝图，在各种技术和实施方法中权衡利弊，精心设计，合理地使用各种资源，最终勾画出新系统的详细设计方法。

1.2 设计方法

  1. 结构化设计方法
  2. 面向对象设计方法

1.3 设计内容

  1. 概要设计：
    1. 基本任务：又称为 系统总体结构设计，是将系统的功能需求分配给软件模块，确定每个模块的功能和调用关系，形成软件的模块结构图，即 系统结构图。
    2. 软件概要设计将软件需求转化为软件设计的 数据结构 和软件的 系统结构。
    3. 软件概要设计，又称高层设计，是 将需求规格转化为软件系统的结构设计 的过程，目的是为后续的详细设计奠定基础。其核心任务是 定义模块的结构、层次、功能以及模块之间的接口和数据流向。
    4. 常用的描述程序结构的图形工具：
      1. 模块结构图：描述模块间的调用关系；
      2. 层次图：展示模块的层次和结构；
      3. HIPO 图：既反映模块的结构又说明其功能。
  2. 详细设计：
    1. 基本任务：模块内详细算法设计、模块内数据结构设计、数据库的物理设计、其他设计（代码、输入/输出格式、用户界面）、编写详细设计说明书、评审。

1.4 基本原理

  1. 抽象化
  2. 自顶而下，逐步求精
  3. 信息隐蔽
  4. 模块独立（高内聚，低耦合）

1.5 设计原则

  1. 保持模块的大小适中
  2. 尽可能减少调用的深度
  3. 多扇入，少扇出
  4. 单入口，单出口
  5. 模块的作用域应该在模块之内
  6. 功能应该是可预测的

1.6 系统设计模型

  1. 行为模型：关注系统的行为分析和描述
  2. 领域模型：由开发人员和领域专家协商，反映深层次的领域知识
  3. 专家模型：更关注专家的专业经验
  4. 知识库模型：更多地用于知识管理系统

2. 处理流程设计

2.1 定义

  1. 处理流程设计的任务是：设计出 系统所有模块以及它们之间的相互关系，并 具体设计出每个模块内部的功能和处理过程，为开发人员提供详细的技术资料。

2.2 组成内容

  1. 流程：
    1. ISO 9000 定义：一组将输入转化为输出的相互关联或相互作用的活动。
    2. 6 个要素：输入资源、活动、活动的相互作用、输出结果、用户、价值
  2. 工作流：
    1. WFMC 定义：可部分 / 完全自动执行的业务过程，基于规则在执行者间传递文档、任务等。
  3. 活动及其所有者：
    1. 活动：流程基本要素，改变数据 / 状态，推动流程（人或系统完成）
    2. 所有者：有权结束活动并推动流程的参与者
  4. 工作项：
    1. 定义：流程实例中参与者需执行的具体工作

2.3 流程设计工具（详细设计）

  1. 图形工具
    1. 程序流程图（PFD）：用图框表示各种操作，独立于任何程序设计语言，直观且易于掌握，但符号不规范、随意转移控制的问题需要改进。只能描述执行过程而不能描述有关的数据。
    2. N-S 图（盒图）：以方框代替传统的 PFD，包括顺序型、选择型、WHILE 循环型、UNTIL 循环型和多分支选择型控制结构，具有强烈的结构化特征。
    3. IPO 图：描述模块的输入、输出和数据加工，结构清晰，常用于 系统设计文档。
    4. 问题分析图（PAD 图）：由日立公司提出，支持结构化程序设计，包含五种基本控制结构，执行顺序明确，适合嵌套和层次关系的表示。
    5. 判定树：用树形结构表示逻辑判断，条件和处理流程直观，适合复杂条件判断。
  2. 表格工具
    1. 判定表：结构清晰、简明，用表格形式表示逻辑判断问题，条件和行动一目了然，适合多个互相联系的条件和多种结果的描述。
  3. 语言工具
    1. 过程设计语言（PDL）：也称伪代码，混合自然语言词汇和结构化程序设计语言语法，用于描述处理过程，灵活。

2.4 工作流管理系统（WFMS）

  1. 概念
    1. 通过软件定义、创建工作流并管理其执行。
    2. 它运行在一个或多个工作流引擎上，这些引擎解释对过程的定义与工作流的参与者相互作用，并根据需要调用其他 IT 工具或应用。
  2. 功能
    1. 对工作流建模：定义活动和规则，对应现实业务处理过程
    2. 工作流执行：创建和执行实际工作流
    3. 业务过程管理和分析：监控管理执行中的业务情况
  3. 工作流参考模型（WRM）
    1. 6 个模块：
      1. 工作流执行服务
      2. 工作流引擎
      3. 流程定义工具
      4. 客户端应用
      5. 调用应用
      6. 管理监控工具
    2. 作用：为工作流管理系统关键模块提供了功能描述，并描述了关键模块之间的交互，而且这个描述是独立于特定产品或技术的实现的

3. 结构化方法（Structured Analysis and Structured Design，SASD）

3.1 结构化分析（Structured Analysis， SA）

  1. 结构化分析的常用手段：
    1. 数据流图（DFD）
    2. 数据字典（DD）
    3. 结构化语言
    4. 判定表
    5. 判定树

3.2 结构化设计（Structured Design，SD）

  1. 是一种 面向数据流 的方法。
  2. 它以 软件需求规格说明（SRS），系统分析（SA） 阶段所产生的 数据流图（DFD） 和 数据字典（DD） 等文档为基础。
  3. 是一个 自顶向下、逐步求精 和 模块化 的过程。

3.3 软件设计活动

软件设计包括四个既独立又相互联系的活动：

  1. 数据设计：
    1. 把需求分析阶段产出的 数据模型 转化为软件可以实现的 数据结构定义
    2. 质量的数据设计可改善程序结构与模块划分，降低过程复杂性
  2. 架构（体系结构）设计：
    1. 定义软件系统的主要部件（模块或组件等），去明确各个部件之间的关系
    2. 目的是开发一个模块化的程序结构，并表示出模块之间的控制关系
  3. 人机界面（接口）设计：
    1. 定义软件与用户之间的交互关系，包括输入输出方式与交互流程
    2. 包括 软件内部接口、软件与操作系统和硬件或和外部的交互接口、软件和人的接口
    3. 三条黄金规则：
      1. 置用户于控制之下；
      2. 减少用户的记忆负担；
      3. 保持界面一致性。
  4. 过程设计：
    1. 描述 系统结构部件 转化为 具体软件实现 的过程
    2. 核心要 确定每个部件内部的算法逻辑 和 定义部件内部的局部数据结构，为后续的具体编码阶段提供清晰的实现依据

这四个活动完成以后就得到了全面的软件设计模型。

3.4 模块化设计

  1. 模块 是指执行某一特定任务的 数据结构 和 程序代码。是实现功能的基本单位。
  2. 每个模块完成相对独立的特定子功能，与其他模块之间的关系最简单。
  3. 模块接口 是模块与外部进行交互的部分，属于模块的外部特性。
  4. 功能定义 也应当对外部可见，以便其他模块调用。
  5. 三个基本属性：功能、逻辑、状态。
  6. 模块四要素：输入和输出、处理功能、内部数据、程序代码。
  7. 模块设计的重要原则是 高内聚、低耦合
  8. 模块划分原则
    1. 模块大小适中
    2. 模块扇入扇出合理
    3. 深度和宽度适当
    4. 信息隐蔽

4. 耦合

  1. 耦合表示模块之间联系的程度。
  2. 从低到高：（非鼠标控制外公嘞）
    1. 非直接耦合（最低 ⬇️）：两个模块之间没有直接关系，它们之间的联系完全是通过主模块的控制和调用来实现的
    2. 数据耦合：一组模块借助参数表传递简单数据值
    3. 标记耦合：一组模块通过参数表传递记录信息（是指数据结构）
    4. 控制耦合：模块之间传递的信息中包含用于控制模块内部逻辑的信息
    5. 通信耦合（外部耦合）：一组模块都访问同一全局简单变量而不是同一全局数据结构，而且不是通过参数表传递该全局变量的信息
    6. 公共耦合：多个模块都访问同一个公共数据环境，公共的数据环境可以是全局数据结构、共享的通信区、内存的公共覆盖区等
    7. 内容耦合（最高 ⬆️）：一个模块直接访问另一个模块的内部数据；一个模块不通过正常入口转到另一个模块的内部；两个模块有一部分程序代码重叠；一个模块有多个入口

5. 内聚

  1. 内聚表示模块内部各代码成分之间联系的紧密程度。
  2. 从高到低：（公孙铜锅涮罗欧）
    1. 功能内聚（最高 ⬆️）：完成一个单一功能，各个部分协同工作，缺一不可
    2. 顺序内聚：处理元素相关，而且必须顺序执行（存在数据传递和依赖关系）
    3. 通信内聚：所有处理元素集中在一个数据结构的区域上
    4. 过程内聚：处理元素相关，而且必须按特定的次序执行（不存在数据传递和依赖关系）
    5. 时间内聚（瞬时内聚）：所包含的任务必须在同一时间间隔内执行
    6. 逻辑内聚：完成逻辑上相关的一组任务
    7. 偶然内聚（最低）：完成一组没有关系或松散关系的任务

6. 面向对象设计

6.1 基本思想

  1. 抽象：数据结构 和 在数据结构上定义的操作算法 封装在一个对象之中。
  2. 封装：对外只暴露必要的接口，隐藏对象内部的数据与实现细节，防止外部直接访问和修改，从而提高模块的安全性与可维护性。
  3. 可拓展性：通过 继承 和 多态 实现。

6.2 设计类分类

  1. 边界类：封装系统与外部的交互信息（用户界面、外部接口、设备驱动（U 盘、内存条））
  2. 控制类：用于协调、控制用例的执行逻辑，承担完成用例的业务逻辑（按什么顺序调用实体类、边界类等其他类）
  3. 实体类：
    1. 用于映射需求中的实体，存储和表达业务数据，不负责界面与外部交互
    2. 命名规则：采用业务领域术语，一般为名词。
    3. 作用：代表业务领域实际对象，封装一系列涉及到业务领域的逻辑或者数据，处理各种实体的行为

6.3 分析模型

  1. 顶层架构图（宏观）
  2. 用例与用例图（具体的）：用户想要的行为
  3. 领域概念模型：捕捉业务领域的核心对象和它们之间的关系

6.4 设计模型

  1. 以 包图 表示的 软件体系结构图 ：包图是用来组织和分层类及其他模型元素的图形方式
  2. 以 交互图 表示的 用例实现图：展示用例如何由系统内的对象协作完成
  3. 完整精确的 类图
  4. 针对 复杂对象 的 状态图：用于描述对象生命周期中的状态变化
  5. 用以 描述流程化处理过程 的 活动图：用于描述业务或系统内部的流程化处理过程

6.5 继承的分类（从继承中所包含的内容角度出发）

  1. 取代继承：子类继承父类的能力后，用自己的功能 完全取代 父类的实现，强调 覆盖关系。
  2. 包含继承：子类 完整继承父类的全部特性和能力，并进一步 从其他类继承了更多内容，使自身功能 大于等于父类，实现了对父类的 “包含”。
  3. 受限继承：只继承父类部分能力或在继承时进行某些限制或裁剪。
  4. 特化继承：子类对父类进行了 扩展或细化，使其成为父类的 “特例”，但不一定继承全部内容，更多强调 概念上的子集与约束增强。

7. 系统分析与设计中的图

7.1 结构化分析方法中的模型

7.1.1 数据模型

  1. 组成：ER 图

7.1.2 功能模型

  1. 组成：数据流图（DFD）

7.1.3 行为模型

  1. 组成：状态转换图（状态图）

7.2 ER 图

  1. 定义：实体关系图，描述数据实体及其之间的关系

7.3 用例图

  1. 定义：描述角色的一些用例
  2. 用例图之间的三种关系
    1. 包含关系（include）：一个用例无条件的包含另一个用例，主要用于 提取多个用例公共部分
    2. 扩展关系（extend）：一个基本用例在某些条件下可以被另一个用例拓展，用于 处理可选行为
    3. 泛化关系（generalize）：表示多个用例具有相似的行为，可以抽象出一个共同的父用例

7.4 数据流图（DFD，Data Flow Diagram）

  1. 定义：数据流图，展现 整个数据在各个模块中是如何进行流转 的。
  2. 四种基本构件：
    1. 处理/加工（Process）：表示对输入数据的处理、变换，是唯一能够接收处理数据、执行逻辑或计算，并产生新输出数据的元素
    2. 外部实体（External Entity）：表示系统外部与系统交互的对象（如用户或外部系统）
    3. 数据流（Data Flow）：表示数据在构件之间的流动路径，仅用于显示数据的流向
    4. 数据存储（Data Store）：表示系统中数据的静态保存位置
  3. 规则：
    1. 父图必须在子图中出现；
    2. 子图输入输出必须和父图加工输入输出保持一致；
    3. 一个处理至少有一个输入流和一个输出流；
    4. 一个存储必定有流入和流出；
    5. 一个数据流至少有一端是处理端；
    6. 模型表达的信息是全面的、完整的、正确的、一致的；

7.5 对象图

  1. 定义：表示各种各样的对象，描述对象的属性（方法）
  2. 作用：用于展示某一时刻对象及其关系的快照，通常表现为实例化的类和它们的连接

7.6 通信图

  1. 定义：描述各个系统之间是如何通信的
  2. 作用：强调对象间的结构连接与消息传递路径，用于展示为实现某一用例所需的网络式协作关系

7.7 顺序图

  1. 定义：表示对象之间按照时间顺序相互发送消息的一个交互过程，描述各种逻辑判断流程
  2. 特点：按时间轴纵向排列对象生命线，用箭头消息精确描述交互顺序，可嵌套 alt / opt / loop 等片段表达逻辑判断流程

7.8 时序图

  1. 定义：与顺序图同义，侧重时间顺序与消息流
  2. 作用：用于描述对象之间的交互过程和消息流，侧重于对象间 “谁先谁后” 的交互过程

7.9 活动图

  1. 定义：展现这个活动是如何执行的，从活动起点开始
  2. 作用：描述控制流与数据流的动态过程，是动态过程建模，强调控制流

7.10 状态图（状态转换图）

  1. 定义：描述系统或对象的行为随事件变化而发生的状态变更
  2. 定义对象的内部状态以及状态变化规则，用于建模对象的动态行为

7.11 程序流程图

  1. 特点：详细地描述程序内部的逻辑和执行步骤，用于 详细设计 阶段
  2. 作用：用于描述程序执行的控制流程

7.12 模块结构图

  1. 特点：描述系统的模块划分以及模块之间的调用关系
  2. 作用：按层次展示子程序/模块及其调用、数据传递关系，用于总体设计阶段划分系统骨架

7.13 构件图

  1. 定义：描述可部署的软件构件及其依赖、接口，呈现运行时软件装配结构
  2. 作用：用于描述系统的硬件和软件组件的结构

7.14 问题分析图（PAD，problem analysis diagram）

  1. 定义：二维树形图，纵向表示 顺序/选择/循环 结构，横向展开处理细节，支持由分析到代码的平滑过渡
  2. 作用：用于结构化分析与设计

7.15 盒图（N-S 图）

  1. 特点：将程序的逻辑封装在一个盒子里面，通过盒子之间的嵌套顺序展现整体的程序设计，强调 结构化编程，可以让程序的逻辑更加清晰。
  2. 作用：用于 表示模块及其调用关系

7.16 层次图

  1. 特点：在 概要设计 的基础之上，以 分层 的方式展现软件系统的模块结构（调用关系、调用顺序）
  2. 可以理解为 HIPO 图的一部分

7.17 HIPO 图（Hierarchy Input Process Output）

  1. 定义：是结构化设计的分层输入-处理-输出图，用于展示系统分解结构和功能流程
  2. 特点：既展现模块之间的层次关系，又能够细化每一个模块的输入输出和处理过程，能够完整地描述程序结构和模块功能细节。用于 概要设计 阶段
  3. 最详细、最完整的展现结构设计

8. "4+1" 视图模型

8.1 概念

  1. 主要用于 描述系统体系结构。
  2. 多视图的核心思想：
    1. 关注点分离
    2. 将系统分解成多个视图，每个视图聚焦于一个特定关注点，从而降低复杂度并增强可理解性

8.2 分类

与 UML/RUP 中的 “4+1” 的视图模型略有不同，名称不太一样（其实英文名是一样的）

  1. 逻辑视图
    1. 对应 最终用户
    2. 从设计角度描述系统的功能模块，支持 功能性需求，展示 系统应为用户提供的功能和服务
    3. 常用 类图、对象图、状态图、协作图表示
  2. 开发视图
    1. 对应 程序员
    2. 关注软件的模块化结构，通过类图或子系统图 来 描述系统的各部分（代码、包、类）如何被组织为模块和组件，即开发环境中软件的 静态组织结构
    3. 常用 包图、组件图、状态图 表示
  3. 进程视图
    1. 对应 系统集成人员
    2. 考虑非功能性需求，侧重并发和交互过程的设计，反映了系统的 动态结构。
    3. 用于捕捉设计的并发和同步特征，关注 系统运行时的行为，包括并发性、线性模型、任务划分、进程间通信和同步机制等方面的内容
    4. 适用于多线程和分布式系统的分布
    5. 常用 活动图、流程图 表示
  4. 物理视图
    1. 对应 系统工程师
    2. 描述系统的物理部署结构，考虑如何把 软件映射到硬件 上
    3. 常用 部署图 表示
  5. 用例视图（统一的场景）
    1. 描述系统如何满足用户需求
    2. 用于检验这些视图是否完整且一致
系统分析 “4+1” 视图模型
系统分析 “4+1” 视图模型

9. 业务流程分析

  1. 核心：了解业务运作的过程、部门间的关系以及每个业务处理环节的意义，从而为流程优化和系统设计提供依据。
  2. 业务流程建模工具：
    1. DEMO（Design & Engineering Methodology for Organizations）：是一种用于组织建模的方法，更 侧重于企业沟通与协作建模，不是主要用于复杂流程的数学化建模。
    2. Petri 网：是一种重要的数学化建模工具，它能 从流程的角度描述和分析复杂系统。Petri 网由位置（Place）、变迁（Transition）和弧（Arc）构成，既有图形化表示，又有严谨的数学定义，适用于 并发、同步、冲突 等复杂业务流程的建模和分析
    3. BPM（Business Process Management，业务流程管理）：是一种管理理念和方法，旨在 优化企业业务流程。它可以使用多种建模工具，但 BPM 本身并不是一种具体的数学化建模工具。
    4. IDEF（Integration DEFinition）：是一系列建模方法，尤其是 IDEF0 用于功能建模，IDEF3 用于过程描述，主要 适合业务流程的描述和分析，但缺乏 Petri 网那种严格的数学分析能力。
  3. 工作流 用于表示业务过程模型，强调业务活动的顺序、条件、并发与同步等，通常采用图形化符号进行描述。常见的业务流程建模方法包括：
    1. 流程图（Flowchart）
    2. 角色活动图与角色交互图
    3. IDEF0 与 IDEF3
    4. 高级 Petri 网（High-level Petri Net）
    5. UML 活动图（Activity Diagram）
    6. 业务流程建模标注（BPMN）

10. 系统可行性分析

10.1 概念

  1. 可行性分析也称为可行性研究，是所有项目投资、工程建设或重大改革在开始阶段必须进行的一项工作。

10.2 分类

  1. 经济可行性：
    1. 定义：评估项目成本与收益
    2. 分析建设、运行成本及直接间接等多种收益，因系统开发初期难以准确估算，只能大致估量
  2. 技术可行性：
    1. 定义：研究系统功能性能与技术约束
    2. 考量现有技术、资源能否支持项目，需与项目功能、性能和约束定义同步进行，开发阶段调整目标或技术体系会增加成本
  3. 法律可行性：
    1. 定义：从社会因素论证项目现实性
    2. 确保项目不与法律政策抵触，不违规使用技术构件，否则项目不可行
  4. 用户使用可行性（从管理者角度出发）：
    1. 定义：从用户角度评估
    2. 管理可行性：关注领导支持、管理方法科学性等；
    3. 运行可行性：关注系统易用性及对 IT 设施、组织机构等各方面的影响
    4. 领导不支持或运行评估不足易导致项目失败
  5. 进度可行性：
    1. 定义：评估项目期限合理性
    2. 参考经验和类似系统，在资源约束下判断能否按时完成，需区分强制和期望期限

11. 系统建议方案

11. 概念

  1. 系统建议方案：通常是在 系统可行性 研究的基础上形成的文档，用于向 管理层 和 相关利益方 汇报研究结果并提出推荐的系统解决方案。

11.2 内容

  1. 问题陈述：说明为什么需要新系统或改进系统。
  2. 项目范围：明确系统边界与目标。
  3. 候选方案及其可行性分析：比较多个可行的替代方案，说明优缺点与可行性。
  4. 建议方案：提出推荐的解决方案及理由。
  5. 结论与附录：总结与支持性材料。

12. 联合需求计划（JRP，Jiont Requirement Plan）

12.1 概念

  1. JRP 是一种相对来说 成本较高但十分有效 的 需求获取方法，在 JRP 实施之前，应 制定详细的议程，并 严格遵照议程进行。

12.2 目的

  1. 获取需求。
  2. 联合起来讨论需求，面向客户，尽可能使用通俗的语言，尽可能的获取客户的需求。

12.3 角色

  1. 客户代表
  2. 开发团队
  3. 系统分析师
  4. 产品经理

13. COM 重用

  1. 两种形式：
    1. 包含：外部对象拥有指向一个内部对象的唯一引用，外部对象只是把请求转发给内部对象
    2. 聚集：直接把内部对象的接口引用传给外部对象的客户，而不再转发请求

14. 商业智能（BI）

  1. 商业智能系统通常分为四个阶段：
    1. 数据预处理：ETL（抽取、转换、加载），对原始数据进行采集与清洗。
    2. 建立数据仓库：存储、整合来自不同源的数据，是 BI 的核心基础。
    3. 数据分析：通过 联机分析处理（OLAP） 和** 数据挖掘** 技术对数据进行多维度和深层次的分析。
    4. 数据展现：通过报表、仪表盘、可视化工具向用户展示分析结果。
主题美化