OO終章--總結博客

1、測試與正確性論證的比較

        從方法上看，測試是使用大量測試樣例來覆蓋測試代碼，從而可以檢測代碼的實現是否正確，功能是否完善。而正確性論證是使用代碼的規格和邏輯進行嚴密的推論和證實，從而驗證代碼的實現正確性。從優缺點來看，測試的優勢在於可以直觀地看出測試的結果是否正確，而缺點在於難以構造覆蓋完整的測試集；正確性論證的優勢在於可以保證正確性和覆蓋率，可是不夠直觀，並且論證錯誤不易察覺，也就是不易二次檢查。

        所以，在對一個程序進行設計測試檢查的時候，須要兩者同時使用，相互補充，使用測試集測試程序功能的完備性，使用正確性論證驗證代碼的邏輯正確性和嚴密的覆蓋全部代碼，這樣才能對程序進行充分的測試驗證。

2、OCL與JSF的比較

        OCL，即Object Constraint Language, 中文譯爲對象約束語言。OCL是一種用來在指定的模型單元上施加約束的語言。同時OCL也不只用來寫約束，還可以對UML圖中的任何元素寫表達式。OCL是約束和查詢語言，有一個形式化的數學語義，而且容許用戶定義本身的OCL符號集。

        與JSF的相同之處：OCL和JSF都是形式化的語言，都有一樣的規格即前置、後置條件以及不變式。

        與JSF的不一樣之處：JSF基本上使用的是邏輯表達式，少許使用天然語言。而OCL的表達式具備類型，且數據也有基本類型，這點和JSF有較大區別。

3、UML圖

        類圖：

        時序圖：

       狀態圖：

4、學期總結

    1. 知識點總結：

        第一階段：從多項式加減到ALS電梯，一個入門的階段，主要的知識是面向對象編程的思想，以及java語言一些基礎的語法，好比正則匹配等等，較爲簡單，屬於經驗怪，前期給玩家升級用的。

        第二階段：從多線程電梯、IFTTT到第一次出租車做業，一個逐漸熟悉的階段。主要講解了多線程的機制，競爭和同步機制、文件監測和操做等等知識，同時對規格有了必定的要求，代碼質量也更高了。這屬於精英怪，對於在第一階段沒有花時間認真打怪升級的玩家來講，可能就會被這個階段的精英怪秒殺了，而後消耗一次復活（無效做業）的機會來從頭打怪升級，苦肝到深夜。

        第三階段：對出租車進行功能上的完善，添加了許多功能。這個階段主要是對程序有了規格化要求的設計，包括JSF規格的書寫，和程序的規格化設計，在整體的代碼量上也有顯著提高。屬於boss級別的怪物，須要苦戰幾日，熬夜連戰，才能最後幹掉boss。

        第四階段：這個階段的主要做業是對以往的代碼進行驗證和測試，以及正確性論證。雖然整體做業量小了不少，不用寫大量代碼，也不用構造複雜的結構。可是這個階段的知識是很重要的，放在課程的最後，重要性也不言而喻。

    2. 我的總結：

        從一開始的多項式加減，到最後的功能強大的出租車，總共9次編程做業，說多很少，說少很多，總而言之，對於個人編程能力仍是有較大提高的。最開始的做業，對於面向對象的思想仍是不夠理解，寫出來的程序只是有面向對象的外殼，可是實際上仍是一個面向過程的程序，一個方法佔了100多行，質量也不高，debug還十分困難。到最後幾回做業時，對面向對象已經有了比較深刻的看法，對類和方法的區分比較嚴格，方法的代碼量也很少，嵌套深度也少了，把各個模塊和功能安排得比較明白，質量有了明顯的提高，debug也容易多了。儘管如此，但仍是有一些不足的地方，須要更深刻的學習。

    3. 工程化開發：

        我認爲工程化開發就是，首先須要規範設計好每一個功能的規格。而後將各個功能的實現分發給不一樣的程序員實現，團隊的各個成員負責本身的模塊，同時又能夠相互協調合做，提升整體效率，下降成本。在此基礎上，良好的規格化設計和封裝是必要的，大部分程序須要實現大量的功能，這對於工程化開發是必不可少的條件。

    4. 對課程的建議：

        其實要說平時的吐槽倒挺多的，真要給實際建議的時候，還找不到幾條。首先就是指導書的問題，我相信絕大部分的同窗都會提到這個，指導書寫的實在是很粗糙，對於一些細節上的問題，還有幾回做業的扣分點都交代得不清楚。有不少次狀況就是，一些摸棱兩可的問題，一開始說readme自行定義，而後發現這些條件又是必要的，在提交做業前忽然通知說要改指導書的內容，這讓不少同窗心態會崩的。還有就是在issue裏提到要更改的地方，沒有正式的通知，最後詢問獲得的結果是本身沒看issues。雖然有各類吐槽，但確實找不到更好的替代方法，包括互測的面向運氣得分機制。但願學弟學妹們能存活吧。。