第5章-UML用例图要点
合集下载
软件体系结构课件第5章统一建模语言
2:GetPrefSet()
10:PrefSet(date_mg)
1:GetPrefSet()
:MeetingInitiator
第5章 统一建模语言 直接使用UML建模 – 会议安排系统的类图
Person
StronglyConflicts With
Conflicts With
Important Attendee
0..* 0..*
0..* Profers
Attendee
1..* 1..* 0..* 0..*
11 1 1
1
Meeting Initiator
Find.exe
Query .dll
部署图 定义系 统中软 硬件的 物理体
系结构
第5章 统一建模语言 部署图
客户端:个人PC QueryClient.exe
服务器
《TCP/IP》 查询
QueryServer.exe 部署图
定义系
统中软
Find.exe
硬件的
物理体
Query.dll系结构
第5章 统一建模语言
第5章 统一建模语言
直接使用UML建模 – UML中的通用表示
➢ 字符串：表示有关模型的信息； ➢ 名字：表示模型元素； ➢ 标号：不同于编程语言中的标号，是用于表示或说明图形符号的字
符串； ➢ 特殊字符串：表示某一模型元素的特性； ➢ 类型表达式：声明属性、变量及参数，含义同编程语言中的类型表
0
10
20
30s 时间刻度
第5章 统一建模语言 状态图
提交订单 已审核 印前处理
客户付钱
已付款
已处理
进行冲印
冲印中 冲印完成
描述满足 用例要求 所要进行 的活动以 及活动间 的完约成束关 系，有利 于识别并 行活动
第5章-UML用例图
• 用例图清楚地描述了使用者及它们之间的泛化关系，用例及用例 之间的泛化、扩展关系，用例和参与者之间的关联关系，可从用 例图中得到对于被定义系统的一个总体印象。
5.2 UML包含的内容
5.2.3 用例图
用例图主要包括3个部分： 用例（User Case） 参与者（Actor） 关系
AssociationName UseCaseName
5.2 UML包含的内容
5.2.3 用例图-用例
用例描述
对用例的描述，可以使用自然语言，活动图和伪代码，也可以使 用用户自己定义的语言。无论用什么形式，所描述的动作序列应该 足够清晰，是其他人员易于理解。
在用例中只需要描述参与者和系统彼此对对方做了那些事，不需 要描述怎么做。
最简单的用例描述，至少会包含一条“基本流程（basic course）” ，用来描述正常的使用。
5.2.3 用例图-用例
用例描述
用例图只能告诉我们系统应具有的功能及参与者，让用户对系统 有一个总体的认识。而没有说明用例的执行过程。
因此，对于每一个用例，我们还需要有详细的描述信息，以便让 别人对于整个系统有一个更加详细的了解。
UML是一套标准的图形语言，其中只提出了13种图，没有将用例 描述考虑在内，也当然没有任何标准的用例描述格式了。
5.2 UML包含的内容
5.2.3 用例图-参与者
如何确定参与者？
（1）使用系统主要功能的人是谁（即主要角色）？ （2）需要借助于系统完成日常工作的人是谁？ （3）谁来维护和管理系统（次要角色），保证系统正常工作？ （4）系统控制的硬件设备有哪些？ （5）系统需要与哪些其它系统交互？其它系统包括计算机系统，也包 括该系统将要使用的计算机中的其它应用软件。其它系统也分成二类， 一类是启动该系统的系统，另一类是该系统要使用的系统。 （6）对系统产生的结果感兴趣的人或事是哪些？
5.2 UML包含的内容
5.2.3 用例图
用例图主要包括3个部分： 用例（User Case） 参与者（Actor） 关系
AssociationName UseCaseName
5.2 UML包含的内容
5.2.3 用例图-用例
用例描述
对用例的描述，可以使用自然语言，活动图和伪代码，也可以使 用用户自己定义的语言。无论用什么形式，所描述的动作序列应该 足够清晰，是其他人员易于理解。
在用例中只需要描述参与者和系统彼此对对方做了那些事，不需 要描述怎么做。
最简单的用例描述，至少会包含一条“基本流程（basic course）” ，用来描述正常的使用。
5.2.3 用例图-用例
用例描述
用例图只能告诉我们系统应具有的功能及参与者，让用户对系统 有一个总体的认识。而没有说明用例的执行过程。
因此，对于每一个用例，我们还需要有详细的描述信息，以便让 别人对于整个系统有一个更加详细的了解。
UML是一套标准的图形语言，其中只提出了13种图，没有将用例 描述考虑在内，也当然没有任何标准的用例描述格式了。
5.2 UML包含的内容
5.2.3 用例图-参与者
如何确定参与者？
（1）使用系统主要功能的人是谁（即主要角色）？ （2）需要借助于系统完成日常工作的人是谁？ （3）谁来维护和管理系统（次要角色），保证系统正常工作？ （4）系统控制的硬件设备有哪些？ （5）系统需要与哪些其它系统交互？其它系统包括计算机系统，也包 括该系统将要使用的计算机中的其它应用软件。其它系统也分成二类， 一类是启动该系统的系统，另一类是该系统要使用的系统。 （6）对系统产生的结果感兴趣的人或事是哪些？
uml
都会成为CRUD
光CRUD能为 actor提供价值吗？
识别用例
——用例的“粒度”
一个用例背后可能隐藏着许多数据操作
识别用例
——用例的“粒度”：如果确实是纯 CRUD
如果CRUD不涉及复杂的交互，一个用例“管
理××”即可 不管是C、R、U、D，都是为了完成“管理” 的目标 甚至很多种基本数据的管理都可以用一个用例 表示
系统外部的一个实体。 参与用例的执行过程。 通过向系统输入或请求系统输入某些事
件来触发系统的执行。 由参与用例时所担当的角色来表示。 每个参与者可以参与一个或多个用例。
5.1.2 参与者
参与者的种类：
系统用户 与所建造的系统交互的其他系统
一些可以运行的进程
确定参与者
确定参与者
对参与者建模的过程中需要注意的问题
参与者对于系统而言总是外部的 参与者可以直接或间接的同系统交互
一个人或事物在与系统交互时，可以扮演多个
角色 每一个参与者必须有简短的描述
参与者间的关系
参与者(actor)之间可 以存在泛化关系，表示 一个一般性的参与者与 另一个更为特殊的参与 者之间的联系。 参与者间的泛化关系 示例：
如何寻找系统的参与者
谁使用系统的主要功能？ 谁改变系统的数据 谁从系统获取信息 谁需要系统的支持以完成日常工作任务？ 谁负责维护、管理并保持系统正常运行？ 系统需要应付（处理）哪些硬设备？ 系统需要和哪些外部系统交互？ 谁（或什么）对系统运行产生的结果感兴趣？ 有没有自动发生的事件
主事件流
备选事件流
1a.非法用户：提示用户名或密码错误； 5b.学生的实验结果文件夹未按要求命名，不是以学期和学号两部分组成 ：系统提示文件夹命名错误； 5b.学生所提交的实验结果文件夹是空：系统提示文件夹为空； 6c.在上传实验结果的过程中突然中断：系统要求学生重新上传实验结果 ； 6c.学生误传了实验结果，把其他课程的实验提交到该实验课，可以进行 删除操作，重新上传，重复3～7的操作； 6c.学生未按时提交实验结果：系统提示已过期；
UML 用例图的基本概念
系统名称 参与者
用例
UML建模语言
5.2.3 用例 1. 用例的概念 用例（Use Case）是参与者（角色）可以感 受到的系统服务或功能单元。
带路径名的用例
UML建模语言
2. 用例的识别
任何用例都不能在缺少参与者的情况下独 立存在。同样，任何参与者也必须要有与 之关联的用例，所以识别用例的最好方法 就是从分析系统参与者开始，在这个过程 中往往会发现新的参与者。
细化后 的学生 管理系 统
UML建模语言
4. 用例规约
用例图只是在总体上大致描述了系统所提 供的各种服务，让用户对系统有一个总体 的认识。但对于每一个用例还需要有详细 的描述信息，以便让其他人对于整个系统 有一个更加详细地了解，这些信息包含在 用例规约之中。而用例模型指的也不仅仅 是用例图，而是由用例图和每一个用例的 详细描述——用例规约所组成的。
1. 参与者的概念 2. 参与者的确定 3. 参与者间的关系
UML建模语言
1.参与者的概念
参与者（Actor）是指存在于 系统外部并直接与系统进行交 互的人、系统、子系统或类的 外部实体的抽象。
UML建模语言
2. 参与者的确定
在获取用例前首先要确定系统的参与者，寻找参与者可 以从以下问题入手： .系统开发出来后，使用系统主要功能的是谁？ .谁需要借助系统来完成日常的工作？ .系统需要从哪些人或其他系统中获得数据？ .系统会为哪些人或其他系统提供数据？ .系统会与哪些其他系统交互？其他系统可以分为两类， 一类是该系统要使用的系统，二是启动该系统的系统， 包括计算机系统和计算机中的其他应用软件。 .系统是由谁来维护和管理的，以保证系统处于工作状 态？ .系统控制的硬件设备有哪些？ .谁对本系统产生的结果感兴趣？
用例
UML建模语言
5.2.3 用例 1. 用例的概念 用例（Use Case）是参与者（角色）可以感 受到的系统服务或功能单元。
带路径名的用例
UML建模语言
2. 用例的识别
任何用例都不能在缺少参与者的情况下独 立存在。同样，任何参与者也必须要有与 之关联的用例，所以识别用例的最好方法 就是从分析系统参与者开始，在这个过程 中往往会发现新的参与者。
细化后 的学生 管理系 统
UML建模语言
4. 用例规约
用例图只是在总体上大致描述了系统所提 供的各种服务，让用户对系统有一个总体 的认识。但对于每一个用例还需要有详细 的描述信息，以便让其他人对于整个系统 有一个更加详细地了解，这些信息包含在 用例规约之中。而用例模型指的也不仅仅 是用例图，而是由用例图和每一个用例的 详细描述——用例规约所组成的。
1. 参与者的概念 2. 参与者的确定 3. 参与者间的关系
UML建模语言
1.参与者的概念
参与者（Actor）是指存在于 系统外部并直接与系统进行交 互的人、系统、子系统或类的 外部实体的抽象。
UML建模语言
2. 参与者的确定
在获取用例前首先要确定系统的参与者，寻找参与者可 以从以下问题入手： .系统开发出来后，使用系统主要功能的是谁？ .谁需要借助系统来完成日常的工作？ .系统需要从哪些人或其他系统中获得数据？ .系统会为哪些人或其他系统提供数据？ .系统会与哪些其他系统交互？其他系统可以分为两类， 一类是该系统要使用的系统，二是启动该系统的系统， 包括计算机系统和计算机中的其他应用软件。 .系统是由谁来维护和管理的，以保证系统处于工作状 态？ .系统控制的硬件设备有哪些？ .谁对本系统产生的结果感兴趣？
软件工程 第5章--UML
10
UML的定义
UML定义有两个主要组成部分：语义和表示法。 语义用自然语言描述，表示法定义了UML的可 视化标准表示符号，这决定了UML是一种可视 化的建模语言。 在语义上，模型是元模型的实例。UML定义给 出了语法结构的精确定义。 使用UML时，要从不同的角度观察系统，为此 定义了概念“视图(View)‖。视图是对系统的模 型在某方面的投影，注重于系统的某个方面。
独立于过程
系统建模语言，独立于开发过程。
9
容易掌握使用 概念明确，建模表示法简洁明了，图形结 构清晰，容易掌握使用。 着重学习三个方面的主要内容： (1) UML的基本模型元素 (2) 组织模型元素的规则 (3) UML语言的公共机制 与程序设计语言的关系 用Java，C++ 等编程语言可实现一个系统。 一些CASE工具可以根据 UML所建立的系 统模型来产生Java、C++ 等代码框架。
31
UML事物 — 注释事物
11) Note（注释）
依附于一个元素或一组元素之上，对其进
行约束或解释的简单符号。没有语义影响。
See policy8-5-96.doc for details about these algorithms.
CashAccount presentValue()
32
15
UML定义 9 种图，表达UML中的 5 种视图，各 视图在静态和动态方面表示系统模型。
结构 视图 静态 方面
动态 方面
行为 视图 同左
实现 视图 构件图
环境 视图 部署图
同左
用例 视图 用例图
同左
类图 对象图
顺序图 同左 顺序图 合作图 (注重 合作图 状态图 进程、 状态图 活动图 线程) 活动图
UML的定义
UML定义有两个主要组成部分：语义和表示法。 语义用自然语言描述，表示法定义了UML的可 视化标准表示符号，这决定了UML是一种可视 化的建模语言。 在语义上，模型是元模型的实例。UML定义给 出了语法结构的精确定义。 使用UML时，要从不同的角度观察系统，为此 定义了概念“视图(View)‖。视图是对系统的模 型在某方面的投影，注重于系统的某个方面。
独立于过程
系统建模语言，独立于开发过程。
9
容易掌握使用 概念明确，建模表示法简洁明了，图形结 构清晰，容易掌握使用。 着重学习三个方面的主要内容： (1) UML的基本模型元素 (2) 组织模型元素的规则 (3) UML语言的公共机制 与程序设计语言的关系 用Java，C++ 等编程语言可实现一个系统。 一些CASE工具可以根据 UML所建立的系 统模型来产生Java、C++ 等代码框架。
31
UML事物 — 注释事物
11) Note（注释）
依附于一个元素或一组元素之上，对其进
行约束或解释的简单符号。没有语义影响。
See policy8-5-96.doc for details about these algorithms.
CashAccount presentValue()
32
15
UML定义 9 种图，表达UML中的 5 种视图，各 视图在静态和动态方面表示系统模型。
结构 视图 静态 方面
动态 方面
行为 视图 同左
实现 视图 构件图
环境 视图 部署图
同左
用例 视图 用例图
同左
类图 对象图
顺序图 同左 顺序图 合作图 (注重 合作图 状态图 进程、 状态图 活动图 线程) 活动图
第05章 类图及对象图
26
实体类通过事件流和交互图发现, 实体类通过事件流和交互图发现, 采用目 事件流和交互图发现 标领域术语命名. 标领域术语命名. 通常实体类对应数据库中的表, 属性对 通常实体类对应数据库中的表, 其属性对 应表的字段 字段, 应表的字段, 但实体类与数据库中的表不一定 是一一对应关系. 是一一对应关系.
23
借书处理类图
24
通过用例图可以确定需要的边界类, 每个Actor/User 通过用例图可以确定需要的边界类, 每个Actor/User case对至少需要一个边界类 对至少需要一个边界类. case对至少需要一个边界类.
但并不是每个 case都需 Actor/Use case都需 要生成惟一边界类, 要生成惟一边界类, 多个actor actor启动同一 多个actor启动同一 case可以使用同 use case可以使用同 一边界类. 一边界类.
初始值][{特性}] [可见性]属性名[:类型][‘[ ’多重性[次序]‘]’][=初始值][{特性}] 可见性]属性名[:类型][ 多重性[次序] ][=初始值][{特性 [:类型
该属性对外部实体的显现程度. 该属性对外部实体的显现程度. 可见public : + 可见public 受限protected: 受限protected: # 私有private 私有private : -
13
？
问题： 问题：
1、指出下面属性名的含义。 、指出下面属性名的含义。
+studentName:String=“李明” 李明” 李明 #studentBirthDay:Date=1999-10-21 -price:float=12.01{R/W}
14
5.1.3 类的操作
第5章 用例图
5.3 用例（Use Case）
描述用例 8.假设[可选]：假设描述的是系统在使用用例之前必须 满足的状态，这些条件并没有经过用例的检测，用 例只是假设它们为真。 9.基本操作流程：参与者在用例中所遵循的主要逻辑 路径。操作流程描述了用户和执行用例之间交互的 每一步。 10.可选操作流程：包括用例中很少使用的逻辑路径， 那些在变更工作方式、出现异常或发生错误的情况 下所遵循的路径。 11.修改历史记录[可选]：主要记录的是关于用例的修 改时间、修改原因和修改人的详细信息。
扩展关系也是一种依赖关系。 它指定了一个用例可以增强另一个用例的功 能，通过项基本用例添加动作来扩展该用例。 一个用例被定义为基本用例的增量扩展，这 称作扩展关系。 在扩展关系中，基本用例可以是独立的。在 一定条件下，基本用例的动作可由另外一个 用例扩展而来。基本用例提供了若干“扩展 点”，扩展用例只能在这些扩展点上增加一 个或多个新的动作。也就是说，扩展用例只 能发生在基本用例序列中的某个特定的点上。
用例的表示
在UML语言中，用例用一个椭圆来表示，并
且每个用例必须有一个名字。 在用例命名时用例的名字一般用字符串来表 示，可分为简单名和路径名。其中，路径名 引入了包的概念，在用例名前加上该用例所 属包的名字，两个名字之间用两个冒号分开。
AddBook
Libraian::LoanBook
5.3 用例（Use Case）
5.3 用例（Use Case）
描述用例 5.频率：记录参与者使用该用例的频率。 6.前置条件：前置条件以一个条件列表的形式进行记 录，用来描述执行用例之前系统所必须满足的条件。 这些条件必须在使用用例之前得到满足。前置条件 在使用之前，已经由用例进行过测试。如果条件不 满足，则用例不会被执行。 7.后置条件：后置条件将在用例成功完成以后得到满 足，它提供了系统的部分描述。即在前置条件满足 后，用例做了什么？以及用例结束时，系统处于什 么状态？
uml用例图
取款
查询
持有银行信 用卡的自动 取款机用户
转账
银行客户
图 ATM用例图
图 银行客户注释图
用例图的基本概念
5.1.2 用例图的作用
用例图是需求分析中的产物，主要作用是描述参与者和用例之间的关系， 用例图是需求分析中的产物，主要作用是描述参与者和用例之间的关系， 帮助开发人员可视化地了解系统的功能。减少了大量交流上的障碍， 帮助开发人员可视化地了解系统的功能。减少了大量交流上的障碍，便于 对问题达到共识。 对问题达到共识。
用例名
2.用例的识别
可以通过以下问题来寻找用例？ 参与者希望系统提供什么功能？ 参与者希望系统提供什么功能？ 参与者是否会读取、创建、修改、删除、存储系统的某种信息？ 参与者是否会读取、创建、修改、删除、存储系统的某种信息？如果 是的话，参与者又是如何完成这些操作的？ 是的话，参与者又是如何完成这些操作的？ 参与者是否会将外部的某些事件通知给系统？ 参与者是否会将外部的某些事件通知给系统？ 系统中发生的事件是否通知参与者？ 系统中发生的事件是否通知参与者？ 是否存在影响系统的外部事件？ 是否存在影响系统的外部事件？
基础用例
扩展用例
《 extend》
扩展关系
3.泛化
用例的泛化指的是一个父用例可以被特化形成多个子用例，而父用例和子用例之间的 关系就是泛化关系。在UML中，用例的泛化关系通过一个从子用例指向父用例的三角箭头 来表示：
父用例
子用例
泛化关系
5.3 用例图的创建概述
5.3.1 5.3.2 5.3.3 5.3.4 创建用例图 创建参与者 创建用例 创建用例之间的关联
课程回顾
用例图的基本概念 用例图的组成 用例图的创建概述 用例图的创建示例
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
备注 UML 1原有
UML 1非正式图 UML 2.0新增 UML 1原有 UML 1原有 UML中非正式图 UML 1原有 UML 1原有 UML 1原有 UML 1原有 UML 1中的协作图
复合结构图 描述类的运行时刻的分解
定时图
描述对象之间的交互，重点在于定时
UML 2.0 新增
UML 2.0新增
5.2.3 用例图-参与者
如何确定参与者？
（1）使用系统主要功能的人是谁（即主要角色）？ （2）需要借助于系统完成日常工作的人是谁？ （3）谁来维护和管理系统（次要角色），保证系统正常工作？
（4）系统控制的硬件设备有哪些？
（5）系统需要与哪些其它系统交互？其它系统包括计算机系统，也包 括该系统将要使用的计算机中的其它应用软件。其它系统也分成二类， 一类是启动该系统的系统，另一类是该系统要使用的系统。 （6）对系统产生的结果感兴趣的人或事是哪些？
5.2.3 用例图-参与者
参与者（Actor）是指存在于系统外部并直接与系统进行交互的 人、系统、子系统或类的外部实体的抽象。 每个参与者可以参与一个或多个用例，每个用例也可以有一个或 多个参与者。 注意：参与者可以是人，也可以是外部系统或其它设备。
5.2 UML包含的内容
5.2.3 用例图 -参与者 5.2.1 参与者
• 用例图可视化地表达了系统的需求，具有直观、规范来自优点，克 服了纯文字性说明的不足。
5.2 UML包含的内容
5.2.3 用例图 2. 用例图的作用
用例图的作用
• 用例方法是完全从外部来定义系统功能，它把需求和设计完全的 分离开来。我们不用关心系统内部是如何完成各种功能的，系统 对于我们来说就是一个黑箱子。 • 用例图清楚地描述了使用者及它们之间的泛化关系，用例及用例 之间的泛化、扩展关系，用例和参与者之间的关联关系，可从用 例图中得到对于被定义系统的一个总体印象。
5.2 UML包含的内容
5.2.3 用例图
类图 类(class) 关联(association) 系统的内观(里子) 静态结构 稳定成长 用例图 用例(use case)、参与者(actor) 包含(include)、扩展(extend) 系统的外观(面子) 动态功能 变化迅速
类图与用例图
5.2 UML包含的内容
• 要在用例图上绘制一个参与者（表示一个系统用户）， 可绘制一个人形符号。
5.2 UML包含的内容
5.2.3 用例图
• 参与者和用例之间的关系使用带箭头或者不带箭头的线段来描述，箭 头表示在这一关系中哪一方是对话的主动发起者，箭头所指方是对话 的被动接受者。如果不想强调对话中的主动与被动关系，可以使用不 带箭头的线段。
• 注意：包、注释都不是用例图的基本组成要素，但在 用例建模过程中可能会用到它们。
5.2 UML包含的内容
5.2.3 用例图
用例图的作用
• 用例图是需求分析中的产物，主要作用是描述参与者和用例之间 的关系，帮助开发人员可视化的了解系统的功能。
• 借助于用例图，系统用户、系统分析人员、系统设计人员、领域 专家能够以可视化的方式对问题进行探讨，减少了大量交流上的 障碍，便于对问题达成共识。
5.2 UML包含的内容
5.2.3 用例图
用例图主要包括3个部分：
用例（User Case） 参与者（Actor） 关系
AssociationName UseCaseName
ActorName (From Use Case View) (From Use Case View)
5.2 UML包含的内容
5.2 UML包含的内容
5.2.3 用例图
• 进行用例建模时，所需要的用例图数量是根据系统的复杂度来衡 量的。
• 对于较复杂的大中型系统，可能会需要几张甚至几十张用例图， 可以使用包来对其进行有效管理。
5.2 UML包含的内容
5.2.3 用例图
• 在用例建模中，为了更加清楚的描述用例或者参与者， 会使用到注释。
交互概观图 是一种顺序图与活动图的混合
5.2 UML包含的内容
5.2.3 用例图
用例图主要用于为系统的功能需求建模，它主要描述系统功能， 也就是从外部用户的角度观察，系统应该完成哪些功能。
用例图可以帮助开发人员以一种可视化的方式理解系统的功能 需求，是后续的系统分析与设计工作的依据。 用例图是对系统功能的一个宏观描述，画好用例图是由软件需 求到最终实现的第一步，也是最重要的一步。
信息系统分析、设计与开发方法
第5章 功能强大的对象建模 工具——UML
用例图
5.2 UML包含的内容
5.2.3 用例图
UML有三个基本构造块：事物、关系和图。
通过关系把多个事物连接在一起，构成了图。 其中，图可视化地描绘了系统某一方面的特征。一个图只能反映系 统中某个侧面和特征，多个图结合在一起可以反映系统的某些侧面 和多个特征。 在UML 2.0中共定义了13种图，比UML 1.0新增了3种。
UML2.0的图型
图名 类图
对象图 组件图 部署图 包图 用例图 活动图 状态机图 顺序图 通信图
功能 描述类、类的特性以及类之间的关系
描述一个时间点上系统中各个对象的一个快照 描述组件的结构与连接 描述在各个节点上的部署 描述编译时的层次结构 描述用户与系统如何交互 描述过程行为与并行行为 描述事件如何改变对象生命周期 描述对象之间的交互，重点在强调顺序 描述对象之间的交互，重点在于连接
5.2.3 用例图 • 由参与者（Actor）、用例（Use Case）以及 它们之间的关系构成的用于描述系统功能的动 态视图称为用例图。
• 用例和参与者之间的对应关系叫做通信关联， 它表示参与者使用了系统中的哪些用例。
5.2 UML包含的内容
5.2.3 用例图
• 要在用例图上显示某个用例，可绘制一个椭圆，然后 将用例的名称放在椭圆的中心或椭圆下面的中间位置。
• 参与者有三大类：
– 第一类参与者是真实的人，即用户，是最常见的参与者，几 乎存在于每一个系统中。
– 第二类参与者是其他的系统。这类位于程序边界之外的系统 也是参与者。
– 第三类参与者是一些可以运行的进程。如时间，当经过一定 的时间触发系统中的某个事件时，时间就成了参与者。
5.2 UML包含的内容