一、测试与正确性论证的效果差异
对工程的测试是学习计算机和软件工程的同学必须掌握的专业技能。有白盒测试、黑盒测试、回归测试、验收测试等。人工设计的测试样例具有一定的主观性，由人来设计测试数据、营造测试环境、验收测试结果，确定错误位置，因此对测试者的测试技巧具有较高的要求。
而正确性论证则是以一种抽象的视角去审视工程代码，验证抽象对象是否都得到了有效实现、方法实现是否都满足各自规格、所有方法是否都不会导致不变式为假 。
测试的优点是测试样例的构造比较简单，不需要深入学习正确性论证的内在逻辑理论，赵傲问题可以针对性的测试是否修复。
测试的缺点是因为测试的覆盖性，设计简单的样例对整个工程进行全覆盖BUG测试难度太高，即使通过了部分测试样例也难以保证程序的稳定性。
正确性论证的优点是通过逻辑层面对程序的设计合理性进行严谨的分析，分支覆盖率高，“以理服人”。
正确性论证的缺点是学习正确性论证理论需要一定精力，测试论证的严谨性需要反复训练才能达成，抽象到的层面不好把握。
二、调研OCL语言，并比较其与课程所介绍的JSF规格之间的相似和不同之处
OCL：面向对象约束语言，作为图形符号的补充，说明建模元素的某些细节，例如：约束、前置条件、后置条件等。
OCL的原则：①：声明性语言，不会改变模型中的内容。②：形式化语言。③：无二义性规范语言。④：类型性语言，每个表达式都有类型。⑤：易学好用。
与JSF的相似之处：
基本类型： OCL和JSF一样都支持整型、字符串类型和布尔型。但OCL还有实型（Real）
都有约束、前置条件、后置条件等。
与JSF的不同之处：
布尔型中有implies（蕴含），即b1 implies b2则当b1 b2均为真或b1为真b2为假时，表达式为真。
OCL表达式由操作符和运算符按照一定的规则构成，表达式和特定的上下文有关，表达式具有确定的值。表达式的上下文表示这个表达式所作用的范围，可以是类、类的属性和操作。
OCL表达式可以有不变量，用inv关键字规定。OCL可以从初始的上下文导航到和它有关系的其他类，这些类与初始的类有关联和组合关系。
OCL定义的高级数据类型有群、集合、袋和序列。其中群是抽象数据类型，集合、袋和序列是群的子集。
OCL的约束、前置条件、后置条件用context、pre、post表示。
三、根据第十四次作业的单电梯系统，针对调度器、电梯、请求队列和 请求，至少整理出 一幅UML类图、一幅顺序图和一幅状态图，并使用 图(graph)来表示出模型
类图：
时序图:
状态图：
四、整理总结一个学期所学所练
1、阐述知识点之间的关系
第一单元是比较基础的单元，主要任务是学习JAVA语言面向对象的特点、学习JAVA语言的语法，熟悉掌握JAVA的内在机制，尽快适应以功能、类为划分的代码特点，明确分工。
第二、三单元多线程是课程难度陡然上升的阶段。
多线程的不确定性给debug带来了很大的困难，无法正常的进行调试，也无法还原某些特殊场景，因此出现了一些玄学问题。后来慢慢意识到有很多问题是多线程的保护机制设计的不好，没有严格把控这种执行顺序的内在确定性。也学习到了如果巧妙地通过打印输出查看县城调度执行过程中的细节，修改线程不安全的部分。设计时，应注意原则。
第四单元主要是正确性的论证等。在这一单元我们学到了测试程序实现正确性的新方式，分支设计的检查更科学、有效。
2、梳理自己所设计实现的程序，分析自己在设计、测试和质量上的进步
设计：设计思路更注重算法、而不是简单的代码堆砌，完成功能即可。尤其是回来写第三次作业的分析时，发现那个时候的代码冗余很多，存在明显的重复堆砌现象，目不忍视，苦不堪言。
测试：一开始就是在一些非常基础的功能测试，或者是大数据轰炸，后面就知道应该在设计时记录下容易忽视掉的BUG，甚至有些问题就在于代码逻辑的漏洞，所以要想有效的测试别人的程序、发现自己的BUG，分析分支之间的联系非常重要。
质量：一开始的程序BUG比较多，虽然被别人发现之前大多都已经测试出来并修改，但是因为不熟悉语言的特性，思维的漏洞也多，出现了很多让人头疼的低级错误。后面基本上就很注意了。
3、阐述自己对工程化开发的理解
我认为应该注意一下几点：
1、代码的可读性要好
2、代码逻辑要清，分工明确，方法实现算法精妙易懂而且代码长度较短
3、注意分析功能需求和代码实现之间的联系，对一些优化的环节必须做好记录
4、工程化的测试非常重要，要从分支的角度保证测试的覆盖率。
5、无论任何情况下都应该保证工程的可靠性，系统的瘫痪是无论如何不允许的
6、设计出的工具运行起来要用户友好。
4、对课程的任何希望和建议
我个人认为OO课程的训练目标没有什么问题的，而且吴际老师讲课认真负责，助教组亲切耐心，必须给个赞！
一些细节可能稍作修改以后会对课程有更好的帮助。
1、增强课程概况的透明度，提前预警同学们可能埋下的雷：以后几次作业为例，出现方法太长导致必须重构的情况，一方面是一开始的JAVA代码水平不太好，另一方面是没有这方面的提示，就没有注意这个问题。如果我是助教，我会在第一时间先告诉同学们前面哪些地方没有处理好可能会导致后面很难做，也可以拿几分往年实例对比，预防总比亡羊补牢要高效很多。
2、适当调整课程顺序：把规格训练、测试训练往前提一提，好处有两个：趁同学们还很熟悉电梯的架构的时候去训练，如果有代码需要修改也节省很多时间，印象也很深刻，可以增强作业的有效性。同时在课程比较靠前的阶段就引入这个内容，可以提高同学们的重视。长期的训练才会更有效。
3、关于作业信息的对称：感觉可以考虑取消掉群内问问题这个环节，助教依次解决issue上的问题效率会很高，透明性也很强，不会出现信息不对称两个同学互相推诿或者同学作业偷懒把锅甩给助教的问题。
4、互测环节：本身还是没有问题的，但是最好设置一个信用机制，被申诉成功次数过多（异常多）会导致分数受损。这样对这种竞争有一个好的约束。
5、可以设计一个学习对方代码的环节：以某种方式推动同学去阅读学习别人的代码优点，而不是盲目用大数据测BUG拿分即可。
在这个过程中， 我看到很多同学他们的水平已经达到了令我敬佩的地步，我也在不断的反思自己，发现自己还是有很多需要优化的思维、需要培养的好习惯。发现问题就解决问题，只要我们不是在原地踏步，就是有收获的。