2018 OO第一次总结（做业1-3）

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　第一次做业
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时给予咱们的忠告，但愿时刻能提醒本身。