OO第四階段總結

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

　　從哲學的角度來講，正確性論證與測試的關係就像理論與實踐的關係同樣。

　　使用測試的方法檢驗程序正確性確實是一個很是方即可行且普遍運用的方法。能夠經過幾個簡單或複雜的測試樣例，迅速地校驗程序主要邏輯是否正確，運行結果是否符合預期。可是對於較爲複雜的問題來講，測試樣例極可能並不能覆蓋全部的狀況，所以咱們曾經引入代碼覆蓋率和分支覆蓋率的概念。可是在操做過程當中我發現，即便某個不徹底的測試樣例代碼覆蓋率達到100%，分支覆蓋率高於95%，它仍然並不必定徹底檢驗程序的邏輯是否正確，即便結果符合預期。所以咱們很難經過測試樣例說明程序必定正確，即便咱們使用了腳本生成等自動化測試方法，仍然不能全面地測試程序的邏輯是否徹底正確。所以測試這樣的方法有着其便捷性，也有着其侷限性。

　　正確性論證是一個全新的思路，咱們把程序的邏輯構形成分支的形式，經過規格總結出在各個分支下程序的預期表現來從宏觀的邏輯層面上論證程序是否正確，不去關心程序運行過程當中如何實現，只須要知足規格提到的前置條件和後置條件便可認爲程序正確。可是對於複雜問題，構建出程序的邏輯分支便已經十分吃力，程序的複雜邏輯極可能在分析的過程當中遺漏一些錯誤，所以這並非一個萬全的方法。

　　咱們在實踐中，應該結合兩者進行測試，雖然耗費時間，可是在對程序認知較爲深入的狀況下，天然更容易思考到比較偏僻和少見的邏輯問題。

2、OCL語言

OCL語言是對象約束語言，與JSF類似，一樣擁有着前置條件和後置條件，可是沒有JSF中的Modified屬性，有相似的不變式。還有叫作監護規則的約束，即在對象可以從一種狀態轉變爲另外一種狀態前其值必須爲真的約束。

OCL語言和JSF同樣，都只關心方法或對象在運行先後的屬性狀態，不關心具體的實現過程。

3、第十四次做業總結

 

　　以上是第十四次做業的UML類圖。

 

　　以上是第十四次做業的時序圖。

4、學期總結

　　本學期咱們首先學習了面嚮對象語言的初級應用，完成了一個看起來很不面向對象的Java程序——多項式計算，這個程序因爲功能簡單，致使其類的功能過於集中，Main類用於錄入信息，ComputePoly類用來計算多項式加減，確實是難以感覺到Java面向對象程序與傳統面向過程程序的區別（除了程序中多了幾個class關鍵字）。固然如今看來，這個程序還能夠寫得更面向對象一點，更完美一點。可是對於一個什麼都不懂的初學者來講，用這個做業入門且因爲設計需求中對輸入的嚴格要求，你們每每會把注意力集中在java的基本語法學習和正則表達式在Java中的運用之中，反而忽略了面向對象程序的關鍵。愚覺得，這個做業能夠進行一些改進以更加地偏向面向對象教學，不過考慮到因爲須要公測進行測試，且規範輸入格式對以後電梯程序的鋪墊做用，設計出這樣的做業已是很是合理了，且暫時也難以想到兼顧兩者的做業設計，畢竟對於當時的我來講，面向對象仍是一個很是抽象籠統的概念，是須要一個學期的學習才能正確認知的。

　　隨後咱們完成了兩次單線程電梯，第一個是傻瓜式電梯，以後咱們運用了學到的類的繼承，將其升級爲有一點點智能的可捎帶電梯。到這裏，咱們已經能夠管中窺豹地初步認識到Java面向對象中一大特性之繼承的做用以及好處，同時對單線程編程也是較爲熟練。

　　以後咱們便愉快地進入了Java多線程的世界，咱們首先再次升級了以前的稍微智能一點的小垃圾電梯，將其改造爲很是小可愛的三部電梯同時工做，而且直接進入了多線程階段，能夠真實地模擬時間，簡直是太酷了！

