一、 第五、六、七次作业设计策略变化
这三次作业都是要识别问题域中的对象的特点，发现谁是线程，哪些数据是共享数据，需不需要做安全处理。
在做作业5时，参考的类图和程序框架图中说明的很清楚，每部电梯是一个独立的线程，请求模拟器模拟产生用户请求也应是独立线程，调度系统也是独立运行的线程，而请求队列和电梯状态是共享数据，在访问时需要进行访问控制。
作业6，自己将每一个合法输入的不重复的命令生成一个独立的监控线程，而所有被监控对象都生成一个共同快照（缓存），是共享数据，设计相对简单。
作业7，将每一辆出租车设计为一个线程，出租车的状态数据是一种共享数据。模拟产生用户的呼叫中心设计成一个独立线程（这个线程类似于生产者线程），呼叫处理调度器也设计成一个独立的线程（类似于消费者线程），呼叫队列是共享数据。
二、 自己的程序结构分析
1、 类图
Figure 1 第五次作业类图
Figure 2 第六次作业类图
Figure 3 第七次作业类图
2、UML协作图
Figure 4 第五次作业协作图
Figure 5 第六次作业协作图
Figure 6 第七次作业协作图
3、类分析
三、 发现自己和别人bug时的策略
这几次的作业，主要的考察点是在多线程的安全部分，卡输入，卡边界的测试已经少了很多，在电梯和监控当中，建立多线程的目标是明确的。每一个电梯是一个线程，每一个请求是一个线程。而到了之后的几次中，可能有好几处需要考虑多线程的内容，比如在出租车的问题中，出租车，乘客和请求是否需要单独建立线程，将抢单的行为放在哪个类下面都是需要考虑的情况。课程后半部分的测试与前半部分是略有不同的，除去直接看代码的方法以外，想要通过输入----输出的情况来测试已经变得比较麻烦，比如在第七次作业的测试中，除了输入后针对性的看某个乘客或者某个出租车的运行情况以外，一次输入多条指令的做法只能作为压力测试。因为除非crash否则，多条指令中某步运行出错是不能用模拟的方法得到期望输出的。
因此对于对方程序的测试主要就是将自己的测试样例过一遍，因为对于这些样例的考察点和期望输出有一定了解，否则不看代码的话某辆车在某条路上运行时间不对感觉很难发现。
四、 心得体会
1 老师在对我们上课估计每次作业的时候是单独列出思考指导书的时间的，而在作业越来越复杂后我确实感到指导书是需要单独拿出来理清之后再开始思考的。比如出租车的信用我一开始的时候没有发现有什么用，以为是用来给出租车的行动计数的，因此抢单中根本没有加入信用，后来和同学讨论的时候才发现这一点，还需要回去进行不小的改动。
2 在追赶别人的过程中，迈出一步比不动要好。差距仍然存在，但是向前进总是比什么都不做要好。比起思考在2.9s的时候突然有一个新的请求，能够做出来能响应一开始就存在的请求更为重要，我一开始没有想到怎么测试，就直接用随机生成的请求。虽然不能发现细微的错误，但是可以看到程序跑了起来，先弄清楚每一次的考察点所在并且有一定了解我觉得是放在第一位的。
3 show me your code 是最重要的学习方式。这门课一方面是建立面向对象编程的思维，一方面也是在提高代码能力。每一次的作业既是测试，也是使得人进步的压力。确确实实的敲下每一行代码，使得人受益匪浅。
4与此同时，io.file，基于hash值的动态锁，很多内容我们也是不断在资料中看到并且学习的，沟通与交流也是不可或缺的能力之一