企业官网建设流程全解析

做过头歌（educoder）软件工程导论实验的人，大概率在“结构化分析方法-数据流图”这一关停过很久。题目给的是一段几百字的需求描述，让你在一个在线画布上拖方框、拉箭头，然后点提交，系统告诉你哪一条数据流不平衡、哪个加工没编号。很多人第一次提交被打回五六次，最后干脆照着别人的截图抄，抄完还是没搞明白为什么要这么画。这篇就把数据流图（DFD，Data Flow Diagram）从头到尾拆一遍：它到底在描述什么、四类元素怎么用、自顶向下逐层分解的每一步怎么落地、educoder 的评测点在什么地方、我踩过的那些坑又是怎么绕过去的。不管你是刚学软件工程导论的大一新生，还是准备课程设计答辩、需要用 DFD 给老师讲清楚系统结构的老油条，下面这些内容都能直接拿去用。

1. 先搞清楚 educoder 这道题到底在考什么

很多同学一上来就急着拖图形，结果画得挺满，提交全是红叉。问题不在手上，而在脑子里没建立“这道题要我输出什么”的模型。头歌的这套实验，本质是让你用一套标准化的图形语言，把一段自然语言的业务描述翻译成计算机和相关人员都能看懂的模型，评测系统查的就是这套翻译是否守规矩。

1.1 结构化分析方法在导论课里的位置

软件工程导论里，结构化分析方法（SA，Structured Analysis）是最早接触的一整套“面向过程”的需求建模手段，它主要由三样东西组成：数据流图、数据字典、加工说明（也叫小说明）。数据流图负责画“系统的数据怎么流动”，数据字典负责解释“图里每个名字是什么意思”，加工说明负责讲“最底层的那个加工具体怎么算”。这三者是配套的，缺一个模型就不完整。

导论课之所以把它放在很靠前的位置，是因为它训练的是“分解”这个能力。一个复杂系统，谁也没法一口气说清楚，那就先画出整个系统和外界的关系，再把系统内部拆成几个大加工，大加工继续往下拆，直到每个加工都简单到能用一段话描述清楚。这个“自顶向下、逐层分解”的思路，后面学面向对象、学架构设计，其实都在反复用，只是换了个壳。

educoder 的实验通常只聚焦在数据流图上，数据字典和加工说明有时作为附加题或客观题出现。所以你要清楚：这一关的主角是图，但图的背后是分解逻辑，评测系统考的是逻辑，图形只是表达形式。

1.2 数据流图不是流程图，别混为一谈

这是我见过最普遍的认知错误。很多人把数据流图画成了程序流程图，用菱形表示判断、用箭头表示“然后执行下一步”，画完自己觉得挺合理，系统判错还一脸懵。这两者的区别，用一句话说就是：数据流图看的是“数据”，流程图看的是“动作的顺序”。

数据流图里没有“先做A再做B”这种时间顺序，也没有判断分支。它回答的问题是：这个数据从哪来、经过哪个加工变成什么、最后存到哪里或者输出给谁。箭头代表的是数据在流动，不是控制权在转移。举个生活化的例子，做菜的流程图是“先洗菜、再切菜、再下锅”，而对应的数据流图是“生菜 + 菜谱 → 加工‘切配’ → 切好的菜”“切好的菜 + 调料 → 加工‘烹饪’ → 成品菜”。前者关注步骤先后，后者关注物料怎么被加工成另一个物料。

所以画 DFD 的时候，你的脑子里不应该有“第一步第二步”，而应该有“有哪些数据、它们在哪些加工之间来回跑”。理解这一点，后面很多奇怪的扣分你就能自己解释清楚了。判断类逻辑（比如“如果库存不足就提示”）在数据流图里是不直接体现的，它藏在加工说明里，最多表现为同一个加工有两条不同的输出流。

1.3 头歌实验的评测逻辑与常见卡点

educoder 这类平台的数据流图实验，评测方式大致分两种：一种是客观题式，给你一张图或一段描述，让你选正确的元素、选正确的分解结果；另一种是作图题，在画布上拖拽图形连线，提交后由后台比对标准答案的结构。

客观题主要考概念，比如“下列哪一项不属于数据流图的元素”“父图和子图之间必须满足什么关系”，这类题错了一般就是概念没记牢，翻回去把四类元素的定义和平衡原则背熟就行。

