UML建模案例即时通信系统方案.docx

UML建模案例即时通信系统方案.docx

《UML建模案例即时通信系统方案.docx》由会员分享，可在线阅读，更多相关《UML建模案例即时通信系统方案.docx（7页珍藏版）》请在冰豆网上搜索。

UML建模案例即时通信系统方案

案例：

即时通信系统

1、问题描述

设计一个即时通信系统，实现多个用户进行网上聊天的功能，各个聊天客户端通过注册、登录才可以和好友进行通信。

系统既包括客户端部分、也包括服务器端部分。

在客户端能够实现消息的查看，添加和删除网上的好友，与选定的好友进行通信，查询自己与好友的聊天记录等功能。

服务器端负责好友的在线维护，同时服务器还应该具有保存用户资料和用户聊天记录的功能。

此外，当用户不在线时，收到的好友消息能够被保存，使用户在下次登录时可以查看。

2、建立用例模型

（1）确定参与者

当考虑构造一个系统时，首先要确定系统的边界，即主体。

系统边界定义了由谁（参与者）使用系统，系统能够为参与者提供什么功能（用例）。

根据定义，参与者是指所有存在于系统外部并与系统进行交互的人或其他系统。

为了确定参与者，需要考虑谁或什么使用系统，它们在与系统的交互中扮演什么角色，然后归纳它们。

一般地，寻找参与者可以从一下问题入手：

●系统开发完成后，有哪些人会使用这个系统？

●系统需要从哪些人或其他系统获取数据？

●系统会为哪些人或其他系统提供数据？

●系统会与哪些其他系统相关联？

●系统是由谁维护和管理的？

●谁启动或关闭系统？

这些问题有助于抽象出系统的参与者。

分析：

●对于即时通信系统，参与聊天的客户（Client）显然是系统的参与者。

●为了完成在线客户的管理和客户信息的验证等功能，需要有一个服务器（Server）。

●为了实现客户信息和通信记录的存储等功能，需要有一个数据库（DataBase）。

（2）确定用例

确定参与者后，就可以根据参与者来确定系统的用例，用例是参与者想要系统做的事情。

需找用例可以从以下问题入手（针对每一个参与者）：

●参与者希望系统提供什么功能？

●参与者是否会在系统中创建、修改、删除、访问、存储数据？

如果是的话，参与者又是如何来完成这些操作的？

●参与者是否会将外部的某些事件通知给该系统？

●系统是否会将内部的某些事件通知给该参与者？

分析：

●参与者Client使用的用例有：

Register（注册账号）、Login（登录系统）、Logout（退出系统）、SendMessage（发送消息）、AddFriends（添加好友）、DeleteFriends（删除好友）、QueryRecord（查询聊天记录）等。

●参与者Server使用的用例有：

Login（登录系统）、Logout（退出系统）、AddFriends（添加好友）等。

●参与者Database使用的用例有：

Register（注册账号）、SendMessage（发送消息）、AddFriends（添加好友）、DeleteFriends（删除好友）、QueryRecord（查询聊天记录）等。

在用例的抽取过程中，必须注意：

用例必须是由某一个参与者触发而产生的活动。

如果存在与参与者不进行交互的用例，就可以考虑将其并入其他用例；或者检查该用例相对应的参与者是否被遗漏？

然后补上相应的参与者。

反之，每个参与者也必须至少涉及到一个用例，如果发现有不与用例相关联的参与者存在，就应该考虑该参与者是否与系统发生交互？

若是，则由该参与者确定一个新的用例；若不是，则该参与者是一个多余的模型元素，应该将其删除。

3、用例描述

用例图只是在总体上描述了系统所能提供的各种服务，但是没有提供任何细节信息。

为此，对于每个用例，还需要有详细的说明，即用例描述。

对于用例描述的格式和内容，没有硬性规定，但一般应包括以下几部分：

●用例名称

●用例编号

●参与者

●简要描述

●事件流：

包括基本事件流、可选事件流和异常事件流

●前置条件

●后置条件

对于上述用例图中的用例，其描述如下表：

表1：

用例“注册账号”的描述

用例名称：

