简介名称虽然叫‘空调’但这份北邮软件工程课程实践资源的核心并不是暖通技术而是一套基于Qt的C多线程管理程序。项目着眼于软件工程专业学生的实践训练适合刚掌握C基础、想通过完整项目学习MVC架构与GUI开发的读者。压缩包共113个文件大小仅2.68MB16个cpp源文件和13个h头文件构成程序主体4个ui文件定义了登录、主窗口、表单等界面65张jpg图片作为界面背景或图标素材另有docx文档说明、qrc资源定义文件和pro工程配置导入Qt Creator即可直接编译运行。代码覆盖用户登录验证、多线程服务端处理、房间信息管理、表单交互等模块清晰呈现了信号槽机制、线程同步、模型-视图分离等关键技术的实际用法。已有392人学习下载尤其适合作为课程设计参考、期末速成复习材料或用来借鉴如何将软件工程的分层思想落地到一个可运行的中小型项目中。1. 软件工程课程里的空调管理系统它到底在练什么某高校软件工程课程的团队实践项目里空调管理系统是一个每年都被翻来覆去做的题目。你以为它只是「设备列表加远程开关」的 CRUD真正做起来才发现温度策略、能耗统计、设备离线判定、批量控制幂等每一项都能让一个小组在评审前夜集体熬夜。这篇笔记以一套完整的空调管理系统模拟项目X为例把需求边界、架构选型、数据库设计、核心代码落点和交付前的验证手段一次讲透。适合正在做课程设计或准备把这个题目扩展成毕业设计的人新手能一步步把工程跑起来熟手能对照检查自己方案里的设计盲区。2. 从需求到架构空调管理系统的模块拆解与选型理由2.1 课程设计的需求边界哪些功能必须做哪些可以砍先聊需求。课程设计最怕的不是功能少而是需求边界失控。我带这个方向的模拟项目X时小组曾经把「根据室内人数自动调节温度」「和课表联动提前预热」都列进需求结果两周过去连设备上报接口都没联调完。后来把需求砍到四件事工期立刻变得可控。必须做的功能我一般归为四类。设备管理负责空调的台账、上下线状态、所属房间和楼栋远程控制负责单台开关机、温度设定和批量开关机自动策略按时间表和温度阈值自动调整运行状态能耗统计按天、按周聚合设备的运行时长和用电量。这四类合起来正好构成一条完整链路设备接入进来数据存下来策略驱动控制报表呈现结果。可以砍掉或放到扩展题目的功能包括和课表联动、多人权限审批流、地图可视化大屏、移动端独立 App。不是这些功能不好而是课程设计周期内收益低。软件工程课程设计的评审重点在于完整度而非酷炫度把一条链路从设备上报做到报表展示比铺开一堆半成品更容易拿高分。需求边界一定要落成文档而不是口头约定。我习惯用一张简单表格记录功能编号、优先级、验收标准评审时直接拿表讲。表格本身不复杂但能让每个成员在开发时清楚自己该交付什么也避免评审老师问「这个功能为什么没做」时只能回答「时间不够」。2.2 单体还是前后端分离选型要看团队人数和评审要求架构选型我见过两种主流做法。第一种是后端框架直接渲染模板的简单单体适合两个人以内的小组开发链路短部署只需要一个进程缺点是前端展示和设备控制耦合在一起后续想扩展移动端就要改后端模板。第二种是前后端分离后端提供 REST API前端单独起一个工程。高校的软件工程课程设计普遍更认可这种结构因为模块边界清晰每个成员负责的部分可以独立测试。模拟项目X 最终选的就是这套后端统一暴露 JSON 接口前端按页面维度组织请求。代价是必须先约定接口文档否则前后端各自猜字段联调阶段会非常痛苦。接口文档的约定方式我建议直接用一份 Markdown 或在线表格先定死字段名不要等代码写完再补。字段命名统一用驼峰时间统一用 ISO8601 字符串ID 统一以字符串形式传给前端。这些约定在选型阶段写进文档后边大量翻车都能提前避免。2.3 设备接入层模拟 MQTT 上报还是直接走 HTTP空调项目的硬件接入是最大的变量。如果实验室有真实设备通常走 MQTT 协议接收设备上报的温度、运行状态如果没有硬件就用一个模拟客户端按固定频率上报数据。模拟项目X 的做法是后者用一个 Python 脚本模拟 20 台空调设备每台每 10 秒上报一次温度、模式、运行状态。为什么用 MQTT 而不是 HTTP关键在于设备数量多、上报频率高、网络环境不稳定MQTT 的发布订阅模型天然适合这类低功耗设备场景。即使你的课程设计完全不接真实硬件在架构图里把 MQTT Broker 画出来再让模拟设备通过 MQTT 客户端接入评审时也会明显感觉到你做过设备侧的技术调研。后端与前端之间的交互仍然走 HTTP设备上报走 MQTT两条链路职责分离HTTP 管人的管理操作MQTT 管设备的状态采集。这样的架构在答辩时容易讲清楚后续把模拟设备替换成真实硬件只需要改设备端不用动业务代码。2.4 模块划分与工程目录组织模拟项目X 的工程目录这样组织aircon-system/ ├── backend/ │ ├── controller/ # HTTP 接口层 │ ├── service/ # 业务逻辑 │ ├── mapper/ # 数据访问 │ ├── mqtt/ # MQTT 订阅与消息处理 │ └── task/ # 定时任务 ├── frontend/ │ ├── src/api/ # 接口请求封装 │ ├── src/views/ # 页面组件 │ └── src/store/ # 全局状态 ├── simulator/ │ └── device_simulator.py # 模拟设备 └── sql/ └── init.sql # 建表脚本这个结构的好处是后端按接口、业务、数据三层切分MQTT 和设备模拟器单独放不会和业务代码混在一起。前端以 API 封装作为和后端唯一的数据通道页面组件不直接拼请求地址。模拟器和数据库脚本独立成目录方便组员各自拉取运行互不干扰。3. 数据库建模与核心表设计别把空调项目做成纯 CRUD3.1 四类核心表的字段设计空调管理系统的数据库设计我一般拆成四张核心表房间表、设备表、运行日志表、策略表再加一张能耗汇总表用于报表加速共五张。设备表是核心中的核心。字段设计上要特别注意设备 ID 在数据库里用自增主键没问题但返回给前端时尽量转成字符串否则前端拿到超过安全范围的数字时会出精度问题这是翻车率极高的一处。设备表里的字段包括id、device_no 设备编号作为业务唯一键、room_id 所属房间、status 在线状态、mode 制冷制热送风、target_temp 目标温度、current_temp 当前温度、last_report_time 最后上报时间、enabled 是否允许被远程控制。房间表承载组织维度id、building_no 楼栋号、floor_no 楼层、room_no 房间号、area 面积面积字段用于后续能耗分摊。策略表存自动控制的规则核心字段是id、strategy_name、start_time、end_time、target_temp、enabled、prioritypriority 用于多条策略冲突时决定谁生效。运行日志表记录每一次控制动作和状态变化id、device_id、action_type、from_status、to_status、operator、create_time。这里有一个容易踩的坑不要在设备表里直接放今日能耗这种聚合字段。很多人在项目初期为了省事把能耗直接记在设备行里每次上报都覆盖最后报表只能看到当前值没法按天聚合。能耗必须单独建表。3.2 能耗数据怎么存明细表与汇总表的分工能耗这块我想单独说。按天聚合能耗时如果每天有几万条上报记录查询会明显变慢。常见做法是两张表配合能耗明细表记录每次功率采样能耗汇总表按小时粒度预聚合。明细表字段id、device_id、sample_time、power_watts、duration_seconds。模拟项目中设备每 10 秒上报一次每次上报都带当前功率和持续时长明细表按 device_id 和 sample_time 建联合索引。汇总表字段id、device_id、stat_date、stat_hour、total_kwh、run_minutes。汇总表由定时任务每小时跑一次把上一小时的明细聚合进汇总表。报表接口只查汇总表不碰明细表百天级能耗查询也能保持较快响应。如果课程设计的数据量不足以让明细查询变慢很多小组会跳过汇总表。我仍然建议把汇总表建出来因为评审时「明细留底、汇总提速」这个设计点本身就是加分项后续扩展成校级平台时汇总表的必要性会立刻体现。3.3 初始化 SQL 与关键索引模拟项目X 的初始化脚本核心部分长这样CREATE TABLE device ( id BIGINT AUTO_INCREMENT PRIMARY KEY, device_no VARCHAR(32) NOT NULL, room_id BIGINT NOT NULL, status TINYINT NOT NULL DEFAULT 0, mode TINYINT NOT NULL DEFAULT 0, target_temp DECIMAL(3,1) NOT NULL DEFAULT 26.0, current_temp DECIMAL(3,1) NOT NULL DEFAULT 26.0, last_report_time DATETIME NULL, enabled TINYINT NOT NULL DEFAULT 1, UNIQUE KEY uk_device_no (device_no), KEY idx_room_id (room_id), KEY idx_last_report_time (last_report_time) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; CREATE TABLE energy_summary ( id BIGINT AUTO_INCREMENT PRIMARY KEY, device_id BIGINT NOT NULL, stat_date DATE NOT NULL, stat_hour TINYINT NOT NULL, total_kwh DECIMAL(10,4) NOT NULL, run_minutes INT NOT NULL, UNIQUE KEY uk_device_hour (device_id, stat_date, stat_hour) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;这里几个参数值得说明。status 和 mode 用 TINYINT 而不是 VARCHAR是为了让取值受枚举约束减少脏数据。device_no 单独建唯一索引业务上不允许两台设备用同一个编号。energy_summary 的唯一索引 uk_device_hour 是关键它保证同一台设备同一个小时的汇总只有一条记录定时任务重跑时可以直接用 INSERT 加 ON DUPLICATE KEY UPDATE 做幂等更新。外键我故意没有建。课程设计里引用关系明确外键会让批量插入和删除时多一层约束检查一旦数据有问题删除设备时会因为外键失败导致接口报错。用普通索引加代码层校验就足够这是小型项目里常见的取舍。3.4 状态位、软删除与常用字段的设计取舍设备表里 status 表示在线状态enabled 表示是否允许被远程控制这两个字段容易混淆。我的约定是status 反映设备侧真实通信状态由 MQTT 上报驱动enabled 反映管理侧人工开关比如某间教室晚上强制断电就把 enabled 置 0即使设备在线也不允许策略任务下发控制。软删除用 is_deleted 字段还是物理删除空调这种设备台账删除操作很少物理删除完全可以接受。但策略表会被反复调整建议保留 is_deleted 软删除方便恢复误删的策略。我一般只在会被人为误操作的配置类表里加软删除日志和明细表不加因为日志的删除操作是被审计的物理删除更利于排查。最后是 create_time 和 update_time 这两个字段所有核心表都加上。update_time 在建表时设置 ON UPDATE CURRENT_TIMESTAMP排障时能省大量时间。缺这个字段的表查「这个策略什么时候被改过」只能靠应用日志非常被动。4. 核心业务实现温度策略、远程控制与能耗统计的代码落点4.1 设备状态上报与离线判定实现模拟设备通过 MQTT 主题 aircon/{device_no}/report 上报 JSON 数据后端订阅这个主题并更新设备状态。离线判定不是「没收到消息就立刻标离线」而是设置一个阈值窗口。模拟项目X 的设备每 10 秒上报一次离线判定阈值设为 30 秒也就是连续 3 个上报周期没收到消息就认为掉线。核心监听器代码如下Component public class DeviceReportListener { private static final long OFFLINE_THRESHOLD_MS 30_000L; public void onReport(String deviceNo, DeviceReport payload) { Device device deviceMapper.findByNo(deviceNo); if (device null) { log.warn(unknown device: {}, deviceNo); return; } device.setCurrentTemp(payload.getTemperature()); device.setMode(payload.getMode()); device.setStatus(1); device.setLastReportTime(new Date()); deviceMapper.updateStatus(device); energyService.sample(device.getId(), payload.getPowerWatts(), 10); } }逻辑说明收到上报先按业务编号查设备查不到就告警这能第一时间暴露模拟器里设备编号写错的低级失误。更新状态的同时把功率采样交给 energyService职责分离监听器不直接写能耗表。参数说明OFFLINE_THRESHOLD_MS 是离线判定窗口30 秒对应模拟设备 10 秒的上报周期。真实项目中如果设备上报间隔是分钟级这个值要改成间隔的 3 到 5 倍设置太短会导致网络抖动时大量误判离线。sample 方法第三个参数 10 是采样时长秒数要和模拟设备上报间隔保持一致否则能耗明细算出的时长会偏大或偏小。4.2 温度策略调度器定时任务怎么写才不失控温度策略是自动控制的入口。常见做法是每分钟跑一次定时任务扫描所有启用的策略匹配当前时间落在生效区间内的设备然后下发控制指令。Component public class StrategyScheduler { Scheduled(fixedRate 60_000L) public void execute() { ListStrategy enabled strategyMapper.findEnabled(); ListDevice devices deviceMapper.findOnlineDevices(); for (Strategy s : enabled) { if (!s.timeInRange(LocalTime.now())) continue; for (Device d : devices) { if (Math.abs(d.getTargetTemp() - s.getTargetTemp()) 0.05) continue; controlClient.send(d.getDeviceNo(), s.getTargetTemp(), s.getMode()); log.info(strategy {} applied to device {}, s.getId(), d.getDeviceNo()); } } } }逻辑说明先取启用的策略再取在线设备两层循环匹配。设备目标温度已经和策略一致时跳过下发避免每 60 秒对全网设备广播一次控制指令。温度比较用绝对值小于 0.05 判断相等是因为 DECIMAL 字段读出来转成浮点后直接等值比较容易踩精度坑。参数说明fixedRate 为 60 秒表示按固定速率触发不考虑单次执行耗时。如果策略要求秒级响应需要调小间隔但课程设计场景 60 秒足够。这里有一个大坑如果服务以多实例部署Spring 的 Scheduled 会在每个实例上都执行一遍导致重复下发必须加分布式锁。注意Scheduled 在多实例部署下每个实例都会执行课程设计若只部署单实例可以忽略但答辩时要说清这个边界。4.3 批量远程控制的接口设计与幂等处理批量控制接口要从页面勾选多台设备点击「开机 26 度」。接口设计成接收设备编号列表和目标状态逐台下发。难点在于批量操作不能因为一台设备失败而全部回滚也不能因为用户连点两次就重复下发。PostMapping(/devices/batch-control) public BatchResult batchControl(RequestBody BatchControlRequest req) { BatchResult result new BatchResult(); for (String deviceNo : req.getDeviceNos()) { ControlRecord record controlService.controlOnce(deviceNo, req.getTargetTemp(), req.getMode()); if (record.isOk()) { result.addSuccess(deviceNo); } else { result.addFailure(deviceNo, record.getReason()); } } return result; }逻辑说明逐台处理成功和失败分别记录前端拿着结果列表提示用户哪几台失败、失败原因是什么。这种设计比整体成功或整体失败更符合真实运维诉求也方便按失败项单独重试。参数说明幂等处理在 controlOnce 内部完成。控制前先查设备当前状态如果目标和当前一致直接返回「已是最新状态」不产生控制日志也不下发指令。这样用户连点两次提交第二次不会造成重复动作。控制日志在 controlOnce 成功落库action_type 记录为 REMOTE_CONTROLoperator 从登录态里取这条日志是后续审计和排障的重要依据。4.4 能耗统计的聚合查询与报表接口能耗报表接口按日查询时直接查 energy_summary 表GetMapping(/energy/daily) public ListEnergyDailyVO daily(String deviceNo, String startDate, String endDate) { return energyMapper.sumByDeviceAndDateRange(deviceNo, startDate, endDate); }对应的 SQL 在 mapper 里SELECT device_id, stat_date, SUM(total_kwh) AS total_kwh, SUM(run_minutes) AS run_minutes FROM energy_summary WHERE device_id #{deviceNo} AND stat_date BETWEEN #{startDate} AND #{endDate} GROUP BY device_id, stat_date ORDER BY stat_date;逻辑说明报表只聚合汇总表天然就有预聚合的加速效果。device_id 这里传入的是设备主键前端传字符串后端转 Long 时用 Jackson 的字符串反序列化不会触发前边提到的精度问题。参数说明startDate 和 endDate 用闭区间 BETWEEN调用方传日期边界时语义清晰。两个参数必须统一为 YYYY-MM-DD 格式如果前端传了带时间的完整字符串SQL 比较会错位所以接口层要加格式校验或统一格式转换。5. 空调项目落地避坑指南现象、原因与解决方案以下几条都是我在这类项目里遇到过的真实问题每条都按现象、原因、解决三个步骤记录适合在联调阶段对照排查。5.1 设备 ID 传到前端变成 0现象设备列表点击某台设备进行控制后端日志显示查不到设备设备 ID 变成了一串以 0 结尾的数字和库里的主键对不上。原因数据库主键是 BIGINTJSON 序列化后前端拿到 Number 类型一旦 ID 数值较大就触发精度丢失末尾几位变成 0。课程设计数据量小时自增主键不一定触发但主键一旦换成雪花 ID 策略问题必然出现。解决实体类的 ID 字段序列化成字符串。常见做法是给 ID 字段单独提供字符串类型的 getter或者用 Jackson 注解把 Long 输出为字符串。模拟项目X 里我在所有 VO 对象的 ID 字段上加字符串转换前端统一按字符串处理。5.2 设备离线误判心跳间隔与判定阈值没对应现象网络偶发波动时设备在后台被批量标记离线过一会又自动恢复运行日志里反复出现上线、下线记录。原因离线判定阈值写死为 30 秒但模拟设备上报间隔在测试时被从 10 秒改成了 60 秒阈值没有同步调整。设备实际 60 秒才报一次30 秒没收到消息就被判定离线。解决把判定阈值做成配置项和上报周期解耦。上线时核对两个值判定阈值至少要达到上报周期的 3 倍。我在项目里用配置参数承载这两个值并在启动日志里打印当前生效值排查时先看日志确认配置真的生效。5.3 定时任务在多个实例上重复执行现象温度策略每分钟重复下发控制指令设备频繁收到相同的开关命令日志中同一台设备一分钟内出现多条策略记录。原因服务发布到两个实例Scheduled 在每个实例上都触发了执行两个实例同时扫描策略并下发没有任何互斥机制。解决加分布式锁。课程设计阶段可以用数据库乐观锁或 Redis 锁模拟项目X 用 Redis 的 SETNX 实现一个简单锁持有锁的实例才执行调度另一个实例直接跳过。锁的过期时间要大于任务最长执行时间否则锁提前过期两个实例还是会并发执行。5.4 批量控制接口部分失败但没有补偿现象批量控制 20 台设备其中 2 台因为模拟器离线失败前端提示失败但没有任何重试入口用户只能重新勾选再提交一次。原因接口只返回每台设备的结果没有提供「对失败项重试」的能力。对用户来说失败 2 台要重新整批提交体验很差。解决在批量结果里返回失败设备的编号列表并提供一个单独的重试接口接收失败项编号再走一遍同样的逻辑。重试接口同样做幂等判断已成功的设备不会重复操作。这个补偿机制我在模拟项目X 联调后期补上补完之后运维同学操作起来明显顺手。5.5 测试环境正常、部署后 MySQL 报时区错乱现象提前部署时所有数据都正常正式部署后日志开始报时区相关错误能耗按小时聚合的数据全部错位一小时。原因数据库连接串里没有显式指定 serverTimezone应用服务器和数据库服务器的系统时区不一致导致时间字段读写出现偏移。测试环境恰好两个服务器时区一样问题没有暴露。解决数据库连接串统一显式配置 serverTimezone明确指定为应用部署环境的时区偏移值并在建表时明确 DATETIME 字段的语义代码里一律用统一时区转换。这个排查花了整整一个下午最后发现只是连接参数少写了一个配置属于典型的细节翻车。6. 交付前怎么验证模拟设备脚本、巡检与压测的最小方案验证阶段不必做大而全的自动化测试但要覆盖三条链路设备上报链路、策略控制链路、能耗统计链路。我一般写一个模拟设备脚本让它在固定时间点批量发送指定状态再写一个巡检接口定时检查在线设备数、策略命中数、能耗汇总是否与明细一致。模拟设备脚本的启动参数可以设计成--device-count 20 --interval 10 --failure-rate 0.05。这样既能模拟正常上报也能通过 5% 的概率随机制造上报失败用来验证离线判定逻辑是否真的生效。运行时把每个设备的动作打到日志里和策略调度器的日志做交叉比对能快速定位是设备没发还是后端没处理。接口压测不需要引入复杂工具写一个并发请求脚本模拟 10 个用户同时发起批量控制检查返回结果中同一设备是否出现重复控制记录就能验证幂等逻辑是否扛得住并发重复提交。注意压测时要单独开一个开关把模拟设备的接收动作打印成审计日志否则只能靠数据库记录判断定位问题会慢很多。巡检脚本放在最后做每天定时跑一次检查当周能耗汇总与明细的误差率。我习惯把这个误差阈值设为 0.5%超过阈值就告警。调试这个系统的那几周我最大的教训是接口幂等、时间时区、设备离线这几个问题每个单看都是小问题但如果不做巡检它们会攒在交付前一天一起爆发。后来我把这几个检查点固化成了脚本每次交付前跑一遍才安心。希望这些经验能帮你在做空调管理系统或其他带设备接入的软件工程项目时少走弯路祝你顺利交付。本文还有配套的精品资源点击获取