OO第二单元电梯作业

程序结构分析

类图分析

以第三次作业为例，我一共建了14个类，下面我会分层次介绍各类的情况。

这三个类分别是主类，输入类（创建输入线程）和封装的安全输出类，主类中进行初始化和输入线程、电梯线程的启动。在输入类中主要是不停地把新的输入送进来，并完成对应的操作。

这五个类主要是完成对于每个人的请求进行路线的寻找的。我的思路是把每个人的路线作为一个Route类并作为每个Person类的固有属性。将每座楼的每层算作一个节点，把每座电梯可以到达的节点两两连接，边权为到达时间，这样就可以用Dijkstra算法找出最短路，并让乘客的路径为这条路，其中的Node类和Edge类都是Dijkstra算法中所需要用到的类。这样就可以在乘客的每个请求读入时调用Dijkstra算法，算出最短的路径（保证是一次纵向电梯接一次横向电梯），并存储到每个乘客请求的固有类Route中。

这四个类分别是横向、纵向电梯的等待队列和电梯类，对于每一个楼层和楼座，建立一个等待队列，在每个等待队列上安排若干个电梯，每个电梯互相独立，自由竞争请求，采取LOOK策略进行电梯调度。（这里由于我的第三次作业没有完成，所以FloorQueue没有写完）

这两个类负责完成流水线工作模式的实现，PersonCounter负责统计乘客请求完成的数量，只有乘客把整条路径走完才+1，等到最后确认完成的数量等于请求数即可认为所有操作结束，线程停止。而Controller类负责整个流程的控制，包括接收新请求，分配请求到等待队列，接收完成的请求并分配到下一次的等待队列等。

同步块的设置和锁的选择

在这次作业中，我选择用了传统的wait-notify作为锁，同步块选择了所有的等待队列，确保对队列中的元素的调用是线程安全的。

调度器设计

这次作业中在队列与电梯之间我没有安排调度器，唯一的调度器就是不断安排请求到下一道工序的Controller。

心得体会

这次作业，由于在第一次看错了时间，导致没做完，进而之后的两次作业都是差了一点做完，好在我最后已经完全搞懂了原理，希望以后的作业不会在出现这样的情况了。
在整体设计上，也有一些可以优化的地方，比如让所有电梯直接从等待队列里取请求会加剧队列的拥挤程度、这种最短路算法无法在新加入电梯后更新最短路径，最短路径的算法太过简单粗暴不是最优的等，希望下次作业可以做出更多的优化吧。