本次作業需要實現一部簡單電梯的執行，很自然的，我選擇將本次作業的三個部分，讀入資料、排程資料、電梯執行作為三個執行緒來執行。其中讀入資料的執行緒比較簡單，根據提供的介面使用方法順序讀入即可。排程資料我實現了乙個排程器類，用於管理兩個佇列，乙個是讀入資料的佇列，乙個是給電梯分配任務的佇列。電梯作為乙個類，實現了執行，進出人等功能。
我認為本次作業的可拓展性做的比較不錯，增加電梯只需要再建立乙個執行緒即可，增加功能也只需要在電梯內部進行增加。
uml類圖如下：
協作圖如下：
度量分析如下：
除了電梯的run方法外其他方法複雜度都控制的比較好，因為電梯需要考慮優先去接哪乙個樓層的人，所以run方法的複雜度比較高。從類圖也可以看到電梯類的複雜程度是最高的。
本次作業我在強測和互測中均沒有被發現bug。在互測中我也沒有發現其他同學的bug。
本次作業要求實現多個電梯並拓展了可以到達的樓層。我在第一次作業的基礎上新增了乙個整體佇列用於給每乙個電梯提供自身獨享的佇列。由於出現了負樓層，新增了根據樓層轉化佇列下標的方法。
可拓展性比較好，新增功能只需要在相應類中增加方法或者增加類即可。
uml類圖如下：
協作圖如下：
度量分析如下：
可以看到第二次作業的分析整體來看與第一次作業區別不大，電梯的run方法由於設計原因複雜度還是比較高。
本次作業我在強測和互測中均沒有被發現bug。在互測中我也沒有發現其他同學的bug。
本次作業新增了電梯的種類以及換乘和動態增加電梯的功能。對於電梯種類，我給電梯定義了乙個floor陣列用於標記可以到達哪些樓層，並用string來儲存電梯的型別和名字。對於換乘，我採用了寫回請求佇列的方法。首先排程器在排程時如果發現乙個無法直接到達的請求，就對此物件進行乙個特殊的標記。電梯在接到有特殊標記的person時會將其送到最近的換乘樓層（1或15層）並將此請求寫回請求佇列。對於動態增加電梯只需要在讀入執行緒建立電梯即可。
本次作業我覺得可拓展性還是比較不錯的，由於電梯、排程器、讀入器分離，實現了比較好的拓展性。
uml類圖如下：
協作圖如下：
度量分析如下：
本次作業的複雜度比上次作業稍有上公升，但總體來說還算比較正常。
本次作業我在強測與互測中均沒有被發現bug。在互測中我發現一些同學在運送大量換乘人員時會超時，還有一些同學對於某種特殊的需求無法到達。
在第二單元的學習中，我深刻認識到了執行緒安全的重要性，我身邊同學幾乎百分之八十的錯誤都**於執行緒不安全所導致的死鎖或者資料冒險，而且執行緒安全的問題很有可能自己測試時很難發現，一些錯誤可能只有非常小的概率發生。還有設計原則也必須要清晰，應該誰做的工作就應該誰做，不應該讓某個執行緒做不屬於它的工作，這樣不但提高了耦合度，還有可能引發意想不到的錯誤。我們應當在一開始就規劃好整個程式的大體框架，不能寫到**算**。
2020北航OO第二單元總結
任務要求 通過多執行緒的互斥和同步控制，實現電梯功能模擬，並進行擴充套件和迭代。第一次作業 單電梯，由於請求完成時間有限制，所以需要進行捎帶或者其他優化策略。第二次作業 多部電梯，增加每部電梯人數限制，到達樓層可擴充套件到負數層。第三次作業 多部電梯，每部電梯可到達樓層 速度 人數限制不同。需要支援...
OO第二單元部落格
一 概述 本單元通過多執行緒實現電梯排程，和上一單元相比較，更加側重於執行緒的安全的模式。相較於上一單元難度有提高，整體來看，沒有第一單元的學習結果好，三次作業中第一次第二次作業比較順利，第三次作業因為執行緒安全的問題最後是無效作業，比較讓人頭痛。在排程策略上三次作業都選擇了指導書中的als排程策略...
OO第二單元部落格作業
首先這三次作業總體都是關於電梯，所以電梯肯定要抽象出乙個類。然後聽老師上課說的，排程器要有乙個類。還要乙個主線程來開始其他執行緒，以及乙個用來讀取輸入的執行緒。所以總體我寫了四個類。電梯類 模擬電梯執行，持有屬性為執行速度，到達樓層，所在樓層，執行方向等，還有自己的request佇列，存放的是在本電...