一、测试与正确性论证
测试是给程序一组或几组初始值，进行试运行，将运行的结果与实现已知的结果比较，如果两者相同，则认为程序是正确的，否则，则说明程序有错误。在实际操作中，可以根据输入条件进行划分，进而对不同的划分构造多种多样的测试样例。一般而言，采用测试的方法可以发现程序中存在的错误，但却不能证明程序中没有错误，除非进行穷举测试，但在实际中是无法知晓是否做到了全面测试。程序测试实质上只是一种抽样检查，测试只是一种查错的手段，他可以帮助人们去发现程序中的错误，但不能证明程序中没有错误。即：测试不能证明程序是正确的。其优点是可以有针对性的构造测试样例，从而直观的理解程序行为的正确性，但其缺点也是显而易见的，测试无法证明程序是正确的。
正确性论证是论证程序达到预期目的的一般性陈述，通过数学技术来确定程序是否正确，而该论证与程序输入数据的特定值无关，能代表穷举性测试。不同于程序测试通过构造测试样例来发现程序是否存在错误，正确性论证从逻辑上证明程序符合规格说明，即对于每一个满足前置条件的行为，后置条件中都有相应的结果或影响。通过这种数学逻辑上的推理证明，最终证明程序行为的正确性。其优点是一旦从逻辑上证明程序行为的正确性，这种正确性不受主观性的影响，那么基本可以说该程序是正确的，缺点则是证明过程繁琐复杂，需要较强的逻辑推理能力。
二、OCL与JSF
OCL (object constraint language)是一种对象约束语言，作为图形符号的补充，说明建模元素的有关细节，比如，前置条件、后置条件，是一种形式化的无二义性的语言。
同JSF相似的是，OCL是一种声明式语言，表达式仅仅描述了应该去做什么，而不是应该怎样去做，从而不必理解实现的细节和实现的语言。OCL同样可以描述四类约束，分别是不变量、前置条件、后置条件和监护条件，这里监护条件相当于JSF中的副作用。因为OCL是一种约束语言，所以可以表达比JSF更强的作用，比如对UML图进行约束等等，而JSF仅仅被用来描述java语言开发规范。
三、模型表示
- UML类图
2. 时序图
3. 状态图
四、学期所学所练
本学期共进行了15次训练，分为四个单元模块，这些训练模块如下：
- 对象与对象化编程
- java对象运行与多线程
- 过程抽象与数据抽象
- 规格设计与基于规格的正确性论证
这些模块的设计层层递进，在理解和掌握上一个模块的基础下，进行本模块的开发理解，从而最终形成一个比较完整的知识体系。从最基础的面向对象编程的编程实例，讲授面向对象的思想，体会与面向过程的异同，接着理解java对象运行机制，从底层掌握其设计思想，并开始多线程的学习，理解与单线程的异同，然后，进一步从较高层面理解过程与数据，最后，给出了工程化开发的一些方法，体会工程化开发的思想。
1. 在设计、测试和质量上的进步
在开始课程之前，除了接触pyhon的一些关于面向对象的知识，对于java面向对象的机制几乎是空白，更不用提设计出一个完善的解决方案了。经过层次的、递进的学习，现在面对一个问题时，不再像之前那样直接拿过来开始编程，而是开始思考整体框架，模块功能的分配与配合，然后接着实现具体的代码，这种设计方式效率大大提升，并且过程中的BUG也相比之前大大减少。关于黑盒测试和白盒测试，之前并没有什么数据选择标准，一般是随机选择几组数据，这样的测试并没有进行充分测试，现在呢则会对输入进行划分，针对每个划分构造合理的输入数据，这样的测试相对较为全面，基本做到了覆盖性测试。经历过一学期的OO课程学习，在这个过程中，虽然有过痛苦，有过不快，但不可否认的是代码能力还是提升了很多，尤其是在规格化设计这方面，之前并不怎么关注代码的可读性以及可维护性，追求的是速度以及最终结果，可是这样的代码带来的影响便是，经过一段时间之后重新阅读代码，并不能很快掌握代码逻辑与结构，需要花费不少时间来理解。基于规格的设计，因为提供了方法的功能实现，即使不知道代码的实现，也可以知晓方法的功能以及使用。
2. 对工程化开发的理解
因为之前没有工程化开发的经验，仅以现有的水平对工程化开发做出理解。不同于个人编程，对于个人编程，可以不遵守某些规范，只要本人能理解就可以了。但是对于一个需要团队合作的工程化开发，涉及到的不仅仅是功能实现，还需要后续维护与继续开发。那就需要各开发人员遵守共同的规格标准，便于快速理解掌握代码逻辑与功能。
3. 对课程的任何期望或建议
经历过OO这门课，虽然编程能力有了提升，代码风格更加规范，但不得不说，OO之旅的体验并没有那么美好。每次作业的随机分配完全看运气，遇到脾气暴躁的测试者，一副“BUG挂满树，你能拿我怎么样”的姿态，尤其是进入规格化设计，只要测试者存心寻找设计不完善，是总能找到的，比如，拼写错误，双等号为赋值号等。当然，如果代码设计的完善，设计者任凭测试者怎么测试也不用担心，可是在一周一作业的轰炸下，再加上大部分同学是不可能把所有精力投入到OO这门课中的，就会导致在某些小的细节实现方面不尽完善，在花费大部分精力编程完成后，还要面对分支数上那些可有可无、完全凭主观认定的BUG，难免会心生怨气，进而甚至产生厌烦的情绪，因为投入与产出的严重不对等。
关于双盲测试，怎么说呢，既有好处又有不好的地方。虽然双盲测试可以督促大家认真测试，可这也会催生为了扣分而扣分的恶意扣分现象，我的建议是降低双盲测试的程度，互测阶段仍然采用双盲测试，但测试结果可以实时在线查看，也就是说，当对方挂了己方一个BUG后，己方可以在线看到，但并不知道对方的身份。其实在这门课一开始采用的便是这种制度，感觉测试的氛围还是挺和谐的，只不过后来课程组关闭在线查看后，每个人完全不知道自己的被扣情况，于是便按照最坏情况甚至恶意寻找设计者实现的缺陷。
我们也知道，在教学组的角度看来，理想的情况是每次作业同学们尽心尽力测试，尽量呈现出公平公正的测试环境，也许，采取的双盲测试实现了这种设想，甚至有过之无不及。但是，站在我们同学的角度来看，大部分人还是希望在获得能力的同时，OO之旅也能稍显轻松，毕竟大家的压力还是挺大的。希望课程组考虑一下。