第二次博客總結

類圖：

 

 

本程序主要有出租車線程(taxi)以及調度線程(sche)，請求類(Request)和尋找 最短路徑類(即 bfs 類)。

出租車線程掌管着出租車本身的狀態以及運行，x，y 表明出租車的座標，tag 爲 出租車派單標識，Num 爲出租車編號，state 爲出租車狀態，credibility 爲出 租車信用度，Request 爲當前接受的乘客請求，shortcut[]存儲最短路徑信息數

組。出租車線程具備增長信用度方法和接受請求方法。

 

調度線程掌管着乘客請求隊列以及出租車隊列，每隔 20ms 掃描一遍乘客請求隊 列，根據必定規則分配乘客請求到特定的出租車。有增長乘客請求方法和增長出 租車方法。

 

請求類掌管着乘客請求的信息，例如起始座標，目的地座標，窗口時間值，備選 出租車隊列，和保存着請求輸出信息的字符串數組。具備增長窗口時間函數，增 加備選出租車方法，以及一些獲取輸出信息的方法，和輸出信息方法。

 

尋找最短路徑類爲 GUI 中尋找最短路徑方法的改進，減小了一些沒必要要的運算步 驟來縮減了運行時間。

 

 

度量圖：

 

 

度量分析可知，taxi做爲判斷出租車的接客，送客，並自行判斷狀態進行state的改變，致使類的複雜度較高。Sche做爲派車調度也較爲複雜。故二者也出現了嵌套深度過多的問題。

 

存在的bug：

1. 無車響應時未輸出
2. 數組越界：

因無腦採用選擇表達式而忘記了判斷數據的存在性：

Flg = ( (guigv.m.map[x][y]==1||guigv.m.map[x][y]==3)

                       && (dis-1==shortcut[x*80+y+1] ) ) ? 4 :

                           ( (guigv.m.map[x][y]==2||guigv.m.map[x][y]==3)

                               &&(dis-1==shortcut[(x+1)*80+y]) ) ? 3 :

                                   ( (guigv.m.map[x-1][y]==2||guigv.m.map[x-1][y]==3)

                                       &&(dis-1==shortcut[(x-1)*80+y]) ) ? 2 :

                                           ( (guigv.m.map[x][y-1]==1||guigv.m.map[x][y-1]==3)

                                               &&(dis-1==shortcut[x*80+y-1]) ) ? 1:

                                               0;

Map數組自己可能越界致使crash。

 

心得體會：

沒啥體會，早進補給站早輕鬆吧。。。

要深刻理解多線程之間的協做關係才能寫好多線程。