（1）关于规格化设计……我在网上没能找到有效的资料，结构化设计的资料倒是找到一些，并且在这几次作业的要求与结构化设计有些类似，那在规格化设计这个概念被明晰之前，我不妨假定它与结构化设计意义相同好了。
结构化程序设计（structured programming）是进行以模块功能和处理过程设计为主的详细设计的基本原则。结构化程序设计是过程式程序设计的一个子集，它对写入的程序使用逻辑结构，使得理解和修改更有效更容易。——百度百科。
结构化设计最早由荷兰计算机科学家迪杰斯特拉在1965年提出，是第一次软件危机的产物，也是软件发展的重要里程碑。
当时，随着计算机硬件的飞速发展和应用复杂度越来越高，原有的程序开发方式已经越来越不能满足需求（面向过程语言中的goto语句导致的面条式代码极大限制程序规模），第一次软件危机由此爆发。
结构化设计，就是当时被提出的其中一种解决方案（另一种方案是软件工程），其主要观点是采用自顶向下、逐步求精及模块化的程序设计方法；使用三种基本控制结构构造程序，任何程序都可由顺序、选择、循环三种基本控制结构构造。结构化设计通过“自顶向下、逐步细化、模块化”的指导思想将软件复杂度控制在一定范围内，从而从整体上降低了软件开发的复杂度。
对于结构化设计，我其实早已深有体会。在上学期的计算机组成原理中，自顶向下、逐步细化、模块化的思想可以说贯穿了整个实验课程，特别是到了后期，在繁杂而庞大的代码量需求背景下，需求分析文档几乎成了制胜的唯一法宝和最有效措施。之所以如此，我认为还是因为结构化设计将设计与实现分离，保证了设计的独立性和清晰性；而自顶向下、逐步细化、模块化的思想在保证了设计和思考的连贯性的同时，将整个设计化整为零，极大降低了设计难度和复杂度；另外，当整个设计被有机分割、化整为零之后，相对整个设计就有了一定的独立性，可以很方便地验证其正确性，或者在不影响正确性的基础上对其进行优化和修改。
（2）规格bug分析
第九次作业没有被报告规格bug。
第十次作业规格bug表格如下：
| bug序号 |
规格bug类别 |
对应方法代码行数 |
| 1 |
Effects不完整 |
29 |
| 2 |
Requires不完整 |
36 |
| 3 |
Effects内容为实现算法 |
31 |
这几个方法的规格bug跟代码量关系不大，问题主要是出在我的规格书写不是很规范。
第十一次作业规格bug表格如下：
| bug序号 |
规格bug类别 |
对应方法代码行数 |
| 1 |
Modifies不规范 |
16 |
| 2 |
Requires只记录变量名 |
10 |
| 3 |
Effects内容为实现算法 |
13 |
很明显，这几个bug同样跟代码量关系不大，同样是书写不规范导致……
（3）正如上一部分所展示的，我的方法代码量一般不会多于50行（包括规格在内），这样的代码量并不算多；但即使是15行左右的代码量的方法，依然出现了规格bug。我稍微分析了一下，发现这几个规格bug全都是因为书写不规范造成的，而不是因为代码量太大、方法实现的功能过多导致规格不完整造成。
（4）不好写法列举和改进
例1：
不好写法：
Requires：None
Effects：
改进：
Requires：None
Effects：\this.curTime=\this.curTime+1;
(\this.curTime-\this.lastTime==100)==>\this.lastTime=\this.curTime
例2：不好写法：
Requires:FileName,records,head,tail,taxis
Effects：将处理过程输出到文件
改进写法：
Requires：None
Effects：将处理过程输出到文件
例3：
不好写法：
Requires：当前点，目标地点
Effects：确保周围四点中，与当前点相连的点到目标地点的距离是真实有效的
改进写法：
Requires：cur!=null&&dst!=null
Effects:(\all i>=0&&i<4)==>(\this.validMap[cur.x*80+cur.y][cur.x*80+cur.y+\this.offeset[i]]&&\this.validMap[cur.x*80+cur.y+\this.offeset[i]][cur.x*80+cur.y]&&\this.validMap[dst.x*80+dst.y][dst.x*80+dst.y+\this.offeset[i]]&&\this.validMap[dst.x*80+dst.y+\this.offeset[i]][dst.x*80+dst.y])
例4：
不好写法：
Requires：当前点cur，判断方向i
Effects：判断方向i是否越界
改进写法：
Requires：cur!=null&&i>=0&&i<4
Effects：((i==0&&cur.x==0)||(cur.y==79&&i==1)||(i==2&&cur.x==79)||(cur.y==0&&i==3))==>\result=true;
!((i==0&&cur.x==0)||(cur.y==79&&i==1)||(i==2&&cur.x==79)||(cur.y==0&&i==3))==>\result=false;
例5：
不好写法：
Requires：None
Effects：1,更新地图
改进写法：
Requires：None
Effects：\this.validMap!=\old.validMap
（5）功能bug与规格bug聚集关系分析
第九次作业没有规格bug，被报告的两个bug属于测试的同学误报，一个bug是因为没有按照Readme规定的结束操作来结束程序，导致没有获得处理结果；另一个bug是因为没有注意Readme说明，因为没有在gui看到流量所以误以为我没有采用最短流量路径，实际上我没有采用gui提供的流量记录方法，而是自己另行记录，然后考虑到gui显示流量无用且费时，我就把它注释了。因为测试者是认识的同学，人也不错，我就没申诉，算是送分了……
第十次作业聚集关系表格如下：
| 方法名 |
规格bug数 |
功能bug数 |
| run(Clock.run) |
1 |
0 |
| setRoad |
0 |
1 |
| printProcess |
1 |
0 |
| getTheMap |
0 |
1 |
| refreshTheTaxi |
1 |
0 |
| closeEnrollWindow |
0 |
1 |
| getTheLight |
0 |
1 |
第十一次作业聚集关系表格如下：
| 方法名 |
规格bug数 |
功能bug数 |
| checkTheRoad |
1 |
0 |
| outOfRange |
1 |
0 |
| resetTheTaxiAndMap |
1 |
0 |
（6）体会
1、设计与实现分离，先设计后实现有利于降低整体难度，保证了设计思维和实现思路的清晰明了。
2、可靠的规格可以作为实现的蓝图和验证实现正确性的有效标准。
3、有些规格真的很难表达……