第六周UML用例图.pptVIP

第四章 UML用例图（Use case diagram） 任课老师：黄武 提纲 用例概述 用例图的组成 执行者（Actor） 执行者和用例之间的关系 用例之间的关系 用例模型的获取方法 UML语境建模技术 UML需求建模技术 用例图举例 1. 用例概述 用例是由Ivar Jacobson在开发AXE系统中首先使用，然后加入到OOSE设计中的，以后被广泛采用，被认为是第二代面向对象技术的标志 用例是外部可见的系统功能部分，也就是外部执行者（Actor）所能理解的系统功能，比如在网上预定机票或酒店等 用例是开发者理解用户需求的有利武器 1.1 用例的作用 用例图用于对系统、子系统或类的行为的可视化，以便使系统的用户更容易理解这些元素的用途 用例通过捕获用户的可见需求，实现一个具体的用户目标 用例将系统看做黑盒，从外部执行者的角度来理解系统，便于简化用户需求 用例驱动了分析之后各个阶段的工作，比如验证和测试 2 用例图的组成 用例图是用来描述用例的，通常由6个部分组成 执行者（Actor） 用例（Use Case） 关联关系（Association） 包含关系（Include） 扩展关系（Extend） 泛化关系（Generalization） 2.1 用例的表示 在UML语言中，用例用一个椭圆表示，并且每个用例必须有一个名字，用例的名字之间不能重合 用例的名字包括简单名和路径名，路径名是在用例名前加上的所属包的名字 3 执行者（Actor） 执行者（Actor）是系统外部的一个实体，它以某种方式参与用例的执行 我们按照角色来区分执行者，每个执行者可以参与一个或多个用例，它通过交换信息与用例发生交互 在UML语言中，执行者通常使用人形图标表示 3.1 执行者分类 执行者可以分为三类： 操作系统的用户 与该系统建立联系的外部系统，比如，网上商城的信用卡验证系统，股票交易系统的远程数据更新系统等 系统内运行的进程，比如定时器 从执行者的分类可以看出，凡是能够驱动系统产生动作的内外条件均可以看做是执行者 3.2 理解执行者的注意事项 执行者对于系统而言总是外部的，因此在系统的控制之外 执行者直接同系统交互，可以帮助定义系统的边界 执行者表示人和事物与系统发生交互时扮演的角色，而不是特定的人或事物 每一个执行者应该有一个与角色相一致的名字 每个执行者必须有简短的描述 执行者与系统发生交互时，可以扮演多个角色 3.3 执行者之间的关系 在UML中，执行者是类，因此，多个执行者之间的关系是类与类之间的关系，比如泛化关系。 3.4 执行者和用例之间的关联关系 关联关系描述执行者和用例之间的关系，表示执行者与用例之间进行通信 关联关系使用箭头表示 4 用例之间的关系 用例除了与执行者之间直接相关之外，还可以与其他用例之间存在关系，这些关系包括： 包含关系（使用关系） 泛化关系 扩展关系等 4.1 包含关系（使用关系） 一个用例可以使用其它用例具有的行为，并把它所包含的用例行为作为自身的一部分，叫做包含关系 比如，我们进行成绩查询，学分查询的操作之前均需要登陆学籍管理系统 4.2 泛化关系 一个用例可以被特别列举为一个或多个子用例，并称为用例泛化，比如，取款可以泛化为远程取款和柜台取款 4.3 扩展关系 扩展关系是一个用例被定义为基础用例的增量扩展，这样通过扩展关系，就可以把新的行为插入到已有用例中 基础用例提供了一组扩展点，扩展点与一个类的接口相似，我们可以写这个接口的实现（扩展用例），也可以不写（基础用例） 4.4 用例三种关系之间的差异 包含关系是调用关系，两个用例之间可以不存在逻辑关系，比如我们建立一个数学函数库，提供sin，cos等函数被使用，这些函数与使用者之间没有直接的逻辑关系 泛化关系用例之间存在着内在的逻辑关系，子用例可以代替父用例 扩展关系属于一种特殊的泛化关系，实际上是增加接口，是一种抽象类的泛化关系 5 用例模型的获取 首先通过下面的问题识别执行者： 系统主要功能的使用者是谁？ 系统所服务的对象及要完成的工作？ 系统的维护、管理人员是谁？ 系统所需要的硬件设备有哪些？ 与该系统交互的其他系统有哪些？ 对本系统产生结果感兴趣的人或系统是谁？ 5 用例模型的获取 然后通过下面的问题识别用例： 特定执行者希望系统提供什么功能 当系统改变状态时，是否通知执行者 是否存在影响系统的外部事件 哪个执行者通知系统这些事件 系统是否存储、检索信息？如果需要，由哪些执行者出发 5.1 用例与事件流 事件流的功能是为了用例的逻辑流程建立文档，这个文档详细描述了系统参与者的工作和系统本身的工作；事件流是对用例的详细描述 事件流包括： 简要说明：描述用例的作用 前提条件：描述用例开始必须满足的条件 主事件流和其他事件流 事后条件：描述