作業十五
測試與正确性論證的效果差異
程式的測試需要通過輸入特定資料等方式，檢查程式是否和預期相同，因為測試不可能窮舉，導緻了不窮舉的測試不可能驗證程式是完全正确的，隻能驗證程式在測試時沒有發生錯誤，盡管如此，測試依然是一種高效的檢查程式的方法，通過輸入資料或複現現場，直覺的發現代碼的問題，進而在代碼中找到問題的來源并修正。
程式的正确性論證是在使用者提出需求後，進行規格撰寫後，論證程式是否符合規格的過程。因為規格往往是布爾型或自然語言，對程式員來說并不如代碼和測試資料直覺，且工作量巨大。但相應的，好處是對代碼整體進行了具體的剖析，在規格符合需求的前提下，能夠發現程式與規格間的邏輯上的不符。
二者相比較而言，測試是一種較為簡單，較為直接與直覺的方法。通過編寫測試資料就可以對于程式進行黑盒測試，不需要花大量時間在了解程式本身上。相比之下正确性論證就需要測試者對于程式本身就很細緻的了解，對于要求功能有很細緻的了解，每一部分的測試都會顯得十分麻煩，尤其是在面對一些邏輯較為複雜的代碼，正确性論證的工作量呈指數型增長。
OCL語言和JSF規格的對比
OCL語言全拼為objective constraint language，中文叫做對象限制語言，是用來限制定義的，形式化無二義的語言。OCL語言是一種聲明式語言，用來描述應用于UML模型的規則，現在是UML标準的一部分。OCL語言和JSF都是聲明式語言，但OCL一般與UML圖相關，文法更規範。
第十四次作業
UML類圖
UML順序圖
UML狀态圖
總結
闡述四個單元子產品知識點之間的關系
本學期所學内容大概可分為以下四個單元。
一、什麼叫做面向對象程式設計，面向對象和面向過程的差別在哪裡。主要是第一次至第四次作業。
二、多線程程式設計，多線程程式設計的運作特點及調試方法。主要是第五次至第九次作業。
三、規格設計，如何在宏觀上對于程式進行設計與調試，為以後大規模的軟體開發打基礎。主要是第十次至第十三次作業。
四、正确性論證，從科學理論的角度去評價一個程式的好壞，改變之前黑盒測試的邏輯習慣。主要是第十四次作業。
四個單元深入淺出，從全面講解java知識，深入多線程設計，到較為輕松的測試和jsf論述，我們體驗了從語言學習、建構工程到單元測試的完整過程。
梳理自己所設計實作的程式，分析自己在設計、測試和品質上的進步
應該說OO這門課給我帶來了很大的提升。一是面向對象的程式設計，二是多線程的相關内容，三是工程化開發的相關知識。在閱讀部落格，進行互評，與室友同學的交流過程中，我學到了很多東西，簡單的如常量的定義（其實很想叫他宏定義，因為主要作用其實類似于宏定義），大到程式設計風格，程式設計結構，可以說，沒有與同學們之間的大量交流，我是難以獲得這些提高的。在面向對象課程之前，雖然我也編寫過一些小型的程式，基本沒有接觸過測試方面的内容，測試時也更多地根據自己想當然的方式來測試，沒有一個規範的，高效的方式，在現在看來，以前自己的測試也略顯笨拙。
闡述自己對工程化開發的了解
軟體開發無疑需要大量的團隊合作，工程化代碼就尤為重要。代碼規範、JSF規範，都是友善工程化開發的實用工具。工程化之是以出現，也是因為計算機行業從量變到質變的一個過程，一個人編寫代碼，隻需要自己能夠編寫時讀懂，甚至不需要考慮維護。幾個人開發的程式，需要有一定的規範，友善他人閱讀，對接。幾十上百人的工程，需要的則是一個高效的開發規範，不僅需要考慮到目前的開發成本，甚至需要考慮到多年後，其他人閱讀并維護代碼的代價。個人代碼的可閱讀性，魯棒性，與整個工程息息相關，一個人的不留意可能會帶來整個團隊很大的困擾。工程化開發正是适合目前的大規模計算機開發的一個有效手段。
對課程的任何期望或建議
首先不能否認，OO這門課有一定的不足，經過一個學期的學習，大家也能體驗到不少。但總的來說OO這門課，是利大于弊的，對我們個人能力的提升非常巨大，是以個人還是認為可以保留目前OO的主要形式，但也不可否認需要一些改進，比如受到很多人吐槽的指導書經常修改，助教的解答甚至互相沖突等等，這些也需要助教團隊和老師們多總結以前的同學們的常見問題，以減少不必要的工作量
同時，對于不少同學惡意的查找bug，亂報bug的行為，個人認為可以采用同學們曾經提到過的，每次測試後，由被測者給測試者打一個印象分，對于亂找bug的同學報以相對較低的分數，除了段位比對外，也增加印象分的比對，進而可以一定程度上限制一些同學亂報bug的風氣。