BUAA_OO_2020_总结

OO_2020_总结

一、三次作业的设计架构

从第一单元走到了第四单元，前三个单元随着对oo的进一步认知，结构越来越合理。完全没想到第四单元越写越回去了，我没有按照UmlElement的种类去拆分代码，相比如果拆分结构必将更加oo，架构一定会更加合理，可是却摸了，导致了代码的臃肿。

第一次作业

采用了上图的结构用于存储，基本在构造方法中解决了战斗，基本是分析需求，在读类图的过程中分析问题，构造存储容器，存储需要的信息。

可以看到，构造方法分了三个层次，分别对每个层次进行分析。

graph TB; A(Class)-->B(Operation) A-->C(Attribute) D(Interface)-->B D-->C A-->E(Association) E-->F(AssociationEnd) B-->G(Parameter) A-->H(Generalization) A-->I(Realization)

除了Association和AssocationEnd由于存储结构的关系，出现了倒置，其余均按照该图分层，即父子关系

第二次作业

第二次作业依旧沿用第一次作业的结构，即采取容器存储关键信息。而且第二次作业有一个隐藏的小黑洞，是Atribute不只有Class和Interface有

graph TB; A(StateMachine)-->B(Region) B-->C(State) B-->D(FinalState) B-->E(PseudoState) B-->F(Transition)

graph TB; A(Interaction)-->B(LifeLine) A-->C(Message)

第三次作业

第三次作业的关键在于Uml图的正确性检测。这次完全舍弃了性能，多次使用每个点dfs的方法去检测。而且由于疏忽，没有仔细阅读讨论区，导致对rule001产生了误解，认为attr和associationEnd需要分开算，导致了强测wa了一个点，可以说是非常难受了。

三次作业的架构

可以看到结构非常差，不过好在这次作业的迭代体现在了新增功能，而且和过去功能的耦合度很低，可以通过新增类来解决，才使得这次作业没有多次重构。

复杂度

