BUAA-OO 第四單元做業 UML 總結與思考 & 結課學期總結

寫在前面

OO結課散花~

蟹蟹這一個學期來並肩奮戰的小夥伴們~

藝雯，毅飛，鄭奕，xg，雨桐，小丁，花花，xsy，zyy，wsb，zwc，dyh，lmz，qzz學長等等等等~

蟹蟹你們給個人幫助~(｡･ω･｡)ﾉ♡

目錄

1、第四單元做業需求分析

2、第四單元做業思路分析

一、基於度量的程序結構分析

二、BUG分析

三、架構分析

3、前四單元總結

一、架構設計及OO方法理解的演進

二、測試理解與實踐的演進

4、收穫與致謝

5、一點建議

1、需求分析

實現UML類圖解析器，要求:

(1) 能夠經過輸入各類指令來進行UML類圖有關信息的查詢。

(2) 支持對UML順序圖和UML狀態圖的解析，並可以支持幾個基本規則的驗證。

2、思路分析

一、基於度量的程序結構分析

代碼行數統計（利用Statistic插件）

第一次

第二次

 

代碼設計複雜度（利用MetricsReloaded插件）

ev(G)基本複雜度，用來衡量程序非結構化程度

iv(G)模塊設計複雜度，用來衡量模塊斷定結構

v(G)獨立路徑條數

第一次

第二次

 

二、BUG分析

這兩次做業的弱中測和強測都順利經過，但沒少經歷坎坷，第一次做業在南昌的火車上和賓館裏肝了三個夜晚，最後一天晚上9:50才提交了修改完致命bug的版本。而第二次做業用一天寫完，卻在馬原考試前的晚上12:00發現了bug。

感謝%%少布和%%花花的對拍器，幫我de出了不少bug。

除對拍的方法外，此次做業用JUnit單元測試來進行正確性驗證也十分合適。

第一次：

強測中得分 100

對拍中發現的問題：建圖時要注意讀入處理順序。由於attribute隸屬於class，parameter隸屬於operation，因此必定要先把底層的指令預先讀入。

第二次：

在強測中得分 100

對拍中發現的問題：

1. tarjan算法dfs時class與interface的屬性數組用混了。

2. tarjan算法沒有考慮自環狀況（R002）。

3. R001沒有考慮本身繼承本身的狀況。

4. 命令行參數的使用

 

三、架構分析

第一次：

第二次：

 

1. 第一次做業要讀懂需求，主要是每一個元素的id惟一，而name可重複，故用兩個hashmap來維護類：

private HashMap<String, MyClass> clist;//id-->class
private HashMap<String, MyClass> cnList;//name-->class

因此在處理異常的代碼段以下：

private MyClass checkClassException(String className)
        throws ClassNotFoundException, ClassDuplicatedException {
    if (!cnList.containsKey(className)) {
        throw new ClassNotFoundException(className);
    }
    if (cnList.get(className) == null) {
        throw new ClassDuplicatedException(className);
    }
    MyClass cls = cnList.get(className);
    return cls;
}
​
/*
       MyClass cls = new MyClass(e.getName(), e.getId());
       clist.put(e.getId(), cls);
       //在dup時加入null:
       if (cnList.containsKey(e.getName())) {
           cnList.put(e.getName(), null);
       } else {
           cnList.put(e.getName(), cls);
       }
*/

第二次做業同理。我複用了第一次做業的代碼，而且用package創建了一個更爲清晰的結構:

↓

 

2. 關於類與接口間的行爲有必定的類似性，能夠創建一個抽象基類來提取出相同的部分統一處理，避免重複編碼。

   二者不一樣之處在於對繼承關係的處理方面，類只能單繼承，而接口支持多繼承：能夠將繼承關係和實現關係抽象成有向邊，轉化爲樹/圖模型。而後無非就是建樹（建圖），遞歸找父節點（前驅結點）的工做。

3. 而圖和樹結構的建模和運用在第二次做業中體現得更加明顯：

   狀態圖和順序圖的兩個主要元素能夠抽象成點和邊，這樣查詢任務和合法性檢查任務就迎刃而解。

   我用了最熟悉的Floyd處理連通性問題，tarjan算法求強連通份量（找環）。

 

3、四個單元的總結與反思

一、架構設計及OO方法理解的演進

第一單元 多項式求導 面向對象架構

讓我深入地瞭解了面向對象來架構程序的思想，給了當時的我很大的衝擊。再加上當時對java語言的運用還很吃力。如今還能想起來當時榮老師在課上對繼承和接口的講解給個人那種醍醐灌頂的感受。

經過了解編譯原理中的遞歸降低算法，更好地分析出了多項式的結構層次。

也是我第一次瞭解了設計架構、測試優先的重要性。

在具體的實現過程當中運用了工廠模式。

第二單元 電梯調度 多線程

多線程做爲一個」新世界「，編寫代碼的思路和debug的方法相較以往都有很大變化。

而多線程的設計模式是幫助我更好更快地上手編寫多線程程序並保證邏輯正確性的必要工具。

同時我也對線程安全的容器有了必定的瞭解。

其次，決定此次做業得分的還有調度算法的取捨。怎麼保證在廣泛的狀況下(≈數據隨機)得到更好的執行效率，是很實際的問題。有趣的是，電梯調度算法的來源居然是操做系統的磁盤讀取算法LOOK和SCAN（os亂入片場

第三單元 地鐵線路 規格化與單元測試

第四單元 UML解析器 UML

這兩個單元畫風比較相近，對面向對象的架構要求不高，而重在幫助咱們熟練掌握JML規格和UML圖這兩大工具。

編寫實際場景下運用的程序比單純地寫規格和畫圖，對我加深理解的幫助更大。