Register

用例编号：

UC001

优先级：

高

参与者：

客户、数据库

简要描述：

客户在即时通信系统中注册

前置条件：

客户端应用程序主界面已经启动

基本事件流：

1、客户单击“注册”按钮；

2、系统弹出一个注册交互对话框；

3、客户输入注册信息；

4、客户单击“提交”按钮，发送注册信息到数据库；

5、数据库保存注册信息，并自动生成一个数字ID返回；

6、客户端弹出对话框显示注册的ID，提示注册成功

7、用例终止。

可选事件流：

在单击“提交”按钮前，客户可随时单击“取消”按钮，关闭注册窗口，返回客户端界面

异常事件流：

提示注册错误，请稍后再试，客户确认，然后返回客户端主界面

后置条件：

客户获得一个ID，可用此ID登录系统开始即时通信

表2：

用例“登录系统”的描述

用例名称：

Login

用例编号：

UC002

优先级：

高

参与者：

客户、服务器

简要描述：

客户登录即时通信系统

前置条件：

客户端应用程序主界面已经启动，并且已经有了注册ID

基本事件流：

1、客户输入ID和密码；

2、客户单击“登录”按钮，发送登录请求到服务器；

3、服务器执行“验证用户”用例，将登录请求中的信息发送给数据库；

4、数据库将ID和密码与数据库中的注册记录比对；

5、如果用户信息合法，数据库发送合法信息、用户的详细注册资料和用户不在线期间收到的离线消息给服务器，否则进入可选事件流。

6、服务器将客户加入在线用户列表，返回登录成功消息和离线消息给客户，并将在线用户列表发送给所有的在线用户。

7、提示登录成功，更新好友列表的状态信息并显示离线消息

8、用例终止

可选事件流：

将用户不合法消息发送给客户，提示重新登录

异常事件流：

提示登录失败，请稍后再试，客户确认，然后返回客户端主界面

后置条件：

主界面显示用户好友及好友的在线状态

表3：

用例“发送消息”的描述

用例名称：

SendMessage

用例编号：

UC003

优先级：

高

参与者：

客户、数据库

简要描述：

客户给自己的好友（在线和离线）发送消息

前置条件：

客户已成功登录即时通信系统

基本事件流：

1、客户选择一个好友；

2、系统激活主界面消息编辑文本框；

3、客户在文本框中输入、编辑消息，然后单击“发送”按钮；

4、如果好友不在线，发送消息给数据库，数据库保存该聊天记录；否则执行可选事件流

5、数据库返回聊天记录已保存的通知。

6、系统提示“对方在登录时会看到您发的消息”

7、用例终止

可选事件流：

1、从好友列表中读出此用户的通信参数，将消息直接发送给用户

2、用户返回消息收到通知

3、系统提示客户“消息已成功发送对方”

异常事件流：

提示消息发送失败，请稍后再试，客户确认，然后返回客户端主界面

后置条件：

客户返回登录后的主界面状态

表4：

用例“添加好友”的描述

用例名称：

AddFriends

用例编号：

UC004

优先级：

高

参与者：

客户、数据库、服务器

简要描述：

客户端查询数据库列表并选择添加好友

前置条件：

客户已成功登录即时通信系统

基本事件流：

1、客户单击“添加好友”按钮；

2、系统弹出“用户浏览”对话框；

3、客户端发送查询请求给数据库；

4、数据库返回用户信息给用户浏览对话框

5、客户选择需要添加的好友，并单击“添加”按钮。

6、系统更新客户的好友列表，新添加的好友展示为离线状态；

7、客户发送刚添加的好友消息给服务器；

8、服务器查询在线用户列表，如果用户在线，返回消息给客户，否则执行可选事件流；

9、客户端将好友列表中此用户更改为在线状态；

10、用例终止

可选事件流：

1、服务器发送消息给数据库

2、数据库将此用户被添加为好友的消息保存为用户的离线消息

异常事件流：

提示添加好友失败，请稍后再试，客户确认，然后返回客户端主界面

后置条件：

返回用户浏览对话框，让用户选择“继续添加好友”或者“返回”