JAVA课程设计聊天室系统.docx

资源描述

JAVA课程设计聊天室系统.docx

《JAVA课程设计聊天室系统.docx》由会员分享，可在线阅读，更多相关《JAVA课程设计聊天室系统.docx（30页珍藏版）》请在冰豆网上搜索。

JAVA课程设计聊天室系统.docx

JAVA课程设计聊天室系统

Java课程设计指导书（学生版初稿）

第二章聊天室系统

目标

2.1背景介绍

2.1.1业务背景

2.1.2技术背景

2.2需求分析

2.2.1功能需求分析

2.2.2业务对象分析

2.2.3验收测试要求

2.3系统设计

2.3.1总体设计

2.3.2详细设计

2.4系统实现

2.5小结

2.6展望

第二章聊天室系统

学习目标：

1、理解基于网络的C/S模式的软件系统结构，掌握网络编程的基本概念。

2、了解Java的多线程机制，掌握Java多线程技术的应用。

3、熟练掌握基于TCP协议的Socket编程。

4、了解Socket编程的协议约定，掌握简单应用协议的开发。

5、进一步巩固发展团队协作能力。

学习寄语：

想必大家都用过QQ，其主要功能就是聊天，是不是很想知道它是如何实现的？

本项目就是帮你实现一个简单的聊天系统，当然跟商业项目没法比，但从中你却可以了解这些系统是如何实现的，学到开发类似系统的基础知识和基本技能（基本并不意味不实用）。

本章的内容有一定难度（多线程、基于TCP的应用协议编程），所以系统的开发采用了“增量迭代”的开发方式，由简易到繁难，希望你能顺利前行。

我们的信念依然是：

“不抛弃，不放弃”。

你的改变和收获依然是老师真诚的期待，期待你更踏实、更自信。

Comeon!

2.1背景介绍

2.1.1业务背景

随着网络社会的不断发展，具有相同兴趣的网民需要互相远程交流，既要能省钱又要能即时交互，电话太贵、email又嫌慢，所以开发一个类似QQ的及时通讯系统就变得非常有意义了。

“HappyChat”聊天系统应运而生，它较之QQ的唯一好处是自主开发，用的放心，更适合在局域网内使用。

它提供的功能远不如QQ丰富，但应具有如下功能：

（1）与聊天室成员一起聊天；

（2）可以与聊天室成员私聊；（3）用户注册、登录；（4）服务器监控聊天内容；（5）服务器发送通知；（6）服务器踢人；（7）保存服务器日志。

（8）保存用户聊天信息。

2.1.2技术背景

本系统要求使用java技术开发，使用文件保存数据，集成开发环境使用eclipse。

开发者应有java程序设计语言、SWING基本GUI组件、多线程、文件使用、socket编程、使用eclipse的基本知识和技能。

系统采用两层C/S体系结构，C端负责通过GUI与客户交互，实现注册、登陆、收发信息、退出等功能；S端是聊天系统的应用服务器，主要有处理用户注册、登录、用户收发信息、用户退出等功能。

C端和S端是通过网络交互的，其基本原理如图1所示：

图1C/S通讯基本原理图

首先服务器启动，它会建立一个专门用于接收客户端连接请求的“倾听Socket”（相当于总服务台，有固定的IP地址和端口号）,然后等待客户的连接请求。

当用户想聊天时，从界面输入信息，然后与服务器建立Socket连接（连接时应指定服务器的IP地址和端口号，而客户端socket的端口由本方操作系统从空闲端口中确定），服务器端的“倾听Socket”收到连接请求后，一般会接受连接请求，并生成一个服务端socket（其端口号由服务端操作系统从空闲端口中确定），专门负责与此客户端socket的通信。

一旦连接请求成功，客户端将信息及请求通过本方socket的输出流发送给服务器端相应的socket，服务端则通过服务器端Socket的输入流接受客户端传输过来的信息及请求，分析是何请求，然后根据请求类型，进行相应的处理（如登录、转发信息等）。

服务方也可以根据需要，通过socket的输出流发信息和请求给客户端（公告）。

