基于Java的机场航班起降与协调管理系统设计

简介基于Java的机场航班起降与协调管理系统毕业设计资料包面向计算机相关专业毕业生及Java Web开发者提供从需求分析、系统设计到编码实现、测试优化与答辩展示的完整项目方案。压缩包约84.93MB涵盖项目报告、答辩PPT、源代码、数据库、截图及部署视频等核心内容文件类型覆盖文档、工程代码、SQL脚本与演示素材目录结构清晰便于按模块对照学习。已有495人浏览学习。系统中涉及MVC设计模式、Servlet/JSP、Spring与MyBatis持久层、MySQL数据库、前端展示及安全权限控制等关键技术通过实际航班调度场景串联各知识点。读者可据此掌握企业级Java Web开发流程理解框架整合与项目部署思路同时借鉴需求文档、数据库设计、答辩讲稿及部署视频快速完成同类课题的搭建、测试与展示。1. 基于 Java 的机场航班起降与协调管理系统毕设选题的第一课机场航班起降与协调管理听起来是离学生很远的民航业务但真把这个题目拆开会发现它是一道非常考验 Java Web 综合功底的毕业设计题。大部分管理类毕设都止步于增删改查而这个系统天然包含航班计划、跑道资源分配、停机位调度、延误协调几条业务线每一条都有状态变化和资源冲突能让你把 Spring Boot、MySQL、事务控制、并发处理这些技术点全部串起来。这套管理系统解决的核心问题就是让航班从计划降落到实际起飞的全过程可跟踪、可调度、可协调。如果你正在选 Java 方向的毕设题不想做那种没有业务深度的纯 CRUD 系统这个方向值得认真研究。整套资料包里的源代码、数据库脚本、项目报告、答辩 PPT 和部署视频恰好覆盖了从开发到交付的全流程。2. 从业务到表结构航班起降协调的数据底座怎么搭先给结论这类系统的成败一半在表结构设计。机场航班起降协调的核心不是“记录航班信息”而是“管理资源在时间轴上的占用”。跑道、停机位、登机口都是有限资源航班是流动的占用方协调的本质就是给每个航班分配合适的资源窗口并处理资源冲突。所以表结构设计必须围绕“资源 时间 状态”三个维度展开。2.1 先分清“航班”和“飞机”实体关系是第一步我一般做这类系统时不先碰代码而是先画实体关系。这里最容易翻车的地方是把“航班”和“飞机”混为一谈。航班是一次运输任务有航班号、起降时间、出发到达城市飞机是一架具体的航空器有机身编号、机型、载客量。一架飞机一天可能执飞多个航班一个航班也可能因为延误换飞机执飞。所以业务建模上航班flight和飞机aircraft必须拆成两个实体中间通过执飞关系关联。资源侧则是跑道runway、停机位gate它们是独立于航班存在的静态资源通过分配关系与航班关联。实体关系梳理下来大概是这样的航班表一次航班的计划信息和实际执行信息包括航班号、航空公司、机型、计划起降时间、实际起降时间、状态、始发地、目的地。飞机表飞机的基础档案包括机身号、机型、最大航程、当前状态。跑道表机场跑道信息包括跑道编号、长度、可用状态。停机位表停机位编号、所属航站楼、是否可用。航班跑道分配表记录某次航班用了哪条跑道、计划占用时段、实际占用时段。航班停机位分配表记录某次航班停靠的停机位和时段。延误记录表记录每次延误发生的时间、原因、延误时长。协调日志表记录人工协调动作比如换跑道、换停机位、调整时刻方便事后回溯。2.2 五张核心表的设计要点字段怎么定才能支撑协调逻辑航班表是整个系统的主线字段设计上要区分“计划时间”和“实际时间”。我见过很多毕设只存一个起降时间结果延误协调根本没法做。计划时间和实际时间必须分开延误时长就是两者差值这是协调系统的数据基础。状态字段建议用 tinyint 存数字枚举不要直接存字符串否则状态流转查询和统计都很别扭。跑道分配表和停机位分配表是资源调度的核心。这两张表不能只存“哪条跑道给了哪个航班”必须带上计划占用开始时间和计划占用结束时间因为跑道是有时间窗口的资源。多条航班不能在同一时间段占用同一条跑道冲突检测就是针对这两张表做时间重叠判断。实际占用开始和结束时间也建议保留用于事后统计跑道利用率。延误记录表要有航班号、延误类型出港/进港/备降、原定时间、修正时间、延误原因、操作人。备降航班是个特殊场景它没有计划时间需要单独标记并插入到当前资源分配队列中参与调度。协调日志表则把人工干预记录留痕答辩时老师问“系统怎么处理突发情况”这张表就是你的底气。2.3 建表 SQL一套能直接落到 MySQL 的 DDL下面给一套我常用的建表 SQL撇开所有外部依赖直接在 MySQL 8.0 里能跑通。你拿到后根据自己项目的包结构调整表前缀即可。CREATE TABLE flight ( id BIGINT AUTO_INCREMENT PRIMARY KEY, flight_no VARCHAR(10) NOT NULL COMMENT 航班号如 CA1234, airline_name VARCHAR(50) NOT NULL COMMENT 航空公司, aircraft_id BIGINT COMMENT 执飞飞机ID关联aircraft表, departure_city VARCHAR(30) NOT NULL COMMENT 始发地, arrival_city VARCHAR(30) NOT NULL COMMENT 目的地, plan_start_time DATETIME NOT NULL COMMENT 计划起飞时间, plan_end_time DATETIME NOT NULL COMMENT 计划降落时间, real_start_time DATETIME COMMENT 实际起飞时间, real_end_time DATETIME COMMENT 实际降落时间, status TINYINT NOT NULL DEFAULT 0 COMMENT 0-待起飞 1-已起飞 2-已降落 3-延误 4-取消, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, update_time DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, deleted TINYINT DEFAULT 0 COMMENT 逻辑删除标记, INDEX idx_status (status), INDEX idx_plan_time (plan_start_time, plan_end_time) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT航班表; CREATE TABLE runway_reservation ( id BIGINT AUTO_INCREMENT PRIMARY KEY, flight_id BIGINT NOT NULL COMMENT 航班ID, runway_id BIGINT NOT NULL COMMENT 跑道ID, plan_start DATETIME NOT NULL COMMENT 计划占用开始时间, plan_end DATETIME NOT NULL COMMENT 计划占用结束时间, real_start DATETIME COMMENT 实际占用开始时间, real_end DATETIME COMMENT 实际占用结束时间, status TINYINT DEFAULT 0 COMMENT 0-占用中 1-已完成 2-已释放, INDEX idx_runway_time (runway_id, plan_start, plan_end) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT跑道资源占用表; CREATE TABLE delay_record ( id BIGINT AUTO_INCREMENT PRIMARY KEY, flight_id BIGINT NOT NULL COMMENT 航班ID, delay_type TINYINT NOT NULL COMMENT 1-出港延误 2-进港延误 3-备降, original_time DATETIME NOT NULL COMMENT 原定时间, adjusted_time DATETIME NOT NULL COMMENT 调整后时间, delay_minutes INT NOT NULL COMMENT 延误分钟数, reason VARCHAR(255) COMMENT 延误原因, operator VARCHAR(50) COMMENT 操作人, create_time DATETIME DEFAULT CURRENT_TIMESTAMP ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT延误记录表;这套 DDL 里有几个设计点值得说明。第一时间字段统一用 DATETIME 而不是 TIMESTAMP因为 TIMESTAMP 在 MySQL 里有时区转换问题国内开发环境如果没配好时区前端展示会出现 8 小时偏差这是高频踩坑点。第二status 用 TINYINT 存数字枚举配合注释比直接存“已起飞”这种字符串要节省空间查询效率也高。第三逻辑删除字段 deleted 是给数据安全留后路毕设答辩时老师问“删除数据怎么处理”可以用这个字段回答软删除方案。第四联合索引 idx_runway_time 落在冲突检测的查询路径上跑道分配时按跑道 时间范围过滤这个索引能极大减少扫描行数。注意实际项目里还会补充 aircraft、runway、gate 几张基础表结构比较简单字段就是编号、名称、状态、备注这里不占篇幅。你要关注的是 flight 和 runway_reservation 这两张表协调系统的核心逻辑全部围绕它们展开。3. 用 Spring Boot 把调度流程串起来状态机与核心接口表结构落定后下一步就是把业务流程变成代码逻辑。机场航班起降与协调管理系统在 Spring Boot 里最值得写透的是航班状态机和跑道分配算法。前者让航班生命周期可视化后者是系统“协调”能力的直接体现。3.1 航班状态机起降流程的状态定义与流转条件航班状态不能只是数据库里一个字段它应该有清晰的流转边界。状态机设计好了业务逻辑就不会乱写。常见做法是定义一个枚举类把所有状态和允许的流转方向集中管理。public enum FlightStatus { SCHEDULED(0, 待起飞), DEPARTED(1, 已起飞), ARRIVED(2, 已降落), DELAYED(3, 延误), CANCELLED(4, 取消); private final int code; private final String desc; FlightStatus(int code, String desc) { this.code code; this.desc desc; } // 状态流转校验返回true表示允许从from流转到to public static boolean canTransform(int from, int to) { if (from SCHEDULED.code to DEPARTED.code) return true; if (from SCHEDULED.code to DELAYED.code) return true; if (from DEPARTED.code to ARRIVED.code) return true; if (from DELAYED.code to DEPARTED.code) return true; if (from SCHEDULED.code to CANCELLED.code) return true; if (from DELAYED.code to CANCELLED.code) return true; return false; } }逻辑说明canTransform 静态方法集中定义了状态机的合法流转路径。比如待起飞只能流转到已起飞、延误或取消延误状态可以恢复为待起飞也可以取消已起飞只能流转到已降落不能倒退为待起飞。这套约束的价值在于所有 Controller 和 Service 在改状态时都调用这个校验非法流转直接在入口被拦截不会污染数据。参数说明这里的状态码与数据库 tinyint 字段一一对应避免在代码里到处写魔数。desc 字段用于接口返回给前端做下拉框或标签展示。如果后续要扩展状态比如“登机中”“滑行中”只需要在枚举里加一项并在 canTransform 中补充合法流转路径。3.2 跑道分配先到先服务加优先级修正的朴素实现跑道分配是这个系统的技术亮点。真实机场的跑道分配涉及气象、机型、航空公司时刻表等多种因素但毕设系统做到先到先服务再叠加优先级修正就已经能展示完整的协调逻辑了。核心算法思路是按计划起飞时间排序依次为每个航班找一条当前时段空闲的跑道如果航班有延误或属于备降航班在排序时获得优先级加成。public RunwayReservation allocateRunway(Long flightId) { Flight flight flightMapper.selectById(flightId); // 1. 查询该时间段所有已占用的跑道 ListRunwayReservation occupied reservationMapper .selectOccupiedByTime(flight.getPlanStartTime(), flight.getPlanEndTime()); // 2. 找出被占用的跑道ID集合 SetLong occupiedRunwayIds occupied.stream() .map(RunwayReservation::getRunwayId) .collect(Collectors.toSet()); // 3. 查询所有可用跑道过滤掉被占用的 ListRunway available runwayMapper.selectAvailable() .stream() .filter(r - !occupiedRunwayIds.contains(r.getId())) .collect(Collectors.toList()); if (available.isEmpty()) { throw new BusinessException(当前时段无可用跑道建议调整航班时刻); } // 4. 优先选择空闲时间最长的跑道简单轮转策略 Runway target available.get(0); RunwayReservation reservation new RunwayReservation(); reservation.setFlightId(flightId); reservation.setRunwayId(target.getId()); reservation.setPlanStart(flight.getPlanStartTime()); reservation.setPlanEnd(flight.getPlanEndTime()); reservation.setStatus(0); reservationMapper.insert(reservation); return reservation; }逻辑说明这个方法的核心是先查冲突再分配。第 1 步先把当前航班计划时间范围内的所有跑道占用记录查出来得到“哪些跑道在这个时间段不能再用”第 3 步从全部跑道中剔除这些被占用的跑道第 4 步按可用跑道列表顺序选择。这是典型的“时间窗口冲突检测 资源匹配”流程也是面试时讲得清楚的算法思路。参数说明selectOccupiedByTime 需要传入计划开始和结束时间SQL 层面对应跑道占用表的 plan_start 和 plan_end 做时间段重叠判断。重叠条件在 SQL 里写成plan_start #{endTime} AND plan_end #{startTime}这就是区间重叠的标准判定式。available 列表为空时要抛异常因为协调系统不能静默失败必须暴露冲突让上层去走人工调整流程。3.3 核心 REST 接口与前端联动方式接口设计上不需要做得很重把协调流程的关键动作暴露给前端即可。我一般会这样设计接口路径方法功能关键参数/api/flight/listGET分页查询航班列表pageNum, pageSize, status, flightNo/api/flight/detailGET查询航班详情及资源分配flightId/api/flight/createPOST新建航班flight 对象/api/flight/changeStatusPOST航班状态流转flightId, targetStatus/api/runway/allocatePOST手动触发跑道分配flightId/api/runway/releasePOST释放跑道资源reservationId/api/delay/recordPOST记录延误并调整计划flightId, delayMinutes, reason状态流转是异步动作前端调 changeStatus 接口时后端要先做状态机校验再做资源释放或占用更新。比如航班从“已起飞”流转到“已降落”系统要自动释放占用的跑道和停机位并把实际降落时间写回航班表。这些联动动作放在同一个事务里避免出现状态变了但资源没释放的数据不一致问题。4. 协调与冲突检测让系统真正“管起来”的关键逻辑如果只做增删改查和状态流转这个系统还没有灵魂。机场协调管理最核心的价值是当两个航班同时申请同一时间段、同一条跑道时系统能精准识别冲突并给出可操作的协调建议。这一章把冲突检测、延误传播两个重点讲透。4.1 两阶段冲突检测时间重叠与资源占用冲突检测分两阶段展开。阶段一是资源时间窗重叠检测判断新航班要占用的时间段是否与已有分配记录冲突阶段二是目标航班自身的时间链校验判断同一航班的前后节点是否自洽。比如一个航班计划 10:00 降落却要在 10:30 占用跑道起飞这就属于航班内部逻辑冲突必须拦截。public ListConflictInfo checkConflict(Flight newFlight) { ListConflictInfo conflicts new ArrayList(); // 阶段一检测跑道时间窗重叠 ListRunwayReservation overlapReservations reservationMapper .selectOverlap(newFlight.getPlanStartTime(), newFlight.getPlanEndTime()); for (RunwayReservation res : overlapReservations) { Flight occupyFlight flightMapper.selectById(res.getFlightId()); conflicts.add(new ConflictInfo( occupyFlight.getFlightNo(), 跑道资源冲突, res.getPlanStart() ~ res.getPlanEnd() )); } // 阶段二检测同航班前后时间自洽性 if (newFlight.getArrivalCity() null newFlight.getPlanStartTime() .isAfter(newFlight.getPlanEndTime())) { conflicts.add(new ConflictInfo(newFlight.getFlightNo(), 时间逻辑错误, 计划起飞晚于计划降落)); } return conflicts; }逻辑说明阶段一直接针对跑道占用表做重叠查询只要返回结果不为空说明当前时段有跑道被其他航班占用冲突就摆在明面上。阶段二比较特殊出港航班的计划开始时间就是起飞时间进港航班的计划开始时间通常写降落时间两者不能倒挂。这个校验在新建航班时调用也在调整时刻时调用能挡住大部分人工误操作。参数说明selectOverlap 的查询条件同样使用plan_start #{endTime} AND plan_end #{startTime}与跑道分配用的判定式一致。这样做的好处是一个 SQL 既服务于分配查询也服务于冲突检测业务口径统一。4.2 延误传播、备降处理与人工干预兜底延误是这个系统最常见的异常场景。一次出港延误往往不是孤立的它可能导致后续航班顺延、目标跑道时段被挤占、甚至下游航班登机口冲突。我一般用延误传播链来处理航班 A 延误后先查它占用的跑道时段是否影响了后续航班再查共用同一停机位的后续航班逐级更新计划时间并把每次调整写入延误记录表。备降航班则需要快速插入当前资源队列系统给它标记最高优先级在跑道分配排序中置顶。人工干预是协调系统不可缺失的兜底。自动分配结果未必最优比如天气原因导致某条跑道临时关闭算法无法感知这个外部信息协调员需要手动把已分配航班转移到其他跑道。所以系统要保留人工改派接口允许指定航班、指定跑道、指定时间段强制分配同时自动释放原分配记录。答辩时这一块就是你系统健壮性的证明。4.3 并发提交下的数据一致性事务与乐观锁机场协调系统是典型的多用户并发场景协调员同时处理多个航班的调配请求如果不对并发做控制跑道超卖马上就会发生。常见的做法是给跑道占用表加版本号字段更新时带上版本号做乐观锁校验。另外所有状态变更和资源分配操作都要放在同一个事务里要么全部成功要么全部回滚。Transactional(rollbackFor Exception.class) public void changeFlightStatusWithResource(Long flightId, int targetStatus) { Flight flight flightMapper.selectById(flightId); if (!FlightStatus.canTransform(flight.getStatus(), targetStatus)) { throw new BusinessException(非法状态流转); } if (targetStatus FlightStatus.ARRIVED.getCode()) { releaseRunway(flightId); releaseGate(flightId); } flight.setStatus(targetStatus); flight.setRealEndTime(LocalDateTime.now()); flightMapper.updateById(flight); }逻辑说明这个方法是航班降落时释放资源与更新状态的事务性操作。Transactional 保证释放跑道、释放停机位、更新航班状态三个动作要么全部提交要么全部回滚。如果先释放了跑道但更新状态时抛异常事务回滚后资源仍然处于占用状态不会出现“状态没变、资源却释放了”的脏数据。目标状态为已降落时实际降落时间被同步写入 real_end_time这是后续统计准点率的数据来源。参数说明事务的 rollbackFor 设置为 Exception.class是捕获所有异常避免运行时异常没有被拦截导致事务没有回滚。如果你在多线程环境测试并发分配可以给 runway_reservation 表增加 version 字段每次 update 语句带上WHERE version #{oldVersion}更新成功后 version 加 1冲突时更新影响行数为 0再提示协调员重新调度。5. 从开发到交付的避坑清单5 个让系统翻车的真实问题这套系统开发链路长踩坑点集中在小细节上。下面直接列五条我见过多次的真实问题每条按现象、原因、解决写清楚。5.1 时间字段在页面上差了 8 小时现象航班列表页显示的计划起飞时间比数据库里实际存储的时间晚了 8 个小时排查半天发现是时区问题。原因MySQL 连接串里的 serverTimezone 没有设置或者服务器时区与 JVM 时区不一致DATETIME 字段被 JDBC 驱动做了时区转换。解决在数据库连接 URL 上显式加serverTimezoneAsia/ShanghaiuseLegacyDatetimeCodefalse同时检查 MySQL 全局时区设置用SET GLOBAL time_zone 8:00;统一。5.2 跑道分配超卖两个航班同时占用了同一条跑道现象并发测试时两个协调员同时为不同航班分配跑道接口都返回成功数据库里出现同一条跑道同一时间段的重复记录。原因跑道分配方法没有加锁也没有乐观锁机制两个请求同时通过了冲突检测并执行插入。解决在跑道占用表增加 version 字段插入前先做一次SELECT ... FOR UPDATE行级锁查询或者分配接口整体加分布式锁。毕设层面用行级锁已经足够。5.3 航班列表页加载越来越慢N1 查询现象航班列表接口返回 200 条数据花了 6 秒数据库连接不断被消耗。原因MyBatis 中查询航班列表后又循环查询每架飞机和每条分配记录产生 N1 次查询。解决改成一条连表 SQL 一次性查出航班关联的飞机名称、跑道编号、停机位编号或者在 Service 层用批量查询收集 ID 后一次 in 查询补齐。推荐前者SQL 写起来直观也方便后期加筛选条件。5.4 状态流转更新后前端还显示旧状态现象协调员在 A 页面把航班状态改成已起飞B 页面下拉列表里还是待起飞刷新后才正确。原因接口返回后前端本地缓存了旧状态对象没有重新拉取最新列表。解决状态变更接口返回最新航班对象前端用返回值直接替换当前对象而不是重新请求列表。如果状态变更涉及资源分配把分配结果一并返回前端可以立即展示跑道编号和时段。5.5 部署后中文乱码Tomcat 与 MySQL 编码不一致现象本机运行正常部署到服务器后航班名称和城市名全是问号。原因服务器 Tomcat 默认编码不是 UTF-8MySQL 表虽然建了 utf8mb4但连接层没指定字符集。解决在连接 URL 上加characterEncodingutf8mb4在 Tomcat 的 server.xml 连接器配置 URIEncodingUTF-8确保从 HTTP 请求到数据库全链路统一 UTF-8 编码。6. 把项目从“能跑”变成“能答辩”演示数据与验证技巧6.1 造一套有冲突、有延误、有备降的演示数据我建议准备三条业务线用于演示。第一条是正常航班线从待起飞到已降落走完整流程展示状态流转和资源自动释放。第二条是冲突协调线造两个航班计划时间重叠展示跑道分配推荐和冲突提示。第三条是延误与备降线给一个航班记录 40 分钟延误触发后续航班顺延调整再标记一条备降航班插入队列。这三条数据能让答辩老师在五分钟内看到一个有业务逻辑的完整故事。造数据的方式有两种手工在管理页面逐条录入或者写一个测试数据构造函数直接向数据库插入。推荐后者因为可以精确控制时间字段方便为冲突场景制造重叠窗口。展示时优先从航班列表页开始讲先让老师看到整体状态再点进某个延误航班看协调过程。6.2 接口自动校验守住状态机和冲突检测逻辑我一般会给核心逻辑写 JUnit 测试不需要覆盖全部接口但状态机和冲突检测必须有测试保护。写一个状态流转测试断言待起飞可以流转到已起飞但已降落不能流转到待起飞写一个冲突检测测试插入两条重叠时段的跑道占用记录断言冲突列表返回两条结果。这些测试在答辩时可以现场跑一遍比口头描述逻辑更有说服力。测试数据要通过 BeforeEach 清理或使用独立测试库避免测试数据污染演示环境。6.3 答辩讲解顺序建议从业务痛点进入答辩时不要一上来就讲技术架构先讲清楚“机场同时有几十架航班起降跑道资源怎么分配、延误了怎么协调”这个业务场景然后展示系统中的航班列表、跑道时间轴、延误记录三个核心页面最后再展开讲状态机和冲突检测的代码实现。我自己的教训是第一版答辩讲稿满篇都是框架名词老师问了个“跑道占用时间重叠怎么判断”当场没答好。后来改成从冲突检测 SQL 的区间重叠条件讲起老师反而追问了索引优化这就是加分点。希望帮到你。本文还有配套的精品资源点击获取