用 Visio 画网上书店数据流图：从外部实体识别到分层平衡与 PDF 交付

简介这是一份面向软件工程学习者的Visio绘图实践教程PDF围绕网上书店系统数据流图绘制展开。文档以Gane-Sarson符号为基础依次讲解顶层、中层、底层三层数据流图的分析思路并演示如何利用Visio 2007的拖曳式绘图完成图元绘制、文字编辑、连线连接与布局调整适合系统分析与设计课程作业参考或自学入门。资源为单个PDF文件压缩包大小857KB已有5320人学习。内容不仅给出网上书店系统的外部用户游客、会员、管理员划分还梳理了用户注册、订单信息查询、书籍信息查询、订购图书、订单信息管理和图书信息管理等主要功能模块并附带订购图书、订单信息查询等底层数据流图示例。通过这份资料读者可以快速掌握结构化需求分析方法中“自顶向下逐层分析”的实际落地并在Visio环境中完成规范的数据流图绘制对课程设计或毕业设计中的系统分析环节有直接参考价值。1. 利用 Visio 画网上书店数据流图从业务边界到可交付的 PDF利用 Visio 绘制网上书店系统的数据流图是软件工程课设和系统分析师手里最常见的“一张图入行”任务。网上书店系统的数据流图DFD把顾客、管理员、出版社、支付平台之间的数据流动画成一张可评审的图让团队在写代码之前就统一对“订单从哪儿来、状态往哪儿去”的认知。Visio 因为形状库齐全、连线智能、导出 PDF 方便成了画这类图最主流的工具。这篇笔记按我的实战习惯把这个方向拆解清楚先讲清边界与分层再在 Visio 里逐步操作最后是几个容易翻车的细节和自检方法。新手能照着复现一套完整的网上书店数据流图熟手也能对照检查自己容易忽略的平衡规则。2. 画图前先定边界网上书店数据流图的层级结构与外部实体识别2.1 网上书店的五个外部实体哪些画在框内、哪些画在框外在结构化分析方法的语境里数据流图DFD是用来描述数据从哪里产生、经过哪些加工、最终落到哪个存储的建模手段。网上书店系统的 DFD 首先要回答一个问题系统到底管哪些事画图的第一步不是打开 Visio 拖形状而是把系统的边界找出来。边界之内的是过程和数据存储边界之外的是外部实体。我一般会把“谁跟这个系统说话”先列成一张清单。网上书店系统常见的五个外部实体如下外部实体与系统的数据交互数据方向边界判断依据顾客注册/登录信息、图书查询条件、购物车操作、订单信息、支付请求顾客 → 系统系统服务对象无法被改造书店管理员图书上下架指令、订单处理指令、库存调整指令管理员 → 系统使用后台界面但属于外部触发者出版社图书书目、补货回执出版社 → 系统上游数据源独立第三方支付平台支付结果回调支付平台 → 系统第三方支付网关系统不可控物流公司配送状态回传物流公司 → 系统订单履约环节外部系统判断一个角色是不是外部实体标准只有两条它有没有使用系统的账号它能不能被我们改造两条都为否就一定是外部实体。顾客用账号但顾客不受我们改造所以顾客是外部实体管理员使用后台账号但管理员仍然是外部角色因为我们改造的是系统而不是管理员本人购物车既不登陆也不被改造它连外部实体都不是它是系统内部的一条数据流和一组状态。还有两个常见的边界误判。第一是把“数据库”当成外部实体画在图上但实际上它是数据存储画成开口矩形。第二是把“店铺后台”当作独立的系统画在框外但实际上后台是网上书店系统的一部分管理员只是通过界面操作并不应该出现一个虚构的“后台管理系统”外部实体。这种冗余实体是评审会上最常见的扣分点。2.2 上下文图、0 层图、1 层图的分层规则与分解粒度分层是 DFD 区别于其他流程图的本质特征。网上书店系统涉及顾客、订单、书籍、库存、支付、物流六个主要业务域细节如果全画进一张图视觉复杂度会超过人的理解上限。标准做法是把图画成上中下三层上下文图只画一个过程编号为 0代表整个网上书店系统。外部实体分布在四周数据流直接与中心过程相连。上下文图不画任何数据存储存储是系统内部的细节。这张图的读者是业务方用来确认系统边界我们从谁那里接收什么向谁输出什么。0 层图把中心过程拆成多个主过程。我按业务域把这个系统拆成 7 个过程用户管理、图书查询与浏览、购物车管理、订单管理、支付处理、库存与书籍管理、报表统计。0 层图里要画数据存储因为分析者需要看到数据在哪里落地。1 层图针对 0 层图中复杂的过程继续分解。例如“订单管理”在 0 层图里只是一个过程但它内部包含创建、查询、修改、取消、状态更新五种操作必须展开成子图。这种自上而下的分解过程就是结构化分析所说的“上下文数据流图的分解”。层级过程数量数据存储适用场景上下文图1不画项目启动、业务边界确认0 层图5-8 个全部主要存储架构评审、模块划分1 层图每个过程 3-8 个子过程局部存储接口设计、编码实现分解粒度有一个实用经验一个过程在 0 层图里有超过 8 条连接线就值得拆。相反一个过程只有一条输入和一条输出逻辑简单到一眼能看懂就别拆。网上书店系统的“报表统计”通常只读订单和支付记录输出报表保持单过程即可而“订单管理”一定要拆。编号规则贯穿所有层级。上下文图是 00 层图用 1 到 71 层图的子过程用父编号加小数点比如 4.1、4.2、4.3。数据存储统一用 D1、D2、D3从 D1 开始顺序编号。同一条数据流在父图和子图中必须同名同方向。上下文图中的“订单信息”从顾客流向系统到了 0 层图它必须从顾客流向过程 4 订单管理再拆到 1 层图它必须从顾客流向子过程 4.1 创建订单。链路不能断方向不能变。我在评审中见过最典型的分解失误是0 层图做得像一个漂亮的菜单但 1 层图突然冒出一个父图中完全没有对外数据流的过程。比如订单子图里画了“发票开具”但 0 层图和上下文图里都没有“发票”相关数据流。这说明子图不是父图的分解而是另起炉灶。正确的做法是先定稿 0 层图的每条对外数据流再拆 1 层图拆的时候发现新功能需要新增数据流就回到 0 层图补上并走一次版本变更而不是让两层图各说各话。3. 在 Visio 里搭好数据流图底稿模板、形状映射与编号规则3.1 选对模板入口安装版本与「数据流图」模板的兼容性假设你的机器上已经装好 Visio 2013 及以上版本。没有的话去微软官方或公司 IT 渠道拿安装包安装过程没什么玄学一路下一步就行。问得最多的两个问题是Visio 和 Office 版本要不要完全一样答案是不需要同版本但位数最好一致32 位配 32 位、64 位配 64 位否则部分机器上跨位数打开文件会报“格式错误”。装好后先打开一次确认形状库能正常加载。Visio 打开后新建页有几个入口。中文版路径是文件 → 新建 → 类别里找「软件和数据库」→「数据流图」。英文版对应 Software and Database 下的 Data Flow Diagram。有些汉化版本叫“数据流图表”注意别选成“基本流程图”。我一般建议首选这个模板因为模板已经预置了 DFD 四类形状的模具和默认连线样式省去后期统一格式的功夫。如果用的是精简版或某些订阅版模板库可能被裁掉。找不到模板时用「基本流程图」模板也能画外部实体用矩形数据存储用开口矩形过程用圆角矩形数据流用带箭头的直线。只是多一步手动设置形状样式。两种方式我都试过结论是有模板用模板没模板也不用卡住。还有一点要认清Visio 并不理解你的业务流程它只能帮你把已经画好的图形自动排列。搜“visio 流程 自动生成”的时候找到的是“重新布局页面”这类自动对齐功能而不是智能建模。DFD 的业务结构必须你自己设计和确认Visio 不会根据一句“网上书店系统”就生成图。指望自动生成是画 DFD 前最需要放弃的幻想。3.2 外部实体、过程、数据存储、数据流四类形状的 Visio 实操DFD 有两套记号体系Yourdon/DeMarco过程用圆形和 Gane/Sarson过程用圆角矩形。Visio 数据流图模板默认用 Gane/Sarson 风格这也是国内课设和项目评审最通用的风格。我直接按这个风格讲。外部实体拖「外部交互者」形状双击改名。网上书店系统里分别命名为顾客、书店管理员、出版社、支付平台、物流公司。过程拖「过程」形状圆角矩形命名为“编号 动词短语”如“4.1 创建订单”。数据存储拖「数据存储」形状闭合矩形左侧带小竖条命名为 D1、D2、D3。名称写在右侧明细区。数据流用「连接线」工具箭头表示方向双击连线添加数据流名称。DFD 元素Visio 形状名称命名示例填充颜色建议外部实体外部交互者顾客白色过程过程4 订单管理浅蓝数据存储数据存储D4 订单信息浅黄数据流连接线订单状态黑色单向箭头为什么建议统一填充颜色一张 0 层图有几十条数据流和七八个过程不区分颜色的话评审者要在图上找半天。浅蓝 过程、浅黄 存储、白色 外部实体这个约定我在团队内沿用很久没出过理解歧义。统一颜色用「开始」选项卡里的「填充」下拉框先全选同类形状再批量设置不要一个一个点。3.3 数据流编号约定与数据流字典开始动笔之前先把编号体系定下来等于先画一张骨架过程编号上下文图 00 层图 1-71 层子图 4.1、4.2、4.3 这样的父子编号。数据存储编号D1 用户信息、D2 图书信息、D3 购物车信息、D4 订单信息、D5 库存信息、D6 支付记录。编号从 D1 开始不要跳号。数据流命名用名词短语不写动词。“订单信息”而不是“提交订单”“支付结果”而不是“收到支付结果”。数据流上传递的是数据不是动作动作在过程名里体现。命名是 DFD 评审最容易产生争议的环节。我见过一个项目组把同一条数据流在上下文图叫“订单”0 层图叫“订单数据”1 层图叫“订单详情”三条线实际上是同一个东西评审会直接掰扯了一个小时。所以我在画第一张图之前就列出数据流字典把核心数据流名统一登记注册信息、登录信息、查询条件、图书列表、购物车操作、订单信息、订单状态、支付请求、支付结果、库存变更、配送状态、图书管理指令、报表请求、报表结果。数据流命名还有一个实用技巧如果两条方向相反的数据流实际上承载同一份数据的请求与响应建议用“请求 / 结果”成对命名。比如“库存变更请求”管理员 → 系统和“库存变更结果”系统 → 管理员而不是两条都叫“库存变更”否则评审时没人分得清方向。3.4 页面、方向与网格为大图预留画布Visio 默认画布是 A4 纵向但 DFD 的 0 层图即使布局紧凑也往往超过一页 A4。我建议第一步就改页面设置设计 → 页面设置 → 页面尺寸选“预定义大小”里的 A3 横向或者自定义成 1200 × 800 毫米针对屏幕评审。注意如果最终要打印或导出 PDF页面尺寸要和内容范围匹配否则会出现第 5 章讲的截断问题。同时把网格调到最小刻度 0.5 厘米方便形状对齐。对齐可以靠拖动但更稳定的做法是开“自动对齐”设计 → 对齐 → 对齐网格。Visio 的形状拖动时有“磁吸”特性拖到接近边缘会自动吸附不注意的话会把两条连接线的端点吸到同一个点上导致数据流看起来少一根。我的习惯是先把“粘附”关掉视图 → 视觉帮助 → 粘附取消勾选等主体布局完成后再重新打开减少早期绘图时的误吸附。4. 网上书店系统 0 层图和 1 层图的具体绘制从上下文图到订单子图4.1 画好上下文图只有一个过程外部实体全部就位上下文图在 Visio 里的操作我按下面这几步走顺序是固定的别跳第一步把「过程」形状拉到画布中央命名“网上书店系统”编号 0。第二步拖入五个「外部交互者」形状。位置约定上方放出版社左侧放顾客右侧放支付平台下方放书店管理员和物流公司。这个布局不是标准但按顺时针讲流程最顺评审时主持人不用来回找实体。第三步画顾客相关的数据流入系统注册信息、登录信息、查询条件、购物车操作、订单信息、支付请求。方向都是顾客 → 系统。第四步画系统回到顾客的数据流注册结果、登录结果、图书列表、购物车确认、订单状态、支付结果。注意起点是系统过程终点是顾客外部实体。第五步画管理员相关线图书上下架指令、订单处理指令、库存调整指令管理员 → 系统系统 → 管理员的图书信息、订单明细、库存报表。第六步画出版社相关线系统 → 出版社的采购订单出版社 → 系统的图书书目、补货回执。第七步画支付平台相关线系统 → 支付平台的支付请求支付平台 → 系统的支付结果回调。第八步画物流公司相关线系统 → 物流公司的配送指令物流公司 → 系统的配送状态回传。上下文图数据流清单如下方向数据流名称关联外部实体顾客 → 系统注册信息、登录信息、查询条件、购物车操作、订单信息、支付请求顾客系统 → 顾客注册结果、登录结果、图书列表、购物车确认、订单状态、支付结果顾客管理员 → 系统图书上下架指令、订单处理指令、库存调整指令管理员系统 → 管理员图书信息、订单明细、库存报表管理员系统 → 出版社采购订单出版社出版社 → 系统图书书目、补货回执出版社系统 → 支付平台支付请求支付平台支付平台 → 系统支付结果回调支付平台系统 → 物流公司配送指令物流公司物流公司 → 系统配送状态回传物流公司这十组线画完上下文图就完成大半。这张图上的每一条线在 0 层图里都必须能找到对应的过程作为起点或终点。等 0 层图画完逐条勾对漏一条就说明 0 层图没拆完整。4.2 0 层图分解把网上书店拆成七个主过程0 层图是评审时看得最多的一张图。我用七个过程来拆分覆盖网上书店核心业务过程 1 用户管理接收注册信息、登录信息读写 D1 用户信息返回注册结果和登录结果。过程 2 图书查询与浏览接收顾客查询条件读 D2 图书信息返回图书列表和图书详情。过程 3 购物车管理接收购物车操作添加、修改数量、删除、勾选结算读写 D3 购物车信息返回购物车确认。过程 4 订单管理接收顾客订单信息、订单查询条件、订单修改请求、订单取消请求以及管理员的订单处理指令读 D3 和 D4写 D4对外返回订单状态和订单明细。过程 5 支付处理接收支付指令读 D4 订单信息发起支付请求给支付平台接收支付结果回调写 D6 支付记录并更新 D4 中的支付状态。过程 6 库存与书籍管理接收管理员的图书上下架指令和库存调整指令读 D2 和 D5写 D2 和 D5输出库存报表。过程 7 报表统计读 D4 订单信息和 D6 支付记录生成报表结果给管理员。Visio 操作上把上下文图作为底稿复制一份删除中心过程替换成七个过程五个外部实体从上一页直接复制粘贴过来避免重新命名和重新摆放。数据存储统一放在图底部与过程之间用直线连接。注意连线规则过程与数据存储之间的数据流不需要经过外部实体直接连。顾客到购物车、订单、查询之间的线从顾客实体出发落到对应过程的边框。过程与过程之间也会存在数据流比如订单管理读取购物车数据生成订单这条线从“3 购物车管理”指向“4 订单管理”线上标注“已选商品清单”。我整理了一份 0 层图的过程-存储矩阵画完图后对照检查过程编号过程名读取存储写入存储1用户管理D1D12图书查询与浏览D2—3购物车管理D3D34订单管理D3、D4D45支付处理D4D4、D66库存与书籍管理D2、D5D2、D57报表统计D4、D6—注意一个高频误区过程 2 图书查询只读不写过程 7 报表统计也是只读不写。图上数据流如果出现从过程指向 D2 的箭头说明方向画反了。查询类操作基本不会有写存储的线除非系统记录查询日志。4.3 1 层图细化订单管理子图如何拆出查询与修改流程以 0 层图里的过程 4 订单管理为例展开 1 层图。这个过程的输入输出在 0 层图上有顾客发来的订单信息、订单查询条件、订单修改请求、订单取消请求管理员发来的订单处理指令输出到顾客的订单状态、订单明细输出到管理员的订单处理结果以及读写 D3、D4。在 Visio 中新建页面命名为“1层图-订单管理”把过程 4 展开成五个子过程子过程编号子过程名输入数据流输出数据流涉及存储4.1创建订单顾客订单信息订单创建成功通知D3、D4、D54.2订单查询顾客订单查询条件订单详情D44.3订单修改顾客订单修改请求修改成功/失败结果D44.4订单取消顾客或管理员的取消请求取消确认D4、D54.5订单状态更新物流公司配送状态回传订单状态推送D4、D6这一层特别要重视“查询与修改”这一对操作。网上书店系统的订单查询与修改是高频功能很多初学者的 1 层图里直接把“订单查询”的数据流画成从顾客到 D4 的一条线过程 4.2 完全没用上——这在 DFD 里是禁止的。数据流不能直接落到数据存储上它必须经过过程。订单修改同理必须经过 4.3不能从顾客外部实体直接画到 D4 上。画完子图再做一次平衡检查把 4.2 的输入“订单查询条件”和输出“订单详情”跟 0 层图对照。0 层图里“订单管理”与顾客之间有两根数据流一根入一根出。1 层图中五个子过程的对外数据流合计也必须与 0 层图保持一致。多一条或少一条都说明分解有遗漏。跨页引用时1 层图里的顾客、管理员、物流公司这些外部实体直接从 0 层图复制过来粘到新页面。这样即使后续改名两页保持一致。Visio 的跨页复制会把形状位置一起带过来子图的外部实体摆位用不了两分钟。关于“查询修改数据流图”再补一句订单查询和修改在 1 层图里是两个独立过程不要合成一个“订单查询/修改”过程。两者的数据流方向、请求参数和返回结果都不同合成一个会让后续数据库接口设计时不好拆分。分得越清楚后面写接口文档越省事。5. 画数据流图的 5 个典型踩坑方向画反、层级失衡与 Visio 连线问题5.1 数据流方向画反支付结果当作输入而不是输出现象0 层图里画“支付结果”这条数据流时箭头从系统指向支付平台评审时被问“支付结果到底是谁产生的”当场答不上来。原因把支付请求和支付结果的语义弄混了。支付请求是系统主动发出的方向系统 → 支付平台支付结果是支付平台处理完成后回调给系统的方向支付平台 → 系统。如果画反表示系统在给支付平台发结果语义正好相反。解决在数据流字典里明确每条数据流的“产生方”和“消费方”。画图时先标方向再描线鼠标点连接线工具后先想清楚这条数据流是“谁发给谁”再按住起点拖到终点。另外Visio 的箭头默认是单向的双向传输必须换乘双箭头连接线或者画两条单向线并分别命名如“支付请求”和“支付回调”不要用一条双向线表示两个方向的数据。5.2 父图与子图不平衡1 层图凭空多出一个过程现象1 层订单管理子图里出现了“4.6 发票开具”过程但 0 层图里的“订单管理”没有对外发票数据流连接。评审时定性为“父图与子图不平衡”整张子图要返工。原因画 1 层图时脑子里的业务比 0 层图多想到发票就顺手画上没有先把子图的输入输出边界列出来。多数人画图是先想业务再画图而不是先画图再补业务边界顺序颠倒后就会出这种问题。解决在动笔前先做一个“子图接口检查”把父过程的数据流全部抄在一张纸上只抄与外部实体交互的部分不抄存储读写。子图里每新增一个过程都问一句它和外部实体之间有没有数据流如果有回 0 层图补上这条线。标准做法是 0 层图定稿后冻结1 层图发现需要增加功能时回 0 层图更新并走版本变更而不是让两层图各画各的。5.3 数据存储只写编号不写名称评审时被追问现象图上只有“D4”两个字评审者问它存的是订单、发票还是购物车作者答不上来。原因Visio 的「数据存储」形状默认比较窄名称没地方放很多人就把名称省略了或者随便拖到形状旁边导出 PDF 后标签位置漂移和图主体脱节。解决双击数据存储形状在“形状数据”窗口的“名称”属性里填写“D4 订单信息”。右键该形状 → 格式 → 行为 → 标注把显示方式设为“名称编号”这样图上会稳定显示“D4 订单信息”不再出现一条游离的文字。另一个实用做法是把存储形状拉到至少 1.5 厘米宽字号调到 10 号以上保证 PDF 缩印后还能辨认。5.4 Visio 的自动连接线乱跳动态连接线不适合静态 DFD现象两条数据流本该平行Visio 自动给他画成折线拖动过程形状时连接线像开了倍速一样跟着重新路由最后整张图的线交叉得像一张网。原因Visio「连接线」工具默认是动态路由连接线会随形状位置变化自动寻找最短路径。0 层图过程多、存储多动态连接线彼此干扰就会乱跳。这不是故障是连接线模式与静态图不匹配。解决画 DFD 这种静态数据图用「直线连接线」工具。我的步骤是先把所有图形摆位定稿再用“直线连接线”逐条画箭头每条线的路径都由手动控制不把路由交给 Visio 自动处理。这样图面干净评审时投到投影仪上也不乱。另外“设计 → 重新布局页面”会用算法把所有图形重排一遍点之前务必另存一份副本。这是血泪经验误点过一次就知道这个按钮值多少钱。提示连接线交叉不严重时可以手动拖拽交叉处的控制点微调路径比“重新布局”安全得多。5.5 导出 PDF 后文字重叠、图形被截断现象PDF 导出后一页纸只有半张图后半段被截掉把图缩放到单页后数据流名称小得看不清。原因页面尺寸与形状分布范围不匹配。Visio 默认 A4 纵向0 层图宽度远超 A4被硬生生截断。缩放适配后文字又缩得太小阅读性崩了。解决在“设计 → 页面设置 → 页面尺寸”里选“调整以适应绘图”让 Visio 自动把页面边界包住全部图形。方向选横向。导出 PDF 时在“打印”对话框里选全部页面缩放方式选“适合”一页或两页显示完整图。如果要把图贴进 Word 或 PPT缩放比例调到 90%边缘留白更稳。最后一条经验不要导 JPG。DFD 布满小字JPG 压缩后文字全是马赛克。PDF 是矢量格式是评审和文档交付里最稳妥的选择。6. 画完不等于交付数据流图的三项自检与 PDF 导出设置6.1 三个自检动作数据守恒、平衡检查、命名完整性画完图先别急着导出按顺序自检三遍。第一遍数据守恒检查。每个过程至少有一条输入数据流和一条输出数据流。没有输入只有输出的过程数据从哪来有输入没输出的过程数据去哪了用 Visio 的“跨功能流程图”辅助视图逐个数或者在图上画完主链后把每个过程的输入线和输出线数量列成一个清单。网上书店系统里最容易出问题的是“报表统计”它只有输入没有输出会被人质疑所以输出端“报表结果”必须画清楚。第二遍父图子图平衡检查。对照 0 层图和 1 层图逐条核对对外数据流。做法是把每条数据流写在一张纸上数据流名、父图出处、子图出处。评审时直接拿这张纸当讲稿讲一条划一条。第三遍命名完整性检查。所有外部实体、过程、数据存储、数据流都必须有名字和编号。过程编号连续存储编号不重复。文本里的名词和图上完全一致不能“订单信息”和“订单详情”混用。6.2 PDF 导出时页面大小与缩放比例的设置PDF 导出设置直接决定交付物能不能用。流程我固定为三步第一步设计 → 页面设置 → 页面尺寸 → “调整以适应绘图”。这一步解决图被截断的问题。第二步确认页面方向为横向。0 层图几乎是横向构图纵向导出会被强行拉长线型全变。第三步文件 → 另存为 → PDF缩放方式选“适合”。如果多页子图打印范围勾选全部页面。使用场景页面设置导出建议课设文档插图A3 横向适合页面宽度清晰度保持 100%打印评审A3 横向适合页面宽度打印质量选“高”投屏讲解自定义尺寸适合窗口宽度字号 12 号以上提示导出 PDF 后用阅读器放大到 200%检查每条数据流名称是否清晰。看不清就回 Visio 调字号再导出不要硬交付。6.3 我的习惯版本存档与评审备注我交付数据流图时除了 PDF一定保留 Visio 源文件并在文件里加一页“修订记录”谁在什么时间改了哪张图、改了哪几条数据流。DFD 是分析阶段的可交付物也是编码阶段查接口怎么设计的底图。没有修订记录的 DFD三个月后回来看就是黑匣子自己都看不懂当初为什么这么拆。评审时我把 PDF 打开按上下文图 → 0 层图 → 1 层图的顺序讲每条数据流的起点、终点和承载内容嘴里过一遍。讲的过程中如果发现某条线连不上说明图有问题当场改 Visio 源文件再导出新版 PDF。把“讲解”当作最后一次校验比对着图空想检查有效得多。这个习惯帮我在多次课设和项目评审里一次性通过也希望你用得上。希望帮到你。本文还有配套的精品资源点击获取