当前位置：文档之家 › 第5章-UML用例图

第5章-UML用例图

  • 格式：ppt
  • 大小：686.00 KB
  • 文档页数：55

下载文档原格式

  / 55

合集下载

产品需求文档的写作(五) – 用例文档(UML用例图、流程图)

产品需求文档的写作(五) – 用例文档(UML用例图、流程图)

产品需求文档的写作(五) –用例文档(UML用例图、流程图)在产品和技术领域里都有UML的技能知识，而对于产品人员的UML则更多的是指用例图，也就是我所称呼的用户流程图。

在讲PRD文档写作的第二篇文章里，我提到了用户流程图的制作，实际上用户流程图是我在产品规则的初期对用例图的一种结构化的表达方式，由于以结构化的方式描述用例太抽象，缺少逻辑性表达，并且那篇文章更偏向于功能性用户流程，还不是实际意义上的用例，因此今天我补文一篇，细讲一下UML用例图和用例文档。

用例文档是由多个用例组成的一份文档，主要用于技术开发与测试使用，他是PRD中的重要辅助文档，用于讲解某个环节的功能逻辑，例如用户注册、活动报名等等功能都是需要用例辅助说明的。

用例文档的写作时间在原型设计之后，通常和PRD文档同步撰写。

用例文档中有两个关联文件，分别是用例图和流程图。

用例图是UML的一种类图表现方式，是从用户角度描述产品功能，并指出该用户在产品各功能中的操作权限。

流程图是通过线框图形的方式描述产品功能的处理过程，主要是描述功能的执行顺序、分支和循环的逻辑。

写用户文档的常用软件是Word，其中用例图和流程图的制作软件常用的是Visio，当然也有用Axure RP软件制作的，例如下面的第三步流程图就是用Axure RP制作的。

一份完整的用例文档分别是由以下三点内容组成，其中第3点的“用例”是描述功能逻辑的部分，根据功能的多少决定有多少个用例。

用例文档的大概组成部分如下：1、修改记录：每次修改的备注记录，同PRD文档。

2、角色介绍：描述参与系统中的各个角色3、用例：同下方步骤的第4步，其中第3步中的流程图是直接插入到第4步的流程图表格项中的。

用例文档的模板格式如同以上三点内容，通过Word文档绘制表格，在表格中撰写用例描述，表格的格式和样式参考以下示例图。

1、撰写用例文档的第一步是注明使用产品的各个角色(参与者)和角色说明(角色介绍)。

第5章-UML用例图

第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）对系统产生的结果感兴趣的人或事是哪些？
UML用例图

UML用例图


用例图主要包括： 用例图主要包括：一个用例图中包括一组用例和一组参与者，主
要描述用例之间、用例与参与者之间、参与者之间的关系，还有相关 注解和约束。
用例图的六个元素： 用例图的六个元素：参与者(Actor)、用例(Use Case)、关联关系
(Association)、包含关系(Include)、扩展关系(Extend)以及泛化关系 (Generalization)。
用例(Use Case)
概念: 概念 用例是外部可见的系统功能单元,这些功能由系统单元所提供,并通过一
系列系统单元与一个或多个参与者之间交换的消息所表达.一个用例表示一个 系统中的一部分功能和行为.
用例的特征: 用例的特征
1.用例总是由一个参与者启动 参与者必须直接或间接地命令该系统执行这 用例总是由一个参与者启动: 用例总是由一个参与者启动 个用例. 2.用例为参与者提供某种结果值 用例必须向用户交付某种具体的结果值. 用例为参与者提供某种结果值: 用例为参与者提供某种结果值 3.用例是完整的 用例必须是一个完整的描述 用例是完整的: 用例是完整的
识别用例: 识别用例 最好的方法就是从分析系统的参与者开始,考虑每个参与者是如何
使用系统的.
1.特定参与者希望系统提供什么功能 2.系统是否存储和检索信息,如果是,由哪个参与者触发 3.当系统改变状态时,是否通知参与者 4.是否存在影响系统的外部事件 5.哪个参与者通知系统这些事件
用例和事件流
事件流是什么:事件流是用来为用例的逻辑流程建立文档.这个文档
用例和事件流:用例分析处于系统的需求分析阶段,这个阶段应该尽
量避免考虑系统实现的细节问题.但是要实际建立系统,就需要更加具 体的细节,所以就将这些细节写到事件流文件中去.
UML用例图的基本概念

