16071070_陳澤寅_期末總結

面向對象編程學期總結

1、總結本單元兩次做業的架構設計

單元概述：

本單元介紹了UML類圖的知識與用法，而且經過StarUml軟件來生成相應的UML壘土、狀態圖、時序圖來進行相應的驗證。UML語言：統一建模語言（英語：Unified Modeling Language，縮寫 UML）是非專利的第三代建模和規約語言。UML是一種開放的方法，用於說明、可視化、構建和編寫一個正在開發的、面向對象的、軟件密集系統的製品的開放方法。UML展示了一系列最佳工程實踐，這些最佳實踐在對大規模，複雜系統進行建模方面，特別是在軟件架構層次已經被驗證有效。下面講一下本單元所學到的一些理解。

第一次做業

此次做業主要是進行類圖的解析。主要的思路就是從UmlClass和UmlInterface進行創建層次結構，而後根據UmlAttribute、UmlParameter以及Umlssociation等進行建模。進行兩遍掃描，第一遍掃描，首先將全部的類，接口等UmlElement記錄下來，第二遍掃描將全部的類、鏈接關係等創建起關係。本次做業的解析過程沒有什麼難點。主要是怕TLE的錯誤，所以咱們的想法是將一些能夠重複使用的東西存起來，方便往後查詢的時候直接使用

類圖

這裏主要須要介紹的是InterOrClass這個接口，因爲第一次做業涉及到了類和接口的問題，所以必需要區別這兩類，可是這兩類之間有不少共享的相同點，若是分紅兩部分來處理則會有不少的冗餘操做，所以咱們設計了一個InterOrClass接口，咱們使咱們的UmlClass和UmlInterface類都實現這個接口，而在這個接口裏放共同的函數這樣就可使咱們的代碼簡單明瞭。

Bug分析：

本次做業未出現Bug，也是對個人理解的一種確定。

第二次做業

第二次做業重要是在第一次做業的基礎上加入了有關狀態圖和順序圖的分析，而且對於代碼進行三種規則的驗證。在狀態圖和順序圖的方面，整體來講邏輯仍是比較清楚的，依照上次做業的方法就能夠作個大概，重點仍是先理解各個元素的含義,主要的難點在於類圖的三個規則的驗證。尤爲是008和009規則的驗證。首先講008規則，因爲008規則要識別全部的成環的類或接口，所以我使用了DFS的深度優先遞歸搜索算法，而且記錄下已經遍歷的節點，當識別到一個節點已經在當前路徑內，則咱們將成環的一些點刪去。對於009規則，咱們使用相似的算法，識別出重複實現的接口，而且對於這些接口，實現其的類也算作矛盾類予以刪除。對於009規則存在不少種複雜的狀況，討論區已經闡明，此處不一一贅述，在構造數據集進行測試的時候，須要注意覆蓋到每一種狀況。

類圖

此次的設計思路與建模方式與第一次做業相同，而且針對UML順序圖和UML時序圖的查詢也都相對比較簡單，所以在解決了上述三個check規則以後就一路暢通無阻。

Bug分析：

在中測過程當中，我出現的Bug是對於009規則的查詢存在遺漏的狀況，即CLASSA實現了IA,IB,而後IA,IB分別繼承了同一個IC，這樣CLASSA就是違反了009。

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

心得

剛接觸面向過程的編程的時候，內心仍是挺驚慌的，由於內心尚未從面相過程的思惟中轉變過來，固然這樣的轉變也不是一朝一夕就能完成，老實來講，最後一個單元的架構中，我依然存在不少的面相過程的編碼習慣，這也說明了咱們仍是須要一段很長時間的練習才能徹底造成面相對象的思惟。下面講一下我在每一個單元中的思路歷程。

第一單元

