数据流图（Data Flow Diagram，DFD）也称数据流程图或数据流向图，它是一种便于用户理解、分析系统数据流程的图形工具。它摆脱了系统的物理内容，精确地在逻辑上描述系统的功能、输入、输出和数据存储等，是系统逻辑模型的重要组成部分。[1]

数据流图分析法是结构化分析与设计方法（SSADM，Structured Systems Analysis & Design Method）的重要方法之一。分析产生的数据流图，和数据字典等一同构成结构化分析方法的核心输出。

历史

数据流图在 1970 年代后期由计算先驱 Ed Yourdon 和 Larry Constantine的《结构化设计》一书普及开来。他们基于 David Martin 和 Gerald Estrin 的“数据流图”计算模型。结构化设计理念在软件工程领域起飞，DFD方法随之起飞。DFD 表示法借鉴了图论，最初用于运筹学，以对组织中的工作流进行建模。除了Edward Yourdon和Larry Constantine，还有三维促成 DFD 方法论兴起的专家，分别是 Tom DeMarco、Chris Gane 和 Trish Sarson。他们以不同的组合组合在一起，成为数据流程图符号的主要定义者。

后来随着UML的流行，数据流图变得不那么重要了。很大一部分原因是因为UML不使用纯数据流图，UML主要显示软件的控制流，也允许指示数据流。然而，这种控制流和数据流的混合使得在分析和设计新系统时很难专注于基本要素。

优点

取决于其复杂性，数据流程图可以在数小时到数天内创建。相比之下，寻找系统性错误可能需要数周时间，并导致巨大的损失。在系统设计的早期阶段使用纯数据流图，有很多优点：

  • 符号简单，合适与各类人员进行讨论
  • 有助于快速识别出功能需求
  • 更好地识别接口

数据流图易于阅读，支持对软件架构的理解，并使与相关人员的沟通更加容易。可以尽早发现系统中的弱点和错误，优化系统架构、减少的系统缺陷，值得我们学习掌握。

应用场景

数据流图 (下称DFD) 可以表达出任何流程或系统的信息流。数据流图的范围可以从简单的、甚至手绘的过程概述到深入的、多层次的 DFD，这些 DFD 逐渐深入挖掘数据的处理方式。

DFD 通常可以直观地“说出”难以用语言解释的东西，适用于从开发人员到 CEO 的广泛的技术和非技术受众。虽然它们源于软件分析设计，但是能够运用在多种场合。

  • 应用于软件工程

    这是 1970 年代数据流图应用的起点。DFD 可以提供一种专注于技术开发的方法，在这种方法中，预先进行更多研究以进行编码。

  • 应用于需求分析

    用数据流图进行分析，能准确的抽象系统的信息处理过程，概括的描述信息流和当数据从输入移动到输出时被应用的变换，每一层都明确强调“干什么"，“需要什么”，“给出什么”；可以反映出数据的流向和处理过程；更容易发现是否有输入信息或需要输出的信息被遗漏，及早发现系统各部分的逻辑错误；数据流图还有助于消除通常存在于软件开发人员与系统总体及硬件人员的交流隔阂，系统开发人员通过数据流图更容易理解软件要完成什么功能，数据来源于哪里，结果要输出到哪等等，他们可以给软件人员更多合理的建议，由于采用数据流图进行分析，提高分析的可见性和可控性，有助于软件的缺陷在软件开发阶段早期被及时的发现和消除。

  • 应用于系统规模估算

    DFD还可以与ER图结合，在需求分析阶段，先使用实体联系（Entity-Relationship，E-R）图建立数据库概念模型，然后使用数据流图（Data-Flow Diagram，DFD）来描述系统的功能性。使用这种ER图简化的数据流图，可以进行软件功能点估算。

  • 应用于敏捷开发

    DFD 可用于可视化和了解业务和技术要求，并计划下一步。它们可以成为一种简单而强大的沟通和协作工具，以专注于快速开发。

  • 应用于系统安全管理

    系统安全领域的许多标准（如ISO 26262-6、ISO 13849等）建议，应通过数据流分析或验证软件是否安全。因此，可以使用数据流图执行数据流分析，在开发的早期阶段识别安全风险。

  • 应用于业务分析

    业务分析师使用 DFD 分析现有系统并发现效率低下的问题。绘制流程图表可以发现可能遗漏或未完全理解的步骤。

  • 应用于业务流程再造

    DFD 可用于对通过业务流程的更好、更有效的数据流进行建模。BPR 于 1990 年代首创，旨在帮助组织降低运营成本、改善客户服务并更好地在市场中竞争。

制图语言

常见DFD符号集包括：

  • Gane and Sarson
  • Yourdon and De Marco
  • SSADM
  • UML (commonly used to map software architecture, but can be used in DFDs)

虽然符号集的具体图形有所差异，但所有DFD的语言都包含四类内容：

实体（外部实体）：

指存在于软件系统之外的人员或组织，指示出系统所需数据的发源地和系统所产生的数据的归宿地

数据流：

定义信息在所描述的系统中进出和内部的移动，由一组固定成分的数据组成，表示数据的流向

数据存储：

维护或保存信息的地方，通常是数据库或数据库表

流程（或加工、过程）：

转换信息，描述了输入数据流到输出数据流之间的变换，亦即输入数据经过什么处理之后变成了输出数据流。但就像我们在流程建模中看到的那样，语言存在差异，DFD也是一样，不同的 DFD 方法使用不同的符号约定。

