1. 程式人生 > >OO第三次階段總結

OO第三次階段總結

關系 while循環 時有 -s src 區塊 mce font 撰寫

(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第三次階段總結