第五次作业
- 度量分析
因为第五次作业是在第三次作业的基础上改的，所以出现了与第三次作业一样的问题，即圈复杂度超标和嵌套现象严重。同时，由于对多线程的不熟悉，将一些功能集中的放入了一个类里，这也是McCabe Cyclomatic Complexity和Nested Block Depth标红的原因。
2.类图
从类图可以看出度量分析中体现的问题，即在方法的分配上不平均，将大部分功能都交给了dt类，导致这个类很冗长，从而也影响了整个程序的简洁性。
3.BUG
对于这一次的电梯作业，第一次用多线程来解决问题，感觉压力很大。在思考，设计和实现的过程中，遇见了很多问题，用了很多的时间。直到最后，对多线程安全的理解也是似懂非懂，导致在公测和互测中出现了很多BUG。首先公测中，出现几个粗心的BUG，（1）没有输出T（2）没有把结果输出到result,输出到了控制台。这两个简单的BUG，都是因为没有仔细的阅读指导书导致的，所以要认真的阅读指导书的要求，才能避免一些简单的BUG。然后出现了指令分配错误，指令执行的时间输出以及指令本身的输出有问题和电梯选择不正确的BUG。而回到程序中去解决BUG的时候，发现主要是qingq类，即分配指令的类出现了问题。而这个类的设计问题，导致出现了一系列的问题，所以对每一个类的设计都应该反复的思考和测试。作为被测者，被发现了两个BUG，一个是测试完后程序的线程没有关闭，这个是因为对多线程的不熟练导致的。作为测试者，发现了对面的公测出现了三个错误，全是关于捎带问题的。这次作业比较难，不仅整体的设计上容易出现问题，在一些细节上的处理也容易出现问题。第一次多线程作业，带来了很多关于多线程的反思和经验。
第六次作业
第六次作业是对文件的各种操作与监控，因为对作业目标和很多新操作的不清楚，没有及时做完提交，就不做分析了。
第七次作业
- 度量分析
第一次出租车作业，仍然出现了之前的问题。因为将很多的功能放到了taxi类里，以及if-else的大量使用，导致嵌套严重。因此以后需要注意这些问题。
2.类图
这次的类图比较简单。
3.BUG
尽管这是第三次多线程作业，但是对于多线程的理解和具体实现，仍然有很多不明白的地方。就这次作业而言，公测与互测中，出现了两个BUG。公测中有一个BUG，是当输入指令的关键字错误时，没有报错。互测中的BUG是，当没有出租车响应乘客请求时，没有告知乘客。而作为测试者，发现了对方的两个BUG，一个是输出格式的错误，没有输出途径节点的坐标和时刻，另一个BUG，是输出时间不正确，回到对方的程序中，发现他的设计没有问题，只是在计算时间的时候用到了系统时间，而系统时间在调用gui，计算最小距离时，可能出现了延迟，导致最后算出的时间多了100ms或200ms。
心得体会
1.第一次接触学习多线程，发现理解起来有困难。而在用多线程解决问题时，发现对于多线程的项目的架构设计也有困难，因为要清楚建立多少个类，多少个线程，每个类都承担什么功能，线程与线程之间的关系，才能将更好的解决问题。
2.线程安全是多线程的关键。对共用资源的分析，是否对其进行保护，将影响程序是否出现一些不合乎常理的错误。因为多个线程同时运行的情况下，会对公共资源进行争夺，如果不加管控，可能会对公共资源进行难以意料或是不想要的操作和改变。所以在设计时，要分析线程之间的关系，要分析清楚共用资源。
3.虽然尽力的完善设计，但是实现的过程中总会有一些问题。只是在处理这些问题时，需要思考的是这个问题与整体设计的联系，这样才能及时的发现整体设计的问题，不然，这个问题解决了，仅仅是解决了局部的问题。