北航OO第四單元（UML圖解析）&課程總結部落格
第四單元(UML圖解析)&課程總結部落格
第四單元要求我們對UML圖進行解析，通過得到的UML元素構建起自己的UML圖結構，接收到來的指令對UML圖進行查詢。慶幸的是課程組已經給我們提供好了相應的解析器和輸入輸出介面，我們只需要完成構建圖結構的過程和介面中需要完成的相應查詢方法即可，總體來說難度不算很大。這個單元取消了互測，每天都是平安夜的感覺真好(￣︶￣*\))。這也是最後OO課程的最後一個單元啦，完結撒花~
一、本單元作業架構設計
這個單元的架構設計是我在四個單元中最滿意的一次架構設計，從本單元第一次作業建立好架構後，之後的兩次作業都沒有在整體架構上進行太多的改動，只是對類、儲存內容和方法進行了增量開發，就基本上完成了作業的要求。
第十三次作業
這一次作業主要是對UML類圖進行解析。這一次作業是在基物實驗考試的那一週佈置的，最後只留了一天的時間來完成這一次的作業，說實話比較極限，所以當時是從功能入手來建構的架構。之後再根據效能和可擴充套件性進行一定的修改。
這一次的作業主要是查詢UML類圖中：
- 類(Class)和介面(Interface)相關：類的個數、類的相連關係、類實現的介面、類的頂級父類
- 屬性(Attribute)相關：類的屬性個數、類屬性可見性、類屬性型別、是否滿足資訊隱藏原則（可見性均為private）
- 操作(Operation)相關：類操作個數、類操作可見性、類操作引數型別
根據這一點，我抽象出應該構建的類有：類MyClass
MyInterface、屬性（UmlAttribute已經夠用）、操作MyOperation等。然後再構建類與類之間的協作關係，這裡根據經驗我選擇使用樹形結構：在程式碼層級上，各個類進行組合和依賴實現樹形結構；在資料層級上，MyClass和MyInterface等之間實現樹形結構。每個類中配備相應的查詢方法和資料結構，互動類中一層層向下呼叫查詢即可。為了滿足效能需要，建立了相應的緩衝。考慮到可擴充套件性，我將類圖有關的所有資料和方法都封裝在MyUmlClassTree中，這樣在之後擴充套件其他圖功能時，可以降低各個類之間的耦合。
順便一提，由於輸入的元素順序是不定的，資料儲存的方便，在互動類的構造器中人為地控制了輸入Tree的元素的順序。
這樣構建出來的架構出乎我意外的還不錯，之後的作業架構會展開來說。
第十四次作業
如我上一次所料，這一次作業增加了對順序圖和狀態圖的解析。本來我已經做了對上次程式碼進行重構的心理建設，但這次似乎不需要。在上一次作業的基礎上，仍然依據之前的思路，我增加了：
- 狀態圖：
UmlStateMachineTree，狀態機MyStateMachine，狀態MyState，狀態轉移Mytransition。 - 順序圖：
UmlCollaborationTree，互動MyInteraction，生命線MyLifeline。
依然按照上一次作業的方法，控制輸入順序，每個類配備相應的方法和資料結構即可。不過在這一次作業中，出現了上一次作業的遺留bug，即緩衝的設定和使用出現了一些問題。
可以清晰地看到三種圖間的耦合性很低。
第十五次作業
這一次在之前的基礎上，增加了查詢前的錯誤檢測，實際上類似於先進行一通自動查詢，與之前的功能擴充套件沒太大區別，只是適當地增加了耦合性。所以架構上基本沒有變化。
這裡有一點需要注意的是，之前的UmlAttribute只涉及到類種的屬性，但現在在順序圖中也會存在UmlAttribute（且涉及到查詢），所以儲存時需要一定的區分。
二、四個單元中架構設計及OO方法理解的演進
一步步走過四個單元，我對“架構”的理解也是越來越明晰，也越來越明白架構的重要性。還記得之前老師說的，切忌拿到需求就直接動手寫程式碼。現在回頭看來真是如此，許多情況下，做好一個設計比完成一個程式碼更加重要。
第一單元，初步接觸“面向物件”，我彷彿一個剛出生的孩子一樣不斷地試錯、不斷地適應，奠基了這個學期的整個學習。從頭開始構建專案，從頭開始建立測試，同時面臨大段大段的指導書、面臨恐怖的強測和殘忍的互測，面臨卷而又卷的效能分，第一單元我過的非常痛苦。第一單元我也面臨了整個學期最大的一次程式碼重構，給我留下了很深的印象，從此開始重視“架構”的設計。OO是什麼，這一單元給了我一個非常基礎但非常明確的答案。
第二單元，是我學習到東西最多的一個單元。首先是多執行緒，看到指導書時我甚至連程式的基本輸入輸出該怎麼進行都不知道。多執行緒究竟是個什麼東西？這個問題從週三開始一直困擾到週日。必須感謝課程組設定的實驗課，讓我在絕望中有了一個模仿的物件，模仿中研究、學習，最終交上了一份有效的作業。其次是設計模式，在這個單元我接觸到了很多設計模式，像策略模式、狀態模式、工廠模式等等，有了這些作為支撐，架構設計顯得容易不少，突然就覺得OO是一個接近自己的東西了。當然還學到了很多演算法，這裡就不說了。
第三單元，我以為輕鬆但實際上分數最低的一個單元。JML規格是個好東西，但需要使用它的人對自己的頭腦時刻保持清醒。JML規格語言是設計和實現之間的橋樑，這意味著JML只關心程式的黑箱結果和正確性，不關心內部具體實現和效能。這一單元的架構基本都由課程組搭建，但我們仍需要根據效能要求對一些架構進行修改。這個單元似乎就與面向物件本身關係不大了。由於JML並不關心效能，如何優化演算法成為了這一單元的重點。
第四單元，UML圖解析完全扣緊了“面向物件”這一主題。無論是UML類圖、順序圖還是狀態圖，都是平時面向物件設計時非常重要的工具，對它們進行解析分析，更加加深了我對面向物件這一概念的理解。架構設計在上一部分已經講述，這裡不再展開。
三、 四個單元中測試理解與實踐的演進
“測試”這個過程真是貫穿整個OO的課程。在上OO課之前，我對測試的理解就是類似於“考試”，好像測試是程式設計師的一生之敵。但我逐漸發現並不是這麼一回事（雖然我還是非常討厭互測）。
在OO之前，我的認知中測試就是黑箱測試，即給出一個測試資料到程式，對比實際輸出是否與期望輸出一致。但測試的內涵遠不止於此，測試還包括了白盒測試、效能測試、程式碼風格、記憶體測試等等，涵蓋了各個方面。第一單元的測試是我比較熟悉的，即每個樣例都有一個“標準答案”，但到了後面的單元，就不再存在什麼“標準答案”了，或者說重點已經不在於“標準答案”了。例如第二單元輸出並不重要，而是輸出的時間；第三單元輸出也有正確性，但對效能的要求更嚴格……到了後期，已經沒有所謂的標準答案可以參照，測試更多的變成同學之間的“對拍”。
測試的主要方法，一是手動構造資料進行測試，這種方法最簡單、最直接、也最能控制，但缺點就是資料量不大，測試不一定充分；二是進行黑箱測試，這一般依賴評測機自動構造資料、自動測試，能大量地進行測試，但搭建評測機並不簡單；三是單元測試（白盒測試），這一點上JUnit是一個很好的工具，根據程式碼內容來進行測試。
四、課程收穫
這一點在上面兩個部分中穿插著講述了，這裡就不再單獨說了。總的說，OO無論在程式碼編寫上、程式設計上還是思想上都有很大的提升。
五、 對於課程的具體改進建議
- 建議明確課程評分標準。OO課的評分標準一直是一個非常困擾的問題，由於OO課本身內容就很多，包括課堂、作業、實驗、研討，其中作業中又有弱測、中測、強測、互測，各個測試中又有各種評分規則。助教和老師又從不透漏各個部分的具體佔比、具體演算法（或者給出一個公式但公式中不給出具體的數字比例），這讓學生很迷惑。儘管學生上課的重點是學習而不在於成績如何計算，但這是學生應該知曉的內容，課程組應該決定好具體數值並進行公佈。有助教透露xx部分比xx部分佔比更高，這種資訊是學生應該有渠道知道的，而不是像祕密一樣由學生猜測。
- 建議優化互測體驗。我認為，互測的目的應該是讓同學們互相之間能夠學習，而不是讓同學們互相“作對”。現在的互測，我只感受到了同學之間的“心狠手辣”，沒有感受到“互相幫助”。首先，我認為，可以用加分來激勵大家閱讀和測試他人的程式碼，卻不應該用扣分來打擊出現bug的同學。即使要進行扣分，也應該使得加分>扣分，使得互測整體是正和的，而不是零和的。其次，應該在互測內增加同學間的交流，即提供一個被hack的同學學習交流的機會，讓他們能更好地優化自己的程式碼。例如hack的一方可以選擇性地提示被hack的一方是哪個地方出現了錯誤等等。
- 建議增加實驗的講解。不得不說現在的實驗確實能給到同學很大的幫助，但實驗課下課後就完全關閉，這一點非常讓人遺憾。如果在實驗結束後，可以得到一份供參考的答案（或者一些提示），會給予同學更大的幫助。尤其是實驗是填空型的題目時，同學們迫切地需要驗證自己的思路和想法是否正確，這樣才能更好地確認自己學習是否達到了效果。如果能在適當的時間（比如實驗結束後的第二天、實驗結束三天後等），公佈實驗的參考答案、參考程式碼、參考思路，那麼實驗課能發揮更大的作用。當然，如果實驗課能有一定的講解，那就更好了。