Main.main(String[])	1.0	1.0	1.0
MyUmlCollaborationInteraction.getIncomingMessageCount(String,String)	5.0	1.0	5.0
MyUmlCollaborationInteraction.getMessageCount(String)	3.0	1.0	3.0
MyUmlCollaborationInteraction.getParticipantCount(String)	3.0	1.0	3.0
MyUmlCollaborationInteraction.MyUmlCollaborationInteraction(UmlElement...)	1.0	10.0	10.0
MyUmlGeneralInteraction.checkForUml001()	2.0	10.0	11.0
MyUmlGeneralInteraction.checkForUml002()	2.0	5.0	6.0
MyUmlGeneralInteraction.checkForUml003()	2.0	5.0	6.0
MyUmlGeneralInteraction.checkForUml004()	2.0	9.0	10.0
MyUmlGeneralInteraction.checkForUml005()	12.0	12.0	17.0
MyUmlGeneralInteraction.checkForUml006()	5.0	4.0	5.0
MyUmlGeneralInteraction.checkForUml007()	4.0	3.0	4.0
MyUmlGeneralInteraction.checkForUml008()	4.0	4.0	5.0
MyUmlGeneralInteraction.findAll(String,String)	1.0	4.0	5.0
MyUmlGeneralInteraction.findAndPush(String)	1.0	5.0	5.0
MyUmlGeneralInteraction.findDuplicateOne(String)	1.0	5.0	5.0
MyUmlGeneralInteraction.getClassAssociatedClassList(String)	1.0	1.0	1.0
MyUmlGeneralInteraction.getClassAssociationCount(String)	1.0	1.0	1.0
MyUmlGeneralInteraction.getClassAttributeCount(String,AttributeQueryType)	1.0	1.0	1.0
MyUmlGeneralInteraction.getClassAttributeVisibility(String,String)	1.0	1.0	1.0
MyUmlGeneralInteraction.getClassCount()	1.0	1.0	1.0
MyUmlGeneralInteraction.getClassOperationCount(String,OperationQueryType[])	1.0	1.0	1.0
MyUmlGeneralInteraction.getClassOperationVisibility(String,String)	1.0	1.0	1.0
MyUmlGeneralInteraction.getImplementInterfaceList(String)	1.0	1.0	1.0
MyUmlGeneralInteraction.getIncomingMessageCount(String,String)	1.0	1.0	1.0
MyUmlGeneralInteraction.getInformationNotHidden(String)	1.0	1.0	1.0
MyUmlGeneralInteraction.getMessageCount(String)	1.0	1.0	1.0
MyUmlGeneralInteraction.getParticipantCount(String)	1.0	1.0	1.0
MyUmlGeneralInteraction.getStateCount(String)	1.0	1.0	1.0
MyUmlGeneralInteraction.getSubsequentStateCount(String,String)	1.0	1.0	1.0
MyUmlGeneralInteraction.getTopParentClass(String)	1.0	1.0	1.0
MyUmlGeneralInteraction.getTransitionCount(String)	1.0	1.0	1.0
MyUmlGeneralInteraction.MyUmlGeneralInteraction(UmlElement...)	1.0	1.0	1.0
MyUmlInteraction.findAll(String)	1.0	4.0	4.0
MyUmlInteraction.getClassAssociatedClassList(String)	3.0	4.0	6.0
MyUmlInteraction.getClassAssociationCount(String)	3.0	2.0	4.0
MyUmlInteraction.getClassAttributeCount(String,AttributeQueryType)	3.0	3.0	5.0
MyUmlInteraction.getClassAttributeVisibility(String,String)	11.0	4.0	11.0
MyUmlInteraction.getClassCount()	1.0	1.0	1.0
MyUmlInteraction.getClassIdSet()	1.0	1.0	1.0
MyUmlInteraction.getClassOperationCount(String,OperationQueryType[])	14.0	7.0	15.0
MyUmlInteraction.getClassOperationVisibility(String,String)	5.0	5.0	9.0
MyUmlInteraction.getIdToAnotherAssociationEnd()	1.0	1.0	1.0
MyUmlInteraction.getIdToElement()	1.0	1.0	1.0
MyUmlInteraction.getIdToExtendingElementId()	1.0	1.0	1.0
MyUmlInteraction.getIdToImplementingElementId()	1.0	1.0	1.0
MyUmlInteraction.getIdToItsAttribute()	1.0	1.0	1.0
MyUmlInteraction.getIdToName()	1.0	1.0	1.0
MyUmlInteraction.getImplementInterfaceList(String)	3.0	5.0	7.0
MyUmlInteraction.getInformationNotHidden(String)	3.0	6.0	8.0
MyUmlInteraction.getTopParentClass(String)	3.0	2.0	4.0
MyUmlInteraction.getUmlInterfaces()	1.0	1.0	1.0
MyUmlInteraction.isConflictQueryType(OperationQueryType[])	10.0	5.0	10.0
MyUmlInteraction.isParamTypeOperation(UmlOperation)	5.0	4.0	5.0
MyUmlInteraction.isReturnTypeOperation(UmlOperation)	3.0	2.0	3.0
MyUmlInteraction.MyUmlInteraction(UmlElement...)	1.0	4.0	4.0
MyUmlInteraction.setListsForClassAndInterface(UmlElement)	1.0	4.0	4.0
MyUmlInteraction.setListsForOperationAndSoOn(UmlElement)	1.0	10.0	10.0
MyUmlInteraction.setListsForParameterAndAssociate(UmlElement)	1.0	8.0	8.0
MyUmlStateChartInteraction.findAll(String)	1.0	4.0	4.0
MyUmlStateChartInteraction.getStateCount(String)	3.0	1.0	3.0
MyUmlStateChartInteraction.getStateToNextStateList()	1.0	1.0	1.0
MyUmlStateChartInteraction.getSubsequentStateCount(String,String)	5.0	4.0	8.0
MyUmlStateChartInteraction.getTransitionCount(String)	3.0	1.0	3.0
MyUmlStateChartInteraction.MyUmlStateChartInteraction(UmlElement...)	1.0	12.0	12.0
Total	160.0	208.0	275.0
Average	2.4615384615384617	3.2	4.230769230769231

