★ FEATURED ARTICLE 简介围绕图书订购与考务系统数据流图设计提供了一套二十四页PPT教学资料从顶层DFD、一层DFD到二层DFD逐级拆解覆盖学生注册课程系统、图书订购系统、资格和水平考试考务处理系统三大案例详细讲解加工、数据流、文件、源与宿的确定方法以及顶层图与零层图的绘制思路。针对考务处理系统梳理了报名单核验、准考证生成、成绩清单检查、合格者审定与统计分析等数据流转过程针对图书订购系统说明了订购单、库存入库单、发书单等关键数据流走向。幻灯片中还给出了数据流图通用绘制步骤例如先确定系统边界与输入输出再按业务流识别加工对复杂加工继续分层细化最终形成完整分层DFD。包体内共一个PPT文件压缩包仅二百六十三KB结构清晰适合软件工程、系统分析与设计课程学习也可作为毕业设计或项目文档中数据流图绘制的参考资料已有1422人学习浏览对需要快速掌握分层DFD方法的开发者具有较高参考价值。1. 图书订购与考务系统数据流图先把这张图的定位搞清楚图书订购与考务系统数据流图PPT资料.pptx这类文件名在课程设计、系统分析和毕设里出现频率很高。它不是程序代码也不是数据库脚本而是用来向评审讲清楚这个系统到底怎么处理数据的成套材料其中数据流图DFD是整套资料的核心。数据流图回答三个问题数据从哪来、经过哪些加工、最终落到哪。图书订购与考务系统恰好有两条业务主线——一条是学生订书、供应商发货、入库发放另一条是考试安排、报名、成绩发布。两条线交织在一张图里分层和命名稍不严谨PPT翻到第三页评审就开始皱眉。适合读这篇的人有两类一类是正在做教材订购、考务管理类系统设计的同学需要画一套能直接交差的DFD并排成PPT另一类是工作中要写系统分析文档、把业务流转讲给非技术同事听的工程师。下面按先立图元、再分层、后装PPT、最后自查的顺序讲。默认你已有系统设想这里只讲怎么把它画成评审挑不出硬伤的样子。先给一个反直觉的结论数据流图不是流程图。它不画判断分支、不画循环、不画按钮点击只画数据在系统里的流动与变换。很多人交上去的数据流图其实是程序流程图换了个皮这恰恰是最常见的翻车原因。2. 先立四类图元再画顶层图图书订购与考务系统的边界从哪定画DFD的第一步不是打开绘图工具而是先列外部实体清单。边界不定义清楚后面所有分层都会返工。我拿到这类资料习惯是先问自己一句这个系统对谁提供服务、从谁那里拿数据答案就是边界。2.1 四类图元与识别规则外部实体、加工、数据存储、数据流数据流图一共只有四类图元任何一张合格的DFD里不会出现第五种。识别规则如下图元常见画法命名要求本系统示例外部实体矩形写具体角色禁止写用户学生、教师、图书供应商加工圆角矩形或圆形动词宾语校验订购申请、生成采购订单数据存储开口矩形右开口名词不带表字订购单、图书库存、成绩数据流带箭头的实线名词短语不写动词订购申请、发货单、成绩查询请求外部实体是系统之外、但和系统交换数据的角色。图书订购与考务系统里学生提交订购申请和考试报名教师录入成绩和提出考试计划图书供应商接收采购订单、返回发货单这三方是天然的实体。注意管理员一般不画成外部实体。如果系统本身就包含管理功能管理操作应该体现为加工而不是从图外伸进来一只管理员的手。加工是对流入数据的变换它必须有输入也有输出。数据存储是静止状态的数据集合用名词命名就够不需要标注字段。数据流是图里唯一的箭头一条线只能有一个方向一来一回的数据交换必须拆成两条独立数据流比如成绩查询请求和成绩查询结果。提示绘图时给四类图元固定配色加工用主色、存储用暖色、外部实体用灰色。评审打印黑白稿也能区分开比花哨的渐变实用得多。2.2 顶层图把整个系统画成一个加工先圈定系统边界顶层图也叫上下文图目的是把系统边界一次画清。常见做法是页面中间画一个大圆角矩形标图书订购与考务系统四周放三个外部实体把系统与外界交换的所有数据流都标出来内部一个加工都不画。画顶层图的四个步骤画中间加工框命名图书订购与考务系统不编号。顶层图只有一个加工编号没有意义。四周摆外部实体学生放左边、教师放上边、图书供应商放下边布局按谁和系统交互最频繁谁靠得最近调整。逐个实体过数据流该实体给系统什么、系统给它什么一条条画箭头并命名。数一遍总箭头数记下来。这个总数在0层图里会被反复核对。顶层图的数据流清单我一般做成表格存档它既是绘图依据也是后面做父子图平衡检查的底稿外部实体流入系统的数据流流出系统的数据流学生订购申请、退订申请、考试报名、成绩查询请求订购结果通知、到货通知、考试安排通知、成绩查询结果教师教材需求建议、考试计划建议、成绩录入数据教材确认结果、考试计划确认、成绩审核结果图书供应商发货单、发票、到货信息采购订单、退货单2.3 外部实体的取舍没有数据流通过的角色一律不画外部实体不是越多越好。判断标准只有一条这个角色有没有至少一条数据流和系统交互没有就删掉。最典型的例子是财务处。很多同学觉得订书要付钱就把财务处画进去然后多出一堆付款单结算单数据流。如果系统只记录订购和库存、不涉及在线支付和财务对账这些流全部超出系统边界。真需要结算时再引入财务实体否则就是给自己挖坑。另一个取舍点是管理员。图书订购与考务系统通常把登录验证、参数配置、公告发布作为内部功能这时管理员是系统的使用方但它不是数据来源操作会转化为配置信息发布内容等数据流进入对应加工。我的处理方式是管理员相关功能落成一个系统管理加工不单独画外部实体。原因很简单评审最爱问的一句话就是你这个管理员在0层图上的位置为什么和顶层图不一样少一个实体就少一个被问的点。顶层图的外部实体集合要一直沿用到底层0层图上可以继续出现这三个实体但不能再新增。如果画到一半发现还需要班主任参与考务审核说明顶层边界画漏了先回去改顶层图再改0层。3. 0层图到1层图图书订购主线和考务主线的逐层分解顶层图定边界0层图定主干1层图定细节。分层的目的不是把图画满而是让评审在每一页只需要接收一层信息。0层图控制在四到六个加工超过六个就说明顶层功能切分过粗或过细。3.1 0层图加工怎么切订购、入库、考务、成绩四个加工划分加工的原则是高内聚、低耦合每个加工内部做的事逻辑相关加工之间尽量只通过数据流和数据存储协作不画加工间的互相调用。图书订购与考务系统我一般切成四个加工编号加工名主要输入主要输出职责边界P1图书订购处理订购申请、退订申请、发货单采购订单、到货通知、退订结果汇总学生申请与供应商交互P2图书入库与发放到货信息、订购明细入库单、领书通知书到后验收、入库、按单发放P3考务安排处理考试计划建议、报名信息考场安排表、考试通知制定计划、处理报名、排考场P4成绩处理成绩录入数据、查询请求成绩单、成绩查询结果录入、审核、发布、查询为什么成绩处理要单独拆成P4因为它的数据特征和考务安排完全不同考试报名是短时间集中的写入成绩则是录入集中在考后几天、查询分布在整学期。把成绩发布和考场安排塞在同一个加工里会让1层图数据流多到没法看。为什么P2不合并进P1订购和入库是两个生命周期P1结束于供应商发货P2开始于到货验收。合并后加工说明里要同时描述下单和入库两套逻辑内聚性就差了。评审如果问P1和P2之间为什么还要走存储答案就是两张图各自要表达一个完整闭环。3.2 1层图分解示范P1订购处理和P3考务安排的子加工1层图是0层图每个加工的内部放大图。以P1为例把它拆成四个子加工编号加工名输入输出说明P1.1校验订购申请订购申请有效订购信息检查学号存在、教材编号在目录中、数量未超限P1.2汇总生成采购订单有效订购信息、库存缺书提醒采购订单按供应商分组合并形成批量采购单P1.3处理到货与分发发货单、到货信息到货通知、分发清单核对到货与订单差异生成领书清单P1.4处理退订与换订退订申请退订结果通知更新订购单状态涉及未发部分同步给供应商P3考务安排可以对应拆成P3.1制定考试计划、P3.2处理考试报名、P3.3生成考场与监考安排、P3.4发布考试通知。每个子加工都能用一句话说清读什么、写什么、做什么。这里有一个停在哪层的判断标准当每个加工都能用一句结构化文字描述内部逻辑不需要再展开判断和分支时就可以停。比如P1.1写校验学号存在性、教材编号是否在D3教材目录中、数量是否超过限购通过后写入D1订购单这句话说完P1.1不需要再往下画。如果某个加工的描述超过三句话还说不清楚就把它继续拆成P1.1.1、P1.1.2。3.3 数据流命名与编号规范让每张图不被误读命名是DFD里最容易埋雷的地方。三条硬规矩数据流必须用名词短语。查询成绩是动词开头不能做数据流名改成成绩查询请求和成绩查询结果两条流语义立刻清楚。数据流本质是在途的数据不是正在发生的动作。同一个词在全套图里只能有一个含义。订单这个词最危险——学生提交的叫订购申请发给供应商的批量单叫采购订单到货后的记录叫到货通知。全部拆开命名评审不用猜。真做到同义词排查可以在数据字典里做一次一词一义检查。加工和存储必须有全局面编号。加工用P1、P1.1、P1.1.1逐层下挂存储用D1、D2顺序编号不跟随加工。数据流不强制编号但名字要稳定顶层图叫订购申请0层图和1层图里就必须一直叫订购申请不能中途改名订书申请。存储的编号习惯我是这样定的D1订购单、D2图书库存、D3教材目录、D4考试安排、D5成绩。五个存储刚好铺满一层数量少到评审不用翻数据字典就能记住。存储一多就说明加工切得不够数据分散在全系统评审很难串起主线。4. 把DFD装进PPT8页结构、数据字典与排版参数图画好只完成一半。PPT的页面顺序就是讲故事的顺序评审跟着翻页就能复述整个系统这套资料才算合格。我的固定做法是先在绘图工具里把全套图画完导成高清图再往PPT里放绝不在PPT的文本框里直接画图。4.1 PPT资料的8页结构评审按什么顺序读这套图一份标准的图书订购与考务系统数据流图PPT资料我一般排8页封面系统名称、设计说明、版本与日期。标题写成图书订购与考务系统数据流图比系统设计更能让评审一眼定位。系统范围与外部实体文字说明系统做什么、不做什么配外部实体清单表解决边界不清的第一问。顶层数据流图全图一张外部实体与系统之间的所有数据流一览。0层数据流图四个加工、五个存储、三条主线。页面底部放加工一览表编号、名称、职责一行一个。P1/P2的1层图图书订购主线和入库发放线两页或一页并排图例放右下角。P3/P4的1层图考务安排和成绩处理线。这两张图的数据流比P1少可以合并一页。数据字典数据流定义表和数据存储定义表每条一组。加工说明与检查记录每个加工的输入、输出、处理逻辑一句话附平衡检查的结果说明。核心原则是一页一张图。0层图里已经包含了大量数据流再把1层图塞进同一页字号压到8磅打印出来全是乱的。图占页面60%以上的面积说明文字控制在三行以内图例单独放角落而不是占用正文位置。4.2 数据字典怎么写数据流、数据存储、加工说明三张表数据字典是DFD的配套解释评审问这条数据流里到底有什么就靠它回答。数据流条目的格式我固定为组成 来源 去向 说明。条目名组成来源去向说明订购申请学号 教材编号 数量 提交日期 备注学生P1.1一个学生一次可提交多本按提交时间顺序处理采购订单订单号 供应商编号 教材明细 总金额 下单日期P1.2图书供应商每周五批量生成一次状态字段区分在途/已到货成绩查询结果学号 课程名 成绩 绩点 审核标记P4学生未审核通过的成绩不对外显示数据存储条目用集合符号表示组成不用画字段表D1订购单 {订购申请采购订单到货记录}D5成绩 {课程成绩记录审核标记发布时间}。这样既说明了存储里有什么又没把DFD拖成数据库设计。加工说明用结构化文字一条加工一段P1.1校验订购申请检查学号是否存在于学生基础信息、教材编号是否在D3教材目录中、订购数量是否超过限购阈值默认10本校验通过后生成有效订购信息写入D1失败则返回订购失败原因给学生。这段文字在答辩时可以直接照着念比临场组织语言稳妥得多。4.3 绘图导出与排版参数字号、线型、导出精度直接给一组我反复调过、打印不糊、投屏不空泛的参数。页面设横版16:9绘图网格对齐开5毫米加工框宽约3厘米、高约2厘米外部实体宽3厘米、高1.6厘米数据存储宽3厘米、高2厘米开口线画在左侧。图内文字不小于10磅数据流标签9到10磅PPT正文14磅。连线全部用直线或折线不用曲线。两条数据流必须交叉时在交叉点画半圆弧桥不能直接穿过。布局顺序固定为外部实体靠页面四边加工居中数据存储靠下分布箭头从实体指向加工、从加工落到存储让整张图呈现从上到下的流动感。导出图片用PNG格式、300dpiPPT里插入后统一按固定宽度放置不要一张图拉大一圈。配色控制在全图不超过三种主色加工用深蓝边框白底、存储用橙色边框白底、外部实体用灰色边框白底。评审经常把PPT投到教室屏幕上深底色的图在投影仪上会连带文字一起糊掉白底深框是最稳的选择。注意PPT里不要用动画逐个点亮数据流。答辩现场一旦动画顺序卡壳整套图的逻辑就断了。静态全图是DFD资料最专业的呈现方式。5. 数据流图避坑手册分层不平衡、命名歧义与加工黑洞这一章是血泪经验汇总。下面五类问题覆盖了我见过的大部分DFD返工原因每条按现象、原因、解决三步写清楚。5.1 父子图数据流对不上加了流、漏了流现象评审拿着0层图问P1在0层图有4条流入1层图怎么只有3条入门流。或者反过来1层图里多出一条库存缺书提醒0层图上根本没有这条流。原因画1层图时从加工内部逻辑出发画着画着把父图边界上的流漏了或者觉得内部需要一条新流就直接加上没回头同步父图。解决分解任何加工之前先把父图的流入、流出清单抄到一张纸上比如P1流入为订购申请、退订申请、发货单流出为采购订单、到货通知、退订结果。子图画完逐条勾对。子图确实需要新流时先改父图再加子图顺序不能反。这个习惯叫先清单后画图是分层平衡最笨也最可靠的办法。5.2 加工只有输入没有输出数据进了黑洞现象P1.4接收退订申请但图上没有任何输出箭头数据进去就消失了。评审一眼就能指出来这个加工的归宿在哪原因多半是画到一半忘了画输出流或者该加工实际做的事情是更新D1订购单状态更新存储这条数据流漏标了。解决逐个加工数一遍每个加工至少各一条输入流和输出流输出到数据存储也算。遇到只有输入没有输出的加工追问一句这笔数据最终去哪只有输出没有输入追问数据从哪来。数据存储也要做同样检查一个存储不能只进不出也不能不进只出初始数据例外。做完这轮检查黑匣子加工基本清零。5.3 数据存储画成了数据库表现象图上出现D1图书订购表旁边还标注了id、book_id、qty这样的字段甚至画出一个带列标题的表格形状。原因把DFD和数据库物理设计混在一起了。数据存储表达的是数据在这里停留不是数据在这张表里存成什么结构。解决数据存储一律用逻辑名D1就叫订购单不叫订购表。字段、主键、索引全部进数据字典或后续的数据库设计章节不进DFD。判断方法很简单如果一张DFD需要读者懂SQL才能看懂那它就不是合格的DFD。5.4 外部实体在子图里重复出现现象1层图里每个子加工旁边都画着一个学生矩形一张图里出现五个学生虚线框也不知道往哪画。原因想把数据流画完整把外部实体复制进子图结果实体重复、连线交叉整张图视觉混乱。解决约定外部实体只出现在顶层图和0层图。1层及以下子图里涉及外部实体的数据流画在子图外缘标注来自学生或去往学生简化处理不画实体矩形。顶层图是系统与世界的对话0层图是世界在边界上与系统的交互1层图是系统内部的加工细节三个层级各自管好各自的表达范围。5.5 数据流命名用了动词或一条线画两个箭头现象箭头上写着提交订购查询成绩还有的图一条线上左右各画一个箭头表示一来一回。前者是流程图习惯后者直接违反DFD规则。原因把程序流程图、时序图的表达方式带进了DFD。数据流是数据本身不是动作本身一条流也不能同时承载两个方向。解决数据流强制用名词短语提交订购改成订购申请查询成绩拆成成绩查询请求和成绩查询结果两条流。一来一回必须画成两条独立数据流分别命名、分别编号。检查时把图上所有流的名字过一遍凡是能读成动词宾语结构的全部改掉。6. 交图前的最后10分钟编号回溯法与平衡检查表图画完、PPT排完别急着导出交差。我有一套固定自查流程整个过程十分钟已经帮我在答辩现场躲开过至少三次追问。编号回溯法的核心是顺着一条数据流走完全程。从顶层图随便选一条外部实体发起的数据流比如订购申请然后一步步验证顶层图中它从学生指向系统记下名字。打开0层图找到同名数据流确认它进入P1。打开P1的1层图确认边界流订购申请存在且进入P1.1。沿P1.1输出继续追有效订购信息写入D1还是流向P1.2每一步都要有去路。走到数据存储或外部实体为止。过程中每经过一层该数据流名字必须完全一致。用一张平衡检查表固化结果每张父图对应一张父图加工流入流清单流出流清单子图核对结果备注P1订购申请、退订申请、发货单采购订单、到货通知、退订结果全部匹配无差异P3考试计划建议、报名信息考场安排表、考试通知全部匹配报名名单同步写入D4最后再讲一遍给假想中的评审听。我自己的习惯是把整套图的编号清单打印出来一支笔一条条划划的过程就是讲的过程。有一次交图前只检查了图画没查数据字典评审问订购申请在数据字典里的组成写没写当场翻了半天才找出来。那次以后我的固定顺序变成先查字典、再查平衡、最后查命名三个检查用同一张清单贯穿。等价地你也可以找同学帮你看图让一个没参与画图的人按PPT顺序复述系统流程。他能讲通说明图的逻辑是顺的他卡住的地方就是图上隐藏的断点。这比对着镜子自述有效得多因为自己画完的图自带脑补滤镜外人没有。整套DFD资料做到这个程度图书订购与考务系统是什么样的、数据怎么流转、每层图之间如何对齐评审基本就问不出硬伤了。希望帮到你。本文还有配套的精品资源点击获取
阅读完成 · 觉得有帮助？
