OO第三次博客作業——規格

一、調研結果：

規格的歷史：

引自博文鏈接：http://blog.sina.com.cn/s/blog_473d5bba010001x9.html

傳統科學的特點是發現世界，而軟件的特點是構造世界。軟件的最底層就是0，1，兩個離散的值。

程序設計語言的三次分離使軟件技術產生了飛躍

1950年代，第一次分離，主程序和子程序的分離程序結構模型是樹狀模型，子程序可先于主程序編寫。通過使用庫函數來簡化編程，實現最初的代碼重用。產生基本的軟件開發過程：分析—設計—編碼—測試，使大型軟件系統的開發成為可能

1975—1980年代，第二次分離，規格說明（Spec）和體（body）的分離說明是類型定義和操作描述，體是操作的具體實現。（具體的例子就是C++,Java等面向對象語言的類說明與類實現的分離。）解決方案設計只關注說明，實現時引用或者設計體。體的更改、置換不影響規格說明，保證了可移植性。支持多機系統，但要同樣環境。此時產生了劃時代的面向對象技術。

1995—2000年代，第三次分離，對象使用和對象實現的分離

基于構件開發：標準化的軟件構件如同硬件IC，可插拔，使用者只用外特性，不計內部實現。Web Services：軟件就是服務。分布式，跨平臺，松耦合。

為什么規格很重要?

這三次分離中的第二次就是OO課程要求我們去做的，也是面向對象的精髓。在大型項目的開發中，單個項目不可能由一個人完成。多人協作共同完成任務就意味著不僅僅需要知道自己的代碼做了什么，還要知道別人的代碼做了什么。自己的代碼是自己寫出來的，具體怎么實現，使用了什么樣的數據結構，使用了什么樣的算法，當然知道自己的程序會對什么產生影響，需要什么樣的輸入 。假設有個人寫了一個方法，寫好了，實現了，于是，他交了這份代碼上去，你要使用這個方法，一看，這什么**玩意?；藭r間適應了代碼風格，知道要干嘛之后，寫自己的代碼進行測試，一測，bug，找了半天，發現是他和你的代碼對于某個變量能不能修改有沖突。浪費了很長時間，再交給上面。。惡行循環。于是，規格的誕生可以說是拯救了這個局面。拿到代碼，看前置條件，副作用，后置條件，就很清晰，永無bug（當然是不可能的）。

軟件工程行業代碼也越來越復雜，多人協作是必不可少，規格在我看來是代碼風格的調和劑，多人項目運作的潤滑油。

二、功能與規格BUG：

第9，10，11次，三次都沒有被報功能bug和規格bug（當然不是我程序寫得好，運氣運氣運氣）。

但是還是想說明一下，自己在規格上的一些不足和功能上的一些不足。

JSF上：

JSFbug原因

后置條件使用了較多的自然語言	因為部分方法在設計的時候沒有設計好，行數較長，使用布爾表達式過于繁雜，有點嫌麻煩
副作用有幾個函數存在問題，比如System.out缺失	這是我剛和同學交流時才發現的（捂臉）,剛開始的時候寫了，但是JSF檢查工具給我報wrong，我就一直沒寫emm

功能上：

功能bug原因

(前兩次作業都存在，第11次作業修復)接客時正好處于請求起點時，車輛無法正常運行	屬于狀態機中的邊界狀況，在計算下一個到達位置的時候，判斷的是下一個位置與起始點，忽略了邊界情況

三、列舉不好的寫法和改進：

前置1：不判斷是否對象是否存在

1 /** 2 * @REQUIRES: None; 3 * @MODIFIES: this.req; this.position; 4 * @EFFECTS: this.req == req; this.position == position; 5 */ 6 public Record(Request req, Point p) { 7 this.req = req; 8 this.position = p; 9 } 10 //正確寫法 11 /** 12 * @REQUIRES: req != null && p != null; 13 * @MODIFIES: this.req; this.position; 14 * @EFFECTS: this.req == req; this.position == position; 15 */ 16 public Record(Request req, Point p) { 17 this.req = req; 18 this.position = p; 19 }

前置2：不判斷值是否符合實際

/*** @REQUIRES: None;* @MODIFIES:this.index; * @EFFECTS: this.index == index;*/public TaxiCar(int index) { this.index = index;} //正確 /*** @REQUIRES: 0<=index<100;* @MODIFIES:this.index; * @EFFECTS: this.index == index;*/public TaxiCar(int index) { this.index = index;}

前置3：未使用布爾表達式

/*** @REQUIRES: index is in 0-100;* @MODIFIES:this.index; * @EFFECTS: this.index == index;*/public TaxiCar(int index) { this.index = index;} //正確 /*** @REQUIRES: 0<=index<100;* @MODIFIES:this.index; * @EFFECTS: this.index == index;*/public TaxiCar(int index) { this.index = index;}

前置4：遺漏

/*** @REQUIRES: req != null;* @MODIFIES: this.req; this.position;* @EFFECTS: this.req == req; this.position == position;*/public Record(Request req, Point p) {this.req = req;this.position = p;} //正確寫法 /*** @REQUIRES: req != null && p != null;* @MODIFIES: this.req; this.position;* @EFFECTS: this.req == req; this.position == position;*/public Record(Request req, Point p) {this.req = req;this.position = p;}

前置5：布爾表達式描述邏輯錯誤

/*** @REQUIRES: req != null && index >= 80 || index < 0;* @MODIFIES: this.req; this.index;* @EFFECTS: this.req == req; this.index; */public Record(Request req, int index) {this.req = req;this.index = index;} //正確寫法 /*** @REQUIRES: req != null && (index >= 80 || index < 0);* @MODIFIES: this.req; this.index;* @EFFECTS: this.req == req; this.index; */public Record(Request req, int index) {this.req = req;this.index = index;}

