總體架構
三次作業總體架構保持一致，在初始架構的基礎上進行增量的迭代開發。
第一次作業
需求：模擬多執行緒實時電梯系統，每座固定一部縱向電梯，處理同樓座移動請求。
**框架：
本架構採用生產者-消費者設計模式，托盤為各樓座等待佇列，為每座定義了兩條等待佇列，根據起點至終點的方向不同分為上行佇列與下行佇列，簡化了電梯方向判定的演算法。
**規模：
第二次作業
需求：模擬多執行緒實時電梯系統，每座初始各一部縱向電梯，可增加縱向電梯與橫向電梯，處理同樓座、同樓層移動請求。
**框架：
**規模：
對 timableoutput 封裝為outputthread類，避免出現輸出時間戳非遞增的情況
第三次作業
需求：模擬多執行緒實時電梯系統，每座初始各一部縱向電梯，一層一部橫向電梯，可增加縱向電梯與橫向電梯，處理同樓座、同樓層移動請求以及換乘請求。
**框架：
**規模：
第三次架構與第二次基本相同，主要修改在排程器部分，增加了換乘相關操作的方法。
可擴充套件性分析
協作圖
同步塊鎖
三次作業中，我都選擇了使用關鍵字synchronized修飾的鎖機制。
在前兩次作業中，排程器的核心功能極為簡單，即充當「托盤」的作用，接收請求，並分配到候乘表佇列中。
第三次作業增添了換乘操作，排程器多了乙個「分解」請求的作用，即把換乘請求分解成多個簡單請求，這樣保證了電梯類只需較少改動，就能完成換乘的要求。
在請求接收方面，採取自由競爭的策略，優點是不需排程器從電梯獲取資訊，降低耦合性；但有可能會導致電梯接收到不能處理的請求（目標層座不可達），此時需要將請求吐出。
第一次作業：
強測出現兩個rtle錯誤，主要是因為結束時沒有判斷電梯內是否清空，導致電梯執行緒沒有結束。
第二次作業：
由於未封裝輸出模組，導致強測出鍋，未進互測。
在debug過程中對輸出模組進行了封裝。
第三次作業：
強測出現兩個rtle錯誤，乙個是縱向電梯中轉向函式的缺陷導致，另乙個是橫向電梯吐出請求的函式，在佇列中有多個需要吐出的請求的時候會死迴圈。
互測無bug。
三次作業中，均採用測評機+構造資料相結合的方式進行測評。
OO第二單元總結
本單元的作業總體來說比較愉快，畢竟不像上次一樣次次重構。本單元為電梯系列問題，涉及到多執行緒問題。簡單起見，我使用的是生產者 消費者模式。本次作業要求實現單部可稍帶電梯。看完題目後我認為生產者 消費者模式非常適合解決這個問題。本次電梯我採用的是look方法。本方法核心即在於電梯方向的判斷，這在dis...
OO第二單元總結
共享資料類 在總結後面的3.基於度量的程式結構分析部分，本人根據展示的uml類圖更加詳細的講解了具體的協同結構工作原理。通過對實現以上操作的共享資料類中的方法設定synchronized，從而實現執行緒對共享資料的訪問同步。ocplsp ispdip 根據以上類圖，分析本次作業設計思路如下 2 根據...
OO第二單元總結
第二單元總結 第一次作業 思路與反思 uml類圖 度量分析 耦合度 第二次作業 思路 第二次作業與第一次的迭代在於電梯增加 人數限制 樓層改變，我依舊用的look演算法，在第一次作業的基礎上修改細節即可，多部電梯要求實現執行緒安全，由於我使用的look演算法，電梯盲目執行，沒有更高階的排程，只需要在...