简介数据流图DFD是系统分析与设计的重要建模工具这套PPT教学课件面向管理信息系统、软件工程等课程的初学者系统讲解如何从外部项、数据流、加工、数据存储四个基本元素入手通过自顶向下逐层分解绘制完整的数据流图。内容源自济南职业学院精品课程第14讲详细展开数据流图基本符号与命名规范、绘制步骤、布局原则和注意事项并以银行取款处理为完整实例呈现从关联图、顶层图到分层图逐步细化的全过程帮助学习者直观理解系统间信息流动并避开常见错误。压缩包内共1个文件为PPT格式大小312KB便于直接放映教学或按页拆解自学。已有625人学习适合正在准备数据流图作业、管理信息系统课程设计或系统分析文档的读者参考。1. 数据流图不是画框连箭先搞懂它在记录什么数据流图英文缩写DFD是需求分析和系统设计里最常被误用的一张图。最常见的翻车现场是把下单、检查库存、生成订单、支付这几步画成一串矩形加箭头箭头旁边写着“下一步”。这张图画得再整齐也不是数据流图。数据流图记录的不是业务动作的先后顺序而是数据记录从哪里产生、经过哪些加工、写入哪个存储、又流向哪里。箭头代表数据在流动不代表时间在推进。画好它的第一价值是逼着你把系统边界说清楚哪些外部实体跟系统交互系统内部哪些加工在消费和产出数据。它适合需求分析师、软件工程初学者、做系统概要设计的人也适合那些受够了“流程图画成流水账”的项目组。2. 数据流图怎么画四个核心符号与分层分解法则数据流图难画从来不是符号记不住而是不知道从哪里落笔、分解多细、边界画在哪里。我的做法是先把四种符号当成纪律背下来再按“上下文图 → 0层图 → 子图”的顺序往下拆每拆一层用平衡规则对上。顺序一旦反过来从细节往整体画绝大多数情况下都要返工。2.1 外部实体、加工、数据存储、数据流符号与命名规范四种元素是数据流图的全部家当一张表可以看完整套规则。元素常见画法命名方式举例外部实体矩形名词客户、支付网关、仓库加工圆角矩形或圆动词 宾语校验订单、生成报表数据存储开口矩形或双线名词订单记录、库存台账数据流带箭头线段名词订单请求、支付结果四种元素的分工很清晰外部实体是系统之外、但跟系统交换数据的人或系统加工表示对输入数据做的处理数据存储是数据停留的场所数据流是数据的移动。只需要这四个元素就能描述一个系统的数据全貌。画法上不同流派略有差异有的把加工画成圆有的画成圆角矩形数据存储也有开口矩形和双线两种画法。具体用哪种按团队规范统一即可不必纠结。真正要命的是命名。我的命名习惯是外部实体用名词客户、支付网关、仓库都行加工用动词加宾语校验订单、生成报表绝不能写成“订单处理中”这种状态描述数据流和数据存储也用名词订单请求、订单记录。一句话加工是动作其余是对象。如果一个数据流的名字让人看不出它装的是什么比如“数据”“信息”“内容”这张图后续基本没法评审。命名一旦含混评审会上就是各猜各的。流名要具体到能让别人直接判断它承载的数据内容这是数据流图和其他图的根本区别。2.2 先画上下文图把系统压成一个加工逼出边界上下文图是整个系统的起点也是我反复强调不能跳过的一层。做法是把整个系统画成一个加工节点编号为0然后把外部实体放在加工四周把跨越系统边界的数据流一条条标出来。它只有一层却决定了整个系统的边界。边界错了后面画得越细返工成本越高。画上下文图的步骤我一般固定为四步写下系统名画成加工节点0列出所有和系统交换数据的外部实体在实体与加工0之间画出所有跨边界数据流标好名字逐条核对每个外部实体至少有一条数据流每条数据流的两端必须一端是外部实体、一端是系统加工0。上下文图画完一定要让业务方确认这张图。因为外部实体是否被系统“管得到”是判断边界最核心的尺度系统能管理其内部数据的人或系统不应该出现在外部实体里。比如某后台系统里财务专员自己维护报表但报表数据由业务系统同步进来那业务系统才是外部实体财务专员不是。很多人把内部角色画成外部实体就是没想清楚这一层。上下文图中系统本身是一个黑匣子。评审只看这张图时只需要回答两件事系统跟谁交换数据、交换什么数据。任何关于内部加工的问题都不该在上下文图阶段出现。2.3 0层图把加工0展开成主加工0层图是把加工0打开外部实体保持不变内部变成若干主加工以及它们之间的数据流和数据存储。展开的依据是业务职能或数据加工阶段而不是组织架构。常见做法是先按业务环节分订单系统的校验、支付、发货图书系统的借书、还书、查询。每个主加工都应该对应一个完整的数据处理阶段。编号规则我习惯这样用0代表整个系统主加工从1开始编号加工1的子加工写成1.1、1.2。这个编号不只是为了好看而是让评审能快速定位说问题的人只要报一个编号大家就能找到对应的图和加工。没有编号的图评审沟通成本会成倍增加因为大家得靠“右上角那个圆角矩形”来指代。0层图是评审时最常用的一张图。它比上下文图多出内部结构又比子图少一些实现细节粒度正合适。很多项目最后只维护上下文图加0层图就够用了只有争议集中在某个加工内部时才往下拆一层。不要一上来就把所有层画完那会让评审陷入细节而忽略边界问题。2.4 平衡规则父子层的数据流必须对齐平衡规则是数据流图里最容易引起翻车、也最能体现功力的规则。它只有一句话父层加工有多少条输入输出数据流展开后的子图边界就必须有同样的一组数据流。举例来说父层里加工2“处理支付”有输入流“支付请求”和“支付结果”有输出流“支付通知”那么展开后的子图边界就必须原样出现这三条数据流。子图内部可以任意拆分加工但跨过子图边界的流一条不多一条不少。注意数据存储不需要在父子层之间强制对齐但加工的数据流必须对齐。子图内部新出现的数据存储如果只被当前加工内部使用可以留在子图不提升到父图。平衡规则保证所有层说的是同一件事。没有它父图和子图就是两张各自成立的画评审根本没法纵向看下去。我一般展开完一层马上做这个核对不要等整摞图画完再查那时改一个加工要带动一片改起来非常痛苦。平衡规则是数据流图里少有的可以机械检查的项做错了很丢分做对了能省很多评审时间。2.5 分解到什么粒度黑匣子与停止拆分的信号上一层的加工是一个黑匣子只看它接收什么数据、输出什么数据不关心内部怎么实现。到了下一层才把黑匣子打开看它内部有哪些加工、哪些存储。黑匣子思维能防止你在0层图就开始画实现细节也能防止把图拆成代码级别的设计。数据流图不是越细越好分解到能确认数据来源、加工和去处就足够了。拆分终点靠三个信号判断一是叶子加工能用一个动作加明确的输出数据说清楚比如“格式校验”输入订单请求、输出标准订单二是一个加工展开后的子加工数量在3到7个之间超过7个说明上层拆得太粗应该先分层三是再往下拆只能拆出流程图内容比如判断、循环、异常处理说明已经拆过界了。超过这个边界画的就是流程图加数据库设计图不是数据流图。过度分解的结果是图变得臃肿评审成本翻倍收益几乎为零。数据流图的目标是让人快速理解数据走向而不是替代码实现做详细设计。判断该不该继续拆就一个问题不拆这一层评审能不能讲清楚如果能停在这里。3. 手把手画一个订单处理系统的数据流图从上下文图到1层图下面用一个订单处理系统走完整流程。这套步骤是我的固定套路先列跨边界数据流清单再画上下文图再展开0层最后按需展开到1层。照这个顺序走基本不用返工。如果反过来先画一堆加工再连线画完回头对边界一定会发现流的名字和方向要改一大半。3.1 场景定义与外部实体清单场景是某公司的订单处理系统客户在网站上提交订单系统校验订单调用支付网关收款收款成功后通知仓库发货。业务动作只有三个校验、支付、发货它们正好对应三个数据处理阶段后面0层图的加工划分也沿这条线走。先别急着画框。第一步是把外部实体和跨边界数据流列成清单。这个项目的外部实体有三个客户、支付网关、仓库。客户提交订单请求给系统系统给客户返回订单状态通知系统向支付网关发起支付请求支付网关回调支付结果系统给仓库发发货指令仓库返回发货回执。把这些整理成一张表后面画图就是照着表连线。外部实体流入系统的数据流系统流出的数据流客户订单请求订单状态通知支付网关支付结果支付请求仓库发货回执发货指令这张清单就是上下文图的全部内容。清单能对上图不会大改清单有遗漏画图时迟早会发现但那时改起来就费事了。所以我把“先列数据流清单”当作画图的第一步而不是直接画框。这一步花不了十分钟省的却是后面几个小时的返工。3.2 上下文图只有加工0的一张图把系统画成加工0三个外部实体围在周围然后把清单里的六条跨边界流画出来。核对一下每个外部实体都有进有出每条流一端是外部实体、一端是加工0边界判断没有争议。这张图就是订单系统的上下文图简单到只有四个节点和六条流。这张图不回答系统内部怎么做事只回答两件事系统跟谁交换数据、交换什么数据。评审如果先看这张图基本五分钟就能确认边界。要改的也只是某个外部实体或者某条流成本很低。很多项目跳过上下文图直接画0层结果外部实体反复增减图被涂改得没法看这就是省掉边界确认的代价。上下文图还有一个作用它是画0层图的参照系。所有跨边界流在0层图中必须原样保留只是从指向加工0改成指向对应的主加工。有了上下文图打底0层图不会出现漏外部实体的问题。3.3 0层图拆成校验订单、处理支付、安排发货把加工0展开成三个主加工1校验订单、2处理支付、3安排发货。数据存储先定两个订单记录、支付流水。每个加工、每条流列进表里画的时候照着表连线。这里有个关键选择订单记录被三个加工共同读写必须提升到0层支付流水被加工2单独写但为了后续追踪方便也可以放在0层。编号加工输入流输出流读写存储1校验订单订单请求有效订单写订单记录读库存快照2处理支付有效订单、支付结果支付请求、已支付订单写支付流水、写订单记录3安排发货已支付订单、发货回执发货指令、订单状态通知写订单记录表里有一个细节需要说明“库存快照”这个存储只被加工1内部使用按照平衡规则它留在子图层级是允许的不需要提升到0层。如果后续发现其他加工也要读库存快照再把它提升到0层不迟。共享存储的层级判断标准就是多个加工用放上层单个加工用放下层。连线关系走一遍订单请求从客户进加工1加工1把有效订单给加工2加工2把支付请求发出去支付结果从支付网关回来加工2把已支付订单给加工3加工3向仓库发发货指令接收发货回执最后把订单状态通知送回客户。主链是加工1到加工2、加工3串行外部实体接在链的对应位置。画这一步时注意不要在这里画任何判断分支。支付成功才发货是流程逻辑数据流图上体现为加工2输出“已支付订单”、加工3接收它仅此而已。数据流图的主人公是数据不是业务步骤。把分支画进来是新手最常见的错误后面避坑章节还会专门说。3.4 1层图展开校验订单验证平衡规则0层图里最容易产生争议的是加工1校验订单评审时大概率有人会问“校验到底做了什么”。这时才把加工1展开成1层图1.1格式校验、1.2库存检查、1.3生成订单记录。边界上必须保留父图的两条流输入“订单请求”和输出“有效订单”。子图内部走一遍订单请求进1.1格式校验输出格式合格订单格式合格订单进1.2库存检查库存检查读库存快照输出库存充足订单库存充足订单进1.3生成订单记录写订单记录输出有效订单。注意1.2读的是库存快照这个存储只出现在子图层级父图里没有出现这是允许的。画完马上做平衡核对父图加工1的输入输出流是“订单请求”和“有效订单”子图边界上也是这两条没有多出也没有缺少平衡成立。如果子图里出现一条来自客户的“证件补充”流那就说明父图漏画了一条跨边界流应该抬头改父图而不是低头把子图改得自洽。这个顺序很重要子图永远不能私自扩大边界。到这里一张能拿去评审的数据流图就齐了。上下文图管边界0层图管主加工1层图管争议加工内部。流程上不要贪多哪个加工在评审里被打问号再单独展开那一层。没有争议的加工画到0层就够了。4. 数据流图实例对照图书借阅与库存盘点差在哪同样的画法换一个场景容易暴露一个共同问题分不清数据存储和外部实体。下面两张实例图一张以读者为中心的图书借阅一张以多实体协作为主的库存盘点。放在一起看判断差异就清楚了这也是“数据流图实例”最有价值的地方不同场景把同一个问题打出原形。4.1 图书借阅系统的数据流图实例场景是自助借还读者借书、还书、查书目。外部实体只有一个读者。系统内部三个主加工1登记借书、2登记还书、3查询书目。存储有三个书目记录、借阅记录、读者档案。这三个存储都是系统内部的数据资产读者作为外部实体无权直接访问。加工输入流输出流读写存储1 登记借书借书请求借书凭证读书目记录写借阅记录2 登记还书还书请求还书凭证写借阅记录写读者档案3 查询书目查询请求查询结果读书目记录上下文图更简单加工0加外部实体读者跨边界流有借书请求、借书凭证、还书请求、还书凭证、查询请求、查询结果一共六条。0层图把加工0展开成上述三个加工存储画在对应读写位置。这里要注意读者和借阅记录之间不能直接画线一切访问都要经过加工节点。这张图的关键在“登记借书”加工内部确认书目可借是一个内部决策图上不画菱形也不画“是/否”分支。如果借书被拒绝图上最多是输出一条“借书失败通知”数据流给读者但这依然是一条普通数据流不是判断分支。判断题留给流程图数据流图只关心数据本身。4.2 库存盘点系统的数据流图实例场景是盘点员发起盘点系统生成盘点单盘点员录入实盘数系统比对库存台账差异部分由仓库系统调整。外部实体有两个盘点员、仓库系统。前者在系统外录入数据后者在系统外执行库存调整。这里的外部实体是一个外部系统但它属于系统边界之外所以必须画成实体。加工输入流输出流读写存储1 生成盘点单盘点请求盘点单写盘点单记录2 录入实盘数实盘数已录入盘点单写盘点单记录3 核对差异已录入盘点单差异结果读盘点单记录、库存台账写盘点差异记录4 更新库存差异结果、调整结果库存调整请求读盘点差异记录写库存台账注意盘点单的流向盘点请求从盘点员进加工1加工1生成盘点单给盘点员这是系统内部加工向外部实体输出数据盘点员拿到单后录入实盘数实盘数从外部实体回到系统加工2。数据在外部实体和系统之间来回要拆成两条方向相反的数据流分别命名而不是画一根双向箭头。更新库存这里系统向仓库系统发“库存调整请求”仓库系统返回“调整结果”二者都是跨边界流。仓库系统内部怎么调库存数据流图完全不关心它是一个外部实体内部是黑匣子。外部系统和外部人一样只交换数据不暴露内部加工。4.3 两张实例图的三个判断差异第一外部实体与数据存储的判别标准。读者、盘点员、仓库系统都是系统管不到内部的对象是外部实体借阅记录、库存台账是系统内数据停留的场所是数据存储。判别时问一句这个对象能被系统管理其内部吗不能就是外部实体。这个问题在盘点例子里尤其有效仓库系统是一个独立系统订单处理系统管不到它所以它是外部实体。第二双向流动的处理。借书请求和借书凭证方向相反盘点单生成方向和实盘数录入方向也相反一律拆成两条独立命名的数据流。一根线加两个箭头会让命名、数据字典和后续追踪都没法做。数据流图里没有“双向数据流”这种元素只有两条方向明确、名字不同的数据流。第三共享存储的层级归属。书目记录被登记借书和查询书目两个加工读取提升到0层库存台账被核对差异和更新库存两个加工读写也提升到0层。一个存储如果只被一个加工使用放子图即可不必让父图承担多余细节。这个判断和实际代码里的共享模块归属很相似共用就往上提独用就往下沉。这两张图结构上很像都是一群加工围绕几个存储但数据走向的驱动力完全不同。借阅图是读者单点驱动整个系统围绕读者的借还行为转盘点图是多个外部角色协作驱动盘点员、仓库系统和内部加工在一条链上配合。画之前先想清楚谁发起数据、谁消费数据、数据最终落哪个存储这比手快更重要。想清楚了画图只是把脑子里的路径搬上纸面。5. 数据流图避坑指南五个高频错误与修正方法前面几章把画法讲完了这一章集中说坑。以下五类错误是我在评审和带人时看到最多的每一条都有具体现象、原因和修正方法对照着自查基本能避开九成问题。这些坑不是画图软件的错而是思路没转过来理解了原因之后换个场景也能避得开。5.1 把判断分支画进数据流现象加工内部画了菱形箭头标“是/否”或者数据流名字写成“若库存不足则拒绝”。整张图出现分支、循环、异常跳转越看越像流程图而不是数据流图。原因画的时候想的是业务步骤不是数据流动。数据流图描述数据在加工之间的移动判断逻辑是加工内部的事不该在图上出现控制枢纽。一个人一旦画了分支就会忍不住把“下一步做什么”画进去图就彻底跑偏了。修正方法把判断分支从图上拿掉换到流程图或伪代码里去表达。库存不足反映为两条数据流库存充足订单和库存不足通知分别从加工输出。外部接收者可能是同一个下游加工但数据流是两条各自命名。图面干净信息也没丢评审时不存在“这条线该走哪边”的争论。5.2 父子图数据流不平衡现象父图里加工1有输入流A、输出流B展开子图后边界上多了条输入流C或者少了输出流B。评审时上下层一对照立刻对不上两个人拿着两张图各说各话。原因展开子图时细化了需求把新数据流直接画了进去没有回到父图核对。这是最常见的翻车点也是最隐蔽的。新增的流在子图内部看起来合理却忘了父图的边界没有这条流上下层就断裂了。修正方法每展开一层用清单核对三件事父图的输入流是否都出现在子图边界父图的输出流是否都出现在子图边界子图边界上的流是否都能在父图里找到。任何一条对不上先改父图再改子图。子图多出来的流如果是跨边界流父图必定漏画不要为了子图自洽而丢掉平衡规则。5.3 黑洞、奇迹与灰洞加工的输入输出不配对现象一个加工只有输入没有输出数据进去就没了这是黑洞没有输入直接有输出像凭空生成这是奇迹输入信息根本不足以支撑输出比如只输入订单号却输出完整发票文档这是灰洞。三种情况在评审现场都会被一眼抓住。原因只想着把业务动作画全没验证加工的数据消费和生产关系。加工是数据处理单元不是业务流程节点输入输出必须构成数据上的因果关系。输入输出的数量和质量都要匹配否则加工就没有存在的必要。修正方法对每个加工连续问三个问题输入数据从哪个外部实体或存储来加工到底对这个输入做了什么输出数据流给到哪个存储或外部实体。三个问题里有一个答不上来这个加工就要拆分或补流。做完这一轮核对黑洞、奇迹、灰洞基本都能当场现形别让它们带着问题进评审会。5.4 外部实体直连数据存储现象图上有外部实体直接指向数据存储的箭头常见的是客户箭头直接插进订单记录或者读者直接连书目记录。看起来没绕路但数据流图不允许这么画。原因画的人把“访问数据”理解成人与数据库的关系外部实体本质上是读写系统存储。这种画法把系统边界直接穿透了外部实体和内部存储之间没有任何加工做隔离等于承认外部对象可以绕过所有业务逻辑操作数据。修正方法外部实体访问任何数据存储都必须经过加工节点。读者查书目的路径应该是读者把查询请求给查询书目加工加工读书目记录再把查询结果返回读者。这样画的道理很实在存储的访问由加工封装外部对象不能直接触达存储。这也是数据流图能表达系统安全边界的底层逻辑。5.5 数据流命名不一致与万金油流名现象同一份数据在父图叫“订单信息”子图叫“订单详情”还有流名直接写“数据”“处理结果”“信息”这类看不出内容的词。评审时两个人对着两个名字扯了半天才发现说的是同一个东西。原因多人并行画图命名没有统一约定画图时偷懒先用占位名顶着后来没补。数据流图一旦多人协作命名不一致就成了最大的沟通成本图本身画得再对名字对不上也白搭。修正方法数据流名全图唯一一个对象从头到尾叫一个名字数据流用名词加工用动词加宾语从命名上区分动作与对象在数据字典里登记别名。开始画图前先花几分钟把跨边界流的名字定好这张表就是命名的蓝本后面子图直接延用不要临时造新词。命名统一了图的质量就上了一半台阶。6. 用数据字典和平衡校验把数据流图变成评审依据图画完只是第一步能让人信服并照着往下做靠的是图旁边的数据字典和一张可执行的校验清单。数据字典不是可选项它决定图里的流名是否经得起追问。一张只有框和箭头的图经不起哪怕一个“这条数据流里到底有什么”的提问。6.1 为每条数据流建立数据字典条目我习惯给每一条数据流和数据存储建一个条目记录名称、组成、来源、去向。组成字段最关键它把流名展开成具体字段评审时任何一条流被质疑翻开字典就能解释清楚。名称组成来源去向订单请求订单号 客户ID 商品行列表 订单金额外部实体客户加工校验订单有效订单订单请求全部字段 库存校验状态加工校验订单加工处理支付支付结果支付流水号 支付状态 实付金额外部实体支付网关加工处理支付字段定义得越细画图时的“数据流信息不足”问题越早暴露。如果“有效订单”的组成里包含库存校验状态那么校验订单加工的输入就不止订单请求还要读库存快照这是数据字典反过来校验图的好例子。字典先写图后画比图先画再补字典更省事。6.2 五步校验清单收图前的最后自查收图前我用五步清单过一遍全部打勾才拿出去评审第一步上下文图与0层图的跨边界数据流完全一致外部实体一个不多一个不少 第二步每个父层加工的输入输出流与子图边界流完全一致 第三步每条数据存储至少有一个加工写入、一个加工读取不能只写不读或只读不写 第四步数据流名全图唯一不出现“数据”“信息”这类万金油名字 第五步每个加工至少一条输入一条输出不存在黑洞、奇迹、灰洞。这套清单在评审前做一遍基本能把低质量问题挡在门外。评审时间宝贵不要在基础规则上消耗大家耐心。我一般会把清单结果直接附在评审材料里让对方知道这些基础项已经自查过了。6.3 评审现场怎么验证一张图图在评审上是否成立我常用的验证办法是“跟流走”从一条跨边界数据流出发比如从客户的订单请求开始顺着箭头走完整张图每经过一个加工就追问一句这个加工改变了什么字段结果写到哪个存储或传给谁。走到第三四个加工大多数隐藏问题就会暴露要么某条流断了要么某个加工读了根本没定义的数据。这个方法不需要评审人懂整套数据流图理论跟着箭头走就行业务方也能参与。我早期画图就是先画框再连线被项目负责人退回来一次之后学老实了。现在的习惯是先列跨边界数据流清单再画上下文图展开一层平衡一层最后配数据字典。这套流程在项目交接时救过我很多次图让人看懂走向字典让人看懂内容两边都对得上才敢说这张数据流图能落地。希望帮到你。本文还有配套的精品资源点击获取