后置1：未使用布爾表達式

/*** @REQUIRES: req != null && p != null;* @MODIFIES: this.req; this.position;* @EFFECTS: this.req = req; this.position = position;*/public Record(Request req, Point p) {this.req = req;this.position = p;} //正確 /*** @REQUIRES: req != null && p != null;* @MODIFIES: this.req; this.position;* @EFFECTS: this.req == req; this.position == position;*/public Record(Request req, Point p) {this.req = req;this.position = p;}

后置2：使用自然語言

/*** @REQUIRES: req != null;* @MODIFIES: None;* @EFFECTS: 判斷起始點與目標點是否為同一個點*/public boolean samedest(Request req) {if(req.getSrc().equals(req.getDst())) {return true;}else return false;} //正確 /*** @REQUIRES: req != null;* @MODIFIES: None;* @EFFECTS: (req.getSrc() == req.getDst()) ==> \result == true;* (req.getSrc() != req.getDst()) ==> \result == false;*/public boolean samedest(Request req) {if(req.getSrc().equals(req.getDst())) {return true;}else return false;}

后置3：未處理異常

public static int min (int[ ] a) throws NullPointerException, EmptyException /**@ EFFECTS: \result == \min a; */ //正確 public static int min (int[ ] a) throws NullPointerException, EmptyException /**@ EFFECTS: normal_behavior\result == \min a; (a == null) ==> exceptional_behavior (NullPointerException); (a.length == 0) ==> exceptional_behavior (EmptyException); */

后置4：描述不準確

/*** @REQUIRES : None; * @MODIFIES : this.AskList;* @EFFECTS : AskList.contains(ask);*/public synchronized void addAsk(Ask ask){AskList.add(ask);} //修改為 /*** @REQUIRES : None; * @MODIFIES : this.AskList;* @EFFECTS : AskList.contains(ask) && AskList.size == \old(AskList).size + 1;*/public synchronized void addAsk(Ask ask){AskList.add(ask);}

后置5：多線程規格

/*** @REQUIRES : None; * @MODIFIES : this.AskList;* @EFFECTS : AskList.contains(ask) && AskList.size == \old(AskList).size + 1;*/public synchronized void addAsk(Ask ask){AskList.add(ask);} //正確 /*** @REQUIRES : None; * @MODIFIES : this.AskList;* @EFFECTS : AskList.contains(ask) && AskList.size == \old(AskList).size + 1;* @THREAD_EFFECTS : \locked(Asklist);*/public synchronized void addAsk(Ask ask){AskList.add(ask);}

四、感想與體會：

首先說一下自己在寫規格的體會。即便是知道規格的重要性，在第一次寫規格的時候還是抗拒的，因為尤其是后置條件，全部寫成布爾表達式是真的很難受。在OO實驗課上提供的代碼相對來說都比較簡單，所以寫成布爾表達式相對來說比較容易，使用布爾表達式來寫具體實現也比較容易，但是自己寫的代碼有些結構相對來說比較復雜，除了一些比較簡單的轉換函數，JSF寫的感覺很規范，其他都或多或少存在著問題?；蛘呤菍嵲谙氩坏饺绾斡貌紶柋磉_式表示偷摸摸用了自然語言啊，或者就像自己上面列的部分毛病啊，或者是自己對JSF原則上的一些忽略啊，等等。雖然這幾次互測我沒有被報bug，但是看周圍同學被報的BUG，也知道自己的JSF存在很大的問題。

我在扣別人JSF時候，還是比較松的，第一次報了兩個問題比較嚴重的，后面兩次就只報了一個方法遺漏了JSF的bug。我會隨機挑選幾個函數的JSF進行查看，看能否get到這個函數的意思，我覺得能夠讓很多人快速理解代碼的作用而不是每一行看代碼找方法的作用就是JSF的精華。

還是挺開心的，OO的代碼作業終于也是結束了，三次作業在設計上雖然不是十分的滿意，但還是完成了基本的任務。雖然有一個邊界條件直到最后一次作業才解決（其實我在第10次作業就發現了這個bug，原因是提交之前想測試一下能不能編譯通過，結果出現了bug，復現了幾遍都失敗了，但是已經沒有了時間，僅僅是初步判定了bug的可能位置，后來確實是我想的地方出了問題）。

最后，我記得第九次作業測試我的老哥在最后一個公測點，寫了，和諧六系，OO不易，與君共勉，當時很感動。然后第10次和第11次作業都遇到了好人（或者是摸魚測試者）。怎么說呢，雖然感謝老哥給我送分，但是感覺自己的程序的bug也被隱藏了emmmm。其實自己在課下有時候也能聽到一些同學對OO互測的抱怨，有佛系測試者，有對結果很不滿，有想擊潰對面心理防線的（害怕&&鄙視）,有惡意扣分獲利的，怎么說呢，面向運氣是一方面，課程的精髓有時候被掩蓋了。引入公測是好事，雖然我是公測的受害者（為什么呢，因為第三次作業，格式上出了錯誤導致公測全WA，被判了無效，如果是后幾次的測試模式，我覺得也就是一個BUG的事，不至于無效。也不是開脫，畢竟是自己不小心，甚至第四次作業臨交前，對了十幾遍輸出害怕再無效。要說覺得很難受就是第四次作業的時候有同學甚至輸出了調試信息，都沒有判無效，覺得很不平emmmm）。

這句話真的很好，和諧六系，OO不易，與君共勉。一起走向未來，Code the world! Debug the world！

?

轉載于:https://www.cnblogs.com/xiaoxin83121/p/9101785.html

總結

以上是生活随笔為你收集整理的OO第三次博客作业——规格的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。