這三次作業都是要識別問題域中的物件的特點，發現誰是執行緒，哪些資料是共享資料，需不需要做安全處理。
在做作業5時，參考的類圖和程式框架圖中說明的很清楚，每部電梯是乙個獨立的執行緒，請求模擬器模擬產生使用者請求也應是獨立執行緒，排程系統也是獨立執行的執行緒，而請求佇列和電梯狀態是共享資料，在訪問時需要進行訪問控制。
作業6，自己將每乙個合法輸入的不重複的命令生成乙個獨立的監控執行緒，而所有被監控物件都生成乙個共同快照（快取），是共享資料，設計相對簡單。
作業7，將每一輛計程車設計為乙個執行緒，計程車的狀態資料是一種共享資料。模擬產生使用者的呼叫中心設計成乙個獨立執行緒（這個執行緒類似於生產者執行緒），呼叫處理排程器也設計成乙個獨立的執行緒（類似於消費者執行緒），呼叫佇列是共享資料。
1、類圖
figure 1 第五次作業類圖
figure 2 第六次作業類圖
figure 3 第七次作業類圖
2、
uml協作圖
figure 4 第五次作業協作圖
figure 5 第六次作業協作圖
figure 6 第七次作業協作圖
3、類分析
這幾次的作業，主要的考察點是在多執行緒的安全部分，卡輸入，卡邊界的測試已經少了很多，在電梯和監控當中，建立多執行緒的目標是明確的。每乙個電梯是乙個執行緒，每乙個請求是乙個執行緒。而到了之後的幾次中，可能有好幾處需要考慮多執行緒的內容，比如在計程車的問題中，計程車，乘客和請求是否需要單獨建立執行緒，將搶單的行為放在哪個類下面都是需要考慮的情況。課程後半部分的測試與前半部分是略有不同的，除去直接看**的方法以外，想要通過輸入----輸出的情況來測試已經變得比較麻煩，比如在第七次作業的測試中，除了輸入後針對性的看某個乘客或者某個計程車的運**況以外，一次輸入多條指令的做法只能作為壓力測試。因為除非
crash
否則，多條指令中某步執行出錯是不能用模擬的方法得到期望輸出的。
因此對於對方程式的測試主要就是將自己的測試樣例過一遍，因為對於這些樣例的考察點和期望輸出有一定了解，否則不看**的話某輛車在某條路上執行時間不對感覺很難發現。
1老師在對我們上課估計每次作業的時候是單獨列出思考指導書的時間的，而在作業越來越複雜後我確實感到指導書是需要單獨拿出來理清之後再開始思考的。比如計程車的信用我一開始的時候沒有發現有什麼用，以為是用來給計程車的行動計數的，因此搶單中根本沒有加入信用，後來和同學討論的時候才發現這一點，還需要回去進行不小的改動。
2在追趕別人的過程中，邁出一步比不動要好。差距仍然存在，但是向前進總是比什麼都不做要好。比起思考在2.9s的時候突然有乙個新的請求，能夠做出來能響應一開始就存在的請求更為重要，我一開始沒有想到怎麼測試，就直接用隨機生成的請求。雖然不能發現細微的錯誤，但是可以看到程式跑了起來，先弄清楚每一次的考察點所在並且有一定了解我覺得是放在第一位的。
3 show me your code 是最重要的學習方式。這門課一方面是建立物件導向程式設計的思維，一方面也是在提高**能力。每一次的作業既是測試，也是使得人進步的壓力。確確實實的敲下每一行**，使得人受益匪淺。
4與此同時，
io.file
，基於hash
值的動態鎖，很多內容我們也是不斷在資料中看到並且學習的，溝通與交流也是不可或缺的能力之一
OO第二階段作業總結
前言 本次部落格是針對pta中的第4，5，6次作業的總結，其中我前面兩次沒有得到滿分，但是都及格了，最後一次我覺得相對更簡單一些。作業過程總結 總結三次作業之間的知識迭代關係 這三次作業主要圍繞正規表示式的應用和圖形的繼承展開，其中關於正規表示式的校驗兩題我都覺得有點難度，要考慮的方面有點多 圖形的...
第二階段小結
資料結構基本概念 資料 資料即資訊的載體，是能夠輸入到計算機中並且能被計算機識別，儲存和處理的符號總稱 資料元素 資料元素是資料的基本單位，又稱之為記錄。一般，資料元素由若干基本項 字段，域，屬性 組成。資料結構 資料結構指的是資料元素及資料元素之間的相互關係，或組織資料的形式 資料之間的結構關係 ...
第二階段小結
先是pta上的作業 這題要求我們熟練的掌握類之間的繼承與多型的使用，在類與類之間傳遞資訊時不能弄混，要弄清楚單一職責原則。這一題主要考察繼承與多型，泛型容器的應用。接下來是學習通上的課後作業 第乙個是單向鍊錶 單向鍊錶由乙個個的節點組成，這些節點都帶有下乙個節點的引用，最後乙個節點指向null，這樣...