本文主要是介绍五分钟搞懂UML————用例图(User Case Diagrams ) 新手学习感悟。，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
在这之前，我给大家推荐一款在线画流程图的神奇💁💁开始制作！
1. Use Case
在面向对象中，我们经常会见到这类型的用例图，其实不难，我们只需了解每一个元素需要的内容就可以完全掌握它，我让我们一起来看吧！！！
1.1用例简介：
use case 讲述了参与者使用系统的故事，用例展示了系统执行的一系列操作，使特定的参与者生成一个可以直观观测的结果。（表达功能和需求）。用例是文本文档，而不是图表，是编写文本的行为。
比如：用户（user）想要什么？
- 想要想要从图书馆出一本书
- 想要付帐
- 想要输入他的注册详情
1.2用例的作用：
- 对于非分析人员来说是一种简单，熟悉的交流工具，重要的是，它可以减少沟通障碍。
- 帮助我们关注所使用系统的业务价值和开发的优先级。
- 通过它所展现的故事来说明功能需求。
- 定义了系统行为的契约。
1.3类型：
- 系统用例（system use case）
- 业务用例（business use case）
1.4方法：
用例的句子一般是（动词+名字构成），比如：确认客户订单，租赁视频，返还视频，支付罚款.....
2. 角色和用例（Actors and Use Case）
2.1角色（绘画出人物图标）
定义系统外部对象所扮演的角色。
- 是外部观点而不是内部的结构为特征
- 参与涉及与系统的消息交换和操作的交互
- 通过与系统交互实现目标
- 具有充当参与者角色的对象(具有操作和属性)的实例
- 可能与其他参与者具有泛化关系（后面讲之间的关系）
2.2用例（对话框或者椭圆）
定义系统所提供的功能或者单元块
- 表示系统及其参与者之间的外部交互序列，即系统如何为各种交互提供服务
- 产生对参与者有价值的结果
- 具有表示一系列活动的场景的实例(在序列图中描述)
- 可能具有扩展点
- 分层组织
2.3角色和用例之间的关系
通信关系（用实线表示）
- 关联是否显示了参与者和用例之间的交互?
- 是否只允许参与者和用例之间的关系?
用例之间的依赖关系
- <extend>：提供额外功能，并且很可能再次被使用，这两者都应该有助于保持基本UC的简单性，箭头从扩展用例绘制到基本用例
- <include>：是一个单独的用例，因为它将再次被使用，箭头从基本用例绘制到包含的用例
2.4关于租赁的例子
角色的意图：
- 客户赠送会员卡及租赁物品
- 职员记录项
- 客户支付
系统的责任：
- 记得租来的物品
- 计算当前价格
- 授权并记录付款
2.43 关于该用例图典型的事件流
角色的意图
- 顾客带着视频或游戏来到收银台
- 客户向店员出示他们的会员身份，店员将其输入系统
- 对于每一款视频或游戏，店员都会将物品标识记录到系统中
- 店员告诉顾客总费用，并要求付款
- 顾客用现金或信用卡支付给店员
- 店员将付款记录到系统中
- 店员将收据和贷款报告交给顾客，顾客带着租赁物品离开。
系统的责任
- 提供会员信息，以及贷款状况(通常没有贷款，也没有未付贷款）
- 显示累计列表的租赁项目标题，到期日期，总租金，以及任何逾期费用
- 如果信用付款，给予授权
- 生成收据和贷款报告
2.44 将故障模式作为扩展
通常，每一步都可能失败，单独注意失败情况。（备选场景列表）
替代路径或者方案
- 客户现金不足。申请信用付款，取消交易，或扣除租赁项目，直到交易可以支付。
- 客户有未付的滞纳金，不会支付。客户在租用更多商品之前必须先付款，所以要么全额付款，要么取消交易。
- 未能授权信用付款，原因可能是信用不足或授权服务不活跃。要求现金支付。
3. 用例描述
| 用例名称 简要描述 |
| 事件流程
|
| 特殊要求 |
| 先决条件 |
| 后置条件 |
| 注释 |
这篇关于五分钟搞懂UML————用例图(User Case Diagrams ) 新手学习感悟。的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
