面向對象Uml單元及課程總結

 

Uml單元做業架構設計分析

第一次做業架構分析：

類圖：

 

總覽圖：

總結及分析：

　　這次做業的要求是查詢給出的由uml類圖解析出來的文件包含了多少個類，每一個類的屬性，操做以及操做可見性、關聯對端、接口的實現和繼承狀況等等共計十條指令，所以在最初設計架構的時候我以爲把元素分紅類和接口兩大類比較合適，所以有了上圖總覽中的TryClass和MyIntergrace兩個本身定義的類，分別用來實現類和接口相關數據的整合，這是一個總的框架，大體是把數據分散到不一樣的子樹下，而後在MyUmlInteraction裏面進行查詢數據的操做，該類中只保存數據的索引列表。

　　在進一步實現的時候，我考慮到查詢和存儲以及時間性能的須要，決定在查詢機制中採用電梯的調度策略，在進行一次查詢的時候存儲通過的全部可能被查詢的中間值，這種策略相比於構造時一次性計算出查詢結果，提升了性能，但也帶來了代碼量增大的問題，所以，我考慮到將MyUmlInteraction裏面用於計算的部分也遷移到對應的TryClass或者MyIntergrace類中，將數據和查詢部分完全分離，可是考慮到代碼已經基本完成，就沒有再進一步優化，只是簡化了MyUmlInteraction中的HashMap索引結構。

　　算法部分，一部分查詢計算爲了簡化代碼和電梯算法實現緩存的緣由，採用了遞歸算法，最終問題也就出如今了遞歸算法上，也就是遞歸的起始，過程，返回與復原並無處理好，致使出現了一些問題，該部分在下一次做業中受到了重視。

第二次做業架構

類圖：

總覽圖：

 

分析及總結：

　　第二次做業在第一次做業的基礎上增長了三條狀態圖的查詢指令、三條順序圖的查詢指令和三條規則檢測，所以能夠直接將第一次的代碼複用。但因爲規則檢查須要用到第一次代碼的一些數據，所以沒有采用繼承的方式，同時，又以爲改爲數據和查詢分離的模式更改部分太多，擔憂出現錯誤，所以，將部分第一次做業代碼寫入Lib這個類做爲方法調用，同時在實現第二次做業的時候徹底採用了樹形結構，在做爲查詢類的MyUmlGenerallnteraction中只保存了用來檢索數據的索引，方法直接調用對應元素類的方法，也就是計算只在MyUmlGenerallnteraction的下級進行，本級只進行單純的查詢操做。更改成這種模式的架構後，代碼的解耦就很順利，層層分離，對下級方法只須要傳遞元素的索引便可，層次比第一次做業清晰。

　　這種架構模式帶來的體驗就是，在修改代碼時不會出現粘連的情形，逐行排查代碼問題的時候也不會影響上層或者下層代碼，無論是排查仍是修改層次都變得很清楚，我認爲是一個比較完善的架構。但存在的麻煩是，對於輸入數據的處理沒有解耦，依然是一個大塊，這一點由於影響不是很大就沒有解決。

四個單元架構設計及OO方法的理解：

第一單元做業：

　　雖然第一次做業歷時比較就久遠了，但依然給我留下了較深的印象。按照最後一次理論課的說法，第一次做業是逐步引入不一樣的項而且逐步引入組合規則，可是，我實際完成這三次做業並非這個感覺。第一次和第二次做業個人重點基本上都在正則表達式的運用上，以後對數據的推理和數據的處理反而在其次，第一次做業我甚至只提交了一個類就完成了全部的工做，根本不可能有什麼層次化抽象和歸一化處理，並且這一單元重點介紹的繼承和接口在前兩次做業中根本沒有用過。

　　而後就是給我留下了深入印象的第三次做業，從看完指導書到結束設計開始進入編碼，這一過程我用了兩天，也是這兩天我基本搞懂了什麼是層次化抽象，以及繼承和接口究竟有什麼用，而對OO的模糊認識也有了一個較大的飛躍，從一個文件一會兒跨到了9個文件，開始習慣從邏輯上對需求進行分層和分類，而不是和之前同樣直接開始寫代碼，邊寫邊構思。

