logo资料库

WEB课程设计.doc

第1页 / 共30页
第2页 / 共30页
第3页 / 共30页
第4页 / 共30页
第5页 / 共30页
第6页 / 共30页
第7页 / 共30页
第8页 / 共30页
资料共30页,剩余部分请下载后查看
系统的主要功能已在业务分析中有所介绍,在这里需要对每个功能从使用者角度作较为具体的分析。很明显,整个
一 客户端
二 服务器端
一 注册模块
2 验证密码是否为空
3 验证密码的一致性
4 验证年龄是否为空
6 验证电子邮箱的合法性
二 登录模块
1 验证用户名是否为空
2 验证密码是否为空
三 收发模块
1 用户发送信息
2 接收聊天信息
功能描述:
一 用户注册
二 用户登录
三 用户退出
3 返回聊天信息
WEB 课程设计 院(系) 别 班 学 姓 级 号 名 指导教师 时 间 2013-4-18—2013-5-10 长江大学
聊天室系统 目标 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)系统启动后,等待客户请求
分享到:
收藏