OO第四单元总结——UML图解析器 & OO课程总结

OO第四单元总结——UML图解析器

第一次作业

架构设计

第一次作业要求我们实现一个UML类图解析器,架构方面我使用了适配器模式,将UMLClass等类各自封装成一个保存有其各种信息(如Class中的方法、属性、关联等)的适配器UmlClassInfo。在输入时先将所有UmlElement保存起来,再逐一进行重建,以防输入顺序(找不到爹)的问题。同时,只处理有用的信息,如与UmlClass关联的UmlInterface就可以只计数,不用管到底是关联了哪个接口。Uml类图如下。

bug分析

本次作业在强测中测出了一个bug,是由于测试数据中UmlInterface的大量继承造成的超时,在将UmlInterface的寻找所有继承的接口方法进行缓存之后解决。

第二次作业

架构设计

第二次作业中增加了顺序图和状态图的解析,由于要求的解析中三张图是完全独立的,我分别建立了MyUmlClassModelInteraction、MyUmlCollaborationInteraction和MyUmlStateChartInteraction三个类分别用来解析三张图,在MyUmlGeneralInteraction中将所有的指令分配给三个类进行完成。Uml类图如下。

bug分析

本次作业在强测中也同样测出了一个bug,是由于没有考虑到顺序图中的EndPoint导致RE。

第三次作业

架构设计

第三次作业中增加了对于UML图合法性的检查。延续第二次作业的架构,我还是将八个检查分配给三个图(其实是两个),在其内部进行检查,只留一个对MyUmlGeneralInteraction类的接口。其中Uml002使用了Tarjan算法求强连通分量,判断重复我采用了比较分别用HashSet和ArrayList保存的元素的个数的方法。由于本次仅仅在第二次作业的基础上增添了一些方法,并未新增类和接口,Uml类图和第二次作业完全一致。

bug分析

本次作业在强测中再次出现了一个bug,是Uml002的检测中少检测出了一些接口,初步判断是Tarjan算法写错了,目前还没有修复。

OO课程总结

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

  • 第一单元,表达式求导,我认为重点在于如何抽象一个对象。如何用一个类表示一个表达式/一个项,如何让其具有被求导的能力,如何实现项之间的关联,等等。这一单元在我看来我主要做的工作就是思考如何将一个概念抽象成一个类结构,同时用继承等的方式构建,或者说还原概念之间的各种关系。
  • 第二单元,多线程电梯调度,重点在于多线程。上学期我曾经选过Java程序设计这门课程,其中有一项大作业,我在其中曾经尝试使用了多线程的方式,结果出现了许多线程安全问题,最终还是放弃了使用多线程。这让我对多线程有了心理阴影。但是在系统学习了多线程的知识之后,我还是圆满完成了这一单元的任务,认识到解决线程安全问题其实并没有那么难。
  • 第三单元,JML语言,重点在于契约式程序设计。这也是我过的最惨痛的一个单元,第一次作业就迎来了“不存在此互测成员”的惊喜,这也与我没有深入思考架构,只是挨个完成方法的做法有关。这一单元对我而言感觉更注重算法的考察,JML的内容也更贴近工程开发方面,OO味反而不是那么浓了。
  • 第四单元,UML图解析器,重点在于UML图的理解。第四单元的难度有所降低,我认为重点与第一单元类似,还是在于如何抽象出一个对象,只是这里的对象变成了类、方法等概念,有点套娃的意思。与第一单元不同的是,第一单元的多项式这一概念我们早已十分熟悉,基本无需多言,而UML图这一概念则是新概念,需要在深入理解的基础上进行思考如何抽象,难度更胜一筹,好在要求的功能比较简单,只是一些简单的查询。

四个单元中测试理解与实践的演进

测试代码与编写代码一样,都是一个项目完成过程中重要的一部分。在我看来,我在测试这一方面做的不是很好。四个单元基本上都采用了手动构造测试样例的方式,第一单元是利用了python库得到求导的正确答案,之后进行比对;第二单元在代码内部编写了两种输入方式,一种是要求的输入,另一种是从文件读入带时间前缀的输入,用于测试,而正确性只靠了肉眼识别,没有编写额外的正确性判断程序;第三单元尝试使用了JUnit单元测试,然而自己编写的样例并没有测出什么致命的bug,而TLE的性能问题更是无法测试;第四单元是在starUml中绘制一些手动构造的样例,用官方包导出后进行人肉正确性判断。可以说,我在测试时还是过分依赖中测评测机,而这一点在第三单元中测过弱的情况下得到了致命打击。

课程收获

  • 既然是OO课,对面向对象思维方式的收获肯定是最大的。学习OO之前,对于OO的理解不是为零,但也仅限于“封装、继承、多态”这三个词。而这一学期的学习,通过四个单元的训练,我对于OO的理解更加深入,也能更自然的用面向对象的方式来思考一个问题。
  • Java语言的熟练使用也是一个巨大的收获。Java作为一个工程化的语言,有广泛的应用,经过这一学期几千行代码的训练,我对Java语言也有了较熟练的使用。
  • 还有码力的提升。周二发布,周六ddl的紧迫要求下,我的码力也有了很大的提升,可以在较短时间内基本完成从架构到编码再到测试的流程。

改进建议

  • 实验课在结束后给出结果。能知道自己是否做对了,或者错在哪里;现在这样在实验课结束后没有反馈,也不知道自己对实验内容的理解有没有问题,有什么问题,学习效果不是很好。
  • 第三单元的中测强度实在太弱,我认为至少也应该与其他单元近似,否则中测的意义就削弱了许多。
  • 每次作业给出下次作业的大致扩展方向。这样在思考架构时就可以更好地考虑扩展,否则很有可能想的太多或者太少,浪费很多精力。
  • 第三、四单元的运行时间限制可以改成性能分的形式。我认为对OO课程来说算法的优化并不应当是考察的重点,第三单元给的CPU时间限制有点过于紧张,搞得像数据结构或是算法课程一样,大家都在优化算法,侧重点有些偏离;而第四单元又完全放弃了考察运行时间,直接给了10s,除非特别严重的嵌套绝无可能超时。性能限制改成性能分的形式也可以鼓励大家尽量去优化算法,而保证正确性可以得到一部分分数,我认为这样较为合理。

线上学习体会

其实感觉对于OO课程而言,线上学习的影响并不大,作业和实验都没有受到什么影响,只是研讨课的气氛有些冷清。这也是史无前例的一学期了。

原文地址:https://www.cnblogs.com/DongzyHome/p/13126827.html