JAVA课程设计聊天室系统.docx
《JAVA课程设计聊天室系统.docx》由会员分享,可在线阅读,更多相关《JAVA课程设计聊天室系统.docx(31页珍藏版)》请在三一办公上搜索。
1、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编程的协议约定,掌握简单应
2、用协议的开发。 5、进一步巩固发展团队协作能力。 学习寄语:想必大家都用过QQ,其主要功能就是聊天,是不是很想知道它是如何实现的?本项目就是帮你实现一个简单的聊天系统,当然跟商业项目没法比,但从中你却可以了解这些系统是如何实现的,学到开发类似系统的基础知识和基本技能。本章的内容有一定难度,所以系统的开发采用了“增量迭代”的开发方式,由简易到繁难,希望你能顺利前行。我们的信念依然是:“不抛弃,不放弃”。你的改变和收获依然是老师真诚的期待,期待你更踏实、更自信。Come on! 2.1 背景介绍 2.1.1 业务背景 随着网络社会的不断发展,具有相同兴趣的网民需要互相远程交流,既要能省钱又要能即时
3、交互,电话太贵、email又嫌慢,所以开发一个类似QQ 的及时通讯系统就变得非常有意义了。“Happy Chat”聊天系统应运而生,它较之QQ的唯一好处是自主开发,用的放心,更适合在局域网内使用。它提供的功能远不如QQ丰富,但应具有如下功能:与聊天室成员一起聊天;可以与聊天室成员私聊;用户注册、登录;服务器监控聊天内容;服务器发送通知;服务器踢人;保存服务器日志。保存用户聊天信息。 2.1.2 技术背景 本系统要求使用java技术开发,使用文件保存数据,集成开发环境使用eclipse。开发者应有java程序设计语言、SWING基本GUI组件、多线程、文件使用、socket编程、使用eclips
4、e的基本知识和技能。系统采用两层C/S体系结构,C端负责通过GUI与客户交互,实现注册、登陆、收发信息、退出等功能; S端是聊天系统的应用服务器,主要有处理用户注册、登录、用户收发信息、用户退出等功能。C端和S端是通过网络交互的,其基本原理如图1所示: 图1 C/S通讯基本原理图 首先服务器启动,它会建立一个专门用于接收客户端连接请求的“倾听Socket”,然后等待客户的连接请求。 当用户想聊天时,从界面输入信息,然后与服务器建立Socket连接,服务器端的“倾听Socket”收到连接请求后,一般会接受连接请求,并生成一个服务端socket,专门负责与此客户端socket的通信。一旦连接请求成
5、功,客户端将信息及请求通过本方socket的输出流发送给服务器端相应的socket,服务端则通过服务器端Socket的输入流接受客户端传输过来的信息及请求,分析是何请求,然后根据请求类型,进行相应的处理。服务方也可以根据需要,通过socket的输出流发信息和请求给客户端。客户方和服务方都可以通过关闭本方的socket而结束一次通讯过程。 不难发现服务器需要能同时接受多个客户的请求,为了实现这一点,一般使用多线程机制来处理,对每一个客户端连接通讯,服务器端都有一个线程专门负责处理。 上述方式两个聊天者之间通信必须通过服务器进行转发,聊天者多时,显然服务器是个性能瓶颈。能不能聊天者之间直接通信?当
6、然可以,这是所谓的P2P聊天室,缺点是对聊天者缺乏集中监管的手段。也有界于二者之间的,即有一服务器,接受注册和登录,实际聊天双方通信时,仍然是直接通信,此时服务器相当于一个婚姻介绍所,只管牵线搭桥,具体谈还是聊天者自己的事。 本文主要采用聊天信息通过服务器转发的方式,而且只支持一个聊天室。因为其他典型系统如电子邮件系统,FTP系统均采用类似结构,WEB服务系统本质上也是C/S系统,只不过其客户端是浏览器,采用了HTTP通信协议和HTML,所以变成了B/S结构,可以认为是C/S的一个具体应用,其机理是相似的。 2.2 需求分析 2.2.1功能需求分析 系统的主要功能已在业务分析中有所介绍,在这里
7、需要对每个功能从使用者角度作较为具体的分析。很明显,整个系统的功能可以自然地分为客户端和服务器端。以下是主要用例描述 一 客户端 1 . 注册 客户启动程序,显示出登陆界面 客户选择其中的注册按钮,系统显示注册界面 客户填写用户名、密码、确认密码、性别、年龄、电子邮件,按确定按钮 系统验证密码和确认密码是否相符、用户名、电子邮件格式、年龄 系统发送上述信息及“注册请求”到服务端,等待服务端返回“注册成功”消息 系统提示注册成功 系统返回登陆界面 若验证失败,提示“重新输入” 若服务端返回“注册失败”,提示“注册失败” 若服务端返回“注册失败 用户名重名”,则提示“注册失败 用户重名”。 2.
8、登录 客户启动程序,显示出登陆界面 客户填写用户名、密码,服务器IP地址,按登陆按钮 系统验证用户名、密码,不能为空、密码字符长度为6-10 系统发送用户名、密码及“登陆请求”到服务端,等待服务端返回“登录成功”消息 若成功系统显示客户端主界面 若用户名、密码验证失败,系统提示;“用户名或密码错”,重复3次若仍不能通过验证则客户端程序退出。 若服务端返回“登录失败”,系统提示“用户名或密码错”。 3. 发送信息 在客户端主界面,用户输入消息,选择是群发还是私聊,若是私聊还要选择对方用户名,按发送按钮 系统验证消息长度, 私聊要求目的方用户名非空。 系统发送信息及“接收消息请求”到服务器端,等待
9、服务端返回“接收成功”消息。 系统提示信息已发送 若发送不成功,则系统提示“发送失败”。 4. 接收信息 客户端系统启动,进入主界面后,会显示消息接收框 其他客户或服务端系统本身发送消息过来,系统接收,分析确认是” 接收消息请求“,则分析提取出消息 (3) 在消息接收框逐条显示发送者姓名、发送的消息。 5 退出 用户请求退出,按退出按钮 系统确认用户退出 系统发“退出请求”到服务端,等待服务端返回“退出成功” 客户端系统关闭连接,程序退出 二 服务器端 1. 用户注册 系统启动后,等待客户请求 客户请求到,接受请求,分析确认是“注册请求” 系统读取信息,分析并再次验证用户名、密码、确认密码、性
10、别、年龄、电子邮件。 系统根据用户名,在已有客户记录中查询,确认没有重名 系统将用户名、密码、确认密码、性别、年龄、电子邮件信息保存 系统向客户端发送“注册成功”消息 系统在监控界面上写信息:xx客户名 已注册 注册时间 若重名,向客户端发“注册重名”消息 若注册失败,向客户端发“注册失败”消息 2. 用户登录 系统启动后,等待客户请求 客户请求到,接受请求,分析确认是“登录请求” 系统读取信息,验证用户名、密码是否存在 系统验证是否已经登录 系统验证用户是否已超过最大用户数 系统将客户加入聊天室,通知其它客户“新用户加入” 系统向客户端发送“登录成功”消息 系统在监控界面上写信息:客户名:已
11、登录 登录时间 若验证失败,向客户端发“验证失败”消息 3. 发送信息 系统启动后,等待管理员请求 管理员在监控界面输入消息,确定发送类型,若私聊还需指定目的用户名,按发送按钮 系统读取信息,分析并确认是群发还是私聊 若是群发,则将信息发给聊天室内其它所有用户;若是私聊,则将消息发给指定的用户。 系统在监控界面上写信息:管理员-消息 若出现异常,提示“发送失败”。 4 接收信息 系统启动后,等待客户请求 客户请求到,接受请求,分析确认是“接收信息请求” 系统读取信息,分析并确认是群发还是私聊 若是群发,则将信息发给聊天室内其它所有用户 系统向客户端发送“接收成功”消息(可省) 系统在监控界面上
12、写信息:xx客户名-消息 群发/私聊 若出现异常,向客户端发“接收失败”消息 5 用户退出 系统启动后,等待客户请求 客户请求到,接受请求,分析确认是“用户退出请求” 系统从聊天室删除客户,并通知其它用户“客户退出” 系统向客户端发“退出成功”,关闭连接。 聊天系统主要应用在局域网,在性能方面要求,客户到客户间消息传输时间不大于5s,传输可靠性要求95%的情况下,消息可以可靠传到目的地,同时在线用户数量不小于200。 友情提示:本需求分析只是分析了主要的用户使用情况,在对客户端进行分析时,聊天者是一个接口,服务方也是一个接口,在对服务端进行分析时,客户端是一个接口,服务方管理员是另一个接口。在
13、接口处只关心接口处的输入输出,并不关心接口里面是如何实现的。例如客户端登陆用例分析时,客户发“登录请求”信息到服务端,此时只需关注服务方返回情况,所以只需等待获取服务端返回信息,而无需知道服务方是如何处理的。服务方如何处理是在服务端登录用例中描述的。 隐含需求的发现。在登录用例中,客户和服务方都有登录用例,合作完成一个完整的登录过程,密码和用户名的验证一般都能想到,但限制用户数量,同一用户不能重复登录则不太容易想到,这里经验就会起作用,这是第一步,想到了就要向客户提出,具体要不要做由客户决定,则是第二步。这里还有一个度的把握,因为不可能任何情况都要向客户解释。经验如何来?学习前人的经验并运用到
14、自己的项目开发中,体会转化为自己的东西应该是个有效途径。 优先级的划分。作为聊天系统,其主要功能就是聊天,客户间互相发送消息,所以优先级最高的是客户端的发送、接收、退出用例,服务器端的接收、退出用例。注册、登录用例次之。而公告、踢人、保存日志及聊天记录、个性化界面等又次之。优先级划分后,设计实现时,先做优先级高的,例如本系统,为了实现上述全部功能,可以分3次迭代,第一次,实现高优先级的基本聊天功能,第二次实现注册和登录,第三次实现公告、踢人、保存日志及聊天记录等。其核心是先实现最重要和最难的,这一观点和日常思维相反,但却是有效避免风险和损失的方法,因为必需的和难度大的一开始就实现不了的话,项目
15、可以及时改变,否则等到最后才发现了难以解决而又必须解决的问题时,损失就会更大。当然在攻克重难点时,又可以采用由易到难的办法,逐步解决。一个是策略,一个是战术,思路相反,关键是要运用得当。 2.2.2 业务对象分析 从上述的分析中,运用名词法,可以发现出主要的业务对象: 1 聊天者: 属性:用户名、密码、确认密码、性别、年龄、电子邮件 行为:登录、注册 2 聊天客户端: 属性:消息、聊天者、界面 行为:接收处理,发送处理、退出 3 消息 属性:消息类型、消息参数 行为:创建消息、获取消息类型、获取消息参数 4 服务器 属性:IP、端口、服务监控、消息处理者 行为:监听、创建消息处理者、创建服务监
16、控 5 服务监控 属性:服务状态,消息,聊天者列表、界面 行为:发送服务方消息、关闭服务器 6 消息处理者 属性:连接、消息 行为:处理消息(登录、注册、发送、接收、退出),收发消息 友情提示:业务对象是系统中对象的初步提炼,其属性和行为在后面还会修改、变动,主要与业务相关,和具体的实现关系不大,是后面设计中业务类的基础,但实际类的数量也许会很多,因为在设计甚至在实现时都可能需要建立新的类以实现功能。不少讲分析设计的书并不提到这一步,而是在设计中直接给出类图,结果是一样的,但反映不出这些类是如何来的,如果你注重过程,可以看一下本节,若果你注重结果,直接看设计实现中的相关内容。 2.2.3 验收
17、测试要求 测试环境: 客户及服务器机操作系统:Window XP,内存:512M。 客户端程序安装在客户机上,通过以太网与服务器相连。 前置条件: 1 注册文件已创建但为空。 2 客户及服务程序安装配置正确,能正常启动运行。 3 客户程序与服务程序能通过网络互通。 一 初始化数据 1 客户端启动,进入注册界面,输入正确的注册数据,请求注册,查看服务端,看是否正确注册。 2 重复1,在另一客户端注册用户,注意不要重名。 二 功能测试 1 注册测试。测试重名注册。进入注册界面输入重名用户名,其它正确,请求注册。测试空输入,进入注册界面,直接按注册按钮。测试口令的一致性,口令长度,年龄及邮箱的数据有
18、效性。 2 登录测试。输入正确的口令和密码,按登录按钮空输入,直接按登录按钮。分别输入用户名不正确但密码正确,用户名正确但密码不正确,用户名和密码均不正确,应均不能正确登录。以同一用户名重复登录一次 测试时要查看服务端的显示 3 发送接收测试。进入收发界面,群发一条消息,观察其它客户是否收到消息,察看服务器有无相应显示 私聊一条消息,察看指定用户是否收到消息 无任何输入,直接按发送。退出系统,察看服务端显示,察看其它客户端是否已将该客户名删除。再启动客户端,登录进入收发界面,连续群发,连续私聊,再连续群发,观察其它客户及服务方的显示是否正确。 三 可靠性测试 1 切断一客户至服务器的网络连接,
19、分别进行注册、登录消息,客户端应能给出提示,而不是死机或退出,在正常聊天过程中,切断一客户端网络连接,客户程序应能给出提示。再接通网路,继续发送信息,应能正常运行。至少关闭并重启程序后,应能正常收发。同时观察其它客户及服务器收发、客户列表是否正常。 2 在正常收发中,强行关闭服务器,观察各客户端的反应。客户端应给出发送异常提示,不应退出或死机。 四 性能测试 编制一测试程序,作为客户端,登录进系统,向服务器按指定时间间隔群发消息。可同时启动多个发送线程,同时向服务器群发消息。看在200个模拟客户,每1s一个消息的情况下,服务器能否满足客户到客户传输时间小于5s的要求。也可以考虑使用JMeter
20、压力测试工具。 2.3 系统设计 2.3.1 总体设计 一 系统总体结构 总体设计阶段主要是确定系统的体系结构和主要模块 ,显然系统分客户端子系统和服务器子系统。系统体系结构如图2所示: 客户A 收发界面 业务逻辑 网络通信 TCP/IP 客户C TCP/IP 聊天服务器 监管界面 聊天业务处理 数据 网络通信 访问 TCP/IP 客户B 数据库/文件 图2 系统体系结构图 客户端可以划分成三子层,服务端也可以划分出三个子层,客户和服务器间通信采用的是可靠的TCP协议。基本的聊天过程如下: 0 客户端启动注册、登录后,进入收发界面,此时C/S连接已建立,C处于接收状态。 1 客户A从界面输入消
21、息,确定群发,业务逻辑层从界面获取信息并验证后生成“消息接收请求”消息,再将消息作为参数调用网络通信层的发送函数,发送函数将消息发往服务器,然后等待服务器的消息 2 服务器收到消息,确定是客户A发来的,从消息中分析出是群发,然后从当前客户列表中取出除A以外的与每个客户对应的socket,然后通过socket将消息转发给客户B,C。 3 服务器在监控界面上显示:客户A消息 群发 4 服务器生成“消息接收成功”消息,向客户A回发。 5 客户A收到消息,确定是“消息接收成功”消息后,在界面上显示发送成功。 6 客户B/C的通讯模块接收到消息,分析确认是“消息接收请求”,则在界面上显示:客户A-消息
22、群发。不向服务器发送消息收到的确认消息。 消息收发的简图如下图3所示: 发送 客户A 3接收消息成功 2.2接收消息请求 2.1接收消息请求1接收消息请求 聊天服务器 客户B 接收 客户C 接收 图3 消息收发示意图 经验共享:下面是本人在网络编程方面多年积累的经验,感兴趣的可以读一读。 要不要回复消息?由于使用的是TCP协议,可以保证点对点的可靠传输,所以最简单的情况是无需回复,在上图中取消3也可以,客户A将消息发到服务器就认为已成功群发了消息,但若客户B、C都断线,显然消息并没有成功群发。最复杂的是客户B、C收到消息后也回复给服务器,服务器确认都收到回复后再向A回复。前者编程简单、性能好,
23、但对于某些异常情况不能可靠处理,后者编程复杂,性能差,但可靠性高。这就要根据情况在上述矛盾中折中,对于“聊天室系统”,对可靠性要求并不高,即使消息有5%未收到,也没有大的问题,另外聊天者是处理各种不可靠问题的最佳人选,实在不行,可由人重启系统,另外本系统主要应用在局域网,而局域网的可靠性是较高的。所以本文推荐采用无回复方式。这适用于其它消息的处理。 消息的收发方式?主要分两种,一种是推方式,例如客户A有了消息就直接发给服务器,这是推方式,即由数据源方直接将消息发给接收方;另一种是拉方式,即接收方主动向数据源请求获取数据,例如服务器通过定期询问客户A有无数据的方式,客户A一旦有消息,就会发消息给
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- JAVA 课程设计 聊天室 系统
链接地址:https://www.31ppt.com/p-3159794.html