第五章 用例图

(2)谁需要系统的支持以完成日常工作任务？
(3)谁负责维护，管理并保持系统正常运行？
值班护士、医生
(4)系统需要应付（或处理）哪些硬设备？
系统管理员
(5)系统需要和哪些外部系统交互？
监护器,网络,报警系统
(6)谁（或什么）对系统运行产生的结果（值）感兴趣？
标准病症信号库、病历库
同(2)
角色描述
通过回答这六个问题以后，再进一步分析可以识别出本系统的四个角色：值班 护士，医生，病人，标准病症信号库。
用例的重要元素
• 比如：网站后台管理系统中的会员信息维护用例，管理员需要进行添加会员信息、 修改会员信息、删除会员信息等操作。
• 我们还可以根据具体的操作把它抽象成3个用例，它展示的系统需求和单个用例是 完全一样的。
用例的重要元素
3. 用例规约
对于每一个用例，我们还需要有详细的描述信息，以便让别人对于整个 系统有一个更加详细的了解，这些信息包含在用例规约之中。
用例图可视化地表达了系统的需求，具有直观、规范 等优点，克服了纯文字性说明的不足。
用例方法是完全从外部来定义系统功能，它把需求和 设计完全的分离开来。我们不用关心系统内部是如何 完成各种功能的，系统对于我们来说就是一个黑箱子。
用例图的构成要素
1. 参与者
参与者（Actor）是指存在于系统外部并直接与系统进行交互的人、系统、 子系统或类的外部实体的抽象。
可以通过以下问题来寻找用例： (1)参与者希望系统提供什么功能？ (2)参与者是否会读取、创建、修改、删除、存储系统的某种信息？ 如果是的话，参与者又是如何完成这些操作的？ (3)参与者是否会将外部的某些事件通知给系统？ (4)系统中发生的事件是否通知参与者？ (5)是否存在影响系统的外部事件。
用例的重要元素
系统根据医生的要求随时打印病人的病情报告，系统定期 自动更新病历。
例2 医院病房监护系统
监视病情
产生 病情报告
经1.过请监初对视步系病的统员需需的求求病进分症行析（分，析血得！压到、系体统温功、能脉要搏求等：） 2. 定时更新病历 3. 病员出现异常情况时报警。 4. 随机地产生某一病员的病情报告。
添加资源
<<Use>
删除资源 >
查找资源
PRMS高层Use Case图
Use Case图可以自顶而下不断精化，抽 象出不同层次的Use Case图。
更新资源 <<Use>>
<<Extend> > 把技能指
定给资源
<<Extend> > 从资源中
清除技能
注：这里的“技能”是指人力资源。
资源管理Use Case图
什么叫用例图
在用例建模中，为了更加清楚的描述用 例或者参与者，会使用到注释。
什么叫用例图
2. 用例图的作用
用例图是需求分析中的产物，主要作用是描述参与者 和用例之间的关系，帮助开发人员可视化的了解系统 的功能。借助于用例图，系统用户、系统分析人员、 系统设计人员、领域专家能够以可视化的方式对问题 进行探讨，减少了大量交流上的障碍，便于对问题达 成共识。
2. 用例的粒度
用例的粒度指的是用例所包含的系统服务或功能单元 的多少。用例的粒度越大，用例包含的功能越多，反 之则包含的功能越少。
如果用例的粒度很小，得到的用例数就会太多。反之， 如果用例的粒度很大，那么得到的用例数就会很少。
如果用例数目过多会造成用例模型过大和引入设计困 难大大提高。 如果用例数目过少会造成用例的粒度太 大，不便于进一步的充分分析。
系统同时又是相对的，一个系统本身又可以是另一个更大系统的组成部分，因此， 系统与系统之间需要使用系统边界进行区分开来。我们把系统边界以外的同系统 相关联的其他部分，称之为系统环境。
用例的重要元素
1. 识别用例
任何用例都不能在缺少参与者的情况下独立存在。同样，任何参 与者也必须要有与之关联的用例。所以识别用例的最好方法就是 从分析系统参与者开始，在这个过程中往往会发现新的参与者。
5.3.3用例图实例
例1 建立项目与资源管理系统的Use case图 系统的主要功能是：包括项目管理，资源管理
和系统管理三大管理功能。 1. 项目管理包括项目的增加、删除、更新。 2. 资源管理包括对资源和技能的添加、删除
和更新。 3.系统管理包括系统的启动和关闭，数据的
存储和备份等功能。
说明：技能表示人力资源。
用例之间的关系
1. 包含
包含关系指用例可以简单地包含其他用例具有的行为，并把它所 包含的用例行为作为自身行为的一部分。在UML中，包含关系是 通过带箭头的虚线段加<<include>>字样来表示，箭头由基础用 例(Base)指向被包含用例(Inclusion)。
用例之间的关系
包含关系代表着基础用例会用到被包含用例，具体的 讲就是将被包含用例的事件流插入到基础用例的事件 流中。需要注意的是，包含关系是UML1.3中的表述， 在UML1.1中，同等语义的关系被表述为使用(uses)。
在用例的泛化关系中，子用例继承了父用例所有的结构、行为和关系， 子用例是父用例的一种特殊形式。
子用例还可以添加、覆盖、改变继承的行为。在UML中，用例的泛化关 系通过一个三角箭头从子用例指向父用例来表示。
用例之间的关系
泛化的示例：银行存款有两种方式，一种是银行柜台存款，一种 是ATM机存款。在这里，银行柜台存款和ATM机存款都是存款的 一种特殊方式，因此“存款”为父用例，“银行柜台存款”和 “ATM机存款”为子用例。
每个参与者可以参与一个或多个用例，每个用例也可以有一个或多个参 与者。
在用例图中使用一个人形图标来表示参与者，参与者的名字写在人形图 标下面。
用例图的构成要素
2. 参与者间的关系
由于参与者实质上也是类，所以它拥有与类相同的关系描述，即 参与者与参与者之间主要是泛化关系（或称为“继承”关系）。
<<Extend> > 更新任务
<<Extend> >取消对任务 的资源分配
<<Use> <<Use>
添加技能>
>
查找技能
存储数据
<< Extend >>
启动系统
关闭系统
<<Extend >>
备份数据
系统管理员
备源份数资据<><Use><><Use>备 目份 数项 据 备份系统
项目管理Use Case图
每一个用例的用例规约都应该包含以下内容： (1)简要说明:对用例作用和目的的简要描述。 (2)事件流:事件流包括基本流和备选流。基本流描述的是用例的基本流 程，是指用例“正常”运行时的场景。 (3)用例场景:同一个用例在实际执行的时候会有很多不同的情况发生， 称之为用例场景，也可以说用例场景就是用例的实例。 (4)特殊需求: 特殊需求指的是一个用例的非功能性需求和设计约束。特 殊需求通常是非功能性需求，包括可靠性、性能、可用性和可扩展性等。 例如法律或法规方面的需求、应用程序标准和所构建系统的质量属性等。 (5)前置条件: 执行用例之前系统必须所处的状态。例如，前置条件是要 求用户有访问的权限或是要求某个用例必须已经执行完。 (6)后置条件:用例执行完毕后系统可能处于的一组状态。例如，要求在 某个用例执行完后，必须执行另一个用例。
用例之间的关系
在处理包含关系时，具体的做法就是把几个用例的公 共部分单独的抽象出来成为一个新的用例。主要有两 种情况需要用到包含关系：
第一，多个用例用到同一段的行为，则可以把这段共 同的行为单独抽 象成为一个用例，然后让其他用例 来包含这一用例。
第二，某一个用例的功能过多、事件流过于复杂时， 我们也可以把某一段事件流抽象成为一个被包含的用 例，以达到简化描述的目的。
角色描述模板：
角色：病 人 角色职责： 提供病症信号
角色职责识别：
负责生成、实时提 供各种病症信号。
角色：医 生 角色职责：
对病人负责，负责
处理病情的变化
角色职责识别： (1)需要系统支持 以完成其日常工作 (2)对系统运行结果 感兴趣
角色：值班护士 角色职责： 负责监视病人的病 情变化 角色职责识别： (1)使用系统主要功能 (2)对系统运行结果感 兴趣
1. 分析确定系统的执行者(角色) 到确定
项目管理员、资源管理员、系统管理 员、备份数据系统。
2. 确定用例
到确定
项目管理，资源管理和系统管理。
3. 对用例进行分解，画出下层的Use case图
对上层的用例进行分解,并将执行者 分配到各层次的Use case图中。
还应画出相应的执行者描述模板及用 例描述模板。
3. 当病症信号异常时，系统自动更新病历并打印病情报告。 4. 值班护士可以查看病情报告并进行打印。 5. 医生可以查看病情报告，要求打印病情报告，也可以查看或要求打印病 历。
6. 系统定期自动更新病历。
三、建立系统的用例模型
需求分析
1. 通过以下六个问题识别角色
(1)谁使用系统的主要功能？
值班护士、医生、病人
第五章 用例图
学习内容
什么叫用例图 用例图的构成要素 用例的重要元素 用例之间的关系 使用Rose创建用例的步骤说明
什么叫用例图
1. 用例图的含义
• 由参与者（Actor）、用例（Use Case）以及它们之间的关系构成的 用于描述系统功能的动态视图称为 用例图。要在用例图上显示某个用 例，可绘制一个椭圆，然后将用例 的名称放在椭圆的中心或椭圆下面 的中间位置。 • 要在用例图上绘制一个参与者 （表示一个系统用户），可绘制一 个人形符号。参与者和用例之间的 关系使用带箭头或者不带箭头的线 段来描述，箭头表示在这一关系中 哪一方是对话的主动发起者，箭头 所指方是对话的被动接受者。
角色： 角色职责：
角色职责识别：
角色描述模板
用例名： 功能描述： 主要步骤： 相关用例： 相关信息：(优先级 性能,频度…)
用例描述模板
例1 项目与资源管理系统（PRMS）
资源管理员
资源管理
项目管理
项目管理员
添加技能
删除技能
<<Use >>
查找技能
更新技能
<<Use> >
备份系统
系统管理
系统管理员 资源管理员
更新病历
二、简单的需求分析说明
需求分析
对“医院病房监护系统”进行分析，确定系统的主要功能如下：
1. 病症监视器可以将采集到的病症信号（组合），格式化后实时的传送到 中央监护系统。
2. 中央监护系统将病人的病症信号开解后与标准的病症信号库里的病症信 号的正常值进行比较，当病症出现异常时系统自动报警。
系统管理Use Case图
应用举例 例2—医院病房监护系统
一、问题描述
为了对危重病人进行实时监护，随时了解病人病情，及时 进行处理，建立病房监护系统。
病症监视器安置在每个病床，通过网络将病人的病症信号 （组合）实时传送到中央监护系统进行分析处理。
在中心值班室里，值班护士使用中央监护系统对病员的情 况进行监控，监护系统实时地将病人的病症信号与标准的病诊 信号进行比较分析，当病症出现异常时，系统会立即自动报警， 并打印病情报告和更新病历。
例1 项目与资源管理系统（PRMS）
添加项目 <<Use>>
删除项目
查找项目
项目
<<Extend> 更新项目
<<Use>> <<Extend>
管理员> 添加活动
> 添加任务
<<Extend >删> 除活动
<<Extend> >更新活动
<<Extend >>分配资源
给任务
<<Extend> >删除任务
泛化关系的含义是把某些参与者的共同行为提取出来表示成通用 行为，并描述成超类。泛化关系表示的是参与者之间的一般/特殊 关系，在UML图中，使用带空心三角箭头的实线表示泛化关系。
用例图的构成要素
3. 系统边界
在项目开发过程中，边界是一个非常重要的概念。这里说的系统边界是指系统与 系统之间的界限。通常我们所说的系统可以认为是由一系列的相互作用的元素形 成的具有特定功能的有机整体。
角色:标准病症信号库 角色职责： 负责向系统提供病症 信号的正常值
源自文库角色职责识别： (1)负责保持系统正 常运行 (2)与系统交互
２. 识别用例
回答下面的问题： ⑴ 与系统实现有关的主要问题是什么？ ⑵ 系统需要哪些输入/输出？这些输入/输出从何而来？到 哪里去？ ⑶ 执行者需要系统提供哪些功能？ ⑷ 执行者是否需要对系统中的信息进行读、创建、修改、删除或存储？
用例之间的关系
2. 扩展
在一定条件下，把新的行为加入到已有的用例中，获得的新用例叫做扩 展用例(Extension)，原有的用例叫做基础用例(Base)，从扩展用例到基 础用例的关系就是扩展关系。
一个基础用例可以拥有一个或者多个扩展用例，这些扩展用例可以一起 使用。
用例之间的关系
3. 泛化
用例的泛化指的是一个父用例可以被特化形成多个子用例，而父用例和 子用例之间的关系就是泛化关系。