終于來到了最後一次的OO作業，以部落格作業的形式來終結也是極好的，回顧一下過去十六周自己的經曆，感慨頗深。
測試和正确性論證
簡單來說，測試的目的是将程式的代碼做到全覆寫，進而確定每個分支都運作一遍，進而分析代碼中是否有錯誤，錯誤出在哪裡。這個方法是十分實用的，可以有效的找出自己代碼中的錯誤，即很容易發現淺顯的錯誤，但不容易發現隐晦的錯誤。程式設計的經驗告訴我，确實存在那種執行了多條代碼之後有了不一樣的結果，一環套一環，這種情況雖然很難發現，但确實存在。而正确性論證則不同，它通過大量的窮舉，基于repOK和jsf來論證正确性，可以說絕對正确，但時間複雜度實在太高了，遠高于寫這份代碼的複雜度。
OCL和JSF
OCL的基礎是數學中的集合論和謂詞邏輯，并且它有一個形式化的數學語義，但是它并沒有使用某種數學符号。因為雖然數學符号能夠清晰的、無歧義的表達事物，但是隻有極少的專家可以看懂。是以數學符号并不适合用于一個廣泛應用的标準語言。自然語言是最易懂的，但是它是含混不清晰的。OCL取了自然語言和數學符号的折中方案，使用普通的ASCII字元來表達數學中同樣的概念。如果你不喜歡目前的OCL表達方法，OCL規範還允許你定義自己的OCL符号集，這點是可以了解的，因為OCL有一個清晰的數學語義。
相同點在于它們都采取了自然語言和數學語言的折衷，采用了前置條件，後置條件和監護規則的模式，不同點在于OCL有着豐富性和完備的可計算性，更重量化。
UML圖
總結
這一學期下來，我從最開始連Java都不怎麼會編的菜鳥變成了現在能順利通過OO的人，期間可謂受益匪淺。要談到自己的進步的話，從第十四次作業可以看出來，以往的作業真的就是一個超級面向過程的作業，後來才真正的了解了面向對象。
四個章節從最開始的初次提到面向對象再到後面的多線程及線程安全，是程式設計能力的提升。抽象與規格則要求了規格化的程式設計，最後強調了工程化的品質。
有一個很簡單的評測标準，那就是方法的行數，實不相瞞，最開始我的Java代碼有過一百多行的方法，寫它的jsf簡直要把我寫死了！後來到了計程車，基本上就沒有了這種問題，但面對之前自己的作業，隻能狠下心來重構了。也真真切切的了解到了面向過程和面向對象之間的差距，代碼能力也會有顯著提高。
我認為工程化開發最重要的是可移植性和便捷程度。因為一個工程需要一個團隊合作完成，是以各自負責的部分必須要把接口寫好，友善别人使用；同時程式内部雖然是一個黑箱，可這個程式後期是可能進行加工的，并且有可能不是原開發者加工維護，是以代碼一定要簡潔明了，符合規範。
我對課程的最大期望是，在檔案系統的那一章作業，要麼降低難度要麼增加時間。我的能力有限，時間也無法全部放在OO一門課上，是以有限的時間内我無法保證作業的品質，分到一個心狠手辣的人我就被扣的不成樣子，同樣寫的不好的同學卻不會這樣，這中間的落差很容易讓人走向黑化的道路，進而病毒式的擴散到全系。老師或許會說，保證作業品質就不會有這樣的情況了，說的太對了，可這個課的難度本身就應該讓所有人努力一下就不會太慘才對，不應該有這一章作業存在，請老師好好考慮，不然像我這樣運氣不好的菜鳥隻能在申訴之後面對助教一句“全部視為錯誤”之後想罵人了。關于這門課我真的沒什麼好贊美的，它讓我學到了很多東西，面向對象的程式設計思想，節約時間的必要性等等，卻也讓我明白了黑暗森林體系中每個人能有多瘋狂，吳際老師說将來每個人都會感謝這門課教會自己的東西，可我更喜歡另一個老師的這句話：“社會是複雜的，但希望我們盡量保持一顆純潔的心”。與君共勉，繼續努力