oo第四测博客
1. 测试与正确性论证
测试相较于正确性论证，更加快速，便利，易于使用。在不知晓代码全部设计结构时也能够使用，可以针对于程序进行黑盒测试，特可以针对方法进行部分黑盒测试。采用自动化测试同样也可以达到较好的覆盖率，验证程序是否正确。但是无论进行怎样的测试，测试一直是一个试图证伪的过程，永远不是完备的，尤其对于一个较为复杂的程序来说，进行完测试后的绝大多是情况为，没有发现bug，而不是没有bug。
而正确性论证更像是一种推演，根据需求来检查是否代码能否实现功能。要求撰写者对自己正在处理的代码有着充分的理解，基本上只有开发者自身能够做到这一点。但是带来的好处是，能够非常完备的对方法的实现进行验证，对于方法的边界条件等一些测试样例不方便构造的极端情况进行验证。在进行完正确性论证后，理论上每一个方法都将是完备的，在JSF约束符合程序实现的要求时，整个程序的正确性将是完备的。但是在实际操作中，这种正确性论证的合理与否，或者论证过程是否符合逻辑，取决于撰写者的能力，可能存在即使代码中有问题，在论证过程中仍然无法发现这种逻辑错误，导致论证与代码实现有一定出入，仍有bug存在。此外，撰写和验证撰写是否正确的工作异常的费时费力，对于规模较大的代码将变得难以采用。
2. OCL语言
OCL起源于1997年BIM公司为响应OMG的"面向对象分析和设计标准"征求稿所提交的"对象时间限制提议"，OCL是该提议的部分内容。 用OCL可以描述四类约束，分别是不变量、前置条件、后置条件和监护条件。
1）不变量是在属性的生命期内一直保持为真的规则。
2）前置条件是在一个操作被调用时必须为真的约束。它是一个断言，不是可执行语句。
3）后置条件就是在操作完成时必须为真的约束。它不是可执行语句而是断言，必须为真。
4）监护规则是在对象能够从一种状态转变为另一种状态前其值必须为真的约束。
OCL与JSF的相似之处在于他们都是形式化的约束语言，都是一种形式化的语言，具有无二义性，每个变量都有类型，不会改变系统的运行状态，都采用前置条件和后置条件对方法的运行加以约束。
不同是JSF是通过逻辑布尔表达式将规格分成前置条件、副作用、后置条件来表示，而OCL取了自然语言和数学符号的折中方案，包含了基本数据类型以及其他高级结构。
3. UML图
4. 学期总结
本学期的四个模块循序渐进，逐级向我们介绍工程化开发的方法和技巧。
第一个模块的主要目的在于介绍面向对象的基本思想，将编程方法逐渐由C语言面向过程的编程方式，向java的面向对象的转化，经过三次代码的训练，逐渐熟悉并掌握java和面向对象思想。在具备了一定的面向对象编程能力后，第二个模块引入了多线程这一在程序开发中必不可少的方法，并强调了线程安全的问题。进一步加强对于编程能力的训练。第三个模块是多线程应用的加强以及JSF的引入，强调规范化的编程方法。第四个模块在规范化的编程之上，对于实现的正确性进行提升，介绍了测试和正确性论证的方法。
经过一个学期的学习后，最大的感受就是对于java的理解更加深刻，应用更加灵活，掌握了更好的抽象程序的方法，可以有效地将程序进行合理的划分，并以独立的类分别实现。在实现过程中，有效的缩减了代码的规模，有效地控制了方法的复杂程度。在进行正确性论证的书写时，为了方便论证，重构了第三次作业的代码，与其说是重构，不如说是重写，在这个过程中明显感觉到实现正确代码的速度增快了，删除了一个多余的类，并且至少将每一个重写类的代码规模减小了一半。并且debug的时间也大大减少，用了一个下午就完成了整个程序的调试。虽然对第三次作业的逻辑不用进行重新思考在加速实现代码上提供了一定帮助，但是重写完后将两次代码作对比，那种简洁和畅快的感觉令我非常难忘。
对于工程化开发，我认为实际上更强调协作和规范。个人能力再突出也不可能独自完成对于一个大型工程的驾驭，所有开发者的代码需要组合使用，因此如何写出能与他人匹配的代码才是工程化开发的核心。只有当既有能力实现又能符合规范时，才能成为一个高效的工程化开发人员。
对于oo这门课程，首先感谢尽职尽责的助教们，感谢他们在百忙之中抽出时间为我们答疑解惑，明确了许多模棱两可的地方。在本课程中一个难以规避的bug，也是这门课熬人的核心所在，就是需求和实现的差距。在这门课的设计中，我隐约记得，对于指导书的需求，我们作为开发者，应当自行理解，并为了功能上的正确自行设计。即客户说的不一定准，但是如何做到让客户满意，并采用一定的方法让客户满意是每个人可以自行设计的事情。在不违背指导书原则的基础之上可以自行设计，有种戴着脚镣跳舞的感觉。这么做实际上非常正确，但是在实现中出现了一点小小的问题。既然是自行设计，那么所有的模棱两可的点实际上都是见仁见智。在这种互测的机制之下，这种见仁见智就变成了对战的开始。这究竟是一个feature还是一个bug谁也说不清，因此为了避免这种情景，就出现了大量的issue和助教咨询，在得到答复后这种可以自行设计的点就变成了需求。这脚镣越来越紧，能够发挥的地方越来越少，还附带着有些实现完的地方因为一个issue的出现而重写的情况，过得惶惶不可终日。
