一、各次作业设计策略、度量分析及bug
第一次作业
（1）设计策略
第一次作业是可捎带电梯模拟，使用生产者-消费者模式，将请求队列作为共享对象，请求模拟器生产请求，电梯通过调度器以scan策略消耗请求
（2）类复杂度分析
（3）方法复杂度分析
（4）UML类图
本次作业各个类的功能相对独立，但电梯类与调度器类仍有较大耦合
（5）协作图
（6）关于bug
本次作业在编码过程中出现过的一个bug是线程未成功退出，若电梯已休眠退出时须先唤醒线程
第二次作业
（1）设计策略
第二次作业变为了多部电梯模拟，增加分派器线程用于将请求分给各个电梯的内部队列，此外本次作业将调度方法纳入电梯内，用于请求调度
（2）类复杂度分析
（3）方法复杂度分析
（4）UML类图
本次作业将调度器纳入电梯内部，导致电梯类较为复杂
（5）协作图
以一部电梯为例，线程间协作关系如下，此次由电梯主动索要请求变为派器分配请求：
（6）关于bug
本次作业开始在互测中hack bug，生成随机数据进行测试，该方法节省人力但效率不高，并未发现同屋一人实际存在的bug
第三次作业
（1）设计策略
本次作业增加了可停靠楼层和加入电梯指令，整体架构与上次作业差别不大，分派器中需要增加可达性判断，分派时考虑新增的等待时间性能指标和负载均衡，使各台电梯尽量并行，减小总运行时间
（2）类复杂度分析
（3）方法复杂度分析
（4）UML类图
本次作业分派器类设计较为复杂
（5）协作图
本次作业线程间协作关系与上次相同
（6）关于bug
本次作业在提交评测时出现了部分RTLE，问题代码如下：
synchronized (requestList) {
status = ElevatorStatus.IDLE;
try {
requestList.wait();
} catch (InterruptedException e) {
e.printStackTrace();
}
}
本次作业设计输入结束时唤醒休眠线程从而退出，但若请求在执行该段代码前结束，则线程陷入休眠后无法被唤醒
二、第三次作业架构可扩展性分析
1. 单一职责原则：第三次作业较为遵循单一职责原则，分派器负责分配乘客，电梯负责运输乘客
2. 开闭控制原则：本单元三次作业电梯种类不多，情况不太复杂，作业实现也未严格遵循开闭控制，若电梯类型繁杂，需考虑多种电梯继承自抽象电梯父类，开关门移动定义为抽象方法以支持不同实现的扩展等等
3. 里氏替换原则：本单元作业没有进行继承相关设计
4. 接口分离原则：第三次作业较为遵循接口分离原则，不实现多余的接口
5. 迪米特原则：第三次作业并未很好遵循迪米特原则，电梯和分派器之间存在直接调用，有一定耦合
三、第二单元心得体会
本单元较大的心得体会首先依然是架构设计的重要性，由于第一次作业开始时架构尚可，后续作业在该基础上迭代较为平缓轻松。
其次就是多线程情形下更突显了架构设计需要降低各个模块的耦合度，各个模块功能独立才能保持程序运行逻辑清晰、简洁高效、可维护，解除耦合可以考虑层次化处理。
另外还有设计模式有必要深入学习，生产者消费者模式、观察者模式等等在开发经验中总结出来的设计模式能有效优雅地解决实际问题