【面向對象 第十五次作業】第四次博客作業
測試與正確性論證
效果差異
測試是試圖通過使用一些特定的、或是隨機的輸入，並預測代碼的執行結果，來對結果進行檢查。
正確性論證則需要對代碼的行為進行進一步的抽象，並考慮每個代碼部分之間的關系是否正常，是否存在潛在的問題。
前者的自由度很高，更加具體，但對潛在問題的覆蓋性稍差；後者需要的代價較大但固定，抽象性更高，覆蓋性很好。
優缺點
測試
優點：
- 容易構造
- 適應正常的開發過程，並能確定問題具體在實現中出現的位置
缺點：
- 覆蓋性稍差，提高覆蓋性所需的代價很高
- 容易找出問題，但修復問題所需的代價和代碼的規模相關
正確性論證
優點：
- 覆蓋性好
- 抽象性高，可以在設計之初來避免問題
缺點：
- 代價直接與代碼規模相關
- 抽象程度過高會導致與具體實現脫離，達不到效果
- 抽象程度過低則代價很高，與具體實現差別無幾
比較
代碼規模直接限制了尋找問題的代價。測試可以以較小的代價達到尋找表層的問題，正確性論證可以以固定的代價達到控制潛在的問題。
Object Constraint Language (OCL)
The Object Constraint Language (OCL) is a declarative language describing rules applying to Unified Modeling Language (UML) models developed at IBM and is now part of the UML standard.
（來自Object Constraint Language - Wikipedia）
如今，其標準由Object Management Group維護，OMG是一個非盈利的標準制定協會。
OCL來自wiki的一部分例子：
context Auto inv: self.registration>=self.constructionYearcontext Person inv: self.cars->notEmpty() implies self.cars->exists( c | Calendar.YEAR - c.constructionYear < self.age)
與 JSF規格 的異同
相似
- 兩者都可以用來描述對象及其行為的限制
- 均可與具體實現無關，僅限制前值和後置條件
不同
- OCL的標準更完善
- JSF描述Java代碼的規格，與具體開發關系密切；OCL的用途更廣，可以用於數據庫的查詢，與SQL均被劃為Query languages
- OCL的表現力更強，完善的標準也更容易實現解析；JSF要求過多，強制要求一階邏輯（及兩個謂詞）或自然語言，一階邏輯表達力差，自然語言難於解析
第十四次作業
類圖
順序圖
狀態圖
總結
四個單元模塊
大致可以分為 Java和面向對象基礎、面向對象與多線程開發、規格與文檔、測試與正確性論證。
關系
“面向對象與多線程開發”部分嚴格依賴於“Java和面向對象基礎的知識”；測試與正確性論證也依賴於規格與文檔的能力。
作業之間也明確地依賴於之前的作業內容或作業所需的能力。
梳理
Java和面向對象基礎沒有很多值得提及的，但是至少是我初次進行完整的Java程序的設計與開發。多線程的部分可以說讓我稍微接觸了一下Java在這方面的優勢，也大致地了解了很多並發模式可能的底層實現，雖然與面向對象的關系可能遠了一點。規格與文檔是我第一次知道世界上存在不是給其它開發者提供幫助的文檔，刷新了三觀。測試與正確性論證是我一直很希望能了解的內容，安排學習JUnit也是讓我很欣喜，這門課程竟然有如此正常的內容。
總體來講，開拓了眼界。
工程化開發
說些實際的話，根據計算機組成的實驗課以及這門課程的內容，可以發現高院長提出的“工程化開發”就是統一化開發模式；即對開發的幾乎個個層面上進行限定。面向對象的作業也很好地體現了這一點。
簡單地說，這種方式無法適應任何正統開發的需要，僅僅只適合於高校留作業。所謂的“各高校爭相模仿”也是基於這個原因，畢竟規範所有的步驟自然容易得到方便教學、方便評估的作業。那種“整齊劃一”的感覺也能很好地給評估者一種統治感，類似於中小學穿校服。問題自然也很明顯了，這種方式沒有一般性，並且若所要求的規範很不合理甚至自相矛盾，同時教師固執死板，結局就是如今中小學的校服情況。
課程
大開眼界，這是我參與的第一個內容與名字幾乎不符的課程。
理論課（除作業相關）和實驗課的內容還是相對來講非常完善，為學生的開發能力打下了基礎。
遺憾的是理論課的內容大量地描述定義和例子，很少提到面向對象的一些原則相對其他的開發方式的優勢和原則之間的關聯。僅僅只是定義和例子的話可以說與網上的“面向對象”內容幾乎一致，幾乎沒有優秀的一流高校應有的出彩點。同時關於Java的內容相對過少，內容的完善度甚至不及專科院校，缺乏開發的高級能力的培養；嚴重依賴於作業的內容，而作業的內容也不需要很強的開發能力。
實驗課的內容相比之下很適合學生訓練；作業也應當和實驗課的進度配合，而非提前或延後。稍稍有些問題的地方是，實驗課提供的代碼風格不統一，縮進不是很正常。
作業的話各個模塊需要的能力幾乎一致，並且很少有通過作業內容來體現面向對象的優勢，僅僅只是通過互測來強制要求應用一部分面向對象的設計方式，嚴重缺乏啟發性。並且因為互測，評分與導向性並不傾向於帶領學生提高代碼的質量，而是如何規避風險、實現若幹次大型的博弈場景。好事是幾次作業的情況，收集一下可能會輔助博弈論與社會學的研究。
期望與建議
規範用語（課程存在濫用詞語的情況，如語法樹），取消互測。
【面向對象 第十五次作業】第四次博客作業