项目那点儿事---番外篇(一)之用例的粒度

文章来源:项目那点儿事                                                              作者: 羽之


前段时间发现网上很多朋友问我,做需求调研是明白的,写用例是了解的,但是需求划分成用例怎么做是不清楚的。

我查阅了一下,书里有讲需求的,有讲用例的,就是没有讲两者是怎么过渡的,仅有一本书讲到了《UML和模式应用》但比较抽象。鉴于这一事实,我们今天的主角是用例。


我想之所以没有书上讲怎么划分用例,是因为划分用例不是一个通用型的知识,就像可以教你兵法布阵,但指挥军队就不教了,如何做到如指臂使就没有书讲一样,因为这是经验,不是知识。历史无数次的证明,知识就是力量,但没有经验就是书呆子。像没有知识的但有经验的市井混混魏忠贤,不就把东林党这群有知识没经验的书呆子给打倒了吗。

闲话少说,要说划分用例,就要从需求分解讲起

问:把需求分解共需几步?
    答:三步。

第一步,分解需求。
    得到需求后要进行分解。这不是杀鸡一样乱分,要有规律的分。一个屡试不爽的方法就是按使用功能来分。分类是中国人的强项,老祖宗们最爱分类了。为了让大家知道分类,还流传下 “万般皆下品唯有读书高”这样的话。不过汉人都是按照学识和技能来分的,像元、清特别点,按血统分,读不读书无所谓,关键看你生在哪。不管怎么分都对,
    做个例子分解人的一生,按功能分,补充养分、休息、学习、工作。分好了,进行第二步。


    第二步,将使用功能分解成系统功能
    以上划分,只能草率的把需求分类,要实现这些需求,你必须分出系统功能。这就是我们说的功能列表了。就是光中了进士不行,还要分出哪些人是头甲,二甲,三甲。功能列表不仅包括这个功能名字,还要有功能描述,说说这功能都干了啥事!补充养分分解出吃饭、喝水、吃药、上厕所(排泄是为了更好的吸收);休息分解为午睡、夜睡、玩游戏等;学习分解为听课、看书、上博客园;工作分解为写代码、测试、摆摊等。


    第三步,将功能分解出操作
    光有功能不行啊,这个功能要执行操作的。前面了一大堆事,当然要告诉大家这些事是怎么实现的。比如睡觉,要有准备、开始睡、起床几个动作完成。

    至此需求分解完成

现在我们来看看等了半天还没出场有用例。

用例是一个很大的概念,有多大啊?大概有3公里那么大。
    我们这里只说一个方面,用例说明。我们来用个用例来说,大家容易理解一些,上床睡觉,这是一个挺好的用例,因为大家都熟悉。眼一闭一睁一天就过去了,嚎
       用例名称:上床睡觉
       参与者:待睡眠者
       涉众:此人可能打鼾
       前置条件:1、有困意
                 2、有床
                 3、有被
       后置条件:人进入睡眠状态,体能活动降低
       主业务流程:1、洗脸刷牙
                   2、脱衣
                   3、上床
                   4、钻被窝
                   5、开始睡觉
                   重复步骤5直到睡着
                   6、用例结束
扩展业务流程:
                   1a、没水了,今天放弃洗脸刷牙
                   1b、洗脸把盆打翻了,调用擦地用例,后继续
                   3a、上床没上好,摔地上了,调用自查用例,如无事继续上床
                   5a、重复30次无法入睡,数羊后继续睡觉
                   5b、数羊无效,数猪后继续睡觉
                   5c、数猪无效,放弃睡觉,今天失眠
       业务规则:  1、脱衣服时需保留裤头,如参与者有特殊要求可不保留裤头
                   2、数羊不得超过100只
                   3、数猪不得超过100头
                   4、上床后必须盖被

以上就是一个上床睡觉的用例,通过这个用例大家可以很好的明白用例说明是怎么用的了。
       特殊说明一下:
       涉众:是指涉及用例以外的事情或用例影响到的事。
       扩展业务流程的编号,必须与主业务流程编号相对应,这样看起来更明确。
       用例只描述用户看到和操作的东西,后台的东东一律不要写。
       UML中一直强调没有固定的用例格式,但潜规则一般认为上面的表格就是用例说明。


   从这个用例中,我们看到,一个完整用例只能表示一个从上至下的流程化动作,你一个用例描写赤壁大战是不可以的。以此来看,我们的用例只能对一个系统功能中的一种操作加以描述,这是最好的方法。

   但要是这样划分的,分解的工作量会成几何式上升。为了解决这个问题,我们把相同操作的用例拿出来,单独作为公共用例,以后不再复述。但就算这样,工作量依然贼大。
   看来从用例身上想着辙是没办法了。除非你偷赖,用例写的不全面。有时候想,这和修城墙是一样一样的。因为这个城是你要守的,现在让你修墙,你可好奸赖馋滑,糊弄完事。等敌人来了,用小凿子把你的墙打开时,你就哭吧。所以写用例时别偷赖。
   工作量大这是没办法的事,尤其对时间紧人手少的项目,也有变通的方法,每个功能都写一个用例,当然这种和稀泥的方法肯定有不足之处。
   我个人建议每个功能的每个操作做一个用例。而每个用例的实现时间不要超过8个人时。这样便于控制。

后话:

本来应该写《建立标准的数据库和系统框架结果》的,不过今天电脑坏了,没有装PD12,所以放在明天讲。今天插一篇番外篇。顾名思义就是讲一下与原作没啥太大关系的事,而里面的主角在原作中都是配角。未来我还会写一些番外篇,讲述一些项目相关但与原作无关的事。希望大家能喜欢。
   关于用例,我推荐大家看《UML和模式应用》,写得很好很全,不过我第一次看只看懂60%,这本书要反复看才行。

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

UML和模式应用

   一本经典的面向对象分析设计技术的入门书,众多知名专家强力推荐,值得我们置于案头,随时参考采撷。全球最畅销UML图书,三版累计销量超过11万册!新版本体现了Larman一贯的风格,准确并富有思想。这确实是一本上佳之作。
  --Alistair Cockburn
  人们经常问我,对于介绍OO设计而言,哪本书最好?在遇到这本书之后,我毫不犹豫地选择了它。
  --Martin Fowler
  本书英文版面世以来,广受业界专家和读者的好评,历经3个版本的锤炼,吸收了大量OOA,D的精华思想和现代实践方法。全书叙述清晰、用词精炼、构思巧妙,将面向对象分析设计的概念、过程、方法、原则和个人的实践建议娓娓道来,以实例为证,将软件的分析和设计的过程叙述得如逻辑推理一般,于细节处见真知。
  本书是一本经典的面向对象分析设计技术的入门书,适用范围广泛,从初学者到有一定对象技术知识但希望进一步提高开发水平的中级读者,甚至是资深的专业人员,都可以从本书获益匪浅,同时,本书也适合作为高等院校相关课程的教材和各类培训班的辅导教材。


本文链接:http://www.hihubs.com/article/60

关键字:项目那点儿事---番外篇(一)之用例的粒度

若无特别注明,文章皆为Hubs'm原创,转载请注明出处...O(∩_∩)O


微信沟通