简介一份图书馆管理系统数据流图的文档资源适合软件工程课程设计、系统分析与项目文档撰写。文档以读者管理、图书管理、借书、续借、预约、处分和催还为主线逐层拆解整套系统先给出顶层综合管理图再展开为借书证管理、离校注销、图书借阅等多个子系统并进一步细化到核查读者身份、检查借书限额、处理预约记录等具体处理过程同时辅以ER图与DFD总观清晰呈现数据流走向、实体关系及模块边界对理解数据输入、处理、输出的完整路径很有帮助。资源包内为1个doc文件大小约889KB内容以文字说明和图例为主可直接复制用于二次绘制或课程报告整理。该文档已有107人学习适合用于毕业设计、课程作业或系统设计文档的参考。1. 图书馆数据流图为什么需求评审前一定要把它画到 0 层以下一份名为“图书馆数据流图.doc”的文档放在需求阶段就是给整个图书馆系统拍 X 光片。数据流图DFD用外部实体、加工、数据流、数据存储四个固定符号把业务从头到尾跑一遍读者提交借书请求是一条数据流系统校验并登记借阅是一次加工借阅记录落库是一个存储罚款通知发给读者又回到外部实体。它是结构化分析方法里的主模型画到 0 层甚至 1 层能直接回答“系统要做哪几件事、每件事吃什么数据、产出去了哪”。适合正在做图书馆系统需求分析、准备评审、或者第一次碰 DFD 的从业者。不管你是用 Word 直接画还是从 Visio 粘过来的这篇内容会按“定边界→分解→补数据字典→验收”的顺序把整条路走通。2. 从借书到催还用结构化分析方法先定加工边界2.1 先记住四个符号DFD 不是流程图是数据在系统里的流动路线业务流程图关心“谁先做什么事、什么顺序做”DFD 只关心数据从哪来、被哪些加工改变、最后存到哪。这两个图混在一起是图书馆数据流图最容易走偏的地方。我一般拿到需求先把四个构件在图书馆场景里的对应关系列出来再动笔画构件图形画法图书馆场景示例外部实体方框在系统边界外读者、馆员、图书供应商加工圆角矩形必须有动作P3 借阅与预约管理、P1 读者信息管理数据流带箭头的线只能从实体到加工、加工到加工、加工到存储借阅请求、催还通知、罚款通知数据存储开口矩形在系统边界内读者信息库、馆藏书目库、借阅记录库、预约登记库四个构件的判别方法也很固定能独立产生或消费数据的角色才叫外部实体加工必须改变数据形态把“借阅请求”变成“借阅记录”这才算加工数据存储是数据的静止状态只能被加工读写不能直接连实体。2.2 识别实体与存储把“读者本人”和“读者信息库”分开画很多初稿会把“读者”画成一个数据存储理由是系统要从库里读读者信息。这是混淆了业务对象和数据的落点。读者是一个活生生的人站在系统边界外产生借书请求读者信息库是系统内部的数据存储保存读者证号、读者类型、可借数量、当前借阅数。加工从读者信息库里读数据不代表读者本身是存储。判断标准很简单外部实体是数据流的起点或终点它永远不在系统边界内数据存储只能被加工读写。画图时“读者信息库存储”和“读者外部实体”是两个构件读者给系统送请求读者信息库给加工提供校验依据。顺带说一个常见练习“查询修改数据流图”查询读者信息和修改读者信息应该拆成两个加工。查询不产生新数据只读存储数据流可以从加工出发回到读者面前修改必须写回读者信息库。如果把两个动作并成一个“读者信息维护”数据字典里看不到读写差异评审时会被追问“这个加工到底改了哪张表”。2.3 从事件清单到加工清单一张 A4 纸列完我画 DFD 前不做任何图形先列业务事件。图书馆业务听起来杂但事件可以收敛列出所有业务事件读者借书、读者还书、读者续借、读者预约、到书通知、馆员催还、图书采购、图书到馆验收、读者信息查询与修改、罚款收取、统计报表生成。去掉纯查询事件暂时不单独展开。因为查询没有写操作0 层图可以合并到“查询统计”这个加工里。把有写操作的事件归并成加工类。给每个加工命名命名格式必须是“动词宾语”登记借阅、更新馆藏、计算罚款、生成报表。事件归并后的对照表长这样业务事件归属加工加工编号读者借书、还书、续借、预约、催还借阅与预约管理P3读者注册、信息查询与修改、注销读者信息管理P1图书采购、到馆验收、编目入藏图书采编与入藏P2馆藏查询、借阅统计、报表输出查询统计P4这一步做完0 层图的加工清单就出来了。不要在事件清单阶段纠结数据流细节事件只管“发生了什么事”数据流是分解阶段的事。加工边界没定清楚就画线画到一半一定会来回返工。3. 数据流图的分解从上下文图到 1 层图的四步做法3.1 上下文图整个系统只有 1 个加工上下文图也叫顶层图它的作用只有一个锁定系统边界。这一层只画一个加工名字就叫“图书馆信息管理系统”加工内部长什么样完全不展开它就是一个黑匣子。外部实体一般只保留三个读者、馆员、图书供应商。对应数据流按进出分组读者发来的借阅请求、还书请求、预约请求、续借请求、查询条件系统发给读者的借阅回执、罚款通知、预约到书通知、催还通知馆员发起的采购清单、盘点请求、统计报表请求供应商返回的到货单、图书配送单上下文图画到“每个外部实体至少有一条进、一条出的数据流”就算合格。这一层如果出现第二个加工或者加工对加工的数据线就是边界泄漏。评审时经常有人在这里犯迷糊把“图书供应商”省掉采购数据流就悬空了。记住只要数据流有起点没有终点上下文图就不成立。3.2 0 层图按四条业务主线把黑匣子拆开上下文图定完边界0 层图做第一次分解。图书馆业务基本稳定在四条主线加工编号加工名主要输入流主要输出流主要数据存储P1读者信息管理注册申请、信息修改申请注册回执、修改回执读者信息库P2图书采编与入藏采购清单、到货单、验收单入藏回执、新书通报馆藏书目库P3借阅与预约管理借阅请求、还书请求、预约请求借阅回执、罚款通知、预约到书通知读者信息库、馆藏书目库、借阅记录库、预约登记库P4查询统计查询条件、报表请求查询结果、统计报表馆藏书目库、借阅记录库0 层图最常犯的错是加工与加工之间乱连数据线。只要数据要写入存储就画“加工→存储”不要加工对加工传文件。加工之间传数据只发生在某个加工需要另一个加工先完成某个动作时比如 P2 完成书目入库后给 P3 发一条“新书可借标志”这种情况才在 P2 和 P3 之间画数据流。其余时间尽量让数据流通存储中转这样每一层分解后续都不会卡壳。3.3 1 层图把 P3 拆到借书、还书、续借、预约1 层图是“上下文数据流图的分解”落地的关键一步。以最复杂的 P3 借阅与预约管理为例先拆出 4 个子加工P3.1 借书处理P3.2 还书处理P3.3 续借处理P3.4 预约处理再把 P3.1 借书处理继续拆到原子级P3.1.1 读取读者证信息接收读者提供的证号触发后续校验P3.1.2 校验借书资格查读者信息库核对读者类型、是否逾期、当前借阅数是否到达上限P3.1.3 校验图书可借状态查馆藏书目库确认图书在馆且未被预约锁定P3.1.4 登记借阅记录写借阅记录库同时生成应还日期P3.1.5 更新馆藏状态把馆藏书目库中该图书的流通状态从“在馆”改成“借出”这里把校验拆成两个加工是有意的。借书资格和图书状态来自两个不同的数据存储拆开后每一条失败原因都能单独走一条数据流。比如资格校验失败输出“拒绝原因逾期未还”可借状态校验失败输出“拒绝原因图书不可借”。如果不拆一个加工里同时查两张表、写两套失败原因数据字典就没法定义了。拆到这一层评审才能看清“借书”到底做了几件事。很多图停在“读者→借书登记→借阅记录”把校验逻辑吞在加工里等于告诉评审你们猜这里有没有规则。这是不合格的。3.4 分解出来后用三句话闭环自查每张图分解完我会做三个检查全是体力活但能省掉评审时的大麻烦。父图子图平衡父图 P3 有多少条输入流、输出流子图就必须原样出现。P3 有输入流“借阅请求”P3.1 就必须有“借阅请求”P3 有输出流“催还通知”子图 P3.2 还书处理里就必须画出来。缺一条就是对不上。编号连续0 层加工 P1 到 P41 层子加工 P3.1 到 P3.4。如果 1 层图出现了 P3.5 却没有出现在 0 层图里说明要么漏了父图分解要么归错了类。命名规范加工必须是动词短语数据流必须是名词短语。看见“借阅记录”当加工名改叫“登记借阅”看见“馆藏书目”当加工名改叫“更新馆藏状态”。数据流也别叫“信息”这种词“读者信息”到底指证号还是地址改成“读者证号变更请求”这种精确名词评审才不需要靠猜。4. 让图能过评审数据字典与加工说明的写法4.1 数据字典给每条数据流、每个存储做属性登记数据流图画的是一张网数据字典就是这张网的节点清单。图书馆系统的评审专家普遍会先看图再随手翻数据字典如果字典里没有一条“借阅请求”的组成定义图再漂亮也会被打回。数据字典条目一般按五个字段写字段说明示例数据流名全局唯一与图中命名一致借阅请求组成用 {} [] 符号表达结构借阅请求 读者证号 图书条码 借出时间 应还日期来源数据流的起点读者外部实体去向数据流的终点P3.1 借书处理说明触发条件、频率、约束读者在自助借还机提交系统实时处理数据字典里常用的符号约定也要在文档开头写清楚 表示“由……组成” 表示“且”| 表示“或”{} 表示重复[] 表示可选() 表示可选项。例如读者信息可以写成读者信息 读者证号 姓名 读者类型教师|学生|社会读者 可借数量 当前借阅数 状态一个容易被忽略的细节纯查询加工的数据流也要定义。P4 查询统计接收“查询条件”组成是“读者证号 图书条码或书名关键词”这条数据流的去向是加工而不是存储。字典里把查询条件定义清楚开发阶段做接口时可以直接照着拼 SQL 参数不需要再回去翻需求文档。4.2 加工说明用判定表把复杂规则写死数据流图只表达“有什么加工”加工内部“按什么规则执行”要靠加工说明补充。图书馆业务的难点全在规则上借书资格不是一句话能说清的它取决于读者类型、当前借阅数、逾期状态、图书状态、预约锁定状态。用文字写“校验借书资格”会被评审连环问最好的办法是上判定表。以 P3.1.2 校验借书资格为例条件与动作组合1组合2组合3组合4读者类型 学生是是——当前借阅数 上限 8 册否是——存在逾期未还记录否否是—允许借出是否否否拒绝原因码成功BORROW_LIMITOVERDUE其他判定表的优势在于穷举。任何一行组合评审都能指出“这里漏了一种情况”。比如组合 4 没有写否定条件评审会追问“那图书被预约锁定怎么办”这时补一行“图书在馆且未锁定”的条件列进去规则边界就闭合了。预约锁定状态属于 P3.1.3 图书可借状态校验所以这里不写进同一张表但要保证两张表的条件列加起来覆盖全部业务规则。数据字典和加工说明两张表加在一起开发阶段基本不用再拉业务方逐字核对。一个 LIS 系统的几十个加工难写的规则就那么几条全用判定表定死比需求评审现场临时解释可靠得多。5. 画到一半的四类问题排查从数据流对不平到 Word 图散架5.1 父图与子图数据流对不上现象1 层图展开 P3 后评审对照 0 层图发现 P3 的输出流里少了一条“催还通知”子图里却找不到对应的线。原因分解时把“催还通知”当成了 P3.2 还书处理内部的动作没有画到子图边界上。数据流没有从子加工里出来父图子图平衡就直接破裂。解决不要凭眼睛对比用对齐表逐条核对父图 P3 输出流子图对应加工是否画出借阅回执P3.1 借书处理是罚款通知P3.2 还书处理是预约到书通知P3.4 预约处理是催还通知P3.2 还书处理否缺失对齐表一列缺哪条一目了然。补线的时候顺手把数据流向也检查一遍催还通知必须从还书处理流回读者不是流向馆员。5.2 把外部实体画成存储导致数据流断头现象图里出现了“读者信息”存储读者发来的借阅请求直接从存储里冒出来评审说这条数据流没有来源。原因画图时把“读者”和“读者信息库”混为一谈觉得反正都是读者相关的数据画一个就行。但外部实体是数据流的起点存储是数据的落点两者语义完全不同。解决读者方框和读者信息库两个构件都保留。读者在边界外发送“借阅请求”给 P3.1P3.1 再从读者信息库读取“读者借阅状态”。一个负责产生请求一个负责提供校验数据数据流各有来源和去向断头问题自动消失。改完之后检查全图任何一条数据流都不能从存储发起也不能从实体直接落到存储必须经过加工。5.3 加工命名用名词评审质疑图不是数据流图而是表结构图现象0 层图里的加工名叫“借阅记录”“馆藏书目”“读者信息表”每一条都像数据库表名。外行看着整齐内行一看就知道加工语义缺失。原因照着系统菜单栏或后端表结构命名没有理解加工的实质是动作。解决把每个名词加工名改写成动词短语“借阅记录”改成“登记借阅”“馆藏书目”改成“更新馆藏状态”“读者信息表”改成“维护读者信息”改写过程本身就是一次语义检查如果某个加工名改不成动词短语说明这个加工根本不是动作而是对存储的误读。比如“馆藏书目”改不成动作就应该把它退成数据存储而不是硬塞在加工框里。5.4 .doc 里的图转 PDF 后散架箭头错位现象Word 里画好的数据流图在另一台电脑打开后形状和箭头全部错位转 PDF 输出给客户圆角矩形和开口矩形叠在一起。原因Word 的绘图画布在不同版本之间兼容性不稳定图里的形状没有组合复制或翻页时锚点位置变化Visio 直接粘贴进 Word 的图如果粘贴成嵌入对象而非图片也容易出现渲染问题。解决画图时把每张 DFD 放进同一个绘图画布画完立即全选组合。用 Word 的“选择窗格”给每个对象重新命名比如“P3-加工”“借阅请求-数据流”避免锚点错乱。转 PDF 之前先在阅读视图里逐页检查箭头和标签是否对齐。最稳妥的做法是把 Visio 或 draw.io 的源文件单独归档Word 里的 .doc 只当交付稿源文件才是以后改动的主版本。经历过一次转 PDF 全部散架的返工就会明白源文件归档比图本身更重要。6. 数据流图做完之后两组验收数据把漏掉的加工找出来图不是画完就结束。我交一份 DFD 前会拿两组数据当黑匣子去“打”它。这里的黑匣子测试不是讲算法模型的黑盒而是把整张图看成只认输入输出的对象输入一个业务场景顺着图走看它能不能走通。第一组是正常业务流读者借书。从上下文图开始走“借阅请求”进 P3到 0 层图再进 1 层图的 P3.1走完“读取读者证信息→校验借书资格→校验图书可借状态→登记借阅记录→更新馆藏状态→借阅回执”整条链。每一层的输入输出都要对得上有一层断掉说明分解出了问题。第二组是边界数据读者借书数量已经达到上限、读者有逾期未还、图书被预约锁定、读者证已挂失。逐条走一遍如果某一条输入在图里找不到对应的子加工和输出数据流就是漏加工的铁证。比如“读者借一本已被预约锁定的书”1 层图里只有“校验图书可借状态”没有分流到“拒绝原因预约锁定”的输出路径走查时就会发现这条输入没有去处必须补数据流。我自己的习惯是任何 DFD 进评审前先做一张父图子图平衡表再拿三组边界输入把每条支流走一遍。跑不通就补图补完再走一遍直到所有输入都有去处、所有输出都有来源。没有经过这两关的图我不会拿进评审会。希望帮到你。本文还有配套的精品资源点击获取
