BUAA_OO_第四单元作业总结&课程总结

一.第四单元总结

这个单元的任务，是在课程组下发的的demo基础上实现接口解析UML图的元素，并实现UML规则检查以及查询功能。UML-Unified Modeling Language 统一建模语言，又称标准建模语言。是用来对软件密集系统进行可视化建模的一种语言。UML的定义包括UML语义和UML表示法两个元素。

代码架构分析

第一次作业

由于第一次作业实现的功能只包含类图查询，因此我直接把所有需要实现的接口方法放在了MyUmlInteraction类中。这样做下来，其实很容易发现这个类代码太臃肿了，基本上就要超过500行的文件长度限制，所以在第二次作业中就不得不进行重构，把查询任务分配到下一级类中。另外，我认为这个单元的作业难点就在第一次作业，因为我在编写代码时考虑的最多的是如何组织这么多元素：不仅要考虑class、interface这种父类元素，考虑attribute、operation这种子类元素，parameter这种“子类的子类”元素，还要考虑association（关联）、realization（实现接口）、generalization（继承）这种特殊的带有方向性的元素。经过权衡，我选择了HashMap这种优秀的数据结构来储存各种元素，以及元素之间的关系。所以在我的代码中，使用了特别多的hashMap（使用量之大，我也是没想到的）。
在确定好数据的组织方式后，就要在构造方法中实现这些组织结构。第一次作业的构造方法就是简单的“单个判断+单个构造”，在之后的作业中，由于构造代码量太大，我使用了工厂模式。确定好上面的基础之后，其实这三次作业也就不难了，就像助教说的“迭代特别容易”。下图是第一次作业UML图。

第二次作业

这次作业在第一次基础上增加了对状态图和顺序图的查询。我在完成这次作业时的重点主要有两个，一是把类图查询、状态图查询、顺序图查询的方法下放到三个具体的类中；二是使用工厂化模式初始化数据结构。使用工厂化模式，一种简单的方法就是使用hashMap，通过它的get方法取出对应的数据。这样做的好处是减少代码的重复、代码逻辑也更加清晰、迭代更加方便。

第三次作业

第三次作业要求检查UML图的正确性，也就是检查语法规则。在前两次作业的基础上，这次作业不难（依然是使用hashmap数据结构，依然是对图的遍历查询），UML图如下。

代码测试分析

第四单元很不幸，第一次作业和第三次作业都被检查出了bug，而且都是死循环CPU TLE。本来这种bug可以避免的，第一次是因为忘了在进行图的遍历时存储经过点、第二次是因为脑抽忘了我是在处理图（我写代码时一直认为我在处理树。。）教训深刻，我在手动构造数据时只专注于代码结果的正确性，没有构造一些刁钻的数据导致翻车。第四单元我偷懒了，没有写测评机，（但其实就算写了测评机，随机数据也很难测出死循环这种错误，要不然为什么我第三单元最后一次作业翻车如此之惨。。），之后的死循环错误需要引以为戒。

二.四个单元的架构设计&OO方法演进

• 第一单元：多项式求导。第一次正式接触OO课程，我对架构的理解不深刻，写代码时依然沿用的面向过程思想。结果就是一堆类的功能不明确，代码重复严重。第一次作业还好，但是到了后两次作业，想进行重构都来不及了。总的来说，第一单元考验的是对正则表达式的理解和使用，还有代码的结构层次。
• 第二单元：多线程电梯。经历了第一单元的磨炼，第二单元做起来得心应手了一些。我在写代码前先规划好了每个类的作用，因此在后两次作业中，对新的要求我只进行了少量的方法更改。第二单元的难点是线程调度以及线程安全，我么们要选择合适的调度方法，以及使用synchronized关键字使得线程互斥。在这个单元的学习过程中，我们学习了许多经典模式比如消费者生产者模式、观察者模式等，强化了多线程设计能力。因为有了明确的代码架构，我也有时间进行代码性能的优化，以及编写测评机。总的来说，第二单元考验的是多线程间的同步与互斥，这两个功能正确实现之后基本没有问题了。
• 第三单元：JML。第三单元考察的是对方法的管理。在课程组下发的demo中，每个需要实现的方法都用JML语言描述，需要我们用java语言正确实现这些方法。在这个单元，老师反映的情况是：同学们都太过依赖课程组的模板，没有仔细思考如何合理地分配方法到具体的类中，导致代码臃肿。我的代码也完全是按照demo模板编写的，欠缺了应有的考虑。此外，在编写代码时，必须要认识到JML语言和java语言的区别，一味地模仿JML只会导致超时、死循环。总的来说，第三单元就像是给出了伪代码，需要我们用java语言实现出来，另外需要我们合理安排这些方法的归属类。
• 第四单元：UML图分析。第四单元考察对数据的存储、分析。这一单元应该来说对代码架构的要求是仅次于第一单元的。在实际的开发中，我们也会面临大量的数据，如何存储这些数据影响到代码的性能以及之后的迭代开发。由于元素之间相互链接：包含关系、单向关系、双向关系，需要我们合理组织数据。在动手写代码前，我思考了很久关于数据的存储，最后得出了一个我认为最好的办法，因此在后两次作业中我的代码任务也轻松了很多。总的来说，第四单元提高了我对大量数据的整合分析能力。