作图题才是真正的难点。它的判分点通常包括：外部实体有没有画对、加工的层级和编号对不对、数据流有没有遗漏或多余、父子图是否平衡、有没有出现不该有的控制流。后台一般不看你图形摆得好不好看，看的是拓扑结构：有哪些节点、节点之间连了哪些边、边的方向对不对。这就意味着你画的图哪怕歪歪扭扭，只要结构对就能过；反过来，画得再漂亮，多连一条线照样扣分。

我个人的经验是，作图题被打回时，先别急着改图形位置，先对着“平衡原则”和“命名规范”这两条硬规则自查，八成问题都出在这。后面第 5 章会把高频错误整理成速查表，你可以直接拿去当提交前的检查清单。

2. 数据流图的四类元素与命名规范

图形是数据流图的皮，规范是它的骨。这一章把四类元素、命名规则、分层约定这三件事讲透，这是你后面所有操作的基础，也是 educoder 客观题最爱考的地方。

2.1 外部实体、加工、数据存储、数据流各自的图形符号

数据流图只有四种基本元素，但每一种的图形符号在不同的教材和工具里略有差别，头歌的画布一般会固定一套，你要先认清它用的是哪一套。

• 外部实体（外部参与者）：用矩形表示，代表系统之外、和系统有数据交换的人、组织或另一个系统。比如“学生”“教师”“银行系统”。它是数据的源头或终点，不参与系统内部的加工。
• 加工（处理）：用圆角矩形或圆形表示，代表对数据做某种变换。名字必须是动宾结构，比如“审核申请”“计算成绩”。加工可以有编号，用来体现层级，比如 1、2、1.1、1.2。
• 数据存储：用开口矩形（右边不封口）或者两条平行横线表示，代表数据静止存放的地方，比如“学生信息表”“订单库”。注意它存的是数据，不是文件本身。
• 数据流：用带箭头的线表示，代表数据在流动，箭头方向就是数据流向，线上要标数据流的名字，比如“成绩单”“借阅请求”。

这四类元素里，最容易画错的是数据存储。很多人会给数据存储画一个封闭的方框，那就和外部实体撞符号了，评测系统很可能直接判你少了一个外部实体或多了一个。还有一个细节：数据流两端必须是有意义的连接，箭头不能悬空，也不能自己指向自己。

提示：画之前先看画布左侧的图例，头歌不同实验的符号可能有细微差别，按它给的来，不要凭记忆画。

2.2 命名这件事，比画线更容易丢分

我见过太多人图形结构完全正确，就因为名字起得随意被打回。命名规范是数据流图里最容易忽视、又最容易被扣分的部分，值得单独拎出来说。

加工的名字必须是“动词 + 宾语”，这是铁律。“处理”“加工”“操作”“模块”这种词一律不合格，因为它们没有说清楚到底做了什么。正确写法是“录入借书信息”“核对身份”“生成账单”。评测系统里如果带了关键词校验，像“处理数据”这种名字会直接被标记为“加工命名不规范”。

数据流的名字必须是名词或名词短语，代表流动的“东西”。“发送”“输入”“传递”这类动词不能做数据流名，因为它们是动作不是数据。你想表达“学生把借书请求交给系统”，数据流应该叫“借书请求”，而不是“提交请求”。

外部实体和数据存储的名字也有讲究：外部实体用现实中的角色或系统名，数据存储用“××表”“××库”“××文件”这种能看出是存放地的名字。还有一个隐藏规则——同一个名字不能同时出现在两种元素上。你不能既有一个叫“学生”的数据存储，又有一个叫“学生”的外部实体，这样评测系统无法判断你指的是哪一个。

注意：头歌的客观题里常有一道“下列命名哪个是正确的”，选项里往往混着“处理信息”“数据2”“输入”这类干扰项，记住“加工动宾、数据流名词、存储带表/库”这三条就能秒选。

2.3 分层结构：上下文图、0层图、子图的约定

数据流图不是一张图，而是一组图。一个完整的数据流图模型，通常从一张顶层图开始，逐层往下拆。头歌的实验经常让你在“顶层图—0层图—1层图”之间来回切换，所以层级的命名和编号必须搞清楚。

顶层图也叫上下文图（Context Diagram），它把整个系统当成一个加工（有的教材就画一个圆圈，编号 0），外面挂上所有和系统交互的外部实体，以及它们和系统之间的输入输出数据流。顶层图里不出现数据存储，也不出现系统内部的细节，因为这时候系统还是个黑盒。

