oo課的總結得與失是與他處的格局不同的，大概就是這樣一節矛盾的課吧，想要拿到襯衫就要許許多多個日夜看到沙河的日出，然而熬夜又熬夜之後脂肪卻先於知識囤積在了身上，望著被撐起來的報告bug襯衫，實在是感慨萬千，大概這就是oo課的“欲戴王冠，必承其重”吧。

測試與正確性論證的效果差異及優缺點

測試與正確性論證從思路上來說是完全不同的，測試仍然是一種將代碼看成黑箱的處理方式，將得到的輸入輸出與樣例進行對比，如果得到錯誤，為了報告bug再去打開黑箱。當然，我們在oo中的測試可能更偏向於面對代碼構造測試樣例，而實際中面對更長更加模塊分工的代碼，測試樣例的效力可能會大大下降。

而正確性論證，是將黑箱打開進行測試。一個方法我們要說明調用中不改變

OCL調研及與JSF的異同

OCL (Object Constraint Language) 即對象約束語言，是一種指示用戶建模系統中的限制方式，在在UML2標準中，OCL不僅用來寫約束，還能夠用來對UML圖中的任何元素寫表達式。每個

與JSF的異同：

相同：

均使用了數學的方法（謂詞邏輯、集合論）來表達對對象和方法的約束，都采用了自然語言和數學符號折衷的方式，使得用戶能夠使用普通的ASCII字符來表達數學中同樣的概念

表達式僅僅描述了應該去做"什麽"，而不是應該"怎樣"去做。不需要考慮這些表達式是以何種語言，何種循環去實現的，在共通的標準下達到相同的效果即可。

都包含前置條件和後置條件的聲明，也都包含不變式相關邏輯

不同：

OCL中沒有JSF的MODIFIES

第十四次作業類圖、順序圖、狀態圖

圖 電梯狀態轉換圖

圖 電梯系統類圖

圖 樓層請求時序圖

圖 發出電梯請求

學期總結

四個單元模塊知識點之間的關系

對於我的學習之路來說，我想起了華羅庚先生所說的把書由厚讀淺再讀厚的過程。在剛剛接觸面向對象思想的時候，是完全的生疏。此時的問題並不是說要怎麽建立隊列，數組，而是帶著根深蒂固的面向過程的思維（實際上c的學習也並沒有到融會貫通的地步），這裏這個方法到底和函數有什麽區別呢，這是完全不能夠理解的。而第一單元的學習主要是從框架的角度，引出了java的類，屬性，方法等元素，繼而介紹了繼承，多態等基於面向對象的思想而出現的知識。

第二單元的學習，開始了多線程的學習，然而有著多線程電梯和ifttt的這一單元是“淺”的，我們主要的訓練內容是代碼的熟練程度，回顧自己的博客，但是我的確是糾結於，隊列要怎麽建，掃描要怎麽掃，還為了正則匹配的bug，在幾次作業裏都被針對了。

第三第四單元的學習，又上升到了一定的層次。我們所學的這門課程是使用java語言授課的面向對象設計。前兩單元主要內容是“面向對象”與“java”語言，而後兩個單元，中心在編程上。對於單次作業是否通過來說其實這些內容並不是很重要，但是作為日後的準備，系統化，工程化的思想是無比重要的。

最簡單的例子就是solid到底是什麽，其實solid是什麽並不是很重要，只是一個定義，用法語寫也許就是另一個單詞。但是，程序員A與程序員B，他們的solid是否相同，這才是至關重要的，而為了讓所有人的solid都相同，就必須有一定的規範被明確定義。第三單元所講述的jsf規格，數據抽象等，就是在建議工程化的定義。Jsf就好像衣服，衣服是量體裁衣，但是反過來，很多時候對於衣服的考量也使得方法的表達得到了改觀。而第四單元是在沒有測試的情況下對於自己代碼的工程化考量。

自己的進步

其實這一點還是感觸最深的，雖然說了很多工程化，規格等等。但是這門課最大的影響還是代碼能力的提升。一開始的時候看到了代碼是這樣那樣，但是寫的時候add方法裏面，this.number這個this到底什麽意思，可以不可以換還思考了好久。仍然是show me your code這種學習方法收益最大，把樣例的代碼切實的敲出來，然後運行。比起腦中跑程序所能發現的問題和學到的東西要多的多。

隨著時間的推移，從傻瓜電梯的無效到最後出租車的2000行（雖然2個java文件加起來2000行是挺不好的習慣），我自己都可能驚訝自己的進步。最後拿到“菜雞進步獎”也還是很開心的，雖然熬了這麽多夜，體重漲了不少導致衣服很難穿的下。對於多個模塊的代碼，能夠掌握他們的功能（保證通過測試），確實是課程帶給我的提升。

工程化的理解

其實這門課很多同學的不滿之處就在於這裏，課程組將工程化的理念加入了課程設置，從課件到作業再到以互測為特點的課程體系本身，都體現著工程化的思想。然而同學們在此之前對於工程化很少接觸，之後也有一段時間暫時接觸不到。因此對於工程化是缺乏理解的。在我們的視角看來，接觸的不是工程化，而是jsf，repok，無聊的互測和單詞寫錯都會扣分。我們缺乏一根線把這些串聯起來，在和一些有實際經驗的同學交流後感受到，我們的能力和經驗的缺乏，是我們沒有辦法把這些看成體系，更沒有辦法去驗證工程化的意義在哪裏的一個原因，所以我覺得之後的課程中應該有一些變動，能夠讓同學們意識到自己在接受工程化訓練，而不是jsf和repok的訓練。

對課程的期望和建議

實際上感覺自己一直是以追趕者的心態去學習整個課程，因此更多的時候看到的是自己的不足。如果要說課程改進的話，似乎還是希望先導的體系能夠使得一些同樣基礎不高的同學能夠不會一上來就犯怵，在學習面向對象思想的時候不會因為代碼能力而先天不足。

當然互測一直是同學們所詬病的地方，個人信息導致無效似乎是個永恒的難題，另一方面在jsf測試的時候，我的一個number++這樣僅有一行的方法因為沒有寫jsf而被扣分，站在我的角度肯定是很難接受的，這樣一個錯誤和程序錯誤等價確實很難受，希望以後能在分值衡量上有所考量。

至於課程的難度分配上，在多線程這裏確實是突然拔高到不合理的高度，但是後面的內容也都是多線程的作業，不可能有所調整，也許和計算機組成一樣在突然的難度高峰這裏多放幾個星期會好一點。以及在上面所說的工程化的建議。

最後的報告bug