没有好好架构，复杂度的暴增是必然的结果。

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

第一单元

第一单元是我的架构噩梦。每次代码都是从头开始，第一次代码仅仅考虑了多项式，可谓是为了实现而实现，关键是我还分了好多类，类似于读取类，求导类和输出类，现在想起来，这个划分十分的可笑。这完完全全是对功能的划分，而不是面向对象的过程，仅仅是把之前面向过程的函数变成了类而已。迭代性极差。第二次作业，出现了三角函数，这次的对象划分逐渐合理，对多项式，项，多项式和三角函数进行了划分，可以说第一次体现出了面向对象的特点。但是可迭代行还是很差，主要体现在读入的处理上和WF的判断，采用大正则表达式判断WF可以说是非常死板了，根本不具有可变动性。而读入处理也不具备可变动性，体现在采取了函数的特点去读取，不具备普适性。第三次作业不得不再次重构，这次是第一次在笔头上哗啦了两天才下手，仔细思考了架构，在读入处理使用了递归下降的方法，普世性极强，如果下一次作业有新的需求也可以完美适应，而且WF的判断夹在递归下降的过程中，非常丝滑。对于没中可能出现的原子，都有自己的类，而且运用了多态，接口等非常OO的方法。

第一单元是让我对OO理解最深的一个单元，多次的重构也让我彻底明白了一个好架构意味着什么

第二单元

第二单元基于第一单元的训练，在架构上非常合理，三次作业均没有对架构进行改动。第一次作业就采用了调度器，使之后两次作业都不需要进行大改动，电梯的封闭性也非常好，三次作业对电梯的改动几乎为0。这是一次极佳的体验。

第三单元

我觉得第三单元的重点不在架构的考察，如果说影响最深的应该是容器结构的使用。即采取什么样的容器结构去存储信息，如何维护信息，如何选择一个更加合理的算法。第三单元的算法选择让我体会到了最优算法有时就是骗局，我牺牲了ar的时间换取了所有的查询O(1)，有人ar采用基础操作，而查询则耗费时间。不同的数据会造成截然不同的结果

虽然电梯作业中就有该趋势，手搓的数据可以卡各种算法，不过随机数据还是很能说明问题的；而这单元的作业中，随机的数据就能让多种算法各有优劣。

第四单元

第四单元的主体架构，官方包已经给出，而且UML图本身是非常适合面向对象编程的，可惜摸了。

OO思想

通过四个单元的练习，尤其是前两个单元，让我对OO编程有了更加深刻的理解。第一单元的层层递进让我逐渐摸索出了什么样的划分类才算面向对象，是对处理问题的基本单位做划分，而不是处理问题的基本方法做划分。这是我的个人理解。比如第一单元划分的应该是各个原子项，而不是求导一个类，输出一个类，这些应该是这个类的方法。第二单元是让我对高内聚，低耦合有了更深的理解，电梯类的高内聚，低耦合让我的三次作业顺利迭代，让每次编程都非常轻松。相信在以后的学习过程中，我也会仔细思考如何划分架构，如何划分问题得基本单位，采取面向对象的思想解决问题。

三、我对测试的理解和实践的演进

四个单元的是测试基本都是互测驱动评测机。

上学期的CO我就对评测机有所耳闻，当时在我心里评测机是一个高大上的东西，通过这次OO的学习，逐渐揭开了简易评测机的神秘面纱。

第一单元第一次作业在完成之后，闲来无事翻看讨论区的时候看到一位同学分享的评测机思路，下定心思手搓一个，在造评测机的过程中，最先解决的居然是我的环境问题，我发现我的java和javac的版本不一致，导致我手动编译的项目没法运行，非常心累，改了环境变量于事无补，重启之后自动恢复，当时心态炸裂，最后发现我改的是user的path，而系统的path没有改。之后也是学习了shell脚本，使用xeger包生成随机数据，进行了大量的测试。不过由于我的jdk版本为13.1，导致我的评测机可移植性几乎为0。第二单元则是使用java，采用了面向对象的思想，对于每个指令都建立一个类进行分析，进行运行模拟，判断执行是否正确。而且也学会了一些粗略看运行时间的方法。可以说前两次的黑盒测试都是可以判断正确性的。但是三四单元由于评测机其实就是按照自己的思路翻译代码，所以主要的方法就是对拍，和造随机数据。

