目錄

• 電梯作業(yè)的設(shè)計策略
• 基于度量的程序結(jié)構(gòu)分析
• BUG分析及測試
• 心得體會

電梯作業(yè)的設(shè)計策略

在整體的架構(gòu)上，我三次作業(yè)使用的設(shè)計策略較為統(tǒng)一，主要的組成部件有：

• 輸入控制線程：用于控制輸入，向主等待隊列中添加請求（生產(chǎn)者）
• 主控制線程：用于向電梯分發(fā)任務(wù)，從主等待隊列中拿請求（消費者）
• 主線程：主線程使用輪詢的方式查看任務(wù)是否全部執(zhí)行完畢，并結(jié)束程序
• 電梯線程：用于運行每個電梯的等待隊列中的請求
• 主等待隊列WaitList：一個線程安全的共享對象，設(shè)置put和get方法來放入、拿走請求，并使用wait()和notifyAll()來阻塞或喚醒訪問該共享對象的線程

從具體的策略上講，使用了生產(chǎn)者&消費者模型，輸入控制線程和主控制線程構(gòu)成一對生產(chǎn)者和消費者，二者的共享對象則是主等待隊列WaitList，這里我們加鎖來保證同一時間只能有一個線程訪問該共享對象，通過wait()和notify()來實現(xiàn)阻塞和喚醒訪問該共享對象的線程；

主控制線程向電梯線程分配其執(zhí)行的人員，每一個電梯具有自己的等待隊列，而其任務(wù)就是循環(huán)執(zhí)行分配到自己的等待隊列中的任務(wù)，主控制線程和電梯線程之間的共享對象就是每個電梯的等待人員隊列，這里我們同樣加鎖來保證同一時間只能有一個線程訪問等待人員隊列(共享對象)；

• 在單部電梯執(zhí)行任務(wù)的策略上，我使用了LOOK方法，即電梯選定一個方向運送乘客，在執(zhí)行完當前方向上的所有任務(wù)后，再更換方向執(zhí)行后續(xù)任務(wù);
• 在人員分配策略上，我將能夠直達的請求按照一定的規(guī)則分配給對應(yīng)電梯進行處理，在這里需要考慮的問題是各個電梯的負載均衡和最終的時間最優(yōu)。為了將各個因素綜合考慮，在這里我設(shè)計了一種根據(jù)電梯和請求的當前狀態(tài)進行“打分”的分配方式，即根據(jù)電梯是否已滿、電梯是否正在執(zhí)行任務(wù)、電梯目前所處樓層和方向和當前任務(wù)請求的匹配程度等幾個指標來為每個電梯打分，最終將待分配請求加入得分最高的電梯中（但是由于測試不夠&參數(shù)沒調(diào)，導致運行的效果并不好）。對于不能直達的請求，則會先執(zhí)行前一部分(運到中轉(zhuǎn)層)，由電梯線程放入大的等待隊列，再由主控制線程進行新一輪的分配。在中轉(zhuǎn)層的選擇上，我結(jié)合了請求的運行方向、分配電梯當前的運行方向和請求發(fā)出的樓層進行了分配。
• 程序結(jié)束的判定：輸入線程終止且電梯運行完畢。
  在具體的判斷上，當輸入線程讀取到null時，將一個信號量isEnd置位，主線程通過輪詢+Sleep來判斷以下條件：
  • 信號量isEnd置位
  • 主等待隊列為空
  • 每個電梯處于空閑狀態(tài)且每個電梯的等待隊列、運行隊列均為空

  在滿足上述的三個條件的情況下結(jié)束程序

  但是，主線程可能在下述情況下出現(xiàn)錯誤的判定：
  • 最后一個任務(wù)從主等待隊列中取出，但還沒有交給電梯的時候
  • 最后一個任務(wù)不能直達，從電梯中出來而未放入主等待隊列的時候

  為了避免這樣的情況下程序的提前截止，我讓主線程在Sleep一小段時間后再次進行判斷，只有兩次判斷均能滿足的時候才會結(jié)束運行。

基于度量的程序結(jié)構(gòu)分析

第五次作業(yè)：單部傻瓜電梯

• 復雜度分析：
  
  本次作業(yè)中，Main由于需要監(jiān)控各個線程的運行狀況并結(jié)束程序，且具有一定的邏輯判斷深度，所以造成了其OCavg指標復雜度較高；

而類Elevator由于需要維護其兩個隊列（運行隊列和等待隊列），并判斷和執(zhí)行相應(yīng)的任務(wù)，單類中執(zhí)行的功能較多，方法間的互相調(diào)用過于復雜，導致其WMC指標復雜度過高。

• 類圖：
  