例如，在 Gane-Sarson方法中，实体是用直角矩形表示，过程用圆角矩形表示。而在Yourdon-DeMarco方法中，实体是直角矩形，过程是圆形。SSADM 几乎颠倒了Gane-Sarson 的约定。Yourdon-De Marco的数据存储显示为平行线，但其他方法不是。

本质上，数据流图有两种不同类型的符号（Yourdon-Coad、Gane-Sarson），它们为流程、数据存储、数据流和外部实体定义了不同的可视化表示。Yourdon-Coad类型的数据流图通常用于系统分析和设计，而Gane-Sarson 类型的 DFD 更常见于可视化信息系统。

各个符号集之间的差异详见下图：

DFD 分层

从原理上讲，只要纸足够大，一个软件系统的分析模型就可以画在一张纸上。然而，一个复杂的软件系统可能涉及上百个加工和上百个数据流，甚至更多。如果将它们画在一张图上，则会十分复杂，不易阅读，也不易理解。

因此，根据自顶向下逐层分解的思想，可以将数据流图按照层次结构来绘制。

DFD 中使用级别或层来表示有关系统或过程的渐进式详细程度。这些级别包括：

级别 0：也称为“上下文图”，这是最高级别，它仅包含一个流程节点（“流程 0”），它概括了与外部实体相关的整个系统的功能。

  • 所有外部实体以及进出它们的主要数据流都显示在上下文图上。
  • 该图不包含任何数据存储。
  • 上下文图中的进程名称应该是信息系统的名称。例如，评分系统、订单处理系统、注册系统。

级别 1：仍然是系统的相对宽泛的视图，但包含子流程和更多细节。

级别 2：提供更多细节，并根据需要继续分解子流程。

级别 3：虽然这种详细程度并不常见，但复杂系统可以从该级别的表示中受益。

例1：证券交易平台

0级DFD

这个 0 级 DFD 提供了一个证券交易平台示意图。数据从客服助理和经纪人单向流动到平台，客户和平台间双向流动。

1级DFD

此 1 级 DFD 更详细地分解了客户流程，将其扩展到包括帐户创建、现金提取和 最终证券交易。

2级DFD

此 2 级 DFD 分解了订单流程，将下订单所需的步骤置于上下文中— 由客户或经纪人提供。它甚至考虑了一个第三方证券交易所中心，在该中心下订单后会转发交易细节。

例2：学费管理系统

0级DFD

1级DFD

虽然下面的level 1 DFD只有三个流程，但是从流程到外部实体的输入和输入相当多，最终可能在图中出现几条交叉线；为了避免这个问题，我们可以在 DFD 中使用（主视图和辅助视图）同一外部实体的多个视图。

2级DFD

如果一个流程在几个外部实体之间有大量数据流链接，我们可以先将该特定流程和关联的外部实体提取到一个类似于上下文图的单独图表中，然后再将流程细化为单独的 DFD 级别；通过这种方式，您可以更轻松地确保它们之间的一致性。

绘图要求

整体要求

需要规范使用DFD符号集，不要交叉使用多种DFD符号集，如果没有必要，也不应该引入其他图形符号。

在命名时应注意以下问题：

  • 名字应反映整个对象（如数据流、加工），而不是只反映它的某一部分。
  • 避免使用空洞的、含义不清的名字，如“数据”“信息”“处理”“统计”等。
  • 如果发现某个数据流或加工难以命名，往往是DFD分解不当的征兆，此时应考虑重新分解。

画数据流而不是控制流

数据流图强调的是数据流，而不是控制流。在DFD中一般不能明显地看出其执行的次序。区分数据流和控制流的办法，可以简单地回答下列问题：“这条线上是否有数据流过？”，如果有表示是数据流，否则是控制流。

绘图过程

用“系统”的视角看事物

这里的系统可以是狭义上的信息系统，也可以是多个主体及其相互作用组成的广义上的系统。虽然任何系统或过程都可以变成 DFD，但过程越庞杂，图表绘制也将越困难。

识别、分类系统组件

将与此流程相关的所有活动识别出来，标识为外部实体、数据流、加工和数据存储。

  • 明确信息的输入和输出。
  • 找到系统的外部实体。
    一旦找到外部实体，则系统与外部世界的界面就可以确定下来，系统的数据流的源点和终点也就找到了。
  • 找出外部实体的输入数据流和输出数据流。

选择合适的建模语言和工具

使用通用的、标准的语言能够加速理解；使用工具能够提高建模效率，方便存档和分享。

绘制上下文 DFD

从最上层的0级DFD开始，映射所有基本连接和流程。从外部实体的输入流（源）出发，按照系统的逻辑需要，逐步画出一系列逻辑处理过程，直至找到外部实体处理所需的输出流，形成数据流的封闭。

检查

在继续分解绘制下一级别DFD之前，对照DFD的制图要求和常见错误，检查当前层级DFD，确保其准确和完整。如果遗漏某项内容或者逻辑上存在错误，则下一级 DFD 可能没有意义，或者到时候需要大量的调整。

向下分解

将系统内部数据处理又分别看做整体功能，其内部又有信息的处理、传递、存储过程。每个过程（无论大小）都可以重新想象为 0 级上下文图，并且可以重新开始循环。根据需要重复这些步骤以创建所需数量的 DFD，或进一步分解流程以开发 2 级、3 级等 DFD。

根据需要继续分解

重复步骤5、6，如此一级一级地剖析，直到所有处理步骤都很具体为止。

最终检查

最终检查所画的分层DFD，确保准确、完整、平衡、美观。