0层图是对顶层图那个唯一加工的第一次分解。它把系统内部拆成若干主要加工（编号 1、2、3……），同时把顶层图里的输入输出流分配到这些加工上，这时候数据存储开始出现。关键点来了：顶层图的输入输出流，在 0层图里必须全部能找到对应，这就是第一层“父子平衡”。

1层图是对 0层图里某个加工的继续分解。比如 0层图里的加工 2“处理借阅”，在 1层图里可能被拆成 2.1“验证借阅资格”、2.2“登记借出”、2.3“更新库存”。编号用小数点表示层级，2 的子加工就是 2.1、2.2、2.3。继续往下拆就是 2级、3级，编号依次加长。

这套编号规则看着简单，但它直接决定你能不能通过评测。评测系统会检查“父图里编号为 2 的加工，其输入输出流是否和子图边界上的流一一对应”，对不上就是平衡性错误。下一章我会用一个具体案例把平衡校验的实操过程走一遍。

3. 自顶向下逐层分解的完整实操过程

概念讲完了，这一章进入真正动手的环节。我会拿一个经典的“图书借阅管理系统”当例子，把从读需求到画出多层数据流图的每一步都走一遍。你把这套流程套到 educoder 的题目上，基本就是照抄作业。

3.1 从需求描述里抠出外部实体与输入输出流

拿到一段需求描述，第一件事不是画图，而是抄关键词。把描述里出现的“人/角色”“系统”“数据/信息/单据”三类词圈出来，分别对应外部实体、外部系统、数据流。

以图书借阅系统为例，需求描述大概是：“读者向系统提交借书请求，管理员审核读者资格，系统记录借阅信息并更新图书库存，读者归还图书时系统更新库存并生成归还记录，管理员可以查询借阅情况。”读完这段话，你先做三件事：

1. 找出外部实体：读者、管理员。这两个是系统之外的角色。
2. 找出可能的加工：提交借书请求、审核资格、记录借阅、更新库存、生成归还记录、查询借阅情况。
3. 找出数据流：借书请求、资格信息、借阅信息、库存变更、归还记录、查询结果。

这一步不需要你判断对错，先把素材都捞出来。捞得越全，后面画图越不容易漏。我个人的习惯是用一张纸分三列写：实体、加工候选、数据候选，然后用线把“谁产生谁、谁流向谁”连起来，这张草稿就是你画正式数据流图的地基。

实操心得：需求里凡是出现“查询”“统计”“生成××单”的地方，几乎都对应一个或几个数据流；凡是出现“如果/当……时”的地方，往往是加工说明里的逻辑，不要急着在图上画成分支。

3.2 画上下文图（顶层图）的具体步骤与参数

上下文图是整个模型的第一张，也是最容易画的一张，因为它简单到只有“一个加工 + 若干外部实体 + 若干数据流”。但正因为简单，它的数据流最容易被漏。

画上下文图的步骤是这样的：

1. 在画布中间放一个加工，名字就叫“图书借阅管理系统”，编号可以标 0。
2. 在四周放外部实体：左边放“读者”，右边放“管理员”。
3. 把每一条跨越系统边界的数据流画出来。读者这边，进系统的是“借书请求”“归还请求”，出系统的是“借阅结果”“归还回执”。管理员这边，进系统的是“审核结果”“查询条件”，出系统的是“借阅情况”。

这里有一个非常重要的原则：上下文图里，一个外部实体和系统之间的数据流，必须是成对出现的“请求—响应”关系（不一定严格成对，但要有来有往）。如果你只画了“读者→系统”的借书请求，却没画系统回给读者的结果，评测很可能判你缺少输出流。因为一个正常的交互，系统不会只收不回。

数据流的命名在这一层就要定下来，后面 0层图、1层图要沿用这些名字。你如果在上层叫“借书请求”，下层突然改叫“借阅申请”，评测系统会认为这是两条不同的流，平衡检查直接挂掉。所以命名一次定好，全模型统一，这是我踩过的最深的坑之一。

3.3 0层图的分解与父子平衡校验

0层图是重头戏。你要把顶层图里那个大加工拆开，同时保证拆完之后边界上的数据流和顶层图完全一致。

接着图书借阅的例子，我把系统拆成三个主要加工：1“借阅办理”、2“归还办理”、3“借阅管理”。然后分配数据流：

