画数据流图这件事说难不难说简单也真不简单。我见过太多人拿到一份需求文档打开 Visio 就往画布上拖方框半小时画完一张图评审会上被问三句话就答不上来这条数据从哪来、到哪去、中间谁加工的更尴尬的是图上明明画了五个加工翻到下一层却只画出来四个父图和子图对不上整张 UML 相关的图集直接失去参考价值。数据流图DFD本身不是装饰品它是用来跟业务方、开发、测试三方对齐数据怎么流动、在哪儿被加工、落到哪个存储的工具。这篇内容我打算把从零到能交付的完整路径讲清楚包括图元选型、分层规则、平衡校验、Visio 落地操作以及我自己踩过的那些坑。无论你是刚接触需求分析的新人还是画了几年图但总觉得差点意思的老手都能从里面找到能直接拿去用的东西。1. 先搞清楚数据流图的定位它到底画什么、给谁看在动手拖第一个方框之前得先把这张图的身份说清楚。很多新手上来就画细节画完之后自己都说不清这张图要表达什么评审的人自然也看不懂。数据流图的核心使命只有一句话描述数据在系统边界内外如何流动、在哪里被加工、最终落到哪个数据存储。它不关心类与类之间的继承关系也不关心对象在运行时的生命周期它关心的是数据这条主线。把这层定位想明白后面的符号选择、分层策略、命名规范才有依据可循否则画出来的东西既不像 DFD也不像流程图四不像。1.1 数据流图不在 UML 十四种图里为什么还总被放在一起讲这是个挺容易被忽略的知识点但我觉得必须先把话说在前面UML 2.5 规范里正式定义的图有十四种包括类图、对象图、包图、组合结构图、组件图、部署图、用例图、活动图、状态机图、序列图、通信图、交互概览图、定时图、制品图。数据流图不在这十四种之列它属于结构化分析方法SA/SD时代的产物Yourdon、DeMarco、Gane-Sarson 这些方法学才是它的老家。那你可能会问为什么网上一搜UML 数据流图出来的教程一大堆把两者混着讲原因很现实企业里做需求分析的人往往是先用 UML 的用例图框定范围再用数据流图把数据层面的细节铺开两套工具在同一个项目文档里并存久而久之就被打包成一门需求建模课来讲了。我个人的做法是把它们当成互补而不是同类。用例图回答谁用系统做什么事数据流图回答做这件事的时候数据怎么走。举个常见的例子一个订单系统用例图上画的是顾客提交订单客服审核订单这两个用例但数据流图上你要画的是订单信息从顾客这个外部实体流向接收订单这个加工加工后拆出待审订单写入订单存储再由审核订单加工读取并输出审核结果。这两张图讲的是同一件事的两个侧面硬要把 DFD 塞进 UML 的十四种图里只会让你在选择图元的时候自我怀疑。所以我在团队内部培训时会明确告诉新人DFD 是结构化分析的工具跟 UML 是邻居不是亲戚放心用。还有一点值得强调UML 1.x 时代确实有过一些模糊地带活动图在早期被拿来兼职做数据流表达但那是历史遗留现在没人这么干。活动图讲的是控制流和并发重点在步骤的先后和分支条件数据流图讲的是数据流重点在数据的来源去向和加工归属。你要是拿活动图去画数据流会发现存储这个东西根本没法自然表达最后只能靠注释硬凑评审的时候别人一眼就能看出别扭。1.2 一张图讲清DFD 与用例图、类图、包图的分工从业这些年我发现真正让人卡住的不是某个符号怎么画而是不知道手上这堆图该怎么配合。这里我给一套我自己常用的分工逻辑简单粗暴但很好用用例图负责圈定系统边界和参与者回答系统为谁服务、提供哪些功能块。它是所有后续建模的起点。数据流图负责把每个用例内部的数据流转展开回答输入什么、加工什么、输出什么、存到哪。类图负责把数据流图里出现的数据存储和数据流结构化成实体类、属性、关联关系。包图负责把类图里数量爆炸的类按业务域分组回答哪一堆类属于哪个模块。这套顺序不是死规矩但它符合从粗到细、从行为到结构的认知路径。我见过有人反过来先画类图再反推数据流图结果类图里的方法名和 DFD 的加工名完全对不上两份文档像来自两个项目。顺序反了不代表一定错但返工成本会明显上升。举个具体场景做一个图书借阅系统用例图上你先圈出借书还书查询馆藏三个用例数据流图上你把借书展开看到借阅请求从读者流向校验借阅资格加工合格后生成借阅记录写入借阅存储同时更新图书状态到了类图阶段你就很自然地知道需要 Reader、Book、BorrowRecord 这几个实体类以及它们之间的关联。整个过程是顺的中间不用来回猜。再补一句关于包图。很多人觉得包图是画着玩的其实当你的类图超过三四十个类之后没有包图就是灾难。而包怎么分最靠谱的依据之一就是数据流图里的加工划分——一个大的加工往往对应一个业务域这个业务域上的数据存储和加工涉及的实体天然就该聚到一个包里。这个思路我后面第 5 章还会展开讲。2. 四种图元与两条流派选型、命名与最容易翻车的细节符号这块看起来是最简单的实际上新手翻车率最高的地方就在这里。数据流图只有四种基本图元外部实体、加工、数据存储、数据流。数量少但每一种都有讲究而且存在两套主流符号体系混用是常见病。更重要的是命名一张图能不能被别人看懂八成取决于命名是否规范。这一章我把图元语义、流派选择、命名规则一次讲透后面画图的时候你就不会在这个圆还是圆角矩形这种问题上浪费时间。2.1 外部实体、加工、数据存储、数据流各自代表什么先说外部实体。它代表系统边界之外、与系统有数据交互的人、组织或外部系统。注意关键词是之外凡是系统自己要开发的模块一律不能画成外部实体。我见过有人把数据库画成外部实体这就错了数据库如果是自己设计的它属于数据存储。外部实体在图上通常用矩形表示命名用名词比如顾客财务系统银行接口。这里有个小经验外部实体的名字要具体到角色不要写用户这种泛称因为一个系统里往往有多个角色写用户等于没写。加工也有人叫处理或变换代表对数据做的一次操作它必须有输入也有输出而且输出是由输入经过某种逻辑产生的。加工的命名是动宾结构比如校验订单计算运费生成对账单。这一点极其重要我后面 2.3 节细讲。加工在图上用一个圆圈或者圆角矩形表示具体用哪个取决于你选的流派。数据存储代表数据静止存放的地方可以是数据库表、文件、甚至一张纸质台账。它用两条平行线或者一个开口矩形表示。数据存储的命名用名词比如订单表用户档案日志文件。这里有个关键规则数据存储不能直接和外部实体相连也不能直接和另一个数据存储相连中间必须经过加工。原因很直观——数据不会自己从人手里跳进数据库一定有个加工在搬运和转换它。数据流代表数据在以上三者之间的移动方向用带箭头的线表示。它的命名必须是名词或者名词短语比如订单信息审核结果查询条件。箭头方向就是数据流向不能画双向箭头除非真的是双向交互且你明确标注了两组数据因为单向是数据流图的默认约定双向箭头会让读者搞不清哪条数据往哪走。2.2 Yourdon 与 Gane-Sarson 该选哪套符号不能混用这是很多人不知道的一个历史遗留问题。数据流图有两套主流符号体系一套是 Yourdon/DeMarco 风格加工用圆圈数据存储用两条平行线另一套是 Gane-Sarson 风格加工用圆角矩形数据存储用开口矩形右边不封口。两套体系本身没有优劣就是历史演化出来的两种表达习惯。但问题是你在同一张图上绝对不能用混否则读者会以为圆圈和圆角矩形代表两种不同类型的加工那就乱套了。那到底选哪套我的建议是看团队和工具。如果你用 Visio 画Visio 的数据流图模具里两套都有不同版本中文名可能是数据流图或数据流模型图里面分 Yourdon 和 Gane-Sarson 两套形状选一套用到底就行。国内多数教材和考试用的是 Gane-Sarson也就是圆角矩形代表加工考试和论文里用它比较稳妥。如果是跟业务方沟通Gane-Sarson 的圆角矩形看起来更像一块处理模块直观一些。Yourdon 的圆圈在老一辈系统分析文档里更常见如果你在维护历史文档跟着原来的风格走就好。这里插一句我踩过的坑。早年我带的一个项目甲方给的参考文档是 Yourdon 风格我图省事用了 Gane-Sarson 画结果评审时甲方专家第一句话就是你这个圆角矩形是什么加工还是存储——因为他们的阅读习惯里加工就是圆圈。那次之后我养成一个习惯新项目开始前先确认符号体系写进文档模板里避免后面全员各画各的。工具层面的操作也很简单Visio 里拖形状之前先确定好模具来源不要一半从 Yourdon 模具拖、一半从 Gane-Sarson 模具拖。2.3 命名规范加工用动宾数据流用名词命名的质量直接决定图的可用性。我总结了几条硬规则基本可以覆盖绝大多数场景。加工一律用动词名词结构。写校验订单而不是订单校验写计算运费而不是运费计算。为什么强调这个因为加工的本质是一个动作动宾结构一眼就能让人知道这里发生了什么事。写成名词短语读者会把它误认为数据存储。我见过最离谱的一张图上面五个加工分别叫用户信息订单信息库存信息支付信息日志看完完全不知道每一步在干什么这张图基本等于废纸。数据流一律用名词或名词短语。写订单信息审核结果查询条件不要写提交订单校验通过。因为数据流是流过去的东西它是数据不是动作。这里有个细节流入加工的数据流和流出加工的数据流最好能体现出状态的差异比如流入叫原始订单流出叫已校验订单这样读者一眼就知道加工做了什么。如果流入流出都叫订单信息说明这个加工可能什么都没干值得警惕。数据存储用名词并且要能对应到物理表或者文件。写订单表用户档案写出来之后你心里要清楚它对应数据库里哪张表如果对应不上说明你的存储划分有问题。外部实体用具体角色名这个前面说过了。最后说一个组合技巧给数据流编号。特别是在复杂的 0 层图里数据流的名字重复率很高加个编号方便做平衡校验。比如 F1 订单信息、F2 审核结果子图里沿用同样的编号父图子图对照起来一目了然。这个做法不是标准强制要求但实务中非常好用我后面第 4 章讲平衡检查的时候会用到。3. 从上下文图到逐层分解一次完整的实操推演这一章是整篇的重头戏。前面讲的是概念和规则这里我要带你完整走一遍从上下文图到多层分解的全过程用一个具体案例把每一步的操作、判断依据和容易出问题的地方都摊开。我选的案例是图书借阅管理系统中等复杂度既不会简单到没东西可讲也不会复杂到把读者绕晕。整个推演过程你完全可以套用到自己的项目上。3.1 上下文数据流图一个圆圈定边界上下文数据流图也叫顶层图是整个分层结构的第一张图。它的画法极其简单把整个系统当作一个加工通常编号为 0画在正中间然后把它所有的外部实体画在四周用数据流把外部实体和这个中心加工连起来。没有数据存储没有内部加工细节就这么干净。简单归简单但它是全套图里最重要的一张因为它一次性把系统边界定死了。哪些东西在系统内、哪些在系统外全在这张图上体现。我通常的做法是先做一次实体清单盘点把所有会跟系统交换数据的角色列出来然后逐个问自己这个角色的数据是进入系统被处理还是从系统取走结果还是两者都有。以图书借阅系统为例读者要提交借阅请求、查询借阅记录管理员要维护图书信息、处理归还可能还有一个财务系统接收逾期罚款数据。那么外部实体就是读者、管理员、财务系统三个。注意上下文图里绝对不能出现数据存储。一旦你在这一层画了数据库说明你在做系统内部设计不是在做上下文定义这张图就失去定边界的意义了。这一步我有个独家的小技巧数据流的方向和名称在上下文图里就要规范到位。很多人在这层随便写个数据就完事到了 0 层图想对齐的时候发现对不上。我建议在这一层就把数据流命名成具体的东西比如读者流向系统的叫借阅请求系统流向读者的叫借阅结果管理员流向系统的叫图书维护信息系统流向管理员的叫借阅统计报表。这些名字在后续的每一层都要原样沿用这就是后面平衡校验的基础。还有一个判断边界的方法我自己常用问自己这个东西是不是我们团队要开发的。如果答案是是它就在系统里面不能画成外部实体。如果答案是不是别人提供的那它才是外部实体。比如短信通知服务、第三方支付渠道这些是外部的画成外部实体而系统自己维护的订单库、用户库属于数据存储属于系统内部。3.2 0 层图分解与父子平衡原则上下文图画完之后下一步是把它展开成 0 层图。所谓展开就是把中心那个编号为 0 的大加工拆成若干个具体的加工编号 1、2、3……同时把上下文图里连着中心加工的每一条数据流重新接到对应的具体加工上。拆几个加工合适经验值是一张图里控制在 3 到 7 个最多不超过 9 个。这个数字不是随便定的来源于人的短期记忆容量限制超过这个数量读者就需要反复翻看才能理清逻辑。如果你发现拆出来十多个说明颗粒度太细应该先合并成几个大块把细的留到下一层。以图书借阅系统为例0 层图我一般拆成三个加工1 处理借阅、2 处理归还、3 维护图书信息。然后开始接线。读者这个外部实体的借阅请求流向加工 1加工 1 输出借阅结果给读者。管理员流向加工 3 的图书维护信息加工 3 输出维护确认给管理员。加工 2 处理归还输出逾期信息给财务系统。到这里还没完加工之间也需要数据流加工 1 需要读取图书的可借状态加工 2 归还后要更新图书状态所以加工 1 和加工 3 之间、加工 2 和加工 3 之间都有数据流联系。现在讲平衡这是数据流图里最容易出错、也最能体现专业度的地方。平衡原则说的是父图和子图在边界上的数据流必须完全一致。具体来说上下文图里借阅请求从读者流向系统 0那么 0 层图里就必须有一条借阅请求从读者流向加工 1或者某个具体的加工数量和方向都要对得上。不能多也不能少。多了说明你凭空造了一条数据流来源不明少了说明你丢了一条数据数据凭空消失。注意平衡检查只检查跨层边界的数据流图内部的细节数据流不需要在父图里出现。判断方法很简单看这条数据流的起点和终点是否都在同一层里如果一端在上一层、一端在本层它就属于边界数据流必须平衡。我做过统计新手画的 DFD 里超过一半的问题都出在平衡上。最常见的是多出一条。比如上下文图上系统只输出了借阅结果给读者但 0 层图里加工 1 和加工 2 各输出一条给读者名字还不一样一条叫借阅结果一条叫归还确认。这时候读者这个外部实体在 0 层图上有两条入向数据流跟上下文图对不上了。解决办法有两个要么回到上下文图把两条都补上去要么在 0 层图里把两条合并成一条。选哪个取决于业务上是否真的是两类不同的反馈如果归还后是另一套通知逻辑那就补上去如果只是借阅结果的两种呈现就合并。3.3 用 Visio 把这套图画成可交付的成果规则讲完了落到工具上。Visio 是国内画数据流图最常用的工具之一我把它画一套可交付 DFD 的流程拆成几个步骤你照着做就行。第一步选对模板。打开 Visio新建的时候在类别里找软件和数据库不同版本叫法略有差异里面会有数据流图或数据流模型图相关的模板。如果找不到现成的 DFD 模板用空白绘图再手动打开数据流图形状模具也可以。这一步的关键是找到 Gane-Sarson 或 Yourdon 的两套形状确定好之后一套用到底。第二步设定页面。数据流图往往横向铺得比较开我习惯一开始就把页面设成 A3 横向或者自定义更大的尺寸省得后面图形挤在一起。页面设好之后打开网格和对齐功能图形对齐会让整张图看起来专业很多。Visio 的视图菜单里有网格、标尺、参考线全打开。第三步放置图元。先把外部实体拖到画布四周改好名字再把加工拖到中间右键形状可以设置编号Visio 的 DFD 模具里的加工形状通常带有编号属性或者你手动在文字里加前缀1.。数据存储拖到合适位置。这里提醒一句图元的位置不是随便放的习惯上外部实体贴边放加工放中间数据存储一般放在加工下方或者两侧。这样读者扫一眼就知道哪是边界、哪是核心。第四步连线。Visio 里用连接线工具画数据流关键是要让线自动吸附到形状的连接点上形状边缘会出现小叉号连上去就吸附了。吸附之后移动形状时线会跟着走不会断开。连线的箭头方向默认从起点指向终点方向反了就在右键菜单里翻转。连好之后双击连线输入数据流名称名称要放在线的旁边不要压在线上Visio 里可以拖动标签位置。第五步分层组织。我的做法是一层图用一个页面Page页面名就叫上下文图0层图1层图-处理借阅这样导出 PDF 的时候目录很清晰。Visio 页面右键可以重命名也可以在页面设置里加上页面编号导出时自动生成页码。第六步导出交付。评审用的版本我一般导出成 PDF矢量格式放大不糊如果对方要放进 Word 文档就用另存为选 PNG 图片分辨率给到 300dpi 以上。还有一种方式是在 Visio 里选中所有图形复制然后粘贴到 Word 里这样粘贴过去的是可编辑的 Visio 对象对方还能改但缺点是文件会变大而且换台电脑可能显示不全所以我更推荐 PDF 或者 PNG。提示Visio 的 DFD 形状拖出来之后文字默认在图形中间加工和存储还好外部实体和连接线的文字记得调整位置尤其是连接线的标签默认会叠在线上一定要拖到线的上方或者下方不然打印出来看不清。关于工具选择我再补一句。Visio 是付费软件如果是个人学习或者小团队draw.io现在叫 diagrams.net也是很好的替代品它内置了数据流图的形状库操作逻辑跟 Visio 接近而且支持存到本地文件。选择工具的核心标准只有一个能不能稳定地画出四种图元并且方便连线。别在工具上纠结太久图的内容质量比工具华丽程度重要得多。4. 高频翻车现场黑洞、奇迹与灰洞的排查手册图画完了不等于画对了数据流图有一套自己的体检标准其中最关键的是四类结构性错误。这四类错误有个很形象的叫法黑洞、奇迹、灰洞还有一类是非法连接。这一章我把它们逐个拆解再给一张速查表你画完之后对着检查一遍能挡掉大部分低级问题。4.1 四类结构性错误的识别与修复先说黑洞。黑洞指的是一个加工只有输入没有输出数据进去就没了像掉进黑洞一样。出现这种情况通常有两种原因一是这个加工的产出被漏画了比如校验订单校验完应该有校验结果输出你可能忘了画二是这个加工本身就不该存在它可能是一个纯查询动作输入是查询条件输出是查询结果如果两者都没画那它就没意义。修复办法就是补上输出数据流如果实在没有输出就把这个加工删掉说明它是多余的。奇迹正好相反加工只有输出没有输入数据凭空产生。这个在现实中不可能发生除非这个加工是系统初始化的种子数据生成器那也要明确标注出数据来源。处理方法一样补上输入这条线。我见过一个案例图上有个加工叫生成月度报表只连了一条月度报表输出没有输入。评审时被问数据从哪来作者说从数据库读的那就应该画一条从数据存储到加工的订单数据输入线。这就是典型的漏画输入。灰洞是最隐蔽的一类。灰洞指的是输入有了、输出也有但输入的数据量或信息量不足以产生输出。举个抽象的例子一个加工叫计算员工工资输入只有员工基本信息输出是工资单。信息量显然不够至少还需要考勤记录薪资标准这些输入。灰洞不像前两类那样一眼能看出来需要你对着加工的业务逻辑逐条追问要完成这件事最少需要哪些数据。我自己排查灰洞的方法是假装自己是执行这个加工的工程师把输入的数据摊在桌上问自己就靠这些我能不能做出输出来做不出来就是灰洞。第四类是非法连接。前面提过数据存储不能直接连外部实体也不能直接连另一个数据存储外部实体之间也不能直接相连。我见过有人画顾客→订单表一条直线觉得顾客的信息存进订单表了但中间缺了录入订单这个加工这就是非法连接。修复方法很简单中间插一个加工。注意这四类错误在评审时是硬伤尤其是黑洞和非法连接评审人一眼就能看出来。我的习惯是画完图先自查一遍用下面这张表过一遍再交出去。错误类型表现特征常见成因修复动作黑洞加工有输入无输出漏画产出数据流、加工多余补输出线或删除加工奇迹加工有输出无输入漏画来源数据流补输入线标明来源灰洞输入输出都有但信息不足业务逻辑梳理不完整追问最少必要输入并补齐非法连接存储直连实体、存储直连存储、实体直连实体概念混淆、赶工中间插入合适的加工4.2 常见问题速查表与独家避坑技巧除了上面四类结构性错误还有一些高频问题值得单独拎出来说。我把它们整理成一张速查表方便你按图索骥。问题现象排查方向处理建议加工数量超过十个颗粒度太细合并成 3 到 7 个大加工细节下放父图子图对不上平衡性被破坏逐条核对边界数据流多删少补数据流名字重复但含义不同命名过于笼统加限定词如原始订单和已审订单数据存储没有对应物理表存储划分不清回头跟数据库设计对齐该拆就拆一个加工命名像名词命名结构错误改成动宾结构动词在前双向箭头满天飞方向约定不清拆成两条单向数据流各自命名图里出现流程判断框混淆 DFD 和流程图判断逻辑不体现在 DFD另附说明编号混乱不连续分层管理缺失统一用 1、1.1、1.1.1 的层级编号这张表我基本是每次项目都拿出来过一遍尤其是图里出现流程判断框这一条特别常见。很多人画着画着就把菱形判断框拖出来了这是把 DFD 和流程图混了。数据流图不表达控制逻辑判断条件、循环、分支这些东西应该在加工说明小说明或者活动图里体现不要画在 DFD 上。如果实在需要表达加工内部的复杂逻辑我会在加工旁边挂一个编号然后另起一页写加工说明用结构化语言或者判定表来描述这样图面干净逻辑也不丢。再分享几个我自己的实战技巧。第一个是关于评审呈现我会在每张图的角落放一个数据流清单小表格列出这张图上所有数据流的编号和名称评审时逐条对照效率非常高。第二个是关于版本管理Visio 文件不要只保留最终版每一轮评审后的版本单独存一份文件名带上日期因为后面写详细设计文档的时候经常要回溯某一版是怎么定义的。第三个是关于协作如果多人一起画一定要先约定好形状模具来源和命名风格我见过两个人合作画一张图一个人用圆角矩形一个人用圆圈合到一起就废了。还有一个容易被忽略的点数据流图最好不要一次画到底。正确的节奏是先画上下文图跟业务方确认边界确认完了再往下分解 0 层再确认再往下。每层确认一次比一口气画完五层再被人推翻要省事得多。我吃过这个亏一个项目上来就画了三层结果业务方看到第一张上下文图就说这个外部实体不对我们不走人工审核是系统自动对接的后面两层全白画。分层确认这个习惯能帮你省掉大量返工。5. 数据流图和 UML 家族其他图的衔接打法前面四章基本把数据流图讲圆了但实际项目里它从来不是孤立存在的。数据流图跟你熟悉的用例图、类图、包图之间有清晰的上下游关系理清这条链路你的整套建模文档才算闭合而不是一堆各自为政的图。这一章讲怎么衔接重点在映射方法和衔接时的检查点。5.1 用例图到数据流图的映射路径用例图和数据流图的衔接点在于每个用例都可以展开成一张或者一组数据流片段。我通常的做法不是在图上做映射而是用一张对照表做桥接。表格的左列是用例名右列是它对应的加工编号和数据存储。以图书借阅系统为例用例借书对应 0 层图的加工 1处理借阅涉及的数据存储是图书档案和借阅记录用例还书对应加工 2处理归还涉及借阅记录和图书档案用例查询馆藏对应加工 3 的一部分只读不写涉及图书档案。这张对照表的价值在于两个地方。一是保证用例不遗漏凡是用例图上的用例数据流图上都应该能找到对应的加工找不到就说明要么用例是纯查询不需要加工要么是你漏画了。二是反过来验证加工不多余凡是数据流图上的加工都应该能追溯到至少一个用例如果某个加工在用例图上找不到出处那它可能是不该存在的内部细节或者是需求漏了。我做过一个统计用这种方法能揪出大约一到两成的遗漏或冗余效果挺明显。提示查询类用例在数据流图上通常表现为读数据存储不产生写操作。画的时候别硬给它编造一个写入动作读就是读图面要如实反映。还有一点值得说用例图里的包含和扩展关系怎么在数据流图上体现其实数据流图不表达用例的这种关系它只关心数据流。如果你有个用例是审核订单另一个用例是批量审核两者的数据流大同小异你在数据流图上完全可以画一个审核订单加工然后在加工说明里注明支持单个和批量两种方式。不要为了在 DFD 上体现用例关系而硬造两个几乎一样的加工那样只会让图变丑。5.2 数据流图的产物怎么喂给类图和包图数据流图往下走就是类图和包图。这中间的转换方法很简单我总结成三步。第一步把数据存储映射成实体类或者持久化类。每一个数据存储比如订单表它对应的就是一个订单实体类。数据存储里存了哪些字段就是类的哪些属性。这里要注意数据流图上的存储是逻辑概念类图是面向对象的中间可能有拆分或合并比如订单表和订单明细表在数据流图上可能分别画在类图上可能用聚合关系表达。这是正常的不用强求一一对应。第二步把数据流映射成类之间的方法参数或者关联关系。数据流订单信息从接收订单加工流向订单表存储对应到类图上就是订单服务类的 createOrder 方法接收订单信息作为参数并把它持久化为订单对象。这个映射不是机械的需要你判断数据流是参数还是关联判断标准是看这条数据流是不是长期存在于对象之间。第三步用加工划分来指导包图。这是我觉得最有价值的一条。数据流图上的每一个大加工往往对应一个业务模块这个模块涉及的所有实体类、服务类天然就应该聚到一个包里。图书借阅系统里加工处理借阅涉及 Reader、Book、BorrowRecord 三个实体和一些服务类那就可以建一个 borrow 包处理归还涉及 BorrowRecord、FineRecord可以建一个 return 包。当然Reader、Book 这种跨模块共用的类通常放在一个公共包里单独管理。这套衔接方法还有一个附带的好处它帮你做分层架构设计了。数据流图上的数据存储和加工的关系天然就体现了哪些是数据层、哪些是业务层、哪些是表示层。数据存储属于数据层加工属于业务层外部实体跟系统的交互界面属于表示层。你画完 DFD分层架构的雏形基本上就有了不用另外拍脑袋。最后再说一句包图的判据。很多人分包的依据是看哪个类跟哪个类关系近这个方法在类少的时候还行类一多就乱。用数据流图的加工作为一阶划分依据再用类之间的关系做调整是我这些年用得最顺的方式。它既有业务语义支撑又能跟需求文档里的模块划分对上评审的时候解释起来也理直气壮。我在实际项目里最深的体会是数据流图这东西工具会过时符号体系会变化但数据从哪来、经过什么加工、放到哪里去这三问是不会变的。把这套思维练熟了就算哪天换了一个全新的建模工具你一样能快速把图建起来。所以别急着追求图好看先把逻辑跑通图画得丑一点但数据流转清晰比画得漂亮却对不上平衡要好得多。