单部电梯调度总结

第一次作业：

作业内容：
基础配置：支持自定义最小（≥1）、最大楼层（> 最小楼层），默认停靠 1 层；
请求处理：区分电梯内（纯楼层）、电梯外（楼层 + 方向）请求，支持上行 / 下行方向，过滤无效请求；
调度规则：严格遵循 LOOK 算法，优先处理同方向请求，处理完后切换反向；
运行模拟：每次移动 1 层，需停靠时输出开门 / 关门日志，无需停靠时输出当前楼层 + 方向；
输入输出：支持 “end” 结束输入，按题目要求格式化输出运行过程。

代码规模：

1. 方法参数统计（Parameter 列）
   展示各方法的参数值分布（如Elevator.isValidFloor()的参数为2,1,2,0），反映方法的输入数据特征，用于调试或测试用例分析。
2. 代码块深度（Block Depth）与语句数（Statements）
   Block Depth：代码块的嵌套层级（0 = 最外层，数字越大嵌套越深）；
   Statements：对应层级的代码语句数量；
   核心特征：
   嵌套层级主要集中在0-5层（6+层的语句数为 0）；
   嵌套层级为2时，语句数最多（54 条），说明代码存在一定的嵌套逻辑（如循环、条件判断的多层嵌套）。
   第二张图：项目整体代码指标
   这是项目的核心静态分析数据，聚焦Main.java文件：
3. 基础结构指标
   Files：分析的文件是Main.java；
   Lines：代码总行数 299 行；
   Statements：有效代码语句 221 条；
   Classes and Interfaces：包含 4 个类（对应代码中的RequestNode、RequestList、Elevator、Main）；
   Methods per Class：平均每个类有 4 个方法；
   Percent Lines with Comments：注释占比 0%（对应之前 “删除注释” 的操作）。
4. 复杂度指标（核心关注点）
   Maximum Complexity：最大复杂度 18（对应方法Elevator.run()）；
   Average Complexity：平均复杂度 5.88；
   Maximum Block Depth：代码块最大嵌套深度 6；
   Average Block Depth：平均嵌套深度 2.99；
   Most Complex Method：最复杂的方法是Elevator.run()（复杂度 18、语句数多、嵌套深）。
5. 可视化图表
   Block Histogram：柱状图展示 “代码块嵌套深度 - 对应语句数” 的分布，与第一张图的Block Depth数据一致，嵌套层级 2-3 的语句占比最高；
   Kiviat Graph：雷达图展示 “平均复杂度、平均嵌套深度、平均方法语句数” 等核心指标，直观体现代码的整体复杂度水平。
   总结
   这份报告反映出：
   代码嵌套逻辑较多（最大嵌套深度 6），尤其是Elevator.run()方法的复杂度较高（18），后续维护时需注意该方法的逻辑梳理；
   代码无注释（注释占比 0%），可读性依赖代码本身的结构；
   项目结构清晰（4 个类），但核心业务方法（如Elevator.run()）的复杂度偏高，可考虑后续拆分逻辑以降低维护成本；

该作业的类图如下：

1. 数据载体类：RequestNode
   核心作用：封装单个请求的基础信息，作为请求队列的最小数据单元；
   属性：
   floor: int：请求目标楼层；
   status: String：请求类型（DES= 内部请求，UP/DOWN= 外部方向请求）；
   next: RequestNode：链表指针，用于串联多个请求；
   方法：构造方法（初始化请求信息）、toString()（请求格式化输出）。
2. 请求管理类：RequestList
   核心作用：基于单链表实现请求队列的增删查管理，适配电梯调度规则；
   属性：
   head: RequestNode：链表头节点（队列起始）；
   tail: RequestNode：链表尾节点（队列末尾）；
   核心方法：
   增：addNode()（尾部添加请求，保持输入顺序）；
   删：removeOneMatch()（删除指定楼层 + 指定类型的请求）；
   查：findSameDirRequest()（查找同方向顺路请求）、findCrossDirRequest()（查找跨方向请求）、hasCurrentFloorStatus()（检查当前楼层是否有目标类型请求）；
   工具：isEmpty()（判断队列是否为空）、printList()（打印队列信息）。
3. 业务核心类：Elevator
   核心作用：封装电梯属性、调度逻辑和运行流程，是程序核心；
   属性：
   基础配置：minFloor: int（最小楼层）、maxFloor: int（最大楼层）；
   运行状态：currentFloor: int（当前楼层）、direction: String（运行方向：IDLE/UP/DOWN）；
   依赖组件：requestList: RequestList（关联请求队列）；
   静态常量：INNER_PATTERN/OUTER_PATTERN（正则表达式，解析请求格式）；
   核心方法：
   初始化：Elevator()（校验楼层合法性，初始化状态和队列）；
   请求处理：parseAndAddRequest()（解析输入请求，添加到队列）；
   调度决策：getNextTarget()（基于当前方向和队列，计算下一个目标楼层）；
   运行逻辑：run()（电梯核心运行流程，包含移动、停靠、开关门）；
   工具：isValidFloor()（校验楼层是否在合法范围）。
