【正文】 ?。?，關(guān)閉連接。 友情提示： 本需求分析只是分析了主要的用戶使用情況，在對客戶端進(jìn)行分析時，聊天者 是一個接口，服務(wù)方也是一個接口，在對服務(wù)端進(jìn)行分析時，客戶端是一個接口，服務(wù)方管理員是另一個接口。例如 客戶端 登陸用例分析時，客戶發(fā)“登錄請求”信息到服務(wù)端， 此時只需關(guān)注服務(wù)方返回情況 ，所以只需等待獲取服務(wù)端返回信息，而無需知道服務(wù)方是如何處理的。 隱含需求的發(fā)現(xiàn) 。這里還 有一個度的把握，因為不可能任何情況都要向客戶解釋 。 優(yōu)先級的劃分。 注冊、登錄用例次之。優(yōu)先級劃分后，設(shè)計實現(xiàn)時，先做優(yōu)先級高的，例如本系統(tǒng)，為了實現(xiàn)上述全部功能，可以分 3次迭代，第一次，實現(xiàn)高優(yōu)先級的基本聊天功能，第二次實現(xiàn)注冊和登錄，第三 次實現(xiàn)公告、踢人、保存日志及聊天記錄等。當(dāng)然在攻克重難點時，又可以采用由易到難的辦法，逐步解決。 業(yè)務(wù)對象分析 從上述的分析中，運(yùn)用名 詞 法， 可以發(fā)現(xiàn)出主要的業(yè)務(wù)對象： 1 聊天者： 屬性： 用戶名、密碼、確認(rèn)密碼 、性別、年齡、電子郵件 行為：登錄、注冊 2 聊天客戶端 : 屬性： 消息 、 聊天者 、 界面 行為：接收 處理 ，發(fā)送 處理 、退出 3 消息 屬性：消息類型、消息參數(shù) 行為：創(chuàng)建消息、獲取消息類型、獲取消息參數(shù) 4 服務(wù)器 （相當(dāng)于總服務(wù)臺） 屬性： IP、端口 、服務(wù)監(jiān)控、消息處理者 行為：監(jiān)聽、 創(chuàng)建消息處理者 、創(chuàng)建服務(wù)監(jiān)控 5 服務(wù)監(jiān)控 屬性：服務(wù)狀態(tài)，消息， 聊天者 列表 、界面 行為：發(fā)送服務(wù)方 消息、關(guān)閉服務(wù)器 6 消息處理者（相當(dāng)于服務(wù)員） 屬性：連接（ socket） 、消息 行 為：處理消息 (登錄、注冊、發(fā)送、接收、退出 )，收發(fā)消息 友情 提示： 業(yè)務(wù)對象 是系統(tǒng)中對象的初步提煉，其屬性和行為在后面還會 修改、變動 ， 主要與業(yè)務(wù)相關(guān)，和具體的實現(xiàn)關(guān)系不大， 是后面設(shè)計中 業(yè)務(wù) 類的基礎(chǔ)，但實際類的數(shù)量也許會很多， 因為在設(shè)計甚至在實現(xiàn)時都可能需要建立新的類以實現(xiàn)功能。 驗收測試要求 測試環(huán)境： 客戶及服務(wù)器機(jī)操 作系統(tǒng)： Window XP，內(nèi)存： 512M。 前置條件： 1 注冊 文件已創(chuàng)建但為空 。 3 客戶程序與服務(wù)程序能通過網(wǎng)絡(luò)互通。 2 重復(fù) 1，在另一客戶端注冊用戶，注意不要重名。（ 1）測試重名注冊。（ 2）測試空輸入，進(jìn)入注冊界面，直接按注冊按鈕。 2 登錄測試。（ 3）分別輸入用戶名不正確但密碼正確，用戶名正確但密碼不正確，用戶名和密碼均不正確，應(yīng)均不能正確登錄。（ 1）進(jìn)入收發(fā)界面，群發(fā)一條消息，觀察其它客戶是否收到消息，察看服務(wù)器有無相應(yīng) 顯示 （ 2）私聊一條消息， 察看指定用戶是否收到消息 （ 3）無任何輸入，直接按發(fā)送。 （ 5）再啟動客戶端，登錄進(jìn)入收發(fā)界面，連續(xù)群發(fā)（至少 3 次），連續(xù)私聊（至少 3 次），再連續(xù)群發(fā)，觀察其它客戶及服務(wù)方的顯示是否正確。再接通網(wǎng)路，繼續(xù)發(fā)送信息，應(yīng)能正常運(yùn)行。同時 觀察其它客戶及服務(wù)器收發(fā) 、 客戶列表是否正常 。 客戶端應(yīng)給出發(fā)送異常提示，不應(yīng)退出或死機(jī)。 可同時啟動多個 發(fā)送線程 （模擬多個客戶），同時向服務(wù)器群發(fā)消息。 也可以考慮使用 JMeter 壓力測試工具。系統(tǒng)體系結(jié)構(gòu) 如 圖 2所示 ： 圖 2 系統(tǒng)體系結(jié)構(gòu)圖 客戶端可以劃分成三子層，服務(wù)端也可以劃分出三個子層，客戶和服務(wù)器間通信采用的是可靠的 TCP 協(xié)議。 1 客戶 A從界面輸入消息，確定群發(fā)，業(yè)務(wù)邏輯層從界面獲取信 息并驗證后生成 “消息接收請求” 消息， 再將消息作為參數(shù) 調(diào)用網(wǎng)絡(luò)通信層的 發(fā)送 函數(shù)， 發(fā)送函數(shù)將消息發(fā)往服務(wù)器，然后等待服務(wù)器的消息 2 服務(wù)器收到消息，確定是客戶 A 發(fā)來的，從消息中分析出是群發(fā)，然后從當(dāng)前客戶列表中取出除 A 以外的 與 每個客戶 （ B， C） 對應(yīng) 的 socket，然后通過 socket將消息轉(zhuǎn)發(fā)給客戶 B， C。 5 客戶 A收到消息，確定是“消息接收成功”消息后，在界面上顯示發(fā)送成功。 不向服務(wù)器發(fā)送 消息收到的確認(rèn)消息。 要不要回復(fù)消息？由于使用的是 TCP 協(xié)議，可以保證點對點的可靠傳輸，所以最簡單的情況是無需回復(fù)，在上圖中取消 3 也可以，客戶 A將消息發(fā)到服務(wù)器收發(fā)界面 業(yè)務(wù)邏輯 網(wǎng)絡(luò)通信 聊天服務(wù)器 監(jiān)管界面 聊天業(yè)務(wù)處理 數(shù)據(jù) 網(wǎng)絡(luò)通信 訪問 客戶 B 客戶 A 客戶 C 數(shù)據(jù)庫 /文件 TCP/IP TCP/IP TCP/IP 接收 接收 發(fā)送 3 接收消息成功（可以不要） 息 客戶 A 聊天服務(wù)器 客戶 B 客戶 C 1接收消息請求 就認(rèn)為 已成 功群發(fā)了消息， 但若客戶 B、 C 都斷線，顯然 消息并沒有成功群發(fā)。前者編程簡單、性能好，但對于某些異常情況不能可靠處理，后者編程復(fù)雜，性能差，但可靠性高。所以本文推薦采用無回復(fù) 方式。 消息的收發(fā)方式？主要分兩種，一種是推方式，例如客戶 A有了消息就直接發(fā)給服務(wù)器，這是推方式，即由數(shù)據(jù)源方直接將消息發(fā)給接收方；另一種是拉方式，即接收方主動向數(shù)據(jù)源 請求 獲取數(shù)據(jù)，例如服務(wù)器通過定期詢問客戶 A有無數(shù)據(jù)的方式， 客戶 A一旦有消息，就會發(fā)消息給服務(wù)器。 數(shù)據(jù)源（客戶 A）的特點是 消息的產(chǎn)生是不確定的 （接收方難以知道發(fā)方何時有消息 ） ，產(chǎn)生就發(fā)是高效的方 式，若服務(wù)器采用輪詢的方式，一方面 在大多數(shù)情況下 會產(chǎn)生許多無謂的詢問，另一方面會降低服務(wù)器的性能（特別是服務(wù)器可能成為整個系統(tǒng)的性能瓶頸，這就尤為重要） ， 這里 還 隱含了一個假設(shè) :在聊天過程中， 服務(wù)器一直等待消息的到來， B、 C也隨時能接受消息 ， 所以發(fā)送 （推） 一般是能成功的。服務(wù)器可能白發(fā)了消息 （為保證消息發(fā)到客 戶，服務(wù)器會重復(fù)發(fā)送消息，造成性能損失） ，因為它不知道客戶是否在等著接收消息，這時可以考慮客戶方主動接收消息，通過定期輪詢的方式，向服務(wù)器要數(shù)據(jù)，這時服務(wù)器就知道客戶一定能接收消息，所以就發(fā)消息給客戶，這種方式是“拉”方式。輪詢時間的確定主要是在消息收發(fā)的及時性和性能影響之間取得平衡，周期過小，服務(wù)器處理壓力大，周期過長，客戶不能及時收到消息，一般可取 2— 5秒。即認(rèn)為在 多客戶 聊天過程中服務(wù)器一直正常運(yùn)行，客戶端也一直正常。 結(jié)論：系統(tǒng)采用無回復(fù)的“推”方式收發(fā)消息。 為服務(wù)器監(jiān)控窗體，負(fù)責(zé)監(jiān)控服務(wù)器運(yùn)行狀態(tài)，聊天內(nèi)容，發(fā)送公告，踢人 ?? 為服務(wù)器連接處理的具體實現(xiàn)。（可選） 三 客戶端結(jié)構(gòu) 客戶端主要 模塊和結(jié)構(gòu)如圖 5所示： 為客戶端程序啟動類，負(fù)責(zé)客戶端的啟動和退出。 圖 5 客戶端結(jié)構(gòu)圖 圖 4 服務(wù)器端結(jié)構(gòu)圖 為客戶端程序注冊界面，負(fù)責(zé)用戶帳號信息的注冊驗證與反饋。 Windowclose 為 的內(nèi)部類，負(fù)責(zé)監(jiān)聽聊天室界面的操作，當(dāng)用戶退出時返回給服務(wù)器信息。（可選） 詳細(xì)設(shè)計 客戶端設(shè)計 一 注冊 模塊 程序?qū)⑼ㄟ^ 用戶注冊界面收集用戶的用戶名、密碼、年齡、電子郵箱 等 。 圖 6 客戶端注冊界面 處 理過程： 當(dāng)用戶注冊時，客戶端的 界面收集并驗證了用戶的注冊信息后，封裝成 Register_Customer 類然后通過建立在 Socket 的連接之上的對象輸出流將用戶注冊信息發(fā)送給服務(wù)器端，服務(wù)器端將請求轉(zhuǎn)發(fā)給Connection 處理， Connection 在收到信息后將驗證數(shù)據(jù)的完整性并在數(shù)據(jù)庫中查找該用戶名是否已經(jīng)注冊，然后將注冊信息加入數(shù)據(jù)庫，最后將注冊結(jié)果返回給客戶端。 驗證 要求如下 ： 1 驗證用戶名是否為空 即用戶名的字符長度不 為 0，如果驗證通過，就繼續(xù)下面驗證，否則返回“用戶名為空”錯誤。 3 驗證密碼的一致性 驗證密碼兩次輸入是否一致，如果驗證通過，就繼續(xù)下面驗證，否則返回“密碼兩次輸入不一致，請重新輸入”錯誤 。 圖 7 客戶端登錄界面 登錄過程如下： 當(dāng)用戶登錄時，客戶端由 界面收集并驗證用戶登錄信息后，封裝成 Customer對象類然后通過建立在 Socket的連接之上的對象輸出流將用戶登錄信息發(fā)送給服務(wù)器端，服務(wù)器端將請求轉(zhuǎn)發(fā)給 Connection 處理， Connection 在收到信息后將驗證數(shù)據(jù)的完整性并在對象型數(shù)據(jù)庫中查找該用戶名是否已經(jīng)注冊，然后將注冊用戶的信息與登錄請求信息進(jìn)行密碼驗證，在登錄成功后將該用戶添加到在線用戶列表，最后將登錄結(jié)果返回給客戶端。 驗證要求： 1 驗證用戶名是否為空 即用戶名的字符長度不為 0，如果驗證通過，就進(jìn)行繼續(xù)下面驗證，否則返回“用戶名為空”錯誤 , 2 驗證密碼是否為空 即密碼的字符長度不為 0，如果驗證通過，就進(jìn)行繼續(xù)下面驗證，否則返回“用戶密碼為空”錯誤 當(dāng)以上信息驗證成功時，客戶端將打開與服務(wù)之間的 Socket 連接，用對象輸出流包裝后將用戶登錄的信息發(fā)送給服務(wù)器端，并接收服務(wù)器處理完用戶登錄的信息。 三 收發(fā)模塊 當(dāng)用戶登錄成功后，用戶的登錄界面將會 消失 ，然后創(chuàng)建 用戶聊天室窗口（如圖） ,在界面的標(biāo)題欄將會顯示當(dāng)前登錄用戶的用戶名，以防止一個機(jī)器上的用戶開多個帳號進(jìn)入聊天室后分不清哪個窗口是哪個用戶登錄的，界面第一行將顯示當(dāng)前服務(wù)器的在線人數(shù)。 位于界面下方的就是一些用于聊天的功能控件和聊天內(nèi)容個性化配置控件（可選） 。 當(dāng)用戶點擊完發(fā)送按鈕后，程序開始將當(dāng)前用戶名、聊天對象、聊天內(nèi)容、聊天語氣和是否私聊進(jìn)行封裝，然后