电梯调度问题

电梯调度问题
一．第三次作业
1.目标
对之前电梯调度程序再次进行迭代性设计，加入乘客类（Passenger），取消乘客请求类。新增：1.乘客请求输入变动情况：外部请求由之前的<请求楼层数,请求方向>修改为<请求源楼层，请求目的楼层> 2.对于外部请求，当电梯处理该请求之后（该请求出队），要将<请求源楼层，请求目的楼层>中的请求目的楼层加入到请求内部队列(加到队尾）

2.方法分析

分析：迭代后，inOrder类和outOrder类被统一为Passenger类，使代码更简洁，类似重复的方法也被删除。此外，Requests类中的addOuterRequest和addInnerRequest方法在添加请求时，对请求的楼层进行了边界检查，确保请求的楼层在合法范围内。同时，还对连续重复的请求进行了判断，避免重复添加相同的请求，提高了数据的准确性。
3.代码分析

Project Directory：项目目录，显示代码所在路径。
Project Name：项目名称，显示为乱码。
Checkpoint Name：检查点名称，为 “Baseline” 。
File Name：文件名是Main.java 。
Lines：代码行数为 304 行（* 可能含空行等 ）。
Statements：语句数量为 181 条 。
Percent Branch Statements：分支语句占比 21.0% ，说明代码中条件判断等分支逻辑占比情况。
Method Call Statements：方法调用语句数量为 102 条 。
Percent Lines with Comments：含注释的代码行占比 15.1% ，反映代码注释情况。
Classes and Interfaces：类和接口数量共 3 个 。
Methods per Class：每个类平均方法数为 9.67 个 。
Average Statements per Method：每个方法平均语句数为 5.28 条 。
Line Number of Most Complex Method：最复杂方法所在行号为 232 行 。
Name of Most Complex Method：最复杂方法是Control.runDianti() 。
Maximum Complexity：最大复杂度为 6 ，体现方法逻辑复杂程度。
Line Number of Deepest Block：最深嵌套代码块所在行号为 26 行 。
Maximum Block Depth：最大代码块深度为 4 ，表示代码中嵌套结构的最深层次。
Average Block Depth：平均代码块深度为 1.51 。
Average Complexity：平均复杂度为 1.81 。
分析：相较于第二次作业，第三次作业的最大复杂度终于降低，整体都在雷达图的绿色范围内，同时注释量也保持在了占比 15.1% 。
4.Bug分析
未发现bug。第三次作业终于完全通过了测试点。在又一次经过几十次测试后发现，在删除两个队列头部的已经到达的楼层时，外部命令需要考虑方向与电梯运动方向相同才应删除，如电梯执行内部命令向上到达5楼后，两个队列头部分别为<5><5,UP>时两者都被删除，而<5><5,DOWN>的情况不删除外部的<5,DOWN>。然而这个逻辑并没有在最初给出的电梯运行逻辑里体现
5.总结与反思
相较于第二次作业，第三次作业主要在按要求修改之外，显著降低了代码的最大复杂化度，并且找到了第二次作业遗留的一个逻辑问题
二．第二次作业
1.目标
对之前电梯调度程序进行迭代性设计，目的为解决电梯类职责过多的问题，类设计要求遵循单一职责原则（SRP），要求必须包含但不限于设计电梯类、乘客请求类、队列类以及控制类。新增：1.乘客请求楼层数有误，具体为高于最高楼层数或低于最低楼层数，处理方法：程序自动忽略此类输入，继续执行2.乘客请求不合理，具体为输入时出现连续的相同请求，例如<3><3><3>或者<5,DOWN><5,DOWN>，处理方法：程序自动忽略相同的多余输入，继续执行，例如<3><3><3>过滤为<3>

2.方法分析

分析：迭代后，代码将不同功能封装在不同的类中，Dianti 负责电梯状态和运行，Requests 管理请求队列，Control 控制电梯运行逻辑，更加的符合模块化设计原则，提高了代码的可维护性和可扩展性。但是，仍然没有进行异常处理，在读取用户输入、操作请求队列等过程中，如果出现输入格式错误、队列越界等，程序可能会报错。此外，电梯的控制逻辑虽然单独作为了一个Control类，但是只拆分为两个方法仍然比较复杂
3.代码分析

2.1.Project Directory：项目目录，显示代码所在路径。
2.2.Project Name：项目名称，显示为乱码。
2.3.Checkpoint Name：检查点名称，为 “Baseline” 。
2.4.File Name：文件名是Main.java 。
2.5.Lines：代码行数为 306 行（* 可能含空行等 ）。
2.6.Statements：语句数量为 181 条 。
2.7.Percent Branch Statements：分支语句占比 20.4% ，说明代码中条件判断等分支逻辑占比情况。
2.8.Method Call Statements：方法调用语句数量为 90 条 。
2.9.Percent Lines with Comments：含注释的代码行占比 18.0% ，反映代码注释情况。
2.10.Classes and Interfaces：类和接口数量共 4 个 。
2.11.Methods per Class：每个类平均方法数为 8.00 个 。
2.12.Average Statements per Method：每个方法平均语句数为 5.47 条 。
2.13.Line Number of Most Complex Method：最复杂方法所在行号为 199 行 。
2.14.Name of Most Complex Method：最复杂方法是Control.runDianti() 。
2.15.Maximum Complexity：最大复杂度为 8 ，体现方法逻辑复杂程度。
16.Line Number of Deepest Block：最深嵌套代码块所在行号为 138 行 。
2.16.Maximum Block Depth：最大代码块深度为 4 ，表示代码中嵌套结构的最深层次。
2.17.Average Block Depth：平均代码块深度为 1.38 。
2.18.Average Complexity：平均复杂度为 1.87 。
分析：迭代后，代码的注释量相较于上一次明显占了更大的比例，但是复杂度的问题仍然没有得到解决简单的将电梯的运行逻辑从一个方法差分成两个方法并没有显著降低代码的复杂度。不过新增的requests类显著加快了代码的运行速度，解决了第一次作业中存在运行超时的情况。此外，方法调用语句数量为 90 条，说明代码中各方法之间存在较多交互
4.Bug分析
未发现bug。但是在PTA提交时存在一个测试点不通过的情况，在与正确的代码进行对比测试时，测试了几十种样例仍未发现问题所在（最终在第三次作业解决，见上文）
5.总结与反思
相较于上一次作业，第二次作业解决了代码注释量不足的情况，但是个别方法复杂度过高的问题并没有得到明显的解决，并且在逻辑上仍然存在问题没有被解决（最终在第三次作业解决，见上文）
三．第一次作业
1.目标
设计一个电梯类，包含状态管理、请求队列管理以及调度算法
2.方法分析

分析：电梯的控制方法集中在order（）方法中，导致这个方法无论是长度还是复杂度都太大方法过于复杂，嵌套的条件判断和循环使得代码可读性变差，维护难度增大；并且代码中存在一些硬编码（如 10086 作为默认楼层值），可维护性和可扩展性欠佳。getNow()、getRun()、setNow(int now)、setRun(int run)、Dianti(int min, int max)方法在数据处理时缺少对属性值的有效性验证，可能设置不合理的值。
3.代码分析

3.1.Project Directory：项目目录，显示代码所在的路径，但这里存在乱码。
3.2.Project Name：项目名称，乱码状态。
3.3.Checkpoint Name：检查点名称，这里是 “Baseline” 。
3.4.File Name：文件名，Main.java 。
3.5.Lines：代码行数，234 行
3.6.Statements：语句数量，143 条 。
3.7.Percent Branch Statements：分支语句占比，23.8% ，反映代码中条件判断等分支逻辑的比例。
3.8.Method Call Statements：方法调用语句数量，55 条 。
3.9.Percent Lines with Comments：含注释的代码行占比，10.3% ，体现代码注释情况。
3.10.Classes and Interfaces：类和接口数量，共 2 个 。
3.11.Methods per Class：每个类平均方法数，8.00 个 。
3.12.Average Statements per Method：每个方法平均语句数，8.50 条 。
3.13.Line Number of Most Complex Method：最复杂方法所在行号，第 5 行 。
3.14.Name of Most Complex Method：最复杂方法名，Main.main() 。
3.15.Maximum Complexity：最大复杂度，8 ，衡量方法逻辑复杂程度。
3.16.Line Number of Deepest Block：最深嵌套代码块所在行号，39 行 。
3.17.Maximum Block Depth：最大代码块深度，6 ，表示代码中嵌套结构的最深层次。
3.18.Average Block Depth：平均代码块深度，1.71 。
3.19.Average Complexity：平均复杂度，2.75 。
分析：代码整体都在雷达图的绿色范围内，但是复杂度最大为8即将超出。作为第一次作业，将所有方法都放在电梯类中确实存在不合理的地方，导致个别方法太过复杂。此外，注释占比即将低于绿色范围的最低值，注释占比百分之十点三偏低，还应在一些变量的定义处声明其意义以及对于复杂的order方法应该要有更加详细的注释以便于理解代码控制电梯的原理，避免遗忘。
4.Bug分析
未发现bug。但是在PTA上运行时会存在某些样例运行超时的情况发生，原因是代码order（）方法完成了所有电梯运行的逻辑导致代码过于复杂，嵌套太多，分支太多，导致运行超时。
5.总结与反思
总结
目标达成情况：初步实现了设计电梯类的目标，电梯类包含了控制电梯运行、开关门、处理内外部命令等方法，能在一定程度上模拟电梯的实际运行逻辑。
方法层面问题：
order () 方法：作为核心控制方法，承担了过多职责，导致方法长度和复杂度急剧上升。复杂的嵌套条件判断和循环结构，严重降低了代码的可读性，增加了维护难度。此外，getNow ()、getRun ()、setNow (int now)、setRun (int run) 以及 Dianti (int min, int max) 等方法，在处理数据时缺乏对属性值的有效性验证，这可能导致不合理的数据被设置。
运行问题：在 PTA 上运行时，部分样例出现运行超时情况，根源在于 order () 方法的复杂性，过多的嵌套和分支导致程序执行效率低下，无法在400ms内完成任务。
反思
方法拆分：应该将 order () 方法中复杂的逻辑按照功能模块进行拆分，每个模块负责单一职责，降低单个方法的复杂度，提高代码的可读性和可维护性。
数据验证：在所有涉及数据设置的方法中，需要添加数据有效性验证。确保电梯对象始终处于合法状态。