基於有窮狀態機思想的電梯系統

介紹

此次設計的電梯系統是一次軟件工程的小組做業（這門課沒安排實驗，佛），我在此次小組做業中負責的是後端設計和算法設計的部分，多虧了想出來了（否則只能CV了，其實我是這個系統的產品經理
項目上傳到了GitHub中，歡迎follow。

設計

設計思想

電梯系統要求採用有窮狀態轉換機的思想，在我看來就是：」電梯A的狀態 + 按下任意電梯按鈕 = 電梯A的下一狀態「，這種方程的體現。在這個表達式中，咱們發現電梯的狀態改變是由不一樣電梯按鈕的按下狀態來影響的，簡單的說就是按鈕刺激電梯的狀態改變。那麼，咱們就將電梯形象地設計爲激活按鈕的接收器，每部電梯能夠接收任意數量的按鈕，並對之作出反應。
進而考慮到電梯接收激活的按鈕，可是並非按照先激活先刺激電梯狀態改變的順序，因此咱們設計了兩個優先隊列，分別是等待隊列和執行隊列。執行隊列中的按鈕會刺激電梯狀態改變，而等待隊列中的按鈕會按照電梯的須要加入到執行隊列中。具體的優先和調度邏輯在詳細設計中闡述。
最後考慮到多部電梯，激活的按鈕具體分配到哪一步電梯，這裏也存在着一個分配策略。
上面的內容都來自於個人報告，我同窗設計的界面能夠很好的反應咱們的設計思想：

程序設計

以下圖所示，一共設計了5個包和一個程序入口類：

其中，最核心的包是schedule包，有調度隊列類scheduleQueue，包含了兩個優先隊列和一些對優先隊列的處理和刷新方法，還有一個調度線程類scheduling，考慮到能夠設計多個電梯，因此每部電梯只須要綁定一個調度隊列而且開啓一個調度線程就能夠正常工做了。
其餘的，button是按鈕包，包含了電梯內部按鈕和電梯外部按鈕，電梯外部按鈕正表示向上，負表示向下；comparator是比較器包，優先隊列的比較器；elevator是電梯包，包含了一個核心的anElevator電梯類，用於實例化電梯對象和moveElevator類，表示電梯的移動枚舉類；frame是界面包，這個由我同窗設計。

調試

程序設計的仍是比較簡單的，不過設計出來的系統與人們的正常思惟邏輯仍是有區別，因此大部分時間都花在了Debug上，界面上的那幾個隊列的表格都是爲了方便調試而加上的（沒有這個很差調試啊，因此兼職產品經理的我和前端室友開戰，逃！）。有兩個bug仍是讓我印象深入的：

修改執行隊列Comparator

問題例子：電梯在1層不一樣，依次點擊電梯外部5層向下和4層向下按鈕，電梯先到4層停頓而後在5層中止。正確的移動軌跡應該是先在5層停頓而後在4層中止，等待電梯內部按鈕被摁下。
解決方法：修改執行隊列中的比較器，兩個電梯外部按鈕而且和但電梯當前所在層反向的時候，須要將原來的優先級反向。以下圖所示：

修改刷新執行隊列判斷時間

問題例子：電梯在1層中止，依次點擊七、六、五、8梯內部按鈕，電梯先到第7，而後依次是六、5層，最後中止在8層。
解決方法：出現的這個問題的緣由是由於當時設計的時候，僅僅支持在執行隊列執行完後，即執行隊列爲空，才刷新執行隊列，如今修改成電梯每移動一次就刷新一次，提升刷新的密度，保證儘可能完成能順便完成的按鈕動做。

最後的話

很是歡迎你們修改和完善這個小系統吼，固然也很是期待我你們給我找出的Bug（那得看我又沒時間改Bug了）。

人生此處，絕對樂觀