五分钟搞懂UML————用例图(User Case Diagrams ) 新手学习感悟。

在这之前，我给大家推荐一款在线画流程图的神奇开始制作！

1. Use Case

在面向对象中，我们经常会见到这类型的用例图，其实不难，我们只需了解每一个元素需要的内容就可以完全掌握它，我让我们一起来看吧！！！

1.1用例简介：

use case 讲述了参与者使用系统的故事，用例展示了系统执行的一系列操作，使特定的参与者生成一个可以直观观测的结果。（表达功能和需求）。用例是文本文档，而不是图表，是编写文本的行为。

比如：用户（user）想要什么？

• 想要想要从图书馆出一本书
• 想要付帐
• 想要输入他的注册详情

1.2用例的作用：

1. 对于非分析人员来说是一种简单，熟悉的交流工具，重要的是，它可以减少沟通障碍。
2. 帮助我们关注所使用系统的业务价值和开发的优先级。
3. 通过它所展现的故事来说明功能需求。
4. 定义了系统行为的契约。

1.3类型：

• 系统用例（system use case）
• 业务用例（business use case）

1.4方法：

用例的句子一般是（动词+名字构成），比如：确认客户订单，租赁视频，返还视频，支付罚款.....

2. 角色和用例（Actors and Use Case）

2.1角色（绘画出人物图标）

定义系统外部对象所扮演的角色。

• 是外部观点而不是内部的结构为特征
• 参与涉及与系统的消息交换和操作的交互
• 通过与系统交互实现目标
• 具有充当参与者角色的对象(具有操作和属性)的实例
• 可能与其他参与者具有泛化关系（后面讲之间的关系）

2.2用例（对话框或者椭圆）

定义系统所提供的功能或者单元块 

• 表示系统及其参与者之间的外部交互序列，即系统如何为各种交互提供服务
• 产生对参与者有价值的结果
• 具有表示一系列活动的场景的实例(在序列图中描述)
• 可能具有扩展点
• 分层组织

2.3角色和用例之间的关系

 通信关系（用实线表示）

• 关联是否显示了参与者和用例之间的交互?
• 是否只允许参与者和用例之间的关系?

用例之间的依赖关系

• ：提供额外功能，并且很可能再次被使用，这两者都应该有助于保持基本UC的简单性，箭头从扩展用例绘制到基本用例
• ：是一个单独的用例，因为它将再次被使用，箭头从基本用例绘制到包含的用例

 

2.4关于租赁的例子

角色的意图：

• 客户赠送会员卡及租赁物品
• 职员记录项
• 客户支付 

 

 系统的责任：

• 记得租来的物品
• 计算当前价格
• 授权并记录付款 

 

2.43 关于该用例图典型的事件流

 角色的意图

• 顾客带着视频或游戏来到收银台
•  客户向店员出示他们的会员身份，店员将其输入系统
• 对于每一款视频或游戏，店员都会将物品标识记录到系统中
• 店员告诉顾客总费用，并要求付款
• 顾客用现金或信用卡支付给店员
• 店员将付款记录到系统中
• 店员将收据和贷款报告交给顾客，顾客带着租赁物品离开。

系统的责任

• 提供会员信息，以及贷款状况(通常没有贷款，也没有未付贷款）
• 显示累计列表的租赁项目标题，到期日期，总租金，以及任何逾期费用
•  如果信用付款，给予授权
• 生成收据和贷款报告 

2.44 将故障模式作为扩展 

通常，每一步都可能失败，单独注意失败情况。（备选场景列表）

替代路径或者方案

• 客户现金不足。申请信用付款，取消交易，或扣除租赁项目，直到交易可以支付。
• 客户有未付的滞纳金，不会支付。客户在租用更多商品之前必须先付款，所以要么全额付款，要么取消交易。
• 未能授权信用付款，原因可能是信用不足或授权服务不活跃。要求现金支付。

3. 用例描述 

用例名称        简要描述

事件流程 基本流程 子流程 交替流程

特殊要求

先决条件

后置条件

注释