用例图可视化地表达了系统的需求，具有直观、规范 等优点，克服了纯文字性说明的不足。
用例方法是完全从外部来定义系统功能，它把需求和 设计完全的分离开来。我们不用关心系统内部是如何 完成各种功能的，系统对于我们来说就是一个黑箱子。
用例图的构成要素
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)
角色描述
通过回答这六个问题以后，再进一步分析可以识别出本系统的四个角色：值班 护士，医生，病人，标准病症信号库。