第四次oo博客

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

　　單元測試利用測試者構造的測試用例來檢查類或方法的正確性，通常來講所須要測試的用例是無窮多的，經過人爲構造表明性的測試用例來儘可能測試全部代碼。測試的優勢在於不易出錯，只要能正確肯定測試結果就好了，可是缺點在於難以考慮到全部的表明性用例，在複雜工程中，徹底周密的測試是幾乎不存在的，測試者不能保證沒有不被考慮到的用例。

　　而正確性論證是邏輯論證，從代碼層面出發，用天然語言來描述程序的運行正確性。優勢是邏輯論證能夠徹底覆蓋類或方法的運行過程，可是缺點是天然語言論證自己就是不能保證正確的，沒法與單元測試的機器運行相媲美。

OCL與JSF的比較

　　OCL是對象約束語言，能夠應用與任何實現方式的非正規語言。對象約束語言對UML中圖形或其餘組件都沒有控制權，他只是在使用時返回值。OCL、並不能修改對象的狀態，而是用來指示對狀態的修改什麼時候發生。而JSF更增強調對代碼功能的說明，OCL是形式化語言，JSF是半形式化語言，可使用天然語言；OCL表達式的值能夠有不一樣的類型，JSF表達式的類型都是布爾型。共同點在於OCL和JSF均可用於描述規格的前置條件和後置條件。

UML圖

 

整理總結

　　闡述四個單元模塊知識點之間的關係：第一個單元應該是整個java編程的基礎，初步瞭解面向對象編程的過程，幫助你們熟悉Java語言的使用狀況。第二單元和第三單元都着重於多線程編程，先利用電梯做業體驗簡單的多線程編寫，只限於三個電梯和樓層間信息交換，開始設計進程同步等知識，而到了第三單元將多線程複雜化爲更多的出租車和地圖，加大多線程編程的難度。第四單元着重於規範化代碼的編寫，對JSF、規格文檔、正確性論證進行訓練。

　　梳理本身所設計實現的程序：以第十四次做業爲例，我徹底重寫了第三次做業的代碼，第三次做業的類圖以下：

　　第三次做業的數據管理很是很是混亂，共享的數據分佈在各個類中都有定義，其中還AskDisposeOverride的長度達到了四百多行，可讀性基本爲0。而在第十四次做業中，我將共享數據集中在一個類中進行管理，每一個方法的長度都控制在五十行之內，代碼的規範度有了質的提高。同時重寫後的方法使用了徹底不一樣的調度方法，更加貼合多線程運行的實際狀況，請求管理也使用了ArrayList，代碼更加方便維護。

　　闡述本身對工程化開發的理解：而在企業項目中，代碼的規格化尤其重要，一個項目大多都是由一個團隊來完成，若是沒有統一的代碼規範，那麼每一個人的代碼一定會風格迥異。且不說會存在多我的同時開發同一模塊的狀況，即便是分工十分明晰的，等到要整合代碼的時候也有夠頭疼的了。大多數狀況下，並不是程序中有複雜的算法或是複雜的邏輯，而是去讀別人的代碼實在是一件痛苦的事情。統一的風格使得代碼可讀性大大提升了，人們看到任何一段代碼都會以爲異常熟悉。顯然的，規格化的代碼在團隊的合做開發中是很是有益並且必要的。

　　對課程的任何指望或建議：強烈建議對於部分測試刪除互測階段，對於JSF、規格檢查，互測其實無可厚非，這些內容有些時候就是用來給別人看的，可是第1、2、三單元徹底能夠依靠公測進行測試，指導書統一輸入方式和輸出結果就好了。課程組可能對於匿名後的學生素質指望太高，亂扣bug是一個低風險的行爲，除了一些明顯無理由的bug外，大部分互測爭端是助教難以評判的，並且工做量巨大。因此強烈建議前一二三單元使用公測進行測試，這三個單元的做業更加註重結果的正確性而非規範性。