规格化设计-----JSF(第三次博客作业)

从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.代码的规格很有必要，如果不写规格，其他程序员很难理解方法的目的和相关要求，在团队合作中这显得尤为重要。可以说规格相当于第二自然语言，便于沟通。