BUAA OO 第四单元总结

BUAA OO 第四单元总结

一、第四单元架构设计

第一次作业

作业要求

实现对Uml类图的元素分析

设计细节

本次作业的Uml类图如下

image

在第一次作业中,仅对UmlClass,UmlOperation和UmlParameter进行进一步抽象。由于Id的唯一性,在读取全部element时,利用hashMap将class,interface和operation建立索引,同时也将全部element建立索引便于后续查询。同时,对于class进行进一步封装,建立class下属的operation、attribute以及其对应的父节点等信息,便于后续查询操作,同理对于operation和parameter也进行了封装。

对于指令1、2、3,均可利用hashmap进行直接查询。对于指令4、5、6、7、8则均在MyClass中进行具体实现。在MyImplement中调用MyClass提供的接口函数即可。

第二次作业

作业要求

实现对Uml类图、时序图和状态图的元素分析,并实现相关查询接口。

设计细节

本次作业Uml类图如下

image

在上次作业的基础上,对新加入的元素Interaction、LifeLine、StateMachine、Region和Transition做了封装。并且由于输入处理的情况增多,新增了Utils工具类用于处理输入和在输入阶段对类图、时序图和状态图的建模。实际上对于建模的工作量才是最大的,在组织好相应类的模型和数据结构后,再进行查询操作就是一件很自然的事情。

类的内部结构方面,时序图部分,Interaction类维护LifeLine和EndPoint,LifeLine维护creator和相关message的信息。状态图部分,StateMachine仅维护一个Region,仅仅是作为对外的一个接口方便调用。Region中维护State和全部的Trigger,在预处理时,则把Transition里的Trigger全部抽出,并在两个状态之间连边。对于边的抽象在Edge中,具体而言就是维护了起点终点信息,和两个状态之间的全部Trigger。

对于新操作的实现,时序图部分,在预处理部分已经为三个操作准备好了相关数据组织,直接利用HashMap查询即可。状态图部分,指令1和指令3可直接查询,对于指令2,由于在Region中已经建立好了图,利用对图进行简单的BFS即可。注意在预处理建好图之后先对整体做BFS检测是否存在initial到finish的路径。

第三次作业

作业要求

实现对Uml类图、时序图和状态图的元素分析,并实现相关查询接口,并加入了模型有效性检查。

设计细节

本次作业Uml类图如下

image

在上次作业的基础上,要加入对模型的检查功能。对于本次作业要用到的新元素Association和AssociationEnd进行处理,需要在Utils中的预处理加入新的分支。由于方法复杂度进一步增加,对Utils的预处理过程进行进一步细化,同时在预处理过程中,将Association元素加入到MyClass类中,方便后续指令的处理。

在有效性检查中,R001可在读入的过程中完成,R005-R009在组织好数据结构和相关类维护的数据中,也能很容易的实现。稍微复杂的是R002-R004。对于R002,则在MyClass中通过其维护的attributes和associationEnd比较即可。对于R003,由于维护有Class和Interface的父子关系,利用dfs来找图中的环即可。对于R004,由于Class是单继承的,如果出现重复继承则会在R003中被检测到,其实只需要对Interface做判断即可,同样利用DFS,在递归过程中记录每个元素在递归过程中出现的次数即可。

二、课程总结

对OO方法和架构设计的理解

在这学期OO课程的培养下,最直观的进步就是感觉现在的代码还勉强能看,学程设和数据结构时候的代码实在没眼看。OO课程将层次化设计的思想贯穿始终,在进行具体的代码实现前,应当提前做好模块化的设计工作,要设计好数据与功能之间的关系。这一点不光体现在这门课程的代码实践中,在完成其他项目代码时,无论功能简单与否,做好设计工作都是一件非常能提高效率的事情。在写python的时候,不会再脑门一热,要写一个脚本就单独开个函数从头到尾写一遍,然后下次再有需要时发现之前的代码完全不具备复用性。一个好的架构,除了可扩展性之外,也能让整体的逻辑设计更加清晰,在debug时能够更快的定位,实现过程中也不会出现两天没看代码就看不懂了的局面(×对于更贴近实际的大型项目而言,面向对象的设计能够实现对整个大型项目的管理,对于整个模型的抽象的想法也能更好的指导代码实践。

对测试的理解和实践的演进

对于OO这门课程而言,测试恐怕比设计来的还要重要。在以往习惯了通过准备好的数据来对自己的代码进行正确性检验,这门课更让我意识到了测试的重要性。在第一单元,开始完全不懂要如何进行测试。在同学的帮助下,了解了递归下降算法,学会了如何搭测评机进行测试,但还是会出现某些边界情况没有办法覆盖到。在第二单元和第三单元的测试中,还要求对程序性能进行检测和评估。总体而言,对于测试只能说掌握了基本方法,但还没能够对整体的测试覆盖率进行评估。在造数据的时候,数据生成的逻辑也会启发到对代码的正确性检查,从某种程度上说,数据生成也是对代码进行检查的一个过程。

课程收获

  • 对于java的掌握

    代码实践永远是掌握一门编程语言最有效的方式。在写pre的过程中就能迅速掌握java的基本用法,不得不说写代码还是比看书来的快多了。随着课程的进行,也掌握了多线程编程模型和java的特性等等知识,对于java的理解更进一步了。

  • 面向对象的设计思想

    以往写代码基本就是想到哪里写到哪里,面向对象的设计思想更多的是为代码实践提供了一个新的理论指导,如何真正的将一个复杂功能的系统给组织起来,实现代码上的权责分配,OO确实教会了我很多。同样,在看到别人的完整项目时,也能更容易理解代码的框架和功能。

  • 代码风格

    OO强制要求的checkstyle真的好评,纠正了很多不好的代码习惯,增强了程序的易读性。对于函数行数的限制也在侧面让人保持了面向对象的习惯

课程建议

  1. 在JML单元实际上真正学习JML的就基本在第一次作业里都学完了,配合上课上的实验,感觉后面两次作业和JML关系就不是很大了,反而更像一个算法作业,大家完成作业的重点基本都在如何避免TLE上,感觉没有太大必要为了这个单元开设三次作业
  2. 在UMl这个单元,个人感觉在完成作业时很多时候就是在和指导书较劲,对我个人而言真正的难点在于有没有准确理解指导书的内容。在设计和实现上反倒是没有多少困难。个人感觉第三次指导书对于R002、R003的表述等不是很清晰,还有诸如同学在群里问的“为空”等,指导书中确实有描述,但看的时候确实不直观。(手动保命)建议能够给出更加直观的样例在每条指令下配合说明,可以尝试加一些配图,有时候对着一堆json文件确实不太好看,毕竟指导书的目的是希望大家准确理解题意,如果门槛都在理解题意上感觉有点头重脚轻了。
  3. 还是对于后两个单元的意见,感觉后两个单元的内容实际上撑不起六次作业的内容,对于UML图和JML而言,更多的意义是在理论层次上,可以考虑将两个单元的内容合成一个,最后一个单元的内容以一种较为开放的形式,完成一个综合功能的程序,可以由课程组给出一定接口和框架,留下一部分需要个人设计的空间。
posted @ 2022-06-29 14:25  刘鸿睿SC  阅读(8)  评论(0编辑  收藏  举报