java与uml面向对象程序设计用例图.pptVIP

Java与UML面向对象程序设计 第4章 用例图 用例图概述 用例图（Use Case Diagram）以每一个参与系统的人员都能理解的方式列举系统的业务需求，它将系统、子系统和类的行为可视化，以利于所有参与人员准确理解这些元素，并确保软件的开发人员最终实现这些元素。 用例图的建立处在RUP的第一阶段，它是获取需求的直接方法。 用例图还是软件测试人员进行测试的指导。 用例图中的标记符元素 系统边界； 参与者（Actor）； 用例（Use Case）； 用例间的关系（Relationship）。 用例图示例 主体 主体（Subject）就是UML早期版本中的系统边界，在UML 2.0中把主体作为系统边界的正式术语。在开发一个系统时，首先要确定系统的主体，即决定什么是系统的组成部分，什么是系统的外部。 主体决定了谁（参与者）使用系统，系统能为谁提供什么功能（用例）。这表面看起来显而易见，事实上，对于某些系统来说，其边界很难确定。 UML系统边界表示法 参与者 参与者是指系统以外的，在使用系统或与系统交互中所扮演的角色。因此参与者可以是人，可以是事物，也可以是时间或其它系统等等。 参与者在建模过程中利用人形符号和命名来表示。由于参与者表示外部事物参与系统的角色，因此参与者的命名一定要充分体现其功能特性。 用例图中的参与者命名 参与者间的泛化关系 用例 用例（Use Case）最初由Ivar Jackboson博士提出，后被综合到UML规范之中。它用来表示参与者期望系统所要完成的功能。 系统执行的一组动作序列，这些动作序列可以产生一个特定参与者可观察的结果。简单来讲，用例就是对系统功能的描述。不过，一个用例描述的是整个系统功能的一部分（子功能模块），若干个用例联合起来描述了完整的系统功能。 用例主要有以下几个特点 用例总是由参与者来启动的。 用例必须为参与者提供数据。 用例的完整性。 用例图中的通信关联 用例之间的关系 泛化（Generalization）关系 包含（Include）关系 扩展（Extend）关系 用例间的泛化关系 多级泛化关系 用例间的包含关系 用例包含关系示例 用例间的扩展关系 建立用例模型 问题描述 确定参与者 确定用例 用例描述 即时通信系统的参与者 即时通信系统用例图 用例“注册帐号”的描述 用例“登录系统”的描述 用例“发送消息”的描述 用例“添加好友”的描述 用例“删除好友”的描述 用例“查询聊天记录”的描述 用例“退出系统”的描述 检查用例模型 功能需求的完备性 模型是否易于理解 是否存在不一致性 避免二义性语义 根据以上检查，如果发现用例模型符合要求，则完成了系统的用例建模。 * 后置条件： 客户获得一个ID，可用此ID登录系统开始即时通信。 异常事件流： 提示注册错误，请稍后再试，客户确认，然后返回客户端主界面。 可选事件流： 在“提交”按钮前，客户可随时点击“取消”按钮，关闭注册窗口，返回客户端主界面。 基本事件流： 客户点击“注册”按钮。 系统弹出一个注册交互对话框。 客户输入注册信息：昵称、密码等。 客户按“提交”按钮，发送注册信息到数据库。 数据库保存注册信息，并自动生成一个数字ID返回。 客户端弹出对话框显示注册的ID，提示注册成功。 用例终止。 前置条件： 客户端应用程序主界面已经启动。 简要描述： 客户在即时通信系统中注册。 参与者： 客户、数据库 用例名称： Register 后置条件： 主界面显示用户好友及好友的在线状态。 异常事件流： 提示登录失败，请稍后再试，客户确认，然后返回客户端主界面。 可选事件流： 将用户不合法消息发送给客户，提示重新登录。 基本事件流： 客户点击应用程序主界面上的“登录”按钮。 系统弹出一个登录交互对话框。 客户输入ID和密码。 客户按“登录”按钮，发送登录请求到服务器（包含ID、密码和用户的网络通信参数）。 服务器执行“验证用户”用例，将登录请求中的信息（ID和密码）发送给数据库。 数据库将ID和密码与数据库中的注册纪录比对。 如果用户信息合法，数据库发送合法消息、用户的详细注册资料和用户不在线期间收到的离线消息给服务器，否则进入可选事件流。 服务器将客户加入在线用户列表（列表维护了用户的一切注册资料和网络通信参数），返回登录成功消息和离线消息给客户，并将在线用户列表发送给所有的在线用户。 提示登录成功，更新好友列表的状态信息并显示离线消息。 用例终止。 前置条件： 客户端应用程序主界面已经启动，并且已经有了注册ID。 简要描述： 客户登录即时通信系统。 参与者： 客户、服务器 用例名称： Log in 后置条件： 客户返回登录后的主界面状态。