OO最后一次博客作业

一、测试与正确性论证效果差异

  说实话,单从结果来看,我认为对于我们的作业还是测试的意义更大一些,因为从一开始到现在主要寻找bug的方式就是测试。先构造样例,再根据结果分析问题。而正确性论证是后来才进行的,建立在已有代码的基础上,所以如果正确性论证出问题大抵还是因为对正确性论证本身的理解出了偏差,代码出问题的可能性还是比较低的。

  测试的优点自然不用多说,它能让我们明确问题,而且通过构造样例,插桩,单元测试等手段明确问题所在。而缺点就是我们基本不可能做到所有case的覆盖,所以很难证明的确是对的。

  正确性论证其实处在一个微妙的境地,它本来的有点就是能通过形式化论证,论证我们的代码的确符合规格,也就是符合设计意图。但是缺点也很明显,就算符合设计意图,设计本身就有问题怎么办,这是它不能发现的问题。除此之外,还有一个问题就是,简单的划分无需论证,正确性很显然;而一些较为复杂的逻辑就算论证了,也很难保证其正确性,很可能划分就是错的。所以正确性论证在效果上没有测试好。

二、OCL语言和JSF

  OCL是一种对象约束语言,它可以描述四类约束,分别是不变量,前置条件,后置条件和监护条件。

  • 不变量是在属性的生命期内一直保持为真的规则。
  • 前置条件是在一个操作被调用时必须为真的约束。它是一个断言,不是可执行语句。
  • 后置条件就是在操作完成时必须为真的约束。它不是可执行语句而是断言,必须为真。
  • 监护规则是在对象能够从一种状态转变为另一种状态前其值必须为真的约束。

  它与JSF相似之处就是都拥有不变量、前置条件、和后置条件的概念。

  而不同之处则很多,OCL的表达能力要远强于JSF,而且要比JSF更加严格,其定义了基本类型和基本数据结构,并且有多种类型的关键字,例如If,Let表达式等。尽管OCL一般用于建模,但还是有用其进行编程的可能。

  除此之外,貌似OCL语言对多线程的支持较弱,而JSF中有对线程的约束,在多线程场景下表达能力较强。

三、UML

请求类、请求队列类、电梯类、调度器类类图

顺序图

扫描二维码关注公众号,回复: 1720121 查看本文章

请求类状态图

请求队列类状态图

电梯类状态图

调度器状态图

四、学期总结

4.1 四个单元模块知识点关系

  第一单元主要是面向对象的基本概念,例如什么是对象,什么是继承、多态、抽象等。第二单元前两节是有关多线程的知识,而之后是一些设计原则。第三单元主要是有关数据抽象、过程抽象等一系列关于JSF的内容。第四单元是有关单元测试、正确性论证等内容。整体来讲内容的抽象化程度是不断提高的,也是循序渐进的过程,形成了一个知识体系,除了第一单元的基础,剩下单元都是在第一单元基础上进行提升与完善的过程。

4.2 设计、测试和质量上的进步

  在代码质量上的进步我体会是不大的,毕竟课程并没有过多的对代码风格做出硬性规定,很难评判自己的代码风格是否有进步。虽然这门课讲了很多,但是由于互测机制的引入大家的兴趣点全在测试上,所以测试能力也可以说提高了一点点。但不得不承认设计还算有一点进步的,至少能从面向对象的角度去考虑问题。设计是否优秀暂且不谈,但是每一次作业的困难都感觉是在设计上而不在编码上,我感觉这至少能算作一个进步,说明通过设计,减少了编码阶段要考虑的许多逻辑,对好的设计的重要性体会还蛮深。

4.3 工程化开发理解

  因为这门课暂时涉及不到团队协作的问题,所以对工程化开发的理解仅仅停留在一个很表面的层次。在这门课程中我所做的就是设计,细化设计,编码,测试按部就班进行的,这形成了一个固定套路,提高了我的效率并减少了思维量,这也许就是工程化开发的意义所在。大抵宗旨就是把一个大规模问题规范化,模块化,从而提升效率并降低bug率。当然这门课的作业相对来讲还并非特别特别复杂,我所做的也称不上工程化开发,只能说是感受到了按照一定流程开发的方便之处。

4.4 对课程的期望或建议

  最好还是降低一下对每次作业结果评判的严苛程度,某些可以readme的东西就因为同学们不停的询问,全变成了死要求,让我不禁开始怀疑issues是个错误的存在。。。所以对于需求可以细化,但是不要太过细化,因为某些同学周二晚上的问题所有不符合的人全得改,未免是很心累的。

  还有就是唯bug论也是很坑的,不考虑设计,不考虑代码风格,仅仅考虑能找出多少错。我知道很难有一个标准去评判设计好坏或代码风格好坏,但唯bug论很容易让人失去改变代码风格或考虑优秀设计的动力。

  互测机制的出发点是对的,但是因为一个人的恶意扣分会引起他人的恐慌,一个好人也会因此变成恶人。可能互测这种事还不适合一群大二的学生,尤其是在与分数挂钩的时候,bug的界限再模糊一点,留给学生的都是心理的疲惫。一个学生,很努力很努力,尝试新的设计思想与设计模式,结果因为模糊不清的jsf被扣掉了几十个bug,他还有何动力再去尝试新的东西?互测存在,很难改变面向运气编程的格局,好多好多人都在期待遇到一个友善的测试者,友善的测试者甚至比代码本身还重要,一类错误,好人会算一个,分数的走狗会给你分类算好几个,而分类树的存在仅仅能改善这一问题,完全解决这一问题是不存在的,毕竟很多作业本身就没有一个标准的答案,JSF就更不用提了。

  总而言之,这门课大概在以其自己的方式改变着,据我了解我们比上届也好多了。但很多矛盾是不可调和的,这门课程只要与分数挂钩,就总会有恶人存在,就总会有好多努力的人被不断打击甚至失去动力。我想降低互测分数的比重,更相信学生的自觉性会好一些。那样认真的人还是会认真,不认真的人也不会为了一点点分就去处心积虑去找规则的漏洞,整体生态环境会好一些。

猜你喜欢

转载自www.cnblogs.com/mingming97/p/9217380.html