• 加工 1 借阅办理：输入“借书请求”，输出“借阅结果”；需要读“读者信息表”核对资格，写“借阅记录表”。
• 加工 2 归还办理：输入“归还请求”，输出“归还回执”；更新“借阅记录表”和“图书库存表”。
• 加工 3 借阅管理：输入“查询条件”，输出“借阅情况”；读“借阅记录表”。

现在做父子平衡校验，方法是逐条核对顶层图的每一条流：

这张表就是平衡检查的核心工具。只要有一条顶层流在 0层图里找不到“落脚点”，平衡就不成立。反过来说，0层图里也不能凭空多出一条顶层图没有的、跨越系统边界的流。注意“跨越系统边界”这几个字——0层图内部加工之间、加工和数据存储之间的流是可以新增的，那不叫不平衡，那叫分解。

提示：educoder 判平衡时，往往只看“顶层图的外部输入输出流”和“0层图边界流”是否一一对应。你在画的时候，可以把顶层图的流列表贴在旁边，画一条勾一条。

3.4 再往下分解：1层图与数据字典的配合

如果题目要求继续分解，比如把加工 1“借阅办理”拆开，那就进入 1层图。加工 1 在 1层图里变成三个子加工：1.1“验证读者资格”、1.2“登记借出”、1.3“更新库存”。这时候仍然是同样的平衡规则：加工 1 在 0层图里的输入“借书请求”、输出“借阅结果”，以及它和“读者信息表”“借阅记录表”之间的流，都要在 1层图的边界上原样出现。

这里会出现一个新手常犯的错误：把 0层图里加工 1 与数据存储之间的流，在 1层图里“重新分配”给了某个子加工，而不是让子加工去读写数据存储。这在某些情况下是可以的，但前提是 0层图里那条流本身就要体现在 1层图的边界上，或者能被合理的内部流替代。判断标准还是那句话：看父图的边界流有没有在子图里落实。

数据字典在这一步开始发挥作用。图上出现了“读者信息表”“借阅记录表”“图书库存表”这些数据存储，数据字典就要给出每个存储的数据项组成，比如“读者信息表 = 读者编号 + 姓名 + 学号 + 借阅权限”。数据流也可以进数据字典，比如“借书请求 = 读者编号 + 图书编号 + 请求时间”。educoder 的数据字典题一般是客观题形式，给你定义让你判断正误，或者让你补全某个条目。

数据字典的符号约定要记牢，考频很高：

• =表示“定义为”，如借书请求 = 读者编号 + 图书编号
• +表示“与”，即各项都出现
• [ | ]表示“或”，在括号内选一个，如状态 = [已借 | 可借]
• { }表示“重复”，如借阅列表 = { 借阅记录 }
• ( )表示“可选”，如备注 = ( 说明 )

把这几个符号背熟，数据字典的客观题基本就是送分。而它对作图题的帮助在于：当你拿不准某条数据流该包含哪些内容时，翻一翻数据字典，往往能反推出这条流应该连到哪个加工或存储上，这个技巧我在第 6 章还会细讲。

4. educoder 平台上机实操：一次完整的答题记录

纸上谈兵结束，这一章还原一次真实的上机过程。我把读题、画图、自查、提交、被打回、再改的整条链路都记下来，你可以对着自己的操作比对，看是哪一步出了问题。

4.1 题目读法与打分点拆解

头歌的作图题一般会给你三段东西：任务描述（一段业务需求）、任务要求（明确要画到第几层、有几个加工）、评测说明（告诉你判分点）。很多人只读第一段就开始画，这是大忌，后两段才是决定你能不能过的关键。

任务描述负责给素材，任务要求负责划范围。比如要求里写“请画出该系统的 0层数据流图，加工数量不超过 5 个”，那你就老老实实拆 3 到 5 个加工，别硬拆成 8 个，拆多了不合规，拆少了覆盖不全。评测说明里如果写“检查父子平衡、检查元素类型、检查命名规范”，那你提交前就按这三项逐一过一遍。

我的做法是把任务要求抄在便签上，画的时候随时瞄一眼。特别是“画到第几层”这一条，很多人画了 1层图但题目只要 0层图，结果多画的部分反而被判为结构错误。范围意识比画图技巧更重要。

4.2 画布操作与提交前的自查清单

头歌的画布操作和大多数在线绘图工具差不多：左侧图例拖图形，选中元素可以改名，拖动端口连线，线上可以加标注。几个操作层面的坑要提醒一下。