客户方和服务方都可以通过关闭本方的socket而结束一次通讯过程。

不难发现服务器需要能同时接受多个客户的请求，为了实现这一点，一般使用多线程机制来处理，对每一个客户端连接通讯，服务器端都有一个线程专门负责处理（相当于一个服务员专门服务一个以IP地址和端口号唯一标识的客户）。

上述方式两个聊天者之间通信必须通过服务器进行转发，聊天者多时，显然服务器是个性能瓶颈。

能不能聊天者之间直接通信？

当然可以，这是所谓的P2P聊天室，缺点是对聊天者缺乏集中监管的手段。

也有界于二者之间的，即有一服务器，接受注册和登录，实际聊天双方通信时，仍然是直接通信，此时服务器相当于一个婚姻介绍所，只管牵线搭桥，具体谈还是聊天者自己的事。

本文主要采用聊天信息通过服务器转发的方式，而且只支持一个聊天室。

因为其他典型系统如电子邮件系统，FTP系统均采用类似结构，WEB服务系统本质上也是C/S系统，只不过其客户端是浏览器，采用了HTTP通信协议和HTML，所以变成了B/S结构，可以认为是C/S的一个具体应用，其机理是相似的。

2.2需求分析

2.2.1功能需求分析

系统的主要功能已在业务分析中有所介绍，在这里需要对每个功能从使用者角度作较为具体的分析。

很明显，整个系统的功能可以自然地分为客户端和服务器端。

以下是主要用例描述

一客户端

1.注册

（1）客户启动程序，显示出登陆界面

（2）客户选择其中的注册按钮，系统显示注册界面

（3）客户填写用户名、密码、确认密码、性别、年龄、电子邮件，按确定按钮

（4）系统验证密码和确认密码是否相符、用户名（不能重复）、电子邮件格式、年龄（大于10小于100）

（5）系统发送上述信息及“注册请求”到服务端，等待服务端返回“注册成功”消息

（6）系统提示注册成功

（7）系统返回登陆界面

若验证失败，提示“重新输入”

若服务端返回“注册失败”，提示“注册失败”

若服务端返回“注册失败用户名重名”，则提示“注册失败用户重名”。

2.登录

（1）客户启动程序，显示出登陆界面

（2）客户填写用户名、密码，服务器IP地址，按登陆按钮

（3）系统验证用户名、密码，不能为空、密码字符长度为6-10

（4）系统发送用户名、密码及“登陆请求”到服务端，等待服务端返回“登录成功”消息

（5）若成功系统显示客户端主界面（收发消息界面）

若用户名、密码验证失败，系统提示；“用户名或密码错”，重复3次若仍不能通过验证则客户端程序退出。

若服务端返回“登录失败”，系统提示“用户名或密码错”。

3.发送信息

（1）在客户端主界面，用户输入消息，选择是群发还是私聊，若是私聊还要选择对方用户名，按发送按钮

（2）系统验证消息长度,私聊要求目的方用户名非空。

（3）系统发送信息及“接收消息请求”到服务器端，等待服务端返回“接收成功”消息（等待返回消息可省）。

（4）系统提示信息已发送

若发送不成功，则系统提示“发送失败”。

4.接收信息

（1）客户端系统启动，进入主界面后，会显示消息接收框

（2）其他客户或服务端系统本身发送消息过来，系统接收，分析确认是”

接收消息请求“，则分析提取出消息

（3）在消息接收框逐条显示发送者姓名、发送的消息。

5退出

（1）用户请求退出，按退出按钮

（2）系统确认用户退出（对话框）

（3）系统发“退出请求”到服务端，等待服务端返回“退出成功”（等待返回消息可省）

（4）客户端系统关闭连接，程序退出

二服务器端

1.用户注册

（1）系统启动后，等待客户请求

（2）客户请求到，接受请求，分析确认是“注册请求”

（3）系统读取信息，分析并再次验证用户名、密码、确认密码、性别、年龄、电子邮件。

（4）系统根据用户名，在已有客户记录中查询，确认没有重名

