简介这是一份关于图书订购与考务系统数据流图设计的PPT教学资料适合软件工程、系统分析与设计课程的学生以及需要绘制分层DFD的开发者使用。内容以考务处理系统为主线从顶层图、0层图到加工内部子图逐步拆解覆盖报名单、成绩清单、合格标准等数据流定义以及考试报名、统计成绩等加工划分同时给出图书订购系统的DFD示例帮助理解源、宿、文件与数据流之间的关系。资源包仅含1个pptx文件共24页大小263KB属于轻量级课件资料目前已有1422人学习。读者可快速掌握顶层DFD、0层图与各层子图的绘制方法、数据流与加工标注规则以及如何用功能分解和业务处理流程识别加工、确定文件和边界数据流适合备考或课程设计时对照参考。1. 图书订购与考务系统数据流图PPT不是画流程是在划系统边界图书订购与考务系统数据流图PPT资料看着像是一套“画图加排版”的活儿实际上它解决的是两个完全不同业务域放进同一套系统后怎么把信息流向讲清楚的问题。数据流图DFD跟业务流程图最大的区别是它只关心“数据从哪来到哪去、经过什么加工、落在哪个存储”不关心谁先点按钮、谁后弹窗口。很多人一上手就把它画成业务时序图这是最大的翻车点。这套资料适合三类人做课程设计或毕业设计需要配套需求文档的同学准备系统答辩但被评审追问数据流向的开发以及要接手图书订购或考务模块却看不懂老代码的人。它的核心价值在于用分层DFD把两个系统的边界、外部交互、加工逻辑一次性理清再组织成能汇报的PPT。2. 上手DFD前先定规则四种符号、分层原则与命名约束数据流图看似自由其实是一套纪律很强的建模语言。很多人画到一半返工不是因为业务复杂而是因为一开始没定符号规范、没定分层粒度。图书订购和考务系统放在一个PPT里等于两张图共用一套规则规则不定清楚后面每张图都要改。2.1 数据流图的四个符号与两种流派怎么选数据流图只有四种基本符号外部实体、加工、数据存储、数据流。外部实体用矩形表示是系统之外但与系统交换数据的角色加工用圆角矩形或圆形表示是对数据做的处理或转换数据存储用开口矩形表示是数据的静态落脚点数据流用带箭头的线表示方向就是数据的移动方向。流派上常见两套一套是 Yourdon/DeMarco 记号加工用圆存储用双横线另一套是 Gane/Sarson 记号加工用圆角矩形存储用开口矩形。国内教材和课程设计里后者更常见因为方方正正画出来容易对齐而且能直接写文字。我一般建议统一用 Gane/Sarson 记号理由只有一个它在 PPT 缩略图上比圆更适合中文排版文字不用绕圈排。定完流派还要定两个全局约定第一数据流线上必须写名字名字必须是名词短语比如“订单信息”“到货通知”不能写“发送”“处理”这种动词短语动词属于加工不属于数据流第二同一个名词在全套 PPT 里只能表达同一个含义比如“订单信息”一旦出现就不要在另一张图里用“订购单”代替同一个东西。2.2 分层结构顶层图、0层图、1层图各放什么内容DFD 的分层是它区别于流程图的核心能力。顶层图也叫上下文图整张图里只有一个加工代表整个图书订购与考务系统外面围着外部实体。这一层回答的问题是“系统的边界在哪里谁在跟系统打交道”。0层图把系统内部按业务域拆成若干加工图书订购和考务两个模块在这里分开。1层图则针对 0 层的某个加工继续细化把它内部的数据处理流程展开。分层的核心原则是“平衡”父图里的一条数据流必须在子图里有对应的入口或出口子图里新增的数据流也必须能在父图里找到来源。这句话听起来简单实操中九成的不一致问题都出在这里。另一个原则是粒度的把控0层加工数量控制在 4 到 7 个超过 7 个说明你把多个业务域塞进了一张图少于 3 个说明你还没拆到位。2.3 加工编号体系与数据字典的同步策略加工编号是分层图的定位系统没有编号评审问你“你那个订单处理内部怎么做的”你根本说不出看哪张图。常见规则是顶层图加工不编号0 层的加工按顺序编为 1、2、3、41 层加工编为 1.1、1.2、1.3依此类推。图书订购模块占 1 号段考务模块占 2 号段两个模块在同一套系统里编号不能重叠。数据字典要跟图同步建不能等图画完了再补。每条数据流、每个数据存储、每个外部实体都建一条记录。数据流记录包含名称、组成、来源、去向数据存储记录包含名称、结构说明外部实体记录包含名称和用途。建数据字典有个实际好处它能逼你把“订单信息包括哪些字段”这种模糊表述落实成“订单号、订购人、ISBN、数量、单价、订购日期”如果这些字段说不出来说明数据流还没想清楚。3. 图书订购模块从顶层图到1层图的逐步推演图书订购业务看起来简单不外乎选书、下订单、收货、付款但它是全校所有师生都在用的高频路径信息流的细节比想象中多。这一章按分层思路把图书订购模块的顶层图、0层图和1层图逐层推演一遍。3.1 顶层图外部实体只有三个边界先立住图书订购模块的顶层图外部实体就三个订购人、供应商、财务经办人。订购人是发起购书请求的师生供应商是提供图书书目的外部书商财务经办人是负责审核付款和发票结算的管理角色。这里最容易犯的错是让供应商既当外部实体又当加工——比如把“书商发货”画在系统内部。记住一条判断标准系统无法控制对方的行为它就是外部实体。顶层图的数据流有六条订购人发出“购书请求”系统返回“书目查询结果”和“订单状态”系统向供应商发出“图书订单”供应商返回“到货通知”和“发票”系统向财务经办人提交“付款申请”财务经办人返回“付款回执”。注意付款申请是系统发出去的不是财务经办人发起的说明资金操作还是由系统触发只是由人工审核。3.2 0层图书目查询、订单处理、验收入库、财务结算四个加工0 层图把图书订购模块拆成四个加工1 书目查询、2 订单处理、3 验收入库、4 财务结算。这 4 个加工之间要画清楚 6 条数据流。加工 1 接收订购人的“查询条件”输出“书目信息”给订购人加工 2 接收订购人选定的“购书请求”校验后输出“图书订单”给供应商加工 3 接收供应商的“到货通知”清点后输出“入库记录”加工 4 接收供应商的“发票”结合入库记录输出“付款申请”。数据存储在 0 层图里要标出四个书目信息存储、订单台账、库存记录、财务凭证。这些存储分别被哪个加工读写是一张图是否专业的关键。书目信息存储由加工 1 读、由加工 3 写因为新书到货录入后查询才能看到新书订单台账由加工 2 写、由加工 4 读结算时要以订单为依据库存记录由加工 3 写财务凭证由加工 4 写。数据流图上每个存储必须同时有“写者”和“读者”否则就是悬空存储。3.3 1层图示例订单处理加工的内部展开拿 0 层图里的加工 2“订单处理”做一次 1 层展开最能说明这套方法的实用价值。加工 2 内部可以拆成 2.1 生成订单、2.2 订单审核、2.3 发送书商三个子加工。订购人发的“购书请求”先进 2.12.1 从书目信息存储读单价和库存生成“待审核订单”写入订单台账2.2 读取待审核订单做合规检查比如单笔金额上限、是否在采购目录内审核通过后把“审核通过订单”传给 2.32.3 把它整理成“图书订单”发给供应商。这里有个容易漏的细节1 层图里外部实体不是必须出现。2.1 接收的数据来自外部实体订购人但在子图里你只需要画一个从来源方向进入加工 2.1 的“购书请求”数据流不需要把订购人矩形再画一遍。很多初学者在子图里重复画外部实体把图画得很乱这个习惯要改掉。子图平衡检查在 1 层图上要过一遍父图加工 2 的入口数据流有“购书请求”出口有“图书订单”子图里2.1 有“购书请求”这个入流2.3 有“图书订单”这个出流两条主线都对应上了。至于审核不通过的情况也要有一条“审核退回”的数据流从 2.2 回到 2.1或者直接回到订购人否则这张图只画了成功路径不完整。4. 考务模块报名、编排、成绩三条主链路的数据流考务模块比图书订购更强调状态流转一场考试从发布通知到成绩发布数据会经过多次写入和校验。这一章不按加工逐个讲而是沿着三条主链路推演考试报名、考场编排、成绩流转。每条链路都有完整的数据流路径画图时按链路检查比按加工检查更容易发现问题。4.1 考务模块的外部实体与顶层图设计考务模块的顶层图外部实体有四个学生、任课教师、教务管理员、教学秘书。学生提交考试报名和查询成绩任课教师录入平时成绩和期末成绩教务管理员负责发布考试安排教学秘书负责审核报名数据和成绩单。注意要把“学生”和“教师”在边界上区分开学生是系统外的纯使用者教师既是使用者又是成绩数据的生产者教师在顶层图里是两条数据线的起点。顶层数据流包括学生发“报名申请”和“成绩查询请求”入系统系统返回“报名回执”和“成绩单”任课教师提交“成绩录入表”教务管理员发布“考试安排通知”教学秘书提交“报名审核意见”。这里有一条容易忽略的规则系统与每个外部实体之间至少有一条入流和一条出流否则这个外部实体就是孤立角色。孤立角色要么删掉要么补上数据流。4.2 0层图考务基础信息、报名管理、考场编排、成绩管理考务模块的 0 层图可以拆成四个加工1 考务基础信息管理、2 考试报名管理、3 考场编排管理、4 成绩管理。加工 1 维护课程信息、考试科目、考试时间表是另外三个加工的数据来源加工 2 处理报名申请和审核意见输出报名汇总名单加工 3 读取报名名单和考场资源生成考场安排表加工 4 接收成绩录入数据经过审核后发布成绩。四个加工之间的数据流是环环相扣的。加工 1 向加工 2 发“可报考试计划”加工 2 向加工 3 发“报名确认名单”加工 3 向加工 4 发“考试实施结果”加工 4 再向加工 1 回流“成绩发布汇总”。这种回路说明考务不是一个单向流程成绩发布后会影响下一次考务计划的基础数据这套逻辑在画图时必须有体现否则数据流图断链读图的人会问“成绩发布完了然后呢”。数据存储在 0 层图里出现五个考试计划存储、报名信息存储、考场安排存储、成绩存储、课程信息存储。考试计划存储由加工 1 写、加工 2 读报名信息存储由加工 2 写、加工 3 读考场安排存储由加工 3 写、加工 4 读成绩存储由加工 4 写和读课程信息存储由加工 1 写、加工 4 读。五个存储中没有悬空存储图才算成立。4.3 手工推演一条成绩数据从录入到发布的完整路径画图前先做一次手工推演是避免漏数据流最有效的土办法。我一般会在纸上写下谁产生数据、经过什么校验、落到哪个存储、谁最终消费它。以成绩为例走一遍完整链路任课教师录入成绩生成“成绩录入表”进入加工 4加工 4 先写入成绩存储同时做一次完整性校验检查是否有缺考标记、是否有超过百分制的异常值校验通过后生成“待发布成绩单”交由教学秘书审核教学秘书返回“审核通过意见”加工 4 再把“正式成绩单”发给学生。推演时会发现一个容易被忽略的细节成绩发布后加工 4 还要向加工 1 发一条“成绩归档数据”用于生成补考计划。这条数据流如果不推演几乎一定漏掉因为业务上它不是主要路径但对系统的完整性很重要。把这条推演路径画进 0 层图评审一眼就能看出你真的理解考务业务而不是在套模板。5. 把DFD做成能汇报的PPT版式、标注与说明页设计图画好只是第一步把图做进 PPT 并让人看懂是图书订购与考务系统数据流图PPT资料里最容易翻车的环节。数据流图的信息密度远比流程图高直接截图放上去评审在投影上是看不清的。这一章讲 PPT 的页面结构、绘制规范和说明页写法。5.1 PPT页面结构一张图配一页说明不堆图完整的 PPT 建议按七页结构组织封面、符号说明页、系统顶层图、图书订购模块 0 层图、图书订购订单处理 1 层图、考务模块 0 层图、数据字典摘要页。如果为了凑篇幅把 0 层图和 1 层图放在同一页投影效果会大打折扣不推荐。每一页技术图都必须是“图为主、文字为辅”图的宽度占页面 70% 以上下方留一行图题。图题写清楚这层图的编号和它对应的父图位置比如“图 3 图书订购模块 0 层图父图图 1 系统顶层图”。这是评审快速定位的逻辑锚点也是答辩时最容易被提问的点。符号说明页很多人不重视但它是整套 PPT 的阅读基础。用表格列四行外部实体、加工、数据存储、数据流每行配符号样式和一句话定义。这里的关键是要用“本项目语境”来解释比如数据存储写“数据的静态存放处如订单台账”不要写教科书上的抽象定义。评审翻到后面看不懂符号时会翻回这一页对照表格做得清楚能省掉很多口舌。5.2 绘制规范统一字体、线型与导出清晰度绘制规范决定了图在 PPT 上的观感。先说字体图内文字统一用无衬线字体数据流名称字号不小于 10 号加工名称不小于 12 号因为投影后字号缩水太小直接看不清。再连线型数据流一律用正交折线不用斜线箭头两条数据流交叉时用拱桥过线或断线让路避免视觉上像两条线连在一起。最重要的一个设置是导出分辨率。用绘图工具导出图片时目标分辨率至少 150 DPI推荐 200 DPI 以上否则贴进 PPT 放大一点就是锯齿。PPT 里不要直接复制嵌入小图再拉大你会得到一张所有数据流名称都糊掉的图。导出格式选 PNG如果能导出 SVG 矢量格式更好PPT 对 SVG 支持已经很成熟放大不模糊。5.3 用“数据字典页”把每个数据流字段化图书订购与考务系统数据流图PPT资料的最后一页建议放数据字典摘要。它不需要列出全量字段只列关键数据流和数据存储的组成控制在十条以内每条包含编号、名称、来源、去向、组成。下面是本套 PPT 中数据分析梳理示例样式编号数据流/存储名称来源去向组成说明D1购书请求订购人订单处理书目号、数量、订购人账号、订购时间D2图书订单订单处理供应商订单号、书目明细、总金额、期望到货日D3成绩录入表任课教师成绩管理课程号、学号、成绩、录入时间D4报名确认名单报名管理考场编排考试场次、学号、姓名、报考科目数据字典页的价值在于别人能把你画的图读成一个明确的数据协议。如果没有这一页图上的箭头虽然画了但“图书订单”里到底传什么只有你自己知道开发对需求会产生多种理解。这一页也是评审最喜欢翻看的内容字段列得准比图本身更能证明你想清楚了每个数据流。6. DFD绘制与汇报中的避坑、翻车点与排查方法数据流图看着简单但评审问倒人的往往都是细节。这一章把最常见的五个坑整理出来每条按现象、原因、解决三段式处理。这些都是我见过大量新建DFD时反复踩的真实问题。6.1 坑1把控制流画进数据流图现象图里出现“打印完成”“审核触发”这类没有数据含义的箭头评审问“这条线上传了什么数据”画图的人答不上来。原因把流程图的思考方式带进了 DFD认为“下一步动作”就是一条流。但在数据流图里动作属于加工内部的事务不属于数据流。解决画每条线之前问自己这条线上传输的具体数据是什么。“打印完成”不携带数据它不是数据流“打印任务”携带了打印内容和打印机标识它才是数据流。把“打印完成”这样的线删掉只在加工内部标注处理逻辑即可。6.2 坑2顶层图边界划错供应商被画进系统内部现象顶层图里出现一个加工叫“供应商发货处理”或者外部实体和加工用双向箭头直接相连导致系统边界模糊。原因系统边界划在哪取决于系统能否控制和约束这个行为。供应商发货是外部行为系统只接收“到货通知”不对发货本身做处理。解决把“供应商发货”整体挪到系统外系统内只保留“验收入库”加工。判断标准很简单加工的动作能不能由系统内部触发如果不能它就不是这个系统的加工。边界划对顶层图的外部实体和加工就自然分离了。6.3 坑3父图与子图不平衡编号对不上现象答辩时评审问“你的 0 层图里订单处理有‘购书请求’和‘图书订单’两条流1 层图里怎么多了一条‘审核退回’”画图的人说“审核退回是内部流”但子图里它确实连到了外部。原因子图内部可以局部细化但出入口必须只保留父图已有的数据流。“审核退回”如果真实存在要么是父图漏画要么它不应该穿过加工的边界。解决先把父图补齐加上“审核退回”数据流再在子图中展开对应路径。每细化一层就对照父图检查一遍出入口数据流集合两者必须完全一致。6.4 坑4PPT 里图模糊到数据流名称看不出来现象PPT 放映时评审问“这个箭头是‘订单信息’还是‘订单明细’”现场放大页面字已经糊成一片。原因粘贴进 PPT 的图片分辨率太低或者图片被拉伸放大导致文字边缘发虚。这是 PPT 汇报最常见的观感翻车比图画错还致命。解决绘图时初始纸张设置成 A4 横向导出 PNG 前把缩放比例调到 200%导出后再放回 PPT 检查一次文字清晰度。有条件就把图导出为 SVG 矢量格式在 PPT 里随意缩放都不糊。6.5 坑5数据存储画了但没人读写现象图里有一个“库存记录存储”但检查所有加工没有一个加工向它写数据也没有一个加工从它读数据。原因为了显得图完整而加存储或者复制其他项目模板时留下的空存储节点。解决逐个检查数据存储必须有至少一个加工写、至少一个加工读。没有读写的存储直接删掉。图书订购模块的库存记录由“验收入库”写、由“订单处理”读这个闭环在图里必须有明确的箭头指向不能只是画个矩形摆在那里。7. 进阶用数据字典校验两套图的一致性画完图书订购和考务模块的图最后一步不是排版而是做一次跨图一致性校验。校验不需要依赖工具用一张检查表就能跑完。做法是把所有数据流和数据存储在 Excel 里列出来每条记录包含编号、名称、父图、层数、来源、去向、组成。然后按固定顺序过四个检查所有数据流编号是否全局唯一同一名称的数据流在不同层图中是否存在但组成不一致每个数据存储是否同时有写者和读者每个外部实体是否至少有一条入流和一条出流。这个检查动作我在项目里执行过无数次超过一半的图都能查出问题。最常见的是同一个名称在不同层图里代表不同内容比如 0 层图里“订单状态”只含订单号和状态码但 1 层图里它突然多了到货日期和折扣信息。这种问题靠眼睛看图根本发现不了必须靠编号查组成才能定位。检查表过完之后把这套校验结果附到 PPT 的最后一页作为数据字典摘要的补充。答辩时如果有人质疑图的完整性你直接指出“我已按四步校验表做过一致性检查所有存储都有读写闭环”评审很难再挑出结构性问题。这个技巧不需要额外工具但能让整套资料的专业度上一个台阶。我自己的习惯是每次画完 DFD 都强制自己关掉图纸等半小时再打开只看编号和数据流名称重推一遍业务链路。推不通的地方一定是图里漏了数据或者边界划错了。这套资料的重心永远是让读图的人一次看懂而不是把图画全。希望这个校验习惯对你有所帮助。本文还有配套的精品资源点击获取 图书订购与考务系统数据流图PPT：DFD分层绘制与避坑指南
简介这是一份关于图书订购与考务系统数据流图设计的PPT教学资料适合软件工程、系统分析与设计课程的学生以及需要绘制分层DFD的开发者使用。内容以考务处理系统为主线从顶层图、0层图到加工内部子图逐步拆解覆盖报名单、成绩清单、合格标准等数据流定义以及考试报名、统计成绩等加工划分同时给出图书订购系统的DFD示例帮助理解源、宿、文件与数据流之间的关系。资源包仅含1个pptx文件共24页大小263KB属于轻量级课件资料目前已有1422人学习。读者可快速掌握顶层DFD、0层图与各层子图的绘制方法、数据流与加工标注规则以及如何用功能分解和业务处理流程识别加工、确定文件和边界数据流适合备考或课程设计时对照参考。1. 图书订购与考务系统数据流图PPT不是画流程是在划系统边界图书订购与考务系统数据流图PPT资料看着像是一套“画图加排版”的活儿实际上它解决的是两个完全不同业务域放进同一套系统后怎么把信息流向讲清楚的问题。数据流图DFD跟业务流程图最大的区别是它只关心“数据从哪来到哪去、经过什么加工、落在哪个存储”不关心谁先点按钮、谁后弹窗口。很多人一上手就把它画成业务时序图这是最大的翻车点。这套资料适合三类人做课程设计或毕业设计需要配套需求文档的同学准备系统答辩但被评审追问数据流向的开发以及要接手图书订购或考务模块却看不懂老代码的人。它的核心价值在于用分层DFD把两个系统的边界、外部交互、加工逻辑一次性理清再组织成能汇报的PPT。2. 上手DFD前先定规则四种符号、分层原则与命名约束数据流图看似自由其实是一套纪律很强的建模语言。很多人画到一半返工不是因为业务复杂而是因为一开始没定符号规范、没定分层粒度。图书订购和考务系统放在一个PPT里等于两张图共用一套规则规则不定清楚后面每张图都要改。2.1 数据流图的四个符号与两种流派怎么选数据流图只有四种基本符号外部实体、加工、数据存储、数据流。外部实体用矩形表示是系统之外但与系统交换数据的角色加工用圆角矩形或圆形表示是对数据做的处理或转换数据存储用开口矩形表示是数据的静态落脚点数据流用带箭头的线表示方向就是数据的移动方向。流派上常见两套一套是 Yourdon/DeMarco 记号加工用圆存储用双横线另一套是 Gane/Sarson 记号加工用圆角矩形存储用开口矩形。国内教材和课程设计里后者更常见因为方方正正画出来容易对齐而且能直接写文字。我一般建议统一用 Gane/Sarson 记号理由只有一个它在 PPT 缩略图上比圆更适合中文排版文字不用绕圈排。定完流派还要定两个全局约定第一数据流线上必须写名字名字必须是名词短语比如“订单信息”“到货通知”不能写“发送”“处理”这种动词短语动词属于加工不属于数据流第二同一个名词在全套 PPT 里只能表达同一个含义比如“订单信息”一旦出现就不要在另一张图里用“订购单”代替同一个东西。2.2 分层结构顶层图、0层图、1层图各放什么内容DFD 的分层是它区别于流程图的核心能力。顶层图也叫上下文图整张图里只有一个加工代表整个图书订购与考务系统外面围着外部实体。这一层回答的问题是“系统的边界在哪里谁在跟系统打交道”。0层图把系统内部按业务域拆成若干加工图书订购和考务两个模块在这里分开。1层图则针对 0 层的某个加工继续细化把它内部的数据处理流程展开。分层的核心原则是“平衡”父图里的一条数据流必须在子图里有对应的入口或出口子图里新增的数据流也必须能在父图里找到来源。这句话听起来简单实操中九成的不一致问题都出在这里。另一个原则是粒度的把控0层加工数量控制在 4 到 7 个超过 7 个说明你把多个业务域塞进了一张图少于 3 个说明你还没拆到位。2.3 加工编号体系与数据字典的同步策略加工编号是分层图的定位系统没有编号评审问你“你那个订单处理内部怎么做的”你根本说不出看哪张图。常见规则是顶层图加工不编号0 层的加工按顺序编为 1、2、3、41 层加工编为 1.1、1.2、1.3依此类推。图书订购模块占 1 号段考务模块占 2 号段两个模块在同一套系统里编号不能重叠。数据字典要跟图同步建不能等图画完了再补。每条数据流、每个数据存储、每个外部实体都建一条记录。数据流记录包含名称、组成、来源、去向数据存储记录包含名称、结构说明外部实体记录包含名称和用途。建数据字典有个实际好处它能逼你把“订单信息包括哪些字段”这种模糊表述落实成“订单号、订购人、ISBN、数量、单价、订购日期”如果这些字段说不出来说明数据流还没想清楚。3. 图书订购模块从顶层图到1层图的逐步推演图书订购业务看起来简单不外乎选书、下订单、收货、付款但它是全校所有师生都在用的高频路径信息流的细节比想象中多。这一章按分层思路把图书订购模块的顶层图、0层图和1层图逐层推演一遍。3.1 顶层图外部实体只有三个边界先立住图书订购模块的顶层图外部实体就三个订购人、供应商、财务经办人。订购人是发起购书请求的师生供应商是提供图书书目的外部书商财务经办人是负责审核付款和发票结算的管理角色。这里最容易犯的错是让供应商既当外部实体又当加工——比如把“书商发货”画在系统内部。记住一条判断标准系统无法控制对方的行为它就是外部实体。顶层图的数据流有六条订购人发出“购书请求”系统返回“书目查询结果”和“订单状态”系统向供应商发出“图书订单”供应商返回“到货通知”和“发票”系统向财务经办人提交“付款申请”财务经办人返回“付款回执”。注意付款申请是系统发出去的不是财务经办人发起的说明资金操作还是由系统触发只是由人工审核。3.2 0层图书目查询、订单处理、验收入库、财务结算四个加工0 层图把图书订购模块拆成四个加工1 书目查询、2 订单处理、3 验收入库、4 财务结算。这 4 个加工之间要画清楚 6 条数据流。加工 1 接收订购人的“查询条件”输出“书目信息”给订购人加工 2 接收订购人选定的“购书请求”校验后输出“图书订单”给供应商加工 3 接收供应商的“到货通知”清点后输出“入库记录”加工 4 接收供应商的“发票”结合入库记录输出“付款申请”。数据存储在 0 层图里要标出四个书目信息存储、订单台账、库存记录、财务凭证。这些存储分别被哪个加工读写是一张图是否专业的关键。书目信息存储由加工 1 读、由加工 3 写因为新书到货录入后查询才能看到新书订单台账由加工 2 写、由加工 4 读结算时要以订单为依据库存记录由加工 3 写财务凭证由加工 4 写。数据流图上每个存储必须同时有“写者”和“读者”否则就是悬空存储。3.3 1层图示例订单处理加工的内部展开拿 0 层图里的加工 2“订单处理”做一次 1 层展开最能说明这套方法的实用价值。加工 2 内部可以拆成 2.1 生成订单、2.2 订单审核、2.3 发送书商三个子加工。订购人发的“购书请求”先进 2.12.1 从书目信息存储读单价和库存生成“待审核订单”写入订单台账2.2 读取待审核订单做合规检查比如单笔金额上限、是否在采购目录内审核通过后把“审核通过订单”传给 2.32.3 把它整理成“图书订单”发给供应商。这里有个容易漏的细节1 层图里外部实体不是必须出现。2.1 接收的数据来自外部实体订购人但在子图里你只需要画一个从来源方向进入加工 2.1 的“购书请求”数据流不需要把订购人矩形再画一遍。很多初学者在子图里重复画外部实体把图画得很乱这个习惯要改掉。子图平衡检查在 1 层图上要过一遍父图加工 2 的入口数据流有“购书请求”出口有“图书订单”子图里2.1 有“购书请求”这个入流2.3 有“图书订单”这个出流两条主线都对应上了。至于审核不通过的情况也要有一条“审核退回”的数据流从 2.2 回到 2.1或者直接回到订购人否则这张图只画了成功路径不完整。4. 考务模块报名、编排、成绩三条主链路的数据流考务模块比图书订购更强调状态流转一场考试从发布通知到成绩发布数据会经过多次写入和校验。这一章不按加工逐个讲而是沿着三条主链路推演考试报名、考场编排、成绩流转。每条链路都有完整的数据流路径画图时按链路检查比按加工检查更容易发现问题。4.1 考务模块的外部实体与顶层图设计考务模块的顶层图外部实体有四个学生、任课教师、教务管理员、教学秘书。学生提交考试报名和查询成绩任课教师录入平时成绩和期末成绩教务管理员负责发布考试安排教学秘书负责审核报名数据和成绩单。注意要把“学生”和“教师”在边界上区分开学生是系统外的纯使用者教师既是使用者又是成绩数据的生产者教师在顶层图里是两条数据线的起点。顶层数据流包括学生发“报名申请”和“成绩查询请求”入系统系统返回“报名回执”和“成绩单”任课教师提交“成绩录入表”教务管理员发布“考试安排通知”教学秘书提交“报名审核意见”。这里有一条容易忽略的规则系统与每个外部实体之间至少有一条入流和一条出流否则这个外部实体就是孤立角色。孤立角色要么删掉要么补上数据流。4.2 0层图考务基础信息、报名管理、考场编排、成绩管理考务模块的 0 层图可以拆成四个加工1 考务基础信息管理、2 考试报名管理、3 考场编排管理、4 成绩管理。加工 1 维护课程信息、考试科目、考试时间表是另外三个加工的数据来源加工 2 处理报名申请和审核意见输出报名汇总名单加工 3 读取报名名单和考场资源生成考场安排表加工 4 接收成绩录入数据经过审核后发布成绩。四个加工之间的数据流是环环相扣的。加工 1 向加工 2 发“可报考试计划”加工 2 向加工 3 发“报名确认名单”加工 3 向加工 4 发“考试实施结果”加工 4 再向加工 1 回流“成绩发布汇总”。这种回路说明考务不是一个单向流程成绩发布后会影响下一次考务计划的基础数据这套逻辑在画图时必须有体现否则数据流图断链读图的人会问“成绩发布完了然后呢”。数据存储在 0 层图里出现五个考试计划存储、报名信息存储、考场安排存储、成绩存储、课程信息存储。考试计划存储由加工 1 写、加工 2 读报名信息存储由加工 2 写、加工 3 读考场安排存储由加工 3 写、加工 4 读成绩存储由加工 4 写和读课程信息存储由加工 1 写、加工 4 读。五个存储中没有悬空存储图才算成立。4.3 手工推演一条成绩数据从录入到发布的完整路径画图前先做一次手工推演是避免漏数据流最有效的土办法。我一般会在纸上写下谁产生数据、经过什么校验、落到哪个存储、谁最终消费它。以成绩为例走一遍完整链路任课教师录入成绩生成“成绩录入表”进入加工 4加工 4 先写入成绩存储同时做一次完整性校验检查是否有缺考标记、是否有超过百分制的异常值校验通过后生成“待发布成绩单”交由教学秘书审核教学秘书返回“审核通过意见”加工 4 再把“正式成绩单”发给学生。推演时会发现一个容易被忽略的细节成绩发布后加工 4 还要向加工 1 发一条“成绩归档数据”用于生成补考计划。这条数据流如果不推演几乎一定漏掉因为业务上它不是主要路径但对系统的完整性很重要。把这条推演路径画进 0 层图评审一眼就能看出你真的理解考务业务而不是在套模板。5. 把DFD做成能汇报的PPT版式、标注与说明页设计图画好只是第一步把图做进 PPT 并让人看懂是图书订购与考务系统数据流图PPT资料里最容易翻车的环节。数据流图的信息密度远比流程图高直接截图放上去评审在投影上是看不清的。这一章讲 PPT 的页面结构、绘制规范和说明页写法。5.1 PPT页面结构一张图配一页说明不堆图完整的 PPT 建议按七页结构组织封面、符号说明页、系统顶层图、图书订购模块 0 层图、图书订购订单处理 1 层图、考务模块 0 层图、数据字典摘要页。如果为了凑篇幅把 0 层图和 1 层图放在同一页投影效果会大打折扣不推荐。每一页技术图都必须是“图为主、文字为辅”图的宽度占页面 70% 以上下方留一行图题。图题写清楚这层图的编号和它对应的父图位置比如“图 3 图书订购模块 0 层图父图图 1 系统顶层图”。这是评审快速定位的逻辑锚点也是答辩时最容易被提问的点。符号说明页很多人不重视但它是整套 PPT 的阅读基础。用表格列四行外部实体、加工、数据存储、数据流每行配符号样式和一句话定义。这里的关键是要用“本项目语境”来解释比如数据存储写“数据的静态存放处如订单台账”不要写教科书上的抽象定义。评审翻到后面看不懂符号时会翻回这一页对照表格做得清楚能省掉很多口舌。5.2 绘制规范统一字体、线型与导出清晰度绘制规范决定了图在 PPT 上的观感。先说字体图内文字统一用无衬线字体数据流名称字号不小于 10 号加工名称不小于 12 号因为投影后字号缩水太小直接看不清。再连线型数据流一律用正交折线不用斜线箭头两条数据流交叉时用拱桥过线或断线让路避免视觉上像两条线连在一起。最重要的一个设置是导出分辨率。用绘图工具导出图片时目标分辨率至少 150 DPI推荐 200 DPI 以上否则贴进 PPT 放大一点就是锯齿。PPT 里不要直接复制嵌入小图再拉大你会得到一张所有数据流名称都糊掉的图。导出格式选 PNG如果能导出 SVG 矢量格式更好PPT 对 SVG 支持已经很成熟放大不模糊。5.3 用“数据字典页”把每个数据流字段化图书订购与考务系统数据流图PPT资料的最后一页建议放数据字典摘要。它不需要列出全量字段只列关键数据流和数据存储的组成控制在十条以内每条包含编号、名称、来源、去向、组成。下面是本套 PPT 中数据分析梳理示例样式编号数据流/存储名称来源去向组成说明D1购书请求订购人订单处理书目号、数量、订购人账号、订购时间D2图书订单订单处理供应商订单号、书目明细、总金额、期望到货日D3成绩录入表任课教师成绩管理课程号、学号、成绩、录入时间D4报名确认名单报名管理考场编排考试场次、学号、姓名、报考科目数据字典页的价值在于别人能把你画的图读成一个明确的数据协议。如果没有这一页图上的箭头虽然画了但“图书订单”里到底传什么只有你自己知道开发对需求会产生多种理解。这一页也是评审最喜欢翻看的内容字段列得准比图本身更能证明你想清楚了每个数据流。6. DFD绘制与汇报中的避坑、翻车点与排查方法数据流图看着简单但评审问倒人的往往都是细节。这一章把最常见的五个坑整理出来每条按现象、原因、解决三段式处理。这些都是我见过大量新建DFD时反复踩的真实问题。6.1 坑1把控制流画进数据流图现象图里出现“打印完成”“审核触发”这类没有数据含义的箭头评审问“这条线上传了什么数据”画图的人答不上来。原因把流程图的思考方式带进了 DFD认为“下一步动作”就是一条流。但在数据流图里动作属于加工内部的事务不属于数据流。解决画每条线之前问自己这条线上传输的具体数据是什么。“打印完成”不携带数据它不是数据流“打印任务”携带了打印内容和打印机标识它才是数据流。把“打印完成”这样的线删掉只在加工内部标注处理逻辑即可。6.2 坑2顶层图边界划错供应商被画进系统内部现象顶层图里出现一个加工叫“供应商发货处理”或者外部实体和加工用双向箭头直接相连导致系统边界模糊。原因系统边界划在哪取决于系统能否控制和约束这个行为。供应商发货是外部行为系统只接收“到货通知”不对发货本身做处理。解决把“供应商发货”整体挪到系统外系统内只保留“验收入库”加工。判断标准很简单加工的动作能不能由系统内部触发如果不能它就不是这个系统的加工。边界划对顶层图的外部实体和加工就自然分离了。6.3 坑3父图与子图不平衡编号对不上现象答辩时评审问“你的 0 层图里订单处理有‘购书请求’和‘图书订单’两条流1 层图里怎么多了一条‘审核退回’”画图的人说“审核退回是内部流”但子图里它确实连到了外部。原因子图内部可以局部细化但出入口必须只保留父图已有的数据流。“审核退回”如果真实存在要么是父图漏画要么它不应该穿过加工的边界。解决先把父图补齐加上“审核退回”数据流再在子图中展开对应路径。每细化一层就对照父图检查一遍出入口数据流集合两者必须完全一致。6.4 坑4PPT 里图模糊到数据流名称看不出来现象PPT 放映时评审问“这个箭头是‘订单信息’还是‘订单明细’”现场放大页面字已经糊成一片。原因粘贴进 PPT 的图片分辨率太低或者图片被拉伸放大导致文字边缘发虚。这是 PPT 汇报最常见的观感翻车比图画错还致命。解决绘图时初始纸张设置成 A4 横向导出 PNG 前把缩放比例调到 200%导出后再放回 PPT 检查一次文字清晰度。有条件就把图导出为 SVG 矢量格式在 PPT 里随意缩放都不糊。6.5 坑5数据存储画了但没人读写现象图里有一个“库存记录存储”但检查所有加工没有一个加工向它写数据也没有一个加工从它读数据。原因为了显得图完整而加存储或者复制其他项目模板时留下的空存储节点。解决逐个检查数据存储必须有至少一个加工写、至少一个加工读。没有读写的存储直接删掉。图书订购模块的库存记录由“验收入库”写、由“订单处理”读这个闭环在图里必须有明确的箭头指向不能只是画个矩形摆在那里。7. 进阶用数据字典校验两套图的一致性画完图书订购和考务模块的图最后一步不是排版而是做一次跨图一致性校验。校验不需要依赖工具用一张检查表就能跑完。做法是把所有数据流和数据存储在 Excel 里列出来每条记录包含编号、名称、父图、层数、来源、去向、组成。然后按固定顺序过四个检查所有数据流编号是否全局唯一同一名称的数据流在不同层图中是否存在但组成不一致每个数据存储是否同时有写者和读者每个外部实体是否至少有一条入流和一条出流。这个检查动作我在项目里执行过无数次超过一半的图都能查出问题。最常见的是同一个名称在不同层图里代表不同内容比如 0 层图里“订单状态”只含订单号和状态码但 1 层图里它突然多了到货日期和折扣信息。这种问题靠眼睛看图根本发现不了必须靠编号查组成才能定位。检查表过完之后把这套校验结果附到 PPT 的最后一页作为数据字典摘要的补充。答辩时如果有人质疑图的完整性你直接指出“我已按四步校验表做过一致性检查所有存储都有读写闭环”评审很难再挑出结构性问题。这个技巧不需要额外工具但能让整套资料的专业度上一个台阶。我自己的习惯是每次画完 DFD 都强制自己关掉图纸等半小时再打开只看编号和数据流名称重推一遍业务链路。推不通的地方一定是图里漏了数据或者边界划错了。这套资料的重心永远是让读图的人一次看懂而不是把图画全。希望这个校验习惯对你有所帮助。本文还有配套的精品资源点击获取