DFD教程：如何在任何业务系统中建模数据流动

数据流图（DFD）是信息系统可视化的蓝图。与通过语法描述逻辑的代码不同，DFD通过数据的流动来描述逻辑。它描绘了数据如何进入系统，经过各种处理过程，最终以输出或存储的形式离开。本指南全面介绍了如何构建这些图表，而无需依赖专有工具，重点聚焦于系统分析的基本原则。

无论你是为新应用程序定义需求，还是审计现有的遗留系统，理解数据流都至关重要。一个结构良好的DFD能够消除歧义，迫使利益相关者就信息的来源和终止点达成一致。本文档探讨了DFD的构成要素、构建规则，以及将复杂系统分解为可管理视图的方法论。

🧠 理解核心概念

数据流图不是控制流图。它不展示事件的时间或顺序。相反，它关注的是数据本身。将其想象成一个河流系统的地图。你并不关心水流的速度或天气状况，而是关心支流、水库以及河流的入海口。

在建模业务系统时，DFD回答三个核心问题：

• 数据来自何处？（外部实体）
• 数据是如何被改变的？（处理过程）
• 数据保存在何处？（数据存储）

通过回答这些问题，你就能创建出业务的逻辑表示。这种表示不受构建系统所用技术栈的影响，始终有效。它是一种抽象语言，能够弥合业务需求与技术实现之间的差距。

🔑 四个核心组成部分

每个数据流图都是由四个特定符号构成的。尽管不同方法论中的符号表示略有差异，但其基本概念保持一致。掌握这些元素是实现准确建模的基础。

1. 外部实体 🏢

外部实体代表存在于所建模系统边界之外的数据源或目标。它们通常是与主系统交互的人、部门或其他系统。

• 来源： 一位客户提交订单。
• 目的地： 一个税务机关接收报告。
• 系统： 一个外部支付网关。

在图表中，这些通常以方形或矩形表示。它们必须始终与某个处理过程相连；数据不能凭空出现，也不能凭空消失。

2. 处理过程 ⚙️

处理过程将输入数据转换为输出数据。它是系统的引擎。在DFD中，处理过程通常以圆形或圆角矩形表示。处理过程的名称应始终为动词+名词短语，以表明其动作性质。

• 有效： “验证订单”，“计算税款”。
• 无效： “订单”，“税款”。

每个处理过程都必须至少有一个输入和一个输出。如果一个过程有输入但没有输出，那就是“黑洞”；如果有输出但没有输入，那就是“奇迹”。两者都代表建模错误。

3. 数据存储 💾

数据存储表示信息被保存以供后续检索的位置。这可以是数据库、文件系统、实体档案柜或临时缓冲区。与处理过程不同，数据存储不会改变数据，它只是保存数据。

• 示例：客户数据库、库存日志、临时购物车。

它们通常被绘制为开口的矩形或两条平行线。它们通过数据流与过程相连，表示读取或写入操作。

4. 数据流 🔄

数据流是连接各个组件的箭头。它们表示数据在实体、过程和存储之间的流动。箭头头表示流动的方向。

• 标注：每个箭头都必须有一个唯一的标签，用于描述数据包。
• 命名：使用名词，例如“发票”、“登录凭证”或“库存报告”。
• 方向：数据流是单向的。如果数据双向流动，则需绘制两条独立的箭头。

📉 分解的层级

复杂系统无法绘制在单页上。为了管理复杂性，DFD被分解为不同详细程度的层级。这种分层方法使分析人员能够深入或跳出系统架构进行查看。

第0层：上下文图

上下文图是最高层级的视图。它将整个系统表示为一个单一的过程气泡。它展示了系统与外部实体的交互方式。

• 范围：一个中心过程。
• 细节：最少。仅包含输入和输出。
• 目的：用于定义项目的边界。

第1层：功能分解

第1层将上下文图中的单一过程扩展为多个主要子过程。该层级识别系统的主功能区域。

• 范围：最多5到9个过程。
• 细节：展示主要的数据存储和交互。
• 目的：用于概述系统的主模块。

第2层：详细逻辑

第2级聚焦于第1级中的特定流程。它将复杂的函数分解为更小、可执行的步骤。这一级别通常是开发人员查找特定逻辑需求的地方。

• 范围：多个图表，每个主要的第1级流程对应一个。
• 细节：细粒度的数据元素和存储点。
• 目的：用于技术规范和编码。

📐 比较符号风格

系统分析中使用了两种主要的符号表示法。尽管逻辑相同，但视觉表现形式不同。选择合适的符号取决于团队的熟悉程度和组织的标准。

特性	Yourdon & DeMarco	Gane & Sarson
流程形状	圆角矩形	圆角矩形
实体形状	方形	方形
数据存储形状	开口矩形	顶部和底部较粗的开口矩形
数据流形状	曲线箭头	直线箭头
流标签位置	在线条下方	在线上或线下

在Gane & Sarson与Yourdon & DeMarco之间进行选择主要是外观上的差异。然而，保持一致性至关重要。在单一文档中混合使用不同符号会引发混淆，降低文档的清晰度。

🛠 逐步构建指南

构建DFD是一个系统化的过程，需要迭代和验证。遵循以下步骤以确保准确性和完整性。

