基于Qt的公共卫生间管理系统的设计与实现大数据专业毕业设计深度学习图像识别

✅源码获取--------------------【点击左上方头像在置顶文章上方的wx】联系我们-----------------✌网站介绍✌10年项目辅导经验、专注于计算机技术领域学生项目实战辅导。✌服务范围大数据、机器学习、Java(SpringBoo/SSM)、Python、PHP、Nodejs、爬虫、数据可视化、小程序、安卓app等设计与开发。✅优秀相关专栏推荐✅2024-2025年最全的计算机软件毕业设计选题大全1000个热门选题推荐✅Java精品实战项目1000Python精品实战项目1000ASP.NET精品实战项目1000PHP精品实战项目1000APP精品实战项目1000微信小程序精品实战项目1000Node.js精品实战项目1000针对中小城市基层市政部门在公共卫生间管理中面临的预算有限、人工管理效率低、现有智慧公厕方案落地成本过高的问题本课题设计并实现了一套低成本的公共卫生间管理系统。系统采用前后端分离的架构基于 PyQt5 与 FastAPI 完成开发实现了用户权限管理、站点管理、实时状态监控、环境监测、自动派单、统计报表等核心功能其中环境异常自动派单、WebSocket 实时推送、任务去重等机制有效解决了传统管理中的痛点。经过测试验证系统的所有功能均满足设计需求能够有效提升基层部门的管理效率降低管理成本。该系统为中小城市的公共卫生间信息化管理提供了可落地的低成本解决方案具备良好的应用价值。总体分层架构设计本系统采用前后端分离的分层架构进行设计整体划分为前端客户端层、通信协议层、后端接口层、业务逻辑层和数据访问层五个层次各层之间通过明确的接口进行交互实现了职责的清晰分离和模块的有效解耦。前端客户端层基于PyQt5框架构建负责用户界面的渲染与交互逻辑的处理。该层包含状态展示、信息管理、统计报表、用户管理、系统配置、日志管理六个功能模块每个模块以独立的页面组件形式实现由主窗口统一管理页面切换和角色分流。前端通过封装的HTTP客户端与后端进行业务数据交互通过WebSocket客户端接收后端的实时推送消息。通信协议层定义了前后端之间的数据传输规范。业务数据的查询与操作采用HTTP协议传输请求和响应体统一使用JSON格式编码前端在请求头中携带JWT令牌进行身份认证。实时状态数据的更新采用WebSocket协议后端定时向所有已连接的客户端推送状态刷新信号前端收到信号后主动拉取最新数据该机制避免了纯轮询带来的网络压力同时保证了数据的时效性。后端接口层基于FastAPI框架构建负责接收前端请求、路由分发和响应返回。该层通过依赖注入机制统一处理数据库会话的获取与释放、当前用户身份的解析与校验、管理员权限的验证等横切关注点使得业务接口的代码聚焦于核心逻辑提升了代码的简洁性和可维护性。业务逻辑层封装了系统的核心业务规则包括认证服务、站点服务、厕位服务、环境服务、任务服务、统计服务和日志服务。每个服务模块独立负责各自领域的业务处理服务之间通过数据库模型进行数据共享避免了不必要的耦合。环境服务在检测到异常指标时调用任务服务生成自动派单任务服务在创建任务时调用日志服务记录操作审计形成了清晰的业务协作关系。数据访问层基于SQLAlchemy ORM框架实现将数据库表映射为Python类将SQL查询转化为面向对象的操作。该层屏蔽了底层数据库的访问细节上层业务逻辑通过操作ORM模型即可完成数据的增删改查当需要更换数据库类型时只需修改连接配置无需调整业务代码。分层架构的核心优势在于解耦。各层之间通过定义良好的接口进行通信某一层的内部实现发生变化时只要接口契约不变就不会影响其他层的功能。这种设计使得系统在面对需求变更时具备良好的适应性例如前端界面可以独立优化而不影响后端逻辑业务规则可以独立调整而不影响数据存储方案。系统总体分层架构如图4-1所示。图4-1系统总体分层架构图前后端交互流程设计前后端之间的交互流程围绕请求—认证—处理—响应四个环节展开确保每一次数据交互都经过完整的身份校验和业务处理。在登录阶段用户在Qt客户端输入账号和密码后前端向后端的登录接口发送POST请求请求体包含用户名和密码信息。后端接收请求后通过bcrypt算法对输入密码与数据库中存储的哈希值进行比对验证验证通过后使用PyJWT库签发JWT令牌令牌的载荷中包含用户名和角色信息并设置过期时间。前端收到令牌后将其存储在内存中后续所有请求均在HTTP头的Authorization字段中携带该令牌。在业务请求阶段前端发起请求时由封装的HTTP客户端自动注入令牌。后端接口通过依赖注入函数解析令牌提取用户身份信息若令牌无效或已过期则返回401状态码前端收到401响应后弹出登录过期提示并跳转回登录界面。对于需要管理员权限的接口后端在解析用户身份后进一步校验角色字段非管理员用户访问管理类接口时返回403状态码。在实时推送阶段前端状态页面在加载时建立WebSocket连接后端将连接对象加入连接列表。后端启动一个异步广播循环按照配置的刷新间隔定时查询厕位状态汇总和环境数据汇总将数据序列化为JSON格式后向所有活跃的WebSocket连接推送。前端通过独立线程接收推送消息收到消息后触发信号通知主线程重新调用HTTP接口拉取最新数据并更新界面展示。这种推送通知拉取数据的混合模式既保证了实时性又避免了WebSocket传输大量数据带来的性能开销。前后端核心交互流程如图4-2所示。核心业务模块划分根据系统需求分析本系统将功能划分为认证与权限管理、公厕站点信息管理、厕位状态实时监控、环境状态监测预警、维护任务管理、统计报表与导出、系统配置管理、日志审计管理八个核心业务模块。各模块与功能性需求一一对应模块之间通过数据依赖和业务协作关系进行关联。认证与权限管理模块是系统的基础支撑模块负责用户身份的验证和访问权限的控制其他所有模块的接口调用都需要经过该模块的身份校验。公厕站点信息管理模块维护站点的基础数据和设施配置为厕位状态监控、环境监测、任务管理、统计报表等模块提供站点维度的数据基础。厕位状态实时监控模块和环境状态监测预警模块依赖于站点数据分别提供厕位占用状态和环境参数的实时监控能力其中环境监测模块在检测到异常时会触发任务管理模块的自动派单逻辑。维护任务管理模块与站点数据和用户数据均存在关联任务的创建需要指定关联的公厕站点任务的派发需要选择系统中的用户作为执行人。统计报表与导出模块依赖于站点数据和任务数据进行多维度统计分析。系统配置管理和日志审计管理作为辅助模块前者维护系统的运行参数后者记录关键操作的审计轨迹。系统功能模块划分如图4-3所示。图4-3系统功能模块划分图环境异常自动派单逻辑环境异常自动派单是本系统的核心业务逻辑之一其设计目标是在环境指标出现异常时自动生成维护任务同时避免因持续异常而重复创建相同类型的任务。该逻辑的完整流程如下首先系统在每次获取环境数据时检测当前的环境指标是否超过预设阈值。判断规则分为两个层级一般异常层级判定条件为湿度超过80%、异味等级超过6或AQI超过100触发生成清洁类型的任务严重异常层级判定条件为AQI达到130及以上或异味等级达到8.5及以上触发生成维修类型的任务。严重异常的判定优先级高于一般异常即当指标同时满足两个层级时生成维修任务而非清洁任务。其次在确定需要生成任务后系统执行去重检查。去重的判定条件为同一公厕站点、同一任务类型清洁或维修、同一任务来源环境异常或设备故障下是否已存在状态为待派发、已派发或执行中的任务。若存在未完成的同类型任务则跳过本次任务生成避免重复派单造成资源浪费。最后通过去重检查后系统创建新的任务记录初始状态设置为待派发同时将本次自动派单操作记录到操作日志中日志的用户名字段标记为system表示系统自动触发的操作。环境异常自动派单逻辑流程如图4-6所示。实时状态推送逻辑实时状态推送逻辑的设计目标是在后端数据发生变化时及时通知前端刷新展示内容使管理人员能够实时掌握公厕的运行状态。该逻辑采用后端定时推送通知前端按需拉取数据的混合模式实现。在后端系统启动时创建一个异步广播循环任务broadcast_loop。该循环按照配置的刷新间隔默认10秒可在系统配置中调整周期性执行以下操作首先从数据库查询所有公厕站点的厕位状态汇总数据和环境监测汇总数据然后将两部分数据合并序列化为JSON格式的消息体最后遍历当前所有活跃的WebSocket连接逐一发送该消息。若某个连接在发送过程中出现异常则将该连接从列表中移除保证连接列表的有效性。在前端状态页面加载时创建一个独立的线程WsThread与后端建立WebSocket连接。该线程在独立的事件循环中持续接收后端推送的消息每收到一条消息即通过Qt的信号机制向主线程发射refresh信号。主线程中的状态页面接收到refresh信号后调用load_data方法重新向后端发送HTTP请求拉取最新的厕位状态和环境数据并更新表格和图表的展示内容。当状态页面被切换隐藏时前端主动关闭WebSocket连接并停止接收线程避免不必要的资源消耗页面重新显示时重新建立连接恢复实时推送。这种设计将推送通知与数据传输分离WebSocket仅承担通知前端刷新的轻量级职责实际的数据传输仍通过HTTP请求完成。这样做的好处是WebSocket消息体较小推送延迟低同时前端拉取数据时可以携带筛选参数灵活性更高。实时状态推送逻辑流程如图4-7所示。在前端RestroomsPage页面在加载时调用列表接口获取站点数据以表格形式展示站点ID、序号、名称、行政区、区块和使用状态。筛选区域提供行政区、区块、类别三个下拉选择框其中区块选项根据所选行政区动态更新实现级联筛选效果。分页控件提供上一页和下一页按钮底部显示当前页码和总记录数。管理员点击新增或编辑按钮时弹出RestroomForm对话框该对话框以表单形式收集站点的各项信息包括序号、名称、地址、行政区、区块、类别、使用状态、坑位数量、开放时间、责任人员等字段保存后调用对应的接口提交数据。公厕站点管理界面如图5-3所示。图5-3公厕站点管理界面截图厕位使用状态实时监控功能实现厕位使用状态实时监控功能的实现涉及后端的数据聚合接口、WebSocket推送机制以及前端的状态展示和图表渲染。在后端厕位状态服务为每个公厕站点维护厕位的占用状态数据。get_all_restrooms_stall_summary函数遍历所有站点对每个站点调用get_restroom_stall_status函数获取该站点的厕位汇总信息。该函数首先根据站点的女坑位数和男坑位数计算总坑位数然后查询stall_status表中该站点的已有记录若记录数不足则自动补充生成随机占用状态的记录最终返回总坑位数、已占用数和各坑位的详细状态列表。汇总接口GET/api/v1/stalls/summary将所有站点的汇总数据以列表形式返回每条记录包含站点ID、站点名称、总坑位数、已占用数和各坑位状态。WebSocket推送机制在ws.py中实现。broadcast_loop异步函数按照系统配置的刷新间隔默认10秒周期性地调用厕位状态服务和环境服务获取汇总数据将数据序列化为JSON后向所有活跃的WebSocket连接发送。websocket_endpoint函数处理新连接的建立将连接对象加入全局连接列表连接断开时从列表中移除。在前端StatusPage页面在显示时启动WsThread线程建立WebSocket连接在隐藏时停止线程并关闭连接。load_data方法被调用时首先请求厕位状态汇总接口解析返回数据后更新指标卡片公厕数量、总坑位、整体占用率、工单数量、工单完成率和厕位占用列表。列表支持按占用率排序每行显示站点ID、名称、总坑位、已占用、占用率和进度条。图表展示方面饼图使用QPieSeries展示整体占用与空闲的比例柱状图使用QBarSeries展示占用率最高的前15个站点堆叠柱状图使用QStackedBarSeries展示前12个站点的占用与空闲分布。所有图表均支持鼠标悬停显示详细数据的交互效果。当WsThread收到后端推送消息后发射refresh信号触发load_data方法重新执行实现界面的自动刷新。厕位状态监控界面如图5-4所示。图5-4厕位状态监控界面截图环境状态监测功能实现环境状态监测功能的实现包括后端的环境数据接口、异常检测与自动派单逻辑以及前端的环境参数展示和告警提示。在后端环境监测服务environment_mock.py负责生成和管理各站点的环境采样数据。_gen_reading函数为指定站点生成一组模拟的环境读数包括温度18-28°C随机值、湿度40%-95%随机值、AQI20-150随机值和异味等级0-10随机值同时根据阈值判断是否产生告警。_ensure_latest函数确保每个站点至少有一条环境记录若数据库中无记录则自动生成一条。get_latest_by_restroom函数在返回环境数据的同时调用_auto_dispatch_by_env函数执行异常检测与自动派单逻辑。自动派单逻辑的实现分为两个层级。当AQI达到130及以上或异味等级达到8.5及以上时系统判定为严重异常调用_create_auto_task函数生成类型为维修、来源为设备故障的任务。当湿度超过80%、异味等级超过6或AQI超过100时系统判定为一般异常生成类型为清洁、来源为环境异常的任务。_create_auto_task函数在创建任务前调用_has_open_task函数检查去重条件若同站点、同类型、同来源下已存在未完成任务则跳过创建。任务创建成功后系统自动记录一条操作日志用户名标记为system。在前端StatusPage页面的环境状态区域同时提供表格和图表两种展示方式。表格列出各站点的温度、湿度、AQI、异味等级、是否异常和记录时间异常状态以红色文字标注。图表提供两种模式AQI-异味散点图模式使用QScatterSeries以AQI为横轴、异味为纵轴绘制各站点的环境分布便于识别异常站点温湿度趋势图模式使用QLineSeries绘制最近30条记录的温度和湿度变化曲线便于观察环境参数的时间趋势。用户可通过下拉框切换图表模式图表支持鼠标悬停显示站点名称和具体数值。环境状态监测界面如图5-5所示。图5-5环境状态监测界面截图维护与保洁任务管理功能实现维护与保洁任务管理功能的实现覆盖任务的创建、派发、执行和完成全流程包括后端的任务接口和自动派单逻辑以及前端的任务列表和工单流转界面。在后端任务服务task.py封装了任务的CRUD操作。create_task函数接收TaskCreate模型创建新任务初始状态为待派发。list_tasks函数支持按公厕ID、状态、类型、执行人、时间范围等多条件筛选返回分页结果。update_task函数处理任务状态的变更当状态更新为已派发时自动记录派发时间当状态更新为已完成时自动记录完成时间。任务接口/api/v1/tasks在路由层注入权限校验依赖管理员可查看全部任务操作员通过assignee筛选参数仅可查看指派给自己的工单。在前端TasksPage页面根据用户角色呈现不同的交互模式。管理员模式下页面提供新建任务、派发和标记完成三个操作按钮。新建任务时弹出TaskForm对话框用户选择关联的公厕站点下拉列表从后端动态加载、任务类型清洁/维修、任务来源人工上报/环境异常/设备故障并填写任务描述。派发任务时系统先获取所有用户名列表弹出执行人选择对话框管理员选择执行人后调用更新接口将任务状态设为已派发并指定执行人。标记完成时直接调用更新接口将状态设为已完成。操作员模式下页面标题变更为工单任务副标题提示仅查看已指派给当前用户的工单新建和派发按钮被隐藏仅保留提交完成按钮。筛选条件中自动以当前用户名作为执行人过滤条件确保操作员只能看到自己的工单。任务列表以表格形式展示任务ID、公厕ID、类型、来源、状态、执行人、描述和创建时间状态列使用不同颜色标注待派发为橙色、已派发为蓝色、执行中为紫色、已完成为绿色创建时间统一转换为北京时间显示。任务管理界面如图5-6所示。图5-6任务管理界面截图统计与报表功能实现统计与报表功能的实现包括后端的统计数据计算接口和前端的统计图表渲染与数据导出。在后端统计服务stats.py提供站点资源统计和运行指标统计两类计算能力。站点资源统计按行政区、区块、类别三个维度分组使用SQLAlchemy的func.count和func.sum聚合函数统计每个分组下的站点数量和设施总数女坑位、男坑位、小便池计算结果通过Pydantic模型序列化返回。运行指标统计get_usage_stats函数基于任务数据和站点容量进行确定性计算使用频率根据站点容量和每日任务数量按公式计算清洁次数和故障次数直接统计对应类型的任务数量资源消耗根据清洁次数、故障次数和使用频率按权重系数累加计算。时间序列数据按日期分组统计每日任务数量结合站点容量计算每日使用频率值。该计算方式替代了早期的随机模拟确保统计结果可解释且可复现。导出接口GET/api/v1/stats/export支持JSON和CSV两种格式CSV格式按行政区维度输出站点统计数据。在前端StatsPage页面以选项卡形式组织五个统计视图。按行政区、按区块、按类别三个选项卡分别以表格展示对应维度的站点资源统计每行包含分组名称、站点数、女坑位、男坑位、小便池和占比进度条。运行指标选项卡提供公厕ID多选下拉框支持勾选多个站点进行聚合统计、时间范围选择器和查询按钮查询结果展示使用频率、清洁次数、故障次数、资源消耗四个核心指标同时以折线图展示使用频率的时间趋势。站点分布选项卡以散点图展示各站点在二维坐标上的分布位置坐标通过行政区和区块的MD5哈希值映射生成下方配合站点明细表格。页面底部还展示按行政区的公厕数量柱状图。导出CSV按钮调用导出接口将返回的CSV文本保存到用户选择的文件路径中。统计报表界面如图5-7所示。图5-7统计报表界面截图系统配置与日志审计功能实现系统配置与日志审计功能的实现为系统提供了运行参数管理和操作行为追溯的能力。在后端系统配置服务config_service.py提供配置项的读取和设置操作。配置数据存储在system_config表中以键值对形式维护。get_config_value函数根据键名查询配置值set_config函数更新或创建配置项。配置接口/api/v1/config的读取和更新操作均需要管理员权限更新操作同时记录操作日志。当前系统维护的核心配置项为refresh_interval_secWebSocket推送刷新间隔单位秒默认10。日志审计服务logs.py提供操作日志的记录和查询功能。log_operation函数在每次关键写操作时被调用记录操作用户、角色、模块、动作、目标ID和详情信息。list_operation_logs函数支持按用户名、模块、动作、时间范围进行多条件筛选查询返回按时间倒序排列的分页结果。日志接口/api/v1/logs仅对管理员开放确保操作审计数据的安全性。在前端SettingsPage页面为管理员提供系统配置的维护界面包括刷新间隔的设置和前端主题浅色/深色及字体大小的配置。主题切换通过调用style.py中的apply_theme函数实现该函数根据选择的主题文本为QApplication设置对应的QSS样式表。LogsPage页面提供日志查询界面管理员可按用户名、模块、动作和时间范围筛选日志记录查询结果以表格形式展示包含用户名、角色、模块、动作、目标ID、详情和操作时间等字段。系统配置界面如图5-8所示日志管理界面如图5-9所示。图5-8系统配置界面截图图5-9日志管理界面截图