数据流图到底该画什么？只看数据流向

数据流图（DFD）用来回答“数据从哪里来，经过什么处理，最后到哪里去”。它经常出现在需求分析或概要设计章节，适合说明系统的数据边界。它不是流程图，也不是页面操作图；如果你在图里写满“点击新增”“点击保存”，大概率画错了。

流程图关心步骤顺序，数据流图关心数据输入、加工、存储和输出。例如“用户提交选课申请”在流程图里是一个步骤，在数据流图里则要拆成：学生提交申请数据，系统校验培养方案，读取开课计划，写入选课记录，再返回处理结果。

这张图由哪些东西组成

本工具的数据流图由三类节点和一类数据流组成。每条数据流必须写名称，且必须连接到至少一个处理节点。

组件	DSL 写法	图里表达什么
外部实体	外部实体 student: 学生	系统外部的数据来源或去向
处理	处理 validate: 1.1 校验申请	对数据进行加工、判断、转换的过程
数据存储	数据存储 ledger: F1 选课记录表	数据暂存或持久化的位置
数据流	student -> validate: 选课申请	有名称的数据移动路径

也可以用英文类型写法，例如 entity、process、store，但论文里的图建议用中文标签，让评阅者不用反推含义。

后端会检查数据流是否合规

数据流图有几条硬规则：外部实体不能直接连外部实体，数据存储不能直接连数据存储，外部实体和数据存储之间也不能绕过处理节点直接传数据。处理节点必须既有输入也有输出，否则它就不是“处理”。

这些规则能避免常见假图：用户直接写数据库、两个数据库互相传数据、处理过程只有输入没有结果。论文里出现这些图，会让读者怀疑你没有分清系统边界。

一个可用的文本例子

#标题 图表导出数据流图
外部实体 user: 用户
处理 submitExport: 1.1 提交导出请求
处理 renderDocument: 1.2 生成文档文件
处理 returnResult: 1.3 返回下载结果
数据存储 projectStore: F1 项目数据表
数据存储 exportLedger: F2 导出记录表

user -> submitExport: 导出参数
submitExport -> renderDocument: 有效请求
projectStore -> renderDocument: 图表脚本与配置
renderDocument -> exportLedger: 导出记录
renderDocument -> returnResult: 文件信息
returnResult -> user: 下载地址

这张图没有写“点击导出按钮”，因为按钮不是数据。它写的是导出参数、项目数据、文件信息、下载地址这些真正流动的数据。

分层 DFD 要保持输入输出平衡

如果系统比较大，可以先画顶层数据流图，再展开某个处理过程。顶层图只展示外部实体和系统之间的数据交换；子图再解释内部处理如何读写数据存储。

拆子图时要小心：父图里进入某个处理的数据，在子图里应该能找到来源；父图里从该处理输出的数据，在子图里也应该能找到去向。否则就像论文前后对不上。

图后文字按“输入—处理—输出”写

数据流图后最好不要按箭头逐条念，而是概括关键数据：

用户提交导出参数后，系统读取项目数据和图表脚本，由文档生成过程产出文件信息，并将导出结果写入导出记录表。最终系统向用户返回下载地址，相关数据流如图 3-4 所示。

这类文字能把图中的箭头变成需求说明。

定稿前检查

• 外部实体是否真的在系统边界外。
• 每条数据流是否有明确数据名称。
• 处理节点是否既有输入又有输出。
• 数据存储是否和数据库设计章节里的表或存储对象一致。
• 是否把页面按钮、菜单项误写成数据流。