第一次blog作业 电梯调度分析

前言

这是第一次java大作业，刚开始对他的预想要好很多，特别是刚开始看到只有三道题时，我认为肯定是可以完成的，但因为老师多次提醒说很难要早点开始，我也没太掉以轻心，但确实没太放在心上，但是当我看到直到第三天都没人拿到满分时，我意识到事情的不简单，于是开始认真分析题目认真梳理思路，但好像为时已晚直到最后也没写出来。
考点：主要是对电梯调度题目进行代码迭代，第一次是单类，设置单一类封装所有功能，考察输入格式及无效请求，考察调度算法，关键实现移动时实时检查当前楼层是否需要停靠，第二次是多类分解，拆分类职责，关键实现控制器协调电梯和队列，解耦状态管理与调度逻辑，第三次引入乘客类，外部请求<源,目的>转换为内部请求（目的楼层加入内部队列）关键实现乘客类分离请求的发起者和目的，队列类需区分内外请求优先级。
题量及难度：其实要认真说的话毕竟是大作业一周只有一次题量并不算太大，但难度的话就比较大，毕竟刚接触java本来对于发就不太熟悉又是第一次接触大作业，但我相信有了这次经验及教训以后肯定会越来越好的。

设计与分析

题目

7-34 NCHU_单部电梯调度程序

分数 70
中等
作者 段喜龙
单位 南昌航空大学
设计一个电梯类，具体包含电梯的最大楼层数、最小楼层数（默认为1层）当前楼层、运行方向、运行状态，以及电梯内部乘客的请求队列和电梯外部楼层乘客的请求队列，其中，电梯外部请求队列需要区分上行和下行。
电梯运行规则如下：电梯默认停留在1层，状态为静止，当有乘客对电梯发起请求时（各楼层电梯外部乘客按下上行或者下行按钮或者电梯内部乘客按下想要到达的楼层数字按钮），电梯开始移动，当电梯向某个方向移动时，优先处理同方向的请求，当同方向的请求均被处理完毕然后再处理相反方向的请求。电梯运行过程中的状态包括停止、移动中、开门、关门等状态。当电梯停止时，如果有新的请求，就根据请求的方向或位置决定移动方向。电梯在运行到某一楼层时，检查当前是否有请求（访问电梯内请求队列和电梯外请求队列），然后据此决定移动方向。每次移动一个楼层，检查是否有需要停靠的请求，如果有，则开门，处理该楼层的请求，然后关门继续移动。
使用键盘模拟输入乘客的请求，此时要注意处理无效请求情况，例如无效楼层请求，比如超过大楼的最高或最低楼层。还需要考虑电梯的空闲状态，当没有请求时，电梯停留在当前楼层。
请编写一个Java程序，设计一个电梯类，包含状态管理、请求队列管理以及调度算法，并使用一些测试用例，模拟不同的请求顺序，观察电梯的行为是否符合预期，比如是否优先处理同方向的请求，是否在移动过程中处理顺路的请求等。为了降低编程难度，不考虑同时有多个乘客请求同时发生的情况，即采用串行处理乘客的请求方式（电梯只按照规则响应请求队列中当前的乘客请求，响应结束后再响应下一个请求），具体运行规则详见输入输出样例。

输入格式:
第一行输入最小电梯楼层数。
第二行输入最大电梯楼层数。
从第三行开始每行输入代表一个乘客请求。

电梯内乘客请求格式：<楼层数>
电梯外乘客请求格式：<乘客所在楼层数,乘梯方向>，其中，乘梯方向用UP代表上行，用DOWN代表下行（UP、DOWN必须大写）。
当输入“end”时代表输入结束（end不区分大小写）。
输出格式:
模拟电梯的运行过程，输出方式如下：
运行到某一楼层（不需要停留开门），输出一行文本：
Current Floor: 楼层数 Direction: 方向
运行到某一楼层（需要停留开门）输出两行文本：
Open Door # Floor 楼层数
Close Door
输入样例:
在这里给出一组输入。例如：

1
20
❤️,UP>
<5>
<6,DOWN>
<7>
<3>
end
输出样例:
在这里给出相应的输出。例如：

Current Floor: 1 Direction: UP
Current Floor: 2 Direction: UP
Current Floor: 3 Direction: UP
Open Door # Floor 3
Close Door
Current Floor: 4 Direction: UP
Current Floor: 5 Direction: UP
Open Door # Floor 5
Close Door
Current Floor: 6 Direction: UP
Current Floor: 7 Direction: UP
Open Door # Floor 7
Close Door
Current Floor: 6 Direction: DOWN
Open Door # Floor 6
Close Door
Current Floor: 5 Direction: DOWN
Current Floor: 4 Direction: DOWN
Current Floor: 3 Direction: DOWN
Open Door # Floor 3
Close Door
代码长度限制
16 KB
时间限制
400 ms
内存限制
64 MB
栈限制
8192 KB