該單元是進行多項式的求導，第一次做業的慘痛教訓我至今難以忘記，因爲第一次寫代碼，寫的徹底就是面相過程的形式，所謂的‘類’，也就是套了一個類的空殼子，裏面的代碼徹底就是按照面相過程的形式進行的，所以在該單元第二次做業時，全部的代碼都須要進行重構，這就讓我下定了決心要好好理解面向對象，當時的想法就是多建立類，將類類分離，每一個類各司其職，將其耦合度下降，雖然理論上都知道，可是在操做起來時仍是存在不少不熟練的問題。在第三次實驗，帶有遞歸的求導時，我以爲是我真正意義上第一次比較好的使用了接口、類的含義的一次實驗，我將求導與類分離，這樣每一個對象只關心本身的事情，所以最後的強測也比較滿意。總的來講，第一個單元的幾回嘗試，讓我初步瞭解了面向對象的思路以及構造之法，至於代碼能力，還須要增強訓練。

第二單元

第二單元的做業是有關電梯調度的做業，此次的訓練核心是多線程的運用。在這三次做業中，我主要是針對當前的狀況經過不一樣的調度算法進行調度，將電梯做爲一個單獨的線程。該單元我以爲是幾個單元中最難的一個單元，由於多線程的理解的確有點困難，好在仍是挺過來了，也收穫不少。主要的思想就是創建Elevator,Dispatcher,User三個類，而後每一個類完成本身的職責，而且互相聯繫。難點就在於如何聯繫，前兩次我使用暴力輪詢的算法，可是這樣的話會致使RTL的問題，所以最後一次做業我對每個可能會發成輪訓的地方，咱們都採用wait,notify的方法來進行解決，這樣能夠大大減小CPU的不必的使用時間，大大增長了程序的執行效率。還有第三次做業中的調度策略須要進行劃分，這對於類的架構設計要求就更高了，須要你明確每一個類的職責，否則在多線程中就會出現不少難以描述的問題。總結，第二單元讓我更加明確了類的職責，也搞明白了多線程的一些問題。

第三單元

該單元我認爲是在四個單元中比較簡單的一個單元，主要的目的是對JML規則進行理解，咱們根據JML規則進行代碼的撰寫。但其實JML的規格理解仍是其次，主要的提高是對於類與類的數據結構的架構設計以及時間複雜度的合理把控。由於在此次做業中我就出現了RTL的錯誤，所以咱們必需要合理構造數據結構對數據進行存儲。在第三次做業時，因爲存了不少不須要的重複節點，致使時間複雜度太高，致使不少的節點時間超時讓我悔恨至極，所以在第四次做業中我很認真地對算法和數據結構進行了設計。總的來講，這個部分我學到了不少關於數據結構以及查詢效率方面的內容。

第四單元

見第一部分，主要收穫和第三單元相似。

3、總結本身在四個單元中測試理解與實踐的演進

這個單元主要闡述我對於測試數據以及實踐演示的理解，在第一單元的時候我還不瞭解本身構建測試集的重要性，每次都是覺得中測過了以後強測就穩了，卻不知好幾回強測都掛了不少點，而這緣由大都是由於一個很簡單的小問題，而這些問題也正是因爲本身沒有構建測試集而形成的問題。所以從第二單元開始我就本身構建測試集，先整理好有哪些邊界條件，或者可能出錯的問題，而後針對這些問題一一構造數據集進行測試。針對電梯單元，我特地用python編寫了測試腳本，能夠模仿評測機，對輸入自動解析，而且在相應的時間節點重定向入標準輸入。可是還要注意有一些設計上的bug是數據集可能沒法測試出來的，這些問題在多線程中是多發的，所以在設計多線程時，最主要的步驟仍是在設計的時候就想清楚一切，而不要過度依賴測試集。

