[BUAA OO]第四次博客做業

 

1、      測試與正確性論證的區別

在最後一個單元的OO做業中，咱們主要進行了代碼的測試與正確性論證工做。這倆者在做業中的體現分別是junit單元測試以及jsf論述語言。這二者在java代碼開發中分別可以幫助咱們檢測代碼、測試代碼，最終起到對工程正確性進行檢測的功能。

這兩者就比如一個是完成前的完整性檢查，一個是完成後的正確性測試。固然了，理論上來講，這二者之一均可以幫助咱們避免代碼中問題的出現，可是更保險一點又有誰會反對呢？

先說說junit單元測試。這個相比jsf論述語言，應該是咱們比較熟悉的一個了。就像咱們平時完成代碼後的功能測試同樣，junit經過編寫可以完整覆蓋代碼邏輯分支、語句分支的測試樣例，對每個功能單元進行測試，並與預期結果進行比對，從而起到輔助程序員規避代碼bug的功能。這種方法十分親民，可是，卻有着必定的問題。通過實踐發現，因爲邏輯自己存在的問題，雖然使用的測試樣例達到了代碼覆蓋率100%，邏輯分支覆蓋率100%，可是樣例過於簡單，沒有在數據範圍上完整覆蓋全部區間，在經過單元測試以後，仍然致使了問題的出現。

這就須要jsf論述語言來幫咱們規避問題。jsf論述語言，在剛開始學習的時候讓咱們感到無比頭痛。絕不親民的語言格式，不直觀的展現方式，囉嗦的描述方式，讓我對其功效一度產生了懷疑。但這卻能讓咱們規避junit所沒法規避的問題，那就是在邏輯上對實際實現的代碼與程序員所構思的程序應該具備的功能作比較。在這個單元的學習中，我就經過jsf論述成功發現了個人第三次OO做業中的一處邏輯漏洞，是判斷語句中數據覆蓋不完整致使的，若是不使用極其特殊的測試樣例，使用junit單元測試就很難發現其中的問題。

 

2、      OCL VS JSF

OCL（Object Constraint Language）語言，即對象約束語言，跟jsf語言同樣，是聲明式語言，對於方法只關心作什麼、效果怎樣，而具體如何實現，則不關心。都是使用邏輯表達式來描述具體的約束內容，採起了相似前置條件，後置條件，不變式這樣的語法。可是OCL一般會結合uml類圖來使用，相比jsf的約束性也更廣。

 

3、        第十四次做業總結

 

 

以上是個人時序圖和uml圖。

 

4、      學期總結

這學期的面向對象程序設計課程主要進行了四個單元的練習，分別以基礎java程序設計，基礎多線程程序設計，進階多線程程序設計、jsf論述入門，以及jsf論述進階、junit單元測試爲主。在總體上來看，逐步深刻，每一個單元的做業由三次程序做業組成，按照指導書加答疑的方式佈置內容，要求咱們有非直觀信息的理解能力。

這個學期的做業我作起來仍是至關認真的，每次都是「謀定然後動」，中間的電梯第二次做業還在週一夜因爲邏輯設計的問題重構過一次，總體上來講應該算是質量不低的。但事實卻跟我想的有點區別。第一次單元測試做業，讓咱們測試第三次做業（也就是第一次電梯做業）。在回顧的時候，簡直慘不忍睹。雖然做業總體功能上沒有出現問題，可是各類變量名混亂、類功能混亂、對於同一個信息的檢測分割在不一樣類中，羞於認可這是我寫的。進而總體重構了一遍。在羞愧之餘，我卻發現，這未嘗不是一種提升呢？在當時我那樣設計，雖然已經忘記了當時的初衷，可是如今對於當初的鄙夷不正是表現了我對於清晰的面向對象程序的認識與嚮往麼？這種提升每次一都很小，可是12次做業積累下來，簡直讓人沒法相信這些都是同一我的寫的。不可謂提升不小。