一、测试与正确性论证

　　测试是通过构造测试用例，对程序中各个方法，对象进行测试，并且根据覆盖率可以直观的了解测试用例是否覆盖了程序所有可能的情况。测试构建的测试用例没有严格的标准，是编程者根据需求以及自己认为程序可能遇到的各种情况来构建的。测试用例的数量可以很多，一般情况下可以覆盖到绝大多数通常情况。

　　正确性论证是以每个对象、方法的规格为标准，用严格的数学逻辑思维对程序的正确性进行论证。可以保证程序与规格的对应。但是当方法、对象比较复杂时论证十分困难且不一定能够都得出完全正确的结论，而且对于规格设计上存在的问题无法发现。

　　两种方法各有优缺点。测试较为直观，设计用例比正确性论证方便快捷，能够发现程序是否符合要求。但是构造的测试用例无法保证覆盖了使用过程中可能出现的所有情况。正确性论证可以保证程序与规格的对应，但是论证过程费时费力，而且对于程序设计本身存在的问题无法察觉，在论证过程中也可能出现错误，得出错误的结论。

　　两种方法应当相互结合，扬长避短，才能发挥最好的效果。例如，对于系统中各个细小部分应当使用正确性论证确保其实现正确，对于综合性较强，处于结构上层的，比较复杂的对象或方法，难以严格进行正确性论证时，应当尽可能构建完备的测试用例，使用测试确保系统的功能满足要求。

二、OCL与JSF

　　OCL全称为 Object Constraint Language，意为对象约束语言，是一种用于进行约束定义的，形式化的无二义性的语言。OCL于1995年在IBM设计成功并开始使用。1997年UML的1.1版本正式采用了OCL。2003年1月推出了OCL1.4版本。

　　OCL的原则主要有以下几点：

　　　　1、声明性语言，不改变模型内容；

　　　　2、形式化语言；

　　　　3、无二义规范语言；

　　　　4、类型性语言，每一个表达式都有类型；

　　　　5、易学好用。

　　OCL语言主要包括类型、操作、表达式、语句。

　　OCL与JSF均是形式化的约束语言，没有二义性。但OCL的规范范围应当比JSF更大，JSF重在约束方法，而OCL的约束范围是对象甚至系统。

三、单电梯系统总结

　　1、类图

　　

　　2、时序图

　　

　　3、状态图

　　

　四、学期总结

　　这一学期的OO课上内容有四个部分，分别是Java与对象、并发与安全、抽象与规格、测试与论证。第一部分中，我接触了Java语言，了解了什么是对象，什么是面向对象编程。第二部分中，我学习了Java中非常重要的多线程机制，学习了思考与解决多线程同步问题，以及如何使用多线程更高效的解决问题。第三部分中，我了解了数据抽象以及规格化设计，向更规范的编程，更好的设计前进。第四部分中，我了解了如何测试程序，如何保证程序正确性。总体来说，是一个循序渐进的过程。从会写程序，到能完成任务，到更高效的完成任务，再到更规范、更正确的完成任务。一步一个脚印，向更好的程序设计前进着。

　　这一学期的收获无疑是巨大的。首先，我的编程水平有了极大的提高。能够解决较为复杂的问题。除此之外，我了解了面向对象编程的思想，并且将这种思想作为一种变成习惯，在今后的学习生活中延续下去。我也了解了程序的测试方法，如何规范正确地设计程序等等。回看第一次OO作业的代码，内心不由生出一种成就感，我已经成长了太多。面对困难的任务，不仅能够完成，而且能够做到规范，高效的完成，并且易于理解，易于与他人合作完成。

　　我目前尚没有接触完全意义上的工程化开发，仅仅是谈一谈自己想象中的样子。工程化开发需要注重产品的质量，满足要求，同时也要兼顾成本，包括时间成本，金钱成本，人力成本等等。这就要求合作开发的人员共同遵循一套设计规则，编程规则，才能合作产出合格的产品。普通大众使用的产品有时并不要求完全意义上的正确。在通常情况下，或者说出错的几率低于一定水平就可以视为合格，所以在解决错误与执行成本上需要作出权衡，以确保最大的收益。

　　一学期下来，可以感觉到大家对这门课程怨念颇深。但抱怨是没有用的，如何使这门课程变得更好才是大家应该思考的问题。我在这里提出一些建议，希望能够给课程组带来一点灵感，将OO越办越好。大家诟病最大的就是互测机制，以及扣分加分基础上的天梯排名机制。发现BUG加分，被发现BUG扣分，这一点天经地义无可厚非。但是实际情况是，作业指导书仅仅给出了大纲式的宽泛要求。在程序具体实现时有许许多多细枝末节的问题是没有而且也无法完全包含的。虽然原则上“可以readme”，但是仍然有很多情况readme中说明了，但助教认为这不属于readme的范围。如何划分什么可以自定义，什么不可以自定义？这一条线我认为是无法完全划清的。JSF那几次作业中，恶意扣分的情况更是屡见不鲜。吹毛求疵就可以拿到很高分数，放宽心态就可能被狠宰一刀。这已经涉及到了公平问题。为了改善这一情况，我认为可以从两方面入手。首先，提高公测分数占比，降低互测分数占比。如果一位同学的程序能够通过公测，那么应当可以认为其已经实现了指导书中规定的功能，就应当获得绝大部分分数，作为此次作业完成的肯定。互测分数降低，可以避免出现恶意扣分的情况，也减轻同学的心理压力。第二是增加恶意互测惩罚机制。当前的规则中，如果报BUG一方被申诉成功，仅仅是这2分无法拿到，没有其他负面影响。我认为可以引入惩罚机制。汇报的BUG，如果另一方申诉成功驳回，那么对报BUG的一方扣一定的分数。这样可以使每位同学对自己的报BUG行为更加慎重，降低可能出现的恶意行为。

　　希望这些建议能够给课程组一些启发，将OO课越办越好！