面向对象分析与设计-即时聊天系统.doc
《面向对象分析与设计-即时聊天系统.doc》由会员分享，可在线阅读，更多相关《面向对象分析与设计-即时聊天系统.doc（28页珍藏版）》请在冰点文库上搜索。
中南民族大学
计算机科学学院
实验报告
课程面向对象分析与设计
题目即时聊天系统
年级2009级
专业软件工程
姓名
学号
指导教师
日期2012年03月28日
文档修订历史
日期
版本
教师评语
描述
12/03/09
1.0
系统概述
12/03/10
1.1
格式不对，修改
正文格式的校对，目录的更新
12/03/10
1.2
添加非功能性需求
非功能性需求的增加
12/03/16
2.0
术语表、用例、设计概述
12/03/17
2.1
用例图的修改
由于用例图添加了的内容很多，系统活动图需要整体修改，同时增加系统管理员的内容。
12/03/18
2.2
缺少界面
增加了系统界面
12/03/18
2.2
主界面的完善
界面增加主界面或者至少一个用例操作界面
12/03/25
3.0
类图、对象模型和数据字典
12/03/27
4.0
动态模型、功能模型、数据库定义、部署图
目录
28
1概述 4
1.1系统简述 4
1.2软件设计目标 4
1.3参考资料 6
1.4修订版本记录 6
2术语表 7
3用例 9
4设计概述 12
4.1简述 12
4.2系统结构设计 12
4.3系统界面 14
4.4约束和假定 16
5对象模型 16
5.1类定义 16
5.2类关联描述 16
5.3对象模型图 18
6对象数据字典描述 18
6.1用户系统中的对象 18
7动态模型 22
7.1场景（Scenarios） 22
7.2事件定义（Events） 23
7.3状态图 26
8功能模型 27
8.1确定输入输出与事件关系 27
8.2功能模型图 28
9数据库定义 30
10部署图 31
1概述
1.1系统简述
现在，各种聊天软件相继出现，其中以QQ软件做的最好。
但是由于其商业化性质太强，各种增值业务的存在，导致QQ用户等级划分出现，引起了部分用户的反感。
即时聊天系统，又名LovelyTalk，是一款非盈利性质的聊天软件。
其用户界面形象直观，简洁快速实用，可以满足大部分人群的聊天需求，同时满足平等化的观念。
即时聊天系统，是一个在线聊天软件。
该系统的开发主要包括后台数据库的建立与维护，前台应用程序、用户界面的开发两大方面。
运行环境
硬件环境：
处理器：
IntelPentium及以上/AMD
内存：
512M
硬盘空间：
80G
软件环境：
服务器端/客户端：
操作系统：
Windows98/ME/2000/XP或者Win7
1.2软件设计目标
功能需求：
（1）该系统可以实现用户在此线注册、登录的功能以及用户间的查询、添加好友、删除好友、聊天、访问家园空间、进入娱乐应用以及举报的功能。
（2）该系统采用形象化界面，根据用户的提供住址信息，将在界面地图上标注。
这样好友容易知道对方的一些基本信息。
同时，此系统只记录在线人员的情况，不提供隐身、忙碌等状态。
即LovelyTalk的宗旨是活跃聊天的即时聊天系统。
（3）该系统在每个地区划分上设有一系列的管理员，类似现实中的省长、市长、县长，共分三级管理员，负责不同的事情。
管理员账户系统自动分配，且是固定的。
非功能需求：
（1）该系统使用C++编写，后台数据库使用SQL支持，同时需要Word、Photoshop、Excel、Visio等软件设计一些必要的文档、表格、图片以及各种UML图。
（2）该系统在Windows98/2000/XP/Win7等均可运行，操作简便，程序响应快速，用户界面友好。
系统总体活动图如下：
1.3参考资料
[1]麻志毅.《面向对象分析与设计》.机械工业出版社,2008
[2]王珊、萨师煊.《数据库系统概论》.高等教育出版社,2006
[3]张海藩.《软件工程导论》.清华大学出版社,2008
1.4修订版本记录
文档修订历史
日期
版本
教师评语
描述
12/03/09
1.0
系统概述
12/03/10
1.1
格式不对，修改
正文格式的校对，目录的更新
12/03/10
1.2
添加非功能性需求
非功能性需求的增加
12/03/16
2.0
术语表、用例、设计概述
12/03/17
2.1
用例图的修改
由于用例图添加了的内容很多，系统活动图需要整体修改，同时增加系统管理员的内容。
12/03/18
2.2
缺少界面
增加了系统界面
12/03/18
2.2
主界面的完善
界面增加主界面或者至少一个用例操作界面
12/03/25
3.0
类图、对象模型和数据字典
12/03/27
4.0
动态模型、功能模型、数据库定义、部署图
2术语表
用户
1.注册：
用户想要使用即时聊天系统─LovelyTalk，必须申请一个账号，这是一切操作的前提。
2.登录：
用户在申请到账号之后，使用账号和密码进行登录，进行其他操作。
每一个新用户都必须登录后才能使用系统进行其他操作。
3.好友操作：
.查询好友，用户根据好友的账号，进行搜索查询，然后进行相关操作。
添加好友，用户可以将好友添加到好友列表中去。
删除好友，用户可以选择性的删除部分不聊天的好友。
聊天，用户和好友交流时，点击好友家园，就可以进行交互聊天了。
因为系统只提供在线状态，即用户如果在线，则家显示开放状态，有色彩。
如果不在线，则显示关闭状态。
即形象化的开门和关门状态。
访问空间，即访问用户的家园空间。
4.娱乐应用：
用户在聊天之余可以进行娱乐活动。
娱乐应用里提供了丰富的在线小游戏。
同时提供家园空间。
家园空间，是用户拥有自己的账号之后，根据其归属地，在虚拟地图上生成的相应的房屋标志，这是用户的家。
较之一般的空间，显得更形象化。
5.举报：
用户可以举报一些违法、骗人的用户，被举报的用户会被系统管理员审核，并作相应处理。
小管（第三级级系统管理员）
1.后台登录：
后台专门的系统管理员登录界面，小管理员使用既定的账号密码登录。
并开始其他工作。
2.审核：
小管是指系统管理员最低权限管理，负责审核用户举报的违法用户，并将信息反馈给中管，即第二级系统管理员。
中管（第二级系统管理员）
1.后台登录：
后台专门的系统管理员登录界面，中管理员使用既定的账号密码登录。
并开始其他工作。
2.处理：
中管接收小管提供的信息，对账号的行为进行简略描述，并将处罚方式——封号永久、封号几天等，整理后反馈给大管，即第一级系统管理员。
大管（第一级系统管理员）
1.后台登录：
后台专门的系统管理员登录界面，大管理员使用既定的账号密码登录。
并开始其他工作。
2.执行：
通过中管的处理信息，对违法用户做出相应处罚。
3.发布：
发布系统消息，如系统更新通知，提醒用户注意骗子等。
3用例
系统总体用例图如下：
用例表如下：
用例1
注册
参与者
用户
前置条件
登录LovelyTalk的官网
后置条件
获得合法账号和密码
工作流
1.【用户】进入官网界面
2.【用户】填写注册信息
3.【用户】获得账号
用例2
登录
参与者
用户
前置条件
成功注册，输入合法的账号和正确的密码
后置条件
工作流
1.【用户】输入登录信息
2.【系统】检验登录信息，若合法，登录成功进入操作界面；否则输出密码错误。
用例3
好友操作
参与者
用户
前置条件
成功登录并进入操作页面
后置条件
工作流
1.【用户】选择查询好友功能，输入好友账号查找
2.【用户】选择添加好友，根据好友账号选择添加，并发送验证信息，好友收到后，同意即完成添加。
3.【用户】选择删除好友。
4.【用户】选择聊天操作，和好友进行即时聊天。
5.【用户】选择访问家园空间，进入好友的家园空间查看、留言等操作。
用例4
娱乐应用
参与者
用户
前置条件
成功登录并进入操作页面
后置条件
工作流
1.【用户】选择娱乐应用选择，点击游戏进入。
2.【系统】响应用户请求，载入游戏。
3.【用户】选择退出操作，返回操作界面。
用例5
举报
参与者
用户
前置条件
成功登录并进入操作页面
后置条件
有违法用户进行违法操作
工作流
1.【用户】点击违法用户，选择举报。
2.【系统】接受信息，进行核实处理。
用例6
后台登录
参与者
小管、中管、大管（系统管理员）
前置条件
系统分配账号和密码
后置条件
输入合法信息，输入正确密码
工作流
1.【系统管理员】输入账号和密码
2.【系统】检验登录信息，若正确则进入管理界面；否则，输出密码错误。
用例7
审核
参与者
小管
前置条件
成功登录并进入管理页面
后置条件
工作流
1.【小管】查看用户举报的信息，并进行筛选。
2.【系统】将筛选后的用户反馈给中管。
用例8
处理
参与者
中管
前置条件
成功登录并进入管理页面
后置条件
工作流
1.【中管】查看小管反馈来的信息，进行处理。
写出处理信息简述以及处理方案。
2.【系统】将处理后的信息反馈给大管。
用例9
执行
参与者
大管
前置条件
成功登录并进入管理页面
后置条件
工作流
1.【大管】查看中管反馈的信息，点击执行。
2.【系统】对违法账号执行封号等处理。
4设计概述
4.1简述
本系统采用了面向对象分析、设计方法，基于对象而不再是基于结构；
系统采用了三层C/S结构风格，包括数据库服务器、应用服务器以及Web浏览器。
作图过程中采用的是UML（统一建模语言）和MicrosoftVisio进行作图。
4.2系统结构设计
系统层级方框图如下：
4.2.1系统顶层系统结构图如下：
4.3系统界面
即时聊天系统可以包括四个系统界面，分别是用户登录界面，用户操作界面，系统后台登录界面，系统后台操作界面四个部分。
本题目只提供用户登录界面和用户操作界面。
用户登录界面如下：
主界面之聊天用例的操作界面窗口如下所示：
4.4约束和假定
该系统须在9周之内完成，预算投入10万人民币。
提供4-5个熟练的程序员。
开发此系统的语言最好能使用开发此系统的语言最好能使用跨平台语言进行开发。
当1亿名用户同时登录系统时，系统应该正常运行。
系统响应时间应该在人所能接受的等待时间范围内（一般为1秒左右）。
界面友好，易于操作，安全性好。
5对象模型
5.1类定义
账号
用户
大管
中管
小管
5.2类关联描述
类关联
关联关系
意义
1
账号与用户
1：
1
一个用户只能拥有一个账号，账号是系统判别用户的唯一标识。
2
小管与账号
m：
n
在某一特定的区域内（县区），一名小管管理多名账号。
全部区域共有多名小管。
3
中管与账号
m：
n
在某一稍大特定的区域内（市区），一名中管管理更多名账号全部区域共有多名中管。
4
大管与账号
m：
n
在某一更大特定的区域内（省区），一名大管管理更多名账号。
全部区域共有多名大管。
5
中管与小管
m：
n
在同一特定的区域内（市区），一名中管管理多名小管。
全部区域内，多名中管管理着对应的更多名小管。
6
大管与中管
m：
n
在同一特定的区域内（省区），一名大管管理多名中管。
全部区域内，多名大管管理着对应的较多名中管。
7
大管与小管
m:
n
在同一特定的区域内（省区），一名大管管理多名小管。
全部区域内，多名大管管理着对应的很多名小管。
5.3对象模型图
6对象数据字典描述
6.1用户系统中的对象
6.1.1对象：
用户
用途：
记录用户信息
约束：
一个用户只有一个账号记录个人信息
持久性：
长久存在于数据库中
6.1.1.1属性描述：
1.属性：
账号
类型：
string型
描述：
主键，唯一标识用户
约束：
每个用户都有绝对不相同的账号
2.属性：
昵称
类型：
string型
描述：
不同用户可以采用相同的昵称
约束：
每个用户只有一个昵称
3.属性：
密码
类型：
string类型
描述：
用户可以自行设置密码
约束：
每个用户只有一个密码
6.1.1.2方法描述：
1.方法：
注册
返回类型：
string型
参数：
注册信息
返回值：
账号
Pre-Condition：
用户注册LovelyTalk即时聊天系统
Post-Condition：
系统分配未被申请的账号
读取/修改的属性：
读取账号
调用的方法：
程序中嵌入SQL语句
处理逻辑：
系统根据用户填写的信息，将信息赋予一个账号，然后就账号返回给用户。
2.方法：
登录
返回类型：
无
参数：
账号、密码
返回值：
登录结果
Pre-Condition：
用户存在，用户登录LovelyTalk即时聊天系统
Post-Condition：
系统检测密码是否正确
读取/修改的属性：
读取账号、密码
调用的方法：
程序中嵌入SQL语句
处理逻辑：
系统根据用户登录信息，匹配账号和密码是否完全正确。
完全正确，则进入系统；否则，则返回错误信息提示。
3.方法：
选择操作
返回类型：
无
参数：
操作
返回值：
无
Pre-Condition：
用户在系统界面选择好友操作
Post-Condition：
系统响应操作
读取/修改的属性：
查找好友、删除好友、添加好友
调用的方法：
程序中嵌入SQL语句
处理逻辑：
系统根据用户选择，如果是查找好友，则根据用户填写的账号，查询出账号信息，并反馈账号信息。
如果是添加，则是用户选择添加好友操作，系统将用户的好友请求发送给对方。
如果是删除，系统则将用户的好友列表内被删除好友移除，并更新好友列表。
4.方法：
玩应用
返回类型：
无
参数：
选择应用
返回值：
无
Pre-Condition：
用户选择应用，并选择应用项
Post-Condition：
系统已提供该应用
读取/修改的属性：
读取应用
调用的方法：
程序中嵌入SQL语句
处理逻辑：
系统根据用户选择应用，将应用载入供用户使用。
如果应用出错，将及时反馈出错信息。
5.方法：
举报
返回类型：
string型
参数：
举报的账号
返回值：
处理结果
Pre-Condition：
用户发现违法用户，对其账号进行举报
Post-Condition：
系统管理员对举报的账号进行处理
读取/修改的属性：
读取被举报账号
调用的方法：
程序中嵌入SQL语句
处理逻辑：
系统根据用户的举报信息，将违法账号发送到系统管理员操作窗口，系统管理员根据用户举报进行处理，最终执行处理结果。
测试例1：
注册
CASE
输入
期望结果
CASE1
输入注册
输出获取账号
CASE2
输入错误信息
给出警告信息
CASE3
输入合法信息
输出账号
CASE4
输入合法信息但系统繁忙
注册失败提示
测试例2：
登录
CASE
输入
期望结果
CASE1
输入账号、密码
输出登录成功，进入用户操作主界面
CASE2
输入错误账号、密码
提示账号不存在或者密码错误
CASE3
输入正确账号、密码
输出登录成功，进入用户操作主界面
CASE4
输入正确账号、密码，但系统繁忙
登录失败提示
测试例3：
举报
CASE
输入
期望结果
CASE1
举报账号
举报成功
CASE2
填写举报的原因
尽快处理反馈
CASE3
再次举报同一账号
系统提示，该账号您已经举报，无须重复举报
CASE4
系统繁忙
举报失败提示
7动态模型
用户操作界面好友操作用例的顺序图如下：
7.1场景（Scenarios）
7.1.1场景：
注册
描述：
用户通过填写注册信息以获得账号。
（注：
而系统管理员则是系统已经确定的账号和密码。
）
动作1：
用户打开LovelyTalk即时聊天系统官网，点击申请账号
动作2：
填写正确的注册信息
7.1.2场景：
登录
描述：
用户打开LovelyTalk聊天软件，填写正确的账号和密码，若正确，系统直接跳转到用户操作界面；若是错误，则返回提示信息
动作1：
用户输入账号和密码
动作2：
等待系统验证
7.1.3场景：
查询好友信息
描述：
用户在操作界面，选择查询好友操作。
动作1：
用户点击好友列表，选择查询好友
动作2：
输入查询条件
7.1.4场景：
添加/删除好友
描述：
用户在登录界面，在查询好友后选择添加好友操作。
或者在好友列表中选择删除好友操作。
动作1：
用户找到好友信息
动作2：
选择添加好友操作或者删除好友操作
7.1.5场景：
玩娱乐应用
描述：
用户在聊天之余可以选择玩一些小游戏或者做些其他有趣的事情，用以放松。
动作1：
用户点击娱乐应用
动作2：
用户从应用列表中选择想玩的应用
7.1.6场景：
举报
描述：
用户发现有违法用户向其发送虚假信息时，可以举报违法用户。
动作1：
用户选择违法用户
动作2：
选择举报
7.2事件定义（Events）
7.2.1LovelyTalk即时聊天系统的事件跟踪图如下：
7.2.2LovelyTalk即时聊天系统的事件流图如下
7.2.3定义事件：
添加好友成功事件
添加好友事件顺序图：
7.2.4定义事件：
玩娱乐应用事件
玩娱乐应用顺序图：
7.3状态图
7.3.1好友列表状态：
7.3.2用户登录状态：
8功能模型
8.1确定输入输出与事件关系
添加好友事件与输入输出之间的关系：
玩娱乐应用事件与输入输出之间的关系：
8.2功能模型图
8.2.1用户对象的添加好友功能模型图
8.2.2用户对象的玩娱乐功能模型图
8.2.3用户对象的举报功能模型图
8.2.4系统管理员对象的审核、处理、执行功能模型图
9数据库定义
表定义如下：
用户（账号、密码、注册信息）
用户信息（账号、姓名、性别、年龄、住址、联系方式、其他）
注：
账号为“用户”的外键
娱乐应用（编号、类别、出处）
用户操作（账号、查询、添加、删除、举报、编号）
注：
账号为“用户”的外键，“编号”为娱乐应用的外键
系统管理员（系统账号、密码、类别）
管理员信息（系统账号、类别、姓名、性别、年龄、住址、联系方式、其他）
注：
系统账号为“系统管理员”的外键
管理员操作（系统账号、操作）
注：
系统账号为“系统管理员”的外键
10部署图
即时聊天系统部署图如下：
此部署图显示了系统采用三层C/S结构风格。
用户通过个人计算机登录连接应用服务器进而连接到数据库服务器，进行各种操作。
而通过web服务器进行注册操作，通过连接数据库服务器获得操作结果。
系统管理根据系统提供的账号通过后台客户端登录操作，与应用服务器不发生交互冲突。
升级会员 