数据流图和数据字典是软件设计师下午题的常客，基本年年考、场场不落。很多考生复习到这一块时，总觉得“看得懂、画不出、填不对”，明明几个概念都清楚，一到真题里就丢分。这篇文章我就把这部分拆透了讲，从考试逻辑到答题套路，再到我自己踩过的坑，一次性说清楚。
1. 数据流图在下午题中的定位：为什么它是兵家必争之地
先搞明白一个事实：软件设计师下午考试一共六道大题，通常第一道就是数据流图相关的题目，分值是15分左右。这15分在整张下午卷子里，属于性价比极高的分数。原因很简单——它不考你写代码，不需要你去理解复杂的算法逻辑，它考的是“读图、补图、画图”的能力，只要把规则摸清，拿满分完全有可能。
我当年备考的时候，把近五年的真题翻了个遍，发现数据流图题型的出题模式几乎可以用“模板化”来形容。它的考察核心就围绕两样东西：一是数据流图本身的分层结构，二是数据字典的规范表达。出题人让你做的无非是几件事：给外部实体取个名字、给数据存储取个名字、找出缺失的数据流、补充加工处理的名字，偶尔会考一两道关于数据字典条目是否正确的判断题。翻来覆去，就这么几板斧。
很多考生在复习时有个误区，觉得下午题六道大题，应该把精力放在算法、C语言、Java这些硬骨头上面，数据流图简单看看就行。结果真上了考场，发现这15分拿得并不轻松——原因在于数据流图虽然规则简单，但它特别讲究“细节”和“逻辑一致”。你少补了一条数据流，丢2分；你再把加工名写得不规范，又丢2分；等到整道题下来，15分可能只拿到了七八分。这时候再想靠后面的题目去追分，压力就大了。
所以我的建议非常明确：数据流图这15分，应当作为下午题保分的底线。它不需要你有多深的编程功底，也不需要你背多少复杂的理论，它考察的是缜密的逻辑思维和对系统数据流转的敏感度——这些完全可以通过短时间的强化训练快速提分。
下午题的时间安排其实很紧，150分钟做六道大题，平均每题只有25分钟。数据流图的题目如果掌握了套路，15到20分钟拿满分是可以做到的。省下来的时间分配到后面的算法题和程序设计题上，整个下午的答题节奏就会从容得多。这就是所谓“保底分”的意义所在。
2. 数据流图的核心要素与上下文图的分层之道
既然要拿下这部分分数，首先得把数据流图本身的基本功打牢。很多考生觉得数据流图简单，但一问到“数据流图分几层”“每层之间什么关系”就含糊了。这不怪大家，因为课本上讲的往往偏重理论，而考试需要的偏重应用，两者不是一回事。
2.1 四种基本元素：实体、加工、存储、流的角色
数据流图（DFD）里边就四样东西：外部实体、加工（也叫处理）、数据存储、数据流。按照传统画法，外部实体用矩形表示，加工用圆角矩形或圆圈表示，数据存储用两条横线（开口矩形）表示，数据流用带箭头的线段表示。现在考试题目一般不要求你用符号画图，但你自己理解时这四样东西必须门清。
外部实体就是系统之外的参与者，它给系统提供输入，也接收系统的输出。比如一个“图书馆管理系统”，学生、图书管理员都是外部实体。这里的核心判断标准是：这个对象在系统边界之外，它只负责“递数据”和“收数据”，不参与系统内部的加工处理。
加工就是对数据实施的操作。一个“查询余额”操作就是一个加工，一个“更新库存”也是一个加工。加工是数据流图里最容易出题的地方，因为一个系统里加工的粒度可大可小，完全取决于你在第几层图。上层图里一个粗粒度的“订单处理”，在你往下画一层时，可能会分解成“验证订单”“计算金额”“确认支付”三个子加工。
数据存储是静止的数据。考生最容易混淆的是“数据存储”和“文件”的区别。在数据流图语境里，数据存储就是一个逻辑容器，它不关心数据在物理上存放在哪里，只关心它保存了什么数据、谁在往里面写、谁从里面读。
数据流就是箭头本身，它代表一份数据的流动方向。这里有一个关键考点：数据流上一定要写清楚名字，并且这个名字必须是名词性质的数据，比如“订单信息”“学生名单”，不能是“查询”“更新”这样的动词。数据流的名称是判断数据流是否缺失的重要依据，后面讲答题技巧时会细说。
2.2 上下文图、0层图、子图：三层结构如何衔接
数据流图的分层非常像我们看地图。上下文图好比世界地图，你只能看到各大洲的轮廓，看不到具体的城市；0层图好比国家地图，能看到省会城市和主要公路；子图好比城市交通图，街道、路口一目了然。
上下文图是顶层图，它把整个系统视为一个加工，只画一个大的加工节点，然后用若干外部实体把它围起来，外部实体和系统之间画上数据流。上下文图的作用是划定系统边界——什么在系统内，什么在系统外，对于考生来说，最实用的价值在于补全外部实体。真题第一小问如果问“外部实体A是什么”，基本上都可以在上下文图里通过观察谁在跟系统做数据交换来判断。
0层图是对上下文中那一个大的加工进行分解后得到的图。在0层图中，系统的多个主要功能模块变成了若干个加工节点，外部实体仍然保留，数据存储开始出现。0层图和上下文图之间的对应关系有个铁律：父图和子图的输入输出数据流必须保持一致。也就是说，上下文图中流入系统的数据流，在0层图中必须能找到对应的流出终点的数据流；上下文图中流出系统的数据流，在0层图中也必须能找到对应的起点。这就是著名的“父子图平衡”规则。
再往下就是子图。0层图中的每一个加工，又可以单独展开成一张子图。例如0层图中的“库存管理”加工，展开成一张子图后，内部又包含“入库登记”“出库登记”“库存查询”等更细的加工。子图和0层图之间同样要满足父子平衡。
在这个体系里，最常考的一项技能就是“找缺失的数据流”。题目会给你一张不完整的0层图，让你根据上下文图和题目的文字描述，补出漏掉的那一两条数据流。要补得准，核心就是用好题目里给出的语义描述——题干通常会以处理流程的形式交代数据的流转路径，你把文字转换成图上的箭头，答案自然就出来了。
3. 数据字典：数据流图的“词典”，也是丢分重灾区
很多人在复习数据流图时习惯性地跳过数据字典，认为它不就是一堆定义嘛，背一背就完事了。实际上，数据字典在考试里出现的频率非常高，而且它的出题方式远比想象中灵活。数据字典的核心作用是为数据流图里的每一个数据流、数据存储、加工提供精确的定义说明，简单说，它是数据流图的“配套说明书”。
3.1 四个条目：数据流条目、数据项条目、数据存储条目、加工条目
按照软件工程教材的标准说法，数据字典包含四类条目：数据流条目、数据项条目、数据存储条目、加工条目。每类条目的关注点不一样，考试中考察的方式也各不相同。
数据流条目定义的是数据流的组成。一条数据流“学生选课信息”可能由“学号 + 姓名 + 课程编号 + 选课时间”四个数据项组成。数据流条目的典型写法是：“数据流名：学生选课信息；组成：学号 + 姓名 + 课程编号 + 选课时间；流量：约100份/小时；峰值流量：200份/小时。”
数据项条目是最小的数据组成单位，不可再分。它的描述包括数据项名、数据类型、长度、取值范围等。比如“学号：字符型，长度8，由入学年份 + 学院代码 + 顺序号组成”。这里可能会出判断题，让你判断某个数据项的定义是否有误。
数据存储条目描述的是数据存储的结构和组成，以及它被哪些加工引用。数据存储的组成通常用“数据项集合”的方式来表达，比如“学生表：学号 + 姓名 + 班级 + 联系电话 + 家庭住址”。
加工条目用来说明加工的逻辑，最常见的形式是结构化语言、判定表或判定树。考试中一般不会要求你写一段完整的结构化语言，但可能让你判断一个加工条目描述得是否合理，比如输入是否充分、输出是否完整、处理逻辑是否清晰。
3.2 数据流守恒：数据字典和数据流图的连心桥
数据字典并不是孤立存在的，它和数据流图之间有一条裁不断的纽带——数据流守恒。这个原则说的是，一个加工的输入数据流和输出数据流，在数据内容上必须守恒。也就是说，加工可能对数据做计算、做过滤、做合并，但不可能凭空生产出输入中不存在的核心数据。
举个例子，如果某个加工是“计算员工月薪”，它的输入是“工作时长 + 时薪标准”，那么它的输出应该是“月薪金额”。这里“月薪金额”可以由“工作时长”和“时薪标准”计算得到，数据模型是说得通的。如果题目中这个加工的输出还包含“员工家庭住址”，那就出问题了——“家庭住址”这个数据从哪儿来的？输入流里根本没有。这就违背了数据流守恒。
考试中关于数据字典的题目，往往就是给了你几个数据流图上的元素和数据字典的片段，让你找出不一致的地方。做这种题的方法，就是拿着数据字典的条目，一条一条去对照数据流图上流转的数据流，看有没有哪个加工输出了自己输入中没有的数据，或者有没有哪个数据存储里的数据项是从未在数据字典的任何数据流中出现过的。这种题本质上考的是逻辑验证能力，难度不大，但要求细心。
4. 实操过程：真题场景下的完整推演
说了这么多理论，很多人可能还是有点抽象。下面我用一个非常典型的考试场景，把整个答题过程从头到尾串一遍。这个场景我参考了很多真题的出题思路，不是说它就是某一年原题，而是它覆盖了考试中最常出现的几个考点。
4.1 场景设定：网上书城购物系统
题目描述了这样一个系统：顾客通过浏览器访问网上书城，系统支持注册、登录、浏览图书、查询图书、下单购买等操作。顾客下单后生成订单，系统通知仓库发货，仓库发货后更新订单状态。管理员负责图书信息的上架、下架、库存维护，也可以查询销售统计报表。
题目给了一张0层数据流图，图中已有的外部实体有三个：顾客、仓库、管理员。已有的加工包括：用户管理、图书浏览与查询、订单处理、库存管理、销售统计。已有的数据存储包括：用户表、图书表、订单表、库存表。图中已经画了一部分数据流，但缺失了几条关键的数据流。题目通常有三到四个小问。
第一小问通常是补充外部实体名。这个最简单，上下文图里通常已经标了A、B、C三个代码，让你填具体名字。通过读题干描述，很容易判断：A是顾客，B是仓库，C是管理员。实际上上下文图里会画出数据流的方向，A向系统发请求并且接收系统的响应，是那种“交互型”的外部实体；B接收系统的发货通知，向系统反馈发货结果，属于“上下游协作型”；C做管理维护，是“管理型”。这样的名字基本都不会填错。
第二小问一般是补充数据存储名。题目会给出数据流图中一个代号D1或D2，让你判断它对应的存储是什么。这就需要结合数据流的输入输出判断。比如题干里提到“顾客注册时要将顾客信息保存起来”，图里有一条从“用户管理”加工流出的数据流指向D1，数据流名称是“新顾客信息”，那D1自然就是用户表。
第三小问往往是重点，也是得分拉开差距的地方——补充缺失的数据流。答题思路是回到题干描述里，找到图里还没画出来的动作。比如题干里有一句“顾客查询图书时，系统需要从图书表中读取图书信息”，那就在“图书浏览与查询”加工和“图书表”存储之间添加一条从存储指向加工的数据流，名字是“图书信息”。又比如“订单支付成功后，系统需要更新库存表”，那就在“订单处理”加工和“库存表”存储之间加一条数据流，方向是从加工指向存储，名字是“更新库存量”。像这种根据文字描述来确定缺失数据流的方法，屡试不爽。
第四小问一般会比较灵活，比如给出数据字典中对某个数据流条目或加工的描述，让你判断是否有错，并说明理由。考的还是前面讲的数据流守恒、加工输入输出是否匹配这些点。比如加工“销售统计”的输入如果只有“订单信息”，输出却是“销售报表”和“畅销书排名”，那你就得想想，“畅销书排名”虽然可以基于“订单信息”算出来，但如果题目的数据字典里对“销售报表”的定义里包含了“图书名称、销售数量、销售额”，而这些数据项在输入中都没有明确提供，那就有问题了。这时你就要结合数据字典里数据项的来源来分析，指出加工输入不充分。
4.2 参数计算与答案边界：数据流命名的讲究
在数据流图里，数据流的名字不是随便起的。命名的基本原则，我总结为四个字：“名必达意”。数据流的名字必须准确反映这条流上承载的数据内容。很多考生失分，不是因为找不到数据流，而是因为给数据流起了个似是而非的名字，比如“查询”两个字就画上去。你想想，“查询”是一个动作，不是数据，数据流上应该是“查询条件”和“查询结果”，而不是“查询”本身。
再看数据流的方向。数据流的方向分成三类：从外部实体到加工，也就是输入流；从加工到外部实体，也就是输出流；加工与数据存储之间，有读和写两条方向，从存储到加工是读，从加工到存储是写。考试中最常见的坑，就是方向填反了。比如“系统读取库存表”，那箭头一定要从存储指向加工；如果是“更新库存表”，箭头则是从加工指向存储。
数据流的通道特性也很重要——一条数据流必须是连续传递的，中间不能“凭空消失”。比如有一条数据流标着“从订单处理加工到销售统计加工”，那说明订单处理把订单数据直接传给销售统计。但如果在路径上出现一个数据存储“统计临时表”，那么正确画法应该是订单处理写入统计临时表，然后销售统计从统计临时表读取，而不是中间直接跨过去。考试中的漏画题，往往就是在这些“中转站”上做文章。
为了让大家更有“手感”，我特意把高频率出现的动词和数据流名做了一个对照，类似“答题速查表”，你可以对照着检查自己写的答案是否规范：
| 题干动词 | 数据流方向 | 推荐数据流名称 |
|---|---|---|
| 查询/读取 | 存储 → 加工 | 某某信息 |
| 保存/写入 | 加工 → 存储 | 更新某某信息 / 新某某信息 |
| 提交/发送 | 实体 → 加工 | 某某请求 / 某某申请 |
| 返回/下发 | 加工 → 实体 | 某某结果 / 某某通知 |
| 审核/校验后传给 | 加工 → 加工 | 通过后的某某信息 |
这个表不是标准答案，但它可以帮助你在考场那种紧张的氛围里快速判断一条数据流该怎么命名、方向怎么画。用熟之后，答题正确率会有很明显的提升。
5. 实操过程的完整画法演示：从一个空系统开始
我在备考时养成一个习惯，拿到数据流图题目，先不急着填答案，而是自己先在草稿纸上把题目描述的完整数据流图画一遍。这样做的好处是，你对整个系统会有全局的理解，后面填空时就不容易顾此失彼。下面我完整演示一个简化版系统的画法——就用上文提到的网上书城场景，但精简到最核心的流程。
首先是上下文图。把“网上书城系统”作为一个整体加工放在正中央，三个外部实体围在周围。接下来梳理系统与外部实体的数据交换：
- 顾客：提交注册信息、登录请求、查询条件、订单信息；接收登录结果、图书列表、订单确认信息、支付结果。
- 仓库：接收发货通知单；反馈发货确认。
- 管理员：提交图书信息、库存调整指令；接收销售统计报表。
把这些数据流在外面的大圆上标好，上下文图就画完了。这张图的作用是确定系统的“边界感”，它把系统内部的复杂度全部藏起来了，只留外部交互。
接下来是0层图。用题目给出的五个加工构成系统的骨架。从上下文图流入的数据流会被分配给具体的加工。比如“查询条件”这条数据流，在0层图中，终点应该是“图书浏览与查询”加工；“订单信息”的终点是“订单处理”加工；“入库请求”的终点是“库存管理”加工。同理，流出系统的数据流也要对应到加工上：“图书列表”的起点是“图书浏览与查询”加工，“发货通知单”的起点是“订单处理”加工。
再把数据存储加上。用户注册信息存到用户表，图书信息由管理员维护存到图书表，订单处理过程中会创建订单并存储到订单表，库存管理负责库存表的读写，销售统计从订单表读取数据并生成报表。数据存储与加工之间的数据流，按照“读”和“写”的方向一一补全。
画完这张0层图之后，你要回头检查一遍和上下文图的平衡性。把0层图的所有外部实体边界上的数据流列出来，再和上下文图里的数据流清单做比对——少一条就是漏画了，多一条就是多余的。这个检查动作一定要养成习惯，它虽然不能直接帮你得分，但它能帮你发现很多潜在问题。
我再强调一遍：考试里给的那张图是不完整的，你的任务不是画一整张图，而是“修复”和“补全”这张图。但“修复”的前提是你脑中有完整的图景。如果你自己在草稿纸上能画出完整图，再去填题目空缺，难度会下降一大截。
6. 常见失分点与考场实战策略全解析
数据流图题目的坑就那么几个，我把这些年看到的高频失分点归纳成了一张速查清单，考前拿出来瞄一眼即可：
| 常见问题 | 典型表现 | 对症下药 |
|---|---|---|
| 数据流方向画反 | 把“写入”画成“读取”方向 | 看动词，写→存，读→取 |
| 漏画数据流 | 题干有描述但图上没对应 | 逐句扫描题干，一句一对照 |
| 数据流命名不合法 | 用了动词或短语，如“发送信息” | 改用名词性名称，如“新订单信息” |
| 加工编号对不上 | 子图加工编号与父图不一致 | 父子图之间编号要统一，子加工编号用父加工编号开头 |
| 实体与存储混淆 | 把数据存储错当成外部实体 | 外部实体在系统外，数据存储在系统内 |
| 数据流上无名称 | 光画箭头，不标名字 | 每条数据流必须有名称 |
| 忽略父子平衡 | 子图多了或少了输入输出 | 对比相邻层，边界数据流必须一致 |
| 数据字典种类混淆 | 数据流条目写成数据项条目 | 抓住主要描述对象，组成不同、条目类型不同 |
除此之外，我还想单独讲一下加工编号的问题。数据流图的规范里，0层图中的加工一般用1、2、3来编号，第二层子图中的加工则用1.1、1.2、2.1这种形式来编号。真题中偶尔会给出一个子图，让你判断编号是否正确。这类题难度不大，但恰恰因为简单，很多考生反而容易掉以轻心。看到题目里写“1.3加工”，你得敏感地意识到这是1号加工分解出来的子加工，如果父图里的1号加工是“用户管理”，那1.3就应该是用户管理内部的一个具体功能节点，不能跑到其他加工的逻辑里去。
关于答题顺序，我个人建议是：拿到数据流图的题，先花一两分钟把题干完整读一遍，然后直接做第一小问和第二小问，因为这两问比较简单，属于送分题，稳住心态。第三小问补数据流，花的时间稍长，把题干中的动词部分标出来，一条条核对，宁可多想一步也不要漏答。第四小问如果考的是数据字典的判断题，记住“守恒”和“充分”两个原则，基本就能应付。
考试时数据流图的答题区域比较小，很多考生字写得比较大，结果空间不够。我的做法是先在试卷空白处打草稿，把要填的内容写在草稿上，确认无误后再誊写到答题卡上。注意答题卡上是按空编号的，一定要一一对应，别把“外部实体”写到了“存储”的空格里。这种低级错误每年都有不少考生在犯，丢得非常冤枉。
还有一个很多人忽略的细节：数据流图题目的题干描述往往包含了完整的业务操作流程，这些流程描述不是给你凑字数的，而是出题人故意埋下的信息。每句话几乎都对应着图上的一条数据流或者一个加工。你在读题的时候，建议手上拿一支笔，把动词和名词性的结果都圈出来，比如“提交”“返回”“保存”“读取”“更新”，这些词就直接提示了数据流的方向和名称。
最后再说说时间预算。数据流图部分如果你已经掌握了方法，15到20分钟是合理的时间区间。如果超过20分钟还没做完，说明你在某个小问上卡住了，这时候果断先跳过，去做后面的题目。下午题一共六道，在后面算法题和设计题上多花点时间，收益往往比死磕数据流图里的某一个空要高。等所有题目做完一遍，再回头来补。考试是统筹战，分配时间也是能力的一部分。
数据流图和数据字典这部分，说难也难，说不难也不难。难的是它要求你在短时间内把零散的文字描述转换成规范的数据模型；不难的是它的方法论极其固定，规则就那么多，题目再怎么变也逃不出这个框架。在后面的复习中，我建议你至少把近五年的真题全部做一遍，每做完一套，就把自己错误的地方记录下来，归类到上面的速查表里。几次下来，你会发现错的类型是高度重复的，把这些类型一个一个消灭掉，考试拿满分就不难了。