第三單元難點在於實際場景下的算法模型創建，而第四單元則延續了對圖和樹這兩大重要結構的考察，彌補了大一程設和DS有始無終欠下的「圖論債」。

同時，在爲了知足性能要求須要大量使用、合理選擇java容器。經過用java容器來高效實現c語言中的圖論算法，我對java編程的熟練程度也增長了。

二、測試理解與實踐的演進

在強測中wa了兩次，分別是第一單元第3次做業和第二單元第3次做業，內心有點難受，本身本能夠作得再好一點的。

第一單元 多項式求導

此次的對拍任務很容易藉助python的算術功能來完成，我經過構造易錯數據、編寫對拍程序來進行了簡單的對拍，但沒有進行細粒度和大批量的測試。

第二單元 電梯調度 多線程

開始完善本身的評測機。但架構和編碼時間有點長，直到最後一天晚上才進行性能測試，致使時間不夠優化算法。並且最終仍是在處理換乘問題上出現了紕漏，反映出本身的數據生成器仍是不夠強，粒度也不夠細。而且缺乏靜態差錯的環節。

第三單元 地鐵線路

直到我在第三單元中學習了單元測試的方法，前兩次對於測試的困惑終於獲得了一個解決方案！

嘗試編寫了單元測試程序，同時也利用本身的評測機進行了對拍。

第四單元 UML解析器

通過一個學期與bug抗爭的過程，我認爲一個完整的測試過程應該是這樣的：

①coding前構造通常數據與極端數據，力圖全部狀況後再選擇算法和架構

②coding時，一個功能模塊編寫完成後進行單元測試，經過後再進行下一個模塊的coding

③coding後進行靜態差錯，確保代碼實現與思路一致，結合小黃鴨調試法食用味道更佳（

④用coding前構造的數據進行簡單的正確性驗證

⑤編寫數據生成器，進行對拍驗證，本地測試程序的運行效率與在「大「數據下的執行效果（能夠按照功能分批進行測試）

 

4、課程收穫/致謝

一、oo這門課讓我瞭解了面向對象的思想，以及初步感覺到工程項目與以往所編寫的程序的不一樣。

從最開始的每次重構、看到代碼量大的項目根本無從下手、談」蟲「色變不知從何處de起，到掌握了必定的java語言基礎、設計模式、測試方法，懂得算法如何運用到實際場景中，也學會了簡單的腳本的編寫。

課程組對checkstyle的重視，也讓我養成了良好的代碼風格習慣。

你們在討論區中的發言，不管是解決問題的思路，仍是一些黑科技，也都給了我很大的啓發。

二、同時也更深入地意識到了本身還有很長的路要走。zsa說」窮則思變，而不是窮則思易」。這句話我發自心底地贊同。對於每一次做業，強測只是規定了能力達標的「下限」，而想要寫好代碼，其「上限」是無止境的。

三、感謝老師和助教的辛苦付出。指導書等有紕漏在所不免，課程組對待問題的態度讓同窗們很信任和安心。同窗們對課程的重視和認真也來源於課程組的重視和負責。

四、一些碎碎念：

如今耳機裏播放着哥哥的《怪你過度美麗》《追》，忽然有點想流淚。oo填充了我這個學期一半以上的生活，開學時看到每週時間線望而生畏的我，如今忽然以爲很感激，如果沒有這樣的課程壓力逼着小夥伴們寫代碼debug極限互測，就算會逃避掉不少的痛苦，快樂亦會不復存在吧。

cmx說，coding大概和寫文字有些類似，都是須要「工巧心」的事情。

想明白了這點，不管面前的代碼再如何的支離破碎與混亂不堪，也不會以受難者的心態對待了。

"一想起你如此精細 其餘的一切 沒一種矜貴 "

反倒會以爲，任何本身沒有打磨好的代碼，都會愧對了這份情愫吧。

 

5、一點改進建議

1. 四個單元的做業難度最好有層次梯度，按部就班，而且可以迭代式上升。好比第一單元對面向對象架構的要求能夠稍微弱化，後兩單元在特定的單元主題要求以外，還要強化對面向對象架構的考察。

2. 實驗課內容很好，能夠幫咱們鞏固課堂上老師教授的理論知識。可是實驗課結束以後得不到結果反饋，考察的題目依舊不懂，甚至實驗結束後沒法看到題面和知識點總結，沒法有效地學習鞏固。

3. 我認爲每一個人完成的做業代碼能夠開源，這樣可以擴大同窗間交流學習的範圍，同時這種自發性的交流分享可以讓助教篩選優秀做業的工做輕鬆不少。多閱讀別人代碼，可以提高本身的代碼能力；而在網絡上又很難找到和oo做業所需內容契合的代碼，致使同窗們在沒有面向對象基礎的狀況下只能YY，結果就是交上去的代碼寫得很醜而不自知。至因而在什麼時間讀、以何種方式讀（是大腦空白借鑑別人的思路，仍是在完成本身的代碼後學習別人的實現方法，抑或是給別人找bug），由同窗們本身來決定，只要恪守不抄襲的原則便可。

   若是出現抄襲行爲，對於類似代碼是誰抄襲的評判，能夠經過上傳的時間前後來判斷。

   這個回答或許能夠成爲一個解決方案

4. 老師們能夠了解一下每次做業的內容。課件應該是老師作的，而指導書應該是助教們寫的。課件中的內容和做業內容雖然大致類似，但沒法真正銜接上。同窗們在完成做業時沒法運用課堂上收穫的知識，老師解答同窗的問題時也只能給出大致思路。若是能針對同窗在本次過程當中遇到的具體問題給出具體的解決方案，或許能夠達到「窺一斑而見全豹」的效果。