简介一份面向软件工程课程设计与毕业设计的图书馆管理系统需求分析文档以数据流图和数据字典为核心梳理图书采购、编目、借阅、检索四大子系统适合正在完成相关课题、需要绘制数据流图或撰写需求说明的学生与开发者参考。资源包内为单个DOCX文档大小为563KB内容覆盖系统总体功能说明、第一层与第二层数据流图以及数据字典中数据源点、加工逻辑和数据流名词条的完整描述特别是检验能否借书时的身份校验、库存判断、超期检查等多种判定分支以及添加借阅记录的处理流程。文档还给出了借书错误信息、借书信息等数据流的具体来源与去向包含借书证、图书等数据项的字段组成层次清楚便于直接套用到类似管理信息系统的分析与设计之中。已有2982人学习适合作为软件工程课程报告、课程设计或毕业设计的需求分析章节蓝本。1. 图书馆管理系统需求分析为什么数据流图画完才算真正开始软件工程课程设计里最典型的卡点不是需求写不出来而是写出来的需求画不成图。图书馆管理系统人人都会描述读者可以借书、还书、查询馆藏两句话就能说完一落成数据流图就暴露问题图书管理员算不算外部实体借书是一个加工还是四个加工罚款金额直接从还书流出去还是需要单独的存储写了两千字的需求说明数据流图上一处对不齐就被评审打回。数据流图的训练价值恰恰在这它逼你把每个数据来源、每次加工、每个存储钉在图上并保证上下文图、0层、1层逐层吻合、编号可追。这里按软件工程课程设计和毕业设计的常规路径把图书馆管理系统从用例梳理、上下文数据流图的分解、0层与1层数据流图绘制到数据字典与加工逻辑说明的做法讲全最后给一个能直接运行的Python检查脚本验证父图子图平衡、黑洞加工和奇迹加工。2. 从业务陈述到功能清单图书馆管理系统的需求边界怎么定2.1 外部实体先于加工读者、馆员与系统管理员的数据往来画数据流图的第一步不是画加工而是确定外部实体。外部实体是数据流的起点和终点在图书馆管理系统里通常有三个读者、图书管理员、系统管理员。选实体时最常见的争议是图书管理员算不算系统的一部分。常见做法是把管理员放在系统外部读者把借阅需求交给管理员管理员操作图书馆管理系统所以管理员是系统的使用者而不是系统内部的加工。如果你做的是自助借还的版本读者直接操作终端那么读者作为外部实体发起的借书请求要直接连到系统。边界一旦定下来上下文图、0层图直到1层图都要遵守同一套实体集合中途不能新增角色。实际操作可以按两步走先列出候选实体再逐个回答两个问题——它是否向系统发送数据系统是否必须向它回传数据两个答案都是否就把它排除。采购供应商在大多数课程设计里就是这么被排除的采购业务简化为图书管理员录入采购清单供应商不直接与系统交换数据所以不列为外部实体。各实体与系统的数据往来如下表流名全部用名词短语不要写成动词句外部实体提供给系统的数据流系统输出的数据流读者借书请求、还书请求、续借请求、预约请求、查询条件借阅凭证、应还日期、催还通知、罚款金额、查询结果图书管理员采购清单、编目数据、读者注册信息、罚款核销记录上架清单、馆藏统计、在借明细、借阅记录查询结果系统管理员借阅期限参数、每日罚款单价、读者注销请求统计报表、操作日志写需求分析文档时这一步对应系统边界与参与者小节把每个外部实体选进或排除的理由写清楚。评审最常问的就是为什么没有供应商为什么管理员不算系统内部角色这两问的答案都在上面两段里照抄业务背景并按自己的系统设定改一改即可。2.2 用用例清单映射加工别把功能点直接当数据流图节点外部实体定完之后把需求分析里整理出的用例清单映射到0层加工。图书馆管理系统课程设计的功能点通常覆盖图书采购与编目、借书、还书、续借、预约、逾期罚款、读者注册与注销、统计查询。映射时要注意功能点是做什么加工是数据怎么变两者不是一对一。查询借阅历史和统计热门图书都带查询两个字前者是单记录检索后者要按ISBN分组做聚合后者在数据流图上就得多一步汇总加工。常见的映射关系如下表这也是0层数据流图的雏形功能需求用例对应0层加工主要输入主要输出关联存储图书借阅P1 借书处理借书请求借阅凭证D1读者信息、D2馆藏信息、D3借阅记录图书归还P2 还书处理还书请求还书回执、罚款单D2、D3、D4罚款记录续借与预约P3 续借预约处理续借请求、预约请求续借结果、预约通知D3、D5预约记录图书采购与编目P4 图书管理采购清单、编目数据上架清单、馆藏变更D2读者注册与注销P5 读者管理注册信息、注销请求读者档案更新、注销回执D1查询与统计P6 统计查询查询条件、统计条件查询结果、统计报表D2、D3、D4这里有一个新手常犯的错把系统登录画成一个加工。登录是系统运行的前置能力不是图书馆业务的数据变换画进数据流图会让评审追问你处理的是什么业务数据。课程设计的惯例是把它从DFD里拿掉只在非功能需求或系统管理部分提一句权限控制。2.3 用例描述落到文档借书流程的可评审写法功能映射表给出的是0层加工的骨架但需求分析文档不能只放表。每个核心用例要配一条用例描述软件工程课程设计文档里一般用编号、名称、参与者、前置条件、后置条件、基本流、异常流的固定格式。以借书为例用例编号UC-03 用例名称借书 主参与者图书管理员代读者办理 前置条件读者已注册且持有效借阅证馆藏副本状态为在架 后置条件借阅记录写入D3馆藏副本状态更新为已借出生成借阅凭证 基本流 1. 管理员扫描读者证系统校验读者身份与借阅资格 2. 管理员扫描图书条码系统校验馆藏副本可借状态 3. 系统计算应还日期写入借阅记录 4. 系统返回借阅凭证包含应还日期 异常流 3a. 读者有超期未还记录拒绝借书返回未还图书与罚款金额 3b. 读者在借数量达到上限拒绝借书提示先还书这条用例描述的作用是承上启下异常流里的每个分支后面画1层数据流图时都要有对应的子加工或判定写加工逻辑说明时也要逐条覆盖。评审看的就是用例、数据流图、加工说明三处能不能对得上。非功能需求比如并发借还、数据备份在这一节单独列出去不要混进数据流图的加工里因为DFD只表达功能需求。3. 数据流图逐层分解上下文图、0层数据流图与1层数据流图的画法3.1 上下文数据流图的分解一张图锁死系统边界上下文数据流图的分解是整个DFD体系的起点它只有三个元素一个代表整个系统的加工、全部外部实体、以及实体与系统之间的顶层数据流。上下文图里不画数据存储因为存储属于系统内部也不画加工之间的流因为整个系统被看成一个大加工。图书馆管理系统的上下文图可以直接从第2章的实体流表生成把表里的每一行变成一条带箭头的线。习惯上按五步走列出候选实体、为每个实体写输入输出流、画单个加工节点、核对每条流名、统一编号归档。用文本先把结构定下来确认流名无误后再进绘图工具比直接在软件里拖拽效率高。以读者和图书管理员为例[读者] --借书请求/还书请求/续借请求/预约请求/查询条件-- [图书馆管理系统] [读者] --借阅凭证/应还日期/催还通知/罚款金额/查询结果-- [图书馆管理系统] [图书管理员] --采购清单/编目数据/读者注册信息/罚款核销记录-- [图书馆管理系统] [图书管理员] --上架清单/馆藏统计/在借明细/借阅记录查询结果-- [图书馆管理系统]系统管理员的流也照此登记提供期限参数、罚款单价、注销请求收回统计报表和操作日志。上下文数据流图的分解要点是保守上下文图里出现的每条数据流在0层图中必须能找到承载它的加工反过来0层图里新增的数据流只能出现在加工之间或加工与存储之间不能突然从某个外部实体接到新增的存储上。很多课程设计文档被扣分就是因为上下文图画了罚款金额流出系统0层图却没有一个加工向外输出罚款金额前后对不上。画图工具我推荐ProcessOn原因很实际ProcessOn导出的系统数据流图默认是矢量格式拖进Word的课程设计文档里放大不糊。导出前把画布比例调到200%图片命名用图3-1 上下文数据流图这种带章节号的格式评审翻文档时能找到图就少一句质疑。3.2 0层数据流图借书、还书、图书管理主链路的加工与存储布局0层图是把上下文图里那一个大加工拆成主加工。图书馆管理系统按2.2的功能映射表拆成P1到P6六个加工数据存储固定为D1读者信息、D2馆藏信息、D3借阅记录、D4罚款记录、D5预约记录五个。这个数量对课程设计正合适少于三个说明只是把业务叙述复制了一遍多于八个则说明边界定得太碎评审会问为什么不在一个加工里完成。加工编号加工名称主要输入主要输出关联存储P1借书处理借书请求借阅凭证D1、D2、D3P2还书处理还书请求还书回执、罚款单D2、D3、D4P3续借与预约处理续借请求、预约请求续借结果、预约通知D3、D5P4图书管理采购清单、编目数据上架清单、馆藏变更D2P5读者管理注册信息、注销请求读者档案更新、注销回执D1P6统计查询查询条件、统计条件查询结果、统计报表D2、D3、D4画0层图时有两条守恒规则。第一数据守恒存入某个存储的数据必须来自某个加工的输出从存储读出的数据必须流向某个加工。比如D2馆藏信息被P1、P2读取被P4写入所以D2至少要有一进一出两条流方向不能画反。第二命名守恒流名要精确到业务含义。P1读D2时流名写作馆藏副本状态P4写D2时流名写作馆藏变更不要都叫馆藏信息否则数据字典没法登记。另一个高频错误是把存储当跳板画一条P1借书处理 → D3借阅记录 → P2还书处理的线好像存储能自己产生数据流给下一个加工。存储只是数据的存放处任何流经过存储都必须先由一个加工写入再由另一个加工读取中间没有自动传递。提示存储只是数据的存放处任何流经过存储都必须先由一个加工写入再由另一个加工读取。3.3 1层数据流图的拆分编号规则与父图子图平衡0层图画完评审通常会抽查一到两个核心加工往下拆。借书处理P1是必拆的因为它的加工逻辑最完整。P1按子功能拆成四个子加工P1.1校验读者资格、P1.2校验副本与额度、P1.3登记借阅记录、P1.4更新馆藏状态。子图的编号直接在父图加工编号后面加小数点P1.1、P1.2这种格式在软件工程课程设计文档里是被普遍接受的。P1子图的边界流与父图P1的对应关系如下这也是父图子图平衡检查的核心父图P1的边界流子图中的承接点方向借书请求P1.1校验读者资格外部流入子图借阅凭证P1.3登记借阅记录子图流出到外部D1读者信息P1.1读取存储到加工D2馆藏信息P1.2读取、P1.4写入双向D3借阅记录P1.3写入加工到存储平衡校验的规则是父图加工的输入输出流必须被子图的外部边界流完整承接。这里有一个容易被忽略的细节父图数据流借书请求是一个复合流在子图里被分解成读者证号和图书条码两个数据项分别进入P1.1和P1.2这时数据字典必须明确借书请求 读者证号 图书条码 操作时间 馆员编号否则评审可以判父子不一致。子图内部加工之间的流不需要在父图上单独出现那是合理的细化。拆完P1后如果还书处理P2也拆一层逻辑可以复用P2.1验收副本、P2.2计算逾期罚款、P2.3更新借阅记录与馆藏状态。这套先实体、再0层、后1层的分解办法直接套用到教务管理系统、成绩管理系统这类常见选题也一样成立先列出与系统打交道的角色再定主加工最后挑核心加工拆子图。4. 数据字典与加工逻辑说明让数据流图从图形变成可评审的规格4.1 数据字典的字段级定义数据流、数据存储与数据项怎么登记数据流图画的是结构数据字典登记的是细节。软件工程教材里通常把数据字典分成四类条目数据流、数据存储、数据结构、数据项课程设计文档只需用到前两类加数据项。记法上用等号表示组成加号表示并列。图书馆管理系统里最典型的一组定义如下借书请求 读者证号 图书条码 操作时间 馆员编号 借阅记录 记录编号 读者证号 图书条码 借出日期 应还日期 归还日期 续借次数 罚款金额 超期天数 × 每日罚款单价 超期天数 当前日期 − 应还日期 大于0时才生成罚款单这些定义落在文档里就是一张字典表评审抽查时最喜欢从这里下手条目类型名称定义备注数据流借书请求读者证号图书条码操作时间馆员编号上下文图与0层图共用数据存储D3借阅记录记录编号读者证号图书条码借出日期应还日期归还日期续借次数由P1写入、P2读取数据项罚款金额超期天数×每日罚款单价单位元保留两位小数数据项应还日期借出日期借阅期限参数默认借阅期限30天登记时要注意两个细节。第一单位和精度的约定写进备注比如罚款金额的单位是元、保留两位小数不然加工逻辑说明里写罚款金额超期天数×单价会被追问单价是什么单位。第二数据存储的条目里要说明谁写谁读这和0层图上的流方向必须一致。如果字典里写D3由P2写入数据流图上却只有P1指向D3两处必有一处错。4.2 用结构化语言和判定表写清加工逻辑数据字典解决数据是什么加工逻辑说明解决加工怎么变。加工逻辑说明有三种常用工具结构化语言、判定表、判定树。结构化语言适合描述顺序和计算多条件组合的场合用判定表更清楚判定树适合条件在三层以内又需要直观展示的场景。还书处理里的逾期罚款计算典型的结构化语言描述如下加工编号P2.2 名称计算逾期罚款 输入借阅记录含应还日期、当前日期、罚款单价参数 输出罚款单金额、缴纳状态 逻辑 超期天数 当前日期 − 应还日期 如果 超期天数 0 罚款金额 超期天数 × 罚款单价 生成罚款单缴纳状态 待缴纳 否则 不生成罚款单流程直接进入还书登记结构化语言不是伪代码它不允许出现编程语言的分支和循环写法只允许如果…则…否则…这类受限的自然语言目的是让不懂代码的评审也能核对业务规则。上例里缴纳状态待缴纳是系统的一个状态数据项必须在数据字典里登记否则这条加工说明又会在评审时多一个追问。多条件组合的业务用判定表。续借资格的判定表如下条件是读者无超期未还记录和续借次数小于两次条件 / 规则R1R2R3R4读者无超期未还记录真真假假续借次数 2真假真假允许续借真假假假判定表的价值是强迫你把条件组合穷尽。R3和R4在动作列都是拒绝续借写文档时可以把这两列合并成一条解释说明存在超期未还记录时无论续借次数多少均拒绝。评审看到判定表基本就不会再纠结边界条件覆盖的问题。4.3 数据字典与数据流图的交叉检查数据字典、数据流图、加工逻辑说明三者是互相锁定的关系课程设计文档最后一定要做一遍交叉检查。检查顺序建议是从图到字典、从字典到说明、从说明再回图。从图到字典把0层图和1层图里出现的每个数据流名、每个存储编号列一张清单逐个到数据字典里核对是否存在同名词条。P6统计查询输出的统计报表如果字典里没有定义就补一条统计报表 报表编号 统计周期 统计项目 数值。从字典到说明每个非平凡的叶子加工都要有一条加工逻辑说明纯查询类加工可以例外P1.1校验读者资格这种决策型加工必须有。从说明再回图加工逻辑说明里引用到的数据项必须在输入流、读取的存储、或输出流三者之一出现找不到的就是灰洞。这一步做完需求分析章节的完整性基本就够评审看了。软件工程毕业设计论文里数据字典和加工逻辑说明通常放在需求分析章节的末尾、数据模型章节之前顺序别放反。毕业设计被要求大改的原因多半是设计阶段才发现需求阶段漏了数据项交叉检查能提前暴露这类问题。5. 数据流图自检黑洞加工、奇迹加工与父图子图平衡的验证脚本评审数据流图时最常见的三类问题是黑洞加工、奇迹加工和灰洞加工。黑洞加工只有输入没有输出典型场景是登记借阅子加工画到一半漏了输出奇迹加工只有输出没有输入多半是把数据存储直接当成加工的数据来源灰洞加工输入输出都有但某个输出数据项的来源找不到比如应还日期缺少期限参数的计算依据。黑洞和奇迹可以交给脚本查。把图书馆管理系统各层加工整理成 dfd.json每个加工一条记录带子图的加工用 children 字段列出子加工border_in、border_out 只标记穿越子图边界的流内部加工之间的流不标记。存储的读写流按读D1读者信息写D3借阅记录这种带方向的流名登记父图与子图两侧保持同名。保存下面的脚本为 dfd_check.py与 dfd.json 放同一目录运行 python dfd_check.py。有输出就按加工编号问题类型逐条提示修改图后重跑直到无输出为止。# dfd_check.py —— 数据流图机器可查部分的校验脚本 import json def leaf_check(p): # 叶子加工必须有输入且有输出否则是黑洞或奇迹加工 if p.get(children): return None p_in, p_out set(p.get(in, [])), set(p.get(out, [])) if p_in and not p_out: return f{p[id]} {p[name]}黑洞加工只有输入没有输出 if p_out and not p_in: return f{p[id]} {p[name]}奇迹加工只有输出没有输入 return None def balance_check(p): # 父图边界流必须与子图边界流一致这是父图子图平衡的机器检查 children p.get(children) if not children: return [] border_in set() border_out set() for c in children: border_in | set(c.get(border_in, [])) border_out | set(c.get(border_out, [])) problems [] if set(p[in]) ! border_in: problems.append( f{p[id]} 父图入流 {sorted(set(p[in]))} f与子图边界入流 {sorted(border_in)} 不匹配) if set(p[out]) ! border_out: problems.append( f{p[id]} 父图出流 {sorted(set(p[out]))} f与子图边界出流 {sorted(border_out)} 不匹配) return problems def main(): with open(dfd.json, encodingutf-8) as f: data json.load(f) for p in data[processes]: msg leaf_check(p) if msg: print(msg) for msg in balance_check(p): print(msg) if __name__ __main__: main()脚本里三个字段要弄清in/out 登记加工的输入输出流children 登记子加工border_in/border_out 只在子加工上使用标记跨出子图边界的流。下面用 P1 借书处理的子图数据做一份 dfd.json注意 P1.1 的 border_in 登记借书请求P1.3 的 border_out 登记借阅凭证其余子图内部流不参与平衡比对{ processes: [ { id: P1, name: 借书处理, in: [借书请求], out: [借阅凭证], children: [ {id: P1.1, name: 校验读者资格, in: [借书请求], out: [读者证号, 图书条码], border_in: [借书请求]}, {id: P1.2, name: 校验副本与额度, in: [读者证号, 图书条码], out: [可借确认]}, {id: P1.3, name: 登记借阅记录, in: [可借确认], out: [借阅凭证], border_out: [借阅凭证]}, {id: P1.4, name: 更新馆藏状态, in: [可借确认], out: [馆藏变更]} ] } ] }灰洞加工脚本查不了只能人工核对因为输出能不能由加工逻辑算出需要语义判断。对每个叶子加工的输出数据项做三问这个数据项来自输入流吗来自加工读取的存储吗能由加工逻辑说明里的公式或判定表推导出来吗以罚款金额为例它等于超期天数乘以罚款单价超期天数来自借阅记录单价来自系统参数如果0层图里P2还书处理没有读取D4罚款记录加工逻辑说明里也没有单价参数这一处就是灰洞需要补数据流或补参数说明。把 dfd.json 的 children 分层与ProcessOn的画布分层对应起来每拆一层图就重跑一次 python dfd_check.py父图边界流始终跟得上子图数据流图这一章就不容易返工。本文还有配套的精品资源点击获取