oo第三次总结

Posted 2020-11-09 lexmechanic

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

（由于在百度和谷歌上均未能找到与规格化设计的历史有关的资料，因此这部分参考了许多同学的博客）

程序设计的演变大致可以分成以下三个过程：

　　1. 20世纪60年代以前，计算机刚刚投入实际使用，软件设计往往只是为了一个特定的应用而在指定的计算机上设计和编制，采用密切依赖于计算机的机器代码或汇编语言，软件的规模比较小，很少使用系统化的开发方式，此时的代码更多的是私人性质的，满足个人要求的程序。
　　2. 60年代中期，大容量、高速度的计算机出现，随之出现的是代码量急剧提升，复杂度急剧增长、程序可靠性问题突出的问题。结果化程序设计随之提出，它要求程序设计时以模块为单位，每个模块专职自己的工作，而要在模块间交流，在开发者和用户，开发者和开发者之间交流，就只需要相应接口即可。
　　3. 80年代，面向对象的设计开始在业界大行其道，相比于单纯的结构化设计，面向对象的设计从审视问题的角度上就有了差异，程序发生了从围绕“行为”执行到围绕“客体”执行的变化，随之而来的，就是封装性地提高，可重用性的提高，可以说，面向对象进一步实现了结构化设计，是结构化设计更进一步的实现。

我在维基上找到的与规格化设计最相关的词条就是Software requirements specification, IEEE推荐的一项举措，即在开发软件之前先书写文档说明该软件的预期功能和需求。如果使用得当的话，“软件需求规格可以预防工程的失败”。

 二、bug分析

这个……怎么说呢，六次作业总共被人挂了8个jsf错误，但是其中6个都在等待仲裁……所以我也不知道该怎么写。总之先把确定无误的两个jsf bug挂上来吧。

作业次数	所在方法	所在类	代码行数	产生原因
9	wander	Taxi	64	modifies没有写好
9	compileRoute	Taxi	59	requires没有写好

由于我也是先写的代码再补充的jsf，所以只能说自己写jsf的时候不够上心。

//而且代码的主干部分是在第七次作业里就写好的。

除了jsf以外还被报了若干bug，基本上都是因为自己懈怠才会产生的问题：第九次和第十次作业均因为没有对文件处理问题进行足够的测试导致公测挂了总共4个点，然后又被另挂了2个点（不包括等待仲裁的点）。有3个bug是因为没有读好指导书导致的：输出到文件里的内容缺少部分内容。一个bug是因为程序进行一次大的重构时产生的：第七次作业中最开始时记载点的位置时是以横坐标作为第一维的，然而开始调用gui的时候才发现用纵坐标作为第一维才是通行的做法，在修改代码的过程中漏掉了输出到文件中这一部分的代码，导致程序能够正常运行，但输出时有的点横纵坐标是反的。最后一个bug实在是想不到：我的程序对Load Filename指令实现时没有考虑到文件名中存在空格的情况，结果导致程序会将带有空格的文件名视为无效输入。

 

三、不好的jsf写法举例

1. 什么也没有

一个方法里requests, modifies, effects什么都没有，显然不可能，要不然这个方法岂不是什么用也没有？即使是专门用来返回一个属性的值的方法，也应当至少有

/**
 * @EFFECTS: \\result == (something);
 */

 这样的说明。

2. 没有使用布尔表达式

/**
 * @EFFECTS: this.property;
 */

改进：

/**
 * @EFFECTS: \\result == this.property;
 */

 3. effects写成这样：

/**
 * @EFFECTS: this != null;
 */

显然这是一个repOK方法的jsf。与其这样写，倒不如直接写成：

/**
 * @EFFECTS: \\result == true;
 */

 因为this != null就是一句废话。

 

四、关于规格化的总结：

/*可能是因为我太菜了吧，*/因为我的水平实在是太菜，到现在为止并没有体会到规格化的好处。个人认为也可能是因为现在写的工程规模都还比较小，需求也都比较明确/*emmm*/，所以对规格化的要求没有那么紧迫。可能在以后写大规模的工程时或是多人合作完成工程的时候规格化的好处能够更好地体现出来。