oo课的总结得与失是与他处的格局不同的，大概就是这样一节矛盾的课吧，想要拿到衬衫就要许许多多个日夜看到沙河的日出，然而熬夜又熬夜之后脂肪却先于知识囤积在了身上，望着被撑起来的报告bug衬衫，实在是感慨万千，大概这就是oo课的“欲戴王冠，必承其重”吧。
测试与正确性论证的效果差异及优缺点
测试与正确性论证从思路上来说是完全不同的，测试仍然是一种将代码看成黑箱的处理方式，将得到的输入输出与样例进行对比，如果得到错误，为了报告bug再去打开黑箱。当然，我们在oo中的测试可能更偏向于面对代码构造测试样例，而实际中面对更长更加模块分工的代码，测试样例的效力可能会大大下降。
而正确性论证，是将黑箱打开进行测试。一个方法我们要说明调用中不改变repok这其中包含了电梯上升下降不动，错误输入，边界测试，压力测试等等各种情况，在充分考虑这些情况的基础上，正确性论证实质是将各种情况的概括和抽象。如果要说有什么不足的话，那就是正确性论证需要系统的读完代码，因此在分工合作时，测试他人的代码不可能使用这种打开黑箱的做法。当然，对于水平不够的我们而言，在正确性论证中时常出现对于临界和压力的忽视，因此仍然要配合基于样例的测试。
OCL调研及与JSF的异同
OCL (Object Constraint Language) 即对象约束语言，是一种指示用户建模系统中的限制方式，在在UML2标准中，OCL不仅用来写约束，还能够用来对UML图中的任何元素写表达式。每个OCL表达式都能指出系统中的一个值或者对象。因为 OCL表达式能够求出一个系统中的任何值或者值的集合，因此它具有了和SQL同样的能力，也就是说OCL也是一种查询语言。
与JSF的异同：
相同：
均使用了数学的方法（谓词逻辑、集合论）来表达对对象和方法的约束，都采用了自然语言和数学符号折衷的方式，使得用户能够使用普通的ASCII字符来表达数学中同样的概念
表达式仅仅描述了应该去做"什么"，而不是应该"怎样"去做。不需要考虑这些表达式是以何种语言，何种循环去实现的，在共通的标准下达到相同的效果即可。
都包含前置条件和后置条件的声明，也都包含不变式相关逻辑
不同：
OCL中没有JSF的MODIFIES，但是每一个OCL表达式都必须有明确定义的上下文。
第十四次作业类图、顺序图、状态图
图 电梯状态转换图
图 电梯系统类图
图 楼层请求时序图
图 发出电梯请求
学期总结
四个单元模块知识点之间的关系
对于我的学习之路来说，我想起了华罗庚先生所说的把书由厚读浅再读厚的过程。在刚刚接触面向对象思想的时候，是完全的生疏。此时的问题并不是说要怎么建立队列，数组，而是带着根深蒂固的面向过程的思维（实际上c的学习也并没有到融会贯通的地步），这里这个方法到底和函数有什么区别呢，这是完全不能够理解的。而第一单元的学习主要是从框架的角度，引出了java的类，属性，方法等元素，继而介绍了继承，多态等基于面向对象的思想而出现的知识。
第二单元的学习，开始了多线程的学习，然而有着多线程电梯和ifttt的这一单元是“浅”的，我们主要的训练内容是代码的熟练程度，回顾自己的博客，但是我的确是纠结于，队列要怎么建，扫描要怎么扫，还为了正则匹配的bug，在几次作业里都被针对了。
第三第四单元的学习，又上升到了一定的层次。我们所学的这门课程是使用java语言授课的面向对象设计。前两单元主要内容是“面向对象”与“java”语言，而后两个单元，中心在编程上。对于单次作业是否通过来说其实这些内容并不是很重要，但是作为日后的准备，系统化，工程化的思想是无比重要的。
最简单的例子就是solid到底是什么，其实solid是什么并不是很重要，只是一个定义，用法语写也许就是另一个单词。但是，程序员A与程序员B，他们的solid是否相同，这才是至关重要的，而为了让所有人的solid都相同，就必须有一定的规范被明确定义。第三单元所讲述的jsf规格，数据抽象等，就是在建议工程化的定义。Jsf就好像衣服，衣服是量体裁衣，但是反过来，很多时候对于衣服的考量也使得方法的表达得到了改观。而第四单元是在没有测试的情况下对于自己代码的工程化考量。
自己的进步
其实这一点还是感触最深的，虽然说了很多工程化，规格等等。但是这门课最大的影响还是代码能力的提升。一开始的时候看到了代码是这样那样，但是写的时候add方法里面，this.number这个this到底什么意思，可以不可以换还思考了好久。仍然是show me your code这种学习方法收益最大，把样例的代码切实的敲出来，然后运行。比起脑中跑程序所能发现的问题和学到的东西要多的多。
随着时间的推移，从傻瓜电梯的无效到最后出租车的2000行（虽然2个java文件加起来2000行是挺不好的习惯），我自己都可能惊讶自己的进步。最后拿到“菜鸡进步奖”也还是很开心的，虽然熬了这么多夜，体重涨了不少导致衣服很难穿的下。对于多个模块的代码，能够掌握他们的功能（保证通过测试），确实是课程带给我的提升。
工程化的理解
其实这门课很多同学的不满之处就在于这里，课程组将工程化的理念加入了课程设置，从课件到作业再到以互测为特点的课程体系本身，都体现着工程化的思想。然而同学们在此之前对于工程化很少接触，之后也有一段时间暂时接触不到。因此对于工程化是缺乏理解的。在我们的视角看来，接触的不是工程化，而是jsf，repok，无聊的互测和单词写错都会扣分。我们缺乏一根线把这些串联起来，在和一些有实际经验的同学交流后感受到，我们的能力和经验的缺乏，是我们没有办法把这些看成体系，更没有办法去验证工程化的意义在哪里的一个原因，所以我觉得之后的课程中应该有一些变动，能够让同学们意识到自己在接受工程化训练，而不是jsf和repok的训练。
对课程的期望和建议
实际上感觉自己一直是以追赶者的心态去学习整个课程，因此更多的时候看到的是自己的不足。如果要说课程改进的话，似乎还是希望先导的体系能够使得一些同样基础不高的同学能够不会一上来就犯怵，在学习面向对象思想的时候不会因为代码能力而先天不足。
当然互测一直是同学们所诟病的地方，个人信息导致无效似乎是个永恒的难题，另一方面在jsf测试的时候，我的一个number++这样仅有一行的方法因为没有写jsf而被扣分，站在我的角度肯定是很难接受的，这样一个错误和程序错误等价确实很难受，希望以后能在分值衡量上有所考量。
至于课程的难度分配上，在多线程这里确实是突然拔高到不合理的高度，但是后面的内容也都是多线程的作业，不可能有所调整，也许和计算机组成一样在突然的难度高峰这里多放几个星期会好一点。以及在上面所说的工程化的建议。