BUAA_OO_2020_第四单元与课程总结
第一次
架构设计
第一次作业要求实现UML类图解析器。
我才用自顶向下依次解析的方法,首先将类图中涉及的所有元素分成三层:
第一层 | 第二层 | 第三层 |
---|---|---|
Class, Interface, AssociationEnd | Association, Attribute, Operation, Generalization, InterfaceRealization, | Parameter |
根据需要,实现了MyClass, MyInterface, MyAssociationEnd,MyOperation四个类,按照所属关系(例如属性属于类/接口, 关系属于两个类/接口)将其他元素作为属性保存在这四个类中,并在主解析器中保存以上四种的HashMap(id为key,对应实例为value),用于找出需要的元素调用。
在解析元素时,进行三次遍历,依次解析第一、二、三层。
对于主解析器中的函数调用,多下降到新实现的类中完成。
对于涉及搜索的函数(例如寻找所有关联的类、所有实现的接口等),采用转入hashmap作为函数参数,递归调用进行修改的方法,最终返回时参数hashmap就已经加入了所有符合要求的元素。同时,为了提高效率,设置缓存机制。
例如:
public void getInterfaceList(HashMap<String, String> names) { if (hasInterfaceList) { // 如果已经调用过该方法,则直接返回结果 names.putAll(interfaceList); return; } for (MyInterface a : interfaces.values()) { // 遍历所有该类直接实现的接口 interfaceList.put(a.getId(), a.getName()); // 更新实现的接口hashmap a.getFatherInterfaces(interfaceList); // 调用该接口的该方法,寻找间接接口 } if (father != null) { // 如果有父类,则调用父类的该方法 father.getInterfaceList(interfaceList); } hasInterfaceList = true; names.putAll(interfaceList); // 更新传入的names }
UML类图
第二次
架构设计
第二次作业要求实现时序图和状态图的解析,架构方法与第一次相同,更新层次表格如下
时序图:(仅列出需要使用的)
第一层 | 第二层 | 第三层 |
---|---|---|
Interaction | Lifeline | Message |
状态图:(仅列出需要使用的)
第一层 | 第二层 | 第三层 |
---|---|---|
StateMachine, Region(由于本次作业中一对一,所以简化) | State | Transition |
UML类图
第三次
架构设计
第三次作业涉及模型的有效性检查,基本架构与第二次完全相同。
在进行有效性检查时,检查方法与之前的查询方法类似,下降到对应的类中递归调用。
对于R005,R006,采用在初始化架构时进行预处理的方法更为方便。
UML类图
和第二次架构相同。
设计架构及对OO的理解演进
我认为第一单元对于面向对象思想的体现是最明显的,我的设计重点主要在如何实现某个对象。将表达式从上到下进行解析,提取出表达式类、因子类、各种项类。通过成员变量等方法建立其中的包含关系和函数调用关系,每个类只需要完成自己的任务。综合来看,第一单元是我心中最OO的一个单元,也是阐释OO思想的很典型的一个样例。
第二单元延续OO的设计思想,但增加了重要的功能性,也就是这一单元的特点——多线程,这使得我的设计重点由如何实现某个对象,变为对象之间的如何交互。线程安全等问题非常结合实际又难度,并且调度算法的开放性也激发了我对于不同调度策略的尝试和比较。通过本单元的学习,我明白了对于OO而言,设计好一个对象的行为是远远不够的,如何让他们系统地、高效地、安全地交互才是将架构真正付诸实践的关键。
第三单元涉及JML,让我体会到了在实际工程实现中根据规格要求实现具体方法的过程,我的设计重点放在了如何高效实现方法要求上。针对特定的JML规格,方法的具体实现方法有许多种,但总有效果更好的一种。我认为在阅读JML时,最重要的是要深层次理解其设计目标的内涵(如最短路、连通分量数量等),而不应该仅停留在JML字面意思,否则将难以将需求抽象出来,可能造成方法复杂度过高等后果。
第四单元学习了UML的相关知识,UML模型模型化设计将对象、对象之间的关系全部抽象出来,组建成模型。我认为设计的重点在于层次化抽象成模型。对于层次化,需要将UML图中的各种元素进行层次划分,形成从抽象到具体的逻辑关系。对于抽象,需要深入理解UML图的本质,并采用某种数据结构将元素进行统筹整理。
测试理解与实践
我在每个单元中的测试流程都基本相同:
-
手动构造基本功能测试
-
JUnit单元测试(主要在第三单元采用)
-
对拍(主要在第一、二、三单元采用)
-
自动生成输入数据(第一、二、三单元)
-
自动判断答案正确性
-
对输出答案进行special judge(第一、二单元)
-
生成正确答案,与输出进行比对
-
多份代码一起跑,比对输出之间的差异(第三单元)
-
-
-
手动构造边缘数据
综合来看,对于不同测试方法,我给出以下结论:
-
找bug效率最高的是边缘数据测试
-
清扫诡异bug最有效的是对拍(有的bug只有在某些条件同时满足时被触发,不对拍难以覆盖)
-
输写最有条理的是JUnit(针对单个方法测试,需要考虑的条件少)
课程收获
-
对OO思想从无到有的建立
通过本课程的学习,我理解了面向对象和面向过程的具体含义(之前没有面向对象做对比,我连面向过程的意思都不是很理解),并掌握了OO的基本实现思路和应用场景,能够使用面向对象思想对于某问题进行分析和给出解决方案。
-
对java语言从0开始的学习
掌握了一门编程语言,通过书写具有一定代码量的作业熟练了java的语法和应用,学会了容器等java元素的使用,提高了我的代码能力。
-
对拍测试机制的学习
在去年计组首次接触对拍,但当时没有自己动手实现多少。本学期OO过程中学会自己实现对拍测试的各个部分,并学会了使用bat实现自动化。
-
一些其他的技能
打包工程、markdown使用、git使用、rubyonrails了解……
改进建议
-
强测结果不同分数用不同颜色表示可能更显眼(研讨课有同学提的,我觉得很有道理
-
希望实验课有反馈结果,给个答案就行
-
第三单元东西确实有点少(感觉后来是因为JML没啥可考的才搞算法),或许可以考虑压缩成两次?这样就可以提前一周结课了,不会影响烤漆(虽然我好像也没受啥影响,毕竟6系这学期无烤漆
线上OO感受
线上学习对于OO的影响几乎为0。
除了理论课和研讨课的效果稍微不如线下以外,作业的完成、测试都完全没受影响。
感言
体验极佳的一门课,很系统很完整,从发布指导书到中测、互测、强测一气呵成,感觉学到了很多东西,不限于OO,还提升了我很多基本的计算机素养
虽然内容很多也不简单,也很疯狂鸡肉卷,但总有一些亮点让我觉得学习这门课很有趣,比如互测的圣杯战争(Lancer是我本命,还经常被分到Lancer,喜滋滋,忽略幸运E)
老师们上课各有风格,温文尔雅和幽默风趣我都可以,讨论时也很认真在群里引导我们,老师辛苦了
感觉助教团队为良好的学习体验贡献超多,太强大了,请允许我发自肺腑地呐喊一声助教nb
作为疯狂鸡肉卷中的一根葱丝,感谢其他从者帮我找到的错误