第九到十一次做業總結

1、規格化設計的大體發展歷史

這裏說到的規格化設計就是將程序進行結構化分析的表現方式。結構化分析在1980年代起開始廣爲使用。結構化分析包括將系統概念轉換爲用數據及控制的來表示。數據字典用來描述數據和指令的流動,而用程序規格來描述交易或數據轉換的相關信息。結構化分析是許多結構化方法中的一部分。「結構化分析是系統分析、設計及編程技術的組合,其目的是爲了處理1960至1980年軟件開發所遇到的問題,也沒有將需求及設計文件化的技術。可是隨着系統愈來愈大也更加複雜,信息系統的發展也變得愈來愈困難。」爲了方便管理大而複雜的系統,慢慢演進了更多的結構化方法。80年代後,面向對象的設計興起,相比於單純的結構化設計,面向對象的設計從審視問題的角度上就有了差別,程序發生了從圍繞「行爲」執行到圍繞「客體」執行的變化,隨之而來的,就是封裝性地提升,可重用性的提升,能夠說,面向對象進一步實現告終構化設計,是結構化設計更進一步的實現。算法

規格化設計的重要性就在於,可讓軟件設計者和真正寫程序的人員之間進行有效的溝通。由於用天然語言進行交流老是會發生歧義,致使交流和溝通不便。只有雙方維持着同一套系統的,高效的語言,才能真正發揮規格化設計的做用。編程

 

2、規格bug

modifies不完整 方法代碼行數:150
不符合JSF規範 方法代碼行數:1
overview是否明確抽象 類代碼行數:162

3、規格bug的產生緣由

一、overview的問題是由於忘記撰寫函數

二、不符合JSF規範是由於在遍歷集合元素時,誤把分號寫做冒號學習

三、modifies不完整是由於成員變量沒有加this.this

4、分別列舉5個前置條件和5個後置條件的很差寫法,並給出改進寫法

REQUIRES:spa

(1)*@REQUIRES:String類型的地圖路徑,System.in。改:*@REQUIRES:path!=null;線程

(2)在方法的傳入參數有限制的時候,*@REQUIRES:None;改:**!=null;設計

(3)傳入參數涉及座標時:int sx, int sy, int dx, int dy,*@REQUIRES:None; 改:@REQUIRES: 0<=sx<80&&0<=sy<80&&0<=dx<80&&0<=dy<80對象

(4)get類的方法中,待返回的值不加以約束,*@REQUIRES:None;改:this.*!=null;開發

(5)構造方法中,對傳入的參數不進行約束,*@REQUIRES:None;改:**!=null;

EFFECTS:

(1)天然語言撰寫。*@EFFECTS:查詢是否重複;改:*@EFFECTS:n.exists==>(\result==true);!n.exists==>(\result==false);

(2)對異常的處理不明確。(Unknown situation)==>exceptional_behavior(Exception);改:(I/O error occurs)==>exceptional_behavior (IOException);

(3)涉及算法。(graph[sx*80+sy][dx*80+dy]==1)?true:false;改:

* @EFFECTS: (road.open)==>(\result==true);

* (road.close)==>(\result==false);

改:

(4)使用synchronized關鍵字沒有進行線程約束。改:

* @THREAD_REQUIRES: \locked(this);

* @THREAD_EFFECTS: \locked(this);

(5)出現恆等式:

* @EFFECTS: requestQueue == requestQueue;

* cars == cars;

* taxiGUI == taxiGUI;

改:

* @EFFECTS:this.requestQueue == requestQueue;

* this.cars == cars;

* this.taxiGUI == taxiGUI;

5、功能bug與規格bug在方法上的彙集關係

方法名 功能bug 規格bug
pathlength 1個(搜索算法效率低) 1個

TargetChange

1個(紅綠燈時間差別) 1個
noTargetChange 1個(流量最小的控制) 1個

在上述三個較爲重要的方法中,實現的功能較多,所以而產生的bug會比較集中,也正由於實現功能較多,會致使規格的撰寫較爲冗長,也更容易出現錯誤。

6、設計規格和撰寫規格的基本思路和體會

在撰寫規格時,我關注的是這個方法究竟改變了什麼,以modifies爲綱,不去在意具體的算法,而是在這個方法實現以後,個人程序應該進行到什麼程度,改變了什麼,返回值是什麼。在撰寫過程當中,有些方法的篇幅較長,改變的東西較多,理清全部的內容須要較長的時間並且寫出來的規格也較多較雜。惟一能解決的辦法就是,在這個方法中繼續拆分出更小的函數單元,分別撰寫規格。由於,這幾回的做業都是完成一個工程,咱們須要從一磚一瓦開始搭建,當有了一個詳細的設計圖(規格)以後,整個建築的搭建就會容易不少。在之後的學習中就要學會先進行規格的設計,明確每一個類,每一個方法的做用,使這個過程再也不是零碎的,而是成體系的,有順序的。

相關文章
相關標籤/搜索