規格化設計的大致發展歷史

---

　　1960年代末—1970年代初，出現軟件危機：對軟件系統的大量需求與軟件的研制周期長，可靠性差，維護困難的現實情況形成矛盾。于是人們希望編寫出的程序結構清晰、易閱讀、易修改、易驗證，即得到好結構的程序。1968年，北大西洋公約組織召開第一次軟件工程會議，分析了危機的局面，研究了問題的根源，第一次提出了用工程學的辦法解決軟件研制和生產的問題。

　　與此同時，許多學者也從結構化程序設計、程序正確性驗證等方面展開了規格化設計的研究。Dijkstra 提出了“GOTO是有害的”，希望通過程序的靜態結構的良好性保證程序的動態運行的正確性。Hoare提出了基于“前置后置條件”的接口規格方法。D.Gries綜合了以謂詞演算為基礎的證明系統，首次把程序設計從經驗、技術升華為科學。

　　規格化設計帶來了許多好處。它使得軟件開發過程變得更成熟，能更好地保證軟件質量。而且使得團隊協作開發更加可行，分工更為明確。所以人們非常重視。

規格bug

---

?

?	Bug數	代碼長度
Requires不完整	2	22(write)
?	?	1(addMap)
Effects不完整	1	3（SafeFile)

產生原因：

　　Requires不完整的兩個錯誤原因：其一是在寫被改變的變量的時候，類變量一多，混雜在臨時變量之間就容易被忘記。第二是對參數要求的時候容易想不清楚。比如說存地圖時，在輸入處理環節就已經保證不會傳入非法的參數，所以在存的這一步我沒有對傳入變量進行要求，但事實上應該要求的。我們不能提前預知到前方已經做過處理了，因此要施加我們的要求，好讓前方的處理按照我們的規格進行處理。

　　Effects不完整是因為忘了寫拋出異常。通過這幾次互策 互測，及OO上機代碼，我發現大家都有著很好的異常處理，不像我想到了就給方法加個try catch。他們的異常處理很方便定位錯誤位置，且邏輯性很好，學到了。

前置條件不好的寫法

---

公開處刑1　

public void runLess(Point from, Point to){/** @REQUIRES: 起點from，終點to……*/……from.method();to.method();…… }

　　用自然語言來寫前置條件，為了表達同樣的意思需要更多筆墨。此處的Requires需對from,to進行約束，因為函數體內部運用了對象的方法。所以寫成下面這樣更簡潔更明確。

/** @REQUIRES: from != null && to != null;

公開處刑2

public synchronized boolean judge(Passenger p) {/**@REQUIRES: p!=null && 0<=p.getCurrentX<80 && 0<=p.getCurrentY<80
　　　　　　　　&& 0<=p.getDestinationX<80 && 0<=p.getDestinationY<80;* @THREAD_EFFECTS: \locked();*/ }

　　這和我之前想不清楚的地方一樣：我要對這個對象約束多深？比如：如果傳入參數是一個ArrayList，我是否在保證其不為null的情況下還要保證內部元素不為null；如果是ArrayList<Taxi>的話是否還要檢查元素為Taxi類型，是否還要檢查Taxi的內部參數滿足要求。現在我覺得不需要約束這么多，應交給別的地方來保證這些。例如在Passenger的構造方法中對乘客的坐標進行約束。所以此處寫?p != null;?就夠了。

　　沒法寫5個案例，因為我的前置條件不是在約束數字范圍就是在限制不能為空。

后置條件不好的寫法

---

?公開處刑1

public synchronized boolean isSame(Passenger p) {/**@REQUIRES: requestList != null && p != null;* @EFFECTS :* \result == requestList.contains(p);* @THREAD_EFFECTS: \locked();*/遍歷requestList并根據Passenger的實例變量來判斷是否同質}

　　這個寫的不好的地方在于同質的話，就存在一個和p在時間、當前坐標、將要去的地方完全一樣的對象，但這個對象和我傳入的對象并不是一個對象，所以這種寫法不好。但感覺很難改進，只能自己寫一個contains的方法來保證這個Effects。

公開處刑2

public static void main(String[] args) {/** @EFFECTS: * 啟動xx線程，啟動xx線程，啟動xx線程*/

　　Effects應該描述方法結束后系統的變化。在main方法開始前，這些線程還未出生，main結束的時候又一波帶走了他們，所以main的Effects內只需寫對類變量的改變就行了。

　　*如果一個方法調用了很多別的方法，我要對這個方法的效果描述到多深是一個困擾著我的問題。

?按照作業分析被報的功能bug與規格bug在方法上的聚集關系

---

　　沒有什么關系。

　　因為不是先寫規格再寫功能的。

　　規格出問題的功能都沒問題。反之亦然。

歸納自己在設計規格和撰寫規格的基本思路和體會

---

　　基本思路就是關注外部環境，關注方法結束后的思想吧。

?　　體會是規格蠻重要的，但是現在還不太能體會到，反而不如讀代碼快。

　　最不能理解的是測試者保證的地方又允許測試者不保證來測試，還不如不說。該保證的地方不保證得到錯誤情況難道不是當然的嗎？

其他

---

　　這三次體驗很不好，很影響我心情，遇到了好的測試者、被測試者，但所有的好心情也敵不過一次壞心情。尤其是最后一次吧，終于見到了OO課程被大家詬病的問題了。但他人惡意來面對我，我如果還將惡意傳遞出去，豈不是也成了惡人了嗎。有什么必要呢，分數拿走便是了，我應該關注如何把代碼寫的更嚴密，挑不出瑕疵，關掉網站頁面。

轉載于:https://www.cnblogs.com/AAO972/p/9105226.html

總結

以上是生活随笔為你收集整理的OO9-11总结的全部內容，希望文章能夠幫你解決所遇到的問題。

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