统一建模语言UML验实报告.docVIP

实 验 报 告 课程名称 统一建模语言 实验名称 需求模型的建立 实验时间 2015 年 4 月 2 日 指导单位 计算机学院软件工程系 指导教师 陈志 学生姓名 班级学号 学院(系) 计算机学院 专 业 软件工程 成 绩 批阅人 陈志 日期 2015-4-30 实 验 报 告 实验名称 需求模型的建立 指导教师 陈志 实验类型 验证 实验学时 2 实验时间 2015-4-2 实验目的和要求 实验目的： （1）明确用例图的组成及在建模中的作用 （2）分析餐馆预约系统，使用用例图来获取系统功能需求，并建立领域模型 （3）学习使用 UML 用例图和类图 实验要求： （1） 理解 USE CASE 模型及 View的原理，并能用 Rose 正确画出相关的模型图 （2） 熟悉 Rational Rose Enterprise 的基本用法及文档的组织管理 实验环境(实验设备) 硬件：微机 软件：Rational Software Architect 实验原理及内容 实验原理： 1. Use Case 模型 一个 Use Case 模型由一个或者多个用例图和所有的支持文件（诸如用例规范和参与者定义等）所构成。用例规范是大多数用例模型的产物，而用例图充当将需求模型综合在一起的粘胶剂。用例模型应当从项目投资者的角度进行开发，而不是从开发者的（通常是技术）观点去开发。用例描述通过用户与系统的交互来表示从外部看到的系统功能。用例图由参与者、一组（个）用例、关系等三部分组成，如图 5 所示。 参与者是直接与系统相互作用的系统、子系统或类的外部实体的抽象。它是用户所扮演的角色，是系统的用户。每个参与者定义了一个角色集合。通常，一个参与者可以代表一个人、一个计算机子系统、硬件设备或者时间等角色。在 Rational Rose Enterprise 中，参与者用小人图符表示。参与者可以通过以下方面进行识别： （1） 谁将使用系统的主要功能？ （2）谁将需要系统的支持来完成他们的日常任务？ （3）谁必须维护、管理和确保系统正常工作？ （4） 谁将给系统提供信息、使用信息和删除信息？ （5） 系统需要处理哪些硬件设备？ （6） 系统使用了外部资源吗？ （7） 系统需要与其他什么系统交互吗？ （8） 谁或者什么对系统产生的结果感兴趣？ （9） 一个人同时使用几种不同的规则吗？ （10）几个人使用相同的规则吗？ （11） 系统使用遗留下来的应用吗 用例是对一组动作序列的描述，系统通过执行这一组动作序列为参与者产生一个可观察的结果，在 Rational Rose Enterprise中，用例采用椭圆形表示，其名字显示在图标的下面。用例的特征有： （1）说明了系统具有的一种行为模式 （2）说明了一个参与者与系统执行的一个相关的事务序列 （3）提供了一种获取系统需求的方法 （4）提供了一种与最终的用户和领域专家进行沟通的方法 （5）提供了一种测试系统的方法 事件流是用例完成需求行为的事件描述，其目的是建立用例中逻辑流程的文档，详细描述系统用户的工作和系统本身的工作，既包括正常状态下系统完成需求行为的事件，也包括在其他状态下不能完成需求行为的事件。事件流通常包括： （1） 简要说明 （2） 前置条件 （3） 事件流 （4） 后置条件 关系反应了参与者和用例之间、用例和用例之间以及参与者和参与者之间的相互作用。在一个用例图中，可能会出现关联关系、依赖关系、泛化关系以及这三种关系的扩展形式：扩展关系、包含关系和精化关系。 关联关系表示一种通信路径，它存在于参与者和用例之间，提供用例和参与者之间的通信途径。建立通信之后，信息可以双向流动。关系方向显示的不是信息的流动方向，而是谁启动信息。在 Rational Rose Enterprise 中，关联关系采用一条直线或者一条带箭头的直线表示。 依赖关系是存在于两个模型要素之间的一种关系，其中一个模型要素的改变将影响另一个模型要素。在 Rational Rose Enterprise 中，依赖关系表示为一个带箭头的虚线。 泛化关系是在一个更一般的模型要素和另一个较具体的模型要素之间存在的一种关系，通常用于表示类（包括用例、参与者等）之间的继承关系。在 Rational Rose Enterprise 中，泛化关系表示为一条带空心三角形