第五章 用例图
合集下载
第5章 用例图
用例与事件流
• 用例分析处于系统的需求分析阶段，这个
阶段应该尽量避免考虑系统实现的细节问 题，这些细节问题写在事件流文件中。事 件流文件即用例的逻辑流程文档包括：
• 1. 简要说明：描述用例的作用； • 2. 前提条件：用例之前必须满足的条件；例：用户是否有运行权限 • 3. 事件流（主事件流、其他事件流、错误流 ）：描述参与者执行用
习题：
• 2、一台饮料自动售货机能提供6种不同的 、一台饮料自动售货机能提供6
饮料。售货机上有6 饮料。售货机上有6个按钮，分别对应于这 6中饮料，顾客可以通过按钮来选择所要的 饮料。每个按钮旁边有一个指示灯，用来 表明该售货机中是否还有这种饮料可售。 售货机有一个硬币槽的找零槽，用来收钱 和找钱。
① 处理书籍借阅 ② 处理书籍归还 ③ 删除预定信息
3. 系统管理员进行系统维护的用例
① 查询借阅者信息 ② 查询书籍信息 ③ 增加书目 ④ 删除或更新书目 ⑤ 增加书籍 ⑥ 删除书籍 ⑦ 添加借阅者帐户 ⑧ 删除或更新借阅者帐户
5.3.4 使用Rational Rose绘制用例图 使用Rational Rose绘制用例图 的步骤
扩展关系
• 扩展用例被定义为基础用例的增量扩展，这称作
扩展关系。
用例间的扩展关系
扩展关系例子
扩展关系指的是基础用例执行的情况下可选择是否执行提供者用例。
泛化关系
• 父用例也可以被特别列举为一个或多个子用例。 • 子用例从父用例处继承行为和属性，还可以添加
行为或覆盖、改变继承的行为。
用例间的泛化关系 泛化关系例子
例的具体步骤； • 4. 事后条件：用例执行完毕后必须为真的条件。例：用例完成之后 设置一个标志，这种信息就是事后条件。
第五章 用例图
用例间的关系——扩展关系(extend)
扩展关系允许一个用例（可选）扩展另一个用例的功能。 当某个新用例在原来的用例基础上增加了新的步骤序列，则原用例被称 作基用例，后者常称为扩展用例。这种关系被称为扩展关系。 扩展用例只有在基用例中的某种条件满足时才能执行，如果没有基用例 的运行，扩展用例不能运行。
由于参与者实质上也是类，所以它拥有与类相同的关系描述，即 参与者与参与者之间主要是泛化关系（或称为“继承”关系）。 泛化关系的含义是把某些参与者的共同行为提取出来表示成通用 行为，并描述成超类。泛化关系表示的是参与者之间的一般/特殊 关系，在UML图中，使用带空心三角箭头的实线表示泛化关系。
用例图的构成要素
用例 （Use Case）
•用例描述了系统的功能需求，是系统的一组动作序 列的描述.
•用例的本质是用户与计算机之间的一次交互作用。 在 UML 的概念中用例是系统作出的一系列动作 , 而 参与者能够察觉到这一系列动作的结果。 •UML 中用例用一个椭圆来表示，用例命名用动词 ，名字可以写在椭圆的内部或下方。
用例
如何判断一个用例是否是一个优秀的用例 呢？
①用例是否描述了应该做什么，而不是如何做？ ②用例的描述是否采取了参与者的视点？ ③用例是否对参与者有价值？ ④用例描述的时间流是否是一个完整场景？ ⑤是否所有的参与者、用例都有相应的关联用例 或关联参与者？
案例：零件销售系统
案例：零件销售系统的参与者
用例图-实例
实例2 用例之间扩展和包含关系 用例的上下文是：短途旅行 但汽车的油不足以应付全部路程 。那么为汽车加油的动作在旅行 的每个场景(事件流)中都会出现 ，不加油就不会完成旅行。吃饭 则可以由司机决定是否进行，不 吃饭不会影响旅行的完成。
chapter05 用例图
山东科技大学（泰山科技学院）信息工程系
安新军 sdkdaxj@
5.1 用例图的基本概念
功能分解方法的另一个缺点是这种方法分割了各项 系统功能的应用环境，从各项功能项入手，很难了 解到这些功能项是如何相互关联来实现一个完成的 系统服务的。 所以在传统的SRS文档中，需要另外一些章节来描 述系统的整体结构及各部分之间的相互关联，这些 内容使得SRS需求更象是一个设计文档。
山东科技大学（泰山科技学院）信息工程系
安新军 sdkdaxj@
5.2 用例图的组成
泛化关系：参与者之间可以有泛化(Generalization)关系 泛化关系：参与者之间可以有泛化 关系 或称为"继承 关系）。 继承"关系 （或称为 继承 关系）。
山东科技大学（泰山科技学院）信息工程系
山东科技大学（泰山科技学院）信息工程系
安新军 sdkdaxj@
5.2 用例图的组成
用例图的构成4要素： 用例图的构成 要素： 要素
• • • • 参与者 用例 系统边界 关联
山东科技大学（泰山科技学院）信息工程系
安新军 sdkdaxj@
5.2 用例图的组成
5.2.1 参与者 参与者(Actor)
山东科技大学（泰山科技学院）信息工程系
安新军 sdkdaxj@
5.2 用例图的组成
特殊的参与者――系统时钟 系统时钟 特殊的参与者 有时候需要在系统内部定时地执行一些操作，如检测系统资 源使用情况、定期地生成统计报表等等。从表面上看，这些 操作并不是由外部的人或系统触发的，应该怎样用用例方法 来表述这一类功能需求呢？对于这种情况，可以抽象出一个 系统时钟或定时器参与者，利用该参与者来触发这一类定时 操作。从逻辑上，这一参与者应该被理解成是系统外部的， 由它来触发系统所提供的用例对话。
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. 参与者的确定
在获取用例前首先要确定系统的参与者，寻找参与者可 以从以下问题入手： .系统开发出来后，使用系统主要功能的是谁？ .谁需要借助系统来完成日常的工作？ .系统需要从哪些人或其他系统中获得数据？ .系统会为哪些人或其他系统提供数据？ .系统会与哪些其他系统交互？其他系统可以分为两类， 一类是该系统要使用的系统，二是启动该系统的系统， 包括计算机系统和计算机中的其他应用软件。 .系统是由谁来维护和管理的，以保证系统处于工作状 态？ .系统控制的硬件设备有哪些？ .谁对本系统产生的结果感兴趣？
[UNL课件] 第5章 用例图
![[UNL课件] 第5章 用例图](https://img.taocdn.com/s3/m/ca0dada01a37f111f1855b7e.png)
– 3)弄清楚的概念（续）
5.2 用例图的组成
– 4)参与者检查
• 用于检查发现的参与者是否正确的检查点列表
是否你已找到所有的参与者？也就是说，是否你已经对系统环境中的所有角色都进行了说明和 建模？一般要到找到并说明了所有用例后才能将其确定。 每个参与者是否至少涉及到一个用例？删除未在用例说明中提及的所有参与者，或与用例无通 信关联关系的所有参与者。 你能否列出至少两名可以作为特定参与者的人员？如果不能，请检查参与者所建模的角色是否 为另一角色的一部分。如果是这样，应该将该参与者与另一参与者合并。
精化了
B
– 精化用例由基本用例分解得到，精化用例更细致地展 示了基本用例的核心业务。
开立账户 <<refine>> <<refine>> 存入现金 <<refine>> <<refine>> 转账 预存话费
– 一旦确定了用例，软件开发工作的其他活动都以此为 基础进行，即：用例驱动的开发。
分析
设计
需求单元 开发 组织
测试
部署
5.2 用例图的组成
– 3）用例的粒度
• 粒度，即一个用例的大小（包含多少操作）。 • i. 以阶段为划分标准
– 业务建模阶段，用例的粒度以每个用例能够说明一件
完整的事情为宜。
取钱 报装电话 借书 验证密码 填写申请单 查找书目
» 扩展用例带有抽象性质，表示了用例场景中的某个“支 流”，由特定扩展点触发而被启动。
– “扩展”表示的是“可选”：
» 即使没有扩展用例，基本用例也是完整的；
» 如有没有基本用例，扩展用例是不能单独存在的； » 如果有多个扩展用例，同一时间用例实例也只会使用其 中的一个。
(完整版)软件工程 第五章 面向对象的需求分析
第五章面向对象的需求分析面向对象的需求分析方法的核心是利用面向对象的概念和方法为软件需求建造模型。
它包含面向对象风格的图形语言机制和用于指导需求分析的面向对象方法学。
面向对象的思想最初起源于 20世纪 60年代中期的仿真程序设计语言Simula67。
20世纪80年代初出现的Smalltalk 语言及其程序设计环境对面向对象技术的推广应用起到了显著的促进作用。
20世纪90年代中后期诞生并迅速成熟的UML（Unified Modeling Language，统一建模语言）是面向对象技术发展的一个重要里程碑。
UML 统一了面向对象建模的基本概念、术语和表示方法，不仅为面向对象的软件开发过程提供了丰富的表达手段，而且也为软件开发人员提供了互相交流、分享经验的共用语言。
本章首先介绍面向对象的主要概念和思想。
在概述了UML的全貌之后，以“家庭保安系统”为实例，介绍与需求分析相关的部分 UML语言机制以及基于UML的面向对象的需求分析方法和过程。
第一节面向对象的概念与思想一、面向对象的概念关于“面向对象”，有许多不同的看法。
Coad和 Yourdon给出了一个定义：“面向对象 = 对象 + 类 + 继承 + 消息通信”。
如果一个软件系统是使用这样4个概念设计和实现的，则认为这个软件系统是面向对象的。
一个面向对象的程序的每一成分应是对象，计算是通过新的对象的建立和对象之间的消息通信来执行的。
1.对象（object）一般意义来讲，对象是现实世界中存在的一个事物。
可以是物理的，如一个家具或桌子，如图 5-1-1所示，可以是概念上的，如一个开发项目。
对象是构成现实世界的一个独立的单位，具有自己的静态特征（用数据描述）和动态特征（行为或具有的功能）。
例如：人的特征：姓名、性别、年龄等，行为：衣、食、住、行等。
图 5-1-1 对象的定义（1）对象、属性、操作、消息定义对象可以定义为系统中用来描述客观事物的一个实体，它是构成系统的一个基本单位，由一组属性和一组对属性进行操作的服务组成。
第五章_用例图
统进行交互的人、系统、子系统或类的外部实体 的抽象。 ❖ 每个参与者可以参与一个或多个用例，每个用例 也可以有一个或多个参与者。 ❖ 在用例图中使用一个人形图标来表示参与者，参 与者的名字写在人形图标下面。
5.2.1 参与者
❖ 参与者有三大类：
第一类参与者是真实的人，即用户，是最常见的 参与者，几乎存在于每一个系统中。
用例执行期间可能发生的各种情况。 用例是一个完整的描述。若其被分解成多个小用
例，则仅当所有的小用例完成后才代表整个用例的 完成。
2. 用例的识别
❖ 任何用例都不能在缺少参与者的情况下独立存在。 同样，任何参与者也必须要有与之关联的用例。 所以识别用例的最好方法就是从分析系统参与者 开始，在这个过程中往往会发现新的参与者。
❖ 用例图只是从总体上大致描述了系统所提供的各 种服务，让用户对系统有一个总体的认识。
❖ 对于每一个用例，我们还需要有详细的描述信息， 以便让别人对于整个系统有一个更加详细的了解， 这些信息包含在用例规约之中。
3. 用例规约
❖ 每一个用例的用例规约都应该包含以下内容： (1)简要说明：对用例作用和目的的简要描述。 (2)事件流：事件流包括基本流和备选流。基本流 描述的是用例的基本流程，是指用例“正常”运 行时的场景。备选流描述的是用例执行过程中可 能发生的异常和偶尔发生的情况。
第二类参与者是其他的系统。这类位于程序边界 之外的系统也是参与者。
第三类参与者是一些可以运行的进程。如时间， 当经过一定的时间触发系统中的某个事件时，时间 就成了参与者。
5.2.1 参与者
❖ 参与者虽然代表人或事物，但参与者不是指人或 事物本身，而是表示人或事物当时所扮演的角色。
❖ 一个用例的参与者可以划分为发起参与者和参加 参与者。发起参与者发起了用例的执行过程，一 个用例只有一个发起参与者，但可以有若干个参 加参与者。
5.2.1 参与者
❖ 参与者有三大类：
第一类参与者是真实的人，即用户，是最常见的 参与者，几乎存在于每一个系统中。
用例执行期间可能发生的各种情况。 用例是一个完整的描述。若其被分解成多个小用
例，则仅当所有的小用例完成后才代表整个用例的 完成。
2. 用例的识别
❖ 任何用例都不能在缺少参与者的情况下独立存在。 同样，任何参与者也必须要有与之关联的用例。 所以识别用例的最好方法就是从分析系统参与者 开始，在这个过程中往往会发现新的参与者。
❖ 用例图只是从总体上大致描述了系统所提供的各 种服务，让用户对系统有一个总体的认识。
❖ 对于每一个用例，我们还需要有详细的描述信息， 以便让别人对于整个系统有一个更加详细的了解， 这些信息包含在用例规约之中。
3. 用例规约
❖ 每一个用例的用例规约都应该包含以下内容： (1)简要说明：对用例作用和目的的简要描述。 (2)事件流：事件流包括基本流和备选流。基本流 描述的是用例的基本流程，是指用例“正常”运 行时的场景。备选流描述的是用例执行过程中可 能发生的异常和偶尔发生的情况。
第二类参与者是其他的系统。这类位于程序边界 之外的系统也是参与者。
第三类参与者是一些可以运行的进程。如时间， 当经过一定的时间触发系统中的某个事件时，时间 就成了参与者。
5.2.1 参与者
❖ 参与者虽然代表人或事物，但参与者不是指人或 事物本身，而是表示人或事物当时所扮演的角色。
❖ 一个用例的参与者可以划分为发起参与者和参加 参与者。发起参与者发起了用例的执行过程，一 个用例只有一个发起参与者，但可以有若干个参 加参与者。
UML05用例图模板
●
⑤ 绘制用例图。
34
5.5 发现用例
发现用例的一般方法：
① 找出系统外部参与者，确定系统边界和范围。 ② 确定各参与者所期望的系统行为。 ③ 把这些系统行为命名为用例。 ④ 确定各用例之间的关系(泛化，包含，扩展)。 ⑤ 绘制用例图。
●
⑥ 编制用例描述。
35
5.5 发现用例
发现用例的一般方法：
出纳员
吃饭
系统需要处理的，由系统生成
44
要点：业务语言而非技术语言
• 用户词汇，而不是技术词汇
– 如：发票，商品，洗衣机 – 而不是：记录，字段，COM，C++等
45
要点：用户观点而非系统观点
订票 旅客 查看今日航班
处理订票
旅客
显示今日航班
用户观点
系统观点
46
思考题：识别用例
• Email客户端（如：outlook express），A在 北京发邮件给上海的B，系统提醒B你有 “新邮件”，B收邮件。
用例描述
用例描述一般包括的内容：
用例的目标 用例是怎么启动的 参与者与用例之间的消息如何传送 用例中除了成功场景外, 其它场景是什么 用例结束后系统的状态 其它需要描述的内容
56
用例阐述文档
• 场景（scenario）： 是参与者和被讨论 系统之间的一系列特定活动和交互。每个 用例是一组场景的集合，而每个场景又是 一个步骤序列。 • 用例阐述文档针对每个用例，描述各个场 景
38
5.5.2 获取用例
一旦获取了参与者,就可以对每个参与者提出问题以获取用例。 •执行者要求系统提供哪些功能(执行者需要做什么)? •执行者需要读、产生、删除、修改或存储的信息有哪些类型。 •必须提醒执行者的系统事件有哪些? 或者执行者必须提醒系统 的事件有哪些? 怎样把这些事件表示成用例中的功能? •为了完整地描述用例,还需要知道执行者的某些典型功能能否 被系统自动实现? 还有一些不针对具体参与者问题(即针对整个系统的问题): •系统需要何种输入输出? 输入从何处来? 输出到何处? •当前运行系统(也许是一些手工操作而不是计算机系统)的主要 问题?
⑤ 绘制用例图。
34
5.5 发现用例
发现用例的一般方法：
① 找出系统外部参与者，确定系统边界和范围。 ② 确定各参与者所期望的系统行为。 ③ 把这些系统行为命名为用例。 ④ 确定各用例之间的关系(泛化，包含，扩展)。 ⑤ 绘制用例图。
●
⑥ 编制用例描述。
35
5.5 发现用例
发现用例的一般方法：
出纳员
吃饭
系统需要处理的，由系统生成
44
要点：业务语言而非技术语言
• 用户词汇，而不是技术词汇
– 如：发票，商品，洗衣机 – 而不是：记录，字段，COM，C++等
45
要点：用户观点而非系统观点
订票 旅客 查看今日航班
处理订票
旅客
显示今日航班
用户观点
系统观点
46
思考题：识别用例
• Email客户端（如：outlook express），A在 北京发邮件给上海的B，系统提醒B你有 “新邮件”，B收邮件。
用例描述
用例描述一般包括的内容：
用例的目标 用例是怎么启动的 参与者与用例之间的消息如何传送 用例中除了成功场景外, 其它场景是什么 用例结束后系统的状态 其它需要描述的内容
56
用例阐述文档
• 场景（scenario）： 是参与者和被讨论 系统之间的一系列特定活动和交互。每个 用例是一组场景的集合，而每个场景又是 一个步骤序列。 • 用例阐述文档针对每个用例，描述各个场 景
38
5.5.2 获取用例
一旦获取了参与者,就可以对每个参与者提出问题以获取用例。 •执行者要求系统提供哪些功能(执行者需要做什么)? •执行者需要读、产生、删除、修改或存储的信息有哪些类型。 •必须提醒执行者的系统事件有哪些? 或者执行者必须提醒系统 的事件有哪些? 怎样把这些事件表示成用例中的功能? •为了完整地描述用例,还需要知道执行者的某些典型功能能否 被系统自动实现? 还有一些不针对具体参与者问题(即针对整个系统的问题): •系统需要何种输入输出? 输入从何处来? 输出到何处? •当前运行系统(也许是一些手工操作而不是计算机系统)的主要 问题?
第5章 用例图
5.3 用例（Use Case）
描述用例 8.假设[可选]：假设描述的是系统在使用用例之前必须 满足的状态，这些条件并没有经过用例的检测，用 例只是假设它们为真。 9.基本操作流程：参与者在用例中所遵循的主要逻辑 路径。操作流程描述了用户和执行用例之间交互的 每一步。 10.可选操作流程：包括用例中很少使用的逻辑路径， 那些在变更工作方式、出现异常或发生错误的情况 下所遵循的路径。 11.修改历史记录[可选]：主要记录的是关于用例的修 改时间、修改原因和修改人的详细信息。
扩展关系也是一种依赖关系。 它指定了一个用例可以增强另一个用例的功 能，通过项基本用例添加动作来扩展该用例。 一个用例被定义为基本用例的增量扩展，这 称作扩展关系。 在扩展关系中，基本用例可以是独立的。在 一定条件下，基本用例的动作可由另外一个 用例扩展而来。基本用例提供了若干“扩展 点”，扩展用例只能在这些扩展点上增加一 个或多个新的动作。也就是说，扩展用例只 能发生在基本用例序列中的某个特定的点上。
用例的表示
在UML语言中，用例用一个椭圆来表示，并
且每个用例必须有一个名字。 在用例命名时用例的名字一般用字符串来表 示，可分为简单名和路径名。其中，路径名 引入了包的概念，在用例名前加上该用例所 属包的名字，两个名字之间用两个冒号分开。
AddBook
Libraian::LoanBook
5.3 用例（Use Case）
5.3 用例（Use Case）
描述用例 5.频率：记录参与者使用该用例的频率。 6.前置条件：前置条件以一个条件列表的形式进行记 录，用来描述执行用例之前系统所必须满足的条件。 这些条件必须在使用用例之前得到满足。前置条件 在使用之前，已经由用例进行过测试。如果条件不 满足，则用例不会被执行。 7.后置条件：后置条件将在用例成功完成以后得到满 足，它提供了系统的部分描述。即在前置条件满足 后，用例做了什么？以及用例结束时，系统处于什 么状态？
第5章 用例图
特定参与者希望系统提供什么功能； 系统是否存贮和检索信息，如果是，由哪个参与者触发； 当系统改变状态时，是否通知参与者； 是否存在影响系统的外部事件； 哪个参与者通知系统这些事件。
-11-
made by cnHexu
第5章 用例图
5.1.3 用例
3.用例与事件流 用例分析处于系统需求分析阶段，需要更加具体的细节， 这些细节写在事件流文件中。 事件流的目的：
第5章 用例图
5.1.2 参与者
2 .确定参与者 对参与者建模的过程中需要注意的问题
参与者对系统而言总是外部； 参与者可以直接或间接地同系统交互，或使用系统提供的服务 以完成某件事务； 参与者表示人和事物与系统交互时所扮演的角色，而不是特定 的人或特定的事物； 一个人或事物在与系统发生交互时，可以同时或不同时扮演多 个角色； 每一个参与者需要一个具有业务一样的名字； 每个参与者必须有简短的描述； 参与者可以具有表示参与者的属性和可以接受的事件。
-3-
made by cnHexu
第5章 用例图
5.1.2 参与者
1.参与者的概念 参与者是系统外部的一个实体,以某种形式参与用例的执行过程。 参与者通过向系统输入或请求系统输入某些事件来触发系统的执 行。 每个参与者可以参与一个或多个用例 表示：
人形图
-4-
made by cnHexu
2.确定参与者 如何寻找系统的参与者
谁将使用系统的主要功能； 谁将需要该系统的支持以完成其工作； 谁将需要维护、管理该系统，以保持该系统处于工作状态； 系统需要处理哪些硬件设备； 与该系统交互的是什么系统； 谁或什么系统对本系统产生的结果有兴趣。
第五章 用例图
泛化关系的含义是把某些参与者的共同行为提取出来表示成通用 行为，并描述成超类。泛化关系表示的是参与者之间的一般/特殊 关系，在UML图中，使用带空心三角箭头的实线表示泛化关系。
7
用例图的构成要素
3. 系统边界
在项目开发过程中，边界是一个非常重要的概念。这里说的系统边界是指系统与 系统之间的界限。通常我们所说的系统可以认为是由一系列的相互作用的元素形 成的具有特定功能的有机整体。
和系统管理三大管理功能。 1. 项目管理包括项目的增加、删除、更新。 2. 资源管理包括对资源和技能的添加、删除
和更新。 3.系统管理包括系统的启动和关闭，数据的
存储和备份等功能。
说明：技能表示人力资源。
19
1. 分析确定系统的执行者(角色) 到确定
项目管理员、资源管理员、系统管理 员、备份数据系统。
1. 病症监视器可以将采集到的病症信号（组合），格式化后实时的传送到 中央监护系统。
2. 中央监护系统将病人的病症信号开解后与标准的病症信号库里的病症信 号的正常值进行比较，当病症出现异常时系统自动报警。
3. 当病症信号异常时，系统自动更新病历并打印病情报告。
4. 值班护士可以查看病情报告并进行打印。
23
例2 医院病房监护系统
监视病情
产生 病情报告
经 1.过请监初对视步系病的统员需需的求求病进分症行析（分，血析得！压到、系体统温功、能脉要搏求等：） 2. 定时更新病历 3. 病员出现异常情况时报警。 4. 随机地产生某一病员的病情报告。
更新病历
24
二、简单的需求分析说明
需求分析
对“医院病房监护系统”进行分析，确定系统的主要功能如下：
第五章 用例图
1
学习内容
7
用例图的构成要素
3. 系统边界
在项目开发过程中，边界是一个非常重要的概念。这里说的系统边界是指系统与 系统之间的界限。通常我们所说的系统可以认为是由一系列的相互作用的元素形 成的具有特定功能的有机整体。
和系统管理三大管理功能。 1. 项目管理包括项目的增加、删除、更新。 2. 资源管理包括对资源和技能的添加、删除
和更新。 3.系统管理包括系统的启动和关闭，数据的
存储和备份等功能。
说明：技能表示人力资源。
19
1. 分析确定系统的执行者(角色) 到确定
项目管理员、资源管理员、系统管理 员、备份数据系统。
1. 病症监视器可以将采集到的病症信号（组合），格式化后实时的传送到 中央监护系统。
2. 中央监护系统将病人的病症信号开解后与标准的病症信号库里的病症信 号的正常值进行比较，当病症出现异常时系统自动报警。
3. 当病症信号异常时，系统自动更新病历并打印病情报告。
4. 值班护士可以查看病情报告并进行打印。
23
例2 医院病房监护系统
监视病情
产生 病情报告
经 1.过请监初对视步系病的统员需需的求求病进分症行析（分，血析得！压到、系体统温功、能脉要搏求等：） 2. 定时更新病历 3. 病员出现异常情况时报警。 4. 随机地产生某一病员的病情报告。
更新病历
24
二、简单的需求分析说明
需求分析
对“医院病房监护系统”进行分析，确定系统的主要功能如下：
第五章 用例图
1
学习内容
第5章 用例图
用例的识别
识别用例最好的方法就是从分析系统的参 与者开始，考虑每个参与者是如何使用系 统的。 如何识别用例。
用例的粒度
用例的粒度是指用例所包含的系统服务或 功能单元的多少。 用例的粒度越大，用例包含的功能就越多， 反之，则越少。 用例粒度大，用例数会少，反之，用例粒 度小，用例数会多。 用例数目过多会造成用例模型过大和引入 设计困难大大提高；用例数目过少不便于 进一步充分分析。
图5-17 扩展关系示例
扩展关系一般用来处理异常或构建灵活的系统框架。 使用扩展关系可以降低系统的复杂度，有利于系统 的扩展、提高系统的性能。 扩展关系还可用来处理基础用例中的不易描述的问 题，是系统显得清晰、易于理解。
泛化关系
用例的泛化是指一个父用例可以被特化形成多个子用例， 父用例和子用例之间的关系就是泛化。 父用例也可以被特别列举为一个或多个子用例。 子用例表示父用例的特殊形式。 子用例从父用例处继承行为和属性，还可以添加行为或覆 盖、改变继承的行为。
当系统中两个或多个用例在行为、结构和 目的方面存在共性时，就可以使用泛化关 系。
图5-19 泛化关系示例
泛化关系和包含关系都可以用来复用多个用例中 的公共行为。 泛化关系和包含关系的区别： 1、在用例的泛化关系中，所有的子用例都有相似 的目的和结构，注意它们是整体上的相似。 2、在用例的包含关系中，基础用例在目的上可以 完全不同，但是它们都有一段相似的行为，它们 的相似是部分而不是整体。用例的泛化关系类似 于面向对象中的继承，它把多个子用例中的共性 抽象成一个父用例，子用例在继承父用例的基础 上可以进行修改。但子用例之间又是相互独立的， 任何一个子用例的执行不受其他子用例的影响。 而用例的包含关系是把多个基础用例中的共性抽 象为一个被包含用例，可以说被包含用例就是基 础用例中的一部分，基础用例的执行必然引起被 包含用例的执行。
UML用例图
包含关联与扩展关联的区别： 存在包含关联的两个用例，用例必须包含被包含用例；存在 扩展关联的两个用例则有使用被扩展用例的选择权。
4、用例图示例
成绩管理系统用例图
二、如何建立用例图模型
创建用例图模型有4项任务： •找出系统中的角色和用例。 •区分用例的优先次序。 •细化每个用例。 •建立用例图模型结构。
UML的用例图标
获得产品信息
订购货物
支付货款
。。。
订货处理用例
3、用例图的关联
1）角色与用例的关联
角色与用例的关联表示角色与用例相关性。在UML中是使用 一条带箭头的实线连接角色与用例，如下图所示。
成绩管理
2）角色与角色的关联
角色与角色的关联用来表示一般角色与特殊角色的泛化关系。 在UML图中，使用带空心三角箭头的实线表示。如下图所示：
用例与用例的包含关联用来表示一个用例的行为包含了另一个用例 的行为。在UML图中，使用带虚线箭头表示，并在线上标有构造型 <<include>>。如下图所示：
成绩管理
用例与用例的扩展关联用来表示一个用例的行为扩展了另一个用例 的行为。在UML图中，使用带虚线箭头表示，并在线上标有构造型 <<extend>>。如下图所示：
例1 超市进销存系统用例图建模 1、超市进销存系统的需求描述如下： （1）销售 ①售货员接收顾客订购，输入顾客购买的商品，计算总价； ②顾客付款并接收清单； ③售货员保存顾客购买商品的记录清单。 （2）库存 ①库存管理员每天进行盘点一次； ②库存管理员当发现库存商品有损坏时，及时到相关部门报损； ③在供应商的商品到货时，库存管理员首先检查商品是否合格， 并将合格的商品入库处理；当商品进入卖场时，进行商品出库处 理； ④经理、订货员根据需要进行库存商品的模糊查询或详细查询。
相关主题
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
用例图可视化地表达了系统的需求，具有直观、规范 等优点，克服了纯文字性说明的不足。
用例方法是完全从外部来定义系统功能，它把需求和 设计完全的分离开来。我们不用关心系统内部是如何 完成各种功能的，系统对于我们来说就是一个黑箱子。
用例图的构成要素
1. 参与者
参与者（Actor）是指存在于系统外部并直接与系统进行交互的人、系统、 子系统或类的外部实体的抽象。
每一个用例的用例规约都应该包含以下内容： (1)简要说明:对用例作用和目的的简要描述。 (2)事件流:事件流包括基本流和备选流。基本流描述的是用例的基本流 程，是指用例“正常”运行时的场景。 (3)用例场景:同一个用例在实际执行的时候会有很多不同的情况发生， 称之为用例场景，也可以说用例场景就是用例的实例。 (4)特殊需求: 特殊需求指的是一个用例的非功能性需求和设计约束。特 殊需求通常是非功能性需求，包括可靠性、性能、可用性和可扩展性等。 例如法律或法规方面的需求、应用程序标准和所构建系统的质量属性等。 (5)前置条件: 执行用例之前系统必须所处的状态。例如，前置条件是要 求用户有访问的权限或是要求某个用例必须已经执行完。 (6)后置条件:用例执行完毕后系统可能处于的一组状态。例如，要求在 某个用例执行完后，必须执行另一个用例。
每个参与者可以参与一个或多个用例，每个用例也可以有一个或多个参 与者。
在用例图中使用一个人形图标来表示参与者，参与者的名字写在人形图 标下面。
用例图的构成要素
2. 参与者间的关系
由于参与者实质上也是类，所以它拥有与类相同的关系描述，即 参与者与参与者之间主要是泛化关系（或称为“继承”关系）。
1. 分析确定系统的执行者(角色) 到确定
项目管理员、资源管理员、系统管理 员、备份数据系统。
2. 确定用例
到确定
项目管理，资源管理和系统管理。
3. 对用例进行分解，画出下层的Use case图
对上层的用例进行分解,并将执行者 分配到各层次的Use case图中。
还应画出相应的执行者描述模板及用 例描述模板。
角色： 角色职责：
角色职责识别：
角色描述模板
用例名： 功能描述： 主要步骤： 相关用例： 相关信息：(优先级 性能,频度…)
用例描述模板
例1 项目与资源管理系统（PRMS）
资源管理员
资源管理
项目管理
项目管理员
添加技能
删除技能
<<Use >>
查找技能
更新技能
<<Use> >
备份系统
系统管理
系统管理员 资源管理员
更新病历
二、简单的需求分析说明
需求分析
对“医院病房监护系统”进行分析，确定系统的主要功能如下：
1. 病症监视器可以将采集到的病症信号（组合），格式化后实时的传送到 中央监护系统。
2. 中央监护系统将病人的病症信号开解后与标准的病症信号库里的病症信 号的正常值进行比较，当病症出现异常时系统自动报警。
用例之间的关系
1. 包含
包含关系指用例可以简单地包含其他用例具有的行为，并把它所 包含的用例行为作为自身行为的一部分。在UML中，包含关系是 通过带箭头的虚线段加<<include>>字样来表示，箭头由基础用 例(Base)指向被包含用例(Inclusion)。
用例之间的关系
包含关系代表着基础用例会用到被包含用例，具体的 讲就是将被包含用例的事件流插入到基础用例的事件 流中。需要注意的是，包含关系是UML1.3中的表述， 在UML1.1中，同等语义的关系被表述为使用(uses)。
系统管理Use Case图
应用举例 例2—医院病房监护系统
一、问题描述
为了对危重病人进行实时监护，随时了解病人病情，及时 进行处理，建立病房监护系统。
病症监视器安置在每个病床，通过网络将病人的病症信号 （组合）实时传送到中央监护系统进行分析处理。
在中心值班室里，值班护士使用中央监护系统对病员的情 况进行监控，监护系统实时地将病人的病症信号与标准的病诊 信号进行比较分析，当病症出现异常时，系统会立即自动报警， 并打印病情报告和更新病历。
用例之间的关系
2. 扩展
在一定条件下，把新的行为加入到已有的用例中，获得的新用例叫做扩 展用例(Extension)，原有的用例叫做基础用例(Base)，从扩展用例到基 础用例的关系就是扩展关系。
一个基础用例可以拥有一个或者多个扩展用例，这些扩展用例可以一起 使用。
用例之间的是一个父用例可以被特化形成多个子用例，而父用例和 子用例之间的关系就是泛化关系。
5.3.3用例图实例
例1 建立项目与资源管理系统的Use case图 系统的主要功能是：包括项目管理，资源管理
和系统管理三大管理功能。 1. 项目管理包括项目的增加、删除、更新。 2. 资源管理包括对资源和技能的添加、删除
和更新。 3.系统管理包括系统的启动和关闭，数据的
存储和备份等功能。
说明：技能表示人力资源。
什么叫用例图
在用例建模中，为了更加清楚的描述用 例或者参与者，会使用到注释。
什么叫用例图
2. 用例图的作用
用例图是需求分析中的产物，主要作用是描述参与者 和用例之间的关系，帮助开发人员可视化的了解系统 的功能。借助于用例图，系统用户、系统分析人员、 系统设计人员、领域专家能够以可视化的方式对问题 进行探讨，减少了大量交流上的障碍，便于对问题达 成共识。
系统同时又是相对的，一个系统本身又可以是另一个更大系统的组成部分，因此， 系统与系统之间需要使用系统边界进行区分开来。我们把系统边界以外的同系统 相关联的其他部分，称之为系统环境。
用例的重要元素
1. 识别用例
任何用例都不能在缺少参与者的情况下独立存在。同样，任何参 与者也必须要有与之关联的用例。所以识别用例的最好方法就是 从分析系统参与者开始，在这个过程中往往会发现新的参与者。
3. 当病症信号异常时，系统自动更新病历并打印病情报告。 4. 值班护士可以查看病情报告并进行打印。 5. 医生可以查看病情报告，要求打印病情报告，也可以查看或要求打印病 历。
6. 系统定期自动更新病历。
三、建立系统的用例模型
需求分析
1. 通过以下六个问题识别角色
(1)谁使用系统的主要功能？
值班护士、医生、病人
系统根据医生的要求随时打印病人的病情报告，系统定期 自动更新病历。
例2 医院病房监护系统
监视病情
产生 病情报告
经1.过请监初对视步系病的统员需需的求求病进分症行析（分，析血得！压到、系体统温功、能脉要搏求等：） 2. 定时更新病历 3. 病员出现异常情况时报警。 4. 随机地产生某一病员的病情报告。
泛化关系的含义是把某些参与者的共同行为提取出来表示成通用 行为，并描述成超类。泛化关系表示的是参与者之间的一般/特殊 关系，在UML图中，使用带空心三角箭头的实线表示泛化关系。
用例图的构成要素
3. 系统边界
在项目开发过程中，边界是一个非常重要的概念。这里说的系统边界是指系统与 系统之间的界限。通常我们所说的系统可以认为是由一系列的相互作用的元素形 成的具有特定功能的有机整体。
2. 用例的粒度
用例的粒度指的是用例所包含的系统服务或功能单元 的多少。用例的粒度越大，用例包含的功能越多，反 之则包含的功能越少。
如果用例的粒度很小，得到的用例数就会太多。反之， 如果用例的粒度很大，那么得到的用例数就会很少。
如果用例数目过多会造成用例模型过大和引入设计困 难大大提高。 如果用例数目过少会造成用例的粒度太 大，不便于进一步的充分分析。
<<Extend> > 更新任务
<<Extend> >取消对任务 的资源分配
<<Use> <<Use>
添加技能>
>
查找技能
存储数据
<< Extend >>
启动系统
关闭系统
<<Extend >>
备份数据
系统管理员
备源份数资据<><Use><><Use>备 目份 数项 据 备份系统
项目管理Use Case图
可以通过以下问题来寻找用例： (1)参与者希望系统提供什么功能？ (2)参与者是否会读取、创建、修改、删除、存储系统的某种信息？ 如果是的话，参与者又是如何完成这些操作的？ (3)参与者是否会将外部的某些事件通知给系统？ (4)系统中发生的事件是否通知参与者？ (5)是否存在影响系统的外部事件。
用例的重要元素
添加资源
<<Use>
删除资源 >
查找资源
PRMS高层Use Case图
Use Case图可以自顶而下不断精化，抽 象出不同层次的Use Case图。
更新资源 <<Use>>
<<Extend> > 把技能指
定给资源
<<Extend> > 从资源中
清除技能
注：这里的“技能”是指人力资源。
资源管理Use Case图
(2)谁需要系统的支持以完成日常工作任务？
(3)谁负责维护，管理并保持系统正常运行？
值班护士、医生
(4)系统需要应付（或处理）哪些硬设备？
系统管理员
(5)系统需要和哪些外部系统交互？
监护器,网络,报警系统
(6)谁（或什么）对系统运行产生的结果（值）感兴趣？
标准病症信号库、病历库
同(2)
角色描述
通过回答这六个问题以后，再进一步分析可以识别出本系统的四个角色：值班 护士，医生，病人，标准病症信号库。
用例方法是完全从外部来定义系统功能，它把需求和 设计完全的分离开来。我们不用关心系统内部是如何 完成各种功能的，系统对于我们来说就是一个黑箱子。
用例图的构成要素
1. 参与者
参与者（Actor）是指存在于系统外部并直接与系统进行交互的人、系统、 子系统或类的外部实体的抽象。
每一个用例的用例规约都应该包含以下内容： (1)简要说明:对用例作用和目的的简要描述。 (2)事件流:事件流包括基本流和备选流。基本流描述的是用例的基本流 程，是指用例“正常”运行时的场景。 (3)用例场景:同一个用例在实际执行的时候会有很多不同的情况发生， 称之为用例场景，也可以说用例场景就是用例的实例。 (4)特殊需求: 特殊需求指的是一个用例的非功能性需求和设计约束。特 殊需求通常是非功能性需求，包括可靠性、性能、可用性和可扩展性等。 例如法律或法规方面的需求、应用程序标准和所构建系统的质量属性等。 (5)前置条件: 执行用例之前系统必须所处的状态。例如，前置条件是要 求用户有访问的权限或是要求某个用例必须已经执行完。 (6)后置条件:用例执行完毕后系统可能处于的一组状态。例如，要求在 某个用例执行完后，必须执行另一个用例。
每个参与者可以参与一个或多个用例，每个用例也可以有一个或多个参 与者。
在用例图中使用一个人形图标来表示参与者，参与者的名字写在人形图 标下面。
用例图的构成要素
2. 参与者间的关系
由于参与者实质上也是类，所以它拥有与类相同的关系描述，即 参与者与参与者之间主要是泛化关系（或称为“继承”关系）。
1. 分析确定系统的执行者(角色) 到确定
项目管理员、资源管理员、系统管理 员、备份数据系统。
2. 确定用例
到确定
项目管理，资源管理和系统管理。
3. 对用例进行分解，画出下层的Use case图
对上层的用例进行分解,并将执行者 分配到各层次的Use case图中。
还应画出相应的执行者描述模板及用 例描述模板。
角色： 角色职责：
角色职责识别：
角色描述模板
用例名： 功能描述： 主要步骤： 相关用例： 相关信息：(优先级 性能,频度…)
用例描述模板
例1 项目与资源管理系统（PRMS）
资源管理员
资源管理
项目管理
项目管理员
添加技能
删除技能
<<Use >>
查找技能
更新技能
<<Use> >
备份系统
系统管理
系统管理员 资源管理员
更新病历
二、简单的需求分析说明
需求分析
对“医院病房监护系统”进行分析，确定系统的主要功能如下：
1. 病症监视器可以将采集到的病症信号（组合），格式化后实时的传送到 中央监护系统。
2. 中央监护系统将病人的病症信号开解后与标准的病症信号库里的病症信 号的正常值进行比较，当病症出现异常时系统自动报警。
用例之间的关系
1. 包含
包含关系指用例可以简单地包含其他用例具有的行为，并把它所 包含的用例行为作为自身行为的一部分。在UML中，包含关系是 通过带箭头的虚线段加<<include>>字样来表示，箭头由基础用 例(Base)指向被包含用例(Inclusion)。
用例之间的关系
包含关系代表着基础用例会用到被包含用例，具体的 讲就是将被包含用例的事件流插入到基础用例的事件 流中。需要注意的是，包含关系是UML1.3中的表述， 在UML1.1中，同等语义的关系被表述为使用(uses)。
系统管理Use Case图
应用举例 例2—医院病房监护系统
一、问题描述
为了对危重病人进行实时监护，随时了解病人病情，及时 进行处理，建立病房监护系统。
病症监视器安置在每个病床，通过网络将病人的病症信号 （组合）实时传送到中央监护系统进行分析处理。
在中心值班室里，值班护士使用中央监护系统对病员的情 况进行监控，监护系统实时地将病人的病症信号与标准的病诊 信号进行比较分析，当病症出现异常时，系统会立即自动报警， 并打印病情报告和更新病历。
用例之间的关系
2. 扩展
在一定条件下，把新的行为加入到已有的用例中，获得的新用例叫做扩 展用例(Extension)，原有的用例叫做基础用例(Base)，从扩展用例到基 础用例的关系就是扩展关系。
一个基础用例可以拥有一个或者多个扩展用例，这些扩展用例可以一起 使用。
用例之间的是一个父用例可以被特化形成多个子用例，而父用例和 子用例之间的关系就是泛化关系。
5.3.3用例图实例
例1 建立项目与资源管理系统的Use case图 系统的主要功能是：包括项目管理，资源管理
和系统管理三大管理功能。 1. 项目管理包括项目的增加、删除、更新。 2. 资源管理包括对资源和技能的添加、删除
和更新。 3.系统管理包括系统的启动和关闭，数据的
存储和备份等功能。
说明：技能表示人力资源。
什么叫用例图
在用例建模中，为了更加清楚的描述用 例或者参与者，会使用到注释。
什么叫用例图
2. 用例图的作用
用例图是需求分析中的产物，主要作用是描述参与者 和用例之间的关系，帮助开发人员可视化的了解系统 的功能。借助于用例图，系统用户、系统分析人员、 系统设计人员、领域专家能够以可视化的方式对问题 进行探讨，减少了大量交流上的障碍，便于对问题达 成共识。
系统同时又是相对的，一个系统本身又可以是另一个更大系统的组成部分，因此， 系统与系统之间需要使用系统边界进行区分开来。我们把系统边界以外的同系统 相关联的其他部分，称之为系统环境。
用例的重要元素
1. 识别用例
任何用例都不能在缺少参与者的情况下独立存在。同样，任何参 与者也必须要有与之关联的用例。所以识别用例的最好方法就是 从分析系统参与者开始，在这个过程中往往会发现新的参与者。
3. 当病症信号异常时，系统自动更新病历并打印病情报告。 4. 值班护士可以查看病情报告并进行打印。 5. 医生可以查看病情报告，要求打印病情报告，也可以查看或要求打印病 历。
6. 系统定期自动更新病历。
三、建立系统的用例模型
需求分析
1. 通过以下六个问题识别角色
(1)谁使用系统的主要功能？
值班护士、医生、病人
系统根据医生的要求随时打印病人的病情报告，系统定期 自动更新病历。
例2 医院病房监护系统
监视病情
产生 病情报告
经1.过请监初对视步系病的统员需需的求求病进分症行析（分，析血得！压到、系体统温功、能脉要搏求等：） 2. 定时更新病历 3. 病员出现异常情况时报警。 4. 随机地产生某一病员的病情报告。
泛化关系的含义是把某些参与者的共同行为提取出来表示成通用 行为，并描述成超类。泛化关系表示的是参与者之间的一般/特殊 关系，在UML图中，使用带空心三角箭头的实线表示泛化关系。
用例图的构成要素
3. 系统边界
在项目开发过程中，边界是一个非常重要的概念。这里说的系统边界是指系统与 系统之间的界限。通常我们所说的系统可以认为是由一系列的相互作用的元素形 成的具有特定功能的有机整体。
2. 用例的粒度
用例的粒度指的是用例所包含的系统服务或功能单元 的多少。用例的粒度越大，用例包含的功能越多，反 之则包含的功能越少。
如果用例的粒度很小，得到的用例数就会太多。反之， 如果用例的粒度很大，那么得到的用例数就会很少。
如果用例数目过多会造成用例模型过大和引入设计困 难大大提高。 如果用例数目过少会造成用例的粒度太 大，不便于进一步的充分分析。
<<Extend> > 更新任务
<<Extend> >取消对任务 的资源分配
<<Use> <<Use>
添加技能>
>
查找技能
存储数据
<< Extend >>
启动系统
关闭系统
<<Extend >>
备份数据
系统管理员
备源份数资据<><Use><><Use>备 目份 数项 据 备份系统
项目管理Use Case图
可以通过以下问题来寻找用例： (1)参与者希望系统提供什么功能？ (2)参与者是否会读取、创建、修改、删除、存储系统的某种信息？ 如果是的话，参与者又是如何完成这些操作的？ (3)参与者是否会将外部的某些事件通知给系统？ (4)系统中发生的事件是否通知参与者？ (5)是否存在影响系统的外部事件。
用例的重要元素
添加资源
<<Use>
删除资源 >
查找资源
PRMS高层Use Case图
Use Case图可以自顶而下不断精化，抽 象出不同层次的Use Case图。
更新资源 <<Use>>
<<Extend> > 把技能指
定给资源
<<Extend> > 从资源中
清除技能
注：这里的“技能”是指人力资源。
资源管理Use Case图
(2)谁需要系统的支持以完成日常工作任务？
(3)谁负责维护，管理并保持系统正常运行？
值班护士、医生
(4)系统需要应付（或处理）哪些硬设备？
系统管理员
(5)系统需要和哪些外部系统交互？
监护器,网络,报警系统
(6)谁（或什么）对系统运行产生的结果（值）感兴趣？
标准病症信号库、病历库
同(2)
角色描述
通过回答这六个问题以后，再进一步分析可以识别出本系统的四个角色：值班 护士，医生，病人，标准病症信号库。