OO第四单元总结及课程总结
19373069 刘川枫
一、本单元架构设计
第四单元的任务是实现一个UML图解析器，能正确解析UML三种图。基本的mdj文件解析逻辑官方包已经给出，我们需要实现的只是各种关系的存储和解读。
具体来讲，就是构造自己的用于存储接口、类等参数的类，并将其实例化，完成对mdj文件的解析。
如图所示，自己定义了三个类：接口、类、操作，并利用解析好的mdj文件信息将其在类MyUmlInteraction中实例化，完成解析。
第二次作业要求增加对时序图和状态图的解析，第三次作业需要完成UML图的检查。
遗憾的是，这个单元我的作业完成的情况很不理想，第一次作业本地测试，无法完成CLASS_ASSO_CLASS_LIST等几个操作，因此没有通过评测，随后由于考试比较多，时间安排的不好，尽管后来改正了第一次的bug（实际上好像还有问题，改后不抛异常了，但是有些自己写的测试样例解析出的结果还是存在问题，但我实在不会改了），第二次和第三次也没有完成。
二、OO四个单元回顾
- 第一单元：多项式求导
初见OO，这一个单元可以算是最难的一个单元了，第一次作业我的方法是先将正负号合并，然后把多项式的每一项切割出来，利用容器存储，然后对其进行解析，求导，本质上这种做法还是面向过程编程，没有丝毫面向对象的意思，但是至少对JAVA的语法有了深刻的巩固。OO以及将来的工程开发都讲究迭代，因此毫无疑问，下次作业只能重写了，第二次作业不能再使用切割合并的方法了，因此我改用表达式树进行求导操作；第三次作业在第二次作业基础上增加了格式检查（终于不用重写了，可以重构了），我单独建立一个错误类负责检查输入表达式是否存在各种错误，但现在回想起来，这种方法覆盖面不是很广，可能会有遗漏，最好还是采取递归下降的方法去解析。
第一单元真的很难，但是我已经逐步有了面向对象的思想。 - 第二单元：电梯调度
第二单元是我真正彻底从面向过程思维走向面向对象思维的一个单元，真的很感谢那个亲爱的Elevator类，这个类让我理解了面向对象的含义。
第一次作业，由于正在进行思维过渡，因此最开始我并没有考虑调度算法，直接使用傻瓜电梯的方法，写出一个正确（但不考虑性能）的程序，交上去发现性能不行，由于时间紧迫，来不及写ALS了，因此直接简单的改进了一下傻瓜算法（性能介于傻瓜和ALS之间），最后强测分数不高；因此在第二次作业开始之前，我就修正了第一次作业，采取了ALS算法；之后第二次作业，引入多线程，与synchronized大战三百回合后算是弄明白了锁该怎么写，其实这次作业只要弄懂锁，在第一次作业上重构难度不大；第三次作业，把电梯分类即可，同时这次作业我改用了比synchronized更好用的可重入读写锁。后两次作业强测效果都很好。
第二单元我理解了面向对象的真正含义（让对象自己去做事），学会了简单的JAVA多线程开发。 - 第三单元：JML编程
第三单元是我认为最简单的一个单元，这一单元要求我们理解JML语法，并按照要求实现各种接口。第三单元最重要的是对规格的思考，选用什么样的规格完成“甲方”的要求，是这个单元作业性能分的评判标准。
第一次作业由于功能简单，数据量小，几乎没有任何压力就轻松拿下，而且强测分数很高；也正是因此麻痹了我，第二次作业依然采用不合适的ArrayList结构，遍历查询，再加上弱测中测数据太弱具有欺骗性，最后我强测特别惨；有了前车之鉴，第三次作业我使用HashMap替代ArrayList，采用加权并查集查找代替遍历查找连通路径，并采用改进的dijistra算法，第三次作业顺利完成。 - 第四单元：UML解析
第四单元是设计UML解析器，由于个人对UML理解不佳，再加上期末考试时间安排不合理，最后很遗憾没有通过评测。
后来进行反思，打铁还需自身硬，还是需要多锻炼自己阅读大量代码的能力，以及架构设计能力，这单元作业的失败算是一个很深的教训了，以后的学习过程必须要勤加练习，合理安排学习时间。
四个单元中测试与实践的演进
- 第一单元
第一单元，由于刚刚接触OO课程，不了解更好的测试方法，我的测试方法就是自己构造各种样例（普通样例和极端样例），自己本地测试，和同学对拍测试。 - 第二单元
第二单元开始采用自动化测试策略，当然也没有放弃自己构造样例的方法，先自己构造一些样例，测试各种可能的极端情况（我的二次作业的一个重大电梯吃人BUG就是自己构造极端样例测出来的）；之后还采用了大佬写的自动化样例生成器和自动评测机进行自动化测试。
总的来说，我认为，两种方法各有特色：人造样例便于模拟极端情况；自动化样例便于模拟普遍情况，方便进行大量测试分析性能。 - 第三单元
第三单元在原有的测试方法基础上，引进了OpenJMl,Junit等现代测试工具，对程序进行系统化、全面的覆盖性测试。 - 第四单元
第四单元自行构造样例测试没有通过 (⊙﹏⊙)
四、课程收获
OO这门课虽然困难，但是带给我的收获还是蛮大的。首先最基本的就是学会了JAVA基本语法、高阶应用、面向对象开发。其次，面向对象的课程模式很接近将来的工作，因此学会自己测试，学会发现自己和他人的bug，提前适应将来的开发模式也是这门课的重要收获之一。另外，OO课程让我明白了编程的一个重要的原则：先设计再写代码，设计不仅要考虑本次需求，还要考虑未来可能新增的需求，以便迭代开发。最后，OO这门课本身也能培养同学们不怕困难，克服困难的能力，这应该是我们以后人生路上需要的重要能力，奥利给！。
五、课程建议
总的来说，虽然我自己被OO虐地挺惨的，但是不得不说这门课是一门非常优秀的课程，虽然难，但真的能学到东西，就像上学期的CO一样。课程到此告一段落了，我也提几个建议，希望课程组采纳。
- 一、第一单元难度过大
可能是课程组希望给刚接触OO的同学们一个下马威，激励大家多投入精力，认真对待这门课程，因此第一单元难度大一些，这我能理解。
但是，难度是不是太大了点？
首先，大部分同学还没有建立起面向对象的思想，还有的同学JAVA语法还不太熟悉，直接上递归下降这种编译原理课才涉及到的算法，可能对于很多来说属实有点困难；而且，第一单元作业似乎和面向对象关系也不大，很多同学最后也是拿面向过程的思维做的（我也是第二个单元才真正明白啥叫面向对象）。后几个单元难度明显小于第一单元，这样的梯度安排似乎不大合理，可能有的同学第一单元失利，直接丧失了信心，这无疑是我们和课程组的老师和学长学姐们不希望的结果。
因此我的建议是，降低第一单元的难度，把第一单元的培养目标改为“理解面向对象思想，弄清面向对象和面向过程的区别”。具体来说，可以设置一个新的主题，例如迷你图书管理系统；或者一个更简单的方法，把求导这单元放在后面，电梯调度放在第一单元（第一次傻瓜电梯；第二次ALS电梯；第三次多线程ALS电梯） - 二、时间安排有待改进
当前的OO是周三晚上开放，周日晚上截止，一共4天时间，属实有点短，而且从周日截止提交之后，一直到下次周三晚上，除去互测时间，还存在至少一天半的空余时间。所以我的建议是可以适当延长作业时间，给大家更多时间去思考，去完善，这样更有利于开发一个性能好、bug少的程序，毕竟谁不喜欢一步到位呢？ - 三、评测次数限制以及评测时间间隔适当放宽
OO作业只有20次评测机会，而且后十次还要扣分，相邻两次评测要求间隔很长时间，造成很多同学即使写好了也不敢测。当然我知道课程组不希望大家拿评测机来测试，而是要培养自己的测试能力，但是我还是认为当前这个评测要求太过严厉。
我的建议是：可以不限评测次数，但是只有前10次是无代价评测，11~20次适当扣分，20次以后再扣一些分数，适当缩短评测时间间隔，并且在DDL之前的半小时内没有评测间隔要求，这样或许可以避免写好了交不了的悲剧。
当然我这个建议也不是完美的，毕竟这样也会很大增加评测机的工作压力，归根结底还是希望课程组能放宽一些评测的限制。 - 四、bug修复可以补偿强测扣分
这样可以大幅增加大家bug修复的积极性。
最后感谢老师和助教们的付出，OO这门课我学到了很多，谢谢你们！
标签：总结,OO,评测,样例,作业,面向对象,课程,单元 来源： https://www.cnblogs.com/19373069lcf/p/oo_4_sum_lcf.html
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。