第五章-用例图

第五章用例图1学习内容什么叫用例图用例图的构成要素用例的重要元素用例之间的关系使用Rose创建用例的步骤说明2什么叫用例图1.用例图的含义

由参与者（Actor）、用例（UseCase）以及它们之间的关系构成的用于描述系统功能的动态视图称为用例图。要在用例图上显示某个用例，可绘制一个椭圆，然后将用例的名称放在椭圆的中心或椭圆下面的中间位置。要在用例图上绘制一个参与者（表示一个系统用户），可绘制一个人形符号。参与者和用例之间的关系使用带箭头或者不带箭头的线段来描述，箭头表示在这一关系中哪一方是对话的主动发起者，箭头所指方是对话的被动接受者。3什么叫用例图在用例建模中，为了更加清楚的描述用例或者参与者，会使用到注释。4什么叫用例图2.用例图的作用用例图是需求分析中的产物，主要作用是描述参与者和用例之间的关系，帮助开发人员可视化的了解系统的功能。借助于用例图，系统用户、系统分析人员、系统设计人员、领域专家能够以可视化的方式对问题进行探讨，减少了大量交流上的障碍，便于对问题达成共识。用例图可视化地表达了系统的需求，具有直观、规范等优点，克服了纯文字性说明的不足。用例方法是完全从外部来定义系统功能，它把需求和设计完全的分离开来。我们不用关心系统内部是如何完成各种功能的，系统对于我们来说就是一个黑箱子。5用例图的构成要素1.参与者参与者（Actor）是指存在于系统外部并直接与系统进行交互的人、系统、子系统或类的外部实体的抽象。每个参与者可以参与一个或多个用例，每个用例也可以有一个或多个参与者。在用例图中使用一个人形图标来表示参与者，参与者的名字写在人形图标下面。6用例图的构成要素2.参与者间的关系由于参与者实质上也是类，所以它拥有与类相同的关系描述，即参与者与参与者之间主要是泛化关系（或称为“继承”关系）。泛化关系的含义是把某些参与者的共同行为提取出来表示成通用行为，并描述成超类。泛化关系表示的是参与者之间的一般/特殊关系，在UML图中，使用带空心三角箭头的实线表示泛化关系。7用例图的构成要素3.系统边界在项目开发过程中，边界是一个非常重要的概念。这里说的系统边界是指系统与系统之间的界限。通常我们所说的系统可以认为是由一系列的相互作用的元素形成的具有特定功能的有机整体。系统同时又是相对的，一个系统本身又可以是另一个更大系统的组成部分，因此，系统与系统之间需要使用系统边界进行区分开来。我们把系统边界以外的同系统相关联的其他部分，称之为系统环境。8用例的重要元素1.识别用例任何用例都不能在缺少参与者的情况下独立存在。同样，任何参与者也必须要有与之关联的用例。所以识别用例的最好方法就是从分析系统参与者开始，在这个过程中往往会发现新的参与者。可以通过以下问题来寻找用例：

(1)参与者希望系统提供什么功能？

(2)参与者是否会读取、创建、修改、删除、存储系统的某种信息？如果是的话，参与者又是如何完成这些操作的？

(3)参与者是否会将外部的某些事件通知给系统？

(4)系统中发生的事件是否通知参与者？

(5)是否存在影响系统的外部事件。9用例的重要元素2.用例的粒度用例的粒度指的是用例所包含的系统服务或功能单元的多少。用例的粒度越大，用例包含的功能越多，反之则包含的功能越少。如果用例的粒度很小，得到的用例数就会太多。反之，如果用例的粒度很大，那么得到的用例数就会很少。如果用例数目过多会造成用例模型过大和引入设计困难大大提高。如果用例数目过少会造成用例的粒度太大，不便于进一步的充分分析。10用例的重要元素比如：网站后台管理系统中的会员信息维护用例，管理员需要进行添加会员信息、修改会员信息、删除会员信息等操作。我们还可以根据具体的操作把它抽象成3个用例，它展示的系统需求和单个用例是完全一样的。11用例的重要元素3.用例规约对于每一个用例，我们还需要有详细的描述信息，以便让别人对于整个系统有一个更加详细的了解，这些信息包含在用例规约之中。每一个用例的用例规约都应该包含以下内容：

(1)简要说明:对用例作用和目的的简要描述。

(2)事件流:事件流包括基本流和备选流。基本流描述的是用例的基本流程，是指用例“正常”运行时的场景。

(3)用例场景:同一个用例在实际执行的时候会有很多不同的情况发生，称之为用例场景，也可以说用例场景就是用例的实例。

