需求用例分析之八：用例颗粒度
作者：张克强 作者微博：张克强-敏捷307
RUP系的考虑
在RUP中，没有对用例的颗粒度给出清晰的指导。2004年Rational 中国区技术销售经理 傅纯一发表一文《用例建模指南》，是这样说明用例的粒度的。
我的系统需要有多少个用例？这是很多人在用例建模时会产生的疑惑。描述同一个系统，不同的人会产生不同的用例模型。例如对于各种系统中常见的"维护用户"用例，它里面包含了添加用户、修改用户信息、删除用户等操作，这些操作在该用例的事件流可以表述成为基本流的子事件流(subflow)。
管理用户-基本事件流
该基本流由三个子事件流构成：
1) 添加用户子事件流
…
2) 修改用户 子事件流
…
3) 删除用户子事件流
…
但是你也可以根据该用例中的具体操作把它抽象成为三个用例，它所表示的系统需求和单个用例的模型是完全一样的。
应该如何确定用例的粒度呢？在一次技术研讨会上，有人问起Ivar Jacoboson博士，一个系统需要有多少个用例？大师的回答是20个，当然他的意思是最好将用例模型的规模控制在几十个用例左右，这样比较容易来管理用例模型的复杂度。在用例个数大致确定的条件下，我们就很容易来确定用例粒度的大小。对于较复杂的系统，我们需要控制用例模型一级的复杂度，所以可以将复杂度适当地移往每一个用例的内部，也就是让一个用例包含较多的需求信息量。对于比较简单的系统，我们则可以将复杂度适度地曝露在模型一级，也就是我们可以将较复杂的用例分解成为多个用例。
用例的粒度不但决定了用例模型级的复杂度，而且也决定了每一个用例内部的复杂度。我们应该根据每个系统的具体情况，因时因宜地来把握各个层次的复杂度，在尽可能保证整个用例模型的易理解性前提下决定用例的大小和数目
傅的这篇文件代表了当时雅各布森-RUP系对用例颗粒度的看法。
科伯恩的关于颗粒度的考虑
在科伯恩的编写有效用例中，探讨了CRUD类型用例，CRUD是指创建、检索、更新和删除，上述的添加用户、修改用户和删除用户就是典型的CRUD类型用例。书中提到“S.R.A公司的Susan Lilly认为分离的CRUD用例便于追踪，主执行者可以安全地调用不同功能。但是，我倾向于先使用单个管理实体用例对其进行处理，这样可以减少用例数目。如果编写用例的复杂度增加，再对其进行分裂。”“在实际使用中，两种方法都可以使用，到目前为止没有足够的证据表明哪个方法好或不好”。
编写开发用例的时间颗粒度
仍然在《编写有效用例》中，谈到了用例需要的平均时间，对于识别用例摘要，即是草拟，平均每人每天2.8个，可以换算为每用例草拟摘要需2.9小时，整理并添加其他需求，总计每个用例需要2个工作周，而开发需要每用例3到5个工作周。合计的话，约每用例需要5到7个工作周，可换算为每用例约需要200工时到280工时，或者1.2人月到1.7人月。
而在1993年Gustav Karner提出的用例点方法中，一个中等用例含有4～7个环形事务，计为10个用例点；一个复杂用例含有超过7个环形事务，计为15个用例点。Gustav Karner给出的缺省用例生产率是每用例点需20工时，对于中等用例而言，就需要200工时，复杂用例需要300工时。这个结果与科伯恩的结果极为接近。
谭云杰（Coffeewoo）在《大象Thinking in UML》第2版中，提到了好像一个用例费时约2人周（那书好厚，回头再找找不到了，也许记错了）
执行用例的时间颗粒度
另外一个观察用例颗粒度的维度是用例执行的时间。在科伯恩的书里，用户目标用例标为蓝色，海平面（对等于雅各布森用例的系统用例），在多数情况下，用户目标用例需要一次2到20分钟的处理。概要层次（白色、云朵，风筝）的用例通常需要执行几个小时到几个月，甚至几年。这层次的用例对照到雅各布森用例体系，相当于业务用例。
在《大象Thinking in UML》第2版中，提出“以一个用例能够描述操作者与计算机的一次完整交互为宜”，按这样推断的话，与2到20分钟的处理是一致的。
用例篇幅的颗粒度
还有一个观察用例颗粒度的维度是用例规约的篇幅，科伯恩推荐用例的主成功场景的步骤在3到8、9步。他说：“对于一个要通过10个以上中间步骤才能完成对过程来说，人们感觉是不能容忍或难以想象的”。“几乎所有多于11步的用例都可以被裁短而不影响表达。”
从RUP和编写有效用例公布的各类例子来看，一个步骤一般在A4篇幅下需要1行到3行，基本流或者主成功场景加上备选流或者扩展场景再加上各类用例属性字段，一般而言用例的篇幅是在半页到2页A4纸范围内。
Use-Case 2.0中的颗粒度
2011年，雅各布森为首三人等发布了Use-Case 2.0。其第4条原则是Principle 4: Build the system in slices。将Use-Case进行切片，称为Use-Case Slice。
The concept of a use-case slice is as integral to Use-Case 2.0 as the use case itself. It is the slices that enable the use cases to be broken down into appropriately sized pieces of work for the development team to tackle. Imagine that you are part of a small team producing working software every two weeks. A whole use case is probably too much to be completed in one two-week period. A use-case slice though is another matter because it can be sliced as thinly as the team requires. Use-case slices also allow the team to focus on providing a valuable, usable system as soon as possible, shedding all unnecessary requirements on the way.
在Use-Case 2.0中，Use-Case Slice的推荐组织方式是利用条目化工具与Use-Case分别管理，维护两者的关联从属关系，推荐采用了故事点了对Use-Case Slice进行估算。这样处理后，Use-Case相当于User Story中的EPIC，Use-Case Slice相当于User Story。
更多相关文章
需求用例分析之六：业务用例之科伯恩系
需求用例分析之五：业务用例之Rational系
需求用例分析之四：业务规则