简介一套面向软件工程课程设计的酒店管理系统完整项目适合软件工程、数据库及管理信息系统课程的本科生作课程设计参考。项目模拟酒店实际运营流程划分系统用户、客房标准、客房信息、订房信息与结算信息五大核心模块覆盖权限分配、动态房价、实时房态、预订冲突检测及多种支付结算等典型业务场景。压缩包共195个文件约17.85MB以C源文件.h/.cpp、数据库.mdb及可执行程序.exe为主同时包含Visual C工程配置.dsp/.dsw和课程设计报告.doc/.docx等材料便于直接打开、编译与查阅。目前已有1228人学习下载。通过该资源读者可获得可运行的酒店管理系统源码、数据库表结构、界面图标与背景资源、课程设计报告及答辩PPT既能支撑课程设计答辩也可从中理解软件工程需求分析、模块划分、编码与测试流程。1. 课程设计不是写代码是“按流程造轮子”酒店管理系统到底在考察什么拿到“软件工程课程设计——酒店管理系统”这个题目最忌讳的一件事就是直接打开 IDE 开始建窗体。这门课设表面上是写一个能跑的管理后台实际上考的是你有没有走完软件工程的全流程需求分析、用例建模、数据库设计、分层实现、测试记录、文档答辩。酒店业务足够经典客房、预订、入住、退房、账单这些模块边界清楚又天然带有日期冲突和并发操作这类容易翻车的点用来考察需求分析和系统设计能力正合适。适合谁来照着做如果你正被课程设计卡住或者想用最短路径把整个流程跑完整这篇笔记就是给你准备的。2. 从用例图到数据表四个核心模块的设计顺序与状态机2.1 用例图与需求边界画清楚“谁在用、能做什么”软件工程课程设计的第一份交付物不是代码是用例图。酒店管理系统的用例图如果画得对后面建表、写接口、做界面几乎是被推着走的如果画错了后面每写一个功能都在打补丁。我一般把角色分成三类前台、经理、系统管理员。前台负责预订、入住、退房、换房、挂账和查询经理看报表和统计分析系统管理员维护用户和房间基础数据。这个划分不是拍脑袋它直接决定了权限模块的粒度——如果你把管理员和前台混成一个角色登录后的菜单就会乱掉。角色与核心用例的对应关系课程设计里通常按这张表来定角色核心用例验收标准前台预订、入住、退房、换房、查询能完成“预订→入住→退房→结算”的完整链路经理入住率报表、营收统计能按日期区间看到统计结果而不是只能看原始列表管理员用户管理、房间类型维护能增删改查用户和房型操作有权限校验用例图画完紧接着要做的事是给每个用例写一段用例描述包含前置条件、主流程、异常流程。比如“预订房间”的异常流程至少要有三种日期冲突、房间被锁定、游客身份证号已存在。这些内容到写测试用例时会原封不动地变成测试步骤所以这一步偷懒后面全部翻车。2.2 数据库设计五张主表和一条核心外键链酒店管理系统的表结构不需要很多常见的做法是六张表用户表、房间表、客人表、预订表、入住记录表和账单表。表之间有一条清晰的外键链客人→预订→入住记录→账单。多一张冗余表不如多一条清晰的外键关系这句话在课设评分里很重要。建表 SQL 我一般写成这样CREATE TABLE sys_user ( id INT PRIMARY KEY AUTO_INCREMENT, username VARCHAR(50) NOT NULL UNIQUE, password VARCHAR(64) NOT NULL, role TINYINT NOT NULL DEFAULT 2 COMMENT 1-管理员, 2-前台, 3-经理, real_name VARCHAR(50) ); CREATE TABLE room ( id INT PRIMARY KEY AUTO_INCREMENT, room_no VARCHAR(10) NOT NULL UNIQUE, room_type VARCHAR(20) NOT NULL, price DECIMAL(10,2) NOT NULL, status TINYINT NOT NULL DEFAULT 0 COMMENT 0-空闲, 1-已预订, 2-已入住, 3-脏房, 4-维修 ); CREATE TABLE guest ( id INT PRIMARY KEY AUTO_INCREMENT, id_card VARCHAR(18) NOT NULL UNIQUE, name VARCHAR(50) NOT NULL, phone VARCHAR(20) ); CREATE TABLE reservation ( id INT PRIMARY KEY AUTO_INCREMENT, guest_id INT NOT NULL, room_id INT NOT NULL, checkin_date DATE NOT NULL, checkout_date DATE NOT NULL, status TINYINT DEFAULT 1 COMMENT 1-生效, 2-已入住, 3-已取消, 4-已完成, FOREIGN KEY (guest_id) REFERENCES guest(id), FOREIGN KEY (room_id) REFERENCES room(id) ); CREATE TABLE checkin_record ( id INT PRIMARY KEY AUTO_INCREMENT, reservation_id INT, guest_id INT NOT NULL, room_id INT NOT NULL, checkin_time DATETIME NOT NULL, checkout_time DATETIME, total_amount DECIMAL(10,2), FOREIGN KEY (guest_id) REFERENCES guest(id), FOREIGN KEY (room_id) REFERENCES room(id) );几个配置上的讲究price 字段用 DECIMAL(10,2) 而不是 FLOAT因为浮点数算钱会有精度丢失退房结算时多一分少一分很尴尬status 字段用 TINYINT 存数字状态而不是直接存中文是为了后面加索引和做统计时写法干净每个表都带 UNIQUE 约束的字段username、room_no、id_card这是防止重复数据的最后一道防线。2.3 房间状态机从空闲到脏房的流转规则房间状态是酒店系统的核心状态机所有业务操作本质上都是在驱动房间状态迁移。当前状态触发动作下一状态空闲前台预订已预订已预订客人到店办理入住已入住已入住退房结算脏房脏房保洁打扫完成空闲任意状态管理员报修维修维修维修完成空闲这个状态机看起来简单但落地时经常有人漏掉“脏房”这一环。很多课设代码里房间状态只有空闲和入住两种退房之后直接置回空闲结果就是这个房间在保洁还没打扫的情况下又被订出去了。课程设计的老师可能不会实际去验证保洁流程但你在数据库里把状态流转做完整答辩时能讲的东西就多了一个维度。状态机的落点应该在数据库的唯一约束上。比如入住记录表按 room_id 和 checkout_time IS NULL 建一个唯一索引保证同一房间同时只有一条未退房记录这个后面并发章节会细说。3. 分层架构与代码落地Java Swing MySQL 的最小可跑通骨架3.1 为什么课程设计普遍选 Java Swing MySQL而不是 Spring Boot课程设计的评分重点从来不是技术栈有多新而是你有没有把软件工程的流程走完整。Spring Boot 固然是好东西但对于一个两周内的课设来说光环境配置和依赖管理就可能吃掉一半时间而且多数人写出来的 Spring Boot 项目只是个套壳 CRUD反而讲不清楚分层是怎么回事。常见的做法是 Java Swing 做界面层 JDBC 做数据访问层 MySQL 存数据。Swing 的好处是界面代码和业务逻辑在同一个工程里课堂答辩时可以直接从按钮事件一路追到 SQL 语句老师一眼就能看出你的分层思路。用 Python 做课设的同学也类似用 tkinter sqlite3 也能走出同样的分层只是 JDBC 换成驱动 API、MySQL 换成 sqlite3 模块而已。分层上我建议至少分成三层界面层只负责组件和事件监听、业务层负责状态判断和流程编排、数据层只做 SQL 的执行与结果映射。千万别在按钮事件里直接写 SQL那样答辩时你会被一句“你这里为什么出现两条一模一样的 JDBC 代码”问住。3.2 数据库连接单例别在每个方法里重写 DriverManager新手最容易犯的错是每一个方法里都写一遍 Class.forName 和 DriverManager.getConnection。这样做开发时没问题但程序一跑起来每个操作都新建连接、用完不关几天后数据库连接数就爆了。课程设计虽然不会真的被并发打爆但这个坏习惯在代码审查时属于明显减分项。我一般会用一个连接工具类把连接的创建和关闭收敛到一个地方public class DBUtil { private static final String URL jdbc:mysql://localhost:3306/hotel_db?useSSLfalseserverTimezoneAsia/Shanghai; private static final String USER root; private static final String PASSWORD 123456; static { try { Class.forName(com.mysql.cj.jdbc.Driver); } catch (ClassNotFoundException e) { e.printStackTrace(); } } public static Connection getConnection() throws SQLException { return DriverManager.getConnection(URL, USER, PASSWORD); } public static void close(Connection conn, Statement stmt, ResultSet rs) { if (rs ! null) { try { rs.close(); } catch (SQLException ignored) {} } if (stmt ! null) { try { stmt.close(); } catch (SQLException ignored) {} } if (conn ! null) { try { conn.close(); } catch (SQLException ignored) {} } } }这段代码有三个关键点。定义里 URL 带了 useSSLfalse 和 serverTimezone 参数前者避免本地 MySQL 的 SSL 握手警告后者解决 JDBC 8.x 与 MySQL 时区不一致导致的报错静态代码块里加载驱动类保证驱动只加载一次close 方法对三个资源分别判空关闭避免哪里忘了关连接导致数据库连接耗尽。你看这个工具类虽然简单但每一行都有存在的理由答辩时能讲出这些参数的含义远比背概念得分高。3.3 登录与权限控制prepareStatement 为什么必须替代字符串拼接登录功能是所有课程设计里第一个写的功能也是最容易被问出问题的功能。很多人的第一版写法是用字符串拼接 SQL这属于典型的血泪教训。// 错误示范这种方式会被 SQL 注入击穿 String sql SELECT * FROM sys_user WHERE username username AND password password ;输入框里输入admin OR 11密码随便填这条 SQL 就变成了恒真查询账号直接绕过。课程设计不能只跑通还要经得起追问。用 PreparedStatement 替代字符串拼接是最基础的防线public User login(String username, String password) { String sql SELECT * FROM sys_user WHERE username ? AND password ?; try (Connection conn DBUtil.getConnection(); PreparedStatement ps conn.prepareStatement(sql)) { ps.setString(1, username); ps.setString(2, md5(password)); try (ResultSet rs ps.executeQuery()) { if (rs.next()) { User user new User(); user.setId(rs.getInt(id)); user.setUsername(rs.getString(username)); user.setRole(rs.getInt(role)); user.setRealName(rs.getString(real_name)); return user; } } } catch (SQLException e) { e.printStackTrace(); } return null; }两个细节值得注意参数通过 setString 注入SQL 语句本身提前编译输入值只作为参数参与比较注入语句就失去了语义密码这一栏我在代码里写了 md5(password) 的调用这是示意你要对密码做哈希而不是明文存储但 MD5 在现代场景下不够安全如果时间允许换成 BCrypt 会更稳妥答辩时主动说出这一点反而加分。登录成功后的 User 对象里存了 role 字段进入主界面后根据角色值决定菜单可见性这就是前面用例图里角色划分的落地。真正卡住人的其实不是登录本身而是你拿到 user 对象之后没有做权限判断导致权限形同虚设。4. 并发预订与日期冲突酒店系统最容易翻车的三个业务边界4.1 日期冲突检测一条 SQL 拦住同房间同一天被订两次酒店系统的所有业务逻辑里最容易挂的就是日期冲突检测。用一个简单的条件判断“待订入住日 已有预订退房日”是不够的因为存在完全包含、部分重叠、前后相接三种情况。判断两个时间段重叠的标准条件是已有预订的入住日 新预订的退房日 并且 已有预订的退房日 新预订的入住日。SQL 里写成这样SELECT COUNT(*) FROM reservation WHERE room_id ? AND status IN (1, 2) AND checkin_date ? AND checkout_date ?这里的两个参数分别是新预订的退房日和入住日。查询结果大于 0说明该房间在这个时间段内存在生效中的预订或入住浏览器端要弹冲突提示。这个条件能同时覆盖“新入住日在已有预订期间内”和“已有预订期间在新入住区间内”两种情况写一次就够。边界情况也要想清楚退房日当天中午 12 点是默认的结算时间所以如果你预订 5 月 1 日入住、5 月 3 日退房那么 5 月 3 日当天房间应该可以被下一个客人预订。上面 SQL 里用的是严格小于和严格大于天然允许了退房日当天被重新预订这一步处理对很多新手来说是个隐藏坑。4.2 房间状态的双写问题数据库状态才是唯一真源很多课设做房间列表时会在界面层用一个集合对象缓存所有房间的状态然后在前台界面上实时修改这个集合觉得这样“界面刷新快”。这属于把简单问题复杂化而且会引入一个非常隐蔽的 bug页面上的状态和数据库里的状态不一致重启程序后明明数据库显示房间空闲界面上还挂着已入住。正确做法是数据库里的 status 字段是唯一真源界面只负责展示查询结果不承担状态存储职责。每次状态变更都通过 SQL 更新数据库再重新查询一次刷新列表代价很小但一致性永远有保证。状态更新时记得用状态值做条件过滤这是第二种冲突形态。比如执行入住操作时SQL 应该写成UPDATE room SET status 2 WHERE id ? AND status 1;注意这里带上了 AND status 1意思是只有房间当前处于“已预订”状态才允许入住。如果 UPDATE 影响行数为 0说明房间状态已经被别人改过了业务层就应该抛出异常提示。这种方式叫乐观锁的简单形态虽然课设没有高并发环境但这个写法和“直接 SET status 2”有本质区别。4.3 事务与锁退房结算中途崩溃怎么保证账单和房间状态一致退房流程要同时干两件事写入账单记录、把房间状态改成脏房。如果第一步成功而第二步失败就会出现客人已经走了但房间还是已入住状态的脏数据。代码上必须把这两个操作放进同一个事务里Connection conn null; try { conn DBUtil.getConnection(); conn.setAutoCommit(false); // 插入账单记录金额来自入住时锁定的房价 PreparedStatement ps1 conn.prepareStatement( INSERT INTO checkin_record (guest_id, room_id, checkin_time, checkout_time, total_amount) VALUES (?, ?, ?, NOW(), ?)); ps1.setInt(1, guestId); ps1.setInt(2, roomId); ps1.setBigDecimal(3, amount); ps1.executeUpdate(); // 房间状态改为脏房 PreparedStatement ps2 conn.prepareStatement( UPDATE room SET status 3 WHERE id ?); ps2.setInt(1, roomId); ps2.executeUpdate(); conn.commit(); } catch (SQLException e) { if (conn ! null) { try { conn.rollback(); } catch (SQLException ignored) {} } e.printStackTrace(); } finally { if (conn ! null) { try { conn.setAutoCommit(true); conn.close(); } catch (SQLException ignored) {} } }关键点是 setAutoCommit(false) 之后的 commit 和 rollback 必须成对出现。这里有个容易忽略的细节finally 里要把 autoCommit 恢复成 true 再关闭连接因为连接池复用时不会帮你重置这个属性下次从池里拿出来的连接可能还带着上次的事务设置。课程设计虽然用不到连接池但你把这个细节写进代码注释里答辩时解释清楚属于典型的“超出预期的加分点”。事务里还要想一件事入住时锁定的到底是哪个房价课程设计里通常简单处理成 room 表里的当前价格但真实酒店的价格会随房型、日期和会员等级浮动。如果你在入住记录表里冗余存了当时的价格字段total_amount后面房价调整就不会影响历史账单这个设计思路值得在答辩时主动讲出来。5. 课程设计常见问题与避坑从重复预订到答辩被问崩的六个教训5.1 需求阶段别把“房间管理”做成“房间增删改查”现象很多人的需求分析里写“房间管理模块实现房间的增删改查”然后就照着这个去写代码最后系统能跑但老师一问“你的系统怎么处理换房需求”直接愣住。原因需求分析只停留在数据层的 CRUD 思维没有从业务角度抽象功能。酒店业务的真实需求是客人住到一半想换房系统要同时处理原房间的退订和恢复空闲、新房间的状态变更、可能存在的差价结算。解决做需求分析时每一个用例要问三个问题前置条件是什么、触发后有哪些数据要变、失败时怎么回滚。把这三个问题写成文字放在需求规格说明里就算代码实现得粗糙需求分析部分也是及格的。5.2 编码阶段日期比较用了 String当天退房永远算错账现象入住日期存的是 java.util.Date退房日期也是 Date但比较两个日期是否重叠时有人把日期格式化成了 yyyy-MM-dd 的字符串再比较大小结果跨月的时候排序错乱比如 “2024-09-30” 和 “2024-10-02”字符串比较结果居然是 9 月大于 10 月。原因String 的字典序比较不是日期语义需要 DATETIME 或 DATE 类型才能正确比较。课程设计里很多人把日期在界面层转成字符串展示顺手把比较也做了属于“耦合了展示层与业务层”的典型问题。解决数据库日期字段统一用 DATE 类型Java 侧使用 LocalDate 进行日期运算SQL 里用参数直接传入 LocalDate 对象。界面显示时再格式化成字符串千万不要在业务判断链路里出现字符串日期。5.3 集成阶段Jar 包缺了 MySQL 驱动换电脑就白屏现象在自己电脑上跑得好好的课程设计拷到教室演示用的电脑上启动后直接报 java.lang.ClassNotFoundException: com.mysql.cj.jdbc.Driver或者能启动但点登录按钮后卡死。原因IDE 里能跑是因为依赖 jar 包配置在 IDE 的 classpath 里但导出的可运行 jar 没有把 MySQL 驱动打包进去。这是课设答辩现场最高频的事故。解决用 IDEA 的 Artifacts 配置时把 mysql-connector-j 的依赖范围设为 compile并且打包时选择 “JAR from modules with dependencies”或者干脆用 maven-assembly-plugin 打出 fat jar。答辩前换一台干净电脑实测一次启动过程这个动作能救回一半的演示分。5.4 文档阶段测试用例只写“正常登录成功”现象软件测试报告里写满了“输入正确用户名密码点击登录系统跳转到主界面测试通过”二十条用例全部是正常路径没有一条异常路径。原因很多同学把测试报告理解成“证明系统能用”而没有理解测试的目的是“证明系统处理了异常”。需求分析里写了多少异常路径测试用例就要对应多少条异常验证。解决每条正常用例补两条异常用例比如“用户名为空时提示”“密码错误三次锁定账号”“预订房间日期冲突时提示且不写入预订表”。这些用例直接基于需求分析里的异常流程抄一遍工作量不大但测试报告的“完整性”评分通常能上一个档次。5.5 答辩阶段被问“数据量大了怎么办”直接卡壳现象老师问“如果宾馆有 500 间房每天的预订记录有上千条你这个系统会不会慢”学生只会回答“不会吧”。原因课程设计通常不要求做性能优化但软件工程课程的老师很多会追问这个经典问题。这个问题的考点不是让你做分库分表而是让你说出“索引、分页、连接池”这三个概念。解决提前准备一段话房间列表按房间号建了唯一索引预订表按 checkin_date 建了索引列表查询统一做了分页数据库连接通过连接池复用。哪怕你没有真正实现连接池只要逻辑上能说清优化的方向这个追问就过关了。你这部分实现里其实已经把索引做了只是没意识到这能用来回答问题。5.6 演示阶段没有准备演示数据和演示脚本现象答辩现场打开系统房间列表是空的现敲数据又慢又容易录入格式错误全场沉默浪费时间。原因没有把演示当成一次“演出”只把系统当成代码交付物。解决数据库里提前造好一组真实感强的演示数据比如 10 个房型30 个房间20 条客人档案以及跨越过去 30 天和未来 7 天的预订记录。演示时先查一个未来日期有没有空房再走一遍“预订→入住→退房”的完整链路整个过程控制在 5 分钟以内。数据要造得像真酒店客人姓名、身份证号、电话号码要符合基本格式否则演示中途会被细节扣分。6. 让系统显得完整的最后一招报表统计与全局异常日志课程设计的评分差异很多时候不体现在核心业务上而是体现在边角功能的完整度上。两个系统都能预订和退房一个只有原始列表一个能按天统计入住率后者的“软件工程完成度”观感会高出一截。我建议在最后一个模块里加两张报表不用复杂用 SQL 聚合就能实现。第一张是近 30 天每日入住率SELECT DATE(checkin_time) AS day, COUNT(DISTINCT room_id) AS used_rooms, (SELECT COUNT(*) FROM room WHERE status ! 4) AS total_rooms FROM checkin_record WHERE checkin_time DATE_SUB(CURDATE(), INTERVAL 30 DAY) GROUP BY DATE(checkin_time) ORDER BY day;这张报表的逻辑是统计每天实际有入住的房间数除以可用房间总数。注意 COUNT(DISTINCT room_id) 而不是 COUNT(*)因为同一个房间在一天内可能被重复入住两次去重后才是真实的房间占用数。报表展示时再算一个百分比列经理角色的菜单里才能看到这个入口这就把“角色权限”和“统计报表”两个加分点串起来了。第二张报表是房型营收统计按 room_type 分组求和。两张报表足以撑起“经理角色”的完整度而绝大多数课设做到这一步就会展示出明显的分层价值。另一个容易被忽略的细节是全局异常日志。Swing 程序遇到未捕获异常默认行为是控制台打印堆栈但课程设计演示时不会有人盯着控制台看。我一般会在主类的 main 方法里加一个自定义的 UncaughtExceptionHandler把异常信息写入运行目录下的 error.log 文件。别小看这个文件它有两个作用演示时如果崩溃了你可以当场打开日志说“我来定位一下问题”代码审查时这也是“程序健壮性”的直观证据。课程设计做到这里业务、文档、答辩这三个维度都有料可讲。我最想提醒你的是不要追求把每个按钮的代码都写到最优这个系统只要把预订和入住这两条主链路的状态流转搞清楚把日期冲突和事务这两个边界处理好就已经超过大多数同学了。很多人在课设上翻车翻的不是技术是时间分配——前两周玩最后两天通宵结果文档写得像流水账代码里全是赶工痕迹。我自己的习惯是第一天先把用例图和状态机画完后面每天推进一个模块留出三天专门写测试和排错。希望帮到你。本文还有配套的精品资源点击获取
简介一套面向软件工程课程设计的酒店管理系统完整项目适合软件工程、数据库及管理信息系统课程的本科生作课程设计参考。项目模拟酒店实际运营流程划分系统用户、客房标准、客房信息、订房信息与结算信息五大核心模块覆盖权限分配、动态房价、实时房态、预订冲突检测及多种支付结算等典型业务场景。压缩包共195个文件约17.85MB以C源文件.h/.cpp、数据库.mdb及可执行程序.exe为主同时包含Visual C工程配置.dsp/.dsw和课程设计报告.doc/.docx等材料便于直接打开、编译与查阅。目前已有1228人学习下载。通过该资源读者可获得可运行的酒店管理系统源码、数据库表结构、界面图标与背景资源、课程设计报告及答辩PPT既能支撑课程设计答辩也可从中理解软件工程需求分析、模块划分、编码与测试流程。1. 课程设计不是写代码是“按流程造轮子”酒店管理系统到底在考察什么拿到“软件工程课程设计——酒店管理系统”这个题目最忌讳的一件事就是直接打开 IDE 开始建窗体。这门课设表面上是写一个能跑的管理后台实际上考的是你有没有走完软件工程的全流程需求分析、用例建模、数据库设计、分层实现、测试记录、文档答辩。酒店业务足够经典客房、预订、入住、退房、账单这些模块边界清楚又天然带有日期冲突和并发操作这类容易翻车的点用来考察需求分析和系统设计能力正合适。适合谁来照着做如果你正被课程设计卡住或者想用最短路径把整个流程跑完整这篇笔记就是给你准备的。2. 从用例图到数据表四个核心模块的设计顺序与状态机2.1 用例图与需求边界画清楚“谁在用、能做什么”软件工程课程设计的第一份交付物不是代码是用例图。酒店管理系统的用例图如果画得对后面建表、写接口、做界面几乎是被推着走的如果画错了后面每写一个功能都在打补丁。我一般把角色分成三类前台、经理、系统管理员。前台负责预订、入住、退房、换房、挂账和查询经理看报表和统计分析系统管理员维护用户和房间基础数据。这个划分不是拍脑袋它直接决定了权限模块的粒度——如果你把管理员和前台混成一个角色登录后的菜单就会乱掉。角色与核心用例的对应关系课程设计里通常按这张表来定角色核心用例验收标准前台预订、入住、退房、换房、查询能完成“预订→入住→退房→结算”的完整链路经理入住率报表、营收统计能按日期区间看到统计结果而不是只能看原始列表管理员用户管理、房间类型维护能增删改查用户和房型操作有权限校验用例图画完紧接着要做的事是给每个用例写一段用例描述包含前置条件、主流程、异常流程。比如“预订房间”的异常流程至少要有三种日期冲突、房间被锁定、游客身份证号已存在。这些内容到写测试用例时会原封不动地变成测试步骤所以这一步偷懒后面全部翻车。2.2 数据库设计五张主表和一条核心外键链酒店管理系统的表结构不需要很多常见的做法是六张表用户表、房间表、客人表、预订表、入住记录表和账单表。表之间有一条清晰的外键链客人→预订→入住记录→账单。多一张冗余表不如多一条清晰的外键关系这句话在课设评分里很重要。建表 SQL 我一般写成这样CREATE TABLE sys_user ( id INT PRIMARY KEY AUTO_INCREMENT, username VARCHAR(50) NOT NULL UNIQUE, password VARCHAR(64) NOT NULL, role TINYINT NOT NULL DEFAULT 2 COMMENT 1-管理员, 2-前台, 3-经理, real_name VARCHAR(50) ); CREATE TABLE room ( id INT PRIMARY KEY AUTO_INCREMENT, room_no VARCHAR(10) NOT NULL UNIQUE, room_type VARCHAR(20) NOT NULL, price DECIMAL(10,2) NOT NULL, status TINYINT NOT NULL DEFAULT 0 COMMENT 0-空闲, 1-已预订, 2-已入住, 3-脏房, 4-维修 ); CREATE TABLE guest ( id INT PRIMARY KEY AUTO_INCREMENT, id_card VARCHAR(18) NOT NULL UNIQUE, name VARCHAR(50) NOT NULL, phone VARCHAR(20) ); CREATE TABLE reservation ( id INT PRIMARY KEY AUTO_INCREMENT, guest_id INT NOT NULL, room_id INT NOT NULL, checkin_date DATE NOT NULL, checkout_date DATE NOT NULL, status TINYINT DEFAULT 1 COMMENT 1-生效, 2-已入住, 3-已取消, 4-已完成, FOREIGN KEY (guest_id) REFERENCES guest(id), FOREIGN KEY (room_id) REFERENCES room(id) ); CREATE TABLE checkin_record ( id INT PRIMARY KEY AUTO_INCREMENT, reservation_id INT, guest_id INT NOT NULL, room_id INT NOT NULL, checkin_time DATETIME NOT NULL, checkout_time DATETIME, total_amount DECIMAL(10,2), FOREIGN KEY (guest_id) REFERENCES guest(id), FOREIGN KEY (room_id) REFERENCES room(id) );几个配置上的讲究price 字段用 DECIMAL(10,2) 而不是 FLOAT因为浮点数算钱会有精度丢失退房结算时多一分少一分很尴尬status 字段用 TINYINT 存数字状态而不是直接存中文是为了后面加索引和做统计时写法干净每个表都带 UNIQUE 约束的字段username、room_no、id_card这是防止重复数据的最后一道防线。2.3 房间状态机从空闲到脏房的流转规则房间状态是酒店系统的核心状态机所有业务操作本质上都是在驱动房间状态迁移。当前状态触发动作下一状态空闲前台预订已预订已预订客人到店办理入住已入住已入住退房结算脏房脏房保洁打扫完成空闲任意状态管理员报修维修维修维修完成空闲这个状态机看起来简单但落地时经常有人漏掉“脏房”这一环。很多课设代码里房间状态只有空闲和入住两种退房之后直接置回空闲结果就是这个房间在保洁还没打扫的情况下又被订出去了。课程设计的老师可能不会实际去验证保洁流程但你在数据库里把状态流转做完整答辩时能讲的东西就多了一个维度。状态机的落点应该在数据库的唯一约束上。比如入住记录表按 room_id 和 checkout_time IS NULL 建一个唯一索引保证同一房间同时只有一条未退房记录这个后面并发章节会细说。3. 分层架构与代码落地Java Swing MySQL 的最小可跑通骨架3.1 为什么课程设计普遍选 Java Swing MySQL而不是 Spring Boot课程设计的评分重点从来不是技术栈有多新而是你有没有把软件工程的流程走完整。Spring Boot 固然是好东西但对于一个两周内的课设来说光环境配置和依赖管理就可能吃掉一半时间而且多数人写出来的 Spring Boot 项目只是个套壳 CRUD反而讲不清楚分层是怎么回事。常见的做法是 Java Swing 做界面层 JDBC 做数据访问层 MySQL 存数据。Swing 的好处是界面代码和业务逻辑在同一个工程里课堂答辩时可以直接从按钮事件一路追到 SQL 语句老师一眼就能看出你的分层思路。用 Python 做课设的同学也类似用 tkinter sqlite3 也能走出同样的分层只是 JDBC 换成驱动 API、MySQL 换成 sqlite3 模块而已。分层上我建议至少分成三层界面层只负责组件和事件监听、业务层负责状态判断和流程编排、数据层只做 SQL 的执行与结果映射。千万别在按钮事件里直接写 SQL那样答辩时你会被一句“你这里为什么出现两条一模一样的 JDBC 代码”问住。3.2 数据库连接单例别在每个方法里重写 DriverManager新手最容易犯的错是每一个方法里都写一遍 Class.forName 和 DriverManager.getConnection。这样做开发时没问题但程序一跑起来每个操作都新建连接、用完不关几天后数据库连接数就爆了。课程设计虽然不会真的被并发打爆但这个坏习惯在代码审查时属于明显减分项。我一般会用一个连接工具类把连接的创建和关闭收敛到一个地方public class DBUtil { private static final String URL jdbc:mysql://localhost:3306/hotel_db?useSSLfalseserverTimezoneAsia/Shanghai; private static final String USER root; private static final String PASSWORD 123456; static { try { Class.forName(com.mysql.cj.jdbc.Driver); } catch (ClassNotFoundException e) { e.printStackTrace(); } } public static Connection getConnection() throws SQLException { return DriverManager.getConnection(URL, USER, PASSWORD); } public static void close(Connection conn, Statement stmt, ResultSet rs) { if (rs ! null) { try { rs.close(); } catch (SQLException ignored) {} } if (stmt ! null) { try { stmt.close(); } catch (SQLException ignored) {} } if (conn ! null) { try { conn.close(); } catch (SQLException ignored) {} } } }这段代码有三个关键点。定义里 URL 带了 useSSLfalse 和 serverTimezone 参数前者避免本地 MySQL 的 SSL 握手警告后者解决 JDBC 8.x 与 MySQL 时区不一致导致的报错静态代码块里加载驱动类保证驱动只加载一次close 方法对三个资源分别判空关闭避免哪里忘了关连接导致数据库连接耗尽。你看这个工具类虽然简单但每一行都有存在的理由答辩时能讲出这些参数的含义远比背概念得分高。3.3 登录与权限控制prepareStatement 为什么必须替代字符串拼接登录功能是所有课程设计里第一个写的功能也是最容易被问出问题的功能。很多人的第一版写法是用字符串拼接 SQL这属于典型的血泪教训。// 错误示范这种方式会被 SQL 注入击穿 String sql SELECT * FROM sys_user WHERE username username AND password password ;输入框里输入admin OR 11密码随便填这条 SQL 就变成了恒真查询账号直接绕过。课程设计不能只跑通还要经得起追问。用 PreparedStatement 替代字符串拼接是最基础的防线public User login(String username, String password) { String sql SELECT * FROM sys_user WHERE username ? AND password ?; try (Connection conn DBUtil.getConnection(); PreparedStatement ps conn.prepareStatement(sql)) { ps.setString(1, username); ps.setString(2, md5(password)); try (ResultSet rs ps.executeQuery()) { if (rs.next()) { User user new User(); user.setId(rs.getInt(id)); user.setUsername(rs.getString(username)); user.setRole(rs.getInt(role)); user.setRealName(rs.getString(real_name)); return user; } } } catch (SQLException e) { e.printStackTrace(); } return null; }两个细节值得注意参数通过 setString 注入SQL 语句本身提前编译输入值只作为参数参与比较注入语句就失去了语义密码这一栏我在代码里写了 md5(password) 的调用这是示意你要对密码做哈希而不是明文存储但 MD5 在现代场景下不够安全如果时间允许换成 BCrypt 会更稳妥答辩时主动说出这一点反而加分。登录成功后的 User 对象里存了 role 字段进入主界面后根据角色值决定菜单可见性这就是前面用例图里角色划分的落地。真正卡住人的其实不是登录本身而是你拿到 user 对象之后没有做权限判断导致权限形同虚设。4. 并发预订与日期冲突酒店系统最容易翻车的三个业务边界4.1 日期冲突检测一条 SQL 拦住同房间同一天被订两次酒店系统的所有业务逻辑里最容易挂的就是日期冲突检测。用一个简单的条件判断“待订入住日 已有预订退房日”是不够的因为存在完全包含、部分重叠、前后相接三种情况。判断两个时间段重叠的标准条件是已有预订的入住日 新预订的退房日 并且 已有预订的退房日 新预订的入住日。SQL 里写成这样SELECT COUNT(*) FROM reservation WHERE room_id ? AND status IN (1, 2) AND checkin_date ? AND checkout_date ?这里的两个参数分别是新预订的退房日和入住日。查询结果大于 0说明该房间在这个时间段内存在生效中的预订或入住浏览器端要弹冲突提示。这个条件能同时覆盖“新入住日在已有预订期间内”和“已有预订期间在新入住区间内”两种情况写一次就够。边界情况也要想清楚退房日当天中午 12 点是默认的结算时间所以如果你预订 5 月 1 日入住、5 月 3 日退房那么 5 月 3 日当天房间应该可以被下一个客人预订。上面 SQL 里用的是严格小于和严格大于天然允许了退房日当天被重新预订这一步处理对很多新手来说是个隐藏坑。4.2 房间状态的双写问题数据库状态才是唯一真源很多课设做房间列表时会在界面层用一个集合对象缓存所有房间的状态然后在前台界面上实时修改这个集合觉得这样“界面刷新快”。这属于把简单问题复杂化而且会引入一个非常隐蔽的 bug页面上的状态和数据库里的状态不一致重启程序后明明数据库显示房间空闲界面上还挂着已入住。正确做法是数据库里的 status 字段是唯一真源界面只负责展示查询结果不承担状态存储职责。每次状态变更都通过 SQL 更新数据库再重新查询一次刷新列表代价很小但一致性永远有保证。状态更新时记得用状态值做条件过滤这是第二种冲突形态。比如执行入住操作时SQL 应该写成UPDATE room SET status 2 WHERE id ? AND status 1;注意这里带上了 AND status 1意思是只有房间当前处于“已预订”状态才允许入住。如果 UPDATE 影响行数为 0说明房间状态已经被别人改过了业务层就应该抛出异常提示。这种方式叫乐观锁的简单形态虽然课设没有高并发环境但这个写法和“直接 SET status 2”有本质区别。4.3 事务与锁退房结算中途崩溃怎么保证账单和房间状态一致退房流程要同时干两件事写入账单记录、把房间状态改成脏房。如果第一步成功而第二步失败就会出现客人已经走了但房间还是已入住状态的脏数据。代码上必须把这两个操作放进同一个事务里Connection conn null; try { conn DBUtil.getConnection(); conn.setAutoCommit(false); // 插入账单记录金额来自入住时锁定的房价 PreparedStatement ps1 conn.prepareStatement( INSERT INTO checkin_record (guest_id, room_id, checkin_time, checkout_time, total_amount) VALUES (?, ?, ?, NOW(), ?)); ps1.setInt(1, guestId); ps1.setInt(2, roomId); ps1.setBigDecimal(3, amount); ps1.executeUpdate(); // 房间状态改为脏房 PreparedStatement ps2 conn.prepareStatement( UPDATE room SET status 3 WHERE id ?); ps2.setInt(1, roomId); ps2.executeUpdate(); conn.commit(); } catch (SQLException e) { if (conn ! null) { try { conn.rollback(); } catch (SQLException ignored) {} } e.printStackTrace(); } finally { if (conn ! null) { try { conn.setAutoCommit(true); conn.close(); } catch (SQLException ignored) {} } }关键点是 setAutoCommit(false) 之后的 commit 和 rollback 必须成对出现。这里有个容易忽略的细节finally 里要把 autoCommit 恢复成 true 再关闭连接因为连接池复用时不会帮你重置这个属性下次从池里拿出来的连接可能还带着上次的事务设置。课程设计虽然用不到连接池但你把这个细节写进代码注释里答辩时解释清楚属于典型的“超出预期的加分点”。事务里还要想一件事入住时锁定的到底是哪个房价课程设计里通常简单处理成 room 表里的当前价格但真实酒店的价格会随房型、日期和会员等级浮动。如果你在入住记录表里冗余存了当时的价格字段total_amount后面房价调整就不会影响历史账单这个设计思路值得在答辩时主动讲出来。5. 课程设计常见问题与避坑从重复预订到答辩被问崩的六个教训5.1 需求阶段别把“房间管理”做成“房间增删改查”现象很多人的需求分析里写“房间管理模块实现房间的增删改查”然后就照着这个去写代码最后系统能跑但老师一问“你的系统怎么处理换房需求”直接愣住。原因需求分析只停留在数据层的 CRUD 思维没有从业务角度抽象功能。酒店业务的真实需求是客人住到一半想换房系统要同时处理原房间的退订和恢复空闲、新房间的状态变更、可能存在的差价结算。解决做需求分析时每一个用例要问三个问题前置条件是什么、触发后有哪些数据要变、失败时怎么回滚。把这三个问题写成文字放在需求规格说明里就算代码实现得粗糙需求分析部分也是及格的。5.2 编码阶段日期比较用了 String当天退房永远算错账现象入住日期存的是 java.util.Date退房日期也是 Date但比较两个日期是否重叠时有人把日期格式化成了 yyyy-MM-dd 的字符串再比较大小结果跨月的时候排序错乱比如 “2024-09-30” 和 “2024-10-02”字符串比较结果居然是 9 月大于 10 月。原因String 的字典序比较不是日期语义需要 DATETIME 或 DATE 类型才能正确比较。课程设计里很多人把日期在界面层转成字符串展示顺手把比较也做了属于“耦合了展示层与业务层”的典型问题。解决数据库日期字段统一用 DATE 类型Java 侧使用 LocalDate 进行日期运算SQL 里用参数直接传入 LocalDate 对象。界面显示时再格式化成字符串千万不要在业务判断链路里出现字符串日期。5.3 集成阶段Jar 包缺了 MySQL 驱动换电脑就白屏现象在自己电脑上跑得好好的课程设计拷到教室演示用的电脑上启动后直接报 java.lang.ClassNotFoundException: com.mysql.cj.jdbc.Driver或者能启动但点登录按钮后卡死。原因IDE 里能跑是因为依赖 jar 包配置在 IDE 的 classpath 里但导出的可运行 jar 没有把 MySQL 驱动打包进去。这是课设答辩现场最高频的事故。解决用 IDEA 的 Artifacts 配置时把 mysql-connector-j 的依赖范围设为 compile并且打包时选择 “JAR from modules with dependencies”或者干脆用 maven-assembly-plugin 打出 fat jar。答辩前换一台干净电脑实测一次启动过程这个动作能救回一半的演示分。5.4 文档阶段测试用例只写“正常登录成功”现象软件测试报告里写满了“输入正确用户名密码点击登录系统跳转到主界面测试通过”二十条用例全部是正常路径没有一条异常路径。原因很多同学把测试报告理解成“证明系统能用”而没有理解测试的目的是“证明系统处理了异常”。需求分析里写了多少异常路径测试用例就要对应多少条异常验证。解决每条正常用例补两条异常用例比如“用户名为空时提示”“密码错误三次锁定账号”“预订房间日期冲突时提示且不写入预订表”。这些用例直接基于需求分析里的异常流程抄一遍工作量不大但测试报告的“完整性”评分通常能上一个档次。5.5 答辩阶段被问“数据量大了怎么办”直接卡壳现象老师问“如果宾馆有 500 间房每天的预订记录有上千条你这个系统会不会慢”学生只会回答“不会吧”。原因课程设计通常不要求做性能优化但软件工程课程的老师很多会追问这个经典问题。这个问题的考点不是让你做分库分表而是让你说出“索引、分页、连接池”这三个概念。解决提前准备一段话房间列表按房间号建了唯一索引预订表按 checkin_date 建了索引列表查询统一做了分页数据库连接通过连接池复用。哪怕你没有真正实现连接池只要逻辑上能说清优化的方向这个追问就过关了。你这部分实现里其实已经把索引做了只是没意识到这能用来回答问题。5.6 演示阶段没有准备演示数据和演示脚本现象答辩现场打开系统房间列表是空的现敲数据又慢又容易录入格式错误全场沉默浪费时间。原因没有把演示当成一次“演出”只把系统当成代码交付物。解决数据库里提前造好一组真实感强的演示数据比如 10 个房型30 个房间20 条客人档案以及跨越过去 30 天和未来 7 天的预订记录。演示时先查一个未来日期有没有空房再走一遍“预订→入住→退房”的完整链路整个过程控制在 5 分钟以内。数据要造得像真酒店客人姓名、身份证号、电话号码要符合基本格式否则演示中途会被细节扣分。6. 让系统显得完整的最后一招报表统计与全局异常日志课程设计的评分差异很多时候不体现在核心业务上而是体现在边角功能的完整度上。两个系统都能预订和退房一个只有原始列表一个能按天统计入住率后者的“软件工程完成度”观感会高出一截。我建议在最后一个模块里加两张报表不用复杂用 SQL 聚合就能实现。第一张是近 30 天每日入住率SELECT DATE(checkin_time) AS day, COUNT(DISTINCT room_id) AS used_rooms, (SELECT COUNT(*) FROM room WHERE status ! 4) AS total_rooms FROM checkin_record WHERE checkin_time DATE_SUB(CURDATE(), INTERVAL 30 DAY) GROUP BY DATE(checkin_time) ORDER BY day;这张报表的逻辑是统计每天实际有入住的房间数除以可用房间总数。注意 COUNT(DISTINCT room_id) 而不是 COUNT(*)因为同一个房间在一天内可能被重复入住两次去重后才是真实的房间占用数。报表展示时再算一个百分比列经理角色的菜单里才能看到这个入口这就把“角色权限”和“统计报表”两个加分点串起来了。第二张报表是房型营收统计按 room_type 分组求和。两张报表足以撑起“经理角色”的完整度而绝大多数课设做到这一步就会展示出明显的分层价值。另一个容易被忽略的细节是全局异常日志。Swing 程序遇到未捕获异常默认行为是控制台打印堆栈但课程设计演示时不会有人盯着控制台看。我一般会在主类的 main 方法里加一个自定义的 UncaughtExceptionHandler把异常信息写入运行目录下的 error.log 文件。别小看这个文件它有两个作用演示时如果崩溃了你可以当场打开日志说“我来定位一下问题”代码审查时这也是“程序健壮性”的直观证据。课程设计做到这里业务、文档、答辩这三个维度都有料可讲。我最想提醒你的是不要追求把每个按钮的代码都写到最优这个系统只要把预订和入住这两条主链路的状态流转搞清楚把日期冲突和事务这两个边界处理好就已经超过大多数同学了。很多人在课设上翻车翻的不是技术是时间分配——前两周玩最后两天通宵结果文档写得像流水账代码里全是赶工痕迹。我自己的习惯是第一天先把用例图和状态机画完后面每天推进一个模块留出三天专门写测试和排错。希望帮到你。本文还有配套的精品资源点击获取
)
