1、规则化发展历史调研
程序中的规格化设计的发展历史，与计算机的发展历史、编程设计的发展历史是紧密相连，密不可分的。从1940年的面向机器编程，到之后的面向过程编程，逐渐出现了我们现在使用的各个语言的原始版本。而随着代码量的不断增加，程序功能的不断复杂化，简单的面向过程编程不再能够满足人们的需要，因此，出现了结构化程序设计。而从这一过程中，编写代码的人们也注意到了规格的重要性。“结构化程序设计”作为另外一种解决软件危机的方案被提出来了。 Edsger Dijkstra 于 1968 发表了著名的《GOTO 有害论》的论文,引起了长达数年的论战,并由此产生了结构化程序设计方 法。同时,第一个结构化的程序语言 Pascal 也在此时诞生,并迅速流行起来。在此之后，随着硬件的快速发展，程序的复杂度迎来了再一次的飞跃，而这时出现了面向对象编程。此后规格化得到了人们越来越多的重视，因为其可以帮助阅读者迅速理解代码，也能帮助设计者更好的设计、规划自己的程序，避免由于粗心大意造成的种种错误。
2、规格BUG分析
| 规格BUG | 功能BUG | 是否有联系 | |
| 第九次作业 | 0 | 0 | 无 |
| 第十次作业 | 1 | 2 | 无 |
| 第十一次作业 | 0 | 2 | 无 |
唯一一个规格BUG是某一个类规格的抽象对象不明确。而4个功能BUG中，3个都是由于后来作业中，每次更新新的GUI时，总会漏掉某一些之前作业中对于GUI的更改（比如对于时间的更改。。）。
3、规格BUG产生的原因
第十次作业中规格BUG产生的原因，是对于抽象对象的概念不明确。也可以说是对类规格总体概念的不明确。在之后特意翻阅了前几次的所有PPT，虽然没有对抽象对象的明确定义，但根据上下文，以及对于类规格的理解更进一步后，也算是更加理解了抽象对象的概念 吧。
4、5个前置条件和后置条件不好的写法
1、前置条件、后置条件不准确。
修改前：
/** @ 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:
@ */
2、使用了自然语言
/** @ 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:
@ */
3、没有关于异常的信息
/** @ REQUIRES:
@ MODIFIES:
@ EFFECTS: AL.hasNext() ==>
esult == AL.Next();
@ THREAD_REQUIRES:
@ THREAD_EFFECTS:
@ */
修改后：
/** @ REQUIRES:
@ MODIFIES:
@ EFFECTS: AL.hasNext() ==>
esult == AL.Next();
@ Otherwise ==> throw NoSuchElementException
@ THREAD_REQUIRES:
@ THREAD_EFFECTS:
@ */
4、没有及时更新
/** @ REQUIRES:
@ MODIFIES:
@ EFFECTS: str == CheckTaxi ==>
esult=1;
@str == CheckStatus ==>
esult=2;
@else
esult=0;
@ THREAD_REQUIRES:
@ THREAD_EFFECTS:
@ */
修改后：
/** @ REQUIRES:
@ MODIFIES:
@ EFFECTS: str == CheckTaxi ==>
esult=1;
@str == CheckStatus ==>
esult=2;
@str == SetRoadStatus==>
esult=3;
else
esult=0;
@ THREAD_REQUIRES:
@ THREAD_EFFECTS:
@ */
5、不完整
/** @ REQUIRES: 0<=LP,CP,NP<80
@ MODIFIES:
@ EFFECTS: light's red ==>
esult==wait time;
@ light's green ==>
esult==0;
@ THREAD_REQUIRES:
@ THREAD_EFFECTS: lock(guigv.lightmap);
@ */
修改后：
/** @ REQUIRES: 0<=LP,CP,NP<80
@ MODIFIES:
@ EFFECTS: (light's red) || (direction == right) ==>
esult==wait time;
@ light's green ==>
esult==0;
@ THREAD_REQUIRES:
@ THREAD_EFFECTS: lock(guigv.lightmap);
@ */
5、功能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 |
6、基本思路和体会
可以体会到，在将来我们在实习中、工作中所要处理的大型工程中，完善、统一、严格的规格是十分必要的。这样的好处有：
1、减少出现低级BUG的概率，极大的减少了后期DEBUG时需要的时间，提高了工作效率。
2、方便在团队合作时的契合，使自己的代码可读性更高，在其他同伴理解、使用自己的代码时，基本上不会出现过多的偏差。
3、优化自己的代码风格，增强自己的代码编写能力。
写规格的思路：在写规格时，应尽量使用布尔表达式。而这一重要原则也等于是再检查了一遍自己的代码是否符合面向对象编程的原则：当有那种极为冗杂，功能复杂，不符合面向对象编程思维的方法时，往往是写不出来由布尔表达是组成的标准后置条件的。
题外话：
在第十一次作业中，出现了大量以“管他是不是BUG报了再说，反正不是BUG对方会申诉，是BUG我就加分”心态报了BUG的现象。这显然是因为提交BUG几乎不需要成本，而误报BUG也没有惩罚的制度缺陷下，测试者滥用权力造成的。个人认为，OO在引入了互测这种人为因素极大的测试方式的情况下，各方面规定极为不完善，还有许多没有量化标准的规定，导致了许多争端与不合理的扣分，也导致了每次作业同学们都需要浪费极为大量的时间在与助教沟通各项规定的细则、特殊情况，以及与测试者的沟通上。也许锻炼我们理解需求的能力、锻炼我们沟通能力的初衷是好的，但是在本学期中，个人认为OO的确存在占用了大多数同学过多的时间的问题。一门课程导致大多数学生经常熬夜难道不正是课程设计上不合理的一种体现吗？而根据开课时老师们的表现来看，似乎为这此而引以为豪？。。