《UML建模案例——即时通信系统》.docVIP

案例：即时通信系统 问题描述 设计一个即时通信系统，实现多个用户进行网上聊天的功能，各个聊天客户端通过注册、登录才可以和好友进行通信。系统既包括客户端部分、也包括服务器端部分。 在客户端能够实现消息的查看，添加和删除网上的好友，与选定的好友进行通信，查询自己与好友的聊天记录等功能。 服务器端负责好友的在线维护，同时服务器还应该具有保存用户资料和用户聊天记录的功能。此外，当用户不在线时，收到的好友消息能够被保存，使用户在下次登录时可以查看。 2、建立用例模型 （1）确定参与者 当考虑构造一个系统时，首先要确定系统的边界，即主体。系统边界定义了由谁（参与者）使用系统，系统能够为参与者提供什么功能（用例）。根据定义，参与者是指所有存在于系统外部并与系统进行交互的人或其他系统。为了确定参与者，需要考虑谁或什么使用系统，它们在与系统的交互中扮演什么角色，然后归纳它们。 一般地，寻找参与者可以从一下问题入手： 系统开发完成后，有哪些人会使用这个系统？ 系统需要从哪些人或其他系统获取数据？ 系统会为哪些人或其他系统提供数据？ 系统会与哪些其他系统相关联？ 系统是由谁维护和管理的？ 谁启动或关闭系统？ 这些问题有助于抽象出系统的参与者。 分析： 对于即时通信系统，参与聊天的客户（Client）显然是系统的参与者。 为了完成在线客户的管理和客户信息的验证等功能，需要有一个服务器（Server）。 为了实现客户信息和通信记录的存储等功能，需要有一个数据库（DataBase）。 （2）确定用例 确定参与者后，就可以根据参与者来确定系统的用例，用例是参与者想要系统做的事情。需找用例可以从以下问题入手（针对每一个参与者）： 参与者希望系统提供什么功能？ 参与者是否会在系统中创建、修改、删除、访问、存储数据？如果是的话，参与者又是如何来完成这些操作的？ 参与者是否会将外部的某些事件通知给该系统？ 系统是否会将内部的某些事件通知给该参与者？ 分析： 参与者Client使用的用例有：Register（注册账号）、Log in（登录系统）、Log out（退出系统）、Send Message(发送消息)、Add Friends （添加好友）、Delete Friends（删除好友）、Query Record（查询聊天记录）等。 参与者Server使用的用例有：Log in（登录系统）、Log out（退出系统）、Add Friends （添加好友）等。 参与者Database使用的用例有：Register（注册账号）、Send Message(发送消息)、Add Friends （添加好友）、Delete Friends（删除好友）、Query Record（查询聊天记录）等。 在用例的抽取过程中，必须注意：用例必须是由某一个参与者触发而产生的活动。如果存在与参与者不进行交互的用例，就可以考虑将其并入其他用例；或者检查该用例相对应的参与者是否被遗漏？然后补上相应的参与者。 反之，每个参与者也必须至少涉及到一个用例，如果发现有不与用例相关联的参与者存在，就应该考虑该参与者是否与系统发生交互？若是，则由该参与者确定一个新的用例；若不是，则该参与者是一个多余的模型元素，应该将其删除。 3、用例描述 用例图只是在总体上描述了系统所能提供的各种服务，但是没有提供任何细节信息。为此，对于每个用例，还需要有详细的说明，即用例描述。 对于用例描述的格式和内容，没有硬性规定，但一般应包括以下几部分： 用例名称 用例编号 参与者 简要描述 事件流：包括基本事件流、可选事件流和异常事件流 前置条件 后置条件 对于上述用例图中的用例，其描述如下表： 表1：用例“注册账号”的描述 用例名称： Register 用例编号： UC001 优先级： 高 参与者： 客户、数据库 简要描述： 客户在即时通信系统中注册 前置条件： 客户端应用程序主界面已经启动 基本事件流： 1、客户单击“注册”按钮； 2、系统弹出一个注册交互对话框； 3、客户输入注册信息； 4、客户单击“提交”按钮，发送注册信息到数据库； 5、数据库保存注册信息，并自动生成一个数字ID返回； 6、客户端弹出对话框显示注册的ID，提示注册成功 7、用例终止。 可选事件流： 在单击“提交”按钮前，客户可随时单击“取消”按钮，关闭注册窗口，返回客户端界面 异常事件流： 提示注册错误，请稍后再试，客户确认，然后返回客户端主界面 后置条件： 客户获得一个ID，可用此ID登录系统开始即时通信 表2：用例“登录系统”的描述 用例名称： Log in 用例编号： UC002 优先级： 高 参与者： 客户、服务器 简要描述： 客户登录即时通信系统 前置条件： 客户端应用程序主界面已经启动，并且已经有了注册ID 基本事件流： 1、客户输入ID和密码