一、總結本單元兩次作業架構設計
1.uml第一次作業
本次作業中使用的是將類圖抽象為乙個trueclass物件，用來儲存類中的相關資訊，在trueclass中還建立了方法物件oper，屬性物件attribute，還有用來儲存查詢的中間變數aftercal用來實現記憶查詢，在oper物件中還建立了傳入的引數物件，總體來說就是進行了分層次的儲存，並且使用新建的物件aftercal來記憶計算過的結果，減少需要進行的從頭查詢的次數（但是在執行時間上表現並沒有比不進行記憶儲存好很多。。。。。。）查詢時的方法是使用了遞迴，是為了能夠進行記憶搜尋，將「路過」的類的結果也記錄下來。感覺上由於使用的層次較多，出現問題時比較容易定位，debug體驗很良好。在強測中沒有發現問題。本次uml類圖如下
2. uml第二次作業
本次作業的解析類圖的部分是通過繼承上次作業實現的，解析狀態圖的部分是通過建立狀態圖類state的hashmap實現的，在state中存有region，用以對應region, 還有狀態遷移的arraylist,其中存的是遷移到的state的id；解析順序圖的部分同理，是建立interaction，然後在interaction中存有messcnt用來記錄不同的message，並且存有lifes用來記錄生命線，lifel是生命線類，用來存生命線中的元素。本次的演算法主要是檢查有效性的部分，主要是使用了類似bfs的寫法，實際上在查是否有迴圈繼承時寫了bug，由於在將某個類的繼承的類及介面加入暫時迴圈使用的佇列時未考慮是否已經遍歷過這個類了導致了死迴圈。並且在新增messege時沒有考慮target找不到的情況，導致了丟擲異常。本次的類圖如下。
二、在四個單元中架構設計及oo方法理解的演進
在第一單元時實際上並沒有很好的理解物件導向的思想，總體還是使用c語言的面向過程的寫法，導致**比較長，而且維護起來難度較大，出現問題難以定位。在第一單元的前兩次作業中沒有用到物件導向的思想。在最後一次作業中為了能夠拆分多項式並分別處理，使用了一點點物件導向的思想，即將多項式通過符號逐步拆分，並對拆分出的字串進行遞迴的處理，如果是能夠處理的簡單項則進行求導，然後進行乘法，加法，如果不是簡單項則加入初始的類中進行處理。
在第二單元時對物件導向有了初步的理解，能夠簡單地運用。但是第一次作業由於對多執行緒的理解是錯誤的，自己理解的是每一條指令作為乙個執行緒，雖然在本次作業沒有出現問題，但是我認為如果資料量龐大，會引起很大問題。第二作業由於對排程器理解有誤翻車，導致寫了一次無效作業。但是後來改正後發現也不是很大的問題，只是很小的地方沒有處理好執行緒問題的衝突。第二次作業修改後的架構是由排程器將乘客塞給電梯，電梯自己只負責執行，執行完畢至車內無人則等待排程器發出指令。第三次作業我一開始的想法有些複雜。開始時試圖沿用上一次的策略，電梯每到一層，由排程器將能夠上電梯的人塞入電梯，但是這次由於有三種電梯，且如果這樣寫的話換乘電梯較為複雜，所以最後並沒有成功實現。後來的做法是，有三個電梯執行緒，乙個排程器執行緒，乙個輸入執行緒。電梯負責將本電梯的等待佇列捎帶進入電梯，排程器負責將能直達的指令塞給電梯的等待佇列，將無法直達的指令通過計算出兩層間能夠從哪層換乘其他電梯來拆分指令，並分為兩部分塞入電梯和存入乘客類的副指令中，在人出電梯時才將副指令加入指令佇列中。這種排程雖然無法讓其他電梯在能夠接人時提前過去，但是在最大限度上保證了執行緒安全，最後在強測及互測中正確性表現良好。
在第三單元時對物件導向的思想能夠正確運用了，並且使用了繼承的做法（之前由於checkstyle會報錯導致基本沒有使用）。在第一次作業就是按照jml進行書寫，申請了三個hashmap，plist，pidlist，和dot。plist中使用路徑的id作為key，用來儲存路徑；pidlist使用的是path轉為字串作為key，用來儲存路徑對應的id；dot用結點id作為key，用來儲存點的個數。其中為了減少查詢不同點的複雜度，每次addpath的時候都會進行點集合(dot)的增加，每次remove時也會對dot進行修改，使查詢不同點方法的複雜度降為o(1)。在第二次作業中當時由於checkstyle在繼承時父類中如果又public屬性會導致無法通過，就沒有使用繼承，而是直接將上次的**複製貼上到了本次作業，導致**較為臃腫。在本次作業中使用了兩個hashmap來對應點和抽象陣列的關係，這樣能夠做到在乙個120*120的圖中進行運算，效果比較好。每次在有add和remove指令時重新計算兩個最短路徑圖和可達矩陣，這樣能夠降低些查詢的複雜度。在本單元的第三次作業中，使用了繼承上次的作業，就是並未修改父類的物件，而是在子類中使用super獲取父類的物件。這樣能夠在checkstyle不報錯的前提下使用繼承。在作業中使用了不拆點的做法，將所有點對映到大小為120*120的二維陣列中，能夠較為便捷的計算。在上次的基礎上新增了用來儲存最低票價，最少換乘，最低不滿意度的二維陣列。每次add時重新計算這三個矩陣。但是由於演算法的問題，每次remove時需要將所有路徑重新新增，並計算每一條，這樣能夠直接將換乘的代價加入，較為簡便。但是這樣寫也就犧牲了增加和刪除路徑時的不滿意度。
在第四單元也就是最後的本單元，能夠正常運用物件導向的思想了。（通過類圖的複雜程度可見。。。架構主要是建立各種類，用來分層次儲存所需的資料，維護起來較為方便。
三、在四個單元中測試理解與實踐的演進
在第乙個單元中主要使用的是自己手動構造各種測試用例，效果不佳，覆蓋面也不夠廣。
在第二個單元中使用過通過c語言進行簡單的輸出作為測試用例，雖然比較極限但是資料面也不夠廣，測試效果不是很好。輸入時使用了按鍵精靈來完成定時的輸入。
在第三個單元中也是使用了通過c語言進行簡單的輸出作為測試用例，能夠較好地測試極端情況，但是隨機性不太好。
在第四個單元中使用的是手動畫uml圖，並使用官方的工具進行解析，進行測試。較為直觀。
四、課程收穫
oo這門課對我來說是受益匪淺的。首先是每週的時間線，雖然整週都較為緊張，但是在完成任務後也是成就感滿滿。也培養了自己的抗壓能力。。在每單元作業的遞進式的難度中，能夠較好地理解本單元的重點，並且對物件導向的思想的理解也是逐步加深的。還鍛鍊了自己的心理素質。第二單元第二次作業翻車後感覺實際上當時如果心態放平還是有可能改對的（畢竟在修復bug是大概只是看了20多分鐘就找到了問題所在）雖然第二單元第三次作業一開始寫的架構較為複雜導致實現難度較高，但是認識到問題後冷靜開始重構，最後效果還是可以的。**風格的檢查也使我現在敲**會向標準的格式靠攏，（從修改**格式的時長可以看出）每次作業修改的都在變少。
五、立足於自己的體會給課程提三個具體改進建議
1. 執行緒單元我認為是可以在第一次作業時給一些提示，或者標準的有關執行緒的**。我開始對多執行緒理解的錯誤實際上是源自一次實驗，實驗中所給的**是銀行櫃檯排隊的問題，其中就是每次來乙個請求就開乙個執行緒，於是當時我對多執行緒的理解就是每個請求是乙個執行緒。這樣實際上是比較浪費資源的，所以我認為在開始時可以做一些**方面的引導。
2. 實驗課與理論課我認為間隔較少，是否能夠在本週做上週理論課講的內容，這樣能夠留出時間進行理解。
3. 能否多提供一些標準寫法的有關架構實現的**，老師們在課上強調了多次架構的重要性，但是對我而言架構的實現有些困難。希望能夠提供標準寫法的**以供參考。
OO第四單元總結
第一次作業我將umlelement進行分類，新建乙個封裝類uml，用介面和類進行例項化 新建乙個operation類例項化operation元素。在myumlinteraction的初始化，先找到所有的類和介面例項化uml。然後找到所有的方法，例項化operation類，並且將類根據parentid...
OO第四單元總結
從這四個單元來看，除了第三單元對於架構的感受不深，兩外三個單元對架構的要求是比較高的。雖然這三個單元內容主題完全不同，但設計架構的目標是一樣的，就是盡可能地把現實中的邏輯細緻地還原表達出來。所以oo是什麼？j同學在一次研討課上表示oo在他看來就是將資料和方法集中起來封裝，我認為這個表述沒有觸及到oo...
OO第四單元總結
這個單元寫 的時候在面向過程的方便和物件導向的清晰架構中反覆橫跳，導致最後寫出來的東西亂七八糟。第一次作業 第一次作業只涉及到了uml的類圖。定義了myclass myinte ce myoperation三個類，儲存attribute等資訊。我的想法是將一條條資訊即乙個個umlelement分類存...