OO第四单元——终章

• 2020 年 6 月 17 日
• 筆記

一.架构设计

　　这一单元的作业主要是围绕UML来对我们的面向对象思维进行训练，刚开始接触的时候或许因为些许陌生而觉得有一定难度，但随着一次一次的代码阅读再加上思考，逐渐地也变得得心应手了起来。

　　1.第一次作业

　　本次作业最终需要实现一个UML类图分析器，可以通过输入各种指令来进行类图有关信息的查询。

　　在刚下载完官方的源码时，面对规模庞大的代码，我一时也不知道从哪开始读起，便硬着头皮直接开始按循序阅读，结果还没读完几个java文件，我就感觉读不下去了，一是因为有很多语法我并不是特别熟悉和了解，还有就是觉得读完似乎对这次作业的需要完成的代码没有什么帮助，便直接打开需要实现的接口代码，结果发现有很多类都需要我去使用。后来在和同学的讨论下，，原来只需要把element文件夹中的代码都通读一遍就基本上没有什么问题了。

　　在参考了讨论区后，我便做出了以下的层次设计，首先增加了一个接口TopClass，并创建了两个类MyUmlClass和MyUmlInterface分别实现这两个接口，以便后续的对这两个类的调用，并考虑到方法可能较为复杂，便又创建了一个MyUmlOperation类，用来管理参数。在每一个对应的MyClass中，我都存储了官方包中自带的类，以便于获取ID和name。

　　2.第二次作业

　　在第一次作业的基础上，第二次作业要求我们扩展类图解析器，使得可以支持对UML状态图和顺序图的分析，可以通过输入相应的指令来进行相关查询。

　　其实只要按照第一次作业的思路来进行建构，第二次作业并不是很难，就是增加几个类，恰当地管理存储某些数据。不过为了代码风格和进一步的划分各个类的职责，我又新建了一个ElementAnalyse类，用来将传入的所有的element分辨管理存储好，然后主函数直接调用get方法即可获得处理好的类图，状态图和顺序图的数据，并进行后面的操作。在第二次作业中，因为需要用到状态机，所以我专门创建了一个MyStateMachine类，用来管理UmlStateMachilne，这个类中存储的即是那些需要管理的数据。对于状态图的管理，我同样创建了一个MyInteraction类，其中存储了生命线和各个消息，方便进行统一管理。

　　3.第三次作业

　　第三次作业与前两次不一样的是，在上次作业基础上，扩展解析器，使得能够支持对UML顺序图和UML状态图的解析，并对模型进行有效性检查。

　　所以第三次作业如果是在前两次作业已经有了好的框架之后，便只需要实现一些函数即可，我便是在交互的主函数中实现了那8个接口，并在我自己的管理三个图的类中增加了一些判断的方法，总体的架构和前两次相比较基本没有什么变化。

　　4.这三次作业的bug情况与反思

　　对于第一次作业，我刚开始抱着应该很简单的心态，试图在周六最后一天可以完成，结果万万没想到的是，实现起来还是有着一定的复杂度的，所以没有及时的完成，成了我的第一个未提交的作业，但后来在与同学的讨论中，逐渐地完善了自己的架构，这次作业也就算是完成了。而对于第二次作业，因为有个地方没有加上判断是否已经访问过就直接进行访问，导致出现了死循环，对应的强测也就出现了ctle，但在发现问题后及时地改正了bug。至于最后一次作业，或许是因为没有太注意题目的意思和各种特殊情况的讨论，导致在判断rool0的时候忽视了对名字为null的讨论，wa了好几个点，最后在修复的时候加了特判便通过了。

二.四个单元的架构总结

