OO第二阶段总结
第五次作业
类图
度量
时序图
设计策略分析及心得体会
最开始接触多线程，对于多线程的工作机制理解起来比较困难，花费了两天时间查阅大量资料之后终于对线程的相关知识所有掌握和了解。在阅读过指导书之后，经过一定的分析和思考，并参照PPT上的思维导图，得到了初步的设计策略。
真实模拟时间的电梯调度和第三次作业比起来更加清晰和简洁，基本的调度方法没有太大差别，主要的难点在于多线程安全的控制。一开始设计的策略没有很好地使用同步锁，线程之间共同对象的交互比较混乱，所以在完成第一版的代码之后又对synchronized关键字的用法和设计思想进行了大量资料查阅，最终得到一个较为完善的设计策略。
第五次作业中最为关键的是控制器与请求模拟器之间的交互，以及控制器和电梯之间的交互。考虑到请求队列作为公共访问对象，需要进行同步控制，所以设计队列托盘，模拟生产者-消费者模型。调度器从托盘中取得请求之后，访问三部电梯的状态和运行情况，经过比较分析之后得到调度结果，再将请求分给相应的电梯响应。每部电梯内部设置待响应请求队列，与调度器之间设置相应托盘以保证线程安全的控制。
调度器的设计有一定缺陷，主要问题在于对于电梯对象的访问，直接采用e1,e2,e3的形式进行访问，没有较好的扩展性，应采用电梯队列，在扩展电梯数量后仍然可以对电梯进行管理，并且可以简化调度器的代码书写。此次设计中责任分配不够均衡，调度器和电梯代码数量过多，部分代码冗余。
自己的bug:
本次设计比较仓促，前期的多线程机制理解花费了大量时间，导致自己没有对代码进行自测，公测没有错误，但在互测中被检查出三个bug，虽然很心痛，但的确是自己不够细致认真。。。其中一个bug是对于格式的检查，第二个bug则是最简单不过的同质测试，由于某天深夜改掉一处bug之后，没有对相应的判断条件进行修改，导致最后的互测bug。。。第三处bug则是线程安全设计漏洞，此处的bug具有很好的提醒意义。
对方的bug:
此次的互测作业多线程设计非常好，但是在细节上有一定忽视，最终找到一处crash和incomplete。
第六次作业
类图
度量
时序图
设计策略分析及心得体会
第六次作业完成过程艰辛且艰辛，从理解指导书开始再到思路分析，再到代码书写，其中花费了大量精力和时间，此次代码是所有作业中完成最晚的一次，心态也得到了很大程度的锻炼。。。
本次作业中的多线程安全控制与电梯作业比起来要求较为简单，主要在于对safeFile类的安全控制。设计的主要策略是在监控类中记录监控对象的snapshot，并在相应的操作之后进行扫描得到新的snapshot，二者进行对比之后判断是否触发相应的触发器。其中modified和size-changed较为简单，只需要按照前面叙述的思路对二者相应属性进行对比即可，rename和path-changed触发器处理起来相对来说比较麻烦，但是二者处理思路大致相同。对于rename触发器，对每一个监控对象设置了同层文件snapshot，采用ArrayList记录相应的文件信息，在操作之后进行比对，并且更新此层的文件列表，采用这样的设计思路主要考虑到了同属性文件的rename操作，但之后的测试要求改变，使得这样的设计显得有些复杂和多余。其中path-changed的设计策略与rename相同。文件监控和目录监控思路一致，但在具体的设计中有细节的差别，主要在于文件队列的设置，只是增加了相应的查找过程。
此次作业的完成总体还是满意的，代码的流畅度个人认为比起多线程电梯来说有所进步，但在一开始的设计上花费了大量时间，以及对文件的操作比较陌生，代码完成的时间尺度过长，没有进行完备的测试和bug查找。
自己的bug：
此次测试的结果也不令人满意，细节上的问题没有得到合适的处理，互测中被检查出两个bug,一个为目录rename 并recover，在写完目录rename触发器后，没有时间测试相应的recover任务直接提交，自然被发现了bug。第二个bug主要是目录的size-changed触发器的detail记录，这里出现的问题是由于一开始对size-changed的触发条件理解有偏差，修改了文件判断条件后忘记修改目录的判断条件，导致被检查出bug。。。
对方的bug：
此次作业发现多处bug，被测者申诉自己的运行结果正确，但自己在本地运行数次后结果均不正确，最终选择仲裁解决。
第七次作业
类图
度量
时序图
设计策略分析及心得体会：
本次作业相对于前两次作业来说较为简单，但也并没有简单到非常。。。还是花费了不少的精力。。。本次作业在类的划分上和多线程电梯较为相似，核心的类为请求模拟器，调度器以及出租车。本次作业需要关注的细节比较多，比如最短路径的处理和请求分派时间的控制。总体来说代码的书写过程比较流畅，但在调度策略的选择上有所修改，最初的策略不够清晰，不能及时使得各个请求在窗口期内得到响应，经过重新思考后得到的调度策略则更为合理。
自己的bug:
此次互测中被检查出一个输出错误，输出情况中的确少考虑到一种情况，且该种情况难以发现，十分感谢测试同学检查出的此bug。其次设计原则被扣incomplete，被扣理由为责任分配不均，事实上觉得责任分配还是比较均衡的。。。
对方的bug:
找到文档设计原则不符，理由为显示表达不符。
