一、测试与正确性论证
从第一次作业开始，我们就与测试结下了不解之缘，不管是在自己完成作业的过程中使用各种测试集去覆盖自己的代码，还是在互测的过程中使用一些刁钻的测试数据进行针对性测试。测试最核心的部分就是构造好的测试集，通常大家都会根据指导书和讨论区的一些要求进行构造，但是总还是有自己没想到的部分，再或者就使用随机测试数据，和别人的代码进行对拍，以达到尽可能全覆盖的效果。这样的方法贯穿了整个OO之旅，不过事实上，在多线程或一些稍显复杂的问题上就已经体现出其缺点了，由于多线程的不稳定性，测试的过程很麻烦，要进行很多次尝试才能找到问题。对于我来说，测试实际上就是穷举所有的情况，并没有一套完整合理的框架，很难保证程序的正确性。
最后一次作业进行了正确性论证，即通过分析需求，代码规格，以论证程序的实现符合要求。通过代码走查的方式，确保每一句的执行不会违反相关要求，并且实现了功能，从理论上保证正确。这样的方法对于工程是很有必要的，否则就会出现千里之堤溃于蚁穴的情况。不过我们的作业由于是先进行代码实现再撰写规格，有点本末倒置，所以正确性论证的过程就比较艰难，还需要进行改进。
个人认为，测试和正确性论证都是必要的，毕竟要仰望星空与脚踏实地，完备的测试加上正确性论证才能保证整个系统的运行不会出错。
二、OCL语言与JSF规格
OCL是约束（Constraint）语言和查询（Query）语言，起源于1997年BIM公司为响应OMG的"面向对象分析和设计标准"征求稿所提交的"对象时间限制提议"，OCL是该提议的部分内容。 用OCL可以描述四类约束，分别是不变量、前置条件、后置条件和监护条件。
1）不变量是在属性的生命期内一直保持为真的规则。
2）前置条件是在一个操作被调用时必须为真的约束。它是一个断言，不是可执行语句。
3）后置条件就是在操作完成时必须为真的约束。它不是可执行语句而是断言，必须为真。
4）监护规则是在对象能够从一种状态转变为另一种状态前其值必须为真的约束。
OCL与JSF的相似之处在于他们都是形式化的约束语言，都是一种形式化的语言，具有无二义性，每个变量都有类型，不会改变系统的运行状态，都采用前置条件和后置条件对方法的运行加以约束。
不同之处在于OCL是在进行理论建模时对类进行约束，基于类图等，而JSF是针对代码实现时的具体约束，以确保程序的实现正确，而且，OCL每个方法有自己的一套体系，JSF是支持Java和用户自定义的一些类型的。
三、单电梯系统模型
四、学期总结
1.单元模块知识点
第一单元主要是在进行Java基础知识的学习，让我们从面向过程的设计向面向对象的设计而转变，为后续工作打下基础。
第二单元从多线程电梯开始，进行多线程编程，这部分着重训练了多线程的安全设计以及一些经典设计模式。
第三单元引入了规格化设计，不断增加程序功能，同时通过JSF对代码做出规范，以提升代码质量和代码的完备性。
第四单元对程序进行测试验证，包括自动化测试以及正确性论证，确保程序执行的正确性。
2.程序梳理
经过这么多次作业的洗礼，自己还是进步了许多的。从最开始的什么都不懂，所有东西都放在一个类里面，到慢慢地学会通过功能、性质等对类进行合理的划分，在面向对象编程方面渐渐走上了正轨。同时，对于代码的测试也不再无从下手，可以通过代码逻辑，功能要求方面构造合理的测试，尽量条理清晰，全方位的对代码进行覆盖。
3.工程化开发理解
走向工程化开发是我们的必经之路，通过合理的团队分工协作，开发出各方面都具有良好性能的程序。好的工程化开发可以节省开发人员测试人员的重复劳动，减少返工。我们的作业远远算不上工程，但已经可以显现出不同的开发者对于同一个问题的解决方案是哈姆雷特式的，设计上的好坏直接决定了程序在后续增添功能以及维护上的难易程度。
4.课程期望及建议
在整个课程中被提到最多的两个关键词，一个是指导书，一个是互测。
关于指导书，老师有说过真正工作中的指导书绝不会像课程指导书这么详细，很多都需要自己去理解揣摩，这点我是赞同的。但问题在于作业是要进行互测的，需要有统一的硬性标准，很多模糊不清的地方都可能会演变成莫名其妙扣分的点，所以大家对于指导书中的每一句话才会不断的研究，因此还是希望指导书可以不断完善，减少助教的部分答疑工作。
关于互测，可以说是让我们提前了解了一下社会现状？一开始还好，扣分都不是那么凶，自从有了规格之后，互测就变了味，成了JSF大战，比的是心狠手辣，这是让人对着门课程最失望的地方。不过我也没想出这门课程的其他测试方式，既然这样，就希望对互测提高一些约束，减少一些不必要的争端吧。
最后，还是要感谢老师和助教团队一学期对我们的帮助，希望课程变得更好，有口皆碑是不可能的，但，至少别让这门课被喷的太惨。