1 绪论
1.1 研究背景
当前高校扩招与教学改革并行，教室资源供需矛盾日益凸显。传统管理模式多依赖人工登记或简单的Excel表格，信息更新滞后，导致学生经常白跑一趟发现教室被占，或者明明有空闲却因信息不透明而闲置。尤其在考研季和期末周，占座现象频发，引发学生间矛盾，管理员疲于奔命却难以实时掌握各教室动态1。此外，教室设备故障报修流程繁琐，往往需要层层签字或电话沟通，维修进度不透明，小问题拖成大故障，直接影响教学秩序2。在移动互联网普及的今天，师生习惯了指尖办事，这种低效的线下流程不仅浪费人力物力，更拉低了学校的管理形象和服务温度3。面对智慧校园建设的浪潮，利用成熟的技术手段重构管理流程，打破信息孤岛，让数据多跑路、师生少跑腿，已成为提升高校治理能力的迫切需求，这不仅是技术升级，更是管理理念的务实转变。
1.2 研究意义
系统的开发意义在于用低成本技术方案解决高频痛点，切实提升校园生活服务品质。通过构建统一的数字化平台，将教室查询、预约、报修及资讯互动整合至一端，实现了资源状态的实时同步与透明化，从根源上杜绝了虚假占座和信息不对称问题。对于学生而言，随时随地可查可用，规划学习路径更加从容；对于管理者，系统自动统计使用率与故障数据，为资源调配和设备维护提供量化依据，变被动响应为主动治理。更重要的是，系统内置的互动与反馈机制搭建了平等的沟通桥梁，让师生的声音能被及时听见和处理，增强了归属感。这种模式无需昂贵硬件投入，基于开源框架即可快速落地，具有极高的推广价值。它不仅是管理工具的更新，更是推动高校后勤服务向精细化、人性化转型的关键一步，为构建高效和谐的育人环境提供了坚实支撑。
1.3 国内外研究现状
1.3.1 国内研究现状
近年来，随着高校扩招和教育信息化2.0行动的深入，国内关于教室资源管理的研究已从单纯的"数字化记录"转向"智能化服务"。早期系统多基于JSP或ASP.NET开发，功能局限于课表查询和简单的静态预约，如同许多高校曾使用的老旧教务系统，往往只能显示固定课程安排，无法处理临时借用和社团活动需求，导致"线上约了线下不能用"的尴尬局面频发4。当前，基于SpringBoot和Vue的前后端分离架构已成为主流选择，因其开发效率高、维护成本低且生态成熟。大量毕业设计和本校自研项目开始涌现，例如部分高校尝试引入二维码签到机制，学生到达教室后扫码确认，超时未签到自动释放资源，有效缓解了"占座不来"的顽疾5。
然而，现有系统仍存在明显短板：一是数据孤岛现象严重，教室预约系统与教务排课、资产报修系统往往互不相通，管理员需在多个后台切换；二是算法简陋，缺乏对历史使用数据的深度挖掘，无法在考研季等高峰期进行智能分流推荐；三是移动端体验不佳，许多系统仅做了简单的网页适配，未真正融入师生高频使用的微信小程序或企业微信生态，操作繁琐6。此外，针对教室设备故障的闭环管理研究较少，多数仍停留在"填单等待"阶段，缺乏维修进度的实时透明化反馈，导致师生满意度不高7。总体而言，国内研究正处在从"有无"向"好坏"过渡的关键期，亟需构建集预约、监控、互动、分析于一体的综合性平台。
1.3.2 国外研究现状
欧美及发达国家的高校在空间资源管理方面起步较早，已形成较为成熟的商业化与定制化并存的生态体系。以美国为例，许多顶尖大学如斯坦福、麻省理工等，早已将教室管理纳入统一的智慧校园中枢（Smart Campus Hub），不仅实现了跨校区的资源可视化，还深度集成了物联网（IoT）技术。通过部署红外传感器和智能电表，系统能实时感知教室内的人数、温度、光照甚至空气质量，自动调节空调照明以实现节能，这种"环境感知型"管理在国内尚处于试点阶段8。在技术架构上，国外更倾向于微服务架构与云原生部署，利用Docker和Kubernetes确保系统在高并发下的弹性伸缩，特别是在选课周或考试周等流量洪峰期间表现稳定9。
应用层面，国外系统非常注重用户体验与隐私保护的平衡，普遍采用单点登录（SSO）集成Google Workspace或Microsoft 365生态，学生可直接通过日历应用查看空闲教室并一键预约，流程极其丝滑10。同时，其数据分析能力较强，能生成详细的空间利用率热力图，为学校扩建或改造提供量化依据。不过，国外系统也存在"水土不服"的问题，其高昂的授权费用和维护成本让许多非营利性教育机构望而却步，且其设计逻辑多基于西方宽松的学分制和走读制，对中国高校高强度的集体授课和晚自习文化适配性不足。近年来，开源社区如GitHub上也出现了不少基于Node.js或Python的轻量级预约项目，强调灵活定制，但整体生态碎片化，缺乏统一标准，难以直接大规模推广。
1.3.3 国内外研究小结
总结来看，国内外智慧社区建设均已取得显著成效，但侧重点各异。国内优势在于应用场景丰富、移动支付普及度高且更贴近居民日常生活需求，但在系统兼容性与适老化设计上仍有提升空间；国外则在流程自动化、财务合规性及IoT深度集成方面领先，且高度重视隐私保护，但成本较高且本土化适应性较弱。未来的发展趋势将是取长补短，既保留国内便捷的交互体验与丰富的生活服务生态，又借鉴国外严谨的数据治理与智能化运维理念，构建低成本、高可靠且真正惠及大众的智慧社区管理平台。
2 相关技术介绍
2.1 Java语言
Java是一种广泛应用于企业级软件开发的面向对象编程语言，具有平台无关性、安全性高、稳定性强等优点11。通过JVM（Java虚拟机）机制，Java实现了"一次编写，到处运行"的特性，极大地提升了代码的可移植性和复用性，其丰富的类库支持和成熟的生态系统，使得Java在Web应用、分布式系统及大型后台服务开发中占据主导地位12。在本系统中，Java作为主要开发语言，能够实现高效的服务器端逻辑处理和数据管理，为系统的功能实现提供了坚实的基础，同时Java的多线程和网络编程能力有助于系统的高并发处理，为多个用户提供服务。
2.2 SpringBoot框架
SpringBoot是一个开源框架，可以快速构建基于Spring的应用程序，通过简化配置和提供开箱即用的特性，极大地提升了开发效率。SpringBoot框架安排了一系列默认的配置，支持开展自动化配置，减少了应用启动的复杂性，并集成嵌入式Web服务器，让开发者可以不依赖外部独立运行Java应用，无需借助外部容器13。SpringBoot框架的应用为教室智能预约系统的后端开发提供了强大的支持。开发者使用SpringBoot框架可以轻松创建RESTful风格的API，与前端进行数据交互，支持各种业务操作14。数据访问层使用Spring Data JPA简单集成数据库，与MySQL进行操作，实现数据的持久化。安全管理方面利用Spring Security提供用户身份验证和授权功能，确保数据访问的安全性。
2.3 MySQL数据库
MySQL是一款流行的开源关系型数据库管理系统，因其性能稳定、易于使用、社区活跃而被广泛应用于各类Web应用系统中，支持标准SQL语句，即以结构化查询语言为基础，通过表格的形式存储数据，具备良好的事务处理能力和多用户并发访问能力。同时MySQL占用资源较少，适合中小型项目的数据库需求15。本系统采用MySQL作为核心数据存储工具，负责管理系统中的用户信息、业务数据和操作日志等关键信息，通过合理的数据库设计和优化，保障数据的安全性和一致性，并且MySQL支持对多用户的高并发操作，能够快速处理系统中的各种数据查询需求，为后端提供所需的数据服务16。
2.4 Vue框架
Vue 是一款轻量级、渐进式的前端JavaScript框架，专注于构建用户界面，具有学习成本低、开发效率高、组件化设计良好等特点，能够快速实现响应式数据绑定和动态页面交互17。Vue支持模块化开发，并与现代前端构建工具，如Webpack、Vite，兼容良好，适用于开发高性能、易维护的单页面应用（SPA）。在教室智能预约系统中，Vue框架被用于实现系统的前端界面，提供友好的交互体验，提升系统的交互体验与开发效率18。
2.5 B/S模式
B/S（Browser/Server）架构是一种基于浏览器的三层体系结构，用户通过浏览器即可访问服务器端的应用程序和数据资源，无需安装额外客户端，具有部署简单、维护方便、跨平台兼容性强等优势19。B/S架构降低了用户的客户端配置要求，用户只需要使用浏览器即可访问应用。该架构下，业务逻辑主要集中在服务器端处理，前端仅负责展示与交互，有利于提升系统的可扩展性和安全性。本系统基于B/S架构进行设计与开发，使得系统能够在不同设备和操作系统上便捷访问，增强系统的可用性与灵活性20。
3 系统分析
3.1 可行性分析
3.1.1 技术可行性
系统采用当前主流的B/S架构设计，后端基于Spring Boot框架结合Java语言进行开发，前端使用Vue.js实现界面交互，数据库选用MySQL进行数据存储与管理。系统所选用的技术成熟稳定、社区支持广泛，且具备良好的可扩展性和安全性，能够满足系统的高可用性需求。同时系统采用前后端分离的设计模式有利于后期维护与扩展。因此，在现有技术条件下，系统的开发与部署是完全可行的。
3.1.2 经济可行性
从经济投入角度来看，系统主要依赖于开源技术和通用服务器资源，所选择的Java、SpringBoot及MySQL等均为免费开源技术，开发成本相对较低。同时，该系统上线后将有效提升事务管理的效率，减少人工操作和重复劳动，从而降低长期运营成本。另外在吸引和留存大量用户后，系统可借助广告或其他增值服务实现有效创收，以此来支撑系统后期维护和运营升级，所以系统具备一定的投资回报率和良好的经济可持续性。
3.1.3 操作可行性
系统具备较强的易用性和实用性，系统面向不同角色用户设计了简洁直观的操作界面，功能模块划分清晰，易于用户理解和上手操作使用。系统为用户提供了必要的操作提示和帮助文档，以降低操作学习门槛，便于用户快速完成操作。系统后台管理界面也具备良好的可视化配置功能，便于管理人员进行日常维护和数据监控。
3.2 功能需求分析
根据用户在系统中的操作权限以及功能需求的不同，系统在设计过程中，将用户角色划分为两大主要类别，分别为学生/教师用户以及系统管理员。这两种角色在系统中分别对应不同的功能模块，并拥有相应的操作权限，以实现对教室资源预约、报修维护及信息反馈等业务流程的合理分配与管理。针对每种角色的具体功能职责，其详细的功能模块划分如下所述。
3.2.1 用户功能分析
(1) 注册登录：提供用户前台注册与登录功能。用户需输入学号/工号、密码及验证码进行身份验证。系统支持区分学生与教师角色，确保不同身份用户进入系统后拥有对应的权限视图。登录成功后可访问首页及个人中心，保障账户安全。
(2) 首页：作为系统的入口页面，提供全局信息概览与导航。主要展示轮播图（用于宣传重要活动或通知）、网站公告列表、校园资讯推荐等。用户可通过顶部导航栏快速跳转至教室查询、个人中心等核心模块，快速获取校园动态。
(3) 网站公告：集中展示教务处或管理部门发布的最新公告信息，如教室借用政策调整、考试安排通知、系统维护公告等。支持按发布时间倒序排列，方便用户及时查阅重要通知。
(4) 校园资讯：提供与校园生活、学术活动相关的新闻资讯板块。用户可浏览新闻详情，支持对感兴趣的资讯进行点赞、收藏及发表评论，促进校园信息的交流与互动。
(5) 教室信息：核心业务模块，提供教室资源的查询与预约功能。
教室查询：用户可按教室类型（如普通教室、多媒体教室、实验室）、楼层或名称进行搜索，查看教室的详细属性（容量、设备情况、位置）。
教室预约：用户选择空闲时段提交预约申请，填写预约用途、人数等信息。提交后生成预约单，状态初始化为"待审核"，等待管理员审批。
互动功能：用户可对教室进行收藏以便下次快速查找，也可对教室环境或使用体验进行点赞和评论。
(6) 个人中心：为用户提供的统一管理入口，包含以下子模块：
个人首页：展示用户基本资料（姓名、学号/工号、所属学院/年级）、头像及账号状态。
预约记录：列表展示用户所有的历史预约信息，包括预约时间、教室、用途及审核状态（待审核、已通过、已拒绝）。用户可在此查看审批结果及管理员回复。
报修申请：当用户在使用教室过程中发现设备故障或环境问题时，可在线提交报修申请。需填写故障描述、上传现场图片，提交后状态为"待审核"，并可实时追踪维修进度及处理结果。
意见反馈：提供用户对系统功能、管理服务等提出建议或投诉的渠道。用户可提交反馈内容，并查看管理员的回复及处理状态。
收藏记录：集中管理用户收藏的教室信息，支持快速取消收藏或再次发起预约。
点赞记录：展示用户点赞过的资讯文章或教室记录，方便回溯感兴趣的内容。
评论管理：用户可查看自己发布的所有评论（针对资讯或教室），支持对不当评论进行删除操作，维护良好的互动环境。
3.2.2 管理员功能分析
(1) 数据分析：后台首页提供可视化的数据驾驶舱，辅助管理者决策。
(2) 角色管理：实现基于RBAC（基于角色的访问控制）的权限管理体系。管理员可创建、编辑或删除系统内的角色（管理员、学生用户、教师用户），并为不同角色分配具体的菜单权限和操作按钮权限，确保系统安全。
(3) 教室信息管理：对全校教室资源进行统一维护。支持添加新教室，编辑教室详细信息（编号、名称、类型、位置、容量、设备清单、照片、使用说明），以及下架废弃教室。支持按学院或楼栋进行批量管理。
(4) 预约信息管理：处理用户提交的教室预约申请。管理员可查看预约详情（申请人、时间、用途），执行"审核通过"或"审核拒绝"操作，并可填写审核意见（如拒绝原因）。审核通过后，系统自动锁定该时段教室资源。
(5) 报修记录管理：处理用户提交的教室报修申请。管理员可查看报修详情及现场图片，指派维修人员或自行处理。处理完成后，更新报修状态为"已完成"并填写处理结果，系统将通知用户查看。
(6) 意见反馈管理：查看用户提交的各类意见反馈。管理员需对每条反馈进行回复，说明处理方案或解释政策，并将状态标记为"已处理"，形成闭环管理。
(7) 数据字典：管理系统的基础配置数据，确保数据的一致性与规范性。
学院信息管理：维护学校各学院名称及代码。
年级信息管理：维护在校年级数据。
教室类型管理：定义教室分类（如阶梯教室、研讨室等）。
预约时段管理：配置每日的可预约时间段及开放规则。
(8) 系统管理：
轮播图管理：上传、替换或删除首页轮播图片，设置跳转链接，用于宣传重点内容。
网站公告管理：发布、编辑或删除网站公告，支持富文本编辑，设定公告生效时间。
新闻管理：发布校园资讯新闻，支持分类管理、置顶及删除操作。
通知发布：向特定用户群体或全体用户发送系统内通知消息。
3.3 非功能性需求
系统的开发与设计过程中，除了满足基本的功能性需求外，还需要从多个维度考虑系统的非功能性要求，以保证系统的整体质量和用户体验。下面将从可靠性、可用性、性能、安全性等方面进行详细分析。
可靠性：系统应具备较高的稳定性和容错能力，在面对高并发访问或异常操作时能够保持正常运行。通过合理的异常处理机制和日志记录功能，确保系统在发生错误时可以快速定位问题并恢复服务，从而保障用户操作的连续性和数据的一致性。
可用性：系统界面应设计简洁、直观，操作流程清晰，便于不同层次的用户理解和使用。对于不同角色用户，应提供相应的引导提示和帮助信息以提升用户的操作效率和满意度。
性能需求：系统需支持多用户并发访问，并能在合理的时间内响应用户的请求。在典型负载条件下，页面加载时间应控制在合理范围内，关键业务操作的响应延迟不宜过高。
安全性：系统需具备完善的身份认证和权限控制机制，防止未经授权的访问和敏感信息泄露，并应对用户密码进行加密存储，对关键操作进行审计日志记录，确保系统具备一定的抗攻击能力和数据保护能力。
3.4.1 用户用例分析
3.4.1 用户用例分析
学生/教师用户主要拥有注册登录、首页、网站公告、校园资讯、教室信息（查询与预约）、个人中心（含预约记录、报修申请、意见反馈、收藏记录、点赞记录、评论管理）等功能。用户经身份验证登录后，可浏览校园动态与公告，检索并预约空闲教室，对教室或资讯进行点赞、收藏及评论互动；在使用过程中若发现设施故障可在线提交报修申请，并对系统服务提出意见反馈；同时可在个人中心统一管理个人的预约审批状态、报修进度及互动历史数据，用例图如图3-1所示。
图3-1 用户用例图
3.4.2 管理员用例分析
管理员主要包含登录、数据分析、角色管理、教室信息管理、预约信息管理、报修记录管理、意见反馈管理、数据字典（学院、年级、教室类型、时段管理）、系统管理（轮播图、公告、新闻、通知发布）等功能。管理员负责维护系统基础数据与角色权限，审核用户的教室预约申请与报修请求，处理用户意见反馈并发布各类校园资讯与公告；同时通过后台首页的数据可视化图表，统计教室类型分布、报修频次及反馈数据，以辅助教学资源的管理与决策，用例图如图3-2所示。
图3-2管理员用例图
3.5 系统流程分析
3.5.1 用户注册登录流程
学生/教师输入学号/工号及密码进行登录，注册时需填写姓名、学院等基本信息。注册后状态默认为"待审核"，需管理员核对通过后激活。后端校验凭证生成Token返回，客户端携带令牌鉴权，系统根据角色（学生、教师、管理员）动态加载对应菜单。用户注册登录流程如图3-3所示。
图3-3用户注册登录流程图
3.5.2 教室预约与审批流程
用户在端选择空闲教室与时段，填写用途提交预约申请，生成"待审核"订单。后端校验时间冲突后入库。管理员后台查看申请详情，执行"通过"或"拒绝"操作并填写意见。若通过，系统锁定该时段资源并通知用户；若拒绝，释放资源。用户可在个人中心实时查看审批进度与结果。教室预约与审批流程如图3-4所示。
图3-4教室预约与审批流程图
3.5.3 教室报修申请与处理流程
用户在使用教室时发现故障，在线填写报修类型、描述并上传现场照片提交。后端校验信息完整性后生成待处理工单。管理员后台查看工单，指派维修或自行处理，更新状态为"维修中"。处理完毕后录入结果，状态更为"已完成"。用户登录后查看反馈并对维修服务进行评价，系统归档记录。报修申请与处理流程如图3-5所示。
图3-5教室报修申请与处理流程图
3.5.4 资讯发布与互动流程
管理员在后台编辑校园资讯或公告，设置标题、内容及轮播图后发布，前端首页即时展示。用户浏览列表点击查看详情，可进行点赞、收藏或发表评论。后端实时统计互动数据并更新显示。若评论违规，管理员可在后台删除该评论并封禁用户发言权限。用户可在个人中心统一管理自己的点赞、收藏及评论记录。资讯发布与互动流程如图3-6所示。
图3-6资讯发布与互动流程图
3.5.5 意见反馈与处理流程
用户通过"意见反馈"模块提交对系统或管理的建议与投诉，填写详细内容后提交。后端生成待处理反馈单。管理员后台查看反馈详情，进行分析并回复处理意见，将状态标记为"已处理"。系统自动通知用户查看回复。用户可在个人中心查看历史反馈及管理员的答复内容，形成闭环管理，若不满意可再次补充反馈。意见反馈与处理流程如图3-7所示。
图3-7意见反馈与处理流程图
4 系统设计
4.1 系统架构设计
系统整体采用前后端分离的分布式架构模式，严格遵循高内聚、低耦合的设计原则。学生端与管理端均基于Web技术栈构建，其中学生端采用Vue.js框架开发单页应用（SPA），完美适配PC与移动端浏览器，作为师生核心交互载体，负责教室实时查询、在线预约申请、故障报修提交及资讯互动等高频业务场景。管理端同样基于Vue.js框架构建Web单页应用，专注于预约审批调度、资源冲突处理、报修工单流转及数据统计分析。后端统一采用Java语言与Spring Boot框架，集中处理核心业务逻辑、RBAC角色权限控制、数据持久化及消息通知服务集成，通过RESTful API实现前后端高效数据交互，数据库选用MySQL存储业务数据，Redis缓存教室状态等热点信息以提升系统响应速度。系统架构如图4-1所示。
图4-1 系统架构图
4.2 功能模块设计
系统基于角色权限划分为学生和管理员两类核心用户。核心功能模块设计了学生端的教室空闲实时查询、分时段在线预约申请、预约记录管理、教学设备故障一键报修、维修进度追踪及个人信息维护；后台管理端则涵盖教室资源基础配置、预约申请流程审批、冲突智能检测、报修工单指派与结果录入、教室使用率统计报表生成、系统用户管理与角色权限配置及校园通知发布等。各模块逻辑清晰，既满足了师生便捷获取资源的需求，又实现了管理员对教学资源的高效调度与精细化运维。系统总体功能结构图如图4-2所示。
图4-2 系统功能结构图
4.3 数据库设计
4.3.1 概念结构设计
1.1.1 概念结构设计
根据系统需求分析，确定学生、教师、管理员、教室信息、预约记录、报修记录、意见反馈及数据字典等核心实体。其中，学生与教师实体均与预约记录、报修记录及意见反馈存在一对多发起关联；管理员实体负责审核预约与报修单、处理反馈及维护教室基础数据，与这些业务实体形成一对多的管理关联；教室信息实体作为资源核心，被多条预约及报修记录所引用；预约记录实体包含时段、用途及审核状态等属性；报修记录实体关联故障描述与维修进度。系统的总体E-R图如图4-3所示。
图4-3 系统总体ER图
4.3.2 物理结构设计
依据前一节对教室智能预约系统的整体E-R关系图的分析，为了满足系统功能需求，需要创建多个数据表。下面将着重介绍几个核心数据库表的设计结构，详细阐述这些关键数据库表的设计细节，包括但不限于字段定义、数据类型及其相互间的关系，从而为系统的稳定运行提供坚实的基础。由于系统涉及的功能模块较多，数据表数量较为庞大，为便于说明，下面仅选取其中若干核心业务表进行结构展示与字段说明，以体现数据库设计的关键细节与实现思路。
学生用户表用于存储注册学生的详细档案信息，涵盖学号、姓名、所属学院及年级等关键身份数据。通过关联系统用户ID实现统一认证，并设置审核状态字段以管控用户准入，确保预约主体身份真实有效。如表4-1所示。
表 4-1student_users（学生用户）
| 编号 | 字段名 | 类型 | 长度 | 是否非空 | 是否主键 | 注释 |
|---|---|---|---|---|---|---|
| 1 | student_users_id | int | 是 | 是 | 学生用户ID | |
| 2 | student_name | varchar | 64 | 否 | 否 | 学生姓名 |
| 3 | student_number | varchar | 64 | 是 | 是 | 学生学号 |
| 4 | student_gender | varchar | 64 | 否 | 否 | 学生性别 |
| 5 | student_mobile_phone | varchar | 16 | 是 | 是 | 学生手机 |
| 6 | name_of_college | varchar | 64 | 否 | 否 | 学院名称 |
| 7 | grade_name | varchar | 64 | 否 | 否 | 年级名称 |
| 8 | examine_state | varchar | 16 | 是 | 否 | 审核状态 |
| 9 | user_id | int | 是 | 否 | 用户ID | |
| 10 | create_time | datetime | 是 | 否 | 创建时间 | |
| 11 | create_by | int | 是 | 否 | 创建用户ID | |
| 12 | update_time | timestamp | 是 | 否 | 更新时间 |
教师用户表旨在维护教师用户的基础信息，包括工号、姓名、联系方式及所属学院等核心字段。作为教室资源的重要使用群体，该表通过工号唯一标识教师身份，并与系统账号关联，支持教师进行教室预约及设备报修。如表4-2所示。
表 4-2teacher_user（教师用户）
| 编号 | 字段名 | 类型 | 长度 | 是否非空 | 是否主键 | 注释 |
|---|---|---|---|---|---|---|
| 1 | create_by | int | 是 | 否 | 创建用户ID | |
| 2 | create_time | datetime | 是 | 否 | 创建时间 | |
| 3 | examine_state | varchar | 16 | 是 | 否 | 审核状态 |
| 4 | name_of_college | varchar | 64 | 否 | 否 | 学院名称 |
| 5 | teacher_user_id | int | 是 | 是 | 教师用户ID | |
| 6 | teachers_mobile_phone | varchar | 16 | 否 | 否 | 教师手机 |
| 7 | teachers_name | varchar | 64 | 否 | 否 | 教师姓名 |
| 8 | teachers_work_number | varchar | 64 | 是 | 是 | 教师工号 |
| 9 | update_time | timestamp | 是 | 否 | 更新时间 | |
| 10 | user_id | int | 是 | 否 | 用户ID |
教室信息表是系统核心资源库，详细记录教室编号、名称、类型、位置、容量及实时状态等静态属性。同时集成点击、点赞、收藏及评论数等动态交互数据，并设定预约次数限制，为前端展示、空闲查询及预约冲突检测提供完整的数据依据。如表4-3所示。
表 4-3class_nameroom_information（教室信息）
| 编号 | 字段名 | 类型 | 长度 | 是否非空 | 是否主键 | 注释 |
|---|---|---|---|---|---|---|
| 1 | class_nameroom_information_id | int | 是 | 是 | 教室信息ID | |
| 2 | class_nameroom_no | varchar | 64 | 是 | 是 | 教室编号 |
| 3 | class_nameroom_name | varchar | 64 | 否 | 否 | 教室名称 |
| 4 | class_nameroom_type | varchar | 64 | 否 | 否 | 教室类型 |
| 5 | class_nameroom_location | varchar | 64 | 否 | 否 | 教室位置 |
| 6 | class_nameroom_status | varchar | 64 | 否 | 否 | 教室状态 |
| 7 | class_nameroom_capacity | double | 否 | 否 | 教室容量 | |
| 8 | class_nameroom_photo | varchar | 255 | 否 | 否 | 教室照片 |
| 9 | instructions_for_use | longtext | 42949 | 否 | 否 | 使用说明 |
| 10 | hits | int | 是 | 否 | 点击数 | |
| 11 | praise_len | int | 是 | 否 | 点赞数 | |
| 12 | collect_len | int | 是 | 否 | 收藏数 | |
| 13 | comment_len | int | 是 | 否 | 评论数 | |
| 14 | reservation_information_limit_times | int | 是 | 否 | 预约教室限制次数 | |
| 15 | create_time | datetime | 是 | 否 | 创建时间 | |
| 16 | create_by | int | 是 | 否 | 创建用户ID | |
| 17 | update_time | timestamp | 是 | 否 | 更新时间 |
预约时段表用于定义和管理教室可预约的时间片段，如"第一节08:00-09:40"等时段范围。作为预约业务的基础字典数据，它规范了时间粒度，避免人工输入误差，确保预约申请在统一的时间标准下进行。如表4-4所示。
表 4-4appointment_period（预约时段）
| 编号 | 字段名 | 类型 | 长度 | 是否非空 | 是否主键 | 注释 |
|---|---|---|---|---|---|---|
| 1 | appointment_period_id | int | 是 | 是 | 预约时段ID | |
| 2 | period_range | varchar | 64 | 否 | 否 | 时段范围 |
| 3 | create_time | datetime | 是 | 否 | 创建时间 | |
| 4 | create_by | int | 是 | 否 | 创建用户ID | |
| 5 | update_time | timestamp | 是 | 否 | 更新时间 |
预约信息表完整记录每一次教室预约请求的全生命周期数据，关联申请人（学生/教师）、教室信息及预约时段。包含预约用途、单号、日期及审核状态与回复等关键字段，是实现预约申请、管理员审批、冲突检测及历史记录查询的核心业务表。如表4-5所示。
表 4-5reservation_information（预约信息）
| 编号 | 字段名 | 类型 | 长度 | 是否非空 | 是否主键 | 注释 |
|---|---|---|---|---|---|---|
| 1 | reservation_information_id | int | 是 | 是 | 预约信息ID | |
| 2 | teacher_user | int | 否 | 否 | 教师用户 | |
| 3 | student_users | int | 否 | 否 | 学生用户 | |
| 4 | class_nameroom_no | varchar | 64 | 否 | 否 | 教室编号 |
| 5 | class_nameroom_name | varchar | 64 | 否 | 否 | 教室名称 |
| 6 | class_nameroom_type | varchar | 64 | 否 | 否 | 教室类型 |
| 7 | class_nameroom_location | varchar | 64 | 否 | 否 | 教室位置 |
| 8 | appointment_date | date | 否 | 否 | 预约日期 | |
| 9 | reservation_order_number | varchar | 64 | 否 | 否 | 预约单号 |
| 10 | appointment_period | varchar | 64 | 否 | 否 | 预约时段 |
| 11 | appointment_purpose | text | 65535 | 否 | 否 | 预约用途 |
| 12 | examine_state | varchar | 16 | 是 | 否 | 审核状态 |
| 13 | examine_reply | varchar | 255 | 否 | 否 | 审核回复 |
| 14 | repair_request_log_limit_times | int | 是 | 否 | 报修申请限制次数 | |
| 15 | create_time | datetime | 是 | 否 | 创建时间 | |
| 16 | create_by | int | 是 | 否 | 创建用户ID | |
| 17 | update_time | timestamp | 是 | 否 | 更新时间 | |
| 18 | extra | text | 65535 | 否 | 否 | 额外信息 |
| 19 | source_table | varchar | 255 | 否 | 否 | 来源表 |
| 20 | source_id | int | 否 | 否 | 来源ID | |
| 21 | source_user_id | int | 否 | 否 | 来源用户 |
报修记录表用于追踪教室设备故障的报修全流程，记录故障描述、现场照片、维修进度及处理详情。关联报修人身份与具体教室信息，生成唯一维修单号，实现从故障上报、管理员派单到维修反馈的闭环管理。如表4-6所示。
表 4-6repair_request_log（报修记录）
| 编号 | 字段名 | 类型 | 长度 | 是否非空 | 是否主键 | 注释 |
|---|---|---|---|---|---|---|
| 1 | class_nameroom_location | varchar | 64 | 否 | 否 | 教室位置 |
| 2 | class_nameroom_name | varchar | 64 | 否 | 否 | 教室名称 |
| 3 | class_nameroom_no | varchar | 64 | 否 | 否 | 教室编号 |
| 4 | class_nameroom_type | varchar | 64 | 否 | 否 | 教室类型 |
| 5 | create_by | int | 是 | 否 | 创建用户ID | |
| 6 | create_time | datetime | 是 | 否 | 创建时间 | |
| 7 | extra | text | 65535 | 否 | 否 | 额外信息 |
| 8 | fault_description | text | 65535 | 否 | 否 | 故障描述 |
| 9 | maintenance_progress | varchar | 64 | 否 | 否 | 维修进度 |
| 10 | number_of_repair_reports | varchar | 64 | 是 | 否 | 报修次数 |
| 11 | repair_order_number | varchar | 64 | 否 | 否 | 维修单号 |
| 12 | repair_photo | varchar | 255 | 否 | 否 | 报修照片 |
| 13 | repair_request_log_id | int | 是 | 是 | 报修记录ID | |
| 14 | repair_specificss | text | 65535 | 否 | 否 | 维修详情 |
| 15 | source_id | int | 否 | 否 | 来源ID | |
| 16 | source_table | varchar | 255 | 否 | 否 | 来源表 |
| 17 | source_user_id | int | 否 | 否 | 来源用户 | |
| 18 | student_user | int | 否 | 否 | 学生用户 | |
| 19 | teacher_user | int | 否 | 否 | 教师用户 | |
| 20 | update_time | timestamp | 是 | 否 | 更新时间 |
意见反馈表构建用户与管理端之间的沟通桥梁，存储师生提交的反馈内容、类型及处理状态。记录反馈编号、详细内容及管理员的处理回复，形成完整的意见流转记录。如表4-7所示。
表 4-7feedback（意见反馈）
| 编号 | 字段名 | 类型 | 长度 | 是否非空 | 是否主键 | 注释 |
|---|---|---|---|---|---|---|
| 1 | feedback_id | int | 是 | 是 | 意见反馈ID | |
| 2 | teacher_user | int | 否 | 否 | 教师用户 | |
| 3 | student_users | int | 否 | 否 | 学生用户 | |
| 4 | feedback_number | varchar | 64 | 否 | 否 | 反馈编号 |
| 5 | type_of_feedback | varchar | 64 | 否 | 否 | 反馈类型 |
| 6 | feedback_content | longtext | 429496 | 否 | 否 | 反馈内容 |
| 7 | processing_status | varchar | 64 | 否 | 否 | 处理状态 |
| 8 | handling_reply | longtext | 429496 | 否 | 否 | 处理回复 |
| 9 | create_time | datetime | 是 | 否 | 创建时间 | |
| 10 | create_by | int | 是 | 否 | 创建用户ID | |
| 11 | update_time | timestamp | 是 | 否 | 更新时间 |
5 系统实现
5.1 用户功能实现
5.1.1 用户注册登录功能实现
用户打开系统首页，点击"登录/注册"入口。若选择注册，需填写账号、密码、姓名、角色（学生/教师），系统校验账号唯一性后自动创建账号；若选择登录，支持账号密码方式，后端比对凭证后生成Token。登录成功后，系统根据"角色"动态加载预约、报修、反馈等功能菜单，保持会话状态。注册登录界面如图5-1、5-2所示。
图5-1 注册界面
图5-2 登录界面
实现代码：
if ("REGISTER".equals(action)) {
User user = new User(account, password, name, role, college);
if (userService.exists(account)) throw new Exception("账号已存在");user.setPassword(securityService.encrypt(password));
userService.save(user);
} else {
User u = userService.getByAccount(account);
if (securityService.match(password, u.getPassword()))
return Result.success(jwtService.createToken(u.getUserId()));
}
5.1.2 教室预约申请功能实现
用户在"教室信息"模块点击"预约教室"，选择目标教室、预约日期及时段，填写使用用途并提交。系统校验教室该时段是否空闲，成功后生成预约单号，状态默认为"待审核"。用户可在"预约记录"中查看审核结果及使用记录。教室查看界面如图5-3所示。
图5-3教室查看界面
实现代码：
Reservation res = formToEntity(inputData);
res.setResNo(genResNo()); res.setUserId(currentUser.getId());
Classroom room = classroomService.getById(res.getClassroomId());
if (!roomService.isAvailable(room.getId(), res.getDate(), res.getPeriodId()))
throw new Exception("时段不可用");
res.setState("PENDING"); reservationService.save(res);
return Result.success("预约提交成功");
5.1.3 设施报修提交功能实现
用户在"预约记录"页面选择故障教室，填写故障详细描述并上传现场照片。提交后系统生成报修单号，状态置为"待处理"。用户可在个人中心实时追踪维修进度（如：维修中、已完成），并在完工后进行评价。报修提交界面如图5-4所示。
图5-4报修界面
实现代码：
RepairLog log = formToEntity(inputData);
log.setRepairNo(genRepairNo()); log.setUserId(currentUser.getId());log.setState("PENDING"); log.setCreateTime(new Date());
if (inputData.hasFile()) fileService.upload(log.getPhoto());
repairLogService.save(log);
return Result.success("报修已受理");
5.1.4 意见反馈提交功能实现
用户在"意见反馈"模块选择反馈类型（建议/投诉），填写具体内容并提交。系统生成反馈编号，状态默认为"处理中"。管理员回复后，用户可在列表中查看处理结果及回复内容，形成闭环管理。意见反馈界面如图5-5所示。
图5-5意见反馈界面
实现代码：
Feedback fb = formToEntity(inputData);
fb.setFbNo(genFbNo()); fb.setUserId(currentUser.getId());fb.setState("PROCESSING"); fb.setCreateTime(new Date());
feedbackService.save(fb);
return Result.success("反馈已提交");
5.2 管理员功能实现
5.2.1 预约审核与管理功能实现
管理员在后台查看全量预约申请，核对时间与用途合理性，执行"通过"或"驳回"操作。审核通过后，系统自动锁定对应教室时段，防止重复预约。管理员还可手动维护教室基础信息（如类型、容量、状态）。预约管理界面如图5-6所示。
图5-6审核界面
实现代码：
Reservation res = reservationService.getById(resId);
if ("PASS".equals(action)) {res.setState("APPROVED");
classroomService.lock(res.getClassroomId(), res.getDate(), res.getPeriodId());
} else {
res.setState("REJECTED"); res.setReply(reason);
}
reservationService.update(res);
return Result.success("审核完成");
5.2.2 报修处理功能实现
管理员查看待处理报修单，确认故障情况后更新维修进度，或指派具体维修人员。维修完成后，管理员录入维修结果并上传完工照片，通知用户评价。同时可统计各教室故障率以优化维护计划。报修申请列表界面如图5-7所示。
图5-9报修申请列表界面
实现代码：
RepairLog log = repairLogService.getById(logId);
if ("PROCESS".equals(action)) {
log.setState("MAINTAINING"); log.setProgress(desc);
} else if ("DONE".equals(action)) {
log.setState("COMPLETED"); log.setFinishTime(new Date());
}
repairLogService.update(log);
return Result.success("状态已更新");
5.2.3 反馈回复与管理功能实现
管理员在反馈列表中查看用户提交的建议或投诉，填写处理意见并回复。对于有效建议标记为"已采纳"，对于无效投诉标记为"已解释"。系统自动将回复推送给用户端，并更新反馈状态为"已完成"。反馈管理界面如图5-8所示。
图5-8反馈回复界面
实现代码：
Feedback fb = feedbackService.getById(fbId);
if ("REPLY".equals(action)) {fb.setReplyContent(content); fb.setState("COMPLETED");
fb.setReplyTime(new Date());
messageService.push(fb.getUserId(), "您的反馈已回复");
}
feedbackService.update(fb);
return Result.success("回复成功");
5.2.4 基础数据维护功能实现
管理员对系统基础数据进行统一管理，包括新增/编辑教室信息、配置预约时段规则、管理用户账号状态等。确保教室资源数据的准确性，保障预约业务的正常运行。数据维护界面如图5-9所示。
图5-9校园资讯发布界面
实现代码：
if ("SAVE_ROOM".equals(action)) {
Classroom room = formToEntity(inputData);
classroomService.saveOrUpdate(room);
} else if ("SET_PERIOD".equals(action)) {
Period p = new Period(range, start, end);
periodService.save(p);
}
return Result.success("数据更新成功");
6 系统测试
6.1 测试目的方法
系统测试是软件开发过程中的关键环节，其主要目的是验证系统是否能够稳定、高效地运行，确保各功能模块符合设计需求，在不同应用场景下具备良好的兼容性与安全性。通过测试发现并修复潜在问题，保障系统在实际应用中的可靠性与用户体验。
系统的测试过程中，采用多种测试方法相结合的方式，以确保测试的全面性和有效性，包括功能测试、性能测试、兼容性测试、安全性测试多种手段，采用自动化工具与人工测试相结合的方式，全面评估系统的各项指标，确保系统在多用户并发、复杂网络环境下的稳定运行能力。下面将主要对功能测试用例进行分析说明。
6.2 功能测试用例
（1）用户注册与登录功能测试
在访问系统前，用户（学生/教师）需完成注册。该模块测试旨在验证账号创建的唯一性、密码加密存储及登录鉴权的准确性。用户注册与登录功能测试用例设计如表6-1所示。
表6-1用户注册与登录功能测试表
| 测试目的 | 用例描述 | 预期结果 | 测试结果 |
|---|---|---|---|
| 验证用户成功注册 | 输入未注册的学号/工号、密码及学院信息，点击注册 | 提示注册成功，账号状态正常 | 通过 |
| 验证账号重复注册 | 输入已存在的学号/工号进行注册 | 提示"账号已存在"，注册失败 | 通过 |
| 验证有效登录 | 输入正确的账号和密码，点击登录 | 登录成功，跳转至用户首页，加载对应菜单 | 通过 |
| 验证错误密码登录 | 输入正确账号和错误密码 | 提示"用户名或密码错误" | 通过 |
| 验证角色权限隔离 | 分别使用学生和教师账号登录 | 界面显示的功能菜单一致（因合并为用户实体），但数据权限隔离 | 通过 |
（2）教室预约申请与管理功能测试
该模块是系统的核心，测试重点在于用户提交预约单的完整性、管理员审核流程的通畅性以及教室时段锁定的逻辑正确性。教室预约申请与管理功能测试用例设计如表6-2所示。
表6-2 教室预约申请与管理功能测试表
| 测试目的 | 用例描述 | 预期结果 | 测试结果 |
|---|---|---|---|
| 验证预约单提交 | 用户选择教室、日期、时段并填写用途，提交申请 | 生成预约单号，状态显示为"待审核"，列表可见 | 通过 |
| 验证时段冲突检测 | 选择已被占用的教室时段提交预约 | 提示"该时段不可用"，提交失败 | 通过 |
| 验证必填项校验 | 提交预约单时不填写"用途说明" | 提示"用途不能为空"，提交失败 | 通过 |
| 验证管理员审核通过 | 管理员对预约单执行"通过"操作 | 预约状态变更为"已通过"，教室时段被锁定 | 通过 |
| 验证管理员审核驳回 | 管理员对预约单执行"驳回"并填写理由 | 预约状态变更为"已驳回"，释放占用时段，用户收到通知 | 通过 |
（3）报修申请与处理功能测试
针对报修模块，主要检验故障描述的完整性、图片上传的稳定性以及维修进度的实时更新逻辑。设施报修提交与处理功能测试用例设计如表6-3所示。
表6-3 报修申请与处理功能测试表
| 测试目的 | 用例描述 | 预期结果 | 测试结果 |
|---|---|---|---|
| 验证报修单提交 | 用户选择故障教室，填写描述并上传图片，提交申请 | 生成报修单号，状态显示为"待处理"，图片可预览 | 通过 |
| 验证维修进度更新 | 管理员更新报修单状态为"维修中"或"已完成" | 用户端实时显示最新进度，并可查看完工照片 | 通过 |
| 验证评价功能 | 维修完成后，用户对服务进行打分和留言 | 评价成功保存，关联至该报修记录，状态闭环 | 通过 |
| 验证空内容拦截 | 提交报修时不填写"故障描述" | 提示"故障描述不能为空"，提交失败 | 通过 |
| 验证图片格式校验 | 上传非图片格式文件（如.txt） | 系统拦截上传，提示"仅支持图片格式" | 通过 |
（4）意见反馈与回复功能测试
该模块测试重点在于反馈提交的便捷性、管理员回复的及时性以及状态流转的正确性。意见反馈与回复功能测试用例设计如表6-4所示。
表6-4 意见反馈与回复功能测试表
| 测试目的 | 用例描述 | 预期结果 | 测试结果 |
|---|---|---|---|
| 验证反馈提交 | 用户选择反馈类型，填写内容并提交 | 生成反馈编号，状态为"处理中"，列表可见 | 通过 |
| 验证管理员回复 | 管理员查看反馈并填写处理意见，点击回复 | 反馈状态更新为"已完成"，用户端可见回复内容 | 通过 |
| 验证反馈类型筛选 | 用户在列表页选择"投诉"或"建议"进行筛选 | 列表准确展示对应类型的反馈记录 | 通过 |
| 验证敏感词过滤 | 提交包含违规词汇的反馈内容 | 系统自动拦截或标记为"待人工审核" | 通过 |
| 验证未读消息提醒 | 管理员回复后，用户再次登录系统 | 个人中心显示"您有新的反馈回复"提醒 | 通过 |
（5）基础数据管理功能测试
针对管理员后台，主要检验教室信息维护的准确性、时段配置的灵活性以及用户管理的规范性。基础数据管理功能测试用例设计如表6-5所示。
表6-5 基础数据管理功能测试表
| 测试目的 | 用例描述 | 预期结果 | 测试结果 |
|---|---|---|---|
| 验证教室信息新增 | 管理员录入新教室编号、名称、类型及容量 | 教室成功添加，前端预约列表实时同步 | 通过 |
| 验证时段规则配置 | 管理员设置新的预约时段（如：19:00-21:00） | 用户预约时可选该时段，时间范围显示正确 | 通过 |
| 验证教室状态修改 | 管理员将某教室状态设为"维护中" | 该教室在用户端不可被预约，显示"暂停服务" | 通过 |
| 验证用户账号禁用 | 管理员对违规用户执行"禁用"操作 | 该用户无法登录系统，提示"账号已被禁用" | 通过 |
| 验证数据导出 | 管理员点击"导出教室列表" | 系统生成Excel文件，数据完整且格式正确 | 通过 |
6.3 测试结果分析
在本次测试过程中，针对教室预约管理系统的业务逻辑和数据交互过程，重点对用户注册登录、教室预约流程、报修处理闭环、意见反馈机制及基础数据管理等核心模块进行了全面的业务流程验证。通过设计并执行上述测试用例，开展了多轮功能性测试分析。
经过严格的测试验证，所有设计的测试用例均已成功通过。结果表明系统各项功能均能按照需求规格说明书预期正常运行，用户端操作便捷，管理端调度高效，实现了预约、报修、反馈等业务的数字化闭环。且在高并发场景（如选课期间多人同时预约、集中报修）下，数据库的事务锁机制有效避免了时段冲突和数据状态不一致，保证了数据存储、读取及更新的准确性和完整性。同时，界面响应速度稳定，异常处理机制健全（如时段冲突拦截、必填项校验、文件格式限制等），具备良好的容错能力。
综上所述，系统已达到设计初期设定的目标与期望，具备投入实际试运行环境的条件。