OO第二次博客總結作業
第五次作業總結
1.分析協同和同步控制
多線程三部電梯，請求接收和調度器寫在同一個線程中，一個請求進入之後就根據當前各個電梯的狀態進行分配，如果能夠分配就分配給1、2、3的編號，如果不能分配就進行阻塞，當有電梯為wait for service時分配給這個電梯。另有三個電梯線程，一部電梯一個線程。每個電梯線程是相互獨立的，三個電梯線程、一個請求接收和調度器線程，三個電梯分別返回自己的狀態給調度器線程。
2.基於度量來分析自己的程序結構
類圖
解釋分析：
control類：舊的control，被繼承的父類
elevator類：電梯，運行三個電梯線程
floor類：樓層類，沒有用到
Main類：主函數類
NewControl類：繼承舊的control
Request類：請求，用於記錄單挑請求的內容
RequestSimulation類：請求模擬器
Sequence類：linkedlist 請求數組
代碼分析
解釋分析：
DO方法是調度器中執行電梯調度的方法，went是電梯的主要執行方法。
時序圖
3.分析自己的bug
第一個bug：
是判斷捎帶的時候產生了問題，沒有判斷電梯外請求想要前往的方向和當前運動方向是否一致。
第二個bug：
開始的時候不知道什麽原因，導致自己跑這段測試代碼的時候丟了一個請求，後來發現是因為這個請求因為判斷的原因被忽略了...
4.分析自己發現別人bug所采用的策略
我查找別人的bug的策略第一步是依靠我自己在寫這道題時，寫給自己的測試樣例，用別人的程序跑一遍，我的測試樣例都是我覺得哪些點我可能會出錯、或者是哪些不容易被註意的點。第二步是依靠測試樹，在測試樹的分支上特意寫一些代碼用作測試代碼，給被測程序跑。第三步是閱讀被測者的代碼，看看還有哪些我覺得有問題的地方，進行測試。
5.心得體會
第一次使用多線程寫題目，現在回過頭看，發現問題還是很多的。頭一次接觸多線程，發現多線程真的是比單線程有很多好處，但是同時也存在了許多問題例如安全問題等。第一次多線程的體驗還算好，起碼沒有出現太多的問題導致自己的程序崩潰...三個電梯一個電梯一個線程，請求接收和調控器一個線程，四個線程同時進行，完成多線程電梯工作。希望在之後的多線程作業中能收獲更多知識，得到更多的有關多線程的技巧。
第六次作業總結
1.分析協同和同步控制
輸入請求完成之後，將已經準備好的所有監控線程一起啟動，之後啟動測試線程，監控線程會根據測試線程完成的動作返回相應的輸出和完成相應的動作。
2.基於度量來分析自己的程序結構
類圖
解釋分析：
Monitor類：監控線程，完成監控的類
Detail類：寫文件detail.txt
Summary類：寫文件summary.txt
FileAttributes類：文件屬性類，存放文件具體屬性
SafeFile類：安全類，重寫file的方法，保障線程安全
Snapshot類：哈希Map類，用哈希Map進行快照，存放信息
TestThread類：測試文件所用的線程
代碼分析
時序圖
3.分析自己的bug
第一個bug：
由於我是先判斷後加所以當第是十一個進入的時候，count是10，在第十一個監控請求放進隊列之後，count才會變成11，是當時沒有考慮清楚，改成count>=10就可以了
4.分析自己發現別人bug所采用的策略
我查找別人的bug的策略第一步是依靠我自己在寫這道題時，寫給自己的測試樣例，用別人的程序跑一遍，我的測試樣例都是我覺得哪些點我可能會出錯、或者是哪些不容易被註意的點。第二步是依靠測試樹，在測試樹的分支上特意寫一些代碼用作測試代碼，給被測程序跑。第三步是閱讀被測者的代碼，看看還有哪些我覺得有問題的地方，進行測試。
5.心得體會
本次作業的工程量相對較大，線程安全的應用也是第一次實踐到代碼中，更加深一步了解多線程的奧妙的同時，也覺得身心疲憊...我的天，好難啊...隨時準備解決程序可能出現各種各樣奇奇怪怪的bug...一會更改一個版本push一遍，防止自己改哪個地方改崩了。不過助教和老師說這是最難的一次了，剩下的就簡單了（我真是 差點兒就信了），當時一聽這話，精神百倍！奮起直追，記憶猶新當時淩晨三點還只有九個人交了，看來大家為了這次作業都肝到了很晚。不過無論如何，能堅持下來就是件好事。
第七次作業總結
1.分析協同和同步控制
一百個出租車，一百個線程，每個請求一個線程。請求線程的生命周期為3S，3S結束請求線程結束。一百個出租車有請求的時候就完成請求，沒有請求的時候自由跑。
2.基於度量來分析自己的程序結構
類圖
解釋分析：
detail類：將出租車完成的動作寫進文件
Gui類：提供的視圖
Main類：主函數
RequestAndControl類：請求和調度器
Taxi類：出租車類
代碼分析
時序圖
3.分析自己的bug
第一個bug：
沒有判斷輸入的請求出發地和目的地是否是同一個地方
第二個bug：
沒有在readme中說明超過1000條請求會怎麽樣，並且沒有驚醒處理
4.分析自己發現別人bug所采用的策略
我查找別人的bug的策略第一步是依靠我自己在寫這道題時，寫給自己的測試樣例，用別人的程序跑一遍，我的測試樣例都是我覺得哪些點我可能會出錯、或者是哪些不容易被註意的點。第二步是依靠測試樹，在測試樹的分支上特意寫一些代碼用作測試代碼，給被測程序跑。第三步是閱讀被測者的代碼，看看還有哪些我覺得有問題的地方，進行測試。
5.心得體會
這次作業，也沒有助教和老師說的難度小，不過相比前幾次作業，工程量是少了一些，不過感覺在一些細微的地方，還是有些彎彎繞繞值得我們思考。不過，很感謝助教和老師提供了GUI 能夠幫助我們debug，更好的完善自己的代碼，不然光靠代碼測試，還是十分困難的。通過GUI也能讓我們感受到自己的多線程出租車的成果，對於沒有過這種經歷的人來說真的是激動萬分了，能夠看到自己的100倆出租車跑起來完成任務，還真是挺高興的。在完成這次作業的時候，也遇到了一些困難，這是之前多線程沒有遇到過的，包括一些十分嚴重的錯誤，期望自己接下來的作業中，多學只是，刻苦努力。
OO第二次博客總結作業