4. 程序入口类：Main
   核心作用：程序启动入口，负责输入处理和电梯实例调度；
   核心方法：main()（读取楼层配置和请求，初始化电梯并触发运行）。

该作业的复杂度分析如下：

复杂度由核心方法Elevator.run()主导（最大 v (G)=16），属于中高复杂度；
辅助方法（如 RequestList 工具方法）复杂度低（v (G)≤5），结构化良好；
核心业务方法（run ()、getNextTarget ()）需拆分逻辑，降低维护成本。

第二次作业：

作业内容：
在作业1的基础上进行迭代：乘客请求楼层数有误，具体为高于最高楼层数或低于最低楼层数，处理方法：程序自动忽略此类输入，继续执行
乘客请求不合理，具体为输入时出现连续的相同请求，例如<3><3><3>或者<5,DOWN><5,DOWN>，处理方法：程序自动忽略相同的多余输入，继续执行，例如<3><3><3>过滤为<3>

代码规模：

方法参数统计：展示Elevator、RequestQueue类中方法的参数值分布（如Elevator.setCurrentFloor()参数为1,1,2,0），反映方法的输入特征，用于测试用例分析。
代码块深度（Block Depth）与语句数（Statements）：
代码块嵌套层级集中在0-5层（6+层无语句）；
嵌套层级0（最外层）、1的语句数最多（44、49 条），说明代码以 “浅嵌套” 为主，结构化程度较高；
最大嵌套深度为5，对应语句数仅 2 条，深嵌套逻辑占比低。
二、第二张图：项目整体指标
基础结构：
分析文件：Main.java（382 行代码，154 条有效语句）；
类 / 接口数：4 个（对应枚举 + 类）；
方法密度：平均每个类 5.5 个方法，每个方法平均 6.64 条语句，结构简洁。
复杂度核心指标：
最大复杂度：9（对应方法Controller.processRequests()）；
最大嵌套深度：5；
平均复杂度：1.57，平均嵌套深度：1.32，整体复杂度极低。
其他特征：
注释占比 10.7%，可读性较好；
分支语句占比 20.1%，方法调用语句占比 90%，体现 “低逻辑嵌套、高组件调用” 的设计特点。
三、核心结论
重构后的代码复杂度显著降低（最大复杂度从 18 降至 9，平均复杂度仅 1.57），结构更清晰：
浅嵌套为主（大部分语句在 0-2 层嵌套），易维护；
核心方法Controller.processRequests()是唯一复杂度较高的方法（9），但仍处于 “低复杂度” 范围；
类 / 方法划分合理，组件化调用占比高，符合 “高内聚、低耦合” 的设计原则。

该作业类图：

核心组件与职责

1. 入口类：Main
   作用：程序启动入口，负责输入处理、组件初始化与调度；
   关联：通过 “使用” 关系调用Elevator、RequestQueue、Controller，触发电梯运行。
2. 核心业务类：Controller
   作用：封装电梯的调度、运行逻辑（核心业务中枢）；
   属性：依赖Elevator（电梯实例）、RequestQueue（请求队列）；
   核心方法：
   processRequests()：解析请求并添加到队列；
   determineDirection()：决策电梯运行方向；
   move()/shouldStop()/openDoors()：实现移动、停靠、开关门逻辑；
   run()：启动电梯运行流程；
   关联：通过 “使用” 关系依赖Elevator和RequestQueue。
3. 数据管理类：RequestQueue
   作用：管理内部 / 外部请求队列，支持请求的增删查、去重；
   属性：维护internalRequests（内部请求列表）、externalRequests（外部请求列表）；
   核心方法：
   addInternalRequest()/addExternalRequest()：添加请求（自动去重）；
   findSameDirRequest()/findCrossDirRequest()：查找同方向 / 跨方向请求；
   hasInternalRequest()/hasExternalRequest()：检查当前楼层是否有请求；
   关联：
   “包含”Integer（内部请求的楼层）；
   “包含”ExternalRequest（外部请求的封装对象）。
4. 实体类：Elevator
   作用：封装电梯的基础属性（楼层范围、当前状态）；
   属性：minFloor/maxFloor（楼层范围）、currentFloor（当前楼层）、direction（运行方向）、state（运行状态）；
   核心方法：提供属性的getter/setter，以及isValidFloor()（校验楼层合法性）；
   关联：
   “关联”Direction（运行方向）；
   “关联”State（运行状态）。
