OO第二階段做業總結

第五次做業：

        設計策略：

         本次做業設計的基本思路是按照指導書所給的推薦方法來完成的，即共用對象爲隊列盤，線程有電梯、調度器、以及掃描器，掃描器將控制檯輸入的有效指令加入到隊列盤中，調度器依據指導書的原則分配任務給電梯，而後電梯將其一條條執行。在電梯的類中，加入了一個小隊列，即電梯依次須要完成的任務。在同步控制中，對隊列盤對象加鎖，在某一線程使用時，其餘線程沒法更改，可是能夠訪問。這樣存在一些時間上不一樣步的問題，致使了一些bug的出現。

         度量：

         類圖：

         本次的類圖較爲簡單，因爲實際使用的類並非不少，List類爲掃描器，scheduler類爲調度器，Elevator類爲電梯，因爲是三個電梯同時運行，所以實例化了三個電梯來同時運行。此次做業實現的好處在於思路簡單，而且各種間的關係明確，易於在後續的找bug工做中提供幫助。可是缺點在於，類中只有run（）方法，代碼的可讀性太差，沒有將各個工做模塊化，所有工做塞在一塊兒顯得臃腫，而且代碼複雜度極高，致使一些沒必要要的問題出現。

         Metrics度量圖：

         第一行的紅色標記，代表了本次做業中，我對從控制檯讀取有效命令的方法部分模塊複雜度過於複雜，而且嵌套深度也過深，這在第三行中也代表了出來。這依舊是由於，我在處理控制檯的輸入時，將正則判斷也加入了這個模塊，這致使了一個方法承擔了許多任務和工做，所以讓該模塊的複雜度直線上升。而且對一條輸入進行了屢次正則匹配，也直接致使了模塊代碼的複雜度和嵌套程度加深。對代碼的優化和提煉作得還不夠。

         分析本身程序的bug和不足：

         本次做業出現了兩個bug，一個是因爲沒有使用繼承機制，直接使用了之前的調度器和調度方法。事實證實，偷懶是沒有好處的，測試者真的很細心，這樣都能發現我用了之前的調度器。另外一個bug是若是最後一條命令是（#ER,1,1），個人程序就會crash，這依然是使用以前的調度方法的問題。還有一個bug測試者並未發現，在個人設計中，調度和掃描只能交替進行，這是因爲對同步控制錯誤致使的。雖然沒被發現，可是若是不及時改正，對接下來的其餘做業一定會形成影響。此次做業仍是存在許多的不足，某個方法依然顯得臃腫複雜，模塊化和可讀性程度都極差。對線程的同步控制也是作得不夠完美，在調度上也存在一些問題，致使了程序crash。

 

第六次做業：

         設計策略：

         此次做業是實現對文件的監控和管理，明白ifttt原理。雖然老師一直說此次做業很簡單，可是我以爲一直寫到深夜的應該不止我一我的。此次做業最大的難點就是，須要本身先自學java裏對文件的操做怎麼描述。這就花去了我許多時間。其實此次的做業難點在於架構，基本方面在於，掃描器掃描控制檯的輸入，讀取文件的路徑，監控內容等。在文件通過相應的操做後，可以做出對應的響應。而且須要寫一個類，讓測試者可以操做目標文件。個人策略就是每兩秒掃描一次目標文件所在的文件夾，而後判斷是否作出了監控器監控的動做，若是出現了，就執行須要執行的輸出。按照指導書的要求，判斷各個操做是否出現。

         度量：

         類圖：

         其中List類是掃描器，負責處理控制檯的輸入。monitor類是監控器，也就是程序的主體，負責判斷各個監控器的內容是否出現。detail記錄了文件或文件夾的前後名臣，前後路徑，前後大小和前後最後修改時間，而且輸出到指定位置。summary類記錄了監控器監控內容發生的次數，而且輸出到指定位置。filevisit類是提供給測試者操做文件的另外線程。此次的優勢在於我將detail和summary另起一類，讓各個變量間獨立，使結構更加清晰明瞭，輸出到文件就不易於犯錯。缺點在於須要在monitor中調用這兩個實例化對象，會形成代碼量變大以及monitor類中的變量增多，易讀性就大大下降了。

         Metrics度量圖：

         根據此次的metrcs度量圖，能夠看到已經沒有紅色的字體出現了。可是模塊複雜度最高的仍是個人掃描器對控制檯輸入的部分，因爲此次對輸入格式並未做要求，所以在正則匹配上就沒有那麼多的工做量，所以沒有形成模塊的過於複雜。嵌套程度最深的是個人監控器類的監控方法，因爲調用了不少其餘方法來監控文件，因此嵌套程度最深。此次對各個模塊代碼的優化和簡練仍是作得比較滿意，模塊化的程度也較高，並無預料中出現過於複雜化的模塊的出現。

         分析本身的bug和不足：

         此次做業的bug存在不少，主要緣由是對recover要求處理不到位，對這個要求的並無去測試，只是完成了基本代碼，可是在本身測試的時候並無考慮這個狀況，所以就直接交上去了。而後錯了一堆bug，才發現對recover，也就是將文件還原的操做是錯誤的，有時候程序還會不響應。後來在檢查過程當中才發現執行recover操做時，沒有記錄更改前目標文件的路徑和名稱，只是將文件的位置改變了而已，由此形成了極大的失誤。還有一個比較嚴重的bug是沒有設計好多個監控內容的狀況，若是監控多個目標文件，時間上會不一樣步，致使輸出到detail的最後修改時間錯誤。這是因爲同步控制作得很差致使的。

 

