測試與正確性論證

　　我認為第十三次作業的測試是基於規格通過測試用例對實現方法正確性的檢查。與平時測試時直接用數據輸入輸出判斷不同，本次測試針對每一個具體方法的實現，使用junit，能夠快速地定位到自己的bug。但是一旦代碼規模增大，測試很難做到覆蓋性的檢查。

　　正確性論證可以做到全面的覆蓋，我在論證過程中也找到了不少寫的不正確的規格。但是，它的工作量實在是太大了，除了單純論證還要重構代碼，好多方法的論證感覺並沒有什麽用。

　　這兩者配合使用，可以快速又全面地完成代碼正確性的檢查。

OCL與JSF

　　一個約束就是對一個（或部分）面向對象模型或者系統的一個或者一些值的限制。UML類圖中的所有值都可以被約束，而表達這些約束的方法就是 OCL。在UML2標準中，OCL不僅用來寫約束，還能夠用來對UML圖中的任何元素寫表達式。每個OCL表達式都能指出系統中的一個值或者對象。因為 OCL表達式能夠求出一個系統中的任何值或者值的集合，因此它具有了和SQL同樣的能力，也就是說OCL也是一種查詢語言。

　　OCL取了自然語言和數學符號的折中方案，使用普通的ASCII字符來表達數學中同樣的概念。

　　OCL是一個類型語言，任何表達式的值都是屬於一個類型的。這個類型可以是預定義的標準類型例如Boolean或者Integer，也可以是UML圖中的元素例如對象。也可以是這些元素組成的集合，例如對象的集合、包、有序集合等等。

　　OCL是聲明式語言，所以UML中的表達式被提升到了純建模的領域，而不必理會實現的細節和實現的語言。

　　相似：

• 　都有清晰的數學語義。
• 　都包含前置條件，後置條件和不變式。

　　不同：

• OCL有監護條件而JSF沒有，JSF有Modifies而OCL沒有。
• OCL更加復雜精細

UML類圖

UML時序圖

UML狀態圖

總結

　　1.單元模塊知識點之間的關系

　　第一單元是對基礎的java語言的訓練以及面向對象編程思想的熟悉，為後面的三個單元做了鋪墊；第二單元是集中的多線程訓練，是任務最重的一個單元；第三單元是對出租車的完善設計以及規格訓練，比第二單元稍微輕松；第四單元是測試的訓練，是對前三個單元的總結。

　　2.程序設計相關

　　第一單元我都是直接寫代碼，一個類方法幾百行，寫到一半發現不行又重新開始。從第二單元開始我先花時間把指導書看懂，明確需求。然後根據這個需求列出一個框架，根據框架進行細節擴充，不僅縮短了編寫代碼的時間，也減少了bug的數量，同時debug的過程也相比原來更加簡單，代碼質量有了明顯的提升。

　　在測試上，我覺得我這學期沒有多少進步，前三次作業用printf測試，覺得不太好，準備學學調試，結果就到了多線程沒法用調試工具了，所以我打算再學學調試。最後一單元學會了JUnit來測試代碼，還是比較方便的。

　　在設計上，除了第五次作業的覺得我的架構有點問題以外，其他的作業基本上都是中規中矩，按照指導書的要求設計的。有一次互測拿到一個8個包20個類的作業，研究了一下，覺得比自己的設計好太多了，以後要多學習學習。

　　3.工程化開發

　　我認為工程化開發不應該是一個人的事情，應該是許多人按照某種約定的規則去開發同一個東西。在實際的工作和產品研發中，我不覺得還有什麽事情比降低成本，提高效率更迫切的事情。我更不認同工程化只是項目經理，技術 Leader 去研究和推廣的事情。每個團隊都是不一樣，技術棧不一樣，產品不一樣，工作環境背景不一樣。大公司有大團隊，多部門合作。小公司有小團隊，各種職能配合更密切，或者你身兼數職，但是並不妨礙工程化的推進，作為團隊的一員，非常有義務和必要一起推進工程化，找到符合團隊的工作習慣和規範。

　　關於課程的工程化開發思想，說實話我並沒有體會到，也並沒有實踐。以我對工程化開發的淺薄的認識，我只能判斷出那個20個類的大佬的工程化開發思想應該是比我好太多了。

　　4.期望或建議

　　抱怨可能很多，但是建議好像沒有，畢竟我也想不出什麽好辦法改變這門課的制度讓同學們都很滿意。

　　完結撒花~~~

第四次博客作業