1、第四單元兩次作業的框架設計

兩次作業的框架設計是一脈相承的，第14次作業完全繼承了第13次作業類中的方法。

通過對UmlElement類的分析，直接將前一次作業中涉及到的9個類在構造方法中便分開并單獨存放，即分為了9個HashMap

? 因為一開始對查詢需求沒有做過多考慮，后續發現這種分離方式在一定程度上使查詢結果復雜化了，而一些結構也可以使用ArrayList代替，而不會增加時間復雜度。

? 在另一方面，為了存儲查詢過程中涉及到的中間結果，建立了ClassDate類來存儲，其內部主要數據結構如下：

private int operationFlag;private int operationNum;private int paramOperationNum;private int noParamOperationNum;private int returnOperationNum;private int noReturnOperationNum;private int attributeFlag;private int attributeNum;private int attributeMapFlag;private HashMap<String, AttributeClassInformation> attributeMap;private int associationFlag;private int associationNum;private HashMap<String, String> associationMap;private ArrayList<String> associationList;private int interfaceFlag;private HashMap<String, String> interfaceMap;

? 其中xxxxFlag代表此大項的數據結果是否被算出，而內部的數據結構則記錄具體的數目，自身名單以及包含父類的名單。在調用每個類/接口的查詢方法時，初次查詢，創建相應的ClassDate類，而查詢相應數據時，將其中的數據結構中的內容逐一完善。

而第14次作業在第13次作業的基礎上，僅僅是構造方法中的HashMap結構變多了，將所有有用的類單獨存放，而在查詢中沒有用到的類則直接舍棄，不會存入結構體中。

2、四個單元中框架設計及OO方法理解的演進

? 在前期的過程中，由于受到面向過程編程的長期影響，在代碼框架設計上并沒有很多的理解，將Class看作是實現所有函數的集合，而將所有需要實現的函數，均加到同一個Class中，沒有關注到代碼的耦合性過大。

準備階段

昨夜西風凋碧樹，獨上高樓，望盡天涯路

? 在之后的框架設計中，我更加注重了框架設計，在之后的作業中，有因為框架合理而后續作業幾乎不需要改動的情況，但也出現了其他的問題。例如：在第一單元最后一次作業中，由于前期沒有建立好良好的數據結構，對于層次分析的方法也不甚了解，最后靠兩天的完全空想完成了“有限狀態機”+“表達式樹”的方法，并且其中包含了大量的接口繼承。我同時和一些同學講述了這種方法，但自己其實沒有實現出具體的細節，僅僅是一個前期的框架。吳際老師在總結課上說的，所有沒有具體實現的框架都是沒用的，最簡單的驗證方法就是"show me your code."。我對這句話的感觸很深，在自己沒有思考清楚的情況下，給別人去講述自己的方法，簡直是害人害己。

醞釀階段

衣帶漸寬終不悔，為伊消得人憔悴。

? 第二單元的多線程調度，是對框架設計的一次很好的練習。由于對請求序列 / 總控制器 / 電梯調度器 / 電梯各自功能非常清晰。電梯僅僅充當一個根據主需求上下行的機器，而請求序列將所有請求加入總控制器，總控制器根據電梯的繁忙情況及現行狀態，將其分配到各個電梯的分調度器上。其中的耦合關系較小，僅僅在傳遞階段，各類分工明確。這三次作業是我充分認識到：一個好的設計框架在實際開發中將使你的修改事半功倍。

頓悟階段

眾里尋他千百度，驀然回首，那人卻在燈火闌珊處

? 將之后的框架設計看作是頓悟階段，其實是夸大事實的。只能說，由于在前兩單元的摸爬滾打，在最后的兩個單元作業中，我在寫代碼之前會更加注重SLIOD原則。并且在實現過程中不直接和大家分享我框架的先進性，更多的還是細節方面實現的交流。

3、四個單元中測試理解與實踐的演進

肯定

? 四個單元的測試環節是非常重要的。測試過程是真正開發中不可或缺的一環，在前期沒有JUnit單元測試的前提下，采取了肉眼測試的方法。通過閱讀別人的方法與注釋，感覺受益匪淺，從另一個角度看待了這個問題。

否定

? 之后通過和其他同學的溝通交流，逐漸掌握了更自動化的方法，包括使用matlab進行對拍，使用正則表達式構造樣例并使用shell進行測試，對比整個房間的結果。雖然一開始可以找到大量bug，但卻逐漸懷疑這種方法的科學性：我們僅僅機械地構造了樣例，卻沒有閱讀別人的代碼，更沒有從中獲取知識。

否定之否定

? 厭倦了這種機械式找bug行為后，一次分享課使我受益匪淺。那位同學在通過自動化生產樣例發現bug之后，會嘗試在別人的代碼中發現bug存在的原因，并嘗試在5行之類將其進行修復。在修正完畢后，繼續通過自動化樣例測試修正后的程序，如此一來找出的bug便幾乎不會出現同質現象。原來一開始的沒有收獲僅僅是因為自己的惰性驅使，自動化測試沒有錯，而使用自動化測試后沒有勤加思考才是最大的問題所在。

4、課程收獲與總結

? 在經過一學期的操作系統課程后，逐漸了解了真正的產品研發的步驟。通過第一單元的表達式求導，了解到用戶輸入的正確性判斷與錄入；而第二單元的電梯調度與操作系統的課程內容完美對接，可以從原理角度與高級語言實際實現角度雙管齊下，對線程概念有著更深的理解。第三單元的JML和第四單元的UML，一個用協議規范方法的實現，通過閱讀規格定義便可了解代碼的輸入，輸出，前提條件等必要內容；一個用圖的方式實現了框架的可視化，使我們清晰地了解執行順序和狀態轉變。

? 但對自己還是有一些不滿意的地方：原本計劃讀完讀透的《Java編程思想》因為課業壓力越來越大只能中斷，而最后的幾次代碼也沒有那么認真完成，摸魚情況時有發生，到強測完畢才發現為時已晚。而對于Java底層運行時間和CPU時間等并沒有充分思考他們與時間復雜度之間的關系，如何在保證程序正確性的前提下，將程序的CPU占用時間降低，需要以后更多的學習和思考。

5、課程建議

? 我認為今年的面向對象課程進行巨大的變革后，確實使同學們的滿意度大幅度提高，但還是有部分地方有所欠缺。

• ? 本學期面向對象的課上測試部分，基本上沒有什么體驗感，除后期幾次難度適中外，前期要么涉及到剛剛學到的知識點，要么工作量過大導致無法完成，還有少數幾次不知所措（多線程調度觀察）。希望可以充分考慮課上測試強度和其意義，將課上測試的機制做得更加完善。

• 在指導書發布階段，盡量少一些模棱兩可的解釋和例子，盡量細致，避免看完指導書還是不明真相的現象發生。

• 在涉及到多線程，UML等重要知識時，由于涉及的知識量過大，建議課上之前便發布一些簡明扼要的知識點概括，或者明確告知下次測試將涉及到哪方面的知識。對于一些軟件的使用，由于網上的方法多而雜，建議推出符合教程需求的教程。

  老師和助教對本課程的努力改善有目共睹，期待下屆的同學能在這門課中收獲更多，樂趣更多！

轉載于:https://www.cnblogs.com/ArthurN/p/11076520.html

總結

以上是生活随笔為你收集整理的面向对象第四单元（UML）总结体会课程总结的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。