（5）系统将用户名、密码、确认密码、性别、年龄、电子邮件信息保存

（6）系统向客户端发送“注册成功”消息

（7）系统在监控界面上写信息：

xx客户名已注册注册时间

若重名，向客户端发“注册重名”消息

若注册失败，向客户端发“注册失败”消息

2.用户登录

（1）系统启动后，等待客户请求

（2）客户请求到，接受请求，分析确认是“登录请求”

（3）系统读取信息，验证用户名、密码是否存在

（4）系统验证是否已经登录

（5）系统验证用户是否已超过最大用户数

（6）系统将客户加入聊天室，通知其它客户“新用户加入”

（7）系统向客户端发送“登录成功”消息

（8）系统在监控界面上写信息：

客户名：

已登录登录时间

若验证失败，向客户端发“验证失败”消息

3.发送信息（用于管理员向聊天者发送公告信息）

（1）系统启动后，等待管理员请求

（2）管理员在监控界面输入消息，确定发送类型（群发还是私聊），若私聊还需指定目的用户名，按发送按钮

（3）系统读取信息，分析并确认是群发还是私聊

（4）若是群发，则将信息发给聊天室内其它所有用户；若是私聊，则将消息发给指定的用户。

（5）系统在监控界面上写信息：

管理员--〉消息

若出现异常，提示“发送失败”。

4接收信息

（1）系统启动后，等待客户请求

（2）客户请求到，接受请求，分析确认是“接收信息请求”

（3）系统读取信息，分析并确认是群发还是私聊

（4）若是群发，则将信息发给聊天室内其它所有用户

（5）系统向客户端发送“接收成功”消息（可省）

（6）系统在监控界面上写信息：

xx客户名--〉消息群发/私聊

若出现异常，向客户端发“接收失败”消息（可省）

5用户退出

（1）系统启动后，等待客户请求

（2）客户请求到，接受请求，分析确认是“用户退出请求”

（3）系统从聊天室删除客户，并通知其它用户“客户退出”

（4）系统向客户端发“退出成功”（可省），关闭连接。

聊天系统主要应用在局域网，在性能方面要求，客户到客户间消息传输时间不大于5s，传输可靠性要求95%的情况下，消息可以可靠传到目的地，同时在线用户数量不小于200。

友情提示：

本需求分析只是分析了主要的用户使用情况，在对客户端进行分析时，聊天者是一个接口，服务方也是一个接口，在对服务端进行分析时，客户端是一个接口，服务方管理员是另一个接口。

在接口处只关心接口处的输入输出，并不关心接口里面是如何实现的。

例如客户端登陆用例分析时，客户发“登录请求”信息到服务端，此时只需关注服务方返回情况，所以只需等待获取服务端返回信息，而无需知道服务方是如何处理的。

服务方如何处理是在服务端登录用例中描述的。

隐含需求的发现。

在登录用例中，客户和服务方都有登录用例，合作完成一个完整的登录过程，密码和用户名的验证一般都能想到，但限制用户数量，同一用户不能重复登录则不太容易想到，这里经验就会起作用，这是第一步，想到了就要向客户提出（必要时解释），具体要不要做由客户决定，则是第二步。

这里还有一个度的把握，因为不可能任何情况都要向客户解释。

经验如何来？

学习前人的经验并运用到自己的项目开发中，体会转化为自己的东西应该是个有效途径。

优先级的划分。

作为聊天系统，其主要功能就是聊天，客户间互相发送消息，所以优先级最高的是客户端的发送、接收、退出用例，服务器端的接收、退出用例。

而公告、踢人、保存日志及聊天记录、个性化界面等又次之。

优先级划分后，设计实现时，先做优先级高的，例如本系统，为了实现上述全部功能，可以分3次迭代，第一次，实现高优先级的基本聊天功能，第二次实现注册和登录，第三次实现公告、踢人、保存日志及聊天记录等。

其核心是先实现最重要（用户观点）和最难的（开发者观点），这一观点和日常思维相反，但却是有效避免风险和损失的方法，因为必需的和难度大的一开始就实现不了的话，项目可以及时改变，否则等到最后才发现了难以解决而又必须解决的问题时，损失就会更大。

