OO semester course summary and the fourth unit operation
table of Contents:
First, the fourth job analysis unit
Two, four cell architecture and method for understanding the evolution of OO
Three, four unit tests to understand the evolution and practice
Fourth, summary curriculum harvest
Five suggestions for improvement
A fourth job analysis unit
1. The first job
·Class Diagram
(1) Analysis of instructions
In the first operation the need to achieve a total of 9 query instruction. In this 9 instruction in the most complex instructions should be "class implements all interfaces", this instruction needs to continue to query the parent side up along the inheritance, and at the same time to find all the interfaces of each layer of the parent classes. Because the job specified class can only single inheritance, so all UmlClass can be organized into a forest. But because the rule allows the interface appears multiple inheritance, so all UmlInterface not form a forest, it can only be organized into a number of directed graph.
(2) Analysis of program architecture
The first version of the work intensity measurement class map as shown in FIG. Upon completion of the first job he stole lazy, and not after entering all the data, UmlClass and UmlInterface were set up and tree chart, but take a direct approach Mang. Each time you find a class or interface inheritance, have to traverse to get UmlGeneralization inheritance relationship between father and son class or interface. After writing but we found that this approach not only does not directly Mang reduce the workload, but also greatly increase the amount of code so that the program becomes bloated.
Wherein GetOperationCount checkstyle class only to satisfy the requirements of the length of the file, and the instructions in a single class GetOperationCount go complete.
The first job is just to complete the most basic command functions, level design in the architecture program there are many places worth improving.
Reconstruction (3) architecture
在通过第一次作业的强测后，为了使程序具有更好的层次框架和更好的可扩展性，我对第一次作业中UmlClass和UmlInterface的数据结构进行了重构，将他们分别组织成树ClassTree和有向图InterfaceGraph的形式。这对在第二次作业中完成三条有效性规则的检查有很大的帮助。
2.第二次作业
·类图
（1）指令分析
在第二次作业中，新增了对顺序图和状态图进行解析的共6条指令，以及对模型有效性检查的3条指令。在新增的指令中，我认为最复杂的不是对顺序图和状态图的解析，而是对模型有效性检查的后两条指令。
针对
（2）程序架构分析
二、四个单元中架构设计与OO方法理解的演进
在本学期总共四个单元的作业中，我认为第二单元多线程电梯与第三单元地铁系统最能够锻炼架构设计能力。
1.第一单元
第一单元的作业是围绕多项式求导这个主题展开的。
在完成第一单元作业时，由于之前连最基础的Java语法都没有学习过，基本是一边查找学习Java的语法一边完成作业的。因此也就不太可能在架构层面花费足够的精力。在完成第一单元作业后，感觉尽管作业难度不小，但是并没有学到太多OO的内容，唯一比较有收获的就是学习了Java正则表达式的使用。
2.第二单元
第二单元的作业是实现多线程电梯的调度，从第一次作业的单部傻瓜电梯，到第三次作业的多部智能电梯。
第二单元的多线程电梯作业，让我真正感受到了OO编程的强大之处。在面对像第一单元那种偏静态的求导问题时，并不能体现出OO编程的强大之处。但是在面对需要多个对象互相合作，多线程并发的问题时，面向对象的编程思想就要显著优于面向过程的编程思想了。利用多线程的设计模式，并将各个类之间的协作关系理清楚，可以比较容易的写出多线程电梯的调度程序。比如如何将输入队列，调度器，电梯这三个对象独立起来，并使他们在多线程并发的条件下相互合、作完成任务。而且如果架构合理的话，在面对增量设计时也可以很好地满足新增需求。在第二单元的第三次作业中，引入了多部电梯，如果架构合理的话，只需要多“注册”两部电梯，程序的改动将非常小。
而如果是传统的面向过程的编程思想则很难进行下去，不同状态之间的转移仅仅靠一个个独立的函数完全描述准确是困难的。并且在面对增量设计时，采用面向过程思想写出的程序的扩展性也不如OO思想写出来的程序好。
在经过第二单元电梯作业的洗礼后，自己对Java的多线程编程以及OO编程思想的认识都有了进一步的提升。
3.第三单元
第三单元的作业形式为阅读官方给出的JML规格，根据JML规格实现接口并补全代码、实现针对指令的交互功能。
本单元的作业比较有意思，从最开始一个简单的路径管理系统，到第二次作业扩充为无向图系统，以及最终第三次作业的简单电梯系统，每一次作业都是在前一次作业的基础上进行扩充，以满足更多的指令需求。这就要求对程序的架构有很好的把控，如果程序架构不合理，不能很好的构建出类之间的层次关系，导致程序的可扩展性很差，很可能就需要在完成新的作业之前，先对上一次作业进行大规模的重构。
本单元的第二次作业相比于第一次作业只是新增了一个无向图的查询，如果想要偷懒，不顾及程序的架构设计，直接把所有指令的计算任务全都放在一个Graph类里实现还是有可能的。但是从第二次作业到第三次作业，继续这么做肯定是不可行的，因为这样做的话一个类的长度肯定是要超过500行了。本人在被这么坑了一次，在完成第三次作业之前就强行重构了一次代码，这个过程确实有一些痛苦，但也十分必要，加强了自己对程序架构设计重要性的认识。
4.第四单元
第四单元的作业是实现一个UML的解析器，需要能够支持对UML类图、UML顺序图和UML状态图的解析，并且要完成对三个有效性规则的检查。
这里必须要承认一个错误，在完成第四单元的作业时并没有像完成第三单元作业时那样花功夫。最后一次作业甚至是在作业提交截至前的十几个小时前才开始阅读指导书，完成设计与编程的。最后算是熬了个通宵，卡着deadline把作业交上去的。
嗯。。。。。。所以作业的架构设计要远远差于第三单元的作业，而且也没有时间对架构进行调整了，所以最后的代码风格分也是惨不忍睹，算是对自己态度不认真的一个处罚吧。
希望等熬过了烤漆，自己可以去继续完善一下最后一次作业的设计架构。
三、四个单元中测试理解与实践的演进
1.第一单元
第一单元的测试与找BUG基本上都是围绕"WRONG FORMAT"展开的，我自己就由于在正则表达式中使用了\s去匹配空白字符，导致在互测中被各种奇奇怪怪的空白字符砍了n多刀。这一单元的测试让我认识到了程序的鲁棒性想要做好不是件容易的事情，程序的鲁棒性也是考察程序质量的一个重要衡量指标。
2.第二单元
第二单元由于输入部分提供了官方的解析包，我们不再需要针对输入的格式进行处理，测试的重点也更多的转向了程序的逻辑正确性和多线程的安全性。在第二单元中由于多线程的存在，如果处理不好各线程之间的同步与互斥，是非常容易出现BUG的。而由于多线程BUG出现的不确定性，就算是做了大量的测试也不一定能够真正定位出BUG的所在地，最后只能通过一行一行地阅读代码去发现程序潜在地安全性。
在构造测试样例时，我采取的策略是在一个小的楼层范围内、短时间投入大量的请求，以检查程序对电梯换向，承载人数限制等条件的实现正确性。
这单元的作业也间接地让我认识到了在编程前做好设计工作的重要性。我记得老师在课上反复向我们强调过：测试只能在一定程度下改善程序的质量，但并不能从根本上提升程序的质量。一个程序的好坏，往往在其设计阶段就已经定型了。
3.第三单元
第三单元的第二次作业和第三次作业加入了许多最短路径以及最短路径的变体问题，在实现各最短问题的求解过程中，如果考虑的不全面，在算法的正确性上就无法得到保证的话，是非常容易出现致命BUG的。
在后两次作业中，我都手工构造一些比较容易出现坑点的测试样例，用它们对自己程序的正确性进行检测。此外，在第三次作业中，还利用大佬写的评测机对自己程序的正确性进行了验证。
在对别人的程序测试时，采用的是跑大量随机生成的样例的办法，但是最后的效果并不是很理想。
4.第四单元
最后一个单元的作业取消了互测的环节，测试也主要是针对自己的程序展开的。第四单元在解析UML图时，由于对一些概念比较模糊，很容易出现理解不到位导致的实现错误。对于一些比较模糊的地方，主要采取阅读讨论区，针对讨论区中提出的一些坑点进行测试，以保证不会出现因理解错误导致的BUG。
四、总结课程收获
1.面向对象的编程思维
大二上学期学习的C语言课程主要练习的是面向过程的编程思维，我感到面向过程的思维方式在解决一些实际问题时会非常的复杂。在学习OO这门课程后，发现面向对象的思想更接近实际生活，在解决一些复杂问题时更加的方便。并且用面向对象思维写出来的程序也往往具有更好的可扩展性。
2.编程能力的提升
对于我这样一个大二上学期才开始接触C语言、数据结构的编程小白，每周一个大作业还是十分具有挑战性的，熬夜爆肝干OO的情况也是真实存在的。但是这一学期的作业走下来后，能够感受到自己的编程能力和debug能力得到了比较大的提升。
3.jprofiler插件、StarUML工具等等
这学期在完成课程学习和编程作业的同时，还学习到了许多实用的插件和工具。编程不仅仅是打开一个记事本简单地敲代码，如果能够将一些辅助性工具利用好的话，它们将对实现设计任务带来极大的便利。
4.Java语言
当然，这一学期一直都在用Java语言完成编程作业，也算是初步掌握了Java这一门编程语言吧。
5.代码规范
归功于checkstyle，我想如果让一个完全不懂程序的人去看我上学期的C代码和这学期的OO代码，它们也都会觉得这学期的OO代码更好看一些吧:）
五、改进建议
1.课上实验
我认为课上实验有两点可以改进的地方：
（1）每次实验课都是上午刚讲完课，下午就要上机考。这样做的本意是好的，希望同学们能够及时掌握课上所学的知识，更好地完成作业。但是对于一部分像我这样基础比较薄弱，反映比较慢的同学，仅仅通过上午的两节理论课是难以达到上机要求的。
因此，我建议课程组在每次上机的几天前，都能给同学们提供一些具有针对性的预习材料，以便同学能够提前进行预习。
（2）每次上机结束后，得不到任何有关实验的反馈结果。可能对于大佬来说，上机实验任务它们都可以轻松并且正确的完成，但是对于一些小菜菜，我们可能并不足以在限定的时间内完成上机任务，而课上实验结束后，就真的是彻底结束了，根本无法进一步查看和完善实验任务。
因此，我建议课程组在每次试验后能够继续保持实验界面的开放性，并且提供出一些比较优秀的上机作业供大家学习。
2.作业难度
在完成第一单元作业时，有些同学可能是刚刚接触Java，很多Java的语法都没有掌握好，所以作业难度不易过高。在经历过一学期的所有作业后，我觉得第一单元的求导作业难度确实有一些大，尤其还是出现在课程初期，所以希望能够降低一下第一单元作业的难度。
3.理论课内容
UML单元中，感觉老师在课上对UML图中各种元素之间的关系讲的有一些少，所以在完成作业时会感到有很多把握不准的地方。希望老师在课程中能够再加入一些对UML图元素的讲解内容，以便同学们能够更好、更大胆地去完成作业。
最后的最后，感谢老师们和助教们一学期辛苦的付出。这一学期走下来后，发现OO课程并没有之前传说的那么可怕，那么不好，整体的感觉还是非常不错的，能够感觉到自己的能力得到了一定程度的提升。希望OO这门课能够变得越来越好！！！