一.**分析
第五次作業：
uml類圖
耦合度：
第五次作業是實現乙個先來先服務的傻瓜電梯，主要思路就是乙個輸入執行緒，乙個電梯程序，
出現太大的困擾。
第六次作業：
uml類圖：
耦合度：
在做第六次作業的過程中，由於一開始對多執行緒理解不深，對wait，notify的使用非常生疏，
導致一開始將輸入執行緒和排程器執行緒共用請求佇列，自己給自己造成了很大的理解困難，
沒辦法去寫出同時工作的多執行緒，但在寫完大部分後明白了可以拆分成兩個佇列，然而此時
**已經變得十分臃腫，是本次作業的遺憾。
第七次作業：
uml類圖：
耦合度：
第七次作業幾乎是在第六次的框架上寫的，不過將als捎帶改成了look演算法，僅僅是
簡單的改動，因此在做本次作業時遇到的阻力遠遠小於第六次，最後的結果也比較
讓人滿意。
二.程式bug
1.第五次作業沒有出現bug。
2.第六次作業的bug是在寫優化的過程中打錯了括號的位置，又沒有最後再測試就提交了，導致出現了重複進人的bug。
3.第七次作業沒有出現bug，但是程式執行的時間比較長。
三.互測
這一單元的多執行緒作業，在測試的過程中，若是用人眼去找bug，是非常困難的，因此僅僅在第二次作業中通過
觀察**尋找到乙個bug，在後面的作業中，由於寫評測機判斷正確性的難度非常大，所以便放棄了，所以這一單元的
互測幾乎只是學習了其他同學的**。
四.總結
本單元的訓練重點首先是多執行緒的執行緒安全問題和一些多執行緒方法的使用以及對鎖機制的理解，而想要保證這些，
乙個良好的架構能讓自己事半功倍，因此對架構設計能力的培養還是不能落下。對鎖的機制的理解還是非常生疏，
因此在寫作業過程中使用了過多的synchronized導致**看上去十分臃腫。並且在寫本單元作業的過程中由於害怕出錯
從而對優化只做了簡單的嘗試。今後的oo還需要更加努力地去學習。
OO第二單元總結
本單元的作業總體來說比較愉快，畢竟不像上次一樣次次重構。本單元為電梯系列問題，涉及到多執行緒問題。簡單起見，我使用的是生產者 消費者模式。本次作業要求實現單部可稍帶電梯。看完題目後我認為生產者 消費者模式非常適合解決這個問題。本次電梯我採用的是look方法。本方法核心即在於電梯方向的判斷，這在dis...
OO第二單元總結
共享資料類 在總結後面的3.基於度量的程式結構分析部分，本人根據展示的uml類圖更加詳細的講解了具體的協同結構工作原理。通過對實現以上操作的共享資料類中的方法設定synchronized，從而實現執行緒對共享資料的訪問同步。ocplsp ispdip 根據以上類圖，分析本次作業設計思路如下 2 根據...
OO第二單元總結
第二單元總結 第一次作業 思路與反思 uml類圖 度量分析 耦合度 第二次作業 思路 第二次作業與第一次的迭代在於電梯增加 人數限制 樓層改變，我依舊用的look演算法，在第一次作業的基礎上修改細節即可，多部電梯要求實現執行緒安全，由於我使用的look演算法，電梯盲目執行，沒有更高階的排程，只需要在...