UML用例和用例图

父用例
子用例
关系—参与者与参与者之间

泛化关系
Customer
Personal
Company
用例的粒度


用例的粒度指用例所包含的系统服务或功能单元 的多少。用例的粒度越大，用例包含的功能越多， 反义包含的功能越少。 例：学生管理系统中维护学生信息用例图如下：
维护学生信息
管理员
添加学生信息
管理员
•用例描述了系统的功能需求，是系统的 一组动作序列的描述。 •用例的本质是用户与计算机之间的一次 交互作用。
识别用例
执行者使用这个系统达到什么目标？
语法测试：【执行者】使用系统来【用例】
识别用例
——有意义的目标
识别用例
——业务语言而非技术语言
识别用例
——用户观点而非系统观点
用户观点
系统观点
识别用例
参与者（Actor）


定义：参与者是指系统以外的、需要使用系统 或与系统交互的东西，包括人、设备、外部系 统等。通过系统边界与系统进行有意义交互。 参与者未必是人，可以是设备、外部系统等。 一个参与者可以执行多个用例，一个用例也可 以由多个参与者使用。 参与者并不是系统的一部分， 尽管在模型中会使用参与者。

7、ATM系统记录事务到日志文件；
用例描述分析

Use Case: Buy Something 参与者：Customer 主事件流： 1、系统显示ID和密码窗口； 2、顾客键入ID和密码，然后按OK键； 3、系统验证顾客ID和密码，并显示个人信息窗口； 4、顾客键入姓名、街道地址、城市、邮政编码、电话号码，然 后按OK键； 5、系统验证用户是否为老顾客； 6、系统显示可以卖的商品列表； 7、顾客在准备购买的商品图片上单击，并在图片旁边输入要购 买的数量。选购商品完毕后按Done按钮； 8、系统通过库存系统验证要购买的商品是否有足够库存； …….（后续描述省略）
问题：只描述了ATM系统的行为，而没有描述参与者的行为
ATM取款（修改后的描述）





Use Case：取款 Actor：储户 主事件流： 1、通过读卡机，储户插入ATM卡； 2、ATM系统从卡上读取银行ID、帐号、加密密码、并用主银行系统 验证银行ID和帐号； 3、储户按“取款”按钮，ATM系统根据上面读出的卡上加密密码， 对密码进行验证； 4、储户按“快速取款”按钮，并键统通知主银行系统，传递储户帐号和取款数量，并接收返 回的确认信息和储户帐户余额； 6、ATM系统输出现金、ATM卡和显示帐户余额的收据；
修改学生信息
删除学生信息
主要内容
基本概念：Use case、Actor、Scenario
Use case间的关系
Use Case 分析技术
案例讲解
用例的描述

没有描述的Use Case就像是一本书的目录 从用例的定义也可以看出，用例是一个“文 字描述序列”，是“动作序列的说明”。 用例的描述是用例的主要部分，是后续的交 互图分析和类图分析必不可少的部分。
用例描述原则：尽可能写的“充分”，而不是追求写 的形式化、完整或漂亮。
书写用例文档
——路径交互步骤的描述 只书写“可观测”的 使用主动语句 句子必须以执行者或系统作为主语 每一句都要朝目标迈进 分支和循环 不要涉及界面细节
书写用例文档
——路径交互步骤的描述(1)
系统通过ADO建立数据库连接，传送SQL查 询语句，从“零件”表查询… 系统按照查询条件搜索零件 只书写“可观测”的
用例间的关系——包含关系
1）包含关系(include)
包含关系指两个用例之间的关系，其中一个用例（即 基本用例）的行为包含了另一个用例（即包含用例） 的行为。 包含关系中箭头的方向是从基本用例到包含用例。
<<include>>
基本用例
包含用例
用例间的关系——包含关系
本例中，用例“Check Credit” 检查输入的信用卡号 是否有效以及信用卡是否有足够的资金。
常见错误


只描述系统的行为，没有描述参与者的行为 只描述参与者的行为，没有描述系统的行为 在用例描述中就设定对用户界面设计的详细 要求 描述过于冗长
ATM取款案例
Use Case：取款 Actor：储户 主事件流：
1、储户插入ATM卡，并键入密码； 2、储户按“取款”按钮，并键入取款数目； 3、储户取走现金、ATM卡并拿走收据； 4、储户离开。
主要内容
基本概念：Use case、Actor、Scenario
Use case间的关系
Use Case 分析技术
案例讲解
案例1：ATM系统

