第五次作业分析
1）类图
2）OO度量
McCabe Cyclomatic Complexity 表示圈复杂度，圈复杂度主要与分支语句（if、else、，switch 等）的个数成正相关。Nested Block Depth表示嵌套块深度，嵌套深度表示if、for、while循环嵌套的个数。此次作业圈复杂度和嵌套块深度过高的原因是因为在电梯调度器类scheduler中使用了过多的if语句来对电梯状态和指令类型进行分类造成的，归根结底还是程序设计上出了错，违背了SRP原则，一个类负担了过多的职责，从而需要较多的分支路径来保证功能的正常执行，在以后的设计中应该多加注意。
3）协作图
由于此次作业截止时间之前由于设计存在问题导致未调出的BUG导致无法正常工作，所以没有正确的协作图。
4）作业总体分析
此次作业的代码质量不高和写代码之前设计不充分是有很大关系的，俗话说“磨刀不误砍柴工”，在拿到指导书后先理清思路，遵循SOLID原则设计出良好的结构对后期的调试和测试都会有事半功倍的效果。
第六次作业分析
1）类图
2）OO度量
这此作业依旧是圈复杂度和嵌套快深度过高。圈复杂度过高的原因主要是因为在pc方法（监控path-change）中使用了大量的if-else语句对处理对象的类型的状态进行区分，这也还是由于pc方法的职责分的还不够细，需要对多种情况进行分类处理。嵌套块深度过高的原因是在读入时使用了多层嵌套的if-else语句来区分指令类型和判断指令的格式是否合法，要改善这个缺陷，就应改在设计时尽量简化逻辑，去除不必要的语句嵌套。
3）协作图
4）BUG相关分析
这一次作业里最主要的BUG如下：
1）由于时间比较紧，所以调试时的输出没来得及全部注释掉，导致了在控制台输出较多无关信息。
2）对于目录的rename响应错误，由于在对rename的判断中条件考虑的不充分，导致了程序将不同名的文件都当做了rename类型来响应。虽然只是一个微小的地方没有考虑到，却导致了比较严重的后果，这就使我深刻认识到了在写程序时任何一个角落的bug都是不可忽视的，设计充分的测试方法来使程序趋向完美应该是编写代码时的重要准则。
4）作业总体分析
这一次作业犯的错误主要还是在一些细节上，主要问题依旧是代码逻辑不清晰导致的，过多的嵌套和分支使得我在编写代码时很容易就忽略了藏在某个嵌套块深处某个分支上的bug，所以，在以后的作业中应该进一步努力理清思路，整理出清晰的逻辑，使用尽可能简单的结构进行代码的编写，为后期的调试和拓展功能提供便利。
这一次作业在设计上也是存在一些问题的，我的程序中一个类以及方法需要对多种情况进行相应的处理，这种违背SRP原则的设计就导致了程序需要多个if-else语句来对处理情境进行分类以正常完成功能，而这就造成了圈复杂度和嵌套块深度比较高，应该在以后的作业中着重于逻辑的简化以及类职能的单一化。
第七次作业分析
1）类图
2）OO度量
这次作业圈复杂度和嵌套块深度过高以及在Taxi类的构造方法中使用了过多的参数。圈复杂度过高是因为提供的gui中draw方法在图形化时使用了大量的if-else语句对地图和出租车的状态进行分类以执行相应的操作。而嵌套块深度过高的原因是因为在调度器类的run方法中使用了多层的if-else语句按照给定的策略选取出租车，可以考虑将选取方法按照优先级顺序依次执行，找到合适的出租车就停止，从而避免多层嵌套带来的逻辑复杂的问题。Taxi类的构造方法中涉及7个参数，可以将状态state和信用credit这两个初始值确定的属性从参数中移出。
3）协作图
4）BUG相关分析
这此作业主要的bug是出租车送达乘客的瞬间在相同地点发出新请求后该出租车没有被选中作为指派对象（该出租车完成一单后信用应该高于其他出租车，同时该出租车还离请求地点最近，所以按照给定策略，此出租车应当是被选中为最佳指派对象的），经过我的分析，这个bug主要是因为出租车的信用添加不及时导致选择指派对象时该出租车不是信用最高的出租车，这也就导致了应该作为最佳指派对象的出租车没有被选中。
4）作业总体分析
这此作业花了大量的时间来理清具体实现的逻辑，但是在代码中还是遗留了未预料到的bug，主要还是最后设计的测试用例不够全面，考虑的情况不够充足，于是在测试阶段漏掉了一些本该查出来的bug。其次，在设计中，我把选取策略的实现以多层if-else嵌套的形式加到了dispatch类中，使得程序嵌套块深度过高，应该换用更加清晰的逻辑结构，以减少bug的“藏身之处”。此外，在参数设置时，应该多考虑参数初始化时是否为固定值，将不必要的参数移除，以使得方法的调用更加简洁，同时无形中减少了参数数量或次序输入错误而导致的bug。
发现BUG的策略
1）先根据错误分类树构造全面的测试样例，尽可能覆盖所有可能出现的bug。
2）检查程序对非法输入的处理，能否保证程序在任何情况都不crash，充分测试程序是否具有良好的鲁棒性。
3）认真阅读代码，尝试理解代码而从逻辑层次上发现可能出现的bug。
心得体会
1）多多阅读指导书以及issue上的内容，尽量避免应理解偏颇导致的bug（这种bug通常都是成群出现的）。
2）写程序之前先理清思路，尽可能简化逻辑，使每个类以及方法拥有独立且明确的职责，避免使用多层的嵌套以及过多的分支语句使用。
3）写代码之前认真思考自己的设计是否遵循了SOLID原则，这五大原则不仅为我们的调试带来便利，更会使得程序拥有优良的拓展性，这对于OO这样“逐层上升”式的作业是很重要的。
