1. 规格设计的发展历史
规格设计用于对程序设提供分解，抽象等的手段。在撰写代码规格的时候，需要对组成部件进行抽象。
在1960s，软件设计出现危机，例如Dijkstra提出了goto语句的种种危害，引发了软件开发领域长期的论战，并且在这时候产生了结构化程序设计方法，例如Pascal语言在1970s占据有统治地位。
之后，随着计算机软件规模日渐庞大，结构化程序设计方法开始无法满足用户的需求，面向对象程序设计（OOP）应运而生。面向对象程序设计是一场重大的革命，提高了开发人员的效率，有效的控制了软件开发的复杂度，提高了软件的可维护性和可拓展性。
规格化设计是随着面向对象程序设计的火热而发展起来的，可以有效提高程序的规范性以及程序的模块化划分。这样使得程序设计的数据更加安全，软件的可维护性得到有效的提高。
2. 规格Bug
由于我觉得JSF意义寥寥，没有认证对待，又或是我欧气不足，每次都被报了很多规格相关的bug
| 作业次数 | Bug分类 | 具体原因 |
|---|---|---|
| 9 | 不符合JSF规范 | JSF必须以/**开头，这个我没有注意 |
| 9 | Modifies不完整 | 使用了较明显的自然语言 |
| 9 | Requires不完整 | 前置条件必须为布尔表达式 |
| 10 | Effects逻辑错误 | \result == true了，不知道自己是怎么想的 |
| 10 | Effects不完整 | EFFECTS中的内容与Modifies重合 |
| 10 | Requires逻辑错误 | 这个是因为修改了方法却忘了改规格，应该diff一下的 |
| 10 | 不符合JSF规范 | Modifies应该只列出被修改的对象 |
| 11 | Requires逻辑错误 | Requires使用了自然语言 |
| 11 | Effects不完整 | Modifes中修改了this，但是没有在Effects中写出 |
3. Bug产生原因
- 第九次作业时，没有认真看JSF的说明，也很随意的使用了自然语言。
- 第十次作业时，首先这次作业出现了修改了代码但是忘记修改规格的问题，另外对Modifies和Effects的功能区别没有搞很清楚。
- 第十一次作业时，除了一点小错误，还是没有把Modifies和Effects的功能区别搞很清楚。
4. 不好写法举例
改进前：
/* @REQUIRES: None/* @
* @MODIFIES: All that below... Sorry I won't copy it again :)
* @EFFECTS: Call: gui.SetTaxiStatus()
*/改进后：
/* @REQUIRES: None/* @
* @MODIFIES: this
* @EFFECTS: this != \old(this)
*/改进前:
/* @REQUIRES: currentRequest is not null;
state is ORDERED or SERVING;
destination is not null;
currentPoint is in roadMap.mapPoints[][];
* @MODIFIES: state if destination is reached;
* currentPoint;
* gui
* @EFFECTS: gui is updated
*/改进后：
/* @REQUIRES: currentRequest != null;
state == ORDERED || state == SERVING;
destination != null;
* @MODIFIES: state; currentPoint; gui
* @EFFECTS: gui != \old(gui) && state != \old(state)
*/改进前：
private void finishRequest() {
/**@REQUIRES: None
* @MODIFIES: \this.currentRequest;
* \this.state;
* \this.destination;
* \this.startWaitingTime;
* @EFFECTS: None
*/
}改进后：
private void finishRequest() {
/**@REQUIRES: None
* @MODIFIES: this
* @EFFECTS: this != \old(this)
*/
currentRequest = null;
state = CarState.WAITING;
destination = null;
totalWaitingTime = 0;
}改进前：
synchronized private void moveRandom() throws InterruptedException {
/**@REQUIRES: currentPoint in roadMap.mapPoints[][]
* @MODIFIES: currentPoint;
* gui
* @EFFECTS: gui != \old(gui)
*/改进后：
synchronized private void moveRandom() throws InterruptedException {
/**@REQUIRES: \exist int r, c; 0 <= r < 80 && 0 <= c < 80 && RoadMap[r1][c1] == source &&
RoadMap[r2][c2] == destination;
* @MODIFIES: currentPoint;
* gui
* @EFFECTS: gui != \old(gui)
*/功能bug
第九次作业：
| 方法名 | 功能bug | 规格bug |
|---|---|---|
| Car.update | 1 | 0 |
| CarsController.assignRequest | 1 | 0 |
第十次作业：
| 方法名 | 功能bug | 规格bug |
|---|---|---|
| RoadMap.addFlow | 1 | 0 |
第十一作业：
| 方法名 | 功能bug | 规格bug |
| ---------------------------- | ------- | ------- |
| Car:update | 1 | 0 |
心得体会
要求用布尔语言来写规格实在有些不靠谱，毕竟做的不是数据结构题，很多函数用布尔表达式很难说清。如果真的想要完全说好，最后的规格可能比代码还要长。
收获大概是注释确实很重要，但还是表达清楚意思最为重要，不要拘泥与形式，当然这也可能是课程设计上为了互测做的不可避免的牺牲。