四个单元的演进，让我的抽象、层次思维能立有了很大的提升。写代码时，我会更加考虑到将来的迭代，因此对代码架构、数据存储三思而后行，这就是我在OO中学到的最重要的思想吧。

三.四个单元的测试&实践

• 第一单元。这个单元我还没有实现测评机的意识，还只是认为“只要手动构造几个数据不就好了”。事实证明我错了，有些数据构造起来要人命啊，数据量太大了。这个单元，我有幸得到了同学的测评机的帮助，因此代码功能的正确性得到了保障。自从这个单元之后，我就开始写测评机了（总是向同学要测评机也不太好意思，另外自己的测评机改起来也方便）。
• 第二单元。我写完第一次作业之后就开始了测评机编写，使用的是随机数据模式。测评机包括了数据生成部件，和结果检查部件。因为第二单元的结果较容易得出，因此不需要与同学对拍即可实现。另外，在开发测评机的过程中，我发现这也是一种迭代开发，充满了趣味（至少比作业好写多了）。因为有大量的数据支撑，第二单元我也没有被检查出错误，由此我更加坚定了写测评机的想法。
• 第三单元。这个单元我也实现了测评机，不过这次需要和同学对拍来检查正确性。前两次作业都得了满分，唯独第三次作业翻了大车--时间复杂度过高，我被hack了一半的点，只得到了50分。这次滑铁卢让我明白了一个道理：随机数据不太行啊！还是要手动构造一些刁钻的数据。另外，这单元我们接触到了JUNIT自动化测试工具。我使用后，感觉JUNIt虽然能够手动测试一些刁钻的数据，但是无法达到大量数据的测试。所以，最好的方法还是JUNIt与测评机相结合吧。用测评机实现数量级测试，JUNIT实现手动构造测试。
• 第四单元。这个单元我没写测评机，因为感觉比较简单，手动构造数据也可（其实是因为数据不太好构造了，想偷懒）。由于手动构造的数据不能面面俱到，我在两次作业中都被hack到了超时的数据点，挺可惜的。

四.课程收获

我的课程收获就是养成了面向对象的思维。在大二上学期选择的java课程中，由于没有系统地学习面向对象，我对java代码的编写还是使用的面向过程思想，经常是“一main到底”、代码臃肿混乱。但是学习了OO之后，我写代码都是三思而后行，更多地考虑到代码修改的难易程度（一想到之后艰巨的重构任务就脑袋疼）。我还学习了java的许多经典开发模式，建立了层次化的思想，学会站在对象层次思考问题、分析架构优劣，这就是面向对象的精髓吧。

五.改进意见

• 与课程配套的实验课是很好的，但是希望能在实验课前多给一点预习建议和指导。在JML单元的实验课上，代码量太大，没有时间阅读或者作答。在垃圾回收实验课上，堆机制较为陌生，而且代码量也太大。
• 老师在每次的理论课后都会耐心地在微信群组织讨论课堂问题，殊不知这时有人已经在下一门课程中了。（哭笑）也许可以使用问卷星的方式搜集同学们的回答？（但是这样的话课堂互动效果就不好了，需要权衡考虑）。
• 关于第四单元的课程讲解我认为还不够透彻。可能是因为第四单元的内容比较多，包括类图、状态图、顺序图，而且又临近烤漆，时间紧迫。在课后作业中，我是通过看样例才理解了UML图中的各个元素。

六.线上学习体会

我觉得线上学习的好处是：可以选择适合自己的时间进行学习、大家参与讨论也不会有所顾忌、视频可以反复观看预习和复习。我认为不好的地方：对于自控能力较差的同学不友好、线上交流学习不如线下方便快捷、学习氛围较弱。