从20世纪60年代开始，就存在着许多不同的形式规格说明语言和软件开发方法。在形式规格说明领域一些最主要的发展过程列举如下：
1969－1972 C.A.R Hoare撰写了"计算机编程的公理基础（An Axiomatic Basis for Computer Programming）"和"数据表示的正确性证明"两篇开创性的论文，并提出了规格说明的概念。
1974－1975 B.Liskow/S.N. Zilles和J. Guttag引入了"抽象数据类型"的概念。
1976 E.W. Dijkstra定义了"最弱前置条件"的概念
1977 R.Burstall和J.Goguen提出了第一个代数规格说明语言：Clear
1988 Standford的SRI开发了代数规格说明语言OBJ3
1980-1986 C.Jones定义了VDM语言，也就是维也纳开发方法。
1985－1992 牛津大学的程序研究小组开发了Z规格说明语言。与此同时BP研究室开发了称之为B方法的面向模型的规格说明语言。
1985－1993 在MIT和Digital SRC开发了代数规格说明语言Larch
从1991年开始，面向对象的形式规格说明语言开始发展，例如，Object-Z, VDM++, CafeOBJ等语言。
1996－2000年 在欧洲CoFI（Common Framework Initiative）项目资助下开发"统一"代数规格说明语言CASL(Common Algebraic Specification Language)
上述规格说明语言可以分为两大类：
l 基于代数和公理方法（Clear, OBJ, Larch, CafeOBJ）
l 基于模型的方法（VDM, Z, B, Object-Z）
来源：https://blog.csdn.net/jnucstan/article/details/1724259
至于为什么得到了人们的重视：我觉的是因为写出来的代码要有广泛的使用价值才是好代码，而广泛的适用性则要求必须要有相对统一的标准格式，这样有利于程序员之间沟通交流。
第九次作业的代码规格使用了自然语言来实现，没有说明性，就不列出来了。
第十次的代码有两个格式错误，
1.
public Mypoint(int x, int y) {
/** * @REQUIRES:None; * @MODIFIES:None; * @EFFECTS:实例化一个对象并设置相应参数 */ super(x,y); this.x=x; this.y=y; this.link=new char[4]; link[0]='f'; //up link[1]='f'; //right link[2]='f'; //down link[3]='f'; //left p = new Vector<Point>(); }对于类的初始化方法中MODIFIES应该为this,而我写了None;
2.
public void setcredit(int credit) {
/** * @REQUIRES:None; * @MODIFIES:this.credit; * @EFFECTS:this.credit==credit; */ this.credit=credit; }该方法的前置条件REQUIRES不完整，credit应该约束一个范围。
功能bug与这两个格式bug无关。
功能bug:
字符串转数字crash,没有捕捉。
出租车会走回头路，也就是流量设置有问题，或者道路选择有问题。
派单时，对于两个相同起点的乘车请求，虽然出租车被派单，但有一个不会被接单。
在非十字路口设置红绿灯，没做报错处理。（至于要不要做报错处理，我一头雾水，助教，issues, 一天变一次，然后自己没勤刷聊天记录，信息更新不及时）
测试者在地图文件里多添加几个空格，被提供的GUI类认定为非法地图文件并退出
第十一次作业：
规格bug
我将GUI提供的一个类单独成一个类文件，然后没写规格，报了两个规格bug.
一个类没写overview, 一个类的repOK写错了。
功能bug:
不是最短路径
路径字符串限制了长度没在readme中说明
红绿灯只能加在十字路口
功能bug与规格bug之间没有明显的联系，方法多为获取类的属性或者设置类的属性或者简单的运算，因此也没有什么明显的改进。
撰写规格的体会：
1.要懂得均衡方法的长度，太长了，规格不太好写，就像老师说的，多余50行的方法很难写出规格。而我的方法就没掌握好长度，零散的方法比较多，都是set, get方法，要么就是方法很长，比如有的run方法超过了100行，根本没法规格。
2.代码的规格很有必要，如果不写规格，其他程序员很难理解方法的目的和相关要求，在团队合作中这显得尤为重要。可以说规格相当于第二自然语言，便于沟通。