数据流图DFD画法：符号约定、分层分解与父子平衡校验-北京尧图网络

简介这份数据流图DFD专题PPT课件面向信息系统分析与设计的初学者及课程教学场景针对看不懂图形符号、不清楚自顶向下逐层分解逻辑的常见难点系统梳理了DFD的建模方法。课件先从数据流、加工、数据存储、外部项四类基本符号讲起说明编号规则与命名要点再给出识别外部项、确定输入输出流、划分主要处理功能、逐层细化直至检查完善的完整绘制步骤并归纳明确系统界面、合理布局等原则以及数据流必须经过加工等易错事项。压缩包内仅1个PPT文件约312KB篇幅紧凑、图示与讲解配套可直接用于课堂演示或自学通读。已有626人学习其中银行取款业务的关联图、顶层图与二层分解示例较具参考价值便于读者对照模仿独立完成从关联图到分层DFD的绘制与自检。1. 先弄清一个前提数据流图到底画给谁看带课程设计和毕设这几年返工率最高的一张图不是架构图也不是 ER 图而是数据流图。有同学画银行取款把现金画成一条数据流导师扫一眼就打回来整张图跟着重画。数据流图DFD的价值在于它不谈硬件、不谈软件、不谈数据结构和文件组织只回答系统在信息处理上做什么所以完全不懂技术的业务人员也能读懂代价是它对符号约定和分层纪律极其挑剔四种符号、四套编号、七步画法任何一步偷懒图就会从沟通工具变成只有画图的人自己看得懂的黑匣子。下面这套流程是我带项目时固定走的顺序从符号约定到逐层分解再到验收照着走能直接交作业也能直接用在需求评审上。2. 符号体系与建模约定四类元素、四套编号和一张画布很多人一上手就急着画画到第二层发现线交叉成一团改都改不动。问题几乎都出在前面符号用法没统一编号没规划布局没约定。这三件事在动笔前花二十分钟定死后面能省两天。我一般会先在一张草稿纸上写好本项目的符号约定和编号规则贴在图旁边谁来画都按这个来。2.1 四类基本符号各自管什么边界在哪数据流由一个或一组确定的数据组成线条加箭头表示流向。名字要能直观反映含义数据信息结果这类名字等于没起名读者看完还是不知道线上跑的是什么。数据流可以同名但必须是不同的数据或不同的含义同名同结构又同含义的两条流会让读者误以为是一条。两个符号之间允许同时存在多条数据流DFD 不表达它们之间的次序和主次——有人习惯在两条流之间标注先执行后执行那是流程图的思维混进来会让整张图的性质变掉。加工是对数据流的操作符号分上下两部分上面是标识部分写加工编号编号以 P 开头且全局唯一下面是功能描述部分写加工名要求简短、能概括对数据的加工行为更细的规则不进图全部放到数据词典里。加工必须逐层分解一直分到功能简单、易于理解为止这个终止条件后面会单独讲。数据存储用来存数据开口长方框框内写存储名概括说明里面主要放什么。有两条硬规矩数据存储上一定要有数据流只写不读是死数据只读不写等于凭空产生数据存储要编号写在符号左端的小方格中以 D 开头。为了避免图上出现交叉线同一个数据存储可以在多处重复画出用一个重复标记表示它们是同一个。外部项又叫源点和终点是系统之外的实体可以是人也可以是别的系统。从源点进系统的信息是输入从系统到终点的是输出。外部项编号以 S 开头图上不需要详细描述它——它的内部逻辑不属于本系统写多了反而是越界。同一个外部实体在图上出现两次既收又发时我一般左右各画一个同编号的符号比拉一条横穿全图的长线干净得多。边界这条最容易被忽略现金、发票、纸质存折、货物这类实物不是数据。数据流跑的是信息不是物流。银行取款里现金从柜台递到储户手上这件事在 DFD 里根本不出现真正上线的是存折、利息单、结算清单这些承载信息的单据。提示判断一条线该不该画问一句这条线上跑的是能被记录、存储、加工的信息还是实物或动作。是实物或动作就别进 DFD。2.2 编号规则P / D / F / S 四套前缀怎么定前缀对应元素编号写法层级约定常见错误P加工P1、P2分解后写 P2.1、P2.2父图子图共用一个编号D数据存储D1、D2全局唯一不随层变同一个文件在不同层换号F数据流F1、F2细化后写 F1.1、F1.2同一条数据在不同层换名S外部项S1、S2全局唯一同一实体画两个符号两个号编号不是为了好看是为了评审时能一句话定位。P2.3 少了一条输入比那个分类处理好像缺点什么高效太多尤其在多人协作时编号就是共同语言。数据流编号有个好用的习惯同一条数据流在父子图之间保持同一编号和同一名字只在细化时加点号。父图上 F1 是取款单、存折子图拆成 F1.1合格存折、取款单和 F1.2不合格存折、取款单点号一看就知道血缘关系。反例是把父图的 F1 在子图里改名成 F7评审的人得来回对照才敢确认这是同一条流这种改动除了给自己添麻烦没有任何收益。加工编号的层级要统一。顶层是 P1、P2、P3P2 分解出来的二层图就是 P2.1、P2.2、P2.3、P2.4绝不允许出现 P2 下面挂 P5 的情况。数据存储编号通常不分层D1 在第一层叫图书目录到第二层还是 D1因为它是同一个物理文件在不同层被读写。2.3 画布布局与防交叉线的约定布局有套稳定的排法外部项贴画布四边源点在左、终点在右加工居中偏上数据存储靠下或贴两侧。这么排是因为读图的人眼睛习惯从左到右、从上到下扫边界在边上一眼就能看出系统管到哪儿为止。反过来把外部项堆在中间、加工甩到角落读者第一眼就找不到边界。线尽量走直线拐弯只拐直角斜线会让整张图看起来像蜘蛛网。实在避不开交叉时断开来画把被穿过的数据存储在图的两侧各画一个重复符号中间那条穿过去的线就不存在了。这条技巧在小图上无所谓到二层图、三层图就是救命用的。每层单独一张画布关联图一张、顶层图一张、二层图一张或数张绝不混画。混画的典型症状是一张图上既有总的系统框又有拆开之后的子系统框编号还混着用评审时没法判断这是哪一层。分层的意义在于每一层都能单独拿出来讲一张图讲一件事。命名和布局要一起做。画完先别急着往下分解把每条数据流的名字逐条念一遍念出来像人话就留念出来像数据 1处理结果就改。名字改在图上是两分钟的事等到数据词典写完再改就是牵一发动全身。3. 分层分解的落地路线从关联图到二层图的七步操作七步听着像仪式其实每一步都有明确交付物第一步交出外部项清单第二步交出关联图第三步交出子系统划分说明第四步交出各层子图第五步交出分解终止判定第六步交出检查记录第七步交出用户确认意见。有交付物进度才可控没有交付物画到哪儿算哪儿最后只能推倒重来。3.1 前三步定外部项、画关联图、划分子系统第一步确定外部项就是找系统的数据来源和去处。做法很土但管用把业务方提到的所有角色、所有外部单位、所有上游下游系统列成一张清单逐条问它给系统什么数据系统给它什么数据答不上来的先划掉。清单出来后统一编号这是后面所有图的基准。第二步画关联图。把整个系统当成一个加工环节画一个框就行可以不编号把第一步整理出的全部输入输出数据流画上去。关联图的作用是锁定系统边界这张图跟用户确认过之后后面所有分解都不许越界。很多返工都是因为关联图上多画了一个外部项导致后面每一层都要跟着改。第三步划分子系统。划分依据是主要信息处理功能按业务动作切——审核、处理、汇总、发送而不是按部门切也不是按技术模块切。按部门切出来的图一旦组织结构调整图就废了按业务动作切动作本身是稳定的。切完给每个子系统编号 P1、P2、P3同时确定每个加工的输入输出数据流以及跟这些加工有关的数据存储。3.2 第四到第五步逐层分解与父子平衡分解遵循自顶向下、逐层细化的原则对上层图中的全部或部分加工继续拆。这里有个判断标准什么时候停当这个加工的功能简单到能用一句话说清、且不需要再拆就能直接写进数据词典时就可以停。行业里管这种叫基本加工。拆过头的典型是把审核再拆成读单据比对返回结果那是程序设计的层次不是 DFD 的层次。父子平衡是这一阶段最硬的约束父图上某个加工的输入流集合必须等于子图上该加工所有外部输入流之和允许细化不允许凭空多出或消失。举个例子父图 P2 的输入是 F1输出是 F2 和 F3那么二层图里 P2.1 到 P2.4 这几个加工它们与子图外部相连的流加起来必须正好对应 F1或其细化 F1.1、F1.2、F2、F3。如果子图里冒出一条父图没有的 F9或者父图的 F3 在子图里彻底消失就是不平衡。不平衡是评审时最容易被抓的点因为它可以被机械检查出来不需要理解业务。我见过最典型的一次是子图上多画了一条内部通知流作者觉得顺手但在父图层面它没有对应的出入口整条链就断了——要么在父图补上要么在子图删掉没有第三种选择。3.3 第六到第七步布局检查与用户走查第六步是检查与合理布局检查项有四类分解是否恰当彻底各层是否有遗漏、重复、冲突各层之间以及同层各图之间关系是否正确命名与编号是否确切合理。这一步不要自己闷头看最好找一个没参与画图的人对着图讲一遍讲不通的地方就是问题所在。第七步是跟用户交流。顺序是先拿关联图讲边界问你们的数据来源和去处就这些吗再拿顶层图讲子系统划分问这几块业务是这么分的吗最后逐条念数据流的名字问你们平时是这么叫的吗。用户说我们不管这个叫取款单叫凭条那就改名字别争。名字错了后面数据词典、界面设计、字段设计全跟着错这是血泪经验。注意走查不是一次性的。每分解一层就该走一次等到全部画完再拿去给用户看改动成本会翻好几倍。3.4 用一份元素清单做机械校验人工检查容易漏尤其是流多的时候。我一般会把图上的元素先录入一份清单再用脚本跑一遍把断线、黑洞、只读不写的存储挑出来。清单直接用一个 Python 字典表示改起来比数据库快。# dfd_model.py # 用字典描述单张 DFD元素连线脚本负责机械校验 dfd_top { name: 取款处理顶层图, externals: {S1: 储户}, processes: {P1: 取款审核, P2: 取款处理}, stores: {D1: 账目库, D2: 取款记录}, # 每条流: 编号 - (起点, 终点)端点必须是上面三类里定义过的编号 flows: { F1: (S1, P1), # 取款单、存折进入审核 F1.1: (P1, P2), # 合格单据送取款处理 F1.2: (P1, S1), # 不合格单据退回储户 F2: (P2, S1), # 存折、利息单、结算清单交储户 F4: (D1, P1), # 审核时查账目 F5: (P2, D1), # 处理后改账目 F6: (P2, D2), # 取款单存档 }, }校验函数做四件事端点是否存在、加工是否有进有出、数据存储是否既被读也被写、父子图边界流是否对得上。def check(dfd): nodes set(dfd[externals]) | set(dfd[processes]) | set(dfd[stores]) in_flow, out_flow {}, {} for fid, (src, dst) in dfd[flows].items(): if src not in nodes or dst not in nodes: print(f[断线] {fid}: {src} - {dst}端点未定义) in_flow.setdefault(dst, []).append(fid) out_flow.setdefault(src, []).append(fid) # 加工不允许只有输入黑洞或只有输出奇迹 for pid, pname in dfd[processes].items(): if not in_flow.get(pid): print(f[奇迹] 加工 {pid} {pname} 没有输入) if not out_flow.get(pid): print(f[黑洞] 加工 {pid} {pname} 没有输出) # 数据存储必须有读有写 for did, dname in dfd[stores].items(): if not in_flow.get(did): print(f[只读] 存储 {did} {dname} 没有任何写入) if not out_flow.get(did): print(f[死数据] 存储 {did} {dname} 没有任何读取)父子平衡单独一个函数思路是把子图里所有跨越子图边界的流按编号前缀归并回父级编号再跟父图上该加工的进出流比对。def check_balance(parent_flows, child_flows, pid): # parent_flows: 父图上与加工 pid 相关的流编号集合如 {F1, F2, F3} # child_flows: 子图中所有一端在子图内部、另一端在子图外部的流编号 base lambda f: f.split(.)[0] # F1.1 - F1 child_base {base(f) for f in child_flows} missing set(parent_flows) - child_base # 父图有、子图没了 extra child_base - set(parent_flows) # 子图凭空多出来的 if missing: print(f[不平衡] {pid} 子图缺少父图的流: {sorted(missing)}) if extra: print(f[不平衡] {pid} 子图多出父图没有的流: {sorted(extra)})参数说明parent_flows填父图上挂在这个加工上的流编号child_flows填子图里所有跨边界的流。split(.)[0]是为了把 F1.1、F1.2 归并回 F1因为父子平衡允许细化只禁止增减。跑完输出为空说明这张图在结构上站得住有输出就照着编号回去改图比盯着画布找问题快得多。4. 两个案例走一遍银行取款与图书预订的逐层拆解光看规则记不住得有两三个实例走一遍全流程。银行取款适合讲边界什么不能画成数据流图书预订适合讲分解为什么顶层画完还得多走一层。这两个例子吃透换成教务系统、图书管理系统、设备报修系统套路是一样的。4.1 银行取款现金是实物不是数据流业务描述储户把填好的取款单和存折交给银行银行审核并查对账目不合格的存折和取款单退回储户合格的送取款处理处理取款时修改账目把存折、利息单、结算清单和现金交给储户同时把取款单存档。第一步关联图。外部项只有储户一个但要注意它既是源点也是终点储户给出 F1取款单、存折系统返回 F2存折、利率单、结算清单。现金在这里不出现它属于实物交接不进 DFD。这一步画完就该拿去跟业务方确认进出系统的信息就这两条吗确认了再往下走。第二步顶层图。把系统拆成两个加工P1 取款审核、P2 取款处理两个数据存储D1 账目库、D2 取款记录。数据流这么连编号名称起点终点说明F1取款单、存折S1 储户P1 取款审核系统输入F1.1合格存折、取款单P1P2 取款处理审核通过F1.2不合格存折、取款单P1S1 储户审核退回F2存折、利率单、结算清单P2S1 储户系统输出F4账目查询D1 账目库P1审核时查账F5更新账目P2D1处理后改账F6取款单P2D2 取款记录存档这里有两个设计点值得说。P1 只读不写它是纯判定加工这在 DFD 里完全允许但必须保证它有进有出否则就是黑洞。F1 在子图里被细化成 F1.1 和 F1.2编号带点号评审时一眼能看出它们是从 F1 分出来的这就是 2.2 节那套编号习惯的实际收益。4.2 图书预订顶层画完还得多走一层业务描述书店向顾客发放订单顾客填好交回系统系统依据图书目录检查订单合格订单进入处理处理时根据顾客情况和订单数目把订单分成优先订单和正常订单优先订单随时处理正常订单定期处理最后汇总已处理订单按出版社要求发给出版社。关联图S1 顾客给出 F1 订单系统返回 F3 不合格订单系统向 S2 出版社发出 F2 汇总订单。三条流边界干净。顶层图P1 订单检查、P2 订单处理、P3 发送订单数据存储四个D1 图书目录P1 读、D2 合格订单P1 写、P2 读、D3 待发出订单P2 写、P3 读、D4 出版社要求P3 读。这张图已经能讲清系统有哪几块业务但 P2 仍然不是基本加工——它内部同时干了数目统计、订单分类、处理优先订单、处理正常订单四件事一句话说不清必须再分解一层。二层图把 P2 拆成四个加工P2.1 数目统计读 D2写 D5 订单数目、P2.2 订单分类读 D2、D5 订单数目、D6 顾客情况分出 D7 优先订单和 D8 正常订单、P2.3 随时处理优先订单读 D7、P2.4 定期处理正常订单读 D8写 D3 待发出订单。这里体现了一条重要原则数据存储一般作为两个加工之间的界面来安排。分类和处理之间不直接拉线而是用 D7、D8 两个存储承接好处是以后要加一种订单类型只需在分类里加一个输出处理侧不受影响。对比一下就能看出两个例子的分工银行取款重点在边界判断图书预订重点在分解深度。同一个套路一个用来练什么不该画一个用来练什么时候该继续拆。4.3 数据词典怎么跟图配套图上的名字必须有地方落定否则答辩时被问合格订单里到底有哪些字段就卡住了。我一般用三张表把图和词典钉在一起。-- 元素表图上的每一个符号都在这 CREATE TABLE dfd_element ( elem_id VARCHAR(16) PRIMARY KEY, -- P2.2 / D7 / S1 elem_type CHAR(1) NOT NULL, -- P加工 D存储 F数据流 S外部项 elem_name VARCHAR(64) NOT NULL, parent_id VARCHAR(16), -- 所属父加工顶层为 NULL remark VARCHAR(255) ); -- 连线表外键保证不会出现悬空的线 CREATE TABLE dfd_flow ( flow_id VARCHAR(16) PRIMARY KEY, -- F1.1 flow_name VARCHAR(64) NOT NULL, src_id VARCHAR(16) NOT NULL, dst_id VARCHAR(16) NOT NULL, FOREIGN KEY (src_id) REFERENCES dfd_element(elem_id), FOREIGN KEY (dst_id) REFERENCES dfd_element(elem_id) ); -- 数据项表数据词典的正文本 CREATE TABLE data_item ( item_id VARCHAR(16) PRIMARY KEY, flow_id VARCHAR(16), -- 属于哪条流或哪个存储 item_name VARCHAR(64) NOT NULL, item_type VARCHAR(32), -- 字符/数值/日期 item_len VARCHAR(16), rule VARCHAR(255) -- 取值规则、校验规则 );dfd_element.parent_id撑起分层树任意一层都能顺着字段往上找父加工dfd_flow的两个外键把端点必须存在这条约束交给数据库插入一条指向不存在加工的流会直接报错data_item是词典本体答辩被问订单字段就翻这张表。要查某个加工的所有进出流一条 SQL 就够SELECT flow_id, flow_name, src_id, dst_id FROM dfd_flow WHERE src_id P2 OR dst_id P2;把P2换成任意加工编号即可复用。这种查法在评审前特别好用把每个加工查一遍输出为空的那一行就是图上漏画的加工。5. 避坑与常见问题排查五类最容易被退回的图这些年看过的图里出问题的就那么几类反复出现。下面每条按现象—原因—解决写对着自查基本能挡掉大部分返工。第一类实物和动作混进数据流。现象是图上出现现金发票货物发货这类名字。原因是画图的人把 DFD 当成了业务流程图觉得业务里发生的都该画上去。解决办法是回到定义数据流由一个或一组确定的数据组成必须是可记录、可存储、可加工的信息。现金交接不画但现金对应的结算清单要画发货动作不画但出库单要画。判断方法就一句这条线上跑的东西能被存进数据库吗。第二类数据流绕过加工。现象是外部项直接连到数据存储或者外部项之间拉一条线。原因是图省事觉得反正数据就是从这儿到那儿。解决数据流必须通过加工外部项跟数据存储之间不存在直接通路中间一定要有一个加工在做转换。外部项之间更不能有流它们分属系统内外两侧跨过整个系统的连线说明边界没划清。第三类父子图不平衡。现象是父图上 P2 有两条输入子图里对不上或者子图里凭空冒出一条父图没有的流。原因多半是分层时改图只改了子图忘了回头同步父图也可能是分解时顺手加了个内部通知之类的流。解决用 3.4 节那个check_balance跑一遍按编号前缀归并后比对缺的补、多的删删不掉就在父图补上对应出入口。第四类加工黑洞与数据存储只读不写。现象是某个加工只有输出没有输入或者某个存储从头到尾只有箭头指向它。原因是分解到一半思路断了先画个框占位后来忘了补。解决跑check函数输出里出现[黑洞]、[奇迹]、[只读]、[死数据就回去补。特别提醒纯判定类加工比如审核它们可以不写存储但必须有进有出这一点最容易误判成它不写库所以没问题。第五类分解失控与命名含糊。分解失控有两种表现一种是一层画到底把几十个加工全塞在顶层图上读者根本看不出层次另一种是拆到原子级把审核拆成读单据—比对—返结果这已经进入程序设计层面不是 DFD 该管的。命名含糊则是通病加工叫处理数据数据流叫信息数据存储叫数据库。解决办法加工名用动宾结构能一句话说清动作对象数据流名用名词或名词短语能念出来像业务里的人说的话存储名概括里面主要放什么。分解终止条件统一为功能简单到不需要再拆即可写进数据词典全组按这一个标准执行别各拆各的。6. 验收与答辩十分钟里证明这张图是对的图交上去之前我一般会走一遍固定自查六项对着表打勾比凭感觉靠谱得多。检查项合格标准一句话验法符号只出现四种基本符号画布上有没有圆角框、云朵、动作箭头混进来边界外部项只出现在图的四周有没有外部项直接连到数据存储平衡父子图边界流一一对应父图 P2 的进出流能不能在子图里找全编号P/D/F/S 前缀正确且分层有没有两个 P1有没有跨层编号存储每个存储既有写入也有读取顺着箭头数进出方向命名每条流念出来像业务用语出现数据信息处理就重命名答辩的讲法比图本身还重要。十分钟的场子我通常这么排先用三十秒讲关联图只讲系统边界——谁是数据来源、谁是数据去处、进出各几条流讲完评审就知道你把范围框住了接着两分钟讲顶层图重点讲子系统划分依据为什么按审核、处理、发送这么切而不是按别的切法然后三分钟挑一条主线数据流走到底比如一张取款单从储户填单开始进审核、查到账目、合格后送处理、改账目、写取款记录、最后生成结算清单回到储户一条线走完整张图的连贯性就立住了最后两分钟讲终止条件说明为什么在这一层停、哪些加工已经是基本加工。剩下的时间留给提问。常被问的三类问题提前准备好答案某个数据存储为什么放在这一层而不是上一层某个加工为什么不再往下拆某个外部项为什么不算系统内部模块。这三问本质上都在考你有没有想清楚边界和层次而不是考你画得漂不漂亮。从那以后我每次交图前都强制走两件事把元素清单丢进校验脚本跑一遍再把关联图拿给一个完全不懂技术的同学讲三分钟他能复述出系统边界和数据流向这张图才算过关。希望帮到你。本文还有配套的精品资源点击获取

