測試和正確性論證的效果差異
測試一般分為：功能測試、單元測試、魯棒性測試、效能測試、回歸測試等。測試的優點是操作簡單粗暴；缺點是如果測試集不夠大可能不能覆蓋所有可能出現的場景，也就是說測試不夠全面的問題。
正確性論證偏理論，是從邏輯層面分析**正確性。其優點是能覆蓋到**的所有分支，從而保證**的正確性；缺點是需要花費大量時間和精力。
ocl語言 vs jsf規格
ocl是一種形式語言，可以應用於任何實現方式的非正規語言，最初由ibm公司設計完成。雖然ocl是一種形式化語言，但是它具有形式化語言無二義性的特點，又消除了形式化語言的複雜性。傳統意義上的形式語言一般僅適用於有一定數學背景的人，而沒有相關知識培訓的人則難以使用，也就是說傳統意義上的形式語言對使用者要求較高，而ocl語言簡練易上手，適用範圍更廣。
jsf規格約束沒有ocl語言規範，尤其是用自然語言描述的jsf很容易造成歧義。
ocl和jsf的相似之處在於，ocl的前置條件用"pre"標識，後置條件用"post"標識，相當於jsf的"requires"和"effects"。且ocl和jsf都起約束作用。
ocl格式如下：
context typename::operationname(param1 : type1, ... ): returntype
pre : param1 > ...
post: result = ...
jsf格式如下：
/*** @requires:
* @modifies:
* @effects:
* /單電梯als排程
類圖：
時序圖：
狀態圖：
oo學期總結
作業清單：
第一次作業：多項式處理
第二次作業：傻子電梯
第三次作業：als電梯
第四次作業：多執行緒als電梯
第六次作業：檔案系統
第七次作業：多執行緒計程車
第九次作業：多執行緒計程車+道路開閉
第十次作業：多執行緒計程車+紅綠燈
第十一次作業： 多執行緒計程車+jsf+lsp原則
第十三次作業：單執行緒als電梯+jsf+junit4覆蓋性測試
第十四次作業：單執行緒als電梯+正確性論證
四個單元模組知識點：
1、熟悉物件導向程式設計方式和正規表示式的使用
2、多執行緒共享資料避免出現死鎖問題，同步與互斥的處理
3、處理多執行緒時間錯誤的問題
4、jsf規範化、測試集全覆蓋和正確性論證
設計、測試和質量上的進步：
oo這門課帶給我很多，烏雞老師在最後一節總結課上說的很對，上完物件導向這門課，我們的**風格有了質的飛躍，主要體現在**架構、程式設計技巧、規格編寫等方面。
設計：從面向過程到物件導向，物件職責越來越明確，方法功能也逐漸清晰，**也開始相對模組化。
測試：剛開始不知道怎麼構造乙個完備的測試集，像個無頭蒼蠅想到什麼就寫什麼，經歷了這個學期的互測，開始領悟到了測試的套路，擅於發現奇怪的邊界情況。
質量：從方法長度可以明顯感受到**質量的變化，乙個方法上百行到基本50行以內，方法功能也變得清晰明了，以及物件之間的互動資訊也明確了不少。最重要的還有**規範的問題，變數名和方法名等，剛開始我會取乙個自己喜歡的或者有趣的名字比如「haha」「balabala」「bibi」之類的，回頭看自己寫過的**時，讀起來非常費勁，現在我已經成熟了，這些膚淺的命名絕不出現在我的**中，對變數、方法命名的規範化使**可讀性大大提高！即使幾周不看，還是很明確方法功能和變數的意義。
對工程開發的理解
我覺得工程開發需要乙個團隊合作來完成，通過git隨時隨地修改**，對**規範化要求高，提高團隊合作效率。並且對測試要求也很高，聽說測試不行的程式猿是要拿去祭天的qaq
課程建議
OO最後一次部落格
一 測試與正確性論證比較 測試是使用測試樣例對程式進行檢測而正確性論證則是根據 的邏輯進行驗證。測試想要完全覆蓋的難度較大，需要大量的樣例才能達到近似的完全覆蓋，而正確性論證則不需要花費那麼大的精力，只需要根據 的邏輯和規格進行一系列驗證即可。二者相互補充，相輔相成。正確性論證可能由於一開始設計的錯...
OO第一次部落格總結
oo是我大學裡經歷的又乙個難關。和計算機組成相比，物件導向程式設計的起點更高。第一次作業 第一次作業給了我乙個下馬威，因為當時正在準備乙個補考，沒有時間學習j a，等到考完，時間已經不多。我的學習一直是沒有效率的，之前程式設計基礎也很差。我開始時候看指導書感覺很難懂，然後同學說要學習字串陣列和正規表...
最後一次救贖
連這個也廢掉了嗎？66歲的王安石枯槁的身軀在料峭的春寒中顫慄著，昏花的雙眼無力地凝視著西北方向 那裡有承載他嘔心瀝血的未竟事業的帝都，是他生命中最為燦爛輝煌也最為寥落失意的地方。稟性剛毅的倔強老人無法想象，自己窮盡一生的政治智慧型所醞釀的帝國變革方略竟以這樣一種方式謝幕，他深切熱愛的國家和人民繼續在...