2019北航oo第二單元
1. 第一次作業
1.1實現思路
第一次作業需要完成的任務為單部多執行緒傻瓜排程電梯的模擬。總體來說傻瓜電梯排程坑點不多。採用了生產者消費者模型，輸入為生產者，電梯為消費者。把輸入作為乙個執行緒，電梯作為乙個執行緒，共享排程器資源（也就是請求佇列），其中對電梯上下，開關門的操作是在電梯執行緒中完成的。將輸入的請求儲存到共享的請求佇列中，然後電梯從請求佇列取出一條請求執行。
1.2**分析
uml類圖如下
本意想寫乙個單例模式，但是沒寫好多謝出來乙個single類，雖然沒有影響效能但是架構的不好。
metrics分析
1.3bug分析
由於傻瓜電梯沒有坑點所以強測和互測都沒有找到bug也沒有找到別人的bug。
1.4總結
雖然這次作業並不是很難，但是由於剛剛接觸執行緒，所以還是遇到了一些問題的，不過後來一點點解決了，這也使我進一步理解了程序，算是乙個過渡階段。
2. 第二次作業
2.1實現思路
第二次作業需要完成的任務為單部多執行緒可捎帶排程電梯，相比於第一次作業多了乙個捎帶過程。我的架構還是，輸入作為乙個執行緒，電梯作為乙個執行緒，排程器中儲存著二者共享的請求佇列，其中電梯執行緒中多了乙個自己的請求佇列。這次作業還是把關於電梯的排程放在了電梯內部處理（這為第三次作業帶來了很大困難）。輸入請求儲存到總的請求佇列中，當電梯的請求隊列為空時，從總請求佇列中取出第乙個作為主請求，執行。在執行主請求的過程中，電梯每到達一層，就在電梯請求佇列中找是否有人要出，在總請求佇列中尋找是否有可捎帶的請求，如果有進行捎帶。
2.2**分析
uml類圖如下
metrics分析
2.3bug分析
強測掛了3個點，互測中被瘋狂hack，後來找了一下問題，發現是排程上的問題，在某種情況下電梯停不下來！瘋狂向上或者是瘋狂向下。為了讓電梯正常捎帶，當前電梯在1層，主請求為7層到1層，電梯在上樓這個過程中需要捎帶一些向上的乘客，也就是電梯開始的狀態是向上執行的和主請求不一致，當我們接到主請求且把電梯中的向上捎帶都送到了目的樓層，我要將電梯的執行方向反轉一下，也就是和主請求保持一致，這個地方我寫了很久！最後還是沒判斷好！又錯了！因為判斷條件寫的太侷限了。
互測中也沒找到其他人什麼bug，主要是通過對一些易錯型別進行測試，只測出來幾個人。
2.4總結
第二次作業我重構了3次！本來是打算為下次作業做準備，然而因為太菜了，一直在錯！後來換了一種方法，又出現了執行緒安全問題！最後不得不放棄，沿用第一次的傻瓜電梯，勉強算是過了中測，強測還是崩了。對執行緒和執行緒安全等問題還不是完全理解，所以在寫**的時候才會遇到各種問題且很難解決。
3. 第三次作業
菜的真實，沒寫出來。還是架構的問題，不太清楚要怎麼進行排程和請求分配，以及鎖也不是很會用，這些問題在第
一、二次都勉勉強強過了，在第三次作業中全部成為擺在我面前的障礙。
4. 總結
關於測試和bug，就像很多人用「玄學」來形容執行緒，它一旦出現bug是很難復現的，可能這次對了，下次就錯了，也很難進行除錯。總之一旦執行緒出現錯誤，總是令我抓狂，我要用很長的時間來修復這個bug。最後就是我執行緒這部分知識學的不太好，到現在還對很多概念和知識一知半解，一到實際應用就有更多的問題了。還要花更多時間來好好學！
OO第二單元總結
本單元的作業總體來說比較愉快，畢竟不像上次一樣次次重構。本單元為電梯系列問題，涉及到多執行緒問題。簡單起見，我使用的是生產者 消費者模式。本次作業要求實現單部可稍帶電梯。看完題目後我認為生產者 消費者模式非常適合解決這個問題。本次電梯我採用的是look方法。本方法核心即在於電梯方向的判斷，這在dis...
OO第二單元總結
共享資料類 在總結後面的3.基於度量的程式結構分析部分，本人根據展示的uml類圖更加詳細的講解了具體的協同結構工作原理。通過對實現以上操作的共享資料類中的方法設定synchronized，從而實現執行緒對共享資料的訪問同步。ocplsp ispdip 根據以上類圖，分析本次作業設計思路如下 2 根據...
OO第二單元總結
第二單元總結 第一次作業 思路與反思 uml類圖 度量分析 耦合度 第二次作業 思路 第二次作業與第一次的迭代在於電梯增加 人數限制 樓層改變，我依舊用的look演算法，在第一次作業的基礎上修改細節即可，多部電梯要求實現執行緒安全，由於我使用的look演算法，電梯盲目執行，沒有更高階的排程，只需要在...