一、规格化发展历史及其重要性
规格化的设计方法起源于20世纪50年代后期对于编程语言和编译技术的研究，当时出现了各种语法分析程序自动生成器以及语法制导的编译方法，此时结构化的程序设计方法逐渐成为软件设计的主流方法。
随着计算机技术的发展，软件设计的需求急剧增长，原来的结构化的设计方法已经越来越难以满足需求，软件的开发和维护成本也在不断提高，这就导致了所谓的“软件危机”的爆发。规格化设计的研究高潮始于20世纪60年代后期，针对当时所谓的“软件危机”，人们提出种种解决方法，如采用工程方法来组织、管理开发过程和通过钻研规律建立严密的理论以指导开发实践，软件工程的概念也正是在这样的大背景下诞生的。
经过多年的研究和应用，如今人们在规格化设计方面已经取得了大量、重要的成果，从早期最简单的一阶谓词演算到现在的基于逻辑、状态机、网络、进程、代数等多种规格形式化方法，同时规格化的设计方法不仅局限于代码码阶段，而是逐渐融入设计开发的各个阶段，例如需求分析、功能描述、算法设计、编程、测试以及后期的维护工作等。
我认为规格化的设计方法之所以能够得到人们的重视，是因为其对于代码的编写以及整个项目的开发和维护都是有着十分重要的意义和作用。一方面，规格化的设计方法有助于我们在程序的构思和设计阶段明确设计需求，为我们的代码编写指明方向，可以减少我们在编写代码时的盲目性；另一方面，规格化的设计方法对于软件的使用和维护工作带来极大便利，为多人协同开发大型软件带来极大的便利，同时也使得整个软件的生命周期得到延长。
二、规格bug分析
1. 第九次作业
| 规格bug类别 | bug内容 | 对应方法 |
|---|---|---|
| jsf不符合规范 | exception_behavior理解错误 | Main类中的main方法 |
| Modifies不完整 | 方法内使用其他方法更改属性，但并未指出 | Taxi类中的searchRequest方法 |
| Requires不完整 | 未指出requestQueue为null的情况 | InputHandler类中的isSameRequest方法 |
| Modifies不完整 | 方法内使用其他方法更改属性，但并未指出 | InputHandler类中的setTaxi方法 |
| Requires不完整 | 未指出srcPoint!=null的前置条件 | Request类中的printRequestInfo方法 |
2. 第十次作业
| 规格bug类别 | bug内容 | 对应方法 |
|---|---|---|
| jsf不符合规范 | 使用JSFTools检测到了Error和Warning | 测试者未指出 |
| jsf不符合规范 | 使用JSFTools检测到了Error和Warning | 测试者未指出 |
| jsf不符合规范 | 使用JSFTools检测到了Error和Warning | 测试者未指出 |
| Modifies不完整 | 方法内使用其他方法更改属性，但并未指出 | Taxi类中run方法 |
| Modifies不完整 | 方法内使用其他方法更改属性，但并未指出 | InputHandler中的Run方法 |
3. 第十一次作业
未测出规格类bug。
三、规格bug产生原因
我认为原因主要有以下几个方面：
- 对jsf的规范细节理解不够清楚，虽然仔细阅读了下发的两个Guideline文件，但由于自身阅读理解水平有限，加之两个Guideline文档叙述较为精炼，因而对jsf的语法规范出现了理解上的偏差，出现了很多格式上的问题。
- 未能充分利用JSFTools来对自己的规格书写进行检测，并根据检测结果进行修正，因而给了测试者报bug的理由。
- 因整个作业内方法数量太多，虽然耗费了较多的时间撰写规格，但仍未能对每一个方法的规格都进行充分的分析，部分方法的Requires分析不完整。
- 对于方法内调用用其他方法更改属性，是否需要在Modifies中指出这一点，助教的回复与测试者的观点出现了分歧。
四、规格改进
1.前置条件：
（1）使用自然语言，使用自然语言描述表意不够清晰，容易产生二义性，且Guideline明确指出前置条件不允许使用自然语言。改进：使用布尔表达式。
（2）过于冗余，对于一些明显在任何情况下都满足的条件，我认为不需要过多赘述，但测试者可能认为这属于Requires不完整。改进：可以适当删除冗余条件，但为了避免被扣分，最好还是暂时保留那些冗余的部分。
（3）过于简单，可能缺少必要的前置条件，而恰恰这些条件会对方法的结果产生影响。改进：认真分析方法结构和功能，使前置条件书写更加完整。
（4）格式不规范，如将==，>=等符号写错，缺少分号等细节问题。改进：认真阅读jsf圣经Guideline，使用钦定的jsftools对自己的规格进行检测。
（5）多线程条件下规格不完整。改进：认真分析方法对多线程同步的需求，避免遗漏THREAD_REQUIRES。
2.后置条件：
（1）使用自然语言，使用自然语言描述虽然不易扣分，但表意不够清楚，容易产生二义性。改进：使用布尔表达式。
（2）过于冗余，对于一些方法执行后系统状态的描述，可能以经在其调用的方法内描述过，不需要再进行重复表述。改进：可以适当删除冗余条件，但为了避免被扣分，也可以暂时保留那些冗余的部分。
（3）过于简略，可能缺少必要的后置条件，而恰恰这些条件是方法执行后返回结果或系统状态应该必须满足的要求。改进：认真分析方法结构和功能，使后置条件书写更加完整。
（4）格式不规范，出现对算法的描述等。改进：认真阅读jsf圣经Guideline，使用钦定的jsftools对自己的规格进行检测。
（5）多线程条件下规格不完整。改进：认真分析方法对多线程同步的需求，避免遗漏THREAD_EFFECTS。
五、功能bug与规格bug在方法上的聚集关系
在第九次和第十次作业中测试者只报告了许多规格bug，而第十一次作业测试者又只报告了功能bug，所以说人生啊，就是这样不可预测，且所报的功能bug也并不指向具体的方法，而是关于文档书写、代码风格结构的方面的bug。所以仅仅从这三次的作业的测试结果来分析，无论是横向还是纵向，二者之间并无明显的直接关联。当然也可能是由于测试者侧重点主要在于容易扣分的jsf规格类bug，而忽略了对功能bug的测试，所以这种聚集关系一时还难以体现。
六、规格撰写思路和体会
最近几次作业的规格撰写都是在写好现有方法的基础上才书写规格，但我认为更加理想的方式应该是先有规格后有方法，根据规格来实现方法的功能。在撰写规格的时候，一定不能仅仅局限于方法的参数或返回值，而应该对方法内所有用到的属性或变量需要满足的条件，以及所有被方法更改过的属性在方法结束时满足的状态，都有一个全面的认识。
从上课时的作业bug统计情况可以看出，我们的课程最多允许报告38个规格类bug，但最后被报的规格类bug总数还远远不及功能性bug的数量，说明包括我自己在内的许多测试者在之前的测试中对方法规格的重要性并没有充分的认识，也没有对测试代码的规格书写进行认真的分析和报告，而这显然是不符合我们这门课程的预期要求的。所以我们在最后三次作业的互测中，一定要更加注重对于自己程序的规格撰写，同时更加注重对于规格类bug的分析和报告，以期达到我们这门课程的训练要求和学习目的。