用例粒度与函数粒度的思考

 

用例的粒度问题一直是困扰着需求分析员的常见问题，对于这个问题，抱歉，没有银弹，我只能给出一些解决这个问题的基本原则：

站长的话：在我的实际经验中，对这个问题倒也不悲观，因为用例中“一个参与者”、“一个价值”的定义基本上就确定了用例的粒度，在此我比较认可UMLchina的潘加宇先生的“用例没有粒度”的观点。

1.         控制用例的总体数量：一般来说，一个相当复杂的系统的用例数量可能在30-50个之间，如果一个系统的用例数量大大超过了这一范围，那就该看看是不是陷入了功能分解的误区；

         站长的话：说一个系统的用例数量是衡定的，这必然是一种误解！如果说“一个相当复杂的系统的模块数量可能在30-50个之间”，我想没人可以相信。用例数量的多少和是否功能分解应该没有什么关系。功能分解是一种纵向视角，而用例是一种业务的横向视角，换句话说，是一种白盒视角。功能分解的结果不一定意味着比用例多！

2.         高内聚、低耦合：用例是一种结构化写作需求的技术，用例是被从现实的场景中抽象出来的。如果这些场景有紧密的联系（高内聚），那用用例技术来组织它们则可以复用这些场景中的步骤描述，从而达到事倍功半的效果；

         站长的话：这倒是一个铁的原则！不过，业务价值最容易进行的判断方法是“Boss测试”，例如：“计算折扣"是否为一个合适的用例呢？你只需想一个操作层可以向经理说”我今天完成了30次折扣计算“吗？显然不行，因此它的业务价值是不够的！其实对于信息系统的需求人员，多阅读一些岗位职责也能够建立更好的用例视角！每个表示“职责”的”业务活动“就是一个好的用例。

3.         写写看:很多时候在初步规划用例模型的阶段，有时很难判断一个用例的粒度是否合适，不要执迷于一次获得一个完美的用例模型和用例粒度。不妨先得出一个初稿，然后写写用例，看看是不是符合高内聚、低耦合的原则，实际上在写用例的过程中，用例模型往往是需要不断进行调整的；

         站长的话：不错的建议，但是填充细节和确定用例应该处于不同的需求阶段，因此操作起来有一定障碍。

4.         避免功能分解：功能分解是正确使用用例技术的最大敌人，很多用例粒度的讨论其实都是功能分解的思想在作怪。

         站长的话：解决这个问题，有一点思路。例如”新增客户“就是功能分解，功能分解的模式是”我（系统）能做什么？“，而用例是”他（用户）想干什么？“，因此要转成用例思路，只要问”用户什么时候会新增客户“，得到的答案可能是”办理客户开户“，那么这就是好的用例！

其他关于用例的话还有很多，做为短文就到此结束吧！大家有什么疑问可以跟贴交流。

 

 

=================================================================================================================

　粒度是令人迷惑的。比如在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，也不一定局限这个用例，一般都是所谓的综合查询，是可能跨用例的。所以根据实际情况，查询可以作为一个业务用例出现。