軟工老師出了一道題目，關於電梯排程問題，假設一幢大廈有21層， 4部電梯，很多乘客使用這些電梯（旅客重量：平均70公斤最大120公斤，最小45公斤）。其他常量資料：電梯速度，開/關門時間，乘客要進出電梯的時間。具體設計乙個電梯排程演算法，實現合理排程。
在搞清該用什麼演算法之前，先搞清電梯是怎麼執行的。
那麼電梯是如何執行的？（以下是我們的想法和設計）
假設分兩種訊號，外部訊號與內部訊號，外部訊號就是電梯外乘客的請求訊號，內部訊號就是電梯內乘客所請求的目的地訊號。
首先，假設電梯內部沒人，就沒有內部訊號，當有乘客發出外部訊號時，電梯就會以首先到來的訊號作為方向訊號（上或者下），然後以自己樓層作為出發點，向這個方向進行動態遍歷，電梯就開始執行，同時將遍歷到的最遠端作為終極停靠訊號，並且在執行時不斷檢測，只要有本樓層到終極樓層之間的訊號（無論內外），電梯就會停靠，若此時有不同方向的外部請求訊號，電梯也會先到終極訊號後再折回來。
舉個例子，假設電梯在第9層，有人在第12層發出請求，電梯就把上方作為遍歷的方向，在從9執行到12的過程中，檢測到了第14層，第18層，第5層的訊號，電梯就會將18作為終極訊號（假如沒檢測任何訊號，那麼12就是終極訊號）,假設進入到電梯的乘客此時發出了內部訊號，有第15層，第7層，而15顯然屬於12到18之間的，電梯向上執行，依次在14,15,18停靠，然後方向改變，向下遍歷訊號，已經有第5層的外部訊號和第7層的內部訊號，5比7小，電梯就會將5作為終極停靠訊號，然後在向下執行的同時繼續遍歷，只要出現小於5的訊號，就將此訊號作為終極訊號，並且在從本樓層到終極樓層之間，只要檢測到訊號，無論內外，都會停靠。到了終極樓層5之後，電梯等待方向訊號，然後繼續以上式方式執行。當然，當電梯停靠在某一樓層後，若無輸入訊號，電梯則不會執行，一直在此樓層保持待機狀態，等待訊號輸入。
搞清了電梯的執行模式，接下來是需求分析，這是一幢有
4個電梯的大樓，電梯的載重不都一樣，假設四個電梯分別為
a,b,c,d
，各電梯獨立執行，
a,b電梯都是載重
800公斤，限制
10人，
c電梯載重
1600
公斤，限制
20人，
d電梯載重
2000
公斤，限制
20人，考慮到上下班高峰，為了提高電梯的效率，上班時間（
7:00—8:00,13:00—14:00
），假設
4個電梯都沒有請求訊號，那麼這
4 個電梯都會回到
1層等待，下班時間（
11:00—12:00,17:00—18:00
），電梯則會在
20層等待，除卻上下班的高峰時間，電梯就會在原位置等待，不會回到
1層或者
20層。經過實地調研，大型電梯上下一層的用時約為3秒，單人進出電梯用時約為2秒，故可設電梯開關門用時20秒。
以上就是我們的想法，具體的資料結構及實現還有待商榷。
開發日誌
3月5號 21:00—22:00 網上查閱資料
3月7號 15:00—17:00 結合資料分析題目
3月8號 9:00—11:30 具體分析電梯執行模式
3月8號 15：00—17:00 繼續分析電梯執行模式
3月9號 10:00—11:30 撰寫部落格並完善細節
開發人員：閆立新 蘇海岩
關於OCR，一些想法
ocr一般分為兩種 1，根據給定的字元特徵集合，提取未知字元的特徵進行匹配識別 典型例子 gocr 2，不知道字元特徵，但給出提取特徵的規則，通過機器學習training來獲取某個字符集的特徵集，對未知字元進行匹配識別。典型例子 tesseract 第一種方法簡單，在某些場合很高效，但比較侷限，字符...
關於tv app的一些想法
以前是做iptv機頂盒的，現在是做網際網路電視機頂盒的，在技術上的區別是不大的。通過這些年與電信，廣電打交道，現在對產品有了一些小想法。那麼在顯示上都是以web為主，用web來顯示epg內容，用osd來顯示狀態。但是隨著android的出現，現在大部分機頂盒或電視劇集廠家，都開始了智慧型之旅。乙個是...
關於敏捷的一些想法
敏捷軟體開發宣言 個體和互動 勝過 過程和工具 可以工作的軟體 勝過 面面俱到的文件 客戶合作 勝過 合同談判 響應變化 勝過遵循計畫 今天看了robert martin的ppp一書的第一部分，敏捷開發 回顧了自己曾經加盟過的幾個公司，經歷過的大大小小的專案，感慨良多。這些公司中不乏奉過程開發為寶典...