第五次作业：
类图：
度量图：
协作图：
分析：本次作业时多线程的电梯实现。第一次接触多线程，我没有过多的思考，直接用线程完成线程间的信息交互和信息储存，导致刚开始程序出现很多错误，甚至不能运行。根据度量图也可看出，线程的run方法写了过多的代码。而这其中的一些代码应是另一个非线程类所具有的，线程的作用应是传递数据实现同步，而不应过多的储存数据修改数据。
bug：本次作业由于多线程设计思路有偏差，出现了很多不可预知的bug。在互测的过程中，对方的代码就分成了很多模块，非线程储存数据，而线程类则进行信息传递与数据更改，避免了线程间过多的交互，更好的实现了同步。但对方的代码由于逻辑的问题，在某一情况的捎带指令执行时会crash。
第六次作业：
类图：
度量图：
协作图：
分析：本次作业线程间没有太多的交互，多个监控对象监控不同或相同的目录树。根据度量图，我在compare两次快照时代码过于繁杂，且只把其作为一个方法。这段具有特定功能的代码，最好还是写成类或线程，以增加代码的清晰程度。
第七次作业：
类图：
度量图：
协作图：
分析：本次作业是模拟出租车呼叫系统，最开始我的想法是汽车接到指令在计算路径，但这样计算需要的时间甚至接近了汽车的每格移动时间，会使整个系统的运行出现滞后。最后，我只能在地图初始化时就将这些路径计算出来，在运行时使用。汽车的随机选择路径方法我写的过于复杂，应该有非常简便的算法，但我暂时没有想到。run方法冗杂，还是老问题，没有将一些功能提取成非线程类或线程类进行使用，结构上的分工应该更合理一些。
bug：这次作业的bug主要是时间问题，比如计算耗时过长，时间出现问题。或是窗口结束后接单的车不对，这是因为窗口结束后车的信息没有正确更新，导致信息滞后。
总结：多线程的作业很复杂也很难，在设计时需要构造出分工明确的类体系，如只保存数据的线程安全类，进行信息传递的某些线程类，实现某些特定方法的线程类等。希望在今后不断地练习中，我可以掌握多线程安全的设计方法，更合理的写出高效的代码。