企业官网建设流程全解析

医院病房管理系统-综合设计成果/ ├── 00-交付清单/ manifest.json + README ├── 01-系统图表/ 8 类系统图（E-R / 功能结构 / 数据流 / 架构 / 流程 / 类图 / 时序 / 用例） ├── 02-设计资料/ 数据库脚本 └── 03-交付成果/ 设计文档 / 开题报告 / 答辩 PPT

做计算机毕设或课程设计，最耗时间的往往不是写代码，而是把课题需求、数据库结构、系统图、文档和答辩材料整理成同一套成果。

这篇把一份真实的 医院病房管理系统 交付包摊开：共30 个文件，其中27 张系统图、建库脚本8 张表、设计文档 / 开题报告 / 答辩 PPT 齐备。下面每一张图、每一个数字都来自这份真实产物。

交付清单

功能结构图：一页看懂整个项目

功能结构图回答"系统由哪些模块组成"，它是文档章节与答辩 PPT 的骨架。本节展示 1 张，逐张说明。

模块树按"一级菜单 → 二级功能"展开，共覆盖 8 张业务表对应的维护功能。答辩前用它对照任务书数一遍：任务书要求的功能，在这张图上必须都能找到。

数据流程图（DFD）：从系统边界拆到具体处理

数据流图回答"数据从哪来、经过什么加工、存到哪里"，注意它和流程图不同：DFD 没有判定菱形，但有数据存储。本节展示 6 张（该图种共 7 张，其余同类图纸结构一致，未全部展开），逐张说明。

顶层图只做一件事：把系统当成一个黑盒，画清外部实体与它的数据往来。它决定了整套 DFD 的边界，画错了下面全错。

1 层图把系统按业务主线切开，每个加工对应一条主要业务，是后面 2 层展开的目录。

2 层图把「查询病房信息」这一个加工内部拆开：输入来自哪里、中间做什么处理、结果写进哪个数据存储。看这张图重点核对"有没有凭空出现的数据流"。

2 层图把「维护病房信息」这一个加工内部拆开：输入来自哪里、中间做什么处理、结果写进哪个数据存储。看这张图重点核对"有没有凭空出现的数据流"。

2 层图把「维护就诊」这一个加工内部拆开：输入来自哪里、中间做什么处理、结果写进哪个数据存储。看这张图重点核对"有没有凭空出现的数据流"。

2 层图把「办理查房」这一个加工内部拆开：输入来自哪里、中间做什么处理、结果写进哪个数据存储。看这张图重点核对"有没有凭空出现的数据流"。

系统流程图：把业务规则画成可检查的路径

流程图回答"业务怎么走、什么条件走哪条分支"。本节展示 6 张（该图种共 11 张，其余同类图纸结构一致，未全部展开），逐张说明。

登录流程是通用流程，重点看三个判定：账号是否存在、密码是否正确、账号是否被停用——这三条也是答辩常问的校验点。

这条业务流程图把"提交 → 校验 → 办理 → 回写状态"画成可检查的路径，注意异常分支（校验不通过时回到哪一步、是否回滚）也要画出来。

这条业务流程图把"提交 → 校验 → 办理 → 回写状态"画成可检查的路径，注意异常分支（校验不通过时回到哪一步、是否回滚）也要画出来。

这条业务流程图把"提交 → 校验 → 办理 → 回写状态"画成可检查的路径，注意异常分支（校验不通过时回到哪一步、是否回滚）也要画出来。

这条业务流程图把"提交 → 校验 → 办理 → 回写状态"画成可检查的路径，注意异常分支（校验不通过时回到哪一步、是否回滚）也要画出来。

这条业务流程图把"提交 → 校验 → 办理 → 回写状态"画成可检查的路径，注意异常分支（校验不通过时回到哪一步、是否回滚）也要画出来。

UML 类图：从数据库结构推进到软件对象

类图回答"代码里有哪些类、类之间什么关系"，和 E-R 图最大的差别是：类图有方法。本节展示 1 张，逐张说明。

类图把 8 张表对应的实体类、它们的属性与方法，以及类之间的关联一次画全。和 E-R 图对照着看：属性区对应表字段，方法区对应业务动作。

时序图：看清参与者、页面、服务与数据交互

时序图回答"一次操作里对象之间怎么互相调用"，是答辩最容易追问答不上来的一张。本节展示 2 张，逐张说明。

「新增就诊」这条时序图讲清一次业务动作里对象之间怎么互相调用。答辩被问"这里为什么分两步"，答案就藏在这张图的消息顺序里。

