OO第四单元总结博客

一、UML单元作业架构设计

这单元给人的感觉就是看上去不难，实际上完成后代码“千疮百孔”。众多bug主要集中于对于指导书的理解不到位以及编写的不严谨上。

• 第一次作业

  • 这次作业相对轻松，关键在于构造出拓展性比较高的架构以备后面复杂的需求（将类、接口、方法分别各自需要管理的属性封装，interaction中调用各自的方法即可），需求本身相对于后两次作业本次作业没有那么复杂。
  • 整个UML分析的过程是怎样的？
    • 首先，根据数据类型分别用类、接口、方法的单一实例来存储数据（设计模式中的“单例模式”）。在数据输入接收后分别进行处理：让各个元素的继承、实现等关系在容器中真正体现出来。最后调用的时候根据容器中包含的关系进行分析（这里为了性能需要维护变量）
  • 如何维护变量？
    • 和第三单元一样，我们要尽可能复用已经计算过的结果，具体就是每次调用方法时判断是否容器中已经存在所要结果，只有不存在才重新计算。
  • debug
    • 这次作业最头疼的反而不是架构和如何编写方法，而是一些细节问题：比如需要判断方法是否相同需要重写hashcode，结果中测结束后才发现自己写错了（按照题目只需要判断参数类型是否一致，结果把所有方法的属性都给考虑了），所幸强测没有hack出来。

• 第二次作业

  • 由于第一次架构比较合理，第二次架构上没有变化。不过有一件工作量比较大的就是因为checkstyle对于java文件的行数限制，需要将每个指令的具体实现迁移到类内部方法实现（其实第一周就可以先做这件事）。
  • 其次将处理数据的过程也迁移到类内部
  • debug
    • 在维护变量时候，搜索所使用的容器上出现错误（存储数据的容器用成计数的容器），属性命名应该更清晰一点以防止这样的问题。

• 第三次作业

  • 本次作业考察对于异常数据的check。其中有一些如循环继承、重复继承，需要特殊的数据结构来进行数据保存和查找。而架构上同样不需要改动。由于对于指令不算太多，可以使用dfs或者bfs进行搜索，并在每次计算过后保存结果。

二、四个单元中架构设计及OO方法理解的演进

• 第一单元
  • 第一单元是四个单元最为艰难的一个单元。一方面对于OO以及这门课程对于我们工程设计考察的理解不够深入，第一次作业仅仅是应付一下本次的需求，完全没有顾虑拓展性，而第二次作业复合要求要求我们最好使用递归下降处理左递归，但如果仅满足于第一次作业是不会考虑这一点的。这就导致了第二次作业重构的灾难。后面两次作业几乎都是周日才通过中测，第三次作业甚至提交达到了10次。当然，吸取这个单元的教训，后三个单元都对可拓展性上进行了考量，没有重蹈覆辙。
  • 其次就是面对对象思想。函数的每一个元素都是一个对象，将对象抽象为对应的类进行分析，这当然不是OO的全部，但也是最基础的一种思想。
• 第二单元
  • 这一单元比较用心地考虑架构设计、调度策略、线程安全，也更多地尝试构造数据用于自测和互测。可以说是各方面能力都提升比较大的一个单元。架构上从观察者模式到四线程的请求模拟器-调度器-电梯-策略类再到最后取消策略类线程优化，架构虽然没有一开始就达到完美，但是大体方向正确，在迭代过程中逐步修正达到了比较好的效果。调度策略上试验了很多如SCAN、LOOK的策略，对电梯的性能不断优化，也是从这单元让自己从思想上获得由“功能正确“到”提高性能“的提升。
  • 本单元第一次尝试用SOLID原则分析代码，通过这些具体指标让自己对于工程整体上有了更加科学、透彻的认识。
• 第三单元
  • JML规格单元，可以说是OO课程带给我们看代码的另一个视角——如何规范设计，在编写之前完成对代码正确性分析。当然，在本次作业实操过程中，还复习了一边数据结构的常用算法。
