简介一份学生成绩管理系统数据流图PDF面向需要完成软件工程课程设计、毕业设计或进行系统建模分析的读者解决成绩管理系统中“数据从哪里来、经过哪些处理、流向哪里”的逻辑梳理问题。资源包含顶层图、0层图、1层图三个层级清晰刻画教师信息管理、学生信息管理、课程信息管理、选课管理、成绩处理等关键功能外部实体、加工过程、数据存储与数据流均标注完整可直接对照绘制同类系统或作为设计文档参考。整个包仅含1个PDF文件压缩后大小166KB内容紧凑便于下载此样例已有2248人学习浏览是绘制数据流图时较为实用的参考。对于需要快速掌握数据流图规范并完成成绩管理相关项目的读者具有直接的借鉴价值。1. 学生成绩管理系统数据流图先画上下文图而不是先画箭头接到补一张“学生成绩管理系统数据流图.pdf”的活儿很多人第一反应是打开工具拖箭头画到一半才发现数据来源没定、审核状态没人更新、查询结果没出口只能推倒重来。数据流图的价值在于迫使你先把数据边界想清楚成绩从哪里进入系统经过录入、审核、查询、统计这些加工最后以什么形式交给学生、教师和教务管理员。做课程设计、写系统需求分析、维护教务项目的人都能从这张图里找到后续设计表结构、拆接口、定权限的依据。下文按符号规则、上下文图、1 层分解、2 层平衡到 PDF 导出的顺序展开照着走能复现一套可直接评审的图。2. 看懂数据流图学生成绩管理系统的符号、分层与系统边界2.1 四类元素怎么认外部实体、加工、数据存储、数据流一张 DFD 里只有四类东西。外部实体是系统以外的角色学生、教师、教务管理员都画在边界外用矩形表示加工表示数据被转换的地方在学生成绩管理系统里就是“成绩录入”“成绩审核”“成绩查询”这些动作用圆或圆角矩形数据存储是数据停留的位置例如学生信息表、课程表、成绩表用双横线或开口矩形数据流是箭头表达的是数据包从一个节点流向另一个节点不是控制信号。常见错误是拿“点击按钮”“页面跳转”作为数据流点击是操作事件数据流上流动的是“查询请求”这类名词性数据。元素DFD 常用符号学生成绩管理系统中的实例命名建议外部实体矩形学生、教师、教务管理员用具体角色名少用“用户”加工圆/圆角矩形1 成绩录入与修改、2 成绩审核与发布动词宾语例如“录入成绩”数据存储双横线/开口矩形D1 学生信息表、D2 课程表、D3 成绩表表名或文件名带编号数据流箭头标签成绩登记表、查询条件、成绩单名词性短语方便建数据字典命名这一步决定了后面能不能做平衡校验。“用户查询成绩”这种带主谓结构的箭头不适合做数据字典条目我一般要求数据流名全部改成名词词组例如把“用户查询成绩”拆成“查询请求”和“成绩查询结果”。在较完整的教务管理系统数据流图里边界之外还会有院系、辅导员甚至报表接收单位外部实体一旦变多命名不规范会让上下文图直接乱掉。2.2 分层规则上下文图、1 层分解、2 层细化各管多宽数据流图用分层来控制单张图的复杂度。上下文图也叫顶层图把整个学生成绩管理系统当作唯一加工编号写 0只表达外部实体和系统的数据往来1 层图把加工 0 按主要功能展开成 5 到 7 个加工画出加工之间的数据流以及加工对数据存储的读写2 层图再把某一个 1 层加工继续细化。这样每一张图上的节点数量都能控制在 7 个左右评审时按层次看不用面对一版挤满几十个箭头的巨型图。层次之间存在等价约束父图中的一个加工与它对应的子图在外部输入输出上必须一致。举例来说如果 1 层图里加工 1“成绩录入与修改”的输入只有“成绩登记表”和“成绩修改申请”那么它的 2 层子图边界上也只能出现这两个输入流不能因为子图里多了一个“学生照片”就把新的流加进去。一旦在子图里发现父图没画过的数据流要先改父图再改子图否则文档和系统最终实现会越走越偏。2.3 用核心加工反推系统边界到底做成绩子系统还是教务系统选实体之前先确认边界。如果需求文档写的是“学生成绩管理系统”通常外部实体只保留学生、教师、教务管理员三个选课数据可以由外部系统提供如果需求其实是“教务管理系统”外部实体里还要出现教学秘书、辅导员、排课人员。边界不同上下文图完全不一样。一个实用的做法是在画图之前把边界清单写成结构化数据用 JSON 把外部实体和它们的数据流先定下来再照着画图{ process: 0-学生成绩管理系统, external_entities: [ { id: E1, name: 学生, to_system: [成绩查询请求], from_system: [成绩查询结果, 成绩单] }, { id: E2, name: 教师, to_system: [成绩登记表, 成绩修改申请], from_system: [录入回执, 修改回执] }, { id: E3, name: 教务管理员, to_system: [审核意见], from_system: [待审核成绩记录, 已发布成绩单] } ] }这段 JSON 中to_system是各实体发给系统的数据流from_system是系统返回的数据流。id要稳定后续 1 层图里的数据流名直接复用这里的字符串能保证上下文图与 1 层图不会出现同义不同名的情况。实际项目里如果从外部选课系统拿课程数据我会在这里再加一个 E4“选课系统”数据流就是“选课结果集”而不是把选课功能画进系统内部。提示上下文图是整份学生成绩管理系统数据流图的根画完先让需求方确认外部实体集合再向下分解。外部实体改一个下面所有层的边界都可能要跟着改。3. 从上下文图到 1 层分解成绩录入、审核、查询的数据流怎么画3.1 先画上下文图三个外部实体与加工 0 的数据往来上下文图本身很简单中间一个编号为 0 的加工“学生成绩管理系统”外面排布 E1 学生、E2 教师、E3 教务管理员。学生向系统发“成绩查询请求”系统返回“成绩查询结果”和“成绩单”教师向系统提交“成绩登记表”和“成绩修改申请”系统返回“录入回执”和“修改回执”教务管理员收到“待审核成绩记录”向系统返回“审核意见”系统再发布“已发布成绩单”。这张图不需要画数据存储因为加工 0 内部的数据存储对边界来说是不可见的部分。受箭头交叉限制实体摆放顺序可以调整E1 放左侧、E2 放下方是比较符合阅读习惯的排法导出 PDF 时也更省版面。上下文图仅表达“系统对外提供什么”这也是系统需求分析里经常作为评审第一页的内容。3.2 1 层图的加工划分5 个加工的标准方案把加工 0 分解成 1 到 5 个加工覆盖成绩从进入到输出的完整生命周期。我一般用下面这套方案它同时满足课程设计和真实教务项目的基本需要加工编号加工名主要输入主要输出读写存储1成绩录入与修改成绩登记表、成绩修改申请录入回执、修改回执、待审核成绩记录读 D2写 D32成绩审核与发布待审核成绩记录、审核意见已发布成绩单读 D3写 D33成绩查询成绩查询请求成绩查询结果读 D1、D2、D34成绩统计与分析统计条件、成绩汇总请求统计报表、及格率分析读 D35成绩单打印打印请求成绩单读 D3加工 1 负责写入和变更输出“待审核成绩记录”给加工 2加工 2 审核通过后成绩才进入“已发布”状态学生查询时只看到发布状态的数据。加工 3 读的是 D1、D2、D3 三个存储的关联结果需要注意的是 1 层图里加工 3 与数据存储 D3 之间是双向箭头的写法还是两条单向箭头一般推荐拆成“查询请求流入 D3”和“成绩结果流出 D3”两条避免双向箭头定义含糊。这个表同时定义了数据流的上下游画完 1 层图后加工之间的数据流名称直接从表格里取。比如加工 1 输出给加工 2 的流叫“待审核成绩记录”审核未通过时加工 2 还会输出给加工 1 一条“退回理由”流这些细节在画图时补全即可。这样加工之间的耦合关系一目了然。3.3 数据流命名与后端字段精度对齐成绩表用 DECIMAL(5,2)数据流图最终要落到实现。到 2 层阶段数据字典里每个数据项都得有类型和精度否则“总评成绩”在一位工程师那里是整数在另一位那里是浮点小数统计结果对不上。成绩数据的关键字段建议用 SQL 定义固定下来CREATE TABLE score_record ( student_id CHAR(10) NOT NULL COMMENT 学号, course_id CHAR(8) NOT NULL COMMENT 课程编号, regular_score DECIMAL(5,2) COMMENT 平时成绩0-100, exam_score DECIMAL(5,2) COMMENT 期末成绩0-100, final_score DECIMAL(5,2) COMMENT 总评成绩0-100, gp_point DECIMAL(3,1) COMMENT 绩点如 3.7, teacher_id CHAR(6) NOT NULL COMMENT 录入教师工号, audit_status TINYINT NOT NULL DEFAULT 0 COMMENT 0待审核 1通过 2退回, update_time DATETIME NOT NULL COMMENT 最近修改时间, PRIMARY KEY (student_id, course_id) ) COMMENT 成绩记录表;这段 SQL 里DECIMAL(5,2)表示最多 5 位数字、小数部分占 2 位能覆盖 0 到 999.99成绩场景只用 0-100 范围余量留给可能的附加分或百分制扩展。绩点DECIMAL(3,1)保留 1 位小数对应常见的 4.0 绩点制。audit_status用TINYINT加注释而不是直接存字符串在数据流图的数据字典里只描述“审核状态”这个数据项具体取值在这里约定。数据流图上的“成绩登记表”里的每个数据项都能在这张表里找到对应字段图和分析模型才算真正对齐。4. 2 层分解与平衡校验成绩查询修改的数据流图细化到可落库4.1 把加工 1“成绩录入与修改”拆成 2 层子图1 层图定义了 5 个加工评审时最容易出问题的是加工 1因为它同时处理录入和修改内部校验逻辑完全不一样。我一般把加工 1 再拆成 4 个更小的加工子加工编号子加工名输入输出1.1校验成绩数据成绩登记表、D2课程表合法成绩记录、非法成绩提示1.2写入成绩表合法成绩记录写入确认、待审核成绩记录1.3处理修改申请成绩修改申请修改前快照、修改后记录1.4生成回执写入确认、修改后记录录入回执、修改回执子加工 1.1 的输入里出现了对 D2 课程表的读取这是为了让子图表达“校验课程是否存在”此时 D2 必须画进子图。1.3 处理修改申请时还要做一次审核状态检查已经被发布过的成绩不能直接改这条规则可以在加工说明里用文字描述也可以在数据字典里给“修改申请”增加一个“当前审核状态”数据项。这里所有子加工的数据流加起来必须与父图边界一致。父图加工 1 的输入是“成绩登记表、成绩修改申请”输出是“录入回执、修改回执、待审核成绩记录”子图的边界输入输出也必须完全一样中间多出来的“非法成绩提示”“写入确认”属于子图内部流不跨边界。4.2 用脚本做父子平衡检查照着 JSON 数据字典核对人工核对几十条数据流容易看漏我把数据字典导出成 JSON再用简短脚本做一次集合差检查。这个脚本不依赖具体画图工具只要命名统一就能用def check_dfd_balance(parent_name, parent_in, parent_out, child_in, child_out): loss_in parent_in - child_in loss_out parent_out - child_out extra_in child_in - parent_in extra_out child_out - parent_out if not (loss_in or loss_out or extra_in or extra_out): print(f[OK] {parent_name} 子图边界与父图一致) return print(f[FAIL] {parent_name} 子图边界不平衡) if loss_in: print( 父图有、子图缺的输入:, loss_in) if extra_in: print( 子图多出的输入:, extra_in) if loss_out: print( 父图有、子图缺的输出:, loss_out) if extra_out: print( 子图多出的输出:, extra_out) parent_name 1-成绩录入与修改 parent_in {成绩登记表, 成绩修改申请} parent_out {录入回执, 修改回执, 待审核成绩记录} child_in {成绩登记表, 成绩修改申请} child_out {录入回执, 修改回执, 待审核成绩记录} check_dfd_balance(parent_name, parent_in, parent_out, child_in, child_out)脚本原理是两轮集合差第一轮拿父图数据流减子图边界数据流缺了说明子图画漏第二轮拿子图边界减父图多了说明子图加了父图不承认的流。parent_in、parent_out里的标签必须与数据字典完全一致差一个空格或错一个同义词就会报“父图有、子图缺”或“子图多出”。实际项目里经常出现父图画“成绩登记表”、子图画“成绩登记单”这种同义不同名的情况脚本会立刻把问题暴露出来这也是我在数据流命名上坚持用名词词组的原因。4.3 三个必核对参数精度、审核状态、加工编号2 层图审完平衡再核对三个细节。第一所有成绩相关字段使用DECIMAL数据库查询做 AVG、SUM 时结果不会出现 0.10.2 的浮点偏差这直接关系到“成绩统计与分析”加工输出报表的准确性。第二审核状态字段的取值要跟数据字典、2 层子加工说明三处一致比如“0 待审核、1 通过、2 退回”不能图里写“待审核/通过/驳回”表里却用布尔值。第三加工编号从 1.1、1.2 编到 1.4图号和子图标题都带这个编号PDF 内引用时直接写“见图 1.2”即可。注意不要为了追求层级多而把加工拆到 3 层以上。学生成绩管理系统的 2 层图已经足够表达校验、写入、修改的逻辑再往下拆只会让数据流图退化成程序流程图。把加工 1 拆完后加工 3“成绩查询”和加工 4“成绩统计与分析”通常不需要拆到 2 层它们的逻辑可以在加工说明里写清楚。这套分层下来数据流图连同数据字典一起就已经可以支撑后端表结构设计和接口定义了。5. 导成 PDF 前的自检清单图幅、字体、缩放与层级索引5.1 图幅与缩放上下文图放一页1 层图横向 A4文件名叫“学生成绩管理系统数据流图.pdf”导出质量就从配图变成正式交付物。第一件事是把每张图放到独立页面上下文图用纵向 A41 层图和 2 层子图用横向 A4避免一张图被 PDF 的页面切割成两半。Draw.io 或 ProcessOn 这类工具一般都有“适应页面”或“页面设置”选项导出前先把画布边缘留白调到 20px 以上再把缩放设为按页面宽度否则打印后箭头会细到看不清。5.2 自检清单从图面到逻辑四步过一遍导出 PDF 之前我按下面这张表逐项过一遍检查项检查内容通过标准外部实体是否独立于系统边界实体不与加工直接重叠均有输入输出流数据流是否每条流都有名字命名与数据字典条目完全一致加工是否每个加工都有输入和输出无黑洞、灰洞、奇迹所有编号连续存储是否有双向含混箭头读写分别表达存储至少有读取或写入层级每一张子图边界是否与父图对应用平衡脚本跑过输出全部为 OK其中“黑洞”指只有输入没有输出的加工“奇迹”指只有输出没有输入的加工“灰洞”指输入不足以产生输出这三个词在软件工程评审里经常直接拿来做检查项。出现这些问题时优先返回第 2 层子图修正边界而不是只改一根箭头。5.3 把图号、数据字典和加工说明放进 PDF 的同一页最后一步是保证可读性在每张图下方加一行图题格式统一为“图 3-2 学生成绩管理系统 1 层数据流图”图号与章节号绑定数据字典不要单独附在最后建议把与图直接相关的数据流条目放在该图后面一页评审时不用来回翻。导出前用 PDF 阅读器放大到 300% 检查箭头连接点是否断开、文字是否重叠、中文是否出现留白所有图题的编号顺序再顺着读一遍。做完这一步这份数据流图才算真正能从需求分析进入设计评审。本文还有配套的精品资源点击获取