　　實際上這裏我對OO和其架構設計的理解，基本就是從邏輯上解耦，以第三次做業爲例，將式子拆解成一個個類別下的小塊，而後小塊將本身完成任務，也就是將信息分解並層次化，後續做業的架構設計基本都包含了這一設計思路。

第二單元做業：

　　第二單元引入了一個全新的概念，多線程。這一部分我以爲和個人相性至關高，多是由於日常我就是一個比較喜歡同步作事情的人。這一部分引入的併發、調度等概念，以及觀察者模式、工廠模式、生產者-消費者模式、訂閱-發佈模式、哲學家就餐等設計模式同時在多門課程上進行了講解，包括C++、OS等，所以理解起來相對簡單。

　　這一部分設計架構主要借鑑了這幾個設計思路：一、尋找共享數據並將其與線程等分離；二、將屬性與方法與線程掛鉤，設計線程之間的同步和互斥關係；三、管理線程間的同步和互斥。架構的具體設計主要採用了調度器和電梯分離的模式，電梯只負責本身的運行，由調度器根據電梯的運行狀況和當前用戶列表進行分配。架構的具體細節上，以第三次做業爲例，由於只有三部屬性不一樣的電梯，沒有采用工廠模式，並且由於是調度器分配任務給電梯，沒有采用觀察者模式，而是純粹的信息傳輸的模式，而對電梯和調度的內部，架構只劃分到了方法的層次，調度器的劃分是根據功能，如分類、查詢和搜索，電梯的劃分是根據類別，上行和下行，這些劃分的形式並不適合於擴展，但在代碼的可讀性和修改方面仍是有一些便利之處。

　　並且，因爲第二次和第三做業的區別不大，第三次的做業框架基本沿用了第二次，只作了一些適應性改變，對此次做業來講，架構的設計仍是蠻合理的。

第三單元做業：

　　第三單元主要講解了面向對象過程當中的一個重要的方法或者說工具，jml規格。

　　這一單元的重點不是架構設計，而是如何讀懂和根據須要寫jml規格。jml規格對於開發人員和設計人員來講是一個很是重要的溝通利器，尤爲對開發人員來講，jml規格減小了對需求理解的二義性。

　　因此我以爲這一單元對架構的沒有要求，主要是感覺jml規格的便利性和重要以及對jml規格的理解。

第四單元做業：

　　第四單元講的是uml類圖，對於程序設計上的側重能夠說不多，主要在如何使用uml繪圖軟件來完成程序的需求設計工做，架構方面仍是採用了第一單元學習到的分類和分層的思想，主要的OO方法爲逐步引入的uml的模型的理解、語義和語法規則、以及對uml圖的結構化解析。

　　這一單元和上一單元相似，做業只是學習的輔助工具，是爲了增長對uml圖的理解而服務的，做業自己的難度比較低，重點在全面地理解uml圖的元素含義及如何使用uml圖來完成本身根據需求要實現的代碼的層次結構和功能。

四個單元中測試的理解和實踐：

　　四個單元過去，個人架構設計能力和思想能夠說有較爲穩健的提高的話，那麼對於測試，個人提高很是有限。在第一單元的時候，個人測試主要是手動編寫一些臨界條件測試或者較爲全面的功能普查性測試，這些測試的用處不小但都有一個較爲侷限的問題，他們都出自個人理解，也就是隻要我考慮了的問題，那麼我都會寫對應部分的代碼，所以我所謂的測試，其實測試的不是程序功能的面向需求的正確性，而是程序功能面向我理解的正確性，而我理解的正確性沒法確保，這一問題到了第四單元集中爆發。其次，我沒有像水羣和討論區中採用了什麼對拍器和規格化單元測試對每一次做業進行測試，最多隻是使用了數據生成器對程序進行了手動的較大規模的普查，並且在第二和第三單元的時候我對測試的重視比較低，也沒有耐心對代碼進行普查，所以有兩次強測得了很是低的分數。到了第四單元，爲了確保代碼的正確，第一次做業我編寫了較爲完善的測試樣例，有效果，但沒有根治代碼的bug，強測依然出現了小毛病，所以，到了第二次做業，我直接對代碼挨行進行檢查，效果我的認爲比編寫測試樣例要強，可是比較費精力。

