一、正确性论证和测试的效果差异及优缺点
1.效果差异：
正确性论证包括对对象的有效性和方法的正确性进行论证，论证过程主要从方法的逻辑出发，验证是否满足相应的不变式和方法前置、后置条件。论证过程较为冗长，但从需求角度出发，在满足规格的前提下，可以对后置的所有可能结果进行验证，从一定程度上可以保证程执行结果的正确性。测试方法相较于正确性论证更加明了具体，通过对分支的梳理和代码覆盖，利用断言检查可以检验程序的正确性。在测试过程中对于构造满足代码分支和语言的样例总体来说较为简单，但某些分支需要构造较为复杂的样例，而这样的情况由具有一定的特殊性，不能够给出严谨的正确性论证。总体来说，测试手段可以使得程序的大部分情况得到满足。
2.优缺点比较：
在进行正确性论证和代码测试的过程中，二者具有较大的差异，也各具优缺点。正确性论证优点主要在于论证过程的严谨性将形式验证和自然语言层次逻辑推理相结合，具有一定的折中性，同时也没有形式化验证构建模型的高昂成本，面对用户需求以及规格化格式化的代码实现，可以较好地满足论证需求。而正确性论证的缺点在于自然语言层面的论证缺乏严格意义的严谨性，人工的逻辑验证缺乏一定的说服力，并且该方法论证结果具有较长的篇幅，较为冗长，阅读体验较差，不够简洁明了。
测试方法主要通过对前置条件和后置条件进行划分，采取抽样数据，对代码进行测试，测试方法的的优点在于容易实施，可以广泛地被工程采用，同时测试结果也较为简洁；但测试方法的缺点也显而易见，基于抽样的测试数据不能够保证测试结果的严谨性和正确性，缺乏逻辑化的验证。
二、OCL语言调研
OCL(Object Constraint Language)，即约束性语言和查询语言，是一种用于施加在指定的模型元素上约束的语言。OCL语言由IBM设计，主要是解决约束表达的问题，具有无二义性的特点并且消除了形式化语言的复杂性。
OCL语言是一种形式语言，可以应用于任何实现方式的非正规语言。对象约束语言对UML中图形或者其他组件都没有控制权，只是在使用时返回值。OCL不能修改对象的状态，而是用来指示对对象的修改何时发生。OCL表达式以附加在模型元素上的条件和限制来表现对该对象的约束，其中包括附加在莫型元素上的不变量活跃数的表达式、附加在操作和方法上的前置条件和后置提条件等。
OCL的基础是数学中的集合论和谓词逻辑，并且它有一个形式化的数学语义，但是它并没有使用某种数学符号。因为虽然数学符号能够清晰的、无歧义的表达事物，但是只有极少的专家可以看懂。所以数学符号并不适合用于一个广泛应用的标准语言。自然语言最易懂，但是含混不清晰。OCL取了自然语言和数学符号的折中方案，使用普通的ASCII字符来表达数学中同样的概念。OCL规范还允许定义自己的OCL符号集。
用OCL可以描述四类约束，分别是不变量、前置条件、后置条件和监护条件。
1）不变量是在属性的生命期内一直保持为真的规则。
2）前置条件是在一个操作被调用时必须为真的约束。它是一个断言，不是可执行语句。
3）后置条件就是在操作完成时必须为真的约束。它不是可执行语句而是断言，必须为真。
4）监护规则是在对象能够从一种状态转变为另一种状态前其值必须为真的约束。
OCL语言和JSF语言的比较：
| 相似 | 1.采用“形式化”语言，没有使用严格的数学符号，无自然语言的模糊性，表达清晰易懂 |
|
| 2.以集合论和谓词逻辑为基础 |
|
| 3.“声明式”语言，不提及完成的算法和具体过程，只声明期望的结果 |
|
| 4.具有前置条件和后置条件的约束 |
|
| 5.不是程序语言，不可编辑程序控制逻辑 |
| 不同 | 1.OCL语言需要赋予一个明确的上下文来定义参考基准，上下文包括类，属性，操作和关联 |
|
| 2.OCL具有不变量 |
|
| 3.OCL后置条件不是可执行语句，是断言；JSF后置条件为一布尔表达式 |
三、时序图、类图、状态图
1.类图
2.时序图
3.状态图
四、学期总结
1.四个单元模块知识点之间的联系
2.梳理自己实现的程序以及自我进步
| 实现程序 | 设计 | 测试 | |
| 模块1 | 多项式相加 | 基本体现面向对象思想，部分细节过于复杂 | 根据测试树构造测试样例，但为考虑到正则表达式爆栈 |
| 傻瓜电梯 | 可以体现面向对象思想，算法思路较为简洁清晰，细节部分仍然冗余 | 根据测试树构造测试样例，基本完善 | |
| 可捎带电梯 | 思路清晰，但有代码重复现象，部分类设计责任分配不均 | 根据测试树构造测试样例，基本完善 | |
| 模块2 | 多线程电梯 | 线程安全设计存有缺陷 | 缺少测试时间，只进行基本功能测试，不够完善 |
| IFTTT | 线程安全可以基本保证，设计比较满意 | 测试基本功能，较为完善 | |
| 出租车调度系统 | 思路清晰，代码流畅，但有代码重复现象 | 测试基本功能，基本完善，但忽略十分隐蔽的细节，针对于代码实现 | |
| 模块3 | JSF&流量&开关道路 | JSF书写缺乏细节完善 | 检查不够仔细 |
| repOK&红绿灯 | 设计基本满意 | 注重细节，尝试构造特殊情况，利用测试文件，测试完善 | |
| 可追踪出租车&继承机制 | 设计基本满意 | 关注与细节和特殊情况的构造 | |
| 模块4 | Junit测试 | 设计基本满意 | 测试完善，但忽略JSF细节 |
| 正确性论证 | 部分类分配责任不够均衡，一些方法过长，承担太多功能，某些正确性论证实现有一定难度 | /
| |
3.工程化开发的理解
通过一学期的OO学习，对于工程化的理解也还只是大致的体察，并不能够完全和深入地认识工程化开发，但是从自己的角度来说，工程化开发强调用户需求，规格设计和代码维护，一定程度上需要开发人员之间的沟通，以及完善的开发流程。
4.课程建议和期望
一学期的OO课总体来说收获还是非常丰富的，从一开始面对这门课程的艰难到每一次的坚持和努力，一路走来对自己在这门课程的表现也足够满意。课程已经结束，也期望OO可以在未来成为更加成熟的一门课程，使学习者从中有更多收获。