第四单元博客总结
作者:互联网
第四单元总结性博客作业
本单元作业的架构设计
- 本单元的作业主要是对于UML图的各种理解和处理,在本次的作业中主要的输入处理由官方包已经完成了处理,并且传入到了我们所需要完成的函数中。在本次的最初的处理中主要是和真实的类图的绘制类似,使用了五次遍历,将所有的元素分批次进行记录,在第一次遍历中首先记录元素中的“老父亲”:
UmlClass、UmlInterface、UmlCollaboration、UmlStateMachine
,因为此后的元素都为其目录下的元素,后来的遍历都是为了
类图 | 时序图 | 状态图 | |
---|---|---|---|
第一次遍历 | UmlClass、UmlInterface | UmlCollaboration | UmlStateMachine |
第二次遍历 | UmlAttribute、UmlOperation | UmlInteraction | UmlRegion |
第三次遍历 | UmlParameter、UmlGeneralization、UmlInterfaceRealization | UmlLifeline、UMlEndpoint | UmlPseudostate、UmlState、UmlFinalState |
第四次遍历 | UmlAssociationEnd | UmlMessage | UmlTransition |
第五次遍历 | UmlAssociation | UmlEvent、UmlOpaqueBehavior |
- 为了便于操作将大部分umlXXX中的信息使用MyXXX进行了封装,并且添加了新的有利于后续操作的信息。
- 第一次作业我认为比较难的是操作的耦合度,这个函数的主要难度是对于官方包代码的阅读,在比较当前操作引用的类是否为当前查询的类时,经过了很长的探索才发现,需要使用
getReferenceId
来进行判断。 - 第二次作业中对于我花时间比较多的是关键状态,在这个函数中我忽略的第一次遍历,即当最开始能否到达终点,如果不能到达就没有关键状态的情况。
- 第三次作业中比较困难的是对于
R003
的构造,在最开始的设想中我企图只需要进行一次遍历就把循环继承的环中的所有类或接口进行记录,但是这个算法见经过尝试最终发现漏洞很大。最终是在对于每一个类都单独判断,即遍历所记录的每一个类直接或者间接继承的“父亲”中是否包含自己,且在每个类中设置了int isv
,用来表示在遍历某个类的“父亲A”时,“父亲A”是否已经被访问过。 - 不过这次作业的总体架构是比较乱的,在第二次第三次作业中为了图方便,将所有的类都使用了
HashMap
来让其ID和元素本身一一对应来进行保存,导致在MyImplementation
类的属性很多而且很复杂。
四个单元中架构设计思维及OO方法理解的演进
- 第一个单元练习的是表达式的化简,在刚刚接触这门课时,自己对于在这个单元自己的架构设计很差,在前两次作业完成的过程中还是处于面向过程的编程,而且中间对于题目考虑有一些不太周到,还是用的以前的思维来一步一步生硬地解决问题,耦合度非常高,也出现了一些十分冗余的步骤,比如在字符串和Factor类之间进行多次的转换,而这种转换是十分复杂且容易出现问题,自己的很多bug也是在这个方面出现的,而且这个地方让程序变得十分复杂难懂,导致自己可能过了几天之后就忘记了。不过在开始学习OO这门课程时,自己也是第一次接触作业是不停迭代来完成的所以在经过第二次作业需要重构之后引起了自己的一些思考,之后在这方面有了一些理解,对于程序的架构也有了更好地把握。
- 第二个单元的中主要练习的是多线程的电梯问题。在这次作业中花费了很长的时间来研究上机的代码,最终理解了实验代码的逻辑过程,使得在完成作业时非常的流畅。借鉴了实验代码的架构,所以本次作业的架构比上一个单元好了很多,在三次作业中 都沿用了该架构设计,没有出现重构的情况。不过可能是由于捎带策略的问题,使得仍然存在某个方法写的过长,耦合度较高的问题,在这次作业中自己也是始终朝着向面向对象思想的方向去做,但是做出来终究还是不是很令自己满意,但是在这次的作业中学习了实验的代码让自己对于代码的大概架构有了更加好的认识,在细节方面仍然需要不断的努力。
- 第三单元是初识JML,在这个单元中我们不需要自己来进行进行架构的设计,只需要对于官方给出的函数根据其语法来进行相应的补充就行,不过自己对于官方包的架构设计也进行过复盘,如果自己来完成这样功能的代码,自己会如何进行架构设计和分类,结果相对来说和官方还是有点差距,设计的更加复杂,一个类的功能也更加臃肿一点。不过经过这次复盘也让自己的能力进行了一些提升。在这个单元自己也学到了一些思路,比如对于
queryValueSum
这个函数,按照我之前的思路就是每次调用的时候来进行遍历求解,但是由于 - 第四单元是处理UML图,在第一次作业中,对于处理图中元素的架构设计地较好,这种结构在也延续到了后面的两次作业中。不过在后面两次的作业中比较慌乱,虽然说能够完成对于元素的处理,但是在添加了新的元素之后,结构没有之前的那么严谨,比较凌乱。
总结自己在四个单元中测试理解与实践的演进
- 在第一单元主要是以手动来构建一些比较基础的情况,对于一些比较复杂,容易出错的情况并没有考虑到,覆盖率很低,有些基础的情况也许单独的情况下自己的程序处理的是没有问题的,但是整合在一起之后会出现一些想不到的问题。
- 在第二单元中对于CPU超时的问题,我学会了通过输出CPU运行时间的方式来查看哪些地方经历了轮询,便于找出bug。电梯中出现的WA的数据,由于多线程很难找输出,所以自己将同一部电梯的输入单独提出来,然后进行测试。
- 在第三单元中主要是利用和同学对拍进行测试,通过和同学对拍会发现自己有些地方可能会产生一些忽略,而且这种对拍的方式也能够和同学交流一下在代码层面的各种思路。
- 第四单元主要是构造UML图,通过官方包提取,然后进行对比,以及后来和同学也进行了数据测试的对拍。
总结自己的课程收获
- OO课程的编程相对来说打开了自己对于编程的另外一扇大门,在这门课的编程中学到了很多之前数据结构完全没有提到的东西,比如对于数据的封装、类的继承、接口的实现等等,大一学习数据结构的时候,完成作业的要求会感觉自己离真正的工程又进了一步,现在看来自己大一写的代码还有很大的差距,只接触到了编程的冰山一角。
- 在课程中也是第一次接触到多线程的处理,自己在学习到这个内容之前,从来没有意识到我们之前写的单线程代码是同时只有一个用户能够和程序交互,是完全无法实现我们目前软件的需求的。在作业中也接触了的生产者-消费者模式,在这之前自己预习的时候,自己也尝试根据网上查找的资料来写一个的,但是虽然完成了网上资料的要求,但是网上的那个过于简单。在上机之后自习研究了上机的代码学习了上机的架构设计,感觉在理解之后会发现这个架构十分清晰明了,分工明确,不会产生轮询这种问题。多线程确实很麻烦,但是在学习的过程中我觉得在这一块是十分好玩的,不过自己在代码的实现中还是使用的
notifyall()
,还不会运用更加高级的比如线程池、读写锁之类的东西,虽然OO课结束了,但是自己还是有想法继续在多线程方面进行一些学习。 - 课程中也学习了JML和UML图,一开始在JML的学习中会觉得其描述过于严谨了,对于很多不涉及的属性都有其规定,让我想起了大一程序设计老师说的“代码就是一个直男,你要什么就给你什么”,但是也许正是这样才让使用它的人非常多吧。在第四单元具体的学习了UML图,回过头了看了一下,自己之前画的图是多么的糟糕,但是感觉网上关于这方面的资料确实不多。
- 通过课程第一次接触到git的使用,也在假期进行了自学,感觉这个东西非常的神奇,虽然有一些东西没有用到,比如分支的合并之类。
三个具体的改进建议
- 研讨课的氛围和方式我认为是很棒的,但是可能由于给的题目的原因,大部分情况大家选择的题目都差不多,而且在经过一两组的讲解之后,大家陈述的内容大多也是重复的了,我觉得除了对于作业思路的讲解外,如果上周的上机部分的代码是具有逻辑的我觉得可以让小组来讲解上机的代码(可能是因为自己就只看明白了多线程生产者消费者的实验代码,递归下降和管道的上机代码都没太看明白)。
- 感觉理论课讲的部分东西东西无法比如对于架构设计的一些理论,不是很好地能够运用到作业的实践中去,而且也不是很明白一个很好地架构设计是怎么样的,感觉每个单元的作业结束之后,可以设计一个比较合理的架构功能发下去,给同学们进行参考模仿。
- 可以增加知道书中git的介绍。刚刚学习git的时候很懵,而且网上对于git的一些讲解不是很容易理解,在指导书中可以增加一些常见问题的解决步骤的介绍。
标签:架构设计,遍历,代码,作业,自己,博客,第四,单元 来源: https://www.cnblogs.com/stubborn-rookie/p/16422872.html