北航OO第四單元——UML圖解析
阿新 • • 發佈:2021-06-26
北航OO第四單元——UML圖解析
作業要求簡析
- 剛接觸本次作業可能需要花上一會才能搞清楚到底是要我們寫個啥,在這裡簡單說一下:
- UML圖的儲存格式
.mdj
檔案是以json
檔案的形式儲存的,將每一個UmlElement
作為其parent
的屬性掛載到其中。可以自己隨便用starUML畫一個,然後看看原始檔內容 - 課程組將這一個個
UmlElement
單獨拿出來逐條輸入,以此在我們的程式中建立起UML類圖 - 然後輸入查詢指令,查詢有關於UML圖的各種資訊並輸出
作業思路及架構
-
由於許多大作業、考試全部堆在這幾個周,所以沒有對本單元作業進行良好的架構設計,整體的思路仍然停留在第一單元水平,十分慚愧
-
MUmlGeneralInteraction
- 此類是與官方包進行互動的類
- 內部屬性主要是幾個管理器和一個合法性檢查器
MChecker
:- 類圖管理器:
MClassManager
- 順序圖管理器:
MCollaboration
- 一組狀態機管理器:
MStateMachine
- 類圖管理器:
- 建構函式遍歷所有要傳入的
UmlElement
,根據其類的型別呼叫不同的add****
函式,講不同型別的UmlElement
傳給相應的管理器 - 詢問時則呼叫相應的管理器的相關方法
- 當官方包呼叫檢查方法時,呼叫
MChecker
中的響應方法 - 注:
- 管理器的查詢方法、合法性檢查器的檢查方法的返回值最好有一定的普適性,從普適性的返回值到官方包要求的特定返回值的過程在
MUmlGeneralInteraction
- 然而由於時間關係我並沒有這麼做 (0ω0)
- 管理器的查詢方法、合法性檢查器的檢查方法的返回值最好有一定的普適性,從普適性的返回值到官方包要求的特定返回值的過程在
-
建模思路
- 對類圖、順序圖和狀態機都是採用樹去建模的,儘可能地將子元素掛載到父元素節點下,從而將各個層次的方法分開
- 比如
MClass
和MInterface
繼承自抽象類MClassOrInterface
,其中包含了MOperation
、MAssociation
、UmlAttribute
等,MOperation
內再儲存了UmlParameter
。 - 這樣可以將各個層次的功能區分開,下級看不到上級,也不應該考慮上級
-
類圖管理器
MClassManager
- 類圖管理器儲存了一組
MClass
和MInterface
- 考慮到
UmlAssociation
Association
在樹中的層次提高一層,儲存到MClassManager
中,需要的時候查詢即可- 缺點:類或介面不知道自己有什麼
Association
,設計較不合理(但是為了趕時間所以就 (0ω0))
- 缺點:類或介面不知道自己有什麼
- 類圖管理器儲存了一組
-
其他:
- 順序圖和狀態機也是差不多的道理,不再贅述
- 第四次作業總體比較簡單,但是十分複雜,程式碼量比較大,寫程式碼時要一再檢查好要求
OO方法的演進過程(實際是吐槽)
-
第一單元的方程求導應該是OO思想提高最快的一個單元。由於上學期上過Java課,一些基礎的面向物件變成思想提前已有接觸,但第一單元各個環節巧妙地設計還是讓我很不好受。前一次作業的設計如果不能做大極大的可拓展性,大概率會被下一次作業逼著重構
-
很遺憾的是,從第二單元作業開始我覺得我編寫面向物件程式的能力已經沒有很多提升了。第二單元主要訓練了多執行緒,鞏固了第一單元的思想;第三、第四單元的程式碼練習過於簡單,演算法的重要性超過了設計,因此並沒有把精力投入到架構設計的訓練中了。
-
我認為第一第二單元的設計是最好的(雖然課程設計的時候可能十分困難),就是需要保證自己程式有足夠的可拓展性,後兩單元的作業在這方面做的過於簡單了,因此就讓人忽視了對架構的設計
-
另外,雖然學習了許多設計模式,但是除了幾種簡單的比如單例模式、工廠模式等,很難應用到自己的程式碼中
測試方法的學習歷程
- 這學期的一大收穫就是學會了如何編寫測評機
- 第一單元由於有python現成的庫計算正確結果,也可以根據正則表示式自動生成測試資料,非常方便編寫自己的測評機,獨立實現程式碼測評。
- 但是當不知道如何編寫標準程式,就陷入了不會寫測評機的困境。一直到第四單元我才知道一種東西叫做對拍機。他的思路非常簡單,將三個人及以上的程式碼放到一起跑,比較結果的差異即可。這樣,我們就只需要負責編寫自動生成測試資料的程式即可
- 另外,我還學習到了JUnit的使用方法,對自己的每一個方法單獨測評,可以“每一個方法體會一遍AC的快感”,體驗也是相當棒的
課程收穫:
- 建立了面向物件程式設計的思想,在編寫程式碼時首先想到的是低耦合性、功能分層、可拓展性等,現在看到不符合面向物件程式設計的程式碼甚至會噁心(x)
- 學習了各種測試方法
- 數量掌握了Java的使用方法
- 編寫之前先設計,設計包括功能設計、許可權設計、介面設計、互動設計等等。設計做好後編寫程式碼是水到渠成的事情。我認為這也是一條極大的收穫
改進建議
- 加大第三單元和第四單元難度,最好像第一單元那樣保證“前一次作業不好好設計,後一次作業大概率要重構”。逼迫同學們思考更優化的設計
- 減少演算法在作業中的佔比,比如第三第四單元海量的圖演算法(雖然大部分都是簡單的遍歷),取消一切考驗演算法效率的測試點。後兩次作業完全被寫成了Java語言演算法編寫,而不是面向物件程式設計
- 一單元作業結束後,可以講解一下標程的設計思想,這樣可以讓同學們學習到足夠優秀的樣例,我認為僅靠討論課是不夠的,就我們班來看,同學們的表達能力不足以清晰的解釋自己的演算法。
- 講解一下最後一次作業的官方包的設計,我認為這是很好的學習樣例
- 理論課的重複內容有些多,就是感覺同一個單元的三次理論課基本講的都是相同的東西