四个单元的黑盒测试下来，shell和python日渐熟悉，也熟练掌握了打包jar包的能力。

黑盒测试之余，采取的是手造边缘数据，因为评测机虽然性能远超人脑，但是介于数据的随机性，很难出现那种特别变态的数据，类似与第二单元的超级无敌括号迭代。

对测试有更深的理解主要出现在第三单元，也就是规格。这时候才懂，测试不是只有给数据给输出的一种方法，当架构足够合理，就可以进行信任性测试，比如对单一的方法测试。更体现出了架构的重要性。第三单元由于正确性和性能难以两全，所以我进行测试，基本是写一版几乎完全匹配JMl的代码，与我的程序进行单一指令的大规模对拍。这就是规格的一个作用，可以让你在追求性能的同时，方便测试正确性！

当然，测试非常好，但是如果能过采取合理的架构，使用合理的码代码的方式，减少bug的出现，这何乐而不为。

四、课程收获

我觉得主要是体现在了码力提升；测试能力增强，测试手段增多；架构更好以及心态更好了。

想到大一高老师经常问一句，你们编过的最大的程序有多少行啊，当时我只有大一下的大作业上了200行，虽然不是以行数论英雄，但是回首过去，当时让我写了很久的地铁，其实仅仅是dijkstra的单纯简单运用，JML单元的使用甚至还加了堆优化，仅仅是为了一个方法。

第二个就是互动驱动测试能力提升，为了hack别人可谓是想尽办法；同时第二单元多线程导致了单步调试的能力大大降低，不得不重拾printf调试法，以及结合jprofile等工具进行分析，首次将代码与CPU运行情况结合测试。

第三点也是前面说的架构能力的提升。

但是我感觉最重要的一点就是心态变好了。大一的时候，C语言上机能让我慌张到不行，数据结构的作业看到了心烦意乱，不敢去下手。这都在今年的到了提升，看到了多线程，面对着完全陌生的概念，自学，找教材，写一些小的程序去试水等等。我真的感觉心态变好了，第七次作业，数次提交都出现了本地无法复现的bug，也没有慌张，仔细地分析了可能出现问题的地方，进行了小规模的修改，通过了中测等等这些经历，让我受益匪浅。

五、三个具体改进建议

• 第一个，必须要说的就是课上测试的形式，说实话，课上测试，我觉得也应该开辟bug修复单元，不能让它过去了就过去了，还有就是最好改一下课上测试和作业下发的时间点，最好能在强测时，也就是现在的周日早上进行测试，不然和作业冲突，有时候会让我对实验丝毫没有准备。
• 第二，就是希望调整一下JML单元，虽然JML单元做起来体验还可以，但是JML的工具链实在是太老了，配置环境消耗的时间远远超过了完成一次作业需要的时间。希望能够对单元进行整改，但是不能舍弃规格单元，规格单元真的很重要！！！
• 第三，预习作业不应该仅仅让同学熟悉java语法，更应该对架构有一个体验，不然第一单元大概率面对三次作业三个架构。

六、线上OO课的体验

• 我觉得最好的就是OO课可以不限时间，不限地点再看一次。因为UML单元其实最主要的就是阅读理解，而网上能够找到的教程相较于多线程什么的又少，质量还参差不齐，线上的形式，可以再看一次，再理解一下UML的结构。
• 研讨课，我讲过一次，对着屏幕空讲的效果很差，时间没法掌控，没有同学的反应，相信老师也面临着相同的问题。而且听的时候，也往往因为缺乏互动性并不能很好的get到别的同学的意思。

七、OO课体验

从原来的玄学课变成今天的样子，多人运动美滋滋，互测驱动测试能力提升，这OO课我爱！