　　綜上，我以爲往後對代碼的檢查，能夠採用以代碼逐行檢查爲主，樣例測試和規格檢查爲輔助的形式。

 課程收穫總結

　　首先，這個課程帶我瞭解了什麼叫作面向對象編程。目前，我所認識的面向對象編程就是與以往的的編程相比，面向對象更傾向於在尋找解決具體問題的數據結構和算法以前，先對抽象的問題進行抽象的處理，也就是所謂的對象，而後在這個基礎上，由上而下地逐步填滿包括數據結構和算法在內的諸多層次。而以往的編程模式，有三個特色，第1、問題是具體而特定的；第2、對於程序地總體架構考慮較少或不考慮；第3、程序的體量小，獨立性強。而面向對象須要考慮複雜、多樣且抽象的問題，架構是必須考慮的內容，程序的體量較大並且程序之間存在邏輯上的關係。所以，這四個單元的做業帶給個人最大的收穫就是對面向對象入門級的瞭解和體驗以及對架構設計的理解和重視。

　　其次，四個單元的做業也伴隨了四個單元的測試，雖然在這個過程當中我沒有嘗試太多的新的測試方法，但對於本來的以測試樣例爲核心的測試模式有了新的感悟，對測試樣例的編寫有了新的體會。同時，也肯定了以閱讀代碼爲核心的檢查方式的必要性，

　　再次，這四個單元經過事實告訴了我一我的的力量是有極限的，尤爲是第四個單元，若是不是水羣裏羣策羣力，討論區裏互相幫助，以及私下和同窗的討論，最後一次做業將會面臨徹底不知道指導書要求標準的尷尬狀況，所以，團隊合做是很是重要的，並且必須主動地尋求交流和合做。

　　最後，感謝這個課程告知的多線程概念，讓我第一次明白了所謂的並行執行是怎麼用代碼實現的，補充了我對代碼理解的侷限，同時展現了代碼可以實現計算機功能的一個新的領域。而在第二單元上手編寫了一次代碼，也讓我對多線程運行有了真實的體會。

給課程提的三個具體改進建議

　　一、第一單元多項式求導的跨越性太大，從假期給的小的java程序體驗題目到第一單元的繼承多態封裝等抽象概念的跨度太大，能夠看出老師和助教但願經過三次做業實現過分學習，可是，我以爲這個過分並無作好，變相致使第三次做業難度驟然上升。我以爲對第一單元的三次做業的要求能夠提升一些，加入諸如必須使用繼承、接口等的條件，以及能夠把第四單元的uml類圖部分提早到第一單元，做爲形式上的輔助。

　　二、第四單元的指導書是但願同窗經過解析uml圖的元素來學習uml圖的諸多含義和畫法，我以爲這一部分單獨放出來有些多餘，不如放入第一單元做爲輔助性工具進行學習，而把結構解析單獨列出來做爲一單元，解析更復雜的數據模型，做爲學期總結把以前學過的繼承、多線程等都用上，做爲一個大做業來完成。

　　三、關於實驗課，實驗課的遊戲體驗很是差，上午剛聽講完下午就要嘗試作，並且只有不到兩個小時的時間，時間緊張，內容不熟，感受徹底起不到實踐上午學習知識的做用，不如把實驗課的內容放到課後做爲課後做業，實驗課留做課後做業的時間，也不須要要求同窗必須到機房，而是自選是否到場，到場的同窗能夠向助教諮詢問題等。