類圖：

本程序主要有出租車線程(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

&&(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。

心得體會：

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

要深入理解多線程之間的協作關系才能寫好多線程。

第二次博客總結