论述测试与正确性论证的效果差异
单元测试利用测试者构造的测试用例来检查类或方法的正确性，一般来说所需要测试的用例是无穷多的，通过人为构造代表性的测试用例来尽量测试所有代码。测试的优点在于不易出错，只要能正确确定测试结果就行了，但是缺点在于难以考虑到所有的代表性用例，在复杂工程中，完全周密的测试是几乎不存在的，测试者不能保证没有不被考虑到的用例。
而正确性论证是逻辑论证，从代码层面出发，用自然语言来描述程序的运行正确性。优点是逻辑论证可以完全覆盖类或方法的运行过程，但是缺点是自然语言论证本身就是不能保证正确的，无法与单元测试的机器运行相媲美。
OCL与JSF的比较
OCL是对象约束语言，可以应用与任何实现方式的非正规语言。对象约束语言对UML中图形或其他组件都没有控制权，他只是在使用时返回值。OCL、并不能修改对象的状态，而是用来指示对状态的修改何时发生。而JSF更加强调对代码功能的说明，OCL是形式化语言，JSF是半形式化语言，可以使用自然语言；OCL表达式的值可以有不同的类型，JSF表达式的类型都是布尔型。共同点在于OCL和JSF都可用于描述规格的前置条件和后置条件。
UML图
整理总结
阐述四个单元模块知识点之间的关系：第一个单元应该是整个java编程的基础，初步了解面向对象编程的过程，帮助大家熟悉Java语言的使用情况。第二单元和第三单元都着重于多线程编程，先利用电梯作业体验简单的多线程编写，只限于三个电梯和楼层间信息交换，开始设计进程同步等知识，而到了第三单元将多线程复杂化为更多的出租车和地图，加大多线程编程的难度。第四单元着重于规范化代码的编写，对JSF、规格文档、正确性论证进行训练。
梳理自己所设计实现的程序：以第十四次作业为例，我完全重写了第三次作业的代码，第三次作业的类图如下：
第三次作业的数据管理非常非常混乱，共享的数据分布在各个类中都有定义，其中还AskDisposeOverride的长度达到了四百多行，可读性基本为0。而在第十四次作业中，我将共享数据集中在一个类中进行管理，每个方法的长度都控制在五十行以内，代码的规范度有了质的提升。同时重写后的方法使用了完全不同的调度方法，更加贴合多线程运行的实际情况，请求管理也使用了ArrayList，代码更加方便维护。
阐述自己对工程化开发的理解：而在企业项目中，代码的规格化尤为重要，一个项目大多都是由一个团队来完成，如果没有统一的代码规范，那么每个人的代码必定会风格迥异。且不说会存在多个人同时开发同一模块的情况，即使是分工十分明晰的，等到要整合代码的时候也有够头疼的了。大多数情况下，并非程序中有复杂的算法或是复杂的逻辑，而是去读别人的代码实在是一件痛苦的事情。统一的风格使得代码可读性大大提高了，人们看到任何一段代码都会觉得异常熟悉。显然的，规格化的代码在团队的合作开发中是非常有益而且必要的。
对课程的任何期望或建议：强烈建议对于部分测试删除互测阶段，对于JSF、规格检查，互测其实无可厚非，这些内容有些时候就是用来给别人看的，但是第一、二、三单元完全可以依靠公测进行测试，指导书统一输入方式和输出结果就行了。课程组可能对于匿名后的学生素质期望过高，乱扣bug是一个低风险的行为，除了一些明显无理由的bug外，大部分互测争端是助教难以评判的，而且工作量巨大。所以强烈建议前一二三单元使用公测进行测试，这三个单元的作业更加注重结果的正确性而非规范性。