第一，连线时注意端口吸附。你看着是连上了，实际可能只连了个“边框”没吸附到端点，提交后系统识别成悬空线。连完一条就拖一下图元，看线是不是跟着走，跟着走才是真连上。

第二，改名字要改对元素。有时候你双击的是线，改的却是名字标注，结果元素本身还叫“矩形1”。提交前挨个点一遍所有图元，确认名字都改过了。

第三，层级编号别偷懒。加工不写编号，评测无法判断层级关系，很可能直接判结构缺失。我一般画完先给加工编号，再连线，这样心里始终有张层级表。

提交前我固定跑一遍自查清单：外部实体是否都是矩形、加工是否都有动宾名字和编号、数据存储是否都是开口矩形、数据流是否有名字和方向、父子图的边界流是否一一对应、有没有多余的悬空线。这六条查完再点提交，通过率能高一大截。

4.3 一个具体案例：教务选课系统的 DFD 落地

光说图书借阅可能不够，我换个案例——教务选课系统，把 0层图的完整落地过程再走一遍，你可以拿它当模板。

需求：学生选课、退课，教师录入成绩，教务员维护课程信息，学生和教师都能查询课表。先抠元素：外部实体是学生、教师、教务员；数据存储候选有课程表、选课记录表、成绩表、课表；加工候选有选课处理、退课处理、成绩录入、课程维护、课表查询。

接着拆 0层图的加工，我拆成四个：1“选课与退课”、2“成绩录入”、3“课程信息维护”、4“课表查询”。然后分配流：

• 加工 1：输入学生的“选课请求”“退课请求”，输出“选课结果”“退课回执”；读写“选课记录表”，读“课程表”判断容量。
• 加工 2：输入教师的“成绩数据”，输出“录入确认”；写“成绩表”。
• 加工 3：输入教务员的“课程信息”，输出“维护结果”；读写“课程表”。
• 加工 4：输入学生/教师的“查询条件”，输出“课表”；读“选课记录表”“课程表”“成绩表”。

画完再回顶层图核对：顶层图里学生进系统的是“选课请求/退课请求/查询条件”，出系统的是“选课结果/退课回执/课表”；教师进的是“成绩数据/查询条件”，出的是“录入确认/课表”；教务员进的是“课程信息”，出的是“维护结果”。逐条比对 0层图，全部能找到对应，平衡成立。

这个案例里有个细节特别容易被评测挑出来：加工 1 同时处理选课和退课，读写了“课程表”和“选课记录表”，那这两条读写流在图上必须画全。有人只画了“选课记录表”忘了“课程表”，认为课程表是加工 3 管的，跟加工 1 没关系。但只要加工 1 需要判断课程容量，它就必须读课程表，这条流不能省。判断某条流该不该画的标准，不是“这个数据归谁管”，而是“这个加工有没有用到它”。

5. 常见问题与排查技巧实录

前四章是正向流程，这一章讲反向排查。我在头歌上被打回的那些次，问题基本集中在下面这几类，整理成可查的清单，你遇到红叉时直接对号入座。

5.1 平衡性错误的排查方法

平衡性错误是数据流图里出现频率最高的判错项，也是最难看出来的。因为它不是说某条线画错了，而是说两张图之间对不上。排查方法我总结成一句口诀：先看边界，再看方向，最后看名字。

先看边界。把顶层图所有跨越系统边界的流列出来，再列 0层图所有边界流，两边数量必须一致。多了少了都是错。

再看方向。同一条流，在顶层图里是“读者→系统”，在 0层图里却变成了“系统→读者”，这就是方向错误。方向错比数量错更隐蔽，因为你肉眼扫过去流是有的，只有逐个比方向才能发现。

最后看名字。前面提过，同一条流在两层图里必须同名。有人上层叫“借书请求”，下层叫“借阅申请”，系统判定这是两条不同的流，于是同时报“缺少借书请求”和“多出借阅申请”。这种错最冤，但只要养成“命名一次定死”的习惯就能避免。

实操心得：我在画 0层图之前，会把顶层图的流复制到一个临时文本框里，画完一条划掉一条，全划完再检查有没有剩余，这个方法几乎能杜绝平衡性错误。

5.2 黑洞、奇迹、灰洞的识别

这三个词听起来玄乎，其实是数据流图里对“加工”的三种典型缺陷的俗称，educoder 的客观题特别爱考。

