oo第12次作业

一、规格化设计发展历史

在上世纪60年代，由于程序猿们难以忍受超级难懂的机器语言和稍微好懂一点点的汇编语言，便发明了结构化的程序语言，使得程序猿们能愉快地编写复杂程度适中的程序。但是需求是在不断增长的，渐渐地程序复杂度上涨得超过了人们的想象，使用结构化的程序语言也会无法控制。这时，面向对象的程序设计方法便应运而生。但是人和人写代码的习惯是不一样的，干脆用一套规格化的框架来写出代码大致功能，让不同的人都能看的舒服。正是如此，程序规格化设计越来越被人们重视，其对于代码编写的规范能够让程序变得更加易懂，能让使用者更加轻松简单的学会如何正确使用这段程序。此外，通过规格的抽象和总结，使用者能够直接使用这段程序而免去浪费大量时间来看懂代码的痛苦过程。更重要的是，代码的维护变得更加简单。其一，按我自身的经历，程序中隐藏的逻辑错误比如括号位置写错或者其他有关优先级的bug，在找到相应错误方法后能够非常轻松的通过抽象出来的规格判断代码具体错误位置。其二，在真正的做项目开发时，规格化设计能够方便整个团队的开发，因其能够统一规范每个人的编写方式，能使分工更加细致，使团队之间更加协调。

二、规格bug

三、规格bug分析

对于EFFCTS里面的错误我认为主要的原因是自己对于jsf的书写规范还是理解的不够深，所以使得虽然自己知道逻辑是怎样的但是表达出来不符合规范，所以造成了逻辑的错误以及书写上面的不规范。而对于MODIFIES和REQUIRES上面的问题，主要是因为自己写的有些着急，所以一些变量没有注意到，因为程序和jsf是分开写的，所以一旦没有看仔细，就会出现漏过一些变量的情况

四、不好写的写法和改进

1.

/**
 * @REQUIRES: None
 * @MODIFIES: None
 * @EFFECTS: (\all int i; 0<=i<=r.taxis.size())==>\result.contains(MIN(r.taxis.get(i).pathlength))
 */

　没有考虑输入指向空的情况，因此这部分JSF的前置条件写的不完整。

　改进如下

/**
 * @REQUIRES: r!=null
 * @MODIFIES: None
 * @EFFECTS: (\all int i; 0<=i<r.taxis.size) && (\exists int j; 0<=j<r.taxis.size && r.taxis[j].credit>=r.taxis[i])
 *　==>\result.contains(j)==true
 */

2.

/**

* @REQUIRES: x!=null;

* @MODIFIES: queue;

* @EFFECTS:

*queue.contains(x);

这个函数是把请求x加入到队列中，在这里还需要对请求的类别进行判断，即只把乘客请求加入到队列中，不用管开关路请求

改进如下：

/**

* @REQUIRES: (x!=null)&&(x.gettype()==0);

* @MODIFIES: queue;

* @EFFECTS:

*queue.contains(x);

3.

/**@REQUIRES:None
* @MODIFIES:None
*@EFFECTS:获得start_x的值，起点的x坐标
*/

运用自然语言

改进如下：

/**@REQUIRES:None
* @MODIFIES:None
*@EFFECTS:\result==>start_x
*/

4、

　/**@REQUIRES:

　*@MODIFIES: 
　*@EFFECTS:q!=null

　*@THREAD_REQUIRES:
　*@THREAD_EFFECTS:
　*/

直接使用源代码

改进如下：

　      　/**@REQUIRES: 
　　　     *@MODIFIES: 
　　　 　*@EFFECTS:(q!=null)==>\result=true

　　　　　　　　　　  otherwise==>\result=false;

　　　 　*@THREAD_REQUIRES:
　　　 　*@THREAD_EFFECTS:
　　　 　*/

5、

　/** @REQUIRES: r范围为0-300

*@MODIFIES: this
*@EFFECTS:  this!=null

*@THREAD_REQUIRES:
*@THREAD_EFFECTS:
*/

前置条件必须为布尔表达式

改进如下：

/** @REQUIRES: 0<=r<300
*@MODIFIES: this
*@EFFECTS: this!=null
*@THREAD_REQUIRES:
*@THREAD_EFFECTS:
*/

　

五、分析被报的功能bug与规格bug在方法上的聚集关系

感觉主要问题在于对jsf的了解不够透彻，指导书给的例子太少了，然后自己遇到一些情况就会不知道标准的正确结果。所以写的时候心里也没有底，所以才会有这些规格bug

六、心得体会

感觉上自己对jsf还是有些不重视，因为没有办法知道jsf的正确和错误吧，要是写的时候能有办法知道自己写的正确或者错误（类似java里的书写错误直接提醒？），可能就会好一点，感觉自己还是对指导书的理解不够透彻吧。不管怎么说还是自己的理解有问题给了别人可乘之机，被扣得分数也都心服口服，不过也算知道了jsf的作用和重要性吧，希望以后能写的更好