UML用例图的基本概念

UML通过统一的符号和图形表示，将复杂的软件系统分解为 更小、更易于理解的组件，帮助开发人员更好地理解和管理 复杂的软件系统。
UML的用途
需求分析
UML可以帮助开发人员更好地理 解客户需求，通过用例图等工具 将客户需求转化为可执行的用例。
系统设计
UML可以帮助开发人员在系统设 计阶段进行系统架构和组件的设 计，通过类图、时序图等工具进 行系统的分析和设计。
05
案例分析
案例一：简单登录系统用例图分析
总结词：简单明了
详细描述：简单登录系统通常包括用户名和密码输入、验证和登录成功或失败的反馈等基本功能。在 UML用例图中，可以清晰地表示出系统的主要功能和参与者的角色。
案例二：网上购物系统用例图分析
总结词：复杂多样
详细描述：网上购物系统涉及到多个参与者，如顾客、管理员和供应商等，以及多种复杂的业务功能，如商品展示、购物车 管理、订单处理和支付等。在UML用例图中，需要对各个功能进行详细的描述和分类，以便更好地理解系统的结构和功能。
用例图在系统设计中的应用
架构设计
用例图可以用于指导系统的架构设计，通过分析用例之间 的关系和交互，设计系统的组件和模块结构。
01
接口设计
用例图可以帮助设计系统组件之间的接 口，明确组件之间的输入输出关系和交 互协议。
02
03
系统流程设计
用例图可以用于描述系统的流程，通 过分析用例的执行顺序和交互逻辑， 设计系统的流程和顺序结构。
用例图在需求分析中的应用
1 2
沟通工具
用例图作为一种可视化图形表示，可以作为沟通 工具，帮助开发团队、客户和利益相关者理解系 统的需求和功能。
需求确认
通过绘制用例图，可以与利益相关者讨论和确认 系统的需求，确保对需求的理解和期望是一致的。
UML 用例图的基本概念

UML 用例图的基本概念

系统名称 参与者
用例
UML建模语言
5.2.3 用例 1. 用例的概念 用例（Use Case）是参与者（角色）可以感 受到的系统服务或功能单元。
带路径名的用例
UML建模语言
2. 用例的识别
任何用例都不能在缺少参与者的情况下独 立存在。同样，任何参与者也必须要有与 之关联的用例，所以识别用例的最好方法 就是从分析系统参与者开始，在这个过程 中往往会发现新的参与者。
细化后 的学生 管理系 统
UML建模语言
4. 用例规约
用例图只是在总体上大致描述了系统所提 供的各种服务，让用户对系统有一个总体 的认识。但对于每一个用例还需要有详细 的描述信息，以便让其他人对于整个系统 有一个更加详细地了解，这些信息包含在 用例规约之中。而用例模型指的也不仅仅 是用例图，而是由用例图和每一个用例的 详细描述——用例规约所组成的。
1. 参与者的概念 2. 参与者的确定 3. 参与者间的关系
UML建模语言
1.参与者的概念
参与者（Actor）是指存在于 系统外部并直接与系统进行交 互的人、系统、子系统或类的 外部实体的抽象。
UML建模语言
2. 参与者的确定
在获取用例前首先要确定系统的参与者，寻找参与者可 以从以下问题入手： .系统开发出来后，使用系统主要功能的是谁？ .谁需要借助系统来完成日常的工作？ .系统需要从哪些人或其他系统中获得数据？ .系统会为哪些人或其他系统提供数据？ .系统会与哪些其他系统交互？其他系统可以分为两类， 一类是该系统要使用的系统，二是启动该系统的系统， 包括计算机系统和计算机中的其他应用软件。 .系统是由谁来维护和管理的，以保证系统处于工作状 态？ .系统控制的硬件设备有哪些？ .谁对本系统产生的结果感兴趣？
软件工程 第5章--UML

