(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。

OO第三次階段總結