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,此次從新審視了一下,有的地方的確是個人錯,但有些地方我也不是很明白到底是誰的錯。this
我本身出錯的規格絕大部分是因爲粗枝大葉,好比將反斜槓 '\' 誤輸入爲 '/' ,忘記在構造函數中初始化某個成員變量致使RepOK存在問題,還有原本就沒有傳入參數的方法卻寫了REQUIRES以及只聲明瞭傳入參數的類型卻沒有加以限制等等。而在第十次做業中我將某一個成員變量的名字更換了,在方法規格中沒有及時改正過來,這天然就是個人問題,沒有首先去更正方法規格,而是首先寫代碼,再去改規格,違反了規格化設計的初衷。應該是首先設計好規格,再去撰寫代碼。spa
3、前置條件的很差寫法設計
1.沒有傳入參數時卻將REQUIRES寫成了須要轉成String的對象。orm
/**
* @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來,所以總有人只爲了分數考慮,拼了命的去扣對方的分。 好好寫規格吧。