UML系统用例及用例关系解析
UML-6.2-用例-用例模型用例场景关系
UML-6.2-用 -用例模型用例场景关系
参与者：具有某些行为的人或事物。如上一章中的收银员。 |_主要参与者：收银员。 |_协助参与者：程序（自动付费、帮收银员验证输入要素） |_幕后参与者：政府等（电子签章取证找公证机构）
用例：一组相关的成功和失败的场景集合。 场景：用例中的某条执行路径。 用例模型：用例的集合
比如： 用例：退货 场景1：退货成功 场景2：退货失败时怎么办
用例不是面向对象的。但是OOA/D的关键输入。
用例解决的问题是：“谁使用系统？”、“目的是什么？”、“他们使用的典型场景是什么？”
简述uml用例间的关系
简述uml用例间的关系UML（Unified Modeling Language）是一种用于软件开发的建模语言，它提供了一种标准的图形化表示方法，用于描述系统的结构、行为和交互。
在UML中，用例图是一种常用的图形化表示方式，用于描述系统的功能需求和用户与系统之间的交互。
用例间的关系是指不同用例之间的相互关联和影响。
在UML中，用例间的关系有以下几种：1. 包含关系（Include）：表示一个用例包含另一个用例的功能。
当一个用例需要借用其他用例的功能时，可以使用包含关系来表示。
例如，一个购物车用例可能包含了添加商品、移除商品和结算等子用例。
2. 扩展关系（Extend）：表示一个用例可以在特定条件下扩展另一个用例的功能。
当一个用例的某个功能在特定条件下可以被扩展时，可以使用扩展关系来表示。
例如，一个支付用例可以在用户选择使用优惠券时扩展结算用例的功能。
3. 泛化关系（Generalization）：表示一个用例是另一个用例的特殊情况或特化。
当一个用例继承了另一个用例的功能，并且在此基础上添加了新的功能时，可以使用泛化关系来表示。
例如，一个在线购物系统中的用户登录和游客购物两个用例可以通过泛化关系来表示，游客购物是用户登录的特殊情况。
4. 关联关系（Association）：表示不同用例之间的关联和交互。
当一个用例需要与其他用例进行交互时，可以使用关联关系来表示。
例如，在一个社交网络系统中，用户发布动态和用户评论动态两个用例可以通过关联关系来表示。
5. 依赖关系（Dependency）：表示一个用例依赖于另一个用例。
当一个用例的实现依赖于其他用例时，可以使用依赖关系来表示。
例如，在一个在线购物系统中，购物车结算用例依赖于查看购物车用例。
6. 一般化关系（Realization）：表示一个用例实现了另一个用例的功能。
当一个用例实现了另一个用例定义的接口和行为时，可以使用一般化关系来表示。
例如，一个在线支付系统可以实现支付用例定义的支付接口和行为。
UML 用例图、关系图、活动图
例如，一个银行系统中，有
一个“验证用户”用例，用 身份认证
于验证用户的合法性，它有
两 个 特 殊 的 子 用 例 ， 一 个 是 密码认证
指纹认证
“检查密码”，另一个是
“检查指纹”，它们都有父
用例“验证用户”的行为，
并且可以出现在父用例出现
的任何地方，还可以添加自
己的行为。
用例图实例
• 以前面图书信息管理系统为例，画出用例 图。先找出参与系统地的角色：
• 扩展关系——允许一个用例扩展另一个用
例的功能。例如，在图书信息管理系统中，
读者还书时，系统检查所还图书是否有预
订记录，如果有则执行“通知”用例。在
UML中扩展关系表示为箭头和《extend》形
式。
《extend》
还书
通知
管理员
读者
注意
• 使用关系和扩展关系之间的区别，A使用B 本质上是A一定使用B，同时增加自己的专 属行为；而A被用例B扩展是说明A是一个一 般用例，B是一个特殊用例，A在某些条件 下可能使用B。
（2）取消预订——本用例提供取消预订图书的功能。
（3）还书——完成还书任务，在还书是要检查所还的书是否超 期、是否有其他读者预订，有的话要通知预订者。
（4）借书——提供借阅书功能 。
• 分析这个用例图，发现“还书”用例应该 被扩展，因为在还书时检查所还图书是否 有预订记录，若有，则应该通知预订者前 来借书。
• 一个用例内部的具体处理细节是由其他图形工具描述 的，用例图只是反映系统的总体功能，以及与这些功 能的相关的角色。有些人可能在画“借书”用例时， 情不自禁地就考虑了“输入读者号和书号”，“检查 图书是否在库？”，“图书数量减1”，“添加读者借 书记录”等等，一旦考虑了这些细节，就会发现用例 图画不下去了。因此，读者注意用例图中不要考虑处 理细节。
UML中的用例图实践案例
UML中的用例图实践案例UML（统一建模语言）是一种用于软件开发的标准化建模语言，它提供了一套丰富的图形符号和概念，用于描述和设计软件系统的各个方面。
其中，用例图是UML中最为常用和重要的一种图形表示方法，它用于描述系统的功能需求和用户与系统之间的交互关系。
本文将通过一个实践案例，介绍用例图在软件开发中的具体应用。
假设我们要开发一个在线购物系统，该系统包括用户注册、浏览商品、添加购物车、下单、支付等功能。
首先，我们需要明确系统的角色和用例。
在这个案例中，系统的角色包括用户、管理员和支付网关。
用户可以注册账号、浏览商品、添加购物车、下单和支付；管理员可以管理商品信息；支付网关负责处理支付请求。
接下来，我们可以使用用例图来表示这些角色和用例之间的关系。
首先，我们可以在用例图中用椭圆形表示各个用例。
在本案例中，我们可以用椭圆形表示注册账号、浏览商品、添加购物车、下单和支付等用例。
然后，我们可以用矩形表示各个角色，即用户、管理员和支付网关。
接着，我们可以使用实线箭头来表示角色与用例之间的关系。
例如，用户可以注册账号，我们可以在用户和注册账号之间画一条实线箭头来表示这种关系。
除了角色和用例之间的关系，用例图还可以表示用例之间的关系。
在本案例中，用户可以浏览商品、添加购物车、下单和支付，这些用例之间存在一定的先后顺序。
我们可以使用虚线箭头来表示这种顺序关系。
例如，用户可以先浏览商品，然后将商品添加到购物车，最后下单和支付。
我们可以在浏览商品和添加购物车之间画一条虚线箭头，表示用户在浏览商品后可以将商品添加到购物车。
此外，用例图还可以表示用例之间的包含和扩展关系。
在本案例中，用户下单时可能需要选择配送地址，我们可以将选择配送地址作为一个包含关系，用一个带有加号的实线箭头表示。
另外，用户下单时还可以选择使用优惠券，这可以作为一个扩展关系，用一个带有箭头和加号的虚线箭头表示。
通过用例图，我们可以清晰地描述系统的功能需求和用户与系统之间的交互关系。
uml用例之间的关系
uml用例之间的关系UML（Unified Modeling Language）是一种用于软件系统建模的标准化语言，它可以通过图形化的方式描述系统的结构、行为和交互关系。
在UML中，用例是对系统功能的一种描述，用例之间的关系充满着指导和解释作用。
下面将具体介绍几种常见的用例之间的关系。
1. 包含关系（Includes）：包含关系是一种用例之间的关系，表示一个用例包含了另一个用例的行为。
通常情况下，一个用例（被包含用例）在执行过程中会调用另一个用例（包含用例）来完成一部分功能。
例如，在一个购物系统中，用户下单时可能会调用一个包含了支付用例的用例。
2. 扩展关系（Extends）：扩展关系也是一种用例之间的关系，表示一个用例可以在另一个用例的基础上进行扩展。
扩展用例在被扩展用例中定义了一些额外的行为，这些行为可以根据系统需求的变化来进行扩展。
例如，在一个社交网络系统中，用户发表动态的用例可以根据用户需求扩展为带有图片上传功能的动态。
3. 泛化关系（Generalization）：泛化关系是一种用于表示继承关系的关系，用于描述一组具有共同特征的用例之间的关系。
泛化用例通常描述了一组具有相似功能的用例，并从中提取出了共同的特征，作为基础用例。
例如，在一个银行系统中，取款用例和存款用例可以被抽象为基本用例-交易用例，其共同的特征是对用户账户进行操作。
4. 关联关系（Association）：关联关系是一种用例之间的关系，表示两个用例之间存在某种关联或依赖关系。
这种关联关系可以是双向的，也可以是单向的。
例如，在一个电子商务系统中，用户注册和登录用例可能存在关联关系，因为用户需要先注册才能登录系统。
综上所述，UML用例之间的关系对于系统分析与设计非常重要。
通过对用例之间的关系进行建模，可以帮助系统开发人员更好地理解系统的功能和行为，并指导团队的开发工作。
不同的用例关系表示了不同的依赖和交互方式，开发人员可以根据具体的需求情况选择适合的关系建模，以实现系统的需求和目标。
UML用例图用例描述详解
UML用例图用例描述详解描述用例规约应该避免这样一种误解――认为由参与者和用例构成的用例图就是用例模型，用例图只是在总体上大致描述了系统所能提供的各种服务，让我们对于系统的功能有一个总体的认识。
除此之外，我们还需要描述每一个有例的详细信息，这些信息包含在用例规约中，用例模型是由用例图和每一个用例的详细描述――用例规约所组成的。
RUP中提供了用例规约的模板，每一个用例的用例规约都应该包含以下内容：•简要说明(Brief Description)简要介绍该用例的作用和目的。
•事件流(Flow of Event)包括基本流和备选流，事件流应该表示出所有的场景。
•用例场景(Use-Case Scenario)包括成功场景和失败场景，场景主要是由基本流和备选流组合而成的。
•特殊需求(Special Requirement)描述与该用例相关的非功能性需求（包括性能、可靠性、可用性和可扩展性等）和设计约束（所使用的操作系统、开发工具等）。
•前置条件(Pre-Condition)执行用例之前系统必须所处的状态。
•后置条件(Post-Condition)用例执行完毕后系统可能处于的一组状态。
用例规约基本上是用文本方式来表述的，为了更加清晰地描述事件流，也可以选择使用状态图、活动图或序列图来辅助说明。
只要有助于表达的简洁明了，就可以在用例中任意粘贴用户界面和流程的图形化显示方式，或是其他图形。
如活动图有助于描述复杂的决策流程，状态转移图有助于描述与状态相关的系统行为，序列图适合于描述基于时间顺序的消息传递。
基本流基本流描述的是该用例最正常的一种场景，在基本流中系统执行一系列活动步骤来响应参与者提出的服务请求。
我们建议用以下格式来描述基本流：1) 每一个步骤都需要用数字编号以清楚地标明步骤的先后顺序。
2) 用一句简短的标题来概括每一步骤的主要内容，这样阅读者可以通过浏览标题来快速地了解用例的主要步骤。
在用例建模的早期，我们也只需要描述到事件流步骤标题这一层，以免过早地陷入到用例描述的细节中去。
UML用例图中的关系
UML用例图中的关系用例之间的关系做一个总结。
1、关联关系（association）：用带箭头的实线表示，由参与者指向用例。
关联关系是指参与者与用例之间的关系，是参与者和用例之间的通信。
一个参与者可以关联多个用例，一个用例可以关联多个参与者。
但是每一对参与者和用例之间（即一条连线上）的通信必须是唯一的，否则则存在可以合并的参与者或者用例。
2、泛化关系（dependency）：用带空心三角形的实线表示，由子级指向父级。
泛化关系是参与者于参与者之间或者用例于用例之间的关系。
泛化即继承关系，子用例（子参与者）继承了父用例（父参与者）的一切行为和通信。
同时还可以增加属于自己独有的行为和通信。
以机房收费系统中的三个参与者为例。
操作员继承了一般用户的所有功能，同时增加了充值、工作记录查询等功能。
而管理员则继承了操作员的一切功能，同时增加了结账和报表生成等功能。
用例图如下：3、包含关系（include）：用带箭头的虚线和版型（include）表示，由基本用例指向被包含用例。
包含关系是用例之间的关系。
所谓的包含关系是指当一个用例需要以另一个用例的执行为前提才能执行时，这两个用例间的关系。
即一个用例不能被独立执行，随着另一个用例的执行而执行，也随着另一个用例的消亡而消亡。
以机房收费系统中的结账功能为例，如下图：在上图中结账用例和汇总退还金额用例之间即包含关系。
如果结账用例不执行时就无法执行汇总退还金额用例，而结账用例结束那么汇总用例也随之结束。
4、扩展关系（extend）：用带箭头的虚线和版型（extend）表示，右基本用例指向扩展用例。
扩展关系也是用例之间的关系。
它指的是，当一个用例执行时出现某种特定的条件时，激活另一个用例。
这里的一定条件称之为扩展点，被激活的用例称之为扩展用例。
以机房收费系统中，上机时余额不足为例，如下图：上图中，上机用例执行时若发现学生卡号中的余额小于最低余额时则直接转入充值用例，但是充值用例也可以单独被执行。
UML用例和用例图
只书写“可观测”的
书写用例文档
——路径交互步骤的描述(2)
系统从会员处获取用户名和密码 会员提交用户名和密码 用户名和密码被验证 系统验证用户名和密码
使用主动语句
书写用例文档
——路径交互步骤的描述(3)
执行者××××× 系统××××× 系统××××× 执行者×××××
句子必须以执行者或系统作为主语
UML用例和用例图
主要内容
基本概念：Use case、Actor、Scenario
Use case间的关系 Use Case 分析技术 案例讲解
Use Case 定义
➢ 定义1：用例是对一个活动者(actor)使用 系统的一项功能时所进行的交互过程的一 个文字描述序列。
➢ 定义2：用例是系统、子系统或类和外部的 参与者（actor）交互的动作序列的说明， 包括可选的动作序列和会出现异常的动作 序列。
有足够库存 …….（后续描述省略）
主要内容
基本概念：Use case、Actor、Scenario
Use case间的关系 Use Case 分析技术 案例讲解
案例1：ATM系统
建立一个具有基本功能的ATM机软件
客户可以存钱，取钱 客户可以查询帐户余额 客户可以修改密码 客户可以进行转帐
需求建模—用例图
互图分析和类图分析必不可少的部分。
用例的描述
一般说来，用例采用自然语言描述参与 者与系统进行交互时双方的行为，不追求 形式化的语言表达（面向不同人员）。
用例描述的内容
用例的目标 用例是怎么启动的 参与者和用例之间的消息是如何传送的 用例中除了主路径外，其他路径是什么 用例结束后的系统状态 其他需要：参与者是指系统以外的、需要使用系统 或与系统交互的东西，包括人、设备、外部系 统等。通过系统边界与系统进行有意义交互。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
识别参与者思路
用例图
谁使用系统的主要功能 谁改变系统的数据 谁从系统获取信息 谁需要系统的支持以完成日常工作任务 谁负责日常维护、管理并保证系统正常运行 谁使用或删除系统中的信息 谁（或什么）对系统运行产生的结果（值）感兴趣 系统需要应付（处理）那些硬设备 系统需要和那些外部系统交互 在预定时间，是否有事件自动发生 时间、气温等内部外部条件 ……
可观测：用例止于系统边界
用例图
系统
描述交互，而不是内在的系统活动
边界---Boundary
用例图
也叫系统边界，用于界定系统功能范围
用一个带名称的矩形框，把描述系统功能的用例都 置于其中，而描述的与系统交互的角色都置于其外 系统----完整系统或子系统 一个系统包括一个或多个用例
准确的定义系统的边界（功能）不是一件很容 易的事 先识别出系统的基本功能集，以此为基础定义 一个稳定的、精确定义的系统体系结构，再不 断地扩充系统功能，以逐步完善
统一建模语言
用例图
11软件工程
CH4 用例图 系统用例及用例关系
知识回顾—需求获取
用例图
需求工程
需求管理
需求开发
问题获取
分析
编写规格说明
验证
教学目标
用例图
掌握用例图的地位作用及定义
重 点 掌握用例图模型元素 能够根据需求分析使用用例图建模
难 点
确定用例及用例间的关系
教学内容
用例图
用例图建模应用 用例图 需求获取
用例图
识别用例
关键词：价值 定义
用例实例是系统执行的一系列动作， 这些动作将生成特定参与者可观测的结 果值 一个用例定义一组用例实例（场景） 简洁：参与者使用系统达到目标
识别用例要点
用例图
可观测→用例止于系统边界 结果值→用例是有意义的目标 系统执行→结果值由系统生成 由参与者观测→业务语言、用户观点 一组用例实例→用例的粒度 用例命名
用例粒度-4
用例图
如果确实是CRUD？
如果CRUD不涉及复杂的交互，一个用例“管理××” 即可 不管是C、R、U、D，都是为了完成“管理”目标 甚至很多种的基本数据管理都可以用一个用例表示
结果值：有意义的目标
用例图
业务功能，而非系统处理
设定查询条件
√
会员 检索零件
会员
×
选择零件
系统执行：结果值由系统生成
用例图
出纳员
×
吃饭
系统需要处理的，由系统生成
参与者观测：用户观点而非系统观点
用例图
订票 旅客 查看今日航班
旅客
×
处理订票
显示今日航班
用户观点
系统观点
要点：用例粒度
用例图
用例要有路径，路径要有步骤；而这一 切都是可观测的 最常犯错误：粒度过细，陷入功能分解
用例2
用例图
用例捕获某些角色可见的需求，实现 一个具体的角色需求 用例由其用户角色使用，并提供确切 的输出给角色 用例可大可小，但它必须是对一个具 体的角色目标实现的完整描述 用例的动态执行过程可以用UML的交互 作用来说明，可以用状态图、顺序图、 协作图或非正式的文字描述来表示
识别用例
参与者的类型和职责
用例图
主要参与者
直接与系统交互的人，或执行系统主要功能的执 行者
次要参与者
使用系统次要功能的执行者，或维护系统一般功 能的执行者
外部硬件
作为系统一部分的、运行应用的非计算机的硬件
其他系统
为其工作需要与系统交互的外部系统
参与者之间的关系
用例图
独立关系 泛化关系
过细的粒度，一般都会导致技术语言的描 述，而不再是业务语言
用例粒度-1
用例图
把步骤当用例
会员 输入用户名
<<include>>
×
把系统活动当用例
<<include>> 建立数据库连接 <<include>> 查询订单 执行SQL语句
会员
登录
√
验证用户名和密码
×
用例粒度-2
用例图
×
增加用户 查询用户
修改用户
管理员
删除用户
用例粒度-3
用例图
“四轮马车”
C(Create) R(Read) U(Update) D(Delete)
所有业务最终会成为CRUD？ CRUD能为Actor提供价值？ CRUD掩盖业务，锐变成关系数据库的建模：
“系统就是数据的增删改查” 关心数据的存储和维护，反而忽略了用户的目的
4
Click to add title in here
一 需求获取
用例图
2 解答问题
在需求获取过程中，主要需要弄清楚三个问题
What
•明确需要获取的信息
Where
•明确所获取信息的来源和渠道
How
•怎样获取需求
用例图
二 用例图相关概念介绍
用例图
1. 什么是用例图
由参与者（Actor）、用例（Use Case）以及它们之 间的关系构成的用于描述系统功能的动态视图称为用 例图。
2. 用例图的作用
用例图
用例图是需求分析中的产物，主要作用是描述参 与者和用例之间的关系，帮助开发人员可视化的 了解系统的功能。 用例图可视化地表达了系统的需求，具有直观、 规范等优点，克服了纯文字性说明的不足。 用例方法是完全从外部来定义系统功能，它把需 求和设计完全的分离开来。
识别参与者1 参与者，Actor
一个参与者的抽象描述 可以被一个或多个具体的 参与者所共享
客户
商业客户
个体客户
用例1
用例图
用例
定义：Use Case 用例表示系统的一项外部 功能，它从用户的角度分析 所得的需求。为完成一个相 对完整的一种功能，系统执 行的一系列动作的集合
是外部可见的一种系统功能 代表的是一个完整的功能 有一系列动作
用例图
关键词：边界 参与者：在系统之外，透过 系统边界与系统进行有意义交 互的任何事物
识别参与者２ 要点
系统外
用例图
参与者代表在系统边界之外的真实事物，并不是 系统的成分
系统边界
参与者透过系统边界直接与系统交互，参与者 的确定代表系统边界的确定
有意义交互的任何事物
人、外系统、外部因素、时间
需求获取及分析 需求的基本方法 什么叫用例图 用例图的构成要素 用例的重要元素 用例之间的各种重 要关系 识别参与者 确定用例
用例建模
一 需求获取
用例图
1 问题引入 需求是客户在项目立项时就有的一个远景，客户需求 将决定在整个项目中需求承办方具体做些什么，即承 办方的任务。承办方在明确了需求后，就会开始后期 的设计、开发、测试、部署等工作。