電梯多線程調度----需求分析及詳細設計
小組成員:劉鑄輝,何曉楠
1.進程管理
首先,做一個項目無論大小,時間規划和進程管理是最根本的,下面是我們的進程管理。
執行計划 | |||||||
任務名稱 | 開始日期 | 結束日期 | 實際用時 | 人員 | 備注 | ||
計划 | 實際 | 計划 | 實際 | ||||
需求分析文檔設計 | 3月5日 星期三 |
3月5日 星期三 |
3月7日 星期五 |
3月7日 星期五 |
2天 | 劉鑄輝 何曉楠 |
|
詳細設計文檔設計 | 3月7日 星期五 |
3月7日 星期五 |
3月9日 星期日 |
3月9日 星期日 |
2天 | 劉鑄輝 何曉楠 |
|
項目功能的實現 | 3月9日 星期日 |
3月9日 星期日 |
3月13日 星期四 |
待定 | 待定 | 待定 | |
測試用例文檔 | 3月13日 星期四 |
待定 | 3月15日 星期六 |
待定 | 待定 | 待定 | |
項目結項報告 | 3月16日 星期日 |
待定 | 3月17日 星期一 |
待定 | 待定 | 待定 |
該項目的任務布置時間是3月3日,由於有段時間沒有拿C#做過小項目開發了,所以我和小楠先用三天時間通過看教學視頻和查資料做了一個掃雷的小項目,項目不大,但是我們使用嚴格的項目開發來寫的,電梯調度的項目我們也用項目開發的步驟來寫。並且用這三天的時間強化了C#的語法和多線程的操作。
3月5日,我們開始着手項目的設計和構思。
2.需求分析
2.1電梯說明
1. 管理者需求描述
- 實現項目的可管理性,能夠監控電梯的安全。
- 實現項目的及時性,當出現問題時候,可以及時的采取施,達到保證人員安全的效果。
- 實現項目的可調控性,能夠使用戶在不同環境中使用項目,並且能夠達到相同的效果。
2. 用戶(內)需求描述
- 正常的開關門
- 可以去任何一層樓層
- 若出現緊急情況時候,可以停止電梯運作,並發送警報給管理人員
- 查看電梯所在當前樓層
- 知道電梯是否已經滿載
3. 用戶(外)需求描述
- 查看電梯所在樓層
- 請求電梯過來,並打開
- 得知電梯是否能打開
4. 電梯調度需求描述
1.電梯內部視圖1-20為相應的樓層,按下變為紅色即可響應樓層
2.電梯到達相應樓層后會按鈕會變色,表示門被打開
3.開關門按鈕,只有在電梯停下來,或者電梯正在開門時(延長開門時間)響應,關門鍵只有在開門以后,按下可以立刻關門,並繼續上下移動。
4.外部的38個按鈕為4部電梯共享。
2.2實地考察
1·我們的調查對象是春暉樓(11層),時間:3月11日中午13:10;
2.電梯開關門時間是2.65s,為了編程方便取2s;
3.從1層到11層,無其他乘客乘坐的情況下,有3個數據28.65s,29.21s,29.01s,為了編程方便取29s,則平均每層通過的時間是3s;
4.調查了電梯如何多線程調度。兩部電梯一個在9層,一個在6層停下,我倆去7層請求向上走,發現6層的那個電梯過來了,那么一定是調用了最短路徑算法,7層離6層最近。
5.得出了兩個結論。
1.電梯優先考慮內部按鈕,對於外部請求,只有順路的情況下,才會有響應,否則一律不響應。
2.當兩部電梯都不工作的時候,當有用戶發送上樓或者下樓的請求,會調用最短路徑算法將最近的電梯調度過來。
3.詳細設計
3.1重要參數及變量
3.1.1Elevator類
boolean arrive[40]; //用於記錄電梯內部的按鈕,也就是電梯需要到達的樓層
arrive是用於存放電梯請求的信息。0~18表示1~19樓的一個向上走的請求,21~38表示20樓到2樓向下走的請求。
arrive[19]與arrive[39]沒有使用是因為在20樓不存在向上的請求以及在1樓不存在向下的請求之所以不給arrive設置20個,而設置40個的原因是因為,電梯分上下行走,如果5樓有2個孩紙,一個按往下行走,一個按往上行走,那么,應該響應的是不同的按鈕。
3.1.2將電梯的狀態分為5個狀態
int state //電梯的狀態
(1)0 靜止 (等待狀態)
(2)1 向上走(去接一個向上走的請求) 比如 電梯在1樓; 3樓按下一個往上走的請求
(3)2 向上走(去接一個向下走的請求) 比如 電梯在1樓; 3樓按下一個往下走的請求
(4)-1 向下走(去接一個向下走的請求) 比如 電梯在5樓; 3樓按下一個向下走的請求
(5)-2 向下走 (去接一個向上走的請求) 比如 電梯在5樓; 3樓按下一個向上走的請求
int willArrive //電梯沿着這個方向運行最終的樓層
int floor //目前電梯在哪一個樓層
3.1.3RequireButton類
bool require[40] //電梯外部的按鈕請求狀態
3.2實現思想
3.2.1先從簡單的一部電梯的內部按鈕開始
(1)只有一部電梯時,電梯內部的按鈕必須優先實現,不考慮外部按鈕。在run方法中,每次調用upOrDown(內部調度核心函數)函數。
內部調度核心函數upOrDown函數會根據上一步的電梯狀態state按照不同的順序將電梯要到達的各個樓層arrive數組掃描一遍,並將返回值返回給新的電梯狀態state。
(2)1.當state=1或者state=2時,內部調度核心函數upOrDown函數會從20樓掃描到當前電梯所在層floor,一旦遇到高層向下的請求,修改willArrive(電梯沿着這個方向運行最終的樓層),並且返回新的電梯狀態state,之所以從20樓開始掃描是因為電梯目前狀態向上,willArrive為一個需要到達的最高處需求
2.當state=-1和state=-2時,相同。
3.當state=0時,如果電梯所在樓層有開門響應這時候執行開門操作。
否則,將電梯要到達的各個樓層arrive[i]掃描一遍,一旦發現有一個樓層需要請求,立刻修改這個方向的最終到達樓層willArrive,並返回新的電梯狀態。
(3)如果電梯內部沒有請求了,檢查是否有外部按鈕被響應,如果有的話,需要修改電梯需要到達的樓層arrive函數,之后可以在下一次調用upOrDown函數中在修改后的電梯需要到達的樓層arrive函數中改變電梯狀態。
(4)對於返回的新的電梯狀態state
1.如果返回值為1或者2執行電梯上樓(upFloor函數);
2.如果返回值為-1或者-2,執行電梯下樓(downFloor函數);
(5)電梯上樓upFloor函數:
1.執行電梯上樓動畫,在上完一樓以后,將floor++,並且判斷電梯要到達的樓層和外部響應的樓層是否為同一層,如果是則表示該樓需要開門,則停止電梯,進行開門。之后返回啟動電梯(run函數),再次調用調度核心函數(upOrDown函數)查看電梯下一步操作。否則無需開門,直接返回到run函數。
2.在這種情況下會響應向下的按鈕。
當state==2(電梯本來就是想上接向下的乘客),並且同樓層外面的人只按下了向下的按鈕(否則會先相應想上的按鈕),並且電梯到達了電梯需要到達的最高樓層,則響應向下的按鈕。
電梯下樓downFloor函數與upFloor類似。
3.2.2關於電梯內部按鈕按下的樓層與arrive數組的響應
1.當按下的樓層>floor(電梯目前所在的樓層),則標記該樓為上樓的請求
2.當按下的樓層<floor,則標記該樓為下樓請求
3.當按下的樓層=floor,電梯處於開門狀態,並延長開門時間
3.2.3響應僅一部電梯時的外部按鈕
1.響應外部按鈕只有在電梯靜止狀態下響應,除非是電梯順路的情況,順路的情況在upFloor和downFloor函數中已經解決。
2.剩下state=0的情況,在upOrDown函數中,首先搜索了電梯需要到達的樓層arrive數組,如果全為false,表示電梯內部沒有需要到達的樓層,這樣在檢查是否有外部按鈕被響應中,將外部請求賦值給電梯需要到達的樓層的數組。(額,感覺不是很對,暫時只能想到這了,看來多線程還是太懂,求大神幫助。。)
3.2.4響應多部電梯(search函數,調度4部電梯管理外部按鈕)
(1)4部電梯是4個線程,線程之間相互工作,互不干涉。因此,內部原理完全相同,要在創建的時候多創建4個Elevator類即可。
(2)唯一不同之處是外部按鈕。當有用戶請求外部按鈕的時候,調度一個最近的電梯過去有一些區別。這里,我們准備對於一個外部響應的電梯,在所有的靜止電梯中,找到一個線路最短的電梯分配過去。也就完成了一部電梯到多部電梯的過度,也完成了4部電梯的調度工作。
我和小楠折騰了好幾天才剛剛把需求分析寫完,路還長着呢。感覺這個項目上,資源分配和進程調度的確是個難點,很多地方感覺思路還算清晰,只是有些地方可能也不太對,只能在編寫功能模塊的時候再發現了,希望大神們能給我們指點指點,謝謝了。