OO第三次課程總結分析

OO第三次課程總結分析

 

規格化設計發展歷史

　　在網上找了很久也沒找到合適的信息，稍稍參考了同窗的博客。大體以下：最初的的軟件並無形式化方法，隨着軟件工程的興起，爲了便於工程間的協調管理，人們提出採用工程方法來組織、管理軟件的開發過程並深刻探討程序和程序開發過程的規律，創建嚴密的理論。隨着時代的發展，軟件的複雜度日益加大，結構化程序設計的缺點日漸暴露出來，面向對象設計由此產生，規格化設計進一步發展，這一次的規格設計能夠更好地區分置換條件，以適應面向對象設計。現在，規格化設計基本完善，軟件能夠輕鬆實現跨平臺、鬆耦合的開發需求。

規格化設計獲得重視的緣由

　　規格化設計能夠提升程序的規範性、可讀性，能夠有效整理邏輯，避免出錯；對類、方法等進行規範化設計，也有利於程序的模塊化劃分。規格化設計程序可使得數據更加安全可控，也便於測試、維護程序，於是受到程序設計人員的重視。

被報告的規格bug以及緣由分析

做業	bug類別	所在方法	方法的代碼行數	bug產生緣由
9	JSF不符合規範	readmap	50	直接使用所給的例子，未進行修改，實際是不符合布爾表達式規範的
10	JSF不符合規範	readmap	50	同上，直接用時忘記改了
	Requires邏輯錯誤	readlight	64	這個各個條件之間未用&&鏈接，不符合布爾表達式
	Modifies邏輯錯誤	is_right	25	Modifies不該該有方法內新建的變量
11	無	無	無	無

 

前置、後置條件很差寫法及改進

---

前置很差寫法：

1.直接用天然語言闡述

 

2.直接用天然語言闡述

 

3.沒有使用布爾表達式

 

4.邏輯不夠嚴謹

 

5. 對前置條件不作要求

 

---

前置改進：

1.換成規範寫法

 

2.不使用天然語言

 

3.使用布爾表達式

 

4.使用規範語句

 

5.應該進行約束

 

---

後置很差寫法：

1.使用天然語言

 

2.蘊含式不對

 

3.使用else

 

4.表述不規範

5.使用天然語言

 

---

後置改進：

1.使用比較規範的語言

 

2.改爲正確形式

 

3.不使用else

 

4.規範表述

 

5.使用規範語言

 

功能bug與規格bug關係分析

方法	功能bug數	規格bug數
which_run	2	0
WriteStringToFile	1	0
readmap	0	2
readlight	1	2
is_right	0	1
Vip_taxi	1	0
service_shortest_run()	1	0
reqok	2	0

　　仔細分析彷佛沒有太大聚焦，畢竟是先碼的代碼再照着代碼寫的規格。

設計規格和撰寫規格的基本思路

　　先寫好規格確實能有效幫助實現和避免犯錯誤，從幾回上機實踐能深入地感覺到規格的強大做用，設計規格的基本思路基本上就是能夠先構思好這個方法具體的功能是實現什麼，會形成什麼效果，而後能夠推斷要產生這個效果必須得知足什麼條件，進行約束（固然能容錯也能夠沒必要），最後思考產生這個效果修改了什麼數據，產生了什麼反作用（我的想法）。

體會

　　寫JSF要花上大把時間，不只如此，還由於這些換來bug，實驗課上收穫的明顯比JSF互測要多，經過實驗課的練習，我以爲JSF能有效提升，但經過互測提升設計規格的能力確實不如實驗來得實在。