第三次博客總結

一.規格化設計對的發展歷史

在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彙集關係並不大。

六.心得體會

最初寫規格是很難上手的，但通過這麼屢次寫規格的訓練，也積累了一些熟練度，寫的更快了。此外，之前我一個方法寫不少行代碼，然而這樣的方法是很難寫出規格的，爲了寫好規格，也必須將代碼縮減，使全部方法各司其職，變相的規範了個人代碼風格，提升了代碼可讀性。