步骤1：定义系统边界

在绘制任何线条之前，先确定系统内部和外部的内容。这通常由项目的范围决定。任何提供输入或接收输出的内容都是边界条件。

步骤2：识别外部实体

列出所有数据源和目的地。通过访谈利益相关者来确定谁与系统进行交互。不要忘记自动化系统；它们和人类一样也是实体。

步骤3：绘制上下文图

从整体视角开始。将系统画成一个圆泡。用箭头连接外部实体。用标签标明交换的数据。这将成为所有后续图表的基准。

步骤4：分解主过程

将单一圆泡扩展为第1层。识别主要功能。将系统分解为逻辑模块。确保第0层图表的输入和输出与第1层各过程的总输入和输出相匹配。

步骤5：添加数据存储

确定数据必须持久化的位置。如果某个过程需要记住前一次事务的信息，则必须设置数据存储。将这些存储连接到相关的过程。

步骤6：平衡图表

这是一个关键规则。父过程的输入和输出必须等于其子过程输入和输出的总和。如果上下文图显示“订单已接收”，那么第1层图也必须在某处显示“订单已接收”进入系统。

步骤7：审查与优化

浏览整个图表。追踪一条数据从开始到结束的流动过程。其流向是否合理？是否存在孤立的过程？所有数据流是否都已标注？

⚠️ 需要避免的常见陷阱

即使是经验丰富的分析师在构建这些模型时也会犯错。意识到常见错误可以显著节省审查阶段的时间。

• 控制流：不要展示系统事件、触发器或控制信号。DFD展示的是数据，而不是控制。如果需要表示触发器，必须将其作为数据进入过程来表示。
• 混乱的数据流：尽可能避免线条交叉。如果必须交叉，使用“桥接”符号或重新调整布局。清晰性比视觉上的完美更重要。
• 遗漏的数据存储：如果一个过程读取数据，就暗示存在存储。如果一个过程写入数据，也暗示存在存储。不要让这些连接关系隐含不清。
• 幽灵过程：不要创建一个不执行任何操作的过程。每个过程都必须对数据进行转换。
• 实体到实体的直接数据流：数据不能在系统外部的两个外部实体之间直接流动。所有交互都必须通过系统边界。

🔍 逻辑模型与物理模型

区分系统的逻辑视图和物理视图非常重要。逻辑DFD描述的是系统做什么系统所执行的功能。物理DFD描述的是如何系统是如何做到的。

• 逻辑层面：关注业务规则。“验证付款”。不指定软件。
• 物理层面：关注实现。“调用支付API v2”。指定技术。

从逻辑模型开始。不要过早引入技术约束。过早引入技术会限制设计选项，并在分析中造成偏见。逻辑模型获得批准后，可以推导出物理模型以指导开发。

📋 文档编写最佳实践

为确保DFD在整个项目生命周期中保持有用，请遵循这些标准。

• 命名一致性：使用数据字典来统一命名。“客户”在同一张图中不应称为“客户”或“用户”。
• 唯一编号：为每个过程编号。1.0、1.1、1.2。这便于在文档中轻松引用。
• 标签简洁：保持数据流标签简洁。如果标签过长，应在术语表中定义。
• 版本控制：将图表视为代码。它们会变化。要跟踪修订记录，以了解系统是如何演进的。
• 交叉引用：将DFD与其他工件关联。参考实体关系图（ERD）了解数据结构，参考用例图了解用户交互。

💡 视觉思维的价值

为什么要在绘制这些图表上投入时间？文本需求容易被误解。描述一个过程的句子可能有多种解读方式。而图表是视觉且具有空间性的。

当利益相关者看到图表时，能立即发现缺失的数据流。他们能发现数据重复的地方。他们能一眼理解系统的复杂性。这种视觉确认降低了构建错误系统的风险。

此外，DFD是业务团队和技术团队之间的沟通工具。业务分析师用它们来理解需求，开发者用它们来理解架构。通过维护一个共享的工件，组织可以减少信息孤岛，提升协同一致性。

🚀 继续前进

实施数据流图方法需要纪律。仅仅画出线条是不够的，你必须理解数据守恒和分解的规则。随着实践的深入，你会发现这些图表自然地成为你思维过程的延伸。

从小处着手。先建模一个简单的交易。然后扩展到一个部门。最后，建模整个企业。随着每一层级的推进，你对系统的理解也会加深。目标不是画出完美的图，而是创建一个清晰的信息流动地图，以指导构建稳健的软件解决方案。

记住，图表是思考的工具，而不仅仅是一份需要归档的文档。用它来挑战假设、发现漏洞并验证逻辑。在系统设计的领域中，清晰始终是最高形式的精确。

📝 关键原则总结

• 守恒：数据永远不会被创造或消灭，只会被转化。
• 分解：将复杂的系统分解为可管理的子系统。
• 平衡：子图必须与父图的输入和输出相匹配。
• 抽象：将逻辑需求与物理实现分开。
• 清晰：优先考虑可读性，而非美学复杂性。

通过遵循这些原则，您可以确保任何业务系统中的数据流动都得到精确记录，并被项目生命周期中所有相关利益相关者理解。