测试和正确性论证的效果差异及优缺点
| 基本方法及效果差异 | 优点 | 缺点 | |
| 测试 | 构造测试用例集，运行程序并输入测试数据，从不同方面对程序展开测试：如功能测试、单元测试、鲁棒性测试、性能测试、回归测试。 | 易于实施，有自动化测试工具 | 覆盖率无法确定达到100%，程序仍可能有错 |
| 正确性论证 | 针对程序的每个类和每个方法，逐条检查其逻辑正确性。 | 基本覆盖所有代码，确保正确性 | 工作量巨大 |
可以看到，使用测试还是正确性论证取决于对程序测试完备性的要求和程序测试完成时间之间的trade-off。因此工业界的大多数项目倾向于采用测试，而航空航天类的程序对正确性要求更高，更可能采取正确性论证。
调研OCL语言
OCL（Object Constraint Language）对象约束语言是用来进行约束定义的，形式化的无二义性的语言，在于1995年在IBM设计成功并开始使用。OCL的基础是数学中的集合论和谓词逻辑，并且它有一个形式化的数学语义，但是它并没有使用某种数学符号。OCL是一个类型语言，任何表达式的值都是属于一个类型的。
OCL与JSF的区别在于，OCL有严格的语法规则和数据类型等等，严格形式化而无二义性；JSF则允许自然语言，形式并不是很严谨。
相似之处在于它们对于方法和类的约束均通过前置条件后置条件和不变式来完成。
第十四次作业相关图
类图：
时序图：
状态图：
整理总结
四个单元模块知识点
第一单元主要是java基础方面的学习，包括面向对象的思想，正则表达式的使用，继承、接口、多态等等。
第二单元是难度最大的多线程编程，主要涉及多线程程序之间同步与互斥的处理。
第三单元引入抽象与规格，每次只做少量功能性要求，重点在JSF的编写与检查。
第四单元重点是测试与论证，包括Junit自动化测试和正确性论证。
这四个单元的模块基本上完成了从需求到基本的实现，再到线程安全控制，规格化设计，正确性论证等一系列软件开发过程中最基础的部分到最高层的部分。是一个递进学习的过程。
梳理自己的程序及进步
本次OO课程确实做到了让我觉得看第一次作业的代码“看不下去”。我觉得最重要的还是学到了OOP的思想，即合理的数据封装，工程设计以及计组也提到过的高内聚低耦合的思想。比如，写完出租车再去看ALS电梯的代码时，就会明显的感觉到自己很多方法代码行数过多，不够简洁，能按功能拆分的方法没有合理拆分。同时，规格的书写也让我感受到了设计先于实现的重要性。
对工程化开发的理解
虽然我们的作业还谈不上工程，也没有体会到工程项目上人员的协作，但是我们确实体会到了工程中需求、实现、测试、论证等方方面面。我们一学期完成的这一系列作业，也可以看做是一个小型的工程周期。我认为工程化开发，模块化规格化十分重要，这样在多人协作时才能大幅提高工作效率。因为实际的工程不是我们这样一个人写完所有的东西，而是每个人分工明确，因此每个人的代码必须体现良好的模块封装和严格的规范。
对课程的期望和建议
1.互测分组中非顶级组的同学无法欣赏到优秀的代码。我认为互测对我们的提高中一个重要的方面就是可以看到其他人的代码，从中学习到自己没有实现或者没有想到的东西（我认为从这方面学到的东西比从JSF鸡蛋里挑骨头要合理而有用得多了）。然而按成绩分组互测虽然有利于同水平的人进行测试，也减少了面向运气的成分，却并不能让排名不是很靠前的同学欣赏到大佬们的代码。我在前几次作业中抽到的一些代码很值得学习，可是后来拿到的都不是很规范。希望以后的课程可以开展类似于“优秀代码分析”这样的课程活动，否则，我们自己写自己的程序也只是闭门造车。同水平的人之间互相看代码，大佬们就会越来越强，不是很大佬的或者水平不强的同学提升就很有限，同学间差距也会越来越大。
2.理论课过于理论。我认为前两个单元的理论课可以学到很多东西，听了也确实对完成作业很有帮助。但是从讲规格开始的理论课太过于抽象，尽管有代码实例，但是上课放几张ppt并没有留给我们时间去看代码去思考，跳跃性太强。实际上后面几次理论课对个人完成作业以及对规格的作业的理解提升帮助不是太大。
3.课程难度分配很奇怪。老师课上也说过多线程电梯和IFTT是最难的，导致很多同学多次通宵。然后后面的JSF和测试论证则很轻松。我觉得课程组应该将多线程部分的时间延长一些，后面JSF的时间缩短一些，这样更合理更有利于同学们消化吸收最难的部分。
4.希望课程分数能切实反映学生能力，希望互测得分扣分机制更加公平完善。
5.后两个单元多次先写代码后补规格，并不能很好的提升我们对规格的理解，希望课程组对这方面有一些改善措施。
