Pair Project1:電梯控制程式

12061199 程剛  &&   12061204 黎柱金

一、結對程式設計的優缺點

結對程式設計相對于一個人的程式設計有更多的優點，缺點也有很大不同。

首先，優點：

1. 結隊可以讓兩人可以更好的協作（也是結隊的意義所在了）。讓兩人的團隊意識和團隊能力有更大提升，增加兩人的互相了解與認識。
2. 結隊可以讓兩人互相學習，在結對中和互相合作、互相學習、互相督促，兩人沖着同一個目标結對程式設計。
3. 結隊可以明顯提高一人程式設計的效率，兩人在一起讀寫代碼時可以互相讨論，一人不知道的多，但是兩人同時不知道的就少許多了，疑問少了，效率自然而然的上來了。
4. 結隊可以提高一人程式設計的正确性，兩人在互相質疑互相讨論的過程中互相糾正着，特别是排程算法中，兩人一同商量着更加好的算法，在不斷的在讨論中改進算法，降低平均乘客等待時間。

其次，确定：

1. 兩人課程時間不是很同步，一起程式設計的時間受限，應協調兩人的課程與作息時間。
2. 兩人代碼風格不同，在代碼編寫中不是很友善。
3. 兩人在結隊時會有不同意見，是以得互相說服對方，最好得出兩人都同意的結果，其中要費不少口舌與時間。

二、結隊組員的優缺點

1. 程剛同學：善于合作，待人真誠，善于尋找更好的算法。但是缺點卻也很明顯，急于求成，總是希望可以立刻完成作業。

2. 黎柱金同學：代碼能力強，性格随和，肯吃苦，穩重，在一步一步中完善代碼。缺點确實比較喜歡拖DEADLINE，這點和程剛完全不同，兩人是以互相監督。

三、結隊合作過程

1. 首先兩人拿到題目，開始閱讀老師的要求，尋找各種在要求中重要的資訊，編譯程式設計的進行。

2. 然後兩人下午相約一起去圖書館進行代碼讀寫，在圖書館中兩人一起老師給的代碼，互相答疑，實在不知道就隻能尋找度娘了，用了一個下午将代碼差不多看完。

3. 晚上，兩人分别自己想好算法，那時我和同寝室的一群人在一起商量如何實作排程算法，經過讨論到淩晨3點左右，最後我們6人（隔壁寝室的 也來了兩個）覺得應該将電梯作為主體，在指令沒有完全完成前，最開始由一個最先的指令調動停止運作着的電梯開始運作，而從此時開始主動權就交個電梯了，電梯在每次經過一個不是disabledfloor時都要進行考慮自己是否已經滿載了？如果是，将不會開門；如果否，考慮在此時電梯所在樓層是否有請求（之前未被處理的請求或者臨時來的請求），如果有且指令與電梯當時狀态時順路的，開門，每進一個順路乘客都要再計算是否滿載，如果否，直到請求全部搭載完或者電梯已經滿載了。如此循環四個電梯，直到指令全部完成。當然其中也許會有電梯搭載完人之後也許就停留下來，如果指令臨時尋找不到順路的電梯，那肯定會調用此時不在運作狀态的電梯，以節省乘客等待時間。第二天詢問黎柱金時，他的想法不同，他的想法是以請求為主體，當第一個請求出來之後，電梯前去搭載乘客，然後在過程中也許會出現順路指令而且在第一個指令之後，于是乎電梯就需要超前掃描指令，在一段時間内尋找最佳選擇，使得乘客等待時間最短，如此循環将指令全部走完。

4. 當然想到的代碼并不一定就可以完全運用在代碼時間編寫中，要在夥伴中不斷讨論、修改、嘗試中不斷修改算法和代碼。

5. 對完成的初步代碼進行測試、完善和優化，其中也不乏和其他組别的交流與比較，進一步完善代碼，提高電梯效率。

6．進入電梯工程的後續步驟，開始部落格的書寫和代碼最後時期的修改。

合作照片：

四、Information Hiding, interface design, loose coupling 的思考

1. Information Hiding：資訊隐藏将程式子產品化，使得每個類都似乎是一個單獨的存在。在結構化中函數的概念和面向對象的封裝思想都來源與資訊的隐藏，是以子產品應該采用定義良好的接口來封裝，這些子產品的内部結構應該是程式猿的私有财産，外部是不可見的。而資訊隐藏原則的應用： 1 多層設計中的層與層之間加入接口層； 2 所有類與類之間都通過接口類通路；  3 類的所有資料成員都是private，所有通路都是通過通路函數實作的。

2. interface design：接口将子產品的部分方法和屬性一同組合起來，為了實作封裝，也是上面Information Hiding的良好手段。接口控制着不同子產品之間的資訊傳遞，實作不同子產品之間的互相協作，幫助資訊隐藏的同時協調整個結構化的工程。是以接口設計也有許多要求：穩定性，易用性，規範性，可移植性，魯棒性，安全性，相容性等等。

3. loose coupling：松耦合為子產品之間的依賴程度。松耦合的目标是實作子產品之間的最先依賴度，在結構化工程中，子產品之間的過多依賴都不利于将各子產品獨立起來，而且過多的牽扯會出現子產品間互相導緻錯誤的危險，一次應盡可能實作子產品間代碼最小化松耦合是以就必須增加抽象類和接口來實作。

五、Design by Contract, Code Contract

1. Design by Contract, 契約設計：

  契約式設計或者Design by Contract (DbC)是一種設計計算機軟體的方法。這種方法要求軟體設計者為軟體元件定義正式的，精确的并且可驗證的接口，這樣，為傳統的抽象資料類型又增加了先驗條件、後驗條件和不變式。這種方法的名字裡用到的“契約”或者說“契約”是一種比喻，因為它和商業契約的情況有點類似。

