OO第四次作业总结

OO第四次作业总结

一、测试与正确性论证

• 当我们在进行一个项目时，我们有两种方式来验证自己的项目是否符合自己的预期。他们分别是测试与正确性论证。在我们进行对比分析之前，我们先来了解一下他们各自都是什么。

（一）测试

• 在编写软件的过程中，测试永远是一股强大的而且并不神秘的力量。很多大牛都曾经分享过自己的测试历程。测试二字，说简单也简单，就是编写测试用例，比较代码运行结果与预期结果。说难也难，因为随着工程项目的增大，想要进行完整的覆盖性测试是有难度滴。覆盖性测试会需要十分庞大的测试样例，往往需要十分精巧的设计测试样例或者采取其他的方式进行妥善解决。

• 为什么我们要进行测试呢？测试的目的只有一个，那就是让我们的代码更加出色。展开来说的话，大致可以分为以下两点。【1】如果你的代码连进行测试都十分困难的话，那么你的代码必然是不好的。【2】在进行设计并实现项目的时候，我们不是每次都可以一次性对问题的方方面面想的十分透彻。总会有些特殊情况我们未必会考虑到。当我们在测试的时候，我们可以对边界情况进行特殊值测试与压力测试，观察我们的代码是否符合预期。如果不符合，那么恭喜我们，我们发现程序的bug了。这是好事。

（二）正确性论证

• 正确性论证与程序正确性理论相类似。据百度百科，程序正确性理论有两种途径，其一为程序验证，研究如何使用数学推理来严格论证程序是否符合要求，其二为程序综合，研究由给定目标出发，如何一步步正确地构造出正确无误的可运行的程序。我们OO课程所学习的正确性验证即与程序验证相类似。具体到OO课程的正确性论证概念，其应该是如下所示：

正确性论证是从程序的规格出发，基于规格对代码进行逻辑上的论证，从而确认某一类或某个方法是否正确。
——OO课程同学计庭瑜

（三）效果差异

• 【二者共性特点】在对两者的区别进行比较时，首先说明二者的共性特点，那就是代码的——单元编写。以功能单元为单位编写代码，不论对测试还是对正确性论证，都具有极其重要的意义。良好的编写习惯，可以让代码的测试与正确性论证更具有针对性和有效性。不高的代码质量，对于测试或者正确性论证而言，都将面临较大的阻力。

• 【测试的优点&缺点】测试操作简单，易于尝试。我们编写测试样例，将运行结果与预期结果相对比，便可判断代码编写是否正确。如果不正确则再从代码中寻找bug。当工程项目庞大时，进行整体的功能测试难以生成覆盖所有代码的测试样例。因而往往采用单元测试的方法。

• 【正确性论证的优缺点】正确性论证通过明确单元的前置条件与后置条件，再对代码的实现过程进行理论分析，判断代码是否正确。这种方法在理论上十分有效，因为可以很轻易地遍历所有可能的情况。然而问题在于如果我们采用手动分析，仍然无法避免思维盲区的存在；如果我们写出逻辑表达式自动分析，可能在编写的时候出现更多的错误降低效率。

• 【小结】通过上述分析，我们不难发现，测试易于操作但周期较长，正确性论证周期短但是可信度存在问题。因而在代码编写过程中，将两种方法结合起来是一个可以考虑的尝试。首先通过正确性论证寻找错误，发现错误并解决之后，采用测试提高代码正确的可信度。

二、OCL语言与JSF语言

（一）OCL语言

OCL语言是一种对象约束语言，他是一种施加在指定模型元素上的语言。OCL表达式以附加在模型元素上的条件和限制来表现对该对象的约束，其中包括附加在模型元素上的不变式和约束的表达式，附加在操作和方法上的前置条件和后置条件等。对象约束语言是一种形式化的语言，与UML捆绑使用，主要用于表示UML模型中施加于模型上的约束。
——UML-OCL对象约束语言，百度文库

【OCL语言的特点】
①OCL是一种精确的、无二义性的语言，易于使用和掌握。
②OCL是一种规范说明性语言，所有有关实现的问题均不能用OCL来表达。
③OCL是一种纯表达式的语言，他是具有没有任何副作用的声明性语言。对OCL表达式的计算将返回一个值，计算不会改变系统的状态。
④OCL是一种类型化语言，即OCL的每个表达式都是具有类型的。
⑤OCL不是一种程序设计语言，不能用OCL编写程序逻辑和控制流程。
——UML-OCL对象约束语言，百度文库