软件工程 第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 种视图，各 视图在静态和动态方面表示系统模型。
结构 视图 静态 方面
动态 方面
行为 视图 同左
实现 视图 构件图
环境 视图 部署图
同左
用例 视图 用例图
同左
类图 对象图
顺序图 同左 顺序图 合作图 (注重 合作图 状态图 进程、 状态图 活动图 线程) 活动图
UML05用例图模板

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 获取用例
一旦获取了参与者,就可以对每个参与者提出问题以获取用例。 •执行者要求系统提供哪些功能(执行者需要做什么)? •执行者需要读、产生、删除、修改或存储的信息有哪些类型。 •必须提醒执行者的系统事件有哪些? 或者执行者必须提醒系统 的事件有哪些? 怎样把这些事件表示成用例中的功能? •为了完整地描述用例,还需要知道执行者的某些典型功能能否 被系统自动实现? 还有一些不针对具体参与者问题(即针对整个系统的问题): •系统需要何种输入输出? 输入从何处来? 输出到何处? •当前运行系统(也许是一些手工操作而不是计算机系统)的主要 问题?
需求分析——UML用例图PPT课件

需求分析——UML用例图PPT课件

-32-
第32页/共84页
要点：用例止于系统边界
描述交互，而不是内在的系统活动
-33-
第33页/共84页
要点：有意义的目标
设定查询条件
会员
选择零件
会员
检索零件
-34-
第34页/共84页
要点：结果值由系统生成
出纳员
吃饭
系统需要处理的，由系统生成
-35-
第35页/共84页
要点：业务语言而非技术语言
• “非程序员杂志”第26到30期UML工具一览，列出了约129个UML开发工具
-7-
第7页/共84页
内容安排
• UML概述 • 理解需求 • 需求，难在何处？ • 以用例为中心组织需求 • 基于用例的需求分析过程
-8-
第8页/共84页
认识问题
分析问题
解决问题
以开发者的身份站在开发团队的 角度分析问题
Booch93 OMT-2
统一 化
Booch91 OMT-1 其他方法 OOSE
分散
的
Grady Booch Jim Rumbaugh
第4页/共84页
Ivar Jacobson各 部
分
-4-
UML发展现状
• 目前通用的是UML 1.x版 • 主要UML 1.3、UML 1.4 • 2003年3月正式发布UML 1.5
-24-
第24页/共84页
相关术语
场景：是用来描述用户和系统之间交互的顺序的步骤 用例：是为了达到某一用户目标而组合在一起的一组场景
用例图：用来显示在系统（或其它实体）内的用例与系统参与者之间的关系
用例模型：是系统既定功能及系统环境的模型，并作为客户和开发人员之间的契 约。用例模型用作分析、设计和测试活动的基本输入。
UML图例之用例图

UML图例之用例图

UML图例之⽤例图 ⽤例图主要⽤来描述“⽤户、需求、系统功能单元”之间的关系，在需求分析阶段，常会借助⽤例图，从⽤户的⾓度描述系统的功能，以图形可视化的⽅式作为开发团队与客户的交流，同时也有助于形成统⼀语⾔。

⼀、⽤例图描述 ⽤例图（Use Case Diagrame）：描述了⼈们希望如何使⽤⼀个系统，将相关⽤户、⽤户需要系统提供的服务以及系统需要⽤户提供的服务更清晰的显⽰出来，以便使系统⽤户更容易理解这些元素的⽤途，也便于开发⼈员最终实现这些元素。

之所以说⽤例图⾄关重要，是由于⽤户并不关⼼系统的实现和内部结构，只关⼼产品所呈现出来的外部特征动态。

