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的应用协议编程），所以系统的开发采用了“增量迭代”的开发方式，由简易到繁难，希望你能顺利前行。
我们的信念依然是：“不抛弃，不放弃”。
你的改变和收获依然是老师真诚的期待，期待你更踏实、更自信。
Come on!2.1 背景介绍2.1.1 业务背景随着网络社会的不断发展，具有相同兴趣的网民需要互相远程交流，既要能省钱又要能即时交互，电话太贵、email又嫌慢，所以开发一个类似QQ 的及时通讯系统就变得非常有意义了。
“Happy Chat”聊天系统应运而生，它较之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所示：图1 C/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次迭代，第一次，实现高优先级的基本聊天功能，第二次实现注册和登录，第三次实现公告、踢人、保存日志及聊天记录等。