软件工程之__用例(use case)粒度越细越好

       需求分析中的用例分析就是分析什么人做什么事，描述做事要描述详细到什么程度呢？这就是粒度问题。这个问题往往困惑很多人，人们搞不清楚描述多么细致才算合适，人们生怕描述的太细致就显得太罗唆，又担心描述的太粗会漏掉什么，心里拿不准，不敢下笔写，即使写出来也惴惴不安，总没有1＋1＝2那样给人确凿无疑之踏实感。

       人们常说的一句话：细节决定成败。而在需求阶段，则需求的粒度越细，后期设计越踏实，因需求不明确而返工的可能性越小，设计越有的放矢，质量越有保障，项目成功的可能性越大。人们对粒度的把握不准，往往是没有厘清需求分析和设计的界限，以致于把用例粒度细致进设计的范围之内这个原因造成的，这时内心觉不对头却说不出哪里不对。所以我们要清晰的划分需求和设计的界限。

       需求分析是描述要参与者做什么的问题，设计是系统如何做的问题。这就是它们的分界标准，用这个标准来衡量用例是否越界是很容易的事。比如用例中的一个经典错误：系统将销售信息写入数据库；这是一个系统如何做的问题，不是参与者要做什么的问题，参与者是不会关心信息是否写入数据库的，参与者只关心我能录入销售信息进电脑（系统）中，所以“写入数据库”属于设计范围，不是需求范围。而到底是否要写入数据库、还是要写入文件、还是别的处理，那是设计的事，与需求无关。技术人员做需求，往往不能站在用户的角度考虑，容易搞不清楚需求与设计的界限。

       只要搞清楚了需求边界，那么在此界内用例的粒度越细越好。前期需求捕获越细，后期开发越顺利。如果前期需求捕获不够完整细致，那么后期设计开发凭什么？凭想当然吗？而事实上，很多的软件设计开发阶段凭的就是想当然，而这些想当然来源于以往的经验，有时这种经验主义也时常会成功，但这只是个人的成功，不是工程技术的成功，况且，这种经验也时常出错。以最熟悉的登陆作为例子，用户登陆，这是一种粒度的描述；用户输入用户明、用户输入密码，这是另一种更细的粒度的描述。那么粒度是否需要细化的这个地步呢？需要的，因为用例粒度越细越好。假如我们觉得罗唆没有给出细粒度描述，只给出“用户登陆”这样的粒度描述，那么后期的设计开发怎么来处理这个“用户登陆”呢？这时候，经验主义跑出来说，当然是处理用户名和密码了；没错，这在大多数情况下的确如此，可这种经验主义的想当然合理吗？如果客户的意思还包括输入验证码，还包括USB锁安全认证，那么从一句“用户登陆”又怎么能反映出来呢？开发人员又是凭什么认为登陆一定是只处理用户名和密码？一定要注意，设计开发人员开发目标是需求，一定要紧盯需求，而不是自己心里的想当然。有经验的开发者容易在粗粒度需求下想当然，无经验的开发者容易在粗粒度需求下不知所措，这些都是需求的错！

       所以用例的粒度一定要细，细到不能再细为止。在这一点上没有什么好犹豫的，至于怎么让用例显得不罗唆，是另一个问题。细化和用户沟通可能会累（这其中也有一些方法可循），但这种细化工作才能体现出一个人的认真程度，也才能展示出需求分析人员并不是白吃干饭的，而是非常重要和需要努力做的一环。怎么算不能再细？以输入用户名为例，“输入用户名”这已经够了，而细化到“把鼠标往文本框中点击，用指头按键盘,甚至要先开机”则过了，这些操作不是我们系统的职责，我们的用例不需要描绘它们。除此之外，越细越好。

       在一个大型项目的需求分析中，如果把用例的粒度都以最细程度展示给客户看，那将是件恐怖的事情，整个屏幕的密密麻麻的用例图肯定让人眼花缭乱，头痛愈裂。这就需要把很多小用例合成为一个大用例，在整个系统中，用几个大用例就能很清楚的描绘出整体需求，使用户对需求有个整体把握，然后分别说明每个大用例中的小用例，直至最细粒度。也就是说，粒度要细，但要分层表示。用例的粗细，只是抽象层次不同，描述复杂的整体，就用高层次粗粒度描述，而粗粒度不能被架空，必须有低层次细粒度支持，这样分层描述避免了罗唆，也符合人们的认知习惯。实际上，对后期的建模也有重要参考作用。

       这样的用例分析也可以很自然的转换为用户的使用手册。前期的细致工作可以使后期工作量极大减少，从整体上大大的提高软件生产效率。

作者：dapplehou email:mmonkeyer@163.com