测试与正确性论证
测试是用通过构造数据， 让程序在某种特定情况下运行， 观察程序的运行结果和预期结果比较， 来判断在这种情况下程序的正确性。 我们每次作业OO的互测， 以及第13次作业中的JUnit测试， 都是测试的例子。 测试像是把程序， 看成一个黑盒， 不关注其内部具体的实现。 测试往往需要大量的数据， 而且需要对输入划分成各种情况， 就像每次作业的错误分支树一样， 通过错误分支树构造测试数据， 能够保证测试的全面性， 更好的覆盖每一种情况， 同时也能避免一味地去构造隶属于同一情况的数据。 通过测试不通过的数据能够方便找到程序的bug， 但及时通过了所有的测试， 也不能一定说程序是正确的。
正确性论证是深入程序的每个模块， 根据代码的规格， 逐一论证每一部分的实现是满足需求的， 从而得到整个程序的实现是正确的。 第14次作业写的正确性文档就是干的这么一件事。 正确性论证是从理论上证明这个程序是正确的， 通过数理逻辑的推导， 往往需要大量的文字描述， 尤其如果程序的规模越大， 其工作量也成倍增加。 但是， 如果程序能通过正确性论证， 那么一定能够说明程序是正确的。
OCL语言与JSF
对象约束语言(Object Constraint Language)， 简称OCL， 是一种指示用户建模系统中的限制方式。 他是UML可选的附加内容， 可以用来更好地定义对象的行为， 并为任何类元指定约束。
在OCL中， 对象代表了系统的组件， 他定义了完善的项目， 约束代表限制， 而语言并非指一种正式的计算机语言。
OCL是一种形式语言， 可以应用于任何实现方式的非正规语言。 对象约束语言对UML中的图形或其他组件都没有控制权， 它只是在使用时返回值。 OCL并不能修改对象的状态， 而是用来指示状态的修改何时发生。
OCL表达式以附加在模型元素上的条件和限制来表现对该对象的约束， 其中包括附加在模型元素上的不变量或约束的表达式、 附加在操作和方法上的前置条件和后置条件等。
OCL语言虽然是一种形式化语言， 但是它既具有形式化语言无二义性的特点， 又消除了形式化语言的复杂性。 JSF和OCL的目的是相似的， JSF包括过程规格和类规格， 是对某段代码的规格化描述， 其实也就是对这一段代码的约束， JSF的组成主要是布尔表达式， 可以说JSF是轻量级的OCL。 OCL是一种纯表达式语言， 是具有没有任何副作用的声明性语言， 一种类型化语言， OCL中的每个表达式都是具有类型的。 可以说OCL的约束比JSF更精准， 无二义性， 其语言体系更加完善， 至少不能像JSF那样写自然语言了。
第十四次UML图
UML类图
UML顺序图
UML状态图
总结
- 第一单元是介绍一些面向对象思想的概述， 了解面向对象与面向过程的区别， 真正认识到什么是类什么是对象， 让我们学会了以面向对象的角度分解一个问题， 即现抽象出一个问题中的几个对象， 再考虑各个对象之间的交互。 第二单元主要涉及到了多线程编程， 这是第一次多线程， 之前的程序写的都是单线程的， 思想还是停留在一个线程顺序执行下来的阶段。 多线程给我们带来了许多便利， 能够提高程序的并发性， 同时让我们也头一次意识到了许多以前单线程没有的问题， 尤其是线程安全性方面， 如何维持线程之间的互斥与同步。 第三单元讲述设计方法与设计原则， 主要是JSF规格的编写， 通过攥写规格来更准确的约束一段代码的前后变化， 同一个规格可以有不同的实现方法， 良好的设计习惯能够避免许多潜在的编程问题。 第四单元主要是测试与正确性论证， 测试的时间往往是写代码的时间都若干倍， 如何正确的做测试就是这个单元主要教给我们的， 当然还有通过编写文档， 逻辑上论证一个程序的正确性。 四个单元呈现出一种递进的层次关系， 从单线程到多线程， 从编写程序到测试程序到论证程序， 从局部设计到整体规划， 循序渐进。
- 通过面向过程这门课， 自己写了不少的代码， 从一开始简单的多项式， 到电梯系列，中途有一个IFFT， 再到出租车系列， 再回到电梯做些测试和论证， 一路走下来也是一遍跌倒一遍爬起来。 在多项式时， 自己还只是简单的用过程化的思想写JAVA代码， 越写到后面越觉得这样吃力， 随后渐渐理解了面向对象的机制， 开始抽象出各个类， 并细化每个类的职责， 通过一次次的作业实践， 认识到怎样的设计才是更具有扩展性， 类与类的耦合度怎样才能减少。 同时在互测机制中， 通过不断地测试别人的代码， 通过错误分支树的构建， 构造各种类型的数据， 提升了自己测试的能力与水平， 也是在互测的阶段， 通过阅读别人的代码， 感受到自己与大佬之间的差距， 对于同样的需求， 为什么这么写更好等等， 从而受益匪浅。
- 工程化即系统化、模块化、规范化的一个过程。指将具有一定规模数量的单个系统或功能部件，按照一定的规范，组合成一个模块鲜明、系统性强的整体。工程化往往包含大量学科和学科分支的知识，是一个复杂的系统工程过程。 我们这门课的作业的编写可能涉及到了许多工程化开发的思想， 而实际的代码规模还谈不上工程化的水平。 不过除了代码量之外， 工程化开发重要的还是工程代码的可拓展性和可维护性， 像是作业中的出租车系列， 电梯系列， 虽说都是基于前一次作业上稍加修改， 但是在编写过程中能够很明显地感受到不同的设计方法， 带来的拓展代价的差异巨大。
- OO这门课确实说是争议比较大， 诸如指导书的不明确性， 互测机制等等。 这些方面争议太多我也不好插嘴， 我还是从一个比较小的方面来说吧， 就是OO作业的问题， OO这门课所涉及到的东西真正要全部理解通透的话绝对不止这么一个学期能够完成的， 同时在OO持续的一周一个大作业的压力下， 同学们本已是在夹缝中生存， 比起理解课堂上所教授的思想， 如何快速搞定眼前这个作业才是当务之急， 其实真正实现的代码， 一路下来听课和没听课的区别不大。 如何加强作业与课堂知识之间的联系， 同时轻量化作业规模， 让同学们在实践的同时多多加以思考， 是这门课程值得考虑的一个问题。