简介这是一份讲解数据流图DFD绘制方法的PPT教学资源适合系统分析与设计初学者、管理信息系统课程学生以及需要与用户沟通系统逻辑的分析人员。内容按数据流图构成、绘制步骤、绘制原则与注意事项、实例讲解等章节组织系统梳理了数据流、加工、数据存储、外部项四种基本要素的符号与命名规范并给出关联图、顶层图到逐层子图的分解思路。其中以银行取款处理为实例演示了从关联图到下层DFD的转化过程同时点明常见注意事项可帮助读者理解数据流必须通过加工、数据存储环节位置安排等易错问题。包体共1个PPT文件压缩包大小约312KB轻量易用。已有625人学习下载适合想快速掌握数据流图实操画法的入门与进阶读者。1. 数据流图画的是什么先分清“数据流”不是“业务流程图”很多人一听到“画数据流图”第一反应是打开绘图工具把业务环节一个个框起来箭头连来连去最后画出来的其实是业务流程图。数据流图DFD要回答的不是“事情按什么顺序做”而是“数据从哪里产生、经过哪些加工被改变、在哪些存储里停留、最终交给谁”。这个区别直接决定了一张图能不能帮开发团队定清楚系统边界和模块划分。画错方向后面做数据库设计、接口设计都会跟着跑偏。这篇笔记面向正在做系统分析、需求梳理或毕业设计的从业者目标是让你拿到一个业务场景能按一套固定步骤把顶层图、0层图一层层拆出来并且画完敢说“这张图是平衡的没漏数据”。2. 画数据流图前必须定清楚的三个边界外部实体、加工与数据存储2.1 外部实体怎么界定在系统边界外的人才算外部实体External Entity是数据流的起点或终点它本身不受当前系统管理。常见的是“人”角色和“外部系统”角色比如网购场景里的客户、仓库系统、支付网关。画图时用矩形表示命名直接写角色名不要写“用户”这种泛指词。判断一个对象该不该画成外部实体我一般用一句话自检这个对象的数据是否由当前系统负责存储和处理客户提交订单后订单存进我们的库所以客户是外部实体但订单表是我们自己维护的它就不能画在边界外。这里有个经典翻车有人把“数据库”当外部实体画在图的左上角画一个数据库方块和系统互相连线。这在逻辑上是错的数据库是实现层的东西在数据流图里它只对应数据存储符号应该在系统边界内而不是边界外。另一个常见误判是把同一个系统里的其他模块画成外部实体比如把“订单模块”和“库存模块”画成两个方块互相传数据。如果这两个模块都在同一个系统边界内那它们之间的数据传递应该通过加工和数据流来表达而不是外部实体。2.2 加工怎么切分动词命名一个加工必须有输入也有输出加工Process是数据流图的核心表示对数据的变换。命名必须用“动词宾语”的结构比如“校验订单”“计算金额”“生成发货单”不能叫“订单处理”这种看不出动作的短语。每一个加工都要有一个明确的输入数据流和输出数据流不能出现只有输入没有输出的“黑洞”也不能出现只有输出没有输入的“奇迹”。加工粒度的把握是新手最容易犹豫的地方。我常用的经验是一个加工对应一个可以被单独描述和验证的中间结果。如果一个动作拆开之后每一步都要产生独立的中间数据那就拆如果两个动作必须捆绑在一起才完整那就合并。比如“校验订单”和“计算订单金额”是两个能独立交付结果的加工拆开而“发送通知邮件并记录日志”两者必须同时发生合并成一个加工“登记并发送通知”。编号也要从一开始就养成习惯。顶层图里唯一的大加工编号为0往下拆一层加工编号变成1、2、3再往下拆编号用1.1、1.2、1.1.1这样的层次结构。这个编号体系不只是为了好看后面做父图子图平衡校验时全靠编号定位对应关系。2.3 数据存储怎么选能“停留”的数据才需要画数据存储Data Store用开口的矩形或两条平行线表示命名用数据集合名比如“订单表”“客户档案”“库存台账”。绘制原则只有一条数据流经过某个加工之后要保存下来供后续使用才需要画存储。临时变量、内存中的中间计算结果不落库就不画。一个需要特别留意的点是存储的读写平衡。每个数据存储至少应该有一条数据流流入、一条数据流流出。只有写入没有读出的存储说明这个数据存了没人用只有读出没有写入的存储说明这个数据来源不明——这两种情况在评审时都会被挑刺。我在画完一张图之后会逐个存储做一次检查谁往它里面写谁从它里面读如果答不上来就要回去补流。3. 从顶层图到0层图一张订单系统的数据流图绘制全步骤3.1 第0步先画上下文图把系统边界钉死上下文图顶层图是整个系统的一张总览只包含一个加工编号为0代表整个系统。外部实体围绕在它周围用数据流和它相连。这张图的目的是把“系统负责什么、不负责什么”一次说清楚。我画上下文图时习惯用 draw.io、Visio 或 ProcessOn 这类通用绘图工具。以下是一个订单处理系统的上下文图先看结构客户 ┌─────┴──────┐ │ 订单 │ 发货通知 ▼ ▼ ┌─────────────────┐ │ 订单处理系统 │ │ 加工编号0 │ └─────────────────┘ ▲ ▲ │ 库存余量 │ 缺货清单 └─────┬──────┘ 仓库外部实体一共两个客户和仓库。客户给系统传订单系统给客户回发货通知系统向仓库查询库存余量仓库把缺货清单交给系统。注意这里的数据流命名用的是“订单”“发货通知”“库存余量”“缺货清单”这样的具体数据名不是“数据”“信息”这种空泛词。上下文图的价值在于它逼你回答客户需不需要登录仓库算不算系统的一部分如果登录功能也在系统边界内那客户和系统之间可以再加一条“登录凭证”的数据流仓库如果自己有独立的库存管理能力它就是外部实体否则仓库这个角色可能要被吸收进系统内部成为加工。我一般建议把上下文图贴在需求文档第一页项目成员对系统边界有争议时回到这张图来吵比对着文字描述高效得多。3.2 第一层分解把系统内的核心加工拆出来上下文图确定之后把加工0展开成0层图。展开的原则是把所有必须发生的数据变换列出来按自然的先后顺序编号。订单处理系统可以拆成四个加工1 校验订单检查订单格式、必填项、客户是否存在2 锁定库存查询库存余量预占库存3 生成发货单汇总有效订单生成发货任务4 更新台账登记订单状态和发货记录拆完之后把外部实体、数据存储、数据流按照数据实际走向连接起来。0层图中外部实体保留数据存储首次出现。订单要最终写进订单表所以“校验订单”之后要有一条数据流指向“订单存储”库存操作要读写“库存台账”发货单则流入“发货存储”。画这一步时最常见的犹豫是加工数量。我常用的判断标准是把加工控制在 3 到 7 个之间。少于 3 个说明拆得太粗这一个加工内部还会有大量分支动作放过多于 7 个说明拆得太碎0 层图应该只展示系统的核心大环节细节留给下一层。加工数量一旦超过 7读者很难一眼看出数据的主流向评审时也没人愿意细看。3.3 连数据流每条连线都必须有名字且名字是数据名词连线的过程最容易出问题。数据流是箭头方向代表数据移动的方向但要注意它不是控制流。也就是说箭头不代表“做完A去做B”只代表“A产生的数据被B消费”。这个区别在评审时几乎每次都会被拿出来问。给数据流命名有三个硬性要求。第一名称必须是数据名词不能是动词短语。可以叫“有效订单”“库存余量”“发货通知”不能叫“确认订单”“发送通知”——那是加工的名字不是数据流的名字。第二同一个数据流在整张图上只能有一个名字不能上游叫“订单”、下游叫“客户订单”这会造成阅读混乱。第三数据流不能直接连接两个数据存储也不能直接从外部实体连到数据存储中间必须经过加工。数据只会被加工处理存储本身不消费数据。画完第一版之后拿这三点逐条过一遍能筛掉大部分低级问题。4. 数据流图实例对照订单系统完整拆解与平衡校验4.1 实例背景与上下文图以一个简化的订单处理系统为例。业务规则如下客户提交订单系统校验订单合法性校验通过后查询仓库库存库存充足则占库存并生成发货单发货单交给仓库执行订单状态登记到订单台账。仓库定期回传缺货清单。上下文图在上一章已经画出。这里直接进入0层图完整的图如下客户 ┌────────┼────────┐ │ 订单 │ │ 发货通知 ▼ │ ▲ ┌─────────┐ │ ┌──────────┐ │ 校验订单 │ │ │生成发货单│ └────┬────┘ │ └────┬─────┘ │ 有效订单│ │ 发货单 ▼ │ ▼ ┌─────────┐ │ ┌──────────┐ │ 锁定库存 │ │ │ 更新台账 │ └────┬────┘ │ └────┬─────┘ │ 占库结果│ │ 台账记录 ▼ │ ▼ ┌───────────────────────────┐ │ 订单存储 / 库存台账 │ └───────────────────────────┘ ▲ │ 缺货清单 ┌──┴──┐ │ 仓库 │ └─────┘这张图一共四个加工、两个数据存储、两个外部实体。对比上一章的上下文图外部实体种类没有变加工0被替换成了四个加工这就是“展开”的标准形态。4.2 关键数据流逐条核对画完0层图不能直接收工要逐条核对每条数据流的来源和去向。下表是这个实例的完整数据流清单数据流名称来源去向承载内容订单客户校验订单客户ID、商品ID、数量、金额有效订单校验订单锁定库存通过校验后的订单明细占库结果锁定库存更新台账库存占用状态、可用数量发货单更新台账生成发货单发货地址、商品明细、物流要求发货通知生成发货单客户发货时间、物流单号缺货清单锁定库存仓库缺货商品编号、缺口数量逐条核对时重点看三件事第一每一个加工至少有一条输入、一条输出四号加工“生成发货单”从更新台账拿数据输出给客户符合要求第二数据存储没有出现悬空“订单存储”同时被锁定库存写入和更新台账读取第三每条数据流的名字都是名词短语没有混入“确认”“检查”这类动词。4.3 父图子图平衡校验这是评审最看重的一关平衡校验是数据流图最核心的质量检查标准含义是父图上下文图中加工0的输入输出数据流必须和子图0层图中所有加工的输入输出数据流总和完全一致。不能父图只画了“订单”和“发货通知”两条子图里突然多出“缺货清单”指向仓库——那说明父图漏了边界。以上面的实例做核对上下文图中系统对外的数据流有四条客户→系统的“订单”、系统→客户的“发货通知”、系统→仓库的“缺货清单”、仓库→系统的“库存余量”。0层图中“订单”进入校验订单“发货通知”从生成发货单流出给客户“缺货清单”从锁定库存流出给仓库。库存余量这条在0层图中体现在“锁定库存”与仓库之间的双向交互里。这里有一个必须说透的细节上下文图里如果有“仓库→系统”的库存余量数据流0层图的对应位置必须能找到同名的数据流进入某个加工。如果找不到要么是0层图漏画要么是上下文图画多了。反过来的情况也一样0层图出现上下文图里没有的外部数据交互说明上下文图不完整需要回头补。我用一个笨办法保证不出错把上下文图的所有外部数据流名抄在一张纸上再在0层图里逐个打钩钩不上就是有问题。5. 数据流图的5个常见问题与避坑清单5.1 把控制信号画成数据流现象图中出现“校验成功”“库存不足”“处理完成”这样的箭头。原因把加工的执行结果当成了传输的数据混淆了数据流和控制流。解决控制信号不该出现在数据流图上。校验成功与否应该通过数据内容体现比如“有效订单”和“退回订单”是两条携带不同数据的流而不是一条“校验结果”流。画图时给自己立一个规矩箭头另一端必须是一个可以被保存、传输、处理的“东西”状态本身不是数据。5.2 父图子图输入输出不对齐现象上下文图只有三条进出系统的数据流0层图却出现了五条外部交互。原因画0层图时把新发现的数据流直接补上没有回头更新上下文图。解决每次画完子图用上一章的逐条对照法核对两边数据流。这个习惯一开始会有点繁琐但一张图从0层再往下拆到1层时如果没有这个校验层次越多错误越严重。等到拆了三四层再回头修基本等于重画。5.3 加工只有输入没有输出或者只有输出没有输入现象图上某个加工方框只进了一条数据流或者只出一条。原因拆加工时只关注了这个环节“做什么”没想清楚它“消费什么数据”和“产生什么数据”。很多情况下是因为中间步骤被当成了终点比如“记录日志”这种动作单独成框没有下游消费者。解决每个加工画完立即做局部检查输入数据从哪个外部实体或存储来输出数据去哪个加工或存储。如果输出数据最终只进日志存储而没有任何业务加工读它可以考虑合并到前一个加工里不要为了“完整性”强行保留孤立加工。5.4 数据流命名写成“数据”“信息”这类空词现象图上出现“数据流1”“信息”“结果”这种标注或者干脆连线不标注。原因画图时想先连线上色命名留到最后统一补结果忘了。解决数据流命名不要拖。每画一条线当场把名字写上名字要具体到能看出内容比如“客户地址变更单”“月度销售汇总”。空泛命名的图拿去评审基本是送审稿送命因为别人根本没法判断你数据流的内容是否合理。5.5 数据存储没有读写闭环现象某个数据存储只有箭头流入没有流出或者反过来只有读出没有写入。原因画图时只考虑了“这个数据要被保存”没追踪它后续被谁用。解决把每个存储看成一个人有人给它“喂”数据有人从它这里“取”数据。只喂不取是囤积只取不喂是凭空变数据。检查时从存储出发沿着反向箭头找源头沿着正向箭头找消耗者任何一端为空就要回到流程图补加工或补连边。这个检查放在整图画完后统一做效率最高。6. 从图到数据字典让数据流图能被开发直接读懂6.1 数据字典的基本格式数据流图画完之后还差最后一步才算真正落地配一张数据字典。数据字典的作用是给图里的每一个数据流、每一个存储定义“里面装的是什么”否则开发拿到图只知道“订单”这条流存在却不知道订单包括哪些字段。我常用的数据字典分两种条目。第一种是数据流条目字段包括数据流名、来源、去向、数据结构、备注。第二种是数据存储条目字段包括存储名、包含的数据结构、写入加工、读取加工。以下面的“订单”数据流为例条目项内容数据流名订单来源客户外部实体去向校验订单加工1数据结构订单编号 客户编号 商品编号 数量 金额备注客户从商城页面提交未经过任何加工字典写法有一个约定俗成的格式用加号连接各字段表示“同时包含”用竖线表示“任选其一”用大括号表示“重复出现”。比如“订单 订单编号 客户编号 {商品编号 数量} 金额”意思是一条订单包含一个订单号、一个客户号、多行商品明细和一笔总金额。这种表达方式简单直接评审时念一遍大家就能判断字段有没有漏。6.2 用字典做一致性的两层校验字典不是写出来给文档凑页数的它有两层校验作用。第一层每个数据流的数据结构必须能在它的来源加工或来源存储里找到对应字段。比如“有效订单”的数据结构里包含“库存占用量”那锁定库存加工的输入端必须有一条数据流能提供这个字段否则字典和图画不上等号。第二层跨层一致性。0层图的“发货单”数据流如果拆到1层图1层图里对应位置的“发货单”数据结构必须一致。如果加了字段必须在字典里标注“由加工3.2补充”这样不同人维护不同层次时能够追踪字段的演变过程。6.3 一个收尾习惯现在画数据流图的时候我习惯画完图先不急着看整体效果而是先重置一遍每个加工的编号和数据流名像拿着检查清单一样从头走一遍。这个习惯帮我挡掉过不止一次评审现场翻车尤其是在集体评审时别人一眼就能看到的问题往往不是复杂的设计问题而是命名不一致、父子图对不上的低级错误。图是给人看的能不能让人一眼就进入业务逻辑比画得多漂亮重要。希望这篇笔记能帮你少踩几个我踩过的坑。本文还有配套的精品资源点击获取
简介这是一份讲解数据流图DFD绘制方法的PPT教学资源适合系统分析与设计初学者、管理信息系统课程学生以及需要与用户沟通系统逻辑的分析人员。内容按数据流图构成、绘制步骤、绘制原则与注意事项、实例讲解等章节组织系统梳理了数据流、加工、数据存储、外部项四种基本要素的符号与命名规范并给出关联图、顶层图到逐层子图的分解思路。其中以银行取款处理为实例演示了从关联图到下层DFD的转化过程同时点明常见注意事项可帮助读者理解数据流必须通过加工、数据存储环节位置安排等易错问题。包体共1个PPT文件压缩包大小约312KB轻量易用。已有625人学习下载适合想快速掌握数据流图实操画法的入门与进阶读者。1. 数据流图画的是什么先分清“数据流”不是“业务流程图”很多人一听到“画数据流图”第一反应是打开绘图工具把业务环节一个个框起来箭头连来连去最后画出来的其实是业务流程图。数据流图DFD要回答的不是“事情按什么顺序做”而是“数据从哪里产生、经过哪些加工被改变、在哪些存储里停留、最终交给谁”。这个区别直接决定了一张图能不能帮开发团队定清楚系统边界和模块划分。画错方向后面做数据库设计、接口设计都会跟着跑偏。这篇笔记面向正在做系统分析、需求梳理或毕业设计的从业者目标是让你拿到一个业务场景能按一套固定步骤把顶层图、0层图一层层拆出来并且画完敢说“这张图是平衡的没漏数据”。2. 画数据流图前必须定清楚的三个边界外部实体、加工与数据存储2.1 外部实体怎么界定在系统边界外的人才算外部实体External Entity是数据流的起点或终点它本身不受当前系统管理。常见的是“人”角色和“外部系统”角色比如网购场景里的客户、仓库系统、支付网关。画图时用矩形表示命名直接写角色名不要写“用户”这种泛指词。判断一个对象该不该画成外部实体我一般用一句话自检这个对象的数据是否由当前系统负责存储和处理客户提交订单后订单存进我们的库所以客户是外部实体但订单表是我们自己维护的它就不能画在边界外。这里有个经典翻车有人把“数据库”当外部实体画在图的左上角画一个数据库方块和系统互相连线。这在逻辑上是错的数据库是实现层的东西在数据流图里它只对应数据存储符号应该在系统边界内而不是边界外。另一个常见误判是把同一个系统里的其他模块画成外部实体比如把“订单模块”和“库存模块”画成两个方块互相传数据。如果这两个模块都在同一个系统边界内那它们之间的数据传递应该通过加工和数据流来表达而不是外部实体。2.2 加工怎么切分动词命名一个加工必须有输入也有输出加工Process是数据流图的核心表示对数据的变换。命名必须用“动词宾语”的结构比如“校验订单”“计算金额”“生成发货单”不能叫“订单处理”这种看不出动作的短语。每一个加工都要有一个明确的输入数据流和输出数据流不能出现只有输入没有输出的“黑洞”也不能出现只有输出没有输入的“奇迹”。加工粒度的把握是新手最容易犹豫的地方。我常用的经验是一个加工对应一个可以被单独描述和验证的中间结果。如果一个动作拆开之后每一步都要产生独立的中间数据那就拆如果两个动作必须捆绑在一起才完整那就合并。比如“校验订单”和“计算订单金额”是两个能独立交付结果的加工拆开而“发送通知邮件并记录日志”两者必须同时发生合并成一个加工“登记并发送通知”。编号也要从一开始就养成习惯。顶层图里唯一的大加工编号为0往下拆一层加工编号变成1、2、3再往下拆编号用1.1、1.2、1.1.1这样的层次结构。这个编号体系不只是为了好看后面做父图子图平衡校验时全靠编号定位对应关系。2.3 数据存储怎么选能“停留”的数据才需要画数据存储Data Store用开口的矩形或两条平行线表示命名用数据集合名比如“订单表”“客户档案”“库存台账”。绘制原则只有一条数据流经过某个加工之后要保存下来供后续使用才需要画存储。临时变量、内存中的中间计算结果不落库就不画。一个需要特别留意的点是存储的读写平衡。每个数据存储至少应该有一条数据流流入、一条数据流流出。只有写入没有读出的存储说明这个数据存了没人用只有读出没有写入的存储说明这个数据来源不明——这两种情况在评审时都会被挑刺。我在画完一张图之后会逐个存储做一次检查谁往它里面写谁从它里面读如果答不上来就要回去补流。3. 从顶层图到0层图一张订单系统的数据流图绘制全步骤3.1 第0步先画上下文图把系统边界钉死上下文图顶层图是整个系统的一张总览只包含一个加工编号为0代表整个系统。外部实体围绕在它周围用数据流和它相连。这张图的目的是把“系统负责什么、不负责什么”一次说清楚。我画上下文图时习惯用 draw.io、Visio 或 ProcessOn 这类通用绘图工具。以下是一个订单处理系统的上下文图先看结构客户 ┌─────┴──────┐ │ 订单 │ 发货通知 ▼ ▼ ┌─────────────────┐ │ 订单处理系统 │ │ 加工编号0 │ └─────────────────┘ ▲ ▲ │ 库存余量 │ 缺货清单 └─────┬──────┘ 仓库外部实体一共两个客户和仓库。客户给系统传订单系统给客户回发货通知系统向仓库查询库存余量仓库把缺货清单交给系统。注意这里的数据流命名用的是“订单”“发货通知”“库存余量”“缺货清单”这样的具体数据名不是“数据”“信息”这种空泛词。上下文图的价值在于它逼你回答客户需不需要登录仓库算不算系统的一部分如果登录功能也在系统边界内那客户和系统之间可以再加一条“登录凭证”的数据流仓库如果自己有独立的库存管理能力它就是外部实体否则仓库这个角色可能要被吸收进系统内部成为加工。我一般建议把上下文图贴在需求文档第一页项目成员对系统边界有争议时回到这张图来吵比对着文字描述高效得多。3.2 第一层分解把系统内的核心加工拆出来上下文图确定之后把加工0展开成0层图。展开的原则是把所有必须发生的数据变换列出来按自然的先后顺序编号。订单处理系统可以拆成四个加工1 校验订单检查订单格式、必填项、客户是否存在2 锁定库存查询库存余量预占库存3 生成发货单汇总有效订单生成发货任务4 更新台账登记订单状态和发货记录拆完之后把外部实体、数据存储、数据流按照数据实际走向连接起来。0层图中外部实体保留数据存储首次出现。订单要最终写进订单表所以“校验订单”之后要有一条数据流指向“订单存储”库存操作要读写“库存台账”发货单则流入“发货存储”。画这一步时最常见的犹豫是加工数量。我常用的判断标准是把加工控制在 3 到 7 个之间。少于 3 个说明拆得太粗这一个加工内部还会有大量分支动作放过多于 7 个说明拆得太碎0 层图应该只展示系统的核心大环节细节留给下一层。加工数量一旦超过 7读者很难一眼看出数据的主流向评审时也没人愿意细看。3.3 连数据流每条连线都必须有名字且名字是数据名词连线的过程最容易出问题。数据流是箭头方向代表数据移动的方向但要注意它不是控制流。也就是说箭头不代表“做完A去做B”只代表“A产生的数据被B消费”。这个区别在评审时几乎每次都会被拿出来问。给数据流命名有三个硬性要求。第一名称必须是数据名词不能是动词短语。可以叫“有效订单”“库存余量”“发货通知”不能叫“确认订单”“发送通知”——那是加工的名字不是数据流的名字。第二同一个数据流在整张图上只能有一个名字不能上游叫“订单”、下游叫“客户订单”这会造成阅读混乱。第三数据流不能直接连接两个数据存储也不能直接从外部实体连到数据存储中间必须经过加工。数据只会被加工处理存储本身不消费数据。画完第一版之后拿这三点逐条过一遍能筛掉大部分低级问题。4. 数据流图实例对照订单系统完整拆解与平衡校验4.1 实例背景与上下文图以一个简化的订单处理系统为例。业务规则如下客户提交订单系统校验订单合法性校验通过后查询仓库库存库存充足则占库存并生成发货单发货单交给仓库执行订单状态登记到订单台账。仓库定期回传缺货清单。上下文图在上一章已经画出。这里直接进入0层图完整的图如下客户 ┌────────┼────────┐ │ 订单 │ │ 发货通知 ▼ │ ▲ ┌─────────┐ │ ┌──────────┐ │ 校验订单 │ │ │生成发货单│ └────┬────┘ │ └────┬─────┘ │ 有效订单│ │ 发货单 ▼ │ ▼ ┌─────────┐ │ ┌──────────┐ │ 锁定库存 │ │ │ 更新台账 │ └────┬────┘ │ └────┬─────┘ │ 占库结果│ │ 台账记录 ▼ │ ▼ ┌───────────────────────────┐ │ 订单存储 / 库存台账 │ └───────────────────────────┘ ▲ │ 缺货清单 ┌──┴──┐ │ 仓库 │ └─────┘这张图一共四个加工、两个数据存储、两个外部实体。对比上一章的上下文图外部实体种类没有变加工0被替换成了四个加工这就是“展开”的标准形态。4.2 关键数据流逐条核对画完0层图不能直接收工要逐条核对每条数据流的来源和去向。下表是这个实例的完整数据流清单数据流名称来源去向承载内容订单客户校验订单客户ID、商品ID、数量、金额有效订单校验订单锁定库存通过校验后的订单明细占库结果锁定库存更新台账库存占用状态、可用数量发货单更新台账生成发货单发货地址、商品明细、物流要求发货通知生成发货单客户发货时间、物流单号缺货清单锁定库存仓库缺货商品编号、缺口数量逐条核对时重点看三件事第一每一个加工至少有一条输入、一条输出四号加工“生成发货单”从更新台账拿数据输出给客户符合要求第二数据存储没有出现悬空“订单存储”同时被锁定库存写入和更新台账读取第三每条数据流的名字都是名词短语没有混入“确认”“检查”这类动词。4.3 父图子图平衡校验这是评审最看重的一关平衡校验是数据流图最核心的质量检查标准含义是父图上下文图中加工0的输入输出数据流必须和子图0层图中所有加工的输入输出数据流总和完全一致。不能父图只画了“订单”和“发货通知”两条子图里突然多出“缺货清单”指向仓库——那说明父图漏了边界。以上面的实例做核对上下文图中系统对外的数据流有四条客户→系统的“订单”、系统→客户的“发货通知”、系统→仓库的“缺货清单”、仓库→系统的“库存余量”。0层图中“订单”进入校验订单“发货通知”从生成发货单流出给客户“缺货清单”从锁定库存流出给仓库。库存余量这条在0层图中体现在“锁定库存”与仓库之间的双向交互里。这里有一个必须说透的细节上下文图里如果有“仓库→系统”的库存余量数据流0层图的对应位置必须能找到同名的数据流进入某个加工。如果找不到要么是0层图漏画要么是上下文图画多了。反过来的情况也一样0层图出现上下文图里没有的外部数据交互说明上下文图不完整需要回头补。我用一个笨办法保证不出错把上下文图的所有外部数据流名抄在一张纸上再在0层图里逐个打钩钩不上就是有问题。5. 数据流图的5个常见问题与避坑清单5.1 把控制信号画成数据流现象图中出现“校验成功”“库存不足”“处理完成”这样的箭头。原因把加工的执行结果当成了传输的数据混淆了数据流和控制流。解决控制信号不该出现在数据流图上。校验成功与否应该通过数据内容体现比如“有效订单”和“退回订单”是两条携带不同数据的流而不是一条“校验结果”流。画图时给自己立一个规矩箭头另一端必须是一个可以被保存、传输、处理的“东西”状态本身不是数据。5.2 父图子图输入输出不对齐现象上下文图只有三条进出系统的数据流0层图却出现了五条外部交互。原因画0层图时把新发现的数据流直接补上没有回头更新上下文图。解决每次画完子图用上一章的逐条对照法核对两边数据流。这个习惯一开始会有点繁琐但一张图从0层再往下拆到1层时如果没有这个校验层次越多错误越严重。等到拆了三四层再回头修基本等于重画。5.3 加工只有输入没有输出或者只有输出没有输入现象图上某个加工方框只进了一条数据流或者只出一条。原因拆加工时只关注了这个环节“做什么”没想清楚它“消费什么数据”和“产生什么数据”。很多情况下是因为中间步骤被当成了终点比如“记录日志”这种动作单独成框没有下游消费者。解决每个加工画完立即做局部检查输入数据从哪个外部实体或存储来输出数据去哪个加工或存储。如果输出数据最终只进日志存储而没有任何业务加工读它可以考虑合并到前一个加工里不要为了“完整性”强行保留孤立加工。5.4 数据流命名写成“数据”“信息”这类空词现象图上出现“数据流1”“信息”“结果”这种标注或者干脆连线不标注。原因画图时想先连线上色命名留到最后统一补结果忘了。解决数据流命名不要拖。每画一条线当场把名字写上名字要具体到能看出内容比如“客户地址变更单”“月度销售汇总”。空泛命名的图拿去评审基本是送审稿送命因为别人根本没法判断你数据流的内容是否合理。5.5 数据存储没有读写闭环现象某个数据存储只有箭头流入没有流出或者反过来只有读出没有写入。原因画图时只考虑了“这个数据要被保存”没追踪它后续被谁用。解决把每个存储看成一个人有人给它“喂”数据有人从它这里“取”数据。只喂不取是囤积只取不喂是凭空变数据。检查时从存储出发沿着反向箭头找源头沿着正向箭头找消耗者任何一端为空就要回到流程图补加工或补连边。这个检查放在整图画完后统一做效率最高。6. 从图到数据字典让数据流图能被开发直接读懂6.1 数据字典的基本格式数据流图画完之后还差最后一步才算真正落地配一张数据字典。数据字典的作用是给图里的每一个数据流、每一个存储定义“里面装的是什么”否则开发拿到图只知道“订单”这条流存在却不知道订单包括哪些字段。我常用的数据字典分两种条目。第一种是数据流条目字段包括数据流名、来源、去向、数据结构、备注。第二种是数据存储条目字段包括存储名、包含的数据结构、写入加工、读取加工。以下面的“订单”数据流为例条目项内容数据流名订单来源客户外部实体去向校验订单加工1数据结构订单编号 客户编号 商品编号 数量 金额备注客户从商城页面提交未经过任何加工字典写法有一个约定俗成的格式用加号连接各字段表示“同时包含”用竖线表示“任选其一”用大括号表示“重复出现”。比如“订单 订单编号 客户编号 {商品编号 数量} 金额”意思是一条订单包含一个订单号、一个客户号、多行商品明细和一笔总金额。这种表达方式简单直接评审时念一遍大家就能判断字段有没有漏。6.2 用字典做一致性的两层校验字典不是写出来给文档凑页数的它有两层校验作用。第一层每个数据流的数据结构必须能在它的来源加工或来源存储里找到对应字段。比如“有效订单”的数据结构里包含“库存占用量”那锁定库存加工的输入端必须有一条数据流能提供这个字段否则字典和图画不上等号。第二层跨层一致性。0层图的“发货单”数据流如果拆到1层图1层图里对应位置的“发货单”数据结构必须一致。如果加了字段必须在字典里标注“由加工3.2补充”这样不同人维护不同层次时能够追踪字段的演变过程。6.3 一个收尾习惯现在画数据流图的时候我习惯画完图先不急着看整体效果而是先重置一遍每个加工的编号和数据流名像拿着检查清单一样从头走一遍。这个习惯帮我挡掉过不止一次评审现场翻车尤其是在集体评审时别人一眼就能看到的问题往往不是复杂的设计问题而是命名不一致、父子图对不上的低级错误。图是给人看的能不能让人一眼就进入业务逻辑比画得多漂亮重要。希望这篇笔记能帮你少踩几个我踩过的坑。本文还有配套的精品资源点击获取