針對第三單元，我使用了Junit對每一個方法進行了單元測試，這個好處就是你能夠着眼於局部，對每個函數檢查其正確性，使測試覆蓋面更加全，而且更加容易定位錯誤的發生位置。同時學習了OpenJml來對JML語言進行規範化的驗證，同時也用Jprofile對生成的代碼運行時的內存資源等進行調研。明白了JVM虛擬機在運行時的CG等機制。針對第四單元，咱們學習使用StarUML對UML進行設計並驗證，明確了各類圖與圖、類與類之間的聯繫。同時編寫Junit單元測試真的對於接口方法實現的正確性驗證起到很大的做用。

4、課程收穫

一、讓個人思想從面相過程向面相對象進行轉化，之前難以理解或者毫無思緒的一些建模情景，如今均可以經過面相對象的思想來進行簡化，這無疑是對我編程道路上的一個跨越。

二、收穫了框架設計的重要性，之前編寫代碼都是想到什麼寫什麼，如今經歷了一系列OO實驗的洗禮，深入明白了設計的重要性，千萬不要急於編碼，要先把做用、規格想清楚，而且注意代碼的可擴展性再進行編碼。

三、類與接口的設計，類的設計越簡單明瞭越好，每一個類承擔的責任越少越好，類與類之間儘可能減小交集，減小耦合，這樣在進行擴展的時候就能減小代碼的修改。

四、對JML規格的認識，代碼在編寫以前，先肯定接口、方法的規格，這樣有助於寫代碼的時候明確代碼的輸入輸出以及異常狀況，這樣既有助於本身的代碼撰寫，也有利於團隊合做時其餘人編寫代碼時的理解。

五、認識了代碼風格的重要性，學會了使用pycheck，曾經在編寫代碼的時候，我不會顧及代碼的風格，想到哪寫到哪，一個函數可能寫個一兩百行，一個函數處理了不少的方法，每一個函數顯得十分臃腫，即不明確其功能，在維護或者擴展時也顯得十分困難，如今每一個方法的功能明確，職責分離，利於實現以及維護，一樣也對閱讀者比較友善，他人容易閱讀代碼。

六、最後就是對於測試驗證的理解更加深刻，之前對於測試驗證的過程不夠重視，草草了事，通過該學期的磨練，認識到了測試驗證的重要性，畢竟之後的工做是服務於客戶，爲了客戶的良好體驗，必需要覆蓋到每一種可能發生的狀況，保證程序的健壯性，在任何狀況下都不crash。

5、立足於本身的體會給課程提三個具體改進建議

一、對於起點難度的把控：

我以爲本學期四個單元的做業對於能力的提高確實比較大，可是可能每一個單元的難度把控不是很規範，好比第一二個單元難度比較大，而且開學的時候你們對於JAVA都比較陌生，可能編碼比較困難，所以我建議在課程開始以前先對JAVA的一些基礎知識進行教學，或者前兩個單元給比較長的時間，讓咱們同窗有一個比較好的過渡和比較充分的瞭解JAVA的時間。

二、課上實驗改進：

課上實驗的內容的確比較結合咱們的編程以及學習內容，可是每次實驗以後咱們的結果就石沉大海，得不到任何的反饋，甚至連本身錯了，對了都不知道，而且也沒有任何的講解，我認爲沒有反饋的訓練就比較乏力，就好比梯度降低算法也是靠反饋來優化參數，只有錯了再優化咱們的能力才能提高，所以我但願可以在每一次實驗課後將咱們的結果進行反饋，而且在理論課的時候簡單地講解一下上次實驗的內容。

三、關於強測機制：

我以爲強測的時候可能過多的測試點都是有聯繫的，每每有些同窗都是由於一個小小的錯誤致使一半的測試點所有錯誤，這樣的話可能讓同窗會有點沮喪，而且可能由於這樣而拉不開層次差距，建議之後的測試點之間的耦合性下降，使同窗們的分數之間有層次感。

六:展望

本學期OO帶給了我不少心得東西，也但願OO課程組能認真採起同窗們的反饋，將這門課作的愈來愈好。