当然在攻克重难点时，又可以采用由易到难的办法，逐步解决。

一个是策略，一个是战术，思路相反，关键是要运用得当。

2.2.2业务对象分析

从上述的分析中，运用名词法，可以发现出主要的业务对象：

1聊天者：

属性：

用户名、密码、确认密码、性别、年龄、电子邮件

行为：

2聊天客户端:

属性：

消息、聊天者、界面

行为：

接收处理，发送处理、退出

3消息

属性：

消息类型、消息参数

行为：

创建消息、获取消息类型、获取消息参数

4服务器（相当于总服务台）

属性：

IP、端口、服务监控、消息处理者

行为：

监听、创建消息处理者、创建服务监控

5服务监控

属性：

服务状态，消息，聊天者列表、界面

行为：

发送服务方消息、关闭服务器

6消息处理者（相当于服务员）

属性：

连接（socket）、消息

行为：

处理消息（登录、注册、发送、接收、退出），收发消息

友情提示：

业务对象是系统中对象的初步提炼，其属性和行为在后面还会修改、变动，主要与业务相关，和具体的实现关系不大，是后面设计中业务类的基础，但实际类的数量也许会很多，因为在设计甚至在实现时都可能需要建立新的类以实现功能。

不少讲分析设计的书并不提到这一步，而是在设计中直接给出类图，结果是一样的，但反映不出这些类是如何来的，如果你注重过程，可以看一下本节，若果你注重结果，直接看设计实现中的相关内容。

2.2.3验收测试要求

测试环境：

客户及服务器机操作系统：

WindowXP，内存：

512M。

客户端程序安装在客户机（至少2台）上，通过以太网（网速至少10M）与服务器相连。

前置条件：

1注册文件已创建但为空。

2客户及服务程序安装配置正确，能正常启动运行。

3客户程序与服务程序能通过网络互通。

一初始化数据

1客户端启动，进入注册界面，输入正确的注册数据，请求注册，查看服务端，看是否正确注册。

2重复1，在另一客户端注册用户，注意不要重名。

二功能测试

1注册测试。

（1）测试重名注册。

进入注册界面输入重名用户名，其它正确，请求注册。

（2）测试空输入，进入注册界面，直接按注册按钮。

（3）测试口令的一致性，口令长度，年龄及邮箱的数据有效性（具体测试用例设计可参考需求分析及详细设计中的相关部分）。

2登录测试。

（1）输入正确的口令和密码，按登录按钮

（2）空输入，直接按登录按钮。

（3）分别输入用户名不正确但密码正确，用户名正确但密码不正确，用户名和密码均不正确，应均不能正确登录。

（4）以同一用户名重复登录一次

测试

（1）（3）时要查看服务端的显示

3发送接收测试。

（1）进入收发界面，群发一条消息，观察其它客户是否收到消息，察看服务器有无相应显示

（2）私聊一条消息，察看指定用户是否收到消息

（3）无任何输入，直接按发送。

（4）退出系统，察看服务端显示，察看其它客户端是否已将该客户名删除。

（5）再启动客户端，登录进入收发界面，连续群发（至少3次），连续私聊（至少3次），再连续群发，观察其它客户及服务方的显示是否正确。

三可靠性测试

1切断一客户至服务器的网络连接，分别进行注册、登录消息，客户端应能给出提示，而不是死机或退出，在正常聊天过程中，切断一客户端网络连接，客户程序应能给出提示。

再接通网路，继续发送信息，应能正常运行。

至少关闭并重启程序后，应能正常收发。

同时观察其它客户及服务器收发、客户列表是否正常。

2在正常收发中，强行关闭服务器，观察各客户端的反应。

客户端应给出发送异常提示，不应退出或死机。

四性能测试（可选）

编制一测试程序，作为客户端，登录进系统，向服务器按指定时间间隔群发消息。

可同时启动多个发送线程（模拟多个客户），同时向服务器群发消息。

