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