概述
定义
由参与者、用例以及它们之间的关系构成的用于描述系统功能的图。
它描述了系统中相关的用户和系统对不同用户提供的功能和服务。
在用例图的四种组成元素中，( 用例 )用于体现系统为外部用户所提供的功能和服务。
注意
一个系统可以有多个用例图
用例图用于需求阶段
组成要素：
参与者(Actor)
• 位于系统外部
使用系统或与系统交互中所扮演的角色
用例(Use Case)
• 位于系统内部
系统提供给参与者的功能
关系(Relationship)
表示参与者如何使用功能
主题(subject)
指要建模的系统，包括主题边界(boundary)和主题名称两部分。
如何界定系统外部和内部?
系统边界(Boundary)表示正在建模系统的边界
边界内表示系统的组成部分
边界外表示系统外部
边界内是用例，边界外是参与者
图形表示
参与者用小人表示，用例用椭圆表示，系统边界用矩形框
如下图：
作用
便于用户和开发人员消除歧义,达成共识。
用例图被广泛应用于系统的需求建模阶段，并在系统的整个生命周期中被不断细化。
从用户的视角，描述整个系统，分析系统的功能与行为；
描述参与者和用例之间的关系；
直观规范，方便客户和系统设计者之间的交流；
从外部定义系统功能，将需求与设计完全分离开来（不关心系统内部如何完成）；
强调从最终用户的角度来理解软件系统的需求。
参与者
确定参与者，是构建用例图的首要任务，第一个要确定参与者。
概念
参与者(Actor)是指存在于系统外部并直接与系统进行交互的外部实体的抽象。
参与者描述了一组与系统交互的外部用户或外部事物。（如：普通用户、管理员、外部设备、其他系统、子系统）
注意事项
参与者位于系统外部，不是系统的一部分。
参与者不是具体的人或事物，而是外部对象相对于系统而言所扮演的角色。
参与者包括所有与系统进行交互的外部实体。
直接且主动的向系统发出动作并获得反馈
表示方法
图标形式 的人形符号
标签形式 的< 装饰形式的带装饰的类符号 一般用人形符号来表示人，用< 分类及确认 按参与者性质划分： 人： 客户，读者，学生…… 设备： 计算机，扫码器，读卡机，打印机…… 外部系统： 上层系统，第三方系统(如银联系统) … 时钟： 定时触发 按参与者重要性划分： 主要参与者：执行系统主要功能的参与者，是系统的重要服务对象； 次要参与者：执行系统次要功能的参与者，通常处于一种协作地位。 确定参与者 确定参与者，是构建用例图的首要任务，可以从以下几个角度来考虑： 为系统提供输入的人或设备（例如，扫码器） 接收系统输出的人或设备（例如，打码器） 需要接入的第三方系统或设备（例如，银联系统） 时间是否会自动触发某些事件（例如， 系统时钟） 负责支持或维护系统中信息的人（例如， 系统维护员） 参与者间的关系 泛化关系(Generalization) 描述了参与者之间特殊与一般的关系 泛化关系的UML表示方法 用例 概念 用例(Use Case)是参与者可以感受到的一个系统服务或功能单元，表示参与者与系统的一次交互过程。 也就是说：用例是对一组动作序列的描述, 系统执行这些动作序列来为参与者产生一个可观察的结果值。 注意事项 用例位于系统的内部 用例是对一组动作序列的描述。 表示： 包含名称的椭圆形，其中的名称可以显示在椭圆下方或椭圆内部。 确定用例 可以通过以下问题来寻找用例： 参与者的主要任务是什么？(希望系统提供什么功能) 参与者需要系统的什么信息？(是否会读取、创建、删除、修改、存储系统的某种信息) 参与者是否需要通知系统外部发生的变化和事件？ 系统是否需要通知参与者系统中发生的变化和事件？ 特征 用例位于系统内部 用例是动宾短语 用例表达的是一个交互序列，需要使用一个动词词组或动宾短语来表达。 例如：登录系统、选课、取款、查看成绩…… 用例表达的是一次完整的人机交互序列。 用例是相对独立的 用例对于参与者来说，在“功能” 上是完整的，不需要与其他用例交互而独自完成某功能。 注意： 区分开用例与用例执行过程中的步骤! 用例的执行结果对参与者来说是可观测且有意义的 用例描述参与者与系统之间的交互行为, 而非内在系统活动 用例为业务功能，不是处理过程 用例是由参与者启动的 用例是参与者请求或触发的一系列行为，不存在没有参与者的用例。 用例不应自动启动，也不应主动启动另一个用例。 参与者与用例的关系**** 关联关系(Association) • 用于为参与者与用例建立连接 关联关系的UML表示方法 用例粒度 基本概念 用例的粒度就是对功能的细化和综合程度，指的是用例所包含的系统服务或功能单元的多少。 注意事项 一个用例图中，所有用例必须是同一粒度。 分类 用例的粒度分为三个层次，不同层次用于不同阶段，没有好坏之分。 用例的细化程度越低，粒度就越大，所包含的功能就越多；用例的细化程度越高，粒度就越小，所包含的功能就越少。 概述级 用来描述商业目标，用于初期的需求讨论。 用户目标级 是对概述级用例的进一步细化，用来描述参与者完成工作或使用系统的目的。 子功能级 子功能级用例是对目标级用例的进一步细化。 注意 用例是系统级的、抽象的描述，不是细化的(考虑的是“做什么what”，而不是“怎样做how”)。哪怕是子功能级的用例 确定模型使用的粒度 因地制宜：一般系统用例10-50个为宜。根据项目复杂程度不同，使用不同的粒度。 对复杂的系统可以划分为若干子系统处理。 因时制宜：在项目过程中根据阶段不同，使用不同的粒度。 在同一需求阶段，所有用例的粒度应该是在同一个量级上的。 在业务建模阶段，用例的粒度以每个用例描述一个完整的事情为宜。 在概念建模阶段，用例的粒度以每个用例能描述一个完整的事件流为宜。 在系统建模阶段，用例的粒度以一个用例能够描述参与者与计算机的一次完整交互为宜。 关系 用例图中的关系，描述了参与者如何使用系统的功能或服务。 分类 参与者之间，存在泛化关系。 参与者和用例之间，存在关联关系。 用例之间，存在依赖(包含、扩展)和泛化关系。 依赖关系 包含(Inclusion) 依赖 包含关系(Include) 是指一个用例 （称为基础用例） 可以简单的包含其他用具有的行为（称为被包含用例）。 表现形式： 被包含用例的事件流可插入至基础用例的事件流中。 UML表示方法 通过带箭头的虚线段加< 应用场景 多个用例使用同一段必需行为 某一用例功能过多，事件流过于复杂 扩展(Extension)依赖 扩展关系(Extend)是指一个用例（称为扩展用例）扩充了另一个用例（称为基础用例）的功能。 特点 扩充功能不是必需的；只有在满足特定条件的情况下才会被执行。 UML表示方法 通过带箭头的虚线段加< 应用场景 用例使用到一段用于增强自身功能的可选行为 两者比较 相同点 从现有用例的事件流中抽取,并用于增强现有用例。 区别: 新用例是否一定被执行 扩展用例描述的是基础用例的可选行为 被包含用例描述的是基础用例的必然行为 基础用例脱离于新用例是否完整 扩展关系中,即使没有扩展用例,基础用例也是完整的 新用例能否脱离于基础用例而独立存在 扩展关系中,扩展用例必须依赖于基础用例 关联关系 表示参与者与用例间 的关系,用于为两者建立连接。 UML表示方法 一般使用带箭头的实线表示。 如果箭头指向用例，则表明参与者启动用例，即用例的主要参与者； 如果没有箭头或箭头指向参与者，则表示用例跟参与者之间有交互，即用例的次要参与者。 Rose中用Unidirectional Association表示单向关联。 注意事项 参与者和用例的消息传递是双向的 · 关联关系的箭头方向通常只代表了用例被参与者启动 参与者和用例之间是多对多的关联关系 一个用例和一个参与者之间最多只有一个关联关系 多个参与者实例参与一个用例实例的发起和执行,则参与者之间存在主次之分 关联关系只存在于参与者和用例之间 用例和用例间不存在关联关系 泛化关系 参与者之间 泛化关系描述了参与者之间特殊与一般的关系。 由于参与者实质上也是类，所以它拥有与类相同的关系描述。 UML表示方法 作用 可以有效减少用例图中关联关系的数量。 用例之间 描述了特化用例（子用例）与一般化用例（父用例）之间的关系 UML表示方法 应用场景 多个用例在行为、结构和目的方面存在共性 泛化关系与包含依赖的异同 泛化关系： 将多个子用例中的共性抽象成一个父用例；子用例之间是整体的相似，但相互独立。 包含关系： 将多个基础用例中的共性抽象为一个被包含用例；基础用例之间是部分的相似，基础用例的执行必然引起被包含用例的执行。 共同点： 复用多个用例的公共行为 区别 原有用例的相似程度 泛化关系中,多个子用例整体相似 包含关系中,多个基础用例部分相似 新用例是否一定被执行 泛化关系中,子用例被启动,父用例不一定被执行 包含关系中,基础用例被启动,被包含用例必然被执行 系统边界 主题(subject) 是指要建模的系统，包括主题边界(boundary)和主题名称两部分。 主题名称就是系统名称， 作用： 主题边界(系统边界) 用于界定系统的内部和外部；边界内表示系统的组成部分，边界外表示系统外部。 系统边界以外的、与系统相关联的其他部分，称之为系统环境。 注意 使用主题是为了强调用例包含在系统内部，而参与者则不包含在系统之中。 表示 主题边界(系统边界) 表示为一个大矩形框。 主题名称标记在矩形框内部，一般位于顶部。 用例规约 概述 用例模型是由用例图和用例规约组成的。 一个完整的用例模型应该不仅仅包括用例图部分，还要有完整的用例规约部分。 用例规约是对每一个用例的详细描述，也就是说有多少用例，就要有多少用例规约。 用例图和用例规约对比 用例图只是在总体上用图形大致描述系统功能，简单、直观 ，但是细节缺失、不明确。 用例规约则是一个用例的详细文字描述，采用自然语言，对用例的细节进行详细的描述。 包含内容 简要说明 用例名称 ，用例编号 ，参与者 ，用例简述 场景描述 触发器，前置条件 ，基本事件流 ，扩展事件流 ，结论 ，后置条件 其他事项 特殊需求， 扩展点 ，优先级 注意： 上面的用例规约中加粗的是 基本内容，没有加粗的是 可选内容 简要说明 用例名称： 描述用例的意图或实现的目标，要与用例图中的用例名保持一致 用例编号： 用例的唯一标识符，建议以UC(Use Case)作为前缀 参与者： 描述用例的参与者有哪些，包括主要参与者和次要参与者 用例简述： 简要介绍用例的作用和目的 实例 场景描述 事件流： 描述了在执行一个用例时，参与者与系统之间的一次交互过程；是对用例在使用场景下的交互动作的抽象。 用例场景是用例的实例，包括成功的场景和失败的场景两种情况。 一般通过基本事件流和扩展事件流的组合来对场景进行描述。 基本事件流与扩展事件流，是事件流的两个组成部分。 基本事件流： 用例正常执行的情况。（典型过程） 不涉及系统实现细节,不对界面设计提出要求 扩展事件流（备选流）： 用例执行过程中可能发生的异常或偶尔发生的情况。 （备选过程） 描述方式 事件流的循环： 当事件需要循环时，可以在需要循环的几个事件下 描述 。 格式：重复begin ~ end步，直到用户选择XXXX 注意：这个描述不需要编号 基本流编号：用 \(数字表示\) 用时间的发生时间先后顺序编号。 扩展流编号: 一般是 \(基本流编号+小写字母\) 小写字母表示第几个扩展流。 扩展流描述：如果... ，那么：返回步骤x 或者 给出提示并结束。 实例 事件流的描述要点 每一个步骤都需要进行编号； 对于流程较为复杂的用例，用简短的标题概括每一个步骤的主要内容； 建议采用双向描述法(参与者< >系统)，针对每一个步骤详细描述交互过程； 参与者和系统之间传递的交互信息，应尽可能的具体； 事件流的编写过程可以分阶段、迭代进行； 使用业务语言，不涉及系统实现细节，不对界面设计提出要求。 扩展事件流的描述要点 在描述扩展流时，为了提高完整性和可读性，建议包括以下几个方面的要素： 起点：扩展事件流从基本事件流的哪一个步骤开始，一般通过编号体现； 条件：在什么样的情况下会触发扩展流的执行； 动作：系统在扩展流下会采取哪些动作； 恢复：扩展流结束之后，用例应该如何继续执行。 【可选内容】 触发器： 触发用例执行的一个事件。 前置条件： 执行用例之前，系统必须所处的状态。 结论： 描述用例何时结束。 后置条件： 用例执行完毕后，系统可能处于的一组状态。 使用前置条件定义用例的起点，使用后置条件定义用例完成的目标。 一般来说前置条件只有一个，后置条件可能有很多（扩展事件流）。 其他事项 特殊需求： 用例实现时需要考虑的业务规则、设计约束（如开发工具、操作系统、兼容性）、非功能性需求（如法律法规、程序标准）等信息。 扩展点： 对当前用例的扩展，即对于基础用例，给出与之存在关系的其他用例的引用和描述。（指出包含用例或扩展用例） 优先级： 说明用户对该用例的期望值，可以为今后开发制定先后顺序。