第七次做業：

         設計策略：

         此次做業要求完成一個基本出租車功能的程序。基本方法在於，由掃描器掃描控制檯乘客的目的地和所在地，而後由調度器調度附近符合要求的出租車去接送乘客。本次做業的難點我認爲在於去完成最短路徑的尋找，雖然由GUI提供的方法可以稍微魔改一下去找到最短路徑，可是會花費大概3~4秒的時間，初始化時間太長我以爲不太合理。就想到了數據結構使用的鏈表方法，使用了一個差很少的方法來查找最短路徑，事實證實效果還不錯。在程序實現時也直接引用了GUI的方法，讓程序可以可視化。另外一個難點在於圈出4*4區域，讓進入的出租車可以響應。

         度量：

         類圖：

         此次須要完成的類有不少，所以看上去結構比較複雜。這是主要的缺點。而且能夠看到各種之間的互相調用不少，致使了程序的嵌套程度很深。可是結構上的複雜必然就會有思想上的簡單。Dis類用來計算兩點間的距離。map類用來從文件中讀取地圖。scan類即從控制檯讀取乘客的需求。queue類即等待對列。taxi類便是出租車類。各自處理各自須要實現的功能，不會互相影響，而且可讀性極高，後續的debug工做容易進行，這也是本次做業沒有被找出bug的緣由之一吧。

         metics度量：

         第一行所指出的最複雜的模塊是指導書所給的GUI模塊中的讓地圖顯示出來的部分。因爲地圖一直須要刷新，這是理所應當的。而後第三行，嵌套程度最深的又是個人掃描器的讀取輸入的函數。此次做業我對程序的優化和簡練應該是作得比較好的，多是因爲這個線程須要一直從控制檯讀取有效輸入致使的，這個線程在設計上是須要一直運行的，由於須要不斷的接受乘客的請求。這是理所應當的。

         分析本身的bug和不足：

         此次做業在互測階段並無被找出bug來，多是測試者沒有發現，可是我本身在設計中有個缺陷，這也是我交上去做業的一瞬間纔想起來的。若是控制檯同時輸入兩個或兩個以上的乘客請求，個人程序只會響應其中的一個。另外一個不足在於，對於指導書提到的4*4區域，若是出租車一開始在該區域，但以後駛出區域後，應當是加入搶單隊列的，可是我沒有 處理這個出租車。雖然僥倖沒被測試出來，可是確實存在這些小問題。必須在下次做業以前改進。

 

心得體會：

         這三次做業據老師說已是全部做業中比較難的了，但願如此吧。可以活過第二階段尚未無效做業已是萬幸，但願之後也不要有無效做業出現吧。而後就是努力完善本身的程序吧，既然不喜歡給別人找錯，那就讓本身的程序變得更無懈可擊就行了。