测试与正确性论证
Dijkstra说过:“程序测试只能证明程序有错,不能证明程序正确。”所谓程序测试,实际上是测试者特意挑出一批检查数据,通过运行程序,检查每个输入数据所对应的运行结果是否符合预期要求。正确性证明是论证程序达到预期目的的一般性陈述,该论证不与程序输入的特定值有关,但能够代表穷举性测试。
测试相比于正确性论证来说,实际像是将程序看作一个黑盒,并不关注程序内部的实现。测试不仅能快速地发现程序的bug,也能测试程序的效率,复杂度等属性。但是缺点在于需要大量的数据,想要做到全覆盖测试并不容易,甚至在很多情况下根本无法实现。
而正确性论证则不一样,如果说测试是从实践方面来检测程序的正确性,那么正确性论证则是从理论上来证明程序的正确性。正确性论证在理论上来说可以覆盖整个程序,从而证明整个程序的正确性。比起测试来说,由于是从理论上来证明程序的正确性,因此所需要的资源相对较少。但是其缺点也比较明显,首先,正确性论证是从实现的角度去论证程序的正确性,只能证明程序实现的正确与否,如果程序一开始的设计就是错的,那么正确性论证不能发现这个问题。其次,当一个方法的实现过于复杂时(比如一个方法的代码超过了50行),正确性论证难以进行。
OCL与JSF
对象约束语言(简称OCL)是一种指示用户建模系统中的限制方式。UML图通常不够精细,无法提供与规范有关的所有相关部分。这其中就缺少描述模型中关于对象的附加约束。OCL便是为了解决这类问题应运而生的形式语言。
与JSF相比,虽然两者都是一种约束语言,但OSL语言是一种无二义性规范语言,并且每一个表达式都有自己的类型。JSF的主要服务对象是方法,而OSL的主要服务对象是每一个类。
第十四次作业
学期总结
不知不觉间已经度过了一个学期的漫长而痛苦的OO旅途。虽说痛苦,但是收获满满。
第一个单元,我们的主要目标是形成面向对象编程的思想。以前所学过的编程语言C语言是典型的面向过程的编程语言,而新接触的Java语言则是一款面向对象的编程语言,这一单元主要是让我们熟悉面向对象的编程思想,并且以典型的电梯程序来辅助练习。这一过程中,主要的问题是对Java语言的不熟悉,难以理解面向对象的编程思想。
第二个单元是针对多线程编程的训练。用一句通俗的话说,这一个单元是最折磨人的。首先在于我们对线程丝毫没有概念,也不懂得并发等术语的含义,因此在多线程编程中处处碰壁。其次,线程安全也是一个让我非常头疼的问题。在这一个单元中,主要出现的问题是如何设计,比如在出租车系列作业中,究竟是一个线程管理一百个出租车还是一百个线程管理一百个出租车方便实现?如何去保证出租车运行过程中线程始终安全?这些问题是当时一直困扰着我的。
第三个单元着重于规格化的设计。这一个单元的主要目的是让我们意识到规格的重要性。尽管JSF一直在被吐槽,尽管大家对测试时测试者对JSF的扣分十分厌恶,但是,这一个过程确确实实让我们了解了规格的重要性。规格不仅仅方便了程序的使用,它还能够让其他人更容易弄懂你的程序,这对于开发者来说十分重要。
第四个单元的重要任务便是测试和正确性论证了。到了这个单元,大家都已经能够理解面向对象的编程思想,也能写出相应的代码。但是如何保证自己写的代码是正确的呢?这一单元针对代码的测试和正确性论证帮我们解决了这个问题。也让我们能够写出完善健全的代码。
回看自己写过的历次作业,我发现自己的提高还是很明显的。最初的我写的代码,完全是面条式的,如今的代码,具有了相当程度的可移植性。针对测试,已经学会了将输入输出划分,以形成分类树来对程序进行测试。
至于工程化开发,我的理解是首先开发者在设计方面要遵循一定的原则,其次要写出可移植性高,可修改性强的代码,便于修改和完善。再次对每个类每个方法的实现要规格化,方便测试。最后的测试阶段中,要尽量按照测试的分类树进行测试,尽量实现全覆盖的测试。
我们经常说的一句话是OO不易,和谐6系。其实我觉得这和课程组有很大的关系。很大的原因是互相测试导致的。有一句网络语是这么说的:“我就这样了,有本事你顺着网线来打我啊?”的确,匿名的互相测试确实让某些同学过于“为所欲为”,周五测试结果出来之后,看到被报的BUG又要与测试者争论许久,最终还得靠课程组的仲裁。既破坏了同学间的关系又加大了同学和课程组的压力。
我认为一个很好的解决方法是加大公测力度,减少互测在分数中所占的比例。实话说,互测有很强的主观性,公测才是真正公平的。但很多次作业公测,弱的惊人,把分数完全交给测试者,难怪同学们都说这是面向运气编程。
虽然怨言不少,但始终还是希望OO课程能越来越好吧,也希望这门课能成为北航计院的特色课程(虽然已经是特色课程了)。