测试与正确性论证
效果差异
测试是试图通过使用一些特定的、或是随机的输入，并预测代码的执行结果，来对结果进行检查。
正确性论证则需要对代码的行为进行进一步的抽象，并考虑每个代码部分之间的关系是否正常，是否存在潜在的问题。
前者的自由度很高，更加具体，但对潜在问题的覆盖性稍差；后者需要的代价较大但固定，抽象性更高，覆盖性很好。
优缺点
测试
优点：
- 容易构造
- 适应正常的开发过程，并能确定问题具体在实现中出现的位置
缺点：
- 覆盖性稍差，提高覆盖性所需的代价很高
- 容易找出问题，但修复问题所需的代价和代码的规模相关
正确性论证
优点：
- 覆盖性好
- 抽象性高，可以在设计之初来避免问题
缺点：
- 代价直接与代码规模相关
- 抽象程度过高会导致与具体实现脱离，达不到效果
- 抽象程度过低则代价很高，与具体实现差别无几
比较
代码规模直接限制了寻找问题的代价。测试可以以较小的代价达到寻找表层的问题，正确性论证可以以固定的代价达到控制潜在的问题。
Object Constraint Language (OCL)
The Object Constraint Language (OCL) is a declarative language describing rules applying to Unified Modeling Language (UML) models developed at IBM and is now part of the UML standard.
（来自Object Constraint Language - Wikipedia）
如今，其标准由Object Management Group维护，OMG是一个非盈利的标准制定协会。
OCL来自wiki的一部分例子：
context Auto inv: self.registration>=self.constructionYearcontext Person inv: self.cars->notEmpty() implies self.cars->exists( c | Calendar.YEAR - c.constructionYear < self.age)
与 JSF规格 的异同
相似
- 两者都可以用来描述对象及其行为的限制
- 均可与具体实现无关，仅限制前值和后置条件
不同
- OCL的标准更完善
- JSF描述Java代码的规格，与具体开发关系密切；OCL的用途更广，可以用于数据库的查询，与SQL均被划为Query languages
- OCL的表现力更强，完善的标准也更容易实现解析；JSF要求过多，强制要求一阶逻辑（及两个谓词）或自然语言，一阶逻辑表达力差，自然语言难于解析
第十四次作业
类图
顺序图
状态图
总结
四个单元模块
大致可以分为 Java和面向对象基础、面向对象与多线程开发、规格与文档、测试与正确性论证。
关系
“面向对象与多线程开发”部分严格依赖于“Java和面向对象基础的知识”；测试与正确性论证也依赖于规格与文档的能力。
作业之间也明确地依赖于之前的作业内容或作业所需的能力。
梳理
Java和面向对象基础没有很多值得提及的，但是至少是我初次进行完整的Java程序的设计与开发。多线程的部分可以说让我稍微接触了一下Java在这方面的优势，也大致地了解了很多并发模式可能的底层实现，虽然与面向对象的关系可能远了一点。规格与文档是我第一次知道世界上存在不是给其它开发者提供帮助的文档，刷新了三观。测试与正确性论证是我一直很希望能了解的内容，安排学习JUnit也是让我很欣喜，这门课程竟然有如此正常的内容。
总体来讲，开拓了眼界。
工程化开发
说些实际的话，根据计算机组成的实验课以及这门课程的内容，可以发现高院长提出的“工程化开发”就是统一化开发模式；即对开发的几乎个个层面上进行限定。面向对象的作业也很好地体现了这一点。
简单地说，这种方式无法适应任何正统开发的需要，仅仅只适合于高校留作业。所谓的“各高校争相模仿”也是基于这个原因，毕竟规范所有的步骤自然容易得到方便教学、方便评估的作业。那种“整齐划一”的感觉也能很好地给评估者一种统治感，类似于中小学穿校服。问题自然也很明显了，这种方式没有一般性，并且若所要求的规范很不合理甚至自相矛盾，同时教师固执死板，结局就是如今中小学的校服情况。
课程
大开眼界，这是我参与的第一个内容与名字几乎不符的课程。
理论课（除作业相关）和实验课的内容还是相对来讲非常完善，为学生的开发能力打下了基础。
遗憾的是理论课的内容大量地描述定义和例子，很少提到面向对象的一些原则相对其他的开发方式的优势和原则之间的关联。仅仅只是定义和例子的话可以说与网上的“面向对象”内容几乎一致，几乎没有优秀的一流高校应有的出彩点。同时关于Java的内容相对过少，内容的完善度甚至不及专科院校，缺乏开发的高级能力的培养；严重依赖于作业的内容，而作业的内容也不需要很强的开发能力。
实验课的内容相比之下很适合学生训练；作业也应当和实验课的进度配合，而非提前或延后。稍稍有些问题的地方是，实验课提供的代码风格不统一，缩进不是很正常。
作业的话各个模块需要的能力几乎一致，并且很少有通过作业内容来体现面向对象的优势，仅仅只是通过互测来强制要求应用一部分面向对象的设计方式，严重缺乏启发性。并且因为互测，评分与导向性并不倾向于带领学生提高代码的质量，而是如何规避风险、实现若干次大型的博弈场景。好事是几次作业的情况，收集一下可能会辅助博弈论与社会学的研究。
期望与建议
规范用语（课程存在滥用词语的情况，如语法树），取消互测。