UML單元總結
架構設計
- 由於UML系列的類圖、狀態圖、順序圖之間彼此相對獨立，故從第一次作業到第三次作業均使用XXXManager進行分包管理，源代碼結構如下
![在這裏插入圖片描述]()
- 由於官方包的UmlElement並不能維護UML間的成員組成關係，故採用適配器模式將UmlElemen轉化爲NodeElement，建立方便維護的數據結構
- 從UML類圖上來看，MyUmlInteraction進行統一管理，將任務分派到三個Manager上進行數據管理，其中每個Manager都對規則檢查模塊PreCheckRuleManager有依賴關係，所有的Manager在對適配器Node進行構建時，都會使用PreCheckRuleManager進行檢查，並將結果保存到其中，調用時才拋出異常
![在這裏插入圖片描述]()
OO課程總結
架構設計與面向對象方法的演進
表達式系列
- 從面向過程到面向對象的思想轉變主要是在這個單元內進行的
- 表達式系列三次作業的層層遞進，每次擴展性功能的時候都需要修改大量代碼，在這個地方我意識到保留一些擴展功能接口的重要性
- 此外，我的作業都是採用 Expression, Term, Factor 的結構設計的，但經過第一次博客總結後，我意識到 對於架構的設計不必侷限與對應現實世界的實體，可以考慮儘可能抽象
- 利用組合模式進行設計，將組合項與項進行抽象，整體的架構設計能夠擁有更好的擴展性，也就是抽象程度和擴展性更高
電梯系列
- 這個單元我的主要收穫在於優化與架構設計的兼容性以及架構與性能的平衡
- 一個好的設計，一定是優化能夠方便地建立在架構上，並且這樣的優化策略能夠很好地擴展
- 此外，這個單元中我開始對設計原則的滿足進行追求，滿足大部分設計原則的代碼經過我的實踐後發現，出錯的概率大大地下降，而根據一些前輩們總結出來的設計模式，能夠獲得更好的魯棒性
JML系列
- 這個單元主要嘗試規格設計與具體實現分離的開發方法
- 架構上，採用了使用專用類進行包裝的方法，例如ShortestPathManager等，開始意識到數據管理的重要性，這也是面向對象的一種設計方法
UML系列
- 這個單元數據管理顯得尤爲重要，三種UML圖放在三個Manager中，各司其職互不干擾，再將公共的RuleCheck模塊放在外面，最大程度地封裝，十分便於數據管理
- 與JML系列類似，我也意識到了採用專門的算法類來完成一些相對獨立的任務
測試理解與實踐的演進
表達式系列
- 這一單元我的測試包括手動構造和隨機黑盒測試的結合，主要是在完善代碼的過程中想到的一些測試樣例
- 經過這個單元，我發現軟件開發的過程實際上並不是只有架構和代碼，更多的是測試的花費
- 測試包括了正確數據、邊緣數據和異常數據三類，而代價花費最大的是邊緣數據和異常數據
電梯系列
- 這個單元的多線程測不準原理給測試帶來了極大的挑戰
- 嚴格隨時間的輸入發生裝置對自動測試機有要求，由於這個單元的狀態多樣，經過實踐發現大量隨機測試的效果比較好，不能復現的多線程bug經過大量測試基本都能測試出來
- 另外我在這個單元的測試嘗試用了多進程的自動評測機，多進程自動評測機
JML系列
- 這個單元給我的最大感受就是，即使寫代碼的時候再怎麼仔細和自信，總在一個小地方會有意想不到的問題，因此我意識到測試無論如何都不能缺少
- 此外，這個單元比較適合基於JUnit的測試，而同時，一種測試方法不是萬能的，往往需要多種測試的方法結合起來使用，效果更加
- 以及JML規格給測試提供了一種新的思路，能夠在一定程度上減少隨機性帶來的不足
UML系列
- 這個單元我對測試有進一步的認識，主要是在正交實現方法的測試方面
- 由於這個單元所實現的功能比較基本，使用測試機無非就是把功能再次實現了一次
- 因此，這個單元的測試應該主要是對拍的方法，對於某個方法採用正交的兩種方式進行實現，測試的時候進行對比
課程收穫
- 總而言之，OO課程並沒有傳說中的難受，甚至還有些好玩，相比於OS實驗和編譯原理等，OO實在是太優秀太爽了
- CO、OS、編譯等經常需要在一個毫無意義的bug上吊死一天，
雖然OO有的bug也能吊死一天，但這樣的bug往往是設計上的缺陷，並且經過修復後在各方面都有很大的收穫 - 另一方面，課程中對於代碼量的要求爲今後管理大項目等有飛躍的提升，在架構設計上和代碼實現上都有巨大幫助，之前做一個Project類似於實現一個服務器集羣的同步控制算法，卻因爲面向對象功底的拙劣和大量工程代碼實現的不習慣而最終沒有做出很好的效果，經過這一學期的提升，自認爲現在再來實現一次這個算法輕輕鬆鬆不在話下
- 而作爲計算機科學專業的學生，各種程序的編寫不可避免，而這門課在debug上也做到了充足的訓練，幫助我們有一雙發現bug構造特殊情形的眼睛和嚴謹細緻的能力
課程建議
- JML在平常使用中感覺並沒有太大用處，只不過是將規格與實現分開了，並不能在規格層面保證沒有邏輯的問題，而且JML在同學們的心中風評也不是太好，個人感覺JML的語法十分繁瑣，表達個意思雖然嚴謹但卻非常麻煩。而且JML單元的作業感覺複雜度梯度也不是很高，建議將JML單元設置成兩次作業，最終實現的內容不變，這樣課程的整體就能少一次作業，爲烤漆其他課程留出複習時間
- 由於在作業已經佈置後又更改了指導書，每次都需要查看哪裏不一樣了，雖然並沒有改變大的需求，但總感覺心裏不踏實，建議儘量減少需求的更改，並在通知中具體說明更改的地方，而不是隻說“指導書有更改”
- 後期理論課的存在感不太強，並且UML單元作業的內容與理論課講的關係不是很大，建議提高研討課的時間，畢竟大部分同學聽研討課還是很積極，乾貨很多
線上學期體會
- 很爽的一點在於，看理論課的時間非常靈活，並且可以倍數看，有重點地在需要的地方反覆看幾遍，聽課效率大大提高！
- 但稍微不好的一點在於有時候因爲家裏的事情，耽誤了測試等環節，
大部分原因是懶了一手，造成一些巨大損失 - 總而言之，這學期特殊的體驗非常酸爽，願OO越來越穩！！，
不要放過學弟學妹們