契約設計的核心思想是對軟體系統中的元素之間互相合作以及“責任”與“義務”的比喻。這種比喻從商業活動中“客戶”與“供應商”達成“契約”而得來。例如： 

　　1.1 供應商必須提供某種産品（責任），并且他有權期望客戶已經付款（權利）。 

　　1.2 客戶必須付款（責任），并且有權得到産品（權利）。

　　1.3 契約雙方必須履行那些對所有契約都有效的責任，如法律和規定等。 

　　2. 同樣的，如果在面向對象程式設計中一個類的函數提供了某種功能，那麼它要： 

　　2.1 期望所有調用它的客戶子產品都保證一定的進入條件：這就是函數的先驗條件—客戶的義務和供應商的權利，這樣它就不用去處理不滿足先驗條件的情況。 

　　2.2 保證退出時給出特定的屬性：這就是函數的後驗條件—供應商的義務，顯然也是客戶的權利。 

　　2.3 在進入時假定，并在退出時保持一些特定的屬性：不變式。 

3.優點：

3.1獲得更優秀的設計：

更系統的設計 契約式設計鼓勵程式員思考諸如“例程的先驗條件是什麼”這樣的問題，這樣有助于程式員理清概念。更清楚的設計 使用者和提供者之間的權利和義務得到了共享，同時獲得了清晰的描述。更簡單的設計 程式的先驗條件清楚地描述了使用該程式的限制，而且非法調用的結果也很清楚，是以我們鼓勵程式員不要開發過于通用的程式，而要設計小巧的、目标專一的例程。

3.2提高可靠性

（1）編寫契約可以幫助開發者更好地了解代碼

（2）契約有助于測試（契約可以随時關閉或者啟用）

3.3更出色的文檔

（1）契約乃是類特性的公用視圖中的固有成分

（2）契約是值得信賴的文檔（運作時要檢查斷言，以保證制定的契約與程式的實際運作情況一緻）

（3）契約是精确的規範，同時也可以作為測試的可靠指導

3.4簡化調試

契約能把錯誤牢牢地定位

3.5支援複用

（1）出色的文檔

（2）正确運用了複用代碼的運作時檢測

4.缺點：斷言可以看做是契約式設計的一個縮影或者是一部分，因為你不可能做DBC所做的一切事情。斷言不能沿着繼承層次往下遺傳。如果你重新定義 了某個具有合約的基類方法，實作該合約的的斷言不會被正确調用（除非你再新的代碼中複制他們），你必須手工調類不變項，基本的合約不會主動實作。

2. Code Contract，程式代碼合約：

程式代碼合約是.NET Framework 4.0的新功能，它是微軟對契約式程式設計(Design by contract)概念所提出的一種解決方案，主要由前置條件(Preconditions)、後置條件(Postconditions)、與對象不變式(Object Invariants)這三大契約所構成，可以很容易的為程式代碼加入驗證程式代碼，降低程式的錯誤發生率，提高程式的品質，也可以整合單元測試，減少單元測試的工作量，甚至整合文檔管理器，讓産出的程式檔案更為詳細 。

使用Code Contracts主要可讓我們享有下列四項特點：

　　1、提升自動測試程度

　　2、靜态驗證

　　3、執行階段驗證

　　4、檔案産生

六、UML

UML是由VS生成的，由于工程較大，圖也不是很好表現出來子產品之間的聯系，但是大緻可以看出。

七、算法

    我們的程式控制台隻輸出平均等待時間，由于乘客過多會導緻控制台輸出的前期的時刻TICKS由于資訊過多流失，避免控制台輸出的緩沖設定，我們将這些内容輸出到log.txt中，希望助教和老師看到！！！

    我們的算法進行的優化幅度不大，但是比較符合實際情況。

    排程政策如下：總體的思想仍然是一條路走到底，但是并不在每一層都停。當有人在門外按下按鈕（上/下）之後，所有順路的電梯都會對其作出響應，最快到達者有優先承載權。然而因為每個電梯的情況不一，乘客還需要進行選擇。這裡乘客選擇的政策和以前一樣，隻要電梯符合要求就上。當乘客上了電梯之後，其他之前對其響應的電梯就可以放棄這名乘客了。

    在我們的算法中，我們假設排程器是不會“預知未來”，也不會“讀心術”的。也就是說：1. 在某個時候，排程器隻能知道到目前為止的所有請求，而不是将未來的請求一并讀入以尋求“最優時間”；2. 排程器不會知道乘客想去那一層。是以對于乘客的電梯外請求，是讓乘客選電梯，而不是電梯選乘客，否則就有作弊之嫌疑。

    由于電梯事先不知道乘客要去哪個樓層，是以隻能讓所有可能的電梯都去迎接這名乘客。而每個人都是貪心的，不會顧全大局，也無暇去做計算（比如轉兩次電梯會不會更快等等），是以首先到達的符合條件的電梯，就直接上了。

    題目要求的最優平均時間，卻有可能導緻總時間變長。比如，我們可以忽略某個順路請求（因為他會浪費電梯上其他人的時間），而到最後再回來接他。這樣乘客等待的時間就增加了，投訴信會更多。

    我們希望算法是通用的，是以并未對題目特定的電梯情況做優化處理。

    我們設計的算法，一方面出于上面的考慮，另一方面是由于能力和時間有限，是以僅能将效率提高一點點。下面是題目自帶測試樣例的結果對比：

測試樣例	Ours	TA
Passenger1	192.5	217.05
Passenger2	782.996	949.133
Passenger3	1231.804	1426.373
Passengers	127	249