• 黑洞：只有输入没有输出的加工。数据进去了，出不来，好像被黑洞吞了。比如“审核申请”只接了“申请单”却没有输出“审核结果”，这就是黑洞。任何加工都应该有输出，否则它存在的意义是什么？
• 奇迹：只有输出没有输入的加工。数据凭空产生，不科学。比如“生成账单”没有任何输入却直接输出账单，那账单的数据从哪来？这类加工要么缺了输入流，要么应该直接连到某个数据存储作为来源。
• 灰洞：有输入也有输出，但输出无法由输入推导出来，相当于偷偷加了料。比如“计算总价”输入是“单价”，输出却是“总价”，中间少了“数量”这个输入，输出对不上输入，就是灰洞。

识别这三类缺陷的方法很机械：对每个加工，检查它的输入流能不能推出它的输出流。推不出来就找问题。我考试时习惯给每个加工画一个“输入集”和“输出集”，两边比一比，黑洞和灰洞基本一眼看穿。

5.3 命名与符号类错误的速查表

命名和符号错误属于“低级但高频”，整理成表最省事。下面这张表可以直接当提交前的检查清单用。

这张表里我划重点的是最后一条。很多同学在其他课程里画惯了流程图，一画 DFD 就手痒加上判断分支，结果被扣分还觉得自己画得更详细。记住，数据流图表达的是数据变换，不是流程控制，判断逻辑归加工说明管。

6. 一些更省力的做法与经验总结

前面讲的都是“怎么把图做对”，这一章聊点“怎么做得更快”。这些技巧不是标准答案，是我自己摸索出来的，用熟了能省下不少重复劳动。

6.1 用数据字典反推数据流

当你卡在“这条流到底该连到哪”的时候，翻数据字典往往比盯着图看更有效。因为数据字典里定义了每个数据项的组成，而数据流的组成决定了它必须从哪里来、到哪里去。

举个例子，你有一条流叫“借阅记录”，数据字典里写“借阅记录 = 读者编号 + 图书编号 + 借出日期 + 应还日期”。那么这条流的产生，必然需要一个能拿到“读者编号”“图书编号”“日期”的加工——“登记借出”正好满足。而它的去向，要么是数据存储“借阅记录表”，要么是输出给某个查询加工。顺着数据字典往回推，流的上下游就清楚了。

这个方法的本质是：数据流的名字不是随便起的，它背后有确定的字段组成，字段决定来源和去向。educoder 如果同时考了数据字典题，那它其实是在给你提示，你可以拿字典的定义去校验自己的图。

提示：如果题目没给数据字典，你可以自己简单列一份，哪怕不写进答案，也能帮你理清哪些流是必要的、哪些是多余的。

6.2 从手工练习到上机一次性通过

最后分享几个我在练习阶段总结的习惯，适合准备考试或者刷头歌关卡的同学。

第一，先用纸笔把顶层图和 0层图画出来，再上机。纸上改起来快，画错了划掉重来就行；上机改图要拖来拖去，效率低还容易把已经连好的线弄乱。我一般纸上定稿，上机照着摆，基本一次成型。

第二，给每个加工作一份“输入输出小卡”。就是每个加工写一行：输入有哪些流、输出有哪些流、读写了哪些存储。全部写完，再统一连图。这样能保证没有黑洞和灰洞，也不会漏掉读写流。

第三，练手时别只练一个系统。图书借阅、教务选课、银行取款、医院挂号、外卖下单，这几个是软件工程导论里的经典案例，翻来覆去就是那几种结构。把其中两三个画熟，再遇到新题目你会发现套路是相通的：先找实体、再定分层、最后填流。真正变化的是业务名，不变的是分解逻辑和那几条平衡规则。

第四，善用课程设计的机会。不少同学做毕设或课设时也要画 DFD，那时候需求是自己写的，更容易画歪。你可以反过来练：先把自己系统的数据字典列出来，再根据字典反推数据流图，最后拿平衡原则验一遍。这套流程走顺了，导论课的实验和后面的课设就能一次性打通，不用学两遍。

我自己在这门课里最大的体会是，数据流图这东西，技巧占三成，规范占七成。画得漂亮没用，守规矩才有分。把四类元素的符号、命名规则、分层编号、父子平衡这四件事刻进肌肉记忆，剩下的就是拿案例多练几遍，练到看见一段需求就能条件反射地拆出实体和加工，这一关就真的过了。