数据流图四条规则详解：符号、分层与校验实践

先交代一下背景：数据流图这个东西，你只要做系统需求分析、软件工程建模相关的事，几乎绕不开。不管是传统的结构化分析（SA方法）还是Yourdon/DeMarco、Gane-Sarson那一套，DFD都是核心交付物。很多人觉得画DFD就是摆几个泡泡和箭头，画得好看就行，结果评审会上被别人问一句“这个数据流哪儿来的？”就答不上来。问题基本出在没吃透一套约束规则上。下面这篇，我就把这套规则掰开揉碎讲清楚，配合实例、易错点、校验方法一起给你。

这套规则，其实是给DFD建模立起来的一组“交通规则”。它约束的不是画图风格，而是图的语义正确性。你在需求阶段用它当草稿，在评审阶段拿它当检查清单，在画到第三层细节的时候可以让你的图不至于崩成蜘蛛网。我建议所有产品经理、业务分析师、软件工程方向的学生，以及刚接触系统设计的开发人员，都先把这套东西背下来再用。

1. 先搞清楚DFD里的四个基本符号

四条规则要落地，你得先认识DFD的建筑材料。所有数据流图，不管画得多复杂，本质上只有四种基本图形元素：外部实体、加工、数据存储和数据流。这个认知很重要，因为在评审现场吵起来的，多半不是逻辑问题，而是有人把“控制命令”画成数据流，或者把“业务角色”直接当成加工。

1.1 外部实体与加工：把“谁跟系统打交道”和“系统做什么”分开

外部实体也叫源点/终点，通常用矩形表示。它代表的是系统边界之外的人、组织或另一个系统。比如图书借阅场景里的读者、图书馆职工，再比如一个电商项目里的支付网关、物流系统，这些都是外部实体。为什么强调“外部”？因为画上下文DFD的时候，你第一步就是把系统边界划清楚，凡是边界外的东西一律进不了加工，只能通过数据流跟加工联系。很多初学者最容易犯的错，就是把角色权限、组织架构画进去，或者把某个部门当成加工来计算，这就把外部实体和系统内部逻辑混在一起了。

加工是真正干事的节点，你用圆角矩形或者圆形表示。加工必须有编号、有名字、有清晰的输入和输出。判断一个节点能不能成为加工，最简单的标准只有一条：它是否把输入数据变成输出数据？比如“读者借书登记”是加工，因为它接收“借书请求”然后输出“借书结果”；而“排队等待叫号”就不是加工，它是过程状态，不该出现在DFD里。

1.2 数据流与数据存储：流的本质是数据在移动，不是控制在流转

数据流用带箭头的线表示，它专门描述数据在元素之间的移动方向。这里有两个非常容易被忽视的坑。

第一，数据流只描述数据，不描述控制流和时间顺序。很多人在DFD里画“点击按钮后页面跳转”，这就错了。“事件”“命令”“触发信号”这类控制信息在DFD里没有合法位置，你得把它们放到流程图、状态图里，而不是DFD里。DFD是“数据的物流图”，它不是“业务的时序图”。

第二，数据流不能凭空出现，也不能消失，它必须连接在加工和加工、或加工与外部实体、或加工与数据存储之间。数据存储，一般用开口矩形或者两条平行线表示，它代表数据的静态停留地，比如数据库表、文件。对数据存储的判断要小心，不是所有中间产物都要画成存储，只有那些“加工之间需要传递数据，但又不是立即通过数据流带走”的场景才需要存储。

1.3 两套主流表示法的差异，别换工具就乱了

你可能会看到不同教材、不同工具里符号略微不同。严格来说，结构化分析领域有两套常见的表示法：一套是Yourdon/DeMarco，加工用圆或椭圆，数据存储用两条横线；另一套是Gane-Sarson，加工用带圆角的矩形，数据存储用开口矩形，数据流的箭头也更方一点。

这两种风格没有本质对错，你选一种，项目里所有图保持一致就行。我见过一些团队画图用Visio自带的模板，结果上下文图用的是Gane-Sarson风格，到了0层图又变成Yourdon风格，评审的时候符号都对不上号，那四条规则再好使也用不起来。标准统一，是一切校验的前提。下面我讲的规则适用于两种风格，你只要把元素概念替换成对应的符号就行了。

2. 四条规则逐条拆解：它们到底在约束什么

如果说前面是认零件，那这一节就是把零件组装起来时必须遵守的规矩。这套规则我从实战角度归纳成四条，很多人叫它“四条规则”，其实就是DFD建模的四大校验准则。每次画完图自己先拿这四条过一遍，再拿给同事评审，你的图会直接上一个档次。

2.1 第一条规则：加工必须有进有出，不允许只有一条腿

最直白的一条：任何一个加工，至少有一个输入数据流，也必须至少有一个输出数据流。这背后的道理很简单，加工的本质是变换，把输入变成输出。如果没有输入却有输出，那数据就是凭空变出来的；如果有输入但没有输出，那数据就被莫名吞掉了，这两件事在物理世界里都说不通。

我在实际评审中，最爱干的事就是先找“只有一条腿”的加工。如果你画了一个加工叫“生成统计报表”，结