《Thinking in UML》读书笔记 4 : 用例（Use Case）

用例是UML建模中最重要的一个元素，因为UML是面向对象的，除了用例以外，其他所有的元素都是“独立”的，“封装”的。在没有外力的驱动下，这些独立的元素就是孤独的。而用例就是施加这一外力的元素。

用例的定义

官方定义：用例定义了一组用例示例，其中每个示例都是系统所执行的一系列操作，这些操作生成特定主角可以观测的值（官方的果然NB，太精辟了，精辟到我一点都看不懂）

简单的说法：一个用例就是与参与者交互的，并且给参与者提供可观测的意义的结果的一系列活动的集合，所谓的用例就是一件事情，要完成这件事情，需要做的一系列的活动；而做一件事情可以有很多不同的办法和步骤，也可能会遇到各种各样的意外情况，因此这件事情是由很多不同情况的集合构成的，在UML中称之为用例场景。一个用例场景就是一个用例的实例。

而启动一个用例可能需要一定的前置条件，例如烧饭这个用例的前置条件就是要有米，用例执行完了会有一个结果，这个被称为后置条件，例如烧饭的结果就是米变成了饭。

用例的特征

1.用例是相对独立的，就是说他不与其他用例交互，而是独自完成参与者的目的。

2.用例的执行结果对于参与者来说是可观测的和有意义的。例如系统中有个删除前自动备份数据的操作，这个操作结果对与参与者是透明的，参与者不是直接受益人，所以他不能称之为用例。

3.事件必须由一个参与者发起，不存在没有参与者的用例，用例不应该自动启动，或启动其他的用例。

4.用例必然是以动宾短语形式出现的、例如“喝水”是一个有效的用例，而“喝”不是。

用例的粒度

用例的粒度是根据建模的抽象层次所决定的。

1.在业务建模阶段，用例的粒度是以每个用例能够说明一件完整的事情为宜。

2.在概念建模阶段，用例的粒度是以每个用例能够描述一个完成的事件流为宜。

3.在系统建模阶段，用例的粒度是以每个用例能够描述操作者与计算机的一次完整的交互为宜。

用例和功能的误区

功能和用例是有本质的区别的。

1.功能是脱离使用者的愿望而存在的。例如我们描述一个自行车的功能就是他能骑和载物，并无谁来使用它。

2.功能是孤立的，在系统中，给一个输入就能得到一个输出。而用例是一个系统性的工作，这个系统的工作非常明确的去为某个参与者达成一个特定的目标。

3.如果非要从功能的角度去解释用例，那么用例可以解释为一系列完成一个特定目标的功能的组合。

目标和步骤的误区

步骤可能是一个用力（概念模型中）也可能是一个用例的组成部分，例如寄信这个用例，其中有买信封，买邮票，付钱，投递等步骤，这些步骤在业务模型中是不能单独成为一个用例的。

业务用例（Business Use Case）

专门用于需求阶段的业务建模。业务模型是针对客户业务的模型，是无关计算机系统建木的，它只是一个业务的模型。它的参与者就是业务主角。

业务用例实现（Business Use Case Realization）

是实现业务用例的过程，业务用例和业务用例实现就例如接口与实现类一样。例如交电话费这个用例有营业厅缴费，银行缴费等业务用例实例。

概念用例

概念模型用来获取业务用例中的核心业务逻辑，成为业务架构的重要指导。

系统用例

系统用例是用来定义系统范围，获取功能性需求的。我们一般说的用例就是指系统用例，业务用例是站在客户业务的角度，而系统用例就是咱在系统的视角来看待。

系统用例实例

类似于业务用例实现。

转载于:https://www.cnblogs.com/ccmaycry/archive/2009/07/08/1519518.html