　　刚开始接触OO的时候,并不太注重整体架构的设计,往往是想好了实现的算法,便直接像数据结构那样,开始了方法的编写,偶尔新建的几个类就像struct一样,一点也没有体现出oo这门课的精髓和思想,在第一次作业中,输入输出中间处理的所有内容几乎都挤在了一个类里,到后来的时候分出来了输入处理和输出处理以及化简的过程,再到后来对每个类都进行精心的设计,或许这就是架构设计的慢慢进步的过程.到第二单元多线程,这时候架构的作用更体现了出来,如果不像老师上课讲的那样设计不同层次的类以及处理类的时候,整个工程可能会变得不堪重负甚至漏洞百出,当然为了提升性能我们不应该只看重算法,更应该仔细想想如何让在结构的设计上让代码的水平更胜一筹.而像第三单元JML,在第一次作业相信大部分同学都犯下了翻译需求的错误,没有重视到整体架构的设计,导致出现了千奇百怪的错误,也就是那次作业,让很多同学的爆0,没有进入互测,所以在接下来的后续两次作业中,我们都开始将重点放在整体的架构设计上,让代码的质量进一步提升.最后一个单元则更是如此,算法的方面其实完全可以被层次设计和架构设计所替代,只要架构设计的够好,算法再差整个工程也不会差到哪里去,这一单元的作业就是完全由我们自己来设计,指导书上并没有给出任何的提升,当然,这次训练也让我们的OO思想得到了极大的升华.

三.四个单元的测试概况

　　当然,我们学习OO课并不仅仅是学习编程思想,工程思想和那些总体架构的思想,我们的测试水平也需要在OO课的学习中不断地进步.在第一单元的测试中,我完全采用了自己编写java程序创建测试数据随机测试的数据模式,一边计算机在生成数据,一边shell文件在自动测试对比,大量的随机数据总能将bug测试出来.第二单元也是如此,只不过使用pathon生成测试数据要更简单一点,仍然是通过自己编写的自动评测机自己在完成大规模的数据测试.到第三单元时,我开始逐渐地使用起来JUNIT来作为辅助测试,单元测试的话更有说服力,测试的力度更大,范围更广,但是数据仍然需要自己去构造,JUNIT的最大的优点就是所有的代码都能被测试到,不留死角,但需要提前设计好测试框架与环境,这也需要一定的经验和练习.对于第四次作业,同样是采用JUNIT单元测试,再通过构造各种极端的样例来达到测试的目的.

四.课程收获

　　OO这门课是大二下学期和操作系统类似的大课重课,不仅难度大,需要我们花费的时间也很多,当然,有付出总有回报,在完成这么多作业的设计与编写,我的OO思想和编程思想也有了质的提升,再也不是仅仅拘泥于算法的设计,而是更注重层次化,抽象,与架构的设计.往最差的情况去想,JAVA这门语言也算是被我们熟练的掌握了.这门课带来的收获绝对不止停留在java这个语言上,对信息领域的任何地方都有着不小的帮助,因为不管什么项目都需要设计,设计都会用到这些方方面面的思想,相信在以后的工作和学习中,这门课所教会我的思想将一直陪伴在左右.

五.具体改进建议

　　(1)第一单元的作业难度对于刚开始接触OO的同学们来说难度可能有一点大,可以在寒假的预习作业中更多地去设计一些相仿的地方,减小同学们学期开始的压力.

　　(2)研讨课讨论的时候对于有些问题可能是一知半解或者不知道答案,直接找同学回答可能不是什么特别好的主意.

　　(3)第四单元的第一次作业的指导书上可以增加以下对阅读官方代码的建议与提示,要不然太多的代码对于某些同学来说可能是一个极大的挑战.

六.线上学习感受

　　感觉OO这门课线上线下的区别不是很大,除了见不着英姿飒爽的老师们和可爱的学长学姐们(似乎没有学姐),其他的没有什么太大的变化,就是在写作业的时候不太方便与同学互相debug与交流,其他的问题都不大.还有就是上理论课的时候并不能直接和老师语言交流,少了一点氛围,但录播课的好处就是可以在不懂的时候看回放,加深理解.