(4)特殊需求:特殊需求指的是一个用例的非功能性需求和设计约束。特殊需求通常是非功能性需求，包括可靠性、性能、可用性和可扩展性等。例如法律或法规方面的需求、应用程序标准和所构建系统的质量属性等。

(5)前置条件:执行用例之前系统必须所处的状态。例如，前置条件是要求用户有访问的权限或是要求某个用例必须已经执行完。

(6)后置条件:用例执行完毕后系统可能处于的一组状态。例如，要求在某个用例执行完后，必须执行另一个用例。12用例之间的关系1.包含包含关系指用例可以简单地包含其他用例具有的行为，并把它所包含的用例行为作为自身行为的一部分。在UML中，包含关系是通过带箭头的虚线段加<<include>>字样来表示，箭头由基础用例(Base)指向被包含用例(Inclusion)。13用例之间的关系包含关系代表着基础用例会用到被包含用例，具体的讲就是将被包含用例的事件流插入到基础用例的事件流中。需要注意的是，包含关系是UML1.3中的表述，在UML1.1中，同等语义的关系被表述为使用(uses)。14用例之间的关系在处理包含关系时，具体的做法就是把几个用例的公共部分单独的抽象出来成为一个新的用例。主要有两种情况需要用到包含关系：第一，多个用例用到同一段的行为，则可以把这段共同的行为单独抽象成为一个用例，然后让其他用例来包含这一用例。第二，某一个用例的功能过多、事件流过于复杂时，我们也可以把某一段事件流抽象成为一个被包含的用例，以达到简化描述的目的。15用例之间的关系2.扩展在一定条件下，把新的行为加入到已有的用例中，获得的新用例叫做扩展用例(Extension)，原有的用例叫做基础用例(Base)，从扩展用例到基础用例的关系就是扩展关系。一个基础用例可以拥有一个或者多个扩展用例，这些扩展用例可以一起使用。16用例之间的关系3.泛化用例的泛化指的是一个父用例可以被特化形成多个子用例，而父用例和子用例之间的关系就是泛化关系。在用例的泛化关系中，子用例继承了父用例所有的结构、行为和关系，子用例是父用例的一种特殊形式。子用例还可以添加、覆盖、改变继承的行为。在UML中，用例的泛化关系通过一个三角箭头从子用例指向父用例来表示。17用例之间的关系泛化的示例：银行存款有两种方式，一种是银行柜台存款，一种是ATM机存款。在这里，银行柜台存款和ATM机存款都是存款的一种特殊方式，因此“存款”为父用例，“银行柜台存款”和“ATM机存款”为子用例。185.3.3用例图实例例1建立项目与资源管理系统的Usecase图

系统的主要功能是：包括项目管理，资源管理和系统管理三大管理功能。

1.项目管理包括项目的增加、删除、更新。

2.资源管理包括对资源和技能的添加、删除和更新。

3.系统管理包括系统的启动和关闭，数据的存储和备份等功能。说明：技能表示人力资源。191.分析确定系统的执行者(角色)到确定到确定

项目管理员、资源管理员、系统管理员、备份数据系统。项目管理，资源管理和系统管理。2.确定用例3.对用例进行分解，画出下层的Usecase图角色：角色职责：角色职责识别：角色描述模板

还应画出相应的执行者描述模板及用例描述模板。

对上层的用例进行分解,并将执行者分配到各层次的Usecase图中。用例名：功能描述：主要步骤：相关用例：相关信息：(优先级性能,频度…)用例描述模板20例1项目与资源管理系统（PRMS）添加技能删除技能更新技能资源管理员添加资源删除资源更新资源查找技能<<Use>>查找资源<<Use>><<Use>><<Use>>把技能指定给资源从资源中清除技能<<Extend>><<Extend>>资源管理UseCase图UseCase图可以自顶而下不断精化，抽象出不同层次的UseCase图。系统管理员项目管理员资源管理员资源管理项目管理系统管理备份系统PRMS高层UseCase图注：这里的“技能”是指人力资源。21例1项目与资源管理系统（PRMS）项目管理员添加项目删除项目更新项目添加活动删除活动更新活动查找项目<<Use>>添加任务<<Use>>分配资源给任务取消对任务的资源分配<<Extend>><<Extend>>删除任务更新任务<<Extend>><<Extend>><<Extend>><<Extend>><<Extend>><<Extend>>项目管理UseCase图系统管理UseCase图系统管理员添加技能存储数据启动系统关闭系统查找技能<<Use>><<Use>><<Use>>备份资源数据备份项目数据<<Extend>><<Extend>><<Use>>备份数据备份系统22应用举例

例2—医院病房监护系统一、问题描述为了对危重病人进行实时监护，随时了解病人病情，及时进行处理，建立病房监护系统。

