OO第四次總結

1、測試與正確性論證

    程序的測試分爲大小不一樣的幾個階段，咱們在這個階段的做業中進行的是基於JUnit測試框架的單元測試。

    單元測試是指對程序中最小的可測試單元進行測試。咱們測試的單元是方法。單元測試的特色使是從結果出發，尋找代碼的漏洞。一個全面的單元測試可以對覆蓋到方法執行過程當中遇到的全部狀況，也就是覆蓋全部分支條件。經過單元測試則說明該方法可以徹底符合指望的規格。所以，單元測試的優勢是可以確保一個方法的正確性。然而構造一個完美覆蓋的單元測試很難，尤爲是當原方法的分支條件不少的時候。編寫單元測試一般要花費比編寫原方法更多的時間。

    正確性論證也是證實方法是否符合指望規格的手段。與單元測試從結果出發不一樣，正確性論證是從代碼邏輯出發，論證方法如何完成規格。正確性論證更像是數學中的證實題，須要嚴謹嚴密的邏輯思惟。完成正確性論證的前提是對代碼邏輯徹底掌握。

    正確性論證可以對全部分支進行論證，較單元測試來講更容易達到徹底覆蓋，然而正確性論證過程較爲複雜，相比單元測試"粗暴"地判斷對錯來講更難保證論證結果的正確性。

    因爲兩者具備各有優劣，能夠互相補充，兩者兼用可以更充分的保證代碼的正確性。

2、OCL語言

    OCL(object constraint language)語言即對象約束語言。它是一種用於約束指定模型的定義，形式化的沒有二義性的語言。

    OCL擁有本身的語法體系，有數據類型和運算符，更優高級數據類型例如羣、集合、袋和序列。在對象約束方面，OCL表達式包括不變量、前置條件和後置條件等。

    OCL同咱們學習的JSF用途相同，都是用於描述對象的約束規範的形式化語言。用兩者描述的約束都是沒有二義性的。不一樣的是，OCL有一套比JSF更加完備高級的語法結構，而JSF只有二階邏輯結構，沒有高級的分支語句等，也沒有對數據類型的描述。

3、單電梯系統模型

UML類圖：

UML順序圖：

UML狀態圖：

4、學期總結

知識點梳理

    課程分爲四個模塊。

    第一個模塊主要熟悉面向對象編程方法以及對象機制。這個模塊是對java語言和麪向對象的初步接觸。

    第二個模塊是多線程編程，以及線程安全問題。這個模塊訓練了多線程的思惟。

    第三個模塊是規格設計。這個模塊咱們將代碼規範化，使代碼更加規格化、模塊化。

    第四個模塊是基於規格的測試與論證。這個模塊學習了更加嚴謹規範的測試方式。

    能夠說這四個模塊之間就是四層積木的關係，層層遞進，讓咱們從零開始體會面向對象程序從構思、實現到測試的完整過程，並在這個過程當中逐漸強化面向對象的編程思想。

進步總結

    在此以前徹底沒有接觸過面向對象有關知識，編程還停留在一個程序幾個方法的過程式編程中。在第一次多項式的編程中，我僅僅使用了兩個對象，且沒有作到對象的封裝，這兩個對象之間相互調用，邏輯十分混亂；第三次ALS電梯在重構以前更是在調度類中一個方法寫了兩百多行，徹底沒有作到方法的抽象，致使程序十分臃腫，不少BUG發現了卻沒法定位修復；

    從多線程電梯開始決定優化代碼結構，至此開始，之後的做業中慢慢造成了面向對象的基本思想和思路框架，代碼結構也在一次次訓練中獲得改善。

    總的來講進步很是明顯。經過這門課程的高強度訓練，如今可以比較完整的從問題中抽象出對象並進行模塊化的編程，代碼的規範程度也有很大提升。但仍有不少不足之處，例如對接口的理解感受不是很深入。

對工程化開發理解

    工程化即系統化、模塊化、規範化的過程。指將具備必定規模數量的單個系統或功能部件，按照必定的規範，組合成一個模塊鮮明、系統性強的總體。工程化開發的關鍵是封裝，將各類資源封裝成一個個模塊以後，咱們沒必要再關心該封裝下的具體細節，只須要將這些模塊組裝成一個總體就可以造成一個完整的工程。

    面向對象的設計原則與工程化開發中模塊化的要求不謀而合，然而面向對象設計缺少清晰的層次關係，面對複雜的操做過程時實現效果不佳，涉及多個對象之間共同協做時也會顯得不那麼靈活，這是面相對象設計的一個不足之處。

    規格設計是工程化開發最重要的一環。良好的規格約束可以便於團隊合做與相互理解，實現更好的協做關係。

對課程的指望與建議

1. 儘量在最初介紹更多的關於java語言的知識，或者哪怕提供更多資料也能夠。
2. 但願可以有更多更完整的程序實例和講解，現有的ppt上的例子對於做業來講徹底不是一個層次上的，致使咱們拿到做業的時候感受難度的跳躍很大。特別是多線程部分，我想多一點複雜的多線程程序例子對於咱們理解多線程操做來講更有幫助。
3. 關於互測部分，特別是規格互測的時候，惡意亂報規格BUG的現象比較嚴重，我認爲在報告規格BUG部分的機制欠妥。
4. 仍是互測，我提出一個關於issue的問題。對於指導書沒有規定的內容，不少徹底能夠自行定義而不影響整個程序的正確性的問題，因爲助教一句話咱們就只能根據助教的理解方式修改程序。有時候這種修改須要花費不少精力，甚至更改整個代碼的結構；甚至有一次因爲助教理解錯誤形成我改過去又改了回來。。。我認爲這些邊角部分的問題不影響教學核心，能夠給予咱們充分的自由。不然這些東西會在無形之中增長咱們的負擔，自己課下任務量就很大，這些本來很小的問題可能會打擊對課程的熱情和積極性。