OO第三次总结

Posted 2020-11-09 yukinoshitayukino

一、规格化设计的历史

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

二、规格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以及只声明了传入参数的类型却没有加以限制等等。而在第十次作业中我将某一个成员变量的名字更换了，在方法规格中没有及时改正过来，这自然就是我的问题，没有首先去更正方法规格，而是首先写代码，再去改规格，违反了规格化设计的初衷。应该是首先设计好规格，再去撰写代码。

三、前置条件的不好写法

　　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){
    ...
}
四、后置条件的不好写法
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) {
    ...
}

五、方法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几乎都没有什么关系。
六、体会和总结
　　这几次OO作业下来，我确实体会到了规格的重要性。规格真的很重要，如果能将规格写得详细一点，自己在检查时也能够很容易发现自己存在的问题。同时首先写好了规格也容易让自己更加轻松的撰写代码，规格在一定程度上体现了自己的思路，顺着思路来，更加容易读懂自己的程序，在后续的补充更改中也变得更加简单。
　　规格很重要，我是个初学者，写不好规格，毕竟以前连注释都懒得写。我相信很多同学也是第一次写规格，都是初学者。我自认为规格这种东西，内容远远大于格式，但是我也看到说有人被报了十几个JSF错误，如果都是逻辑上的问题，那自然是他的错，但如果全都是因为某些格式的问题，那我认为这就是那个测试者的问题，完完全全只为自己的加分考虑。这也是这里规格测试最大的弊端，每个人的对于规格的想法都不同，其实只要想去找，每个人都能被找出一大堆BUG来，因此总有人只为了分数考虑，拼了命的去扣对方的分。
　　好好写规格吧。