⽽⽤例图恰好就是描述软件产品外部特性的视图，它从⽤户的⾓度⽽不是从开发者的⾓度来描述需求，分析产品的功能和动态⾏为。

⼆、基本元素1、参与者(Actor)，在系统外部与系统直接交互的⾓⾊或外部系统。

可通过与客户的沟通交流，确定利益相关⼈，进⽽确定参与者。

⾓⾊：通常是具体⼈承担着⾓⾊，这是最常见的参与者。

外部系统：如CRM系统要操作OA系统，以⽅便发送通知，那么针对OA系统的调⽤，CRM系统作为外部系统这⼀参与者。

时间：如存在定时任务操作或者类似操作等，则时间作为参与者2、⽤例客户通过对需求的描述(主要为功能需求)，开发团队通过⽤例来体现系统功能和服务，通过参与者与⽤例的交互，来达到客户与开发团队的⽬标⼀致。

3、关联关系1）参与者与参与者间的泛化关系⽐如腾讯⽤户，包括微信⽤户和QQ⽤户两部分，但是使⽤腾讯业务时，只需要是腾讯⽤户即可，此时，可以采⽤泛化关系，采⽤三⾓空⼼箭头作为指向。

2）参与者与⽤例间的关联关系参与者与⽤例间是简单的关联关系，⼀个参与者可以有着多个⽤例3）⽤例与⽤例间的泛化关系⽤例之间可以存在泛化关系，⽐如常见的⽀付，可以选择微信⽀付、⽀付宝⽀付等等，但是这个操作就是⽀付。

泛化关系采⽤三⾓空⼼箭头。

4）⽤例与⽤例间的包含关系包含关系⽤来把⼀个较复杂⽤例所表⽰的功能分解成较⼩的步骤。

第5章 用例图

第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用例图

uml用例图


取款
查询
持有银行信 用卡的自动 取款机用户
转账
银行客户
图 ATM用例图
图 银行客户注释图
用例图的基本概念
5.1.2 用例图的作用
用例图是需求分析中的产物，主要作用是描述参与者和用例之间的关系， 用例图是需求分析中的产物，主要作用是描述参与者和用例之间的关系， 帮助开发人员可视化地了解系统的功能。减少了大量交流上的障碍， 帮助开发人员可视化地了解系统的功能。减少了大量交流上的障碍，便于 对问题达到共识。 对问题达到共识。
用例名
2.用例的识别
可以通过以下问题来寻找用例？ 参与者希望系统提供什么功能？ 参与者希望系统提供什么功能？ 参与者是否会读取、创建、修改、删除、存储系统的某种信息？ 参与者是否会读取、创建、修改、删除、存储系统的某种信息？如果 是的话，参与者又是如何完成这些操作的？ 是的话，参与者又是如何完成这些操作的？ 参与者是否会将外部的某些事件通知给系统？ 参与者是否会将外部的某些事件通知给系统？ 系统中发生的事件是否通知参与者？ 系统中发生的事件是否通知参与者？ 是否存在影响系统的外部事件？ 是否存在影响系统的外部事件？
基础用例
扩展用例
《 extend》
扩展关系
3.泛化
用例的泛化指的是一个父用例可以被特化形成多个子用例，而父用例和子用例之间的 关系就是泛化关系。在UML中，用例的泛化关系通过一个从子用例指向父用例的三角箭头 来表示：
父用例
子用例
泛化关系
5.3 用例图的创建概述
5.3.1 5.3.2 5.3.3 5.3.4 创建用例图 创建参与者 创建用例 创建用例之间的关联
课程回顾
用例图的基本概念 用例图的组成 用例图的创建概述 用例图的创建示例

UML建模——用例图（UseCaseDiagram）

UML建模——⽤例图（UseCaseDiagram）⽤例图主要⽤来描述⾓⾊以及⾓⾊与⽤例之间的连接关系。

说明的是谁要使⽤系统，以及他们使⽤该系统可以做些什么。

