Thinking in uml 03 uml核心元素(二)

三．用例

UML是面向对象的，除用例外，所有其他元素都是“封装”的、“独立”的，而用例正是施加这一“外力”的元素，正是用例使得其他那些孤独的UML元素能够共同组成一篇有意义的文字。因而，没有准确的用例定义一切都无从谈起。

1．基本概念

所谓用例，就是一件事情，要完成这件事情，需要做一系列的活动；而做一件事可以有很多不同的办法和步骤，也可能会遇到各种各样的意外情况，因此这件事情是由很多情况的集合构成的，在UML中称之为用例场景，一个场景就是一个用例的实例。

一个系统的功能性是由一些对系统有愿望的参与者要做的一些事情构成的，事情完成后就达成了参与者的一个愿望，当全部参与者的所有愿望都能够通过用例来达到，那么这个系统就被确定下来。捕捉功能性需求，就是用例的作用。

2．用例的特征

用例有一系列特征，这些特征保证用例能够正确捕获功能性需求，同时也可以判断用例是否准确。

（1）用例是相对独立的。

这意味着它不需要与其他用例交互而独自完成参与者的目的，也就是说用例从功能上说是完备的，用例本质体现了参与者的愿望，不能完整达到参与者愿望的不能称为用例。

（2）用例的执行结果对参与者来说是可观测的和有意义的。

例如，有一个后台进程监控参与者在系统里的操作，并在参与者删除数据之前执行备份操作。虽然它是系统的一个必需组成部分，但它在需求阶段却不应该作为用例出现。因为这是一个后台进程，对参与者来说是不可观测的，它应该作为系统需求的补充需求规约中的定义，而不是一个用户需求。

再比如，登录系统是一个有效用例，但输入密码却不是。这是因为登录系统对参与者是有意义的，这样他可以获得身份认证和授权，但单纯地输入密码却是没有意义的。

（3）用例必须由一个参与者发起，不存在没有参与者的用例，用例不应该自动启动，也不应该主动启动另一个用例。

用例总是由一个参与者发起的，参与者的愿望是这个用例存在的原因。

（4）用例必须是动宾短语出现的。

（5）一个用例就是一个需求单元、分析单元、设计单元、开发单元、测试单元，甚至部署单元。一旦决定了用例，软件开发的其他活动都以这个用例为基础，围绕着它进行。

3．用例的粒度

在项目过程的不同阶段，使用不同的粒度。

在业务建模阶段，用例的粒度以每个用例能够说明一件完整的事情为宜。即一个用例可以描述一项完整的业务流程，这将有助于明确需求范围，例如，取钱、报装电话、借书等，而不要细到验证密码、填写申请单、查找书目等业务中的一个步骤。

在用例分析阶段，即概念建模阶段，用力的粒度以每个用例能描述一个完整的事件流为宜。可理解为一个用例描述一项完整业务中的一个步骤。需要注意，在该阶段，需要采用一些面向对象和方法，归纳和抽象出业务用例中的关键概念模型并为之建模。例如，宽带业务需求中有申请报装和申请迁移地址用例，在用例分析时，可归纳和分解为提供申请资料、受理业务、现场安装等多个业务流程中都会使用的概念用例。

在系统建模阶段，用例的视角是针对计算机的，因此粒度以一个用例能够描述操作者与计算机的一次完整交互为宜。例如，填写申请单、审核申请单、派发任务单等，可理解为一个操作界面或一个页面流。

一般来说，一个系统的业务用例定义在多于10个，少于50个之间，否则就应该考虑一下粒度的选择是否合适。

不论粒度如何选择，必须把握的原则：同一个需求阶段，所有用例的粒度应该是同一个量级的。其实，粒度选择的问题本质上还是因为边界认定不同而产生的。如果对选择粒度感到困难，或者出现同一个阶段粒度大小不一的情况，应当首先确认是否选择了一个正确的边界并时时检查自己是否越过了这个边界。

4．用例的获得

用例的定义是由参与者驱动的，并且给参与者提供可观测的有意义的结果的一系列活动的集合。用例的来源就是参与者对系统的期望。所以，发现用例的前提条件是发现参与者，而确定了参与者的同时就确定了系统的边界。

从涉众中选择业务代表作为参与者，并进行访谈。

访谈注意事项：

（1）不要试图让业务代表为你描述整个业务流程；

（2）不要涉及表单填写一类的业务细节；

（3）可以不关系业务规则；

（4）更不要试图让业务代表理解将来的计算机系统会如何工作。