• 第四单元
  • 这一单元和第三单元风格类似，尤其是在维护变量上使用的数据结构和技巧上。这一单元主要是在理解UML图的基础上，完成解析器的编写（其实感觉是不是这一单元应该放在最前面）。

三、测试理解与实践的演进

• 第一单元
  • 使用python随机生成数据。开始是完全随机，但后来发现这样针对性太差，所以根据作业要求调整了生成数据生成范围，”手动+随机“，获得了不错的成果。
• 第二单元
  • 随机生成数据不是很管用了，因为很多bug都是由于策略问题导致的超时。这就要求我们根据代码分析策略，然后构造对应最复杂的数据。这一单元的针对性更强了。
• 第三单元
  • 本单元用了较为丰富的测试方法，可以说是四个单元里最完备的一次，因此强测的分数也是最高的。
    • 对拍机。起初使用纯随机数据，和第一单元一样效果不大。结合了一定的人工构造。（先添加大量点及边，对Group进行反复修改操作然后进行随机）
    • 使用JUNIT单元测试对方法进行逐一功能检查。不过这一功能实际效果并不好，因为方法之间互相调用难以测试。
    • OpenJML用于验证规格编写的正确性。
    • JMLUnitNG——自动化的JUnit。在规格严格正确的情况下生成数据并自动测试，数据多为边界数据。
• 第四单元
  • 白盒测试。完全根据需求构造针对性数据测试功能。不过由于后面复习挤掉了一些debug时间，使得测试不太完备。
• 总结：整个学期测试和以前相比称得上质的飞跃：既有黑盒测试、白盒测试多种类型的方式，又有随机、针对性构造等不同层次的数据测试，让我养成了全面、深入调试的习惯。

四、课程收获

• 整个课程分为四个单元：求导、线程并发电梯、JML、UML，各有侧重，每个单元又为分三次小作业增量迭代，每次作业有弱测中测强测互测，测试程度几乎称得上完备。最后第四次作业作博客总结。这一套下来给我的感觉就是课程设计十分饱满，既有广度，又有深度，增量迭代既可以让不同程度的学生都能收获成就感，也能让我们体验工程设计的实际流程，同时每单元的总结加深对过去教训与经验的印象，感受自己的提升。“中国有两种OO课，一种是北航的OO课，另一种是其他OO课”。初来乍到没有感觉，但一学期的课程让我确实体会到：此言不虚。当然，为了让我们真真正正地掌握知识，课程难度是比较大的。尤其是第一单元和第二单元，在第三次作业时明显感到吃力：那两周都是到了周日中测截止日期前几小时才通过中测，可以说大半个周末都砸进去了。不过，bug找不到的时越让人捶胸顿足，最后通过时的喜悦就越是无以言表。

• 累并快乐着，这也是本学期的最大感受。累是真的累，从周三晚上开始研究指导书到，周四、周五编写、测试、优化，到第二周又要进行bug修复和互测，可谓充实。这种充实伴随着各种能力的提升：基础编程能力自不用提，面对对象思想、设计模式、设计策略、线程安全、设计原则的理解以及调试能力。

• 最后希望将来还能遇到这样”硬“但”好“的课。

五、给课程提三个具体改进建议

1.根据大家其他课的排课安排强测和互测时间。比如互测期间有一天基本被操作系统的理论课和上机占掉，可以往后延长一天，这样互测的效果也会更好。

2.第一章的作业需求可以改进，因为感觉不太符合面对对象思想，尤其是性能优化方面。

3.对于每个单元的测试，虽然课程组在指导书中有提到一些方法，但是可以给出更丰富和详细的引导。虽然现在大家也基本都会一些简单对拍和数据生成，但是如何更好地提升测试完备性，加强调试能力，课程组对此可以有针对性地给出指导。