結對專案:電梯排程演算法的實現和測試

我已經報警了發表於2014-10-18

結對程式設計人員:

12061167林旭鵬

12061174李靖

TFS上Pairproject11

結對程式設計優點:

(1)結對程式設計相對來說比較高效,一些基本功能可以分開來寫unit在進行整合,核心演算法可以進行討論,選擇效率比較好的哪一種演算法。

(2)兩個人同時進行程式設計,不容易分神,集中程度相對一個人時更高,雙方也可以互相監督。並且若有一個人實時對另一個人的程式碼進行實時監督,可以避免手滑打出來的小問題,這些小問題在除錯時時很難找出來的,可以節約除錯的時間。而且debug時,也可以讓頭腦比較清醒的人上。

(3)可以讓我們提前熟悉團隊合作

缺點:

(1)兩個人寫程式時,也許有時候還需要給對方講一講他看不懂的你的程式的具體實現細節,這在一個人寫程式時是不必要的。

我(林旭鵬)的優點:之前做過win8app開發,熟悉vs的使用,熟悉c#,程式碼能力較強。

缺點:打程式碼時非常容易犯一些手滑打錯的小錯誤,debug時往往從思路方面切入,經常搞了很久最後才發現是筆誤導致的bug

李靖的優點:程式碼風格比較細膩。

缺點:不太熟悉c#語言。

(以下三點來自網路)

Information Hiding:首先,在類中,定義的變數和方法可以再前面加上一個下劃線"_"來標識,這是一個好的命名規範,可以避免無意中對私有成員進行賦值。類與類之間交換資訊時,要交流私有變數時,要用事先設計好的方法來訪問,這樣如果我們在其它類裡面呼叫另外一個類的私有變數,那麼我們必須定義一個獲得該類私有變數的方法;要在另一個類裡面改變另外一個類裡面的變數時,我們也要定義一個改變該類私有變數的方法。在C#裡特別方便的一點就是有set和get,我們可以很方便的定義訪問一個類私有變數的方法。

interface design:一個好的介面能夠提供給後面的程式設計一個良好的框架,在這次電梯排程專案裡,介面IElevator、IPassenger、IScheduler、IRequest,我們通過介面能很快的知道電梯、乘客、排程方案、請求都有哪些屬性,要實現哪些方法,而不用關心具體的實現細節;這樣我們的軟體測試也變得更簡單了。

loose coupling:在我們的程式碼設計時,不用擔心會破壞其它地方的程式碼。這種類與類之間依賴性低的設計方法,使一個類與另外一個類彷彿隔開了,它們之間只是通過訊息來聯絡的,所以設計一類時,可以不用擔心破壞另外一個類。當程式碼有改動時,可以不用大規模的改動我們的程式碼,我們只用定位於一個出問題的模組,然後對其進行更改就好了,而且能做到不改變其它模組的服務。

資訊隱藏、介面設計、鬆耦合都是物件導向設計的重要方法,都是使程式設計時更接近日常認識,在大模組之間關係中不用過於擔心細節,只需在模組設計時下功夫。

 

契約程式設計:

給程式設計者提供了非常明確的要求,非常明確地提出了契約者希望實現的功能。

一 前置條件(precondiction):
為了呼叫函式,必須為真的條件,在其違反時,函式決不呼叫,傳遞好資料是呼叫者的責任。
二 後置條件 (postcondiction):
函式保證能做到的事情,函式完成時的狀態,函式有這一事實表示它會結束,不會無休止的迴圈
三 類不變項(class invariant):
從呼叫者的角度來看,該條件總是為真,在函式的內部處理過程中,不變項可以為變,但在函式結束後,控制返回撥用者時,不變項必須為真。
 
在我們的程式碼和單元測試中,保證雙方地位的平等,不同模組間的互動使用了契約的思想,保證傳入的引數是正確的。在進行單元測試的時候,也對方法進行了有效性的驗證和推理。

測試單元及程式碼覆蓋率:

UML圖:

 

演算法關鍵:

排程演算法主要根據電梯的“History dirction”變數,以及有無乘客等資訊,進行排程演算法。

電梯的初始History dirction預設為up。

每個tick:

  電梯若在底層,令其History dirction為up,若在頂層,則設定為down;

  電梯內沒有人時:

  先檢查有沒有方向一致且當前History dirction方向上可達的樓層請求,若有,Reqstopat最近的;

  若當前History dirction方向上,沒有方向一致的樓層請求,則檢查有沒有方向不一致且當前History dirction方向上可達的樓層請求,若有,Reqstopat最遠的,並令電梯的revs變數為true;(revs變數為真時乘客類會進入方向不一致的電梯,接到最遠的乘客後此變數為false)

  若當前History dirction方向上,沒有任何樓層請求,將電梯方向轉向,下個tick再判斷。

  電梯內有人時:

  遍歷所有的電梯內部請求,以及當前History dirction方向上可達,並且方向一致的樓層請求,Reqstopat這些請求中最近的。

演算法的獨到之處:

這種演算法確保了電梯每一趟都至少會把當前方向上的所有請求都考慮完畢後,才考慮轉向的問題。

由於題目中提供了一種情形,當一層和零層有大量的請求時,電梯每次都只能帶一部分人上樓,最好電梯是應該送完人上去後馬上就下來再載人上去,同時響應順路的請求。而我們一開始想的排程演算法,就可能出現電梯在樓上不斷上下響應高樓層的請求,而忽略較遠的零層和一層的請求,這樣由於0層和1層的等待人數太多,就會使平均排程時間大大增加。

使用新的演算法,保證了電梯不會無視這些較遠的請求。

相關文章