109 lines
7.9 KiB
Markdown
109 lines
7.9 KiB
Markdown
---
|
||
title: 数据流图的绘制技巧
|
||
tags:
|
||
- 架构知识
|
||
- 软件设计理论
|
||
- 数据流图
|
||
- 需求分析
|
||
- 需求功能模型
|
||
categories:
|
||
- - 架构知识
|
||
- 软件设计理论
|
||
keywords: '数据流,数据流图,需求,需求分析,功能模型'
|
||
date: 2021-07-02 16:59:28
|
||
---
|
||
|
||
数据流图（Data Flow Diagram，可简写为DFD）是从数据传递和加工的角度，以图形的方式表达系统逻辑功能、数据在系统内部流向和变换过程的一种图示方法，是结构化系统分析方法的主要表达工具，常用来构建和表达软件模型。<!-- more -->数据流图与UML模型、传统流程图不同，数据流图是从数据流传和变换的角度来表示业务的处理流程的，这在进行系统功能需求分析时非常有用，可以快速对功能需求进行建模。
|
||
|
||
数据流图是一个分层的图形，每一层都是上一层的逐步细化。其中顶层数据流图和0层数据流图可以直接作为系统功能需求模型被编入软件规格说明书中。所以如何分析并画好数据流图对需求分析是非常有利的。
|
||
|
||
## 基本图示
|
||
|
||
数据流图一共有四类图例，非常简单也很容易记忆。
|
||
|
||
!!! note ""
|
||
数据流图也使用其他图例，但是除了外部实体、数据加工过程、数据存储和数据流转方向以外，其他的图例并不常用。
|
||
|
||
{% oss_image data-flow-diagram/数据流图图例.svg 数据流图图例 550 %}
|
||
|
||
- **外部实体**是位于系统之外，与系统紧密相关的人或事物，主要表示系统数据的外部来源和去向目标。
|
||
- **数据加工过程**是用来描述输入数据到输出数据之间的变换过程的，换句话说就是输入数据经过什么处理以后就会变成输出数据。
|
||
- **数据存储**是系统中数据保存以后的逻辑称呼，并不是指保存数据的物理介质或者中间件。每个数据存储必须有一个名字。例如订单记录、库存记录。
|
||
- **数据流**，就是数据处理功能的输入和输出，箭头表示数据的流向，箭头上需要标明正在流转的数据的名称。
|
||
|
||
以下是一个0层数据流图的示例。
|
||
|
||
{% oss_image data-flow-diagram/数据流图-示例.svg 0层数据流图示例 650 %}
|
||
|
||
## 如何绘制
|
||
|
||
在绘制数据流图之前，首先要明确一点，数据流图不是流程图，其中只包含数据处理描述，不包含数据处理逻辑。数据流图全程都是在描述业务的输入和输出以及业务的处理动作，不要在其中掺杂进任何逻辑条件、循环处理等。数据流图在绘制过程中其他的注意事项，将会在后面章节中详述。
|
||
|
||
要完成数据流图的绘制，可以按照以下步骤来进行。
|
||
|
||
### 确定系统的输入输出
|
||
|
||
在确定系统的输入和输出之前，应该充分了解以下内容：
|
||
|
||
- 系统从哪些实体接受什么样的数据。
|
||
- 系统向哪些实体送出什么数据。
|
||
|
||
了解了这两点以后，就可以从以下三部分着手绘制顶层数据流图了。
|
||
|
||
- 一个**数据加工过程**，用于标识正在开发的系统。
|
||
- 与系统有关的**全部外部实体**，包括数据的源和终点。
|
||
- 与外部实体相关的系统**主要输入**和**主要输出**数据流。
|
||
|
||
!!! note "顶层数据流图"
|
||
顶层数据流图是一个十分特殊的图，其数据加工过程只有一个，就是系统本身。顶层数据流图表现的是外部实体与系统之间的数据流转关系。顶层数据流图没有编号。
|
||
|
||
以下是一个顶层数据流图的示例。
|
||
|
||
{% oss_image data-flow-diagram/数据流图-顶层图示例.svg 顶层数据流图示例 550 %}
|
||
|
||
### 细化顶层数据流图，构建0层数据流图
|
||
|
||
0层数据流图主要体现系统主主体功能及各项辅助功能与外部接口的情况。0层数据流图的内容实际上主要是系统的框架抽象，一般由四部分组成。
|
||
|
||
- 每个**主体功能**用一个数据加工过程表示。
|
||
- 每个主体功能都需要有相关的**数据输入和输出流**。
|
||
- **外部实体**分别通过输入数据流引发主体功能的执行，并接收执行后的输出结果。
|
||
- **数据存储**用于表示主题功能执行之后产生的需要保留在系统内部的结果数据的去处。
|
||
|
||
在0层数据流图中，每一个数据加工过程都需要用序号标记，这个序号标记将在未来进行分解、记录父子图关系时产生重要的作用。以下是以前一节的顶层数据流图示例细化得到的0层数据流图示例。
|
||
|
||
{% oss_image data-flow-diagram/数据流图-0层图示例.svg 0层数据流图示例 550 %}
|
||
|
||
!!! caution "父图与子图的平衡"
|
||
顶层数据流图与0层数据流图之间可以形成父子图关系，在数据流图中，父子图之间需要保持平衡。这个保持平衡的意思是子图的输入、输出数据流必须与父图相应数据加工过程的输入、输出数据流完全一致。如果父图中的一个输入或输出数据流可以对应子图中多个输入或输出数据流的内容之和，那么父图与子图之间依旧是平衡的。所以父图与子图之间的平衡除了可以使用输入、输出数据流的数量与标记来判断，更重要的是结合数据字典对数据流中的数据项进行判定。
|
||
|
||
### 自顶向下分解，逐层绘制
|
||
|
||
当0层数据流图完成的时候，就可以开始对0层数据流图进行细化了，这个细化过程就是自顶向下分解的过程。不止0层数据流图可以进行细化，如果系统功能比较复杂，那么就可能需要使用更多的层数来对数据流图中的加工过程进行分解，直到数据加工过程已经变得十分简明为止。
|
||
|
||
每一层的数据流图都是对父级图中一个数据加工过程的关注和分解，所以在子图中的数据加工过程一般都会采用`父图加工过程编号.子图加工过程编号`的格式进行编号，例如对1层数据流图中编号为`1.2`的数据加工过程进行分解，那么其2层子图中`1.2`加工过程对应的子加工过程编号就会是`1.2.1`、`1.2.2`等。
|
||
|
||
以下是上一节0层数据流图中名称为`1 加工a`的数据加工过程细化后的1层数据流图示例。请注意观察其中数据加工过程和数据流的编号、命名方式。
|
||
|
||
{% oss_image data-flow-diagram/数据流图-1层图示例.svg 1层数据流图示例 550%}
|
||
|
||
对于数据流图的分解过程中各种过程和元素的识别，可以遵循以下这几个技巧。
|
||
|
||
1. 数据加工过程是系统中数据流**组合**或者是**发生变化**的地方。
|
||
1. 一起到达、一起处理的数据可以看成**一个**数据流。
|
||
1. 需要**暂存**以待未来使用的数据，可以组织成为一个数据存储。
|
||
|
||
## 注意事项
|
||
|
||
数据流图在分解和绘制的时候也是有一定的约束规则的，不能随意绘制。在分解和绘制的过程中，主要需要注意以下几点。
|
||
|
||
1. 数据流图中的**每个**元素都必须有名字，并且命名要合理。
|
||
- 加工过程的名字应该反应整个加工过程的功能，而不是一部分功能，命名习惯一般为**动词+名词短语**。
|
||
- 数据流的名字应该代表**整个数据流**的内容，而不仅仅是它的某些成分，例如“订单”就不是一个合格的数据流名称。数据流名字一般都是**名词**。
|
||
1. 数据流图不是控制流图，只表示系统**做什么**，不反映**如何做**。
|
||
1. 每个加工过程都**至少**有一个输入数据流和一个输出数据流，加工过程不是数据流的终点。
|
||
1. 加工过程需要**按层**进行编号，子图的编号与父图的编号是有关联的。对于这一点在前一节是有阐述的，绘制时必须遵守。
|
||
1. 一个加工过程的输出数据流，**不能**与其输入数据流同名，即便是其内部数据结构完全一致，否则将不能体现数据流的变化。
|
||
1. 子图必须保持和父图的平衡。
|
||
1. 外部实体之间不能存在直接数据流，数据流的起点和终点之间**必须存在至少一个**加工过程。
|