⼀个⽤例图包含了多个模型元素，如系统、参与者和⽤例，并且显⽰这些元素之间的各种关系，如泛化、关联和依赖。

它展⽰了⼀个外部⽤户能够观察到的系统功能模型图。

【⽤途】：帮助开发团队以⼀种可视化的⽅式理解系统的功能需求。

⼀、⽤例图所包含的的元素1. 参与者(Actor)——与应⽤程序或系统进⾏交互的⽤户、组织或外部系统。

⽤⼀个⼩⼈表⽰。

2. ⽤例(Use Case)——⽤例就是外部可见的系统功能，对系统提供的服务进⾏描述。

⽤椭圆表⽰。

3. ⼦系统(Subsystem)——⽤来展⽰系统的⼀部分功能，这部分功能联系紧密。

⼆、⽤例图所包含的的关系 ⽤例图中涉及的关系有：关联、泛化、包含、扩展。

如下表所⽰： a. 关联(Association) 表⽰参与者与⽤例之间的通信，任何⼀⽅都可发送或接受消息。

【箭头指向】：⽆箭头，将参与者与⽤例相连接，指向消息接收⽅ b. 泛化(Inheritance) 就是通常理解的继承关系，⼦⽤例和⽗⽤例相似，但表现出更特别的⾏为；⼦⽤例将继承⽗⽤例的所有结构、⾏为和关系。

⼦⽤例可以使⽤⽗⽤例的⼀段⾏为，也可以重载它。

⽗⽤例通常是抽象的。

在实际应⽤中很少使⽤泛化关系，⼦⽤例中的特殊⾏为都可以作为⽗⽤例中的备选流存在。

【箭头指向】：指向⽗⽤例 c. 包含(Include) 包含关系⽤来把⼀个较复杂⽤例所表⽰的功能分解成较⼩的步骤。

包含关系对典型的应⽤就是复⽤，也就是定义中说的情景。

但是有时当某⽤例的事件流过于复杂时，为了简化⽤例的描述，我们也可以把某⼀段事件流抽象成为⼀个被包含的⽤例；相反，⽤例划分太细时，也可以抽象出⼀个基⽤例，来包含这些细颗粒的⽤例。

这种情况类似于在过程设计语⾔中，将程序的某⼀段算法封装成⼀个⼦过程，然后再从主程序中调⽤这⼀⼦过程。

第五章 用例图

泛化关系的含义是把某些参与者的共同行为提取出来表示成通用 行为，并描述成超类。泛化关系表示的是参与者之间的一般/特殊 关系，在UML图中，使用带空心三角箭头的实线表示泛化关系。
7
用例图的构成要素
3. 系统边界
在项目开发过程中，边界是一个非常重要的概念。这里说的系统边界是指系统与 系统之间的界限。通常我们所说的系统可以认为是由一系列的相互作用的元素形 成的具有特定功能的有机整体。
和系统管理三大管理功能。 1. 项目管理包括项目的增加、删除、更新。 2. 资源管理包括对资源和技能的添加、删除
和更新。 3.系统管理包括系统的启动和关闭，数据的
存储和备份等功能。
说明：技能表示人力资源。
19
1. 分析确定系统的执行者(角色) 到确定
项目管理员、资源管理员、系统管理 员、备份数据系统。
1. 病症监视器可以将采集到的病症信号（组合），格式化后实时的传送到 中央监护系统。
2. 中央监护系统将病人的病症信号开解后与标准的病症信号库里的病症信 号的正常值进行比较，当病症出现异常时系统自动报警。
3. 当病症信号异常时，系统自动更新病历并打印病情报告。
4. 值班护士可以查看病情报告并进行打印。
23
例2 医院病房监护系统
监视病情
产生 病情报告
经 1.过请监初对视步系病的统员需需的求求病进分症行析（分，血析得！压到、系体统温功、能脉要搏求等：） 2. 定时更新病历 3. 病员出现异常情况时报警。 4. 随机地产生某一病员的病情报告。
更新病历
24
二、简单的需求分析说明
需求分析
对“医院病房监护系统”进行分析，确定系统的主要功能如下：
第五章 用例图
1
学习内容