只需要让业务代表从他自己的本职工作出发谈谈他的期望，并时时提醒和引导那些喜欢深入细节的客户。可以通过以下问题提问：

（1）您对系统有什么期望？

（2）您打算在这个系统里做什么事情？

（3）您做这件事的目的是什么？

（4）您做完这件事希望有一个什么样的结果？

通过访谈结果找出用例。不要指望用户对用例了如指掌，也不要期望客户能有条理地分层次的将他对系统的期望表达出来。我们需要从这些杂乱无章的谈话中找出主角真实的期望和有效目标。

总之，应当保证：

一个明确的有效目标才是一个用例的来源；

一个真实的目标完成应当完备的表达主角的期望；

一个有效地目标应当在系统边界内，由主角发动，并具有明确的后果。

需要多次进行访谈，重新开始访谈前，需要考虑：

调整系统边界和主角；

扩大或缩小系统边界；

变更主角；

然后，重新开始。

经过几次调整后，系统边界内应该已经充满了主角的期望，将每个有效地期望用用例绘制出来，并给一个合适的名字就完成了用例的获取工作。

5．用例和功能的误区

如何描述一个事物，可以从三个角度（结构、功能和使用者），例如描述自行车：

结构：是一种交通工具，它由传动系统、刹车系统等部分组成；

功能：可以骑行，可以载物；

使用者：可以用双脚蹬动踏板向前前进，可以用手捏合刹车使自行车停下来。

这仍可以归结为认识论的问题，对于创造一种不存在的事物，最好的方式就是从使用者的观点出发，描述希望这个事物使用者能用它做什么，能获得什么。使用者的观点实际上就是用例的观点，一个用例是一个参与者如何使用系统，获得什么结果的集合，通过分析用例，得出结构性的和功能性的内容，最终实现用例，也就实现了参与者的观点。

可以总结为：

（1）功能是脱离使用者的愿望而存在的；

（2）功能是孤立的；

（3）如果非要从功能的角度解释用例，那么用例可以解释为一系列完成一个特定目标的“功能”的组合，针对不同应用场景，这些“功能”体现不同的组合方式。

最后，例如电视，从功能角度出发，对电视的描述是：能开发、能显示、可以调频道、可以调声音，以上四者是独立的；从用例的角度出发，对电视描述：有一个人要观看电视节目。要完成这个用例，需要先打开开关，调到自己喜欢的频道，如果声音不合适，可以调节一下，以上三者是因人的需求而相关起来。

6．目标和步骤的误区&用例粒度的误区

这与抽象层次有关。当抽象层次确定后，用例粒度就能确定，并且不会出现目标和步骤的误区。

但如何确定抽象层次，需要从软件过程（是处于业务分析、概念分析还是其他），以及对业务的熟悉程度来决定，以及系统的规模等来考虑，但必须要保证用例粒度的一致性。

关于目标和步骤：

步骤也可以作为用例，在概念建模阶段，由于需求已经捕获，在对需求进行分析时，实际上我们已经进入用例的内部。进入用例的内部意味着边界已经改变，边界的改变必然导致参与者的改变。还由于已经进入用例内部，表示现在的参与者的所有活动都处于该用例的上下文环境之内，所以，在寄信这个完整业务目标的上下文环境中，邮局收银员的完整目标是收钱就是合理的。

7．业务用例

业务用例是用例版型的一种，专门用于需求阶段的业务建模。

业务建模是针对客户业务的模型，严格来说业务模型与计算机系统建模无关，它只是业务领域的一个模型，通过业务模型可以得到业务范围，帮助需求人员理解客户业务，并在业务层面上与客户达成共识。业务范围不等于需求（不是所有的业务都能计算机实现，也不是需求（如日志）都是业务），软件需求真正的来源是系统范围，也就是系统模型，业务模型是系统模型的最重要的输入。

8．业务用例实现

一个业务用例可以有多种实现方式，它们的关系可以类比接口与实现类的关系。

如上图，从业务目标上来讲并没有什么差别，但在业务执行上完全不同。

9．概念用例

概念用例用于概念模型，没有预定义版型。

它用于获取业务模型中的核心业务逻辑，这些核心业务逻辑揭示了业务模型，成为业务架构的重要指导。同时，概念用例还是业务用例到系统用例过渡时非常重要的指导。

10．系统用例

系统用例就是我们常说的用例。

它用来定义系统范围、获取功能性需求的。它是软件系统开发的全部范围，是我们得到的最终需求。

如果说业务用例是客户业务视角的话，系统用例将采用系统视角来看待。