简介这份PPT课件以“数据流图DFD”为主题面向系统分析与设计初学者、管理信息系统课程学习者以及需要绘制数据流图的项目人员系统讲解DFD的基本概念、四种核心符号数据流、加工、数据存储、外部项以及自顶向下的绘制步骤与原则。课件结合银行取款处理实例逐步演示从关联图到分层DFD的完整画法并详细说明了识别外部项、确定输入输出数据流、逐层分解加工等关键环节同时强调数据流必须通过加工、数据存储编号规则等常见注意事项能够帮助读者避开绘制中的典型误区。压缩包内仅含1个ppt文件大小约312KB内容紧凑完整适合快速学习或课堂辅助教学使用。该讲作为济南职业学院精品课程的一部分讲解结构清晰理论与实践并重目前已吸引622人浏览学习适合需要系统性理解并动手绘制数据流图的读者。1. 数据流图系统分析中最容易画错的一张图数据流图DFD可能是系统分析里最被低估的工具。很多人觉得它不过是几个方框加箭头真正动手画的时候才发现加工和外部项的边界在哪里数据存储该不该出现在关联图上为什么同一个数据流在上下两层之间总对不上这些问题不是画图技巧问题而是对系统逻辑模型的理解问题。数据流图的本质是把你脑子里的系统逻辑变成一张用户看得懂的图它不关心你用 MySQL 还是 Oracle也不关心服务器部署在哪只关心一件事——数据从哪里来、经过什么处理、存到哪里去、最后给谁用。这篇内容用两个完整实例走一遍从关联图到二层图的全部过程顺带把四种基本符号的命名、编号、布局规则讲透适合正在做课程设计、软考准备或者第一次接手系统分析任务的人。2. 四种基本符号加工、外部项、数据流、数据存储的边界2.1 四个符号的职责划分数据流图的符号系统非常精简只有四种加工P、外部项S、数据流F、数据存储D。这四种符号之间的边界是初学者最容易混淆的地方。外部项是系统之外的人或系统它是数据的来源或去向但外部项本身不参与系统内部的处理逻辑。加工是系统内部对数据做的变换操作每个加工必须有输入数据流和输出数据流不能出现只有输入没有输出或者只有输出没有输入的加工。数据存储是数据的静态落脚点它表示数据在某个时间点被保存下来供后续加工读取。数据流则是连接上述三种符号的纽带它表示数据的动态流动。在实际项目中我经常看到有人把外部项画进系统内部比如把管理员当成一个加工来画这是一个典型的边界错误。管理员是操作系统的用户他本身不是系统功能的一部分正确的做法是把管理员作为外部项系统内部只画管理员发起的请求数据流和系统回送的响应数据流。判断一个实体是外部项还是加工可以问一个问题这个实体是否对数据做了有意义的转换如果只是发起请求、接收结果就是外部项如果对数据进行了校验、计算、分类等操作就是加工。符号命名前缀编号规则必须满足的条件加工 P动词短语P1, P2, P1.1, P1.2至少一条输入流和一条输出流外部项 S名词短语S1, S2不需要详细描述内部结构数据流 F名词短语F1, F2必须连接两个符号不能悬空数据存储 D名词短语D1, D2至少有一条数据流进出这四种符号在一个图中可以重复出现比如同一个外部项在图的左端作为源点、在图的右端作为终点这是允许的目的是避免交叉线。数据存储也可以重复绘制同一个数据存储出现在多个位置时用相同的编号标识即可。2.2 加工的标识与功能描述分离加工符号分上下两部分这是 DFD 与流程图最大的区别。上半部分写加工编号以下反复出现以 P 开头编号在整个系统范围内必须唯一。下半部分写加工名加工名应当简短能够概括对数据做的操作比如审核订单计算工资更新库存。加工名的动词选择很讲究不要用处理操作这类没有信息量的词处理数据这种命名等于没命名应该具体到进行何种处理比如按客户等级分类。加工的详细逻辑不写在 DFD 上而是写在数据词典里。数据词典中会定义加工的描述、输入数据流的组成、输出数据流的组成、加工的逻辑规则。这是 DFD 的一个重要设计思想图形化表达只呈现系统的骨架细节信息集中管理。在课程设计报告中如果老师要求画数据流图并配数据词典理解这一点能让你少返工。2.3 数据流命名的典型错误数据流命名有几种典型错误在作业和实际项目中非常常见。第一种是用动词命名数据流比如录入订单作为数据流名这实际上是在描述一个操作不是描述数据本身正确的命名应当是订单信息或新订单。第二种是命名过于笼统数据信息文件这类词完全没有承载任何意义应该说明是什么数据。第三种是数据流名与内容不一致比如数据流名叫订单但实际携带的是客户信息和商品信息这种不一致在后续的数据词典编写中会暴露出来。数据流的流向必须全部标注清楚DFD 中的箭头既表示流向也表示数据流的名称位置。两个符号之间存在多个数据流是允许的比如合格订单和不合格订单可以同时从订单检查流向后续加工但这并不意味着两个数据流之间有次序、主次关系DFD 不表达控制逻辑它只表达数据的流动关系。3. 绘制数据流图的七个步骤从关联图到分层 DFD3.1 关联图画的是系统边界绘制数据流图的第一步不是画加工而是明确系统边界。把整个系统当作一个加工用一个大圆框表示外部项画在圆框外部系统与外部的所有输入输出数据流画在圆框上这样得到的图称为关联图。关联图的作用是回答一个问题系统从哪些外部实体接收数据、向哪些外部实体发送数据关联图的画法非常严格系统只作为一个加工符号出现不画内部的数据存储不画内部的加工分解。外部项必须画在加工符号的外围数据流的箭头必须指向或离开加工符号不能出现外部项之间的直接数据流因为外部项之间的信息交换不属于本系统的处理范围。以教务管理系统为例学生提交选课申请、教师录入成绩、教务处发布排课结果这些外部项在关联图上与系统存在数据交互。关联图上的外部项数量不宜过多一般控制在五个以内如果外部项超过七个先考虑是否系统边界划分过大把某些外部项拆给了其他系统。3.2 顶层图的第一次分解第二步是画顶层图也就是在关联图的基础上把系统内部按照主要功能分解成若干加工。注意关联图中的加工没有编号顶层图中的加工编号从 P1 开始。顶层图中的每个加工对应系统的一个主要功能模块比如教务管理系统可以分解为选课管理成绩管理排课管理三个加工每个加工之间通过数据流相连数据存储在这一层开始出现。顶层图的分解粒度以能够清晰表达各加工之间的数据关系为准不要分解得过细也不要合并过度。一个常用的判断标准是如果在顶层图中某一个加工已经能够用一句话说明它对数据做什么操作并且这个操作不需要再细分那么这个加工就可以认为是基本加工不必再往下分解。顶层图画完后需要检查输入输出数据流的完整性。方法是回到关联图逐一核对外部项关联关系确认关联图中的每一条输入输出数据流在顶层图中都有对应的去向或来源。关联图中有学生选课申请流入系统顶层图中就必须有一个加工接收选课申请这条数据流。如果发现某条数据流在顶层图中找不到归属说明分解过程中遗漏了功能。3.3 逐层分解的递归过程从顶层图开始对每一个需要细化描述的加工重复分解操作得到二层图、三层图直到每个加工都是基本加工。分解的原则是自顶向下、逐层细化父图中的加工与其子图之间存在严格的对应关系。父图中的加工编号为 P1那么 P1 的子加工编号为 P1.1、P1.2、P1.3 等三层继续向下编号为 P1.1.1。每层分解时子图中的输入输出数据流必须与父图中对应加工的输入输出数据流保持一致这称为数据流的平衡性。父图中的加工订单处理有一条输入数据流订单和两条输出数据流汇总结果退单信息那么子图中所有加工的数据流拼接起来最外层的输入输出必须与父图一致。这是数据流图检查中最关键的一项也是大部分绘制错误的高发区。实际绘制时可以先画图的框架子加工的编号和名称、子加工之间的数据流、子加工与数据存储之间的数据流再逐步补充每一条数据流的名称和详细信息。不建议直接到最后才考虑数据流命名因为数据流名称的一致性本身就是后续验证分解正确性的线索。3.4 与用户确认画数据流图不是一次成形许多初学者的误区是试图一次画出一张完美无误的数据流图。实际上数据流图的绘制过程本身就是一个需求确认过程需要反复与用户沟通。如果用户看不懂你的图不是用户的问题而是图的问题。我在实际项目中通常采用这样的流程先画出关联图给用户确认确认边界无误后再画顶层图。顶层图只展示功能模块和数据流向不涉及任何技术细节用户可以直观地理解这个系统有哪些功能、模块之间如何传递数据。用户对数据流的理解往往与系统分析人员不同他们会告诉你这里不应该有数据流因为实际工作中这个环节由人工传递或者这个数据不应该到这里应该到另一个部门这些反馈是画图过程中最有价值的信息。4. 数据流图实例拆解银行取款处理完整建模过程4.1 关联图画法实例分析银行取款处理的系统描述如下储户将填好的取款单、存折交银行银行做如下处理审核并查对账目将不合格的存折、取款单退回储户合格的存折、取款单送取款处理处理取款修改账目将存折、利息单、结算清单及现金交储户同时将取款单存档。现在要求画出该系统的数据流图。第一步画关联图。系统只有一个外部项就是储户数据来源和数据去处都是储户。注意一个关键点现金是实物不是数据不能作为数据流画在 DFD 中。因此系统的输入数据流是取款单、存折输出数据流是存折、利息单、结算清单现金虽然随输出一起交给储户但它是实物流转不写在数据流图中。许多初学者把现金画在图中这是概念性错误。------------------- | 取款单、存折 | | ------------ | | [取款处理系统] | | ------------ | | 存折、利息单、 | | 结算清单 | ------------------- ^ | S1 储户这里 S1 是储户的外部项编号关联图中的加工通常只写取款系统或取款处理系统不加编号因为关联图只是一个粗粒度视图系统作为一个整体加工存在。4.2 顶层图分解与数据存储的引入第二步将取款处理系统分解为两个加工P1取款审核和 P2取款处理。同时引入两个数据存储D1账目库和 D2取款记录。P1取款审核接收外部项储户发来的 F1取款单、存折根据 D1账目库对照查对。审核结果分为两条路径不合格的退给储户数据流命名为 F1.2不合格存折、取款单合格的进入 P2 取款处理数据流命名为 F1.1合格存折、取款单。P2 取款处理更新 D1账目库并往 D2取款记录写入取款信息最终输出 F2存折、利息单、结算清单返回储户。S1 储户 | F1 取款单、存折 v --------- F1.1 合格存折、取款单 ------------- | P1 | ----------------------------- | P2 | | 取款审核 | | 取款处理 | --------- ------------- | | | | | | F1.2 不合格存折、取款单 | | | v | | | S1 储户 v | | D1 账目库 | D2 取款记录图中 D1 既被 P1 读取查对账目又被 P2 更新修改账目同一个数据存储连接多个加工是常见且允许的。D2取款记录存储取款相关明细P2 向 D2 写入数据。数据流的编号并非必须四位连写可以按层编号父图编号与子图编号之间存在对应关系即可。4.3 图书预订系统的二层分解对比第二个实例是图书预订系统。书店向顾客发放订单顾客将所填订单交由系统处理系统首先依据图书目录对订单进行检查并对合格订单进行处理。处理过程中根据顾客情况和订单数目将订单分为优先订单与正常订单两种随时处理优先订单定期处理正常订单。最后系统根据所处理的订单汇总并按出版社要求发给出版社。关联图的外部项有 S1顾客和 S2出版社输入数据流是 F1订单输出数据流是 F2汇总订单。S1 顾客 S2 出版社 | F1 订单 ^ v | F2 汇总订单 ----------------------------------- | 图书预订系统 | -----------------------------------顶层图分解为三个加工P1订单检查、P2订单处理、P3发送订单。P1 依据 D1图书目录检查订单检查结果分为合格订单和不合格订单。不合格订单直接退回顾客合格订单流入 D2合格订单存储然后进入 P2订单处理。P2 内部需要进一步细分因为订单分类涉及顾客情况D5、订单数目D6等多方面判断通过一次分解无法得出基本加工因此需要画二层图。P2 分解为 P2.1数目统计、P2.2订单分类、P2.3随时处理、P2.4定期处理。P2.1 从 D2合格订单读取并统计订单数目形成 D5订单数目P2.2 根据 D6顾客情况和 D5订单数目对订单分类分成 D7优先订单和 D8正常订单P2.3 随时处理优先订单P2.4 定期处理正常订单。处理结果流入 D3待发出订单最终由 P3发送订单依据 D4出版社要求生成 F2汇总订单发给出版社。F1 订单 | v ------ 合格订单 ---------- | P1 | -------------- | D2 | |订单 | |合格订单 | ------ ---------- | | | 不合格订单 v | ---------- | | P2.1 | v |数目统计 | S1 顾客 ---------- | v ---------- | D5 | | 订单数目 | ---------- | v ---------------- | P2.2 | | 订单分类 | ---------------- 优先订单 | 正常订单 v v ----------- ----------- | D7 | | D8 | |优先订单 | |正常订单 | ----------- ----------- | | v v ----------- ----------- | P2.3 | | P2.4 | |随时处理 | |定期处理 | ----------- ----------- | | v v D3 待发出订单 | v ------ | P3 | |发送 | ------ | v F2 汇总订单 | v S2 出版社对比两个实例可以发现银行取款只需要两层分解而图书预订系统需要三层。分解深度取决于问题的复杂度没有固定层数要求。判定准则只有一条每个最低层加工的功能都足够简单能够用一句话清晰描述其处理逻辑且无需再分解。5. 绘制数据流图的检查清单常见错误与编号技巧5.1 检查数据流必须通过加工数据流图的布局规则中最硬性的一条是数据流必须通过加工。外部项与数据存储之间不能直接画数据流外部项与外部项之间也不能画数据流数据存储与数据存储之间同样不能直接画数据流。数据流要么连接外部项到加工要么连接加工到外部项要么连接加工到数据存储要么连接加工到加工。如果出现外部项直接读写数据存储的情况说明系统分析中遗漏了中间处理环节需要补上相应加工。检查方法是自上而下逐层核对每一条数据流的两个端点是否至少有一端是加工如果两个端点都不是加工就是错误的数据流。5.2 布局优化让图更易读数据流图的布局影响可读性。大致原则是外部项放在图的边缘左侧画源点右侧画终点加工按数据流的方向从左到右排列数据存储画在加工之间的下方或上方避免线条穿过符号实体。同一数据存储如果需要在图中多处引用可以在每个需要出现的位置都画一个相同编号的矩形符号这种重复绘制是允许的。数据存储重复非常重要交叉线增多时对可读性的破坏远大于重复保存数据存储的图形。编号时注意一个约定同一数据存储在不同层级的 DFD 中使用相同编号比如 D1账目库在顶层图和二层图中都是 D1。5.3 一个实用技巧数据流命名与编号的同步后面的回补中最后一个实用技巧是数据流编号的同步。每一层分解时先在一张草稿纸上列出父图中所有加工对应的输入输出数据流清单再在子图中逐项落实。例如父图中 P2订单处理的输入数据流是合格订单输出数据流是优先订单正常订单那么在 P2 的子图中外部的输入输出数据流名称必须严格沿用合格订单优先订单正常订单不能在子图中重命名为有效订单或高端订单。这是数据流图绘制中最容易出现的命名漂移问题。我习惯在画完一层图之后使用数据流清单做一次完整性校验在表格中逐行列出数据流名称、源点、终点然后与父图对照目标。这样做可以提前找出数据流不平衡的问题在评审之前解决问题减少后续修改返工。检查项检查方法错误典型数据流经过加工每个数据流至少一端连接加工外部项直接连数据存储分层平衡父图数据流与子图边界数据流一致子图出现父图没有的数据流编号唯一同一层内编号不重复两个加工同时编号 P2命名一致子图沿用父图的数据流名父图写合格订单子图写有效订单数据存储有数据流每个数据存储至少一条数据流数据存储没有被任何加工读取因果说明一点数据流图不表达处理顺序同层图中多个加工的排列位置也不表示执行的先后。如果在看数据流图时需要表达先做什么后做什么才能理解说明画图时把控制流混入了数据流这是需要特别注意的常见误区。本文还有配套的精品资源点击获取
