OO第四次博客總結

一. 測試與正確性論證的效果差別

　　程序的正確性論證是在用戶提出需求後，進行規格撰寫後，論證程序是否符合規格的過程。由於規格每每是布爾型或天然語言，對程序員來講並不如代碼和測試數據直觀，且工做量巨大。但相應的，好處是對代碼總體進行了具體的剖析，在規格符合需求的前提下，可以發現程序與規格間的邏輯上的不符。

　　測試則須要經過輸入特定數據等方式，檢查程序是否和預期相同，由於測試不可能窮舉，致使了不窮舉的測試不可能驗證程序是徹底正確的，只能驗證程序在測試時沒有發生錯誤，儘管如此，測試依然是一種高效的檢查程序的方法，經過輸入數據或復現現場，直觀的發現代碼的問題，進而在代碼中找到問題的來源並修正。

 

二. OCL語言和JSF規格的對比

　　OCL語言的全稱是Object Contraint Language，即對象約束語言，是UML中約束定義的語言。對OCL的講解，能夠參考這裏。

　　與JSF規格相比，都有不變式和數學邏輯表達式，但JSF多了MODIFIES，而OCL的語法遵循巴斯科範式，而且有集合等高級數據結構。

 

三. 對ALS單電梯系統的圖表示

　　UML類圖：

　　UML順序圖：

　　UML狀態圖：

 

四. 總結

　　oo第一單元是基本的設計思想，包括類的抽象，私有，接口和繼承等等，是後續部分的奠定石。第二單元是多線程的數據管理和衝突解決，引入了多線程的編程方法。第三單元是規格化設計，爲第四章論證鋪墊。第四單元是單元測試和正確性論證，根據規格對每一個方法進行測試和覆蓋率檢查，對每一個類進行正確性論證。

　　一個學期的數次編程聯繫中，提升最大的應該是設計。之前在編寫一個程序，看中的是算法，但當程序有了必定規模和屢次的增補，沒有一個好的設計極可能致使以後的新功能收到影響，甚至不得不重構。以出租車爲例，當初爲了方便，採用了單線程控制100輛出租車來實現，但當流量的定義被改變和加入了紅綠燈後，這樣的設計沒有辦法讓全部車每500ms一塊兒移動，即便記錄下一次最早移動的車，當程序運行時間足夠長，也會變成每1ms遍歷100輛車1次的狀況，當初的設計反而讓程序的效率下降。一樣在第14次做業中，由於要對ALS單電梯系統的方法添加JSF規格說明，因爲當初剛剛接觸java，代碼的調度器部分的方法長達200行，難以寫清不變式，只得重構。重構後發現，全部方法都在40行一下，更加清晰。

　　測試的水平卻不想設計同樣平穩上升，而是先上升後降低，主要緣由在於後期做業的設計佔了更多的時間，完成代碼後每每已經沒有足夠的時間進行測試。但仍是要說的是，對於單線程、統一輸入格式的程序，徹底能夠將兩份做業進行自動化的隨機產生輸入、對比輸出，從而完成測試，這一方法也用在了ALS單線程電梯中。

　　此外，互評機制確實讓不少人第一次見識了工程化的代碼是什麼樣的，一切源於在第一次電梯做業中，我有幸拿到了某個已經開始在公司實習的dalao的代碼，簡單的程序，大多數人用了5個類或更少來完成程序，這份代碼卻包括了23個類，其中包括了exceptions、interfaces、models、helpers、configs等部分，這份代碼也被我分享給了不少人，確實對初次接觸稍複雜的程序時是一種震撼。

　　可是確實不少人在完成了全部的編程做業後，也仍是不知道究竟什麼樣的設計是「很好」的設計，不知道什麼樣的代碼是好的，不妨在每次測評結束後選出一份給你們借鑑的代碼，並附上程序的結構說明。此外對於一些問題，或許已經在前期講過，可是當時咱們對java和oo的認識很是有限，致使到了後期依然不知道該怎麼解決，好比屬性已經所有爲private，也明確說明不該每個private都有get和set，那麼如何減小set和get函數數量？即究竟如何高內聚低耦合？以及對諸如請求隊列這樣的類，到底是該設置爲public static的全局變量仍是應該繁瑣的引用？相信不少人在oo結束後仍有這種感受：一個學期的oo，很肯定本身學到的是一些java的語法、一種多線程編程的方法、JSF規格的撰寫、程序的測試和設計上的鍛鍊，卻對什麼樣的程序是好的程序仍然以爲迷茫，也多是課程組故意爲之吧，畢竟計算機類的專業課，基本職責就該是讓學生了解有這樣一個東西，更進一步的內容還須要本身去深刻。

　　最後感謝oo老師和助教們一學期的辛苦，給咱們答疑解惑，一塊兒熬夜~你問我滋不滋持oo滋不滋持互測，我固然是滋持的。