OO第四次暨期末总结
写在前面：
不知不觉，OO这门课程已经陪伴我们度过了大二年级上学期的生活。有过痛与泪，亦有完成任务和回首收获的快乐。借最后一次博客作业的机会，就让我汇聚起这学期所学过的点点滴滴，为这门课程画上一个完整的句号吧！
（下图是笔者本学期OO的历次作业，真的是经历与收获了很多很多~）
一、测试与正确性论证的效果差异
顾名思义，测试即是通过大量的样例（合法或者不合法）对程序进行尽量完备的覆盖性测试，这是在课程前期互测时用到的主要方式，亦是公测的设计原理所在，直至证明程序可以在所有情况下均能够正确运行。而正确性论证，则是依托JSF规格和repOK，对所有类的实现有效性和方法的正确性进行完备论证，直至通过严密的逻辑论证证明程序是没有问题的。对比之后可以发现，测试是从实践层面，而正确性论证则是从逻辑层面对程序进行了正确性保证。这两种方式各有利弊，但并不矛盾，一个真正合格的程序，应该能够经过测试和正确性论证的“锤炼”，方可保证其鲁棒性。
对于测试：
优点：
- 因为测试是更加偏向于实践的测试，所以相比于正确性论证更加能够在实践的角度加以完善。
- 当通过测试发现bug时，因为测试往往是针对特别的情况进行了划分，所以更加能够快速锁定bug所在并且予以修正。
缺点：
- 很多情形下很难保证对一个程序或者方法进行了真正覆盖了所有情况的覆盖性测试，对于情况复杂的程序更是如此。
- 保证测试的完备需要很多的数据，这些数据有时候很难构造，有时候甚至难以获得。使得测试的过程比编程的过程复杂数倍。
对于正确性论证：
优点：
- 正确性论证的做法相比较于测试能够更加简单的实现全面覆盖。
- 正确性论证是在原理层面对正确性进行了论证，相比于实践层面的验证更加接近程序的本质。
缺点：
- 正确性论证虽然是从逻辑层面来论证程序正确性，但不能保证的时某些语言可能实现的功能与程序员所构思的并不相同（比如=和==的区别）。即，正确性论证更加具有主观性。
- 理想的正确性论证应该是逻辑严密的，而测试者并不能保证逻辑上的完全正确，这对于长度较长的方法（如大于50行）的方法尤其困难。
- 可能通过正确性论证程序本身并没有问题，但在实际使用的过程中会出现一些困难，这个缺陷必须通过实践方可补齐。
综上所述，测试和正确性论证都是在程序构建结束后进行验证程序正确性的工作，各有利弊但并不冲突。在实际编写代码的过程中，“双管齐下”能够起到更好的效果。
二、OCL语言与JSF规格的相似和不同之处
OCL语言简介：对象约束语言（Object Constraint Language，简称OCL）是一种用于施加在指定的模型元素上约束的语言，作为图形符号的补充，说明建模元素的有关细节，例如：约束，前置条件，后置条件等。
OCL与JSF规格的相似之处：
- 均为声明性语言，不会改变模型（方法）的内容。
- 二者均具有一套各自的规格对写法进行了约束，包括前置后置条件等等。
- 二者均是为了更加规格化的程序而存在的。
OCL与JSF规格的不同之处：
- OCL语言主要面向的是指定模型元素，而JSF规格面向的是方法和类。
- OCL语言是形式化无二义的语言，而JSF规格由于允许自然语言的存在，所以虽然相比较OCL更加简单与开放，但准确性相对较差，可能出现二义性。
三、第十四次作业的单电梯系统的ULM类图、顺序图及状态图
类图：
顺序图：
状态图：
四、学期总结
1.四个单元模块知识点之间的关系
总结下来，本学期的知识点分为了四个单元模块，两个大类：
第一个大类是Java及面向对象程序设计的训练，主要侧重于编程。
第一个单元，我们主要训练了面向过程向面向对象编程思想的转变，是整个课程及面向对象编程的基础。这个单元的训练后，我逐渐属性了Java语言，了解了面向对象语言中的类与对象等面向对象语言的特征，并且学习了继承，接口等，进一步理解和应用了基础知识。
第二个单元，是Java语言的进阶应用，在这个单元中我体会了面向对象语言的优势，通过它我们可以实现多线程操作，并且在这个过程中体会了难以复现的多线程debug体验，学习了如何保证线程安全相关理论知识。
第二个大类是面向对象编程的规格化训练，侧重于规格化的设计以及严密的逻辑。
第三个单元，我们训练的是规格化的设计方法，如，JSF规格，repOK的实现等等。从这一部分开始，我逐渐体会到程序的设计是有其标准流程所在的，保证规格化设计之后，编写起代码亦可以更加的得心应手。
第四个单元，我们则训练了测试与正确性论证两种代码完成之后的正确性保证方式。借助第三个单元所实现的规格化设计，这一部分的论证便能够十分得心应手，当然通过这两种方式，我也确信和保证了我程序的鲁棒性。
综上所述，以上四个模块是环环相扣，循序渐进的。我们完成了从设计，规格化，再到正确性论证的整个过程。这样的整个流程在实际工程中将是十分使用的。
2. 我实现的程序以及自己的进步
回顾整个课程经历，我实现了多项式计算，傻瓜电梯，捎带电梯，多线程电梯，IFTTT，gui出租车系列编程等程序。这个过程自然是受益颇多的，站在现在的角度去看前几次作业，那可真的称得上是“惨不忍睹”了。我主要在以下方面取得了进步：
1. 能够深入理解面向对象思想和熟练使用Java进行面向对象编程。
2. 设计方面更加得心应手，能够通过合理的规格来编写代码，这样不仅编写代码的体验更加良好，代码的可移植性亦得到了极大提升。
3. 在测试方面有了自己的心得，亦通过Junit，正确性论证等的学习找到了更好保证程序鲁棒性的方式。
3. 我对工程化开发的理解
首先，工程化开发是一个需要很多人通力协作的事情，它不同于个人编程，需要严格的规格作为规范。在个体去完成一个项目时，由于有着自身的思路，所以能够很简单的连接起来每一个类和方法。但对于工程化开发，却必须具有严格的规格。就像螺丝钉与螺母的工业标准一样，容不得随意与马虎。否则在多人完成的代码拼接起来后，哪怕单个方法并没有错误，但拼接起来后就会出现意想不到的问题。
其次，对于工程化开发的个体，需要保证自身的正确性，这就需要用到测试及正确性论证的方式。如果每个人都能对自己的任务严加要求，不仅没有做无用功，反而提升了整体的效率。
综上，我认为这门课程着重培养了我们的工程化的设计思想，是会让我们在日后受益良多的。
4. 我对课程的期望与建议
首先，个人认为，这门课的互测环节是有它的改进空间所在的。在平时的沟通中，身边的同学这个环节吐槽颇多。我认为问题有二：
a. 现在的课程框架下，挂bug对测试者来说是百利而无一害的，这就导致了极个别同学会有不管三七二十一，先挂上再说的思想，导致了大部分误报。
b. 同学之间的扣分标准是不太一样的。有的可能觉得一个类别，或者同一种bug挂一个就行。但有的同学会根据不同的角度对一个程序进行报错，虽然可能只是一处代码中的错误，这样就导致了写的或许还行的代码却扣分极多，排名低于同水平代码。
以上便是同学之间吐槽较多的问题。我认为可以针对具体问题进行改进。首先，改变测试者扣分不会受任何损失的现状。比如引入扣分有效率机制，对于乱扣分现象可以进行直接针对性申诉，若一位测试者被判为乱报的个数达到一定阈值，会对他的分数产生一定影响。
其二是同学们之间的标准不同的问题，我认为可以对扣分标准进行更进一步的明确，比如同一处代码导致的错误认定为同一个bug，按严重程度进行划分，但这需要被测者提供证据，使作业代码可以得到改进，而不是用完即扔。我认为更加明确的规则可以尽量减小主观的影响。
在OO代码的编写过程中我还遇到过这样的问题。比如第一次编程Java程序不知从何下手；第一次编写多线程程序但手边缺少相关资料，只能进行自我试错；第一次写JSF规格，单单靠目前提供的样例还不足以完全掌握规则。我认为面对这样的困境，课程可以考虑这样的改进：
a. 每次作业下发后，可以更多的提供一些小tips，比如从哪里学习相关知识，该参考些什么资料，可以用怎样的思路去解决当前作业中的问题。这样可以使同学们在编程的过程中少走弯路，减小一些编程的痛苦。
b. 我注意到，每次OO上机课，都会提供相关知识的教程。这个材料是不错的，可以在里面学到很多知识。但上机是在我们已经进行了课下作业之后进行的，并且有时间的限制，难以充分阅读吸收。我想，课上的教程相关材料可以在相对应课下作业布置后就进行下发，上机课就只进行对应练习，一来充分利用了材料，二来使得同学们课下作业的编程又有了新的依据。
还是开头的那句话，这是一门让我有过痛与泪，亦有完成任务和回首收获的快乐的课程。所以，我真心希望和祝愿这门课能够在课程组老师和每一届同学的同学变得越来越好！
完结撒花。
