首先,在分組之前,我和室友周敏軒已經詳細閱讀了往屆學長的部落格,認為電梯排程這個專案應該先做ui會比較好一點,於是動手展開了ui的編寫;但分組結果並沒有如我們所願,但我們依然共同進行了ui的編寫,希望在第二次結對程式設計中能夠再一起對ui介面進行更新和完善.
ui編寫人員
周敏軒 192
薛亞傑 193
另外，特別感謝毛宇大神對我們編寫ui介面進行了細緻入微的指導。。。
另外，也特別感謝同組隊友周萱(149) 吳淵淵(177)對編寫ui的支援..
..這個要吐槽的地方就太多了..
1.如果passenger到了電梯裡面,就會發出乙個我要到哪層的請求,可是,如果去哪層的按鈕已經被按下了...他還有必要再發出這個請求麼..這個缺陷就會導致其實我可以根據計數來判斷此時是否是上班高峰..算作弊?(這一點參考了學長譚傳奇的想法)
2.api有的地方定義的很差啊...比如莫名其妙的出來個10.0什麼的常數搞的一頭霧水的...完全可以用elev.floorheight來代替好麼...
3.scheduler類中能獲得的東西還是太少...我判斷個請求都那麼麻煩...完全可以在這個類中把request請求定義成passengerrequest類好麼...這樣寫起來就簡單多了...
4.題目要求了電梯有passenger limit,有人數限制,可是在這份api裡面根本找不到關於電梯人數的屬性....好挫.
......待我有了時間,老師等我可好!
tt...向大神諮詢了根據演算法新增ui的方法...很簡單果然..
同一解決方案中新建乙個窗體,在winform中實現簡單繪圖,這裡我一開始用tablepanel輔助繪圖(方便對齊),但是後來實現的時候發現閃爍感太強,刪掉後效果好了很多...
然後新開兩個執行緒,乙個跑電梯排程演算法,另乙個重新整理畫面,這裡採用的時候將四部電梯的label不停的刷location的方法,還不錯.
呵呵.mvc全名是model view controller，是模型(model)－檢視(view)－控制器(controller)的縮寫，一種軟體設計典範，用於組織**用一種業務邏輯和資料顯示分離的方法，這個方法的假設前提是如果業務邏輯被聚集到乙個部件裡面，而且介面和使用者圍繞資料的互動能被改進和個性化定製而不需要重新編寫業務邏輯。mvc被獨特的發展起來用於對映傳統的輸入、處理和輸出功能在乙個邏輯的圖形化使用者介面的結構中。
實現起來很輕鬆啊...winform開發大體流程不都是這樣麼...我在winform中新增控制項,這叫模型;在winform或者**中調整窗體,調整布局,這叫檢視;然後新增事件響應,完成程式邏輯流程,這叫控制器...
首先是電梯模組自然要限定對應電梯的限制樓層
然後電梯排程模組將乘客的我要上電梯請求壓入之後,就要判斷能否完成乘客的到哪層的請求了,如果不能滿足,我們就把他踢出電梯...(呵呵呵),只能說這個乘客真傻,明明不能到哪層還要按下按鈕.
所以說,如果電梯的執行方向有限制,那麼必然需要在電梯外部,就要讓乘客知道,這部電梯能夠到哪些樓層,
這就勢必更改我們排程模組的介面,傳入完整的使用者請求,來判斷應該用哪部電梯來響應使用者請求.
軟體工程附加題
1.你認為本門課程需要在 進行改進，具體措施有哪些，包括 時間進度安排，專案難度等均可 對於軟體使用，希望在學期初確定所適用軟體，統一進行培訓，使後期進度統一。對於任務方面，希望增加個人和結對任務的權重，在評價時候同樣增加其權重。2.你認為助教 老師 做的不足，限制太多等 說實話，老師助教盡心盡力，...
軟體工程課程總結附加題
1.你認為本門課程需要在 進行改進，具體措施有哪些，包括 時間進度安排，專案難度等均可 答 額 上課有點索然無味0.0 希望在課上能夠多學到一點知識，我想是應該我自己沒適應好吧，還以為這節課是教技術的課程。不過，張老師在課上講到自己的做專案啊之類的經驗的時候，我感覺到受益匪淺，畢竟是過來人的經驗很不...
附加題1 我想搞懂的軟體工程問題
第一章問題 1.2.1 軟體有哪些形式？第二章問題 2.1 什麼是單元測試？其建立函式主要步驟？答 單元測試 unit testing 是指對軟體中的最小可測試單元進行檢查和驗證。對於單元測試中單元的含義，一般來說，要根據實際情況去判定其具體含義，如c語言中單元指乙個函式，j a裡單元指乙個類，圖形...