面向对象第四单元总结

面向对象第四单元总结

一、本单元作业架构设计

本单元作业的目的是熟悉UML类图的元素及其解析方法,共两次作业,第一次作业解析类图中的各个元素,第二次作业加入了状态图和时序图,并对类图的有效性做分析。

第一次作业

本次作业要求实现类图解析器接口,实现的方法如下:

我通过MyUmlInteraction类实现次接口,功能的完成通过对输入元素进行建图实现,针对不同的UML元素,封装不同的类例如针对UMLClass类型封装了ClassType类,存储Class中的各个属性和方法以及父类等信息,类似的封装类型还有AssociationType,OperationType和InterfaceType。

完成对输入的各个UML元素建图之后,接口中需要实现的方法便迎刃而解了,整体的类间关系图如下:

第二次作业

本次作业在上次的基础上实现对状态图和时序图的解析,并对类图进行有效性检查。其中状态图和时序图的解析比较简单,难点主要在对类图的有效性检查上。一共需要实现三条规则的检查,分别是:

  • R001:针对下面给定的模型元素容器,不能含有重名的成员(UML002)
  • R002:不能有循环继承(UML008)
  • R003:任何一个类或接口不能重复继承另外一个接口(UML009)

我的解决方案如下,R001比较简单,利用Set集合就可以逐一判断各个属性有没有重名。R002和R003需要进行建图,由于我们考虑的是类的继承、接口的继承以及类实现接口这三种关系,所以只需要讲类和接口看作节点,将这三种关系看作有向边即可。对于R002规则,只需从每个节点开始dfs,如果中间搜到了自己,说明有循环路径。对于R003,也是从每个节点开始dfs,如果两次搜到某相同节点,说明有重复继承。整体类间关系图如下:

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

第一单元

第一单元的主题是求导,共三次进阶性作业

  • 第一次:简单多项式求导
  • 第二次:带简单正余弦函数且带乘积项的求导
  • 第三次:带嵌套函数的求导

在本单元的学习中,我们首先熟悉了java语言的基础语法,然后学习了面向对象程序设计的基本思想,并以代码的形式在作业中实现,包括类,继承派生,多态,基类,接口等等。

第二单元

第二单元作业,由简到难地实现了三版目的选层电梯。本单元主要学习java多线程的编程方法。

  • 第一次:多线程的傻瓜式单电梯
  • 第二次:多线程可捎带电梯
  • 第三次:多线程多部多限制可捎带电梯。

难度逐渐加难,对线程安全性的要求也越来越高。

第三单元

第三单元作业,由简到难地迭代式实现了三种JML需求,主要学习了面向规格的编程方法。

  • 第一次:实现Path类和PathContainer类
  • 第二次:继承PathContainer类实现Graph类
  • 第三次;继承Graph类实现RailwaySystem类

本单元中我们学习并掌握了面向规格的编程方法,会写JML会读JML,能用规格语言描述类和方法。

第四单元

本单元作业的目的是熟悉UML类图的元素及其解析方法,共两次作业,第一次作业解析类图中的各个元素,第二次作业加入了状态图和时序图,并对类图的有效性做分析。

在这一单元,学习了与用户打交道常用的UML工具,更方便人对程序架构的理解,会写UML,会读UML,会用UML描述类和方法。

小结

这四个单元循序渐进地向我们展示了面向对象编程思想中的各个模块的内容,从最开始的封装继承等面向对象语法特性,到设计架构中常用的JML和UML,我学习并亲自实践了这些知识点,提升了代码能力和架构能力。

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

对于测试,在这几单元中,我学到了两种方法

  • 搭测评机
  • 单元测试

我从上学期祭祖课开始尝试学习搭测评机,但真正好用其实还是在oo上,其能大量快速地发现很多人眼难以发现的bug,oo课练习了快速写测评脚本以及数据生成器的能力。

在第三单元,我还学到了如何做单元测试,采用Junit架构,可以方便且无漏地对代码中的每个方法进行单元测试,对于今后工作中可能需要的高精度代码,单元测试是十分有必要的。

四、总结自己的课程收获

一学期的oo课程,我感觉收获颇丰,首先我学会了如何写java程序,掌握了java语法。其次我学到了面向对象的基本思想,如封装、继承、多态、接口,并可以用java语法实现。另外,我还学到了代码架构常用的工具和方法,例如面向规格的JML,以及UML类图。

这些知识点涵盖了面向对象编程的方方面面,当然,只凭课上所学并不够,还需要真正接触一些工程上的代码才能对面向对象编程有更深的理解,我希望在今后,能有机会参与一些工程上的任务,进一步提升自己的代码能力。

五、改进建议

为了让北航oo课程体系更加完善,我在此提出自己的一些看法,希望对课程组有帮助。

  1. 对于大部分人来说,oo课是第一次接触java的一门课,后续的其他必修课也不用java,所以广泛的java语法涉猎是有意义的。课程组可以总结一些java中比较高级的语法特性让大家了解,可以利用上机实验,让大家练习使用。
  2. 对于最后一单元的UML作业,我觉得不是很有意义,学习UML的目的是更好的设计复杂的工程架构,而不是遍历UML中的各种元素,分析各种元素的信息之类的。练习的重点应该是画UML图,让大家去设计,即使这样不好评分,但是不应该为了好评分而忽略了更有意义的内容。我现在所画的UML图仅仅是实验课上所画的那一个,其它的都是在给自己出数据的时候画的奇奇怪怪的样例。
  3. 既然引入了互测,莫不如充分利用群智的力量,把测评机不好评测的地方让人去评分。目前对于代码风格的检查使用的checkstyle只是形式上的问题,而不管这个代码是不是真的易读,易维护。我觉得针对这一点可以借助互测的机制让大家去给出代码风格分数,如果认为他的代码易读懂就给高分,否则就给低分。还有我上面提的画UML类图那一条在评分的时候也可以让同学们互测给分,我们学了那么多的有效性规则,正好可以练习一下。总之,我觉得测评机是很公平,但是有时会导致僵化,可以适度开发群智的力量,不仅仅局限在互相挑代码bug这一点上。
原文地址:https://www.cnblogs.com/old-jipa-deng/p/11072512.html