UML用例图

UML用例图UML 用例图：准则在 Visual Studio 旗舰版中，可以绘制“用例图”来概括使用您的应用程序或系统的用户以及该应用程序或系统的用途。

若要创建UML 用例图，请在“体系结构”菜单上，单击“新建关系图”。

用例图有助于讨论和传达以下内容：您的系统或应用程序与人、组织或外部系统进行交互的几种方案。

它帮助参与者实现的目标。

系统的范围。

用例图不显示用例的详细信息：它只概括用例、参与者和系统之间的某些关系。

特别是，用例图不显示每个用例为实现目标所执行步骤的顺序。

可以在其他关系图和文档中描述这些详细信息，这些关系图和文档可与各用例相链接。

有关更多信息，请参见本主题中的详细描述用例。

您为用例提供的描述将使用与系统所用于的领域相关的一些词汇，如“销售”、“菜单”、“顾客”等。

明确定义这些词汇及其关系是非常重要的，您可以借助 UML 类图来进行定义。

有关更多信息，请参见 UML 类图：准则。

用例只处理系统的功能要求。

诸如业务规则、服务质量要求和实现约束等其他要求必须另外表示。

体系结构和内部细节也必须另外说明。

有关如何定义用户需求的更多信息，请参见用户需求建模。

本主题中使用的示例与顾客可在其上从本地餐馆订餐的网站有关。

“参与者”(1) 是与您的系统进行交互的一类人、组织、设备或外部软件组件。

例如，“顾客”、“餐馆”、“温度传感器”、“信用卡授权方”都是参与者。

“用例”(2) 表示一个或多个参与者为实现特定目标而执行的操作。

例如，“订餐”、“更新菜单”、“处理付款”都是用例。

在用例图中，用例与执行它们的参与者相关联 (3)。

“系统”(4) 是您开发的任何成果。

系统可以是小型软件组件，其中的参与者只是其他软件组件；系统也可以是完整的应用程序；系统还可以是部署在多台计算机和设备上的大型分布式应用程序套件。

例如，“订餐网站”、“送餐业务”、“网站版本2”都是子系统。

用例图可以显示系统或其子系统支持的用例。

第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. 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。

