規格化發展的歷史

　　規格化的發展史說的寬泛一些其實就是軟件工程的發展史.
　　1968年秋季，NATO（北約）的科技委員會召集了近50名一流的編程人員、計算機科學家和工業界巨頭，討論和制定擺脫“軟件危機”的對策。在那次會議上第一次提出了軟件工程（software engineering）這個概念，研究和應用如何以系統性的、規範化的、可定量的過程化方法去開發和維護軟件，以及如何把經過時間考驗而證明正確的管理技術和當前能夠得到的最好的技術方法結合起來的學科。它涉及到程序設計語言、數據庫、軟件開發工具、系統平臺、標準、設計模式等方面。其後的幾十年裏，各種有關軟件工程的技術、思想、方法和概念不斷被提出，軟件工程逐步發展為一門獨立的科學。
Edsger Dijkstra 於 1968 發表了著名的《GOTO 有害論》的論文,引起了長達數年的論戰,並由此產生了結構化程序設計方 法。同時,第一個結構化的程序語言 Pascal 也在此時誕生,並迅速流行起來。

　　結構化程序設計的主要特點是拋棄 goto語句,采取“自頂向下、逐步細化、模塊化”的指導思想。結構化程序設計本質上還是一種面向過程的設計思想,但通過“自頂向下、逐步細化、模塊化”的方法,將軟件的復雜度控制在一定範圍內,從而從整體上降低了軟件開發的復雜度。結構化程序方法成為了 1970 年 代軟件開發的潮流。
1970年代和1980年代的軟件危機。在那個時代，許多軟件最後都得到了一個悲慘的結局，軟件項目開發時間大大超出了規劃的時間表。一些項目導致了財產的流失，甚至某些軟件導致了人員傷亡。同時軟件開發人員也發現軟件開發的難度越來越大。在軟件工程界被大量引用的案例是Therac-25的意外：在1985年六月到1987年一月之間，六個已知的醫療事故來自於Therac-25錯誤地超過劑量，導致患者死亡或嚴重輻射灼傷.

　　1993年，電氣電子工程師學會（IEEE）給出了一個更加綜合的定義："將系統化的、規範的、可度量的方法用於軟件的開發、運行和維護的過程，即將工程化應用於軟件開發中"。此後，IEEE多次給出軟件工程的定義。

BUG分析

　　對於規格的bug, 由於剛開始對於jsf並不熟悉, 導致產生了一些語法上的錯誤, 或者是jsf寫的不完整的問題.
甚至還有一次是因為粗心漏填了一點東西被別人找到了.
　　而對於功能性的bug, 出現這些bug的根本原因還是自己沒有對程序進行完整和規範的測試, 導致被別人測出了許多的bug, 還有幾個是由於自己對指導書沒有認真閱讀而導致的, 由於粗心沒有註意到出租車只有在等待服務狀態下才能搶單, 而我只是設定了接單的只能是等待服務狀態, 還有一個是由於第十一次的指導書的狀態編碼和之前的有了變化, 自己沒有認真閱讀, 從而導致了錯誤. 雖然每次都被別人扣了很多分, 感覺很不爽, 卻又找不到什麽反駁的理由, 首先也有在自己身上找原因. 之前的幾次作業總是讓我抱著僥幸的心理, 從而導致了如此多的錯誤. 之後還是得嚴謹地閱讀指導書, 對自己程序進行嚴謹的測試.

前置條件和後置條件不好的寫法
1.
這是出租車run函數的jsf, 寫得過於簡略, 從jsf中並不能看出函數的邏輯.
/**
@Requires: None
@Modifies: time,dep,flag,path,status,position
@Effects: time==old(time+100), position==position.run()||position==position.randomRun();status==(WFS,SERVE,TASK,PAUSE)
*/

2.
Effects使用了自然語言描述, 不太規範, 容易產生二義性.
/**
@Requires: request!=null
@Modifies: taxiInfos,taxi.request
@Effects: distribute request to the best fit taxi

*/

3.前置條件的布爾表達式不夠嚴謹, 夾雜了c語言的語法
/**
@Requires: int 0<=sta<=3, s=WFS||SERVE||PAUSE||TASK
@Modifies: this.sta,this.s
@Effects: this.sta==sta,this.s==s

*/
4.這個方法有try catch, 所以應該寫清楚exceptional_behaviors, 這樣effects才更完整.
/**
@Requires: in!=null
@Modifies: map,requestQueue,scheduler,map[][],taxi
@Effects: initial map, request, light and taxi

*/
5.沒寫清楚哪些變量進行了修改, 不夠清晰明了
/**
@Requires: position!=null, request!=null;
@Modifies: this
@Effects: this.position = position, this.request = request
*/

心得與體會

　　這幾次的作業難度上可能沒之前那麽高, 主要的訓練重點放到了規格化上, 但是還是暴露出自己很多的問題, 其中最大的一個就是對指導書研究得不夠透徹, 導致犯了一些很蠢的錯誤.
　　在規格的設計上, 規格的設計非常重要, 關系到自己代碼的可讀性是否好, 在拓展的時候是否更加方便, 在完成第11次作業的過程中, 也對繼承的概念有了進一步的認識. 通過對jsf的學習, 也對規格的總結與概括有的新的認識.通過這幾次的訓練, 感覺自己的編程能力還是有待提高的, 尤其是對於一些細節方面的把控需要加強, 對於如何構造測試數據也需要多多構思.

第三次OO總結