OO第三次总结

1、规格化设计的历史

       最开始的软件设计都是比较简单的，然而随着计算机性能的不断提高，软件也变得愈来愈复杂，因为缺乏规格化设计，一旦参与撰写代码的人数过多，因为每一个人的思路都不相同，所以撰写出的代码形式、风格各不相同，对代码的编写、维护形成了很大的困难。因而在19世纪六十年代末到70年代初，出现了软件危机，由于软件规模变大，复杂程度变高，缺乏了规格的约束，可靠性天然就变差了。后来人们逐渐产生了软件规格化的思想，也产生了一门新的工程学科——软件工程。在面向对象的设计中，类声明和类实现是分离的（如C++和Java），于是他们的规格多为抽象的规格，不去考虑如何去实现，只须要考虑要去实现什么。拥有了规格化设计以后，软件的可读性、可移植性以及可维护性都大大提升了。

2、规格BUG分析

 

做业	BUG数	代码行数
9	2	6
10	1	18
11	5	28，29，1，10

　　本身在这三次做业中也是被报了不少的BUG，可是有一些BUG我是没法认同的，不知道是我本身没有理解JSF的规格写法，仍是对方没有理解好，至少我可以经过JSF Tools的检测，说明应该是不会出现RUQIRES和EFFECTS不为布尔表达式的状况，可是我因为疏忽，觉得被报了JSF确定就是个人问题，致使没有仔细去查看对方报的BUG，此次从新审视了一下，有的地方的确是个人错，但有些地方我也不是很明白到底是谁的错。

　　我本身出错的规格绝大部分是因为粗枝大叶，好比将反斜杠 '\' 误输入为 '/' ，忘记在构造函数中初始化某个成员变量致使RepOK存在问题，还有原本就没有传入参数的方法却写了REQUIRES以及只声明了传入参数的类型却没有加以限制等等。而在第十次做业中我将某一个成员变量的名字更换了，在方法规格中没有及时改正过来，这天然就是个人问题，没有首先去更正方法规格，而是首先写代码，再去改规格，违反了规格化设计的初衷。应该是首先设计好规格，再去撰写代码。

3、前置条件的很差写法

　　1.没有传入参数时却将REQUIRES写成了须要转成String的对象。

/**
 * @REQUIRES: \this;
 */
public String toString() {
    ...
}

改成

/**
 * @REQUIRES: None;
 */
public String toString() {
    ...
}

　2.没有对传入的数据进行约束

/**
 * @REQUIRES: None;
 */
void SortDistance(int start,int end,int [][] requesttaxi){
    ...
}

改成

/**
 * @REQUIRES: \all int start,end; requesttaxi!=null && 0<=start<end<requesttaxi.length;;

 */
void SortDistance(int start,int end,int [][] requesttaxi){
    ...
}
    3.对于传入的对象没有判断是否为空
/**

 * @REQUIRES: \all Point dstpoint;
 */
Point calpath(Point dstpoint){
    ...
}
改成

/**
 * @REQUIRES: \all Point dstpoint;dstpoint !=null;

 */
Point calpath(Point dstpoint){
    ...
}
4、后置条件的很差写法
1.可使用Java的一些方法简化

/**
 * @EFFECTS: \all if request already exists in requests,return true,else return false;
 */
static boolean CheckSame(Request request){
     for(int i=0;i<RequestNum;i++){
         if(request.roundtime==requests[i].roundtime && request.src.equals(requests[i].src) && request.dst.equals(requests[i].dst)){
             return true;
         }
     }
     return false;
 }
改成

/**
 * @EFFECTS: \return==requests.contians(request);
 */
static boolean CheckSame(Request request){
     for(int i=0;i<RequestNum;i++){
         if(request.roundtime==requests[i].roundtime && request.src.equals(requests[i].src) && request.dst.equals(requests[i].dst)){
             return true;
         }
     }
     return false;
 }

2.错误的状况是直接进行了退出，而不是抛出异常。

/**
 * @REQUIRES: (\all int x,y,up,left,down,right; 0<=x,y<=79; 0<=up,left,down,right<=1);
 * @MODIFIES: None;
 * @EFFECTS: \all Return the direction by possible directions,1 for up ,2 for right, 3 for down, 4 for left, if there is no directions to run, exit the program;
 */
int EnsureDirection(int x, int y, int up, int left, int down, int right){
   ...
}
改成

/**
 * @REQUIRES: (\all int x,y,up,left,down,right; 0<=x,y<=79; 0<=up,left,down,right<=1);
 * @MODIFIES: None;
 * @EFFECTS: \all Return the direction by possible directions,1 for up ,2 for right, 3 for down, 4 for left;
　　　　　　\all if there is no direction to go return 0 and throw a exception;
 */
int EnsureDirection(int x, int y, int up, int left, int down, int right){
    ...
}

3.天然语言过长，致使阅读困难。

/**
 * @REQUIRES: (0<=number<=29);
 * @MODIFIES: this.curnum;
 * @EFFECTS:  \all if number is correct and current position has a next element, return it in a String and move the current position to the next position, else return a message that there is something wrong in a String;
 */
static public String next(int number) {
    ...
}
改成
/**

 * @REQUIRES: (0<=number<=29);
 * @MODIFIES: this.curnum;
 * @EFFECTS:  \all normal_behavior; \return==Iterator.hasnext()?Iterator.next:"no next";
 \all abnormal_behaiover; \return=="Wrong TaxiNumber";
*/

static public String next(int number) {
    ...
}

5、方法BUG与规格BUG
　　几回做业中，方法BUG和规格BUG的关系:

做业	方法BUG	方法BUG的方法名	规格BUG	方法BUG和规格BUG相关
9	4	Taxi.run()，PassengerRequest.run()	2	0
10	0	null	1	0
11	4	Request.toString(), SpecialTaxi.run(),	5	0

　　在这几回做业中，存在着方法BUG，这些方法的BUG有的的确是因为规格没有写清楚。由于一个出租车的run()方法写的过长，致使他的规格只能用一句话简单的去归纳，若是拆分红大量的短方法，效果可能就会好不少，也不会出现和指导书冲突的地方。
　　然而，在互测中，大多数人都是不会去看你的规格和方法是否一致了，他们只是想着去报对方的BUG来给本身加分，所以所报的方法BUG和规格BUG几乎都没有什么关系。
6、体会和总结
　　这几回OO做业下来，我确实体会到了规格的重要性。规格真的很重要，若是能将规格写得详细一点，本身在检查时也可以很容易发现本身存在的问题。同时首先写好了规格也容易让本身更加轻松的撰写代码，规格在必定程度上体现了本身的思路，顺着思路来，更加容易读懂本身的程序，在后续的补充更改中也变得更加简单。　　规格很重要，我是个初学者，写很差规格，毕竟之前连注释都懒得写。我相信不少同窗也是第一次写规格，都是初学者。我自认为规格这种东西，内容远远大于格式，可是我也看到说有人被报了十几个JSF错误，若是都是逻辑上的问题，那天然是他的错，但若是全都是由于某些格式的问题，那我认为这就是那个测试者的问题，完彻底全只为本身的加分考虑。这也是这里规格测试最大的弊端，每一个人的对于规格的想法都不一样，其实只要想去找，每一个人都能被找出一大堆BUG来，所以总有人只为了分数考虑，拼了命的去扣对方的分。　　好好写规格吧。