5.2 UML包含的内容
5.2.3 用例图2-.用用例例的粒度
• 用例的粒度
• 比如：网站后台管理系统中的会员信息维护用例，管理员需要进 行添加会员信息、修改会员信息、删除会员信息等操作。
• 还可以根据具体的操作把它抽象成3个用例，它展示的系统需求 和单个用例是完全一样的。
5.2 UML包含的内容
• (10) 例外：描述该用例执行过程中可能出现的意外情况。例如，没有查找出期望的数据而导 致的计算终止。对于每个例外，应该知道它所发生的环境和应该采取的措施。
• (11) 限制：描述执行用例的限制。例如，为用例分配的资源可能受到限制。还有，要求用例 中必须保持某种条件为真，违反这些条件就会引起错误。例如，公司职员数量要为正数。
• 用例图清楚地描述了使用者及它们之间的泛化关系，用例及用例 之间的泛化、扩展关系，用例和参与者之间的关联关系，可从用 例图中得到对于被定义系统的一个总体印象。
5.2 UML包含的内容
5.2.3 用例图
用例图主要包括3个部分： 用例（User Case） 参与者（Actor） 关系
AssociationName UseCaseName
顺序图
描述对象之间的交互，重点在强调顺序
通信图
描述对象之间的交互，重点在于连接
定时图
描述对象之间的交互，重点在于定时
交互概观图 是一种顺序图与活动图的混合
备注
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 UML包含的内容
5.2.3 用例图3-用. 例用例规约
• (8) 细节（事件流）：详细的描述交互序列。细节要描述参与者与用例的一步步的交互，每 一步要提供充分的内容，用于说明涉及哪些实体、针对每个实体做了什么事，以及这一步的 结果。若用例较为复杂，要区分出基本流程和可选流程。
• (9) 后置条件：描述在用例结束时确保成立的条件。执行用例的目的是要产生一些预计的值 或者状态，用后置条件明确地标识执行该用例后的预期结果。
再者，有时会包含数条“可选流程（alternative course）” 用 来描述错误的、异常的状况。
除此之外，用例描述格式可自由制定。
5.2 UML包含的内容
5.2.3 用例图3-用. 例用例规约
• 按照国家电子信息行业标准《面向对象的软件系统建模规范——第三部 分：文档编制》的要求，下面给出用于描述用例的模板。
注意：参与者可以是人，也可以是外部系统或其它设备。
5.2 UML包含的内容
5.2.3 用例图5-.2参.与1者参与者
• 参与者有三大类：
– 第一类参与者是真实的人，即用户，是最常见的参与者，几 乎存在于每一个系统中。
– 第二类参与者是其他的系统。这类位于程序边界之外的系统 也是参与者。
– 第三类参与者是一些可以运行的进程。如时间，当经过一定 的时间触发系统中的某个事件时，时间就成了参与者。
5.2.3 用例图-用例
用例描述
用例图只能告诉我们系统应具有的功能及参与者，让用户对系统 有一个总体的认识。而没有说明用例的执行过程。
因此，对于每一个用例，我们还需要有详细的描述信息，以便让 别人对于整个系统有一个更加详细的了解。
UML是一套标准的图形语言，其中只提出了13种图，没有将用例 描述考虑在内，也当然没有任何标准的用例描述格式了。
• 要在用例图上绘制一个参与者（表示一个系统用户）， 可绘制一个人形符号。
5.2 UML包含的内容
5.2.3 用例图
• 参与者和用例之间的关系使用带箭头或者不带箭头的线段来描述，箭 头表示在这一关系中哪一方是对话的主动发起者，箭头所指方是对话 的被动接受者。如果不想强调对话中的主动与被动关系，可以使用不 带箭头的线段。
5.2.3 用例图
• 由参与者（Actor）、用例（Use Case）以及 它们之间的关系构成的用于描述系统功能的动 态视图称为用例图。
• 用例和参与者之间的对应关系叫做通信关联， 它表示参与者使用了系统中的哪些用例。
5.2 UML包含的内容
5.2.3 用例图
• 要在用例图上显示某个用例，可绘制一个椭圆，然后 将用例的名称放在椭圆的中心或椭圆下面的中间位置。
UML2.0的图型
图名
功能
类图
描述类、类的特性以及类之间的关系
对象图
描述一个时间点上系统中各个对象的一个快照
复合结构图 描述类的运行时刻的分解
组件图
描述组件的结构与连接
部署图
描述在各个节点上的部署
包图
描述编译时的层次结构
用例图
描述用户与系统如何交互
活动图
描述过程行为与并行行为
状态机图 描述事件如何改变对象生命周期
5.2.1 参与者
• 通过泛化关系可以减少参与者和用例之间的关联的 次数，简化用例模型。
5.2 UML包含的内容
5.2.3 用例图-用例
用例（Use case）是从系统外部可见的行为，是参与者可以 感受到的系统服务或功能单元。它定义了系统是如何被参与者 使用的，描述了参与者为了使用系统所提供的某一完整功能而 与系统之间发生的一段对话。
• 当找到参与者之后可以根据参与者确定系统的用例，主要是看各 参与者如何使用系统，需要系统提供什么样的服务。
5.2 UML包含的内容
5.2.3 用例图-用例
• 可以通过以下问题来寻找用例：
(1)参与者希望系统提供什么功能？ (2)参与者是否会读取、创建、修改、删除、存储系统的某种信 息？如果是的话，参与者又是如何完成这些操作的？ (3)参与者是否会将外部的某些事件通知给系统？ (4)系统中发生的事件是否通知参与者？ (5)是否存在影响系统的外部事件？
• 用例图可视化地表达了系统的需求，具有直观、规范等优点，克 服了纯文字性说明的不足。
5.2 UML包含的内容
5.2.3 用2例.图用例图的作用
用例图的作用
• 用例方法是完全从外部来定义系统功能，它把需求和设计完全的 分离开来。我们不用关心系统内部是如何完成各种功能的，系统 对于我们来说就是一个黑箱子。
5.2 UML包含的内容
5.2.3 用例图-用例
• 注意：用例的主要目的是帮助人们了解系统功能，便于开发人员 与用户之间的交流，所以确定用例的一个很重要的标准就是用例 应该易于理解。
• 对于同一个系统，不同的人对于参与者和用例可能会有不同的抽 象，这就要求在多种方案中选出最好的一个。
5.2 UML包含的内容
用例最大的优点是站在用户的角度上（从系统的外部）来描 述系统的功能。它把系统当作一个黑箱子，并不关心系统内部 是如何完成它所提供的功能，表达了整个系统对外部用户可见 的行为。
5.2 UML包含的内容
5.2.3 用例图-用例
• 用例的特征：
– 用例必须由某一个参与者触发激活后才能执行，即每个用例 至少涉及一个参与者。
5.2 UML包含的内容
5.2.3 用例图
用例图主要用于为系统的功能需求建模，它主要描述系统功能， 也就是从外部用户的角度观察，系统应该完成哪些功能。
用例图可以帮助开发人员以一种可视化的方式理解系统的功能 需求，是后续的系统分析与设计工作的依据。
用例图是对系统功能的一个宏观描述，画好用例图是由软件需 求到最终实现的第一步，也是最重要的一步。
5.2 UML包含的内容
5.2.3 用例图-参与者
如何确定参与者？
（1）使用系统主要功能的人是谁（即主要角色）？ （2）需要借助于系统完成日常工作的人是谁？ （3）谁来维护和管理系统（次要角色），保证系统正常工作？ （4）系统控制的硬件设备有哪些？ （5）系统需要与哪些其它系统交互？其它系统包括计算机系统，也包 括该系统将要使用的计算机中的其它应用软件。其它系统也分成二类， 一类是启动该系统的系统，另一类是该系统要使用的系统。 （6）对系统产生的结果感兴趣的人或事是哪些？
• 注意：包、注释都不是用例图的基本组成要素，但在 用例建模过程中可能会用到它们。
5.2 UML包含的内容
5.2.3 用例图
用例图的作用
• 用例图是需求分析中的产物，主要作用是描述参与者和用例之间 的关系，帮助开发人员可视化的了解系统的功能。
• 借助于用例图，系统用户、系统分析人员、系统设计人员、领域 专家能够以可视化的方式对问题进行探讨，减少了大量交流上的 障碍，便于对问题达成共识。
ActorName (From Use Case View)
(From Use Case View)
5.2 UML包含的内容
5.2.3 用例图-参与者
参与者（Actor）是指存在于系统外部并直接与系统进行交互的 人、系统、子系统或类的外部实体的抽象。
每个参与者可以参与一个或多个用例，每个用例也可以有一个或 多个参与者。
5.2 UML包含的内容
5.2.3 用例图
类图 类(class)
关联(association) 系统的内观(里子)
静态结构 稳定成长
用例图 用例(use case)、参与者(actor) 包含(include)、扩展(extend)
系统的外观(面子) 动态功能 变化迅速
类5.2.3 用例图2-.用用例例的粒度
• 用例的粒度
• 用例的粒度指的是用例所包含的系统服务或功能单元的多少。用 例的粒度越大，用例包含的功能越多，反之则包含的功能越少。
• 如果用例的粒度很小，得到的用例数就会太多。会造成用例模型 过大和设计困难大大提高。
• 反之，如果用例的粒度很大，那么得到的用例数就会很少，不便 于进一步的充分分析。
5.2 UML包含的内容