OO系统分析员之路--用例分析系列（2）--用例的类型与粒度

转自:http://blog.csdn.net/coffeewoo/archive/2008/12/05/3450819.aspx

在正式讨论如何获取用例之前，笔者觉得有两个问题还是先解释清楚为好，这对正确获取用例有很大帮助。这两个问题也是初学者最为困惑，也是最难掌握的。一个是各种用例类型之间的区别和用法，另一个是用例的粒度。
先说说用例类型 的问题。
用例类型，有的资料翻译为版型，英文原文是stereotype。在Rose中默认的类型有business usecase , business usecase realization和use case realization三种。相应的，就是指

业务用例：

业务用例实现：

用例实现：

若不指定类型，则它就是通常意义上的use case ：

Rose 中定义了上述默认类型，但是也可以自定义用例类型。初学用UML建模的人常常在这些类型中迷失，搞不清楚这些类型是什么含义，什么时候该使用什么类型。简单说，需求分析中的各个阶段要描述和分析的目标不同，为表达不同的视角和分析目标，需要使用不同的用例类型。笔者的观点是，用例类型的区分是为了形式上的统一，但用例类型既然可以自定义，它就是一个很灵活的用法，不必墨守成规，大可在工作中根据实际情况定义适合自己项目特点和软件过程的用例类型。不过，默认的用例类型已经几乎可以满足需求分析的各个阶段，自定义的必要性并不大，并且UML的意义就是使用统一的形式描述需求，因此最好使用默认的类型。

说到需求分析阶段，那么需求分析都有些什么阶段呢？一般来说，需求分析要经过业务建模，用例分析和系统建模 三个阶段才能完成需求工作，这三个阶段分别做什么笔者会在以后的文章的详细阐述，这里为了说明用例类型的含义和使用，先简单介绍一下。

1、业务建模的目标是通过用例模型的建立来描述用户需求 ，需求规格说明书通常在这个阶段产生。这个阶段通常使用业务用例和业务用例实现两种类型；

2、用例分析是系统分析员采用OO方法来分析业务用例的过程，这个阶段又称为概念模型阶段 。这个阶段通常使用无类型的用例。用例分析是一个过渡过程，但笔者认为其非常重要，业务架构通常在这个阶段产生。

3、系统建模是将用户的业务需求转化为计算机实现的过程 。这个阶段通常使用无类型的用例和用例实现两种类型。系统范围，项目计划，系统架构 通常在这个阶段形成 雏形（在系统分析阶段确定）。

所谓business usecase，是用来描述用户原始需求的，它的含义是站在用户的角度，使用用户的业务术语来描述用户在其业务领域所做的事情 。业务用例命名 ，描述都必须采用纯业务语言 ，而不能出现计算机术语。因为业务模型是系统分析员与用户讨论需求，达到一致理解的基础，必须使用用户熟悉的，不会有歧义的专业术语以避免系统分析员与用户对同一事件的理解误差。business usecase realization是达到需求可追溯要求的一个连接点，是用户在其业务场景中如何做这一件事的载体。

笔者自己在用例分析和系统建模阶段不区分用例类型，都使用无类型的use case，但在这两个阶段，用例的含义还是有所差别的。用例分析阶段，用例主要是从业务模拟的概念上，从OO的视角来分解、组合业务用例，粗略的建立一个业务架构。而在系统建模阶段，用例主要是从计算机视角描述需求，规定开发范围，作为项目计划的依据，为系统设计做准备。usecase realization的含义可从business use case realization推知。

再来说说用例的粒度 问题。

粒度是令人迷惑的。比如在ATM取钱的场景中，取钱，读卡，验证账号，打印回执单等都是可能的用例，显然，取钱包含了后续的其它用例，取钱粒度更大一些，其它用例的粒度则要小一些。到底是一个大的用例合适还是分解成多个小用例合适呢？这个问题并没有一个标准的规则，笔者可以给大家分享的经验是根据阶段不同，使用不同的粒度。在业务建模 阶段，用例的粒度以每个用例能够说明一件完整的事情 为宜。即一个用例可以描述一项完整的业务流程。这将有助于明确需求范围。例如取钱，报装电话，借书等表达完整业务的用例，而不要细到验证密码，填写申请单，查找书目等业务中的一个步骤。在用例分析 阶段，用例的的粒度以每个用例能描述一个完整的事件流 为宜。可理解为一个用例描述一项完整业务中的一个步骤。需要注意的是，这个阶段需要采用OO方法，归纳，抽象业务用例中的概念模型 。例如，宽带业务需求中有申请报装，申请迁移地址用例，在用例分析时，可归纳和分解为提供申请资料，受理业务，现场安装等多个业务流程中都会使用的概念用例。在系统建模 阶段，用例视角是针对计算机的，因此用例的粒度以一个用例能够描述操作者与计算机的一次完整交互 为宜。例如，填写申请单，审核申请单，派发任务单等。可理解为一个操作界面，或一个页面流。在RUP中，项目计划要依据系统模型编写 ，因此另一个可参考的粒度是一个用例的开发工作量在一周左右为宜 。

