第三次博客做業

一． 規格設計的發展歷程：

在1960年代末至1970年代初期，出現了一次軟件危機：一方面須要大量的軟件系統，如操做系統、數據庫管理系統；另外一方面，軟件研製週期長，可靠性差，維護困難。人們但願編寫出的程序結構清晰、易閱讀、易修改、易驗證，即產生良好結構的程序。60年代中期，大容量、高速度的計算機出現，隨之出現的是代碼量急劇提高，複雜度急劇增加、程序可靠性的重要性突出的問題。結果化程序設計隨之提出，它要求程序設計時以模塊爲單位，每一個模塊專職本身的工做，而要在模塊間交流，在開發者和用戶，開發者和開發者之間交流，就只須要相應接口便可。到了80年代，「軟件工程」的概念第一次被提出，計算機的速度和容量大大提升，程序的複雜度也急劇增加，人們開始在程序設計時以模塊爲單位，各部分有了本身各自獨立的工做，開始出現規格化抽象。好比說C++和JAVA的類說明和類實現出現了分離。以後，隨着計算機軟件規模日漸龐大，結構化程序設計方法開始沒法知足用戶的需求，面向對象程序設計（OOP）應運而生。面向對象程序設計是一場重大的革命，提升了開發人員的效率，有效地控制了軟件開發的複雜度，提升了軟件的可維護性和可拓展性。（本部分來自於互聯網和適當修訂）

規格化的設計大大提升了程序的規範性和規模化，提升了程序可讀性，並下降了維護難度，因此獲得了普遍的重視。

二． 做業中出現的規格bug：

第九次做業無bug。

第十次做業中由於是對第九次的補充。。。致使一些地方忘了補充repok方法和其餘規格而被報了bug。。。

第十一次仍是落下了一個類沒寫repok。。。

這種bug。。。不分析也罷。。。

三． 分析BUG產生的緣由：

不想寫規格，全部的規格都是最後往上加，因此東丟西落。（胡亂分析）

四． 寫法改進：

1. 前置條件：

第一類（無限制）：

/**

         * 增刪流量

         * @REQUIRES: None;

         * @MODIFIES: guigv.flowmap;

         * @EFFECTS:

         * increase and reduce the flow by time interval;

         */

改成* @REQUIRES: 0<=xbegin, ybegin, xend, yend<80;

 

第二類（未檢查repok）:

/**

  * 獲取乘客請求

  * @REQUIRES: r1!=null;

  * @MODIFIES: this.request,this.sign,this.state;

  * @EFFECTS:

  * request == r1;

  * sign == 1;

  * state == 3;

  * r1.tapoint ="("+Integer.toString(this.x)+","+Integer.toString(this.y)+")";

         */

                     改成：* @REQUIRES: r1!=null && r1.repok()!=false;

 

　　2.影響：

/**

       * 讀地圖

       * @REQUIRES: None;

       * @EFFECTS:

       * initialize map

*/

加上* @MODIFIES: this.map;

　　3.後置：

基本都上的天然語言，沒得改。

五． 心得體會：

好人有好報。善惡終有報。人在作，天在看。我就不信抓着一個crash換花樣報三個點，沒檢查map格式扣四個bug，測試文件名裏面加空格的人，能是什麼好人。

就這些，沒了。