OO第二次總結

第五次做業

1. 做業簡介

第五次做業內容爲模擬同一棟樓三部電梯的協同工做。模擬做業對乘客請求作出判斷並按照必定算法將請求分配到具體的電梯上執行。

1. 設計思路

這一次做業在第三次做業的基礎上增長了多部電梯的協同工做。因爲每一部電梯的狀態和運動相互獨立，採用多線程設計頗有必要。個人思路是將三部電梯分別對應一個線程，來描述這三部電梯的運動；將請求輸入做爲一個線程來不斷地獲取用戶請求；將調度器做爲一個線程，及時將獲取到的請求分配到具體的電梯上。程序類圖以下：

因爲第一次接觸多線程編程，這套電梯系統對我來講難度不小。樓層請求的分配處理對於多線程的協同要求很高，這也是這次做業最大的一個難點。從類圖上看，程序基本符合設計思路，將輸入、調度器、電梯分別做爲線程類。

1. 度量分析

最終個人程序結構以下圖：

 

從度量分析結果能夠看到，個人主要的三個類中都有一個方法複雜度較高，並且三個方法都用於實現該類的主要功能。也就是說我習慣於將類中的主要功能集中於一個方法上，雖然相對於前幾回做業來講有所改善，但仍需將功能細化，將各個方法分工明確。整體代碼規模也比較大，說明程序不夠簡潔。

1. 時序圖

 

1. Bug分析

因爲在設計多線程操做時對捎帶請求考慮不周，個人程序在處理某些不知足捎帶的請求時會產生捎帶現象，致使了一個嚴重的Bug；這次互測中對方的代碼思路比較嚴謹，我並無對方的發現任何Bug。

第六次做業

1. 做業簡介

第六次做業是一次IFTTT工做，內容爲對單個文件或目錄下全部文件的監控，監控文件的重命名、修改大小、修改最後修改時間、修改路徑四種操做，並對應進行統計觸發次數、保存修改信息和recover操做。

1. 設計思路

根據指導書對這一次做業的要求，我將針對每個監控對象的一個觸發器設置爲一個線程。只要監控對象觸發了觸發器，這一個線程能夠執行一個或多個任務。本次多線程的衝突集中在文件資源的競爭上，因此設計一個線程安全的文件操做類就可以很好地解決多線程同步問題。在程序類圖以下：

在設計了線程安全類SafeFile類後剩下的工做就是算法的設計了。通過了上一次做業對多線程的理解，這一次我在對線程衝突的處理上好了一些。

1. 度量分析

最終個人程序結構以下圖：

從度量分析結果能夠看到，每一個方法的總體複雜度還算比較低，不過個人方法數量不少，其中存在的一個問題是某些方法的類似度比較高，我認爲能夠作適當合併來提升代碼的可讀性並保持良好的邏輯結構，這是後續值得優化的部分。此外，有幾個方法的邏輯嵌套深度較大，可適當優化邏輯判斷。

1. 時序圖

1. Bug分析

本次做業存在一個Bug：當前監控目錄存在多個屬性相同的不一樣名文件時。這些文件的其中一個重命名會致使另外的文件重命名觸發器的觸發。屬於邏輯判斷上存在的Bug。這次互測對方存在嚴重錯誤，沒法對目錄進行監控，對文件的監控也存在不少問題。

第七次做業

1. 做業簡介

第七次做業是模擬出租車系統工做。在80*80的矩陣網格地圖上隨機放置100輛出租車，對於任什麼時候刻的乘客叫車請求，系統給予相應的迴應。

1. 設計思路
2. 與系統有交互關係的對象識別

1. 特徵分析

    用戶交互的數據特徵：提供乘客當前座標和目的地座標、乘客標識符。

    用戶交互的時間特徵：用戶輸入乘客請求時以當前的系統時間做爲請求時間。請求在系統單位時間（100ms）內算做同時的請求。

    地圖數據特徵：地圖數據固定不變，提供相鄰結點之間的鏈接狀況。

    地圖時間特徵：不隨時間改變而變化。

1. 對象識別與構造

    地圖類Map：

    地圖類的做用爲讀入並保存地圖信息，提供地圖中每兩個點之間的最短路徑。

    用戶類User：

    用戶類的做用爲從控制檯不斷讀入用戶從控制檯輸入的請求，並將用戶的請求傳遞。因爲須要一直監控控制檯輸入，因此該類應爲一個線程類。

    請求類Request:

    請求類是一個數據類，記錄乘客請求的全部信息。

    出租車類Taxi：

    出租車類表示出租車的座標位置，以及運動狀態（等待服務狀態，接單狀態，中止狀態）。出租車行駛一條格子邊須要200ms。出租車不管在什麼狀態下都是獨立運行，因此出租車類應爲線程類

    輸出類Output：

    輸出類負責全部輸出內容，包括控制檯響應輸出和將處理過程輸出到文件。

    類方法：幾個靜態方法，按照條件輸出便可

    分配類assign:

    分配類是一個線程類，該線程啓動3s並在啓動時間內將進入以請求爲中心的4x4範圍內的出租車歸入搶單列表，並在最後結束時選擇一輛出租車派單

程序類圖以下：

1. 度量分析

最終個人程序結構以下圖：

從度量分析結果能夠看到，除了提供的GUI類之外，部分方法的複雜度和嵌套深度較高，須要優化。

1. 時序圖

1. Bug分析

本次做業存在一個輸入格式限制的Bug，除此以外目前沒有發現Bug。這次互測對方有一個輸出時間上的爭議，目前仍在溝通確認。

總結

經過這三次做業的練習，我對多線程的理解從零開始日漸加深，也體會到多線程的強大之處。然而多線程編程中的難點就是處理共享資源以及線程之間的交互。這其中有不少技巧是須要在不斷地實踐練習中掌握的。但願在之後的編程實踐中可以對多線程問題有更加深刻的理解和掌握。