OO第三次博客做业

一、规则化发展历史调研

　　程序中的规格化设计的发展历史，与计算机的发展历史、编程设计的发展历史是紧密相连，密不可分的。从1940年的面向机器编程，到以后的面向过程编程，逐渐出现了咱们如今使用的各个语言的原始版本。而随着代码量的不断增长，程序功能的不断复杂化，简单的面向过程编程再也不可以知足人们的须要，所以，出现告终构化程序设计。而从这一过程当中，编写代码的人们也注意到了规格的重要性。“结构化程序设计”做为另一种解决软件危机的方案被提出来了。 Edsger Dijkstra 于 1968 发表了著名的《GOTO 有害论》的论文,引发了长达数年的论战,并由此产生告终构化程序设计方 法。同时,第一个结构化的程序语言 Pascal 也在此时诞生,并迅速流行起来。在此以后，随着硬件的快速发展，程序的复杂度迎来了再一次的飞跃，而这时出现了面向对象编程。此后规格化获得了人们愈来愈多的重视，由于其能够帮助阅读者迅速理解代码，也能帮助设计者更好的设计、规划本身的程序，避免因为粗枝大叶形成的种种错误。

二、规格BUG分析

	规格BUG	功能BUG	是否有联系
第九次做业	0	0	无
第十次做业	1	2	无
第十一次做业	0	2	无

惟一一个规格BUG是某一个类规格的抽象对象不明确。而4个功能BUG中，3个都是因为后来做业中，每次更新新的GUI时，总会漏掉某一些以前做业中对于GUI的更改（好比对于时间的更改。。）。

三、规格BUG产生的缘由

　　第十次做业中规格BUG产生的缘由，是对于抽象对象的概念不明确。也能够说是对类规格整体概念的不明确。在以后特地翻阅了前几回的全部PPT，虽然没有对抽象对象的明肯定义，但根据上下文，以及对于类规格的理解更进一步后，也算是更加理解了抽象对象的概念 吧。

四、5个前置条件和后置条件很差的写法

一、前置条件、后置条件不许确。

修改前：

/** @ REQUIRES: r!=null
@ MODIFIES: this
@ EFFECTS: RL[len++]=r
@ THREAD_REQUIRES:
@ THREAD_EFFECTS:
@ */

修改后：

/** @ REQUIRES: r!=null
@ MODIFIES: this
@ EFFECTS: r.repOK()==true ==> (RL[len++]==r) && (RL.contain(r)==true);
@ THREAD_REQUIRES:
@ THREAD_EFFECTS:
@ */

二、使用了天然语言

/** @ REQUIRES:
@ MODIFIES: chead
@ EFFECTS: 将RL队列的头指针更新到相应位置
@ THREAD_REQUIRES:
@ THREAD_EFFECTS:
@ */

修改后：

/** @ REQUIRES:
@ MODIFIES: chead
@ EFFECTS: while(head<len && RL[head].issleep==false) ==> head++;
@ THREAD_REQUIRES:
@ THREAD_EFFECTS:
@ */

三、没有关于异常的信息

/** @ REQUIRES:
@ MODIFIES:
@ EFFECTS: AL.hasNext() ==> \result == AL.Next();
@ THREAD_REQUIRES:
@ THREAD_EFFECTS:
@ */

修改后：

/** @ REQUIRES:
@ MODIFIES:
@ EFFECTS: AL.hasNext() ==> \result == AL.Next();
@ Otherwise ==> throw NoSuchElementException
@ THREAD_REQUIRES:
@ THREAD_EFFECTS:
@ */

四、没有及时更新

/** @ REQUIRES:
@ MODIFIES:
@ EFFECTS: str == CheckTaxi ==> \result=1;
@str == CheckStatus ==> \result=2;
@else \result=0;
@ THREAD_REQUIRES:
@ THREAD_EFFECTS:
@ */

修改后：

/** @ REQUIRES:
@ MODIFIES:
@ EFFECTS: str == CheckTaxi ==> \result=1;
@str == CheckStatus ==> \result=2;
@str == SetRoadStatus==> \result=3;
else \result=0;
@ THREAD_REQUIRES:
@ THREAD_EFFECTS:
@ */

五、不完整

/** @ REQUIRES: 0<=LP,CP,NP<80
@ MODIFIES:
@ EFFECTS: light's red ==> \result==wait time;
@ light's green ==> \result==0;
@ THREAD_REQUIRES:
@ THREAD_EFFECTS: \lock(guigv.lightmap);
@ */

修改后：

/** @ REQUIRES: 0<=LP,CP,NP<80
@ MODIFIES:
@ EFFECTS: (light's red) || (direction == right) ==> \result==wait time;
@ light's green ==> \result==0;
@ THREAD_REQUIRES:
@ THREAD_EFFECTS: \lock(guigv.lightmap);
@ */

五、功能BUG与规格BUG在方法上的汇集关系

　　在这一单元的三次做业中，功能BUG与规格BUG没有汇集关系。规格BUG出如今InputHandler的类规格中，而4个功能BUG中，2个源于同一个缘由，即在LoadFile类中，缘由是忘记将编号-1再做为下标。而另外2个都在不要求写规格的GUI中。因为GUI中的默认设置和新修改后的规定不一致，没有修改彻底（忘记了某一个东西要改）形成的。

	功能BUG	规格BUG
InputHandler	0	1
LoadFile	2	0
Gui	2	0

 

六、基本思路和体会

　　能够体会到，在未来咱们在实习中、工做中所要处理的大型工程中，完善、统1、严格的规格是十分必要的。这样的好处有：

一、减小出现低级BUG的几率，极大的减小了后期DEBUG时须要的时间，提升了工做效率。

二、方便在团队合做时的契合，使本身的代码可读性更高，在其余同伴理解、使用本身的代码时，基本上不会出现过多的误差。

三、优化本身的代码风格，加强本身的代码编写能力。

　　写规格的思路：在写规格时，应尽可能使用布尔表达式。而这一重要原则也等因而再检查了一遍本身的代码是否符合面向对象编程的原则：当有那种极为冗杂，功能复杂，不符合面向对象编程思惟的方法时，每每是写不出来由布尔表达是组成的标准后置条件的。

题外话：

　　在第十一次做业中，出现了大量以“管他是否是BUG报了再说，反正不是BUG对方会申诉，是BUG我就加分”心态报了BUG的现象。这显然是由于提交BUG几乎不须要成本，而误报BUG也没有惩罚的制度缺陷下，测试者滥用权力形成的。我的认为，OO在引入了互测这种人为因素极大的测试方式的状况下，各方面规定极为不完善，还有许多没有量化标准的规定，致使了许多争端与不合理的扣分，也致使了每次做业同窗们都须要浪费极为大量的时间在与助教沟通各项规定的细则、特殊状况，以及与测试者的沟通上。也许锻炼咱们理解需求的能力、锻炼咱们沟通能力的初衷是好的，可是在本学期中，我的认为OO的确存在占用了大多数同窗过多的时间的问题。一门课程致使大多数学生常常熬夜难道不正是课程设计上不合理的一种体现吗？而根据开课时老师们的表现来看，彷佛为这此而引觉得豪？。。