1.测试与论证
测试是通过尽可能多而全的构建样例，让程序运行，并且通过观察程序的运行结果与期望对比，得出大概率正确的结果。
初步的样例选择简单，随着覆盖比例上升而变得越来越困难，就好像0分考到60和90考到100的感觉。
正确性论证是根据代码规格，逐步论证代码的正确性。如果代码的规格正确，同时代码的实现正确，就得出总体正确的结论，是一种纯逻辑推演的验证方法。
对于规模量小的实现清晰的代码段容易实现，当规模上升后就不太好用了，但是可能做到100%的正确性论证。
在我看来，测试比论证要更常用而且更好用吧，对于底层的小模块代码实现可以论证，对于整体考虑交互通信之后还是测试更方便。
因为我们讨论问题，不能一概而论而不考虑大环境。大多数情况下，软件开发不是为了实现功能，而是为了满足用户的需求。所以对于不同的人可以有不同的要求，没有必要大费周折进行形式化验证的就不需要，所以追求100%的正确并不一定是明智的选择，毕竟时间很重要，收益最大化才是最好的。如果工程的实现满足用户需求而存在的BUG不太影响用户体验，那么这样的BUG就无关痛痒，所以相比较来说，我认为测试验证更具有实际意义。
2.OCL
对象约束语言简称OCL(Object Constraint Language)，它是一种用于施加在指定的模型元素上约束的语言。OCL表达式以附加在模型元素上的条件和限制来表现对该对象的约束，其中包括附加在模型元素上的不变量或约束的表达式，附加在操作和方法上的前置条件和后置条件等。这一点和我们使用的JSF相同，都是通过对方法的分层描述实现的。都是形式化语言而且没有二义性。
不同点在于，我们使用的JSF相对来说较为轻量简单，而OCL相对复杂，有自己一套固定的数据类型和操作。OCL满足每个表达式都有类型，同样看重数据项的正确性，而JSF需要保证每个语句都是可以判断的布尔表达式，更多关注方法和类的正确性。
3.作业图示
这学期的JAVA学习一共分为四各部分，每个部分持续一个月，
第一章是Java与对象，介绍基本的面向对象的概念和思想，是编程思维从面向过程到面向对象的转变。这一部分是基础，是决定代码架构最重要的一部分，在于对类的抽象，这是贯穿16周始终的一个部分。
第二章是并发与安全，是多线程程序的设计的入门。一开始的高强度训练让所有人都掌握了多线程的基本实现方法，但是如何更有效的设计代码，以实现线程安全，我觉得是欠缺的，一上来就想起的很高。
第三章是抽象与规格，这一部分是对之前的凝练，但是对已经实现了的东西进行重新抽象，这一点就人的心理角度讲不是很有刺激性，缝缝补补是人之常情，尤其是在这么长时间的工作下。
第四章是测试与论证，这一部分意在培养同学们真正面对工程性问题时的实现与验证能力，这一部分的设计位置相对合理，但是由于测试的程序是很久之前的，所以代码的重构代价相对来说更大，所以更多的测试与论证是基于一个不够规范的代码的。
对于自己实现的程序，更多的进步是在于一点点熟练，程序写多了就知道该怎么去划分一个类了，而且作业做多了就知道如何去看指导书了。
对于工程化的训练，我觉得在现在为止，只能说是有一个概念性的框架，并没有真正看过系统性工程是如何实现的。所以还要慢慢来，以后说不定什么时候就能想起之前学过的东西了呢。
4.关于对这门课程的期望
①对于课程的安排
我觉得上面的讲到的四个部分的顺序有点问题，导致后期的训练效果并不是很好。不知道是为了提高这门课的难度还是怎么，要把多线程放到如此靠前的位置，既然希望训练我们有足够强的工程化水平，就要打好基础。为什么要在开始起步的阶段就直接写庞杂的多线程程序呢？同学们更多的是根据自己东拼西凑学到的东西，将一个没有系统性的多线程程序写好，第一要义一定是没有BUG，其次才是如何实现。对待这样的程序循序渐进，并且希望通过对已经实现了的、又不够规范的进行规格抽象，想想也是有悖事物发展规律的。
我个人感觉，将抽象和规格放到第二部分，将多线程放到第三部分，前半部分进行多个小程序的练习，后期再进行一个循序渐进的大程序才是更好的选择。单纯的提高难度有时候并不太有效。
②万事万物都要以人为本
我相信课程组的出发点是好的，但是首先要考虑学生的感受。一门课程被大家诟病那就肯定说明大家在当时接受程度不是很高，我不好说以后会产生什么样的效果，但是拔苗助长总归是一件坏事。其实对于课程难度我觉得大家并不在意，更多的是对课程形式的怨言。所以不妨每年大改一次，看看效果，再多个可能中选一个，最终做到真正的同学们真心愿意花时间去学习。
最后，还是希望OO越来越好的~
