三次作業來的設計策略及其變化

　　這三次作業的重點就在於多線程，出租車、IFTTT、電梯，在不同方面去理解多線程的使用。其中主要是同步異步、線程間信息的交互和共享、鎖和時間關系。此外還有依然重要的類的封裝，也是面向對象的主要內容了。依舊以程序架構設計本身為主，思考多線程的實行，去思考和執行設計策略。再然後是測試接口，學會了去提供測試接口、使用測試接口、在別人的測試接口上寫測試函數。

作業分析

　　第六次作業IFTTT整體設計思路：

　　1.為了減少大規模讀取文件屬性的代價，程序動態維護一個目錄Map，其中保存了在上一個時間點文件的相關信息。對於每一個監聽者線程而言，每次判斷只需要從Map中拉取相關的數據即可。對於監聽者和Map的關系，最初考慮使用觀察者模式進行實現，但這種模式對線程自身信息的反饋支撐有所不足，所以選擇線程按需拉取信息。
　　2.IF ** THEN ** 操作使用動態數組選擇函數，最初看指導書認為可以對一個文件綁定多個檢測函數作為一個線程，所以對每一個監視線程定義了全部的操作，根據需要在一個動態列表中對相關操作進行綁定。後來發現每一個觸發器對應一個線程，所以可以考慮使用裝飾模式進行觸發器和任務的動態綁定。
　　3.安全讀寫類的實現。File類的問題在於他是非阻塞式IO，所以需要將其變作阻塞式IO，然後進行線程同步即可。

　　第七次作業出租車調度設計思路：

　　1.系統簡述

　　此系統為出租車調度系統，主要對已初始化的100輛出租車按照一定規範進行管理和調度。從用戶層面來看，需要在用戶發出用車請求3s後按照信譽度，距離用戶位置等信息進行綜合排名，選定最優的車輛接送用戶到指定地點。對每輛出租車，需要保證自己各時刻都處於運動狀態，有機會參與更多的請求應答，提高自己的信譽度。同時，對每個有效響應請求，都需要記錄相關的信息。系統主要存在的問題是出租車事務處理的延時和自身運動改變的時間窗口的沖突關系。舉例而言，對每個出租車，其行走一條邊的時間為200ms，那麽出租車自身的事務處理（比如狀態轉換，路由等）必須低於200ms。GUI界面的更新應較為平緩，不可出現跳線的操作。

　　2.交互分析

與系統有交互的對象應該有三類：出租車，請求隊列，相關信息記錄類。對出租車而言至少應保證有唯一識別號,當前位置、當前狀態、信用度三個屬性。對請求隊列類而言，至少應包含一個請求帶有的全部信息，即：請求位置，請求時間，目的位置.對輸出類而言，需要指明輸出到的目標文件。出租車管理系統對出租車自身進行調度,負責更新出租車的信息和完成相關的調度任務,主要包括以下方面：1.每隔200ms, 更新出租車的位置信息；2.根據出租車當前狀態,對出租車狀態信息進行更新；3.對滿足一定條件的出租車,分配接客任務。出租車管理系統響應請求隊列類中的相關請求，在一個時間窗口結束後選定滿足條件的出租車將其信息反饋給管理系統。輸出類主要用於記錄管理系統觸發的一些操作，比如用戶發出請求後符合條件的出租車信息，最後時間窗口結束後出租車的信息和最終根據條件選擇的出租車編號。實際實現時增加了更多的類用於責任分流和松耦合。

　　3.並發分析

系統中的並發行為主要包括以下幾個方面：

　　1)車租車自身狀態的更新，對每個出租車其自身狀態和位置的更新需要同時在較短的時間內完成，不允許存在較大的延時。

　　2)出租車自身位置與請求完成後選車過程的並行。

　　3)向輸出類輸出關於請求的相關信息。

從這三個方面考慮，在進行並發設計時需要考慮以下因素:

　　1)出租車位置的更新和獲取需要進行同步，以防獲取過程中信息的改變。

　　2)出租車狀態更新的時延盡可能較小，防止對其他出租車的更新產生阻塞。

　　3)出租車狀態的改變只能通過一個阻塞式的方法進行改變，防止多個狀態改變引起出租車的運行錯誤。

　　4)進行相關信息記錄時，不應該因為具體的操作而阻塞出租車的正常運行。

Bug分析和心得體會

　　在這段時間的作業中，主要的一個內容在於為測試者提供測試線程和使用測試線程來測試bug。這重申了面向對象代碼封裝的概念，以一個接口去測試整體程序。此外主要被提出bug的地方還是因為時間緊張帶來的細節問題，並沒有整體思路上的錯誤。所以在這段時間作業中，提前思考程序思路、多線程構造、想清楚再下手，以完善程序架構為主的重要性就被體現出來了。

OO作業第二次總結