第一次作业
1.程序分析
（1）OO度量
（2）类图：
（3）分析与评价：
这次作业由于作业整体设计难度不大，因此按照去年暑假上的OO先导课老师讲的设计方法很容易实现一个还不错的面向对象式程序，类与类之间的耦合度不是很高。但是即第一次简单的作业还是在设计上出现了漏洞被找到了bug，说明设计做的还是不够充分。
类图分析：本次设计分为Poly类，InputDeal类，Main类，Item类，其中Item类实现了Comparator接口，Main类主要进行主函数运行。Item是一个项数和系数的偶对，并且通过Comparator接口进行按照指数递增的顺序排序。InputDeal的主要作用是对输入序列进行处理，包括合法性检查。
2.
本次作业公测所有测试样例点全部通过，互测的时候被发现一个bug，原因是若出现(0,0) (0,0)两个指数和系数都为0的程序不会判断(0,0)是指数重复。出现这个问题的原因是程序采用了链表存储相应多项式信息，首先会将系数为0的项删掉，使其不能加入到链表之中去，然后再进行判断是否出现重复指数的操作。这次错误出现在InputDeal类的read_poly方法之中。
从设计结构角度来看，这个bug出现的原因主要还是在于自我设计的时候没有将设计的前后顺序等弄明白，程序的流程控制出现了问题。
从分类树角度来看，虽然在测试的时候注意到了指数重复这个错误树分支，但是测试使用的相同指数情况没有构造出系数为0的情况，系数为0的情况主要被用于测试当多项式最后为空的时候的输出是否正确。
3.测试策略：自我测试的时候按照分支树生成了测试数据，先对对方进行粗测，再结合代码进行进一步测试。
这次作业抽到的同学公测出现了一个bug，表现形式是会多输出一个逗号。经过阅读代码以及调试，发现原因来自于输出控制不当，当最后计算结果幂常数项为0的话会多输出一个逗号，因为这个逗号是放在所有系数和指数都不为0的项输出之前的。由于此次任务比较简单，针对自己有疑问的几个带代码片段也进行了针对测试，并未发现问题。
第二次作业
1.程序分析
（1）OO度量
（2）类图：
（3）分析与评价：
这次作业经历了从模拟时间到记录请求完成时间来判断同质两种设计方式的转变，单就本次作业来说，后者的编程复杂度远远比前者低。存在的最主要问题就是在遇到一个稍微复杂的问题时候如何快速而且合理地划分出不同的类，如何合理分配每个类的行为与方法。
类图分析：本次设计主要分Main Request Queue Floor Lift Scheduler类这几个类，Main类是运行主函数，当从main类输入一条指令会送到Floor或者Lift类进行合法性判断，并由电梯和楼层类发出请求（向Queue对象中插入一个Request类对象）。然后输入完毕后调度器依次遍历Queue请求队列中的所有请求，输出多了人类主要有schedule方法（负责判断同质以及调度），pop方法将输出当前执行过的请求并打印出相应的信息。
2. 本次作业公测和互测部分顺利通过
这次作业让我认识到了bug和设计结构密切相关，本来是采用了模拟时间的写法，但是在几个开关门瞬间的理解条件总是处理不当，导致总是出现了各种意想不到的bug。后来采用了记录按钮熄灭的时间来判断是否是同质请求，代码逻辑变得简单起来，后期调试和测试也简化了不少。
3.这次程序最后并没有在互测阶段发现对方的bug，但是在尝试找bug的过程中收获了不少的知识。
采用的测试策略：先使用自己编程的时候构造的分支树测试样例对对方程序进行粗查，随后结合代码对可能出现的隐患位置进行重点攻破。
在浏览一遍对方的代码之后，发现了一个很有可能出现问题的情况：对方读取时间的正则匹配是无限个数字，但是在将字符串转为数字的时候并没有try-catch去捕捉parseDouble产生的异常，这个地方最初在我看来是有很大隐患的：double的数据范围也是有限的，假设输入时间位数超过double的范围，且最高一位是1，其余位是0的话，如果发生溢出，高位丢失，然后就会出现将一个很大的数读成0或者是直接程序crash。但是经过尝试发现每次都没有出现问题，到此处单步调试后发现原来的数字被读成了infinity，而且这个infinity默认大于所有的数。上网查阅资料发现infinity不等于MAX_DOUBLE,而是大于MAX_DOUBLE,于是构造MAX_DOUBLE 和infinity之间的数字，但是结果发现在eclipse之中只要超过MAX_DOUBLE 就会识别为infinity,与资料不符。这个过程中虽然最后证明了该同学的程序不存在问题，但是我仍然认为在使用这种有可能出现异常的函数时应该养成使用try-catch的习惯。
第三次作业
1.程序分析
（1）OO度量
（2）类图：
（3）分析与评价：
这次作业由于第二次作业的设计方法对于这次作业来说不是很适合但是又必须继承第二次作业的关键类，所以在修改的过程中为了追求代码的正确性牺牲了许多老师提到的良好的设计习惯。最大的体现就是核心类的方法过多，每个方法代码长度比较长，而且分支结构太多，这些都是代码的隐患，在以后的作业中要尽可能的避免这类情况的出现。量化分析结果也表明块嵌套层数过多，这种问题以后在编程的时候一定要注意。
类图分析：本次设计主要分Main Request Queue Floor Lift Scheduler NewScheduler类这几个类，Main类是运行主函数，当从main类输入一条指令会送到Floor或者Lift类进行合法性判断，并由电梯和楼层类发出请求（向Queue对象中插入一个Request类对象）。然后输入完毕后调度器依次遍历Queue请求队列中的所有请求，对是否同质以及是否可以捎带进行判断。其中is_same是判断是否同质的方法，而set_mr是设置主请求的方法，update是在进行捎带之后更新到达指定楼层的方法。
2.自我程序分析
本次程序顺利通过公测和互测环节，但是完成程序初稿的过程就遇到了不少的bug。这些bug主要集中于对上次的类Scheduler继承后重写的新的schedule方法之中。这次在编写后程序明显感受到了第二次设计样式的不足，第二次主要是模拟当前按钮熄灭的时间并没有关心当前电梯的运动状态，这种写法在第二次设计起到显著的简化设计的作用，但是却为第三次设计造成了许多困扰。
3.测试方法
本次测试仍然是采用自测的时候按照测试树生成的测试样例加上采用结合代码进行针对测试。但是这次在使用自测的样例的时候就测试出两个问题，一个是同质请求判断的问题，另外是捎带情况处理的边界条件没有处理好。阅读代码后发现同质请求判断失败的主要原因是只判断了相对于主请求是否是同质请求，而没有判断相对于其他捎带请求是否同质。
总结
1. 关于设计问题
第二次作业原本的设计是想模拟现实真实的状况，在外部模拟一个系统真实时间，把请求映射到电梯按钮的熄灭和按亮状态，只有在时间到达了相应的请求发出时间请求才会开始被访问，但是这样写出来的代码跟同学的直接记录这个请求完成时间来判断同质相比还是显得复杂了一些。于是便也采用了记录请求完成时间来判断同质的做法。但是第三次作业在第二次作业的基础上修改起来就很繁琐，也加上了许多判断控制条件，使得代码的结构以及逻辑变得极其复杂，还要对指导书上的捎带条件进行等价转换，整个过程十分复杂，很有可能需要在下一次的电梯作业进行代码的大量重构。经过第三次作业我深刻体会到了设计对于后续的修改以及调试起的决定性作用，一般来说，越是能模拟现实情况的设计在后期编写代码的时候就越容易实现以及调试测试。每次自己在测试找到bug之后更要及时反思原因，如果是编程过程出现实现不当，那么就要勤加练习，让自己的动手能力跟得上自己的思维。反之如果是设计过程中出现的显著漏洞，那么在每次作业之后一定要按时反思设计漏洞，不断规范设计流程和思路。
2. 善用eclipse的TODO标注功能
每次作业都不可能是一个下午和晚上就能够完全实现，而且每次编写代码的时候也不能保证某个地方的逻辑百分之百正确。在同学的推荐下，我开始使用eclipse的TODO标记功能，可以在有疑问的地方做下标记，后续作为测试的重点。晚上睡觉前或者是吃饭前可以对手头上的尚未完全完成的步骤进行标注，以便回来后继续完成。
3. 关于设计与编码的关系感想
第一次在课堂上听到老师强调设计的重要性是上学期计组课上高老师在P4之后反复强调在工程实现过程中设计的构思甚至花的时间应该超过敲代码的时间。快速写完代码后花大量时间找bug不仅让你整个工程的时间不会减少，更会让你的程序变成一个打满补丁而且不规范的程序。第三次作业度量分析之后被标红的部分（块嵌套过深）就是源于不停地向程序打补丁导致方法越来越多，调用越来越深。在今后的作业项目中一定要进行更细致的设计，甚至可以先构造大量样例对设计进行调试，确保设计的完备性之后再进行编码过程。在本文的最后附上上学期计组老师在做P5时给予我们的忠告，希望时刻能提醒自己。