看在200个模拟客户（200个发送线程），每1s一个消息的情况下，服务器能否满足客户到客户传输时间小于5s的要求。

也可以考虑使用JMeter压力测试工具。

2.3系统设计

2.3.1总体设计

一系统总体结构

总体设计阶段主要是确定系统的体系结构和主要模块，显然系统分客户端子系统和服务器子系统。

系统体系结构如图2所示：

收发界面

业务逻辑

网络通信

聊天服务器

监管界面

聊天业务处理

数据

网络通信访问

客户B

客户A

客户C

数据库/文件

TCP/IP

图2系统体系结构图

客户端可以划分成三子层，服务端也可以划分出三个子层，客户和服务器间通信采用的是可靠的TCP协议。

基本的聊天过程如下：

0客户端启动注册、登录后，进入收发界面，此时C/S连接已建立，C处于接收状态。

1客户A从界面输入消息，确定群发，业务逻辑层从界面获取信息并验证后生成“消息接收请求”消息，再将消息作为参数调用网络通信层的发送函数，发送函数将消息发往服务器，然后等待服务器的消息

2服务器收到消息，确定是客户A发来的，从消息中分析出是群发，然后从当前客户列表中取出除A以外的与每个客户（B，C）对应的socket，然后通过socket将消息转发给客户B，C。

3服务器在监控界面上显示：

客户A—〉消息群发

4服务器生成“消息接收成功”消息，向客户A回发（可省）。

5客户A收到消息，确定是“消息接收成功”消息后，在界面上显示发送成功。

6客户B/C的通讯模块接收到消息，分析确认是“消息接收请求”，则在界面上显示：

客户A-〉消息群发。

不向服务器发送消息收到的确认消息。

消息收发的简图如下图3所示：

接收

发送

3接收消息成功（可以不要）

2.2接收消息请求

2.1接收消息请求息

客户A

聊天服务器

客户B

客户C

1接收消息请求

图3消息收发示意图

经验共享：

下面是本人在网络编程方面多年积累的经验，感兴趣的可以读一读。

要不要回复消息？

由于使用的是TCP协议，可以保证点对点的可靠传输，所以最简单的情况是无需回复，在上图中取消3也可以，客户A将消息发到服务器就认为已成功群发了消息，但若客户B、C都断线，显然消息并没有成功群发。

最复杂的是客户B、C收到消息后也回复给服务器，服务器确认都收到回复后再向A回复。

前者编程简单、性能好，但对于某些异常情况不能可靠处理，后者编程复杂，性能差，但可靠性高。

这就要根据情况在上述矛盾中折中，对于“聊天室系统”，对可靠性要求并不高，即使消息有5%未收到，也没有大的问题，另外聊天者是处理各种不可靠问题的最佳人选，实在不行，可由人重启系统（不会带来任何人身及财物损失），另外本系统主要应用在局域网，而局域网的可靠性是较高的。

所以本文推荐采用无回复方式。

这适用于其它消息的处理。

消息的收发方式？

主要分两种，一种是推方式，例如客户A有了消息就直接发给服务器，这是推方式，即由数据源方直接将消息发给接收方；另一种是拉方式，即接收方主动向数据源请求获取数据，例如服务器通过定期询问客户A有无数据的方式，客户A一旦有消息，就会发消息给服务器。

显然这两种方式应用的场合是不一样的，上文中描述的是“推”方式,客户A将消息发（推）给服务器，服务器将消息再转发（推）给其它客户。

数据源（客户A）的特点是消息的产生是不确定的（接收方难以知道发方何时有消息），产生就发是高效的方式，若服务器采用轮询的方式，一方面在大多数情况下会产生许多无谓的询问，另一方面会降低服务器的性能（特别是服务器可能成为整个系统的性能瓶颈，这就尤为重要），这里还隐含了一个假设:

在聊天过程中，服务器一直等待消息的到来，B、C也随时能接受消息，所以发送（推）一般是能成功的。

服务器向客户B，C推消息（相当于客户B、C接收消息），是基于B、C都在准备接收的假设，这一点较之服务器一直可靠运行的假设，其假设的有效性较低，因为客户方的行为难以预料，可能客户重启了系统，可能突然断电等。

