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

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


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个单元，听众一定会觉得云山雾罩，很难在脑子里形成一个清晰的影像。

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