【正文】 。 學(xué)習(xí)寄語(yǔ) ： 想必大家都用過(guò) ，其主要功能就是 聊天 ，是不是很想知道它是如何實(shí)現(xiàn)的？本 項(xiàng)目 就是幫你實(shí)現(xiàn)一個(gè)簡(jiǎn)單的 聊天 系統(tǒng)， 當(dāng)然跟 商業(yè)項(xiàng)目 沒(méi)法比，但從中你卻可以了解這些系統(tǒng)是如何實(shí)現(xiàn)的，學(xué)到開(kāi)發(fā)類(lèi) 似系統(tǒng)的基礎(chǔ)知識(shí)和 基本 技能 （基本并不意味不實(shí)用） 。 我們的信 念依然 是：“不拋棄，不放棄”。 Come on! 背景介紹 業(yè)務(wù)背景 隨著網(wǎng)絡(luò)社會(huì)的不斷發(fā)展，具有相同興趣的網(wǎng)民 需要 互相 遠(yuǎn)程交流 ， 既要能省錢(qián)又要能即時(shí)交互 ，電話(huà)太貴、 又嫌慢， 所以開(kāi)發(fā)一個(gè)類(lèi)似 的及時(shí)通訊系統(tǒng)就變得非常有意義 了 。 它提供的功能遠(yuǎn)不如 豐富，但應(yīng)具有如下功能：（ 1） 與聊天室成員一起聊天 ；（ 2） 可以與聊天室成員私聊 ；（ 3） 用戶(hù)注冊(cè)、登錄 ；（ 4） 服務(wù)器監(jiān)控聊天內(nèi)容 ；（ 5） 服務(wù)器發(fā)送通知 ；（ 6） 服務(wù)器踢人 ；（ 7） 保存服務(wù)器日志。 技術(shù)背景 本系統(tǒng)要求使用 java 技術(shù)開(kāi)發(fā)，使用文件保存數(shù)據(jù)，集成開(kāi)發(fā)環(huán)境使用eclipse。系統(tǒng)采用兩層 C/S 體系結(jié)構(gòu)， C 端負(fù)責(zé)通過(guò) GUI 與 客戶(hù)交互，實(shí)現(xiàn)注冊(cè)、登陸、收發(fā)信息、退出等功能； S端是 聊天系統(tǒng)的應(yīng)用服務(wù)器， 主要有處理 用戶(hù)注冊(cè) 、 登錄 、 用戶(hù) 收 發(fā)信息 、 用戶(hù)退出 等功能。 當(dāng)用戶(hù) 想 聊天時(shí)， 從界 面輸入信息， 然后與服務(wù)器建立 Socket 連接 （連接時(shí)應(yīng)指定服務(wù)器的 IP 地址和端口號(hào)，而客戶(hù)端 socket 的端口由本方操作系統(tǒng) 從空閑端口中 確定） ， 服務(wù)器端的 “傾聽(tīng) Socket” 收到連接請(qǐng)求后，一般會(huì)接受連接請(qǐng)求，并生成一個(gè)服務(wù)端 socket（其端口號(hào)由服務(wù)端操作系統(tǒng) 從空閑端口中 確定）， 專(zhuān)門(mén)負(fù)責(zé)與此客戶(hù)端 socket 的通信。 服務(wù)方也可以根據(jù)需要，通過(guò) socket 的輸出流發(fā)信息和請(qǐng)求給客戶(hù)端 （公告） 。 不難發(fā)現(xiàn)服務(wù) 器 需要 能 同時(shí)接受多個(gè)客戶(hù)的請(qǐng)求 ，為了實(shí)現(xiàn)這一點(diǎn)，一般使用多線程機(jī)制來(lái)處理，對(duì)每一個(gè)客戶(hù)端連接通訊，服務(wù)器端都有一個(gè)線程專(zhuān)門(mén)負(fù)責(zé)處理（相當(dāng)于一個(gè)服務(wù)員 專(zhuān)門(mén) 服務(wù)一個(gè)以 IP 地址和端口號(hào)唯一標(biāo)識(shí)的客戶(hù)）。能不能聊天者之間直接 通信？當(dāng)然可以，這是所謂的 P2P聊天室，缺點(diǎn)是對(duì)聊天者缺乏集中監(jiān)管的手段。 本文主要采用聊天信息通過(guò)服務(wù)器轉(zhuǎn)發(fā)的方式，而且只支持一個(gè)聊天室。 需求分析 功能需求分析 系統(tǒng)的主要功能已在業(yè)務(wù)分析中有所介紹， 在這里需要對(duì)每個(gè)功能從使用者角度作較為具體的分析。 以下是 主要 用例描述 一 客戶(hù)端 1 . 注冊(cè) （ 1）客戶(hù)啟動(dòng)程序，顯示出登陸界面 （ 2） 客戶(hù)選擇其中的 注冊(cè) 按鈕，系統(tǒng)顯示注冊(cè)界面 （ 3）客戶(hù)填寫(xiě) 用戶(hù)名、密碼、確認(rèn)密碼、性別、年齡、電子郵件，按確定按鈕 （ 4）系統(tǒng)驗(yàn)證密碼和確認(rèn)密碼是否相符、用戶(hù)名（不能重復(fù)）、電子郵件格式、年齡（大于 10 小于 100） （ 5）系統(tǒng) 發(fā) 送 上述 信息 及“注冊(cè)請(qǐng)求” 到服務(wù)端， 等待 服務(wù)端 返回“注冊(cè)成功 ” 消息 （ 6） 系統(tǒng) 提示注冊(cè)成功 （ 7）系統(tǒng)返回登陸界面 若驗(yàn)證失敗，提示“ 重新輸入” 若 服務(wù)端返回“ 注冊(cè)失敗 ” ，提示“注冊(cè)失敗” 若服務(wù)端返回“注冊(cè)失敗 用戶(hù)名重名”，則 提示“ 注冊(cè)失敗 用戶(hù)重名”。 若服務(wù)端返回“登錄失敗”，系統(tǒng)提示“用戶(hù)名或密碼錯(cuò)”。 （ 3）系統(tǒng)發(fā)送信息 及“ 接收 消息 請(qǐng)求” 到 服務(wù)器端 ，等待服務(wù)端返回 “接收成功” 消息 （等待返回消息可?。?。 4. 接收 信息 （ 1） 客戶(hù)端系統(tǒng)啟動(dòng)，進(jìn)入主界面后， 會(huì)顯示消息接收框 （ 2） 其他 客戶(hù) 或 服務(wù)端 系統(tǒng)本身 發(fā)送消息 過(guò)來(lái) ， 系統(tǒng)接收，分析確認(rèn)是 ” 接收 消息請(qǐng)求“，則分析提取出消息 (3) 在 消息接收 框逐條顯示發(fā)送者姓名、發(fā)送的消息。 （ 4）系統(tǒng)根據(jù)用戶(hù)名，在已有客戶(hù)記錄中查詢(xún)，確認(rèn)沒(méi)有重名 （ 5）系統(tǒng)將用戶(hù)名、密碼、確認(rèn)密碼、性別、年齡、電子郵件信息保存 （ 6）系統(tǒng)向客戶(hù) 端發(fā)送 “注冊(cè)成功”消息 （ 7）系統(tǒng)在監(jiān)控界面上寫(xiě)信息： xx 客戶(hù)名 已注冊(cè) 注冊(cè)時(shí)間 若重名，向客戶(hù)端發(fā)“注冊(cè)重名”消息 若注冊(cè)失敗，向客戶(hù)端發(fā)“注冊(cè)失敗”消息 2. 用戶(hù)登錄 （ 1）系統(tǒng)啟動(dòng)后，等待客戶(hù)請(qǐng)求 （ 2）客戶(hù)請(qǐng)求到，接 受請(qǐng)求，分析確認(rèn)是“登錄請(qǐng)求” （ 3）系統(tǒng)讀取信息，驗(yàn)證 用戶(hù)名、密碼 是否存在 （ 4）系統(tǒng) 驗(yàn)證是否已經(jīng)登錄 （ 5）系統(tǒng)驗(yàn)證用戶(hù)是否已超過(guò)最大用戶(hù)數(shù) （ 6） 系統(tǒng) 將客戶(hù)加入聊天室 ，通知其它客戶(hù)“新用戶(hù)加入” （ 7）系統(tǒng)向客戶(hù)端發(fā)送“ 登錄 成功”消息 （ 8）系統(tǒng)在監(jiān)控界面上寫(xiě)信息：客戶(hù)名 ： 已登錄 登錄時(shí)間 若驗(yàn)證失敗，向客戶(hù)端發(fā)“驗(yàn)證失敗”消息 3. 發(fā)送信息 （用于管理員向聊天者發(fā)送 公告 信息 ） （ 1）系統(tǒng)啟動(dòng)后，等待 管理員 請(qǐng)求 （ 2） 管理員在監(jiān)控界面輸入消息，確定發(fā)送類(lèi)型（群發(fā)還是私聊），若私聊還需指定目的用戶(hù)名， 按發(fā)送按鈕 （ 3）系統(tǒng)讀取信息，分析并 確認(rèn)是群發(fā)還是私聊 （ 4） 若是群發(fā)，則將信息發(fā)給聊天室內(nèi)其它所有用戶(hù) ；若是 私聊，則將消息發(fā)給指定的用戶(hù)。 4 接收 信息 （ 1）系統(tǒng)啟動(dòng)后，等待客戶(hù)請(qǐng)求 （ 2）客戶(hù)請(qǐng)求到，接受請(qǐng)求，分析確認(rèn)是“接收信息請(qǐng)求” （ 3）系統(tǒng)讀取信息，分析并確認(rèn)是群發(fā)還是私聊 （ 4）若是群發(fā)，則將信息發(fā)給聊天室內(nèi)其它所有用戶(hù) （ 5）系統(tǒng)向客戶(hù)端發(fā)送“接收成功”消息 (可省 ) （ 6）系統(tǒng)在監(jiān)控界面上寫(xiě)信息： xx 客 戶(hù)名 〉消息 群發(fā) /私聊 若出現(xiàn)異常，向客戶(hù)端發(fā)“接收失敗”消息 （可?。? 5 用戶(hù)退出 （ 1）系統(tǒng)啟動(dòng)后，等待客戶(hù)請(qǐng)求 （ 2）客戶(hù)請(qǐng)求到，接受請(qǐng)求，分析確認(rèn)是“用戶(hù)退出請(qǐng)求” （ 3）系統(tǒng)從聊天室刪除客戶(hù)， 并 通知其它用戶(hù)“客戶(hù)退出” （ 4）系統(tǒng)向客戶(hù)端發(fā)“退出成功” （可?。?，關(guān)閉連接。 友情提示： 本需求分析只是分析了主要的用戶(hù) 使用 情況， 在對(duì)客戶(hù)端進(jìn)行分析時(shí)，聊天者 是一個(gè)接口，服務(wù)方也是一個(gè)接口，在對(duì)服務(wù)端進(jìn)行分析時(shí)，客戶(hù)端是一個(gè)接口，服務(wù)方管理員是另一個(gè)接口。例如 客戶(hù)端 登陸用例分析時(shí)，客戶(hù)發(fā)“登錄請(qǐng)求”信息到服務(wù)端， 此時(shí)只需關(guān)注服務(wù)方返回情況 ，所以只需等待獲取服務(wù)端返回信息，而無(wú)需知道服務(wù)方是如何處理的。 隱含需求的發(fā)現(xiàn) 。這里還 有一個(gè)度的把握，因?yàn)椴豢赡苋魏吻闆r都要向客戶(hù)解釋 。 優(yōu)先級(jí)的劃分。 注冊(cè)、登錄用例次之。優(yōu) 先級(jí)劃分后，設(shè)計(jì)實(shí)現(xiàn)時(shí)，先做優(yōu)先級(jí)高的，例如本系統(tǒng)，為了實(shí)現(xiàn)上述全部功能，可以分 3次迭代，第一次，實(shí)現(xiàn)高優(yōu)先級(jí)的基本聊天功能，第二次實(shí)現(xiàn)注冊(cè)和登錄，第三次實(shí)現(xiàn)公告、踢人、保存日志及聊天記錄等。當(dāng)然在攻克重難點(diǎn)時(shí)，又可以采用由易到難的辦法，逐步解決。 業(yè)務(wù)對(duì)象分析 從上述的分析中，運(yùn)用名 詞 法， 可以發(fā)現(xiàn)出主要的業(yè)務(wù)對(duì)象： 1 聊天者： 屬性： 用戶(hù)名、密碼、確認(rèn)密碼、性別、年齡、電子郵件 行為：登錄、注冊(cè) 2 聊天客戶(hù)端 : 屬性： 消息 、 聊天者 、 界面 行為：接收 處理 ，發(fā)送 處理 、退出 3 消息 屬性：消息類(lèi)型、消息參數(shù) 行為：創(chuàng)建消息、獲取消息類(lèi)型、獲取消息參數(shù) 4 服務(wù)器 （相當(dāng)于總服務(wù)臺(tái)） 屬性： IP、端口 、服務(wù)監(jiān)控、消息處理者 行為：監(jiān)聽(tīng)、 創(chuàng)建消息處理者 、創(chuàng)建服務(wù)監(jiān)控 5 服務(wù)監(jiān)控 屬性：服務(wù)狀態(tài)，消息， 聊天者 列表 、界面 行為：發(fā)送服務(wù)方 消息、關(guān)閉服務(wù)器 6 消息處理者（相當(dāng)于服務(wù)員） 屬性：連接（ socket） 、消息 行為：處理消息 (登錄、注冊(cè)、發(fā)送、接收、退出 )，收發(fā)消息 友情 提示： 業(yè)務(wù)對(duì)象 是系統(tǒng)中對(duì)象的初步提煉，其屬性和行為在后面還會(huì) 修改、變動(dòng) ， 主要與業(yè)務(wù)相關(guān)，和具體的實(shí)現(xiàn)關(guān)系不大， 是后面設(shè)計(jì)中 業(yè)務(wù) 類(lèi)的基礎(chǔ)，但實(shí)際類(lèi)的數(shù)量也許會(huì)很多， 因?yàn)樵谠O(shè)計(jì)甚至在實(shí)現(xiàn)時(shí)都可能需要建立新的類(lèi)以實(shí)現(xiàn)功能。 驗(yàn)收測(cè)試要求 測(cè)試環(huán)境： 客戶(hù)及服務(wù)器機(jī)操作系統(tǒng)： Window XP，內(nèi)存： 512M。 前置條件： 1 注冊(cè) 文件已創(chuàng)建但為空 。 3 客戶(hù)程序與服務(wù)程序能通過(guò)網(wǎng)絡(luò)互通。 2 重復(fù) 1，在另一客戶(hù)端注冊(cè)用戶(hù)，注意不要重名。（ 1）測(cè)試重名注冊(cè)。（ 2）測(cè)試空輸入，進(jìn)入注冊(cè)界面，直接按注冊(cè)按鈕。 2 登錄測(cè)試。（ 3）分別輸入用戶(hù)名不正確但密碼正確，用戶(hù)名正確但密碼不正確，用戶(hù)名和密碼均不正確，應(yīng)均不能正確登錄。（ 1）進(jìn)入收發(fā)界面，群發(fā)一條消息，觀察其它客戶(hù)是否收到消息，察看服務(wù)器有無(wú)相應(yīng)顯示 （ 2）私聊一條消息， 察看指定用戶(hù)是否收到消息 （ 3）無(wú)任何輸入，直接按發(fā)送。 （ 5）再啟動(dòng)客戶(hù)端，登錄進(jìn)入收發(fā)界面，連續(xù)群發(fā)（至少 3 次），連續(xù)私聊（至少 3 次），再連續(xù)群發(fā)，觀察其它客戶(hù)及服務(wù)方的顯示是否正確。再接通網(wǎng)路，繼續(xù)發(fā)送信息，應(yīng)能正常運(yùn)行。同時(shí) 觀察其它客戶(hù)及服務(wù)器收發(fā) 、 客戶(hù)列表是否正常 。 客戶(hù)端應(yīng)給出發(fā)送異常提示，不應(yīng)退出或死機(jī)。 可同時(shí)啟動(dòng)多個(gè) 發(fā)送線程 （模擬多個(gè)客戶(hù)），同時(shí)向服務(wù)器群發(fā)消息。 也可以考慮使用 JMeter 壓力測(cè)試工具。系統(tǒng)體系結(jié)構(gòu) 如 圖 2所示 ： 圖 2 系統(tǒng)體系結(jié)構(gòu)圖 客戶(hù)端可以劃分成三子層，服務(wù)端也可以劃分出三個(gè)子層，客戶(hù)和服務(wù)器間通信采用的是可靠的 TCP 協(xié)議。 1 客戶(hù) A從界面輸入消息，確定群發(fā)，業(yè)務(wù)邏輯層從界面獲取信息并驗(yàn)證后生成 “消息接收請(qǐng)求” 消息， 再將消息作為參數(shù) 調(diào)用網(wǎng)絡(luò)通信層的 發(fā)送 函數(shù)， 發(fā)送函數(shù)將消息發(fā)往服務(wù)器，然后等待服務(wù)器的消息 2 服務(wù)器收到消息，確定是客戶(hù) A 發(fā)來(lái)的，從消息中分析出是群發(fā)，然后從當(dāng)前客戶(hù)列表中取出除 A 以外的 與 每個(gè)客戶(hù) （ B， C） 對(duì)應(yīng) 的 socket，然后通過(guò) socket將消息轉(zhuǎn)發(fā)給客戶(hù) B， C。 5 客戶(hù) A收到消息，確定是“消息接收成功”消息后，在界面上顯示發(fā)送成功。 不向服務(wù)器發(fā)送 消息收到的確認(rèn)消息。 要不要回復(fù)消息？ 由于使用的是 TCP 協(xié)議，可以保證點(diǎn)對(duì)點(diǎn)的可靠傳輸，所以最簡(jiǎn)單的情況是無(wú)需回復(fù)，在上圖中取消 3 也可以，客戶(hù) A將消息發(fā)到服務(wù)器收發(fā)界面 業(yè)務(wù)邏輯 網(wǎng)絡(luò)通信 聊天服務(wù)器 監(jiān)管界面 聊天業(yè)務(wù)處理 數(shù)據(jù) 網(wǎng)絡(luò)通信 訪問(wèn) 客戶(hù) B 客戶(hù) A 客戶(hù) C 數(shù)據(jù)庫(kù) /文件 TCP/IP TCP/IP TCP/IP 接收 接收 發(fā)送 3 接收消息成功（可以不要） 接收消息請(qǐng)求 接收消息請(qǐng)求息 客戶(hù) A 聊天服務(wù)器 客戶(hù) B 客戶(hù) C 1 接收消息請(qǐng)求 就認(rèn)為 已成功群發(fā)了消息， 但若客戶(hù) B、 C 都斷線，顯然 消息并沒(méi)有成功群發(fā)。前者編程簡(jiǎn)單、性能好，但對(duì)于某些異常情況不能可靠處理，后者編程復(fù)雜，性能差，但可靠性高。所以本文推薦采用無(wú)回復(fù)方式。 消息的收發(fā)方式？ 主要分兩種，一種是推方式，例如客戶(hù) A有了消息就直接發(fā)給服務(wù)器，這是推方式，即由數(shù)據(jù)源方直接將消息發(fā)給接收方；另一種是拉方式，即接收方主動(dòng)向數(shù)據(jù)源 請(qǐng)求 獲取數(shù)據(jù)，例如服務(wù)器通過(guò)定期詢(xún)問(wèn)客戶(hù) A有無(wú)數(shù)據(jù)的方式， 客戶(hù) A一旦有消息，就會(huì)發(fā)消息給服務(wù)器。 數(shù)據(jù)源（客戶(hù) A）的特點(diǎn)是 消息的產(chǎn)生是不確定的 （接收方難以知道發(fā)方何時(shí)有消息 ） ，產(chǎn)生就發(fā)是高效的方式，若服務(wù)器采用輪詢(xún)的方式，一方面 在大多數(shù)情況下 會(huì)產(chǎn)生許多無(wú)謂的詢(xún)問(wèn)，另一方面會(huì)降低服務(wù)器的性能（特別是服務(wù)器可能成為整個(gè)系統(tǒng)的性能瓶頸，這就尤為重要） ， 這里 還 隱含了一個(gè)假設(shè) :在聊天過(guò)程中， 服務(wù)器一直等待消息的到來(lái)， B、 C也隨時(shí)能接受消息 ， 所以發(fā)送 （推） 一般是能成功的。服務(wù)器可能白發(fā)了消息 （為保證消息發(fā)到客戶(hù)，服務(wù)器會(huì)重復(fù)發(fā)送消息，造成性能損失） ，因?yàn)樗恢揽蛻?hù)是否在等著接收消息，這時(shí)可以考慮客戶(hù)方主動(dòng)接收消息，通過(guò)定期輪詢(xún)的方式，向服務(wù)器要數(shù)據(jù)，這時(shí)服務(wù)器就知道客戶(hù)一定能接收消息，所以就發(fā)消息給客戶(hù)，這種方式是“拉”方式。輪詢(xún)時(shí)間的確定主要是在消息收發(fā)的及時(shí)性和性能影響之間取得平衡，周期過(guò)小，服務(wù)器處理壓力大，周期過(guò)長(zhǎng)，客戶(hù)不能及時(shí)收到消息，一般可取 2— 5秒。即認(rèn)為在 多客戶(hù) 聊天過(guò)程中服務(wù)器一直正常運(yùn)行，客戶(hù)端也一直正常。 結(jié)論：系統(tǒng)采用無(wú)回復(fù)的“推”方式收發(fā)消息。 為服務(wù)器監(jiān)控窗體，負(fù)責(zé)監(jiān)控服務(wù)器運(yùn)行狀態(tài)，聊天內(nèi)容，發(fā)送公告，踢人 …… 為服務(wù)器連接處理的具體實(shí)現(xiàn)。 （可選） 三 客戶(hù)端結(jié)構(gòu) 客戶(hù)端主要 模塊和結(jié)構(gòu)如圖 5所示： 為客戶(hù)端程序啟動(dòng)類(lèi)，負(fù)責(zé)客戶(hù)端的啟動(dòng)和退出。 圖 5 客戶(hù)端結(jié)構(gòu)圖 圖 4 服務(wù)器端結(jié)構(gòu)圖 為客戶(hù)端程序注冊(cè)界面，負(fù)責(zé)用戶(hù)帳號(hào)信息的注冊(cè)驗(yàn)證與反饋。 Windowclose 為 的內(nèi)部類(lèi)，負(fù)責(zé)監(jiān)聽(tīng)聊天室界面的操作，當(dāng)用戶(hù)退出時(shí)返回給服務(wù)器信息。 （可選） 詳細(xì)設(shè)計(jì) 客戶(hù)端設(shè)計(jì) 一