【正文】 特此聲明！ 作者簽名： 年 月 日 。 （ 5）學(xué)?？梢怨紝W(xué)位論文的全部或部分內(nèi)容（保密學(xué)位論文在解密后遵守此規(guī)定）。 （ 3）學(xué)?？梢詫W(xué)術(shù)交流為目的復(fù)制、贈送和交換學(xué)位論文。 關(guān)于學(xué)位論文使用權(quán)和研究成果知識產(chǎn)權(quán)的說明 本人完全了解成都信息工程學(xué)院有關(guān)保管使用學(xué)位論文的規(guī)定，其中包括： （ 1）學(xué)校有權(quán)保管并向有關(guān)部門遞交學(xué)位論文的原件與復(fù)印件。文中除了特別加以標(biāo)注地方外，不包含他人已經(jīng)發(fā)表或撰寫過的研究成果，也不包含為獲得成都信息工程學(xué)院或其他教學(xué)機(jī)構(gòu)的學(xué)位或證書而使用過的材料。 第 37 頁 共 38 頁 致謝 本文是在 ???老師的熱情關(guān)心和指導(dǎo)下完成的，他淵博的知識和嚴(yán)謹(jǐn)?shù)闹?學(xué)作風(fēng)使我受益匪淺，對順利完成本課題起到了極大的作用。 [7] 里德 .JAVA與 UML 協(xié)同應(yīng)用開發(fā) [M].北京：清華大學(xué)出版社 ,2021。 [5] 殷兆 麟，張永平，姜淑娟 .Java網(wǎng)絡(luò)高級編程 [M].北京：清華大學(xué)出版社 ,北京交通大學(xué)出版社， 2021。 [3] 鄭阿奇 ,王燕平 ,湯玫 .ASP 程序設(shè)計(jì)教程 [M].北京：機(jī)械工業(yè) 出版社 ,2021。 程序中利用了 Factory 模式和 Proxy 模式和 Bridge 模式，有利于程序的擴(kuò)展。 通 過序列化類的方式在服務(wù)端與客戶端傳送大量異構(gòu)型數(shù)據(jù)。本系統(tǒng) 人機(jī)對弈的算法 采用 棋盤 最小推算點(diǎn) 的 局部遍歷的方法 ,在判斷 精度 上 不是很高， 有待于繼續(xù)優(yōu)化邏輯實(shí)現(xiàn)上的代碼，進(jìn)行更細(xì)致的劃分和處理 。 此五子棋游戲能夠在互連網(wǎng)中進(jìn)行雙人對弈。能滿足用戶聊天和休閑愉悅的需求。 第 36 頁 共 38 頁 結(jié)論 經(jīng)過幾個月的時間終于完成 網(wǎng)絡(luò) 聊天與五子棋的設(shè)計(jì)與實(shí)現(xiàn) 。在以內(nèi)存耗費(fèi)為代價下提高了查詢速度， 并 解決了并發(fā)訪問數(shù)據(jù)庫瓶頸的問題。如果界面正常，而打印出來到數(shù)據(jù)有問題說明邏輯上的設(shè)計(jì)有錯誤。進(jìn)行對比分析。 第 6 章系統(tǒng)測試與性能分析 在程序中為每個測試模塊 的 關(guān)鍵點(diǎn)進(jìn)行數(shù)據(jù)捕捉，然后打印出來。音樂播放類負(fù)責(zé)對歌曲的播放。 界面中負(fù)責(zé)各個線程的啟動為停止或者掛起。 音樂播放器的實(shí)現(xiàn)說明 音樂播放器主要是在多線程中工作。刷新棋盤。 最后統(tǒng)計(jì)分?jǐn)?shù)的公式 =獲勝積分 +獎勵積分 處罰積分。如果對方悔棋成功則自己獎勵積分加 5 分，對方處罰積分加 2分。程序中的自己的積分信息和對方的積分信息是單獨(dú)統(tǒng)計(jì)的。同時也取得記錄對方的積分信息類的對象的積分信息并與 本次對方應(yīng) 得 的積分作累加再寫入到對象的屬性中 ，同時發(fā)送到服務(wù)端，服務(wù)端向數(shù)據(jù)層發(fā)送消息進(jìn)行數(shù)據(jù)的存儲。 程序中定義存儲積分信息的積分類。 游戲積分處理的實(shí)現(xiàn)說明 游戲采用積分制度。 并存儲到數(shù)組中。程序中用二維數(shù)組來存儲棋盤中的交叉點(diǎn)。只有在數(shù)據(jù)層操作成功的情況下，客戶端才能更新結(jié)果。 用戶移動好友，刪除好友，增加好友的實(shí)現(xiàn)說明 用戶在選擇了移動好友，刪除好友，增加好友的業(yè)務(wù)時，均采用客戶端向服務(wù)端發(fā)送包含業(yè)務(wù)相關(guān)信息的數(shù)據(jù)包。 5 客戶端收到信息后更新自己界面中的數(shù)據(jù)。 3 客戶端 下棋，并向服務(wù)端發(fā)送相應(yīng)的數(shù)據(jù)包。主要流程如下： 1 客戶端選擇臺面進(jìn)入游戲，就會向服務(wù)端發(fā)送入座的臺面和臺面中的椅子位置。 其次服務(wù)端定義了臺面狀態(tài)類。 多用戶并發(fā)下棋的實(shí)現(xiàn)方式 多用戶并發(fā)下棋主要是由服務(wù)端負(fù)責(zé)。沒有則建立該用戶的聊天窗口對象 ，并將對象加入到聊天窗口信息記錄表中。 3 客戶端接收到消息后分析數(shù)據(jù)。 2 服務(wù)端到線程記錄表中查找是否有該聊天者的線程記錄。服務(wù)端根據(jù)記錄每個連接用戶的線程信息來處理每個用戶的業(yè)務(wù)。并根據(jù)這些信息來填寫自己的好友列表好黑名單列表。因?yàn)?list 是可序列化的類類型。在讀字符流的時候采用bufferreader 進(jìn)行快速讀取。而對于大量異構(gòu)類型的數(shù)據(jù)傳送則采用序列化類。對于只需要快速隨機(jī)訪問的操作， 則采用arrylist 而對于需要頻繁的插入和刪除采用 linkedlist。對于同步的則采用 hashtable 的方式進(jìn)行。程序中涉及查詢的結(jié)構(gòu)時都是采用 hash 的方式。如下圖所示： 圖 37 驗(yàn)證碼 整體提升性能的解決方案 性能提 升 的原則和方法主要在以下幾個方面： 凡是大量用到字符串連接的操作時，變量結(jié)構(gòu)摒棄 String 而是采用StringBuider，原因是 String 的連接操作會產(chǎn)生新的變量 ?，F(xiàn)在在應(yīng)用程序中注冊不會出現(xiàn) 灌水性注冊。 圖 36 數(shù)據(jù)庫設(shè)計(jì)圖 第 33 頁 共 38 頁 防止灌水性注冊的解決方案 本程序中采用了兩種方式注冊用戶一種是在 應(yīng)用程序中注冊。所以把用戶信息表分割成了兩個表，一個是用戶永久不變的信息表和用戶經(jīng)常變動的好友表。為了減少實(shí)體外部屬性數(shù)據(jù)或行數(shù)據(jù)的開支而把 1個實(shí)體 (表 )垂直分割成 2 個表 (把所有的屬性分成 2組 )。 數(shù)據(jù)庫表效率問題 的 解決方案 如果規(guī)范化設(shè)計(jì)產(chǎn)生了許多 4路或更多路合并關(guān)系，而在具體應(yīng)用中會大量使用這些 合并關(guān)系，就可以考慮在數(shù)據(jù)庫實(shí)體 (表 )中加入重復(fù)屬性 (列 )。 6 根據(jù)各個方向的加權(quán)值取得最大加權(quán)值 的方向 作為計(jì)算機(jī)落棋的最優(yōu)方向。搜索的距離是五個棋子位置的距離。 3 計(jì)算機(jī)取得用戶落棋的坐標(biāo)并轉(zhuǎn)換成棋盤 結(jié)構(gòu) 中的相應(yīng)位置。對四個方向的加權(quán)值進(jìn)行比較取得加權(quán)值最大的那個方向作為落棋方向的最優(yōu)方向。如下圖所示： 第 31 頁 共 38 頁 圖 34 人機(jī)對弈算法圖 用戶落棋后計(jì)算機(jī)取得用戶落棋的位置并以該位置為起點(diǎn)放射性的進(jìn)行四個方向的搜尋統(tǒng)計(jì)棋子。黑色棋子的坐標(biāo)（ 5， 11）落在 黑色線包圍的 區(qū)域中根據(jù)該區(qū)域的算法得到該落棋點(diǎn)的最大后推結(jié)束點(diǎn)坐標(biāo) =（ 5+4=9， 114=7）即最大后推點(diǎn)為圖 中 黑色 圓 圈 處（ 9， 7）。黑 色 線包圍的 區(qū)域中的最大結(jié)束點(diǎn)坐標(biāo)算法為： 最大后推結(jié)束點(diǎn)坐標(biāo) =（落棋點(diǎn)橫向坐標(biāo) +4，落棋點(diǎn)縱向坐標(biāo) 4）。 對角線下方分割規(guī)則和算法： 圖 33 “ /”下方分割舉例圖 在白色線包圍的區(qū)域具有統(tǒng)一的最大后推結(jié)束點(diǎn)的算法，黑 色線包圍的區(qū)域中有著統(tǒng)一的最大后推結(jié)束點(diǎn)的算法。所以該區(qū)域中的最大結(jié)束點(diǎn)坐標(biāo)算法為：最大結(jié)束點(diǎn)坐標(biāo) =(落棋點(diǎn)橫向坐標(biāo) +落棋點(diǎn)縱向坐標(biāo)， 0)。白色線 包圍的區(qū)域內(nèi) 具有統(tǒng)一的最大結(jié)束點(diǎn)后推方法， 黑色線包圍 的區(qū)域中具有統(tǒng)一的最大結(jié)束點(diǎn)后推方法。 對角 線上方分割規(guī)則和算法如下： 圖 32 “ /”分割舉例圖 棋盤被對角線分割后，主要通過從落棋點(diǎn)到最大結(jié)束點(diǎn)的棋盤遍歷方式來進(jìn)行輸贏判斷。此時的最小起始點(diǎn)的推算方法為（最小起始點(diǎn)橫向坐標(biāo) =落棋點(diǎn)橫向坐標(biāo) —落棋點(diǎn)縱向坐標(biāo)， 0）根據(jù)此公式得出最小起始點(diǎn)坐標(biāo)為 (1,0)在 黑色線 包圍的區(qū)域中有著通用的最小起始點(diǎn)算法（最小起始點(diǎn)橫向坐標(biāo) =落棋點(diǎn)橫向坐標(biāo) — 4，最小起始點(diǎn)縱向坐標(biāo) =落棋點(diǎn)縱向坐標(biāo) — 4）。如果 在保持與對角線平行的條件下 推算會 出現(xiàn)小于零。根據(jù)前面的橫向最小起始點(diǎn)推算法則最小起始點(diǎn)的橫向起始點(diǎn)會出現(xiàn)越界的問題。而在 黑色線包圍的 區(qū)域內(nèi)符合通用的推算法（最小起始點(diǎn)橫向坐標(biāo)點(diǎn) =落棋橫向坐標(biāo) 4，最小起始點(diǎn)縱向坐標(biāo)點(diǎn) =落棋縱向坐標(biāo)點(diǎn) 4）。所以此區(qū)域有著單獨(dú)的縱向最小起始點(diǎn)的推算方法。 圖 28 “ \” 子分割圖 此時根據(jù)與對角線方向平行。對上下方繼續(xù)進(jìn)行分割 對角線下方分割如下圖 : 圖 27 “ \”下方子分割圖 在白色線 包圍 的區(qū)域中具有同一種判斷屬性。如果不小于 4，則最小起始點(diǎn)的縱坐標(biāo) =落 棋點(diǎn)的縱坐標(biāo) 4，并 繼續(xù)進(jìn)行判斷是否小于 10，不小于10 最大結(jié)束點(diǎn) 縱 坐標(biāo)等于 14 ，小于 10 則最大結(jié)束點(diǎn) 縱 坐標(biāo)等于 落棋點(diǎn)的縱 坐標(biāo) +4。如果不小于 4，最小起始點(diǎn)橫坐標(biāo) =落棋點(diǎn)的橫坐標(biāo) 4，并 繼續(xù)進(jìn)行判斷是否小于 10，不小于 10 最大結(jié)束點(diǎn)橫坐標(biāo)等于 14 ，小于 10 則最大結(jié)束點(diǎn)橫坐標(biāo)等于落棋點(diǎn)的橫坐標(biāo)+4。 2 取得落棋點(diǎn)的坐標(biāo)，并轉(zhuǎn)換為棋盤中相應(yīng)的坐標(biāo)。 元算法如下圖所示 圖 24 棋盤分割算法元 第 26 頁 共 38 頁 輸贏判斷和人機(jī)對弈的算法遍歷則 是 根據(jù)推算出的最小起始點(diǎn)和最大結(jié)束點(diǎn)進(jìn)行棋盤的局部遍歷。在速度上比 hashmap 速度慢一些 ， 但是他會減少 hash 的空間浪費(fèi)問題。如果是查詢某個具體的數(shù)據(jù)則會出現(xiàn)二次遍歷 。 Hashmap 中的 value 用相應(yīng)的類列表進(jìn)行填充。通過 Hash 方式檢索定位數(shù)據(jù) ，在速度 上 會得到很大的提高。為了保證所有客戶請求數(shù)據(jù)的唯一性， Server 端采用 Singleton 模式。客戶端的所有數(shù)據(jù)業(yè)務(wù)請求 ， Server 端不會直接與數(shù)據(jù)庫操作。那么數(shù)據(jù)庫的并 發(fā)訪問就成了數(shù)據(jù)庫應(yīng)用的瓶頸。 數(shù)據(jù)包設(shè)計(jì) 第 24 頁 共 38 頁 表 1 數(shù)據(jù)包格式表 數(shù)據(jù)包格式 發(fā)包端 說明 login:臺號，椅子號 客戶端 申請入座該臺號，椅子號的座位 logout:臺號，椅子號 客戶端 注銷該臺號，椅子號的座位，當(dāng)客戶段換座位時先發(fā)出 lougout play! 客戶端 請求與入座的另一方開始對弈 ，服務(wù)器可判斷出客戶的臺號和 椅子位置 下同 go:棋子位置 客戶端 請求服務(wù)器轉(zhuǎn)發(fā)一步棋給對方 win:棋子位置 客戶端 客戶下完一步棋后發(fā)現(xiàn)自己贏了將發(fā)送此 數(shù)據(jù)包到服務(wù)器要求 轉(zhuǎn)發(fā)對弈方對方收到后 將這步棋顯示出來并彈出輸了的信息框 peace:棋子位置 客戶端 客戶下完棋發(fā)現(xiàn)雙方打和將發(fā)送數(shù)據(jù)包到服務(wù)器 對弈方收到服 務(wù)器的轉(zhuǎn)發(fā)消息后 將這步棋顯示出來并彈出雙方打和的消息框 talk:聊天話本 客戶端 請求服務(wù)器轉(zhuǎn)發(fā)該聊天話本給對弈方 Restart! 客戶端 客戶端點(diǎn)擊 ” 重新對弈 ” 按鈕后發(fā)送該請求 到服務(wù)器，服務(wù)器將轉(zhuǎn)發(fā) 該數(shù)據(jù)包到對弈方 agree! 客戶端 客戶 收到對弈方請求重新開始對弈后，若接受 ，將發(fā)送數(shù)據(jù)包到服務(wù)器讓服 器轉(zhuǎn)發(fā)回請求者 go back! 客戶端 客戶點(diǎn)擊 ” 返回大廳 ’ 按鈕后發(fā)送數(shù)據(jù)包到服務(wù)器，服 務(wù)器收到后將轉(zhuǎn)發(fā)給對弈方 ，也導(dǎo)致對弈方返回大廳 exit:臺號，椅子號 客戶端 用戶強(qiáng)行關(guān)閉網(wǎng)頁時，將導(dǎo)致客戶 Applet 發(fā)送數(shù)據(jù)包到服務(wù)器 refresh! 客戶端 客戶請求服務(wù)器將游戲臺面，椅子的入座情況信息，以刷新自己的游戲大廳 seat:臺號，椅子號 服務(wù)器 服務(wù)器向客戶發(fā)送某臺上的椅子的 情 況 no seat! 服務(wù)器 服務(wù)器向客戶返回該座位不可申請坐下的信息 start:椅子號 服務(wù)器 客戶點(diǎn)擊 ” 開始對弈 ” 按鈕后服務(wù)器判 斷雙方可進(jìn)行對弈就向雙方發(fā)送數(shù)據(jù) 包 chess:棋子位置 服務(wù)器 服務(wù)器向客戶端轉(zhuǎn)發(fā)對方的一步棋 defeat:棋子位置 服務(wù)器 客戶端判斷自己贏棋 后，發(fā)送 數(shù)據(jù) 包給服務(wù)器，服務(wù)器將 發(fā)出 defeat 包給對弈方讓他們彈出一個提示輸棋的信息框 peace! 服務(wù)器 客戶端判斷棋局打和后向服務(wù)器發(fā)送打 和信息 服務(wù)器轉(zhuǎn)發(fā)該包向?qū)姆奖砻鞔蚝? message:； 聊天話本 服務(wù)器 客戶端通過 talk 包向服務(wù)器發(fā)送聊天信息，服務(wù)器收到后 ，發(fā)一個 message 包給對弈方和自己，使聊天話本顯示出來 agree? 服務(wù)器 當(dāng)客戶端點(diǎn)擊 ” 重新對弈 ” 按鈕后 ，服務(wù)器收到 后將發(fā)送此格式包給對弈方詢問是否愿意重新開始 agree! 服務(wù)器 當(dāng)服務(wù)器收到對弈方同意重新開始后將 發(fā)送此格式包到原來的請求方以表明情況 go back! 服務(wù)器 游戲一方通知其已返回游戲大廳之后 服務(wù)器發(fā)送此包通知另一方 第 25 頁 共 38 頁 5 系統(tǒng)算法的詳細(xì)分析報(bào)告 數(shù)據(jù)庫并發(fā)訪問瓶頸問題解決方案 數(shù)據(jù)庫的設(shè)計(jì)無非 就是 建立 索引， 對 表分割 ，主鍵的建立，以及 SQL 語句的編寫。游戲客戶端大部分是在處理用戶的界面的維護(hù)，所以游戲客戶端采用多線程機(jī)制。當(dāng)用戶收到聊天消息時，系統(tǒng)分析數(shù)據(jù)后同樣 到 聊天窗口信息記錄表中查找是否有該用戶的聊天窗口對象，如果有就換出并設(shè)置為活躍窗口，如果沒有則建立該用戶的聊天窗口對象，并將對象加入到聊天窗口信息記錄表中。 首先用戶在選擇與某個人聊天時，系統(tǒng)就到窗體信息記錄表中 查找 是否有該用戶的聊天窗口信息記錄，如果有則把該窗體換出設(shè)置為當(dāng)前活躍的窗體。 聊天客戶端采用記錄聊天窗口對象的機(jī)制處理多用戶的聊天信息。服務(wù)