课件

本节针对用例建模过程的默认规范和需要注意的细节进行介绍。

一、设定条统边界

用例建模的一个重要环节就是要明确系统的边界。

系统边界是指一个系统所包含的所有系统成分与系统以外各种事物的分界线。系统边界的选择会影响用例和参与者的定义。

以一个零售店销售管理系统为例：这个系统需要记录销售及付款情况，包含了硬件设备以及运行的软件，系统的重要功能是自动收款，快速准确地销售情况统计及分析，还有自动化的库存管理。

第一种设计方式是将收银员和顾客同时设置为系统外部的参与者，如图1，在这种方式中他们共同拥有的用例是购买物品、登录以及退货等三个用例。

在图2的第二种设计方案中，将整个零售店作为系统内部结构，在这种情况下只有客户作为外部参与者与这个系统进行交互，进行购物或退货两种操作。

在图3的第三种设计方案中，涵盖了系统后台管理部分的描述，因此添加了管理员和经理的角色。

通过这三个例子可以看到，不同系统边界定义决定了与系统交互的对象、参与者与系统的交互方式，进而影响了用例模型的设计。

二、不要把用例定义成功能分解

在确定了系统边界之后，需要寻找参与者和用例。在定义用例时大家往往会犯这样的错误，就是将用例定义与功能分解相混淆，人们在解决复杂问题时往往习惯将问题分解为粒度较细、更为独立的部分，不同部分组合之后，形成原始问题的一个完整解决方案，在计算机领域里我们称之为功能分解。这样的方式使得需求的每一个分解部分丧失了其上下文语境，划分的越详细每一个部分就越细小，那么就需要更多的接口连接这些分解的部分，这样的定义方式是存在很大的隐患的。

在需求的定义中非常需要上下文语境信息，因此用例绝对不是功能分解的过程。通过用例描述需求，在详细程度上与功能分解的效果是一致的，但是干系人的需求是基于一定语境下才有意义，所以用例是综合了所有功能一起来描述系统是如何使用的，包含了丰富的语境信息。

举例说明来区分这两者之间的区别：

这张图给出的是ATM机的一个功能分解。它将每一个步骤都详细地划分。然而在正确的用例建模中，我们应该将这些概念抽象为取款、转账和存钱这三个用例进行描述：

接下来看下功能分解和用例的区别：

通过功能划分的方式我们会得到很多细小的用例，这些用例往往没有实际的价值，而且在命名时往往是通过“操作”+“对象”、“功能”+“数据”的方式进行定义，例如“插入卡片”这个用例描述。通过这样的用例我们很难理解整体的模型，那我们该如何避免呢？如图右边所示，首先我们要寻找更大的应用场景，就是要思考我们为什么要构建这个系统。同时我们应该从一个用户的角度出发：“用户希望通过这个系统达到什么样的目的”、“满足哪个用户的目标”、“这个用例的意义到底是什么，可以为参与者提供哪些价值”、“这个用例背后代表的用户故事是什么”。