服务器可能白发了消息（为保证消息发到客户，服务器会重复发送消息，造成性能损失），因为它不知道客户是否在等着接收消息，这时可以考虑客户方主动接收消息，通过定期轮询的方式，向服务器要数据，这时服务器就知道客户一定能接收消息，所以就发消息给客户，这种方式是“拉”方式。

此方式较之服务器直接推，服务器性能上有所损失，主要用于处理客户的轮询消息（较之重发消息，开支一般较小），客户方因为要轮讯，也损失性能，但这对于客户端并不重要（其计算能力绝大部分情况下都足够），编码量上C/S均增加了，它的好处是如果多数情况下不能保证客户方一直在线，则服务方可以处理多次轮询，但只发一次消息给客户，较之不断的重发消息给客户（尤其是大量用户群发时）总体性能上是提高的。

轮询时间的确定主要是在消息收发的及时性和性能影响之间取得平衡，周期过小，服务器处理压力大，周期过长，客户不能及时收到消息，一般可取2—5秒。

推荐的方式是“推”方式，因为“HappyChat”应用于局域网，网络条件较好，且基于可靠的TCP协议传输消息，本身对可靠性要求也不高，具体说就是服务器向客户转发消息时，不管成功与否只发一次，客户向服务器发消息时，若出错，不会自动重发，但会给出提示，由聊天者决定是否重发（如再次按发送按钮）。

即认为在多客户聊天过程中服务器一直正常运行，客户端也一直正常。

这样做以后，简化了设计编码，性能也得到提高。

结论：

系统采用无回复的“推”方式收发消息。

二服务器结构

服务器端主要的模块和结构如图4所示：

图4服务器端结构图

AppServer.java为服务器端监听类，负责服务器的启动，包括启动监听端口、服务器监控界面。

ServerFrame.java为服务器监控窗体，负责监控服务器运行状态，聊天内容，发送公告，踢人……

Connection.java为服务器连接处理的具体实现。

WordFilter.java语言过滤类，处理非法聊天内容的过滤。

（可选）

三客户端结构

客户端主要模块和结构如图5所示：

图5客户端结构图

ChatClient.java为客户端程序启动类，负责客户端的启动和退出。

ChatRoom.java为客户端程序聊天室主界面，负责接收、发送聊天内容与服务器端的Connection.java亲密合作。

Windowclose为ChatRoom.java的内部类，负责监听聊天室界面的操作，当用户退出时返回给服务器信息。

Clock.java为客户端程序的一个小程序，实现的一个石英钟功能。

（可选）

2.3.2详细设计

2.3.2.1客户端设计

一注册模块

程序将通过Register.java用户注册界面收集用户的用户名、密码、年龄、电子邮箱等。

参考界面如图6。

图6客户端注册界面

处理过程：

当用户注册时，客户端的Register.java界面收集并验证了用户的注册信息后，封装成Register_Customer类然后通过建立在Socket的连接之上的对象输出流将用户注册信息发送给服务器端，服务器端将请求转发给Connection处理，Connection在收到信息后将验证数据的完整性并在数据库中查找该用户名是否已经注册，然后将注册信息加入数据库，最后将注册结果返回给客户端。

客户端显示结果（重名、成功、失败），并断开连接。

验证要求如下：

1验证用户名是否为空

即用户名的字符长度不为0，如果验证通过，就继续下面验证，否则返回“用户名为空”错误。

2验证密码是否为空

即密码的字符长度不为0，如果验证通过，就继续下面验证，否则返回“用户密码为空”错误。

3验证密码的一致性

验证密码两次输入是否一致，如果验证通过，就继续下面验证，否则返回“密码两次输入不一致，请重新输入”错误。

4验证年龄是否为空

即用户年龄的字符长度不为0，如果验证通过，就继续下面验证，否则返回“用户名为空错误”

5验证年龄的合法性

即用户年龄介于10到100之间，如果验证通过，就进行继续下面验证，否则返回“用户年

展开阅读全文