7-37 NCHU_单部电梯调度程序（类设计）

分数 50
较难
作者 段喜龙
单位 南昌航空大学
对之前电梯调度程序进行迭代性设计，目的为解决电梯类职责过多的问题，类设计要求遵循单一职责原则（SRP），要求必须包含但不限于设计电梯类、乘客请求类、队列类以及控制类，具体设计可参考如下类图。

电梯运行规则与前阶段单类设计相同，但要处理如下情况：
• 乘客请求楼层数有误，具体为高于最高楼层数或低于最低楼层数，处理方法：程序自动忽略此类输入，继续执行
• 乘客请求不合理，具体为输入时出现连续的相同请求，例如<3><3><3>或者<5,DOWN><5,DOWN>，处理方法：程序自动忽略相同的多余输入，继续执行，例如<3><3><3>过滤为<3>
注意：本次作业类设计必须符合如上要求（包含但不限于乘客请求类、电梯类、请求队列类及控制类，其中控制类专门负责电梯调度过程），凡是不符合类设计要求此题不得分，另外，PTA得分代码界定为第一次提交的最高分代码（因此千万不要把第一次电梯程序提交到本次题目中测试）。
输入格式:
第一行输入最小电梯楼层数。
第二行输入最大电梯楼层数。
从第三行开始每行输入代表一个乘客请求。
• 电梯内乘客请求格式：<楼层数>
• 电梯外乘客请求格式：<乘客所在楼层数,乘梯方向>，其中，乘梯方向用UP代表上行，用DOWN代表下行（UP、DOWN必须大写）。
• 当输入“end”时代表输入结束（end不区分大小写）。
输出格式:
模拟电梯的运行过程，输出方式如下：
• 运行到某一楼层（不需要停留开门），输出一行文本：
Current Floor: 楼层数 Direction: 方向
• 运行到某一楼层（需要停留开门）输出两行文本：
Open Door # Floor 楼层数
Close Door
输入样例1:
在这里给出一组输入。例如：
1
20
❤️,UP>
<5>
<6,DOWN>
<7>
<3>
end
输出样例1:
在这里给出相应的输出。例如：
Current Floor: 1 Direction: UP
Current Floor: 2 Direction: UP
Current Floor: 3 Direction: UP
Open Door # Floor 3
Close Door
Current Floor: 4 Direction: UP
Current Floor: 5 Direction: UP
Open Door # Floor 5
Close Door
Current Floor: 6 Direction: UP
Current Floor: 7 Direction: UP
Open Door # Floor 7
Close Door
Current Floor: 6 Direction: DOWN
Open Door # Floor 6
Close Door
Current Floor: 5 Direction: DOWN
Current Floor: 4 Direction: DOWN
Current Floor: 3 Direction: DOWN
Open Door # Floor 3
Close Door
输入样例2:
在这里给出一组输入。例如：
1
20
❤️,UP>
❤️,UP>
<5>
<5>
<5>
<6,DOWN>
<7>
<7>
<3>
<22,DOWN>
<5,DOWN>
<30>
END
输出样例2:
在这里给出相应的输出。例如：
Current Floor: 1 Direction: UP
Current Floor: 2 Direction: UP
Current Floor: 3 Direction: UP
Open Door # Floor 3
Close Door
Current Floor: 4 Direction: UP
Current Floor: 5 Direction: UP
Open Door # Floor 5
Close Door
Current Floor: 6 Direction: UP
Current Floor: 7 Direction: UP
Open Door # Floor 7
Close Door
Current Floor: 6 Direction: DOWN
Open Door # Floor 6
Close Door
Current Floor: 5 Direction: DOWN
Open Door # Floor 5
Close Door
Current Floor: 4 Direction: DOWN
Current Floor: 3 Direction: DOWN
Open Door # Floor 3
Close Door
代码长度限制
16 KB
时间限制
400 ms
内存限制
64 MB
栈限制
8192 KB

对之前电梯调度程序再次进行迭代性设计，加入乘客类（Passenger），取消乘客请求类，类设计要求遵循单一职责原则（SRP），要求必须包含但不限于设计电梯类、乘客类、队列类以及控制类，具体设计可参考如下类图。

电梯运行规则与前阶段相同，但有如下变动情况：