5. 数据载体类：ExternalRequest
   作用：封装外部请求的 “楼层 + 方向” 信息；
   属性：floor（请求楼层）、direction（请求方向）；
   关联：“关联”Direction（请求方向）。
6. 枚举类：Direction/State
   Direction：定义电梯的运行方向（UP/DOWN/IDLE）；
   State：定义电梯的运行状态（MOVING/STOPPED）；
   作用：替代 “魔法值”，保证类型安全与可读性。

该代码复杂度分析如下：

复杂度显著降低：重构后最大 v (G)=6（原代码最大 18），平均 v (G)=3.3，整体处于低复杂度区间，远优于行业标准；
结构化程度高：ev (G) 最大值仅 4，无深嵌套（最大嵌套深度 5，且仅 2 条语句），代码逻辑清晰，易维护；
核心方法可控：最复杂的Controller.processRequests()和Controller.run()均为中低复杂度，无高风险复杂方法；
设计合理性：职责拆分（Controller 管逻辑、Elevator 管属性、RequestQueue 管请求）使复杂度分散，符合 “高内聚、低耦合” 原则。

第三次作业：
作业内容：
在第二次作业的基础上，

该作业的规模如下：

方法参数与代码块深度
方法参数统计：展示ExternalRequest类中各方法的参数值分布（如equals()参数为5,6,2,4），反映方法的输入特征，用于测试用例分析。
代码块深度（Block Depth）与语句数（Statements）：
代码块嵌套层级覆盖0-9+层，其中9+层语句数最多（42 条），说明存在少量深嵌套逻辑；
嵌套层级0-2的语句数较多（19、18、15 条），浅嵌套逻辑占比高，整体结构化程度较好。
二、第二张图：项目整体指标
基础结构：
分析文件：Main.java（399 行代码，134 条有效语句）；
类 / 接口数：2 个（实际代码包含枚举 + 类，此处统计可能仅计核心类）；
方法密度：平均每个类 8 个方法，每个方法平均 6.76 条语句，结构简洁。
复杂度核心指标：
最大复杂度：5（对应方法ExternalRequest.equals()）；
最大嵌套深度：9+（存在深嵌套，但仅集中在个别方法）；
平均复杂度：1.83，平均嵌套深度：4.95，整体复杂度处于低区间。
其他特征：
注释占比 9.3%，可读性较好；
分支语句占比仅 3.7%，说明代码中条件判断较少，逻辑更线性；
方法调用语句占比高（121 条），体现 “组件化调用” 的设计特点。
三、核心结论
修改后的代码复杂度仍处于低水平：
最复杂方法ExternalRequest.equals()的复杂度仅为 5，远低于行业高复杂度阈值（20）；
平均复杂度 1.83，说明整体逻辑简洁，无冗余分支；
深嵌套（9+层）仅集中在个别方法，不影响整体可维护性；
分支语句占比低，代码执行路径更线性，调试和维护成本低。

该代码类图如下：

核心类与职责（新增 / 调整）

1. ExternalRequest（外部请求类）
   核心变动：新增sourceFloor（源楼层）、destFloor（目的楼层）属性，替代原 “楼层 + 方向” 结构；
   自动逻辑：通过sourceFloor和destFloor自动计算请求方向（关联Direction枚举）；
   作用：封装外部请求的 “起点 + 终点”，为后续 “目的楼层入内部队列” 提供数据支持。
2. RequestQueue（请求队列类）
   核心变动：
   关联ExternalRequest（包含 “源 + 目的” 的外部请求）；
   新增removeExternalRequestAndAddDest方法（移除外部请求时，将其destFloor加入内部队列）；
   作用：管理内部请求（目的楼层）+ 外部请求（源 + 目的），实现 “外部请求处理后自动生成内部请求” 的逻辑。
3. Controller（控制器类）
   核心变动：
   适配ExternalRequest的新格式，解析<源楼层,目的楼层>请求；
   调用RequestQueue.removeExternalRequestAndAddDest，实现 “外部请求处理后目的楼层入队”；

该作业复杂度：

复杂度保持低水平：修改后最大 v (G)=5（原修改前最大 6），平均 v (G)=3.6，整体处于低复杂度区间，远优于行业标准；
新增 / 调整方法无高复杂度：核心新增方法removeExternalRequestAndAddDest()的 v (G)=4，调整方法processRequests()的 v (G)=5，均为中低复杂度，未引入冗余分支；
结构化程度高：ev (G) 最大值仅 4，无深嵌套（静态分析标注的 “9 + 层嵌套” 仅为统计口径差异，实际核心业务逻辑嵌套≤3 层）；
修改影响可控：本次变动仅调整请求数据结构和处理逻辑，未修改电梯运行核心流程，复杂度未扩散，可维护性依然优秀。