Part 1 设计策略
hw5使用生产者-消费者模式，输入类和控制器共享等待队列，输入类向等待队列添加请求，控制器控制电梯接受请求。
hw6在hw5的基础上改写了输入类，将向一个等待队列添加请求改为了向多个等待队列分配请求。为了保证调度的性能，将已经进入电梯的请求也添加为共享对象。
hw7使用工人模式，在hw6的基础上添加了请求池和总调度器。请求池存放输入和二次调度的请求，总控制器从请求池取出请求分配给各电梯。
总体来说设计比较保守，牺牲了部分程序性能，用简单粗暴的方法保证了线程安全。具体来说就是保证每个对象只被两个线程共享，读写工作都在同步块内进行。
搭建架构的主要思路分别来自第3、4次实验。hw56架构是第三次实验中的生产者消费者模式，hw7的架构是第四次实验中的工人模式。
Part 2 hw7的可扩展性分析
SRP原则
各类的分工比较明确：
Controller：控制单部电梯按照sstf算法运行
WaitingQueue：保存单部电梯的等待请求
MovingQueue：保存单部电梯正在运行的请求
Input：负责读入、将输入存入请求池
requestpool：保存待分配的请求
MasterCpntroller：从请求池取出请求分配给各电梯等待队列
elevator：负责保存电梯的属性以及开关门
OCP原则
从第六次到第七次保留了大部分的代码，只有少部分修改，大部分功能是通过扩展实现的。
LSP原则
作业中没有使用抽象和接口
ISP原则
作业中没有使用抽象和接口
DIP原则
作业中没有使用抽象和接口
Part 3 基于度量的程序结构分析
hw5：
时序图：
类图：
复杂度：
hw6：
时序图：与第五次一模一样
类图：
复杂度：
分析：主要是Input和Controller复杂度高，原因是Input承担了分配请求的工作，需要读取每一部电梯的状态并计算策略。Controller承担单部电梯的调度工作，需要获取等待队列、电梯内部和电梯属性并进行计算。
hw7：
时序图：
类图：
复杂度：
只有MasterController和Controller两个类飘红，主要是因为二者的run方法需要控制电梯的调度。Controller需要先获取单部电梯的所有属性，MasterConler需要获取所有电梯的所有属性，然后再计算调度，因此耦合度很高。
Part 4 BUG分析
hw5:
无bug
hw6：
强测1个bug，互测1个bug
强测bug：判断电梯能否塞人的时候写成了至少放一个。
互测bug：获取程序启动时间的代码写在了初始化时间戳之前，使电梯有小概率提前启动。
hw7：
互测一个bug：判断程序结束时条件为输入结束且所有已经记录出发的人都已经到达，没有判断请求池是否为空。原因是写程序途中修改了判断结束和获取请求池请求的顺序。
Part 5 发现他人的BUG分析
没有发现别人的bug
Part 6 感想
下周我一定会好好测试的