乘客请求输入变动情况：外部请求由之前的<请求楼层数,请求方向>修改为<请求源楼层，请求目的楼层>
对于外部请求，当电梯处理该请求之后（该请求出队），要将<请求源楼层，请求目的楼层>中的请求目的楼层加入到请求内部队列(加到队尾）
注意：本次作业类设计必须符合如上要求（包含但不限于设计电梯类、乘客类、队列类以及控制类），凡是不符合类设计要求此题不得分，另外，PTA得分代码界定为第一次提交的最高分代码（因此千万不要把第一次及第二次电梯程序提交到本次题目中测试）。

输入格式:
第一行输入最小电梯楼层数。
第二行输入最大电梯楼层数。
从第三行开始每行输入代表一个乘客请求。

电梯内乘客请求格式：<楼层数>
电梯外乘客请求格式：<请求源楼层，请求目的楼层>，其中，请求源楼层表示乘客发起请求所在的楼层，请求目的楼层表示乘客想要到达的楼层。
当输入“end”时代表输入结束（end不区分大小写）。
输出格式:
模拟电梯的运行过程，输出方式如下：

运行到某一楼层（不需要停留开门），输出一行文本：
Current Floor: 楼层数 Direction: 方向
运行到某一楼层（需要停留开门）输出两行文本：
Open Door # Floor 楼层数
Close Door
输入样例1:
在这里给出一组输入。例如：

1
20
<5,4>
<5>
<7>
end
输出样例1:
在这里给出相应的输出。例如：

Current Floor: 1 Direction: UP
Current Floor: 2 Direction: UP
Current Floor: 3 Direction: UP
Current Floor: 4 Direction: UP
Current Floor: 5 Direction: UP
Open Door # Floor 5
Close Door
Current Floor: 6 Direction: UP
Current Floor: 7 Direction: UP
Open Door # Floor 7
Close Door
Current Floor: 6 Direction: DOWN
Current Floor: 5 Direction: DOWN
Open Door # Floor 5
Close Door
Current Floor: 4 Direction: DOWN
Open Door # Floor 4
Close Door
输入样例2:
在这里给出一组输入。例如：

1
20
<5,9>
<8>
<9,3>
<4>
<2>
end
输出样例2:
在这里给出相应的输出。例如：

Current Floor: 1 Direction: UP
Current Floor: 2 Direction: UP
Current Floor: 3 Direction: UP
Current Floor: 4 Direction: UP
Current Floor: 5 Direction: UP
Open Door # Floor 5
Close Door
Current Floor: 6 Direction: UP
Current Floor: 7 Direction: UP
Current Floor: 8 Direction: UP
Open Door # Floor 8
Close Door
Current Floor: 9 Direction: UP
Open Door # Floor 9
Close Door
Current Floor: 8 Direction: DOWN
Current Floor: 7 Direction: DOWN
Current Floor: 6 Direction: DOWN
Current Floor: 5 Direction: DOWN
Current Floor: 4 Direction: DOWN
Open Door # Floor 4
Close Door
Current Floor: 3 Direction: DOWN
Current Floor: 2 Direction: DOWN
Open Door # Floor 2
Close Door
Current Floor: 3 Direction: UP
Current Floor: 4 Direction: UP
Current Floor: 5 Direction: UP
Current Floor: 6 Direction: UP
Current Floor: 7 Direction: UP
Current Floor: 8 Direction: UP
Current Floor: 9 Direction: UP
Open Door # Floor 9
Close Door
Current Floor: 8 Direction: DOWN
Current Floor: 7 Direction: DOWN
Current Floor: 6 Direction: DOWN
Current Floor: 5 Direction: DOWN
Current Floor: 4 Direction: DOWN
Current Floor: 3 Direction: DOWN
Open Door # Floor 3
Close Door
代码长度限制
16 KB
时间限制
400 ms
内存限制
64 MB
栈限制
8192 KB

分析

源码报表分析图

图表分析

总行数：235
类数量：1（Main类）
方法数量：10
注释覆盖率：8.1%（低于推荐的15%-20%）
关键问题
单一类设计：所有功能集中在Main类中，违反单一职责原则（SRP）。
方法过长：平均每个方法含12.4条语句，部分方法逻辑过于复杂。
方法复杂度
最高复杂度：6（Main.main()方法）
位置：第199行
语句数：19
块嵌套深度：5
方法调用：16次
平均复杂度：6.00（理想值应≤4）
块嵌套深度分布
深度 语句数 占比 问题描述
0-1 72 53.7% 基础逻辑，合理
2-3 53 39.6% 中等嵌套，可优化
4-5 9 6.7% 过高，需重构
分支语句占比：26.9%
表明代码依赖大量if-else分支，可能增加维护难度。
设计缺陷
所有功能集中在Main类，未拆分职责（如电梯状态、请求队列、调度逻辑）。
高耦合度：方法间调用频繁，但均在同一类内。
代码可读性
注释覆盖率低（8.1%），关键逻辑缺乏说明。
深层嵌套（最深5层）和复杂条件分支影响理解。
维护风险
Main.main()方法复杂度高，修改易引入错误。
新增能时代码扩展性差。
2.
代码结构指标
类数量：5个（符合单一职责原则的初步拆分）
平均每个类包含5.6个方法（职责分配较合理）
平均每个方法包含3.07条语句（方法长度控制良好）
复杂度指标
最大复杂度：7
平均复杂度：1.75（整体控制较好）
最大嵌套深度：5层（存在过度嵌套问题）
平均嵌套深度：2.01（多数代码结构合理）
可维护性指标
注释覆盖率：仅4.3%（远低于15%的推荐标准）
分支语句比例：11.9%（条件逻辑偏多）
深度嵌套问题
存在深度达5层的嵌套代码块
典型场景：多层if-else或循环嵌套
影响：可读性差，维护困难，测试覆盖率难以保证
注释严重不足
关键算法和复杂逻辑缺乏说明
方法功能描述缺失
影响：新成员理解成本高，维护效率低
复杂方法问题
存在1个复杂度达7的方法
可能包含过多职责或复杂条件判断

小结

由于代码复杂度过高导致每次运行都会导致超时，这也是我第一次代码没过的主要原因，后续我的改正纠错就放在了一些基础语法以及算法方面但始终改不对，后来仔细想了想，我觉得并不在这上面，最大的问题还是题目的逻辑问题，我对于电梯的运行规则还是没有分析清楚才会导致中间有很多循环的嵌套导致代码复杂度太高太高，运行超时。
后面对类进行分析时对类图所示方法及结构存在模糊等情况代码出现许多编译错误

踩坑心得

我刚开始写第一次作业时写完给我报的是运行错误，我以为只是一些循环存在问题，还在沾沾自喜，殊不知噩梦已经悄然降临，我改啊改，咋改都改不完，后来才发现是电梯运行的逻辑问题，好不容易改完了又会发现是答案错误等各种问题
还有就是一些代码的逻辑问题，这个要具题目而定，就比如电梯逻辑要分清楚内外部请求

总结

全文总结

这三次大作业我基本上都没得到分，有一个很大的原因就是进度跟不上，自从第一次没有写出来我觉得后面就是很难的事情了，因为要在上一次的基础上进行迭代，所以说要先写上次的，但是等上次写完后就没有时间写这次的了，就会导致每一次都拿不到分数，所以说要从第一次题目集就认真分析不能拉下任何一次。
经过这几次的代码迭代我对面向对象这个概念得到了更加深入的理解，对单一职责以及封装得到了很好的应用，我做题前会先开始进行题目分析，把所有的功能职责进行划分，对每个类的属性及功能进行明确定义，还有就是对正则表达式进行应用，在运用中熟练，在熟练中应用，我的代码写起来高效很多，主要是在字符串的处理问题上面，我还学会了在PowerDesigner上画类图 ，这对于类的职责划分有很大帮助，并且能很好的锻炼我的动手能力，其次画类图的同时还能考察我对每个类之间的关系的理解，需要在类图中标注出来每个类之间的关系，我还学会了使用SourceMonitor,在上面分析我的代码。
在心理方面我们还要有强大的心态，要清楚大作业每一次都会花费我们很多时间和精力，我们在写的过程中会遇到各种各样的问题，一定要有强大的内心，仔细阅读题干和要求，说不定就是一个小的知识点就会导致前功尽弃。

建议

在大作业方面，我觉得老师做的还是很到位的无论是在时间延迟方面还是在群中进行题目分析题目逻辑讲解都是很负责的，但是在测试点的设置方面可以循序渐进，这样不会说一次满分或零分的现象，还有就是测试点不过不知道是哪方面的问题
在实验系统方面，这个系统很脆弱，第一次写到半夜12点我点了一下保存他给我显示什么系统错误直接大退，然后全部拜拜白写，真的很崩溃，第二次我写完但是文件名错了，我问了一圈但是他跟我说竟然无法更改我竟然又要从写，我真的很不敢相信，还有就是系统的换行对其问题，没法系统对其，只能用肉眼看并且非常不准确伤眼睛，真的希望能好好改进这个系统.