核心业务时序图是答辩的主力图：从页面发起，经接口层、业务层到数据层，把一次完整调用的顺序、参数与返回标清楚。

用例图：把角色与权限边界连起来

用例图回答"谁能用哪些功能"，角色数量必须和系统实际登录角色一致。本节展示 5 张，逐张说明。

分角色用例图把「UML用例图-医院病房管理系统病人角色」能做的功能单独圈出来，同时也隐含了"它不能做什么"——答辩最常问的就是后者。

分角色用例图把「UML用例图-医院病房管理系统管理员角色」能做的功能单独圈出来，同时也隐含了"它不能做什么"——答辩最常问的就是后者。

分角色用例图把「UML用例图-医院病房管理系统护士角色」能做的功能单独圈出来，同时也隐含了"它不能做什么"——答辩最常问的就是后者。

分角色用例图把「UML用例图-医院病房管理系统医生角色」能做的功能单独圈出来，同时也隐含了"它不能做什么"——答辩最常问的就是后者。

总体用例图给出角色与用例的完整边界，用它和登录页对照：登录页有几种角色，这张图上就该有几个角色。

九、数据库脚本初稿

脚本可直接导入 MySQL：8 张表 / 6 个外键 / 128 行。表与表的关系围绕"资产"这条主线展开：Admin、Doctor、Nurse、Patient、Room、Ruzhu 等。

CREATEDATABASE`cs_hospital`DEFAULTCHARACTERSETutf8mb4;USE`cs_hospital`;CREATETABLE`Admin`(`id`varchar(32)NOTNULLDEFAULT(REPLACE(UUID(),'-',''))COMMENT'管理员主键',`username`varchar(20)NOTNULLCOMMENT'用户名',`password`varchar(255)NOTNULLCOMMENT'密码',`name`varchar(12)NULLCOMMENT'姓名',`tele`varchar(11)NULLCOMMENT'电话',PRIMARYKEY(`id`),)COMMENT'管理员';CREATETABLE`Doctor`(`id`varchar(32)NOTNULLDEFAULT(REPLACE(UUID(),'-',''))COMMENT'医生主键',`username`varchar(20)NOTNULLCOMMENT'用户名',`password`varchar(255)NOTNULLCOMMENT'密码',`name`varchar(18)NULLCOMMENT'名称',`gender`varchar(10)NULLCOMMENT'性别',`tele`varchar(11)NULLCOMMENT'电话',`age`intNULLCOMMENT'年龄',`position`varchar(255)NULLCOMMENT'职位',`time`datetimeNULLCOMMENT'任职时间',PRIMARYKEY(`id`),)COMMENT'医生';CREATETABLE`Nurse`(`id`varchar(32)NOTNULLDEFAULT(REPLACE(UUID(),'-',''))COMMENT'护士主键',`username`varchar(20)NOTNULLCOMMENT'用户名',`password`varchar(255)NOTNULLCOMMENT'密码',`name`varchar(18)NULLCOMMENT'名称',`gender`varchar(10)NULLCOMMENT'性别',`tele`varchar(11)NULLCOMMENT'电话',`numb`varchar(32)NULLCOMMENT'编号',

逐表说明：Admin（管理员）、Doctor（医生）、Nurse（护士）、Patient（病人）、Room（病房）、Ruzhu（入住）、Jiuzhen（就诊）、Chafang（查房）。每张表的字段注释都写全了，可以直接抄进论文的"数据库设计"章。

十六、常见问题

Q：这些图能直接放进论文吗？能。图是 PNG，按实体内涵命名，改完实体名重新导出即可。

Q：文档和 PPT 可以直接交吗？结构和排版可用，但文献、测试结果、研究现状必须自己补。

Q：为什么数据和图看起来这么"真"？因为图和数据同源：建库脚本的 8 张表决定实体，实体决定图上的方框，数据按业务语义生成。

十七、写在最后

一套 医院病房管理系统 的初稿，图纸 21 张、建库脚本 8 张表、文档与 PPT 若干页，一次导出 30 个文件。

说实话的部分：

• 图、脚本、文档、PPT 都是初稿，业务名、参考文献、测试结果必须你自己核对与补齐；
• 数据是按业务语义生成的合理数据，但业务的特殊规则（如"资产报废后不可领用"）仍需你写进逻辑并验证；
• 生成快 ≠ 能交：从"有初稿"到"能答辩"，中间那一步永远是你自己的。