病症监视器安置在每个病床，通过网络将病人的病症信号（组合）实时传送到中央监护系统进行分析处理。在中心值班室里，值班护士使用中央监护系统对病员的情况进行监控，监护系统实时地将病人的病症信号与标准的病诊信号进行比较分析，当病症出现异常时，系统会立即自动报警，并打印病情报告和更新病历。系统根据医生的要求随时打印病人的病情报告，系统定期自动更新病历。23请对系统需求进行分析！经过初步的需求分析，得到系统功能要求：1.监视病员的病症（血压、体温、脉搏等）2.定时更新病历3.病员出现异常情况时报警。4.随机地产生某一病员的病情报告。

例2医院病房监护系统产生病情报告监视病情更新病历24二、简单的需求分析说明对“医院病房监护系统”进行分析，确定系统的主要功能如下：

1.病症监视器可以将采集到的病症信号（组合），格式化后实时的传送到中央监护系统。

2.中央监护系统将病人的病症信号开解后与标准的病症信号库里的病症信号的正常值进行比较，当病症出现异常时系统自动报警。

3.当病症信号异常时，系统自动更新病历并打印病情报告。

4.值班护士可以查看病情报告并进行打印。

5.医生可以查看病情报告，要求打印病情报告，也可以查看或要求打印病历。

6.系统定期自动更新病历。需求分析251.通过以下六个问题识别角色(1)谁使用系统的主要功能？(2)谁需要系统的支持以完成日常工作任务？(3)谁负责维护，管理并保持系统正常运行？(4)系统需要应付（或处理）哪些硬设备？(5)系统需要和哪些外部系统交互？(6)谁（或什么）对系统运行产生的结果（值）感兴趣？需求分析三、建立系统的用例模型值班护士、医生、病人值班护士、医生系统管理员监护器,网络,报警系统标准病症信号库、病历库同(2)26

通过回答这六个问题以后，再进一步分析可以识别出本系统的四个角色：值班护士，医生，病人，标准病症信号库。角色描述模板：角色：病人角色职责：提供病症信号角色职责识别：负责生成、实时提供各种病症信号。角色：值班护士角色职责：负责监视病人的病情变化角色职责识别：

(1)使用系统主要功能

(2)对系统运行结果感兴趣角色:标准病症信号库角色职责：负责向系统提供病症信号的正常值角色职责识别：

(1)负责保持系统正常运行

(2)与系统交互角色：医生角色职责：对病人负责，负责处理病情的变化角色职责识别：

(1)需要系统支持以完成其日常工作

(2)对系统运行结果感兴趣角色描述27２.识别用例回答下面的问题：⑴与系统实现有关的主要问题是什么？⑵系统需要哪些输入/输出？这些输入/输出从何而来？到哪里去？⑶执行者需要系统提供哪些功能？⑷执行者是否需要对系统中的信息进行读、创建、修改、删除或存储？通过分析可以初步识别出系统的用例为：中央监护，病症监护，提供标准病症信号，病历管理，病情报告管理。顶层用例图为：28

通过分析可以初步识别出系统的用例为：中央监护，病症监护，提供标准病症信号，病历管理，病情报告管理。顶层用例图为：医院病房监护系统高层用例图值班护士医生病人标准病症信号库病症监护提供标准病症信号中央监护病历管理病情报告管理<<extend>><<include>><<include>><<include>>29进一步将用例细化，即分解用例：1.中央监护

分解:a分解信号将从病症监护器传送来的组合病症信号分解为系统可以处理的信号。

b比较信号将病人的病症信号与标准信号比较。

c报警如果病症信号发生异常（即高于峰值），发出报警信号。

d数据格式化将处理后的数据格式化以便写入病历库。2.病症监护

分解:e信号采集采集病人的病症信号。

f模数转化将采集来的模拟信号转化为数字信号。

g信号数据组合将采集到的脉搏，血压等信号数据组合为一组信号数据。

h采样频率改变根据病人的情况改变监视器采样频率。用例细化303.提供标准病症信号

i（此用例不分解）4.病历管理

分解为：j生成病历

k查看病历

l更新病历

m打印病历

5.病情报告管理

分解为：n显示病情报告

在显示器上显示病情

o打印病情报告在打印机打印病情报告用例细化31给出细化的用例图细化的用例图病人模数转化数据格式化值班护士报警信号采集比较信号标准病症信号库

医生信号数据组合采样频率改变提供标准病症信号生成病历查看病历更新病历打印病历显示病情报告打印病情报告分解信号<<Extend>><<Extend>><<Extend>><<include>><<include>><<include>><<include>><<include>><<include>><<include>><<include>>32练习一：请画出学