　　這三次做業讓咱們發現，在功能升級的時候，老是有一些其餘無關類（如Floor類）的代碼因爲一些不可言狀的緣由必須進行修改，這是怎麼回事！明明很厲害的面向對象怎麼會有這種狀況出現！難道是我作錯了什麼！原來隨着需求的修改，程序的邏輯有了很大的變化，以前在樓層類中使用了一些屬性來記錄相應的請求，而在多線程電梯裏又用不到了，致使這部分邏輯在方法中冗餘，才須要大量的修改甚至是重構。此時咱們發現了，類的抽象化作的很是的很差！樓層就是樓層嘛，樓層有樓層的功能，爲何還要用來記錄請求信息呢（實際上是由於要打印輸出），記錄請求信息意味着類之間的耦合性變高了，這也就是咱們必需要修改除去scheduler類以外的其餘代碼的緣由。

　　當這一做業告一段落，咱們完成了一個用做過渡的，用來幫助咱們學習多線程的線程安全和同步控制的做業——文件系統。在此次做業中，咱們學習了諸多線程安全的手段（有且不只有sleep(200L), sleep(500L)和sleep(1000L)），極大地提高了本身在線程同步控制上的造詣。

　　在以後的Taxi做業，咱們早早就據說了本次做業將有屢次升級，所以我在實現時很認真地思考本身的程序，如何讓本身的程序變成高內聚低耦合的神奇存在。又在線程控制上有了很深的認知，使此次做業的線程同步的矛盾從設計層面上被儘可能避免。同時又完成了需求提到的並不豐富的功能，其中最困難的部分多是從新寫一個好用的最短路徑搜索以替代本來GUI中提供的特別佔內存且特別慢的方法吧。

　　以後不管是爲道路添加流量仍是添加紅綠燈仍是設置VIP出租車，都極大地體現了一個良好的程序構思是多麼的有意義，添加流量時因爲要修改map類的邏輯，包括最短路搜索，致使須要寫很多代碼，以後的紅綠燈幾乎只修改了兩三個方法，修改了十幾到幾十行代碼就解決了這個問題。而可追蹤出租車更是完美的體現了面向對象程序中繼承的優勢，程序的其餘部分對可追蹤和普通出租車的處理徹底沒有區別，卻能夠很好地完成功能需求。再加上某個選修課學到的c++面向對象的相關知識，到這，我以爲面向對象程序中繼承的運用以及好處已經被我掌握個大概了。

　　從Taxi第二次做業開始，咱們引入了全新的程序設計理念——規格，這個東西能夠很好地統一程序員之間的交流語言，也能夠爲本身的程序設計提高便利。這一部分與咱們以後的幾回做業有着極大的關聯。

　　以後的幾回代碼量很是小的做業中，咱們前後接觸了JUnit單元測試、程序正確性論證等概念，這兩個概念令我對以前蠢笨的測試方法感到十分羞愧，想起當時百度的時候也曾經看到JUnit的使用方法但因爲懶惰並無深刻學習，致使剛開始在對程序測試時，幾乎都在使用複製粘貼按回車大法。可是代碼量小並不表明做業更輕鬆，雖然當時的我在身體及意識上對它們都有些不重視，可是在實踐過程當中，發現當初寫的程序簡直是太難以接受了，將這樣的程序整理出合適的規格實在是過於繁瑣。所以，無可奈何地修改了一小部分代碼使程序變得好看一點。又因爲在第二次電梯做業中對其很是的上心，記得當時不少的邏輯結構，所以很容易就構造出了符合條件的測試集。雖然因爲邏輯的複雜，在正確性論證的過程當中碰了釘子，但整體來講還算比較順利。

　　從我我的的角度來看，這一路走來，個人工程化能力有着比較大的提高和進步，對面向對象的學習也是很是認真。所以很是感謝OO課程組爲咱們精心設計的關卡，很是感謝助教在這一過程當中對咱們的幫助。就我我的來講，相信若是沒有OO的闖關機制來輔助個人學習，單純經過上OO理論課，而後隨便佈置一些做業的話，我很難對OO這門課的認識有現在的程度。