上述的粒度划分方法笔者是用相对比较具体化的一些依据来说明。实际上，用例粒度的划分依据（尤其是业务用例）最标准的方法 是一个用例的粒度是否合适，是以该用例是否完成了参与者的某个目的为依据的 。这个说法比较笼统，也比较难以掌握。，举个例子，某人去图书馆，查询了书目，出示了借书证，图书管理员查询了该人以前借阅记录以确保没有未归还的书，最后借到了书。从这段话中能得出多少用例呢？请记住一点，用例分析是以参与者为中心的，因此用例的粒度以能完成参与者目的为依据。这样，实际上适合用例是：借书。只有一个，其它都只是完成这个目的过程--这里讨论的用例指的是业务用例--这个例子是比较明显的能够区分出参与者完整目的的，在很多情况下可能并没有那么明显，甚至会有冲突。读者可以从自己实际的情况去找出这种例子。以后的文章中笔者会做一些讨论。

但是上述的粒度选择并不是一个标准，只是在大多数情况下这样的粒度选择是比较合适的。笔者的意思也不是告诉读者上述哪一种是最好的，而只是把一些常用的比较，划分方法告诉读者，期望的是帮助读者在工作实践中自己总结出一套适合自己的方法来。现实情况中，一个大型系统和一个很小的系统用例粒度选择会有较大差异。这种差异是为了适应不同的需求范围。比如，针对一个50人年的大型项目应该选择更大的粒度，如果用例粒度选择过小，可能出现上百甚至几百个业务用例，造成的后果是需求因为过于细碎和太多而无法控制，较少的用例有助于把握需求范围，不容易遗漏。而针对一个10人月的小项目应该选择小一些的粒度，如果用例粒度选择过大，可能只有几个业务用例，造成的后果是需求因为过于模糊而容易忽略细节。一般来说，一个系统的业务用例定义在多于10个，少于50个之间 ，否则就应该考虑一下粒度选择是否合适了。

不论粒度如何选择，必须把握的原则是在同一个需求阶段，所有用例的粒度应该是同一个量级的 。这应该很好理解，在描述一栋建筑时，我们总是把高度，层数，单元数等合在一起介绍，而把下水道位置，插座数量等合在一起介绍。如果你这样介绍一栋楼：这栋楼有10层，下水道在厨房东南角，预留了15个插座，共有5个单元，听众一定会觉得云山雾罩，很难在脑子里形成一个清晰的影像。

如果对上面两个问题读者还有疑惑，不用着急，在以后的文章中应该会逐步加深理解。

预告：下一篇文章将通过一个例子，阐述获取用例的一般方法和如何判断用例的粒度是否合适。

Q&A

--------------------------------------------------------------------------

Q：由 pushboy 发布
在业务建模阶段，用例的粒度以每个用例能够说明一件完整的事情为宜。即一个用例可以描述一项完整的业务流程。"
"在系统建模阶段，用例视角是针对计算机的，因此用例的粒度以一个用例能够描述操作者与计算机的一次完整交互为宜。"
那么，这样一个场景 —— 用户管理，有增删改查
这里，是把 用户管理 作为一个用例，还是把增删改查分别作为用例呢？
他们每一个都是一个完整的业务流程和一次完整交互，而且也都是一个actor发起的动作；怎么来确认呢？
我们的前提是一个普通的比如说财务系统，而不是一个用户管理系统

A：这个问题很好，用例的粒度总是在这样左也可右也可之间难以决定。对这个问题来说，我的观点是业务用例应当用“管理用户”或“维护用户”作为合适的粒度，而增，删，改，查则在作为系统用例。我的理由是：
增删改查不能做为一个完整的业务来理解。作为一个管理业务，数据只有先增，才会有改，才会有删。增删改查结合起来才能完成actor的管理目的，只删或只增加都不是业务的全部。是否是一项完整业务，要看actor的目标，而不是事情是否完整。这个例子中，actor的目标是为了增加一个用户吗？是为了删除一个用户吗？都不是，而是为了管理用户，这个目标包括了用户这个实体的整个生命周期。

再讨论深一些，如果业务要求对用户除了增删改查，还有别的要求，例如权限升级，用户在组织机构中复杂的关系变更，用户与外部系统的交互....实际的情况可能会更多，那么，如果将每个都作为一个业务用例，很容易造成一个结果，这些原本与用户这个实体紧密关联，共同组成用户实体生命周期的业务，被割裂成多个独立的业务，因为定义了多个用例（请参看本人第一篇中的用例特征第一条）。要知道，在RUP中，用例驱动的含义是，一个用例就是一个分析单元，设计单元，开发单元，测试单元甚至部署单元。 相信读者都知道，把紧密关联的业务分成多个独立部分去实施是高成本的，高风险的。

另外，为什么我要说在系统用例阶段要把增，删，改，查又分出来呢？原因在于，系统用例的目的是为了将actor的业务用计算机模拟出来。我们都知道，一般情况下，增，删，改，查对一个actor来说是不会同时发生的，每次actor只会完成其中的一个行为。分开来，有利于详细分析模拟这一行为的细节而不至于混淆。另一方面，对WEB应用来说，针对数据的增，删，改，查等，很容易形成所谓的“模板”，增加用户用这个模板，增加其它基础数据可能也用同一个模板，无非是操作的数据（实体）不同而已。因此，在很多情况下，这些模板是可以复用的。对这个例子来说，在系统用例阶段，我们可以用“管理用户” include “增加用户”来表示这个实现关系，同时，让“增加用户”，“增加XX数据”等等用例来继承自一个抽象出来的“增加数据”用例，这样，可复用的模板体现在 “增加数据”用例上，而具体业务，则体现在“增加XX数据”上。实际上，这也是一种OO思想的体现。

只有一个查询是比较特殊的，查询一般不一定只局限于一个actor，也不一定局限这个用例，一般都是所谓的综合查询，是可能跨用例的。所以根据实际情况，查询可以作为一个业务用例出现。