监狱罪犯监管信息系统-综合设计成果/ ├── 00-交付清单/ manifest.json + README ├── 01-系统图表/ 8 类系统图（E-R / 功能结构 / 数据流 / 架构 / 流程 / 类图 / 时序 / 用例） ├── 02-设计资料/ 数据库脚本 └── 03-交付成果/ 设计文档 / 开题报告 / 答辩 PPT做计算机毕设或课程设计，最耗时间的往往不是写代码，而是把课题需求、数据库结构、系统图、文档和答辩材料整理成同一套成果。
这篇把一份真实的 监狱罪犯监管信息系统 交付包摊开：共35 个文件，其中32 张系统图、建库脚本9 张表、设计文档 / 开题报告 / 答辩 PPT 齐备。下面每一张图、每一个数字都来自这份真实产物。
交付清单
| 目录 | 文件数 | 内容 |
|---|---|---|
| 01-系统图表 | 32 | E-R 图 / 功能结构图 / 数据流程图（DFD） / 系统架构图 / 系统流程图 / UML 类图 / 时序图 / 用例图 |
| 02-设计资料 | 1 | 建库脚本（9 张表 / 10 个外键 / 189 行） |
| 03-交付成果 | 2 | 设计文档 / 开题报告 / 答辩 PPT |
功能结构图：一页看懂整个项目
功能结构图回答"系统由哪些模块组成"，它是文档章节与答辩 PPT 的骨架。本节展示 1 张，逐张说明。
模块树按"一级菜单 → 二级功能"展开，共覆盖 9 张业务表对应的维护功能。答辩前用它对照任务书数一遍：任务书要求的功能，在这张图上必须都能找到。
数据流程图（DFD）：从系统边界拆到具体处理
数据流图回答"数据从哪来、经过什么加工、存到哪里"，注意它和流程图不同：DFD 没有判定菱形，但有数据存储。本节展示 6 张（该图种共 11 张，其余同类图纸结构一致，未全部展开），逐张说明。
顶层图只做一件事：把系统当成一个黑盒，画清外部实体与它的数据往来。它决定了整套 DFD 的边界，画错了下面全错。
1 层图把系统按业务主线切开，每个加工对应一条主要业务，是后面 2 层展开的目录。
2 层图把「查询监舍信息」这一个加工内部拆开：输入来自哪里、中间做什么处理、结果写进哪个数据存储。看这张图重点核对"有没有凭空出现的数据流"。
2 层图把「查询通知公告信息」这一个加工内部拆开：输入来自哪里、中间做什么处理、结果写进哪个数据存储。看这张图重点核对"有没有凭空出现的数据流"。
2 层图把「发布公告通知公告」这一个加工内部拆开：输入来自哪里、中间做什么处理、结果写进哪个数据存储。看这张图重点核对"有没有凭空出现的数据流"。
2 层图把「维护监舍信息」这一个加工内部拆开：输入来自哪里、中间做什么处理、结果写进哪个数据存储。看这张图重点核对"有没有凭空出现的数据流"。
系统流程图：把业务规则画成可检查的路径
流程图回答"业务怎么走、什么条件走哪条分支"。本节展示 6 张（该图种共 14 张，其余同类图纸结构一致，未全部展开），逐张说明。
登录流程是通用流程，重点看三个判定：账号是否存在、密码是否正确、账号是否被停用——这三条也是答辩常问的校验点。
这条业务流程图把"提交 → 校验 → 办理 → 回写状态"画成可检查的路径，注意异常分支（校验不通过时回到哪一步、是否回滚）也要画出来。
这条业务流程图把"提交 → 校验 → 办理 → 回写状态"画成可检查的路径，注意异常分支（校验不通过时回到哪一步、是否回滚）也要画出来。
这条业务流程图把"提交 → 校验 → 办理 → 回写状态"画成可检查的路径，注意异常分支（校验不通过时回到哪一步、是否回滚）也要画出来。
这条业务流程图把"提交 → 校验 → 办理 → 回写状态"画成可检查的路径，注意异常分支（校验不通过时回到哪一步、是否回滚）也要画出来。
这条业务流程图把"提交 → 校验 → 办理 → 回写状态"画成可检查的路径，注意异常分支（校验不通过时回到哪一步、是否回滚）也要画出来。
UML 类图：从数据库结构推进到软件对象
类图回答"代码里有哪些类、类之间什么关系"，和 E-R 图最大的差别是：类图有方法。本节展示 1 张，逐张说明。
类图把 9 张表对应的实体类、它们的属性与方法，以及类之间的关联一次画全。和 E-R 图对照着看：属性区对应表字段，方法区对应业务动作。
时序图：看清参与者、页面、服务与数据交互
时序图回答"一次操作里对象之间怎么互相调用"，是答辩最容易追问答不上来的一张。本节展示 2 张，逐张说明。
「新增申诉与控告」这条时序图讲清一次业务动作里对象之间怎么互相调用。答辩被问"这里为什么分两步"，答案就藏在这张图的消息顺序里。
核心业务时序图是答辩的主力图：从页面发起，经接口层、业务层到数据层，把一次完整调用的顺序、参数与返回标清楚。
用例图：把角色与权限边界连起来
用例图回答"谁能用哪些功能"，角色数量必须和系统实际登录角色一致。本节展示 3 张，逐张说明。
分角色用例图把「UML用例图-监狱罪犯监管信息系统管理员角色」能做的功能单独圈出来，同时也隐含了"它不能做什么"——答辩最常问的就是后者。
分角色用例图把「UML用例图-监狱罪犯监管信息系统专管警员角色」能做的功能单独圈出来，同时也隐含了"它不能做什么"——答辩最常问的就是后者。
总体用例图给出角色与用例的完整边界，用它和登录页对照：登录页有几种角色，这张图上就该有几个角色。
九、数据库脚本初稿
脚本可直接导入 MySQL：9 张表 / 10 个外键 / 189 行。表与表的关系围绕"资产"这条主线展开：Admin、User、Shensu、Criminal、Criminal2、Room 等。
CREATEDATABASE`app_criminal`DEFAULTCHARACTERSETutf8mb4;USE`app_criminal`;CREATETABLE`Admin`(`id`varchar(32)NOTNULLDEFAULT(REPLACE(UUID(),'-',''))COMMENT'管理员主键',`username`varchar(20)NOTNULLCOMMENT'用户名',`password`varchar(255)NOTNULLCOMMENT'密码',`name`varchar(12)NULLCOMMENT'姓名',`avatar`varchar(255)NULLCOMMENT'头像',`tele`varchar(11)NULLCOMMENT'电话',PRIMARYKEY(`id`),)COMMENT'管理员';CREATETABLE`User`(`id`varchar(32)NOTNULLDEFAULT(REPLACE(UUID(),'-',''))COMMENT'专管警员主键',`username`varchar(20)NOTNULLCOMMENT'用户名',`password`varchar(255)NOTNULLCOMMENT'密码',`name`varchar(18)NULLCOMMENT'姓名',`avatar`varchar(255)NULLCOMMENT'头像',`gender`varchar(10)NULLCOMMENT'性别',`age`intNULLCOMMENT'年龄',`tele`varchar(11)NULLCOMMENT'电话',`numb`varchar(32)NULLCOMMENT'警号',PRIMARYKEY(`id`),)COMMENT'专管警员';CREATETABLE`Shensu`(`id`varchar(32)NOTNULLDEFAULT(REPLACE(UUID(),'-',''))COMMENT'申诉与控告主键',`jingy`varchar(32)NULLCOMMENT'负责警员',`shensr`varchar(32)NULLCOMMENT'申诉人',`createtime`datetimeNULLDEFAULTCURRENT_TIMESTAMPCOMMENT'申诉与控告时间',`shenskglx`varchar(255)NULLCOMMENT'申诉控告类型',`xiangxjl`varchar(255)NULLCOMMENT'详细记录',逐表说明：Admin（管理员）、User（专管警员）、Shensu（申诉与控告）、Criminal（罪犯）、Criminal2（重点罪犯）、Room（监舍）、Jiangc（奖惩信息）、Kaohe（罪犯考核记录）。每张表的字段注释都写全了，可以直接抄进论文的"数据库设计"章。
十六、常见问题
Q：这些图能直接放进论文吗？能。图是 PNG，按实体内涵命名，改完实体名重新导出即可。
Q：文档和 PPT 可以直接交吗？结构和排版可用，但文献、测试结果、研究现状必须自己补。
Q：为什么数据和图看起来这么"真"？因为图和数据同源：建库脚本的 9 张表决定实体，实体决定图上的方框，数据按业务语义生成。
十七、写在最后
一套 监狱罪犯监管信息系统 的初稿，图纸 19 张、建库脚本 9 张表、文档与 PPT 若干页，一次导出 35 个文件。
说实话的部分：
- 图、脚本、文档、PPT 都是初稿，业务名、参考文献、测试结果必须你自己核对与补齐；
- 数据是按业务语义生成的合理数据，但业务的特殊规则（如"资产报废后不可领用"）仍需你写进逻辑并验证；
- 生成快 ≠ 能交：从"有初稿"到"能答辩"，中间那一步永远是你自己的。