• 根據(jù)SOLID原則進行分析：
  • SRP：電梯類Elevator需要執(zhí)行的功能較多，類內(nèi)方法互相調(diào)用復雜，沒有很好地滿足單一職責原則；
  • OCP：由于電梯的調(diào)度策略改變，電梯和調(diào)度器均在后續(xù)進行了重寫
  • 其他：本次作業(yè)中沒有繼承和接口，無抽象類

第六次作業(yè)：單部可捎帶電梯

• 復雜度分析：
  
  在本次作業(yè)中，同樣是Elevator類設(shè)置的功能過多，導致其WMC復雜度較高，Main的邏輯判斷深度及復雜度較高?。
• 類圖：本次作業(yè)的類圖和第五次作業(yè)基本相同，不單獨列出
• 根據(jù)SOLID原則進行分析：
  • SRP：同第五次作業(yè)，電梯類Elevator需要執(zhí)行的任務(wù)過多；
  • OCP：在本次作業(yè)中實現(xiàn)了單部電梯的LOOK算法，第七次多電梯作業(yè)中的不同屬性和捎帶策略的電梯是在繼承本次電梯的基礎(chǔ)上通過拓展實現(xiàn)的
  • 其他：本次作業(yè)中沒有繼承和抽象類

第七次作業(yè)：多部智能電梯

• 復雜度分析：
  • Elevator執(zhí)行功能過于復雜，Main依然邏輯復雜度很高（太懶了?）
  • Controller類需要監(jiān)控各個電梯的運行狀態(tài)，并根據(jù)不同的情況決定其運行策略，導致其邏輯判斷的深度過高，在調(diào)試的過程中，這里也確實出現(xiàn)了很多BUG。
• 類圖：
  

• UML時序圖分析：
  三次作業(yè)的時序圖基本類似，挑這次作業(yè)的畫了一下
  

• 根據(jù)SOLID原則進行分析：
  • SRP：Elevator需要實現(xiàn)的功能過多，沒有很好地遵循單一職責原則；
  • OCP：Elevator實現(xiàn)基本的LOOK+捎帶策略，ElevatorA/B/C通過繼承父類Elevator來修改其各自可以停靠的樓層和不同的屬性、捎帶策略；
  • LSP：父類可以替換子類使用（但是調(diào)度策略不同）；
  • 其他：本次作業(yè)中沒有實現(xiàn)接口，無抽象類

BUG分析及測試

我的電梯在本階段作業(yè)的公測和互測中沒有出現(xiàn)BUG(也沒有性能?)，一方面是由于本模塊的作業(yè)邏輯結(jié)構(gòu)較為清晰，另一方面使用了一些極端樣例和大量隨機樣例進行了測試。對于同組同學的程序，我也沒有發(fā)現(xiàn)太多的問題。

在測試過程中，我使用了自動化測試來檢測正確性，也用它來繪制電梯運行期間的時空圖，以監(jiān)測電梯的性能，統(tǒng)計了電梯的運行軌跡及負載（如下）：

電梯運行時空圖 圖注：
藍色：A電梯
綠色：B電梯
紅色：C電梯
折線：電梯運行軌跡
每個方形的大小：當前電梯內(nèi)人數(shù)

可以看出，在整個電梯運行的過程中，LOOK算法的執(zhí)行情況較好。但是B電梯的負荷明顯過高，而C電梯的任務(wù)量太少（運行時間短、運送任務(wù)少），電梯整體的運行圖能夠更加直觀地展示在電梯生命周期內(nèi)的運行負荷，也更易于找出任務(wù)分配的不均衡。

在互測階段，我也為我們組另一位同學畫出了這樣的運行軌跡圖，30S左右輸入的40條左右請求，他的電梯運行了160S以上：

從他的電梯運行圖中我們也能發(fā)現(xiàn)，他的單部電梯在執(zhí)行任務(wù)的過程中使用的算法不是非常合理，例如B電梯出現(xiàn)了大量”折返跑“的情況；多電梯的任務(wù)分配也存在問題，C電梯在程序運行期間有長時間”摸魚“，A電梯亦有空等時間過長的情況。

心得體會

線程安全

• 在設(shè)計時考慮到線程之間的同步互斥關(guān)系
• 考慮不同線程和共享對象之間的關(guān)系
• 合理上鎖
• 考慮所有情況，避免不安全的情況出現(xiàn)

設(shè)計原則

• 首先保證線程安全
• 在設(shè)計時充分考慮以后出現(xiàn)的情況，OCP原則
• 設(shè)計清晰每個類的職責，遵循單一職責原則
• 降低類之間的耦合度
• 使用外部工具來進行正確性分析和性能評

轉(zhuǎn)載于:https://www.cnblogs.com/lebway/p/elevator.html

總結(jié)

以上是生活随笔為你收集整理的面向对象的程序设计-模块二课程总结的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。