第三次博客總結
一.規格化設計對的發展歷史
在1968年,荷蘭教授E.W.Dijkstra提出了“GOTO語句是有害的”觀點,指出程序的質量與程序中所包含的GOTO語句的數量成反比,認為應該在一切高級語言中取消GOTO語句。這一觀點在計算機學術界激起了強烈的反響,引發了一場長達數年的廣泛的論戰,其直接結果是結構化程序設計方法的產生。80年代中後期,面向對象程序設計逐漸成熟,被計算機界理解和接受,人們又開始進一步考慮面向對象的開發問題。這就是九十年代以Microsoft Visual系列OOP軟件的流行的背景。1990年以後,面向對象分析、測試、度量和管理研究都得到長足的發展,規格化設計應運而生。規格化設計能夠幫助編程者進行架構,以及在未來對其方便地維護。此外,因為規格化設計能使他人方便地理解代碼含義,而使得程序員們在大型多人的開發中能夠便捷地以他人的代碼為基礎進行開發工作,提高了工作效率。因此規格化設計得到了人們的重視。
二.規格bug統計
|
功能Bug |
規格bug |
oo9 |
0 |
1 |
oo10 |
0 |
0 |
oo11 |
0 |
0 |
oo第9次作業的bug分析
bug類別 |
bug內容 |
規格bug |
Main和Taxi以及sche的run()沒寫JSF |
三.原因
我當時以為線程方法不需要寫JSF。
四.jsf的修改
前置:
1. 前置條件缺少對傳入參數的範圍判斷
修改前
修改後
2. 前置條件缺少對參數存在性的判斷
修改前
修改後
3.當沒有前置條件時
修改前
修改後
4.前置條件判斷應用“==”號
修改前
修改後
5.多余的前置條件
修改前
修改後
後置:
1. 在非必要情況下使用自然語言
修改前
修改後
2. 不是布爾表達式
修改前
修改後
3.改變值書寫不規範
修改前
修改後
4. 後置條件沒寫全
修改前
修改後
5.將中間變量的修改寫入到後置條件中
修改前
修改後
五.功能Bug與規格Bug的聚類關系
在現階段,我認為JSF問題大多是格式或者規範問題,也就是書寫問題,和功能bug聚集關系並不大。
六.心得體會
最初寫規格是很難上手的,但經過這麽多次寫規格的訓練,也積累了一些熟練度,寫的更快了。此外,以前我一個方法寫很多行代碼,然而這樣的方法是很難寫出規格的,為了寫好規格,也必須將代碼縮減,使所有方法各司其職,變相的規範了我的代碼風格,提高了代碼可讀性。
第三次博客總結