数据流图DFD画法：符号约定、分层分解与父子平衡校验

相关推荐

基于STM32与AD5542的微伏级脑电信号模拟发生系统设计

WorkBuddy+微信+deepseek-v4-flash：打造每日AI日报自动推送系统

AgentScope：Java生产级AI Agent框架深度解析

更多资讯

HY-World 2.0安装配置全攻略：CUDA 12.8环境搭建与依赖管理

cyrillic_PP-OCRv5_mobile_rec_onnx完整指南：从入门到精通移动端OCR

金融量化的概率统计基础2

【系统架构设计（30）】操作系统中：前驱图、死锁与银行家算法

【系统架构师设计（29）】操作系统上：操作系统概述、进程管理、同步与互斥

Maven依赖管理：dependencies、dependencyManagement与BOM分别改变了什么

今日更新

淘宝商品详情API开发实战与性能优化指南

Unity Package Manager刷新错误排查与解决方案

Java record 规范构造器能否被反序列化或反射绕过

本周精选

面向复杂光照与角度的宠物面部识别鲁棒性增强策略

基于DRV8818与STM32的双极步进电机驱动方案实战解析

DRV8818PWPR+PIC18F45K80双极步进电机控制方案实战

本月热门

面向复杂光照与角度的宠物面部识别鲁棒性增强策略

基于DRV8818与STM32的双极步进电机驱动方案实战解析

DRV8818PWPR+PIC18F45K80双极步进电机控制方案实战

读完文章，想聊聊您的网站？