• 【OCL语言与JSF语言对比】从描述对象上对比，二者有明显不同。OCL语言重在对象，描述对象内、对象间的数据项。而JSF则着眼于类与方法，描述类与方法的前置条件后置条件。由上述OCL语言的特点我们不难发现，相较于JSF，OCL语言具有更为出色的表达能力。然而，当语言功能强大时，与之而来便会有重量化的问题。相比之下，JSF就显得更为轻捷方便一些。

三、单电梯系统的设计表示

类图

顺序图

状态图

四、学期总结

• 【各单元的关系】在本学期的课程学习上，我们学习了如下四个单元模块：一、Java与对象，二、多线程入门，三、抽象与规格，四、测试与验证。各个模块间呈现出一种层次递进的关系。第一部分我们进行了Java语法与类与对象的编写的初步尝试；第二部分我们在单一线程的基础上进行了扩展，尝试了多个线程之间的协同合作；第三部分我们在编写代码的基础上，通过对规格的约束，尝试提高代码的质量与正确性；第四部分我们学习了Junit自动测试方法，并对ALS电梯进行了自动化测试。从教学来看，各个单元的知识呈现出明显的层次性与相关性，梯度上升的难度使得学生可以更加平稳地完成学习过程。

• 【各次程序分析】本学期的共有代码作业9次。第一次是多项式的计算，然后进行了傻瓜式电梯、ALS电梯的编写。之后，在学习多线程的基础上，我们完成了多线程电梯，IFTTT文件系统与四次出租车问题。
  在问题的设计上，我印象中很清楚，第一次多项式作业在完成时大脑中一片浆糊。对于这个问题左理右理都理不清，越想与烦躁。花了大量的时间才勉强完成设计的构思。这就是不懂如何拆分问题，将大的问题细分为小问题的典型症状。在接下来的作业中，我的设计能力逐步增强。我能清楚地感觉到，在设计阶段，我可以更加明确的认识所研究的问题对象与数据间的关系，我所实现的各个对象的功能等。我的问题分析与设计能力不断变强。
  在测试阶段，我必须承认，在多次作业的完成上，我的这项能力并未得到有效提高。原因也很简单，作为一个DDL战士，我总是在作业即将截止时才完成自己的项目。往往出现的情况是，我的代码没有测试或者只是进行了简单的测试，抑或是采用同学构造好的测试样例测试结果。自己分析问题构造测试样例的能力并未增强很多。
  至于代码质量，我也能感受到自己的明显进步。完成项目时，我的类与方法变多了，每个方法的代码长度变短了。整个项目的结构更加清晰明了，更具有逻辑性。同时由于OS课程的辅助，在编写代码时，采用宏定义的方式来规定静态常数，不仅代码的可读性更强，而且也更加易于调试。

• 【工程化的理解】编写代码就像工厂生产一样。过去的人们总是通过小作坊的方式进行生产，生产自由度高，但是产能较低。现在人们往往采用流水线等工业化生产模式，生产速度大大提高。代码的发展也具有异曲同工之妙。过去人们可以按照自己的喜好实现自己的风格。但是这样随之而来的问题是，当多人协同合作完成同一个项目时，各部分代码之间耦合度低，可能会出现各种各样的问题。模块化与规格化的设计与实现便应运而生。大家都按照一种规范来完成代码的实现可以提高不同代码的耦合度，进而提高代码的质量。

五、课程建议

• 经过一学期的学习，在OO课程的互测机制上进行过分析，思考过多种可能的解决问题的办法。但是发现很多方法最后都要落脚于【人】上，即要依靠人的主动性。然而这样的课程设计自然是不鲁棒的。之前阅读了昂神的建议，觉得深受感触。完善公测的评测机制，平衡公测与互测的地位是一种比较好的策略。

• 另外呢，个人认为，OO课程与OO实验可以增强联系。JUNIT的使用即为一个样例。实验课上的Junit的使用方法的pdf可以在OO作业之前发出来！实验课上的Junit的使用方法的pdf可以在OO作业之前发出来！实验课上的Junit的使用方法的pdf可以在OO作业之前发出来！
  重要的事情说三遍。大概就是如此了。