OO第三次階段總結

(1)調研，規格化設計的大體發展和爲何獲得人類重視

結構化程序設計（英語：Structured programming），一種編程範型。它採用子程序（函數就是一種子程序）、代碼區塊、for循環以及while循環等結構，來替換傳統的goto。但願藉此來改善計算機程序的明晰性、質量以及開發時間，而且避免寫出麪條式代碼。Edsger Dijkstra 於 1968 發表了著名的《GOTO 有害論》的論文,引發了長達數年的論戰,並由此產生告終構化程序設計方 法。同時,第一個結構化的程序語言 Pascal 也在此時誕生,並迅速流行起來。

在我看來，程序規格化設計是爲以後更大規模程序的設計打基礎，隨着之後需求的增長，要進一步提升程序的抽象化程度，規格化設計能讓人清晰的辨別各個方法的功能，以較簡便的方式解決客戶需求，下降程序的複雜度。

(2)分析本身的規格bug

第九次做業：無效

第十次做業：

 第十一次做業：無

(3)分析本身規格bug產生的緣由

對指導書的研讀不夠，存在誤差。對jsf的理解不夠深入。在以前的編程中，不夠清晰的層次設計，致使後來jsf的表達十分困難，因此要想不被報bug須要更多研讀課上所講的jsf。

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

前置條件的很差的寫法有，隨意使用null，none等，使用天然語言時有可能一時疏忽致使產生二義性。

五個很差的後置條件寫法：

1.簡單函數的的功能，即使很短也要寫。

this.state ==> this.state = i

2.天然語言 ==> 改爲用數據變現的對應關係

3.寫方法內涵的算法 ==> 只關注最後須要得到的數據的限制

4.對於多線程須要加入多線程的後置條件

 

更改前
/**
@ EFFECTS:randomly driving refer to flowmap            
    @ */

更改後
/**
@ EFFECTS:randomly driving refer to flowmap    
@ THREAD_EFFECTS:\locked(guigv.flowmap)    ;\locked(guigv.m.graph)        
    @ */


(5)按照做業分析被報的功能bug與規格bug在方法上的彙集關係
　　　無

(6)概括本身在設計規格和撰寫規格的基本思路和體會
　方法的編程應在規格的撰寫後，而不是寫完方法在回來改寫規格，這樣能夠很好的限制方法的長度也下降了方法的複雜度。規格不只是寫給本身看，更是爲後團隊工做時便於交流，並且要以指導書爲準，否則會被掛不少bug。