OO第九到十一次作业小结

一、规格化设计的大致发展历史

　　软件的规格化一直是软件工程领域研究的一个重要课题。保证程序的正确性，减少软件错误一直是软件研究者关注的目标。

　　计算机发展初期，软件的规模很小，并没有暴露出没有统一规格化的现实问题。而随着计算机科学和技术的快速发展。1960至1980年代软件开发的过程中遇到了一系列问题，这段期间多半是用COBOL和Fortran语言开发，后来也使用C语言及BASIC，也没有将需求及设计文件化的技术。随着系统越来越大也更加复杂，信息系统的发展也变得越来越困难。”为了方便管理大而复杂的系统，演进出一系列的结构化方法。

　　英国计算机科学家C. A. R. Hoare在1969年的论文“计算机程序的公理基础”中提出了著名的针对函数与方法规格化，基于“前置后置条件”的接口规格方法。

　　后来，人们在设计程序时开始以模块为单位，这个时候开始出现了规格化的抽象。后期发展出的面向对象语言C++和JAVA便出现了类说明和类实现的分离。而随着使用者和设计者的分离，在代码移植和跨平台的过程中，软件规格化愈发凸显了其重要性。规格化的程序设计也随之继续发展，直到现在。

 

二、规格bug汇总以及产生原因分析

　　以上便是在两次作业的过程中，我被发现的共计两种不符合规范的写法。其中第一个错误在两次作业中重复出现，因为在写规格的时候由于写代码赋值的习惯所以会写成单等号，所以在不止一个方法中出现了这个问题，导致了在两次互测环节被发现。

　　而第二种错误写法则更多是因为我对布尔表达式的写法以及如何将方法抽象成相应布尔表达式不够熟练，在更靠后的作业中，我对布尔表达式的逻辑写法进行了复习巩固，基本上解决了这个问题。

 

三、部分不好的规格写法的改进方法

01：

　　问题分析：这是一个类的初始化的方法。其中Modifies的写法过于冗长，还可能会出现漏写的现象。

　　改进方法：用\this一言蔽之。

 

02：

　　问题分析：由于时间紧张以及对布尔表达式写法的不熟悉，部分方法的后置条件的内容使用了自然语言去概括。需要明确的是，自然语言具有二义性，可能会造成歧义。

　　改进方法：对于相对简单的方法，使用布尔表达式进行逻辑表达。较长较复杂的方法，进行拆分分别描述。

 

03：

　　问题分析：这个方法传进的是一个类，在写前置条件的时候，仅对对象的部分属性进行了约束，这样的做法可能忽略了这个类中其余可能出现问题的变量。

　　改进方法：利用类中所写的repOK，若满足不变式，即对所有变量进行了约束。

 

四、功能bug与规格bug在方法上的聚集关系

　　分析：在这几次连续的作业中，可以看出我的功能bug数和规格bug数都是在逐步下降的。我在第九次作业中被报了很多功能bug，其中更是包含了两个crash，这源自于对容错处理的欠缺考虑。虽然看到结果很不开心，但毕竟是自己的bug，我能做的也只是完善自己的代码，使它做的更好，考虑的更完善。于是在第十次作业期间，除新功能实现外，我花大力气去进行了以往bug处理，使之后被发现的功能bug数直线下降。第十次作业的3个功能bug中，有两个来自repOK，我也在之后的作业中进行了处理。

　　规格问题，因为第九次作业是第一次接触，所以被发现的不完善的点较多，在之后的作业中我也实现了对之前所写规格的改进和新方法规格的严格要求，基本解决了错误写法。

 

五、规格设计思路及体会

01. 先写规格后写方法是最正确的流程，根据规格可以更加规范自己的代码思路，写出的逻辑也更加清楚，当然就不会出现面对一堆代码对规格无从下手的问题了。

02. 还是应该意识到规格的重要性。虽然写的过程比较痛苦，但毕竟整个系统都是自己一个人实现的。今后很多的编程是需要移植或者与他人合作的。如果人人都好好写JSF，相互之间的代码就更好用了呢~

03. 很多同学吐槽说这门课的测试环节仿佛成了面向运气，遇到佛系和遇到认真的同学的分数差距真的会很大。我在第九次作业成绩出来之后也很有这种感觉，但更后面的两次作业，由于第九次作业后我对很多bug实现了改进，没有被找到其他更多更严重的bug。所以还是应该摆正心态，被扣分也别着急生气，有问题就去心平气和的申诉，有道理就去改进自己的程序。总之，还是希望这门课程在课程设计方面越来越好吧:)。