建立一个具有基本功能的ATM机软件
客户可以存钱，取钱 客户可以查询帐户余额
客户可以修改密码
客户可以进行转帐
需求建模—用例图
建立用例图分为以下几个步骤：

修改密码
(from UseCases)

Use Case 特点
用例是代表系统中各个项目相关人员之间就系统的行为 所达成的契约。它有如下一些特点： 用例描述了用户提出的一些可见的需求，对应一个具 体的用户目标； 用例从使用系统的角度描述系统中的信息，即站在系 统外部察看系统功能，而不考虑系统内部对该功能的 具体实现形式； 用例是对系统行为的动态描述，属于UML的动态建模 部分； 用例并不是系统的全部需求， 用例描述的只是功能性方面的需求。
操作员，管理员 操作员，管理员 操作员，管理员
领料员,退料员,操作员,管理员,供应商



谁负责维护、管理并保持系统正常运行 管理员 系统需要应付哪些硬件设备 系统需要和哪些外部系统交互 生产系统, 供应商系统 谁对系统运行产生的结果感兴趣 操作员,管理员,领料员,退料员
库存管理系统的参与者
2、用例（Use Case）
问题：对用户界面的描述过于详细，对于需求文档来说， 详细的用户描述对获取需求并无帮助。
改进后的描述


Use Case：Buy Something 参与者：Customer 主事件流： 1、顾客使用ID和密码进入系统； 2、系统验证顾客身份； 3、顾客提供姓名、地址、电话号码； 4、系统验证顾客是否为老顾客； 5、顾客选择要购买的商品和数量； 6、系统通过库存系统验证要购买的商品是否 有足够库存 „„.（后续描述省略）
问题：只描述了参与者的动作序列，而没有描述系统的行为
ATM取款案例



Use Case：取款 Actor：储户 主事件流：


1、ATM系统获得ATM卡和密码； 2、设置事物类型为取款； 3、ATM系统获取要提取的现金数目； 4、验证帐户上是否有足够储蓄金额； 5、输出现金、数据和ATM卡； 6、系统复位。
脚本（scenario)

例：在“订货”这个用例中，包含着几个相关 的脚本。一个是订货进行顺利的脚本；一个是 相关货源不足的脚本；一个是涉及购货者的信 用卡被拒的脚本等。这些脚本的组合构成了一 个用例。
主要内容
基本概念：Use case、Actor、Scenario
Use case间的关系
Use Case 分析技术
面向对象的UML设计基础
用例与用例图 翟亚红
计算机工程系
主要内容
基本概念：Use case、Actor、Scenario
Use case间的关系
Use Case 分析技术
案例讲解
Use Case 定义

定义1：用例是对一个活动者(actor)使用 系统的一项功能时所进行的交互过程的一 个文字描述序列。 定义2：用例是系统、子系统或类和外部的 参与者（actor）交互的动作序列的说明， 包括可选的动作序列和会出现异常的动作 序列。

用例的描述

一般说来，用例采用自然语言描述参与 者与系统进行交互时双方的行为，不追求 形式化的语言表达（面向不同人员）。
用例描述的内容


用例的目标 用例是怎么启动的 参与者和用例之间的消息是如何传送的 用例中除了主路径外，其他路径是什么 用例结束后的系统状态 其他需要描述的内容
确定参与者（Actors） 创建用例（Use Case） 创 建 参 与 者 （ Actors ） — 用 例 （ Use Case）关系图
参与者

系统用户 与本系统交互的其他系统

确定参与者(Actor)
创建用例（Use Case）
用例是参与者启动的，基于这样的考虑， ATM 系统根据业务流程大致可以分为以下的几个用例：
<<include>> 预订座位 <<include>> 检查座位信息
安排座位
用例间的关系——扩展关系
2）扩展关系(extend) 扩展关系允许一个用例（可选）扩展另一个用 例的功能。

扩展只能发生在基本用例的序列中某个特定的 点上，这个点叫扩展点。 扩展关系中基本用例本身是完整的。

在扩展关系中，箭头的方向是从扩展用例到基 本用例。
书写用例文档
——路径交互步骤的描述(4)
执行者填写姓名 执行者填写电话 执行者填写联系地址 执行者提交 ××××× 每一句话都要朝目标迈进
书写用例文档
——路径交互步骤的描述(5)
分支：放到扩展路径
循环：直接描述
分支和循环
书写用例文档
——路径交互步骤的描述(6)
会员从下拉框中选择类别 会员在相应文本框中输入查询条件 会员点击“确定”按钮 …… 不要涉及到界面细节
用例间的关系——扩展关系